Применение MSF для разработки инфокоммуникационных систем

Компания Microsoft предлагает свою методологию разработки программного обеспечения – Microsoft Solutions Framework (MSF), которая опирается на практический опыт корпорации и описывает управление людьми и рабочими процессами в процессе разработки решения.

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

MSF состоит из двух моделей и трех дисциплин.

MSF содержит:

· модели:

o модель проектной группы

o модель процессов

· дисциплины:

o дисциплина управление проектами

o дисциплина управление рисками

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

В рамках темы лекции основное внимание будет уделено модели процессов MSF (MSF process model) представляющую общую методологию разработки и внедрения IT‑решений при проектировании инфокоммуникационных систем.

Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral) и покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением.

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

Процесс MSF ориентирован на “вехи” (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы, например: “Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?”, “В достаточной ли степени готов план действий?”, “Соответствует ли продукт утвержденной спецификации?”, “Удовлетворяет ли решение нужды заказчика?” и т.д.

Тремя особенностями модели процессов MSF являются:

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

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

· Интегрированный подход к созданию и внедрению решений.

MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности.

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

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

Для описания модели процессов MSF используется понятие рамок проекта и решения.

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

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

Четкое очерчивание рамок предоставляет возможность:

· Разбиения долговременных планов на достижимые составляющие.

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

· Гибкости в планировании и реализации решения.

· Создания базиса для выработки компромиссов.

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

Термин “рамки” имеет два аспекта: рамки решения и рамки проекта. Несмотря на то, что между ними имеется тесная взаимосвязь, они не тождественны друг другу. Понимание различий между ними помогает эффективному управлению календарным графиком и стоимостью проекта.

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

Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения. Некоторые организации называют рамки проекта “описанием работы” (statement of work - SOW).

Формулирование рамок проекта позволяет проектной группе:

· Сфокусироваться на той работе, которую необходимо выполнить.

· Облегчить разбиение объемных и нечетких задач на меньшие, легко понимаемые.

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

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

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

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