контракта. По истечении первого года, после нескольких усовершенствований в интерпретации, автоматизации, представлении и определении ощущалась практически единодушная поддержка. Все стороны использовали объективные данные из программы по определению метрик для обоснования своих планов, рисков, направлений разработок и результатов.
Все представленные метрики Подсистемы общего назначения извлекались непосредственно из ежемесячных обзоров по управлению проектом. Ни одно из этих значений не создавалось постфактум. Хотя программа по определению метрик и являлась требованием, содержащимся в контракте, правительство не определило, какие именно метрики должны использоваться. Это было оставлено на усмотрение подрядчика с тем, чтобы команда, выполняющая проект, самостоятельно приняла на себя ответственность за выбранную программу по определению метрик.
Компания TRW сформулировала четыре задачи программы по определению метрик:.
1.
Обеспечение данными для оценки текущих тенденций выполнения проекта и определения того, на что следует обратить внимание при управлении проектом.
2.
Обеспечение данными для планирования последующих этапов и создания других подсистем.
3.
Обеспечение данными для оценки относительной сложности достижения соответствия окончательным требованиям по качеству.
4.
Обеспечение данными, позволяющими определить, какие требуются усовершенствования процесса, и обосновать их необходимость.
Ниже приводятся конкретные примеры метрик, рекомендованных в главе 13. Дается несколько примеров метрик для определения прогресса, а также качественных показателей дефектов, доработок и завершенности. Описываются основы, необходимые для автоматизации; они требуют некоторых интересных технических подходов, которые заключены непосредственно внутри рабочих продуктов, связанных с проектированием и кодированием.
D.7.1 Прогресс разработки.
Точное измерение прогресса разработки при наличии нескольких параллельных видов деятельности, находящихся на различных стадиях, являлось сложной проблемой для команды, управляющей созданием Подсистемы общего назначения. Значительные усилия пришлось затратить на формирование согласованного подхода, который предоставил бы точную информацию относительно состояния на уровне подсистем и состояния версий. Целью было получение взвешенной оценки, в которую включалось бы следующее:.
■ Метрики Ada/ADL. Позволяли довольно точно определять непосредственные показатели технического прогресса. Сами по себе эти метрики абсолютно точно отражали прогресс в разработке и реализации. Однако они плохо подходили для описания завершенных частей контракта и финансового состояния.
■ Метрики добавленной стоимости. Позволяли довольно точно определять финансовое состояние и готовые к поставке заказчику части контракта. Вообще говоря, они являются плохими показателями реального технического прогресса.
Как и в случае большинства других метрик ПО, оба эти подхода изначально давали неточные оценки абсолютного прогресса. Однако они являлись превосходными оценками относительного прогресса, если отслеживались регулярно (в нашем случае — ежемесячно). По мере накопления опыта работы с этими метриками абсолютные оценки постепенно настраивались для предсказания успеха или риска. Общие оценки сводились в единую диаграмму. На рис. D.9 показан итоговый прогресс на самом верхнем уровне для каждой отдельной версии и для Подсистемы общего назначения в целом. Длина заштрихованного участка внутри каждой версии относительно пунктирной линии (относящейся к текущему месяцу) определяет, опережает ли выполнение существующее расписание или отстает от него. Например, на рисунке изображено состояние после 17 месяца: НТ-тестирование версии 2 отстает от графика на один месяц, разработка версии 3 опережает график на один месяц, разработка
Рис. D.9. Общий прогресс разработки.
Подсистемы общего назначения соответствует расписанию, а НТ-тестирование Подсистемы общего назначения отстает от графика на один месяц. Заштрихованные области — это оценка главного разработчика, который объединял ежемесячные значения метрик прогресса с ежемесячными значениями метрик финансового состояния в некую обобщенную (а потому, в некотором смысле, субъективную) оценку.
Ежемесячный сбор значений метрик обеспечивал необходимое для управления детальное понимание прогресса, увеличения объема кода и других показателей, достигнутых на каждой из версий. Метрики собираются по каждой версии и по CSCI с тем, чтобы иметь возможность рассмотрения под различными углами зрения. Менеджеры*каждого отдельного CSCI собирали и оценивали свои метрики, прежде чем они сводились воедино для проекта в целом. Этот процесс являлся объективным, эффективным и осмысленным. Самый нижний уровень оценок TBD_Statements был, конечно, субъективным, однако они определялись наиболее осведомленными людьми: непосредственными разработчиками. Оценки хранились в формате исходного кода. В этом случае возрастала вероятность того, что в данном виде рабочих продуктов будет храниться самая последняя информация. Такой процесс позволял также непротиворечиво и единообразно сравнивать прогресс по различным направлениям проекта.
На рис. D.10 представлены ежемесячные оценки прогресса для Подсистемы общего назначения и для каждой версии. Планируемый объем изменений основывался на грубом средневзвешенном подсчете для каждой версии, выполнявшемся согласно указаниям, данным в разделе D.5.3: 30% объема создается к моменту ПСКП и 70% объема — к моменту КСКП. В целом Подсистема общего назначения практически полностью соответствовала своему плану за одним исключением. Прогресс, достигнутый к моменту ППОП (намного опережая график), отразил неожиданное позитивное влияние инструментария, генерирующего исходный код. С его помощью для САПО было сгенерировано более 50 ООО SLOC.
Соответствие работы планам менялось в зависимости от конкретной версии. Прогресс, достигнутый для Подсистемы и для каждой версии, оценивался ежемесячно внутренним руководством и заказчиком в процессе обзоров управления проектом. Метрики прогресса являлись объективным механизмом и согласованным языком для описания изменений, вносимых в планы и архитектуру, проблем, возникающих при разработке, рисков при составлении графиков и других связанных с управлением аспектов. Объективность такого подхода являлась основной составляющей неантагонистических отношений, установившихся между всеми заинтересованными сторонами.
Все понимали, что, хотя значения метрик были не точны на ранних стадиях жизненного цикла, они были верны. Абсолютные значения редко когда оказывались важными. Более важными являлись относительные тенденции, и по мере развития процесса точность всех метрик возрастала. К моменту ПОП значения метрик стали краеугольным камнем при обмене информацией в рамках проекта.
Рис. D.10. Прогресс в разработке Подсистемы общего назначения D.7.2 Прогресс в тестировании.
Организация, осуществлявшая тестирование, должна была создать тесты интеграции версий и тесты на соответствие требованиям (некоторые НТ-, ФТ- и ОКТ-тесты). Тестирование интеграции версий оказалось менее эффективным с точки зрения выявления проблем, чем ожидалось. ИТВ-тесты должны были содержать полный набор процедур тестирования интеграции — от базовых возможностей до особых граничных условий. Большая часть этой работы, в частности основные потоки, перекрывалась с работами по интеграции для демонстрации. Соответственно, ИТВ-тесты зачастую дублировали подготовку к демонстрациям, что было менее эффективно по стоимости, чем если бы деятельность по подготовке к демонстрациям была совмещена с ИТВ, а ответственность за нее.
возложена на организацию, выполняющую тестирование. В таблице D.6 представлены результаты ИТВ этапа 2, которые отражают интегрированное состояние продукта. Однако на планирование, подготовку и проведение ИТВ было затрачено больше усилий, чем требовалось. Совмещение подготовки к демонстрациям с деятельностью по проведению ИТВ позволило бы меньшему числу сотрудников сделать работу лучше. Такой подход позволил бы увеличить степень интеграции (являясь составной частью работ по подготовке демонстраций) перед проведением повторной проверки и более эффективно выполнить обратное тестирование после проведения повторной проверки с целью убедиться в том, что все предыдущие проблемы разрешены.
<.
Таблица D.6.
Характеристики SCO для ИТВ-тестирования версии 2
Источник проблем | Малый ( < 1 часа) | Умеренный ( < 1 дня) | Большой 0 1 дня) | Всего |
Интерпретация требований | 5 | 5 | ||
Проблемы при независимом тестировании | 3 | 4 | 2 | 9 |
Проблемы с интерфейсами | 9 | 2 | 1 | 12 |
Неправильное выполнение | 1 | 1 | ||
Желательное расширение (это не проблема) | 3 | 3 | ||
Несовместимая конфигурация | 3 | 2 | 5 | |
В сумме | 24 | 8 | 3 | 35 |
Таблица D.7 и рис. D.11 позволяют взглянуть на метрики прогресса с различных точек зрения, которые применялись при планировании и отслеживании программы тестирования в проекте CCPDS-R. На рисунке изображен график зависимости прогресса относительно планируемого для тестирования соответствия требованиям. НТ-, ФТ- и ОКТ-тесты являлись источниками вариантов тестирования, использовавшимися организацией-разработчиком ПО. За НТ отвечали команды разработчиков, но оно должно было проводиться в формальной среде управления конфигурацией и под контролем (визуальным наблюдением) персонала, ответственного за тестирование. ФТ состояло из функционально связанных между собой групп сценариев, которые демонстрировали соответствие требованиям, охватывающим сразу несколько компонентов. ОКТ-тесты позволяли определять такие аспекты соответствия требованиям, которые не могли быть показаны до полного создания системы. Количественные требования к производительности (КТП) охватывали все CSCI.
Формальное НТ-тестирование (проверка на соответствие требованиям, выполняемая в форме независимого тестирования) оказалось более трудным, чем планировалось. Это произошло прежде всего из-за того, что спецификации требований и обзоры проекта оказались перегружены деталями, касающимися разработки, а также процедурами согласования.
Проведение формального НТ-тестирования тщательно контролировалось правительством и заняло чрезвычайно много времени на подготовку обзора. Правительство потребовало использовать подробнейшие процедуры тестирования для множества отдельных деталей проекта, которые на самом деле не следовало рассматривать как требования. В горячке разработки выполнение НТ-процедур редко когда оказывалось доступным за 30 — 60 дней до повторной проверки, как это предусматривал контракт для любых видов тестирования на соответствие требованиям. Процесс формального НТ-тестирования явился одной из основных причин того, что повторные рассмотрения постоянно завершались позже, чем было запланировано.
Таблица D.7.
Работа по проверке соответствия требованиям с помощью различных типов тестов для различных CSCI
Рис. D.11. Прогресс тестирования Подсистемы общего назначения
Тип теста | САС | сс | КВ | тиэ | оод | ввд | ктп | Всего |
Версия 0/1 НТ | 42 | 5 | 47 | |||||
Версия 2 НТ | 11 | 52 | 63 | 15 | 12 | 153 | ||
Версия 3/4/5 НТ | 65 | 62 | 18 | 198 | 46 | 389 | ||
ФТ 1/2 | 131 | 39 | 77 | 94 | 341 | |||
ФТЗ | 32 | 49 | 117 | 42 | 240 | |||
ФТ 4 | 16 | 172 | 219 | 5 | 4 | 6 | 422 | |
ФТ 5/0KT | 5 | 105 | 84 | 42 | 54 | 207 | 46 | 543 |
Всего | 237 | 482 | 622 | 221 | 268 | 259 | 46 | 2135 |
D.7.3 Стабильность.
На рис. D.12 приводится общий уровень изменений базовой конфигурации. Он показывает суммарное количество SLOC, признанных негодными (изъятых из базовой версии для доработки из-за обнаруженного дефекта, для расширения или для внесения другого вида изменений), и число восстановленных SLOC (тех, что были вновь включены в базовую версию с исправлениями, расширениями или какими-то другими изменениями). Скорость выявления дефектов, отличающаяся от скорости их исправления, приводила в результате к пристальному вниманию руководства, к изменению приоритетов при распределении ресурсов и к корректирующим мероприятиям, предпринимавшимся с целью убедиться в том, что отвечающая за тестирование организация (выявляющая дефекты) и организация-разработчик (выполняющая восстановление) находятся в относительном равновесии. В целом ситуация, изображенная на рисунке, относится к чрезвычайно благополучному проекту.
D.7.4 Коэффициент дефектности.
На рис. D.13 общее количество дефектов определяется относительно программной подсистемы в целом. Эта метрика оценивает суммарную дефектность, выявленную в процессе разработки Подсистемы общего назначения, приблизительно как 25% от объема всего продукта. В среднем в индустрии по созданию ПО средний объем дефектов колеблется в диапазоне от 40% до 60%. Начальная базовая конфигурация была создана к моменту ПОП, на 14 месяце. После этого в нее было внесено 1600 отдельных изменений.
Месяц выполнения контракта Рис. D.13. Коэффициент дефектности в Подсистеме общего назначения.
D.7.5 Адаптируемость
Для Подсистемы общего назначения в целом на доработку базовой версии ПО было затрачено около 5% от всего объема работ. Средняя стоимость внесения одного изменения составляла около 24 ч на один SCO. Эти значения позволяют оценить ту легкость, с которой могли вноситься изменения в базовую версию ПО. Уровень адаптируемости, достигнутый в рамках проекта CCPDS-R, был примерно в четыре раза выше, чем для обычных проектов, в которых затраты на доработки на протяжении жизненного цикла обычно превышают 20% от общего уровня затрат.
На рис. D.14 показана средняя стоимость одного изменения в процессе создания Подсистемы общего назначения. К моменту ОКТ было обработано 1600 SCO, касающихся изменения основ конфигурации, что привело к стабильной стоимости одного изменения. Проект CCPDS-R оказался одним из немногих контрпримеров утверждения: «чем более поздние стадии жизненного цикла вы проходите, тем больше дорогостоящих проблем обнаруживаете».
Большинство SCO на ранних этапах (на рис. D.14 они изображены в прямоугольнике с надписью «Изменения в проекте») являлись изменениями, затрагивающими большое число сотрудников и большое количество компонентов (изменения в интерфейсах и архитектуре). Более поздние SCO (обозначены как «Изменения в реализации») обычно касались одного человека и одного компонента. Последний участок кривой отражает нетипичное возрастание дефектов, что стало результатом большого технического предложения о полном изменении набора входящих сообщений для Подсистемы общего назначения. Эта область являлась одной из тех областей, внесение изменений в которые было не таким простым делом, как хотелось бы. Хотя проект был устойчивым и приспособленным к большому числу предусмотренных заранее сценариев внесения изменений, пересмотр всего набора входных сообщений никогда не предполагался, да и проект не был для этого приспособлен.
Рис. D.14. Адаптируемость Подсистемы общего назначения.
D.7.6 Завершенность.
К проекту CCPDS-R предъявлялись особенные требования по надежности, в связи с чем ПО было распределено особым образом. Выполняющая тестирование независимая команда создала автоматизированный набор тестов. Он проводился в неурочное время и испытывал базовую версию ПО по сценариям случайных сообщений. Такая стратегия привела к проведению широкого тестирования в условиях, близких к реальным на протяжении длительного времени. По результатам удалось определить значение MTBF для ПО. Критичные по надежности компоненты, принудительно перенесенные в плане итераций на самые ранние стадии, подвергались наиболее жесткому тестированию на надежность. Результаты показаны на рис. D.15.
Для современных распределенных архитектур такой способ статистического тестирования с одной стороны необходим для обеспечения максимального тестового покрытия, а с другой ~ полезен для обнаружения проблем, связанных с борьбой за ресурсы, тупиками, перегрузкой ресурсов, утечкой памяти и другими ошибками Гейзенберга. Выполнение случайных и ускоренных сценариев в течение длительных интервалов времени (на протяжении всей ночи или выходных) позволяет получить на ранних стадиях понимание общей целостности ресурсов системы.
Рис. D.15. Завершенность Подсистемы общего назначения.
D.7.7 Затраты финансов/работы на отдельные виды деятельности.
В таблице D.8 рассматривается общая подробная структура затрат на Подсистему общего назначения в проекте CCPDS-R. Эти данные были получены из окончательного WBS-набора затрат и структурированы в соответствии с рекомендациями, приведенными в разделе 10.1. Элементы более низкого уровня описываются в таблице D.9.
Здесь необходимо сделать несколько замечаний:.
■ Проценты, указанные в таблице D.8, приблизительно соответствуют процентам, приведенным в главе 10. Однако некоторые из элементов таблицы D.9, касающихся управления, были распределены по нескольким элементам таблицы D.8 для выделения видов деятельности, находящихся на уровне управления проектом.
■ Общие трудозатраты команды, осуществлявшей тестирование, оказались относительно низкими по сравнению с затратами в проектах, использующих традиционный процесс. Основная причина такого положения дел заключается в том, что команда по разработке архитектуры передавала интегрированный программный продукт команде, которая выполняла тестирование и оценку и отвечала прежде всего за тестирование интегрированного продукта.
Таблица D.8.
Финансовые затраты на Подсистему общего назначения по WBS-элементам самого верхнего уровня
WBS-элемент | Затраты (%) | Виды деятельности и рабочие продукты |
Управление и администрирование | 9 | Окончательные планы, административная поддержка, финансовое администрирование, взаимодействие с заказчиком, контракты, общий контроль и руководство |
Спецификация. процесса/продукта | 7 | Технические требования, планы демонстраций и критерии оценки, планы итераций, процесс создания ПО, анализ метрик |
Техническое обеспечение разработки ПО | 11 | Разработка архитектуры, координация сквозного контроля проекта, разработка САС CSCI, определение и оценка метрик, планирование демонстраций и интеграция |
Разработка | 38 | Разработка, тестирование, документирование и сопровождение компонентов приложений |
Тестирование, оценка и внедрение | 24 | Управление версиями; подготовка, проведение и отчет о формальном тестировании; разработка сценария тестирования; управление изменениями; внедрение |
Инфраструктура | 11 | Системное администрирование, программные и аппаратные ресурсы, настройка и интеграция инструментов |
Всего работ по созданию ПО | 100 | Финансовые затраты, в том числе на аппаратные и программные средства (как элемент инфраструктуры), командировочные и другие прямые затраты |
WBS-элемент | Затраты (%) | Виды деятельности и рабочие продукты |
Управление проектом по созданию ПО | 6 | Взаимодействие с заказчиком, контракты, администрирование |
Техническое обеспечение разработки ПО | 5 | Координаций требований, главный разработчик |
Спецификации | 4 | Разработка СТПО CSCI |
Демонстрации | 3 | Планы, интеграция, отчеты |
Инструменты/метрики | 3 | Инструменты, сбор метрик |
САС CSCI | 3 | Промежуточное ПО, 20 KSLOC |
Управление интеграцией и тестированием | 4 | Координация тестирования, управление |
ИТВ-тестирование | 3 | Предварительное интеграционное тестирование |
Таблица D.9. (продолжение) WBS-элементы Подсистемы общего назначения более низкого уровня
WBS-элемент | Затраты (%) | Виды деятельности и рабочие продукты |
ФТ-тестирование | 9 | Планы формального тестирования, тестирование, отчеты |
ОКТ-тестирование | 6 | Планы формального тестирования, тестирование, отчеты |
Управление конфигурацией и контроль среды тестирования | 3 | Управление версиями, интеграция |
Среда | 11 | Аппаратные средства, программные средства, системное администрирование |
Управление разработкой | 5 | Управление приложениями CSCI |
СС CSCI | 11 | Архитектура, системное ПО, 160 KSL0C |
КВ CSCI | 9 | Приложения интерфейса вывода, 70 KSL0C |
ВВД CSCI | 9 | Коммуникационные приложения, 80 KSL0C |
ТИЭ CSCI | 2 | Приложения для тестирования и испытания, 10 KSL0C |
00Д CSC! | 4 | Приложения, содержащие алгоритм выполнения задания, 15 KSL0C |
Всего работ по созданию ПО | 100 | Все затраты, связанные с созданием ПО |
■ В проекте CCPDS-R использовалась эффективная среда, на которую было затрачено 11 % от общих ресурсов.
■ Общее сопровождение (суммарные затраты на доработки) обошлось всего в 5% от общих затрат. Это не отражено явно в таблицах, но отслеживалось по отдельным CSCI WBS-элементам.
Чтобы сравнивать изменяющиеся уровни производительности абсолютно унифицированным способом, можно сопоставлять затраты на различные CSCI друг с другом так же, как и с другими метриками. При подобных сравнениях необходимо делать поправку на понимание руководством некоторых субъективных атрибутов, таких как конкуренция между командами, изменчивость требований, сложность конкретного CSCI и других факторов, не поддающихся сравнению.
WBS самого верхнего уровня практически совпадает с рабочими процессами, описанными в разделе 8.1, и с распределением работ, рекомендованным в таблице 10.2.