4. Стабилизация (фазы mfs)

Фокус смещается в область тестирования, документирования решения и создание пилотного внедрения.

Результаты этой фазы : окончательный продукт (golden release), документация выпуска, материалы поддержки решения, результаты тестирования, проектная документация и анализ пройденной фазы.

5. Внедрение (фазы mfs)

Группа внедряет решение, стабилизирует его, получает одобрение заказчика и передает решение службе сопровождения и поддержки.

Далее, согласно MSF, группа работает над сбором метрик и анализом проекта, чтобы сохранить опыт, накопленный в ходе разработки проекта (на практике - редко).

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

3. RAD. XP

Модель быстрой разработки приложений RAD (Rapid Application Development)

• «Плотная» работа с заказчиком;

• Быстрый переход от требований к разработке ПО;

• Жесткое ограничение по времени (60 дней).

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

Фазы модели RAD:

Модель RAD проходит через следующие фазы:

• этап планирования требований – сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач;

• пользовательское описание – совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей (сбор пользовательской информации); на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные средства, обеспечивающие сбор пользовательской информации;

• фаза конструирования ("до полного завершения") – эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависит от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств;

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

Преимущества модели RAD

При использовании модели RAD относительно проекта, для которого она в достаточной степени приемлема, проявляются следующие преимущества:

• время цикла разработки сокращается благодаря использованию мощных инструментальных средств;

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

• существует возможность произвести быстрый изначальный просмотр продукта;

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

• благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;

• обеспечивается эффективное использование имеющихся в наличии средств и структур;

• постоянное присутствие заказчика сводит до минимума риск неудовлетворения продуктом и гарантирует соответствие системы коммерческим потребностям и надѐжность программного продукта в эксплуатации;

• основное внимание переносится с документации на код, причем при этом справедлив принцип "получаете то, что видите" (What you see is what you get, WYSIWYG);

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

• повторное использование компонент уже существующих программ.

Недостатки модели RAD

Если эта модель применяется для проекта, для которого она не подходит в полной мере, могут сказываться следующие недостатки:

• Непостоянное участие пользователя может негативно сказаться на конечном продукте (т.е. если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конечном продукте);

• при использовании этой модели необходимо достаточное количество высококвалифицированных разработчиков, (умеющих воспользоваться выбранными инструментальными средствами разработки для ускорения времени разработки);

• могут возникать затруднения при использовании модели совместно с наследственными системами и несколькими интерфейсами;

• возникает потребность в системе, которая может быть смоделирована корректным образом;

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

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

• при использовании модели "вслепую" на затраты и дату завершения работы над проектом ограничения не накладываются;

• команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут "затянуть" разработку программного продукта до такой степени, что его поставка конечному пользователю будет под большим вопросом;

• существует риск, что работа над проектом никогда не будет завершена (без менеджера цикл может замкнуться), – в связи с этим менеджер проекта должен сотрудничать как с командой разработчиков, так и с заказчиком, что позволит избежать появления замкнутого цикла;

Область применения модели RAD

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

1. в системах, требования для которых в достаточной мере хорошо известны;

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

3. когда пользователи хотят принимать активное участие в использовании автоматических инструментальных средств;

4. при невысокой степени технических рисков;

5. при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки (как правило, не более, чем за 60 дней);

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

7. когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов;

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

9. когда затраты и соблюдение графика не являются самым важным вопросом (например при разработке внутренних инструментальных средств);

10. в информационных системах;

eXtreme Programming (XP)

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

XP ориентирована на:

• командную работу с тесными связями внутри команды и с заказчиком;

• разработку наиболее простых работающих решений;

• гибкое адаптивное планирование;

• оперативную обратную связь (путем модульного и функционального тестирования).

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

Основными практиками XP являются:

• Планирование процесса (поиск компромисса между пожеланиями заказчика и возможностями разработчика);

• Частые релизы;

• Метафора системы;

• Простая архитектура;

• Тестирование;

• Рефакторинг (переработка) кода;

• Парное программирование (попеременная работа за одним компьютером);

• Коллективное владение кодом;

• Частая интеграция;

• 40-часовая рабочая неделя;

• Стандарты кодирования;

• Тесное взаимодействие с заказчиком.