АКИС (10) - Лекция №15 - Оценка зрелости

Оценка зрелости

Качество - это соответствие требованиям и более ничего.

CMM

Capability Maturity Model — модель зрелости возможностей создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение.

Уровни CMM:

1. начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве;
2. повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 99 лишь 20% организаций имели 2-й уровень или выше;
3. установленный. Имеют определенный, документированный и установленный процесс работы, не зависящий от отдельных личностей. Т.е. Вводятся согласованные проф. Стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надежно предсказывать затраты на проекты, аналогичные выполненным ранее;
4. управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений. Но нет изменений при появления новых технологий и парадигм;
5. оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.

	Уровень 1 начальный	Уровень 2 повторяемый	Уровень 3 определенный	Уровень 4 управляемый	Уровень 5 оптимизированный
Связь с миссией организации	Отсутствует или неявная	Явная связь с миссией	Явная связь с ключевыми параметрами миссии	Периодическая переоценка актуальности связи. Контролируемый интервал времени между изменением требований и изменением архитектуры	Процессы постоянно улучшаются на основании измеряемых требований
Вовлеченность высшего руководства	"Что такое корпоративная архитектура?" "Зачем она нам вообще нужна?" "Нет, это у нас работать не будет"	Руководство что-то слышало о проекте по разработке архитектуры. Усердное кивание головами. Некоторое сопротивление в связи с ожидаемыми результатами	Руководство в курсе проекта и поддерживает его. Руководство поддерживает наличие стандартов	Высшее руководство участвует в обсуждении результатов проекта	Руководство активно участвует в оптимизации бизнес-процессов в рамках архитектурного проекта
Участие бизнес-подразделений	"Мы поддерживаем данный проект, пока он рекомендует те стандарты, которые мы уже сами раньше выбрали". "Стандарты только помешают нам реализовать миссию предприятия"	Признание факта, что поддержка слишком большого числа разных технологий накладна. Возможно разочарование от внедрения инновационных приложений "в пустоте"	Признание факта, что стандарты архитектуры помогут облегчить интеграцию и повысят шансы компании на реализацию миссии. Большинство бизнес-подразделений активно участвуют в разработке архитектуры	Все бизнес-подразделения активно участвуют в разработке архитектуры	Рекомендации бизнес-подразделений используются для улучшения самого процесса разработки архитектуры
Описание самого процесса разработки архитектуры	Отсутствует или сохраняется в том виде, как осталось к моменту завершения прошлого провального проекта	Активно разрабатывается внутри ИТ-службы. Недостаточно широко известно в организации	Процесс хорошо определен и известен ИТ-специалистам и бизнес-подразделениям	Процесс является частью корпоративной культуры, он сильно связан с другими процессами, такими как финансовое планирование, реинжиниринг, разработка новых продуктов и др.	Спланированные усилия по оптимизации процесса. Моделирование предлагаемых изменений процесса перед реализацией
Разработка профилей стандартов	Нет никакой архитектуры – просто не о чем говорить. Несколько стандартов, выбранных случайным образом	Стандарты существуют, но не объединены в систему	Разработка профилей стандартов связана с бизнес-требованиями посредством концептуальной архитектуры, определенных принципов и лучших практик	Архитектура компонент ИС определена вплоть до уровня стандартов. Эксплуатируемые системы проверяются на соответствие стандартам	То же, что и на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса разработки aрхитектуры
Распространение описания архитектуры в организации	Вроде бы описание находится в папке, которую недавно видели где-то в службе ИТ. Новые сотрудники ИТ-службы, вероятнее всего, даже не знают о существовании этой папки	Папка с описанием архитектуры периодически обновляется, или результаты размещаются на web-сайте. Для документирования используется MS Word и картинки. Совещания и обсуждения архитектуры иногда имеют место	Документы регулярно обновляются и уточняются. Актуальная на каждый момент версия доступна на web-сайте, в БД коллективного доступа и т.п. Для управления документацией используются специализированные средства. Периодические презентации по ходу процесса для ИТ-службы. Вероятно, они входят в курс начального обучения новых сотрудников	Документы регулярно обновляются и уточняются с контролируемыми сроками. Проводится мониторинг обучения и ознакомления	То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса распространения архитектуры
Контроль за применением стандартов	Явные процедуры отсутствуют	Некоторые стандарты контролируются (напр., ПО рабочих станций). Отклонения на стадиях проектирования и внедрения могут остаться незамеченными	Явный контроль основной части стандартов. Формализованный процесс рассмотрения отклонений	Явный контроль всех инвестиций в ИТ. Формализованный процесс использования выявленных отклонений для коррекции архитектуры	То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса контроля
Управление проектом разработки архитектуры	Стандарты и средства отсутствуют или случайные. Формальный механизм определения приоритетов отсутствует	Используются средства планирования и управления. Оценка рисков производится командой проекта	Целевая архитектура определяет требования к квалификации персонала. Процедуры управления изменениями определены и связаны с процессом рецензирования архитектуры	Инициация проекта и определение ключевых требований производится совместно руководителями организации и ИТ-службы. Управление вендорами – одна из ключевых компетенций. Требования непрерывности производства заложены в цикл планирования проекта	Действует программа обеспечения результативности. Контракты с вендорами продлеваются на основе измеряемых показателей производительности и соответствия корпоративным стандартам. Ключевая компетенция – непрерывность бизнеса
Корпоративная архитектура масштаба предприятия	Миссия, требования к данным и приложениям определены только в принципе. Данные о процессах, приложениях, информационных ресурсах, а также их модели неполны или отсутствуют вообще	Большинство приложений перечислены в реестре. Для части бизнес-процессов существуют модели	Все приложения классифицированы в реестре в соответствии с их позиционированием для бизнеса и состоянием. Модели бизнес-процессов существуют и используются для проектирования разработки решений	Моделирование процессов и выбор приложений производится в соответствии с архитектурой. Методы и средства моделирования периодически проверяются. Оцениваются затраты времени на моделирование и фактическое использование моделей	Метрики, определяемые на уровне 4, используются для улучшения процессов. Происходит переход от использования отдельных приложений к использованию решений. Бизнес-моделирование является постоянным и обязательным, актуальные модели сохраняются в общем репозитории
Организация закупок ИТ	Стратегия закупок отсутствует. Персонал, участвующий в закупках, не принимает заметного участия в процессе разработки архитектуры	Декларируется следование процедурам и стандартам. Контроль заявок и фактических закупок на соответствие архитектуре неполный или отсутствует	Стратегия закупок определена и предусматривает соответствие стандартам архитектуры. Требования запросов на закупку формируются с учетом стандартов. Персонал, осуществляющий закупки, участвует в контроле за соблюдением стандартов	Все закупки планируются и управляются в соответствии с определенной архитектурой. Оценка предложений поставщиков интегрирована в процесс планирования архитектуры. Существуют процедуры по учету и утилизации устаревающих компонент ИС	Незапланированные закупки отсутствуют