Занятие 1. Microsoft Solutions Framework

(Продолжительность занятия 45 минут)

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

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

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

Использование MSF

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

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

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

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

Модели в составе MSF

А теперь запустите видеоролик Chapl3a.exe с прилагаемого к книге компакт-диска. Он подробнее познакомит Вас со всеми моделями в составе MSF.

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

Модели MSF и их назначение перечислены в таблице.

Модель	Описание
Группа	Модель группы сотрудников, работающих над проектом
Процесс	Помогает группе определить методы планирования и контроля проектов, учитывая трудоемкость, имеющиеся ресурсы и график работ
Приложение	Помогает группе разработать распределенные приложения, обеспечивающие оптимальное повторное использование компонентов. Модели группы и процесса формируют ядро методологии MSF в области разработки и управления инфраструктурой проекта
Архитектура предприятия	Ключ к успешному долгосрочному использованию новых технологий. Это модель принятия решений, связанных с информацией, приложениями и технологиями, необходимыми для поддержки бизнеса
Разработка решении	Позволяет найти компромиссный вариант, учитывающий бизнес-цели и идеальную схему разработки, предлагаемую моделью «Приложение»
Инфраструктура	Формирует принципы управления персоналом, процессами и технологией поддержки сетей в рамках крупного предприятия
Совокупная стоимость владения	Процесс оценки и управления стоимостью информационных технологий и максимизации их отдачи

Модель «Группа»

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

Модель «Группа» описывает взаимодействие равноправных сотрудников, для каждого из которых четко определена задача. Такой подход стимулирует личную ответственность и, в конечном счете, позволяет создать высококачественный продукт. Лидеры каждой группы отвечают за менеджмент, руководство и координацию составных частей проекта, в то время как рядовые члены группы заняты выполнением возложенных на них конкретных задач.

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

Модель состоит из шести компонентов (рис. 13.1).

Рис. 13.1 Компоненты модели «Группа»

Выработка программы

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

Оценка продукта

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

Разработка

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

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

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

Логистика

Логистика помогает продумать все трудности, которые могут возникнуть при реализации какого-либо процесса. В результате развертывание и установка продукта проходит «без сучка, без задоринки», а переход рабочих групп и групп поддержки к работе с новым продуктом выполняется безболезненно.

Обучение пользователей

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

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

Модель «Процесс»

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

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

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

Модель «Процесс» состоит из четырех стадий: формирования представления, планирования, разработки и стабилизации (рис. 13.2). Каждая стадия завершается конкретным результатом.

Рис. 13.2 Четыре стадии модели «Процесс»

Формирование представления

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

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

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

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

Разработка

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

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

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

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

Стадия стабилизации завершается выпуском продукта. Тестирование не должно прерываться даже при переработке кода продукта. На стадии стабилизации главная точка приложения усилий — поиск и исправление ошибок. По окончании ее продукт передается группам развертывания и сопровождения. Группе проекта поручают создание следующей версией либо ее сотрудников подключают к работе над другими проектам.

Модель «Приложение»

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

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

Три категории сервисов

Чтобы добиться максимальной распределенности сервисов, модель «Приложение» подразделяет их натри категории: пользовательские, бизнес-сервисы и сервисы данных (рис. 13.3).

Рис. 13.3 Три категории сервисов модели «Приложение»

Пользовательские сервисы

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

Бизнес-сервисы

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

Сервисы данных

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

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

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

Модель «Архитектура предприятия»

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

Планировать архитектуру предприятия следует постоянно, по мере изменения требований бизнеса. Этот подход, часто называемый «планированием во время строительства» (planning while building), основан на таких принципах MSF, как планирование с учетом рисков, установка на фиксированную дату выпуска, планирование деятельности, конкретизация этапов и разбивка на небольшие группы. В отличие от планирования «сверху вниз», модель архитектуры предприятия не только управляет проектами, но и сама видоизменяется по мере разработки проектов (рис. 13.4).

Рис. 13.4 Уровни модели архитектуры предприятия

Бизнес-архитектура

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

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

Архитектура приложений

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

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

Информационная архитектура

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

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

Технологическая архитектура

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

• Развертываете ли Вы стандартные технологии или же приобретаете специализированные решения?
• Понимаете ли Вы, как, где и какая именно технология развертывается в Вашей организации?
• Отвечает ли Ваша технологическая инфраструктура целям и задачам Вашего бизнеса?
• Какие основные технологические тенденции влияют на Ваши операции с информационными технологиями?
• Знаете ли Вы, какой уровень подготовки персонала нужен Вам сегодня и потребуется в будущем?

Модель разработки решений

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

Эта модель координирует разработку решений с потребностями бизнеса двумя способами.

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

Модели приложения, группы и процесса помогают предварительно определить все технические и бизнес-требования к приложению, что позволяет эффективнее распределять ресурсы. Объединив эти модели, Вы увидите сходство процессов разработки программного обеспечения с проектированием архитектурных сооружении. Именно поэтому компания Microsoft называет экспертов по разработке программного обеспечения архитекторами.

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

Рис. 13.5 Три стадии модели разработки решений

Концептуальная стадия

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

Логическая стадия

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

Физическая стадия

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

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

Модель «Инфраструктура»

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

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

• формирования представления;
• планирования;
• разработки;
• стабилизации.

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

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

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

Рис. 13.6 Модель инфраструктуры

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

Модель совокупной стоимости владения

Модель совокупной стоимости владения (Total Cost of Ownership, TCO) позволяет уменьшить затраты и увеличить отдачу от вложений в информационные технологии. Вот некоторые аспекты проблемы стоимости владения, рассматриваемые в рамках этой модели.

• Роль стоимости. Вы можете снизить совокупную стоимость владения до нуля, избавившись от всех компьютеров Вашей организации, однако при этом Вы потеряете и все преимущества от их использования. Эта абсурдная ситуация иллюстрирует два ключевых момента: во-первых, оптимизация стоимости владения должна учитывать эффект от применения информационных технологий; во-вторых, задача заключается не в минимизации совокупной стоимости владения, а в оптимизации затрат на информационные технологии и отдачи от них.
• Какова реальная стоимость? В компьютерной индустрии существует множество моделей расчета совокупной стоимости владения, оценивающих годовые расходы на содержание одного персонального компьютера суммами от $3 200 до $13 000. Такой разброс вызван тем, что даже эксперты не могут прийти к соглашению о том, какие именно затраты должна учитывать модель совокупной стоимости владения. Достаточно полная модель компании Microsoft позволяет организациям понять реальную стоимость владения и использования каждого компонента информационных технологий.
• Применение ТСО для Ваших нужд. Некоторые модели ТСО учитывают все затраты на обеспечение деятельности конечных пользователей, часто без их конкретизации. Такой подход усложняет точную оценку затрат и уменьшает эффект от применения ТСО.
• Обзор картины в целом. Иногда ТСО рассматривают только как стоимость приобретения, не учитывая расходы на сети, затраты на разработку и т.д., что не позволяет получить полную оценку.

Модель ТСО — это динамический процесс уточнения стоимости, учитывающий три ключевых момента: методы оценки, вычисление стоимости и ее проверку. Этот подход полезен при выработке планов и приоритетов в проектах развития инфраструктуры.

Методы оценки

На стадии планирования определяются методы оценки расходов и доходов от инвестиций (Return of Investments, ROI) и проверки оценок. Полную стоимость вычисляют по среднеотраслевым затратам. Базовые оценки основаны на фактической стоимости приобретения, использования и списания используемых информационных технологий.

Вычисление стоимости

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

Проверка оценки

На этой стадии полученные результаты сопоставляются с поставленными задачами, что позволяет принять или отвергнуть выбранную стратегию оптимизации ТСО. В оптимизацию включены следующие элементы модели стоимости владения:

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

Рис. 13.7 Составляющие элементы модели стоимости владения

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

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

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

Резюме

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

Модель	Описание
Группа	Отслеживается состояние проекта, обеспечивается разделение обязанностей и распределение ответственности за выполнение задач. Модель состоит из шести четко определенных компонентов: выработки программы, управления продуктом, разработки, тестирования, логистики и обучения пользователей
Процесс	Выработка рекомендаций по планированию и управлению ориентированными на результат проектами на основе анализа их трудоемкости, имеющихся ресурсов и графика работ. Основные этапы — формирование представления о продукте, планирование, разработка и стабилизация
Приложение	Создание многоуровневых приложений, объединяющих пользовательские сервисы с бизнес-сервисами и сервисами данных
Архитектура предприятия	Выработка согласованного набора рекомендаций по планированию, построению и управлению технологической инфраструктурой для четырех уровней: делового, прикладного, информационного и технологического. Оценка архитектуры с этих точек зрения позволит Вам выработать оптимальную стратегию развития предприятия
Разработка решений	Пошаговая стратегия разработки бизнес-ориентированных решений для конкретных потребностей бизнеса. В основе модели лежат три стадии: концептуальная, логическая и физическая
Инфраструктура	Устанавливает принципы управления персоналом, процессами и технологией поддержки крупных корпоративных сетей. Модель основана на компонентах, определенных в модели «Группа», однако роль логистики при развертывании инфраструктуры возрастает
Совокупная стоимость владения	Помогает уменьшить затраты и увеличить отдачу от вложений в информационные технологии