Что можно использовать для СМК проектного бизнеса

Одна из основных идей всеобщего управления качеством (Total Quality Management — TQM) заключается в том, что мы можем управлять качеством разрабатываемого продукта в основном че­рез процесс его изготовления. Качество продукта улучшается на каждой стадии этого процесса. Во-первых, вследствие техноло­гичности самого процесса, во-вторых, вследствие использования промежуточного продукта, произведенного на предыдущей ста­дии, но более высокого качества.

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

Однако если под качеством понимать степень удовлетворе­ния требованиям, то мы должны измерять выполнение этих требований в конечном продукте. Это достигается организацией процесса разработки, предусматривающего создание на основе требований плана тестирования. Далее на основе плана должны быть разработаны тестовые задания (test cases), затем соответственно тесты и тестовые процедуры. В итоге обеспечиваются те­стирование всех требований и возможность измерения степени их выполнения в готовящейся версии программы. Возможная «утечка» качества происходит при рассогласовании всех этих до­кументов в сложных проектах. Обеспечение стабильности про­цесса возлагается на контроль качества, который должен выяв­лять несоответствия и информировать о них разработчиков и руководителей проекта.

В полной мере управлять качеством можно, только, если оно измеряется на всех этапах жизненного цикла. Качество промежуточного продукта может быть установлено на основе отраслевых стандартов [2].

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

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

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

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

Остановимся сначала на кратком описании всех упомянутых на рис. 1.1 моделей и стандартов.

СММ (Capability Maturity Model) разработана Институтом тех­ники программного обеспечения (Software Engineering Institute — SEI) при университете Карнеги-Меллона (США) и описывает мо­дель зрелости процессов разработки программного обеспечения на предприятиях [3]. В рамках этой модели для каждой компа­нии может быть определен некоторый уровень (один из пяти воз­можных), свидетельствующий о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались прежде всего в целях упорядочения процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО проектами, в то время как техниче­ские аспекты разработки освещены меньше.

В версии SW-CMM V. 1.1 (Capability Maturity Model for Software) имеется 316 Key Practices.

Key Practices — это то, что должно быть внедрено на предприя­тии, и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области — Key Practices Areas (KPA); это уже совокупности взаимосвязанных процессов, которые при совместном выполнении приводят к достижению определенного набора целей.

CMMI (Capability Maturity Model Integration) — дальнейшее развитие модели СММ. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее при­емлемой для разработчиков программных систем, количество Key Practices достигает уже 417.

Увеличение Key Practices связано с самой целью разработки CMMI — модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей СММ.

Начиная с 1991 г. были разработаны модели СММ для различ­ных областей применения, наиболее существенными из них были:

• модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software — SW-CMM);

• модель зрелости процессов для системного реинжинирин­га (Electronic Industries Alliance Interim Standard — EIA/ IS 731);

• модель зрелости процессов интегрированной разработ­ки продуктов (Integrated Product Development Capability Maturity Model — IPD-CMM).

На основе этих моделей и был построен CMMI. Он вобрал в се­бя все лучшее из этих моделей, устранив неоднозначность трак­товки некоторых понятий ввиду наличия множества моделей, по­этому число ключевых практик значительно выросло.

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

Кроме того, Assessment (оценка) для CMMI будет значительно дороже, так как авторизованных SEI Lead Assessors будет пока очень мало и услуги эти будут значительно более дорогие, чем при оценке на соответствие модели СММ.

Более того, многие зарубежные специалисты в области менедж­мента качества, в том числе консультанты, довольно скептиче­ски отзываются о CMMI в контексте полезности для небольших и средних организаций (а именно такие характерны для России и СНГ). Высказывается мнение, что через некоторое время SEI придется выпустить адаптированную SW-CMM V.2. То есть если рынок не примет модели, а такие предпосылки есть, то SEI надо будет адаптироваться к его требованиям.

Стандарты ISO 12207, 15504 и т. п. были разработаны Между­народной организацией стандартизации (ISO — International Organization for Standardization) для описания соответственно про­цессов обеспечения качества в организации, жизненного цикла программ и системы постоянного повышения качества процес­сов разработки ПО.

Таблица 1.1 Сравнение состава КРА в моделях СММ и CMMI

Модель SW-CMM	Модель SW-CMMI
(18 КРА-316 Key Practics)	(25 КРА-417 Key Practics)
Уровни улучшения качества
Уровень 5. Высокая оптимизации	Уровень 5. Высокая оптимизация
(Optimizing)— 3 КРА.	(Optimizing)— 2 КРА.
Управление изменением процессов	Организационные инновации и вне-
(Process Change Management).	дрение (Organizational Innovation and
Управление изменением технологии	Deployment).
(Technology Change Management).	Анализ причин и разрешение
Предотвращение дефектов	(Causal Analysis and Resolution)
(Defect Prevention)
Уровень 4. Управляемость	Уровень 4. Управляемость
(Managed)— 2 КРА.	(Managed)—2 КРА.
Управление качеством ПО	Производительный организационный
(Software Quality Management).	процесс (Organizational Process
Управление процессами через количе-	Performance).
ственные оценки (Quantitative Process	Количественный менеджмент проекта
Management)	(Quantitative Project Management)
Уровни обеспе	чення качества
Уровень 3. Начало оптимизации —	Уровень 3. Напало оптимизации —
определенность (Defined)— 7 КРА.	определенность (Defined)— 14 КРА.
Выявление дефектов на ранних	Разработка требований
стадиях (Peer Reviews).	(Requirements Development).
Координация совместной работы	Техническое решение
групп (Intergroup Coordination).	(Technical Solution).
Проектирование ПО	Интеграция продукта
(Software Product Engineering).	(Product Integration).
Общее управление ПО	Верификация (Verification).
(Integrated Software Management).	Валидация (Validation).
Программа обучения персонала	Менеджмент рисков
(Training Program).	(Risk Management).
Создание формальных моделей	Анализ решений и разрешение (Deci-
организационных процессов	sion Analysis and Resolution).
(Organization Process Definition).	Фокусирование на процессах
Организация работы внутри групп	организации (Organization Process
(Organization Process Focus)	Focus).
	Описание процессов организации
	(Organization Process Definition).
Модель SW-CMM	Модель SW-CMMI
(18 КРА-316 Key Practics)	(25 KPA-417 Key Practics)
Уровни обеспе	чение качества
	Организационный тренинг (Organiza-
	tional Training).
	Менеджмент интеграции проектов (In-
	tegrated Project Management).
	Интегрированное управление разра-
	ботчиками (Integrated Teaming).
	Интегрированное управление постав-
	щиками (Integrated Supplier
	Management).
	Организационная среда для интегра-
	ции (Organizational Environment for In-
	tegration)
Уровень 2. Контроль — повторяе-	Уровень 2. Контроль — повторяе-
мость (Repeatable)— 6 КРА.	мость (Repeatable)— 7 КРА.
Управление требованиями	Измерение и анализ (Measurement and
(Requirements Management).	Analysis).
Контроль за ходом выполнения проек-	Менеджмент требований (Requirements
тов (Software Project Tracking and	Management).
Oversight).	Планирование проекта (Project Plan-
Планирование проектов (Software	ning).
Project Planning).	Мониторинг и контроль проекта (Pro-
Управление субконтрактамн (Software	ject Monitoring and Control).
Subcontract Management).	Менеджмент договоров с поставщика-
Обеспечение качества ПО (Software	ми (Supplier Agreement Management).
Quality Assurance).	Оценка (гарантирование) качества то-
Управление конфигурацией (Software	варов и процессов (Process and Product
Configuration Management)	Quality Assurance).
	Конфигурационный менеджмент
	(Configuration Management)

Наиболее популярным, особенно в Европе, является ISO 9001 [4].

При этом методически, в полном соответствии с дисциплиной построения сложных систем, стандарт ISO 9001 предусматрива­ет, с одной стороны, построение организационной системы «сверху вниз»: от целей предприятия и его политики — к органи­зационной структуре и формированию бизнес-процессов, и с дру­гой — итеративное развитие организационной системы через механизмы измерения и улучшения.

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

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

ITIL (IT Infrastructure Library) — сборник наилучшим образом зарекомендовавших себя методик, применяемых в работе ИТ-служб. Первоначальная версия ITIL была разработана в 1989 г. по заказу правительства Великобритании, однако благодаря уни­версальности и эффективности заложенных в ней идей ITIL бы­стро приобрела международную известность. В 2002 г. увидела свет последняя версия, обобщающая более чем 10-летний опыт использования сборника как государственными, так и частными организациями во всем мире. Сегодня документация ITIL состо­ит из 7 томов, описывающих наилучшие практики управления ИТ-инфраструктурой предприятия, процессами сопровождения ИТ-продуктов и предоставления ИТ-услуг, организации систе­мы безопасности и т. п.

COBIT (Control Objectives for Information and related Techno­logy) — открытый стандарт, имеет свою нишу в общем компле­ксе стандартов, методик и руководств. Прежде всего это стандарт управления и аудита ИТ. ITIL — библиотека лучшего практиче­ского опыта в части предоставления ИТ-услуг, a COBIT специа­лизируется и на управлении, и на аудите ИТ. Процессы ITIL, как и любые другие, могут управляться и контролироваться стандар­том COBIT.

Подобно ITIL, он построен на процессах, является открытым и независимым от конкретных производителей, платформ и тех­нологий. Структурированность проявляется в COBIT очень силь­но — 4 базовые группы (домена) содержат в себе 34 подгруппы, которые, в свою очередь, состоят из 318 объектов контроля.

При использовании ITIL в качестве методики управления ИТ-организация будет в очень большой степени удовлетворять требованиям COBIT как инструмента аудитора, естественно, на соответствующих уровнях зрелости. С другой стороны, у привер­женцев ITIL есть ряд серьезных претензий к COBIT как к инструменту управления — в частности, там не требуется разделения инцидентов и проблем, что ITIL для является основополагающим.

COBIT — результат обобщения мирового опыта, международных и национальных стандартов и руководств в области управления ИТ, аудита и информационной безопасности. Интернациональную команду разработчиков COBIT составили сотрудники госучреж­дений и коммерческих предприятий, учебных заведений и фирм, специализирующихся на вопросах безопасности и управления ИХ

Первая версия стандарта была выпущена в 1996 г. Организаци­ей аудита и контроля информационных систем (Information Systems Audit and Control Foundation, ISACF). Она включала кон­цептуальное ядро (COBIT Framework), определяющее набор ос­новополагающих принципов и понятий в области управления ИХ, описание задач управления (Control Objectives) и руководство по аудиту (Audit Guideline).

Вторая версия COBIT была опубликована в 1998 г. Она содер­жала переработанную версию высокоуровневых и детальных За­дач управления, дополненных набором инструментов внедрения (Implementation Tool Set). Хретья редакция была выпущена уже Институтом управления ИХ (IX Governance Institute), учреж­денным Ассоциацией аудита и контроля информационных сис­тем (Information Systems Audit and Control Association, ISACA), совместно с ISACF с целью развития и популяризации принци­пов управления ИХ; он в настоящее время и является основным разработчиком COBIT В третьей версии стандарта появилось ру­ководство по менеджменту (Management Guidelines), в основе ко­торого лежит понятие «система управления ИХ» (IX Governance).

На базе Модели зрелости процессов разработки ПО в настоя­щее время разрабатывается Модель зрелости для провайдеров ИХ-услуг (The IT Service Capability Maturity Model, IT CMM). В декабре 2002 г. опубликован черновик описания ее третьей сту­пени. Работа по созданию модели ведется группой голландских организаций, координируемых Software Engineering Research Centre. Работа эта открыта для участия всех заинтересованных лиц и организаций. В IT СММ ключевые процессы разделены на группы строже, чем в ITIL, при этом конкретные виды деятель­ности описаны в меньшей степени. Иными словами, если IXIL отвечает на вопрос «как?», то IT СММ — на вопрос «что?» Если сравнивать между собой процессы, описанные в каждом из этих двух подходов, мы увидим, что в IT Service СММ гораздо больше внимания уделяется организационным моментам (в частности, процессы Organization Process Definition, Xraining Program, Inter-group Coordination не имеют аналогов в ITIL) и управлению соб­ственно услугами (в IT1L — один Service Level Management, в IT СММ— 3 процесса: Service Commitment Management, Service Traclcing and Oversight, Subcontract Management).

При этом ряд процессов, базовых'для ITIL, в модели IT СММ объединены (в ITIL — Configuration и Change Management, в IT СММ — Configuration Management; процессу Service Delivery в IT СММ соответствуют 3 процесса ITIL — Release, Availability и IT Service Continuity Management). Хрудно оценивать перспектив­ность использования этой модели в реальной организации управ­ления ИT, во всяком случае пока. Скорее всего, она, как и COBIT, более применима для оценки уровня предоставления услуг. Microsoft, как известно, помимо собственно средств разработ­ки ПО, уже много лет развивает собственный вариант методоло­гии управления жизненным циклом приложений — Microsoft Solutions Framework (MSF), представляющий собой набор опи­саний процессов, принципов и наиболее эффективных реализа­ций софтверных проектов [5].

MSF (Microsoft Solutions Framework) — это концепция управ­ления ИХ-проектами, предложенная компанией Microsoft. MSF не привязан к каким-либо программными продуктам компании и представляет собой набор проверенных временем методик

и лучшей практики. Исходная версия MSF появилась в 1994 г. в результате проекта по улучшению качества разработки именно в Microsoft. Нынешняя версия прошла долгий путь развития, ей присвоен номер 3.0. В отличие от большинства других методоло­гий, MSF не ограничивается проблемами управления, а содержит конкретные технические рекомендации для разработчиков ПО. MOF (Microsoft Operations Framework) — это предложенный опять же компанией Microsoft набор технических руководств, помогающих достигнуть требуемых от информационной систе­мы уровней надежности, доступности, простоты в технической поддержке и управляемости. Рекомендации MOF касаются во­просов управления персоналом, процессами, технологиями и вы­работки стратегии управления в сложных распределенных гете­рогенных IТ-средах.

Действуя в этом направлении, Microsoft объявил о начале более плотного сотрудничества с SEI — федеральным иссле­довательским центром, управляемым университетом Карнеги-Меллона при спонсорской поддержке Министерства оборо­ны США.

Результатом этого проекта должна стать возможность совмест­ного применения MSF и модели управления процессами Capabi­lity Maturity Model® Integration (CMMI).

PMBoK (Guide to the Project Management Body of Knowledge) — это проект Project Management Institute, вобравший в себя накоп­ленные знания в области управления проектами [6]. Последняя версия документа вышла в 2000 г. и тогда же получила статус стан­дарта американского института стандартизации ANSI (хотя стан­дарты ANSI (American National Standards Institute) и IEEE (Institute of Electrical Electronic Engineers) формально считаются американ­скими, большинство из них носит де-факто международный ха­рактер). Важной особенностью РМВоК является то, что он рас­сматривает управление проектами в общем смысле, без привязки к конкретным предметным областям, таким как информацион­ные технологии, и потому не может применяться самостоятель­но — ниже мы рассмотрим, какой эффект дает его использова­ние совместно с ISO 9000.

RUP (IBM Rational Unified Process) — это методология процесса создания ПО, разработанная фирмой Rational и содержащая деталь­ные рекомендации по организации работы в крупных софтверных проектах, структурированию команды разработчиков, построе­нию документооборота и т. д. — вплоть до оформления исходных текстов программы на различных языках программирования.

Методология RUP позволяет объединить проектную команду, предоставляя в ее распоряжение проверенные мировой практи­кой лучшие подходы к разработке ИС. К ним относятся такие процессы жизненного цикла создания ПО, как управление про­ектами, бизнес-моделирование, управление требованиями, ана­лиз и проектирование, тестирование и контроль изменений. Внедрение RUP в организации способствует выработке каче­ственных внутрикорпоративных стандартов и повышению общей культуры разработки. RUP фокусирует внимание не на создании большого количества бумажных документов, а на развитии и при­менении визуальных моделей — семантически богатых представ­лений разрабатываемой ИС. RUP сосредоточивает внимание на создании и дальнейшем развитии надежной и гибкой архитекту­ры, которая облегчает параллельную разработку, минимизирует необходимость изменений, увеличивает возможность многократ­ного использования и надежность эксплуатации системы. Подоб­ная архитектура применяется для планирования использования программных компонентов и управления их развитием. Методо­логия RUP создавалась с прицелом на поддержку управления ка­чеством в рамках требований SEI CMM/CMMI. """

SWEBoK (официальное название — Guide to the Software Engi­neering Body of Knowledge) — совместный проект международных профессиональных обществ АСМ и IEEE Computer Society. Основная идея проекта аналогична РМВоК и заключается в со­здании некоторого базового набора общепринятых знаний, не­обходимых любому профессиональному программисту. Такой набор не включает в себя материалы, относящиеся к другим об­ластям (например, компьютерные науки или информационные системы), а также не содержит материалов, посвященных конк­ретным технологиям.

UML (Unified Modeling Language) — самый известный из су­ществующих стандартов в области ИТ. С момента своего появле­ния в 1994—1996 гг. этот язык моделирования быстро набирал по­пулярность и к сегодняшнему дню стал Lingua franca* в области проектирования информационных систем и бизнес-анализа. Можно с уверенностью сказать, что знание языка UML является необходимым условием для успешной работы в качестве ИТ-специалиста. Стандартизацией UML занимается влиятельный международный консорциум OMG (Object Management Group). Последняя стандартизованная версия UML имеет номер 1.5, одновременно ведется активная работа над принципиально но­вой версией 2.0. Существуют тысячи книг, описывающих процесс моделирования систем с помощью UML, так что изучение этой нотации и сопутствующих ей методов не является проблемой.

Tick-IT — это схема сертификации систем качества для про­граммного обеспечения, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики.

Особенность Tick-IT в том, что он сам базируется на стандартах серии ISO 9001 и ISO 12207 (см. рис. 1.1), но кроме требований ISO 9001 включает и набор требований и практики из стандартов ISO 12207 «Жизненный цикл ПО» и ISO 9000-3 «Руководство для

* Наиболее распространенный язык международного общения. внедрения ISO 9001:94 для разработки, установки и поддержки ПО». Преимуществом данной модели является в первую очередь то, что данный стандарт представляет собой достаточную систе­му, по которой можно не просто проверять, асамое главное дей­ствительно разрабатывать систему качества. Также важным пре­имуществом является то, что, разрабатывая систему качества по Tick-IT, мы также построим полностью ISO 9001 совместимую компанию. К недостаткам Tick-IT можно отнести только неширокое распространение данного стандарта и, как следствие, не-достаточное его признание в мире.

Согласно схеме Tick-IT могут быть сертифицированы систе­мы обеспечения качества предприятий, занимающихся следу­ющими видами деятельности:

• разработка программного продукта или услуги как для внеш­него заказчика, так и для внутреннего использования, вклю­чая встроенное (embedded) ПО;

• копирование, архивирование, хранение данных и ПО;

• системная интеграция, поддержка, администрирование.

Создание такой специальной схемы было вызвано особенно­стями индустрии ПО, которые требуют специальной подготовки аудиторов и интерпретации стандартов ISO 9000. Гибкая инфра­структура Tick-IT позволяет схеме следовать изменениям в этой весьма динамичной отрасли, тем самым обеспечивая постоянное совершенствование.

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

Теперь рассмотрим специальные методологии внедрения го­товых программных средств (ПС), требования к которым тоже содержатся в ISO 9001.

AIM (Application Implementation Method) — методология «Вне­дрение приложений» направлена на управление проектами максимально быстрого и высококачественного внедрения приложе­ний Oracle Applications. AIM регламентирует все основные ста­дии ведения проекта от этапа определения целей и стратегии до сопровождения новой системы, ASAP (Accelerated SAP) — мето­дология «быстрого» внедрения ИС ERP-класса SAP R/3, разра­ботанная ее производителем — корпорацией SAP AG с учетом лучшей практики ее внедрения.

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

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

Эти методологии уже содержат все необходимые действия по обеспечению качества в соответствии с ISO 9001 и базируются на ЖЦ внедрения ПС (SWP — Software Process — процессы разра­ботки ПС) в соответствии с RUP и ISO 12207.

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

А теперь, поняв «кто есть кто», снова посмотрим на рис. 1.1. Комплексное решение задач обеспечения качества программ­ных средств предполагает разработку и внедрение той или иной системы управления качеством. В мировой практике наибольшее распространение получила именно система, основанная на меж­дународных стандартах серии ISO 9000, потому что она опреде­ляет общие требования (и к ПС в том числе), тем самым в целом предопределяет ту стадию зрелости процессов, которая соответ­ствует многим отраслевым моделям и стандартам в ИТ

На вопрос, гарантируют ли внедрение системы качества и ус­пешная сертификация выпуск качественного продукта, следует ответить, что все-таки нет. Подчеркивая, что ISO 9000 — «пре­восходная идея», компания Gartner Group рекомендует рассмат­ривать сертификацию на ISO 9001:2000 только как исходную точ­ку на пути к качеству.

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

Представляется целесообразным провести анализ баланса не­обходимого и достаточного во всех этих основных моделях СМК.

Проведем его в следующих координатах (рис. 1.2):

• степень регламентируемости процессов разработки, обозна­чим это понятие — RP;

• вероятность достижения запланированных результатов, обо­значим это понятие — PQ.

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

Выражаясь математическим языком, величина производной F(Q) = dPQ: dRQ (прирост эффективности в достижении каче­ства dPQ при приросте затрат рабочего времени на поддержку вы­полнения требований dRQ) уменьшается в следующей последо­вательности: ISO 9000, СММ, CMMI.

Рисунок 1.2 наглядно и просто объясняет:

• популярность именно модели ISO 9000;

• правильность методики: сначала ISO, и только потом, при необходимости, СММ;

• определенный скепсис в отношении эффективности моде­ли CMMI.

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

• разработать и внедрить СМК по модели ISO 9001:2000. Ведь большинство компаний, которые сейчас находятся на 4-м и 5-м уровнях SW-CMM, сначала прошли через при­ведение своих процессов в соответствие модели ISO. Как показывает практика, это оптимальный вариант в плане управления развитием системы менеджмента качества и сни­жения рисков;

• начать разрабатывать и внедрять ключевые процессы моде­ли SW-CMM.

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

Рассмотрим, как соотносятся требования уже популярного стандарта ISO 9001:2000 с общими свойствами становящейся все более популярной модели СММ [7] (табл. 1.2).

Каждый уровень СММ, как уже упоминалось, характеризуется набором областей ключевых процессов (Key Process Areas — КРА).

Таблица 1.2 Соответствие между общими свойствами СММ и элементами ISO 9001:2000 Достижение всех целей в рамках КРА для определенного уров­ня СММ определяет соответствие организации данному уровню. Если хотя бы одна цель хотя бы одна КРА для уровня СММ не достигнута, то организация не может соответствовать данному уровню СММ. КРА можно разбить на три категории: управля­ющие, организационные и обеспечивающие (табл. 1.3).

СММ не определяет все процессы, имеющие отношение к раз­работке программного обеспечения; в ней выделяются необхо­димые для достижения уровня СММ, они и включаются в КРА. Каждая КРА разбивается на 5 общих свойств (Common Features):

• обязательство выполнить (Comment to Perform);

• способность выполнить (Ability to Perform);

• выполняемые действия (Activities Performed);

• измерение и анализ (Measurement and Analysis);

• проверка реализации (Verifying Implementation).

Модель SW-CMM	Модель ISO 9000:2000
(Зрелость процессов	(Система менеджмен-
производства ПО)	та качества)
Уровни улучшения качества
Уровень 5. Высокая оптимизации	8. Измерение, анализ
(Optimizing).	и улучшение:
Управление изменением процессов	8.1. Планирование.
(Process Change Management).	8.2. Измерение и мони-
Управление изменением технологии	торинг.
(Technology Change Management).	8.3. Управление несо-
Предотвращение дефектов	ответствиями.
(Defect Prevention)	8.4. Анализ данных для улучшения. 8.5. Улучшение
Уровень 4. Управляемость (Managed).
Управление качеством ПО
(Software Quality Management).
Управление процессами через
количественные оценки
(Quantitative Process Management)
Уровни обеспечения качества
Уровень 3. Начало оптимизации	5. Ответственность ру-
(Определенность) (Defined).	ководства.
Выявление дефектов на ранних стадиях	б. Управление ресур-
(Peer Reviews).	сами.
Координация совместной работы групп	7. Реализация про-
(Intergroup Coordination).	дукции:
Проектирование ПО (Software Prod-	7.1. Планирование соз-
uct Engineering).	дания продукции.
Общее управление ПО (Inte-	7.2. Процессы, связан-
grated Software Management).	ные с потребителем.
Программа обучения персонала	7.3. Проектирование
(Training Program).	и разработка.
Создание формальных моделей	7.4. Закушен.
организационных процессов	7.5. Деятельность по
(Organization Process Definition).	производству и обслу-
Организация работы внутри групп	живанию продукции
(Organization Process Focus)
Модель SW-CMM	Модель ISO 9000:2000
(Зрелость процессов	(Система менеджмен-
производства ПО)	та качества)
Уровни обеспечения качества
Уровень 2. Контроль (Повторяемость)
(Repeatable).
Управление конфигурацией (Soft-
ware Configuration Management).
Обеспечение качества ПО
(Software Quality Assurance).
Управление субконтрактами
(Software Subcontract Management),
Контроль за ходом выполнения проектов
(Software Project Tracking and Oversight).
Планирование проектов
(Software Project Planning).
Управление требованиями
(Equirements Management)
		Модель SW-CMM
	(Зрелость процессов производства ПО)
	Управляющие	Организационные	Обеспечивающие
	(Management)	(Organizational)	(Engineering)
		Управление измене­ниями процессов (Process Change Management). Управление измене­ниями технологий (Technology Change Management)	Предотвращение дефектов (Defect Prevention)
	Управление процес­сами через количест­венные оценки (Quantitative Process Management)		Управление качест­вом ПО (Software Quality Management)
	Координация совмест-	Программа обучения	Выявление дефек-
	ной работы групп	персонала (Training	тов на ранних ста-
	(Intergroup	Program).	диях (Peer reviews).
	Coordination).	Создание формаль-	Проектирование ПО
	Общее управление	ных моделей органи-	(Software Product
	ПО (Integrated Software Management)	зационных процес­сов (Organization Process Definition). Организация работы внутри группы (Organization Process Focus)	Engineering)
	Управление конфигу­рацией (Software Configuration Management). Обеспечение качества ПО (Software Quality Assurance). Управление субконтрактами
	Модель SW-CMM
(Зрелость процессов производства ПО)
Управляющие	Организационные	Обеспечивающие
(Management)	(Organizational)	(Engineering)
(Software Subcontract
Management).
Контроль за ходом
выполнения проектов
(Software Project
Tracking and
Oversight).
Планирование проек-
тов (Software Project
Planning).
Управление требова-
ниями (Requirements
Management)

Таблица 1.3 Категории ключевых процессов СММ

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

Последовательное выполнение общих свойств фактически реа­лизует цикл улучшения процессов качества потенциала компа­нии (КПК), то есть непрерывное улучшение бизнес-процессов (рис. 1.3).

Теперь несколько практических рекомендациий.

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

В результате такого форсирования событий у организации, например получившей сертификат по ISO 9000:2000, определен только минимально необходимый набор процессов для соответ­ствия ISO 9001, а не все процессы, которые требуются компании для эффективного функционирования. К тому же уровень дета­лизации процессов недостаточен для четкого понимания того, что творится внутри процессов и кто за какие задачи внутри процес­са отвечает.

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

И действительно, когда выступаешь в роли независимого ауди­тора, очень сложно доказать, что принятый уровень детализации процесса явно недостаточен для эффективного функционирова­ния системы качества компании. Но и доказать обратное за вре­мя, которое выделяется на аудит по ISO 9000, крайне сложно (этим очень успешно можно пользоваться при оппонировании аудитору). Практика показывает, что быстро построить эффек­тивные процессы даже 3-го уровня зрелости (так же, по-хороше­му, как и процессы на основе ISO 9000) невозможно.

Для того чтобы этого добиться, недостаточно просто описать процессы с учетом требований выбранной модели. Самая глав­ная сложность заключается в том, что необходимо перепроектировать культуру производства внутри организации. И добиться этого волевым решением руководства н евозможно. Именно по­этому подход, который определен в СММ, просто более жизне­способен и реалистичен, чем в моделях ISO 9000.

Экспертная оценка степени покрытия ключевых процессов СММ требованиями ISO 9000:2000, в соответствии с оценкой самих авторов СММ [6], показана в табл. 1.4.

Таблица 1.4 Экспертная оценка степени покрытия ключевых процессов

СММ требованиями ISO 9000:2000

Модель SW-CMM (Зрелость процессов производства ПО)	Модель ISO 9000:2000 (Система менеджмента качества)
Уровень	Область ключевых процес­сов (Key Process Areas)	Обеспечива-емость, %	Возможность, %
	Управление изменением про­цессов (Process Change Management)
Управление изменением тех­нологии (Technology Change Management)
Предотвращение дефектов (Defect Prevention)
	Управление качеством ПО (Software Quality Management)
Управление процессами че­рез количественные оценки (Quantitative Process Management)	0(50)	40 (100)
	Выявление дефектов на ран­них стадиях (Peer Reviews)
Координация совместной ра­боты групп (Intergroup Coordination)
Модель SW-CMM (Зрелость процессов производства ПО)	Модель ISO 9000:2000 (Система менеджмента качества)
Уровень	Область ключевых процес­сов (Key Process Areas)	Обеспечива-емость, %	Возможность,%
	Проектирование ПО (Software Product Engineering)
Общее управление ПО (Integrated Software Management)	0(50)	30(100)
Программа обучения персо­нала (Training Program)
Создание формальных моде­лей организационных про­цессов (Organization Process Definition)	0 (50)	40(100)
Организация работы внутри групп (Organization Process Focus)	0 (50)	30(100)
	Управление конфигурацией (Software Configuration Man­agement)	70 •
Обеспечение качества ПО (Software Quality Assurance)
Управление субконтрактами (Software Subcontract Management)
Контроль за ходом выполне­ния проектов (Software Project Tracking and Oversight)	30 (90)	60(100)
Планирование проектов (Software Project Planning)	40 (90)	70 (100)
Управление требованиями (Equirements Management)

Собственно оценка проводилась по двум координатам:

• степень обеспечиваемости (в процентах) соответствия про­цессов разработки (SWP) уровню зрелости в рамках СММ — обеспечиваемость;

• степень возможности (в процентах) такой обеспечиваемости, которую дает ISO 9000:2000, — возможность.

Как видно из приведенных данных [7], требования ISO 9000:2000 создают реальную возможность для достижения даже верхнего (СММ Level 5) уровня зрелости SWP.

Однако в смысле уже обеспечения зрелости SWP хотя бы тре­тьего (СММ Level 3) уровня СМК по модели ISO 9000:2000 необ­ходимо немного усовершенствовать: разработать и внедрить еще две организационные процедуры (Organization Process Definition and Focus) и процедуру общего управления (Integrated Software Management), что не представляют сложности для любой ИТ-компании (см. табл. 1.4).

Но можно и нужно пойти дальше (СММ Level 4) — например, в скобках (см. табл. 1.4) показана авторская оценка (обеспечива­емое™ и возможности), которая соответствует СМК по модели ISO 9000:2000, в которой процессный ландшафт СМК дополнен процедурами управления проектами в соответствии с требования­ми РМВоК — это может существенно увеличить зрелость еще таких SWP, как:

• контроль за ходом выполнения проектов (Software Project Tracking and Oversight);

• планирование проектов (Software Project Planning);

• общее управление (Integrated Software Management);

• управление процессами через количественные оценки (Quan­titative Process Management).

Как видно из табл. 1.4, модель СММ по заложенным в ней принципам очень близка к СМК, построенной по стандарту

ISO 9001:2000 и дополненной процессами управления проекта­ми в соответствии с РМВоК

Для того чтобы не делать лишней работы при одновременной сертификации по ISO 9000 и последующей оценке по СММ, я рекомендую при определении производственных процессов про­ектной компании включить (а может, ими и ограничиться) в их число все необходимые в модели СММ КРА. Таким образом, ком­пания одновременно:

• выполняет требования ISO 9001:2000 по внедрению про­цессного подхода;

• документирует все необходимые СММ процессы (КРА);

• реализует при этом ряд таких важных требований ISO 9001:2000, как:

— управление процессами на основе метрик (Quantitative Process Management);

— управление поставщиками на основе управления субкон­трактами (Software Subcontract Management);

— анализ требований потребителей на основе управления требованиями (Requirements Management);

— управление человеческими ресурсами на основе програм­мы обучения персонала (Training Program);

— управление коммуникациями на основе создания фор­мальных моделей организационных процессов (Organi­zation Process Definition);

— реализует механизм улучшения (Plan-Do-Check — Action) всех описанных процессов (SWP) посредством последо­вательной реализации всех пяти Common Features.

Важно понять, что и СММ, и ISO 9001:2000 — всего лишь инструменты для непрерывного улучшения деятельности пред­приятия. Сертификация по стандарту ISO 9001:2000 и подтверж­дение сертификата должны способствовать росту качества процессов организации, где критерий оценит роста качества процес­сов — выход предприятия на новый уровень КПК.

Рассмотрим теперь самые важные особенности проектного биз­неса.

Особенности проектного бизнеса

Проектно-ориентированная компания — это компания, осу­ществляющая свою деятельность преимущественно в проектной форме. А это значит, что каждый проект уникален и ни о каком конвейере речи быть не может.

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

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

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

Рис. 1.4. Системный подход к построению бизнес-модели

проектной компании*

* Форматы моделей даны в соответствии с функци ональностью сред ы ARIS.

цикл выполнения проекта и выполняющиеся последовательно, и поддерживающие БП, обеспечивающие функционирование биз­нес-системы и сопровождающие создание проектного продукта на всем его протяжении.

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

БП в проектно-ориентированной компании и осуществляют­ся в соответствии с принятыми в этой компании стандартами управления проектами. Напомним, что по общепризнанной ме­тодологии PMI (Project Management Institute) — РМВоК 2000 [6] процессная модель проекта включает несколько стандартных ста­дий (инициализация, планирование, выполнение, контроль, за­вершение), каждая из которых предполагает выполнение опре­деленных функций, связанных с управлением временными и стоимостными параметрами проекта, с управлением рисками, проблемами, контрактами, качеством и т. д. [4, 6].

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

Главной особенностью БП проектно-ориентированной компа­нии являются стандартная структура процессов выполнения про­екта (этапы проекта) и стандартные ограничения (срок, себестои­мость, персонал). Именно эти стандартные ограничения по времени и стоимости реализации проектов и по качеству резуль­татов и могут быть использованы для построения интегрального (обобщенного) показателя, характеризующего БП проектно-ори­ентированной компании через оценку возникающих отклонений (рис. 1.5).

ь⁷ Таблица 1.5

Метрики проектной деятельности для последующего расчета КПД

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

Рассмотрим еще одну важную особенность проектного биз­неса.

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

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

Рассмотрим вопросы создания мотивации персонала проект­ной компании.

Создание мотивации проектной команды

Можно даже сформулировать лозунг: «В проектном бизнесе персонал решает все!»

Поэтому HR должен внедрить стратегию удержания ключевых сотрудников — носителей этих ценных знаний и опыта.

В компаниях с 10-летним и более опытом работы, особенно в ИТ, просто опасно выстраивать долгосрочную личную эффектив­ность людей на монопольном решении их прямых руководителей.

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

есть получится, что это были люди не компании, а конкретного руководителя.

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

Основная идея лежит в ведении показателя «Личный рейтинг сотрудника».

Личный рейтинг сотрудника (ЛРС) должен зависеть по край­ней мере от двух основных показателей:

• от его реальной утилизации (например, за год) — это уже используемый в компании показатель U;

• от его потенциала: знаний и опыта их реализации — обо­значим такой показатель NC (расшифруем ниже).

Алгоритм определения ЛРС представлен на рис. 1.6. Теперь рассмотрим петлю качества для понятия ЛРС (рис. 1.7). Показатель личного рейтинга для сотрудников проектных под­разделений предлагается в виде формулы.

RU— (Суммарная занятость в проектах за год в ч/д):: (Календарное рабочее время за год в ч/д) х (Коэффициент личного опыта и специализаций сотрудника). Или

RU = (Tn: 7р) xNC=Ux NC,

где: U= Т п: Тр— утилизация сотрудника;

Т п— суммарная занятость в проектах в ч/д;

Тр — календарное рабочее время в ч/д;

NC— коэффициент опыта и специализаций, которыми владеет

сотрудник.

Примечание:

М — число специализаций сотрудника;

N — число проектов, где эти специализации были востребованы.

Для представленной МЗО коэффициент NC будет определяться следующим образом:

NC=(M * N) =6*9 = 54.

* Статус подтверждения — это либо подпись руководителя департамента (ПРД), либо наличие сертификата.

Область знании	Специализа­ция знании	Статусподтвер;кденпя	Количество проектов с опытом примснснил
Управление проектами	Руководитель проекта	Сертификат
Функциональность системы SAP	Модуль FI	Сертификат
Функциональность системы SAP	Модуль СО	Сертификат
Моделирование БП	ARIS	Подпись руководителя департамента (ПРД)
Моделирование БП	BP Win	ПРД
Бухгалтерский учет	GAAP	Сертификат
Итого М	= 6	Итого N = 9

Таблица 1.6

Расчет NC МЗО (Иванов Иван Иванович, U = 60 % за год)

Расчет коэффициента N