Тема 1.2 Жизненный цикл программного продукта. Модели жизненного цикла разработки ПО

Задачи обучения:

· Стимулировать и поддерживать развитие двигательной активности ребенка.

· Обогащать кинестетический опыт.

· Развивать умение воспринимать и воспроизводить фигуру по плоскостному образцу.

Тема 1.2 Жизненный цикл программного продукта. Модели жизненного цикла разработки ПО

Программы любого вида характеризуются жизненным цикломсостоящим из отдельных этапов:

I.Этап.Разработка алгоритма и программы.

II.Этап. Эксплуатация и сопровождение.

III.Этап. Завершение жизненного цикла.

I.Этап. Разработка алгоритма и программы.

1) Маркетинг и спецификация ПП предназначены для изучения требований к создаваемому программному продукту, а именно:

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

-установление требований пользователя к характеру взаимодействия с программным продуктом, типы пользовательского интерфейса (система меню, использование манипулятора мыши, типы подсказок, виды экранных документов и т.п.)

На данном этапе необходимо выполнить формализованную постановку задачи.

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

2) Проектирование структуры ПП связано с алгоритмизацией процесса обработки данных, детализации функций обработки, структуры ПП, структуры информационной базы, выбор методов и средств создания ПП, т.е. технология программирования.

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

4) Документирование ПП выполняется не самим разработчиком, а лицом, связанным с внедрением и распространением ПП. Документ должен содержать:

- сведения по установке и обеспечению надежной работы;

- поддерживать пользователя при выполнении функций обработки;

- определять порядок компенсирования ПП с другими программами.

II.Этап. Эксплуатация и сопровождение.

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

6,7)Эксплуатация ПП идет параллельно сопровождению. Она может начинаться и в отсутствии сопровождения или в случае завершения сопровождения. После снятия ПП с продажи, определенное время может выполняться его сопровождение.

III.Этап. Завершение жизненного цикла.

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

V

t

рисунок 3 - Кривая продаж программного продукта

Длительность жизненного цикла для различных программных продуктотв неодинакова. Для большинства измеряется в 2-3 года.

На рисунке 3 изображены этапы жизненного цикла и показаны их временное соотношение.

Модели жизненного цикла разработки программного продукта

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

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

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

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

Наибольшее распространение получили следующие модели жизненного цикла разработки ПП:

· каскадная модель, или «водопад» (Waterfallmodel);

· V-образная модель (V-shapedmodel);

· модель прототипирования (Prototypemodel);

· модель быстрой разработки приложений, или RAD-модель (RAD — RapidApplicationDevelopmentmodel);

· многопроходная модель (Incrementalmodel); спиральная модель (Spiralmodel).

Краткие характеристики каждой из перечисленных моделей приведены в таблице 1.

Таблица 1- Модели жизненного цикла разработки программного продукта

2) Каскадная модель

В однородных информационных системах 1970-х и 1980-х годов прикладные ПП представляли собой единое целое. Для разработ­ки такого типа ПП применялась каскадная модель, или «водопад» (waterfall) показанная на рисунке 8).

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

Преимущества каскадного способа:

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

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

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

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

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

Это объясняется следующими причинами:

пользователи не в состоянии сразу изложить все свои требо­вания и не могут предвидеть, как они изменятся в ходе разра­ботки;

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

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

Рисунок.