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

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

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 уровне. Однако, эти и другие процессы, не отнесенные, но применяемые на низлежащих уровнях, не могут в полной мере раскрыть свой потенциал, пока не будет создан соответствующий фундамент на нижних уровнях СММ.