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

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

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) моделью, поскольку она дает ответ на вопрос, какими свойствами должен обладать процесс программирования в организации, имеющей тот или иной уровень зрелости, но не говорит о том, какими средствами обеспечить улучшение процесса и достижение соответствующего уровня.

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