CMM = Capability Maturity Model
Описание ключевых требований к улучшению качества производства и внедрения программного обеспечения
Версия 1.01 (дополнена рекомендациями по применению Microsoft Project и MS Project Central)
Приводится на основе описания стандарта:
The Capability Maturity Model: Guidelines for Improving the Software Process.
Carnegie Mellon University
Software Engineering Institute
Addison-Wesley, August 1999
Мы применяли на практике (Alcatel PAS, Gillette Workflow) почти все рекомендации CMM level 2, и многие из рекомендаций level 3,4,5. Методики CMM позволяют значительно повысить управляемость разработки и качество реализации ПО. Однако следует отметить, что CMM не раскрывает многих методических требований к качеству аналитики и прототипирования. Мы рекомендуем по методике аналитических работ обратиться к S.Davis. Bussiness Applications. По методикам тестирования полезны работы Канера.
| Уровень | Ключевые требования к уровню | Пояснения к требованиям |
| Level1 Начальный Initial |
Нет, неуправляемая разработка | На данном уровне находятся 70% компаний разработки ПО. Успех достигается только личными качествами персонала. |
| Level 2 Уровень повторяемости Repeatable |
Управление требованиями Requirements managment | Требования к
системе фиксируются и составляют единое целое с
планом реализации. Если требования изменяются, то изменяется план. Требования документированы. |
| Level 2 | Планирование
проектов Software project planning |
Все задачи по
реализации документируются в виде плана. Рекомендую на данном этапе использовать MS Project |
| Level 2 | Отслеживание
плана и периодический контроль Software project tracking and oversight |
Документируется
состояние проекта (выполнение задач) по
результатам контрольных осмотров. Результата осмотра можно фиксировать как Completed в MS Project |
| Level 2 | Субконтрактное
управление Software subcontract managment |
Менеджер и
исполнитель достигают договоренности о сроках
(ценах) задачи. Задача может быть принята в план
только при обоюдном согласии. Можно использовать Team Inbox (Team Assign) для автоматизации согласования плана в MS Project |
| Level 2 | Контроль качества Software quality assurance |
Группа контроля
качества должна сравнивать продукт с
документированными требованиями. Результаты тестирования сообщаются менеджеру и исполнителям. Примечание. На Level 2 софтверные метрики тестирования не обязывают вести трекинг ошибок со статистическим учетом. Однако требуется документировать ошибки в виде баг-листа и производить регрессивное тестирование. |
| Level 2 | Управление
версиями и конфигурациями продукта Software configuration managment |
Документируются изменения продукта в различных версиях. Существует описание отличий продукта от базовой версии. |
| Level 3 Уровень определения Defined |
Настройка
организационной структуры на процесс разработки Organization Process Focus |
Проводится в
соответствие с технологией ведения проектов
организационная структура компании (создаются
необходимые подразделения, перераспределяется
ответственность). Ведется общий учет, как проектной информации, так и организационных мероприятий, таких как обучение, апробирование новых средств. Производится стоимостная оценка задач, оценка новых средств разработки, сводятся результаты обучения, собираются планы всех групп. Данная информация должна быть размещена в централизованной базе данных, на основе данной статистики производится сравнительный анализ организации Можно рекомендовать виде базы совместного планирования MS Project Central. Необходимо создать в нем межпроектный пул ресурсов. |
| Level 3 | Описание
организационного процесса разработки Organization Process Definition |
Документируется
стандартный процесс разработки. Документы и статистика по организации процесса собираются в едином хранилище доступном разработчикам. Периодически по результатам статистических наблюдений за выполнением планов и стоимостей работ производится пересмотр элементов стандартного процесса разработки. Следует отметить, что CMM не регулирует методы аналитических работ, а определяет только организационные методы ведения аналитики и проектирования. Можно порекомендовать в качестве аналитических стандартов UML и IDEF. |
| Level 3 | Программа
обучения Traning Program |
Согласно
потребностям проектов составляется программа
обучения. Ведется учет результатов тестирований и сертификаций. Производится периодический аудит программ
обучения. Если не зарезервировать время на обучение, то персонал будет самообучаться для проектных целей. Это приведет к "непонятным" потерям времени (неуправляемости проекта), низкому качеству получения знаний. |
| Level 3 | Интегрированное
управление проектами и технологией Integrated Software Managment |
При планировании
проектов используется документированный
стандарт процесса разработки. Проектные планы строятся на созданной организационной структуре. По документированной процедуре прилагающейся к технологии разработки используется оценка рисков, критического пути, стоимости и продолжительности работ. Данное утверждение не противоречит принципу субконтрактного управления. Для принятия задачи требуется утверждение всех сторон, но обсуждение сроков и цен ведется от стандартных нормативов. Разрабатываемые планы учитываются в специальной межпроектной базе данных. Полезна выработка шаблонных документов для ТЗ, договора и т.д. Для оценки рисков по PERT-технике и определения критического пути можно использовать MS Project. |
| Level 3 | Технология
разработки Software product engineering |
Документируется
технология разработки. Описанные
технологические стадии используются при
планировании. Технология должна описывать:
На базе документированной технологии строится план. Ведется учет дефектов выявляемых тестированием и контрольными осмотрами технологического состояния (peer reviews). В MS Project рекомендую выделить отдельные технологические стадии (аналитика, проектирование и т.д.) в виде mile stone (контрольных точек). |
| Level 3 | Межгрупповое
управление Intergroup Coordination |
Требования
пользователя утверждаются для реализации в
продукт всеми группами разработки. Требования пользователя принимаются одновременно с соглашением между группами о реализации. Инженеры выявляют технологические проблемы на стыке работ групп и отлеживают их устранение. |
| Level 3 | Периодический
осмотр технологического состояния Peer reviews |
Производится
технологическая инспекция состояния проектов. Выявленные дефекты регистрируются. |
| Level 4 Уровень управления Managed |
Метрический
Процесс Управления Разработкой Quantitative Process Managment |
По учетной
информации обеспечиваемой Level 4 ведется
всесторонняя статистика. Вычисляются эталонные статистические показатели стандартного процесса разработки. На основе сравнения с ними ведется управление проектами. На данном этапе нужно воспользоваться накопленной статистикой ведения проектов в MS SQL или Oracle (смотря с чем состыкован Microsoft Project Central). Построив статистические отчеты по различным технологическим стадиям, можно получить реальные и проверенные практикой оценки трудоемкостей. Их следует использовать в качестве эталонных при последующем планировании. |
| Level 4 | Управление
Качеством Software Quality Managment |
Ведется
статистический анализ различных параметров
качества продуктов. Полученные данные сравниваются с эталонными показателями. На основе полученных данных вносятся коррекции в технологических процесс и методы реализации проектов. На данном этапе необходимо базу регистрации дефектов интегрировать с SQL Server и получить статистику по видам дефектов, качеству модулей и т.д. |
| Level 5 Уровень оптимизации Optimizing |
Предотвращение
дефектов Defect Prevention |
Ведется анализ и
статистический учет причин возникновения
дефектов. Выявленные причины дефектов ранжируются по приоритетам и устраняются организационными мероприятиями. Для полноценного стаститического анализа дефектов, требуется определить, какую аналитику по дефектом должен вести QA. |
| Level 5 | Управление сменой
технологий Technology Change Managment |
Производится
плановое апробирование новых технологий.
Результаты апробирования регистрируются. Производится плановое внедрение новых технологий, которые показали высокие результаты. Для целей регистрации результатов апробирования можно использовать Lotus Team Room (поставляется как шаблон базы с Lotus Domino). |
