 |
Модели жизненного цикла ПО
|
|
|
|
Основные процессы
1. Процесс приобретения состоит из действий и задач заказчика, приобретающего ПО.
2. Процесс поставки охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой.
3. Процесс разработки предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПО.
4. Процесс эксплуатации охватывает действия и задачи организации, эксплуатирующей систему.
5. Процесс сопровождения предусматривает действия и задачи, выполняемые службой сопровождения, при изменениях или адаптации ПО.
Вспомогательные процессы
1. Процесс документирования предусматривает формализованное описание информации, созданной в течение ЖЦ ПО.
2. Процесс управления конфигурацией позволяет учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
3. Процесс обеспечения качества обеспечивает соответствующие гарантии того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам.
4. Процесс верификации состоит в определении правильности ПО.
5. Процесс аттестации предусматривает определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению.
6. Процесс совместной оценки предназначен для оценки состояния работ по проекту.
7. Процесс аудита представляет собой определение соответствия требованиям, планам и условиям договора.
8. Процесс разрешения проблем предусматривает анализ и решение проблем, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов, независимо от их происхождения или источника.
Организационные процессы
|
|
|
1. Процесс управления состоит из действий и задач, которые могут вы-полняться любой стороной, управляющей своими процессами (приобрете-ние, поставка и др.).
2. Процесс создания инфраструктуры охватывает выбор и поддержку технологии, стандартов и инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, экс-плуатации или сопровождения ПО.
3. Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.
4. Процесс обучения охватывает первоначальное обучение и после-дующее постоянное повышение квалификации персонала.
Взаимосвязь между процессами
Процессы ЖЦ ПО, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (или в различных аспектах), который показан на рис. 2.1. Такими аспектами являются:
• договорной аспект;
• аспект управления;
• аспект эксплуатации;
• инженерный аспект;
• аспект поддержки.
Модели жизненного цикла ПО
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО.Модель ЖЦ представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ.
В состав ЖЦ ПО обычно включаются следующие стадии:
1. Формирование требований к ПО.
2. Проектирование.
3. Реализация.
4. Тестирование.
5. Ввод в действие.
6. Эксплуатация и сопровождение.
7. Снятие с эксплуатации.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ISO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных стадиях.
|
|
|
К настоящему времени наибольшее распространение получили каскадная (1970 - 1985 гг.) и спиральная (1986 - 1990 гг.) модель ЖЦ ПО.
Принципиальной особенностью каскадной модели ЖЦ (рис. 2.2) является то что переход на следующую стадию осуществляется только после того как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия закан-чив1ется погнием некоторых результатов, которые служат в качестве игхмных данных для следующей стадии.
Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Рис. 2.2. Каскадная схема разработки ПО
Преимущества применения каскадного способа заключаются в следующем:
· на каждой стадии формируется законченный набор проектной документации;
· удобно планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования.
Недостатком каскадной схемы является то, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. Данный процесс, как правило, носит итерационный характер, т.е. результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. В результате реальный процесс создания ПО принимает иной вид (рис. 2.3). Это приводит к запаздыванию получения результатов. В результате риск создания системы, не удовлетворяющей изменившимся потребностям пользователей, повышается.
Обычно на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами:
· пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;
· за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.
Рис. 2.3. Реальный процесс разработки ПО
|
|
|
Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 2.4). Ее принципиальной особенностью является то, что ПО создается не сразу, как в случае каскадного подхода, а по частям, с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов, и планируются работы следующей итерации.
Спиральная модель избавляет пользователей и разработчиков ПО от необходимости полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации.
Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными
Основная проблема спирального цикла - определение момента перехода на следующую стадию.
Рис. 2.4. Спиральная модель ЖЦ ПО
|
|
|
