Предприятие ОАО «Спартак» обратилось в компанию по разработке ПО для создания сайта предприятия. На протяжении всего времени работы компания-разработчик тесно сотрудничала с заказчиком. Определить, какой вид модели был использован для разработки. Что выясняла компания разработчик у заказчика.
Существуют три вида моделей ЖЦ ПО: каскадная (водопадная), эволюционная, спиральная.
Эволюционная модель основана на следующей идее: разрабатывается первоначальная версия программного продукта, которая передается на испытание пользователям, затем она дорабатывается с учетом мнения пользователей, получается промежуточная версия продукта, которая также проходит "испытание пользователем", снова дорабатывается и так несколько раз, пока не будет получен необходимый программный продукт. Отличительной чертой данной модели является то, что процессы специфицирования, разработки и аттестации ПО выполняются параллельно при постоянном обмене информацией между ними.
Различают два подхода к реализации эволюционного метода разработки.
1. Подход пробных разработок. В рамках этого подхода вначале разрабатываются те части системы, которые очевидны или хорошо специфицированы. Система эволюционирует (дорабатывается) путем добавления новых средств по мере их предложения заказчиком.
2. Прототипирование. Прототип* обычно строится для экспериментирования с той частью требований заказчика, которые сформированы нечетко или с внутренними противоречиями.
Так как процессы специфицирования, разработки и аттестации ПО в эволюционной модели выполняются параллельно при постоянном обмене информацией между заказчиком и разработчиком. В данном случае использовалась эволюционная модель.
Перечислить все виды моделей ЖЦ ПО.
Дать понятие спиральной модели разработки. Описать достоинства и недостатки.
На протяжении всего этапа разработки программного модуля «Кадровое агентство» уточнялись цели и требования к программному обеспечению, оценивалось качество разработанного фрагмента, планировались новые стадии разработки. Определить вид модели, использованной в данном случае. Ответ обосновать.
В данной модели процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внутренний виток спирали соответствует стадии принятия решения о создании ПО, на следующем витке определяются системные требования, далее следует стадия проектирования системы и т.д.
Каждый виток спирали разбит на четыре сектора.
1. Определение целей.
2. Оценка и разрешение рисков.
3. Разработка и тестирование.
4. Планирование.
Существенное отличие спиральной модели от других моделей процесса создания ПО заключается в точном определении и оценивании рисков.
В спиральной модели нет фиксированных этапов.
Эта модель может включать в себя любые другие модели разработки систем.
В данном случае использовалась спиральная модель разработки ПО, так как действия, описанные выше (на протяжении всего этапа разработки программного модуля «Кадровое агентство» уточнялись цели и требования к программному обеспечению, оценивалось качество разработанного фрагмента, планировались новые стадии разработки) указывают на использование этой модели.
Указать требования, предъявляемые к системе при разработке ПО.
Описать вышеизложенные требования и управление ими.
Как называется документ, содержащий требования - официальное предписание для разработчиков программной системы, который содержит пользовательские требования и детализированное описание системных требований.
Функциональные и нефункциональные требования.
1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
2. Нефункциональные требования. Описывают характеристики системы и ее окружения. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
В обеих ситуациях предоставляются документы, которые называются документированными требованиями к системе.