Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 12. Технологии оценки трудозатрат на т е с т и р о в а н и е и советы 277 Моделирование эксплуатации программного обеспечения Кадровое обеспечение 15 Рис. 12.8. Уровень трудозатрат на эксплуатацию, подсчитанный на основе измерения площади фигуры между осью абсцисс и кривой кадрового обеспечения Предположим, стало известно, что конкуренту вашей компании потребовалось четыре года, чтобы завершить COTS-продукт объемом в 50 KLOC. В соответствие с контрактом, который заключила ваша компания, этот продукт является основой для внесения усовершенствований. Несут ли эти сведения информацию, которая могла бы укрепить ваши позиции в конкурентной борьбе? Имея в своем распоряжении уравнения математической модели, можно восстановить значение (MM A[1 j) из уравнения для TDEV. Далее, имея значение (MM A d j ) и учитывая то, что объем COTS-продукта равен 50 KLOC, единственной неизвестной величиной в урав нении для (MM Ac |j) остается коэффициент EAF. Зная величину коэффициент EAF для COTS-продукта у конкурента, можно определить его затраты на выполнение следую щего проекта, скажем, объемом в 75 KLOC. Постоянно совершенствуя драйверы стоимости, которые используются для вычисления значений коэффициент EAF, ваша компания сможет победить в конкурентной борьбе, создавая программные продукты за более низкую цену. Последовательно управляя математической моделью, ваша компания в конечном итоге с полным правом сможет сказать: "Мы можем поставлять программный продукт в более сжатые сроки и за меньшую цену". 278 Часть II. Технологии быстрого тестирования и советы ПРИМЕР 2. ПОСТРОЕНИЕ М О Д Е Л И COCOREV (ГЭРИ КОББ) Математическое моделирование жизненного цикла программного обеспечения всегда вызывало у меня повышенный интерес. Следствием такой заинтересованности стали краткий обзор различных случаев использования моделей составления смет, которые мне удалось обнаружить, и исследование гибкости этих моделей. С самого-начала я от дал предпочтение структуре электронной таблицы, поскольку она обладала модульно- стью и графическим интерфейсом, необходимыми для достижения поставленных целей. Я принял решение написать для наиболее сложных случаев программу детализированной модели СОСОМО, в которой на каждой стадии применяются собственные коэффициен- ты EAF. В модели COCOREV используются параметризованные коэффициенты и экспо- ненты для вычисления значений (MM A dj) и TDEV, благодаря чему одна и та же электрон-- ная таблица применяется для решения уравнений модели REVIC. Мы решили назвать эту модель, в основу которой положена электронная- таблица, табличной моделью COCOREV. Модель COCOREV предоставит примеры использования математической модели для составления сметы затрат на разработку программного обеспечения. В рав- ной степени найдут применение и уравнения для полуорганизованных проектов (режим 2), полученные Барри Боемом, а в промежуточной модели вычисления сметной стоимо- сти принимается, что для всех стадий разработки используется одно и то же значение коэффициента EAF, равное 0,5. В рассматриваемом конкретном примере м о ж н о выделить три части: • Спиралевидный жизненный цикл с пятью сборками объемом 15 KLOC, которые ин- тегрируются в программный код существующей системы и создаются последова- тельно. • Каскадный жизненный цикл с одной сборкой объемом 75 KLOC, создаваемой один раз. • Многоярусный спиральный жизненный цикл с пятью сборками объемом 15 KLOC, к о - торые интегрируются в программный код существующей системы, при этом спирали создаются каждые два месяца. С итоговыми результатами этого анализа, проводимого с целью выбора компромиссно- го решения, можно будет познакомиться после того, как будут представлены данные третьей части. На рис. 12.9 показаны допущения, принятые для первой части примера. Модель COCOREV представляет собой рабочий журнал, содержащий некоторое мно- жество рабочих страниц. Главная страница, именуемая Титульным листом, содержит все входные данные модели и сводку всех выходных результатов пяти страниц, на которых уравнения модели COCOREV применяются к индивидуальным сборкам, помеченным как Сборка 1, Сборка 2, Сборка 3, Сборка 4 и Сборка 5. Еще одна рабочая страница, по- меченная как Таблицы, содержит фиксированные константы рассматриваемой модели. Пример - Часть 1 • Допущения - 5 сборок - 15 KDSI каждая - Каждая сборка интегрируется с промежуточными результатами предыдущих сборок - Для реализации каждой сборки используется язык программирования C++ - В рамках одной сборки подробно рассматриваются: • Планирование тестирования • Верификация и аттестация Рис. 12.9. Список допущений для части 1 примера 12. Технологии оценки трудозатрат на т е с т и р о в а н и е и советы 279 На рис. 12.10 показан блок входных данных Титульного листа, подробно описывающий каждую из сборок объемом в 15 KELOC. Сборка интегрируется сама с с о б о й ™ с предыдущими унаследованными сборками и реализуется на языке C + + со значением коэффициента EAF, равным 0,5, для всех стадий разработки. Мы выбираем режим 2 которому соответствует полуорганизованная модель СОСОМО. Столбец KDSI (thou sands of delivered instructions — тысячи поставленных инструкций) Титульного листа за полняется значениями, которые начинаются со сборки объемом в 15 KDSI и с каждой строкой возрастают на 15 KDSI. Задержка начала работ в начале равна 0, а затем воз- растает на 10 месяцев с каждой сборкой. Это делается для того, чтобы показать, что на разработку каждой сборки будет затрачиваться не более 10 месяцев. Разработанный программный продукт Номер Язык сборки программирования Сборка 1 C++ Сборка 2 C++ Сборка 3 C++ Сборка 4 C++ Сборка 5 C++ Разработанный программный продукт Номер Модель COCOREV Версия 1.02 KELOC 15,000 15,000 15,000 15,000 15,000 KDSI 15,000 30,000 45,000 60,000 75,000 Задержка начала работ 0,0 10,0 20,0 40,0 50,0 сборки Сборка 1 Сборка 2 Сборка 3 Сборка 4 Сборка 5 EAF:REQ 0,500 0,500 0,500 0,500 0,500 EAF:PO 0,500 0,500 0,500 0,500 0,500 EAF:DD 0,500 0,500 0,500 0,500 0,500 EAF:CUT 0,500 0,500 0,500 0,500 0,500 EAF: IT 0,500 0,500 0,500 0,500 0,500 KELOC KDSI Тысячи эквивалентных срок программного кода Тысячи инструкций поставленного исходного кода Задержка Число месяцев перед началом разработок начала работ EAF Коэффициент уточнения трудозатрат Рис. 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. . Глава 12. Технологии оценки трудозатрат на тестирование и советы 281 Помесячное и поэтапное кадровое обеспечение разработки (задачи, связанные и не связанные с рабработкой программного обеспечения) IT3 а э п I РП ОТКМ КИ 282 Часть II. Технологии быстрого тестирования и советы Глава 12. Технологии оценки трудозатрат на тестирование и советы 283 Кадровое обеспечение Сборка 1 Планирование проведения испытаний 3 4 5 Месяцы Рис.12.15. Кривая кадрового обеспечения планирования проведения испытаний сборки 1 согласно модели COCOREV Что собой представляет персонал, включенный в состав группы, формулирующей техни ческие требования? Модель COCOREV выделяет персоналу, проводящему тестирование, некоторое количество часов для участия в документировании требований на протяжении месяцев -1 и 0, предшествующих началу разработки сборки 1. Персонал тестирования требует от авторов требований дать пояснения, что означают эти требования примени тельно к тестированию каждой важной функции, создавая тем самым основу для со ставления персоналом тестирования соответствующих планов проведения испытаний, тестовых случаев и результатов прогона тестов. На некоторых стадиях разработчикам полезно также время от времени освежать в памяти технические требования на прове дение тестирования, чтобы можно было включать различные специализированные тесто вые процедуры в проекты и далее встраивать их в программное обеспечение. 284 Часть II. Технологии быстрого тестирования и советы Примерами специализированных тестовых процедур могут служить регистрация тран закций, откат всех транзакций баз данных, ведение файлов предыстории, в которых на капливается хронология изменения данных, последовательность прохода ветвей кода или выхода без заказа из пользовательских корзин на Web-сайтах электронной коммерции. Исполнители из числа персонала тестирования с их заряженностью на обнаружение де фектов, должны ознакомиться с эскизной и вспомогательной документацией, чтобы об наружить и задокументировать дефекты в требованиях. В конечном итоге, это наиболее подходящее место для экономически эффективного отлавливания дефектов — когда при наличии всех мощных аппаратно-программных средств для устранения всех этих де- фектов достаточно будет только карандаша и резинки. При сравнении приведенных выше графиков несложно заметить, что в качестве стадий в обоих выбраны одни и те же месяцы, и что анализ ресурсов благоприятствует планиро ванию на ранних стадиях, а верификацию и аттестацию (V&V) лучше выполнять позже, на стадии комплексных испытаний (IT). Это не расходится с предназначением каждой за дачи, например, планирование обнаружения дефектов во время использования техноло гий статического тестирования на стадиях REQ, PD, DD и CUT с последующим выполне- нием планов проведения испытаний, обнаружением и документированием дефектов с использованием динамических технологий тестирования на стадиях IT и приемочных ис пытаний. Модель COCOREV не поддерживает точку зрения некоторых руководителей, ' которые утверждают, что после того, как разработчики построят готовый к запуску программный продукт, м о ж н о подключать к работе независимую команду тестирова- ния, поставив перед ней задачу отыскания всех дефектов. Напротив, удачными считают ся такие проекты, во время разработки которых планирование тестовых работ и прогон . тестов осуществляются на всех стадиях. Внимательность и осторожность при обнаруже нии и исправлении дефектов с использованием статических средств на первых трех ста- днях разработки — вот на чем делается акцент в технологии быстрого тестирования. Допущения анализируемого примера 2 представлены на рис.12.17. Они мало чем отли- чаются от допущений примера 1, однако на этот раз мы намерены изменить одно важ- ное условие для исследования отношения риски/выигрыш, а именно, выбрать в качестве. жизненного цикла вместо спиральной каскадную модель. Для этого поставим перед со- бой задачу объединить все 75 KLOC в сборку 1 и интегрировать ее саму с собой (75 K.DSI), разумеется, отказавшись от использования четырех остальных сборок модели COCOREV. ! После применения модели 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 человек в течение трех месяцев. Пример - Часть 2 • Допущения -1 сборка - 75 KDSI - Для реализации каждой сборки используется язык программирования C++ - В рамках одной сборки подробно рассматриваются: • Планирование тестирования • Верификация и аттестация Рис. 12.17. Список допущений для части 2 примера Глава 12. Технологии оценки трудозатрат на тестирование и советы 285 На рис.12.19 и 12.20 показаны, соответственно, кривые трудозатрат на составление пла нов проведения испытаний и на верификацию и аттестацию. Большая часть трудозатрат на планы проведения испытаний приходится на стадии PD, DD и CUT, при э т о м в течение девяти следующих подряд месяцев потребуется 0,8 человека каждый месяц. Наиболь ш е е количество персонала, занимающегося верификацией и аттестацией, приходится на стадию IT и составляет 2,5 человека в течение трех месяцев подряд. Э т и м заканчивается изучение части 2 п р и м е р а . На рис. 12.21 представлен список д о п у щений для части 3 данного п р и м е р а . 286 Часть II. Технологии быстрого тестирования и советы Кадровое обеспечение 3.500000 3.000000 2.500000 2.000000 1.500000 1.000000 0.500000 0.000000 Разработка в форме единственной сборки Верификация и аттестация Рис. 12.20. Кривая кадрового обеспечения верификации и аттестации для каскадной модели выполнения проекта в 75 KLOC Пример - Часть 3 • Допущения - 5 сборок, выполняемых каждые 2 месяца - 1 5 KDSI каждая - Каждая новая сборка интегрируется с результатами предыдущих сборок - Для реализации каждой сборки используется язык программирования C++ Рис.12.21. Список допущений для части 3 примера Результаты этой части иллюстрируются графиком, который показан на рис. 12.22. Кад ровое обеспечение каждой стадии выглядит следующим образом: REQ = 14,83, PD = 32,50, DD = 41,94, CUT = 60,54, IT = 42,05, что в совокупности дает 191,86 человеко- месяца. Это составляет 28971,7 человеко-часов. Полагая, что месяц содержит 151 оп лачиваемый 151 час, то в пересчете на денежные единицы получается $1,593 миллиона при стоимости человеко-часа $55. Поскольку на каждой стадии разработки программного продукта, а именно, на стадиях PD, DD, CUT, IT, трудится персонал, прошедший специальную подготовку и получивший сертификат на выполнение всех необходимых задач, конкретное значение многоярусно го спиралевидного жизненного цикла состоит в том, что персонал может завершить со ответствующую стадию на одной сборке и перейти к выполнению той же стадии на сле дующей сборке. При этом каждый исполнитель будет непрерывно занят решением сво ей задачи на протяжении года. Другое важное значение многоярусного спиралевидного жизненного цикла связано с тем, что пользователи начинают работать с первой частью новой системы примерно на полпути многоярусного спиралевидного жизненного цикла и, регулярно продолжают получать выпуски с дополнительной функциональностью на про-, тяжении остальных 10 месяцев жизненного цикла. С точки зрения персонала, составляющего планы проведения испытаний и выполняющего верификацию и аттестацию, получение нового выпуска м о ж н о спланировать к концу ка ждого двухмесячного периода из десяти последних месяцев жизненного цикла. |