Make your own free website on Tripod.com

CMM = Capability Maturity Model

Описание ключевых требований к улучшению качества производства и внедрения программного обеспечения

Rambler's Top100

Версия 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).

1C:TOP-100