Презентация "Модели жизненного цикла ПО"

Основные вопросы

Понятие модели ЖЦ ПО
Каскадная модель
V-образная модель
Процесс макетирования ПО
Инкрементная модель
Спиральная модель
Компонентная модель
Модель быстрой разработки приложений
Выбор модели для реализации проекта

Модели жизненного цикла

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

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

Модели жизненного цикла

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

Виды стратегий жизненного цикла

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

Виды стратегий жизненного цикла

Каскадная (водопадная) модель

Автор: Уинстон Ройс, 1970 г

Каскадная (водопадная) модель

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

Этап анализа требований:
детальное определение функциональных и нефункциональных требований, предъявляемых к разрабатываемому ПО;
завершается задача планирования проекта.

Каскадная (водопадная) модель

Этап проектирования:

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

оценка качества будущего программного обеспечения.

Каскадная (водопадная) модель

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

Этап тестирования:
проверка корректности выполнения программы;
обнаружение и исправление ошибок в функциях, логике и форме реализации программного продукта.

Этап внедрения:
выполнение установки разработанного ПО у заказчика;
обучение персонала;
плавный переход от старого ПО (если оно есть) к использованию нового.

Каскадная (водопадная) модель

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

Преимущества каскадной модели

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

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

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

Каскадная модель жизненного цикла

Критерии применения каскадной модели:
требования к ПО и их реализация максимально четко определены и понятны;
неизменяемое определение про­дукта и вполне понятные технические методики;
если компания имеет опыт построения подобного рода систем.

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

Модель водоворота

V-образная модель

V-образная модель

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

V-образная модель

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

V-образная модель

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

Преимущества V-образной модели

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

Недостатки V-образной модели

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

Область применения V-образной модели

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

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

V-образная модель – это отличный выбор для систем, в которых требуется высокая надежность.

Макетирование

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

Процесс макетирования

Преимущества макетирования

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

Преимущества макетирования

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

Недостатки макетирования

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

Критерии применения макетирования

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