Жизненный цикл ПО и его стандартизация, процессы ЖЦ ПО, группы процессов ЖЦ ПО

 

В технологиях разработки программного обеспечения понятие жизненного цикла является одним из основных.

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

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

Согласно стандарту ISO/IEC 12207 все процессы ЖЦ ПО разделены на три группы:

1. основные процессы:

1.1. приобретение;

1.2. поставка;

1.3. разработка;

1.4. эксплуатация;

1.5. сопровождение;

2. вспомогательные процессы:

2.1. документирование;

2.2. управление конфигурацией;

2.3. обеспечение качества;

2.4. верификация;

2.5. аттестация;

2.6. совместная оценка;

2.7. аудит (определение соответствия требованиям, планам и условиям договора);

2.8. разрешение проблем;

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

3.1. управление;

3.2. инфраструктура;

3.3. усовершенствование

3.4. обучение.

3. Процесс разработки ПО: основные действия и их содержание

 

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

Процесс разработки включает следующие действия:

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

2) Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, к внешним интерфейсам и т.д.

3) Проектирование архитектуры системына высоком уровне заключается в определении компонентов ее оборудования, ПО и операций, выполняемых эксплуатирующим систему персоналом.

4) Анализ требований к ПО

Проектирование архитектуры ПО

6) Детальное проектирование ПО

Кодирование и тестирование ПО

8) Интеграция ПО предусматривает сборку разработанных компонентов ПО в соответствии с планом интеграции и тестирование агрегированных компонентов.

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

10) Интеграция системы заключается в сборке всех ее компонентов, включая ПО и оборудование.

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

12) Установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором.

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

 

Сертификация процессов разработки ПО, модель CMM

Гарантия качества процессов разработки программных продуктов является весьма значимой в современных условиях. Такую гарантию дают сертификаты качества процесса, подтверждающие его соответствие принятым международным стандартам. Наиболее авторитетными являются модели стандартов ISO 9001:2000, ISO/IEC 15504 и модель зрелости процесса разработки ПО (Capability Maturity Model – CMM).

Основным понятием модели CMM является зрелость процессов (Software process maturity). Зрелость процессов – это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации.

В модели CMM выделены пять уровней технологической зрелости, которые в принципе могут быть достигнуты компанией:

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

2. На повторяемом уровне внедряются формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Выполнение проекта на этом уровне планируется и контролируется, а применяемые для этих целей средства дают возможность повторения ранее достигнутых успехов.

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

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

5. На высшем, оптимизирующем, уровне главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.

 

Стратегии жизненного цикла ПО: понятие, виды и их сравнительная характеристика

 

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

Всего существует три стратегии разработки ПО:

- однократный проход (водопадная стратегия) – линейная последовательность этапов конструирования;

- инкрементная стратегия – разработка ПО ведется с определения всех требований к ПО, а оставшаяся часть разработки выполняется в виде последовательности версий: каждая новая версия реализует дополнительные возможности по сравнению с предыдущей версией;

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

Таблица 1 - Характеристики стратегий разработки согласно стандарту IEEE/EIA 12207.2

Стратегия конструирования	Определение требований в начале разработки	Количество циклов разработки	Распространение промежуточного ПО
Однократный проход	Все	Один	Нет
Инкрементная стратегия	Все	Несколько	Возможно
Эволюционная стратегия	Только часть требований	Несколько	Да

 

 

Каскадная модель жизненного цикла ПО: описание, преимущества и недостатки,

Критерии применения

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

Системный анализ – Анализ требований – Проектирование – Реализация – Тестирование – Внедрение – Сопровождение

Системный анализ: задается роль каждого элемента и их взаимодействие друг с другом.

Анализ требований: определение функциональных и нефункциональных требований к ПО.

Проектирование: трансляция требований к ПО во множество проектных представлений. Также на этом этапе осуществляется оценка качества будущего программного обеспечения.

Реализация: преобразование проектных спецификаций в текст на ЯП (язык прогр.) (кодирование).

Т естирование: проверка корректности, исправление ошибок в функциях и логике.

Внедрение: установка разработанного ПО у заказчика, обучение персонала.

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

Преимущества:

- модель хорошо известна потребителям;

- хорошо срабатывает для тех проектов, которые достаточно понятны

- весьма доступна для понимания, проста и удобна в применении;

- ее структурой может руководствоваться даже неопытный персонал;

- отличается стабильностью требований;

- хорошо срабатывает тогда, когда требования к качеству доминируют над тре­бованиями к затратам и графику выполнения проекта;

- способствует осуществлению строгого контроля менеджмента проекта;

- стадии модели довольно хорошо определены и понятны;

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

Недостатки:

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

- Выражение "35 процентов выполнено" — не несет никакого смысла и не является показа­телем для менеджера проекта;

- интеграция всех полученных результатов происходит в завершающей стадии работы модели;

- у клиента едва ли есть возможность ознакомиться с системой заранее;

- все требования должны быть известны в начале жизненного цикла;

- возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;

- модель основана на документации, а значит, количество документов может быть избыточным;

- весь программный продукт разрабатывается за один раз. Нет возможности раз­бить систему на части;

- отсутствует возможность учесть переделку и итерации за рамками проекта.

Критерии применения: каскадная модель может использоваться при создании ПО, для которого в самом начале разработки можно достаточно точно и полно сформулировать все требования.