Краткий обзор методологии 3 другие модели процессов 4 Лучшее из двух миров 5 Базовые принципы msf 5

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

бет	13/13
Дата	20.07.2016
өлшемі	0.88 Mb.
	#212391
түрі	Краткий обзор

1 ... 5 6 7 8 9 10 11 12 13

Фаза внедрения

Введение

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

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

Веха “Внедрение завершено”

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

Прежде чем считать решение пущенным в эксплуатацию и свернуть проект, проектная группа должна получить от заказчика подтверждение того, что его цели достигнуты. Для этого решение должно быть стабильным и четко удовлетворять выработанным критериям успешности. Стабильность решения означает также готовность систем его эксплуатации и сопровождения.

Результаты

Результаты фазы внедрения включают в себя:

Информационные системы эксплуатации и поддержки.
Процедуры и процессы.
Базы знаний, отчеты, журналы протоколов (logbooks).
Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта.
Отчет о завершении проекта (project close-out report).
Окончательные версии всех проектных документов.
Показатели удовлетворенности заказчика и потребителей.
Описание последующих шагов.

Основные задачи проектной группы на фазе внедрения

Следующая таблица описывает основные задачи и сферы ответственности каждого из ролевых кластеров проектной группы во время фазы внедрения.

Ролевой кластер	Фокус
Управление продуктом	Получение отзывов и оценок заказчика; акт о приеме выполненной работы.
Управление программой	Сопоставление рамок проекта с поставленным решением; управление стабилизацией.
Разработка	Разрешение проблем; поддержка эскалации.
Удовлетворение потребителя	Обучение; управление календарным графиком обучения.
Тестирование	Тестирование производительности.
Управление выпуском	Управление внедрением; одобрение изменений.

Рекомендуемые промежуточные вехи

Ключевые компоненты развернуты

(Core Components Deployed). Большинство инфраструктурных решений включают в себя ряд компонент, образующих основу всего решения. С точки зрения отдельных пользователей, сами эти компоненты не имеют самостоятельной ценности. Однако внедрение полного решения зависит от ключевых компонент. Кроме того:

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

Внедрение на местах завершено

К моменту прохождения этой вехи (Site Deployments Complete) все целевые потребители получают доступ к решению. Лица, ответственные за участки внедрения, подписывают акты о пуске решения в эксплуатацию, хотя определенные проблемы все еще могут возникать.

Отзывы заказчика и потребителей могут выявить некоторые недостатки. Возможно, обучение прошло не вполне удачно, или часть решения начала неверно функционировать после отъезда проектной команды. По результатам проведенных опросов о потребительской удовлетворенности, некоторые из мест внедрения (sites) могут нуждаться в повторном визите проектной группы.

На этом этапе проектная группа концентрируется на завершении мероприятий по внедрению и на сворачивании проекта.

Многие проекты, в особенности веб-разработки, не подразумевают внедрения на местах, поэтому данная веха к ним не применима.

Внедренное решение стабилизировано

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

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

Если заказчик ожидает, что члены проектной команды будут участвовать в поддержке и сопровождении решения, после завершения проекта соответствующие сотрудники должны быть переведены на новые роли в структуре сопровождения.

На этой стадии, по всей вероятности, члены проектной группы и внешние заинтересованные лица начнут выходить из проекта.

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

Временной отрезок между промежуточной вехой “Внедренное решение стабилизировано” (Deployment Stable) и главной вехой “Внедрение завершено” (Deployment Complete) иногда называют “периодом затишья” (“quiet period”). Хотя проектная группа больше активно не работает, она необходима для реагирования на эскалированые к ней проблемы. Обычно период затишья составляет от 15 до 30 дней.

Целью периода затишья является оценка того, насколько хорошо решение работает в нормальных производственных условиях и насколько затратным будет его сопровождение. Организации, использующие MOF, измеряют количество инцидентов, время простоя и определяют эксплуатационные характеристики решения. Эти данные помогают команде сопровождения, обслуживающей соглашения об уровне услуг (Service Level Agreement - SLA), сформировать оценки объема годового уровня услуг. Для получения дальнейшей информации, см. MOF Operations Guide for Service Level Management.

Стимулируйте изобретательность расширяя функциональность и ограничивая ресурсы

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

Фиксируйте календарный график

Внутренние временные ограничения (известные как “временной ящик” - “time-boxing”) мобилизуют проектную группу и заставляют ее приоритезировать функциональность и деятельность.

Календарное планирование на неопределенное будущее

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

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

При выборе временного буфера рекомендуется учитывать следующее:

Не добавляйте буферы в качестве резерва времени для запланированных задач. Так как работа всегда разрастается на все отведенное ей время (закон Паркинсона), такой буфер будет поглощен этими же самыми запланированными задачами, а не использован для реакции на непредвиденные события.
Буферное время должно выделяться как будто бы под дополнительно существующую задачу. Обычно буфера создаются перед главными вехами, особенно позднейшими из них. Временные буфера всегда должны дополнять критический путь проекта (project’s critical path). Критический путь – это наидлиннейшая цепь зависимых проектных задач, непосредственно определяющая сроки проекта.
Использование буферного времени по ходу проекта должно подвергаться жесткому контролю.
Если потребовалось расширить функциональность решения или уменьшилось количество доступных ресурсов, не компенсируйте это использованием буферного времени. Если вы поступите таким образом, вы ослабите свою возможность адекватного реагирования на риски. Согласовывайте баланс возможностей, ресурсов и сроков при помощи треугольника компромиссов, показанного на рис. 5.
Если буферное время исчерпано, поставьте в известность всю проектную группу о том, что любой сбой или задержка будут ударом по работе над проектом и создадут опасность выхода из временных рамок.

Используйте параллельно работающие компактные команды

с частой синхронизацией усилий.

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

Разбивайте большие проекты на осуществимые части

Фундаментальной стратегией Майкрософт является разбиение больших проектов на многие версионированые выпуски без (или с минимально короткой) отдельной фазы сопровождения.

Извлекайте уроки из пройденных вех

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

Непосредственно после этих собраний проектная группа проводит внутренний анализ своей деятельности, чтобы оценить ее качество и эффективность. Этот анализ может рассматриваться как часть деятельности по контролю за качеством (quality assurance), которая в определенных ситуациях может активизировать триггер изменения управления проектом.

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

Используйте прототипирование

Прототипирование дает возможность до того, как осуществлена разработка, проводить тестирование с точки зрения многих аспектов, в особенности – удобства эксплуатации. Это помогает лучше понять взаимодействие пользователя с решением и усовершенствовать спецификации продукта.

Используйте частые билды и быстрые тесты

Регулярное создание билдов решения – наиболее надежный из доступных способов проверки хода разработки проекта и эффективности коллективной деятельности проектной группы. Во время фазы внедрения аналогичной цели служат циклы тестирования пилотной версии.

Частые итерации разработки и внедрения

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

Избегайте расползания рамок проекта

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

Оценка снизу вверх

В IT-проектах предварительные оценки длительности задач, их стоимости и т.п. должны исходить от тех, кто будет затем выполнять оцениваемую работу. Подход “снизу вверх” (bottom up estimating) дает следующие преимущества:

Большая точность. Оценки, сделанные непосредственными исполнителями, являются более точными, поскольку у этих людей есть опыт аналогичной деятельности.

Ответственность. Те, кто использует в работе собственные оценки, чувствуют большую ответственность, как за свою работу, так и за адекватность сделанных оценок.

Уполномоченость (empowerment) проектной группы. Календарный график, составленный самой проектной группой, а не продиктованный свыше руководством, вдохновляет проектную группу, поскольку он составлен на основе тех оценок, которые сами члены проектной группы считают реалистичными.

Интегрирование представленных проектной группой оценок

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

Ролевой кластер “Управление программой” координирует процесс подготовки оценок трудозатрат и проводит их интеграцию в сводный календарный график и бюджет проекта.

Приложение A

Изменения по сравнению с предыдущей версией MSF

Предыдущая версия MSF включала в себя две модели процессов, каждая из которых состояла из четырех фаз и четырех главных вех. Названия и определения фаз и вех различались в зависимости от того, является ли целью проекта разработка приложения (создание) или развертывание инфраструктуры (внедрение). В MSF версии 3.0 эти две дополняющие друг друга модели были объединены в одну общую модель процессов MSF. Слияние двух моделей привело к появлению дополнительной фазы в модели процессов разработки приложений. Эта фаза вбирает в себя деятельность, знаменующую конец разработки и начало внедрения.

Сперва была разработана модель процессов для разработки приложений (Application Development - AD). Ее целью была консолидация всего лучшего из культуры и процессов, использующихся командами продуктов Майкрософт для создания программного обеспечения и его распространения среди заказчиков и партнеров.

Позднее клиенты Майкрософт стали нуждаться в аналогичном руководстве для крупномасштабного внедрения программных продуктов и аппаратного обеспечения на своих предприятиях. Чтобы удовлетворить эту потребность, модель разработки приложений была адаптирована к модели процессов внедрения инфраструктуры (Infrastructure Deployment - ID).

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

Обеспечение взаимодействия моделей AD и ID.
Лучшая поддержка проектных групп, работающих над решениями, специализированными для конкретного предприятия, и разработкой веб-приложений, так как в обоих случаях разработка и внедрение обычно неотделимы друг от друга.
Лучшая поддержка активно развивающих сегодня веб-сервисов и стратегии Майкрософт .NET. Так как веб-сервисы все чаще становятся основными каналами поставки программного обеспечения, разработчики коммерческого программного обеспечения находят необходимым включение процесса установки в жизненный цикл продукта.
Облегчение передачи решения от команды разработки к команде сопровождения, особенно в случае использования MOF.

Заключение

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

Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.

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

Предмет данного руководства может быть защищен патентами, патентными заявками, товарными знаками, авторским правом или иным образом в пользу корпорации Майкрософт. Данный документ не дает разрешения на использование этих патентов, товарных знаков или авторского права, если таковое не оговорено явным образом в каком-либо лицензионном соглашении корпорации Майкрософт.

Microsoft, BizTalk и Project являются либо охраняемыми товарными знаками, либо охраняемым товарными знаками корпорации Майкрософт в США и других странах.

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

Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf .

1 В предыдущей версии MSF процессы разработки (development) и внедрения (deployment) описывались двумя различными, хотя и очень похожими, моделями (прим. редактора перевода).

2 Что бы подчеркнуть это различие, пару терминов “customer/user” в русских версиях документов по MSF мы переводили преимущественно как “заказчик/потребитель”, хотя иногда и как “заказчик/пользователь” (прим. редактора перевода).

3 Следует учесть, что в MSF определения терминов иногда несколько отличаются от определений этих терминов, используемых в рамках некоторых других подходов к управлению проектами. (прим. редактора перевода)

4 Следует учесть, что в MSF определения терминов иногда несколько отличаются от определений этих терминов, используемых в рамках некоторых других подходов к управлению проектами. (прим. редактора перевода)

5 Шаблоны и примеры большинства упоминающихся здесь и далее документов свободно доступны на http://www.microsoft.com/msf в разделе “MSF Resource Library ”. Кроме того, очень хороший комплект примеров документов поставляется Microsoft вместе со студенческими материалами курса 2710 Analyzing Requirements and Defining Microsoft .NET Solution Architectures (прим. редактора перевода).

1 Royce, Winston W., "Managing the Development of Large Software Systems," Proceedings of IEEE Wescon (August 1970): pp 1-9.

2 Barry Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, Vol.21, No. 5 (May 1988): pp 61-72.