Главная > Галстук > Определение программного инжиниринга в модели SEI CMM. Стандарты ISO, SW-CMM. CASE-технологии Совершенствование процессов работы с требованиями

Определение программного инжиниринга в модели SEI CMM. Стандарты ISO, SW-CMM. CASE-технологии Совершенствование процессов работы с требованиями

В.Ильин.

Руководитель Службы качества Компании TopSBI

"Если делаешь что-нибудь

неправильно - не нужно
рассчитывать на правильный результат."

Народная китайская мудрость

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

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

Подчеркивая, что ISO 9000 - "превосходная идея", Gartner Group рекомендует рассматривать сертификацию на ISO 9001 только, как исходную точку на пути к качеству {1}.

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

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

    Сначала разработать и внедрить СМК по модели ISO 9001:2000. (Ведь большинство компаний, которые сейчас находятся на 4-ом и 5-ом уровнях SW-CMM, сначала прошли через приведение своих процессов в соответствие по модели ISO. Как показывает практика, это оптимальный вариант в плане управления развитием СМК и снижения рисков).

    И только затем начать разрабатывать и внедрять ключевые процессы модели SW-CMM и далее, при необходимости, модели CMMI.

Для того, чтобы понять, насколько это действительно правильно, проведем сравнение этих моделей.


1. Обзор претендентов.

Проведем краткий обзор наиболее популярных стандартов, которые могут быть использованы ИТ-компанией для оптимизации своих бизнес-процессов.

ISO 9001. Наиболее популярным, и особенно, в Европе, является ISO 9001 {2}

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

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

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


CMM (Capability Maturity Model) разработана Software Engineering Institute при университете Карнеги-Меллона (США) и описывает модель зрелости процессов разработки программного обеспечения на предприятиях {3}. В рамках этой модели для каждой компании может быть сопоставлен некоторый уровень (один из пяти возможных), свидетельствующих о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались, прежде всего, в целях упорядочивания процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО проектам, в то время как технические аспекты разработки освещены меньше.

В версии SW-CMM v.1.1 (Capability Maturity Model for Software) имеется 316 Key Practices. Key Practices - это то, что должно быть внедрено на предприятии и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области - Key Practices Areas (KPA) - это уже совокупности взаимосвязанных процессов, которые при совместном выполнении и приводят к достижению определенного набора целей.

CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее приемлемой для разработчиков программных систем, - количество Key Practices достигает уже 417.

Увеличение Key Practices связано с самой целью разработки CMMI - модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей CMM.


(Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:

Модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software - SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard - EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов Integrated Product Development Capability Maturity Model - IPD-CMM)

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


Понятно, что это получилась уже существенно более "тяжелая" модель- см. Рис. 1 , которая, к тому-же, еще не достаточно проверена на практике (вышла только в 2002 году). В связи с этим, по моему мнению, при внедрении модели возможны большие риски, связанные, как с неоправданными потерями скорости разработки ПО, так и с одновременным однозначным возрастанием трудозатрат на функционирование (и поддержку) внедренных KPA - cм. Рис 1. Мне, как практику уже построившему СМК в трех различного профиля ИТ-компаниях, кажется, что в модели CMMI явно нарушен баланс необходимого и достаточного - персонал ИТ-компании (а это, как правило, большей частью- "художники кода ") просто "не примет к исполнению" такое количество контроллируемых регламентов (здесь есть очень большой риск построить "потемкинскую деревню") !


Рис. 1 Сравнение состава KPA в моделях CMM и CMMI.

Кроме того Assessment для CMMI будет значительно дороже, так как авторизованных SEI Lead Assessor" ов будет пока очень мало, и услуги эти будут значительно более дорогие, чем при оценке на соответствие модели CMM.

Более того, многие зарубежные специалисты в области менеджмента качества, (к мнению которых я на данный момент полностью присоединяюсь), довольно скептически отзываются о CMMI в контексте полезности ее для реализации в небольших и средних организаций (именно такие организации, как раз и характерны для России). Высказывается даже мнение, что через некоторое время SEI придется либо выпустить адаптированную SW-CMM v.2, либо произвести какие-то подобные шаги. Т.е. если рынок не примет модели, а такие предпосылки уже на момент написания этой статьи есть, то SEI надо будет адаптироваться к требованиям рынка.

В связи с вышеизложенным представляется целесообразным провести анализ уже упомянутого баланса необходимого и достаточного во всех этих основных моделях СМК.

Проведем его в следующих координатах (см. Рис. 2 ) :

    степень регламентируемости процессов разработки - обозначим это понятие - RP ,

    вероятность достижения запланированных результатов- обозначим это понятие -PQ .

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

Выражаясь математическим языком, величина производной: F(Q) = dPQ \ dRQ (прирост эффективности в достижении качества dPQ при приросте затрат рабочего времени на поддержку выполнения требований dRQ ),уменьшается,соответственно, в следующей последовательности: ISO 9000, CMM, CMMI.

Поэтому Рис. 2 наглядно и просто объясняет:

    популярность именно модели ISO 9000,

    правильность методики: сначала ISO, и только потом, при необходимости, CMM,

    определенный скепсис в отношении эффективности модели CMMI.

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


Расмотрим теперь еще одно руководство, которое широко используется в ИТ-компаниях и будет упомянуто ниже при анализе вопросов практики внедрения СМК.

Это PMBoK (Guide to the Project Management Body of Knowledge) - это проект Project Management Institute, вобравший в себя накопленные знания в области управления проектами. Последняя версия документа вышла в 2000 году и тогда же получила статус стандарта американского института стандартизации ANSI (хотя стандарты ANSI и IEEE формально считаются американскими, большинство из них носит де-факто международный характер). Важной особенностью PMBоK является то, что он рассматривает управление проектами в общем смысле, без привязки к конкретным предметным областям, таким как ИТ, и потому не может применяться самостоятельно - ниже мы рассмотрим, какой это дает эффект при его использовании совместно с ISO 9000.

Рассмотрим теперь, как соотносятся требования уже популярного стандарта ISO 9001:2000 с общими свойствами становящейся все более популярной модели СММ {3}- см. Рис. 3 .


Рис. 3. Соответствие между общими свойствами СММ и элементами ISO 9001:2000


Каждый уровень СММ, как было уже упомянуто выше, характеризуется набором областей ключевых процессов- KPA (Key Process Areas) - см. Рис.3. Достижение всех целей в рамках KPA для определенного уровня СММ определяет соответствие организации данному уровню. Если хотя бы одна цель хотя бы одной KPA для уровня СММ не достигнута, то организация не может соответствовать данному уровню CMM. KPA можно разбить на три категории: управляющие , организационные и обеспечивающие (см. Рис. 4 ).



СММ не определяет все процессы, имеющие отношение к разработке программного обеспечения; в ней выделяются только те, которые необходимы для достижения уровня СММ, они и включаются в KPA . Каждая KPA разбивается на 5 общих свойств (Common Features): Обязательство выполнить (Comment to perform); Способность выполнить (Ability to Perform); Выполняемые действия (Activities Performed); Измерение и анализ (Measurement and Analysis); Проверка реализации (Verifying Implementa­tion)

Общее свойство "Выполняемые действия" описывает действия, которые необходимо выполнить для достижения целей KPA , остальные четыре общих свойств описывают формальные факторы, делающие процесс частью организационной культуры. Полное выполнение всех ключевых приемов (key practice) из всех общих свойств обеспечивает достижение целей KPA . Ключевые приемы работы описывают, каким должен стать рабочий процесс (или элемент процесса, или часть инфраструктуры), но не определяют способ достижения (конкретные технологии или методики), хотя для некоторых приемов даются общие рекомендации. Для различных условий один и тот же результат может достигаться различными способами. Это скорее общие принципы работы, чем конкретные действия.


Последовательное выполнение общих свойств фактически реализует цикл улучшения бизнес-процессов (Buisness-process Improvement -BPI -см. Рис. 5. ), т.е. непрерывное улучшение бизнес-процессов (БП).

Рис. 5. Цикл непрерывного улучшения бизнес-процессов по модели CMM и ISO 9000:2000.


Желание получить сертификат соответствия в самые короткие сроки вынуждает консалтинговые компании и специалистов, занимающихся управлением качества, использовать гибкость и рамочность требований всех перечисленных высокоуровневых моделей в своих "корыстных" целях.
В результате такого форсирования событий у организации, например, получившей сертификат по ISO 9000:2000, определен только минимально-необходимый набор процессов для соответствия ISO 9001, а не все процессы, которые требуются компании для эффективного функционирования- см. Рис. 2 . Кроме того - уровень детализации процессов может быть не достаточен для четкого понимания того, что творится внутри процессов и кто, за какие задачи внутри процесса отвечает.
В лучшем случае через новые процедуры прошли лишь несколько тестовых проектов и через какое-то время становятся ясным необходимость их корректировки и дополнения. Часто, сразу после сертификации СМК о процессах забывают до следующего наблюдательного аудита, забывая при этом и о затраченных финансовых ресурсах и энтузиазме сотрудников.
И действительно, когда выступаешь в роли независимого аудитора, очень сложно доказать, что принятый уровень детализации процесса явно не достаточен для эффективного функционирования СМК компании. Но и доказать обратное за время, которое выделяется на аудит по ISO 9000, крайне сложно (этим очень успешно можно воспользоваться при оппонировании аудитору). Практика показывает, что быстро построить эффективные процессы даже 3-го уровня зрелости (также, по-хорошему, как и процессы на основе ISO 9000) невозможно.
Для того, чтобы этого добиться, недостаточно просто описать процессы с учетом требований выбранной модели. Самая главная сложность заключается в том, что необходимо перепроектировать культуру производства внутри организации .

И сделать это волевым решением руководства невозможно. Именно поэтому подход, который определен в СMM, просто более жизнеспособен и реалистичен, чем в моделях ISO 9000 -см. Рис. 5 .

Рассмотрим теперь, как на практике можно построить СМК совместимую с обоими моделями.

Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000, в соответствии с оценкой самих авторов CMM {4}, показана на Рис.6 .

Собственно оценка ими проводилась по двум координатам:

    степень обеспечиваемости (в %) соответствия процессов разработки (SWP) уровню зрелости в рамках CMM -"обеспечиваемость" ;

    степень возможности(в %) такой обеспечиваемости, которую дает ISO 9000:2000 - "возможность" .

Как видно из Рис. 6, требованияISO 9000:2000 создают реальную возможность для достижения даже верхнего (CMM Level 5) уровня зрелости SWP.

Однако в смысле уже обеспечения зрелости SWP хотя-бы третьего (CMM Level 3) уровня, СМК по модели ISO 9000:2000 необходимо немного доработать- а именно разработать и внедрить еще две организационные процедуры (Organization process definition and focus) и процедуру общего управления (Integrated softwaremanagement), содержаниекоторых не представляют сложности для любой ИТ-компании.

Но можно и нужно пойти дальше (CMM Level 4) - например, в скобках показана оценка автора этой статьи (в тех-же коорддинатах -обеспечиваемости и возможности), которая соответствует СМК по модели ISO 9000:2000, в которой процессный ландшафт СМК дополнен процессами управления проектами в соответствии с уже требованиями другого упомянутого выше стандарта PM Bok - это поможет вам существенно увеличить зрелость еще таких SWP , как:

    Контроль за ходом выполнения проектов (Software project tracking and oversight);

  • Планирование проектов (Software project planning);

    • Общее управление ПО (Integrated software management);

    Управление процессами через количественные оценки (Quantitative process management).

Рис. 6. Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000

Как видно из Рис.6 ., модель СММ по заложенным в ней принципам очень близка к СМК построенной по стандарту ИСО 9001:2000 и дополненной процессами управления проектами в соответствии с PM BoK ..

Для того, чтобы не делать лишней работы при одновременных сертификации по ISO 9000 и последующей оценке по CMM, я рекомендую при определении ваших производственных процессов включить (а может и ими ограничиться - ведь это для ИТ-компании и есть производственные процессы!) в их число все необходимые в модели CMM KPA. Таким образом компания одновременно:

    выполняет требования ISO 9001:2000 по внедрению процессного подхода;

    документирует все необходимые CMM процессы (KPA );

    реализует при этом ряд таких важных требований ISO 9001:2000 как:

    управление процессами на основе метрик (Quantitative process management);

    управление Поставщиками на основе управления субконтрактами (Software subcontract management);

    анализ требований Потребителей на основе управления требованиями (Requirements management);

    управление человеческими ресурсами на основе Программы обучения персонала (Training program);

    управление коммуникациями на основе создания формальных моделей организационных процессов (Organization process definition);

    запускает механизм улучшения (Plan-Dо-Check -Action) всех описанных процессов (SWP) посредством последовательной реализации всех пятиих Common Features -см.Рис. 5.

Таким образом, если в качестве БП использовать KPA CMM и использовать для процедур управления проектами разработки ПС требования PM BoK, то построенная таким образом СМК, может вполне быть оценена на CMM Level 4 - см . Рис. 7.



Рис. 7. Cхема достижения CMM Level 4 при совместном использовании модели СМК по ISO 9000 и руководства PM BoK 2000.

В заключении, исходя из соображений наглядности (в стилизации автора), представляю схему функционирования СМК ИТ-компании при последовательном внедрении моделей ISO 9000 и CMM - см. Рис. 8.


Рис. 8. Схема функционирования СМК при последовательном внедрении моделей ISO 9000 и CMM (стилизация автора)

Здесь важно понять, что и СММ и ISO 9001:2000 сами по себе являются всего лишь инструментами для непрерывного улучшения деятельности.

Таким образом, сертификация по стандарту ИСО 9001:2000 и подтверждение сертификата должны способствовать росту именно качества процессов компании, где критерий оценки роста качества процессов - выход предприятия на новый уровень BPI, то есть оценка их уже по модели именно CMM {3}.

Литература

    "Оценка качества Програмных средств", В. Липаев, Синтег, 2001 г.

    ISO 9001:2000. Система менеджмента качества. Требования.

    Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model for Software (SW-CMM), version 1.1. // CMU/SEI-93-TR-024, - Februaru, 1993.

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

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

История возникновения СММ такова. В конце 80-х гг. прошлого века Министерство обороны США заказало Институту программной инженерии 1англ. SEI - Software Engineering Institute Университета Карнеги-Меллон работу по созданию системы критериев для выбора субподрядчиков в проектах разработки программного обеспечения. Работа была закончена в 1991 г., и результатом ее стала модель CMM . Нужно сразу оговориться, что модель не содержит никаких финансово-экономических, политических, организационных критериев выбора субподрядчика, равно как и критериев возможности допуска к секретным работам (вероятно, такие задачи и не ставились). Речь идет только о критериях, описывающих способности потенциального субподрядчика в части разработки программных систем.

Структура CMM

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

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

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

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

Таким образом, уровни образуют "лесенку", по которой подымается организация по мере собственного развития. Каждый уровень характеризуется определенными составом и свойствами процессов организации. "Лесенка уровней" СММ получила широкое признание и распространение. Вот как она выглядит.

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

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

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

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

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

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

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


Рис. 7.1.

На рис. 7.1 присутствуют следующие понятия.

Группа ключевых процессов . Как говорится в (Paulk, и др., 1995), "каждая группа ключевых процессов определяет блок связанных работ , в результате выполнения которых достигается совокупность целей, значимых для повышения продуктивности производственного процесса. Например, для группы ключевых процессов " Управление требованиями " (см. рис. 7.2) цель состоит в том, чтобы согласовать требования, выдвигаемые к проекту разработки ПО заказчиком и разработчиком".

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


Рис. 7.2.

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

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

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

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

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

Обязательства по выполнению

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

Необходимые предпосылки

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

Выполняемые операции

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

Измерения и анализ

Раздел "Измерения и

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

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

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

Взгляд на деятельность по управлению ИТ, при котором вместо процессов рассматриваются их составляющие - ключевые практики, а процессы присутствуют только виртуально, как что-то, что может быть построено из ключевых практик, выглядит на первый взгляд несколько экзотично. До сих пор задача совершенствования управления ИТ решалась внедрением готовых процессов из эталонной процессной модели. Теперь же возникает множество уровней, содержащих разрозненные (т. е. не объединенные в процессы) ключевые практики, и рекомендуемая последовательность продвижения по уровням. Управление ИТ, согласно CMM , совершенствуется по мере продвижения на более высокий уровень зрелости. Что же происходит при таком продвижении?

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

В ноябре 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 не несет ответственности за его содержание.

Модель зрелости возможностей CMM (Capability Maturity Model) предлагает

различного уровня. Для этого определяются 3 уровня элементов: уровни зрелости организации (maturity levels) , ключевые области процесса (key process areas) и ключевые практики (key practices) . Чаще всего под моделью CMM имеют в виду модель уровней зрелости. В настоящий момент CMM считается устаревающей и сменяется моделью CMMI (см. ниже).

o Уровни зрелости. CMM описывает различные степени зрелости процессов в организациях, определяя 5 уровней организаций.

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

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

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

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

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

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



􀂃 К первому уровню не предъявляется никаких требований.

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

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

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

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

o Ключевые практики. Ключевые области процесса описываются с помощью наборов ключевых практик. Ключевые практики классифицированы на несколько видов: обязательства (commitments to perform), возможности (abilities to perform), деятельности (activities performed), измерения (measurements and analysis) и проверки (verifying implementations). Например, управление требованиями связано со следующими практиками.

􀂃 Обязательство. Проекты должны следовать определенной политике организации по управлению требованиями.

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

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

􀂃 Измерение. Производится периодическое определение статуса требований и статуса деятельности по управлению ими.

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

Таблица 4 суммирует информацию о количестве практик различных видов, приписанных к разным ключевым областям процесса.

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

Таблица 4. Количество ключевых практик в разных областях процесса по CMM версии 1.1.

Модели жизненного цикла

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

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

Наиболее широко известной и применяемой долгое время оставалась так называемая каскадная или водопадная (waterfall) модель жизненного цикла, которая, как считается, была впервые четко сформулирована в работе и впоследствии запечатлена в стандартах министерства обороны США в семидесятых-восьмидесятых годах XX века. Эта модель предполагает последовательное выполнение различных видов деятельности, начиная с выработки требований и заканчивая сопровождением, с четким определением границ между этапами, на которых набор документов, созданный на предыдущей стадии, передается в качестве входных данных для следующей. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла. «Классическая» каскадная модель предполагает только движение вперед по этой схеме: все необходимое для проведения очередной деятельности должно быть подготовлено в ходе предшествующих работ. Выработка системных требований Выработка требований к ПО Эксплуатация

Тестирование

Кодирование

Проектирование

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

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

Эксплуатация

Тестирование

Кодирование

Проектирование

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


Рис. 6.1. Примерная архитектура авиасимулятора


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

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

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

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

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

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

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

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

· IEEE 1016-1998 Recommended Practice for Software Design Descriptions (рекомендуемые методы описаний проектных решений для ПО).

· IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems (рекомендуемые методы описания архитектуры программных систем).

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

Это определение, в отличие от данного в начале этой лекции, делает акцент не на наборе структур в основе архитектуры, а на принципах ее построения. Стандарт IEEE 1471 определяет также представление архитектуры (architectural description) как согласованный набор документов, описывающий архитектуру с точки зрения определенной группы заинтересованных лиц с помощью набора моделей. Архитектура может иметь несколько представлений, отражающих интересы различных групп заинтересованных лиц.

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

Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы для решения таких задач, как следующие.

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

Как правило, менеджмент качества программных проектов основывается на знаниях из трех источников:

Программный инжиниринг (ACM, IEEE);

Менеджмент проекта (PMI);

Качество (ASQ).

Институт программного инжиниринга (SEI, Software Engineering Institute) в Университете Карнеги Мэллон объединяет все эти три источника.

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

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

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

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

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

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

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

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

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

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

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

Действия, формирующие процесс построения организационной структуры, включают документирование и сопровождение описательных характеристик жизненных циклов разработки ПО. Цель интегрированного программного менеджмента области КРА на уровне 3 заключается в том, чтобы объединить программный инжиниринг и управленческую деятельность в логически последовательный определенный процесс разработки ПО, полученный в результате адаптации стандартного процесса разработки ПО в данной организации и связанных с ним ценных свойств процесса, описанных в "Определении процесса на уровне его структуры".

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

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

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

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

Определенный - указывается "способ, требуемый для выполнения дела";

Документированный - разработан таким образом, что может быть известным и используемым в дальнейшем;

Изученный - обучение на основе документации;

Практичный - может применяться на практике, а не откладываться в "долгий ящик";

Поддерживаемый - доступный, пересмотренный и улучшенный;

Контролируемый - изменения одобрены "участниками совместного дела";

Верифицирован - процесс выполняется корректно;

Проверен - выполняется именно тот процесс, который необходим;

Измеренный - оцененная производительность применяется в качестве базиса для контроля и улучшения процесса;

Способность к улучшению - гибкость и способность к изменениям.

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

Первое появление широко распространенного ПО датируется 1890 годом. Именно в это время в Американских центрах по проведению переписи населения появились перфокарты Германа Холерита (1860-1929 гг.), Массачусетский технологический институт, Кембридж, штат Массачусетс.

В это же время произошел первый перерасход средств по вине "компьютеров". Результаты центров по проведению переписи населения США изначально были протабулированы с помощью вспомогательных механических средств; механических табуляторов Германа Холлерита. В это же время и начало развиваться производство перфокарт. Средства, затраченные на табуляцию данных центров переписи населения, на 98 % превышали аналогичные затраты, понесенные в прошлом. Отчасти это объясняется тем, что шаблон, используемый при табуляции данных, был разработан весьма подробно и объем табулированных данных превышал минимально необходимое количество. Хотя и сам процесс табуляции был значительно ускорен. В это же время появились перфокарты, считывание которых выполнялось электрическим способом.

Возвращаясь к модели СММ, отметим, что на уровне 2 процесс разработки ПО можно представить в виде набора "черных ящиков" с определенными контрольными точками (стадиями). Как показано на рис. 2.1, требования включаются в состав процесса и плавно "перетекают" в набор из "черных ящиков".

Рис. 2.1. Процесс уровня 2

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

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

Рис. 2.2. Процесс уровня 3

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

1) область действия организационного процесса;

2) определение организационного процесса;

3) инжиниринг программных продуктов;

4) комплексный менеджмент ПО;

5) взаимодействие между группами;

6) экспертные оценки;

7) учебная программа.

На уровне 3 процесс разработки ПО осуществляется на основе хорошо определенного процесса. Требуется осознание ролей и ответственности в ходе осуществления процесса. Процесс производства программного продукта отображается в ходе выполнения программного процесса.

Уровень 4 (рис. 2.3), т.е. "управляемый", включает две области КРА: количественный менеджмент процессов и управление качеством ПО.

Рис. 2.3. Процесс уровня 4

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

На уровне 5 ("оптимизация") области КРА сосредоточены на стадиях менеджмента изменений технологии, менеджмента изменений процесса и предотвращении дефектов. Благодаря непрерывному улучшению процесса осуществляется количественная обратная связь по отношению к процессу разработки программ. На этом уровне в организации могут апробироваться новые идеи и технологии, позволяющие улучшить качество программного продукта, что схематически изображено на рис. 2.4.

Рис. 2.4. Процесс уровня 5

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

1) процесс должен соответствовать культурным традициям организации;

2) менеджмент обязан способствовать повышению степени культуры;

3) культура должна способствовать внедрению ролевых моделей и наград.

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


Рекомендуем также