Методология разработки программных продуктов

Каскадная модель — она же водопадная модель. Схематично эту модель можно представить в виде каскадов. Этапы: определение требований; проектирование системы; кодирование и тестирование программных модулей; сборка и тестирование системы; эксплуатация и сопровождение.

Эту модель называют ещё жизненным циклом программного продукта.

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

Основой недостаток в следующем: если на одном из этапов требования заказчиков меняются, то в соответствии с каскадной модели необходимо вернуться к первому этапу и повторить весь процесс разработки с самого начала. Для того чтобы избежать полного перепроектирования системы применяется следующий приём: начиная с некоторого этапа все предыдущие этапы замораживаются и любые новые требования заказчика реализуются за счёт программистских хитростей (без проектирования). Ещё один недостаток этой модели: негибкое разбиение процесса на отдельные этапы.

Вывод: каскадную модель целесообразно использовать если требования заданы чётко изначально и не меняются.

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

Всё начинается с эскизного описания, потом идут три типа процессов: спецификация требований; разработка; аттестация. Между этапами идёт постоянный обмен информации, то есть процессы параллельны. В результате получается начальная версия, какое-то множество промежуточных версий, ну и некоторая финальная версия.

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

Эта модель предполагает два основных подхода:

Первый подход — это метод пробных разработок, в этом случае происходит постоянное взаимодействие с заказчиком, для того чтобы получить полную и окончательную версию требований программного продукта, на начальных этапах в этом случае разрабатывают те модули и те части системы, требования к которым понятным и не требуют уточнения, в последствии система эволюционирует, до тех пор, пока не будет создана окончательная версия;

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

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

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

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

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

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

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

Преимущества в том, что самого процесса разработки нет, он заменен формальными спецификациями. Основное преимущество следует из этого: однозначное соответствие программного кода требованиям заказчика, следовательно, тестировать эти модули не надо; экономится время, так как не надо программировать.

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

Разработка на основе ранее созданных компонентов — очевидно, что программы каждый раз с нуля не разрабатываются. Часть модулей находится в готовом варианте, либо адаптируются, при этом довольно заметно меняется жизненный цикл программы.

Этапы: спецификация требований; выполняется анализ компонентов; модификация требований; проектирование системы с учётом тех компонентов, которые выбраны; разработка и сборка; аттестация.

Поиск по сайту: