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