Тема09(СММ)-K

Модель зрелости компании, разрабатывающей ПО

Определенный уровень (Defined Level – 3)

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

Для создания и поддержания методологий в актуальном состоянии в организации, помимо проектных групп QA, подготовлена и постоянно функционирует специальный отдел QA/QM (TQM).

Компания регулярно проводит специальные тренинги для повышения профессионального уровня своих сотрудников.

31

Модель зрелости компании, разрабатывающей ПО

Определенный уровень (Defined Level – 3)

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

не имеет тенденции опускаться на нижестоящие уровни.

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

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

Каждый проект использует утвержденную версию этой технологии,

адаптированную к особенностям текущего проекта.

32

Модель зрелости компании, разрабатывающей ПО

Определенный уровень (Defined Level – 3)

Ключевые области процесса :

7.Настройка (стандартного) процесса организации

(Organization Process Focus)

8.Определение (стандартного) процесса организации

(Organization Process Definition)

9.Программа обучения (Training Program)

10.Интегрированное управление разработкой ПО (Integrated

Software Management)

11.Технология разработки ПО (Software Product Engineering)

12.Межгрупповая координация (Intergroup Coordination)

13.Экспертные (совместные) оценки (Peer Reviews)

33

Модель зрелости компании, разрабатывающей ПО

Управляемый уровень (Managed Level – 4).

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

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

областях.

34

Модель зрелости компании, разрабатывающей ПО

Модель зрелости компании, разрабатывающей ПО

Управляемый уровень (Managed Level – 4)

Ключевые области процесса :

14.Количественное управление процессом

(Quantitative Process Management)

15.Управление качеством разработки ПО

(Software Quality Management)

36

Модель зрелости компании, разрабатывающей ПО

Оптимизирующий уровень (Optimizing Level – 5)

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

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

Основной задачей всей организации на этом уровне является

постоянное совершенствование существующих процессов,

которое в идеале направлено на предотвращение известных

ошибок или дефектов и предупреждение возможных.

37

Модель зрелости компании, разрабатывающей ПО

Оптимизирующий уровень (Optimizing Level – 5)

Ключевые области процесса :

16.Предотвращение дефектов (Defect Prevention).

17.Управление изменением технологий (Technology

Change Management).

18.Управление изменением процесса (Process Change

Management).

38

Модель зрелости компании, разрабатывающей ПО

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

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

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

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

более низких уровней.

39

3 KPA

Распределение ключевых областей

по уровням

2 KPA

7 KPA

6 KPA

40

Модель зрелости компании, разрабатывающей ПО

Расширение

содержания

процесса

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

41

Общая схема формирования стандартного процесса разработки ПО в соответствии с требованиями СММ

42

Модель зрелости компании, разрабатывающей ПО

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

Характеристики Стандартного процесса

43

Модель зрелости компании, разрабатывающей ПО

Соотношение содержания ключевых областей процесса СММ и требований ISO 9000:2000

43

Модель зрелости компании, разрабатывающей ПО

Достижение 3-го и 4-го уровней СММ через требования ISO 9000:2000

45

Модель зрелости компании, разрабатывающей ПО

Соотношение стандартов СММ и ISO 9000:2000 в удовлетворении требований потребителя

46

Модель зрелости компании, разрабатывающей ПО

СММ и соотношение стандартов в области разработки ПО

47

Модель зрелости компании, разрабатывающей ПО

Соотношение стандартов в области разработки ПО

48

Модель зрелости компании, разрабатывающей ПО

Соотношение стандартов в области разработки ПО

49

Модель зрелости компании, разрабатывающей ПО

Преимущества и недостатки модели СММ

К преимуществам модели SEI SW-CMM относится то, что она ориентирована («заточена») на организации, занимающиеся разработкой программного обеспечения.

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

Основным же недостатком SW-CMM является то, что модель

не авторизована в качестве стандарта ни международными,

ни национальными органами по стандартизации. Вследствие этого применение и адаптация SW-CMM на национальном

50 уровне объективно вызывает определенные трудности.

Модель зрелости компании, разрабатывающей ПО

Общие требования СММ, распределенные по ключевым

областям процесса

51

Модель зрелости компании, разрабатывающей ПО

Level 2. KPA 1: Requirements management

(Управление требованиями)

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

Требования составляют единое целое с общими и операционными планами реализации разработки ПО. Если требования изменяются, то соответственно изменяется планы.

Требования документированы в обязательном порядке.

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

52

Модель зрелости компании, разрабатывающей ПО

Общая модель поля требований

53

Модель зрелости компании, разрабатывающей ПО

Интеграция

требований

54

Модель зрелости компании, разрабатывающей ПО

Необходимые практики управления требованиями

Цель

процессной

области

Практика

Практика

Практика

55

Модель зрелости компании, разрабатывающей ПО

Level 2. KPA 2: Software project planning

(Планирование проекта разработки ПО)

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

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

В ходе выполнения работ в случае необходимости планы

оперативно уточняются и пересматриваются.

56

Модель зрелости компании, разрабатывающей ПО

Level 2. KPA 3: Software project tracking and oversight

(Отслеживание хода проекта и контроль)

Состояние проекта (выполнение задач по этапам выполнения) отслеживается высшим руководством и менеджерами проекта и документируется по результатам периодических плановых контрольных обзоров.

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

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

57