Создавая планы, предусматривайте версионирование

Институциируйте процедуры контроля изменений в проекте

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

• 
  Без анализа и одобрения как со стороны проектной группы, так и со стороны заказчика запланированная функциональность не расширяется и не изменяется.
  
• 
  В целях облегчения проведения анализа запросы на изменение функциональности подаются в письменном виде. Это позволяет группировать подобные запросы. В Майкрософт они называются запросами на изменение дизайна (design change requests – DCRs).
  
• 
  Должны быть проанализированы влияние, осуществимость и приоритет каждого запроса на введение новой функциональности. При этом должны быть учтены взаимосвязи с другими составляющими решения, включая пользовательскую документацию, документацию сопровождения, учебные материалы и производственную среду.
  
• 
  Для каждого запрашиваемого изменения должно быть определено его влияние на бюджет и календарный график проекта (детали см. в разделе “Оценка снизу вверх”).
  
• 
  Должны быть определены члены группы контроля за изменениями (change control board), утверждающей или отвергающей запрошенные изменения. В эту группу должны входить представители заказчика, ролевого кластера “Управление программой” и прочие представители проектной группы и других заинтересованных сторон. Группа контроля за изменениями может формироваться различным образом, но, в любом случае, она должна иметь полномочия вносить изменения в бюджет, календарный график и функциональность решения.
  
• 
  Должен вестись мониторинг изменений, и все его результаты должны быть легко доступы. Например, хорошей практикой является создание в функциональной спецификации и других важных проектных документах секции для протоколирования изменений.
  
• 
  Эффективное управление изменениями возможно только при эффективном управлении конфигурациями.
  

Целостный взгляд на разработку и внедрение

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

Преимущества интегрированной модели процессов

Модель процессов, интегрирующая разработку и внедрение решения, имеет следующие преимущества:

Сосредоточение на нуждах предприятия

Предприятия (и в особенности руководители предприятий) обычно рассматривают разработку и внедрение решения как нечто неразделимое. Даже если разработка решения прошла удачно, заказчики не увидят отдачи до тех пор, пока оно не внедрено на предприятии.

Улучшенная поддержка разработки веб-приложений

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

Улучшенная поддержка веб-сервисов

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

Улучшение взаимодействия с командой сопровождения

Зачастую команда разработчиков создает решение, не уделяя должного внимания вопросам его эксплуатации. Это приводит к низким показателям производительности (performance), доступности (availability) и управляемости (manageability) решения. Интегрированная модель процессов MSF обеспечивает процесс передачи ответственности от команды разработчиков к команде сопровождения сквозь ряд последовательных вех, а не как одномоментный перенос нагрузки.

жүктеу/скачать 0.88 Mb.

Достарыңызбен бөлісу: