Записаться

Рассмотренные в предыдущем разделе методологии ориентированы на внедрение готовых информационных систем, построенных на базе определенных программных продуктов. В отличие от них методология Microsoft Solutions Framework (MSF) носит универсальный характер и может использоваться для внедрения произвольной разрабатываемой в ходе проекта системы.

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

Состав работ проекта - модель процессов MSF

Модель процессов MSF отражает интегрированную (общую) методологию разработки и внедрения ИТ-решений.

Под ИТ-решением в MSF понимается скоординированная поставка набора элементов (таких как программно-технические средства, документация, обучение и сопровождение), необходимых для удовлетворения некоторой бизнес потребности конкретного заказчика. Основными компонентами решения являются:

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

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

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

Эта модель сочетает в себе свойства двух стандартных [ 8 ] производственных моделей: каскадной и спиральной (см. рис. 3.1).

Рис. 3.1. Модель жизненного цикла решения MSF

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

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

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

Фазы проекта определяют последовательно решаемые задачи, а вехи (milestones) - ключевые точки проекта, характеризующие достижение какого-либо существенного результата.

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

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

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

Команда проекта - модель проектной группы MSF

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

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

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

Первое - создание групп направлений. Группы направлений (feature teams) - это компактные мини-команды, отвечающие за определенные компоненты создаваемого решения и образующие матричную организационную структуру (см. рис. 3.2). В них входят по одному или несколько членов из разных ролевых кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от планирования и кончая запуском в эксплуатацию.

Рис. 3.2. Разделение проектной команды на группы направлений [5]

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

Рис. 3.3. Разделение проектной команды на функциональные группы [5]

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

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

Рекомендации MSF по возможностям объединения ролей приведены на рис. 3.4.

Роль менеджера проекта возлагается на кластер "Управление программой". Основные функции этого кластера - управление проектом, выработка архитектуры решения, контроль производственного процесса и организация деятельности административных служб. В небольших проектах все эти функции могут успешно осуществляться одним менеджером программы. Но по мере роста объема и сложности проекта в этом ролевом кластере выделяются две ветви специализации: работа над архитектурой и спецификациями и управление проектом.

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

Рис. 3.4. Возможности объединения ролей в малых проектах [5]

Организация исполнения проекта

Фаза выработки концепции

Цель фазы - создание и сплочение проектной группы на основе выработки единого видения проекта.

Основные выполняемые задачи:

• создание ядра проектной группы;
• подготовка документа общего описания (Видение) и рамок проекта (vision / scope document). Видение (vision) - это ничем не ограничиваемое представление о том, каким должно быть решение. Рамки (scope) - определение того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений.
• определение и оценка главных рисков проекта;
• выявление и первичный анализ бизнес требований (детально эти требования рассматриваются во время фазы планирования).

Распределение задач между ролевыми кластерами приведено в таблице 3.3.

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

• Ядро проектной группы сформировано - назначены ключевые члены проектной группы.
• Черновой вариант концепции проекта составлен - подготовлен вариант документа общего описания и рамок проекта, который с целью согласования распространяется среди членов проектной группы, представителей Заказчика и других заинтересованных сторон.

После согласования концепции проекта достигается главная веха "Концепция утверждена".

Результаты выполнения фазы фиксируются в ряде документов (шаблоны документов можно найти в [ 5 ]):

• общее описание и рамки проекта;
• документ оценки рисков;
• описание структуры проекта.

Фаза планирования

Цель фазы - разработка планов проекта.

Основные выполняемые задачи:

1. Подготовка функциональной спецификации на систему включает в себя анализ и документирование проектных требований (выделяются: бизнес-требования, потребительские требования, эксплуатационные требования и системные требования, относящиеся к решению в целом). Задача предусматривает последовательное выполнение следующих работ:

• выявление типов пользователей системы;
• выявление сценариев использования, в которых моделируется выполнение какой-либо операции определенным типом пользователя;
• выделение последовательностей специфических действий, называемых примерами пользования (use cases), которые необходимо выполнить пользователю для осуществления операции;
• проектирование (дизайн системы). В MSF выделяется три уровня процесса проектирования: концептуальный дизайн (conceptual design), логический дизайн (logical design) и физический дизайн (physical design).

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

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

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

Результаты процесса проектирования документируются в функциональной спецификации.

2. Подготовка рабочих планов.

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

3. Оценка проектных затрат и сроков разработки различных составляющих проекта.

Распределение задач между ролевыми кластерами в фазе планирования приведено в таблице 3.4.

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

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

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

Результаты фазы оформляются в базовой версии проекта путем создания следующих документов:

• функциональная спецификация;
• план управления рисками;
• сводный план и сводный календарный график проекта.

Фаза разработки

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

Распределение задач между ролевыми кластерами в фазе разработки приведено в таблице 3.5.

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

• Концепция подтверждена - успешно проведена проверка ключевых элементов решения в непроизводственной копии существующей среды.
• Билд n завершен, билд n+1 завершен - промежуточные вехи, помогающие определить прогресс создания решения. В сложных системах зачастую выделяются компоненты, каждый из которых разрабатывается и тестируется отдельной командой и затем интегрируется в общее решение. Билды (сборки) и являются процедурами слияния компонент. Эти промежуточные вехи могут быть привязаны к некоторым важным элементам системы (например, завершение графического дизайна, разработки базы данных и пр.).

Главная веха "Разработка завершена" означает, что создание всех составляющих завершено, решение готово к тестированию и стабилизации.

Результаты фазы:

• исходный и исполнимый код приложений;
• скрипты установки и конфигурирования;
• окончательная функциональная спецификация;
• материалы поддержки решения;
• спецификации и сценарии тестов.

Фаза стабилизации

Цель фазы - тестирование и отладка разработанного решения в реалистичной модели производственной среды.

Основные выполняемые задачи:

• выявление, приоритезация и устранение ошибок;
• пилотное внедрение решения.

Распределение задач между ролевыми кластерами в фазе стабилизации приведено в таблице 3.6.

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

• Точка конвергенции - характеризует достижение существенного прогресса в устранении ошибок. В этот момент скорость устранения ошибок начинает превосходить скорость их обнаружения.
• Точка достижения нуля - это момент, когда впервые все выявленные ошибки оказываются устраненными. В дальнейшем ошибки еще будут выявляться, но их количество начинает стремительно убывать.
• Версии-кандидаты - последовательный выпуск и доработка полнофункциональных версий системы. Каждая версия-кандидат имеет полный набор составляющих, необходимых для внедрения решения в производство. В процессе тестирования версии-кандидата производится оценка ее готовности к внедрению. При необходимости проектная группа должна подготовить новую версию, исправляющую недостатки предыдущей.
• Контрольное тестирование завершено. К этому моменту проектная группа должна:
  • оценить результаты тестирования в соответствии с имеющимися критериями успешности;
  • подготовить среду внедрения;
  • создать необходимые для внедрения процедуры, скрипты и массивы данных (load sets);
  • иметь готовые учебные материалы;
  • обеспечить условия для сопровождения решения;
  • создать и протестировать план "отката" для восстановления системы после сбоев.
• Тестирование приемлемости для потребителей завершено - пользователи выполнили тестирование и одобряют работу решения в непроизводственной среде.
• Пилотное внедрение завершено - выполнено тестирование полного решения в среде, максимально приближенной к производственным условиям. В MSF пилотный релиз (pilot release) - это внедрение решения или в часть производственной среды, или для части пользователей, или на подмножестве данных.

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

Результаты:

• окончательный продукт;
• документация выпуска;
• материалы поддержки решения;
• результаты и инструментарий тестирования;
• исходный и исполнимый код приложений;
• проектная документация.

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

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

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

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

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

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

Достижение главной вехи "Внедрение завершено" означает, что решение начинает давать Заказчику ожидаемую бизнес-отдачу, а проектная группа завершила свою деятельность.

Результатами этой фазы являются:

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

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

1. сформировать структуру проекта - выделить фазы (этапы);
2. определить, что и в какой последовательности будет исполняться, т. е. построить иерархическую структуру работ и сетевой график проекта;
3. определить состав проектной команды и распределение ролей и ответственности между участниками;
4. задать контрольные точки проекта и критерии оценки их достижения (получения нужных результатов).

Методика планирования и управления проектом рассматривается в последующих разделах.