05.04.2007 Вячеслав Панкратов

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

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

Очевидно, что качество программного обеспечения напрямую зависит от качества процесса его производства. Управляя процессом производства и контролируя показатели эффективности всех его технологических этапов, можно влиять на качество производимого продукта. Говоря о характеристиках программ, можно выделить простые для понимания и анализа количественные метрики, относящиеся к качеству программного кода (цикломатическая сложность кода - сложность структуры модуля, например, количество независимых маршрутов в нем); количество строк кода, отнесенное к артефактам проектного репозитория и т.п.; тесты (покрытие веток и модулей кода сценариями тестов, соотношение количества ошибок, найденных до и после выпуска продукта, динамика обнаружения ошибок и др.); покрытие требований на соответствие рекомендациям к интерфейсу приложений и операционным платформам. Однако, при переходе на процессный уровень обеспечения качества разрабатываемых программ возникают определенные трудности в понимании качества этого процесса. В самом деле, как, например, оценить и измерить эффективность того или иного способа разработки, если практически не существует проектов разработки двух одинаковых программных систем, и тем более не встречаются две идентичные по опыту и навыкам команды разработчиков? Судить по конечному результату не представляется возможным: кроме процессных условий производства программного обеспечения (применяемая методология, структура проектной команды, способы коммуникации с заказчиком) зачастую сильно разнятся и условия проекта (сроки, стоимость и объемы ресурсов). Более детальное рассмотрение процесса тестирования программного обеспечения - технологической составляющей процесса производства - выявляет проблему выбора метрик эффективности тестирования.

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

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

В 1980 году в Институте программной инженерии при Университете Карнеги-Меллона была разработана модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software, CMM), которая впоследствии получила развитие в CMMI (Capability Maturity Model Integration), де-факто признанном в индустрии производства программного обеспечения сертификате уровня зрелости процесса разработки. По аналогии с миром разработки программного обеспечения и существующими моделями зрелости их процессов, рассмотрим модели зрелости процесса тестирования.

Модель зрелости тестирования

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

Консультант по вопросам тестирования Терри Везерил в 2001 году одним из первых сравнил существующие модели зрелости тестирования и выделил шесть моделей:

Testability Maturity Model (TMM);

Software Testing Maturity Model (TMMSW);

Test Process Improvement (TPI);

Test Organization Maturity (TOM);

Testing Assessment Program (TAM);

Proposed Evaluation and Test SW-CMM Key Process Areas (SW-CMM KPA).

Затем в некоторые модели были внесены принципиальные изменения; так, модель ТОМ (ее создала и развивает компания Gerrard Consulting) предлагает обновленный набор метрик, описывающих непосредственно процесс тестирования (длительность тестовых итераций, соотношение тестовых сценариев и функциональных требований и др.), которые собираются и анализируются на этапе описания существующего процесса.

Среди шести моделей зрелости тестирования программного обеспечения практики и консультанты выделяют две: TMMSW, разработанную в Технологическом институте штата Иллинойс, и TPI, предложенную в компании Sogeti. Обе модели получили распространение в первую очередь благодаря своей простоте, а также предлагаемым практикам внутренних аудитов, которые могут производиться специалистами компании, вставшей на путь процессных улучшений. Рассмотрим структуру моделей зрелости тестирования программного обеспечения на примере модели TMM.

Модель TMMSW, выбранная Томасом Стаaбом , одним из ведущих консультантов в области тестирования программного обеспечения, является наиболее интересной для применения, поскольку наряду с простотой понимания и использования практик позволяет организациям собственными силами проводить оценки (assessment) и постепенно приближаться к поставленным целям развития, контролируя промежуточные результаты. В своей работе мы также остановили выбор на этой модели, учитывая непопулярность у отечественных ИТ-компаний практики привлечения сторонней компетенции (компании стараются экономить на инвестиционных проектах, каковыми по сути являются проекты консалтинговые, а также на проектах, приносящих непрямые выгоды, к которым относят процессные изменения), и предлагаем познакомиться с нашим опытом, демонстрирующим готовность компаний самостоятельно проводить внутренние изменения силами собственных специалистов. Итеративность подхода является для многих компаний ключевым моментом при выборе той или иной модели зрелости, так как она позволяет контролировать сроки исполнения проекта по внедрению процессных изменений.

Модель TMMSW разработана группой специалистов под руководством Илен Барнштейн в 1996 году как расширение и дополнение к модели SW-CMM. К ее преимуществам можно отнести соответствие уровней зрелости процессов тестирования программного обеспечения и уровней зрелости процессов разработки в модели SW-CMM. Также модель TMMSW может быть использована в интеграции с CMMI, рекомендациями ISO-9001 и стандартом ISO/IEC Std 12207, которые позволяют пройти формальную сертификацию и при постоянном контроле в виде аудитов и переаттестаций оставаться на заданном уровне качества. С одной стороны, эта особенность TMMSW позволяет внедрять процессные изменения в подразделении тестирования программного обеспечения в формате выделенного проекта меньшего масштаба, чем внедрение CMMI во всей организации (что экономит средства и обеспечивает прозрачность); с другой стороны, при таком подходе исключаются затраты на адаптацию и сопряжение нескольких моделей. Говоря о своеобразном родстве с CMMI, хотелось бы подчеркнуть, что эта модель достаточно широко распространена в мире ИТ и заслужила высокую степень доверия к себе, что намного облегчает мотивацию руководства к затратам на проект по внедрению процессных изменений.

Модель TMMSW предлагает облегченное планирование, внедрение и мониторинг процесса улучшения. Из недостатков модели можно отметить ограниченность литературы: книга Practical Software Testing: A Process-oriented Approach, выпущенная Springer Professional Computing, - пожалуй, единственный значительный труд по данной тематике.

Модель TMMSW, как и CMM, предусматривает пять уровней зрелости.

Уровень 1 - хаотический. Процесс тестирования программного обеспечения имеет хаотический характер, что отличает большинство начинающих компаний. Процесс тестирования не определен как выделенная активность и не отделен от процесса отладки кода. Тестирование выполняется по факту создания кода и построения или сборки системы. Цель тестирования - показать, что приложение работает. Этот уровень характеризуется неподготовленным персоналом, недостатком ресурсов и инструментов. Программное обеспечение выпускается без формального согласия со стороны тестировщиков. Цели уровня не определены.

Уровень 2 - фаза разработки. Тестирование программного обеспечения отделено от кодирования и выделяется как следующая фаза. Главная цель тестирования - показать, что приложение соответствует требованиям. Имеются базовые подходы и практики тестирования. Цели уровня: определить задачи разработки и тестирования, создать соответствующие процедуры, инициировать процесс планирования тестирования, зафиксировать и описать базовые процедуры и методики тестирования.

Уровень 3 - интегрированный. Процесс тестирования интегрирован в жизненный цикл разработки программного обеспечения. Цели тестирования базируются на требованиях. Имеется организация тестирования, а само тестирование выделено в профессиональную деятельность. Цели уровня: выделить тестирование в отдельную группу и определить программу технического обучения, интегрировать процесс тестирования в жизненный цикл разработки, а также контролировать непосредственно процесс тестирования.

Уровень 4 - управление и измерение . Тестирование является измеряемым и контролируемым процессом. Процессы критических осмотров (review) проектных артефактов (тестовые планы и сценарии, сообщения об ошибках, итоговые отчеты о состоянии версии и т.д.) относятся к тестовым активностям. Продукт тестируется на соответствие таким качественным метрикам, как надежность, удобство, сопровождаемость. Тестовые сценарии записаны, хранятся в системе управления тестированием и могут быть многократно использованы вместе с тестовыми наборами данных. Обнаруженные дефекты не только фиксируются, но и анализируются по формальным признакам: критичность, «вес» дефекта, важность, время жизни и т.д. Цели уровня: внедрение программ критических пересмотров и аудитов на уровне всей организации/подразделения наравне с программой измеряемого тестирования. Проводится оценка качества программных продуктов.

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

Все перечисленные уровни зрелости, кроме первого, включают цели развития, которые, в свою очередь, содержат подцели, то есть позволяют оперировать не только высокоуровневыми задачами менеджмента качества процесса разработки программного обеспечения, но и формулировать оперативные задачи для всех исполнителей в проекте. Контроль и анализ выполнения задач достигаются покрытием так называемых ATR-матриц (Activities - Tasks - Responsibilities) - артефактов проектного уровня, с которыми могут работать участники проекта без предварительной подготовки или длительного обучения. ATR-матрицы определяют активности и задачи, которые должны быть выполнены на каждом конкретном этапе внедрения модели, и служат одновременно и «дорожной картой», и своеобразным «контрольным листом» процесса внедрения изменений. Наличие предлагаемых самой моделью проектных артефактов зачастую является существенным критерием успешности проекта по адаптации и внедрению модели. Каждой активности в ATR-матрице назначается задача контроля, которая выполняется менеджерами, разработчиками/тестировщиками или же клиентами/пользователями. Особо отметим, что контроль над проектом по внесению изменений не возлагается на выделенную группу людей или конкретного человека в проекте, а является общей проектной функцией, в выполнении которой заинтересованы участники проекта всех уровней.

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

Применение конкретных методик или следование любой из выбранных методологий (RUP, MSF или Scrum) также не дает гарантий достижения качества продукта или успешности проекта, так как методология разработки программного обеспечения работает только для конкретного типа проектов. Аналогично для процесса тестирования программного обеспечения ни одна методология без адаптации к условиям конкретного проекта не дает гарантированного результата. Модель зрелости процесса - именно тем и интересная для применения практика достижения определенных уровней качества процесса, что представляет собой структуру целей и подходов для их достижения, позволяя использовать «внутри» практически произвольную методологию разработки (при правильной адаптации) и набор инструментария. Модель объясняет, «что и как» делать, но не «чем и в каком порядке».

Практика

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

Контролируемый по срокам процесс выпуска версий с заданным уровнем качества. Здесь не говорится об идеальном качестве выпускаемого продукта или полном отсутствии дефектов - речь идет об уверенности в состоянии выпускаемой версии, со стороны как проектной команды, так и группы тестирования.

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

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

Литература

Terry Weatherill, In the Testing Maturity Model Maze. Journal of Software Testing Professionals, 2001.

Thomas Staab, Using SW-TMM to Improve the Testing Process. Wind Ridge International.

Вячеслав Панкратов ([email protected] ) - генеральный директор компании QAExpert (Киев, Украина).

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

Качество было легко измерить: или нам платили, или нет.
Дин Леффингуэлл, Дон Уидриг.
Управление программными требованиями

CMM/CMMI

Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 г.

Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных , методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

Таблица 1. Уровни модели CMM

№ уровня	Название уровня	Ключевые области процесса
1	Начальный	Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено
2	Повторяющийся	Управление программными конфигурациями.Обеспечение качества программных продуктов.Управление контрактами подрядчиков.Контроль за ходом проектов.Планирование программных проектов.Управление требованиями
3	Определенный	Экспертные оценки.Координация взаимодействий проектных групп.Инженерия программного продукта.Комплексный менеджмент ПО.Программа обучения персонала.Определение организационного процесса.Область действия организационного процесса
4	Управляемый	Менеджмент качества ПО.Управление процессом на основе количественных методов
5	Оптимизируемый	Управление изменением процесса.Управление технологическими изменениями.Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя - SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

Таблица 2. Развитие стандартов CMM

Название стандарта	Описание
System Engineering CMM (SE-CMM)	Ориентирован на вопросы системного инжиниринга - разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование)
Trusted CMM (T-CMM)	Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО
System Security Engineering CMM (SSE-CMM)	Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей
People CMM (P-CMM)	Рассматривает вопросы развития персонала в софтверных организациях
Software Acquisition CMM (SA-CMM)	Охватывает вопросы приобретения программных продуктов у внешних организаций
Integrated Product Development CMM (IPD-CMM)	Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого отдела компании

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

Также существенная проблема CMM состоит в необходимости «выравнивания» всех процессов. Если организация пытается сертифицироваться на определенный уровень, то она должна обеспечить соответствующий уровень для всех своих процессов. Даже если специфика, методология или особенности разработки не располагают к выполнению определенных процессов, сертификация это требует.

Еще одна проблема вызвана тем положением, которое заняли стандарты CMM в современной индустрии ПО. Поскольку организация, обладающая высоким уровнем в соответствии с CMM, должна обеспечивать более высокие показатели программных продуктов по сравнению с теми, кто сертифицирован на низших уровнях, то стандарт стал применяться в качестве критерия отбора для участия в тендерах на разработку ПО или в аутсорсинговых проектах. Спрос на сертифицированные организации породил предложение по «быстрой и безболезненной сертификации».

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

Разрешить большинство проблем CMM призван новый стандарт SEI - Capability Maturity Model Integrated (CMMI) - Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления - классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, вводя новые классы, позволяющие сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

Разработка такого обзора была вызвана запросом американского федерального правительства на предоставление метода оценки субподрядчиков для разработки ПО. Реальная же проблема состояла в неспособности управлять большими проектами. Во многих компаниях проекты выполнялись со значительным опозданием и с превышением запланированного бюджета. Необходимо было найти решение данной проблемы.

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области ПО, и членами общества разработчиков.

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

Развитие

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration) . На текущий момент последняя версия CMMi - 1.3 (опубликована в ноябре 2010) .

См. также

Ссылки

Форум студентов МТИ > Основной раздел > Тесты > Моделирование систем управления

Просмотр полной версии: Моделирование систем управления

Я про решала все модули, сдала все на 4, а итоговый на 2, теперь через три дня попробую сдать повторно, не было ни одного одинакового вопроса. Итоговый тест пыталась исправлять, но проверяйте, за правильность не ручаюсь.Выставляю всё, что есть у меня, может быть кто то сдаст лучше меня. Если есть у кого то вторая, третья попытка, выставите, если не жалко, дисциплина, действительно очень трудная.:eek:

Итоговый тест 100 из 100

итоговое каждый раз разное?

Еще вопросы, которые здесь не указаны и попались мне. Ответы не искала, тк без этого сдала на 4. Кто захочет зоморочиться, выгрузите ответы здесь для остальных 🙂

Модуль 1:
Что не следует рассматривать в качестве отличительного признака бизнес-процесса?

Наращивание стоимости

Выберите один ответ:
Продукт процесса, воплощающий в себе ранее поставленные цели

Выберите один ответ:

В итоговом (сдано на 4.

What is the Capability Maturity Model? (CMM)

Эти вопросы + те, что уже есть на форуме):
1. Выберите правильное утверждение.
Выберите один ответ:
Бизнес-процесс подразделений состоит из различных цепочек создания ценности (НЕ УВЕРЕНА)
Сквозной бизнес-процесс состоит из бизнес-процессов различных организаций
Межфункциональный бизнес-процесс, как правило, состоит из бизнес-процессов подразделений

2. Что не является элементом универсальной структурной схемы бизнес-процесса?
Выберите один или несколько ответов:
Ресурсы процесса
Риски
Деятельность по управлению бизнес-процессом
Факторы внешней среды
Деятельность по преобразованию входов в выходы

3. Материальные ресурсы как базовый элемент процессов представляют собой:
Выберите один ответ:
Активные субъекты деятельности, объединенные в системы, взаимодействующие друг с другом и другими ресурсами
Управляющие воздействия, направляемые субъектами деятельности на объекты деятельности, определяющие цели и результаты процессов
Пассивные средства и предметы деятельности, используемые для выполнения процессов (НЕ УВЕРЕНА)

28.03.2014, 10:07

Модуль 1:
Что не следует рассматривать в качестве отличительного признака бизнес-процесса?Выберите один или несколько ответов:
Преобразование входов в выходы
Поставка продукта внешнему потребителю
Наращивание стоимости
Формирование прибавочной и/или потребительной стоимости

Результаты как базовые элементы процессов представляют собой:
Выберите один ответ:
Активные субъекты деятельности, объединенные в системы, взаимодействующие друг с другом и другими ресурсами
Продукт процесса, воплощающий в себе ранее поставленные цели Пассивные средства и предметы деятельности, используемые для выполнения процессов
Совокупность материальных, энергетических и информационных объектов, необходимых для выполнения процесса

Что такое обратная связь в рамках бизнес-процесса?
Выберите один ответ:
Целенаправленное и сознательное воздействие на процесс, предназначенное для обеспечения необходимого результата
Анализ и сопоставление результатов процесса с ранее поставленными целями
Воздействие на систему объектов и факторов внешней среды, являющиеся источниками различного рода отклонений в функционировании системы
я так ответила! но все равно вышло 4

В итоговом — Эти вопросы + те, что уже есть:
1 Выберите из списка недостатки проектно-целевых структур.

2 Выберите из списка примеры использования команд.
Кружки качества
Комитеты
Рабочие команды

3 Выберите из списка условия применения органистических организационных структур.
Работники мотивированы сложными потребностями
Цели размыты и динамично изменяются
Власть подвергается сомнению и испытанию, требует подтверждения со стороны подчиненных

4 Выберите из списка преимущества проектно-целевых организационных структур.
прямое подчинение сотрудников руководителю проекта и таким образом достигается однозначность направленности усилий этих сотрудников

5 Вспомогательные процессы:
Обеспечивают эффективную реализацию основных процессов

Итоговое оценка 5
Вопрос 1
Выберите из списка примеры использования команд.

Кружки качества
Комитеты
Рабочие команды

Вопрос 2
Для чего применяются посредники в рамках функциональной структуры?

Для интеграции деятельности различных структурных подразделений

Вопрос 3
Назовите типы взаимосвязей в модели SADT:
Управление
Выход-механизм
Обратная связь по входу

Вопрос 4
Какой из перечисленных бизнес-процессов является самым коротким?
Бизнес-процесс подразделения

Вопрос 5
Какие методы, методологии и инструменты можно использовать для создания информационных моделей бизнес-процессов?

Методологию Гейна-Сарсона
Язык моделирования Чена и Баркера

Вопрос 6
Какое представление бизнес-процесса соответствует самому нижнему уровню (из перечисленных)?

Операции бизнес-процесса

Вопрос 7
Длина бизнес-процесса:

Представляет собой субъективную характеристику

Вопрос 8
Материальные ресурсы как базовый элемент процессов представляют собой:

Пассивные средства и предметы деятельности, используемые для выполнения процессов

Вопрос 9
Выберите из списка преимущества проектно-целевых организационных структур.

Реализуется прямое подчинение сотрудников руководителю проекта и таким образом достигается однозначность направленности усилий этих сотрудников

Вопрос 10
Выберите из списка преимущества матричных организационных структур.

Появляется возможность гибко «настраивать» организационную структуру в рамках широкого спектра: от слабой до сильной матрицы

Вопрос 11
Что в себя включает второй контур управления бизнес-системой?

Подсистему управления функционированием
Подсистему управления развитием

Вопрос 12
Общая процессная модель бизнес-системы включает в себя следующие элементы:

Выход
процесс
Вход
Возмущение

Вопрос 13
Какой стандарт из семейства IDEF позволяет моделировать деятельность, потоки и состояние объектов?

Вопрос 14
Каковы полномочия Руководителя проекта в сильной матричной структуре?

От средних до высоких

Вопрос 15
Что можно отнести к числу основных элементов инвестиционно-финансовых процессов?

Инвесторов
Кредиторов

Вопрос 16
Выберите из списка недостатки проектно-целевых структур.

Снижается технологичность в функциональных областях

Моделирование систем управления.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Каков порядок доминирования на диаграммах SADT?
Ответ: Наиболее доминирующие функции располагаются в верхнем левом углу.

помогите 3тренинг укого есть плиз

Добавлено через 1 минуту
прошу 3 тренинг укого есть Моделирование систем управления

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Перевод: zCarot

Методология разработки ИС. Модель зрелости CMM/CMMI.

В 1991 году Институтом программной инженерии Университета

Карнеги-Меллона (Software Engineering Institute, SEI) была создана модель зрелости СММ (Capability Maturity Model) для разработки программных продуктов. С течением времени было выпущено целое семейство моделей:

SW-CMM - для программных продуктов, SE-CMM - для системной инженерии, Acquisition CMM - для закупок, People CMM - для управления людскими ресурсами, ICMM -для интеграции продуктов.

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

требованиями международных стандартов. Поэтому в 2002 году SEI опубликовал новую модель CMMI (Capability Maturity Model Integration), объединяющую ранее выпущенные модели и учитывающую требования

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

области. При этом все области задаются в виде требований, определяющих не то, как они реализованы, а интерфейсные требования. Из этого имеется два следствия.

Следствие 1. CMMI допускает различные реализации и не является методологией разработки ПО, подобно MSF, Scrum, RUP и пр. Последние могут использоваться в его реализации. Так, существует, например, специальный шаблон процесса в VSTS для CMMI под названием MSF for CMMI.

Следствие 2. CMMI используется для сертификации компаний на зрелость их процессов. Изначально, в конце 80-х начале 90-х годов, CMM (тогда еще не CMMI) создавался именно как средство сертификации

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

Например, авиационная, аэрокосмическая индустрии. То есть разработка ПО

происходит вместе с инженерными работами иных видов. И часто бывает, что в одном проекте участвует более двух различных видов инженерии. Задача CMMI – предоставить таким проектам и компаниям единую платформу организации процесса разработки.

В отличии от классической модели CMM, которая была жестко иерархической и допускала только последовательное улучшение процессов по уровням, модель CMMI имеет два измерения - последовательное, такое

же как и в CMM, и непрерывное, допускающее совершенствование процессов в организации до некоторой степени в произвольном порядке. Здесь мы остановимся на последовательной модели. Она имеет 5 уровней

зрелости процессов (рис. 1).

Начальный уровень (уровень зрелости 1) - это уровень, на котором, по определению, находится любая компания. На этом уровне разработка ПО ведется более-менее хаотично.

Управляемый уровень (уровень зрелости 2) - здесь уже появляются политики и процедуры организации процессов, утвержденные на уровне компании. Но в полной мере процессы существуют лишь в рамках отдельных проектов.

Определенный уровень (уровень зрелости 3) - здесь появляется стандартный процесс на уровне всей компании в целом.

What is Capability Maturity Model (CMM)? What are CMM Levels?

Это большой и постоянно пополняющийся набор активов процесса: шаблонов документов,

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

Управляемый количественно уровень (уровень зрелости 4) подразумевает появление системы измерений в компании, которые происходят на базе стандартного процесса и позволяют количественно управлять разработкой.

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

Многим известна аббревиатура CMMI, многие знают, что это — модель, т.е. набор рекомендаций как улучшить процессы, связанные, например с разработкой ПО. Но немногие знают, что моделей CMMI несколько. Самая известная из них — CMMI for Development (CMMI-DEV), которая действительно связана во многом с деятельностью разработческих компаний (т.е. тех компаний и организаций, которые разрабатывают и поставляют некий программный продукт или иное комплексное — программно-аппаратное решение).

Но как быть тем, кто поставляет не продукт, а услуги (например, сопровождение продукта с незначительной долей разарботки в общих трудозатратах или вообще с отсутствием таковых)? Для них тоже есть набор рекомендаций — модель CMMI for Services (CMMI-SVC). Для IT-подразделений, например, эта модель (точнее — её рекомендации) может помочь понять — что надо сделать, чтобы, например, те же рекомендации ITIL, приобрели характер нормального процесса, а не некой «сакральной практики».

Capability Maturity Model (Модель развития функциональных возможностей) (CMM)

Любопытно, что рекомендации этой модели достаточно универсальны и не «замыкаются» только на информационные технологии. Пилотное внедрение практик этой модели проходило … в одной из больниц в США (ведь медицинское обслуживание — это тоже услуги).

Однако, любой модели из перечисленных лучше обучиться. И если на всё СНГ обученных модели CMMI-DEV несколько сотен наберется (порядка 250-300 человек), то обученных модели CMMI-SVC в СНГ… 6 человек. Речь идет именно об обученных, а не об инструкторах. Это как раз и было до декабря 2011 года главной проблемой: по CMMI-DEV на весь мир был только один сертифицированный институтом SEI (разработчиком моделей CMMI) русскоязычный инструктор, а по другим моделям таковых вообще ни одного! Теперь появился такой инструктор и по модели CMMI-SVC (отсюда и первые 6 обученных). Этим инструктором является автор данной публикации, который готов ответить на любые вопросы по упомянутым моделям, и по официальному обучению. Спрашивайте!

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

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

Руководители таких организаций не всегда могут сформировать стратегию совершенствования и развития технологии деятельности своей компании; на рынке труда специалистов необходимой квалификации явно недостаточно. Вместе с тем в области совершенствования технологических процессов разработки и эксплуатации ПО международный опыт долгие годы был недостаточно обобщен и формализован. Только в начале 1990-х годов американский Институт программной инженерии (SEI) сформировал модель технологической зрелости организаций СММ (Capability Maturity Model), определив уровни технологической зрелости и их отличительные черты. В течение десятилетия СММ прошла апробацию в целом ряде организаций, ее эффективность и достоверность проверили заказывающие организации, поставщики ПО, компании, осуществляющие разработку заказного ПО, занимающиеся оффшорным программированием.

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

Оценка технологической зрелости компаний может использоваться:

· заказчиком при отборе лучших исполнителей (например, в тендере);

· компаниями-производителями ПО для систематической оценки состояния своих технологических процессов и выбора направлений их совершенствования;

· компаниями, решившими пройти аттестацию, для оценки «размеров бедствия», т.е. своего текущего состояния;

· аудиторами для определения стандартной процедуры аттестации и проведения необходимых оценок;

· консалтинговыми фирмами, занимающимися реструктуризацией компаний и служб поставщиков информационных технологий и связанных с ними услуг.

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

Зрелость процессов (software process maturity) - это степень их управляемости, контролируемости и эффективности. Повышение технологической зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопровождения ПО в рамках всей организации. Реальное использование процессов невозможно без их документирования и доведения до сведения персонала организации, без постоянного контроля и совершенствования их выполнения. Возможности хорошо продуманных процессов полностью определены. Повышение технологической зрелости процессов означает, что эффективность и качество результатов их выполнения могут постоянно возрастать.

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

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

Начиная с 1990 г. SEI при поддержке правительственных структур США и организаций-разработчиков ПО постоянно развивает и совершенствует эту модель, учитывая все новейшие достижения в области создания и сопровождения ПО.

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

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

На каждом уровне устанавливаются требования, при выполнении которых достигается стабилизация наиболее существенных показателей процессов. Выход на каждый уровень технологической зрелости является результатом появления определенно­го количества компонентов в процессах создания ПО, что в свою очередь приводит к повышению их производительности и качества. На рис. 1.7 показаны пять уровней технологической зрелости СММ.

Рис. 1.7. Пять уровней технологической зрелости СММ

Надписи на стрелках определяют особенности совершенствования процессов при переходе с уровня на уровень.

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

На уровне 1 (начальном) основные процессы создания и сопровождения ПО носят случайный характер и выполняются хаотично. Успех выполнения проекта всецело зависит от индивидуальных усилий персонала. На этом уровне, как правило, в орга­низации не существует стабильной среды, необходимой для создания и сопровождения ПО.

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

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

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

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

Каждый уровень СММ, начиная со второго, характеризуется наличием ряда так называемых основных групп процессов (key process areas - КРА). Модель СММ содержит 18 таких групп, последняя версия модели CMMI - 20 групп. Уровень 2 СММ характеризуется наличием в организации следующих процессов (их наименования соответствуют CMMI):

· управление требованиями;

· управление конфигурацией;

· планирование проекта;

· мониторинг и контроль проекта;

· управление контрактами;

· измерения и анализ;

· обеспечение качества процесса и продукта.

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

На уровне 3 (уровне стандартизованных процессов) про­цессы создания ПО документированы, стандартизованы и предс­тавляют собой единую технологическую систему, обязательную для всех подразделений организации. Во всех проектах использу­ется опробованная, утвержденная и возведенная в статус стан­дарта единая технология создания и сопровождения ПО.

На данном уровне к процессам уровня 2 добавляются следующие процессы:

· спецификация требований;

· интеграция продукта;

· верификация;

· аттестация;

· стандартизация процессов организации;

· обучение;

· интегрированное управление проектом;

· управление рисками;

· анализ и принятие решений.

Основным критерием использования и, при необходимости, корректировки процессов на этом уровне является помощь звену управления и техническим специалистам в повышении эффективности выполнения проектов. На этом уровне в организации создается специальная группа, ответственная за состав операций, из которых состоят процессы, - группа по разработке процессов создания ПО (software engineering process group - SEPG).

На основе единой технологии для каждого проекта могут разрабатываться свои процессы с учетом его особенностей. Такие процессы в СММ называются «проектно-ориентированные процессы создания ПО» (project"s defined software process).

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

Главное назначение уровня 4 (уровня управляемых процессов) - текущий контроль над процессами. Управление должно обеспечивать выполнение процессов в рамках заданного качества. Могут быть неизбежные потери и временные пики в измеряемых результатах, которые требуют вмешательства, но в целом система должна быть стабильна.

На уровне 4 добавляются следующие процессы:

· управление производительностью и продуктивностью;

· количественное управление проектом.

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

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

Результаты выполнения процессов на четвертом уровне становятся предсказуемы, поскольку они измеряемы и варьируются в рамках заданных количественных ограничений. На этом уровне появляется возможность заранее планировать заданное качество выполнения процессов и конечной продукции.

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

На уровне 5 добавляются следующие процессы:

· внедрение технологических и организационных инноваций;

· причинно-следственный анализ и разрешение проблем. Процессы создания и сопровождения ПО характеризуются

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

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

Каждый последующий уровень дополнительно обеспечивает более полную обозримость самих процессов создания и сопровождения ПО.

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

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

На третьем уровне определена внутренняя структура «черных ящиков», т.е. задачи, из которых состоят процессы. Внутренняя структура представляет собой путь, по которому стандартные процессы в организации применяются в конкретных проектах. Звено управления и исполнители в необходимой степени детализации знают свои роли и ответственность в рамках проекта. Руководство заранее подготовлено к рискам, которые могут возникнуть в процессе выполнения проекта. Так как стандартизированные и документированные процессы становятся «прозрачными» для обозрения, сотрудники, непосредственно не занятые в проекте, могут своевременно получать точные сведения о его текущем состоянии.

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

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

Четвертый и пятый уровни редко встречаются в индустрии ПО. Так, если третьего уровня достигло в мире несколько сотен компаний, то фирм пятого уровня (по информации SEI на 2002 г.) насчитывалось 62, а четвертого - 72. При этом отметим, что объявляют о своем уровне зрелости далеко не все компании. Одни не заинтересованы в афишировании своих организационных технологий, другие выполняют сертификацию просто под давлением заказчика.

Для достижения высших уровней СММ требуется десять и более лет. Но даже уровень 3 позволяет смело выходить на международную арену. Для использования СММ компании не надо искать сотрудников с какими-то уникальными способностями, ей достаточно понять общую идею. В описании модели СММ детально указано, что надо делать, чтобы развиваться в соответствии с этой моделью. Следовать регламентированным действиям СММ способен любой менеджер среднего класса.

Последняя версия СММ 1.1 в основном ориентирована на крупные компании, занимающиеся реализацией больших проектов, но она вполне может использоваться и группами из двух-трех человек или отдельными программистами для выполнения небольших проектов (продолжительностью до трех месяцев). В таких случаях модель СММ может сыграть жизненно важную роль, поскольку поступление новых заказов во многом определяется качеством реализации предыдущих проектов. Маленькие группы вполне удовлетворятся уровнем 2, так как для небольшого проекта отклонение от срока на пару недель непринципиально.

С 2002 г. официально распространяется специальная интеграционная версия CMMI. Это новая разработка SEI, охватывающая все аспекты деятельности компании: от разработки и выбора подрядчика до обучения, внедрения и сопровождения. Кроме того, модель CMMI расширена подходами из системной инженерии. В эту модель вошли наработки, сделанные в ходе проектирования версии СММ 2.0 (она не была закончена), основные изменения в которой были направлены на уточнение процессов для компаний четвертого и пятого уровней, что наиболее актуально для крупномасштабных американских проектов.

Модель СММ достаточно весома и важна, однако не стоит применять ее как единственную основу, определяющую весь процесс создания ПО. Она была предназначена в основном для ком­паний, которые занимаются разработкой ПО для Министерства обороны США. Эти системы отличаются большими размерами и длительным сроком эксплуатации, а также сложностью интерфейса с аппаратным обеспечением и другими системами ПО. Над созданием таких систем работают достаточно большие коллективы программистов, которые должны подчиняться требова­ниям и стандартам, разработанным Министерством обороны.

К недостаткам СММ относятся следующие:

1. Модель сосредоточена исключительно на управлении проектом, а не на процессе создания программного продукта. В модели не учтены такие важные факторы, как использование определенных методов, например прототипирования, формальных и структурных методов, средств статического анализа и т.п.

2. В модели отсутствует анализ рисков и решений, что не позволяет обнаруживать проблемы прежде, чем они окажут воздействие на процесс разработки.

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

Главной целью создания модели СММ было намерение Министерства обороны США оценить возможности поставщиков ПО. На данный момент пока не существует четких требований к достижению определенного уровня развития организаций-разработчиков. Однако принято считать, что у организации, достигшей высокого уровня, больше шансов выиграть тендер на поставку ПО. В качестве альтернативы СММ предлагается обобщенная классификация процессов совершенствования технологической зрелости, которая подходит для большинства организаций и программных проектов. Можно выделить несколько общих типов процессов совершенствования.

1. Неформальный процесс. Не имеет четко выраженной модели совершенствования. Его с успехом может использовать отдельная команда разработчи-

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

2. Управляемый процесс. Имеет подготовленную модель, которая управляет процессом совершенствования. Модель определяет действия, их график и взаимосвязи между ними.

3. Методически обоснованный процесс. Подразумевается, что введены в действие определенные методы (например, систематически применяются методы объектно-ориентированного проектирования). Для процессов этого типа будут полезными инструментальные средства поддержки проектирования и анализа процессов (CASE-средства).

4. Процесс непосредственного совершенствования. Имеет четко поставленную цель совершенствования технологического процесса, для чего существует отдельная строка в бюджете организации и определены нормы и процедуры внедрения нововведений. Частью такого процесса является количественный анализ процесса совершенствования.

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

Необходимость приведенной классификации обусловлена тем, что она предоставляет основу для комплексного совершенствования технологии создания ПО и дает возможность организации выбирать разные типы процессов совершенствования. На рис. 1.8 показаны соотношения между разными типами программных систем и процессами совершенствования их разработки.

Рис. 1.8. Применимость процессов совершенствования

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

Многие технологические процессы в настоящее время имеют CASE-средства поддержки, поэтому их можно назвать поддерживаемыми процессами. Методически обоснованные процессы поддерживаются инструментальными средствами анализа и проектирования. Эффективность средства поддержки зависит от применяемого процесса совершенствования. Например, в неформальном процессе могут использоваться типовые средства поддержки (средства прототипирования, компиляторы, средства отладки, текстовые процессоры и т.п.). Вряд ли в неформальных процессах будут использоваться на постоянной основе более специализированные средства поддержки.

Модель СММ не уникальна. Почти каждая крупная компания развивает собственные технологии создания ПО, иногда эти технологии становятся общедоступными и очень популярными. Широкая известность модели СММ связана с ее государственной поддержкой, но реальная эффективность СММ критикуется многими ведущими экспертами. Один из основных недостатков СММ связан с излишне жестким требованием не отклоняться от принципов данной модели, даже если здравый смысл подсказывает обратное. Подобные претензии на владение абсолютной истиной не могут не вызвать настороженности, поэтому в среде малых и средних компаний более популярны подходы, оставляющие гораздо больше свободы для индивидуального и коллективного творчества. Рассматриваемая далее методика SPMN занимает промежуточное место между жесткими, «тяжелыми», эффективными для крупных организаций решениями типа СММ и максимально гибкими технологиями. Она представляется оптимальным вариантом для фирм, которые, с одной стороны, хотят как можно быстрее упорядочить свою управленческую деятельность, а с другой стороны, планируют в перспективе выйти на международный уровень, где сертификация по СММ крайне желательна.