2. Подходы к процессу разработки: виды (каскадный, эволюционный и др.)

Модель процесса создания программного обеспечения— это общее абстрактное представление данного процесса.

ПО представляются как отдельные этапы этого процесса.

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

• Анализ и формирование требований.

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

• Кодирование и тестирование программных модулей.

• Сборка и тестирование системы.

• Эксплуатация и сопровождение.

Результат каждого этапа утверждается документально. Следующий этап не может начаться до завершения предыдущего.

Однако на практике этапы могут перекрываться с постоянным перетеканием информации от одного этапа к другому.

Недостатки: Решение принимаются на ранних этапах что может сказаться на результатах. Модель применяется когда требования формализованы и неизменны.

Плюсы: Полная согласованная документация.

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

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

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

• Прототипирование. Выполняется поэтапное уточнение требований заказчика путём построения экспериментального прототипа для нечётко сформулированных требований.

Достоинства: Постепенная спецификация, в месте с чем заказчик осознаёт решаемые задачи.

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

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

1. Определение требований

2. Формальная спецификация

3. Формальные преобразования

4. Сборка и тестирование системы

Отличие от каскадной модели:

1. Записывается с помощью математической аннотации

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

Минусы данного подхода: существенная зависимость эффективности метода от корректности первого этапа. Большая часть усилий уходит именно на создание спецификаций. Не нашли широкого применения по скольку требуется специальные знания и опыт.

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

• Анализ компонентов. Согласно спецификации требований осуществляете поиск компонентов, которые соответствуют сформулированным требованиям..

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

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

Достоинства: Уменьшается число компонентов для разработки и тестирования.

Недостатки: Необходимость компромиссов при определении требований. При проведении модернизации системы затруднено влияние на новые версии компонентов.