Управление конфигурациями проекта
Управление конфигурациями проекта (configuration management) – это формализованный процесс мониторинга и контроля за состояниями (версиями) различных элементов, таких как программный код, документация, руководства пользователей, файлы помощи, планы и календарные графики. Процесс управления конфигурациями также включает в себя мониторинг состояния аппаратного обеспечения, сетей и программных настроек (settings) решения. Проектная группа должна иметь возможность в случае необходимости осуществить возврат к более ранней конфигурации решения.
Управление конфигурациями часто путают с управлением изменениями в проекте (project change control), обсуждаемым ниже. В действительности эти две задачи взаимосвязаны, но не идентичны. Управление конфигурациями – это протоколирование и контроль состояний элементов проекта. Управление же изменениями – это процесс рассмотрения и одобрения проектных изменений. Управление конфигурациями обеспечивает проектную группу инструментами, необходимыми для эффективного управления изменениями.
Например, проектная группа работает над электронной системой вызовов медицинской помощи, связывающей сеть больниц. Она сохраняет настройки, выбранные для сервера Microsoft® BizTalk®, и отслеживает изменения, производимые в ходе разработки и тестирования. Это пример управления конфигурацией. Затем, следуя недавно принятому правительственному нормативному акту, вносится предложение дополнить систему новой схемой электронного обмена данными (EDI). Руководители проектной группы встречаются со спонсором и членами команды сопровождения, чтобы проанализировать предложенные изменения, оценить их технологические риски и влияние на стоимость и календарный график проекта. Это пример контроля за изменениями.
|
|
|
В организациях, использующих MOF, для управления конфигурацией проекта может быть задействован широкий спектр процессов управления, применяемых в сопровождении решений.
Рекомендации для выпуска версий решения
Выпуск версий решения помогает укрепить взаимоотношения между проектной командой и заказчиком и обеспечить реализацию в решении всех лучших идей. Заказчику будет легче согласиться с переносом реализации определенных возможностей на более поздние версии, если у него есть доверие к проектной группе, основанное на своевременной поставке начальной и последующих версий решения. Вот общие рекомендации, облегчающие выпуск промежуточных версий решения:
· Создавая планы, предусматривайте версионирование.
· Прежде всего, поставляйте базовую функциональность.
· Выбирайте приоритеты, учитывая риски.[SB1]
|
|
|
· Осуществляйте частые итерации разработки.
· Институциируйте процедуры контроля изменений в проекте
· Не создавайте новых версий, если они не увеличивают ценность решения.
Создавая планы, предусматривайте версионирование
Заблаговременное планирование последующих версий позволяет проектной группе более четко прояснить, что должно быть создано сейчас, и с чем можно повременить. Создание долгосрочного графика введения в решение новой функциональности дает возможность использовать доступные ресурсы и время наилучшим образом и избежать нежелательного расползания рамок проекта.
Прежде всего, поставляйте базовую функциональность
Предоставление заказчику простейшего, компактного, но отвечающего основным нуждам решения имеет большую ценность, чем разработка наиполнейшей версии, которая будет изготавливаться недели, месяцы, годы... Внедрив базовую функциональность, разработчики получают прочный фундамент, на основе которого может быть продолжено развитие решения. Проектная группа также получает отзывы от заказчика, помогающие выбирать наиболее адекватный путь эволюционирования решения.
Выбирайте приоритеты, учитывая риски
Проведение проектной группой оценивания рисков позволяет выявить, реализация какой функциональности сопряжена с наибольшими из них. Подробная информация о рисках может быть получена из “Белой книги” дисциплины управления рисками MSF.
В первую очередь планируйте реализовать наиболее рискованные нововведения и изменения и только после них – менее рискованные. Например, задачи, связанные с большими изменениями в архитектуре, имеет смысл выполнить на ранних этапах проекта, минимизируя тем самым влияние этих изменений на бюджет и календарный график.
Дата добавления: 2019-01-14; просмотров: 748; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!