Текст книги "Модель зрелости процессов разработки программного обеспечения"

Автор книги: Марк Паулк

Соавторы: Сьюзен Гарсия,Чарльз Вебер,Мэри Хриссис,Мерилин Буш,Билл Куртис
сообщить о нарушении

Текущая страница: 6 (всего у книги 16 страниц)

7.3. Интерпретация определения производственного процесса

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

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

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

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

7.3.1. Концепции определения процесса

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

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

? архитектурные и проектировочные соображения, влияющие на определение процесса;

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

? проверка описания процесса с помощью измерений;

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

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

Дополнительную информацию о концепциях определения процесса, разработанных внутри сообщества проектировщиков процессов, можно найти в статье «Software Process Development and Enactment: Concepts and Definitions» («Разработка и нормативы производственного процесса: концепции и определения»), [Фейлер, 92].

Рис. 7.1. Концептуальная структура производственного процесса, используемая в CMM

7.3.2. Концепции, касающиеся основных средств производственного процесса организации
Основные средства производственного процесса организации (ППО)

Организация устанавливает и сопровождает набор основных средств производственного процесса, как показано на рис. 4.1. К этим основным средствам относятся:

СППО (включая элементы и архитектуру производственного процесса);

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

инструкции и критерии для адаптации СППО;

база данных ППО;

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

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

Стандартный производственный процесс организации (СППО)

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

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

Отношения между элементами производственного процесса иногда называются «архитектурой производственного процесса».

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

Архитектура производственного процесса

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

Элемент производственного процесса

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

Утвержденное описание жизненных циклов ПО

Жизненный цикл программного обеспечения представляет собой период времени, который начинается с рождения программного продукта и завершается, когда этот продукт более не используется, включает в себя следующие стадии: разработка концепции, формулирование требований, проектирование, реализация, тестирование, установка и отладка, эксплуатация и сопровождение, иногда – вывод из эксплуатации [стандарт IEEE-STD-610].

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

Инструкции и критерии адаптации

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

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

База данных производственного процесса организации

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

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

Библиотека документации по производственному процессу

Формируется для: 1) хранения документов процесса, обладающих потенциальной ценностью для текущего и будущих проектов, особенно в их связи с СППО; 2) совместного использования этих документов в рамках организации. Эта библиотека содержит образцы и фрагменты документов, которые могут оказаться полезными в будущих проектах при адаптации СППО. Примеры могут раскрывать такие темы, как производственный процесс проекта, стандарты, процедуры, планы разработки ПО, планы измерений и учебные материалы процесса. Библиотека является важным ресурсом, который способен сократить объем работ при запуске нового проекта, предлагая примеры успешных проектов в качестве исходного шаблона.

7.3.3. Концепции, связанные с производственным процессом проекта
Описание производственного процесса проекта

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

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

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

Стадии

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

Задачи

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

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

Операции

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

Промежуточные программные продукты (результаты проекта)

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

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

Программные продукты

Представляют собой полный набор (или любой из его элементов) компьютерных программ, процедур, соответствующей документации и данных, который предназначен для поставки заказчику или конечному пользователю [IEEESTD-610].

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

7.3.4. Взаимосвязь между производственным процессом проекта и планом разработки ПО

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

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

7.3.5. Жизненные циклы и CMM

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

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

7.3.6. Технология и CMM

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

7.3.7. Документация и CMM

Ключевые практики описывают несколько документов, связанных с процессом, каждый из которых охватывает определенные области содержания. Ключевые практики не требуют соответствия «один к одному» между этими документами и реальными промежуточными продуктами организации или проекта. Также не подразумевается подобное соответствие и с документами, определенными военным ведомством, или такими стандартами, как DOD-STD-2167A или IEEE. Ключевые практики требуют лишь того, чтобы применимое содержание этих документов входило в документированные промежуточные продукты организации или проекта.

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

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

7.3.8. Сбор и анализ данных процесса

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

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

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

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

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

7.4. Организационная структура и роли

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

7.4.1. Организационные роли

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

Менеджер

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

Руководитель высшего звена

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

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

Менеджер проекта

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

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