Process Model

Организация коллектива разработчиков

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

Ядро: один пишет прототип, потом из него возникает продукт. Проблема: сложен переход.

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

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

"Хирургическая" схема: главный "хирург", зам. гл. "хирурга", подмастерья (документатор, специалист по оптимизации, менеджер). Работает для небольших комплексов, для больших проектов – плохо.

+: нет проблемы согласования, программа получается концептуально целой и грамотной

-: увеличение рисков, все хотят быть главными хирургами, но не подмастерьями.

Microsoft Solution Framework

- Development – наиболее традиционная роль – разработка и начальное тестирование продукта

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

- Product management – управление продуктом. Исполнители этой роли отвечают за общение с заказчиком, написание спецификации, разъяснение задач разработчикам.

- User education – обучение пользователей.Написание пользовательской документации, обучающих курсов, повышение эффективности труда пользователей.

- Logistic management – установка, сопровождение и техническая поддержка продукта, а также материально-техническое снабжение коллектива.

- Testing – тестирование. Выявление и устранение недоработок, исправление ошибок, другие функции QA.

- Envisioning (5%-10%)– выработка единого понимания проекта всеми членами коллектива. Эта фаза заканчивается разработкой формализованного документа:

· problem statement - описание задачи объёмом не более 1 страницы;

· vision statement - от чего хотим уйти, чего хотим добиться;

· solution concept - что хотим внедрить и как;

· user profiles - кто будет этим пользоваться;

· business goals - возврат инвестиций;

· design goals - конкретные цели и ограничения продукта, его конкретные свойства.

// vision approved

- Planning (35%-40%)- планирование очередного цикла разработки:

· функциональные спецификации;

· план-график работ;

· оценка рисков.

//project plan approved

- Developing (30%-35%)- разработка, причём рекомендуются различные технологические приёмы, например, переиспользование кусков кода, программирование по контракту, написание защищённого от ошибок ПО и т.д.

// a-version

- Stabilizing (15%-20%)- - появление стабильной версии, готовой к использованию.

// b- version