1.

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

2.

Были разработаны автоматические инструменты для генерации кода, которые выдавали «многословный» исходный код при меньшем количестве входных строк, написанных людьми. Эти инструменты использовались для прямой генерации форматов вывода, обработки подтверждения сообщений и для функций учета взаимодействий. Сами инструменты состояли из 14 ООО SLOC, и для них потребовалось 20 ООО строк в файлах с входными данными. Выход от этих инструментов составил приблизительно 200 ООО SLOC рабочего ПО. Таким образом, инструменты для генерации кода дали пятикратную отдачу от вложенного в них труда.

Общий рост объема кода приведен в таблице D.10.

Таблица D.10.

Размеры CSCI Подсистемы общего назначения

Главной причиной увеличения числа SLOC явилось изменение правил подсчета. При заключении контракта использовался простой подсчет символов «точка с запятой». Этот подход был перенесен в процедуру подсчета; она была реализована в виде простого инструмента, который использовался всем персоналом проекта:.

■ В рамках той части, которая определялась языком Ada, каждый символ «возврат каретки» считался за одну SLOC. Четыре стандарта кодирования обеспечивали непротиворечивость подсчета строк:.

1.

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

2.

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

3.

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

4.

Инициализация сложных объектов (таких, как записи и массивы) располагается по одному компоненту на каждой строке. Каждое из этих присвоений представляется специально созданным выражением; служебное слово «others» (прочие) обычно используется для стандартных присвоений.

■ Внутри подпрограмм, написанных на языке Ada, каждая точка с запятой принимается за одну SLOC. Общие описания считаются по одной строке на каждый общий параметр.

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

Два компонента послужили причиной изменения определения SLOC. Во-первых, САПО-пакеты в СС содержали сетевые определения, в которые входили все определения процессов, задач, межпрограммных интерфейсов и соединений. В эти пакеты было включено множество определений записей, специально созданных перечислимых типов, а также инициализации полей записей и массивов в спецификациях. Исходный код для этих элементов содержал более 50 ООО символов «возврат каретки», но всего лишь несколько сотен точек с запятой. Поскольку работа над этими пакетами больше была похожа на работу, связанную с написанием 50 ООО SLOC, возникла необходимость в изменениях. Вторым компонентом с аналогичным обоснованием был компонент, содержащий типы глобальных сообщений системы. В этих пакетах содержалось около 300 различных типов записей, представляющих большую часть данных, которыми обменивались между собой САПО-объекты.

Из-за большого разнообразия категорий SLOC, разрабатывавшихся в рамках проекта CCPDS-R, был придуман метод нормализации различных категорий с тем, чтобы можно было правильно распределить бюджет и сравнить продуктивность. В результате появилось расширение метода, предлагаемого моделью СОСОМО для повторного использования; оно называлось эквивалентными строками исходного кода (ESLOC). По существу ESLOC преобразует стандартную для модели СОСОМО единицу измерения SLOC в нормализованную единицу измерения, которая подлежит сравнению на основании работы, затраченной на написание одной строки кода. Необходимость в новой единице возникла при попытке распределения бюджета и анализа продуктивности для случаев, представляющих собой смесь из вновь разработанного, повторно используемого и автоматически сгенерированного кода. Например, компонент размером 10 ООО SLOC, отвечающий за оформление вывода, который автоматически сгенерирован с помощью некоторого инструмента пЬсредством задания 1000-строчного сценария оформления вывода, не должен иметь такого же бюджета, как и вновь разработанный компонент объемом в 10 ООО строк. В таблице D.11 определяется перевод SLOC в ESLOC в проекте CCPDS-R.

Таблица D.11.

Факторы преобразования SL0C в ESL0C

При таких преобразованиях следует учитывать множество факторов:.

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

■ Новое ПО разрабатывается с нуля. Для его создания требуется полный объем работ по проектированию, реализации и тестированию, поэтому ESLOC имеет множитель 100% {преобразование в соотношении один к одному).

■ Код повторно используемых компонентов, которые были разработаны ранее, может применяться в другом компоненте при внесении некоторых изменений. Существует множество способов оценки относительных затрат на повторное использование, и для каждого конкретного случая лучше всего подходит свой собственный. Тем не менее такое преобразование определяется по умолчанию простым эмпирическим правилом. Вообще говоря, повторно используемый компонент требует 50% работ по проектированию, 25% по реализации и 75% по тестированию. Приведение в соответствие с распределением 40/20/40 для нового ПО дает итоговое значение 55%.

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

■ Входные данные для различных инструментов могут принимать самые разнообразные формы. В рамках проекта CCPDS-R использовались входные файлы для определения архитектуры (длинные, но простые таблицы имен, атрибутов и связей), определения вывода (типы выводимых объектов, местоположение и атрибуты) и подтверждения сообщений. Форматы с более высоким уровнем абстракции преобразовывались с затратами 75% работ на проектирование (простые нотации высокого уровня), 50% работ на реализацию (многократно повторяющиеся синтаксис и семантика высокого уровня) и 25% работ на тестирование (которые сосредоточивались на тестировании сгенерированного, а не исходного кода). В результате значение фактора преобразования из SLOC в ESLOC равен 50%.

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

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

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

Таблица D.12.

Размеры CSCI Подсистемы общего назначения, выраженные в ESLOC

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

D.8.2 Совершенствование процессов создания подсистем.

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

подсистем CCPDS-R имелись непротиворечивые способы измерения SLOC, созданных разработчиками, а также единые процессы, команды и методы. Согласованный подход к определению метрик обеспечивал получение сравнимых наборов данных, В качестве нормализованной единицы измерения были выбраны затраты, приходящиеся на одну SLOC. Абсолютные значения затрат несущественны; имеют значение лишь относительные затраты на каждую подсистему. Стоимость одной строки подсистемы PDS составляла 40% от стоимости SLOC Подсистемы общего назначения, а подсистемы STRATCOM — 33%, Это один из реальных показателей процесса уровня 3 или уровня 4 СММ.

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

Из таблицы D.13 видно, что значения коэффициента дефектности (среднее количество дефектов, приходящееся на одно изменение) и адаптируемости (среднее количество доработок на одно изменение) оказываются намного лучше для последующих подсистем (PDS и STRATCOM), нежели для Подсистемы общего назначения. Единственное исключение составляет ССВ CSCI — специальная система взаимодействия, необходимая только для подсистемы STRATCOM и не имеющая аналогов в других подсистемах, поэтому ее сложность является уникальной.

Проект CCPDS-R продемонстрировал наличие реального показателя зрелости процесса в соответствии с описанным в разделе Е.2. Для каждой последующей системы процесс ее создания — если измерять качество, продуктивность или затраченное время — оказывался лучше. За время жизни проекта CCPDS-R возможности по созданию ПО подвергались многочисленным оценкам, проводимым SEI, и зрелость процесса всегда соответствовала уровню 3 или выше. Однако эти улучшения возникли не только благодаря зрелости процесса. Работа в единой команде всех заинтересованных сторон и усилия, направленные на формирование основ архитектуры и автоматизацию процесса, оказались, вероятно, не менее важными для общего успеха проекта.

Таблица D.13.

Изменения, вносимые в подсистемы CCPDS-R по различным CSCI

D.8.3 Диаграмма выполнения SCO.

Среднее значение затрат на внесение изменений со временем стремится к вполне постоянному значению — 16 ч на одно изменение. В эту работу включается время, потраченное на анализ, перепроектирование, повторное кодирование и повторное тестирование решения. Диаграмма внесенных изменений, представленная на рис. D.16, дает еще одну интересную точку зрения.

Рис. D.16. Диаграмма изменения SCO для Подсистемы общего назначения.

D.8.4 Продуктивность и факторы качества для различных С SCI.

В таблице D.14 представлены некоторые итоговые данные по продуктивности и качеству для различных CSCI в рамках проекта CCPDS-R. Значения продуктивности для различных CSCI не являются абсолютными; для того чтобы их можно было сравнивать между собой, они нормированы относительно общей продуктивности для подсистемы в целом. Продуктивность всей подсистемы базируется на суммарных затратах в размере приблизительно 1800 человеко-месяцев. Сюда входят ресурсы, потраченные на управление, разработку и тестирование. Значения продуктивности для каждого CSCI нормировались. Приводятся два различных значения продуктивности: SLOC на один человеко-месяц и ESLOC на один человеко-месяц. Эти данные и мой собственный опыт позволяют прийти к следующим заключениям:.

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

■ У СС оказалось высокое абсолютное значение продуктивности, поскольку весь автоматически сгенерированный с помощью специально созданных CASE-средств код преимущественно содержался в данном CSCI. Команда, имевшая уровень выше среднего, также внесла свой вклад в улучшение продуктивности.

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

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

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

Таблица D.14.

Итоговые данные по различным CSCI для Подсистемы общего назначения

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

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