Краткий обзор методологии 3 другие модели процессов 4 Лучшее из двух миров 5 Базовые принципы msf 5
жүктеу/скачать 0.88 Mb.
|
- Бұл бет үшін навигация:
- Основные задачи проектной группы на фазе планирования
- Рекомендуемые промежуточные вехи
- Базовая версия функциональной спецификации создана
- Базовая версия сводного плана проекта создана
- Базовая версия сводного календарного графика проекта создана
- Среды разработки и тестирования развернуты
РезультатыРезультатами фазы планирования являются:
Основные задачи проектной группы на фазе планированияСледующая таблица описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы планирования.
Рекомендуемые промежуточные вехиВерификация технологийВерификация технологий (technology validation) – это проверка соответствия продуктов и технологий, которые предполагается использовать, спецификациям их поставщиков. Это начальный шаг того процесса, который в последствии должен подтвердить выбранную концепцию и в конце концов трансформироваться непосредственно в разработку решения. Зачастую верификация технологий включает в себя отбор наиболее подходящих из конкурирующих технологий (иногда называемый “shoot out”). Помимо этого на данной вехе фиксируется базовая версия среды заказчика (customer environment). Проектная группа производит аудит (называемый также “исследование” - “discovery”) существующей производственной среды (production environment), в которую будет внедряться решение. Он охватывает конфигурации серверов, сетевое и клиентское программное обеспечение, все затрагиваемое аппаратное обеспечение.
Функциональная спецификация является основой создания сводного плана и сводного календарного графика проекта. Она содержит детальное описание вида и поведения каждой составляющей решения с точки зрения пользователя. Изменения в функциональной спецификации допустимы лишь с одобрения заказчика. Результаты процесса проектирования обычно содержатся в отдельном от функциональной спецификации документе дизайна. Суть документа дизайна - это описание внутреннего механизма решения. Документ дизайна может считаться внутренним документом проектной группы, и изменения в него могут вноситься ею самой, без обременения заказчика деталями технических проблем.
Компоновка различных проектных планов в один сводный документ облегчает совместное планирование работы различных ролевых кластеров и составление единого календарного графика проекта, способствует организации отчетности ролевых кластеров, а также помогает выявить имеющиеся в планах изъяны и несоответствия. Базовая версия сводного календарного графика проекта созданаСводный календарный график проекта включает в себя все детализированные календарные графики вплоть до даты выпуска решения. Сводный календарный график интегрирует в себе календарное планирование деятельности каждого ролевого кластера. Дата выпуска определяется после обсуждения со всеми заинтересованными сторонами базовой версии функциональной спецификации и анализа сводного плана проекта. Зачастую, с целью обеспечения выпуска решения в намеченный срок, проектная группа вносит коррективы в функциональную спецификацию и/или сводный план проекта. Хотя принимаемая функциональность решения, доступные ресурсы и отведенное для проекта время могут варьироваться, всеобщий настрой на фиксированную дату выпуска решения мобилизует проектную группу, что помогает адекватно оценивать риски, расставлять приоритеты в работе и планировать. Среды разработки и тестирования развернутыНезависимая среда разработки (development environment) дает возможность создавать и тестировать решение вне находящихся в эксплуатации производственных систем, что позволяет избежать негативного влияния на эти системы. Правильным подходом является использование для разработки отдельных серверов. При этом проектная группа должна знать, что инсталлированное на этих серверах программное обеспечение может стать нестабильным и потребовать в дальнейшем переустановки. В этой среде производится разработка таких компонент инфраструктуры, как конфигурационные файлы, инсталляционные скрипты, новое аппаратное обеспечение и т.д. Во избежание излишних задержек, среды разработки и тестирования должны развертываться немедленно по окончании составления проектных планов. Это включает в себя установку рабочих станций, серверов и необходимого программного обеспечения. Если к данному моменту еще не готовы системы резервного копирования, они также должны быть развернуты. Помимо этого зачастую создаются CD-образы стандартных серверных конфигураций для быстрого восстановления после переформатирования жестких дисков. Если в организации отсутствует отвечающая требованиям проекта лаборатория тестирования, её необходимо создать. Среда тестирования должна быть максимально приближена к производственной. Этого важно достичь даже тогда, когда подготовка такой среды требует больших затрат. В противном случае ряд специфических ошибок может остаться невыявленым до момента внедрения решения в производственную среду. Организации, применяющие MOF, могут воспользоваться информацией из базы данных управления конфигурациями (Configuration Management Database - CMDB) для воспроизведения в тестовой среде всех характеристик реальной производственной среды. жүктеу/скачать 0.88 Mb. Достарыңызбен бөлісу:
|
