Управление программными проектами. Учебное пособие

2 Краткий обзор процессов

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

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

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

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

как показано на рисунке 2.1.

Рисунок 2.1 – Поток процесса

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

31

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

Таблица 2.1 – Методы

В рамках единого менеджмента процессов происходит объединение всех

описанных методов.

32

2.1 Стадии жизненного цикла разработки продукта

В самом начале жизненного цикла разработки программного продукта,

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

Бюджет

1 – формулирование потребности; 2 – спецификация интерфейса системы;

3 – спецификация требований к ПО; 4 – описание разработки ПО; 5 – план аттестации /

верификации ПО; 6 – отчет об аттестации / верификации ПО; 7 – пользовательская документация; 8 –

документация сопровождению; 9 – архивный отчет.

Рисунок 2.2 – Локализация точки жизненного цикла разработки продукта, где

происходит подгонка процесса

33

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

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

–архитектура и план, поддерживающие информацию о методах определения процесса;

–реализация схемы процесса в проектной или организационной ситуации;

–утверждение описания процесса путем измерений;

–развертывание процесса с созданием широко распространяемого действия в пределах организации или проекта, которого предназначен процесс.

Активы процесса разработки ПО, поддерживаемые организацией с учетом

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

соответствующих программных процессов, включают:

–стандартный процесс разработки ПО в масштабах организации;

–описание жизненных циклов разработки ПО;

–принципы и критерии подгонки стандартного процесса создания ПО на

уровне организации;

–база данных процесса разработки ПО организации;

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

Процесс разработки ПО в рамках модели CMM (CapabilityMaturityModel),

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

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

34

2.2 Организационный процесс

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

Цели организационного процесса заключаются в следующем:

1Разработки и поддержки стандартного процесса создания ПО на уровне организации;

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

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

себя:

1Развитие и поддержка стандартного процесса создания ПО на уровне организации в соответствии с документированной процедурой.

2Документирование стандартного процесса разработки ПО на уровне организации согласно установленным организационным стандартам.

3Документирование и поддержание описаний жизненных циклов разработки ПО, утвержденных для использования в рамках проектов.

4Разработка и поддержка руководящих принципов и критериев для подгонки проектов стандартного процесса создания ПО на уровне организации.

5Установка и поддержка базы данных процесса создания ПО на уровне организации.

6Установка и поддержка библиотеки документации, связанной с процессом создания ПО.

35

На рисунке 2.3 показан треугольник, сформированный персоналом,

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

Продукт

Главные

детерминанты стоимости программного обеспечения, графика и качества работы

Рисунок 2.3 – Детерминанты успеха проекта

2.3 Менеджмент процесса

Менеджмент процесса начинается с определения проектного

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

36

Рисунок 2.4 – Внешний интерфейс процесса Менеджмент процесса реализует и поддерживает рабочие процессы

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

–формального определения процесса;

–измерения процесса;

–обратной связи и контроля;

–оптимизации.

У. Эдвард Деминг (W.EdwardsDeming) и В.А. Шухарт (W.A. Shewhart)

предложили простую структуру для менеджмента процесса, включающая четыре этапа:

1 Планирование краткосрочной цели:

– определение выделенного интервала времени;

– принятие решения относительно требуемых данных;

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

2 Делать то, что требуется по плану:

– собирать данные;

– разрабатывать учебные курсы или методы;

– обучать персонал сбору данных и анализу.

3 Проверять, чтобы увидеть эффект выполнения плана:

– сравнивать учебные курсы с планом;

– если план не был выполнен, добиться его выполнения;

– поиск уроков с намерением применения в будущем;

– обсуждение корректировок при различных подходах;

– определение курсов действия и изменений.

4 Действовать по рекомендациям команды:

– настройка позиций, корректировок и других элементов;

37

6 выбор соответствующего действия.

На рисунке 2.4 эти шесть этапов отображаются на оригинальном цикле PDCA

следующим образом:

–планирование отображается в план;

–выполнение отображается в исследование, наблюдение и анализ;

–проверка отображается в адаптацию;

–действие отображается в улучшение.

Процесс позволяет улучшать качество путем (1) формального определения процесса, (2) измерения процесса, (3) обратной связи и контроля, (4)

усовершенствования, (5) оптимизации.

1 Формальное определение процесса производится с помощью модели внешнего интерфейса процесса, используемый при анализе текущего процесса,

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

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

2 Оценка процесса может происходить сразу после его определения.

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

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

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

4Усовершенствование определяет цель, присущую любому процессу разработки ПО. Способность повторять успешные процессы, а также изменять

39

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

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

2.4 Стандарт IEEE 1074

Документ IEEE 1074 обеспечивает поддержку процесса жизненного цикла разработки ПО (Softwarelifecycleprocess, SLCP). Процесс SLCP определен как характерное для проекта описание процесса, который основывается на жизненном цикле ПО проекта (SLC), а также на интегральных процессах и процессах менеджмента. Интегральные процессы включают менеджмент конфигурации,

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

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

Реализация подобной методологии начинается с выбора соответствующей модели жизненного цикла разработки ПО (Softwarelifecyclemodel, SLCM)с целью ее применения в рамках определенного проекта. Затем создается цикл SLC, используя отобранную модель SLCMи действия, описанные в таблице 2.2. Используемая методология заключается в приращении SLCс применением процессов поддержки уровня организации с целью проектирования процесса SLCP. Действия описанные в таблице 2.2, охватывают полный жизненный цикл проекта ПО от исследования концепции до возможного прекращения процесса эксплуатации программной системы.

40