Дать понятие эволюционной модели ЖЦ ПО. Описать достоинства и недостатки

Предприятие ОАО «Спартак» обратилось в компанию по разработке ПО для создания сайта предприятия. На протяжении всего времени работы компания-разработчик тесно сотрудничала с заказчиком. Определить, какой вид модели был использован для разработки. Что выясняла компания разработчик у заказчика.

Существуют три вида моделей ЖЦ ПО: каскадная (водопадная), эволюционная, спиральная.

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

Различают два подхода к реализации эволюционного метода разработки.

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

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

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

Перечислить все виды моделей ЖЦ ПО.

Дать понятие спиральной модели разработки. Описать достоинства и недостатки.

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

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

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

1. Определение целей.

2. Оценка и разрешение рисков.

3. Разработка и тестирование.

4. Планирование.

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

В спиральной модели нет фиксированных этапов.

Эта модель может включать в себя любые другие модели разработки систем.

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

Указать требования, предъявляемые к системе при разработке ПО.

Описать вышеизложенные требования и управление ими.

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

Функциональные и нефункциональные требования.

1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

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

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