Пример - Часть 1

• Допущения

- 5 сборок

- 15 KDSI каждая

- Каждая сборка интегрируется с промежуточными результатами предыдущих сборок

- Для реализации каждой сборки используется язык программирования C++

- В рамках одной сборки подробно рассматриваются:

• Планирование тестирования

• Верификация и аттестация

Рис. 12.9. Список допущений для части 1 примера

На рис. 12.10 показан блок входных данных Титульного листа, подробно описывающий каждую из сборок объемом в 15 KELOC. Сборка интегрируется сама с с о б о й ™ с предыдущими унаследованными сборками и реализуется на языке C + + со значением коэффициента EAF, равным 0, 5, для всех стадий разработки. Мы выбираем режим 2 которому соответствует полуорганизованная модель СОСОМО. Столбец KDSI (thou­ sands of delivered instructions — тысячи поставленных инструкций) Титульного листа за­ полняется значениями, которые начинаются со сборки объемом в 15 KDSI и с каждой строкой возрастают на 15 KDSI. Задержка начала работ в начале равна 0, а затем воз-растает на 10 месяцев с каждой сборкой. Это делается для того, чтобы показать, что на разработку каждой сборки будет затрачиваться не более 10 месяцев.

Рис. 12.10. Состояние входных значений Титульного листа.модели COCOREV (название сборки, язык программирования, задержка начала работ и коэффициенты EAF по ста­ диям и по сборкам)

Рис. 12.11 является частью комплексного вывода на Титульном листе модели COCOREV Поскольку с началом работ над сборкой 1 задержки не было, они начинаются на меся­ це 1, в то время как работы над сборкой 2 были начаты с задержкой на 10 месяцев, т.е. они начнутся в течение месяца 11 и т.д. Стадия описания требований (REQ) для всех пяти сборок происходит в течение месяцев -1 и 0, а все пять сборок будут завершены до наступления месяца 50. В то время как пики всех пяти кривых кадрового обеспечения появляются в начале фазы CUT, несложно заметить, что пики кадрового обеспечения монотонно возрастают от сборки 1 до сборки 5, что объясняется объемами интегри­ руемых программных модулей и тестовых работ, возрастающих с увеличением KSDI короче говоря, это отнюдь не пять идентичных сборок, выполняемых последовательно.

Если вас интересует, " в какую сумму обойдутся четыре года разработки программного обеспечения, то ответом будет $1, 593 миллиона, если предположить, что средняя ча-

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

совая оплата труда разработчиков останется на уровне $55 на протяжении всего четы­ рехлетнего периода работы. Это еще один ответ, который можно найти на Титульном листе. Итак, в сводке Титульного листа появляется итоговое значение 28968 человеке*-часов, разбитое по стадиям и представленное в человеко-месяцах следующим образом: REQ = 14, 83, PD = 32, 50, DD = 41, 92, CUT = 60, 54, IT = 42, 05, что в сумме составляет 191, 94 человеко-месяца.

В центре внимания рис. 12.12 находится только распределение ресурсов во время соз­ дания сборки 1. Обратите внимание на то обстоятельство, что REQ = 2, 75 человеко-месяца и что это составляет справедливую долю от общего значения REQ = 14, 83 чело­ веко-месяца, затраченных на документирование всего продукта со множеством сборок. Общая стоимость разработки после формулирования требований составляет 34, 18 минус 2, 75, затраченных на REQ, что дает 31, 43 человеко-месяца, и это значение совпадает с об-щим значением, указанным в правом столбце. Из графика загрузки персонала, полученного с помощью модели COCOREV, следует, что преимущество программного обеспечения с точки зрения используемого персонала в этом проекте должно возрасти с 2 исполнителей до 4, 5 при пике нагрузки и снизиться до 1, 5 на протяжении последнего месяца.

Аналог сборки 1, а именно, сборка 2, представлен на рис. 12.13. В чем состоят различия между сборкой 1 и сборкой 2? Итак, во-первых, прежде чем сборку 2 можно будет поставлять, она должна быть интегрирована со сборкой 1, после чего обе сборки долж-ны быть подвергнуты совместному тестированию. Второе отличие заключается в том, что разработка сборки 2 задержана на 10 месяцев. Это означает, что ее разработка начинается на 11-м месяце, т.е. по истечении 1, 5 месяцев после выпуска сборки 1. Дру-гими словами, требования, предъявляемые к сборке 2, ждут своего часа около 10 ме­ сяцев, а за это время требования вполне могут претерпеть определенные изменения, причем совершенно бесплатно, пока кто-нибудь не возьмет на себя обязанности сопро­ вождения документов с формулировками требований. В данном случае выражение " со­ вершенно бесплатно" является доказательством того, что приверженцы спиралевидного-подхода обычно принимают меры в поддержку своего утверждения о том, что спирале-видный процесс уменьшает риски самопроизвольных изменений требований. В силу ка­ ких причин затраты на требования в случае сборки 2 выше, чем затраты на требования в случае сборки 1 (соответственно, 2, 9 и 2, 7 человеко-месяца)? Это объясняется более - высокой сложностью требований сборки 2 к интегрированию со сборкой 1.

Из соображений краткости мы не будем показывать аналогичные графики для сборок 3 и 4. На рис. 12.14 представлена кривая кадрового обеспечения для последней из пяти сборок. Сравнивая эту кривую кадрового обеспечения с аналогичной кривой для сборки 1, можно отметить, что суммарные трудозатраты, за вычетом затрат на документиро­ вание требований, составляют 38, 22 - 31, 33 = 6, 89 человеко-месяцев. Для проекта, на разработку которого уходит немногим более 9 месяцев, для создания сборки 5 требу-ется на одного исполнителя больше (количество персонала), чем для сборки 1. Опять-таки, эти расчеты подтверждают тот факт, что наличие в случае сборки 5 унаследован-ного кода достаточно большого объема обусловливает большие затраты времени и уси-лий по сравнению со сборкой 1, у которой вообще нет унаследованных кодов.

В начале этой главы мы поставили перед собой задачу дать по возможности более точ­ ное описание способа прогнозирования трудозатрат на подготовку и выполнение тесто-вых работ с разбивкой по месяцам, которое обычно называется верификацией и атте-стацией (V6iV). После предварительного описания возможностей модели COCOREV мЫ продолжим рассмотрение примера с последовательностью из пяти сборок, уделяя ос-новное внимание упомянутым двум тестовым функциям. Обратимся снова к сборке 1 и разделим работы по тестированию на две категории: планирование испытаний-(рис.12.15) и верификация и аттестация (рис.12.16). Эти данные содержатся в электрон-ной таблице сборки 1 в рабочем журнале модели COCOREV. Термин персонал тести-рования (test staff) означает совокупность персонала, составляющего планы проведенияиспытаний, и персонала, выполняющего верификацию и аттестацию, например, совокупное число исполнителей, представленных на графиках, изображенных на рис. 12.15 и 12.16..

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

Месяцы

Рис.12.15. Кривая кадрового обеспечения планирования проведения испытаний сборки 1 согласно модели COCOREV

Что собой представляет персонал, включенный в состав группы, формулирующей техни­ ческие требования? Модель COCOREV выделяет персоналу, проводящему тестирование, некоторое количество часов для участия в документировании требований на протяжении месяцев -1 и 0, предшествующих началу разработки сборки 1. Персонал тестирования требует от авторов требований дать пояснения, что означают эти требования примени­ тельно к тестированию каждой важной функции, создавая тем самым основу для со­ ставления персоналом тестирования соответствующих планов проведения испытаний, тестовых случаев и результатов прогона тестов. На некоторых стадиях разработчикам полезно также время от времени освежать в памяти технические требования на прове­ дение тестирования, чтобы можно было включать различные специализированные тесто­ вые процедуры в проекты и далее встраивать их в программное обеспечение.

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

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

При сравнении приведенных выше графиков несложно заметить, что в качестве стадий в обоих выбраны одни и те же месяцы, и что анализ ресурсов благоприятствует планиро­ ванию на ранних стадиях, а верификацию и аттестацию (V& V) лучше выполнять позже, на стадии комплексных испытаний (IT). Это не расходится с предназначением каждой за­ дачи, например, планирование обнаружения дефектов во время использования техноло­ гий статического тестирования на стадиях REQ, PD, DD и CUT с последующим выполне-нием планов проведения испытаний, обнаружением и документированием дефектов с использованием динамических технологий тестирования на стадиях IT и приемочных ис­ пытаний. Модель COCOREV не поддерживает точку зрения некоторых руководителей, ' которые утверждают, что после того, как разработчики построят готовый к запуску программный продукт, можно подключать к работе независимую команду тестирова-ния, поставив перед ней задачу отыскания всех дефектов. Напротив, удачными считают­ ся такие проекты, во время разработки которых планирование тестовых работ и прогон. тестов осуществляются на всех стадиях. Внимательность и осторожность при обнаруже­ нии и исправлении дефектов с использованием статических средств на первых трех ста-днях разработки — вот на чем делается акцент в технологии быстрого тестирования.

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

После применения модели COCOREV на сборке 1 были получены следующие результа-. ты, разбитые по стадиям и выраженные в человеко-месяцах: REQ = 11, 84, РО = 38, 50, DD = 42, 85, CUT = 58, 86, IT = 51, 54, что в совокупности дает 204, 59 человеко-месяца. Это составляет 30983, 7 человеко-часов, учитывая, что месяц приравнивается к 151 опла-чиваемому человеко-часу. В пересчете на денежные единицы получается $1, 699 мил-пиона, исходя из предположения, что стоимость человеко-часа составляет $55. График, изображенный на рис.12.18, показывает, что на разработку проекта потребуется более 16 месяцев, при этом работы над проектом начинаются после трехмесячного периода формулирования требований. Пик кривой кадрового обеспечения приходится на стадию CUT на уровне 15 человек в течение трех месяцев.