Инкрементная модель, спиральная модель разработки ПО: жизненный цикл, достоинства и недостатки.

Инкрементная модель объединяет в себе достоинства двух подходов: классического подхода и макетирования.

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

Для каждого инкремента выполняется:

– Анализ, на котором мы собираем требования и анализируем, и планируем сам инкремент;

– Проектирование, на котором происходит проектирование архитектуры, допроектирование тех вещей, которые не были сделаны на предыдущем инкременте;

– Разработка,

– Тестирование.

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

Спиральная модель – это один из представителей эволюционно-итерактивного подхода. Была предложена Боемом (ученый в области программной инженерии) в 1988 году.

Риск программного проекта – это те причины, из-за которых проект может быть неуспешным. Это могут быть технические риски, проектные риски, экономические риски. Это понятие такой науки как «Управление рисками».

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

Сама по себе спиральная модель не простая в реализации.

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

Поэтому реально в проектах не так часто используют спиральную модель

Методология быстрой разработки приложений (RAD).

Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

• фаза анализа и планирования требований;
• фаза проектирования;
• фаза построения;
• фаза внедрения.

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

определяется необходимость распределения данных;

производится анализ использования данных;

производится физическое проектирование базы данных;

определяются требования к аппаратным ресурсам;

определяются способы увеличения производительности;

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.