Модели Microsoft Solution Framework

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

• Team model
• Process model
• Application model
• Solution Design model
• Innfrastructure model

• TCO (Total Cost of Ownership) model

• Предлагаемые комбинации моделей для различных типов проектов

Team model

Определяет следующий роли участников группы разработчиков:

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

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

• Роль Development не должна совмещаться с какой-либо другой
• Совмещаемые роли не должны конфликтовать друг с другом. (Logistics и Product Manager)

Зависимость ролей от внешних факторов

Business case

Business case - это план действий, который представляется главному менеджеру менеджером продукта. Состоит из следующих частей:

• анализ того, что клиенту нужно
• рекомендуемое решение
• альтернативное решение
• количественная и качественная оценка рекомендуемого решения

Должен меняется в ходе разработки проекта и всегда отражать реальное состояние проекта.

Process model

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

• Envisioning phase

  Определяются требования к проекту. Направление усилий команды в нужное русло.
  Результатом этапа является Vision/Scope Approved milestone. Visions устанавливают основные требования и цели продукта, а Scope - основные ограничения. В результате получается что-то типа: неплохо было бы включить в проект 20 функциональных возможностей, время позволяет включить только 15, а 5 добавить потом в следующей версии.
  
  

• Planning phase

  На этом этапе клиент и команда разработчиков силят и конкретно решают что и как должно быть построено в продукте. Решаются такие вопросы как язык написания проекта и расстановка приоритетов. В результате получается Project Plan Approved milestone в котором приведены функциональная спецификация и расписание.
  
  

• Developing phase

  На этом этапе начинается программирование. Этап может быть разбит на несколько частей. Результат - Scope complete/First Use milestone. В документации содержатся информация о характеристиках не включенных в текущую версию и когда они появятся в следующих версиях.
  
  

• Stabilizing phase

  На этом этапе происходит тестирование и устранене ошибок в проекте. Конечной точкой является Release milestone.
   

Достижение компромисов с клиентом. Установка приоритетов.

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

Например. Если клиент хочет добавить несколько новых характиристик в проект, то соответственно должны быть пересмотрены сроки и ресурсы.

Для установки приоритетов обычно составляется матрица компромисов, которая выглядит следующим образом

В каждой строке должен обязательно стоять один крестик. Важно, чтобы колонка Accept была помечена хотя бы в одной строке.

Application model

Предназначена для конструирования архитектуры приложения. Описывает компоненты (COM) из которых будет состоять приложение и способы их взаимодействия. Приложение разбивается на множество потребителей (consumer) и поставщиков (supplier). Потребитель использует службы (services) предлагаемые поставщиком. Служба - это часть логики приложения выполняющая операцию, функцию или еще какое преобразование объектов. 

Каждое приложение представляется совокупностью трех уровное служб:

• User Service

  • user interface
    • GUI
    • Programmatic

• Business Services (middle-tier services)

  • transaction integrity
  • business logic
  • control sequencing

• Data Services

  • Create, Read, Update, and Delete services
  • Retrieval logic

Modular design

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

• уменьшается времы разработки проекта
• укрепляется мораль разработчиков, так как они видят реальные прогресс разработки
  
  
  

Solution design model

"Дайте людям то что они хотят" - девиз этой модели. Модель помогает команде разработчиков предвидеть потребности пользователя путем включения его в разработку модели.  Включает в себя 3 проекции (perspective).

• Conceptual design

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

• Logical design

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

• Physical design

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

Enterprise Architecture model

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

• Business architecture

  • как реализуются бизнес-процессы в компании
    
    

• Application architecture

  • какие модели приложений используются
  • как модель приложения нового проекта вписывается в существующую структуру
    
    

• Information architecture

  • как используются данные и информация
  • что компания должна знать для запуска бизнес-роцессов и операций
  • определение функциональных требований к данным
  • определение необходимой информации
  • определение прав доступа к данным
  • определение мест хранения данных (servers, databases, spreadsheets)
    
    

• Technology architecture

  • необходимое software и hardware
  • техническая инфраструктура организации
    

Infrastructure model

Описывает все ресурсы, необходимые для поддержки технической инфраструктуры.

• Technologies and standards

• Operational processes

• People and organization resources

TCO (Total Cost of Ownership) model

Оптимизация ресурсов, направленная на минимизацию стоимости проекта.

Факторы, которые могут быть оптимизированы:

• Cost model elements

  Показывает цены относительно текущих средних цен
  
  

• Components

  Software и Hardware используемое в организации
  
  

• Operations

  Элементы, необходимые для нормального функционирования программного обеспечения, такие как
  

  • установка
  • техническая поддержка
  • обучение пользователей
    
    

• Management

  Администрирование сети, данных и др.
  
  

• Hidden costs
  
  

• Downtime and other costs

  Разработка и тестирование

Для оптимизации вышеперечисленных факторов модель применяет 3-х этапную модель. Этапы выполняются последовательно.

• Benchmark and Baseline phase

  Benchmark - общая цена, базируящаяся на средних ценах на рынке.
  Baseline - реальная цена внедрения технологии
  
  

• Improvement phase

  Предложения по минимизации стоимости внедрения технологий. Определение стратегии.
  
  

• Management phase

  Сравнение того что хотелось получить с тем что получилось

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