Каскадная модель(Модель жизненного цикла) ПО

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

График……………………………………..

Этапы:

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

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

3) Кодирование. Архитектура ПО реализуется в виде множества программ или программных модулей. Тестирование каждого модуля включает проверку его соответствия требованиям предъявляемым к данному модулю.

4) Сборка и тестирование системы. Отдельные программы и программные модули интегрируются и тестируются в виде целостной программной системы. Проверяется соответствие системы её спецификации.

5) Эксплуатация и сопровождение. Система инсталируется и начинается её эксплуатация. Сопровождение системы подразумевает исправление ошибок которые не были обнаружены на более ранних этапах. Совершенствование системных компонентов и модернизация функциональных возможностей системы. В соответствии с новыми требованиями.

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

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

Эволюционная модель разработки.(для малых до 500к строк кода)

Диаграмма………………………………………….

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

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

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

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

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

Разработка ПО на основе ранее созданных компонентов.

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

1) Спецификация требований.

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

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

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

5) Разработка и сборка системы. В данном подходе сборка системы является скорее частью разработки, чем отдельным этапом. Основное внимание на этом этапе уделяется интерфейсам повторно используемых компонентов модулей и систем.

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

Модель пошаговой разработки.

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

Достоинства:

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

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

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

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

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