Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 11. Разработка и использование показателей тестирования 243 Основные преимущества применения программных показателей заключаются в следующем: • В возможности использования исходных сравнительных данных совместно с другими проектами разработки. • В возможности сбора данных о состоянии, выражаемых в одних и тех же еди ницах, во всей организации для определения успешности выполнения стоящей задачи. • В возможности выполнить прогнозирование сравнительных трудозатрат. • В возможности оценить трудоемкость или календарный план, исходя из имею щегося опыта разработок. • В возможности во время формальных пересмотров составлять отчеты по дан ным, характеризующим тенденции процесса. Данные измерений программы должны быть получены или преобразованы в чи словые единицы измерения, определенные для программного показателя. Эти дан ные должны характеризовать атрибуты программного процесса, его результаты или календарный план или ресурсы проекта разработки. Несколько примеров программ ных показателей, разделенных по стандартным промышленным категориям, приве дено в таблице 11.1. Прежде всего, следует уяснить, что существуют тысячи возможных программных показателей. П р и измерении большинства из них необходима методичность и боль шие затраты времени, и для одной конкретной группы разработки они могут оказать ся экономически неэффективными. В общем случае выбор показателей из списка, подобного приведенному в таблице 11.1, может быть сродни хождению по минному полю, если только не подходить к процессу определения и использования показате лей очень прагматично. В этом смысле не являются исключением и показатели тес тирования. Н и ж е приведен практический пример, представляющий точку зрения одного из авторов и иллюстрирующий применяемый им подход к определению пока зателей, который удовлетворяет потребности организации и при этом не становится обузой ни для одного из проектов внутри организации. В данном случае термин " о р ганизация" употребляется в отношении нескольких проектов разработки программ ного обеспечения, выполняемых под одним и тем же руководством (например, в ка ком-нибудь подразделении более крупной компании). 244 Часть II. Технологии быстрого тестирования и советы Таблица 11.1. Примеры категорий программных показателей Категория Программный показатель Размер Общее количество написанных строк кода Количество строк комментариев Общее количество объявлений Общее количество пустых строк Количество точек вызова функций Количество объектов Производительность Количество рабочих часов, затраченных на разработку проекта Количество рабочих часов, затраченных на каждый объект Количество изменений каждого объекта Количество параметров, передаваемых каждому объекту Количество методов, приходящихся на один объект Количество объектов, использующих тот или иной метод Количество точек принятия решений в каждом объекте Сложность управляющей логики каждого объекта Количество строк кода в каждом объекте Количество строк комментариев в каждом объекте Количество объявлений данных в каждом объекте Количество прямых ветвей в каждом объекте Количество операторов ввода и вывода в каждом объекте Уровень серьезности каждой ошибки Местоположение каждой ошибки Способ исправления каждой ошибки Лица, несущие ответственность за каждую из ошибок Количество строк, на которые ошибка оказала влияние Время, потребовавшееся для отыскания ошибки Время, потребовавшееся для устранения ошибки Количество предпринятых попыток исправления каждой ошибки Количество новых ошибок, допущенных в результате исправления каждой из ошибок Качество Общее количество ошибок Количество ошибок в каждом объекте Среднее количество ошибок на тысячу строк кода Среднее время наработки на отказ Количество ошибок, обнаруженных компилятором Удобство сопровождения Трассировка ошибок Глава 11. Разработка и использование показателей тестирования 245 ПРИМЕР: ПРОГРАММА ОПРЕДЕЛЕНИЯ ПОКАЗАТЕЛЕЙ (ГЭРИ КОББ) В течение примерно шести лет автору довелось выступать в роли координатора разра ботки программных показателей в организации, занимающейся созданием программно го обеспечения, в которой трудились около 450 разработчиков. Будучи членом группы координации процесса разработки программного обеспечения (Software Engineering Process Group — SEPG), функции которой определены в модели развития функциональ ных возможностей (Capability Maturity Model, C M M V1.1) института технологий про граммного обеспечения SEI, мне пришлось изучить более 400 программных показате лей, предлагаемых SEI. На основе этого исследования я пришел к выводу, что в кон кретной организации следует стандартизировать лишь небольшое количество показате лей. Основная масса показателей должна разрабатываться, отбираться, анализироваться и использоваться каждой группой в зависимости от этапа разработки. При определении программы создания показателей для нескольких независимых проек тов разработки программного обеспечения я установил ряд общих стандартов показате лей, отчеты о которых должны были поступать из всех проектов и анализироваться в SEPG. Но одновременно мною был создан процесс, который позволял в каждом проек те определять и использовать собственные показатели, которые не нужно было вклю чать в отчет или переносить в другие проекты. Стандартный набор из четырех про граммных показателей, который был предложен, утвержден и принят для использования во всех проектах разработки программного обеспечения, описан в таблице 11.2. Таблица 11.2. Общий для всей организации набор программных показателей Название показателя Определение SIZE (РАЗМЕР) Количество тысяч эквивалентных строк кода (KESLOC) EFFORT (ЗАГРУЗКА) Количество неадминистративных работников, занятых в разработке проекта в течение месяца SHEDULE (КАЛЕН- Календарные сроки (по месяцам) выполнения отдельных ДАРНЫЙ ПЛАН) этапов жизненного цикла разработки программного обеспечения QUALITY (КАЧЕСТВО) Количества ошибок на тысячу эквивалентных строк кода Ожидалось, что фактические данные по каждому из этих показателей будут сообщаться в ходе формального пересмотра, проводимого на каждом из основных промежуточных этапов жизненного цикла разработки. Эти основные промежуточные этапы и связанные с ними формальные пересмотры соответствуют основным этапам каскадной м о д е л и жизненного цикла. В их число входят эскизное проектирование (ЭП), рабочее проекти рование (РП), тестирование кода и модулей (ТКМ) и комплексные и системные испыта ния (КИ). В качестве примера на рис. 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% — метода ми динамического и статического тестирования после завершения этапа ТКМ. Большинс- Глава П. Разработка и использование показателей тестирования 247 Технические требования ЭП Поставка Размер 1 6 0 в тысячах эквивалентных строк кода 120 Промежуточные этапы Рис. 11.1. Диаграмма размеров и основные промежуточных этапов. Прогнозируемые данные Рис. 11.2. Загрузка персонала по неделям. 248 Ч а с т ь I I . Технологии б ы с т р о г о т е с т и р о в а н и я и с о в е т ы Глава 11. Разработка и использование показателей тестирования 249 Рис. 11.5. Двухуровневый набор показателей и программа составления отчетов. В следующем практическом примере мы познакомимся с технологией определе ния стандартного процесса, общего для всех проектов разработки программного обеспечения, которые выполняются в данной организации. Цель состоит не в том, чтобы во всех проектах использовались одни и те же единицы измерения конкрет ных показателей, а в том, чтобы предоставить персоналу, занятому разработкой, стандартный способ определения программных показателей, методик выполнения измерений и ф о р м отчетности в рамках проекта. ПРИМЕР: ПРИМЕНЕНИЕ ПРОЦЕССА ЦВП Д Л Я ОПРЕДЕЛЕНИЯ ПОКАЗАТЕЛЕЙ ПРОЕКТА (ГЭРИ КОББ) В SEPG команды разработки были обучены применять специализированные показатели, соответствующие требованиям каждого отдельного проекта и клиента. Для членов ко манд был прочитан обучающий курс по процессу "цель-вопрос-показатель" (ЦВП), в ос нову которого были положены исследования Базили (Basili) и Вейса (Weiss) [6]. Метод ЦВП состоит в определении целей (goal) измерения каждого из показателей, формули ровании вопросов (questions), на которые измерения должны дать ответ, и определении нормализованной формулы показателя (metric), который может масштабироваться в зависимости от размерности разработки. Примерами вопросов, относящихся к тестированию, ответы на которые могут быть получены в ходе выполнения процесса ЦВП, являются: • Каково качество программного проекта? • Каков фактический коэффициент переделок? • Каков коэффициент закрытия отчетов о дефектах? 250 Часть II. Технологии быстрого тестирования и советы • Каково соотношение фактического коэффициента ошибок и прогнозируемого, норма тивного и среднего значений этого показателя? • Для каких компонентов потребуется дополнительное тестирование? • С какими областями связано преобладающее большинство проблем? Профессор Виктор Базили (Victor Basil!) и доктор Девид Вейс (David Weiss) из универси тета Мериленда сформулировали принцип ЦВП в конце семидесятых годов, работая над проектами в центре космических полетов Годдарда, NASA. Свою работу, посвященную ЦВП [6], они опубликовали в 1984 г. Рини ван Солинген (Rini van Solingen) и Эгон Бергхот (Egon Berghout) [50] продолжили разработку концепций ЦВП, сделав их составной ча стью принципа повышения качества (см. рис. 11.6). На первом шаге команде разработки рекомендовалось записать цели, которые ставятся перед командой руководством института, организацией, осуществляющей руководство проектированием, лицами, принимающими решения, и любыми другими организациями (подразделениями), участвующими в управлении проектом. К характеристикам, которые могут быть сформулированы в качестве целей, могут относиться рентабельность, эф фективность, качество продукта, степень удовлетворения требований клиента, объем программного кода и производительность разработки. На втором шаге организуется совещание, в ходе которого занятый в разработке проек та персонал проводит "мозговой штурм" по перечню вопросов или проблем, которые должны быть выяснены, чтобы принимающие решения лица могли эффективно сплани ровать проект. Примерами вопросов, которые связаны с возможностью срыва плановых сроков, могут служить: • Влияют ли последние изменения в бюджете на сроки выполнения тестирования? • Соблюдаются ли плановые сроки тестирования? • Какие события оказывают решающее влияние на действующий в настоящее время ка- лендарный график тестирования? • Каковы последствия срыва календарного графика? На третьем шаге предполагается обсуждение данных проекта, которые должны быть собраны (или сбор которых планируется), и того, можно ли на основе этих данных и их анализа получить ответы на вопросы, поставленные на втором шаге. Эти данные изме- рений могут собираться на уровне проекта или же быть внешними данными, такими как ресурсы, фактические затраты, сроки каждого из промежуточных этапов, распределе- ние дефектов продукта по уровням серьезности или перечень сгруппированных по сборкам задач, которые должны быть решены. Таблица 11.1 содержит множество про ектных показателей, относящихся к тестированию. Подводя итоги анализа двух приведенных примеров, можно отметить следующее. Двух уровневая программа определения показателей была полностью одобрена всеми ко- мандами выполнения отдельных проектов. Им импонировало иметь свободу при созда нии собственных наборов показателей, по которым можно было составлять внутренние, отчеты или отказываться от их использования. Разделение функций между коллекцией показателей SEPG (для сбора данных измерений на общеинститутском уровне) и про- ектной коллекцией показателей (для сбора данных измерений на уровне отдельного проекта) оказалось ключевым фактором успешной деятельности института, его проек- тов и сохранения базы клиентов. |