на сегодняшний день для.

оценки стоимости ПО используется несколько различных моделей. Одной из самых популярных, открытых и хорошо документированных моделей оценки стоимости ПО является СОСОМО (Constructive COst MOdel — конструктивная модель стоимости), разработанная Барри Боэмом. Эволюция СОСОМО отражает то, каким образом эволюционировала экономика ПО последние 20 лет.

Оценочные уравнения СОСОМО имеют следующую форму:

где.

Работа — количество человеко-месяцев С1 — масштабирующий коэффициент.

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

Размер — размер конечного продукта (кода, созданного человеком), измеряемый в исходных инструкциях (DSI, delivered source instructions), которые необходимы для реализации требуемой функциональной возможности.

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

Время — общее количество месяцев.

С2 — масштабирующий коэффициент для сроков исполнения.

Р2 — показатель степени, который характеризует инерцию и распараллеливание, присущие управлению разработкой ПО.

В.1 СОСОМО.

Исходная модель СОСОМО [Boehm, 1981] явилась прорывом в разработке ПО в начале 1980-х гг. — частично из-за присущей ей технологической составляющей, но прежде всего потому, что она представляла собой четко определенную схему взаимодействия для достижения соглашений и установки приоритетов, касающихся управления ценой и сроками создания ПО. Будучи наивным студентом последнего курса UCLA, я впервые столкнулся с моделью СОСОМО в качестве предмета нового курса, читаемого Боэмом для выпускников. Одновременно я работал в компании TRW в качестве ведущего разработчика над проектом, который требовал большого объема программирования и для которого необходимо было спланировать и обосновать оценки стоимости и сроков создания ПО. Огромным преимуществом модели СОСОМО являлось то, что она позволяла получать оценку, подводить под нее заслуживающее доверия основание, судить о ее сильных и слабых сторонах и вести переговоры с заинтересованными сторонами. С тех пор я использовал модель СОСОМО для обоснования технологических нововведений, усовершенствований процесса, изменений в архитектуре проекта и новых подходов к управлению. В процессе этой работы я стал экспертом в области ее сильных и слабых сторон и сфер ее применения.

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

Формулы для оценки основных работ и сроков.

Исходные соотношения для оценки стоимости в модели СОСОМО имели следующий вид:.

Обычный вариант

Работа = 3.2*EAF*(Pa3Mep)

Время (в месяцах)= 2.5*(Работа)

Промежуточный вариант

Работа = 3.0*EAF*(Pa3Mep)

Время (в месяцах) = 2.5*(Работа)

Встроенный вариант

Работа = 2.8*EAF*(Pa3Mep)

*

Время (в месяцах) = 2.5*(Работа)

где.

Работа — количество человеко-месяцев.

EAF — результат учета 15 уточняющих факторов (см. таблицу В.1).

Размер — число исходных инструкций конечного продукта (измеряемое в тысячах строк кода).

Множитель, который является уточняющим фактором работ (effort adjustment factor, EAF), представляет собой комбинацию многих параметров. Эти параметры позволяют характеризовать и нормировать проекты относительно проектов, находящихся в базе данных СОСОМО. Каждый параметр оценивается как очень низкий, низкий, номинальный, высокий или очень высокий. Влияние значения каждого параметра определяется как множитель, который обычно изменяется в диапазоне от 0.5 до 1.5. Результат учета этих 15-ти параметров и используется в качестве коэффициента в уравнении стоимости.

Допущения.

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

Таблица В.1.

Параметры модели СОСОМО, характеризующие проект

Описание жизненного цикла.

Жизненный цикл в модели СОСОМО состоит из пяти основных стадий: планирование и определение требований, проектирование продукта, детальное проектирование, кодирование и тестирование отдельных модулей, интеграция и тестирование. Модель СОСОМО дает рекомендации по распределению работ и времени по основным стадиям традиционной «водопадной» модели. Эти рекомендации в некоторой степени зависят от варианта и масштаба; в таблице В.2 приводится стандартное распределение для большого встроенного проекта. Модель СОСОМО позволяет оценить работу и время, необходимые для получения решения (разработки продукта с помощью итераций и тестирования). Затраты на формулировку проблемы (планирование и определение требований) оцениваются в виде дополнительного процента от и сверх работы и времени, затрачиваемых на разработку.

Таблица В.2.

Распределение работ и времени по стадиям жизненного цикла при традиционном походе

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

Таблица В.З.

Стандартное распределение работ по видам деятельности WBS в модели СОСОМО

Типичный вид проекта в модели СОСОМО.

Приведем пример конкретного проекта, чтобы проиллюстрировать скрытый смысл планирования разработки. Представим себе большую, рассчитанную на 100 ООО строк исходного кода (100-KDSI), критически важную систему (например, для управления электростанцией), создаваемую по контракту с правительственной организацией. На рис. В.1 показан вид проекта, оцененный с помощью модели СОСОМО. Эта оценка составляет 900 человеко-месяцев на разработку плюс 72 человеко-месяца на определение требований для данного проекта. Необходимое для выполнения проекта время составит 22 месяца от начала разработки до тестирования плюс 8 месяцев на определение требований.

В. 2 МОДЕЛЬ ADA СОСОМО.

В середине 1980-х гг. компания TRW столкнулась с проблемой перевода нескольких проектов на язык Ada. В одних случаях движущей силой этого перевода служил правительственный заказ. (В этих проектах, как правило, возникало немало трудностей.) В других случаях разработчики проекта были уверены, что технология Ada окажется критичной для конкурентоспособной цены и успешного выполнения. (А эти проекты завершались успешно.) Первый прототип модели Ada СОСОМО был создан мной в рамках внутреннего проекта по исследованию и разработке в 1985 г. Целью этой работы являлось создание схемы, которая позволила бы убедить руководство компании TRW и правительственных заказчиков в том, что финансовый выигрыш от применения языка Ada для определенных широкомасштабных проектов будет весьма значительным и что предложение использовать язык Ada в этих проектах является конкурентоспособной стратегией. Данный подход был также наименее рискованным, обеспечивающим создание системы в срок в рамках бюджета и требуемого качества. (Речь идет о проекте CCPDS-R — система оповещения о запусках ракет очередного поколения, — который представлен в качестве практического примера в приложении D.).

Изначально разработка модели Ada СОСОМО была лишь одним из направлений выполнения триединой задачи:.

1.

Разработать набор компонентов на языке Ada для создания архитектуры, которая позволила бы измерить быстродействие компилятора и получить базовый комплект повторно используемых основных компонентов для управляющих и контролирующих систем типа CCPDS-R.

2.

Разработать описание процесса следующего поколения, который бы использовал итерационный метод и подход с упреждающей разработкой архитектуры, основанный на демонстрациях. Эта Ada-модель процесса [Royce, Walker, 1990b] была огромным шагом вперед по направлению к применению современного процесса в проектах, имеющих отношение к обороне.

Пример: проект размером 100 ООО SLOC, который требует 972 человеко-месяца работы со сроком выполнения 30 месяцев.

Работа

- 900 человеко-месяцев на разработку.

+ 72 человеко-месяца на планирование, определение требований = 972 человеко-месяца суммарно.

Время

- 22 месяца на разработку.

+ 8 месяцев на планирование, определение требований = 30 месяцев

3. Разработать Ada-версию модели СОСОМО для того, чтобы описать выигрыш в затратах денег и времени для новых технологии и процесса.

Результаты этой работы оказались критичными для подхода компании TRW к проекту CCPDS-R, а создание модели Ada СОСОМО стало ключевым при продаже подхода в целом как менеджерам, так и правительственному заказчику. Первоначальная версия была впоследствии формализована в рамках компании TRW под руководством Боэма [Boehm and Royce, Walker, 1988]. Был учтен опыт нескольких других проектов, определены значения параметров и расширена область применения за счет введения понятия параметризованной экспоненты.

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

Соотношения для оценки стоимости в модели Ada СОСОМО имели следующий вид:

Работа = 2.8*EAF*(Pa3Mep)

Время = 2.5*(Работа)

где.

Работа — количество человеко-месяцев.

EAF — результат учета 19 уточняющих факторов работы.

(см. таблицу В.4).

Размер — число исходных инструкций конечного продукта (измеряемое в тысячах строк кода).

Р — показатель степени.

Время — общее количество месяцев.

Множитель EAF по-прежнему представляет собой комбинацию нескольких параметров. Однако в модель Ada СОСОМО были внесены некоторые изменения, отражающие общее усовершенствование модели СОСОМО, эффекты, специфичные для языка Ada, и эффекты от применения итерационного процесса. Это уточнение привело к добавлению двух новых стоимостных факторов (RUSE и SECU), раздвоению одного из факторов (VTRT был поделен на два компонента: относящийся к хосту и к целевой машине) и к появлению нескольких новых диапазонов значений или к изменениям в эффектах, лежащих в основе стоимостных факторов.

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

Таблица В.4.

Усовершенствование уточняющих факторов работы для модели Ada СОСОМО

Одной из критичных стратегий Ada-модели процесса было выделение контрольной точки обзора предварительной разработки (PDR, preliminary design review), которая требовалась в соответствии с применяемым военным стандартом как рассмотрение архитектуры, подкрепленное демонстрацией возможностей. Эта объемлющая цель приводила к нескольким частным стратегиям, которые задействовали способы, инструментарий и технологии Ada-среды:.

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

■ Внимание на ранних стадиях исполняемому «скелету» архитектуры для демонстрации критичных компонентов и системных потоков управления с целью определения рисков.

■ Пошаговый и независимый сквозной контроль компонентов и версий вместо полного критического обзора проекта сразу для всей системы.

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

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

■ Самодокументируемый код на языке Ada и общие описания вместо толстых подробных проектных документов, в которых разработка описывается по мере ее развития.

■ Метрики, автоматически извлекаемые из кода.

Показатель степени в модели Ada СОСОМО имеет диапазон от 1.04 до 1.24 и описывается как комбинация следующих четырех параметров:.

1.

Знакомство с Ada-моделью процесса. Этот уровень зрелости процесса изменяется от значения «знакомство отсутствует» до «успешное применение во многих проектах».

2.

Тщательность проектирования, предшествующего PDR. Этот параметр характеризует уровень детализации проекта, присущий базовому проекту, демонстрируемому при PDR. Он изменяется в диапазоне от «недостаточной тщательности» (20%) до «абсолютной тщательности» (100%).

3.

Риски, от которых удалось избавиться при PDR. Этот параметр оценивает уровень неопределенности, присущий проекту при PDR, после которого начинается полномасштабная разработка. Он изменяется в диапазоне от «недостаточного разрешения рисков» (20%) до «полного разрешения» (100%).

4.

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

Реальный показатель степени в модели Ada СОСОМО определяется суммой значений всех параметров, нормированных от 0.00 до 0.05. Показатель степени для встроенного ПО (1.20) в исходной модели СОСОМО будет соответствовать Ada-модели процесса с значением каждого параметра процесса, равным 0.04 [1.04 + (4 х 0.04)]. В терминах описанных выше параметров это будет соответствовать (1) слабому знакомству с Ada-моделью процесса, (2) некоторой тщательности разработки на стадии PDR (40%), (3) определенному количеству рисков, от которых удалось избавиться к PDR (40%), и (4) частым, но умеренным изменениям требований.

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

В.З СОСОМО и Проект СОСОМО II [Boehm и другие, 1995; Horowitz, 1997] — это работа,.

которая выполнялась в Центре по разработке ПО USC (USC Centre for Software Engineering) с финансовой и технической поддержкой огромного количества промышленных предприятий. (В их число входили AT&T Bell Labs, Bellcore, DISA, EDS, E-Systems, Hewelett-Packard, Hughes, IDA, IDE, JPL, Litton Data Systems, Lockheed Martin, Loral, MDAC, Motorola, Northrop-Grumman, Rational, Rockwell, SAIC, SEI, SPC, TASC, Teledyne, Texas Instruments, TRW, USAF Rome Labs, US Army Research Lab и Xerox.) Проект имел триединую задачу:.

1.

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

2.

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

3.

Создать количественную аналитическую схему для оценки технологий создания ПО и их экономического эффекта.

USC предполагает, что после 2000 г. на рынке ПО будут присутствовать:.

1.

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

2.

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

3.

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

4.

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

5.

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

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

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

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

Рис. В.З Оценки с помощью модели СОСОМО II на протяжении всего жизненного цикла

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

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

где.

Работа — число человеко-месяцев.

E

h — результат применения семи уточняющих факторов ранних этапов проектирования (см. таблицу В.5).

Размер — число функциональных точек (предпочтительно) или KSLOC Р — показатель степени.

Таблица В.5.

Уточняющие факторы на ранних этапах

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

Уравнение для оценки стоимости в постархитектурной фазе имеет вид:

где.

Работа — число человеко-месяцев.

Едрр — результат применения семнадцати уточняющих факторов постархитектурных этапов разработки (см. таблицу В.6).

Размер - количество KSLOC (предпочтительно) или число функциональных точек Р - показатель степени.

Таблица В.б.

Усовершенствованная по сравнению с Ada СОСОМО и СОСОМО постархитектурная модель СОСОМО II

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

0.5 до 1.5. Результат учета этих 17 эффектов и используется при вычислении работы в уравнении стоимости.

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

Модель СОСОМО II использует одну и ту же показательную функцию для моделей ранних этапов проектирования и для постархитектурных моделей. Показатель степени может изменяться в диапазоне от 1.01 до 1.26 и определяется как сочетание влияния следующих параметров:.

1.

Наличие прецедентов у приложения: уровень опыта организации-разработчика в данной области.

2.

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

3.

Разрешение рисков, присущих архитектуре: степень технической осуществимости, продемонстрированной до перехода к полномасштабному производству.

4.

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

5.

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

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

Таблица В.7.

Параметры показателя экспоненциальной функции модели СОСОМО II

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

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

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

В основе данного подхода к определению метрик лежит гипотеза:.

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

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

Большинство из этих материалов было разработано мной в 1987 г. с целью обоснования программы метрик для проекта CCPDS-R (см. приложение D). Данный материал был опубликован [Royce, Walker, 1990] после.

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

С.1 ОБЩИЙ ОБЗОР.

Мой подход к метрикам аналогичен подходу ДеМарко, который предложил определять качество ПО как степень отсутствия в нем брака [DeMarco, 1982]. Для того чтобы можно было использовать его подход вне зависимости от технологии и проекта, его положения преднамеренно неопределенны, мои же — совершенно точны. Согласованное применение важно для правильной интерпретации так же, как в случае со способами оценки стоимости. Оценка стоимости ПО имеет на входе субъективные данные, а на выходе — объективные. Мой подход определяет объективные входные данные, которым потребуется субъективная интерпретация в контексте конкретного проекта.

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

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

Качество ПО.

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

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

Запросы на внесение изменений.

SCO (см. главу 12) определяют направление работ по внесению изменений в сконфигурированный программный компонент. (SCO нередко называют отчетами о проблемах ПО, однако «проблема» подразумевает нечто негативное, а далеко не все изменения предопределяются наличием проблем.) Внесение изменений может понадобиться для доработки низкокачественного компонента (типы 0 и 1, ошибка), для доработки компонента с целью повышения его качества (тип 2, улучшение) или для приведения в соответствие с изменениями в требованиях, внесенными по указанию заказчика (тип 3, изменение в области применения). Различие между ошибкой и улучшением кроется в причине, по которой вносится изменение. Если причиной внесения изменений является повышение эффективности, тестируемости, полезности и др. (предполагая, что компонент обладает достаточным качеством), доработке будет присвоен тип 2. Доработки типа 0, 1 и 2 приводят к повышению качества конечного продукта. Однако типы 0 и 1 указывают также на ненадлежащее качество имеющейся версии. На практике разграничение между типами 0, 1 и типом 2 может быть весьма субъективным. Как следует из дальнейшего обсуждения, большинство метрик не чувствительно к подобному разбиению на категории, но если такая дифференциация применяется последовательно, она может дать некоторую полезную информацию. Метрики изменений типов SCO 0, 1 и 2 собираются и анализируются совместно.

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

Строки исходного кода.

Являются ли SLOC хорошим способом измерения объема ПО, всегда было спорным вопросом, (ДеМарко называет это термином «bang» (громкий шум).) Джонс указывает на некоторые предосторожности, необходимые при работе с SLOC [Jones, 1994]. Он говорит, что «использование.

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

Совет по управлению конфигурацией.

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

Сконфигурированная базовая версия.

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

С.2 ПОЛУЧЕНИЕ МЕТРИК.

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

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

адаптируемости, завершенности и сопровождаемости. Коэффициент дефектности и адаптируемость можно интуитивно определить как функцию переделок; завершенность и сопровождаемость — понятия более тонкие.

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

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

■ Завершенность. Интуитивно завершенность соответствует уровню надежности продукта. Объективно этот параметр определяет уровень дефектов. Целью является полное отсутствие дефектов, т.е. абсолютная завершенность. Доверие возрастает прежде всего благодаря широкому использованию продукта. Поскольку ПО является интеллектуальной собственностью, не имеющей материальной составляющей, оно не подвержено физическому износу. ПО со временем совершенствуется, это означает, что его пользователи (ответственная за тестирование команда, пользователи бета-версии, пользователи окончательной версии) на практике будут все реже сталкиваться с дефектами по мере появления каждой последующей версии продукта. Ожидание того, что с появлением новых версий завершенность будет возрастать, оказывается верным даже в том случае, когда изменения касаются производительности и функциональных возможностей. Аналогично, на протяжении всего жизненного цикла итерационной разработки должны быть хорошо заметны тенденции совершенствования версий. В случае простого показателя количества дефектов потребуется определение количества дефектов (SCO типов 0 и 1) и общего времени использования. На основе этих параметров можно найти среднее время наработки на отказ (MTBF) для данной версии. Чем выше значение показателя завершенности, которое соответствует среднему времени между двумя отказами в восприятии пользователя, тем лучше.

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

получить значение, не зависящее от продуктивности, но вместе с тем отражающее сложность разработки. Это отношение нормализует различия в продуктивности для разных проектов и позволяет получить метрику, подлежащую сравнению. Таким образом, сопровождаемость определяется как отношение продуктивности доработок к продуктивности разработки. Интуитивно понятно, что это значение идентифицирует продукт, эффективность изменения которого в три раза выше, чем эффективность его создания (значение сопровождаемости равно 0.33), как имеющий лучшую (более низкую) сопровождаемость, чем продукт, эффективность изменения которого всего в два раза выше (значение сопровождаемости равно 0.5) эффективности его создания, независимо от абсолютных значений реальной продуктивности сопровождения. Статистика, необходимая для вычисления этих значений,— это суммарные действия, направленные на разработку, суммарное количество SLOC, суммарные действия по доработке и суммарное количество доработанных SLOC.

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

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

С.2.1 Сбор статистики.

Для практической работы с предложенными метриками требуется собирать некоторую специальную статистику на протяжении всего жизненного цикла проекта. Виды этой статистики приведены в таблице С. 1.

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

Таблица С.1.

Виды собираемой статистики

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

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

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

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

Работа (по дефектам) + Работа (по усовершенствованию) = Константа.

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

■ Новые возможности (SCOg). Изменения типа 3 отражают изменение ожиданий заинтересованной стороны каких-либо новых возможностей и функций, выходящих за рамки имеющегося контракта. Статистика изменений типа 3 анализируется отдельно, поскольку она отражает дополнительную работу, а не доработки.

■ Общее количество SCO (N). Поскольку SCO — это абстрактная единица измерения изменений, важно, чтобы она оставалась неизменной для всех областей, метрики которых будут сравниваться. Так каков же уровень, на котором изменения документируются и отслеживаются? В большинстве проектов используется совершенно произвольное определение SCO, зависящее от размера, степени влияния на отдельных сотрудников и на команды и от общей культуры ССВ. Такой произвольный подход будет работать для отдельно взятого проекта, но если в каждом проекте будут применяться разные определения, то сравнение различных проектов окажется невозможным. Вообще говоря, SCO должен иметь отношение к единственному компоненту и передаваться для выполнения одному сотруднику или руководителю команды. Для такого простого стандарта не требуется более точного определения этих составляющих. Даже не столь точно определенные составляющие будут хорошо работать, а более точное определение ничего не добавит. По мере того как автоматизированные средства будут поддерживать все больший и больший набор метрик, общая методика измерений и ее составные части будут становиться все более однородными.

■ Открытые доработки (В). Теоретически любые доработки приводят к повышению качества. Доработка необходима либо для того, чтобы избавиться от «плохого» качества (SCOo и SCOi), либо для того, чтобы расширить компонент, повысив тем самым эффективность затрат на протяжении всего жизненного цикла (SCO2). Для точной оценки тенденции изменения качества доработки должны рассматриваться в контексте текущей стадии жизненного цикла. Определенное количество доработок всегда необходимо при выполнении большого проекта по созданию ПО; доработки на ранних стадиях в современной модели процесса рассматриваются как признак здорового прогресса. Затянувшиеся, поздние и нулевые доработки вследствие отсутствия конфигурированной базовой версии являются в общем случае показателями отрицательного качества. Интерпретировать эту статистику необходимо в контексте проекта. Однако доработки должны, безусловно, достигать нулевой отметки к моменту поставки продукта. Для обеспечения устойчивого процесса сбора статистики, поддающегося автоматизации, доработки можно определить как оценочное число SLOC, необходимое для внесения изменений по каждому SCO. Абсолютная точность оценок обычно не играет важной роли. Поскольку открытые доработки отслеживаются с помощью оценочных данных, а закрытые доработки отслеживаются независимо с помощью фактических данных, значения постоянно самокорректируются и остаются непротиворечивыми.

■ Закрытые доработки (F). Если статистика по дефектам позволяет оценивать объем допущенных ошибок, то статистика по их устранению определяет количество исправленных ошибок. По мере решения проблемы соответствующая оценка дефектов заменяется на реально потребовавшийся объем исправлений, которые остаются в базовой версии. Хотя действительное количество исправленных SLOC (F) никогда не будет абсолютно точным, оно оказывается достаточно точным для оценки тенденций. Поскольку термин «исправленные» может иметь несколько различных значений в зависимости от того, что было добавлено, удалено или изменено, появляется необходимость в создании непротиворечивого набора правил. Измененные SLOC будут увеличивать значения В и F и не будут влиять на SLOC

. Добавленный код увеличит В, F и SLOC

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

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

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

■ Время использования (UT). Этот важный вид статистики соответствует тому количеству часов, которое базовая версия ПО проработала в режиме реальной эксплуатации. Для некоторых систем такой вид статистики собирается с помощью непосредственного измерения времени; для других автоматизированные тесты могут эмулировать использование системы в течение дня с помощью часового теста. Например, для большинства систем обработки транзакций существует средняя ожидаемая нагрузка за день. Если эта средняя нагрузка может быть оформлена в виде некоторого сценария и выполнена данной версией ПО за один час, то это время засчитывается за 24 часа использования. В качестве другого примера представим себе некий инструмент для разработки, используемый человеком и рассчитанный на скорость работы человека — несколько нажатий клавиш в секунду. Если автоматизированные инструменты тестирования GUI в состоянии поддерживать сценарии взаимодействия, которые способны производить тестирование продукта со скоростью в десять раз большей, в этом случае каждый час тестирования засчитывается за десять часов времени использования. Определение соответствия времени тестирования времени использования обычно не вызывает затруднений. Все это является также отличным упражнением по анализу требований, которое зачастую позволяет вскрыть факты различного понимания сценария использования разными заинтересованными сторонами.

С.2.2 Метрики качества конечного продукта.

Метрики качества конечного продукта (см. таблицу С.2) показывают, какова сопровождаемость продукта по отношению к SCO типов 0, 1 и 2. SCO типа 3 не входят в это число, поскольку они переопределяют изначальное целевое качество системы, и обычно для них необходимо больше глобальных системных и программных разработок, а также некоторое переопределение требований уровня системы. Работа с этими типами изменений ведется совершенно разными способами для разных заказчиков в различных проектах, так что они лишь усложняют сравнимость данных.

Следующие метрики чрезвычайно полезны при определении и планировании объемов работ, необходимых для реализации SCO типа 3. Они оказываются также полезными, когда используются для частей продукта, например компонентов или версий. Термин «продукт» применяется для обозначения того, что подвергается измерению.

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

Таблица С.2.

Метрики качества конечного продукта

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

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

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

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

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

работы, отнесенная к SLOC). Простые математические преобразования показывают, что сопровождаемость (или качество сопровождения — Qm) эквивалентно следующему:.

Q

= Продуктивность

/Лродуктивность р

Например, если (Коэффициент брака) = (Коэффициент доработок), то продуктивность внесения изменений равна продуктивности разработки и Q

= 1. Интуитивно понятно, что значение 1 соответствует «слабому» уровню сопровождаемости, поскольку оказывается проще внести изменения в уже существующее ПО, чем разрабатывать альтернативное с самого начала. Тот факт, чтр в традиционных проектах обычно тратится $2 на сопровождение на каждый доллар, затраченный на разработку [Boehm, 1987], может служить в качестве отправной точки при определении того, что является «хорошим» уровнем сопровождаемости. Представим себе некоторую область деятельности, связанную с ПО, со средним временем жизни продукта 16 лет и со средними ежегодными дефектами в размере 12%. Если Q

= 1, то соотношение между затратами на сопровождение и затратами на разработку окажется равным приблизительно 1:2, другими словами, сопровождаемость окажется такой, которая принимается (грубо) за норму в индустрии ПО. Значение сопровождаемости намного меньшее единицы в большинстве случаев означает, что сопровождаемость продукта очень высока, по крайней мере, по отношению к затратам на разработку и к опыту традиционной разработки.

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

С.2.3 Внутренние показатели прогресса.

Определения внутренних показателей прогресса даны в таблице С.З. Ожидаемые тенденции обсуждаются ниже и демонстрируются на рис. С. 1 и С.2.

■ Стабильность доработок. Эта метрика является количественным выражением разницы между общим числом доработок и закрытыми доработками. Ее важность заключается в том, что она показывает, возрастает ли уровень исправлений по мере увеличения уровня брака. На рис. С.1 дается пример благополучного проекта, в котором уровень доработок не расходится с уровнем брака (за исключением коротких периодов времени). Уровень брака должен отслеживаться и по отношению к уровню SLOC

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

Таблица С.З.

Определения внутренних показателей прогресса

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

■ Тенденция изменения коэффициента дефектности. Изменение этого значения показывает, как степень изменений эволюционирует на протяжении жизненного цикла проекта. Общая тенденция позволяет заглянуть внутрь качества (насколько хорошо архитектура приспособлена к локализации изменений) и управления (соответствие графику работ и последовательное изменение рисков). Большая часть тривиальных ошибок отлавливается и исправляется в процессе тестирования отдельных компонентов. Это значение относится к нетривиальным ошибкам, вкравшимся в базовую конфигурацию. Хотя дать количественное определение того, что именно может считаться хорошей тенденцией, довольно трудно, следующее эмпирическое правило выполняется для успешных проектов: среднее количество SCO должно быть эквивалентно размеру отдельного модуля программы (самый низкий уровень независимо компилируемых элементов программы). Например, средний дефект, приходящийся на один SCO для ПО, написанного на языке C++ (в котором размер среднего элемента программы равен приблизительно 50 строк кода), должен составлять по окончании проекта приблизительно 50 строк. Для зрелого процесса итерационной разработки ошибки, допущенные на ранних стадиях (ошибки при разработке,

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

■ Тенденция изменения адаптируемости. Это значение предоставляет механизм для оценки тенденций, которые присущи сложности изменений, в отличие от степени изменений. Если процедура внесения изменений оказывается простой, то число изменений в рамках проекта, скорее всего, будет возрастать, улучшая тем самым его качество. В случае традиционного процесса внесение изменений на поздних этапах жизненного цикла обходится дороже. Целью современного итерационного процесса является достижение такой стройности процесса и архитектуры, которая бы упростила внесение изменений — с более предсказуемым результатом — на поздних этапах жизненного цикла. Доработки обычно стабилизируются, а.

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

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

С.З ИСПОЛЬЗОВАНИЕ МЕТРИК ИЗМЕНЕНИЙ НА ПРАКТИКЕ.

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

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

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

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

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

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

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