Технологический процесс разработки программного обеспечения

Курсовая работа

Технологический процесс разработки программного обеспечения

Киев 2008

Содержание

1. Введение

2. Понятие технологического процесса в организации

2.1 Компоненты технологического процесса организации

2.2 Компоненты технологического процесса проекта

3. Организационная структура и роли в технологических процессах

4. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения

5. Методы оценивания технологической зрелости

6. Внутренняя структура уровней зрелости

7. Иерархия оценок зрелости ТП по модели СММ

Заключение

1. Введение

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

Для построения такой инфраструктуры организации-разработчики должны иметь:

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

б) руководства по улучшению
возможностей своего ТП.

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

2. Понятие технологического процесса в организации

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

Рассматривают:

технологический процесс организации (ТПО);

технологический процесс программного проекта (ТПП).

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

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

С каждым ТП связываются:

требования к процессу, которые указывают, “что” собой представляет процесс (что он будет делать
);

архитектура процесса, которая описывает, “как” процесс будет определен (каковы будут элементы процесса и как они будут взаимосвязаны);

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

проверка и утверждение (validation) определения процесса (путем измерения его характеристик);

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

Основные элементы описанной концептуальной модели разработки ТП представлены на рис.1 и описаны ниже.

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

2.1 Компоненты технологического процесса организации

Основные компоненты ТП организации таковы:

архитектура ТП;

элементы ТП;

описания жизненных циклов (ЖЦ) ПО, рекомендованных для использования в организации;

руководства и критерии для настройки стандартного ТП организации;

база данных (БД) ТП организации;

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

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

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

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

шаблоны (template), подлежащие заполнению;

фрагменты, требующие укомплектования;

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

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

Рис.1. Концептуальная модель ТП

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

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

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

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

2.2 Компоненты технологического процесса проекта

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

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

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

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

Релизы (продукты ПО) (software products) представляют собой полное множество или любой из отдельных элементов множества компьютерных программ, процедур, данных и соответствующей документации, предназначенных для передачи
заказчику или конечному пользователю (IEEE-STD-610). Все релизы являются в то же время рабочими продуктами, но не все рабочие продукты представляют собой релизы.

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

3. Организационная структура и роли в технологических процессах

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

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

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

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

1.2 Менеджер проекта (руководитель проекта) (project manager). Руководит разработкой программной системы. Несет полную финансовую ответственность за выполнение проекта перед заказчиком.

1.3 Менеджер ПО проекта (project software manager). Несет полную ответственность за все действия, связанные с разработкой ПО проекта. Контролирует ресурсы программирования проекта. Отвечает непосредственно перед менеджером проекта. В крупных проектах менеджер ПО может быть одним (первым) из линейных менеджеров проекта.

2. Разработчики. Непосредственные исполнители (штат) проекта, объединенные в группы (бригады, команды).

2.1 Лидер (software task leader). Возглавляет бригаду разработчиков. Несет ответственность за технические решения. Отвечает перед менеджером ПО.

2.2 Персонал (штат) (staff). Лица, включая лидера, ответственные за выполнение определенных функций в проекте и не являющиеся менеджерами.

3. Группа системной инженерии (system engineering group). Коллектив исполнителей (менеджеры и штат), несущих ответственность за спецификацию системных требований; их распределение по программно-аппаратным компонентам; спецификацию интерфейсов между компонентами; мониторинг проектирования и реализации этих компонентов в соответствии со спецификациями.

4. Группа программной инженерии (software engineering group). Это коллектив исполнителей проекта (разработчиков и менеджеров), несущих ответственность за разработку и сопровождение ПО проекта.

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

5.1. Группа процесса разработки ПО (software engineering process group). Коллектив специалистов, занимающихся определением, сопровождением и улучшением ТП организации.

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

5.3. Группа обеспечения (гарантии) качества ПО (software quality assurance group). Коллектив исполнителей (менеджеры и штат), выполняющих планирование и реализацию действий, гарантирующих соблюдение дисциплины разработки в соответствии с шагами ТП и стандартами. С целью снижения риска, связанного с разработкой проектов ПО, группа обеспечения (гарантии) качества ПО получает независимость от конкретных проектов (в частности, от менеджеров проектов) и несет ответственность непосредственно перед главным менеджером организации.

5.4. Группа управления конфигурацией ПО (software configuration management group). Коллектив исполнителей (менеджеры и штат), несущих ответственность за планирование, координацию и реализацию формальных действий по управлению конфигурацией проекта ПО.

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

4. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения

Концепцию зрелости техпроцесса организации-разработчика ПО предложил институт SEI (Software Engineering Institute).

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

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

СММ-модель (от Capability Maturity Model) определяет характеристики техпроцессов, находящихся на определенном уровне зрелости, и указывает направление совершенствования ТП в организации до уровня зрелого упорядоченного процесса.

Такое определение СММ допускает нескольких направлений ее применения, например:

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

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

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

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

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

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

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

Достоинства СММ:

основывается на реальных процедурах;

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

пригодна для совершенствования или оценки процессов разработки ПО;

хорошо документирована;

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

Концепция зрелости процесса разработки ПО основывается на интеграции концепций:

технологического процесса разработки ПО (software process)

широты возможностей процесса разработки ПО (software process capability)

результативности процесса разработки ПО (software process performance)

зрелости процесса разработки ПО (software process maturity).

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

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

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

Пять уровней зрелости СММ представлены на рис.2. Стрелки на рисунке указывают вид возможностей процесса, который официально утверждается организацией на каждом уровне зрелости. Названия уровней отражают сущность изменений в основном процессе программирования:

Рис.2. Пять уровней зрелости технологического процесса разработки ПО

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

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

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

Ключевые направления совершенствования техпроцесса (КРА, от Кey Рrocess Аreas) указывают области, на которых должна сосредоточить внимание организация для улучшения ТП.

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

Таблица 1 Характеристика уровней зрелости технологического процесса разработки ПО

Уровень зрелости	Характеристика уровня зрелости	Ключевые направления совершенствования ТП
1. Начальный	Отсутствует стабильная среда разработки и сопровождения. Техпроцесс разработки неструктурирован и хаотичен. Бюджет, сроки и качество разработки непредсказуемы. Частые авралы. Успех проекта определяется способностями отдельных исполнителей или менеджера, а не организационной структурой коллектива. По оценкам SEI около 75% фирм-разработчиков ПО (за рубежом) находятся на этом уровне зрелости. Это же касается и подавляющего большинства отечественных организаций-разработчиков. Начальный уровень включен в модель с целью образования точки отсчета (базы) для оценивания последующих улучшений процесса на более высоких уровнях модели
2. Повторяемый	Управление проектом нацелено на контроль соблюдения планов по стоимости, срокам и функциональности разработки ПО. Процесс программирования упорядочен. Применяются неоднократно отработанные приемы управления для схожих проектов. Разработка новых проектов ведется на основе ранее накопленного опыта и в соответствии со стандартами в части определения и сходных требований, управления конфигурацией, планирования и оценки качества ПО	Управление требованиями Планирование проекта ПО Мониторинг проекта ПО Управление работой соисполнителя Обеспечение качества ПО Управление конфигурацией ПО
3. Фиксированный	Процесс программирования документирован, стандартизован и интегрирован в стандартный (базовый) техпроцесс. Внедрена программа обучения разработчиков ПО и менеджеров. Коллективы отдельных проектов следуют стандартизованному техпроцессу разработки в организации и настраивают его для достижения целей конкретного проекта	Обеспечение разработки техпроцессов Определение техпроцесса организации Организация обучения персонала Интегрированное управление проектом ПО Инженерный подход к разработке ПО Межгрупповая координация Коллективный просмотр
4. Управляемый	Достигается цель количественной оценки качества продуктов ПО и процессов разработки в рамках единой программы измерения. Осуществляется сбор и анализ данных по проектам, что дает возможность управлять риском проекта и “возвращать" процесс в установленные рамки	Управление техпроцессом на основе количественных оценок Управление качеством ПО
5. Оптимизируемый	Непрерывное улучшение техпроцесса на основе количественной оценки его слабых и сильных сторон. Данные об эффективности процесса разработки используются для анализа в целях перехода на новые технологии и совершенствования процесса разработки в организации. Данные о новых приемах инженерии изучаются и распространяются по организации. Коллективами проектов производится причинно-следственный анализ ошибок в проектах	Предупреждение ошибок Управление изменениями в технологии Управление изменениями в техпроцессах

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

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

административные меры (
commitment to perform) - действия организации для обеспечения хода и стабильности техпроцесса (обычно касаются формирования политики и обеспечения финансовой поддержки);

необходимые предпосылки (
ability to perform) - условия для обеспечения готовности ТП (необходимые ресурсы, организационные структуры и система обучения);

выполняемые процедуры (
activitiesperformed) - правила и процедуры, необходимые для успешной реализации соответствующего участка ТП (разработка планов и процедур, выполнение технологических операций, проверка и корректировка ТП);

измерение и анализ (
measurementandanalysis) - измерение показателей техпроцесса, анализ полученных результатов измерений, оценка состояния и эффективности процесса;

проведение проверки (
verifyingimplementation) - проверка соответствия выполняемых действий требованиям существующего техпроцесса (методы проверки - обзоры (осмотры) (reviews) и аудиторские проверки (ревизии) (audits) в ходе управления и обеспечения качества ПО).

5. Методы оценивания технологической зрелости

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

Разработано 3 метода оценивания зрелости технологического процесса:

метод SPA (от Software Process Assessment) - определение текущего состояния ТП. Используется для обследования и оценки текущего состояния процесса программирования в организации, выявления существующих проблем, определения высокоприоритетных целей улучшения процесса программирования, выработки соответствующей стратегии улучшения и получения поддержки со стороны руководства;

метод SCE (от Software Capability Evaluation) - оценка способностей организации-разработчика. Используется для идентификации риска заказчика, связанного с определенным проектом или контрактом с организацией-исполнителем на разработку высококачественного ПО в соответствии с установленными сроками и бюджетом. Может использоваться при определении потенциальных организаций-исполнителей программных проектов или для управления эффективностью ТП в организациях-исполнителях, располагающих определенными ресурсами программирования;

метод IP (от Interim Profile) - метод быстрой промежуточной оценки состояния ТП. Используется для получения достоверной информации о ходе выполнения плана мероприятий по улучшению ТП в промежутках времени между
проведением обследований по методу SPA. Осуществляется по контрольному опроснику с минимальным привлечением дополнительной информации со стороны исполнителей проектов. Условием применения этого метода является предварительная оценка по методу SPA и официально утвержденный план мероприятий по улучшению ТП в организации.

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

Обследование методом SPA с целью улучшения процесса в организации выполняется регулярно (с периодичностью 18-36 месяцев) в условиях открытости и сотрудничества с руководством и коллективом разработчиков.

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

Основные шаги выполнения оценок по СММ:

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

Шаг 2. Получение от оцениваемой организации ответов на вопросы контрольного опросника
(maturity questionnare).

Шаг 3. Анализ ответов и идентификация тех участков ТП, которые требуют дальнейшего
обследования.

Шаг 4. Посещение организации. Его цель - произвести интервьюирование разработчиков и обзоры документации
и сопоставить полученные результаты с результатами анализа по опроснику. Руководящими материалами в этом процессе служат описание КРА и практических приемов СММ. В своей работе группа использует методы проведения экспертизы, что дает ей возможность оценить, в какой мере КРА удовлетворяют целям процесса по каждому направлению. В случае, если обнаруживаются расхождения между ключевыми процедурами СММ и действующей практикой в организации, - группа должна документировать обоснование своих решений по каждому направлению.

Шаг 5. Формирование перечняобнаруженных отклонений (findings) по завершении работы группы в организации, которые идентифицируют сильные и слабые стороны ТП в организации. Если целью работы группы является оценивание текущего состояния и возможностей улучшения процесса в организации - она дает руководству организации соответствующие рекомендации, если же цель - оценка способности организации выполнять контракты на разработку, тогда “находки” используются для анализа риска, проводимого соответствующей инстанцией.

Шаг 6. Группа готовит отчет, в котором показывает по каким направлениям и в какой степени организация достигает или не достигает целей КРА. Цели могут считаться достигнутыми и в том случае, когда отмечены отдельные недочеты, но они не касаются основных решений, по которым оценивается достижимость целей.

6. Внутренняя структура уровней зрелости

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

Рис.3. Структура СММ

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

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

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

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

7. Иерархия оценок зрелости ТП по модели СММ

В общем случае, оцениванию подлежат (в приведенной последовательности):

ключевые процедуры (если их оценка предусмотрена в плане работ по SPA или SCE);

разделы (если их оценка предусмотрена в плане работ по SPA или SCE);

цели ключевого направления (всегда);

ключевые направления уровня (всегда);

уровень зрелости (если целью оценивания является определение уровня зрелости).

Цель определенного КРА считается достигнутой (оценка “удовлетворительно”), если в результате обследования ТП обнаруживается, что все ключевые процедуры по всем разделам направления ТП определены, реализованы практически и внедрены во все проекты организации. Оценка “не удовлетворительно" присваивается в том случае, если отмечены существенные недостатки в реализации и внедрении оцениваемых элементов СММ. Каждый метод оценивания может предлагать расширенную шкалу ранжирования, учитывающую частичность реализации целей КРА.

Ключевое направление ТП получает оценку “удовлетворительно”, если эта же оценка присвоена всем
целям, достижение которых предусмотрено по данному направлению. Если хотя бы одна из целей КРА не достигается (с оценкой “удовлетворительно”) - КРА получает оценку “не удовлетворительно".

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

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

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

детально изучить цели и процедуры КРА второго уровня (разд.4 и приложение 2);

получить административную и финансовую поддержку;

создать соответствующие организационные структуры и другие элементы ТП, рекомендуемые СММ (разд.5);

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

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

составить глобальный план работ по совершенствованию ТП организации, рассчитанный на 6-8 лет;

обеспечить надлежащее управление работами.

Заключение

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

Дальнейшая проработка СММ в SEI идет в направлении конкретизации КРА для 4 и 5 уровня СММ по мере накопления опыта в организациях, занимающих 3 ступень в иерархии СММ, а также по мере появления организаций, способных занять уровни 4 и 5. Со временем СММ должна стать многомерной, что даст возможность учесть в ней проблемы технологии проектирования и программирования, а также управления людскими ресурсами.

SEI тесно работает с ISO над созданием стандартов (в частности, ISO 15504, часть 1-9) по применению методов SPA, SCE и улучшения процессов разработки ПО.

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

9. Оценивание существующего уровня зрелости отечественных организаций

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

Процедура ориентирована на ранжирование технологической зрелости организации-исполнителя по шкале от 0 до 2, где рейтинг 2 соответствует второму уровню зрелости по модели СММ.

Процедура основана на использовании фрагмента оригинала контрольного опросника SEI в части, касающейся уровня 2 СММ, и включает следующую последовательность шагов:

Шаг 1. Организация-заказчик составляет проект паспорта
программного продукта, подлежащего разработке, по форме, представленной ниже:

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

Класс системы	(например, АСУ ТП, АИС и др.)
Прикладная область	(например, военного назначения)
Масштабность: Продолжительность Количество исполнителей объем продукта степень повторного использования	(в месяцах) (количество человек, принимающих участие в разработке) (объем ПО в строках исходного кода) ___% исходного кода, ___% модифицированного кода, __% повторно используемого кода Примечание (например, большое количество COTS - большие затраты на разработку)
Долевое участие в работе	(например, головной исполнитель, все виды работ и др.)
Организационный подход	(например, временный трудовой коллектив, интегрированная бригада и др.)
Язык (и)	используемые языки (среды) программирования
Заказчик	наименование организации-заказчика
Применяемые стандарты	(группа применяемых отечественных и международных стандартов)
Наличие соисполнителей	(да/нет, количество организаций-соисполнителей)
Новизна	(например, в замен действующей системы)
Платформа функционирования	характеристика аппаратной, программной и телекоммуникационной среды
Другие требования

Отв. исполнитель проекта: (ФИО) _____ Подпись

Рабочий телефон __________________ Дата _______________

Шаг 2. Организация-заказчик рассылает претендентам на роль исполнителей форму паспорта
и контрольный опросник
;

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

Шаг 4. Разработчик проекта заполняет паспорт
разработанного (разрабатываемого) продукта по форме паспорта и отвечает на все вопросы
контрольного опросника (приложение 1). Ответы на вопросы по каждому направлению проставляются посредством отметки (знак "+" при ручном заполнении формы или число “1” при машинном заполнении) в соответствующих колонках интервальной шкалы;

Шаг 5. Организация-претендент отсылает заполненные паспорта и контрольные опросники организации-заказчику;

Шаг 6. Эксперт организации-заказчика обрабатывает все паспорта и контрольные опросники организации-претендента и определяет уровень зрелости организации.

Обработка контрольных опросников для получения оценок включает выполнение следующих действий:

каждой оценке присваивается эквивалентный числовой коэффициент (табл.1)

Таблица 1

Оценка	Коэффициент
Почти всегда	1
Часто	0.75
Иногда	0.5
Редко	0.25
Никогда	0

обрабатывается один опросник
для одного проекта
: подсчитывается количество ответов по каждой оценке одного направления ТП (количество отметок “+” или “1” в столбце). Это количество ответов умножается на соответствующий коэффициент (см. табл.1) и вычисляется их сумма. Затем эта сумма делится на количество вопросов, касающихся данного направления (приложение 1) и умножается на 100% (для получения оценки достижимости целей направления в процентах).

Ниже приведен пример заполнения опросного листа по направлению “Управление требованиями” и оценка уровня достижимости целей по данному направлению. Соответствующий опросный лист содержит 6 вопросов. Пример заполнения опросного листа приведен в табл.2. Вычисленная оценка КРА по ответам на вопросы по данному направлению составляет.

(2*1 + 1*0.75 + 1*0.5 + 2*0) / 6 = 0.54

или в процентном отношении - 0.54*100% = 54%

Процедура повторяется по всем шести направлениям, представленным в опроснике;

3) подобным образом обрабатываются ответы на вопросы по всем проектам
;

4) по завершении обработки опросных листов оценки по каждому направлению для всех проектов усредняются
. Усредненная оценка направления по всем проектам вычисляется как медиана частных оценок. Например, если в результате обработки вопросов по первому направлению для пяти проектов были получены такие оценки: 54 58 75 79 80

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

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

6) для расчета уровня зрелости
Lзр организации применяется формула:

Lзр = 2/6 * {åi=1
[ (КPA%i) /100] }

где КРАi - полученные суммарные оценки проектов в процентах.

Таблица 2

Управление требованиями	Почти всегда	Часто	Иногда	Редко	Никогда	Не используется
1. Используются ли системные требования, делегированные ПО , в качестве основы для выполнения разработки и управления процессом разработки?	+
2. Выполняется ли корректировка планов ПО , рабочих продуктов и действий при изменении системных требований, делегированных ПО?	+
3. Руководствуется ли проект принятой в организации политикой в части управления системными требованиями, делегированными ПО?	+
4. Прошли ли лица, которым поручено управление делегированными требованиями, обучение приемам управления требованиями?	+
5. Проводятся ли измерения с целью определения адекватности действий, выполняемых по управлению делегированными требованиями (например, есть ли учет общего числа предложенных изменений в требованиях, числа принятых предложений по изменениям, числа произведенных корректировок в базовой версии и пр)?	+
6. Подвергаются ли действия по управлению требованиями в проекте ревизиям с целью обеспечения качества ПО ?	+

Таблица 3 Оценка уровня зрелости по КРА

КРА	Почти всегда >90% случаев	Часто 60-90% случаев	Почти поровну 40-60% случаев	От случая к случаю 10-40%	Крайне редко < 10%
Управление требованиями
Планирование проектов ПО
Мониторинг проектов
Управление соисполнителями
Обеспечение качества ПО
Управление конфигурацией

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