Методология Microsoft Solutions Framework

Методология MSF определяет принципы и способы организации деятельности проектной группы по созданию ИТ-решения, руководство по управлению ИТ-проектами. Она относится к категории итеративных, адаптивных разработок, имеет много общего с методом быстрой разработки программного продукта на основе прототипов — Rapid Application Development (RAD)[1].

Впервые сведения о MSF появились в 1993 г. В 1998 г. вышла версии 2.0, в 2002 г. — версия 3.0 и в 2005 г. — версия 4.0 в двух вариантах: Microsoft Solutions Framework (MSF) for Agile Software Development—управление разработкой гибкого программного обеспечения; Microsoft Solutions Framework (MSF) for CMMI® Process Improvement— улучшенный процесс управления разработкой программного обеспечения на основе модели зрелости.

Методология MSF использует набор моделей и дисциплин: модель процессов (Process Model), модель проектной группы/проектной команды (Model Team), методы управления проектами (Project Management), методы управления рисками (Risk Management), методы подготовки объекта к внедрению (Readiness Management). MSF обеспечивает:

  • ? единое видение ИТ-решения всеми членами проектной группы и заказчиком (Work Toward a Shared Vision);
  • ? партнерство с клиентами (Partner with Customers);
  • ? сохранение гибкости, адаптацию к изменениям при выполнении ИТ-проекта (Stay Agile, Adapt to Change);
  • ? поддержку открытых коммуникаций для членов проектной команды и заказчиков (Foster Open Communication).
  • ? самообучение на основе полученного опыта (Learn From All Experiences);
  • ? усиление позиций членов проектной команды (Empower Team Members);
  • ? определение сферы ответственности исполнителей ИТ-проекта (Establish Clear Accountability);
  • ? инвестирование в качество ИТ-решения (Invest in Quality);
  • ? постоянный рост ценности ИТ-решения (Deliver Incremental Value).

В качестве интегрирующего средства, обеспечивающего поддержку процесса разработки, рассматривается среда Visual Studio 2005 (рис. 18.2), включающая в себя:

  • 1) Visual Studio Team Architects — графические конструкторы для создания архитектуры приложений, корпоративных сетей и Web-служб, развертывания приложений в сетевой инфраструктуре;
  • 2) Visual Studio Team Edition for Software Developers — инструмент анализа качества и производительности исходного кода, предназначенный для создания критически важных приложений и служб в целях тестирования модулей, диагностики проблем безопасности на ранних этапах разработки программных продуктов;
  • 3) Visual Studio Team Edition for Software Testers — инструмент для тестирования приложений и служб до их поставки и установки; [2]
Среда проектирования Visual Studio 2005

Рис. 18.2. Среда проектирования Visual Studio 2005

точки — вехи, используемые для анализа состояния ИТ-проекта. Для каждой фазы ИТ-проекта выделены контрольные точки двух видов: несколько промежуточных вех, которые контролируют изменение состояния ИТ-проекта, и одна главная веха, позволяющая синхронизировать результаты ИТ-проекта с ожиданиями заказчика ИТ-решения. Модель процесса разработки ИТ-решения является сочетанием каскадной (водопадной — Waterfall) и спиральной (Spiral) моделей жизненного цикла производства программных продуктов. Итерационное повторение фаз ИТ-проекта обеспечивает постепенное развитие компонентов и наращение функциональности ИТ-решения. Согласно спиральной модели документирование, разработка и тестирование компонентов ИТ-решения могут перекрываться во времени по отношению к различным их версиям, а небольшие итерации способствуют уменьшению ошибок в проекте.

Промежуточными вехами фазы «Выработка концепции (Envision)» являются: «Ядро проектной группы сформировано», «Черновой вариант концепции составлен»; главная веха — «Концепция утверждена». В результате выработан разделяемый всеми членами команды и заказчиком[3] взгляд на цели и условия реализации ИТ-решения. Ведущий ролевой кластер в проектной команде — «Управление продуктом»; основные документы фазы: «Общее описание ИТ-проекта», «Риски ИТ-проекта», «Структура проекта».

Фаза «Планирование ИТ-проекта (Planning)» связана с разработкой концепции ИТ-решения, оценкой трудозатрат и сроков разработки, созданием планов разработки, тестирования программного кода, подготовки пользователей и др. Бизнес-требования заказчиков подлежат полному удовлетворению с помощью функциональных и эксплуатационных характеристик ИТ-решения. Определяются профили пользователей (User Profiles), разрабатываются сценарии в виде последовательности действий, уточняются режимы эксплуатации ИТ-решения, включая требования к производительности, надежности ИТ-решения, определяется состав ИТ-инфраструктуры. Промежуточными вехами являются: «Верификация технологий завершена», «Базовая версия функциональной спецификации создана», «Базовая версия сводного плана ИТ-проекта создана», «Базовая версия сводного календарного графика ИТ-проекта создана», «Среда разработки и тестирования развернута». Главная веха — «Планы ИТ-проекта утверждены». Фаза завершается созданием базовой версии проекта (Project Baseline), оформлением документов: «Функциональная спецификация ИТ-проекта», «План управления рисками ИТ-проекта», «Сводный план и сводный календарный график ИТ-проекта».

На фазе «Разработка ИТ-проекта (Developing)» выполняется создание компонентов ИТ-решения — программного кода и документации. Промежуточными вехами являются: «Концепция ИТ-решения утверждена», «Промежуточная версия № 1 создана», ..., «Промежуточная версия № N создана». Дополнительно рекомендуется включать следующие вехи: «Завершение графического дизайна», «Разработка базы данных». По завершении фазы должны быть подготовлены исходный и исполнимый код приложений, скрипты для установки и конфигурирования ИТ-решения; сформирована окончательная функциональная спецификация ИТ-решения; подготовлены материалы для поддержки ИТ-решения; разработаны спецификации и сценарии тестов.

Фаза «стабилизация ИТ-проекта (Stabilizing)» обеспечивает тестирование ИТ-решения в среде разработки и опытную эксплуатацию ИТ-решения в среде эксплуатации. Все работы направлены на устранение ошибок в ИТ-решении и подготовку «релиза» для внедрения. Промежуточными вехами являются:

  • ? «Точка конвергенции» — момент времени, когда ошибки в ИТ-решении устраняются быстрее, чем обнаруживаются;
  • ? «Точка достижения “нуля”» — момент времени, когда все первоначально выявленные ошибки в ИТ-решении устранены;
  • ? «Версия-кандидат» — момент времени, когда подготовлен полный набор составляющих ИТ-решения, необходимых для его внедрения;
  • ? «Контрольное тестирование завершено» — момент времени, когда выполнен критерий успешности для тестируемой версии ИТ-решения;
  • ? «Тестирование приемлемости ИТ-решения для пользователя завершено» — момент времени, когда тестируемое ИТ-реше- ние удовлетворит требования пользователей по функциональности, производительности, интерфейсу ИТ-решения;
  • ? «Пилотное внедрение ИТ-решения завершено» — момент времени, когда ИТ-решение внедрено в производственную среду для всех или отдельных пользователей, в полном или ограниченном составе компонентов. В этом случае ИТ-ре- шение должно быть интегрировано с работающими в производственной среде другими бизнес-приложениями, выполнена проверка работоспособности процедур «отката» и восстановления (Rollout and Backout Procedures), программное обеспечение передается группе сопровождения. После этого возможно следующее плотное внедрение либо откат к конфигурации предыдущей версии ИТ-решения.

Главная веха—«Готовность ИТ-решения утверждена», что означает переход к фазе внедрения ИТ-решения в производственную среду.

Результатами фазы стабилизации являются: окончательный вариант ИТ-решения (Golden Release), документация варианта внедрения (Release Notes), материалы поддержки ИТ-решения, результаты и инструментарий тестирования ИТ-решения, исходный и исполнимый код приложений ИТ-решения, проектная документация ИТ-ре- шения, анализ пройденной фазы (Milestone Review) ИТ-проекта.

Фаза «Внедрение (Deploying)» связана с внедрением или стабилизацией работы ИТ-решения. Для внедрения и сопровождения ИТ-решения создается среда эксплуатации в виде ИТ-инфраструк- туры. Промежуточными вехами являются: «Ключевые компоненты ИТ-решения развернуты в производственной среде», «Внедрение ИТ-решения завершено», «Внедренное ИТ-решение стабилизировано». Главная веха — «Внедрение ИТ-решения завершено», т.е. ИТ-решение передано в эксплуатацию. Создаются окончательные версии всех проектных документов, дается оценка удовлетворенности заказчика полученным ИТ-решением.

Процессная модель MSF использует понятие процесса — потока действий, состоящего из элементов (Work Items) различных типов. Для MSF for Agile Software Development Process выделены четыре элемента:

  • 1) сценарий (Scenario) — вариант взаимодействия с ИТ-решением пользователя. Сценарий создается бизнес-аналитиком и передается разработчику. Сценарий получает определенный статус: Completed — завершено создание программного кода ИТ-решения, Split — требуется разбить сценарий на части для дальнейшей разработки, Deferred — отложено создание программного кода в текущей итерации ИТ-решения, Removed — отвергнут сценарий для написания программного кода. Программный код сценариев подвергается тестированию, после чего получает статус: Completed — завершено тестирование программного кода, Split — требуется разбить программный код на части, Deferred — тестирование отложено в текущей итерации, Removed — отвергнутый программный код для тестирования;
  • 2) качество сервисов ИТ-решения (Quality of Service Requirement) — фиксированные ограничения и требования по производительности, времени загрузки, доступности, устойчивости, управляемости и т.п.;
  • 3) работа, задача (Task) — содержание действий, в которых принимают участие роли (исполнители ИТ-решения). Основные типы работ: разработка (применительно к сценарию, требованиям качества сервисов или разработке архитектуры), тестирование, внешние работы. Работа меняет состояние (Completed — завершенная, Deferred — отложенная, Obsolete — не актуальная, Cut — удаленная). Работы можно повторять — свойство Reactivated в связи с изменениями функциональности ИТ-решения;
  • 4) потенциальная проблема (Bug) — требует фиксации и оценки влияния на ИТ-решение. Все выявленные проблемы ИТ-решения документируются с указанием причины: Fixed — изменение исходного кода, As Designed — требует уточнения условий появления, Deferred — не зафиксированная в текущей итерации, Duplicate — дублирующая другую проблему, Obsolete — неактуальная для ИТ-решения, Unable to Reproduce — не воспроизводимая на текущем компьютере. Проблемы со статусом Fixed или As Designed подлежат решению. Возможный статус: Resolution Denied — решение невозможно, Wrong Fix — ошибочная фиксация, Test Failed — проблема не устранена, возврат к началу выявления проблемы.

При идентификации риска (Risk), выявлении его источника, определении ответственного за управление риском вырабатывается стратегия для сглаживания негативных последствий рисков, отслеживается состояние риска: Mitigated (сглаженный по негативным последствиям риск), Inactive (малозначимый риск, который не будет активизироваться), Transferred (выведенный за пределы ИТ-решения), Accepted (принятый как неотвратимый), Avoided (игнорируемый риск в связи с изменениями ИТ-проекта).

Типовая схема потока работ включает в себя:

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

Процессная модель MSF for CMMI Process Improvement использует элементы рабочего потока: Task, Bug, Risk, Issue (инциденты), Requirement (проблемы), Change Request (запрос на изменение), Review (обзор).

Инциденты возникают спонтанно в процессе ежедневной работы, могут перерастать в проблемы, требующие разрешения, вплоть до внесения изменений в ИТ-решение. Статус инцидента: принятый для рассмотрения (Accepted), требующий изучения (Investigate), отклоненный (Rejected).

Запрос на изменение базового плана или программного продукта возникает в системе управления конфигурацией, подвергается анализу и либо принимается (Accepted), либо дополнительно изучается (Investigate), либо отвергается (Rejected).

При внесении изменений в исходный программный код повторяется прохождение фазы тестирования (Code Complete & System Tested). В случае отказа от изменения ввиду нецелесообразности устанавливается статус Abandoned, а при выходе за пределы сферы действия — статус Out of Scope.

Модель проектной группы MSF. Выделяют пять основных принципов организации работы проектной группы MSF:

  • 1) проектная группа — команда «соратников» (Teem of Peers), положение ролей равноправное при обсуждении ИТ-решений;
  • 2) структурирование ролевых кластеров с целью оптимизации управления работами или ресурсами ИТ-проекта;
  • 3) свободное общение членов проектной группы, открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами вне ее;
  • 4) стремление к самосовершенствованию (Willingness to Learn), идея саморазвития посредством накопления опыта и обмена знаниями;
  • 5) создание мотивации к труду, поддержание высокого морального духа в команде.

Обобщенная модель проектной группы MSF рассматривается в виде областей компетенции — ролевых кластеров и ролей:

  • 1. Кластер «Управление продуктом» (Product managements), роль — бизнес-аналитик (Business Analyst).
  • 2. Кластер «Архитектура» (Architecture), роль — архитектор ИТ-решения (Architect).
  • 3. Кластер «Управление программой» (Program Management), роль — «Управляющий проектом» (Project Manager).
  • 4. Кластер «Разработка» (Development), роли — разработчик программного кода, тестов (Developer), администратор базы данных (Database Administrator), разработчик приложений базы данных (Database Developer)».
  • 5. Кластер «Удовлетворение потребителя» (User Experience), роль — менеджер по работе с потребителями ИТ-решения.
  • 6. Кластер «Тестирование» (Test), роль — тестировщик (Tester), проверка сценариев работы пользователей, качества ИТ-сер- висов, устранение ошибок в ИТ-решении.
  • 7. Кластер «Управление выпуском» (Release Operation), роль — менеджер, ответственный за выпуск и развертывание ИТ-решения (Release Manager).

Рекомендации по совмещению нескольких ролей (черный цвет — невозможность, серый цвет — нежелательность совмещения, белый цвет — нормальное совмещение ответственности) представлены в табл. 18.1, а табл. 18.2 содержит функциональные действия для ролевых кластеров на отдельных фазах ИТ-проекта.

Таблица 18.1 Возможность совмещения ролевых кластеров

Таблица 18.2 Связь ролевых кластеров проектной команды и фаз ИТ-проекта

Кластер

Фаза ИТ-проекта

Выработка

концепции

Планирование

ИТ-проекта

Разработка

ИТ-проекта

Стабилизация

ИТ-проекта

Внедрение

Управление продуктом (Product managements)

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

Анализ бизнес-требований, разработка концептуального дизайна ИТ-проекта; разработка коммуникационного плана для взаимодействия членов проектной группы и заказчика

Оценка соответствия ИТ-решения ожиданиям заказчика

Исполнение коммуникационного плана взаимодействия членов проектной группы и заказчика. Планирование подготовки к внедрению ИТ-решения

Получение отзывов и оценок ИТ-решения от заказчика. Подписание акта о приемке-сдаче выполненной работы

Таблица 18.2 Связь ролевых кластеров проектной команды

и фаз ИТ-проекта (продолжение)

Кластер

Фаза ИТ-проекта

Выработка

концепции

Планирование

ИТ-проекта

Разработка

ИТ-проекта

Стабилизация

ИТ-проекта

Внедрение

Архитектура

(Architecture)

Выбор прототипа архитектуры для ИТ-решения, оценка влияния архитектуры на разработку ИТ-проекта

Разработка архитектуры ИТ-решения

Детальная разработка архитектуры ИТ-решения

Доработка архитектуры ИТ-решения

Анализ архитектуры ИТ-решения

Управление программой (Program management)

Определение целей ИТ-проекта. Разработка концепции ИТ-проекта, определение его структуры, ресурсов, временных рамок

Разработка концептуального и логического дизайна, функциональной спецификации ИТ-решения. Составление сводного плана и календарного плана-графика работ по ИТ-проекту. Формирование бюджета ИТ-проекта

Управление реализацией функциональной спецификации ИТ-решения. Внесение корректировок в планы ИТ-проекта

Мониторинг ИТ-проекта. Учет и анализ ошибок, обнаруженных в ИТ-проекте

Завершение ИТ-проекта. Анализ полученных результатов, управление стабилизацией ИТ-решения

Разработка

(Development)

Выбор прототипа для ИТ-решения. Анализ технологических возможностей и осуществимости ИТ-решения

Выбор технологии проектирования ИТ-решения. Логический и физический дизайн ИТ-решения. Разработка календарного плана-графика работ по ИТ-проекту. Составление сметы затрат на ИТ-проект

Разработка программного кода и инфраструктуры для ИТ-решения. Документирование проектных решений

Устранение обнаруженных ошибок в ИТ-реше- нии. Оптимизация программного кода для ИТ-решения

Разрешение обнаруженных в процессе эксплуатации ИТ-решения проблем. Поддержка и совершенствование ИТ-решения

Удовлетворение потребителя (User Experience)

Согласование с заказчиком эксплуатационных характеристик ИТ-решения. Оценка влияния эксплуатационных характеристик ИТ-решения на разработку ИТ-проекта

Создание сценариев (примеров) использования ИТ-реше- ния в соответствии с пользовательскими требованиями. Обеспечение доступности, надежности ИТ-решения. Разработка документации для потребителей ИТ-решения (плана обучения, графика тестирования, графика обучение и др.)

Корректировка плана обучения конечных пользователей ИТ-решения. Оценка удобства эксплуатации и интерфейса пользователя

Доработка руководства по эксплуатации ИТ-решения. Создание учебных материалов ИТ-решения

Обучение конечных пользователей ИТ-решения

Таблица 18.2 Связь ролевых кластеров проектной команды и фаз

ИТ-проекта (продолжение)

Кластер

Фаза ИТ-проекта

Выработка

концепции

Планирование

ИТ-проекта

Разработка

ИТ-проекта

Стабилизация

ИТ-проекта

Внедрение

Тестирование

(Test)

Определение стратегии тестирования ИТ-ре- шения. Выбор критериев приемлемости ИТ-реше- ния. Оценка влияния критериев ИТ-решения на разработку ИТ-проекта

Определение требований к тестированию ИТ-реше- ния. Разработка плана и календарного графика тестирования ИТ-решения

Функциональное тестирование ИТ-решения; выявление проблем; тестирование документации для ИТ-решения; доработка плана тестирования ИТ-решения

Тестирование ИТ-решения; анализ ошибок и их статуса, тестирование конфигурации ИТ-решения

Тестирование производительности ИТ-решения

Управление выпуском (Release operation)

Определение требований к службам внедрения и сопровождения ИТ-ре- шения. Оценка влияния требований к сопровождению ИТ-решения на разработку ИТ-проекта

Оценка соответствия дизайна ИТ-решения требованиям пользователей. Определение эксплуатационных требований к ИТ-решению. Составление календарного плана-графика пилотного и окончательного внедрения ИТ-решения

Разработка плана пилотного развертывания ИТ-решения. Разработка плана подготовки к промышленному внедрению ИТ-решения

Развертывание и поддержка пилотного внедрения ИТ-решения. Планирование внедрения ИТ-реше- ния. Обучение персонала сопровождения ИТ-решения

Управление

внедрением

ИТ-решения.

Анализ

и одобрение

изменений

в ИТ-решении

Управление ИТ-проектом MSF. Для ИТ-проекта должны быть определены миссия (Mission), т.е. назначение ИТ-проекта для решения проблемы повышения эффективности бизнес-системы; видение (Vision) — четкое и однозначное понимание целей и задач ИТ-проекта всеми членами проектной группы и заказчиком; ценность (Business Value) — оценка бизнес-интересов заказчиков (заинтересованных лиц); рамки (Scope) — функциональность ИТ-решения, трудозатраты, сроки и стоимость ИТ-проекта. Управление ИТ-проектом основывается на выделении областей управления проектом, установлении требований к навыкам исполнителей (табл. 18.3).

Ролевой кластер «Управление проектом» осуществляет общее управление ИТ-проектом. Для больших ИТ-проектов ролевой

Таблица 18.3 Состав областей управления проектами

Область управления проектами

Описание

Планирование, мониторинг контроль за изменениями ИТ-проекта (Project planning /Tracking / Change Control)

Интеграция и синхронизация планов ИТ-проек- та; организация процедур и системы управления проектом, мониторинг изменений ИТ-проекта

Управление рамками ИТ-проекта (Scope Management)

Определение и распределение объемов работ ИТ-проекта (рамки проекта); управление компромиссами при принятии решений относительно ИТ-проекта (время разработки, объем трудозатрат, стоимость и качество ИТ-решения)

Управление календарным графиком ИТ-проекта

(Schedule Management)

Составление календарного графика работ ИТ-проекта, исходя из оценок трудозатрат, связей работ, доступности и стоимости ресурсов; применение статистических методов оценки трудозатрат и длительности выполнения работ. Поддержка выполнения календарного плана-графика (перераспределение ресурсов, назначенных на работы проекта, задержка работ, изменение приоритетов работ и др.)

Управление стоимостью (Cost Management) ИТ-проекта

Анализ стоимости ИТ-проекта на уровне отдельных работ, ресурсов и проекта в целом; мониторинг затрат; составление отчетности о затратах на реализацию ИТ-проекта. Выявление и анализ затратных рисков; функционально-стоимостной анализ (value analysis) работ ИТ-проекта

Управление персоналом (Staff Resource Management)

Планирование человеческих ресурсов; формирование проектной команды; определение зон ответственности и полномочий исполнителей, разрешение конфликтов; планирование повышения квалификации персонала

Управление коммуникацией (Communications Management)

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

Управление рисками (Risk Management)

Организация процесса управления рисками в команде и содействие ему; обеспечение документооборота управления рисками

Управление снабжением (Procurement)

Анализ цен поставщиков услуг и (или) аппаратного (программного) обеспечения; подготовка документов об инициировании предложений (Requests for Proposals — RFPs), выбор поставщиков и субподрядчиков; составление контрактов и переговоры об их условиях; договоры; заказы на поставку и платежные требования

Управление качеством (Quality Management)

Планирование качества, определение применяемых стандартов, документирование критериев качества и процессов его измерения

кластер «Управление проектом» разбивается на функциональные группы, состоящие из специалистов по управлению проектами и архитектуре решения. Модель управления ИТ-проектами содержит шаги, выделяемые согласно фазам процесса разработки. Так, фаза выработки концепции (Envisioning Phase) обеспечивает формирование общего видения ИТ-решения, начальной версии и «рамок» ИТ-проекта — сроков, стоимости, трудоемкости. Документ «Общее описание и рамки проекта» (Vision/Scope Document) подлежит одобрению для продолжения ИТ-проекта. Фаза планирования (Planning Phase) требует структуризации работ (Work Breakdown Structure — WBS), т.е. выделения комплексов взаимосвязанных работ для оценки их трудоемкости, учета затрат. Первый уровень структуры WBS соответствует фазам жизненного цикла проекта, а промежуточные вехи фаз проекта составляют второй уровень структуры WBS. Третий и последующие уровни соответствуют процессу декомпозиции работ/задач (Work/Task Decomposition).

Рассмотрим общие рекомендации для декомпозиции работ ИТ-проекта

Количество уровней иерархии работ ИТ-проекта (WBS) — от трех до пяти. Работы ИТ-проекта декомпозируются в целях улучшения планирования и учета их выполнения. Для каждой работы ИТ-проекта должны быть обеспечены однозначное описание содержания действий и ожидаемого результата, точно измерены длительность, трудозатраты и стоимость. Длительность работ должна находиться в диапазоне от 1 до 40 дней. Необходимо гарантировать непрерывность выполнения работ ИТ-проекта (без существенных пауз и перерывов). Ответственность за каждую задачу должна быть поручена одному работнику. Работы, сопряженные с большими рисками, должны детализироваться больше, чем работы, сопряженные с меньшими рисками.

Как правило, количественные оценки ИТ-проекта — длительность, стоимость, трудоемкость работ осуществляются методом «снизу вверх» (Bottom-Up Estimating). Оценки подлежат уточнению при достижении промежуточных и окончательной вех фаз проекта. Расхождение плановых и фактических значений показателей ИТ-проекта (стоимости и длительность) различно для фаз ИТ-проекта (рис. 18.3) к

1 Адаптировано для MSF из «Cost Models for Future Lifecycle Processes: COCO- MO 2.0» Boehm, et. al., 1995. Взято из Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996), p. 168.

Конус неопределенности

Рис. 18.3. Конус неопределенности

В ИТ-проекте график работ учитывает риски (Risk-Driven Scheduling): работы по обеспечению функциональности ИТ-решения, имеющие наибольшие риски, планируются по типу As Soon As Possible (как можно раньше). Предусматривается резерв времени для работ проекта, длительности которых заранее неизвестны. Все это приводит к росту критического пути ИТ-проекта (Critical Path).

Для ИТ-проекта используется методика оценки и пересмотра планов работ PERT (Program Evaluation and Review Technique), вычисляются оптимистическая, пессимистическая и наиболее правдоподобная длительность выполнения работ. Ресурсы ИТ-проекта требуют анализа и балансировки загрузки. При расширении функциональности ИТ-решения, сокращении объемов ресурсов ИТ-про- ект пересматривается.

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

  • 1. Начало проекта.
  • 1.1. Формирование рабочей группы.
  • 1.1.1. Определение ролей в группе.
  • 1.1.2. Определение необходимых умений и навыков.
  • 1.1.3. Определение ресурсов.
  • 1.1.4. Назначение ролей ресурсам.
  • 1.1.5. Формирование группы завершено.
  • 2. Формирование представления.
  • 2.1. Определение предварительных бизнес-требований.
  • 2.2. Управление рисками.
  • 2.3. Определение структуры проекта.
  • 2.3.1. Определение процесса отслеживания хода выполнения проекта.
  • 2.3.2. Определение процесса разрешения проблем.
  • 2.3.3. Определение процесса отслеживания вопросов.
  • 2.3.4. Определение процедуры управления изменениями.
  • 2.3.5. Определение ожиданий и системы учета.
  • 2.3.6. Структура проекта определена.
  • 2.4. Исследование и сбор исходных положений
  • 2.4.1. Проведение предварительных опросов пользователей.
  • 2.4.2. Определение сценариев использования.
  • 2.4.3. Разработка прообраза профиля пользователя.
  • 1 Шаблон программы Microsoft Project «Разработка приложения на основе MSF».
  • 2.4.4. Выработка предварительного представления.
  • 2.4.5. Выработка целей проектирования.
  • 2.4.6. Выработка предварительной концепции решения.
  • 2.5. Выработка предварительной области охвата проекта.
  • 2.5.1. Определение важных составляющих успеха.
  • 2.5.2. Определение метрики успеха.
  • 2.5.3. Определение (предварительное) основных конечных результатов проекта.
  • 2.5.4. Создание черновой версии представления и области охвата.
  • 2.5.5. Пересмотр представления и области охвата.
  • 2.5.6. Обновление представления и области охвата.
  • 2.5.7. Резерв.
  • 2.5.8. Пересмотр вех.
  • 2.6. Представление утверждено.
  • 3. Планирование.
  • 3.1. Обновление оценки рисков.
  • 3.2. Сбор отзывов пользователей.
  • 3.3. Создание функциональной спецификации.
  • 3.3.1. Разработка функциональной спецификации — версия 0.
  • 3.3.2. Разработка функциональной спецификации — версия 1.
  • 3.3.3. Разработка функциональной спецификации — версия 2.
  • 3.3.4. Разработка функциональной спецификации — версия п.
  • 3.3.5. Исходный план функциональной спецификации.
  • 3.4. План разработки.
  • 3.4.1. Создание плана разработки.
  • 3.4.1.1. Концептуальный дизайн.
  • 3.4.1.2. Логический дизайн.
  • 3.4.1.3. Физический дизайн.
  • 3.4.2. Создание календарного плана разработки.
  • 3.5. План тестирования.
  • 3.5.1. Разработка календарного плана тестирования.
  • 3.5.2. Разработка плана тестирования.
  • 3.6. План обучения пользователей.
  • 3.6.1. Разработка плана обучения пользователей.
  • 3.6.2. Разработка календарного плана обучения пользователей
  • 3.7. План материально-технического обеспечения.
  • 3.7.1. Разработка плана материально-технического обеспечения.
  • 3.7.1.1. Анализ инфраструктуры.
  • 3.7.1.2. Разработка плана безопасности.
  • 3.7.1.3. Разработка плана развертывания.
  • 3.7.1.4. Заказ компонентов.
  • 3.7.1.5. План материально-технического обеспечения завершен.
  • 3.7.2. Создание календарного плана материально-технического обеспечения.
  • 3.8. План руководства продуктом.
  • 3.8.1. Разработка плана руководства продуктом.
  • 3.8.2. Разработка календарного плана руководства продуктом.
  • 3.9. План руководства программой.
  • 3.9.1. Создание плана руководства программой.
  • 3.9.2. Создание календарного плана руководства программой.
  • 3.10. Исходный план проекта создан.
  • 3.11. Объединение планов проекта.
  • 3.11.1. Изучение объединенного плана.
  • 3.11.2. Создание объединенного календарного плана.
  • 3.11.3. Резерв.
  • 3.11.4. Определение даты поставки.
  • 3.11.5. Представление и область охвата зафиксированы.
  • 3.11.6. Пересмотр вех.
  • 3.12. План проекта утвержден.
  • 4. Разработка.
  • 4.1. Обновление оценки рисков.
  • 4.2. Получение оборудования для разработки (проверки) концепции.
  • 4.3. Создание лаборатории или среды разработки.
  • 4.4. Внутренний выпуск № 1.
  • 4.4.1. Разработка конечных компонентов.
  • 4.4.2. Тестирование отдельных компонентов.
  • 4.4.3. Тестирование приложения в целом.
  • 4.4.4. Разработка материалов по повышению производительности.
  • 4.4.5. Тестирование и корректировка материалов.
  • 4.4.6. Разработка процедур распространения.
  • 4.4.7. Создание версии продукта для распространения.
  • 4.4.8. Распространение соответствующим получателям.
  • 4.4.9. Резерв.
  • 4.5. Внутренний выпуск № 1 завершен.
  • 4.6. Ознакомление с результатами внутреннего выпуска.
  • 4.7. Корректировка на основе результатов выпуска.
  • 4.8. Внутренний выпуск № п.
  • 4.8.1. Разработка конечных компонентов.
  • 4.8.2. Тестирование отдельных компонентов.
  • 4.8.3. Тестирование приложения в целом.
  • 4.8.4. Разработка материалов по повышению производительности.
  • 4.8.5. Тестирование и корректировка материалов.
  • 4.8.6. Разработка процедур распространения.
  • 4.8.7. Создание версии продукта для распространения.
  • 4.8.8. Резерв.
  • 4.8.9. Распространение соответствующим получателям.
  • 4.9. Внутренний выпуск № п завершен.
  • 4.10. Ознакомление с результатами внутреннего выпуска.
  • 4.11. Замораживание функциональной спецификации.
  • 4.12. Завершение разработки компонента.
  • 4.13. Завершение материально-технического обеспечения.
  • 4.14. Завершение разработки поддержки.
  • 4.15. Компонент завершен.
  • 4.16. Обновление планов и расписаний.
  • 4.16.1. Обновление плана разработки.
  • 4.16.2. Обновление плана тестирования.
  • 4.16.3. Обновление плана материально-технического обеспечения.
  • 4.16.4. Обновление плана руководства программой.
  • 4.16.5. Обновление плана руководства продуктом.
  • 4.16.6. Обновление плана обучения пользователей.
  • 4.17. Резерв.
  • 4.18. Пересмотр вех.
  • 4.19. Область охвата завершена.
  • 5. Стабилизация.
  • 5.1. Обновление оценки рисков.
  • 5.2. Бета-выпуск № 1.
  • 5.2.1. Разработка плана Р-цикла.
  • 5.2.2. Отбор пользователей.
  • 5.2.3. Подготовка Р-пакета.
  • 5.2.4. Начало Р-цикла.
  • 5.2.5. Предоставление Р-поддержки.
  • 5.2.6. Сбор отзывов пользователей.
  • 5.2.7. Прекращение предоставления р-поддержки.
  • 5.2.8. Исправление ошибок.
  • 5.2.9. Окончание Р-цикла.
  • 5.3. Бета-выпуск № п.
  • 5.4. Исправление ошибок.
  • 5.5. Установление тенденции к уменьшению числа ошибок.
  • 5.6. Исправление ошибок с высоким приоритетом.
  • 5.7. Выпуск с нулевым количеством ошибок.
  • 5.8. Заключительное рассмотрение ошибок.
  • 5.9. Кандидат на выпуск № 1.
  • 5.9.1. Исследование группой разработки.
  • 5.9.2. Исследование пользователями.
  • 5.9.3. Исследование службой поддержки.
  • 5.10. Кандидат на выпуск № п.
  • 5.11. Окончательный (золотой) выпуск.
  • 5.12. Выпуск.
  • 6. Анализ хода выполнения и результатов проекта.

Управление рисками ИТ-проекта. В силу неопределенности условий выполнения отдельных работ и влияния многих случайных факторов ИТ-проект подвержен рискам, которые оцениваются с помощью следующих показателей[4]: вероятность рискового случая, сумма ущерба (тяжести).

В управлении ИТ-проектом методологии MSF используется модель управления рисками (Risk Model), обеспечивающая идентификацию, анализ и оценку вероятности наступления рисков ИТ-проекта, оценку последствий, выявление причин, проведение профилактических мероприятий. Управление рисками представляет собой выработку контрмер для устранения негативных последствий рисков. Риски имеют отношение к будущим результатам ИТ-проекта, а негативные их последствия могут стать проблемами, требующими разрешения. Превентивное управление рисками ИТ-проекта осуществляется на всех фазах жизненного цикла ИТ-решения, обеспечивает открытость в обсуждении рисков ИТ-проекта как внутри проектной группы, так и с заинтересованными лицами (Stakeholders), непрерывное самосовершенствование и извлечение уроков из накопленного опыта создания и управления ИТ-проектами, правильное распределение ответственности членов проектной группы ИТ-проекта, внедрение фиксированных форм отчетности для рисковых ситуаций. Планы ИТ-проекта интегрируют действия по управлению рисками на протяжении всего жизненного цикла ИТ-проекта.

Типовая модель управления рисками MSF включает в себя шесть этапов:

  • 1. Выявление рисков (Risk Identification). Важно своевременно выявить риски ИТ-проекта, желательно на начальных фазах жизненного цикла, установить источники (люди, процессы, технологии и внешние условия выполнения проекта), условия возникновения рисков. Большое значение имеют опыт членов проектной группы, классификация рисков, корпоративные правила и инструкции противодействия рискам, база знаний о рисках ИТ-проектов.
  • 2. Анализ рисков (Risk Analysis). Риски получают приоритеты (Risk Prioritization), подразделяются на главные и малозначимые. Каждому главному риску дается количественная оценка: вероятность наступления риска (Probability), величина ущерба (Impact) или дополнительной выгоды (Profit), ожидаемая величина риска (Exposure).
  • 3. Планирование рисков (Risk Planning). Детальный план управления главными рисками ИТ-проекта содержит следующие стратегии:
    • ? исследование (Research) риска — информации о риске и его последствиях явно недостаточно для принятия решения, требуется продолжить исследование;
    • ? принятие (Accept) — ожидаемая величина риска рассматривается как неизбежные потери;
    • ? избежание (Avoid) — выполнение действий, которые позволят избежать появления риска;
    • ? перенос (Transfer) риска на другой проект, проектную группу, организацию или частное лицо;
    • ? предотвращение (Mitigation) риска за счет мероприятий по устранению условий возникновения риска;
    • ? смягчение последствий (Contingency) — разрабатываются мероприятия, которые уменьшат негативные последствия рисков.

Подробный план действий относительно рисков ИТ-проекта —

Risk Scheduling — обеспечивает реализацию выработанных стратегий для обеспечения непрерывности управления рисками.

  • 4. Мониторинг рисков (Risk Tracking). Осуществляется наблюдение за выполнением планов по предотвращению рисков ИТ-проекта, информирование проектной группы о планах реагирования в случае возникновения рисков, контроль их выполнения.
  • 5. Контроль рисков (Risk Control). Вследствие наступления рисков вносятся изменения в ИТ-проект (Project Change Control Requests).
  • 6. Извлечение уроков (Risk Learning). Усвоение накопленного опыта, формирование базы знаний о рисках, достижение зрелости в управлении знаниями о рисках.

Схематично процесс управления рисками для MSF выглядит так, как показано на рис. 18.4.

Как правило, наиболее рисковыми являются ИТ-проекты, являющиеся значимыми для бизнеса (Business Value), которые выполняются в жестких временных рамках, а также ИТ-проекты, использующие дефицитные или дорогостоящие ресурсы, ориентированные на новые ИТ, «виртуальные» проектные группы (члены группы находятся на значительном расстоянии друг от друга) и проектные команды, образованные из специалистов разных компаний, организаций или субподрядчиков и т.п. Страхование рисков является достаточно распространенным методом управления рисками

Процесс управления рисками в MSF

Рис. 18.4. Процесс управления рисками в MSF

ИТ-проекта* 1: хотя само страхование не снижает вероятность рисков, оно уменьшает финансовые потери страхователя при наступлении рискового случая. Страхование ИТ-проекта может осуществляться в размерах расходов, необходимых для восстановления состояния ИТ-решения и возобновления ИТ-проекта, покрытия убытков («упущенной выгоды») в бизнес-сфере вследствие несвоевременного получения ИТ-решения.

Управление подготовкой MSF. Управление подготовкой состоит в управлении знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения ИТ-решений (рис. 18.5). Оно предполагает:

  • ? свободное общение сотрудников для коллективного обмена опытом, стимулы совершенствования профессионального уровня каждого сотрудника;
  • ? высокий уровень профессионализма как основу высокого уровня качества работы сотрудников и успеха предприятия в целом;
  • ? извлечение уроков и накопление опыта во всех аспектах производственной деятельности;
  • ? готовность к изменениям, гибкость (Readiness Agility), дополнительную мотивацию для динамичного усвоения знаний и умений.
Управление подготовкой MSF

Рис. 18.5. Управление подготовкой MSF

В определении страхового риска отсутствует понятие вреда, содержатся только признаки вероятности и случайности наступления рискового случая.

Для реализации этих установок необходим переход к системе управления знаниями (табл. 18.4), а именно планирование подготовки специалистов проектной группы; оценка и мониторинг профессионального уровня и индивидуальных целей сотрудников; идентификация рисков, связанных с недостаточным профессиональным уровнем сотрудников; разработка проекта для подготовки сотрудников. Методологии MSF и MOF рассматривают знания, умения и способности сотрудников как своеобразный ресурс предприятия, который используется для выполнения ИТ-проектов[5]. Навыки, приобретенные в ходе реализации одного проекта, могут лечь в основу разработки последующих проектов, поэтому важно упорядочивание ИТ-проектов для своевременного достижения профессионального уровня сотрудников. Управление подготовкой сотрудников интегрировано в модели процессов и проектной группы MSF.

Подготовка сотрудников проектной группы должна соответствовать содержанию ИТ-проектов. Перспективные ИТ-проекты (High Potential) связаны с разработкой качественно нового продукта, технологии или услуги, носят исследовательский характер работы. Здесь необходим

Таблица 18.4 Требования к представителям проектной команды

Ролевой

кластер

Функция

Описание

Управление

продуктом

Лидер

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

Член

группы

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

Таблица 18.4 Требования к представителям проектной команды (продолжение)

Ролевой

кластер

Функция

Описание

Управление

программой

Лидер

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

Член группы

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

Разработка

Лидер

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

Член группы

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

Тестирование

Лидер

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

Член группы

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

Управление

выпуском

Лидер

Значительный опыт в управлении выпуском. Способность быть лидером и управлять командой. Технические знания в области компонент аппаратного и программного обеспечения. Способность проводить внедрение решений. Способность представлять интересы команды сопровождения

Член группы

Опыт в управлении выпуском

Удовлетворение

потребителя

Лидер

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

Член группы

Значительный опыт в написании технических текстов

высокий уровень профессионализма и гибкость навыков сотрудников. Для стратегических проектов (Strategic) по использованию новых технологий, продуктов или услуг, способных произвести стратегические изменения в бизнес-процессах предприятия, нужен постоянный состав высококвалифицированных сотрудников проектной группы, способных разбираться в особенностях бизнес-требований. Критичные эксплуатационные сценарии (Key operational), связанные с эксплуатацией новых продуктов, технологий или сервисов совместно с системами и программным обеспечением предыдущих поколений (Legacy Systems), требуют опытного персонала с навыками эксплуатации используемых технологий. В случае сценариев сопровождения (Support), связанных с расширением возможностей существующего продукта с целью удовлетворения требований заказчиков (Customer’s Environment), необходимы более «дешевые» специалисты для работы с устаревшими технологиями, возможен и аутсорсинг.

  • [1] Метод RAD предложен в 1980 г. Дж. Мартином, основан на использовании иадаптации прототипа программного продукта.
  • [2] Visual Studio Team Foundation Server — поддержка коллективной работы (обмена информацией, управления версиями программного кода и проектными ресурсами в масштабе компа-нии/организации, генерации отчетов о ходе проекта). Модель процессов MSF. Процесс создания ИТ-решения разбитна пять фаз, внутри которых определены работы и контрольные
  • [3] Различают термины: «заинтересованные стороны» (Stakeholders) — лица илигруппы лиц, непосредственно заинтересованные в результатах ИТ-проекта (синоним — заказчик, Customer); «пользователь» (User) —лицо, использующее ИТ-ре-шение в ходе своей профессиональной деятельности.
  • [4] Наибольшую популярность для анализа и управления рисками получил метод CRAMM: С (Central Computer and Telecommunications Agency) + RAM (Risk Analysis and Management), предложенный Агентством по компьютерным технологиями телекоммуникациям (Central Computer and Telecommunications Agency— CTTA)Великобритании. В основу метода CRAMM положен комплексный подход к оценкерисков с использованием количественных и качественных оценок.
  • [5] Знания — информация, которой должен обладать индивидуум для квалифицированного выполнения работы. Умения — набор освоенных действий и приемов,определяющих квалифицированность. Производительность труда — мера ожидаемой отдачи от применения профессиональных знаний и умений индивидуумав рамках его рабочей роли. Профессиональные навыки — мера способностей к выполнению определенной работы или удовлетворению квалификационным требованиям рассматриваемого сценария. Профессиональные навыки соответствуют задачам, которые индивидуум способен выполнить на определенном уровне.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >