Модели разработки программного обеспечения

Тема статьи может показаться вам немного странной (признаться, сначала я и сам думал, что различные модели разбработки ПО никому не нужны). Но на практике оказалось, что следование описанным моделям значительно упрощает работу над приложением.

Модель водопада (waterfall model). Это один из наиболее исторически устоявшихся способов разработки. Впервые модель была описана в 1970 году. Эта модель предполагает последовательное исполнение следующий этапов:

 

Модель водопада


 
  1. Разработка требований (requirements): сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.
     
  2. Анализ и дизайн (analysis and design): разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т.п.
     
  3. Реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.
     
  4. Тестирование (testing): включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации.
     
  5. Развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.


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

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

И поэтому — внимание! — была разработана другая модель, основанная на системе водопада, а именно...

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

 
Итеративная разработка


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

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

RUP. RUP, или Rational Unified Process, был разработан в корпорации IBM, одной из дочерних компаний которой являюется Rational Software. Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.

Можно выделиьт следующие основные характеристики RUP:

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

Итеративность. Как уже было сказано выше, в основе RUP лежит итеративная модель. Создателями рекомендуется перед началом каждой итерации выделить те преценденты, которые должны быть реализованы в данный момент, но не завышать их количество, чтобы итерация не затянулась.

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

Часто считается, что RUP — очень сложный и формальный процесс. Что ж, честно говоря, и я также придерживаюсь такого мнения.

В заключение могу сказать, что это далеко не все модели разработок ПО, и если вы заинтересовались данным вопросом, то советую обратиться к модели экстремального программирования (XP) и Capability Maturity Model Integration (CMMI). Удачи.

Источник: http://mavsic.habrahabr.ru/



Опубликовал admin
11 Окт, Четверг 2007г.



Программирование для чайников.