Краткий обзор методологии 3 другие модели процессов 4 Лучшее из двух миров 5 Базовые принципы msf 5
жүктеу/скачать 0.88 Mb.
|
- Бұл бет үшін навигация:
- Ранние базовые версии, отложенные итоговые версии
- Ежедневные билды
- Управление конфигурациями проекта
- Рекомендации для выпуска версий решения
Создание “живой” документацииИтеративный подход к процессу разработки требует использования гибкого способа ведения документации. “Живые” документы (living documents) должны изменяться по мере эволюции проекта. Такой подход существенно отличается от принципов ведения документации в каскадной модели, где процесс разработки начинается лишь после того, как готовы и зафиксированы все требования и спецификации. Документация проектов MSF, также как и программный код, разрабатывается итеративно. Зачастую, планы первоначально имеют форму описания высокоуровневых “подходов” (“approaches”). На фазе выработки концепции они распространяются среди членов проектной группы и других заинтересованных лиц для получения отзывов. После перехода к фазе планирования эти документы постепенно дорабатываются. Разработанные детальные планы снова поступают на проверку всем заинтересованным сторонам, и описанный процесс повторяется итеративно. Типы планов и общее количество описывающих их документов могут варьироваться от проекта к проекту. Для избежания путаницы документы планов, разработка которых начинается на стадии выработки концепции, называются “подходами”. К примеру, подход к тестированию может быть кратко сформулирован во время фазы выработки концепции, а его превращение в план тестирования происходит на более поздних фазах.
Большие, сложные проекты часто разделяются на меньшие подпроекты, каждый из которых разрабатывается и тестируется отдельной командой и затем вливается в общее решение. Для таких проектов, типичных в практике разработки продуктов Майкрософт, ежедневные билды (daily builds) являются фундаментальной, неотъемлемой составляющей рабочего процесса. В первую очередь разрабатывается базовая функциональность решения, и лишь затем создаются дополнительные его возможности. Разработка и тестирование ведутся непрерывно и одновременно, представляя собой параллельные процессы. Ежедневные билды служат верификацией совместимости всего разработанного программного кода и позволяют группам направлений продвигаться в своей работе к следующим итерациям разработки и тестирования. Заметим, что ежедневные билды решения не попадают в реальную производственную среду. Лишь после того, как решение хорошо оттестировано и стабилизировано, осуществляется его пилотный (или бета) выпуск, частично устанавливаемый в производственную среду. Для надлежащей синхронизации билдов необходимо иметь в проекте четко организованный механизм управления конфигурациями. Управление конфигурациями проектаУправление конфигурациями проекта (configuration management) – это формализованный процесс мониторинга и контроля за состояниями (версиями) различных элементов, таких как программный код, документация, руководства пользователей, файлы помощи, планы и календарные графики. Процесс управления конфигурациями также включает в себя мониторинг состояния аппаратного обеспечения, сетей и программных настроек (settings) решения. Проектная группа должна иметь возможность в случае необходимости осуществить возврат к более ранней конфигурации решения. Управление конфигурациями часто путают с управлением изменениями в проекте (project change control), обсуждаемым ниже. В действительности эти две задачи взаимосвязаны, но не идентичны. Управление конфигурациями – это протоколирование и контроль состояний элементов проекта. Управление же изменениями – это процесс рассмотрения и одобрения проектных изменений. Управление конфигурациями обеспечивает проектную группу инструментами, необходимыми для эффективного управления изменениями. Например, проектная группа работает над электронной системой вызовов медицинской помощи, связывающей сеть больниц. Она сохраняет настройки, выбранные для сервера Microsoft® BizTalk®, и отслеживает изменения, производимые в ходе разработки и тестирования. Это пример управления конфигурацией. Затем, следуя недавно принятому правительственному нормативному акту, вносится предложение дополнить систему новой схемой электронного обмена данными (EDI). Руководители проектной группы встречаются со спонсором и членами команды сопровождения, чтобы проанализировать предложенные изменения, оценить их технологические риски и влияние на стоимость и календарный график проекта. Это пример контроля за изменениями. В организациях, использующих MOF, для управления конфигурацией проекта может быть задействован широкий спектр процессов управления, применяемых в сопровождении решений. Рекомендации для выпуска версий решенияВыпуск версий решения помогает укрепить взаимоотношения между проектной командой и заказчиком и обеспечить реализацию в решении всех лучших идей. Заказчику будет легче согласиться с переносом реализации определенных возможностей на более поздние версии, если у него есть доверие к проектной группе, основанное на своевременной поставке начальной и последующих версий решения. Вот общие рекомендации, облегчающие выпуск промежуточных версий решения:
жүктеу/скачать 0.88 Mb. Достарыңызбен бөлісу:
|