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

Автор книги: Сьюзен Гарсия

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

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

ГЛАВА 6. ИСПОЛЬЗОВАНИЕ СТРАНИЦ ОПИСАНИЯ КЛЮЧЕВЫХ ПРАКТИК

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

Каждая из групп ключевых процессов содержит:

краткое описание,

цели,

ключевые практики.

Ключевые практики, в свою очередь, сгруппированы по общим признакам в пять подгрупп («Обязательства по выполнению», «Необходимые предпосылки», «Выполняемые операции», «Измерение и анализ» и «Проверка внедрения»). Пример страницы описания ключевой практики приведен на рис. 3.1. Под ключевыми практиками понимают:

Ключевые практики (как таковые)

Ключевые практики, известные так же как ключевые практики верхнего уровня, устанавливают основные политики, процедуры и операции для каждой группы ключевых процессов. В тексте они выделены жирным шрифтом и пронумерованы в пределах соответствующей общей области. Так, например, первая ключевая практика в группе «Выполняемые операции» носит название Операция № 1.

Подпрактики

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

Рис. 6.1. Примеры предложений, используемых в ключевых практиках

ГЛАВА 7. ИНТЕРПРЕТАЦИЯ СММ

7.1. Интерпретация ключевых практик

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

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

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

В Приложении Б приведен глоссарий, содержащий определения терминов (включая термины, описываемые в данном разделе, равно как и в прочих).

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

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

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

7.2.1. Обязательства по выполнению
Положения политики

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

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

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

Лидерство

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

7.2.2. Необходимые предпосылки
Ресурсы и финансирование

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

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

Обучение

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

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

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

Ориентация

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

Начальные условия

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

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

7.2.3. Выполняемые операции

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

Типы планов

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

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

Формальные планы

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

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

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

Неформальные планы

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

В соответствии с документированной процедурой

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

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

Отнесенные к ПО системные требования

Установленные для ПО системные требования обычно называются в СММ «установленными требованиями». Они представляют собой подгруппу системных требований, которые необходимо реализовать в программных компонентах системы. Установленные требования являются исходными данными для плана разработки ПО. Анализ требований к ПО позволяет уточнить и документировать установленные требования.

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

Отношения типа «поставщик – заказчик»

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

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

Отслеживание процесса разработки ПО с принятием корректирующих мер в сравнении с управлением ходом работ

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

Контроль в сравнении с экспертной оценкой

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

Помещение в систему управления конфигурацией в сравнении с управлением и контролем

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

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

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

7.2.4. Измерения и анализ

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

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

7.2.5. Проверка внедрения

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

Регулярный надзор со стороны высшего руководства

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

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

Регулярный и событийный надзор со стороны руководства проекта

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

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

Действия по обеспечению качества ПО

Определенные действия по проводимым группой обеспечения качества (SQA – software quality assurance) проверкам и/или аудиту описываются в виде ключевой практики. В некоторых случаях контрольные мероприятия по обеспечению качества не описываются – примерами могут служить группы ключевых процессов «Программа обучения» и «Межгрупповая координация». Эти группы ключевых процессов находятся на границе сфер компетенции организации и отдельного проекта разработки и не попадают в предполагаемую область полномочий группы обеспечения качества.