Редактор русского перевода

Стр 1 из 7Следующая ⇒

Содержание

Аннотация.. 1

Краткий обзор методологии.. 2

Введение.. 2

Базовые принципы MSF.. 3

Ключевые концепции.. 4

Характеристики управления проектами MSF.. 6

Рекомендации проектным группам... 13

Рекомендации по составлению календарного графика.. 21

Заключение.. 22

Microsoft Solutions Framework

“Белая книга” (White Paper)

Опубликовано: июнь 2002 г.

Для получения дальнейшей информации по MSF, см. http://www.microsoft.com/msf

Перевод на русский язык

Станислав Бусыгин, научный консультант, eLine Software, Inc., Украина/США

Ольга Палий, консультант, eLine Software, Inc., Украина/США

Редактор русского перевода

Владимир Павлов, технический директор, eLine Software, Inc., Украина/США

Рецензенты русского перевода

Андрей А. Терехов, исполнительный директор ЗАО ЛАНИТ-ТЕРКОМ, Россия

Иля Фортунов, старший архитектурный консультант, Microsoft Enterprise Services, UK

Виталий Шорин, преподаватель, УЦ ИТ, Академия Народного Хозяйства при Правительстве РФ, Россия

Аннотация

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

Краткий обзор методологии

Стремясь достичь максимальной отдачи от IT-проектов, Майкрософт выпустил в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Майкрософт при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт, разрабатывавших проекты на предприятиях заказчиков, и лучшем из того, что накопила на данный момент IT‑индустрия. Все это представлено в виде двух связанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).

Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Информация по MSF доступна в Internet по адресу http://www.microsoft.com/msf/.

MOF призван обеспечить организации, создающие критичные (mission-critical) IT‑решения на базе продуктов и технологий Майкрософт, техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала, процессов, технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Central Computer and Telecommunications Agency – Агентством коммерческой палаты правительства Великобритании (Office of Government Commerce ‑ OGC). Информация по MOF доступна в Internet по адресу http://www.microsoft.com/mof/.

Введение

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

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

Носителем профессиональных управленческих навыков и организатором работы команды в MSF является ролевой кластер “Управление программой”. Однако типовые управленческие обязанности при этом распределяются среди лидеров всех ролевых кластеров проектной группы.

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

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

· Профессиональные менеджеры выступают в качестве консультантов и наставников команды, а не выполняют функции контроля над ней.

До прочтения данного документа необходимо ознакомиться с “Белой книгой” модели проектной группы MSF.

Базовые принципы MSF

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

Ключевые концепции

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

Дисциплины MSF

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

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

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

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

Функциональные группы

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

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

Рисунок 2. Пример функциональной группы “Удовлетворение потребителя”

Группы направлений

Рисунок 3. Пример групп направлений

Группы направлений – это многопрофильные подкоманды, организуемые для создания определенной составляющей решения. Они компонуются из ролей модели проектной группы. Рис. 3 иллюстрирует группы направлений. Исполнитель роли “Управление программой” также является лидером группы и обеспечивает интеграцию с общей проектной командой. Создание групп направлений может быть разумным решением при организации удаленных или “офшорных” (off-shore) подразделений, разрабатывающих в значительной мере независимые компоненты решения.

Лидеры групп

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

Существует три аспекта (из показанных на рис. 5), ответственность за которые не возлагается на лидеров команд:

1. Управление стоимостью проекта обычно осуществляется централизовано кластером “Управление программой”. Распределение этой функции среди лидеров команд было бы не рационально и могло бы привести к хаосу в работе.

2. Функции снабжения обычно осуществляются ролевыми кластерами “Управление программой” и/или “Управление выпуском” без участия других лидеров команд. “Управление программой” руководит закупками и заключением контрактов на предоставление необходимых для проекта услуг. Например, это может быть привлечение в проектную команду в качестве субподрядчика сторонней фирмы, занимающейся веб‑дизайном. “Управление выпуском”, будучи ответственным за обеспечение работы проектной группы, осуществляет закупки аппаратного и программного обеспечения, способствует приобретению другого имущества, необходимого для команды разработчиков, лабораторий тестирования и создания разрабатываемого решения в целом.

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

Управление программой

В дополнение к ответственности за высокоуровневую архитектуру решения и создание функциональных спецификаций (в соответствии с моделью проектной группы), ролевой кластер “Управление программой” является единым организатором всех аспектов деятельности по управлению проектом.

“Управление программой” интегрирует планы подкоманд в сводный план проекта, синхронизирует календарные графики и контролирует межкомандные взаимосвязи.

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

Отчетность перед заказчиком

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

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

Следует помнить, что:

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

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

Модель проектной группы MSF предусматривает следующую ответственность перед заказчиком:

· Ролевой кластер “Управление продуктом” поддерживает связь с заказчиком и представляет его интересы в проектной группе. Эта роль служит целям удовлетворения заказчика.

· Задача ролевого кластера “Управление программой” – успешная поставка решения в рамках проектных ограничений.

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

· Как только возникает проблема, которую “Управление продуктом” и “Управление программой” не способны решить совместно, производится эскалация по единой проектной иерархии подотчетности.

Рекомендации проектным группам

Ниже рекомендуется ряд практических методик по управлению проектами для использования лидерами команд и ролевым кластером “Управление программой”. Они относятся к значительной части зон ответственности управления проектами, показанных на рис. 5.

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

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

Планы проекта

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

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

План	Ведущий ролевой кластер
Коммуникационный план	Управление продуктом
План разработки	Разработка
План обучения	Удовлетворение потребителя
План мер безопасности	Разработка, Управление выпуском
План тестирования	Тестирование
План финансирования	Управление программой
План внедрения	Управление выпуском
План закупок и материального обеспечения	Управление выпуском, Управление программой
План пилотного внедрения	Управление выпуском

Преимущества WBS

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

WBS помогает:

· Оценивать будущие затраты. Формируемая базовая версия списка проектных задач позволяет оценить материальные и временные затраты на реализацию проекта.

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

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

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

· Специфицировать ответственность. WBS может быть использован при создании матрицы ответственности (responsibility matrix).

Соответствие между WBS, функциональными спецификациями и сводным планом проекта

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

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

Если существуют составляющие решения, с которыми в WBS не ассоциированы никакие задачи, это указывает на необходимость доработки WBS с целью избежания на последующих этапах проекта недопустимо больших временных или финансовых затрат на “неожиданно” выявившиеся “новые” задачи.

Сводный план проекта и WBS дополняют друг друга. WBS кратко перечисляет стоящие перед проектной группой задачи. Планы же проекта детально документируют, как каждая из имеющихся задач должна выполняться, какие установлены критерии качества (quality bars), какие есть элементарные подзадачи и чеклисты (контрольные списки - checklists) и т.д.

Рис. 6 схематически иллюстрирует использование WBS в качестве инструмента поддержки соответствия между спецификациями, планами и календарными графиками.

Рисунок 6. WBS показывает соответствие между спецификациями, планами и календарными графиками проекта

Создание WBS

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

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

Для создания WBS лидеры ролевых кластеров проводят собрания своих команд. При определении фронта необходимых работ и его разбиении на меньшие части, члены ролевых кластеров совместно анализируют спецификации составляющих решения. Этот процесс называется декомпозицией работы (work breakdown / work decomposition).

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

Первый уровень структуры WBS может соответствовать фазам жизненного цикла проекта. Фазы модели процессов MSF очень хорошо подходят для этого. Предлагаемые в MSF промежуточные вехи фаз проекта соответствуют созданию базовых или рабочих версий определенных составляющих решения, поэтому их естественно использовать как второй уровень структуры WBS. Ниже этого уровня работа структурируется при помощи процесса декомпозиции работы/задач (work/task decomposition).

Рекомендации по декомпозиции работы

При создании WBS полезно учитывать следующие рекомендации:

· Затраты на каждую задачу должны быть реалистично оцениваемы.

· Оценка времени исполнения каждой задачи не должна быть менее одного или более 40 дней (для IT-проектов).

· Каждая задача должна иметь однозначное описание как её самой, так и ожидаемого результата.

· Задачи выделены правильно, если их выполнение может производиться без существенных пауз.

· Ответственность за каждую задачу должна быть поручена одному работнику.

· Каждая задача может предполагать дальнейшее разбиение на элементарные подзадачи.

· Деятельность, сопряженная с большими рисками, должна детализироваться больше, чем деятельность, сопряженная с меньшими рисками.

· За исключением двух верхних уровней, задачи должны формулироваться в повелительном наклонении (например, “Спроектировать схему базы данных” вместо “Схема базы данных”).

· В WBS должно быть от трех до пяти уровней определения задач.

· По ходу работы над проектом WBS последовательно дорабатывается, но обычно ее формирование производится на фазе планирования.

Оценка снизу вверх

В IT-проектах предварительные оценки длительности задач, их стоимости и т.п. следует получать от тех, кто будет затем выполнять оцениваемую работу. Оценка снизу вверх (bottom-up estimating) – это процесс выработки и интеграции оценок многими членами команды. Такой подход обладает следующими преимуществами:

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

Ответственность. Те, кто использует в работе собственные оценки, чувствуют большую ответственность, как за свою работу, так и за адекватность сделанных оценок.

Уполномоченость (empowerment) проектной группы. Календарный график, составленный самой проектной группой, а не продиктованный свыше руководством, вдохновляет проектную группу, поскольку он составлен на основе тех оценок, которые сами члены проектной группы считают реалистичными.

Анализ PERT

После того как получены оценки по каждой из указанных в WBS задач, “Управление программой” (или специалисты по управлению проектами) приводят эти оценки к единым правдоподобным значением используя различные методы статистического анализа. Наиболее часто применяется метод PERT (метод оценки и пересмотра плана - Program Evaluation and Review Technique). Он рассматривает в качестве наиболее вероятного времени работы средневзвешенную величину трех значений оценки. Также этот подход дает возможность оценить границы общих временных затрат проекта исходя из вариаций оценок всех задач критического пути (critical path) проекта.

Полное описание метода PERT не входит в рамки этого документа. Существующие на рынке инструменты автоматизации управления проектами, такие как Microsoft® Project®, позволяют легко осуществлять PERT-анализ.

Рекомендации по составлению календарного графика

Управление календарным графиком включает в себя мероприятия, обеспечивающие своевременное завершение проекта.

Упорядочивание задач

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

Ограничение времени

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

Создание временных буферов

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

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

При выборе временного буфера рекомендуется учитывать следующее:

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

· Буферное время должно выделяться как будто бы под дополнительно существующую задачу. Обычно буфера создаются перед главными вехами, особенно позднейшими из них. Временные буфера всегда должны дополнять критический путь проекта (project’s critical path). Критический путь – это наидлиннейшая цепь зависимых проектных задач, непосредственно определяющая сроки проекта.

· Использование буферного времени по ходу проекта должно подвергаться жесткому контролю.

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

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

Заключение

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

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

Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.

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

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

Microsoft и Project являются либо охраняемыми товарными знаками, либо охраняемым товарными знаками корпорации Майкрософт в США и других странах.

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

Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf .

[*] Подробную информацию о рекомендуемом MSF процессе проектирования можно почерпнуть из пятидневного учебного курса Microsoft 2710 “Analyzing Requirements and Defining Microsoft .NET Solution Architectures” (Прим. редактора перевода).

[1] PMI, Inc., A Guide to the Project Management Body of Knowledge, 2000 Edition (Newtown Square, PA: Project Management Institute, 2000), стр. 4-6. Сходные определения, используемые в европейских странах и Великобритании, могут быть найдены в G. Caupin, H. Knopfel, P. Morris, E. Motzel, O Pannenbacker, IPMA Competence Baseline (Bremen, Germany: International Project Management Association, 1999), стр. 23 и Central Computer and Telecommunications Agency, Managing Successful Projects with Prince2, (London: UK Stationery Office, 1998), стр. 7.

[2] Адаптировано из A Guide to the Project Management Body of Knowledge, стр. 39. IPMA содержит 28 областей знаний, 9 из которых описаны PMI. Prince2 имеет 8 “компонент управления проектами”, лишь 3 из которых точно соответствуют областям PMI. Области IPMA надлежащим образом соответствуют как PMI, так и Prince2.

[3] A Guide to the Project Management Body of Knowledge, стр. 4-6. WBS также определена в IPMA Competence Baseline, стр. 34.

[4] Адаптировано для MSF из “Cost Models for Future Lifecycle Processes: COCOMO 2.0” Boehm, et. al., 1995. Взято из Steve McConnell, Rapid Development (Redmond, WA : Microsoft Press, 1996), стр. 168.