Жизненный цикл ПС, связь с ядром знаний SWEBOK

Программная инженерия, как инженерная дисциплина, охватывает все аспекты создания ПС от начальной стадии разработки системных требований до реализации программного продукта и его использования.

Под программной системой (ПС) понимается комплекс интегрированных программ и средств, которые реализуют функции предметной области в заданной среде. В комплекс могут входить: прикладные системы (зарплата, учет и др.), общесистемные компоненты (отладчик, редактор, СУБД), системы защиты и безопасности и др.

Программное обеспечение - это некоторая конкретная функции системы (например, программный модуль решения одной общей задачи, ОС - функционирование программ и систем, управление данными и др.). ПО может входить в состав ПС или быть идентичным ПС.

Каждая ПС на протяжении своего существования проходит определенную последовательность процессов (этапов), начиная от постановки задачи до ее воплощения в готовую программу, эксплуатации и изъятия из эксплуатации. Такая последовательность этапов называется жизненным циклом (ЖЦ) разработки ПС. На каждом этапе ЖЦ выполняется определенная совокупность процессов и/или подпроцессов, каждый из которых порождает соответствующий промежуточный продукт, используя при этом результаты предыдущего процесса и продукта.

Все продукты программной инженерии представляют собой некоторые описания, а именно, тексты требований к разработке ПС, согласованные договоренности с заказчиком, архитектуру, структуру данных, тексты программ, документацию, инструкции по эксплуатации и т.п. Главные ресурсы разработки ПС в программной инженерии - это сроки, время и стоимость. Правильное управление и использование этих ресурсов при выполнении задач и действий процессов ЖЦ определяет эффективность разработки ПС.

Разновидности действий и задач, представленные в процессах ЖЦ ПС, отображены в международном стандарте ISO \IEC 12207 (таблица 1) и связаны содержательно с областями знаний SWEBOK.

Данный стандарт устанавливает общую структуру и содержание ЖЦ ПС, начиная от разработки концепции до утилизации системы. Структура представляет собой множество процессов, взаимосвязей между ними и определений действий и задач на процессах ЖЦ. Иными словами, ЖЦ определяет, что надо делать, а не как выполнять те или иные действия.

Стандарт не обязывает использовать определенную модель ЖЦ ПО или конкретную методологию разработки ПО и не предъявляет требования к формату и содержанию создаваемых документов. Поэтому организация- пользователь этого стандарта должна для своей работы разработать стандарты предприятия, методики и процедуры, определяющие разные детали процесса разработки ПО.

Таблица 1.1. Процессы ЖЦ в стандарте ISO/IEC 12207
№ п/п	Наименование процессов (подпроцессов)
1. Категория "Основные процессы"
1.1	Заказ (договор)
1.1.1	Подготовка заказа, выбор поставщика
1.1.2	Мониторинг деятельности поставщика, Приемка потребителем
1.2	Поставка (приобретение)
1.3	Разработка
1.3.1	Выявление требований
1.3.2	Анализ требований к системе
1.3.3	Проектирование архитектуры системы
1.3.4	Анализ требований к ПО системы
1.3.5	Проектирование ПО
1.3.6	Конструирование (кодирование) ПО
1.3.7	Интеграция ПО
1.3.8	Тестирование ПО
1.3.9	Системная интеграция
1.3.10	Системное тестирование
1.3.11	Инсталляция ПО
1.4	Эксплуатация
1.4.1	Функциональное использование
1.4.2	Поддержка потребителя
1.5	Сопровождение
2. Категория "Процессы поддержки"
2.1	Документирование
2.2	Управление конфигурацией
2.3	Обеспечение гарантии качества
2.4	Верификация
2.5	Валидация
2.6	Общий просмотр
2.7	Аудит
2.8	Решение проблем
2.9	Обеспечение применимости продукта
2.10	Оценивание продукта
3. Категория "Организационные процессы"
3.1	Категория управления
3.1.1	Управление на уровне организации
3.1.2	Управление проектом
3.1.3	Управление качеством
3.1.4	Управление риском
3.1.5	Организационное обеспечение
3.1.6	Измерение
3.1.7	Управления знаниями
3.2	Усовершенствование
3.2.1	Внедрение процессов
3.2.2	Оценивание процессов
3.2.3	Усовершенствование процессов

Отметим, что ISO выпустил ряд руководств и процедур, дополняющих стандарт ISO \IEC 12207. Основная идея данного стандарта - разработка и сопровождение ПС я так, как этого требует инженерная дисциплина. В процессе разработки создается каркас системы (абстрактная архитектура с вы деленными объектами), для которой определены среда, виды обеспечения, исполнители и сроки.

Как видно из табл. 1.1, все процессы в данном стандарте разделены на три категории:

· основные процессы;

· обеспечивающие (поддерживающие) процессы;

· организационные процессы.

Для каждого из процессов определены виды деятельности (действия - activity), задачи, совокупность результатов (выходов) видов деятельности и задач, а также некоторые специфические требования. Стандарт дает перечень работ для основных обеспечивающих и организационных процессов. Пункты 1.1.1, 1.1.2, а также категории 2 и 3 процессов определяют виды деятельности, цели и задачи которых оговорены в стандарте, но не определяют форму их представления.

К основным процессам относятся:

· процесс приобретения инициирует ЖЦ ПС и определяет действия организации покупателя (или заказчика), которая приобретает автоматизированную систему, программный продукт или сервис. Этот процесс включает следующие виды деятельности: инициирование и подготовка запроса, оформление контракта и его актуализация; мониторинг поставщиков, приемка и завершение;

· процесс поставки определяет действия поставщика, по снабжению покупателя программным продуктом или сервисом. Данный процесс включает в себя следующие виды деятельности: подготовку предложений (ответов на запросы); оформление контракта; планирование, выполнение и контроль поставляемого продукта; анализ и оценку продукта; поставку и завершение работ по поставке. Процесс поставки начинается тогда, когда устанавливаются договорные отношения на поставку ПС между заказчиком и поставщиком. В зависимости от условий договора с заказчиком процесс поставки может включать процесс разработки ПО, процесс эксплуатации и обеспечения служб эксплуатации ПО или сопровождения для исправления и улучшения ПС;

· процесс разработки определяет действия предприятия разработчика программного продукта: анализ требований к системе; проектирование архитектуры системы; детальное проектирование компонентов ПС; кодирование и тестирование ПС; интеграцию системы; квалификационное тестирование; установку ПС; обеспечение приемки ПС;

· процесс эксплуатации определяет действия предприятия оператора, которое обеспечивает обслуживание системы в процессе ее эксплуатации пользователями (консультирование пользователей, изучение потребностей оператора с точки зрения удовлетворения их системой и т.д.). Этот процесс определяет задачи и действия по функциональному тестированию, проверочной эксплуатацией системы; предоставление пользователю необходимых инструкций и документации по запуску и эксплуатации ПО;

· процесс сопровождения определяет действия организации, выполняющей сопровождение программного продукта (управление модификациями, поддержку текущего состояния и функциональной пригодности, инсталляцию и удаление программного продукта на вычислительной системе пользователя). Данный процесс включает задачи и действия по анализу проблем сопровождения и модификации; разработке планов и реализации модификации системы; анализу результатов сопровождения после изменений системы; миграции (перемещению) ПС в другую среду или ее удалению из употребления.

К обеспечивающим процессам создания ПС относятся: документирование, управление версиями, верификация и валидация, просмотры, аудиты, оценивание продукта и др. Процессы управления версиями соответствуют управлению конфигурацией системы, которая так же, как и продукты процессов должна проверяться на правильность реализации целей проекта и соответствия требованиям заказчика. Задачи проверки рекомендуется выполнять специальным контролерам, обладающим знаниями методов и процессов проектирования ПС.

К организационным процессам отнесены: управление проектом (менеджмент разработки), качеством и рисками и др. Эти процессы выполняются специальными службами, выполняющими планирование работ на проекте, контроль процессов, определение метрик для измерения продуктов, проверку показателей качества, соблюдение стандартных положений и др.

Процессы, определенные в стандарте ISO /IEC 12207, охватывают все возможные задачи и действия по проектированию и разработке ПС. Пользователь стандарта может выбрать из них соответствующее подмножество для достижения конкретной цели, стоящей перед данным проектом. Процессы, действия и задачи приведены в стандарте в наиболее общей естественной последовательности. В зависимости от целей конкретного проекта процессы, действия и задачи выбираются, упорядочиваются и применяются итерационно или рекурсивно. Главный разработчик и менеджер должны определить задачи проекта, выбрать под их реализацию модель ЖЦ ПО, которая позволит учитывать ресурсы, стоимость и временные характеристики программного проекта.

Данный стандарт определяет содержание деятельности в сфере технологии разработки ПС, а знания, которые необходимы исполнителям для выполнения всех видов деятельности по проектированию и реализации поставленных задач перед проектом, определяют методы и средства областей ядра знаний SWEBOK, которые распределяются по отдельным процессам и подпроцессам при формировании модели ЖЦ для конкретного проекта.

Как уже отмечалось, между стандартом ISO \IEC 12207 и ядром знаний SWEBOK существует связь и взаимовлияние друг на друга, тем более что в разработке обоих документов примерно в одно время принимали участие высококвалифицированные специалисты в области программирования и информатики.

Общие идеи и методы программирования, сложившиеся в 90-х годах прошлого столетия, проникли в оба направления и оказали влияние на их структуру и содержание. Программисты-профессионалы систематизировали накопившиеся знания и создали 10 разделов, которые близки процессам ЖЦ по целям, задачам и видам деятельности. В ядре знаний SWEBOK они изложены как фундаментальные знания и инженерные методы управления разработкой ПО, а в стандарте как общие положения, структура и регламентированные процессы проектирования как рекомендации по разработке проекта, начиная от процесса постановки требований до эксплуатации ПО.

Следует отметить, что структура ядра знаний SWEBOK не лишена недостатков. Так, между областями знаний в этом ядре имеются пересечения, а некоторые важные направления в области программирования вообще не отражены в нем. Например, методы доказательства правильности программ, эволюция программ, распределенные и неоднородные среды, взаимодействие систем, некоторые методы программирования (сервисные, аспектные, агентные и др.), CASE-системы и др.

Технологические процессы в стандарте структурированы системно. Они не устанавливают связь с существующими методами и средствами программной инженерии, что создает возможность выбирать подходящие процессы стандарта и сопоставлять им привычные методы (объектные, компонентные, сервисные и др.), т.е. те, которые уже использовались коллективом разработчиков и для которых есть инструменты поддержки. Это и отражает идею совершенствования процесса инженерии ПО.

Процессы стандарта отвечают на вопрос, какие действия и задачи процессов ЖЦ надо выбрать, чтобы построить конкретную ПС. Ядро знаний SWEBOK отвечает на вопрос, какими методами, средствами и инструментами надо выполнять регламентированные действия и задачи процессов ЖЦ, чтобы построить ПС.

Программная инженерия сформировалась как инженерная дисциплина, которая базируются на теоретических и прикладных методах и средствах разработки ПС и стандартах (ISO /IEC 12207, 15404, ISO 9126 и др.), содержащих рекомендации, правила и методики управления разработкой ПС. Эти два базиса объединяет инженерия оценивания результатов на процессах ЖЦ, управление качеством ПС, оценка затраченных ресурсов на создание и учет стоимости работ участников разработки.

Инженерия программирования делает акцент на принципы, методы и подходы к управлению проектом, конфигурацией и качеством ПС. Стандарты регламентируют основные процессы, определяющие порядок проведения работ по реализации ПС, рекомендуют процессы организационной деятельности по управлению, планированию и оцениванию работ, выполняемых при проектировании и разработке ПС.

Ядро знаний SWEBOK, а также многочисленные монографии и статьи по методам и средствам программной инженерии предоставляют всю необходимую информацию для выбора наиболее подходящего метода, средства, инструмента. Вместе с тем стандарт - это руководство к построению процессов в сочетании с методами для реализации конкретного программного проекта на стандартизованной инженерной основе.

Естественно, что в небольших программных проектах всегда будет место творческим и неформальным подходам, вносимым отдельными профессионалами, при создании разного рода уникальных продуктов, процесс разработки которых не всегда вкладывается в общее стандартное русло.

Таким образом, программная инженерия базируется на ядре SWEBOK и стандартах ЖЦ. Инженерия производства ПС основывается на стандартных организационных процессах - планирования, управления и сопровождения. Цель планирования - составление планов и графиков работ по реализации проекта и распределение работ между разными категориями специалистов с учетом их квалификации и уровня знаний проблематики программной инженерии. Второй процесс обеспечивает привнесение методов управления в процесс выполнения работ по программированию, а именно, управление временем, стоимостью и сроками. Третий процесс - это выполнения проекта, обнаружение и устранение найденных недостатков и замена или внесения новых функций в систему.

Контрольные вопросы и задания

1. Назовите цели и задачи программной инженерии.

2. Назовите области знаний SWEBOK инженерии разработки ПО.

3. Приведите базовые понятия области знаний "Тестирование ПО".

4. Определите цели и задачи области знаний "Управление проектом".

5. Определите цели и задачи области знаний "Инженерия качества ПО".

6. Дайте определение ЖЦ разработки ПО.

7. Назовите три основные группы процессов жизненного цикла и перечислите процессы каждой из групп.

8. Назовите организационные процессы ЖЦ и перечислите их.

9. Дайте характеристику процесса управления качеством ЖЦ.

10. Какой международный стандарт определяет перечень и содержание процессов ЖЦ ПО?

11. Все ли процессы, указанные в стандарте, должны быть выполнены при каждой разработке ПО?

Тема 2. Модели жизненного цикла для разработки программных систем

а десятилетия опыта построения программных систем был наработан ряд типичных схем последовательности выполнения работ при проектировании и разработки ПС. Такие схемы получили название моделей ЖЦ.

Модель жизненного цикла - это схема выполнения работ и задач в рамках процессов, обеспечивающих разработку, эксплуатацию и сопровождение программного продукта, и отражающая эволюцию ПС, начиная от формулировки требований к ней до прекращения пользоваться ею [1.14], [[2.2- 2.6].

Исторически в эту схему работ включают:

· разработку требований или технического задания;

· разработку системы или технического проекта;

· программирование или рабочее проектирование;

· пробную эксплуатацию;

· сопровождение и улучшение;

· снятие с эксплуатации.

Основное назначение моделей ЖЦ состоит в следующем:

· планирование и распределение работ между разработчиками и ресурсов, а также управление программным проектом;

· обеспечение взаимодействия между разработчиками проекта и заказчиком;

· наблюдение и контроль работ, оценивание промежуточных продуктов ЖЦ на соблюдение спецификаций требований, правильное их выполнение, оценивание продукта и реальных затрат, в том числе и по применяемым программным средствам и инструментам;

· согласование промежуточных результатов с заказчиком;

· проверка правильности конечного продукта путем его тестирования на запланированных и согласованных с заказчиком наборах тестов;

· оценивание соответствия характеристик качества полученного продукта заданным требованиям;

· обсуждение используемых процессов ЖЦ в плане оценки их возможностей и недостатков, проявившихся при их применении, а также определение направлений усовершенствования или модернизации ЖЦ и др.

В связи с такими задачами, возлагаемыми на модель ЖЦ, необходимо сделать правильный выбор процессов, их задач и действий для построения модели ЖЦ ПС, которая удовлетворяет концептуальной идее проектируемой системы с учетом ее сложности и масштаба работ. В модель ЖЦ обязательно включаются процессы реализации работ и задач, обеспечивающие создание промежуточного продукта и переход к следующему процессу модели.

2.1. Процессы ЖЦ стандарта ISO/IEC 12207

При выборе схемы модели ЖЦ для конкретной предметной области, решаются вопросы включения важных для создаваемого продукта видов работ или не включения несущественных работ. На сегодня основой формирования новой модели ЖЦ для конкретной прикладной системы является стандарт ISO /IEC 12207, который задает полный набор процессов (более 40), охватывающий все возможные виды работ и задач, связанных с построением ПС, начиная с анализа предметной области и кончая изготовлением соответствующего продукта. Данный стандарт содержит основные и вспомогательные процессы (рис. 2.1 и рис. 2.2).

увеличить изображение
Рис. 2.1. Схема основных процессов ЖЦ ПС

На рис. 2.1. представлены процессы, связанные непосредственно с разработкой ПС. К категории основных процессов относятся также "первичные" процессы, определяющие порядок подготовки договора на разработку ПС, мониторинг деятельности поставщиков ПС заказчику.

Стандарт ISO /IEC 12207 предоставляет структуру процессов ЖЦ, но не обязывает использовать все процессы в модели ЖЦ ПО или в конкретной методологии разработки ПО.

увеличить изображение
Рис. 2.2. Схема вспомогательных процессов ЖЦ ПС

Являясь стандартом высокого уровня, он не задает детали того, как надо выполнять действия или задачи, составляющие процессы. Он также не задает требований к формату и содержанию документов, выпускаемых на разных процессах.

Процессы, действия и задачи приведены в стандарте в наиболее общей естественной последовательности. Это не значит, что в такой же последовательности они должны быть применены в конкретной модели ЖЦ ПС. В зависимости от проекта процессы, действия и задачи стандарта выбираются, упорядочиваются и включаются в модель ЖЦ. При применении они могут перекрывать, прерывать друг друга, выполняться итерационно или рекурсивно. Это определяет "динамический" характер стандарта и позволяет реализовать с его помощью произвольную модель ЖЦ ПС. Поэтому организации, которая намерена применить этот стандарт в своей работе, понадобятся дополнительные стандарты или процедуры, определяющие разные детали по применению выбранных элементов ЖЦ. Отметим, что комитет ISO выпускает руководства и процедуры, дополняющие стандарт 12207.

Кроме этого, стандарт ISO /IEC 12207 предоставляет основу для принятия ряда других связанных с ним стандартов, таких как

стандарты по управлению ПО, обеспечению качества, верификации и валидации, управлению конфигурацией, метриками ПО и т.д.

Из данного стандарта можно выбрать только те процессы, которые более всего подходят для реализации конкретной ПС. Обязательными являются основные процессы, которые присутствуют во всех известных моделях ЖЦ. В зависимости от целей и задач предметной области они могут быть пополнены дополнительными (документирование, обеспечение качества, верификация и валидация и т.п.) и организационными (планирование, управление и др.) процессами этого стандарта. Разработчик принимает решение о включении в новую создаваемую модель ЖЦ процесса обеспечения качества компонентов и системы управления проектом или определения набора проверочных (верификационных) процедур для обеспечения правильности продукта и соответствия его заданным требованиям.

Процессы, включенные в модель ЖЦ, предназначены для реализации стандартных задач процессов ЖЦ и могут привлекать другие процессы для реализации специализированных задач системы (например, защиты данных). Интерфейсы (входы и выходы) любых двух процессов ЖЦ должны быть минимальными и каждый из них должен удовлетворять следующим правилам:

· если процесс вызывается процессом и только процессом , то принадлежит ;

· если функция вызывается более чем одним процессом, то она становится отдельным процессом;

· проверка любой функции в ЖЦ является обязательной.

Иными словами, если задача требуется более чем одному процессу, то она может стать процессом, используемым однократно или многократно на протяжении жизни конкретной системы. Каждый процесс должен иметь внутреннюю структуру, установленную в соответствии с тем, что он должен выполнять.

Процессы модели ЖЦ ориентированы на разработчика системы. Он может выполнять один или несколько процессов и процесс может быть выполнен одним или несколькими разработчиками. При этом один из них является ответственным за один процесс или за все процессы модели, даже если отдельные работы выполняет другой разработчик.

Создаваемая модель ЖЦ увязывается с конкретными методиками разработки систем и соответствующими стандартами в области программной инженерии либо разрабатываются самостоятельно для проекта с учетом его возможностей и особенностей. Иными словами, каждый процесс ЖЦ подкрепляется выбранными для реализации задач ПС средствами, методами программирования и методикой их применения и выполнения.

Важную роль при формировании модели ЖЦ имеют организационные аспекты:

· планирование последовательности работ и сроков их исполнения;

· подбор и подготовка ресурсов (людских, программных и технических) для выполнения работ;

· оценка возможностей реализации проекта в заданные сроки, стоимость и ресурсы.

Внедрение модели ЖЦ в практическую деятельность по созданию программного продукта позволяет упорядочить взаимоотношения между субъектами процесса разработки ПС и учитывать динамику модификации требований к проекту и к системе.

Пример. ЖЦ разработки ПС с задачами и действиями для процесса тестирования. Основное назначение процесса тестирования ЖЦ - выполнение задач процесса на основе входов (входные данные для выполнения задач процесса) и выходов при завершении задач, а также ролей и действий исполнителей этих задач.

В соответствии со стандартом ISO /IEC 12207 были выявлены задачи тестирования и распределены по процессам ЖЦ ПС. В результате был получен единый непрерывный процесс тестирования разных ПС, задачами которого являются подготовка,проведение и оценивание результатов тестирования, которые распределились по 20 действиям (шагам) процесса разработки [2.7,2.9]. Данный подход к тщательному тестированию ПС целесообразно применять, например, для систем реального времени.

На шаге подготовки осуществляется анализ рабочих продуктов процесса разработки ПС (входных для данного шагу процесса тестирования) для определения целей, объектов, сценариев и ресурсов тестирования, адекватных шагу тестирования. Результаты выполнения шагов подготовки тестирования должны фиксироваться в планах тестирования.

На шаге выполнения осуществляется фиксация результатов выполнения тестов, их сравнение с ожидаемыми результатами, определение текущего состояния рабочего продукта ПС и принятие решения о достаточности тестирования.

Каждый шаг процесса разработки состоит из набора решаемых задач, распределение по процессам и подроцессам ЖЦ (рис. 2.3).

Шаги процесса и отдельные задачи могут выполняться циклически для разных объектов ПС при их тестировании.

увеличить изображение
Рис. 2.3. ЖЦ разработки ПС с конкретизированными задачами на подпроцессах тестирования

Описание семантики задач и шагов процесса тестирования представлено в табл. 2.1.

Для подключения задач тестирования ко всем процессам ЖЦ проводится: распределение обязанностей между участниками процесса с учетом требований относительно их профессиональной подготовки; определение стандартов на представление окончательных документов, метрик процесса, критериев начала и завершения задач и перехода к следующему шагу процесса; подбор методов тестирования для выбранного класса ПС для проверки правильности выполнения задач тестирования; разработка специальных шаблонов документов для документирования процесса тестирования относительно каждого шага процесса тестирования.

Таблица 2.1. Состав задач процесса тестирования
Шаг процесса	Задачи процесса тестирования
1. Создание группы тестирования	1.1. Определение участников процесса тестирования
1.2. Распределение обязанностей в группе и формирование плана тестирования
2. Анализ риска	2.1. Идентификация рисков
2.2. Упорядочение рисков
2.3. Распределение ресурсов
3. Определения целей тестирования	3.1. Идентификация целей тестирования
3.2. Определения критериев прохождения тестов
3.3. Приведения в порядок целей тестирования по оценкам риска
4. Разработка планов тестирования	4.1. Разработка плана тестирования ПС
4.2. Разработка плана интеграционного тестирования
4.3. Разработка плана автономного тестирования
4.4. Разработка плана комплексного тестирования
5. Разработка тестов	5.1. Проектирование и разработка тестов
5.2. Подготовка тестовых данных
5.3. Проверка тестовых документов
6. Автономное и интеграционное тестирование	6.1. Автономное тестирование модулей и анализ результатов
6.2. Интеграционное тестирование
6.3. Повторное тестирование после устранения дефектов
6.4. Анализ результатов интеграционного тестирования
7. Тестирования ПС	7.1. Утверждение среды и ресурсов тестирования
7.2. Тестирование ПС
7.3. Повторное тестирование ПС после устранения дефектов
7.4. Анализ результатов завершения тестирования ПС
7.5. Тестирование инсталляции ПС
8. Составление документа по тестированию ПС и подготовка отчета	8.1. Сбор и анализ данных о результатах тестирования
8.2. Подготовка решений и рекомендаций по использованию ПС
8.3. Подготовка итогового документа о результатах тестирования
8.4. Проверка решений и подготовка документа отчета

При завершении тестирования ПС для определения времени тестирования, стоимости работ учитываются результаты тестирования процесса разработки ПС и оформляется отчетный документ по изготовлению ПС. Оценивание риска отказов проводится на этапе подготовки тестирования и на шагах анализа.