Инкрементальная модель

Одним из условий обеспечения высокого качества является активное вовлечение заказчика в процесс разработки, что нашло отражение в методологии прототипного проектирования. Ядром этой методологии является совокупность приемов для быстрой разработки приложений RAD (Rapid Application Development) – RAD – технологии.

Версии программного продукта называют прототипами. Каждый виток спирали соответствует созданию фрагмента или версии ПО.

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

При использовании спиральной модели на первый план выходят вопросы взаимодействия интерфейсов программных модулей между собой и с БД. На втором плане – реализация алгоритмов решения задач.

Основное желание заказчика АИС – получить готовое приложение высокого качества быстро при минимальных затратах на его разработку. Кроме того, вкладывая деньги в создание системы, заказчики желают контролировать процесс создания системы. Критерием качества должно быть наиболее полное удовлетворение требований заказчика на момент введения системы в эксплуатацию

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

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

Для этого может быть несколько причин:

- необходимость предупреждения рисков;

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

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

Минусы использования спиральной модели:

1. Требуется более искусное управление;

2. Необходимость поддержки целостности документации, которая должна быть полностью сформирована к концу каждой версии;

3. Трудность в определении момента перехода на следующий этап;

4. Переход осуществляется в соответствии с планом, даже если не все работы выполнены;

5. Слишком большое количество витков потребует увеличения затрат;

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

Жизненный цикл при использовании RAD – технологии предполагает активное участие на всех этапах разработки конечных пользователей будущей системы и включает 4 основных стадии информационного инжиниринга:

- анализ и планирование информационной стратегии. Пользователи вместе со специалистами – разработчиками участвуют в идентификации проблемной области (детализации функциональности, анализе, определении видов деятельности, активных субъектов, входных/выходных точек, и т.д.);

- проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов – разработчиков;

- реализация. Специалисты – разработчики разрабатывают рабочую версию АИС с использование современных языков программирования;

- внедрение. Специалисты – разработчики обучают пользователей работе в среде новой АИС.

Все приемы для быстрой разработки приложений RAD служат одновременно для обеспечения высокого качества продукта и низкой стоимости разработки. К числу этих приемов относятся:

· разработка приложений итерациями;

· необязательность полного завершения работ на каждом из этапов ЖЦ для начала работ на следующем;

· обязательное вовлечение пользователей в процесс проектирования и построения системы;

· высокая параллельность работ (чем выше параллельность работ, тем меньше длительность проекта);

· повторное использование частей проекта;

· необходимое применение CASE (Computer- Aided (помощник) Software/System Engineering) – средств, обеспечивающих техническую целостность на этапах анализа и проектирования;

· применение средств управления конфигурациями, облегчающее внесение изменений в проект и сопровождение готовой системы;

· использование автоматических генераторов (мастеров);

· использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;

· тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа.

Инкрементальная модель – (инкреция – (in – внутри, (se)cretus – выделенный))

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

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

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

Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т.д.). Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементальная разработка проходит

· лучше всего, если следующая стадия n+1 начинается по возможности после того, как обновление всех модулей на стадии n закончено,

· и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал.

Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

Дата добавления: 2014-01-13