Методология CCM (Capability Maturity Model for Software) – модель развития способности организации разрабатывать и сопровождать программные продукты) в менеджменте качества проектов

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЮЖНО-УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ФАКУЛЬТЕТ ЭКОНОМИКИ И ПРЕДПРИНИМАТЕЛЬСТВА

КАФЕДРА ЭКОНОМИКИ И ЭКОНОМИЧЕСКОЙ БЕЗОПАСНОСТИ

КОНТРОЛЬНАЯ РАБОТА

По курсу «управление качеством реализации проектов»

Тема: «Методология CCM (CapabilityMaturityModelforSoftware) – модель развития способности организации разрабатывать и сопровождать программные продукты) в менеджменте качества проектов»

Руководитель

профессор Пятков Г.Н.

« » сентября 2003 г.

Автор работы

Студент 638 группы

Гребенщиков И.А.

15 сентября 2003 г.

Челябинск

2003 г.

Содержание:

1. Введение 2

2. Причины необходимости внедрения менеджмента качества при разработке и обеспечении программных продуктов 3

3. Рассмотрение данной проблемы на примере фирмы «Платон»

г. Пенза 3

3.1 Структура СММ (эволюционная модель развития способности организации разрабатывать и сопровождать программные продукты). Сопоставление СММ и МС ИСО 9001:2000 4

3.2 Уровни оценки зрелости ОКП (областью ключевых процессов) «управление требованиями» 7

3.3 Уровни оценки зрелости ОКП «планирование проекта» 8

3.4 Уровни оценки зрелости ОКП «управление деятельностью — контроль над ходом проекта» 9

3.5Уровни оценки зрелости ОКП «процессы, связанные с оценкой, выбором и организацией работ с поставщиками» 11

3.6 Уровни оценки зрелости ОКП «контроля качества» 12

3.7 Уровни оценки зрелости ОКП «Управление конфигурацией» 14

4. Основные выводы 15

5. Литература 17

Введение

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

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

Удовлетворить такую потребность взялись несколько организаций, среди которых московская фирма «1:С». Но одна она просто физически не справлялась с такой задачей. Вследствие чего был создан такой институт как «1:С-Франчайзинг». Таким образом, у фирмы появились партнеры – внедренческие организации, занимающиеся удовлетворением потребностей в автоматизации учета непосредственно на местах.

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

Основной деятельностью внедренческой фирмы- франчайзи является оказание услуг по внедрению в организации автоматизированного учета; то есть непосредственно «на местах» выявляют эти самые потребности и ищут варианты их удовлетворения. Для внедрения требований МС ИСО серии 9000:2000 необходимо определить наиболее острые проблемы управления предприятиями. В работе охарактеризованы «болезни российского менеджмен­та», некоторые из них рассматриваются авторами на примере информационных служб, чья деятельность связана с разработкой и сопровождением программно­го обеспечения (ПО).
Такой выбор обусловлен следую­щими причинами.

I. Использование информационных технологий (ERP-систем, средств телекоммуникаций и т. п.) яв­ляется залогом эффективного внедрения современных методов управления предприятием. Внутренние иформационные службы и внешние консалтинговые организации внедряют и сопровождают данные техно­логии на предприятии. От качества их работы во мно­гом зависит успех непрерывного улучшения бизнес-процессов предприятия (BPI - BusinessProcessesIm­provement);

II. Именно в области информационных технологий (ИТ)
наиболее явно проявляется такой принцип МС ИСО 9000:2000, как «Лидерство». Лидер стремится применять новые подходы и методы, направленные на эффективное использование вычислительной техни­ки (ВТ)
и выявление будущих потребностей пользова­теля. Лидеры закладывают в информационной системе (ИС)
предприятия возможности, которые в текущий момент еще не полностью используются, но в буду­щем дадут предприятию широкий маневр для разви­тия бизнеса.

III. Развитие средств телекоммуникаций (E-mail,Интернет, ICQ и т. п.) готовит революцию в области организации производства, которую можно сравнить с революцией конца XIX в., вызванной развитием же­лезных дорог и использованием расписаний. Область программирования и сопровождения ИС - авангард­ная в новой промышленной революции . Происхо­дит перераспределение центров производства ПО. Средства телекоммуникаций делают равнозначными рабочие места, расположенные в соседних комнатах и удаленные на десятки тысяч километров друг от дру­га. Уже сейчас ведущие западные фирмы за счет суб­подрядчиков из Индии или России могут удешевить работы в 30 раз и добиться круглосуточного сопрово­ждения ПО, тем самым, повышая качество сопровож­дения на порядок. Но для ведущих фирм США, Евро­пы использование субподрядчиков из России связано с риском получить некачественную и несвоевременно исполненную работу. Для России существует угроза остаться на обочине глобального перераспределения центров разработки ПО. Так, Индия в 1999 г. зарабо­тала 2 млрд долл., получая субподрядные работы на разработку ПО и передачу результатов заказчику через Интернет, Россия - только 70 млн долл.

Некачественная работа российских информацион­ных служб, кроме того, является сдерживающим фак­тором развития всего промышленного сектора в Рос­сии. Для решения задачи организации работ по раз­витию ПО с начала 90-х годов в США (затем и во всем мире) используется методология СММ
(
Capabili
­
ty
Maturity
Model
for
Software
) — Эволюционная модель развития способности компании разрабатывать и сопровождать ПО
, которую поддерживает SEI (Soft­wareEngineeringInstitute) — Институт разработки ПО. Этот институт входит в состав американского универ­ситета Карнеги-Мелона. Использование СММ позво­лит российским предприятиям поставить разработку ПО на промышленную основу, повысить производст­венную культуру, гарантировать качественную работу и исполнение проектов точно в срок.

Далее элементы СММ соотносятся с под-элементами МС ИСО 9001:2000, названия которых заключены в скобки.

СММ рассматривается через призму практическо­го опыта ее внедрения Центром информационных технологий «Платон» (г. Пенза) в Управлении Инфор­матизации
(далее УИ) — служба одного из крупней­ших предприятий региона, и в Информационной орга­низации «
CIT
»
(далее CIT
).

В УИ до августовского кризиса 1998 г. работала сильная команда, создавшая и сопровождающая ИС предприятия. После него данное предприятие приме­нило «даунсайзиш» (снижение затрат за счет массово­го сокращения кадров), в результате произошла поте­ря лидеров. Вся деятельность УИ базировалась на личностях, а не на процедурах. Бизнес данного пред­приятия сильно зависел от ИС, поэтому крах последней означал крах самого предприятия. В этих условиях началось внедрение СММ. Перед УИ были поставлены следующие цели:

задача минимум

-
стабилизировать ситуацию экс­плуатации и сопровождения ИС (качество ИС не должно упасть по сравнению с «докризисным» перио­дом);

среднесрочная задача

—
темпы развития ИС пред­приятия не должны снижаться в условиях ограниче­ния ресурсов (сохранить качество процессов при сни­жении стоимости);

задача максимум

—
добиться высокого уровня раз­вития и сопровождения ИС, независимо от внешней и внутренней среды (добиться постоянного уровня качества ИС).

Достижение данных целей на практике означало решение задачи BPI в УИ и выход на второй уровень СММ с направлением на третий уровень. Была вы­полнена только задача минимум.

Сравним результаты, полученные УИ и CIT.

Структура СММ. Сопоставление СММ и МС ИСО 9001:2000

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

I
.
Хаос (начальный уровень)
— Initial — «самоорга­низующийся хаос». Качество ПО и процессов его раз­работки на данном уровне является случайной вели-

Схема 1

чиной и напрямую зависит от способностей отдель­ных сотрудников. Стоимость разработки ПО высока, результат непредсказуем. Для нашего примера (вне­дрение СММ в УИ) на данном уровне решается зада­ча минимум.

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

III
.
Начало оптимизации (определенность) —
Difmed — управляющие и прикладные действия по работе над ПО задокументированы, стандартизованы и объедине­ны в общий для всех проектов процесс создания ПО. Данный уровень характеризуется точной временной оценкой деятельности и расчетом себестоимости про­дукта. Целью (и критерием выхода на данный уро­вень) является создание «инкубатора лидеров». Ка­чество ПО не зависит от способностей отдельных личностей. Основное внимание уделяется приклад­ным процессам и организационной поддержке. На данном уровне решается задача максимум.

IV
.
Управление- Managed - собраны подробные данные о процессах работы над ПО и компонентах продукции. Все процессы и компоненты продукции количественно оцениваются и контролируются. Ос­новное внимание на данном уровне уделяется качест­ву продукции и процессов работы.

V
.
Высокая оптимизация
- Optimizing — обеспечи­вается BPI при помощи количественных оценок и внедрения инновационных идей и технологий.

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

Management

), организационные (

Organiza

­

tion

)

и обеспечивающие (

Engineering

)

(табл. 1).

СММ не определяет все процессы, имеющие отно­шение к разработке программного обеспечения; выде­ляются только те, которые необходимы для достиже­ния уровня СММ, они и включаются в ОКП. Каждая ОКП разбивается на пять общих свойств (CommonFeatures): обязательство выполнить
(Commenttoper­form); способность выполнить
(AbilitytoPerform); вы­полняемые действия
(ActivitiesPerformed); измерение и анализ
(MeasurementandAnalysis); проверка реализа­ции
(VerifyingImplementation).

Общее свойство «Выполняемые действия»
описыва­ет действия, которые необходимо выполнить для дос­тижения целей ОКП, остальные четыре общих свойства описывают формальные факторы, делающие процесс частью корпоративной культуры (следование курсу непрерывного улучшения). Полное выполнение всех ключевых приемов (
key
practice
)
из всех общих свойств обеспечивает достижение целей ОКП. Ключе­вые приемы описывают, каким должен стать рабочий процесс (или элемент процесса, или часть инфра­структуры), но не определяют способ достижения (конкретные технологии или методики), хотя для не­которых ключевых приемов даются общие рекоменда­ции. Для различных условий один и тот же результат может достигаться разными способами. Ключевые приемы — это скорее общие принципы работы, чем конкретные действия. Последовательное выполнение общих свойств фактически реализует цикл BPI (схема 2), т. е. непре­рывное улучшение бизнес-процессов.

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

Уровни зрелости	Категории процессов
	управляющие	организационные	обеспечивающие
V. Высокая оптимизация	Управление процессами через количественные оценки	Управление качеством ПО
IV. Управле­ние	Управление изменением технологии Управление изменением процессов	Предотвращение дефектов
III. Начало оптимизации	Общее управление ПО Координация совместной работы групп	Организация работ внутри групп Создание функциональных моделей организационных процессов Программа обучения персонала	Проектирование ПО Выявление дефектов на ранних стадиях
II. Контроль	Управление требованиями Управление субконтрактами Контроль за выполнением проектов Планирование проектов Обеспечение качества ПО Управление конфигурацией
I.Хаос	Случайные процессы

Схема 2
- цикл BPI (непре­рывное улучшение бизнес-процессов)

Цикл BPI действует на каждом уровне СММ. В табл. 2 проведены параллели между общими свойства­ми СММ и элементами стандарта ИСО 9001:2000.

Таблица 2
- параллели между общими свойства­ми СММ и элементами стандарта ИСО 9001:2000.

Общие свойства СММ	МС ИСО 9001:2000
1. Обязатель­ство выпол­нить	5. Ответственность руководства
2. Способность выполнить	6. Управление ресурсами
3. Выполняе­мые действия	7. Реализация продукции (частично): 7.2. Процессы, связанные с потребителем; 7.3. Проектирование и разработка; 7.4. Закупки; 7.5. Деятельность по производству и обслуживанию продукции
4. Измерение и анализ	8. Измерение, анализ и улучшение (I часть): 8.1. Планирование; 8.2. Измерение и мониторинг; 8.3. Управление несоответствиями; 8.4. Анализ данных для улучшения
5. Проверка реализации	8. Измерение, анализ и улучшение (11 часть): 8.5. Улучшение

Далее детализируется соответствие общего свойст­ва «Выполняемые действия» ОКП второго уровня СММ с элементом «7. Реализация продукции» МС ИСО 9001:2000.

7.2. Процессы, связанные с потребителем — управление требованиями

В этой ОКП описывается по­рядок действий, обеспечивающий появление понятных и заказчику, и исполнителю требований к ко­нечному продукту. Данная ОКП определяет следующие цели:

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

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

Достижение этих целей подра­зумевает наличие:

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

системы заявок и уточнений на протяжении всего жизненного цикла ПО;

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

Уровни оценки зрелости ОКП «Управление требо­ваниями» даны в табл. 3.

Таблица 3
- Уровни оценки зрелости ОКП «Управление требо­ваниями»

Качественная характеристика уровня зрелости	%
0. Требования заказчика формулируются и прини­маются в устной форме и затем нигде не фиксируются	0
1 . Требования заказчика фиксируются в разрозненных документах; прослеживаемости исполнения нет	20
2. Ведется диспетчирование заявок заказчика, стадии их исполнения, уровень удовлетворенности заказчика	40
3. Тесная координация работы с Заказчиком, заказчик интегрируется в процесс разработки ПО	60
4. Накапливаются формализованные знания (метрики) по удовлетворенности заказчика (для планирования приоритетов)	80
5. Система управления знаниями (СУЗ) в повседнев­ной работе помогает заказчику конфигурировать заявки на ПО с учетом будущих потребностей	100

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

УИ в начале внедрения СММ находилось на уров­не 15% зрелости данной ОКП. В начале 1999 г. в УИ внедрялась система учета заявок от подразделений

предприятия (на базе BPI-компоненты — ПО, направ­ленного на преобразование заявок в конкретные зада­ния для персонала). Попытка не удалась, и уровень управления требованиями остался прежним.

CIT в 1999 г. находилась на уровне 15%. С вводомв практику приема заявок заказчиков по E-mail,автоматического формирования заданий в ProseУровень зрелости, %

Рис. 1
. 1 -УИ; 2- CIT оценивается на 40% .

(связанных с данными заяв­ками), учета удовлетворен­ности и поже­ланий заказчи­ков, уровень зрелости дан­ной ОКП здесь

7.3. Планирование проектирования и разработки — планирование проекта

ОКП «Планирование проекта» осуществляется в рамках трехуровнего внутрифирменного планирова­ния. Внутрифирменное планирование включает:

I. «Стратегическое и годовое тактическое планиро­вание», определяющее задачи и финансовые результа­ты, которых организация хочет достичь в заданный плановый период;

II. «Объемно-календарное планирование» (или «Планирование проекта»), определяющее этапы ис­полнения проекта, календарный график начала и за­вершения этапов, результат этапов;

III. «Задание на выполнение работ», подразуме­вающее детализацию выполнения проекта до индиви­дуальных заданий исполнителям с определением нор­мативной трудоемкости, квалификационных требова­ний и используемого инструментария,

Таблица 4 -
Уровни оценки зрелости ОКП «Планирование проекта»

Качественная характеристика уровня зрелости	%
0. Планирования нет, есть авральное реагирование на внешние события	0
1. В наличии первый уровень планирования (на базе бюджетирования)	20
2. Наряду с первым уровнем вводится третий уровень планирования, второй уровень планирования — формальный	40
3. Работают все уровни планирования, центральное ме­сто занимает второй уровень (оценка альтернативных решений)	60
4. Накапливаются формализованные знания (метрики) по элементам планирования (качество, время, ресурсы, взаимодействие, риски, реагирование, условия заказчи­ка), что позволяет получать качественные планы второго уровня	80
5. СУЗ автоматически отслеживает критические моменты, помогая в перепланировании	100

Уровни оценки зрелости ОКП «Планирование проекта» показаны в табл. 4.

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

ия — «Задание на выполнение работ». Данная ОКП ставит следующие цели:

1. Нормативы на разработку ПО (временные и стоимостные оценки) должны быть задокументирова­ны для использования при планировании и отслежи­вании проектов.

2. Действия и обязательства по проектам должны планироваться и документироваться.

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

УИ в начале внедрения СММ находилось на пер­вом уровне оценки зрелости данной ОКП (20%). В 1999 г. в УИ внедрялся третий уровень планирования (на базе той же BPI-компоненты). Попытка не уда­лась. В УИ уровень управления проектами остался прежним.

CIT в 1999 г. находилась на уровне 20%. С вводомв повседневную практику

Рис. 2 - уровень зрелости данной ОКП в «CIT» оценивается на 40%

Уровень зрелости, %

форми­рования заданий, а также учета вы­полненных в рам­ках данных зада­ний работ (ПО «Prose», далее Prose), уровень зрелости данной ОКП в «CIT» оценивается на 40% (рис. 2).

7.3.1. Управление деятельностью — контроль над ходом проекта

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

Данная ОКП базируется на следующих принципах организации работ:

Вовлечение персонала.
Диспетчеризация осуществляется индивидуально каждым работником.

Разбиение работ на стадии', организация работы — выполнение работы — продвижение работы
. Внима­ние направлено на помощь в организации работ (ко­гда исполнитель сам планирует сроки и приоритеты выполнения заданий), а также в продвижении работы (демонстрация уровня и качества работы). Действуем по принципу: Работа учтена — она есть.

Работа не учтена — ее нет.

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

Данная ОКП ставит следующие цели:

1. Результаты и характеристики выполняемого проекта должны постоянно сравниваться с плановы­ми.

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

3. Изменение обязанностей должно согласовывать­ся с задействованными группами и конкретными ра­ботниками.

Вначале УИ находилось на первом уровне оценки зрелости данной ОКП (20%). В 1999 г. в УИ была частично внедрена диспетчеризация работ персонала, но это не стало постоянной практикой, и УИ оста­лось на прежнем уровне. Наблюдается тенденция к снижению уровня ОКП до 15% (табл. 5).

CIT в 1999 г.

Уровень зрелости, %

Рис. 3.
1 - УИ; 2 - CIT

находилась на уровне 20%. С вводом в повсе­дневную практику формирования за­даний, а также учета с помощью Proseвыполненных

Таблица 5 -
Управление деятельностью — контроль над ходомпроекта -
Качественная характеристика уровня зрелости - тенденция к снижению уровня ОКП

Качественная характеристика уровня зрелости	%
0. Контроля нет, есть кризисное управление внеуроч­ными работами	0
1. Существует практика ежедневного обхода рабочих мест	20
2. Существует практика ведения электронного журнала выполненных работ по персональным заданиям	40
3. Существует практика регулярной оценки выполне­ния проекта для выявления отклонений от плана	60
4. Накапливаются формализованные знания (метрики) по трудовым процессам, что позволяет персонально оценивать свою деятельность и самостоятельно реагировать на отклонения	80
5. СУЗ автоматически осуществляет контроль исполне­ния, напоминая исполнителям об отклонениях в деятельности	100

в рамках задания работ (индивидуальное диспет­чирование), уровень зрелости данной ОКП оценива­ется в 40% (рис. 3).

7.4.
Закупки
—
управление
работами с
субподрядчиками

Данная ОКП (табл. 6) определяет процессы, свя­занные с оценкой, выбором и организацией работ с поставщиками (в том числе и поставщиками реше­ний). Здесь подразумеваются следующие принципы работы.

Таблица 6 -
Данная ОКП определяет процессы, свя­занные с оценкой, выбором и организацией работ с поставщиками - Качественная характеристика уровня зрелости

Качественная характеристика уровня зрелости	%
0. Практики передачи работ субподрядчику нет	0
1 . Существует разовая практика работы с субподрядчи­ками на договорной основе, партнерских отношений нет	20
2. Имеется практика фиксирования выполненных работ субподрядчиком, дающая возможность оценивания	40
3. Существует систематическая практика оценки (вы­годно «сделать самим или заказать субподрядчикам»), идет формирование партнерских отношений с поставщиками	60
4. Накапливаются формализованные знания (метрики) по качеству и срокам выполнения работ поставщика­ми; субподрядчики полностью интегрированы в процесс создания ПО	80
5. СУЗ автоматически осуществляет контроль выполнения субподрядчиками работ, напоминая им об отклонениях в их деятельности; знания становятся доступными и субподрядчикам	100

Субподрядчик рассматривается как партнер,
с кото­рым ведутся работы на долгосрочной основе. Если субподрядчик тебя подвел, не выполнив взятые на себя обязательства, виноват не он, а ты, так как вы­брал его в качестве партнера, не просчитав все риски.

Данная ОКП определяет следующие цели:

1. Генеральный подрядчик должен выбирать толь­ко качественных субподрядчиков.

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

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

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

УИ в начале внедрения СММ находилось на пер­вом уровне оценки зрелости данной ОКП (20%). В 1999 г. в УИ была внедрена система ведения заявок субподрядчикам (сначала на базе E-mail, затем на базе Интернет). Это позволило организовать коллективную работу в системе управления заявками и оценивать исполнительскую дисциплину субподрядчиков. В УИ уровень управления работами с субподрядчиками под­нялся до 40%.

Уровень зрелости, %

Рис. 4. 1 - УИ; 2 - CIT

CIT в 1999 г. находилась на уровне 20% зрело­сти ОКП. С вво­дом в повседнев­нуюпрактику формирования заявок к субпод­рядчикам, а также

учета выполненных работ на базе E-mail, уровень зре­лости данной ОКП оценивается в 30% (рис. 4).

7.5.3. Идентификация и прослеживаемость — обеспечение качества

Рекомендуется использовать данную ОКП наряду с методологией PSP (PersonalSoftwareProcess — прог­раммное обеспечение ПК) [7], где львиная доля работ по контролю качества ПО возлагается на разработчика. По данным SEI [8] разработчик находит ошибки в 10 раз быстрее и в десять раз больше, чем тестировщик. Если выполняются действия по определению требова­ний к ПО и по оценке критериев качества ПО, то рабо­ты по автономному тестированию (т.е. тестированию отдельных кусков ПО) считаются экономически невы­годными. Тестировщики осуществляют тестирование системы по принципу «черного ящика», т. е. осуществ­ляют общесистемное тестирование.

Данная ОКП определяет следующие цели:

1) деятельность по обеспечению качества ПО должна планироваться;

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

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

4) вопросы несоответствия требованиям, которые невозможно разрешить в рамках проекта, должны ре­шаться на высшем уровне компании.

УИ в начале внедрения СММ находилось выше нулевого уровня оценки зрелости данной ОКП (10%). В 1999 г. в УИ попытались внедрить учет дефектов с назначением ответственных за дефект. В реальной ра­боте учет дефектов не использовался. Сейчас уровень обеспечения качества ПО снизился до 5%.

CIT в 1999 г. находилась на уровне 10% зрелости по данной ОКП. С вводом в повседневную практику

Уровень зрелости,

Рис. 5. 1" УИ; 2 - CIT

учета дефектов с помощью Prose уровень оценива­ется в 30%. На­блюдается тенден­ция к его повышению (рис. 5, табл. 7).

Таблица 7
- Качественная характеристика уровня зрелости контроля качества

Качественная характеристика уровня зрелости	%
0. Контроля качества ПО нет, есть повседневная практика — «лучшим контролером ПО является пользователь»	0
1. Существует практика «полицейского контроля», с определением виновного и его «материальным наказанием»	20
2. Существует практика тотального учета дефектов в разрезе выполненных работ и исполнителей; за выявленный дефект исполнитель не наказывается, идет стимулирование раннего обнаружения дефектов	40
3. Существует практика регулярного измерения уровня качества ПО и планирование повышения качества	60
4. Накапливаются формализованные знания (метрики) по причинам, вызывающим дефекты, что позволяет исполнителям самостоятельно и своевременно выявлять и исправлять дефекты	80
5. СУЗ позволяет планировать предупреждающие действия по исключению дефектов.	100

7.5.5. Консервация продукции — управление конфигурацией

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

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

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

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

Схема 3 -
систе­ма «Управление конфигурациями»

Уровень зрелости, %

Данная ОКП ставит следующие цели:

1) деятельность по управлению конфигурациями должна планироваться;

2) находящиеся в работе ПО должны быть иденти­фицируемы, управляемы и доступны;

3) изменения в ПО, находящихся в работе, долж­ны контролироваться;

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

Уровни оценки зрелости ОКП «Управление конфигурацией» даны в табл. 8.

УИ находилось на уровне 10%. В начале 1999 г. в УИ было внедрено поддержание эталонной версии, в конце 1999 г. — среда коллективной разработки «Roundtable». Но данная система не охватывала всех автономных задач, т.е. часть исполнителей в УИ нахо­дится на уровне зрелости ОКП, равном 60%, а другая — 0%. Интегральный показатель уровня зрелости ОКП - 30%.

CIT в 1999 г. находилась на уровне 20%. С вводом в повседневную практику среды коллективной разра­ботки «Roundtable» и интеграции ее с Prose уровень зрелости оценивается в 70% (рис. 6).

Таблица 8 -
Уровни оценки зрелости ОКП «Управление конфигурацией»

Качественная характеристика уровня зрелости	%
0. Нет практики ведения конфигураций, каждый исполнитель на своем компьютере имеет версии исходных файлов, и он же обновляет их у конечных пользователей	0
1. Существует практика эталонной версии, с ответственным за сборку исходных файлов от всех исполнителей	20
2. Существует технология ведения репозитария ПО, куда разработчики помещают последние версии исходных файлов	40
3. Существует практика использование технологий коллективной среды разработки, где автоматически подготавливаются версии конфигураций ПО	60
4. Накапливаются формализованные знания (метрики) по стилю и методам разработки, формируются шаблоны и сценарии тестирования, проводится регрессивное тестирование	80
5. СУЗ автоматически оценивает программный модуль и формирует шаблоны и сценарии тестирования, автоматически синхронизирует версии на разных площадках разработки	100

Рис. 6. 1-УИ; 2-
CIT

Основные выводы

Зрелость процессов работы над ПО в УИ соответ­ствует первому (начальному) уровню СММ. Есть вы­бросы в сторону второго уровня СММ только по двум ОКП: «Управление работ с субподрядчиками» и «Управление конфигурациями». Практика неустойчи­ва, и УИ может в ближайшие полгода «откатиться» назад. Виден явный провал в ОКП «Обеспечение ка­чества ПО». То состояние, в котором находится сей­час УИ, означает, что внедрение СММ не состоялось (хотя задача минимум
в УИ была решена). Выделяют­ся три основные причины этого.

I. Руководство предприятия декларативно поддер­живало внедрение СММ в УИ; в своей повседневной практике не использовало методы СММ. Сработало правило: Реальная реорганизация может проводиться только сверху.

II. При внедрении СММ в УИ была выбрана серти­фикационная схема,
т. е. следующая последователь­ность: «разработка комплекта документации» -> «нор­мирование» ->
«внедрение информационных техноло­гий» -» «начало работы персонала по СММ». Ком­плект документации был принят в УИ в качестве стан­дарта «де-юре», «де-факто» - работа велась по-старо­му. Таким образом, проявился принцип «двойных стандартов» . Результатом стало то, что в процессе всех аудиторских проверок (которых было очень много в рамках решения проблемы 2000 г.), руководство УИ показывало проверяющим данные документы, — ин­формационный аудит проходил «на ура». С практиче­ской точки зрения, данные документы стоят меньше, чем бумага, на которой они напечатаны.

III. Так как средний возраст персонала УИ был больше 40 лет, обучение сотрудников шло медленно. При внедрении модели СММ применялись жесткие методы мотивации персонала
. Пока высшее руково­дство поддерживало внедрение, темпы были приемле­мы, но затем произошел откат. Причем по некоторым ОКП откатились даже ниже уровня, с которого начи­налось внедрение СММ.

Исходя из оценки зрелости ОКП по итогам вне­дрения СММ, CIT (схема 4) ближе ко второму уровню СММ. Наблюдается отставание только по двум ОКП: «Управление работами с субподрядчика­ми» (связано с тем, что привлечение субподрядчиков было эпизодическим) и «Обеспечение качества ПО»

Таблица 9 -
оценка«Качества» организации по критериям

Оценка	Средний возраст персонала	Тип организационной структуры	Приверженность стандартам	Видение перспектив	Цели в коллективе
1	от 50 лет	Авторитарная семья	тройной стандарт	в прошлом	личные
2	от 40 лет	Эйфелева башня	двойной стандарт	в настоящем	узкие коллективные
3	от 30 лет	Ракета	единый стандарт	в ближ. будущем	на потенциал организации
4	от 20 лет	Развитая семья	непрер. улучшение	в перспективе	на развитие общества

(связано с тем, что технологию «Учета и контроля дефектов» начали внедрять в последнюю очередь, и результаты еще не сказались). Внедрению СММ в CIT способствовали следующие факторы:

I. Руководство CIT на всех уровнях способствовало внедрению методов СММ; оно первым начинало ис­пользовать методы СММ в своей повседневной прак­тике;

П. Учитывая возможность действия принципа «двойных стандартов» (рис. 6), выбрали следующую схему: «начало работы персонала по СММ» — «ввод информационных технологий» - «нормирование про­цессов» - «разработка комплекта документации». Та­ким образом, производственная культура в CIT выра­щивалась, а не навязывалась, как в УИ.

Схема 4 -
оценки зрелости ОКП по итогам внедрения СММ

III. Были исключены все жесткие методы; для мо­тивации персонала использовались только «мягкие» методы. Средний возраст персонала в CIT соответст­вовал 26 годам.

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

жесткой структуры процесс «выращивания лидеров» невозможен, поэтому необходимо принять на работу (или выбрать из существующего персонала) лидера, признать его лидером, дать соответствующие полно­мочия. Только в этом случае на предприятии будет внутренний рычаг непрерывного улучшения, который сделает возможным использование принципов «Ли­дерство» и «Вовлечение работников». CIT характери­зуется организационной структурой, именуемой как «Развитая семья», где можно наладить «систему инку­баторов», воспроизводящих и воспитывающих лиде­ров, которые смогут вовлечь весь персонал в непре­рывное улучшение, тем самым обеспечивая действие принципов «Лидерство» и «Вовлечение работников». «Качество» организации оценивается по критериям, представленным в табл. 9.

УИ представляет собой достаточно консерватив­ную организацию. Любые организационные измене­ния здесь имеют тенденцию к затуханию. В CIT на­блюдаются противоположные тенденции. Во главе уг­ла поставлен принцип «Лидерство», а «Вовлечение ра­ботников» идет на основе «Воспитания лидеров». Та­ким образом, здесь на деле работает парадигма от «качества предприятия» к «качеству человека»
(в про­фессиональном плане). Из сравнительного анализа УИ и CIT (схема 5) делаем вывод, что для налажива­ния процесса улучшения необходим определенный уровень корпоративной культуры в организации, ина­че все улучшения временны и скоротечны.

Схема 5 -
сравнительный анализ УИ и CIT

Модель СММ по заложенным в ней принципам близка к стандарту ИСО 9001:2000. Но и СММ, и ИСО 9001:2000 являются всего лишь инструментами для непрерывного улучшения деятельности предпри­ятия. Сертификация по стандарту ИСО 9001:2000 и подтверждение сертификата должны способствовать повышению качества процессов организации.

Литература

- журнал « ММК » - 2001, № 7 «Опыт повышения качества деятельности информационных служб» С.А. Волчков, И. В. Балахонова, В. В. Спиридонов

с. 14 – 23.