В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 10

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

Текст из файла (страница 10)

Процессы жизненного цикла ПО и систем по ISO 15504.Например, приобретение ПО включает такие виды деятельности, как определениепотребности в ПО, определение требований, подготовку стратегии покупки, подготовкузапроса предложений, выбор поставщика.25Группа стандартов IEEE••IEEE 1074-1997 — IEEE Standard for Developing Software Life Cycle Processes [5](стандарт на создание процессов жизненного цикла ПО).Нацелен на описание того, как создать специализированный процесс разработки в рамкахконкретного проекта.

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

Группа деятельностей попроектированию включает архитектурное проектирование, проектирование баз данных,проектирование интерфейсов, детальное проектирование компонентов.IEEE/EIA 12207-1997 — IEEE/EIA Standard: Industry Implementation of InternationalStandard ISO/IEC 12207:1995 Software Life Cycle Processes [6-8] (промышленноеиспользование стандарта ISO/IEC 12207 на процессы жизненного цикла ПО).Аналог ISO/IEC 12207, сменил ранее использовавшиеся стандарты J-Std-016-1995 EIA/IEEEInterim Standard for Information Technology — Software Life Cycle Processes — SoftwareDevelopment Acquirer-Supplier Agreement (промежуточный стандарт на процессыжизненного цикла ПО и соглашения между поставщиком и заказчикам ПО) и стандартминистерства обороны США MIL-STD-498.Группа стандартов CMM, разработанных SEI•Модель зрелости возможностей CMM (Capability Maturity Model) [9,10] предлагаетунифицированный подход к оценке возможностей организации выполнять задачиразличного уровня.

Для этого определяются 3 уровня элементов: уровни зрелостиорганизации (maturity levels), ключевые области процесса (key process areas) и ключевыепрактики (key practices). Чаще всего под моделью CMM имеют в виду модель уровнейзрелости. В настоящий момент CMM считается устаревающей и сменяется моделью CMMI(см. ниже).o Уровни зрелости.CMM описывает различные степени зрелости процессов в организациях, определяя 5уровней организаций.ƒ Уровень 1, начальный (initial).Организации, разрабатывающие ПО, но не имеющие осознанного процессаразработки, не производящие планирования и оценок своих возможностей.ƒ Уровень 2, повторяемый (repeatable).В таких организациях ведется учет затрат ресурсов и отслеживается ход проектов,установлены правила управления проектами, основанные на имеющемся опыте.ƒ Уровень 3, определенный (defined).В таких организациях имеется принятый, полностью документированный,соответствующий реальному положению дел и доступный персоналу процессразработки и сопровождения ПО.

Он должен включать как управленческие, так итехнические подпроцессы, а также обучение сотрудников работе с ним.ƒ Уровень 4, управляемый (manageable).В этих организациях, помимо установленного и описанного процесса, используютсяизмеримые показатели качества продуктов и результативности процессов, которыепозволяют достаточно точно предсказывать объем ресурсов (времени, денег,персонала), необходимый для разработки продукта с определенным качеством.ƒ Уровень 5, совершенствующийся (optimizing).В таких организациях, помимо процессов и методов их оценки, имеются методыопределения слабых мест, определены процедуры поиска и оценки новых методов и26техник разработки, обучения персонала работе с ними и их включения в общийпроцесс организации в случае повышения эффективности производства.o Ключевые области процесса.Согласно CMM, уровни зрелости организации можно определять по использованиючетко определенных техник и процедур, относящихся к различным ключевым областямпроцесса.

Каждая такая область представляет собой набор связанных видовдеятельности, которые нацелены на достижение целей, существенных для общейоценки результативности технологического процесса. Всего выделяется 18 областей.Множество областей, которые должны поддерживаться организацией, расширяется припереходе к более высоким уровням зрелости.ƒ К первому уровню не предъявляется никаких требований.ƒ Организации второго уровня зрелости должны поддерживать управлениетребованиями, планирование проектов, надзор за ходом проекта, управлениеподрядчиками, обеспечение качества ПО, управление конфигурацией.ƒ Организации третьего уровня должны, помимо деятельностей второго уровня,поддерживать проведение экспертиз, координацию деятельности отдельных групп,разработку программного продукта, интегрированное управление разработкой исопровождением, обучение персонала, выработку и поддержку технологическогопроцесса организации, контроль соблюдения технологического процессаорганизации.ƒ К деятельностям организаций четвертого уровня добавляются: управлениекачеством ПО и управление процессом, основанное на измеримых показателях.ƒ Организации пятого уровня зрелости должны дополнительно поддерживатьуправление изменениями процесса, управление изменениями используемыхтехнологий и предотвращение дефектов.o Ключевые практики.Ключевые области процесса описываются с помощью наборов ключевых практик.Ключевые практики классифицированы на несколько видов: обязательства(commitments to perform), возможности (abilities to perform), деятельности (activitiesperformed), измерения (measurements and analysis) и проверки (verifyingimplementations).Например, управление требованиями связано со следующими практиками.ƒ Обязательство.Проекты должны следовать определенной политике организации по управлениютребованиями.ƒ Возможности.В каждом проекте должен определяться ответственный за анализ системныхтребований и привязку их к аппаратному, программному обеспечению и другимкомпонентам системы.Требования должны быть документированы.Для управления требованиями должны быть выделены адекватные ресурсы ибюджет.Персонал должен проходить обучение в области управления требованиями.ƒ Деятельности.Прежде чем быть включенными в проект, требования подвергаются анализу наполноту, адекватность, непротиворечивость и пр.Выделенные требования используются в качестве основы для планирования ивыполнения других работ.Изменения в требованиях анализируются и включаются в проект.27ƒИзмерение.Производится периодическое определение статуса требований и статусадеятельности по управлению ими.ƒ Проверки.Деятельность по управлению требованиями периодически анализируется старшимименеджерами.Деятельность по управлению требованиями периодически и на основании значимыхсобытий анализируется менеджером проекта.Группа обеспечения качества проводит анализ и аудит деятельности по управлениютребованиями и отчитывается по результатам этого анализа.Таблица 4 суммирует информацию о количестве практик различных видов,приписанных к разным ключевым областям процесса.Уровни2345Область процессаОбязательства Возможности Деятельности Измерения ПроверкиУправление требованиями14313Планирование проектов241513Надзор за ходом проекта251313Управление подрядчиками231313Обеспечение качества ПО14813Управлениеконфигурацией151014Контроль соблюдениятехнологическогопроцесса34711Выработка и поддержкатехнологическогопроцесса12611Обучение персонала14623Интегрированноеуправление131113Разработка программногопродукта141023Координациядеятельности групп15713Проведение экспертиз13311Управление процессом наоснове метрик25713Управление качеством ПО13513Предотвращение дефектов24813Управление изменениямитехнологий35812Управление изменениямипроцесса241012Таблица 4.

Количество ключевых практик в разных областях процесса по CMM версии 1.1.•Интегрированная модель зрелости возможностей CMMI (Capability Maturity ModelIntegration) [11,12].Эта модель представляет собой результат интеграции моделей CMM для продуктов ипроцессов, а также для разработки ПО и разработки программно-аппаратных систем.Основные изменения по сравнению с CMM следующие.o Созданы два несколько отличающихся изложения модели — непрерывное и поэтапное.Первое предназначено для облегчения миграции от поддержки американскогоотраслевого стандарта EIA/AIS 713 и постепенного усовершенствования процессов за28счет внедрения различных практик.

Второе предназначено для облегчения миграции отподдержки CMM и поуровневого рассмотрения вводимых практик.o Элементы модели получили четкие пометки о том, являются ли они обязательными(required), рекомендуемыми (expected) или информативными (informative).o Используемые практики разделяются на общие (generic) и специфические (specific).Они дополняются набором общих и специфических целей, которые необходимы длядостижения определенного уровня зрелости в определенных областях процесса.o Некоторые уровни зрелости получили другие названия.

Характеристики

Список файлов книги