Реферат: Технологический процесс разработки программного обеспечения
Курсовая работа
Технологический процесс разработки программного обеспечения
Киев 2008
Содержание
1. Введение
2. Понятие технологического процесса в организации
2.1 Компоненты технологического процесса организации
2.2 Компоненты технологического процесса проекта
3. Организационная структура и роли в технологических процессах
4. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения
5. Методы оценивания технологической зрелости
6. Внутренняя структура уровней зрелости
7. Иерархия оценок зрелости ТП по модели СММ
Заключение
1. Введение
Надежды организаций-разработчиков ПО на рост производительности труда и качество создаваемого программного продукта, связываемые с внедрением новых методологий и технологий, не оправдались. Разработчики ПО пришли к выводу, что их основные проблемы коренятся в неспособности эффективно управлять процессом разработки ПО. Даже самые хорошие методы и инструменты не могут быть рационально использованы в рамках недисциплинированного, хаотического проекта. Качество программного продукта остается непредсказуемым, так как нет объективного базиса для его достижения. Изменить ситуацию можно только в результате создания инфраструктуры для поддержки процесса эффективной программной инженерии и сопровождения.
Для построения такой инфраструктуры организации-разработчики должны иметь:
а) средства оценивания их способности успешно выполнять технологический процесс (ТП) разработки ПО;
б) руководства по улучшению возможностей своего ТП.
Заказчикам же нужны средства эффективной оценки возможности разработчика выполнить договор на разработку ПО, поскольку они постоянно сталкиваются с программными продуктами, сделанными с опозданием, превысившими начальную стоимость или не работающими надлежащим образом.
2. Понятие технологического процесса в организации
Технологический процесс разработки ПО (ТП) (software process) — это множество направлений деятельности, методов, практических приемов и процедур, используемых для разработки и сопровождения ПО и связанных с ним продуктов (например, планов проекта, проектных документов, кода, тестов и руководств пользователя).
Рассматривают:
технологический процесс организации (ТПО);
технологический процесс программного проекта (ТПП).
Описание стандартного (базового) ТП организации(standard software process) служит основой для определения ТП проектов. Это описание указывает на элементы стандартного процесса, которые должны включаться в ТП программных проектов, а также взаимосвязи между элементами ТП. Оно обеспечивает согласованность выполнения работ в организации, стабильность процессов и фундамент для их улучшения.
ТП должны разрабатываться исопровождаться так же, как разрабатываются и сопровождаются программные продукты.
С каждым ТП связываются:
требования к процессу, которые указывают, “что” собой представляет процесс (что он будет делать);
архитектура процесса, которая описывает, “как” процесс будет определен (каковы будут элементы процесса и как они будут взаимосвязаны);
описание (проект) техпроцесса в рамках организации или программного проекта (создание элементов процесса и установление интерфейсов);
проверка и утверждение (validation) определения процесса (путем измерения его характеристик);
внедрение процесса в среду разработки ПО, для которой он был разработан (завершение технологической подготовки разработки ПО и обеспечение технологической готовности организации к выполнению работ по проекту).
Основные элементы описанной концептуальной модели разработки ТП представлены на рис.1 и описаны ниже.
Техпроцессы проектов разрабатываются путем настраивания стабильного и гибкого стандартного ТП организации на характеристики конкретного проекта.
2.1 Компоненты технологического процесса организации
Основные компоненты ТП организации таковы:
архитектура ТП;
элементы ТП;
описания жизненных циклов (ЖЦ) ПО, рекомендованных для использования в организации;
руководства и критерии для настройки стандартного ТП организации;
база данных (БД) ТП организации;
библиотека документации, связанной с процессом разработки.
Компоненты ТП открыты для использования проектами при разработке, сопровождении и реализации собственных ТП проектов. Организация может группировать компоненты ТП разными способами в зависимости от подхода к формированию стандартного ТП. Например, описание ЖЦ ПО может быть интегральной частью стандартного ТП организации. Другой пример — часть библиотеки документации, относящейся к ТП, может храниться в БД ТП организации.
Архитектура ТП — это описание стандартного ТП организации, касающееся приоритетов, интерфейсов, взаимозависимостей и других взаимоотношений между элементами стандартного ТП организации и других внешних по отношению к нему процессов (например, системной инженерии, инженерии аппаратного обеспечения и др.).
Элемент ТП — это составной элемент описания ТП, который охватывает четко определенное, ограниченное и связное множество задач (например, оценивание ПО, проектирование ПО и др.). Описания элементов ТП могут представлять собой:
шаблоны (template), подлежащие заполнению;
фрагменты, требующие укомплектования;
описания, выполненные на высоком уровне абстракции и нуждающиеся в уточнении;
полностью сформированные описания, которые могут быть модифицированы или использованы без изменений.
/>
Рис.1. Концептуальная модель ТП
Описание жизненных циклов ПО, рекомендованных к использованию — это набор описаний адаптированных к нуждам организации моделей ЖЦ ПО. По согласованию с заказчиком или пользователем конкретного проекта одна из этих моделей должна быть использована в сочетании со стандартным ТП при построении ТП проекта.
Руководства и критерии настройки ТП организации призваны помочь руководителям проектов ПО выбрать ЖЦ ПО для использования и адаптировать стандартный ТП организации и выбранный ЖЦ ПО к характеристикам конкретного проекта. Эти руководства и критерии обеспечивают общий базис для планирования, реализации, измерения, анализа и совершенствования процессов разработки ПО проектов.
База данных технологического процесса организации — это БД, предназначенная для сбора и предоставления информации о технологических процессах и полученных в ходе их выполнения рабочих продуктах (релизах), в частности, тех, которые имеют непосредственное отношение к стандартному ТП организации. Эта БД содержит или ссылается как на данные реальных измерений, так и на информацию, необходимую для понимания этих данных и оценивания их обоснованности и применимости (например, оценки размера ПО, трудоемкости и стоимости его разработки, реальные данные о размере, трудоемкости и стоимости ПО, данные о производительности, полноте охвата и эффективности обзоров, о числе и серьезность дефектов, обнаруженных в коде, и др.).
Библиотека документации ТП создается для хранения документов процесса, которые могут быть полезными для других действующих или будущих проектов, особенно имеющих отношение к стандартному ТП организации (это могут быть ТП проектов, стандарты, процедуры, планы разработки ПО, планы измерений ПО и материалы по процессу обучения). Использование фонда библиотеки должно помочь снизить затраты труда на развертывание нового проекта, демонстрируя примеры успешно выполненных проектов, которые могут быть взяты за образец.
2.2 Компоненты технологического процесса проекта
Описание ТП проекта — это используемое проектом операционное определение ТП, изложенное в терминах стандартов ПО, процедур, инструментов и методов. Оно разрабатывается путем настраивания стандартного процесса организации на отражение определенных характеристик проекта. ТП проекта создает базу для планирования, выполнения и улучшения деятельности менеджеров и исполнителей проекта. Проект может иметь более одного ТП (например, для прикладного ПО и ПО тестирования). В то же время, один и тот же ТП может использоваться двумя и более проектами.
Стадии (stages) отражают распределение усилий на разработку ПО. Они имеют регулируемый размер и представляют собой измеримое множество связанных между собой задач, выполняемых проектом. Обычно стадия — это фрагмент ЖЦ ПО, как правило, заканчивающийся формальным обзором, предшествующим началу следующей стадии.
Задача (технологическая операция) (task) — это четко определенная единица работы в техпроцессе, завершение которой представляет собой для руководства проектом видимую контрольную точку для оценки состояния проекта. С задачей связывается критерий готовности (предусловие выполнения) и критерий завершения (постусловие выполнения). Каждая задача предполагает какую-либо деятельность (или действие) (activity), но не каждая деятельность до такой степени четко определена, чтобы рассматриваться в качестве задачи.
Рабочие продукты ПО (software work products) — это результаты деятельности или решения задач в ходе определения, сопровождения или использования ТП, включая описания, планы, процедуры, компьютерные программы и связанную с ними документацию, которые предназначаются (или не предназначаются) к поставке заказчику или пользователю. Рабочие продукты образуют вход для следующего шага процесса или архивную информацию по проекту ПО для использования будущими проектами (например, планы, оценки, данные о реальной трудоемкости, документы требований и др.).
Релизы (продукты ПО) (software products) представляют собой полное множество или любой из отдельных элементов множества компьютерных программ, процедур, данных и соответствующей документации, предназначенных для передачи заказчику или конечному пользователю (IEEE-STD-610). Все релизы являются в то же время рабочими продуктами, но не все рабочие продукты представляют собой релизы.
План разработки ПО. Этот план в виде одного или группы документов образует мост между ТП проекта и конкретной реализацией этого ТП (с указанием исполнителей и графика выполнения задач). Только сочетание точного определения ТП и плана разработки дает возможность реально выполнить технологический процесс.
3. Организационная структура и роли в технологических процессах
Роль — это совокупность обязанностей и сфер ответственности, возлагаемых на одно лицо или группу лиц.
В небольших проектах или организациях допускается совмещение нескольких ролей одним лицом. В крупных проектах роли, особенно руководящие (менеджеры), должны исполняться разными лицами.
1. Менеджеры. Выполняют традиционные функции планирования, обеспечения ресурсами, организации, руководства и контроля исполнения работ, входящих в сферу их ответственности.
1.1 Главный менеджер организации (директор) (senior manager). Один из руководителей организации, отвечающий за жизнеспособность и совершенствование ТП организации и всех ТП проектов.
1.2 Менеджер проекта (руководитель проекта) (project manager). Руководит разработкой программной системы. Несет полную финансовую ответственность за выполнение проекта перед заказчиком.
1.3 МенеджерПОпроекта(project software manager). Несет полную ответственность за все действия, связанные с разработкой ПО проекта. Контролирует ресурсы программирования проекта. Отвечает непосредственно перед менеджером проекта. В крупных проектах менеджер ПО может быть одним (первым) из линейных менеджеров проекта.
2. Разработчики. Непосредственные исполнители (штат) проекта, объединенные в группы (бригады, команды).
2.1 Лидер (software task leader). Возглавляет бригаду разработчиков. Несет ответственность за технические решения. Отвечает перед менеджером ПО.
2.2 Персонал (штат) (staff). Лица, включая лидера, ответственные за выполнение определенных функций в проекте и не являющиеся менеджерами.
3. Группа системной инженерии (system engineering group). Коллектив исполнителей (менеджеры и штат), несущих ответственность за спецификацию системных требований; их распределение по программно-аппаратным компонентам; спецификацию интерфейсов между компонентами; мониторинг проектирования и реализации этих компонентов в соответствии со спецификациями.
4. Группа программной инженерии (software engineering group). Это коллектив исполнителей проекта (разработчиков и менеджеров), несущих ответственность за разработку и сопровождение ПО проекта.
5. Группы поддержки разработки. Коллективы исполнителей (менеджеры и штат), связанных с различными аспектами программной инженерии (например, оценкой качества, управлением конфигурацией и др.), но не несущих прямую ответственность за разрабатываемый продукт.
5.1. Группа процесса разработки ПО (software engineering process group). Коллектив специалистов, занимающихся определением, сопровождением и улучшением ТП организации.
5.2. Группа системного тестирования (system test group). Коллектив исполнителей (разработчики и штат), несущих ответственность за планирование и проведение независимого системного тестирования ПО с целью установления соответствия продукта ПО требованиям. Группа системного тестирования существует автономно от разработчиков проектов, что дает возможность исключить влияние принятых ими проектных и реализационных решений на состав и содержание тестов.
--PAGE_BREAK--5.3. Группа обеспечения (гарантии) качества ПО (software quality assurance group). Коллектив исполнителей (менеджеры и штат), выполняющих планирование и реализацию действий, гарантирующих соблюдение дисциплины разработки в соответствии с шагами ТП и стандартами. С целью снижения риска, связанного с разработкой проектов ПО, группа обеспечения (гарантии) качества ПО получает независимость от конкретных проектов (в частности, от менеджеров проектов) и несет ответственность непосредственно перед главным менеджером организации.
5.4. Группа управления конфигурацией ПО (software configuration management group). Коллектив исполнителей (менеджеры и штат), несущих ответственность за планирование, координацию и реализацию формальных действий по управлению конфигурацией проекта ПО.
5.5. Группа обучения (training group). Коллектив исполнителей (менеджеры и штат), несущих ответственность за координацию и систематизацию деятельности по обучению в организации (подготовка учебных материалов, проведение обучения).
4. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения
Концепцию зрелости техпроцесса организации-разработчика ПО предложил институт SEI (Software Engineering Institute).
Зрелость ТП — это степень четкости (ясности) определения, управления, измерения, контроля и выполнения конкретного ТП. Зрелость свидетельствует, с одной стороны, о мощности (richness) процесса программирования в организации, и, с другой стороны, о степени его применимости (адаптируемости) к проектам организации. Производительность и качество, обеспечиваемые зрелым техпроцессом программирования, могут быть со временем повышены благодаря непрерывному росту дисциплины, достигаемому в результате использования такого процесса.
Зрелость технологического процесса в организации помогает предсказать способности проекта в достижении поставленных целей. С ростом зрелости организации различия между ожидаемыми и получаемыми результатами по проектам уменьшаются.
СММ-модель (от Capability Maturity Model) определяет характеристики техпроцессов, находящихся на определенном уровне зрелости, и указывает направление совершенствования ТП в организации до уровня зрелого упорядоченного процесса.
Такое определение СММ допускает нескольких направлений ее применения, например:
группы аналитической оценки — идентификации сильных и слабых сторон организации;
группы экспертной оценки — идентификация рисков выбора исполнителей проектов и управления работами;
менеджеры и технический персонал — оценка собственных действий по планированию и реализации программы улучшения техпроцесса в организации;
группы улучшения техпроцесса — руководство по определению и улучшению техпроцесса в организации.
СММ — это описательная (descriptive) модель, т.к она описывает существенные (или ключевые) атрибуты, которыми должен обладать процесс программирования в организации, находящейся на определенном уровне зрелости.
В то же время СММ — это нормативная (normative) модель, поскольку рекомендует применение определенных практических приемов. СММ обеспечивает достаточный уровень абстракции и не накладывает ограничений на способы реализации процесса программирования в организации, то есть, в любом контексте применения СММ должна существовать разумная интерпретация практических приемов.
СММ нельзя считать предписывающей (prescriptive) моделью, поскольку она дает ответ на вопрос, какими свойствами должен обладать процесс программирования в организации, имеющей тот или иной уровень зрелости, но не говорит о том, какими средствами обеспечить улучшение процесса и достижение соответствующего уровня.
Достоинства СММ:
основывается на реальных процедурах;
отражает передовую практику программной инженерии и опыт выполнения больших государственных заказов на разработку ПО;
пригодна для совершенствования или оценки процессов разработки ПО;
хорошо документирована;
продолжает уточняться (для нижних уровней) и развиваться (для верхних уровней) по мере приобретения организациями-разработчиками опыта построения зрелого ТП.
Концепция зрелости процесса разработки ПО основывается на интеграции концепций:
технологического процесса разработки ПО (software process)
широты возможностей процесса разработки ПО (software process capability)
результативности процесса разработки ПО (software process performance)
зрелости процесса разработки ПО (software process maturity).
Широта возможностей ТП — это диапазон ожидаемых результатов, достигаемых при выполнении техпроцесса. Оценка широты возможностей процесса программирования в организации — это способ предсказания наиболее вероятных результатов (выхода), которые можно ожидать от любого проекта ПО в рамках организации.
Результативность ТП характеризует реальные результаты, достигнутые благодаря следованию процессу. Результативность конкретного проекта, разрабатываемого в определенных условиях, может не отражать в полной мере широты возможностей процесса в организации, поскольку возможности проекта ограничены его средой (на них влияют, например, изменения технологии, требующие от персонала дополнительной подготовки).
Уровень зрелости (maturity level) организации-разработчика — это четко определенный базис для достижения зрелости процесса разработки ПО, который указывает на степень совершенства (состоятельности) процесса. Уровень зрелости описывает характеристики, которые достигает организация. На каждом уровне сконцентрировано множество целей процесса, которые, в случае их достижения, стабилизируют соответствующий важный компонент (направление) процесса программирования.
Пять уровней зрелости СММ представлены на рис.2. Стрелки на рисунке указывают вид возможностей процесса, который официально утверждается организацией на каждом уровне зрелости. Названия уровней отражают сущность изменений в основном процессе программирования:
/>
Рис.2. Пять уровней зрелости технологического процесса разработки ПО
Каждый уровень образует фундамент для эффективной реализации процессов на последующих уровнях. Пропуск уровней противоестественен. Организации могут с успехом использовать (внедрять) процессы, описанные на вышележащих уровнях, находясь при этом на более низком уровне. Например, такие процессы как анализ требований, проектирование, кодирование и тестирование, не обсуждаются в СММ вплоть до третьего уровня, хотя организации проводят соответствующую работу уже на первом уровне. То же касается и обзоров, которые могут проводиться на 1 или 2 уровне, хотя описаны в СММ на 3 уровне. Однако, эти и другие процессы, не отнесенные, но применяемые на низлежащих уровнях, не могут в полной мере раскрыть свой потенциал, пока не будет создан соответствующий фундамент на нижних уровнях СММ.
Таким образом, СММ идентифицирует уровни, через которые организация должна эволюционировать для утверждения культуры программной инженерии. Организации, находящиеся на 1 уровне и пытающиеся создать фиксированный (defined) процесс (уровень 3), не создав перед тем повторяемый процесс (уровень 2), обычно не достигают успеха, поскольку менеджеры проекта больше всего озабочены проблемами сроков и стоимости проекта. Это основная причина, по которой нужно сначала усовершенствовать процесс управления, а затем процессы собственно инженерии. Может показаться, что определить и реализовать процесс инженерии легче, чем процесс управления (особенно с точки зрения разработчика), но без дисциплины управления процесс инженерии неминуемо скатится к проблемам сроков и стоимости. Способность организации реализовывать процессы с высших уровней зрелости не означает, что уровни зрелости могут быть пропущены.
По мере того, как организация достигает зрелости ТП, она официально устанавливает (учреждает, внедряет) (institutionalizes) этот процесс в виде базового (стандартного) путем принятия соответствующих административных решений, разработки стандартов и создания необходимых организационных структур. Административное оформление ТП влечет за собой создание инфраструктуры и формирование корпоративной культуры, которые призваны обеспечить воплощение в жизнь методов, практических приемов и процедур СММ.
Ключевые направления совершенствования техпроцесса (КРА, от Кey Рrocess Аreas) указывают области, на которых должна сосредоточить внимание организация для улучшения ТП.
КРА сгруппированы по уровням зрелости (табл.1) так, что каждое КРА всегда относится только к одному уровню СММ. Это не означает, что в организации, находящейся на определенном уровне зрелости, не могут выполняться процедуры в рамках направлений, относящихся к другим уровням зрелости. Заключение о том, какой уровень зрелости занимает организация, делается только по КРА, соответствующим данному уровню.
Таблица 1 Характеристика уровней зрелости технологического процесса разработки ПО
Уровень зрелости
Характеристика уровня зрелости
Ключевые направления совершенствования ТП
1. Начальный
Отсутствует стабильная среда разработки и сопровождения. Техпроцесс разработки неструктурирован и хаотичен. Бюджет, сроки и качество разработки непредсказуемы. Частые авралы. Успех проекта определяется способностями отдельных исполнителей или менеджера, а не организационной структурой коллектива.
По оценкам SEI около 75% фирм-разработчиков ПО (за рубежом) находятся на этом уровне зрелости. Это же касается и подавляющего большинства отечественных организаций-разработчиков. Начальный уровень включен в модель с целью образования точки отсчета (базы) для оценивания последующих улучшений процесса на более высоких уровнях модели
2. Повторяемый
Управление проектом нацелено на контроль соблюдения планов по стоимости, срокам и функциональности разработки ПО. Процесс программирования упорядочен. Применяются неоднократно отработанные приемы управления для схожих проектов. Разработка новых проектов ведется на основе ранее накопленного опыта и в соответствии со стандартами в части определения исходных требований, управления конфигурацией, планирования и оценки качества ПО
Управление требованиями
Планирование проекта ПО
Мониторинг проекта ПО
Управление работой соисполнителя
Обеспечение качества ПО
Управление конфигурацией ПО
3. Фиксированный
Процесс программирования документирован, стандартизован и интегрирован в стандартный (базовый) техпроцесс. Внедрена программа обучения разработчиков ПО и менеджеров. Коллективы отдельных проектов следуют стандартизованному техпроцессу разработки в организации и настраивают его для достижения целей конкретного проекта
Обеспечение разработки техпроцессов
Определение техпроцесса организации
Организация обучения персонала
Интегрированное управление проектом ПО
Инженерный подход к разработке ПО
Межгрупповая координация
Коллективный просмотр
4. Управляемый
Достигается цель количественной оценки качества продуктов ПО и процессов разработки в рамках единой программы измерения. Осуществляется сбор и анализ данных по проектам, что дает возможность управлять риском проекта и “возвращать" процесс в установленные рамки
Управление техпроцессом на основе количественных оценок
Управление качеством ПО
5. Оптимизируемый
Непрерывное улучшение техпроцесса на основе количественной оценки его слабых и сильных сторон. Данные об эффективности процесса разработки используются для анализа в целях перехода на новые технологии и совершенствования процесса разработки в организации. Данные о новых приемах инженерии изучаются и распространяются по организации. Коллективами проектов производится причинно-следственный анализ ошибок в проектах
продолжение--PAGE_BREAK----PAGE_BREAK--
(например, военного назначения)
Масштабность:
Продолжительность
Количество исполнителей
объем продукта
степень повторного использования
(в месяцах)
(количество человек, принимающих участие в разработке)
(объем ПО в строках исходного кода)
___% исходного кода, ___% модифицированного кода, __% повторно используемого кода
Примечание (например, большое количество COTS — большие затраты на разработку)
Долевое участие в работе
(например, головной исполнитель, все виды работ и др.)
Организационный подход
(например, временный трудовой коллектив, интегрированная бригада и др.)
Язык (и)
используемые языки (среды) программирования
Заказчик
наименование организации-заказчика
Применяемые стандарты
(группа применяемых отечественных и международных стандартов)
Наличие соисполнителей
(да/нет, количество организаций-соисполнителей)
Новизна
(например, в замен действующей системы)
Платформа функционирования
характеристика аппаратной, программной и телекоммуникационной среды
Другие требования
Отв. исполнитель проекта: (ФИО) _____ Подпись
Рабочий телефон __________________ Дата _______________
Шаг 2. Организация-заказчик рассылает претендентам на роль исполнителей форму паспорта и контрольный опросник;
Шаг 3. Организация-претендент, ознакомившись с проектом паспорта заказываемого продукта, подбирает несколько (но не менее трех) завершенных или находящихся в стадии завершения проектов, разработанных в данной организации и схожих с предлагаемым к разработке;
Шаг 4. Разработчик проекта заполняет паспорт разработанного (разрабатываемого) продукта по форме паспорта и отвечает на все вопросы контрольного опросника (приложение 1). Ответы на вопросы по каждому направлению проставляются посредством отметки (знак "+" при ручном заполнении формы или число “1” при машинном заполнении) в соответствующих колонках интервальной шкалы;
Шаг 5. Организация-претендент отсылает заполненные паспорта и контрольные опросники организации-заказчику;
Шаг 6. Эксперт организации-заказчика обрабатывает все паспорта и контрольные опросники организации-претендента и определяет уровень зрелости организации.
Обработка контрольных опросников для получения оценок включает выполнение следующих действий:
каждой оценке присваивается эквивалентный числовой коэффициент (табл.1)
Таблица 1
Оценка
Коэффициент
Почти всегда
1
Часто
0.75
Иногда
0.5
Редко
0.25
Никогда
обрабатывается один опросник для одного проекта: подсчитывается количество ответов по каждой оценке одного направления ТП (количество отметок “+” или “1” в столбце). Это количество ответов умножается на соответствующий коэффициент (см. табл.1) и вычисляется их сумма. Затем эта сумма делится на количество вопросов, касающихся данного направления (приложение 1) и умножается на 100% (для получения оценки достижимости целей направления в процентах).
Ниже приведен пример заполнения опросного листа по направлению “Управление требованиями” и оценка уровня достижимости целей по данному направлению. Соответствующий опросный лист содержит 6 вопросов. Пример заполнения опросного листа приведен в табл.2. Вычисленная оценка КРА по ответам на вопросы по данному направлению составляет.
(2*1 + 1*0.75 + 1*0.5 + 2*0) / 6 = 0.54
или в процентном отношении — 0.54*100% = 54%
Процедура повторяется по всем шести направлениям, представленным в опроснике;
3) подобным образом обрабатываются ответы на вопросы по всем проектам;
4) по завершении обработки опросных листов оценки по каждому направлению для всех проектов усредняются. Усредненная оценка направления по всем проектам вычисляется как медиана частных оценок. Например, если в результате обработки вопросов по первому направлению для пяти проектов были получены такие оценки: 54 58 75 79 80
то медианой ряда будет значение 75 и это будет средняя оценка данного направления по представленным проектам.
5) полученные суммарные оценки проектов в процентах по каждому направлению заносятся в итоговый отчет по форме, представленной в табл.3.
6) для расчета уровня зрелости Lзр организации применяется формула:
Lзр = 2/6 * {åi=1 [ (КPA%i) /100] }
где КРАi — полученные суммарные оценки проектов в процентах.
Таблица 2
Управление требованиями
Почти всегда
Часто
Иногда
Редко
Никогда
Не используется
1. Используются ли системные требования, делегированные ПО, в качестве основы для выполнения разработки и управления процессом разработки?
+
2. Выполняется ли корректировка планов ПО, рабочих продуктов и действий при изменении системных требований, делегированных ПО?
+
3. Руководствуется ли проект принятой в организации политикой в части управления системными требованиями, делегированными ПО?
+
4. Прошли ли лица, которым поручено управление делегированными требованиями, обучение приемам управления требованиями?
+
5. Проводятся ли измерения с целью определения адекватности действий, выполняемых по управлению делегированными требованиями (например, есть ли учет общего числа предложенных изменений в требованиях, числа принятых предложений по изменениям, числа произведенных корректировок в базовой версии и пр)?
+
6. Подвергаются ли действия по управлению требованиями в проекте ревизиям с целью обеспечения качества ПО?
+
Таблица 3 Оценка уровня зрелости по КРА
КРА
Почти всегда
>90% случаев
Часто
60-90% случаев
Почти поровну
40-60% случаев
От случая к случаю
10-40%
Крайне редко
< 10%
Управление требованиями
Планирование проектов ПО
Мониторинг проектов
Управление соисполнителями
Обеспечение качества ПО
Управление конфигурацией
Следует отметить, что чем больше проектов входит в выборку, тем точнее оценка, однако исходя из общего низкого уровня зрелости отечественных организаций разработчиков и сложности сбора информации по большому количеству проектов в одной организации, на данном уровне применения методики допустимо ограничить число проектов тремя.