Категория Программный показатель

Размер Общее количество написанных строк кода

Количество строк комментариев

Общее количество объявлений

Общее количество пустых строк

Количество точек вызова функций

Количество объектов

Производительность

Удобство

сопровождения

Количество рабочих часов, затраченных на разработку проекта Количество рабочих часов, затраченных на каждый объект Количество изменений каждого объекта

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

Количество операторов ввода и вывода в каждом объекте

Трассировка

ошибок

Качество

Уровень серьезности каждой ошибки Местоположение каждой ошибки Способ исправления каждой ошибки

Лица, несущие ответственность за каждую из ошибок Количество строк, на которые ошибка оказала влияние Время, потребовавшееся для отыскания ошибки Время, потребовавшееся для устранения ошибки

Количество предпринятых попыток исправления каждой ошибки

Количество новых ошибок, допущенных в результате исправления каждой из ошибок

Общее количество ошибок Количество ошибок в каждом объекте

Среднее количество ошибок на тысячу строк кода Среднее время наработки на отказ Количество ошибок, обнаруженных компилятором

ПРИМЕР: ПРОГРАММА ОПРЕДЕЛЕНИЯ ПОКАЗАТЕЛЕЙ (ГЭРИ КОББ)

В течение примерно шести лет автору довелось выступать в роли координатора разра­ ботки программных показателей в организации, занимающейся созданием программно­ го обеспечения, в которой трудились около 450 разработчиков. Будучи членом группы координации процесса разработки программного обеспечения (Software Engineering Process Group — SEPG), функции которой определены в модели развития функциональ­ ных возможностей (Capability Maturity Model, C M M V1.1) института технологий про­ граммного обеспечения SEI, мне пришлось изучить более 400 программных показате­ лей, предлагаемых SEI. На основе этого исследования я пришел к выводу, что в кон­ кретной организации следует стандартизировать лишь небольшое количество показате­ лей. Основная масса показателей должна разрабатываться, отбираться, анализироваться и использоваться каждой группой в зависимости от этапа разработки.

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

Таблица 11.2. Общий для всей организации набор программных показателей

Ожидалось, что фактические данные по каждому из этих показателей будут сообщаться в ходе формального пересмотра, проводимого на каждом из основных промежуточных этапов жизненного цикла разработки. Эти основные промежуточные этапы и связанные с ними формальные пересмотры соответствуют основным этапам каскадной модели жизненного цикла. В их число входят эскизное проектирование (ЭП), рабочее проекти­ рование (РП), тестирование кода и модулей (ТКМ) и комплексные и системные испыта­ ния (КИ). В качестве примера на рис. 11.1 приводится диаграмма показателя размера программы, которую можно представить во время формального пересмотра на этапе ТКМ. Часто большая система допускает разложение на основные подсистемы, пред­ ставленные на диаграмме отдельными слоями. В приведенном примере размер про­ граммы в значительной степени изменяется от одного этапа к другому. Не вдаваясь в подробности, можно утверждать лишь следующее. На этапе разработки требований был определен приемлемый размер проекта, но на этапе ЭП предполагалось, что свы­ ше 100000 строк кода будут использоваться повторно. Впоследствии, по завершении этапа ЭП выяснилось, что фактически код повторно использоваться не может. В резуль­ тате оценки размеров модулей были пересмотрены, что и нашло свое отражение в диа­ грамме, начиная с этапа РП.

На рис. 11.2 приведена диаграмма фактических данных по занятости персонала, на ко­ торой показана фактическая загрузка персонала в течение первых четырех месяцев (т.е. 16 недель) и предполагаемая загрузка до окончания проекта (начиная с 16-ой не­ дели). В случае выполнения масштабных проектов данные измерений загрузки персона­ ла разбиваются по этапам и/или характеру выполняемых работ.

246 Часть II. Технологии быстрого тестирования и советы

В данном случае такими этапами являются: эскизный проект (ЭП), рабочий проект (РП), программирование (П), тестирование модулей (ТМ), системные испытания (СИ), прочие работы (Пр) и вспомогательные работы (ВР). В процессе анализа этой диаграммы за- грузки персонала у руководителя разработки должен был бы возникнуть естественный вопрос: " Что на четвертом месяце привело к уменьшению количества занятых в проекте людей? " Судя по представленным данным, в течение 12-й, 13-й и 14-й недели разработ ки имели место потери персонала, за которым последовало резкое увеличение его ко-личества. Будучи руководителем, следует вскрыть причину столь странного поведения показателя и выяснить, было ли это естественным отражением особенностей процесса разработки или же признаком наличия проблемы, которую необходимо решить немед-ленно, а не когда делать это будет уже поздно.

На рис. 11.3 показана диаграмма загрузки персонала по месяцам, на которой представ-лены следующие этапы: разработка требований (ТЗ), эскизное проектирование (ЭП), рабочее проектирование (РП), тестирование кода и модулей (ТКМ) и объединенные комплексные и системные испытания (КИ). Кроме того, в верхней части диаграммы по-мечены формальные пересмотры, проводимые в конце соответствующих этапов, а именно: заключение договора (ЗД), пересмотр эскизного проекта (ПЭП), критический пересмотр проекта (КПП), пересмотр готовности к тестированию (ПГТ) и приемочный пересмотр (Поставка). Месяцы, в течение которых разрабатываются требования, имеют отрицательную нумерацию, поскольку проводить какое-либо прогнозирование не воз-можно до тех пор, пока требования не определены, и, как правило, отсчет времени разработки начинается с момента заключения договора.

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

На практике можно руководствоваться следующим эмпирическим правилом: смещение или удлинение плановых сроков можно считать номинальным, если это изменение не превышает 10%. Для плана проекта, предусматривающего выполнение проекта за 20 месяцев, завершение проекта в период между 18 и 22 месяцем оказалось бы номи­ нальным. Изменения плановых сроков отдельных промежуточных этапов должны лриво-диться к ближайшему полумесячному сроку. Аналогично, если бы план предусматривал выполнение проекта в течение 20 недель, завершение разработки в период между 18 и! 22 неделями было бы номинальным, причем изменения отдельных промежуточных эта-пов должны приводиться к ближайшему полунедельному сроку.

На рис. 11.4 приведено графическое представление измеренных данных показателя ка­ чества, а именно — количества обнаруженных ошибок на тысячу предполагаемых ис-ходных строк кода (К of estimated source lines of code, KESLOC). Количество ошибок на, тысячу строк кода, обнаруженное на каждом этапе жизненного цикла разработки, co-общается по завершении каждого из этих этапов. В данном случае этапы соответствуют этапам каскадной модели жизненного цикла разработки программного обеспечения, а именно разработке требований (ТЗ), эскизному проектированию (ЭП), рабочему проек-тированию (РП), тестированию кода и модулей (ТКАЛ), комплексным испытаниям (КИ), системным испытаниям (СИ) и приемочным испытаниям (ПСИ).

В случае больших программ количество ошибок может определяться отдельно для каж-дой категории серьезности ошибок и отображаться в виде накладывающих одна на дру-гую столбчатых диаграмм. Анализ значений данных этой столбчатой диаграммы показы­ вает, что данный проект является проектом, в котором применяется быстрое тестирова­ ние. Почему? 4 1 % ошибок были обнаружены в ходе статического тестирования еще до начала этапа ТКМ, 36, 3% ошибок были обнаружены на этапе ТКМ, и 22, 7% — метода­ ми динамического и статического тестирования после завершения этапа ТКМ. Большинс-