©Michael Diaz и Joseph Sligo,
Подразделение SSTG фирмы Motorola

Переведено БНТП по заказу Interface Ltd.

• Метрики процесса
• Стратегии внедрения
• Экономические выгоды

Многие организации используют или рассматривают модель зрелости процесса разработки ПО (CMM – Capability Maturity Model) как движущую силу улучшения процесса разработки ПО. Но обеспечивает ли CMM реальные выгоды? Авторы предлагают метрики и приводят данные, иллюстрирующие результаты применения CMM в фирме Motorola.

Во многих компаниях модель зрелости процесса разработки ПО играет ведущую роль в определении улучшений этих процессов. Зачастую организации, рассматривающие возможности улучшения процесса разработки ПО (SPI – software process improvement), хотят быть уверенными, что в результате проведения этих мероприятий будут получены ощутимые выгоды. Наборы данных, собранные в разных организациях индустрии разработки ПО, показывают, что улучшение процесса на основе CMM различно в организациях, пошедших на эти улучшения. Фирма Raytheon достигла удвоения производительности и коэффициента возврата инвестиций 7.7 к одному за счет затрат на улучшения. За 1990 год экономия составила 4.48 миллиона долл. при инвестициях в 0.58 миллиона долларов. За период в четыре с половиной года, с середины 1988 и до конца 1992, компания сэкономила 15.8 миллиона долларов за счет устранения затрат на переделки и исправления.

Компания Hughes Aircraft получила от своих инициатив по улучшению процессов коэффициент возврата инвестиций 5 к одному, расчет основан на изменениях индекса затраты/производительность. Это привело к ежегодной экономии около 2 миллионов долларов сверх затрат, произведенных компанией Hughes на улучшение процессов. Военно-воздушная база Tinker недавно определила коэффициент возврата инвестиций на инициативы по улучшению своих процессов как 5 к одному, что привело к экономии в 3.8 миллиона долларов при инвестициях в 0.64 миллиона долларов. Другие источники тоже подтверждают данную тенденцию.

Долгое время Motorola является чемпионом в области применения модели CMM института программной инженерии (SEI – Software Engineering Institute), как движущей силы улучшения процесса разработки ПО. В ноябре1995 года подразделение Government Electronics Division (GED) компании в результате независимой оценки было аттестовано на уровень 4 SEI. В дальнейшем процедуры и положения GED были аттестованы на уровень 5 SEI (без реализации процедуры верификации проекта, относящейся к ключевым областям процессов уровня 5). В Motorola работает около 1500 инженеров, проектирующих и разрабатывающих широкий спектр электронных систем по заказам правительства. Примерно 350 инженеров GED принимают непосредственное участие в разработке ПО. Мы считаем, что долгий путь поддержки улучшения процессов, который прошла наша организация, подтверждает плодотворность внедрения процессов CMM. В результате мы дополнили модель SEI несколькими собственными программами.

Используемые нами метрики для времени цикла, качества и производительности основаны на текущих измерениях примерно 34-х программ, которые находятся на различных стадиях жизненного цикла. Подразделение GED компании Motorola планирует повторно оценить производительность для этих проектов после того, как все они будут завершены.

В подразделении GED компании Motorola каждый проект подвергается ежеквартальной самопроверке SEI. Для проекта определяется оценка в баллах от 1-го до 10-ти для действий ключевых областей процесса (KPA – key process area), которые потом усредняются для каждой из KPA. Любая из KPA, для которой средний балл падает ниже 7-ми, рассматривается как слабое место. Уровень SEI для проекта определяется как уровень, на котором все соответствующие KPA выполняются в полном объеме, т.е. средний балл KPA должен быть больше или равен семи.

GED использует качество, время цикла и производительность для оценки программ разработки, так как наши клиенты ценят эти характеристики. Кроме того, Motorola всегда придает большое значение качеству во всех своих продуктах и процессах: концентрация внимания на качестве в соответствии с методологией Six Sigma (Шесть Сигма) является корпоративной инициативой в течение нескольких лет. Six Sigma представляет собой процесс контроля качества, снижающий частоту возникновения брака до нескольких случаев на миллион. Этот процесс первоначально разворачивался в области производства и затем был распространен на разработку ПО в Motorola.

Недавно корпорация Motorola лидировала с инициативой по сокращению времени цикла 10X, которая предусматривает поиск во всех элементах бизнеса возможностей десятикратного сокращения времени производственного цикла для ускорения выпуска новых продуктов. Производительность напрямую определяет наши возможности выигрывать тендеры по новым программам, проводимые нашим традиционным заказчиком – министерством обороны США, и обеспечивает нам прибыльность при выпуске коммерческих продуктов. Таблица 1 суммирует тенденции подразделения GED фирмы Motorola по улучшению качества, времени цикла и производительности в зависимости от уровня модели SEI. Данные о производительности в этих областях получены фирмой Motorola из собственных метрик и соотнесены с уровнями модели SEI, определенными путем самоаттестации в ходе каждого из проектов. Проекты, для которых проводился анализ, находились на различных этапах процесса разработки.

* Миллионов строк кода в эквивалентных командах языка ассемблера (MAELOC – Million assembly-equivalent lines of code).

Рисунок 1. Распределение качества по уровням модели SEI. Качество определяется через уменьшение количества дефектов процесса (по вертикали – отношение количества дефектов процесса к MAELOC)

Ниже приводится более детальное рассмотрение каждой из метрик, включая эмпирическую методологию, на основе которой метрики были получены. Результаты конкретных улучшений не всегда приводят к повышению уровня зрелости в соответствии-с моделью SEI, так как подразделение GED фирмы Motorola применяет серьезные инициативы по сокращению времени цикла и управлению качеством, лежащие за рамками модели CMM SEI.

Качество. Проблема обнаруженная на том же этапе разработки, когда она появилась, определяется как ошибка. Дефект – это проблема, которая не была обнаружена на этапе, когда она появилась. Метрика качества исчисляется как количество дефектов, отнесенное к миллионам произведенных строк кода в эквивалентных командах языка ассемблера (MEAELOC – million earned assembly-equivalent lines of code). AELOC (assembly-equivalent lines of code) – строки кода в эквивалентных командах языка ассемблера, равны количеству операторов исходного кода умноженному на коэффициент расширения Capers Jones. Произведенные (Earned) AELOC или EAELOC определяются как произведение AELOC и процента завершенности, который равен отношению использованного на разработку бюджета к общему бюджету, необходимому для завершения проекта.

Результаты. На Рисунке 1 представлено значение метрики качества каждого из проектов, соотнесенное с уровнями модели SEI полученными на основе самоаттестации проектов. Так как большинство из рассматриваемых программ все еще находятся в стадии разработки, мы произвели нормализацию показателя путем использования EAELOC.

Анализ. Результаты проектов показывают, что каждый уровень CMM улучшает метрику качества примерно в два раза. Улучшение качества проектов при переходе с уровня 2 на уровень 3 происходит вследствие наличия на уровне 3 процедуры выявления дефектов на ранних стадиях проекта (Peer Review KPA). В программной индустрии выявление дефектов на ранних стадиях проекта повсеместно признается наиболее важным фактором в обнаружении и предотвращении дефектов программных продуктов. Улучшение качества можно ожидать и при переходе с уровня 3 на уровень 4 за счет управления процессами через количественные оценки (Quantitative Process Management) и управления качеством ПО (Software Quality Management). Использование метрик качества, таких как внутренняя эффективность этапа (отношение количества привнесенных и обнаруженных на данном этапе проблем к общему числу проблем, привнесенных на этом этапе) позволяет разработчикам модифицировать их процессы, когда значения наблюдаемых метрик падают ниже установленных в организации контрольных нормативов.

Например, если выявление дефектов на ранних стадиях проекта обнаруживает 75 из каждых 100 проблем, привнесенных на стадии детального проектирования, внутренняя эффективность этапа будет равна 75%. Вы можете оценить количество привнесенных проблем путем использования исторических данных о плотности распределения дефектов для сходных проектов и отслеживания проблем, обнаруженных на предыдущих этапах разработки (Метод прогнозирования количества проблем, привносимых на разных этапах цикла разработки). Норматив подразделения GED фирмы Motorola установлен на уровне 85% для внутренней эффективности этапа. Проекты, для которых этот показатель ниже, подвергаются детальному анализу причин для улучшения процессов выявления дефектов на ранних стадиях и тестирования. Мы считаем что улучшения, связанные с переходом от уровня 4 к уровню 5, происходят за счет введения процедур предотвращения дефектов (Defect Prevention) и управления изменениями процессов (Process Change Management). Проекты, исполняемые на этом уровне, подвергаются анализу Парето для выявления базовых причин возникновения проблем и причинно-следственному анализу для определения изменений процесса, необходимых для предотвращения появления сходных проблем в будущем.

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

Рисунок 2. Распределение времени цикла по уровням модели SEI.
Более короткий цикл приводит к увеличению X-фактора.

Время цикла. Мы определяем X-фактор, или метрику времени цикла, как длительность минимального календарного периода для разработки продукта (базовый проект), деленное на время цикла нового проекта. Например, если базовый проект требует шести месяцев для выполнения, и новый проект был выполнен за два месяца, X-фактор нового проекта будет равен 3. Целью компании Motorola является достижение значения X-фактора равного 10 для новых проектов в течение пяти лет.

Проекты, которые мы использовали в качестве базовых – это сходные проекты, выполненные подразделением GED компании Motorola ранее 1992 года. Для каждого из проектов GED сокращает время цикла путем выбора программы со сходной предметной областью и мониторинга хода проекта в сравнении с базовой программой. Отношение времени цикла текущей программы к базовой определяется как X-фактор программы. Часто завершение программы не находится под полным контролем контрактора, особенно при сокращении правительственных ассигнований. Кроме того, правительственные контракты обычно включают цикл квалификационного тестирования, в общем случае отсутствующий в коммерческих разработках. Для более точной оценки потенциального времени цикла с коммерческой точки зрения, время цикла измеряется до первой задержки в выполнении проекта. Это позволяет устранить вклад влияния квалификационных тестов и изменений в правительственных ассигнованиях на проект и точнее сравнивать деятельность GED фирмы Motorola с деятельностью других, более коммерциализированных, подразделений компании.

Результаты. На Рисунке 2 показаны улучшения времени цикла с учетом уровня модели SEI. Так как X-фактор вычислен путем деления времени исполнения более старого базового проекта на время исполнения текущего проекта, для более коротких проектов X-фактор выше.

Анализ. Анализ “тиары” показывает достижение значения 3.2 для X-фактора при переходе от уровня 1 к уровню 2, неожиданное ухудшение времени цикла при переходе от уровня 2 к уровню 3, повышение X-фактора с 2.7 до 5.0 для проектов при переходе с уровня 3 на уровень 4 и с 5.0 до 7.8 при переходе с уровня 4 на уровень 5. Снижение X-фактора времени цикла для проектов при переходе от уровня 2 к уровню 3 может свидетельствовать о наличии слабой корреляции между эффективностью планирования и уровнем зрелости, которая наблюдалась в других обзорах преимуществ, приносимых CMM. Кроме того, мы обнаружили слабую корреляцию эффективности планирования с уровнем зрелости для уровней выше первого. По меньшей мере, в одном из обзоров такая корреляция не проявлялась.

Тенденция к росту X-фактора времени цикла выше уровня 3 подтверждает предположение, что эффективность планирования выше у проектов с более высоким уровнем зрелости.

Инициатива 10X компании Motorola является самостоятельной и дополняет инициативу по достижению уровня 5 модели CMM SEI. Главной составляющей инициативы 10X является внедрение схемы жизненного цикла, называемой инкрементальной разработкой. Идея заключается в завершении связанной цепочки функций, которая позволяет протестировать все системные интерфейсы и продемонстрировать функциональность, значимую с точки зрения клиента.

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

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

Рисунок 3. Относительная производительность по уровням модели SEI, приведенная к производительности среднего проекта уровня 2. Мы определяем производительность как количество произведенных строк кода в эквивалентных командах языка ассемблера деленное на время, затраченное на их производство.

Производительность. Мы определяем производительность, как объем произведенной работы деленный на время, затраченное на ее выполнение. Эта величина может измеряться в строках исходного кода в час или в других подобных единицах измерения. Для каждого проекта GED компании Motorola производительность отслеживается на основе произведенных AELOC и времени в часах, затраченного на их реализацию.

Результаты. По понятным внутренним причинам, мы не приводим реальных величин количества строк кода в час. Однако Рисунок 3 показывает относительную производительность проектов для разных уровней зрелости. Данные приведены к производительности среднего проекта уровня 2.

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

Неожиданное снижение производительности наблюдается для проектов при переходе с уровня 2 к уровню 3. Это представляется побочным эффектом от требования одновременного выполнения слишком большого количества новых для персонала проекта задач на уровне 3. При становлении уровня 3 внедряются новые процессы, которые существенно влияют на деятельность каждого конкретного члена команды разработчиков. Подобное внедрение новых процессов не так сильно сказывается на более высоких уровнях зрелости процесса разработки. Как и при освоении любой другой новой технологии, очевидно, что необходимо пройти через этап предварительной адаптации, прежде чем получить заметные выгоды в полном объеме. На уровнях 4 и 5 в рамках каждого из проектов проводятся количественные измерения производительности, что позволяет эффективно изменять процессы для управления производительностью.

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

Внедрение SPI в подразделении GDE компании Motorola началось в 1989 году, когда GED было аттестовано на уровень 2 модели зрелости процессов разработки. В то время мы уже реализовали большинство KPA уровня 2, выполняя требования наших правительственных контрактов. Однако, хотя в каждом из проектов, как это требовалось, выполнялись отдельные процедуры уровня 2, реального организационного внимания процессам разработки ПО не уделялось.

Достигнув уровня 2, ведущие программисты GED сконцентрировали свое внимание на улучшении процессов. Стандарты высокого уровня для положений и процедур процессов разработки ПО в GED получили дальнейшее развитие с публикацией руководства по управлению качеством ПО (Software Quality Management Manual). В этом руководстве этапы были расположены в соответствии с типичной для разработки ПО моделью “водопада”, где за анализом требований следует проектирование, вслед за которым идут этапы кодирования и тестирования. В это время была создана рабочая группа по программному обеспечению, которая должна была попытаться унифицировать опыт различных групп компании в форме целостной методологии. Так же была реализована процедура раннего обнаружения дефектов. Эти усилия привели к аттестации GED компании Motorola на уровень 3 в 1992 году.

Рабочие группы. Начиная с 1992 года и вплоть до 1994, инженерные подразделения создавали рабочие группы для улучшения процессов, формируемые из ведущих специалистов-практиков. В дополнение, из восьми ведущих руководителей проектов, отвечающих за разработку ПО, была сформирована первоначальная рабочая группа по улучшению процесса разработки ПО. Менеджер инженерного подразделения, который убедился в ее важной роли для достижения успеха, передал этой группе руководящую роль. Они создали инструментарий для определения метрик кода, которые собирались для большого количества типов произведенных в рамках каждого проекта затрат. Группа так же определила и внедрила метрики для процессов и качества, которые были полезны для каждого из проектов. В конце этого периода, на основе работ проведенных группой, персонал GED создал руководство по управлению процессом разработки и качеством ПО на основе количественных показателей (Handbook for Quantitative Management of Software Process and Quality). В результате этой деятельности GED было аттестовано на уровень 4 модели зрелости процессов разработки ПО, на основе PA1M с целями, добавленными из CMM.

С 1994 года в GED функционирует рабочая группа по предотвращению дефектов, которая собирает данные по подразделениям для выявления системных причин низкого качества продукции. Эта группы разработала руководство по предупреждению дефектов (Defect Prevention Handbook) которое может использоваться в проекте при выполнении процедур предотвращения дефектов в готовой продукции. Группа ведущего программиста была расширена, чтобы обеспечить выполнение всех новых проектов в соответствие с уровнем 5. В рамках каждого проекта производится самоаттестация процедур CMM для определения областей, которые требуют дополнительных работ. В течение этого периода были разработаны и внедрены метрики уровня 5, обеспечивающие целостный подход к сбору метрик из различных источников при проведении процедур уровней 4 и 5 в рамках проекта. Кроме того, GED расширила единую группу из восьми членов до примерно четырех групп, в работе каждой из которых участвует несколько ведущих разработчиков. Ведущие программисты разработали так же руководства по управлению изменениями процессов и управлению изменениями в технологии.

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

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

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

• Концентрируйте внимание на улучшении новых проектов. Очень сложно изменить ход проекта после его старта, особенно на низких уровнях зрелости процессов разработки ПО.
• Применяйте подход сверху – вниз. Перед погружением в детали CMM, начните с тщательного рассмотрения каждой из KPA, так, чтобы Вы могли определить, насколько они соответствуют Вашим условиям.
• Придавайте особое значение производительности, качеству и времени цикла. Избегайте процессов, существующих ради самих себя.
• Поддержка со стороны руководства необходима на всех уровнях: поддержка со стороны высшего руководства недостаточна, если конкретные руководители проектов не следуют тем же принципам.
• Практики и руководители проектов, а не внешние эксперты, должны привлекаться к определению процессов.
• Менеджеры должны быть убеждены в значимости улучшений процессов. Хотя улучшения и не бесплатны, в длительной перспективе они более чем окупаются.
• Заказчик должен быть в курсе текущего состояния процесса, особенно в случаях, когда процесс подвергается изменению.
• Копирование документов о процессах других организаций обычно нецелесообразно. Процесс должен точно соответствовать Вашей организации.
• Преодоление сопротивления изменениям является, вероятно, одной из наиболее сложных ступеней при восхождении по лестнице уровней модели CMM SEI.

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

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

Затраты на улучшение процесса при штате в 350 программистов слагаются из:

• четыре ведущих разработчика на полном окладе = 48 человеко-месяцев;
• руководители проектов в рабочих группах по улучшению процессов = 34 проекта * 1 час в неделю = 10.5 человеко-месяцев;
• предварительная подготовка и завершение каждой фазы проекта: 34 проекта * 1 час на фазу * 7 фаз = 1.5 человеко-месяца;
• планирование разработки ПО: 34 проекта * 5 дней = 1 человеко-месяц; и
• рабочая группа по предотвращению дефектов: 8 членов * 1 час в неделю = 2.5 человеко-месяца.

Расходы на улучшение процессов составили приблизительно 1,5% от общих затрат на содержание нашего штата программистов.

С точки зрения качества, частота внесения дефектов сокращается примерно вдвое при переходе проекта на следующий вышестоящий уровень CMM. Таким образом, у проектов 2-го уровня SEI частота внесения дефектов в восемь раз выше, чем у проектов 5-го уровня SEI. Следовательно, стоимость переделок и исправлений на уровне 2, по меньшей мере, в восемь раз выше. Предполагая, что каждый дефект требует в среднем 16 часов работы по переделке и анализу, и что стоимость работ по переделке составляет примерно $100 в час, для типичного проекта объемом в 500 000 AELOC (около 100 000 SLOC) можно ожидать следующей экономии:

• На уровне 5, 63 дефекта (исходя из 126 дефектов на MAELOC) потребуют затрат в $100 800 на переделку.
• На уровне 2, 445 дефектов (исходя из 890 дефектов на MAELOC) потребуют затрат в $712 000 на переделку.

Типичный проект объемом в 100 000 SLOC будет исполняться примерно 18 месяцев силами 20 программистов. Если разложить 1.5% затрат на улучшение процессов на каждый конкретный проект, эта сумма составит 1.5% * 20 человек *18 месяцев * 167 часов * $100 = $90 180 инвестиций.

В результате окупаемость будет равна ($712 000 – $l00 800) = $611 200 деленные на $90 180 или 677%.

К сожалению, принимая во внимание, что мы в основном имеем дело с правительственными контрактами, подразделение GED фирмы Motorola не может превратить все эту экономию в прибыль. Истинные финансовые преимущества можно получить при досрочном завершении проекта, что позволяет нам перебросить высвободившиеся людские ресурсы на получение и разработку новых проектов.

Каждый уровень зрелости процессов в модели CMM SEI сокращает частоту появления дефектов вдвое. Время цикла и, в меньшей степени, производительность улучшаются с каждым уровнем зрелости за исключением уровня 3, на котором и время цикла и производительность ухудшаются. Исходя из этого, мы можем заключить, что достижение уровня 3 требует внедрения принципиально новых процессов, что может негативно сказываться на этих двух метриках до тех пор, пока разработчики не адаптируются и не научатся работать по-новому. Данные, приведенные здесь, показывают, что достижения уровня 3 организацией – наименее выгодная цель, которая может быть поставлена.

Усилия, прилагаемые при переходе с уровня 2 на уровень 3, вероятно наиболее значительны, так как с уровнем 3 связано большое количество KPA и достижение этого уровня зрелости процессов играет важную роль в SPI. Организации с низким уровнем зрелости приводят различные причины, затрудняющие изменение своих процессов и внедрение SPI.

• Данные об изменениях ключевых процессов и анализ метрик не будут востребованы до достижения уровней 4 и 5 CMM. Эти данные критичны для повышения эффективности усилий по внедрению SPI.
• Организации с низким уровнем зрелости концентрируют внимание на описании своих базовых процессов, а не на их улучшении.
• Организации с низким уровнем зрелости только начинают улучшать свои процессы разработки ПО. Это требует значительных затрат, особенно на первых порах. Препятствием может служить так же скептическое отношение персонала. Перед тем как включиться в новые SPI инициативы, большинство программистов будет выжидать, чтобы посмотреть, действительно ли эти инициативы пользуются поддержкой руководства, и будут пользоваться ею впредь.

Эти доводы показывают, что модель CMM SEI должна быть улучшена за счет введения некоторых аспектов KPA даже на низких уровнях зрелости процессов. Например, некоторые аспекты предотвращения дефектов и улучшения процессов могут исполняться и при низких уровнях зрелости. Модель SPICE (ISO/IEC 15504) может служить примером такого упорядоченного подхода.

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

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме