Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

514 Глава 11

ходимыми характеристиками качества, ставит цель (и предлагает соответствую-

щие механизмы) для непрерывного совершенствования организации.

11.4.2. Методы улучшения качества QIP и IDEAL. Фабрика опыта

Метод QIP развивается в SEL (Software Engineering Laboratory) центра

GSFC (Goddard Space Flight Center) в NASA уже в течение 20 лет. Его применение

позволяет контролировать эволюцию целей организации и оценивать статус те-

кущих процессов по отношению к этим целям. В отличие от «лестниц восхожде-

ния», здесь используется внутреннее оценивание процессов относительно собст-

венных целей организации, а не идеализированных процессов.

Для повышения качества программных продуктов и совершенствования

процессов разработки метод использует парадигму GQM и методологию Experi-

ence Factory (Фабрика Опыта) [13]. Построение ТЛ разработки конкретной ПС ос-

новывается на анализе опыта выполнения подобных проектов, представленного в

базе знаний о проектах организации в виде «пакета моделей», и построении цепоч-

ки процессов и соответствующей инфраструктуры, пригодных для получения про-

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

Процессы (P

, Q

, R

,...) ---> Продукты (X, Y, Z,...)

и нужно разработать продукт V, то, основываясь на понимании взаимосвязи между

процессами P

, Q

, R

,... и продуктами X, Y, Z,... и целей для продукта V, мы выби-

раем соответствующую смесь подпроцессов p

, q

, r

,…, формируя процесс, адапти-

рованный для целей V:

Процесс (P

) ---> Продукты (V)

Метод QIP включает 6 шагов:

Шаг 1. Охарактеризовать текущий проект и его среду в терминах приме-

няемых моделей и метрик.

Располагая знаниями о том, что собой представляет будущий проект (особен-

ности проблемной области, факторы среды разработки, цели и ограничения проек-

та), нужно отнести его к классу проектов с подобными характеристиками для того,

чтобы воспользоваться существующим опытом разработки и выбрать оптимальную

стратегию его выполнения. При сопоставлении проектов учитываются следующие

группы факторов:

• человеческий фактор – количество исполнителей, профессиональный уро-

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

проблемной области, опыт выполнения процессов и др.;

• особенности проблемной области – тип приложений, новизна проблемати-

ки, изменчивость, внешние ограничения и др.;

• факторы процесса разработки - модель жизненного цикла, методы, техно-

логии, инструментальные средства, язык программирования и др.;

• факторы продукта – релизы (очереди поставки) системы, объем системы,

необходимые характеристики качества (например, надежность, переносность) и др.;

• факторы ресурса – компьютеры в целевой среде и среде разработки, гра-

фик разработки, финансовые средства, используемое существующее программное

обеспечение и др.

Шаг 2. Установить цели в количественном измерении для успешного ис-

полнения и усовершенствования проекта.

Глава 11 515

Используя известные механизмы определения измеримых целей, например,

QFD или GQM, установить цели для процессов и продуктов. Цели могут быть оп-

ределены для любых объектов с учетом используемых моделей качества и различ-

ных точек зрения (пользователя, заказчика, менеджера проекта, организации).

Шаг 3. Выбрать подходящую модель процессов и инструментально-

методологические средства поддержки проекта.

Все процессы должны иметь определения и описываться в терминах целей,

которые они должны удовлетворять. Это поможет понять, при каких условиях эф-

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

вующую определенному контексту применения, среде, особенностям и целям про-

екта, а также любым целям, поставленным для организации (например, проведение

экспериментов с различными процессами, моделями или другими объектами).

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

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

технологий и инструментов.

На практике, выбор процессов – итеративная процедура, с переопределением

целей и, возможно, некоторых характеристик проекта и среды разработки. Итого-

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

лям и процессам разработки ПС в установленной среде.

Шаг 4. Выполнить процессы, создать продукты, собрать данные и про-

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

корректировки проекта.

Процесс разработки должен поддерживать доступ к «носителям» накоплен-

ного опыта по всем аспектам разработки. С другой стороны, он сам должен быть

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

обратную связь для корректировки проекта. Чтобы поддержать этот анализ, нужно

собирать данные по проекту. Процессы должны быть изначально определены как

измеримые, а сбор данных - естественно в них «встроен». Так, например, класси-

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

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

сеанса инспекции проекта. Необходима автоматизированная поддержка рутинных

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

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

автоматически, что требует ответственного отношения исполнителей процессов к

этой процедуре.

Шаг 5. Проанализировать данные, для того чтобы оценить текущую

практику разработки ПС в организации, выявить проблемы, зафиксировать свя-

занные с ними факты (находки) и подготовить рекомендации для последующих

усовершенствований.

Собранные данные интерпретируются в контексте поставленных целей –

охарактеризовать (понять), оценить, предсказать, совершенствовать, и соответст-

вующих им вопросов (см. главу 4).

Шаг 6. Сформировать «пакет», содержащий сконцентрированное пред-

ставление накопленного опыта.

Опыт должен быть описан в виде обновленных и уточненных моделей и дру-

гих форм структурированных знаний, полученных по завершенному и прошлым

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

516 Глава 11

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

ределения процессов, модели качества, описания алгоритмов, процедур и извле-

ченных уроков и др.

Схематически метод представлен на рисунке 11.4. На нем указаны два цикла

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

полнения (в контрольных точках проекта), и обратная связь на уровне организации,

устанавливаемая после того, как проект завершен. Благодаря наличию этого вто-

рого витка обратной связи, ранее накопленные знания дополняются вновь приоб-

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

ции.

Охаракте-

ризовать

проект

Установить

цели

Выбрать

модель

процессов

Выполнить

процессы

Проанали-

зи ровать

данные

Сформиро-

вать пакет

информации

Цикл проекта

Цикл организации

Рис. 11.4. Схема метода QIP

Два цикла в QIP отражают два взгляда на приобретение и использование зна-

ний в программной инженерии:

•

приобретение знаний на уровне организации. Включает шаги: понять со-

стояние организации (охарактеризовать), оценить (установить цели, выбрать про-

цессы, выполнить процессы, проанализировать данные) и сформировать пакет

(упаковать вновь приобретенный опыт);

•

приобретение знаний на уровне проекта. Включает шаги: выполнить плани-

рование проекта (охарактеризовать, установить цели, выбрать процессы), разрабо-

тать продукт (выполнить процессы) и изучить опыт (проанализировать данные).

В отличие от СММ (и других «лестниц восхождения»), использование кото-

рых обеспечивает поэтапное совершенствование организации, начиная со 2-го

уровня зрелости к 5-му, применение метода QIP предполагает начать движение к

совершенству с верхнего, 5-го уровня, несмотря на отсутствие в организации ин-

ституциализированных процессов, соответствующих 5-му уровню зрелости. Побу-

дительными мотивами к совершенствованию служат деловые цели и проблемы ор-

ганизации и проекта, а не определенная извне эталонная модель процессов.

Метод QIP не противоречит CMM и организация может использовать оцени-

вание по СММ для того, чтобы определить уровень зрелости применяемых процес-

сов. Однако, совершенствование процессов методом QIP, стимулируемое внутрен-

ними целями организации, дает шанс «пройти» по шкале зрелости СММ быстрее.

Для поддержки метода в SEL создана специальная организационная структу-

ра, Организация Фабрики Опыта (EFO, от Experience Factory Organization), по-

скольку очевидно, что улучшение процесса разработки и продукта требует непре-

рывной аккумуляции оцененных элементов приобретенного опыта в форме, при-

годной для понимания, хранения и эффективной модификации.

Множество функций EFO разделено на две группы:

- функции Организации проекта по разработке программного продукта с

привлечением пакетов повторно используемого опыта. Выполняются организаци-

онной структурой проекта;

Глава 11 517

- функции Фабрики опыта, связываемые с поддержкой процесса повтор-

ного использования всех видов знаний по программной инженерии и элементов

опыта выполнения проектов. Выполняются отдельной оргструктурой.

Персонал проекта несет ответственность за действия по планированию и раз-

работке продукта, а персонал Фабрики опыта - за изучение опыта и деятельность по

передаче технологий.

Функции Организации проекта и Фабрики опыта принципиально отличны.

В Организации проекта решается конкретная проблема. Процессы, необхо-

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

блему на более мелкие составляющие, проиграть на примерах варианты решения,

запланировать и реализовать различные действия по решению.

В Фабрике опыта решения изучаются, и опыт «упаковывается» для много-

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

переопределение проблемы, а также обобщение и формализация решений, что дает

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

Кроме того, анализируется процесс синтеза решения и различные эксперимен-

тальные действия, что способствует обучению.

Модель совершенствования процессов IDEAL (от Initiating, Diagnosing, Es-

tablishing, Acting & Learning) разработана в институте SEI в 90-х годах. Описывает

пятифазный жизненный цикл внедрения усовершенствований в существующие

процессы организации. Фазы ЖЦ упорядочивают 14 видов деятельности, связанной

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

изначально модель предназначалась для совершенствования именно софтверной

деятельности на базе СММ. Особенность модели состоит в том, что она обеспечи-

вает рамочные условия для планирования и реализации Программы совершенство-

вания процессов, предполагающей интеграцию всех передовых наработок инсти-

тута SEI (технологий, методик, курсов и других услуг) в единую методологию по-

вышения зрелости организации.

Фаза Инициации (Initiating) включает: определение деловых целей и их связи

с выполняемой работой; распределение ресурсов и создание инфраструктуры для

управления реализацией усовершенствований.

Фаза Диагностики (Diagnosing) включает определение текущего состояния

организации и того состояния, которого желательно достичь. Это необходимо для

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

Фаза Учреждения (Establishing) включает: расстановку приоритетов реко-

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

плана усовершенствования процессов.

Фаза Внедрения (Acting) включает разработку, проверку на пилотных проек-

тах и утверждение решений по всем идентифицированным направлениям и дело-

вым процессам (относительно инструментов, знаний, сторонней помощи и др.), а

затем, повсеместное внедрение утвержденных решений.

Фаза Изучения (Learning) завершает цикл усовершенствований. Весь полу-

ченный опыт (при выполнении каждой фазы) пересматривается, упорядочивается и

фиксируется.

Подробнее о модели IDEAL можно узнать на сайте института SEI -

http://www.sei.cmu.edu/ideal/ideal.html.

518 Глава 11

11.5. Унифицированный процесс разработки RUP

11.5.1. Характеристика RUP

Унифицированный процесс разработки (RUP, Rational Unified Process) ведет

свою историю от продуктов Rational Approach и Objectory Process 3.8, объединение

которых произошло после слияния в 1995 г. корпораций Rational Software и Objec-

tory Process. Теперь он поддерживается и совершенствуется Rational Software с уче-

том накопленного передового опыта в области программной инженерии.

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

ектах, и не только за рубежом, но и в Украине, что доказывает его универсальность

и широкую применимость [14]. С одной стороны, RUP — это хорошо структуриро-

ванное описание процесса разработки ПС, содержащее перечень работ и задач, вы-

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

выполнения процесса. С другой стороны, RUP — это методология создания про-

граммного обеспечения, оформленная в виде размещаемой на Web-сайте (распро-

страняемой как готовый продукт) базы знаний, снабженной поисковой системой. И,

вместе с тем, и, прежде всего, RUP - это философия и практика разработки ПС [15].

Создатели RUP определили его как «итеративный, архитектурно-

ориентированный, управляемый пользовательскими сценариями (прецедентами

использования) процесс разработки ПО» [16].

Весь процесс разработки в RUP рассматривается в двух плоскостях. В стати-

ке процесс программной инженерии определяется через виды деятельности, про-

цессы ЖЦ, рабочие продукты (артефакты) и роли исполнителей, а в динамике - че-

рез циклы, фазы, итерации и вехи.

Статическая составляющая включает [15]:

— описания работ и задач (в рамках работ),

— описания создаваемых рабочих продуктов (артефактов),

— рекомендации по выполнению описаний, сгруппированные применитель-

но к таким девяти основным и обеспечивающим процессам (дисциплинам RUP):

• бизнес-моделирование (Business Modeling),

• управление требованиями (Requirements),

• анализ и проектирование (Analysis and Design),

• реализация (Implementation),

• тестирование (Test),

• внедрение (Deployment), а также

• управление конфигурациями и изменениями (Configuration and Change

Management),

• управление проектом (Project Management),

• поддержка среды разработки (Environment).

Динамическую составляющую RUP представляют четыре фазы:

• начало (Inception),

• проработка (Elaboration),

• построение (Construction) и

• передача (Transition).

Действия в фазах проекта выполняются итеративно, причем в ходе каждой

итерации сочетаются работы и задачи из различных дисциплин.

Глава 11 519

Для выполнения работ и задач в RUR определен стандартный набор ролей.

Несколько участников проекта могут выполнять одну и ту же роль; в то же время,

один участник может совмещать выполнение нескольких ролей.

Особенностью RUP является то, что в результате работы над проектом соз-

даются и совершенствуются модели, всесторонне представляющие разрабатывае-

мую ПС (а не множество бумажных документов).

Благодаря тому, что все участники проекта имеют доступ к одной и той же

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

Modeling Language (UML), в RUP обеспечивается согласованное видение того, ка-

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

Процесс разработки поддерживается множеством моделей, среди которых:

Модель сценариев использования, Концептуальная модель, Аналитическая модель

системы, Модель проектирования, Модель развертывания, Модель реализации

(диаграмма компонентов), Модель тестирования (состоит из тестовых примеров,

процедур тестирования, тестовых компонентов, не имеет отображения на UML

диаграммах) и др. Их краткое описание и сопоставительный анализ назначения

можно найти в Интернете на страницах сайта www.caseclub.ru [17].

Философию RUP отражают такие принципы, сформулированные П. Крол-

лом, как «Дух RUP», и отличающие эту методологию от других методологий ите-

ративной разработки [18] (цитируется по [15]):

• атаковать риски как можно раньше, пока они сами не перешли в атаку;

• разрабатывать именно то, что нужно заказчику;

• главное внимание - исполняемой программе;

• приспосабливаться к изменениям с самого начала проекта;

• создавать архитектурный каркас как можно раньше;

• разрабатывать систему из компонентов;

• работать как одна команда;

• сделать

качество стилем жизни.

Успех проекта и высокое качество конечного программного продукта в RUP

достигается путем применения лучших практических приемов, касающихся разра-

ботки концепции ПС, планирования и управления проектом, снижения рисков и

отслеживания их последствий, тщательной проверки экономического обоснования

работ, управления требованиями, использования компонентной архитектуры, визу-

ального моделирования, прототипирования, инкрементного создания и тестирова-

ния продукта, регулярного анализа результатов, управления изменениями и непре-

рывного контроля качества [15].

Бытует мнение, что RUP достаточно громоздкий процесс, однако он подхо-

дит как для больших, так и для маленьких коллективов разработчиков [19]. Это

конфигурируемый процесс программной инженерии, в основе которого лежит про-

стая и понятная архитектура процесса, обеспечивающая общность для целого се-

мейства процессов. Поддержку конфигурирования RUP под нужды конкретных

организаций обеспечивает компонент продукта Development Kit.

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

например, в книгах [16, 20-24].

520 Глава 11

11.5.2. Варианты адаптации RUP

Авторам известны по меньшей мере 3 варианта процессов, созданных на базе

RUP: EUP, IBM RUP, AUP. Все они используют итеративную модель ЖЦ, приня-

тую в RUP, с разбиением на 4 фазы (начало, проработка, построение, передача), и

набор инструментов поддержки визуального моделирования, разработки и тестиро-

вания Rational Inc.

EUP (от Enterprise Unified Process) — унифицированный процесс предпри-

ятия — расширение RUP. К девяти основным дисциплинам RUP в EUP добавлена

дисциплина «эксплуатация и поддержка (сопровождение)», а также 7 дополнитель-

ных дисциплин непосредственно для предприятия:

1. Бизнес моделирование предприятия (Enterprise Business Modeling).

2. Управление портфелем проектов (Portfolio Management).

3. Архитектура предприятия (Enterprise Architecture).

4. Стратегическое повторное использование (Strategic Reuse).

5. Управление персоналом (People Management).

6. Администрирование предприятия (Enterprise Administration).

7. Усовершенствование процесса ПО (Software Process Improvement).

Существует и второе расширение EUP с добавлением двух фаз в модель ЖЦ

для охвата полного ЖЦ ПС: производство (Production ), изъятие (Retirement).

IBM RUP – представляет адаптацию методологии RUP фирмы IBM. Как и в

базовом процессе RUP, в IBM RUP используется итеративная модель ЖЦ с 4 фаза-

ми, а к дисциплинам RUP добавлена дисциплина «применение компонентных ар-

хитектур» (Use Component-based architectures). Другая особенность IBM RUP —

постоянная проверка качества путем многократного тестирования версий.

AUP – (от Agile Unified Process) - упрощенный вариант RUP, представляю-

щий сочетание основных концепций RUP с принципами, провозглашенными в ма-

нифеста Agile (подробнее Agile-методологии рассмотрены дальше в этой главе).

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

ектирование, управляемое тестами (или отталкиваясь от тестов) (test driven de-

sign (TDD)), ускоренное моделирование (Agile modeling), управление изменениями

и переработка (рефакторинг) баз данных. В отличие от RUP, в AUP вместо 9 ис-

пользуется 7 дисциплин (исключены дисциплины «управление требованиями» и

«анализ и проектирование»).

11.6. Методология подготовки программных решений MSF

Методология подготовки решений Microsoft Solutions Framework (MSF)

представляет собой согласованный набор концепций, моделей и правил, позво-

ляющих разрабатывать и внедрять информационные системы на основе технологий

и инструментальных средств корпорации Microsoft [25].

В MSF термин “решение” (solution) обозначает скоординированную поставку

набора элементов (включая программные средства, технические средства, докумен-

тацию, обучение и сопровождение), необходимых для удовлетворения определен-

ной деловой- (бизнес-) потребности предприятия. Хотя MSF и используется при

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

ным образом он концентрируется на поставке решений, предназначенных для кон-

кретного заказчика.

Глава 11 521

Методология MSF описана в виде пакета руководств, включающего пять

документов, так называемых «белых книг», каждый из которых охватывает опреде-

ленную дисциплину или модель MSF

11.6.1. Модель процессов MSF

Модель процессов MSF представлена в документе Модель процессов MSF,

версия 3.1 Модель процессов (Process Model) объединяет лучшие принципы кас-

кадной и спиральной моделей. Она сохраняет преимущества упорядоченности кас-

кадной модели, не теряя гибкости спиральной модели и восполняя ее недостаток -

отсутствие четких вех выполнения работ по проекту.

В основе планирования и контроля разработки в MSF лежит управление ком-

промиссами при определении рамок проекта - объемов работ, взаимосвязанных со

сроками их выполнения и необходимыми ресурсами (затратами).

Наглядными средствами управления компромиссами в MSF являются тре-

угольник компромиссов (рисунок 11.5 а) и матрица компромиссов (рисунок 11.5 б).

Фиксируется

Согласовыва-

ется

Принимается

Ресурсы

√

√√

√

Время

√

√√

√

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

Возможности

√

√√

√

Рис. 11.5. Средства управления компромиссами в MSF

Матрица помогает обозначить проектное ограничение (одну из сторон тре-

угольника компромиссов), воздействие на которое практически невозможно (ко-

лонка “Фиксируется”), фактор, являющийся в проекте приоритетным (колонка

“Согласовывается”), и третий параметр, значение которого должно быть принято

(таким, каким оно будет) в соответствии с установленными значениями первых

двух величин (колонка “Принимается”). Возможны варианты:

• зафиксировав ресурсы, согласовать календарный график и принять ре-

зультирующий объем функциональности решения,

• зафиксировав ресурсы, согласовать функциональность решения и принять

результирующие сроки,

• зафиксировав объем функциональности решения, согласовать затрачи-

ваемые ресурсы и принять результирующие сроки,

Переводы этих документов на русский язык, выполненные eLine Software в 2002

году, можно найти в Интернет по адресу: www.microsoft.com/rus/msdn/msf/default.mspx

522 Глава 11

• зафиксировав объем функциональности решения, согласовать календар-

ный график и принять результирующие затраты ресурсов,

• зафиксировав календарный график, согласовать затраты ресурсов и при-

нять результирующую функциональность решения,

• зафиксировав сроки, согласовать объем функциональности решения и

принять результирующие затраты ресурсов.

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

1) Деление ЖЦ на фазы, заканчивающиеся главными вехами (точками пере-

хода от одной фазы к другой), в которых результаты работы подвергаются анализу,

и которые знаменуют согласие проектной группы и заказчика продолжать работу

над проектом (возможно, корректируя его рамки).

2) Итеративный подход к разработке (циклами) с промежуточными веха-

ми, которые показывают достижение определенного прогресса в ходе проекта и

расчленяют большие сегменты работы на меньшие, обозримые участки.

Методология MSF рекомендует определенный набор промежуточных вех, но

на практике они могут варьироваться от проекта к проекту.

Разработка решения начинается с построения, тестирования и внедрения ба-

зовой функциональности (включая документацию и другие элементы решения), а

затем, к этому решению добавляются все новые и новые возможности (использует-

ся стратегия версионности). Microsoft практикует ежедневные сборки» (билды)

(daily builds) как неотъемлемую составляющую рабочего процесса. Разработка и

тестирование ведутся непрерывно и одновременно, представляя собой параллель-

ные процессы. Сборки служат проверкой совместимости всех элементов нарабо-

танного решения. Эти ежедневные сборные конструкции решения не попадают в

реальную производственную среду. Выпуск решения выполняется только после

того, как оно хорошо оттестировано и стабилизировано.

Для синхронизации сборок используется механизм управления конфигура-

циями

Управление конфигурациями часто путают с управлением изменениями в

проекте (project change control). В действительности эти две задачи взаимосвязаны,

но не идентичны. Управление конфигурациями – это протоколирование и контроль

состояний элементов проекта. Управление же изменениями – это процесс рассмот-

рения и одобрения проектных изменений.

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

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

команд разработчиков и команд сопровождения. Зачастую команда разработчиков

создает решение, не уделяя должного внимания вопросам его эксплуатации. Это

приводит к низким показателям качества решения. Интегрированная модель про-

цессов MSF обеспечивает процесс передачи ответственности от команды разработ-

чиков к команде сопровождения сквозь ряд последовательных вех, а не как одно-

моментный перенос нагрузки.

В версии 3 концепция MSF охватывает весь цикл создания решений— от их

обсуждения до внедрения. Используется 5-фазовая схема цикла: выработка кон-

цепции, планирование, разработка, стабилизация, развертывание (внедрение).

Результаты каждой из фаз становятся видимыми за пределами проектной ко-

манды (табл. 11.3, использует материал Андрея Колесова, опубликованный в жур-

нале BYTE/Россия.- №7.-2004).

Таблица 11.3. Пяти фазовая схема цикла разработки в MSF

Фаза

Задачи Вехи Результат

Анализ и выработка концеп-

ции (Envision)

Определение состава команды

Определение структуры проекта

Определение бизнес-целей

Оценка существующей ситуации

Создание документа общей картины и

области действия проекта

Определение требований и профилей

пользователей

Разработка концепции решения

Оценка риска

Закрытие этапа

Промежуточные вехи:

Костяк команды сформирован

Черновой вариант концепции

проекта составлен

Главная веха:

Концепция решения утвер-

ждена

• Общее описание и рамки проекта

• Документ оценки рисков

• Описание структуры проекта

Определены роли и обязанности членов команды

Описана иерархия отчетности и ответственности в

команде, каналы взаимодействия с заказчиком

Определена концепция решения, которой должна

руководствоваться команда для достижения дол-

госрочных бизнес-целей проекта

Определена область действия (рамки) проекта

Проведено согласование с заказчиком и утвержде-

ние документов

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

(Planning)

Разработка проекта и архитектуры

решения (концептуальное, логиче-

ское, физическое проектирование)

Создание функциональной специфи-

кации*

Разработка детальных планов проекта

Разработка календарного графика

Создание среды разработки, тестиро-

вания и пилотной эксплуатации

Закрытие этапа

*) Утвержденные спецификации, пла-

ны и календарные графики образуют

базовую версию проекта. Все после-

дующие изменения утверждаются

формально

Промежуточные вехи:

Используемые технологии

утверждены

Базовая версия функциональ-

ной спецификации создана

Базовая версия сводного пла-

на проекта создана

Базовая версия сводного ка-

лендарного графика создана

Среды разработки и тестиро-

вания развернуты

Главная веха:

Планы проекта утверждены

• Функциональная спецификация

• План управления рисками

• Сводный план и календарный график проекта

(совокупность отдельных планов)

Разработан набор сценариев использования систе-

мы пользователями различных категорий

Разработана функциональная спецификация про-

дукта

Выполнена оценка стоимости работ и сроков полу-

чения результатов

Разработаны взаимосвязанные планы реализации

продукта, например, план внедрения, план тести-

рования, план эксплуатации, план мер безопасно-

сти, план обучения и др.