Основные понятия и значения CMMI

David J. Anderson. David J. Anderson является автором двух книг «Гибкое управление для Software Engineering: Применение теории ограничений для бизнес-результатов» [1], опубликованной в 2003 г. и «Kanban: Успешное постепенное изменение для вашей технологической компании » [2], опубликованной в 2010 г. Он был членом команды, которая создала метод гибкой разработки программного обеспечения, разработки на основе функций в Сингапуре между 1997 и 1999 гг. Он является создателем принципов гибкого управления проектом, изложенных в декларации взаимозависимости от 2005 г. Дэвид создал MSF для улучшения процесса CMMI и выступил соавтором технической заметки из института Software Engineering Institute "CMMI or Agile: Why Not Embrace Both!" [3] Он является вице-президентом консорциума рационального программного обеспечения и систем, http://www.leanssc.org, и руководит международной компанией по консультациям и обучению управлению, David J. Anderson & Associates Inc., http://www.agilemanagement.net помогает техническим компаниям повысить производительность благодаря улучшенным политикам управления и принятию решений.

Январь 2012 г.

Anderson описывает, как такой взгляд на организации под объективом CMMI предоставляет ценные знания для менеджеров, инженеров-технологов и всех внешних заинтересованных лиц, в том числе клиентов, инвесторов, управляющих органов и аудиторов.

Применение

Управление жизненным циклом приложения; CMMI

Introduction

The Meaning of Organizational Maturity

Inspiration for the CMMI Model

CMMI is a Model

Understanding CMMI Made Simple

CMMI Appraisals

Оригинальная модель зрелости способностей (Capability Maturity Model, CMM) впервые была опубликована в 1991 г. Десятилетием позже она эволюционировала в модель CMMI. CMMI сейчас — это семейство, состоящее из трех моделей. В данной статье рассматривается модель CMMI for Development (CMMI-DEV). Система CMM была разработана чтобы помочь министерству обороны США лучше разобраться в дорогостоящих сбоях в проектах разработки программного обеспечения в рамках широкомасштабных программ государственных закупок. Оценка на основе CMM использовалась для указания «пригодности» для заключения контрактов с правительством. Далее это эволюционировало в указанную схему оценки на основе CMMI.

Концепция организационной зрелости остается противоречивой. Как, например, можно оценить зрелость организации? Имеет ли организация по-настоящему поведение, отличающееся от поведения и действий индивидуумов? Концепция того, что организация может быть оценена на определенном уровне зрелости и что это будет показателем способности выполнять надежную работу для правительства, является предметом непрекращающихся споров. Однако я остаюсь сторонником и приверженцем CMMI и верю, что рассмотрение организаций через объектив CMMI предоставляет ценные знания для руководителей, инженеров-технологов и всех сторонних заинтересованных лиц, в том числе клиентов, инвесторов, управляющих органов и аудиторов.

Значение организационной зрелости

Зрелость в CMMI подразумевать подход и возможность оценивать и управлять рисками и суждениями при принятии решения. Термин «зрелость» фактически используется в смысле его общего потребления по отношению к индивидуумам. Например, страховщики могут сообщить нам, что вероятность попадания 18-летних мужчин в дорожно-транспортное происшествие выше, чем у 55-летних женщин. Юноша 18 лет с большей вероятностью будет проявлять недостаточную сознательность при принятии решений об управлении автомобилем, и скорее всего у него нет достаточного опыта для адекватной оценки рисков, связанных с теми или иными действиями. Это может привести к авариям, которых может избежать женщина в возрасте 55 лет. Страховые компании особенно хорошо оценивают риски, поскольку собирают статистику и сопоставляют данные.

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

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

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

Вдохновение для модели CMMI

Оригинальная CMM была разработана Уоттсом Хамфри и впервые появилась (без названия CMM) в его книге "Managing the Software Process"[4]. Воодушевлением послужило движение за обеспечение качества производства в XX веке и работа Иосифа Юрана. Эдвардса Деминга и Филиппа Кросби. Термин «модель зрелости» и 5 уровней внутри нее был воодушевлен моделью зрелости производства Кросби. Однако CMM необходимо рассматривать как истинный синтез идей. Термин «возможность» почти определенно воодушевлен Демингом.

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

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

Поэтому Деминг разработал модель способности в рамках своей системы глубоких знаний, а Кросби разработал модель зрелости. Хамфри пытался синтезировать эти принципы в одно целое и применить их к области проектирования программного обеспечения, и результатом стала модель Capability Maturity Model.

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

Модель CMMI всегда выступала в качестве основы для поддержки развития культуры непрерывного улучшения в рамках организации и всегда предназначалась для создания "думающих" систем. Есть Очень очевидные параллели бережливому подходу в основах CMMI.

CMMI – это модель

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

Модель CMMI состоит из 22 областей процесса плюс три универсальные цели, к которым должны стремиться все организации.

Три универсальные цели — это следующие:

22 области процесса организованы в четыре категории: инжиниринг, управление проектами, управление процессами и поддержка. Каждая область процесса состоит из 1-3 конкретных целей и всех 3 универсальных целей. Ожидается, что для каждой цели обычно существует несколько методик осуществления этой цели. В составе методики, могут быть предложены вложенные методики. CMMI только требует или предписывает цели. Методики, определенные в целях модели CMMI, являются ожидаемыми, но не обязательными. При их отсутствии необходимо заменить их любым аналогичным методом замены. В следующей таблице показано группирование областей процесса:

Организационный фокус	Область процесса
Проектирование	Разработка требований Техническое решение Интеграция продуктов Проверка Проверка
Управление проектами	Планирование проектов Мониторинг и контроль проектов Интегрированное управление проектами Управление соглашениями с поставщиками Управление требованиями Управление рисками Количественное управление проектами
Управление процессами	Фокус организационных процессов Определение организационных процессов Organizational Training Производительность организационных процессов Организационные инновации и развертывание
Поддержка	Управление конфигурацией Контроль качества процессов и продуктов Измерения и анализ Анализ и разрешение решений Анализ и разрешение причин

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

Области процесса также группируются в уровни зрелости, что обеспечивает сокращенный способ описания зрелости. Хотя группирование областей процесса в уровни остается противоречивым на нескольких уровнях, мое наблюдение за организациями за последние 2 десятилетия показало, что текущая версия 1.3 модели (учитывая, что CMMI является фактически версией 2 CMM) является приблизительно правильной. Низкоорганизованные хаотические организации обычно имеют возможности в областях процесса с уровнем 2, прежде чем добиваются возможностей более высокого уровня в областях процесса.

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

Уровень зрелости	Области процесса
5	CAR – Анализ и разрешение причин OPM — управление организационными процессами
4	OPP – Производительность организационных процессов QPM – Количественное управление проектами
3	RD — Разработка требований TS – Техническое решение PI – Интеграция продуктов VER – проверка VAL – проверка IPM – Интегрированное управление проектами RSKM – Управление рисками OPF – Фокус организационных процессов OPD – Определение организационных процессов OT – Организационное обучение DAR – Анализ и разрешение решений Контроль качества процессов и продуктов
2	CM – Управление конфигурацией MA – Измерения и анализ SAM – Управление соглашениями с поставщиками PP – Планирование проектов PMC – Мониторинг и контроль проектов RM – Управление требованиями
1	Нет областей процесса в пределах уровня 1 модели. Уровень 1 представляет неопределенный процесс без самоанализа или возможности определения процесса или повторения результата путем понимания процесса, давшего его. Технически в оценке CMMI организация, которая не удовлетворяет целям по областям процесса в уровне 2 модели, по-прежнему находится на уровне 1 модели. Поэтому организации с формирующимися процессами технически будут по-прежнему рассматриваться как уровень 1 модели, даже хотя они уже давно отошли от хаоса неопределенности.

В следующей таблице простыми словами описано назначение каждой области процесса:

Область процесса	Назначение
CAR – Анализ и разрешение причин	Изучите основную причину проблем исключительного процесса (варьирование специальных причин, Эдвардса Деминга), а также предложить изменения процесса реализации для предотвращения повторения. Внимание направлено на необычное поведение стабильных процессов, рассмотренных в количественном отношении. Ежедневные сюрпризы, скорее всего, будут считаться частью управления рисками (RSKM), а не значениями CAR.
CM – Управление конфигурацией	Будучи не просто системой управления версиями, эта область процесса охватывает все задачи администрирования, связанные с системными средами, конфигурациями компонентов, платформами, ПО промежуточного слоя, приложениями и документацией. Способность успешно выполнить построение и развертывание работающего кода подпадает под эту область процесса.
DAR – Анализ и разрешение решений	Для всех ключевых решений в проекте или разработке продукта укажите, что рассмотрен набор альтернатив или вариантов и для определения пригодности различных вариантов использовались контекстные элементы. Запишите решение и причины выбора.
IPM - Интегрированное управление проектами	Этот второй уровень управления проектом внутри модели CMMI подразумевает, что организация может управлять несколькими потенциально зависимыми проектами одновременно. Часто это достигается с помощью использования программы или офиса управления портфелем.
MA – Измерения и анализ	Сбор данных о процессе, проекте и характеристиках продукта. Получение показателей и индикаторов в виде отчетов на основе данных.
OPD - Определение организационных процессов	Организация должна иметь одно или несколько определений процессов, которые определяются в пределах контекста. Контекст опишет профиль риска. Каждый проект можно оценить по его рискам и определению процесса, выбранного из организационного каталога, а затем соответствующим образом подогнать его.
OPF – Фокус организационных процессов	Организация должна верить, что определение процесса определяет способность и влияет на нее, и что улучшение способности достигается в первую очередь за счет усовершенствованного процесса. Таким образом, организация активно управляет определениями и мониторами своих процессов (используя область процессов PPQA), чтобы гарантировать соблюдение этих определений.
OPM — управление организационными процессами	Эта область процесса инкапсулирует понятие статистического понимания, насколько хорошо процесс работает относительно его ожидаемых возможностей. Если наблюдаемые результаты не соответствуют спрогнозированным базовой моделью процесса при внесенном изменении в определение процесса, можно проанализировать изменения в процессе, предназначенные для улучшения возможностей, и рассмотреть базовую модель процесса. Организация управляет своей производительностью посредством своих процессов для удовлетворения своих бизнес-потребностей.
OPP – Производительность организационных процессов	Эта область процесса инкапсулирует понятие сравнения производительности, обычно называемого «контрольное тестирование». OPP создает модели процесса на основе базовых данных, чтобы включить сравнение. Это дает организации возможность ответить на вопросы такие как "Какую из наших трех команд продуктов нам нужно выбрать для [этого конкретного проекта]?"
Organizational Training	Индивидуальная возможность в определенных случаях важна для производительности процесса и возможностей системы. Хорошо функционирующая система с высокой производительностью будет иметь высокую способность к обучению для уменьшения изменчивости на уровне локальной практики.
Интеграция продуктов	Возможность интеграции нескольких компонентов для формирования целостного продукта и управление необходимыми для этого элементами.
Мониторинг и контроль проектов	Соберите данные о выполняющихся проектах, сравните их с планами, проекциями и моделями и выполните необходимые действия на основе этих данных.
Планирование проектов	Планирование проекты на основе оценок, имитаций и анализа требований.
Контроль качества процессов и продуктов	Главным образом функция аудита соответствия процессу. Предназначено для демонстрации того, что система работает как запланировано. Помогает избежать потенциальных ошибок управления, заключающихся в изменении процесса для устранения проблемы, когда фактически текущий процесс не выполняется, как предусмотрено.
Количественное управление проектами	Это третий и самый высокий уровень управления проектом внутри модели CMMI. Это означает, что статистически достоверные количественные методы используются для планирования, мониторинга и управления проектами.
Разработка требований	Существует определенный, воспроизводимый процесс истребования, обсуждения, анализа и документирования требований.
Управление требованиями	Требования отслеживаются на протяжении всего жизненного цикла проекта, и в идеале существует полная прослеживаемость между поставленной конфигурацией и изначальным запросом-требованием.
Управление рисками	Хотя всю модель CMMI можно рассмотреть в качестве платформы управления рисками, эта область процесса в частности обращается к рискам или вероятности и влиянию специальных изменений причины и ежедневных сюрпризов. Эта область процесса требует снижения и уменьшения риска, планирования непредвиденных случаев, управление проблемами и разрешение проблем.
Управление соглашениями с поставщиками	Возможность управления внешними поставщиками, определения соглашений, управления контрактом и принятия поставок требуемых продуктов или услуг.
Техническое решение	Все необходимые навыки по отношению к архитектуре программного обеспечения, разработке и кодированию.
Проверка	Приемочное тестирование в сравнении с требованиями клиента.
Проверка	Тестирование на предмет соответствия проекту архитектуры (из технического решения). Задача — обеспечить, что создаваемый продукт соответствует тому, как его представляли себе и проектировали, и будет удовлетворять потребности пользователей и работать в их среде.

Для каждой области процесса можно оценить уровень возможностей. 4 уровня возможностей определяются в v1.3 CMMI.

0. Не завершено

1. Выполнено

2. Управляемое

3. определен

Если достигается каждая конкретная цель и некоторые общие цели, возможность для конкретной области процесса будет оцениваться, как минимум, как уровень 1 — выполнено. Уровень возможностей 1 означает, что члены команды знают, что делать и делают это. Однако конкретная методика вряд ли проявит стабильность при статистическом анализе. Члены команды следуют методикам, однако единообразия по-прежнему не хватает. Уровень возможностей 2 означает, что команда понимает, как что-то работает и имеет уровень квалификации, обеспечивающий предсказуемое и подходящее для представления результатов статистического контроля выполнение методики. Вероятно, что обучение и сотрудничество повышают сплоченность команды. Уровень возможностей 3 означает наличие квалификации и способность разрабатывать новые и улучшенные методы, которые обеспечат достижение цели. Возможность уровня 3 означает, что любой статистический анализ потребует установки новых базовых значений после каждого явного изменения в лежащих в основе методах или практике.

Что такое CMMI Made Simple

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

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

При работе организации на твердом уровне зрелости3, все работает как часы. Организация выполняет свои обещания и считается очень надежной. Высокий уровень доверия проявляется в отношениях с клиентами. Руководители высшего звена начинают задавать такие вопросы, как "Куда мне вложить деньги для дальнейшего улучшения?" и "Какая команда дает самые лучшие экономические показатели?". Менеджеры начинают разрабатывать более подробно план возможностей и производительности и понимают, что можно использовать моделирование и статистический анализ, чтобы улучшить качество продуктов, доставку клиенту и повысить удовлетворенность. Решения руководства теперь полностью объективны и защищены статистическими данными. Это суть уровня зрелости организации 4. Для большинства высших руководителей уровень зрелости 4 представляет их идеальное состояние. Все работает, как часовой механизм, и имеются сравнительные данные производительности, и существует возможность предоставления согласно обещаниям с высоким уровнем точности. Экономическая производительность значительно повышается, и производительность организации точно прогнозируема.

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

Сертификация CMMI

Оценка зрелости процессов CMMI установлена сертификацией. Есть стандартный процесс для выполнения сертификации, Standard CMMI Appraisal Method for Process Improvement (SCAMPI). Это было введено, чтобы привнести определенную повторимость процесса и некоторое доверие к его результатам. Три Уровня строгости в подтверждении называются класс А, Б и В, где класс А - самый жесткий. Сертификация класса A требуется для оценки уровня модели, которая приемлема для публичной записи или требований Министерства обороны США.

Все оценки класса A и большинство оценок класса B управляются ведущими оценщиками CMMI, уполномоченными институтом Software Engineering для проведения оценки. Эти консультанты прошли через тщательную программу тренировки до лицензирования для практики. Некоторые оценщики прошли дополнительное обучение и имеют право называться ведущими оценщиками CMMI высокой зрелости. Организации, которые стремятся к оценке уровня 4 или 5 модели, должны работать с ведущим оценщиком высокой зрелости.

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

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

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

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

[1] Anderson, David J., гибкое руководство для Software Engineering: применение теории ограничений для бизнес-результатов, Prentice Hall PTR, 2003

[2] Anderson, David J., Kanban: Успешное постепенное изменение для вашей технической компании технологии, Blue Hole Press, 2010

[3] Glazer, Hillel и Jeff Dalton, David J. Anderson, Michael D. Konrad, Sandra Shrum, CMMI or Agile: Why not embrace both!, Software Engineering Institute, November 2008

[4] Humphrey, Watts S., Управление программным процессом, Addison Wesley Professional, 1989

[5] Deming, W. Эдвардс, The New Economics for Industry, Government, Education, 2-е издание, The MIT Press, 2000