Найти в Дзене
Kranst -technologies,IT news

Структура жизненного цикла ПО

Структура жизненного цикла ПО: основные, вспомогательные, организационные процессы. На рис. 1 представлена структура жизненного цикла информационных систем согласно стандарту ISO/IEC 12207. Рис. 1. Структура жизненного цикла ИС по стандарту ISO/IEC 12207 Процесс приобретения состоит из действий и задач заказчика, приобретающего ПО. Процесс поставки охватывает действия и задачи, выполняемые поставщиком. Разработка ПО – все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации. Эксплуатация – работы по внедрению компонентов ПО, конфигурирование БД и рабочих мест. Процесс сопровождения активизируется при изменениях программного продукта и соответствующей документации. Внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям. Управление конфигурацией – поддержка основных процессов ЖЦ ПО, прежде всего процессов разработки и сопровождения ПО. Обе
Оглавление

Структура жизненного цикла ПО: основные, вспомогательные, организационные процессы.

На рис. 1 представлена структура жизненного цикла информационных систем согласно стандарту ISO/IEC 12207.

Рис. 1. Структура жизненного цикла ИС по стандарту ISO/IEC 12207

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

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

Эксплуатация – работы по внедрению компонентов ПО, конфигурирование БД и рабочих мест.

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

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

Обеспечение качества проекта – верификация, проверка и тестирование ПО.

Управление проектом – планирование и организация работ, создание коллектива разработчиков, контроль за сроками и качеством выполняемых работ.

Вопрос 3. Модели жизненного цикла ПО. Каскадная и спиральная модели жизненного цикла ИС.

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

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

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

-2

Рис. 2. Каскадная модель ЖЦ ИС

Достоинства каскадной модели:

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

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

Недостатки каскадной модели:

· позднее обнаружение проблем;

· выход из календарного графика, запаздывание в получении результатов;

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

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

· высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей.

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

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

-3

Рис. 3. Спиральная модель ЖЦ ИС

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

Достоинства спиральной модели:

· ускорение разработки;

· постоянное участие заказчика в процессе разработки;

· разбивка большого объема работы на небольшие части;

· снижение риска (снижение вероятности непредсказуемого поведения системы).

Недостатки спиральной модели:

· сложность планирования;

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

· напряженный режим работы для разработчиков.

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