Парадигма управления качеством, как способ организации производства, появилась давно. Идеи, заложенные в группе стандартов ISO9000 Наиболее распространенные стандарты в области управления качеством , уходят корнями, в частности, и в такие "советские" изобретения, как поддержка рационализаторских предложений, наставничества и др.
В современной концепции процессно-ориентированной организации бизнеса процесс непрерывного совершенствования качества занимает одну из ключевых позиций.
Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.
SEI (Software Engineering Institute – Институт программной инженерии) - http://www.sei.cmu.edu. Научно-исследовательский институт, созданный на базе университета Карнеги-Меллона в Питсбурге в рамках деятельности комиссии Министерства обороны США по исследованию проблем, возникающих при разработке программных продуктов в организациях министерства. Наиболее значимые и известные продукты деятельности института – модели зрелости предприятия программной инженерии CMM, CMMI.
EPC SEI Capability Maturity Model - Integrated [for Software Engineering and Systems Engineering] – модель зрелости для программной и системной инженерии –. http://www.sei.cmu.edu/reports/10tr033.pdf, созданная в развитие модели CMM. Унаследовав от CMM описание пяти уровней зрелости организации, дополнительно определяет 22 процессные области (группы процессов программной инженерии). Набор моделей CMMI включает три модели: CMMI for Development (CMMI-DEV) (http://www.sei.cmu.edu/reports/10tr033.pdf), ориентированная на организации, занимающиеся разработкой программного и аппаратного обеспечения, а также комплексных систем; CMMI for Services (CMMI-SVC, http://www.sei.cmu.edu/reports/10tr034.pdf, ориентированная на сервисные службы и CMMI for Acquisition (CMMI-ACQ), ориентированная на организации, приобретающие IT-продукты и услуги. Все они имеют номер 1.3 (ноябрь 2010 года).
Модели совершенствования
ISO9000
Активное внедрение методов управления качеством на Западе началось в начале 1960-х годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous Process Improvement) и TQM (Total Quality Management) [14.1]. Подъем экономики послевоенной Японии во многом был обусловлен идеями, заложенными в TQM.
Качество - термин, который для одних означает необходимость делать то, что желает потребитель, для других - то, что отвечает его потребностям. Менеджмент качества, как он определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если им известно то, чем они занимаются. [14.1].
Поэтому прежде, чем приступить к какому-либо действию, следует получить ответы на вопросы: что нужно делать, кто будет проверять сделанное, как это нужно делать и как определить, что работа завершена? Необходимо также продумать, как вы собираетесь управлять данным процессом и как его можно усовершенствовать.
Основные принципы ISO9000:
Концентрация на потребностях заказчика;
Активная лидирующая роль руководства;
Вовлечение исполнителей в процессы совершенствования;
Реализация процессного подхода;
Системный подход к управлению;
Обеспечение непрерывных улучшений;
Принятие решений на основе фактов;
Взаимовыгодные отношения с поставщиками.
Безусловное достоинство стандартов этой группы связано с тем, что они апробированы на множестве предприятий мира. Однако рекомендации данных стандартов носят достаточно общий характер и не учитывают специфику предприятий отрасли IT. Для этого были разработаны специализированные подходы, рассмотренные ниже.
SEI-CMM, SEI-CMMI
Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон.
Назначение стандарта - оценка уровня "зрелости" (maturity levels) организации - разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий (подробнее см. в [14.2-14.3]). Данный стандарт получил широкую известность, значительное количество западных IT-компаний сертифицировано по CMM.
В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем [14.3].
CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation) соответствует структуре SW-CMM с небольшими уточнениями наименований уровней. Пять уровней зрелости содержат 22 области технологических процессов, показанных в таблице 14.1. (CMU/SEI, 2000а). Непрерывное представление (continuous representation), содержит другой взгляд: те же 22 области структурируются по 4 категориям: управление процессами, управление проектами, конструирование и поддержка (CMU/SEI, 2000b).
В непрерывном представлении вместо уровней зрелости определяются шесть уровней способностей (capability levels) для каждой области технологических процессов. Это представление позволяет каждой организации решать, какой уровень способностей ей соответствует в каждой из 22 областей технологических процессов.
Как и в CMM, в рассматриваемом стандарте на уровне 2 имеется область, именуемая "Управление требованиями", но, в отличие от предыдущего стандарта, на уровне 3 есть и отдельная область "Разработка требований". Размещение этой области на уровне 3 не подразумевает, что требования для проектов организации, не достигших уровня 2, собирать и документировать не нужно. Управление требованиями рассматривается как способ, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований [14.3].
|
Уровень зрелости
|
Название
|
Области процессов
|
|
1
|
Начальный
|
(нет)
|
|
2
|
Управляемый
|
Управление требованиями
Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерения и анализ Обеспечение качества процессов и продуктов Управление конфигурацией
|
|
3
|
Определенный
|
Разработка требований Техническое решение Интеграция продуктов Верификация Валидация Концентрация внимания на процессе Определение процесса организацией Организационное обучение Интегрированное управление проектом Управление риском Анализ и разрешение вопросов
|
|
4
|
Количественно управляемый
|
Производительность организационных процессов Количественное управление проектом
|
|
5
|
Оптимизирующий
|
Организационные нововведения и их развертывание Случайный анализ и разрешение
|
Область процессов "Управление требованиями"
Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование (одно из ключевых свойств требований) включено в рассматриваемую область процессов. В стандарте обсуждаются следующие качества трассирования:
обеспечение записи источников низкоуровневых или вторичных требований;
трассирование каждого требования вниз, к вторичным требованиям, и его размещение по функциям, объектам, процессам и исполнителям;
установка горизонтальных связей между требованиями, принадлежащими к одному типу.
Область процессов "Разработка требований"
В CMMI-SE/SW описаны три набора приемов разработки требований:
приемы, определяющие полный набор требований клиентов, которые затем используются для разработки требований для продукта (выявить нужды заинтересованных в проекте лиц; преобразовать нужды и ограничения в требования клиентов);
приемы, определяющие полный набор требований для продукта (установить компоненты продукта; разместить требования по компонентам продукта; определить требования к интерфейсу);
приемы получения вторичных требований, понимания требований и их подтверждения (установить оперативные концепции и сценарии; определить требуемую функциональность системы; проанализировать вторичные требования; оценить стоимость, сроки и риск создания продукта; утвердить требования).
Как в СММ, так и в CMMI формулируются цели, к которым проект или организация по разработке ПО должны стремиться в различных областях процессов. В них также рекомендуются технические приемы, помогающие достичь этих целей.
CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14.1).
(рис 14.1)
Принципы совершенствования
В [14.3] сформулированы следующие принципы совершенствования качества программных систем:
поэтапность,
непрерывность,
цикличность,
наличие стимула,
ориентация на цели,
проектный подход.
Мероприятия по совершенствованию процессов следует вводить поэтапно. Людям нередко бывает тяжело отказываться от старых привычек, привыкать к новому. Предложенные изменения должны пройти проверку опытом; не все из предложенного обязательно даст эффект, какие-то новации придется пересмотреть, от чего-то - отказаться.
Непрерывность - один из ключевых принципов управления качеством: часто мероприятия проводятся в виде кампании, которая затухает после получения сертификата. Организация, которая стремится к лидерству, должна поддерживать "дух качественной работы" постоянно.
Бизнес-процесс улучшения требований характеризуется цикличностью (см. Процесс совершенствования): его основные этапы повторяются на все более высоком уровне. Циклы оптимизации в софтверных организациях удобно приурочивать к проектам, выполняемых в рабочих группах. Анализ недостатков целесообразно производить тогда, когда они в "оперативной памяти" группы проекта, например - один раз в середине проекта и один - сразу после его окончания. Каждый проект по-своему уникален и несет в себе потенциал для улучшения процессов.
Основным стимулом к изменениям К.Вигерс считает трудности, с которыми столкнулась команда проекта, например:
разработчики не уложились в график, потому что непонятные и неоднозначные требования попали к ним поздно;
разработчикам пришлось много работать сверхурочно, потому что непонятные или расплывчатые требования были уточнены слишком поздно в процессе разработки;
попытка тестирования системы не удалась, потому что тестировщики не понимали, что продукт должен делать;
нужная функциональность была реализована, но пользователи не удовлетворены вялой производительностью, неудобством работы или другими недостатками качества продукта;
организации пришлось пойти на высокие расходы на сопровождение, потому что клиентам потребовалась масса дополнительных функций, которые следовало определить во время составления требований;
организация-разработчик ПО приобрела плохую репутацию поставщика продуктов, которые не нравятся клиентам.
Изменения технологических процессов должны быть целеориентированы. Примеры целей:
уменьшение объема работы, вызванного проблемами с требованиями;
повышение точности планирования и реалистичности планов;
снижение (исключение) числа ситуаций появления новых требований на финишных этапах проекта.
Действия по совершенствованию процессов должны планироваться, контролироваться и управляться, как мини-проекты. Это упрощает выделение требуемых ресурсов, отслеживание перемен и оценки результативности изменений.
Процесс совершенствования
На рис. 14.2 показан типовой цикл совершенствования процессов при создании программного обеспечения [14.3].
(рис 14.2)
Оценка текущих приемов
В соответствии с принципом целенаправленности, в работы по совершенствованию необходимо начать с формулировки целей и оценкой, насколько существующие процессы соответствуют данным целям. Для целей оценки применимы известные в бизнес-моделировании и анализе требований методы и приемы: от проведения интервью и постановочных семинаров до фиксации модели "Как есть".
Эффективным способом является привлечение внешних консультантов, которые могут составить непредвзятый взгляд на положение в вашей компании.
Результатами оценки является список обнаруженных сильных и слабых сторон в текущих процессах, а также, начальные рекомендации по совершенствованию (переходу к модели "Как надо").
Планирование
В соответствии с принципом проектного подхода к проведению мероприятий по совершенствованию, для мини-проекта совершенствования необходимо проделать все то, что обычно делается при инициации проектов: осуществить декомпозицию работ; выделить ресурсы, назначить исполнителей; создать планы работ.
Стратегический план описывает общую программу совершенствования процессов в вашей организации. Тактические планы действий затрагивают конкретные области совершенствования, например процесс сбора требований или процедуру назначения приоритетов [14.3]. В каждом плане действий должны быть указаны цели действий по совершенствованию, участники и отдельные задачи. План также дает возможность отслеживать выполнение процесса совершенствования, отмечая выполнение отдельных задач.
В плане действий не должно быть более 10 пунктов; срок его реализации не должен превышать 2-3 месяца.
Ниже приведен шаблон декомпозиции задачи управления требованиями [14.3].
составить проект процедуры управления изменениями;
проверить и модифицировать процедуру управления изменениями;
провести пробное испытание процедуры управления изменениями для проекта;
модифицировать процедуру управления изменениями на основе обратной реакции по пробному испытанию;
оценить инструментальные средства выявления проблем и выбрать одно из них для поддержки процедуры управления изменениями;
приобрести выбранное инструментальное средство выявления проблем и настроить его для поддержки конкретной процедуры;
внедрить новую процедуру управления изменениями и инструментальное средство в организации.
Создание и апробация новых процессов
Принцип поэтапности призывает не делать "революций" в совершенствовании процессов. Любая новация, описание которой найдено в литературе, заимствована из опыта коллег или разработана лично вами, должна пройти испытание на вашей команде и ваших проектах. Известный неполиткорректный принцип "что русскому хорошо - то немцу смерть" на языке современного менеджмента IT-проектов звучит, как "учет системы ценностей, принятых в команде разработчиков" [14.5].
Апробация на реальных задачах - единственный гарантированный способ проверить - годится ли тот или иной инструмент для вашей команды. Чтобы не вовлекать в масштабные эксперименты значительные ресурсы существует способ пилотных (пробных) проектов.
К.Вигерс предлагает следующие методические приемы при апробации новых процессов:
выбирайте для участия в пробных проектах людей, которые будут относиться к новым приемам беспристрастно и смогут дать им оценку. Это могут быть как сторонники, так и скептики, но они не должны быть ярыми противниками предлагаемых приемов;
чтобы результаты было легко истолковать, определите количество критериев, по которым команда будет оценивать пробный проект;
определите заинтересованных лиц, которых следует проинформировать о том, что представляет собой пробный проект и почему он выполняется;
подумайте о возможности испытания новых процессов по частям в разных пробных проектах. Так вам удастся вовлечь в испытание больше людей, что увеличивает осведомленность, количество откликов и сторонников;
для более полной оценки поинтересуйтесь у участников пилотных проектов, что бы они почувствовали, если бы им пришлось вернуться к существующим приемам работы.
Оценка результатов и принятие решений
Оценка результатов апробации новых процессов должна показать - достигнуты ли поставленные цели, стоит ли осуществлять широкомасштабное внедрение новаций, апробированных на пилотном проекте, либо "овчинка выделки не стоит".
Среди ключевых вопросов в области оценки результатов можно выделить следующие [14.3].
Насколько гладко прошли пробные проекты и как эффективно они разрешили неопределенности в отношении новых процессов?
Собираетесь ли вы менять что-либо в следующих пилотных проектах?
Как прошло общее внедрение новых технологических процессов?
Удалось ли вам довести до сведения каждого информацию о пользе новых процессов или шаблонов?
Смогли ли участники понять и эффективно применить новые процессы?
Собираетесь ли вы менять что-либо при проведении следующего внедрения?
При оценивании результативности достижения поставленных целей следует различать мероприятия, польза от которых проявляется сразу и те, выгода от которых проявится через значительное время. Необходимо учитывать эффект "кривой обучения" (learning curve) [14.3]: производительность падает, пока люди приспосабливаются к новым способам работы. Кратковременное падение производительности, иногда называемое "лощиной отчаяния" - это часть необходимого вклада, который ваша организация вносит в совершенствование процессов.
Невзирая на все возможные трудности, мероприятия по улучшению качества при внимательном к ним отношении неизбежно приведут к повышению эффективности работы команды.
1. Переход к управлению качеством — это не просто формальность для получения сертификата, а фундаментальный сдвиг в культуре производства, требующий постоянного внимания.
2. Модель CMMI является де-факто стандартом для оценки и повышения зрелости IT-компаний, предлагая структурированный путь от хаоса к предсказуемому и управляемому производству.
3. Качество конечного продукта напрямую зависит от качества работы с требованиями на ранних этапах. CMMI подчеркивает это, выделяя управление и разработку требований в отдельные критически важные области.
4. Внедрение улучшений — это рискованный процесс, сопровождающийся временным падением производительности («лощина отчаяния»), но системный и поэтапный подход позволяет минимизировать эти риски и в итоге достичь поставленных целей.
5. Успех совершенствования качества невозможен без создания системы, включающей оценку, планирование, эксперимент (пилотный проект) и анализ, а также без учета человеческого фактора (сопротивление изменениям, необходимость обучения).
1. В чем заключается принципиальное различие между общими стандартами качества (ISO 9000) и специализированными моделями (CMMI) для IT-сферы?
2. Перечислите пять уровней зрелости организации по модели CMM. Что характеризует первый уровень?
3. Какие три модели включает в себя набор CMMI версии 1.3 и на кого они ориентированы?
4. Чем отличается «Управление требованиями» от «Разработки требований» в модели CMMI?
5. Назовите не менее пяти принципов совершенствования качества программных систем, упомянутых в тексте.
6. Что такое «пилотный проект» и зачем он нужен в процессе совершенствования качества?
7. Объясните термин «лощина отчаяния» (или «кривая обучения») в контексте внедрения новых процессов.
8. Перечислите четыре основных этапа типового цикла совершенствования процессов при создании ПО (согласно рис. 14.2).
