Что включает в себя раздел шаблона msf бизнес преимущества

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

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

CRM-система для бизнеса. OkoCRM — обзор системы и преимущества

При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (MSM), которые мы рассмотрим ниже.

Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:

· MSF – » Как правильно создавать ИТ-системы? «

· MSA – » Как правильно создавать технологическую инфраструктуру? «

· MOF – » Как правильно эксплуатировать технологическую инфраструктуру? «

· MSM – » Как правильно строить процессы управления технологической инфраструктурой? «

Как мы увидим, методики MSF и MSA в большей степени относятся к процессу разработки архитектуры прикладных систем и инфраструктуры соответственно, а методики MOF и MSM – к архитектуре системного управления, т.е. вопросам управления и эксплуатации.

При этом MOF и MSF нацелены на различные, но связанные между собой фазы жизненного цикла ИТ-решений так, как показано на рис. 9.3.

Рис. 9.3. Взаимодействие MSF и MOF для удовлетворения запросов бизнеса

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

Как составить профессиональный бизнес-план

Рис. 9.4. Различные перспективы архитектуры системы и используемые модели

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

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

Рис. 9.5. Архитектурные перспективы, шаблоны и методики Microsoft

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

Первый тип руководств – это архитектурные концепции, такие, например, как сервис-ориентированные подходы к проектированию архитектуры. Эти концепции обеспечивают следующее:

· общее понимание и язык описания архитектуры;

· общие руководства, рекомендации по использованию специфических концепций;

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

Второй набор руководств, которыми могут пользоваться системные архитекторы – это архитектурные шаблоны, о которых уже шла речь в лекциях 5-7 и которые основаны на практическом опыте большого количества успешно реализованных проектов создания распределенных прикладных систем; они явились следствием использования описанных выше архитектурных концепций. Эти шаблоны содержат в себе лучшие практики проектирования распределенных приложений и средства по минимизации рисков неудач проектов, поскольку рекомендуют хорошо апробированные модели (см. рис. 9.6).

Эти два типа руководств – архитектурные концепции и шаблоны – могут присутствовать и использоваться на различных уровнях проектирования архитектуры прикладной системы:

· на уровне концептуальной архитектуры в форме концепций построения бизнес-моделей и соответствующих шаблонов;

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

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

Рис. 9.6. Концепции и шаблоны по построению архитектуры приложений

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

Поэтому помимо методик MSF, MOF, MSA и MSM компанией опубликованы подробные руководства по разработке архитектуры систем [5.23], а также шаблоны, которые могут применяться при проектировании корпоративных информационных систем [5.24]. Эти документы можно найти в открытом доступе на следующих web-страницах Microsoft, которые посвящены вопросам архитектуры: http: //msdn.microsoft.com/architecture; http: //msdn.microsoft.com/practices; http: //www.microsoft.com/resources/practices. Читателям можно также посоветовать электронный журнал Microsoft Architecture Journal (http: //msdn.microsoft.com/architecture/journ/).

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

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

Компоненты, составляющие основу методики MSF, могут применяться по отдельности или в совокупности для увеличения вероятности успеха в следующих областях:

· разработка прикладных программных систем, включая web-приложения, системы электронной коммерции, мобильные приложения, n-уровневые системы;

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

· проекты интеграции готовых решений, таких как системы управления ресурсами предприятия (ERP), системы офисной автоматизации, системы управления проектами;

· любая сложная комбинация перечисленных выше типов проектов.

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

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

· итерационность: архитектура создается посредством последовательного выпуска версий решений;

· макетируемость: одна из целей разработки архитектуры – быстро создать промежуточный, но вполне работоспособный макет;

· учет приоритетов: разработка архитектуры всегда учитывает необходимость обеспечения поддержки основных бизнес-процессов.

Компонентами MSF являются:

· Базовые принципы. Они служат основой MSF и выражают основные ценности и стандарты, применимые ко всем элементам методики.

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

· Дисциплины MSF. Это предметные области, которые используют специфический набор методов, терминов и подходов. В настоящий момент MSF включает в себя три дисциплины: управление рисками (risk management), управление подготовкой (readiness management) и управление проектами (project management).

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

· Рекомендации MSF. Это не обязательные, но рекомендуемые практики и руководства, связанные с применением моделей и дисциплин MSF.

Разработка информационных систем с помощью MSF ведется в соответствии с концепцией » приоритета архитектуры», впервые предложенной в книге Уолкера Ройса » Управление программными проектами: унифицированный метод» (» Software Project Management: A Unified Framework» // Addison-Wesley, 1998). Она означает, что все три составляющие ИТ-проектов – планирование, создание и сопровождение системы – базируются на четко определенной высокоуровневой архитектуре, что эта архитектура сформирована до того, как начата разработка, и, наконец, что именно эта архитектура и определяет направление работы. Прежде чем применять подобный подход к конкретным приложениям, необходимо полностью определить архитектуру на уровне предприятия. Информация по MSF доступна в Интернет по адресу http: //www.microsoft.com/msf, а на русском языке по адресу http: //www.microsoft.com/rus/msdn/msf.

Методика Microsoft Systems Architecture (MSA) относится к той части архитектуры предприятия, которая называется Технологической архитектурой. Задачей методики является стандартизация подходов к строительству центров обработки данных (Data Centers), которые лежат в основе любой корпоративной информационной системы. Методика MSA призвана помочь ИТ-подразделениям предприятий создать такие решения, которые отвечали бы шести основным требованиям: безопасности, надежности, доступности, быстродействию, управляемости и простоте технической поддержки. Залогом эффективности применения MSA на практике служит то, что все входящие в состав этого решения рекомендации появились на свет в результате тщательного тестирования описываемых конфигураций программного и аппаратного обеспечения в лабораторных условиях, моделировавших самые непростые ситуации из числа возможных в повседневной практике эксплуатации информационных систем.

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

MSA описывает следующие конфигурации инфраструктуры:

· Вычислительный центр уровня подразделения (DDC – Departmental Data Center).

· Вычислительный центр уровня предприятия (EDC – Enterprise Data Center).

· Вычислительный центр Интернет-систем (IDC – Internet Data Center).

· Вычислительный центр для высокомасштабируемых сервисов (HSSDS – Highly Scalable Services Data Center).

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

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

· Справочные (эталонные или референсные) описания архитектуры.

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

· Руководство по службам.

· Руководство по поддержке.

Источник: studopedia.info

Архитектурные концепции и методики Microsoft

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

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

При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (MSM), которые рассмотрим ниже.

Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:

1. MSF – «Как правильно создавать ИТ-системы?»

2. MSA – «Как правильно создавать технологическую инфраструктуру?»

3. MOF – «Как правильно эксплуатировать технологическую инфраструктуру?»

4. MSM – «Как правильно строить процессы управления технологической инфраструктурой?»

Методики MSF и MSA в большей степени относятся к процессу разработки архитектуры прикладных систем и инфраструктуры соответственно, а методики MOF и MSM – к архитектуре системного управления, т.е. вопросам управления и эксплуатации.

При этом MOF и MSF нацелены на различные, но связанные между собой фазы жизненного цикла ИТ-решений так, как показано на рис. 9.3.

Рис. 9.3. Взаимодействие MSF и MOF для удовлетворения запросов бизнеса

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

Рис. 9.4. Различные перспективы архитектуры системы и используемые модели

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

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

Рис. 9.5. Архитектурные перспективы, шаблоны и методики Microsoft

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

Первый тип руководств – это архитектурные концепции, такие, например, как сервис-ориентированные подходы к проектированию архитектуры. Эти концепции обеспечивают следующее:

1. общее понимание и язык описания архитектуры;

2. общие руководства, рекомендации по использованию специфических концепций;

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

Второй набор руководств, которыми могут пользоваться системные архитекторы – это архитектурные шаблоны, о которых уже шла речь в лекциях 5-7 и которые основаны на практическом опыте большого количества успешно реализованных проектов создания распределенных прикладных систем; они явились следствием использования описанных выше архитектурных концепций. Эти шаблоны содержат в себе лучшие практики проектирования распределенных приложений и средства по минимизации рисков неудач проектов, поскольку рекомендуют хорошо апробированные модели (см. рис. 9.6).

Эти два типа руководств – архитектурные концепции и шаблоны – могут присутствовать и использоваться на различных уровнях проектирования архитектуры прикладной системы:

1. на уровне концептуальной архитектуры в форме концепций построения бизнес-моделей и соответствующих шаблонов;

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

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

Рис. 9.6. Концепции и шаблоны по построению архитектуры приложений

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

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

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

Компоненты, составляющие основу методики MSF, могут применяться по отдельности или в совокупности для увеличения вероятности успеха в следующих областях:

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

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

3. проекты интеграции готовых решений, таких как системы управления ресурсами предприятия (ERP), системы офисной автоматизации, системы управления проектами;

4. любая сложная комбинация перечисленных выше типов проектов.

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

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

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

3. макетируемость: одна из целей разработки архитектуры – быстро создать промежуточный, но вполне работоспособный макет;

4. учет приоритетов: разработка архитектуры всегда учитывает необходимость обеспечения поддержки основных бизнес-процессов.

Компонентами MSF являются:

1. Базовые принципы. Они служат основой MSF и выражают основные ценности и стандарты, применимые ко всем элементам методики.

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

3. Дисциплины MSF. Это предметные области, которые используют специфический набор методов, терминов и подходов. В настоящий момент MSF включает в себя три дисциплины: управление рисками (risk management), управление подготовкой (readiness management) и управление проектами (project management).

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

5. Рекомендации MSF. Это не обязательные, но рекомендуемые практики и руководства, связанные с применением моделей и дисциплин MSF.

Методика Microsoft Systems Architecture (MSA) относится к той части архитектуры предприятия, которая называется Технологической архитектурой. Задачей методики является стандартизация подходов к строительству центров обработки данных (Data Centers), которые лежат в основе любой корпоративной информационной системы. Методика MSA призвана помочь ИТ-подразделениям предприятий создать такие решения, которые отвечали бы шести основным требованиям: безопасности, надежности, доступности, быстродействию, управляемости и простоте технической поддержки. Залогом эффективности применения MSA на практике служит то, что все входящие в состав этого решения рекомендации появились на свет в результате тщательного тестирования описываемых конфигураций программного и аппаратного обеспечения в лабораторных условиях, моделировавших самые непростые ситуации из числа возможных в повседневной практике эксплуатации информационных систем.

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

MSA описывает следующие конфигурации инфраструктуры:

1. Вычислительный центр уровня подразделения (DDC – Departmental Data Center).

2. Вычислительный центр уровня предприятия (EDC – Enterprise Data Center).

3. Вычислительный центр Интернет-систем (IDC – Internet Data Center).

4. Вычислительный центр для высокомасштабируемых сервисов (HSSDS – Highly Scalable Services Data Center).

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

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

1. Справочные (эталонные или референсные) описания архитектуры.

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

3. Руководство по службам.

4. Руководство по поддержке.

Дата добавления: 2019-02-12 ; просмотров: 890 ; Мы поможем в написании вашей работы!

Источник: studopedia.net

Что включает в себя раздел шаблона msf бизнес преимущества

Опубликован: 12.03.2009 | Доступ: свободный | Студентов: 5476 / 1740 | Оценка: 4.44 / 4.12 | Длительность: 11:27:00

Специальности: Системный архитектор
< Лекция 8|| Лекция 9 || Лекция 10 >

Аннотация: IT решение. Основные принципы MSF. Модель команды: основные принципы, ролевые кластеры. Масштабирование команды MSF. Модель процесса.

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

История и текущий статус

В 90-х годах компания Microsoft, стремясь достичь максимальной отдачи от реализации заказных IT-решений и в целях улучшения работы с субподрядчиками обобщила свой опыт по разработке, внедрению, сопровождению и консалтингу ПО , создав методологию MSF . В 2002 году вышла версия MSF 3.1, состоявшая из пяти документов-руководств:

• модель процессов ( process model ),
• модель команды ( team model ),
• модель управления проектами ( project management ),
• дисциплина управления рисками ( risk management ),
• управление подготовкой ( readiness management ).

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

Основными новшествами MSF является следующее.

1. Акцент на внедрении IT-решения.
2. Модель процесса , объединяющая спиральную и водопадную модели.
3. Особая организация команды – не иерархическая, а как группа равных, но выполняющих разные функции (роли) работников.
4. Техника управления компромиссами .

Ниже мы рассмотрим эти положения более детально.

В 2005 году MSF претерпело значительные изменения. Верcия MSF 4.0. стала составной часть продукта Visual Studio Team System (VSTS) и разделилась на две ветки – MSF for Agile и MSF for CMMI . При этом, если версии до 3.х были именно методологиями (там были изложены принципы, MSF свободно распространялась в виде Word-документов, которые были также переведены на русский язык), то теперь MSF превратилась в шаблоны процесса для VSTS.

Эти шаблоны имеют описание в виде html -документов (Word-документов уже нет) и определяют типы ролей, их ответственности, действия в рамках этих ответственностей, а также все входные и выходные артефакты этих деятельностей и другие формализованные атрибуты процесса разработки. Кроме этого «человеческого» описания MSF for Agile и MSF for CMMI имеют XML -настройки, которые позволяют в точности следовать предложенным выше описаниям, используя VSTS. При этом на процесс накладываются достаточно жесткие ограничения, деятельность разработчиков сопровождается набором автоматических действий – все это задано в шаблонах. Данные шаблоны можно частично использовать (например, без некоторых ролей), а также изменять (VSTS предоставляет обширные средства настройки шаблонов). Версия MSF 4.2 продолжила направление версии MSF 4.0.

Можно считать, что фактически, версии MSF 4.x являются продуктами другого класса, чем MSF 3.x. MSF 3.х были нацелены на разработку заказных IT-решений, MSF 4.0 – на разработку произвольного ПО . Формально, документация этих версий не сильно пересекается и содержит для 3.х в большей степени общие принципы, а для 4.х – формальные атрибуты в терминах VSTS. В некотором смысле можно сказать, что MSF 4.х является реализацией MSF 3.х для продукта VSTS. В этой лекции мы рассмотрим основные принципы MSF . то есть, фактически, MSF 3.1, а в лекциях, посвященных VSTS будут рассмотрены MSF for Agile и MSF for CMMI .

Основные принципы

Перечислим основные принципы MSF .

1. Единое видение проекта. Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения ( shared vision ), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта . Как проектная группа, так и заказчик изначально имеют собственные предположения о том, что должно быть достигнуто в ходе работы над проектом. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели. Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу – «Выработка концепции», которая заканчивается соответствующей вехой.
2. Гибкость – готовность к переменам. Традиционная дисциплина управления проектами и каскадная модель исходят из того, что все требования могут быть четко сформулированы в начале работы над проектом, и далее они не будут существенно изменяться. В противоположность этому MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности.
3. Концентрация на бизнес-приоритетах. Независимо от того, нацелен ли разрабатываемый продукт на организации или индивидуумов, он должен удовлетворить определенные нужды потребителей и принести в некоторой форме выгоду или отдачу. В отношении индивидуумов это может означать, например, эмоциональное удовлетворение – как в случае компьютерных игр. Что же касается организаций, то неизменным целевым фактором продукта является бизнес-отдача ( business value). Обычно продукт не может приносить отдачу до того, как он полностью внедрен. Поэтому модель процессов MSF включает в свой жизненный цикл не только разработку продукта, но и его внедрение.
4. Поощрение свободного общения. Исторически многие организации строили свою деятельность на основе сведения информированности сотрудников к минимуму, необходимому для исполнения работы (need-to-know). Зачастую такой подход приводит к недоразумениям и снижает шансы команды на достижение успеха. Модель процессов MSF предполагает открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат , но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. По этой причине модель процессов MSF предлагает проведение анализа хода работы над проектом в определенных временных точках. Документирование результатов делает ясным прогресс, достигнутый в работе над проектом — как для проектной команды, так и для заказчика и других заинтересованных в проекте сторон.

Модель команды

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

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

Одной из особенностей отношений внутри команды является высокая культура дисциплины обязательств:

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

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

Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто из членов проектной группы в одиночку не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. Для разрешения этой дилеммы команда соратников ( команда равных, team of peers ), работающая над проектом, должна иметь четкую форму отчетности перед заинтересованными сторонами ( stakeholders ) при распределенной ответственности за достижение общего успеха. В MSF следующие ролевые кластеры (часто их называют ролями) – см. рис. 9.1.

Рис. 9.1.

• Управление продуктом ( product management ). Основная задача этого ролевого кластера – обеспечить, чтобы заказчик остался довольным в результате выполнения проекта. Этот ролевой кластер действует по отношению к проектной группе как представитель заказчика и зачастую формируется из сотрудников организации-заказчика. Он представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика. В него же входит контроль за полным пониманием интересов бизнеса при принятии ключевых проектных решений.
• Управление программой ( program management ) обеспечивает управленческие функции – отслеживание планов и их выполнение, ответственность за бюджет, ресурсы проекта , разрешение проблем и трудностей процесса, создание условий, при которых команда может работать эффективно, испытывая минимум бюрократических преград.
• Разработка ( development ). Этот ролевой кластер занимается, собственно, программированием ПО.
• Тестирование ( test ) – отвечает за тестирование ПО.
• Удовлетворение потребителя ( user experience ). Дизайн удобного пользовательского интерфейса и обеспечение удобства эксплуатации ПО (эргономики), обучение пользователей работе с ПО, создание пользовательской документации.
• Управление выпуском ( release management ). Непосредственно ответственен за беспрепятственное внедрение проекта и его функционирование, берет на себя связь между разработкой решения, его внедрением и последующим сопровождением, обеспечивая информированность членов проектной группы о последствиях их решений.
• Архитектура (Architecture) 1 Этот ролевой кластер появился в версиях MSF 4.х. До этого данная ответственность входила в ролевой кластер «Управление программой». . Организация и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений.

Масштабирование команды MSF. Наличие 7 ролевых кластеров не означает, что команда должна состоять строго из 7 человек. Один сотрудник может объединять несколько ролей. При этом некоторые роли нельзя объединять. В таблице ниже представлены рекомендации MSF относительно совмещения ролей в рамках одним членом команды. «+» означает, что совмещение возможно, «+-» — что совмещение возможно, но нежелательно, «-» означает, что совмещение не рекомендуется.

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

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

Кроме того, когда ролевому кластеру требуется много ресурсов, формируются так называемые функциональные группы ( functional teams), которые затем объединяются в ролевые кластеры . Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Например, в Майкрософт группа управления продуктом обычно включает специалистов по планированию продукта и специалистов по маркетингу. Как первая, так и вторая сферы деятельности относятся к управлению продуктом: одна из них сосредотачивается на выявлении качеств продукта, действительно интересующих заказчика, а вторая – на информировании потенциальных потребителей о преимуществах продукта.

Аналогично, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневый язык C и создают повторно используемые компоненты, которые могут пригодиться всему предприятию. Создатели же решения обычно соединяют эти компоненты и работают с языками более высокого уровня, такими как, например Microsoft Visual Basic .

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

Прочие особенности

Модель процесса

Водопадная модель – фазы работ и вехи

Источник: intuit.ru