Стадии разработки программных продуктов и программной документации

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

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

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

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

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

Этапы проектирования и эксплуатации и сопровождения различаются целями, задачами, методами и средствами.

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

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

Достоинства классического ЖЦ: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

Недостатки классического ЖЦ:

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

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

3. результаты проекта доступны заказчику только в конце работы.

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

Основная цель макетирования — снять неопределенности в требованиях заказчика.

Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.

Модель может принимать одну из трех форм:

1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);

2) работающий макет (выполняет некоторую часть требуемых функций)

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

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

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

­ Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.

­ Быстрое проектирование приводит к построению макета.

­ Макет оценивается заказчиком и используется для уточнения требований к ПО.

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

Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования:

1. заказчик может принять макет за продукт;

2. разработчик может принять макет за продукт.

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

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

Стратегии конструирования ПО.

Существуют 3 стратегии конструирования ПО:

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

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

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

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

 

Быстрая разработка приложений.

Модель быстрой разработки приложений (Rapid Application Development) – второй пример применения инкрементной стратегии конструирования.

 

 

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD-высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, Rad-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

­ бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется инф-ция? Кто генерирует ее? Где инф-ция применяется? Кто ее обрабатывает?

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

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

­ генерация приложения. Предполагает использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации.

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

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

Применения RAD имеет и свои недостатки и ограничения.

1. для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп);

2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной;

3. RAD не применима в условиях высоких технических рисков (т.е. при использовании новой технологии).

Спиральная модель – классический пример применения эволюционной стратегии конструирования.

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

 

 

Спиральная модель: 1- начальный сбор требований и планирование проекта, 2- та же работа, на основе рекомендаций заказчика, 3- анализ риска на основе начальных требований, 4-анализ риска на основе реакции заказчика, 5- переход к комплексной системе, 6- начальный макет системы, 7-следующий уровень макета, 8- сконструированная система, 9-оценование заказчиком.

Как показано на рисунке, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

1. планирование – определение целей, вариантов и ограничений.

2. анализ риска – анализ вариантов и распознавание/выбор риска

3. конструирование – разработка продукта следующего уровня

4. оценивание – оценка заказчиком текущих результатов конструирования.

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

В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации. Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.

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

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

1. наиболее реально (в виде эволюции) отображает разработку ПО

2. позволяет явно учитывать риск на каждом витке эволюции разработки

3. включает шаг системного подхода в итерационную структуру разработки

4. использует моделирование для уменьшения риска и совершенствования программного изделия

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

1. новизна (отсутствует достаточная статистика эффективности модели)

2. повышенные требования к заказчику

3. трудности контроля и управления временем разработки

 

Закрепление материала

 

Изобразите схему инкрементной, спиральной модели и модели быстрой разработки программных продуктов

 

 

Самостоятельная работа

Проведите анализ всех достоинств и недостатков изученных моделей

 

 

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

 

«______»______________2012г.

Лекция 6,7

Техническое задание и требование к его содержанию