Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 12. Технологии оценки трудозатрат на тестирование и советы 267 Таблица 12.1. Перевод конкретного числа функциональных баллов в тысячи строк KESLOC [26] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 A Языки систем электронных таблиц Языки запросов SMALLTALK OBJECTIVE-C APL STRATEGEM База данных четвертого поколения LOGO BASIC FORTH LISP PROLOG Ada MODULA-2 PL/1 RPG Pascal JOVIAL FORTRAN COBOL CHILL ALGOL С Макроассемблер Ассемблер В 6 16 21 26 32 35 40 53 64 64 64 64 71 71 80 80 81 106 106 106 106 106 150 213 320 С 50 20 20 12 10 9 8 8 5 5 5 5 4,5 4,5 4 4 3,5 3 3 3 3 3 2,5 1,5 1 В — количество строк программного кода, соответствующее одному функциональному баллу С — количество команд на выходном языке транслятора, соответствующее строке программного кода Вывод, который непосредственно можно получить из этого исследования, заклю чается в том, что в условиях мелкомасштабных проектов каждый исполнитель знает все, что происходит ежедневно, а члены команды поддерживают друг друга, помогая решать сложные проблемы, разбираться в кодах и отлаживать модули. Ни у кого не возникает необходимости в документировании процесса, поэтому никто не задумы вается над тем, чтобы упаковать данные измерений. В условиях небольших проектов каждый член группы вынужден брать на себя ответственность за судьбу всего проек- 268 Часть П. Технологии быстрого тестирования и советы та. Исполнитель в этом конкретном примере ощущает настоятельную необходимость иметь в своем распоряжении процесс оценки трудозатрат на тестирование для новых небольших проектов. Но в то же самое время, в состав предыдущих проектов не вхо дили процессы сбора данных для базиса оценок. П р и переходе от мелкомасштабных проектов к крупномасштабным возникает на стоятельная потребность формализовать обмен данными, отчетность, руководящие действия, организационные роли, подготовку кадров и промышленные стандарты. Другими словами, возникает необходимость в определении и использовании полно стью документированного процесса. В нескольких следующих главах будут показаны последовательности технологических операций процесса разработки современного программного обеспечения, при этом упор будет делаться на процесс тестирования и идентификацию его задач. Применение математических методов для оценки программного обеспечения П р и моделировании процесса разработки программного обеспечения необходимо принимать во внимание тот факт, что различные модели жизненного цикла разра ботки имеют дело с современными моделями. В некоторых проектах определены технические требования, выявленные на начальной стадии проекта, и они остаются неизменными на протяжении всех этапов разработки. Минимальных затрат требует каскадный процесс разработки программного обеспечения. Каскадный (или "водо падный") процесс показан на рис. 12.1. Он получил свое название по аналогии с по током самого процесса, Поскольку информационные потоки в диаграмме потоков данных направлены сверху вниз, подобно струям воды в водопаде. Стрелки, которые указывают в обратном направлении, суть потоки верификации. О н и отвечают на во просы наподобие: соответствует ли исходный код тому, чем он должен быть согласно детальной проектной документации. Стадия тестирования, показанная на диаграмме каскадного процесса, включает комплексные, системные и приемочные испытания, в то время как стадия реализа ции, которая также показана на диаграмме, содержит задачи, относящиеся к тести рованию модулей. Перед передачей программного кода независимым организациям, занимающимся тестированием, разработчики должны выполнить тестирование про граммных модулей. П р и решении задач на стадии тестирования каскадного процесса применяются технологии статического и динамического тестирования, рассмотрен ные в главах 3, 10 и 11. Другой популярной моделью жизненного цикла программного обеспечения явля ется модель, получившая название спиралевидного процесса, который показан на рис. 12.2. Этот процесс впервые был использован при разработке прототипов с це лью повышения степени доверия к набору требований и обеспечения возможности экспериментирования с человеко-машинным интерфейсом, структурой базы данных, простотой использования, производительностью и удобством установки. Чтобы дать пользователям возможность поупражняться и получить от них отзывы, создаются инкрементальные сборки. Такие сборки являются должны обязательно тестировать ся, однако слишком частые инкрементальные сборки иногда не позволяют группе тестирования полностью завершить прогон всего тестового набора. Глава 12. Технологии оценки трудозатрат на тестирование и советы 269 Рис. 12.1. Каскадная модель 270 Часть II. Технологии быстрого тестирования и советы В силу этого обстоятельства, задачей наивысшего приоритета становится обнару жение дефектов во вновь добавленной функциональности, но это, в свою очередь, приводит к спешке в разработке и реализации совершенно новых тестовых случаев, тестовых сценариев и ожидаемых результатов прогона тестов. Этот процесс набира ет такие темпы, что становится хаотичным как для разработчиков, так и для тести- ровщиков. Если все этапы работ не будут тщательно выверены и распланированы, то по причине недостатка времени ни разработчики, ни тестировщики не успеют за вершить работу и проанализировать ее результаты до появления следующей сборки. Наилучшей моделью жизненного цикла разработки программного обеспечения, которое должно поступать на рынок с ограниченным набором функциональных воз можностей с целью минимизации рисков, является спиралевидная модель. Спирале видная модель обеспечивает плановый набор выпусков, благодаря чему переделка каких-либо пользовательских интерфейсов, структур баз данных или повышение производительности неоптимальных алгоритмов может выполняться в более позд них выпусках продукта. Эта же модель поддерживает наилучший процесс в условиях, когда требования нечетко сформулированы либо отсутствуют прототипы продукта. Поставка предва рительных сборок будущего программного продукта уменьшает риск неудачи всего проекта благодаря возможности заручиться поддержкой конечных пользователей на ранних стадиях разработки. Спиралевидная модель наилучшим образом подходит для проектов с изменчивыми требованиями, поскольку добавление, удаление и измене ние требований можно встроить в следующие сборки, параллельно занимаясь сопро вождением и разработкой новой сборки. Вы, скорее всего, слышали часто употребляемый девиз достижения качества: "де лай правильно с первой попытки". Если это относится к текущему типу проекта про граммного продукта, то наилучшим решением, требующим к тому же минимальных затрат, будет каскадная модель. Если пользователи не знают, чего они, в конце кон цов, хотят, или если может случиться так, что окончательная версия программного продукта когда-то в отдаленном будущем не удовлетворит ожидания заказчика, то наилучшим подходом к решению этой задачи, который минимизирует риск неудачи, будет спиралевидная модель. В ранее рассмотренном жизненном цикле разработки программного обеспечения возможны изменения, обусловленные необходимостью привлечения внешних ресур сов субподрядчиков на проектирование, кодирование и тестирование модулей. На рис. 12.3 показана диаграмма шарнирно-каскадной модели, которая демонстрирует распределение ответственности в соответствии с промышленными стандартами ме жду генеральным подрядчиком и субподрядчиками/партнерами. Из приведенных примеров, иллюстрирующих широкое многообразие моделей жизненного цикла разработки, можно сделать вывод, что требования, предъявляе мые к стоимостной модели, должны быть разбиты на блоки. Модель должна быть достаточно гибкой, чтобы делить сметную стоимость работ на стоимость работ, вы полняемых генеральным подрядчиком, и стоимость работ, выполняемых субподряд чиком, равно как и в меру гибкой, чтобы выделить трудозатраты на тестирование, например, из затрат на управление разработкой и сопровождением программ или из затрат на кодирование. Это приводит к проекту, который рассматривается далее на примере изучения последовательности конкретных случаев. Глава 12. Технологии оценки трудозатрат на тестирование и советы 271 Распределение обязанностей в соответствии с промышленными стандартами Генподрядчик: требования и архитектура Субподрядчик/партнер: разработка программного обеспечения Генподрядчик: системные и приемочные испытания Субподрядчик Рис. 12.3. Шарнирно-каскадная модель, демонстрирующая распределение обязанностей между генеральным подрядчиком и субподрядчиком В [6] на примере 63 успешно выполненных проектов по разработке программного обеспечения выделяется три группы проектов, а именно: организованные, полуорга низованные и встроенные. Тем же, в [6], были разработаны три модели вычисления сметной стоимости: базовая, промежуточная и рабочая. В группу организованных проектов попадают те из них, в рамках которых работают небольшие группы, выпол няющие хорошо Известную им работу, такую как, например, добавление сообщений в программе на языке COBOL. В группу встроенных проектов попадают проекты, в разработке которых участвовали группы с большим числом исполнителей и рисками, связанными с недостаточной осведомленностью в области программирования, не достаточными знаниями условий испытаний, нестабильностью требований, сокра щенным графиком работ, отсутствием необходимых инструментальных средств, же сткими ограничениями по производительности и качеству. Группу полорганизован- ных проектов образуют проекты, которые находятся где-то посередине между груп пами встроенных и организованных проектов. На рис. 12.4, который представляет сводку уравнений модели СОСОМО (Constructive Cost Model — конструктивная стои мостная модель), предложенную Барри Боемом (Barry Boehm), эти три группы назы ваются режимами. Для того чтобы упростить понимание различий между уравнениями организован ных, полуорганизованных и встроенных режимов, на рис. 12.5 показаны графиче ские диаграммы этих трех уравнений в тысячах строк KELOC (Equivalent Lines Of Code— эквивалентные строки кода). Диаграммы выглядят несколько запутанно, по скольку из них следует, что чем выше риск, связанный с программой, тем быстрее она завершится. По всей видимости, это можно объяснить тем, что руководство под бирает специалистов по разработке с таким расчетом, чтобы этот персонал смог ус- 272 Часть II. Технологии быстрого тестирования и советы пешно выполнять проекты с высокими рисками либо в условиях недостаточности ресурсов. Уравнения, используемые в базовой и промежуточной/детализированной моделях СОСОМО Базовая модель СОСОМО ММ = 2,4 (KLOC)' 0 5 TDEV = 2,5 (ММ) 0 ' 3 8 MM M aint = (Интенсивность годичных изменений) M M A d j трудозатрат на эксплуатацию ELOC Эквивалентные строки программного кода ММ Человеко-месяцы EAF Коэффициент уточнения трудозатрат MM Aci j Скорректированные трудозатраты в человеко-месяцах TDEV Время на разработку MM M a J n t Годичные трудозатраты на эксплуатацию Промежуточная и детализированная модели СОСОМО Организованный режим MM A d j = (EAF) 3,2(KELOC) 105 TDEV = 2,5 (ММ до,) 0 3 8 Полуорганизованный режим M M A d j = (EAF)3,0(KELOC)' 12 TDEV = 2,5(MMA d j ) 0 ' 3 5 Встроенный режим M M A d j = (EAF)2,8(KELOC)'' 20 TDEV = 2,5(MM A d j ) 0 ' 3 2 ELOC = (строки адаптированного программного кода) (1/100) (0,4*Процент модифицированных проектов + 0,3* Процент модифицированных программных кодов + 0,3 Процент модифицированных сборок) Рис. 12.4. Уравнения модели СОСОМО для организованных, полуорганизованных и встроенных режимов Месяцы В Организованный • Полуорганизованный D Встроенный Организованный Разброс в показателях режимов СОСОМО Относительно более медленный старт, начинающийся с меньших значений, и более высокие пиковые требования к кадровому обеспечению встроенного режима становятся очевидными на более высоких точках его графика, расположенного в глубине диаграммы; графики полуорганизованного и организованного режимов (на переднем плане) проходят ниже. Рис. 12.5. Режимы модели СОСОМО: организованный, полуорганизованный и встроенный Глава 12. Технологии оценки трудозатрат на т е с т и р о в а н и е и советы 273 В промежуточных и детализированных моделях СОСОМО применяется коэффи циент EAF (Effort Adjustment Factor— к о э ф ф и ц и е н т уточнения трудозатрат), пред ставляющий собой произведение табличных значений драйверов стоимости про граммного обеспечения, сведенных в таблицу 12.2. В базовой модели С О С О М О к о э ф ф и ц и е н т EAF (Effort Adjustment Factor— коэф ф и ц и е н т уточнения трудозатрат) не используется. Единственное различие между промежуточной и детализированной моделями СОСОМО заключается в том, что в промежуточной модели С О С О М О на всех стадиях применяется один и тот же коэф ф и ц и е н т EAF, в то время как в детализированной модели СОСОМО перемножаются различные драйверы стоимости. В результате для каждой стадии получается свой к о э ф ф и ц и е н т EAF, который применяется на соответствующем этапе вычисления трудозатрат. Единственное различие между моделью СОСОМО и моделью REVIC (Revised and Improved С О С О М О — пересмотренная и улучшенная модель СОСОМО) связано с тем, какие к о э ф ф и ц и е н т ы и экспоненты присутствуют в уравнениях для вычисления количества человеко-месяцев ( М М ц ) и времени разработки (TDEV). На рис. 12.6 значение TDEV откладывается на временной оси графика; в рассмат риваемом случае площадь, ограниченная 18 месяцами и кривой, представляющей изменения значений трудозатрат (MM A d j ), есть суммарное количество персонала за 18 месяцев. Главный драйвер стоимости модели COCOMO/REVIC — это число KLOC (Lines Of Code — тысячи строк программного кода), изображенное в центре диаграм мы на рис. 12.6 в форме отверстия монетоприемника. Остальные драйверы стоимо сти показаны в виде циферблатов, стрелки которого указывают на избранный атри бут драйвера стоимости. В этом случае коэффициент EAF есть произведение значе ний, связанных (через поисковую таблицу) с каждой установкой циферблата. Подоб ное изображение, выполненное в духе графического пользовательского интерфейса, упрощает разработчику модели понимание последовательности событий этого про цесса. Во-первых, необходимо установить показания циферблатов, затем опустить число KLOC в отверстие монетоприемника, запустить модель в работу и на выходе получить готовое произведение. График вычерчивает значения человеко-месяцев, при этом площадь под кривой представляет собой общие трудозатраты, которые по требуются на реализацию всех видов деятельности, которые необходимо выполнить при разработке программного продукта. Время на разработку (TDEV) откладывается по горизонтальной оси графика. Этот процесс повторяется для различных драйверов стоимости, достаточно ввести соответствующий драйвер либо ввести новые значе ния размеров и запустить модель. Следует отметить, что существует прямая связь между трудозатратами (MM A d j ) и временем, затрачиваемым на разработку (TDEV), которая проявляется в том, что при уменьшении KLOC снижаются и трудозатраты, которые, в свою очередь, приводят к уменьшению времени до поставки. И наоборот, если составитель модели узнает, что работу над проектом прекращает специалист по ключевым системам проекта, кото р ы й разрабатывает архитектуру и сам программный проект, необходимо скорректи ровать показания циферблатов АСАР и АЕХР, вследствие чего трудозатраты (MM A d j ) могут возрасти, что, в свою очередь, приведет к увеличению времени на разработку (TDEV). И, наконец, если для вычислений используется средняя стоимость единицы персонала, занимающегося разработкой, то эта стоимость находится в линейной за висимости от вычисленных трудозатрат. 274 Часть II. Технологии быстрого тестирования и советы Таблица 12.2. Значения драйвера стоимости после перемножения дают коэффициент уточнения трудозатрат [6]. Очень Драйвер стоимости низкий Атрибуты программного продукта Низкий Рейтинги Номи нальный Высокий Очень высок. Исключ. высокий RELY (Требуемая надежность 0,75 0,88 1,00 1,15 1,40 программного продукта) DATA (Размер базы данных) - 0,94 1,00 1,08 1,16 CPLX (Сложность 0,70 0,85 1,00 1,15 1,30 программного продукта) Атрибуты компьютера 1,65 TIME (Ограничения на время выполнения) STOR (Ограничения на основную память) VIRT (Изменчивость виртуальной машинная) TURN (Безремонтный срок службы компьютера) 0,87 0,87 1,00 1,00 1,00 1,00 1,11 1,06 1,15 1,07 1,30 1,21 1,30 1,15 1,66 1,56 Персональные атрибуты АСАР (Производительность 1,46 1,19 1,00 0,86 0,71 системного аналитика) АЕХР (Квалификация 1,29 1,13 1,00 0,91 0,82 системного аналитика) РСАР (Производительность 1,42 1,17 1,00 0,86 0,70 программиста) VEXP (Опыт работы на 1,21 1,10 1,00 0,95 виртуальной машине) LEXP (Опыт работы с 1,14 1,07 1,00 0,95 языками программирования) Атрибуты проекта MODP (Правила современного 1,21 1,10 1,00 0,91 0,82 программирования) TOOL (Использование 1,21 1,10 1,00 0,91 0,83 инструментальных средств программирования) SCED (Требуемый график 1,23 1,08 1,00 1,04 1,10 разработки) Глава 12. Технологии оценки трудозатрат на т е с т и р о в а н и е и советы 275 Объект модели COCOMO/REVIC IKLOC RELY Ada-уравнения, используемые в модели REVIC, объектно-ориентированном анализе и объектно-ориентированном проектировании ММ 'Adj EAFx6,8x(KLOC) 0 ' 9 4 TDEV = 4,376 x(MMAdj) 0 ' 3 2 ПЭП Пересмотр эскизного проекта КПП Критический пересмотр проекта ПГТ Пересмотр готовности к тестированию. ЗТК Заключительное тестирование качества Рис. 12.6. Графический пользовательский интерфейс модели COCOMO/REVIC описывает процесс вычислений Как отмечалось ранее, одно из требований, предъявляемых к модели сметной стоимости программного обеспечения, обусловливает ее модульность. Составитель такой модели, по меньшей мере, должен иметь возможность делать разрезы трудоза траты по стадиям разработки, по ролям разработчиков и по сборкам. На рис. 12.7 приводится уравнение рэлеевской кривой, а также трудозатраты (количество персо нала) по месяцам, описываемые кривой кадрового обеспечения. Эта кривая обладает дополнительным свойством, которое заключается в том, что она разбита на типовые стадии разработки: R E Q (документирование требований), PD (эскизное проектиро вание), DD (рабочее проектирование), CUT (тестирование кода и модулей), IT (ком плексные и системные испытания). Вычисление сметной стоимости проекта невоз можно, пока не будет завершена стадия REQ, поэтому в соответствии с соглашением о разметке оси абсцисс, первый месяц стадии PD помечается 1, в то время как метка ми двух месяцев, предшествующих стадии PD, когда выполняется REQ, будут 0 и -1. В случае спиралевидных процессов разработки на стадии REQ должны выполняться общие требования для всех сборок, таким образом, несложно обнаружить, что стадия R E Q отделена от стадии PD на некоторый период задержки. TDEV, время, затрачиваемое на разработку, и ММ, человеко-месяцы, вычисляются по формулам, приведенным на рис. 12.6. Staffing(t) представляет собой количество персонала; значение этого показателя указывается на рис. 12.7 для каждого месяца, при этом t изменяется от -1 до 19. 276 Часть II. Технологии быстрого тестирования и советы Рис. 12.7. Графическая схема модели СОСОМО трудозатрат на стадии разработки И хотя модель С О С О М О не предназначена для получения затрат на эксплуатацию для унаследованных систем, вариант, показанный на рис. 12.8, обеспечивает доста точно точные результаты. Затраты на эксплуатацию MM M a i n t в течение трех лет после выпуска унаследованной системы могут быть подсчитаны на основе интенсивности годичных изменений, которая согласно эмпирическому правилу, составляет в сред нем, соответственно, 15%, 10% и 5% от трудозатрат на создание унаследованной сис темы. Пример, представленный на рис. 12.8, построен для программы объемом в 50 KLOC, на разработку которой потребовалось 362 человеко-месяца, при этом в тече ние первых 12 месяцев 4,525 человека были заняты поддержкой унаследованной сис темы. Такой подход можно применить в случае, когда подрядчик получает новый про граммный COTS-продукт (commercial-off-the-shelf, доступный в продаже) такого же объема (50 KLOC). Предположим, что подрядчик настаивает на добавлении новых функциональных свойств в COTS-продукт, на осуществление которого потребуется не менее двух лет. Этот подрядчик должен требовать новых разработок объемом X KLOC, интегриро ванных в сборку размером X + 50 KLOC, и добавить к соответствующим трудозатра там 4,525 человеко-месяца на первый год и 3,017 человеко-месяца на второй год к трудозатратам на эксплуатацию COTS-продукта. Имея среднюю оплату $55 за челове ко-час, или $8305 за человеко-месяц, примите, что один месяц состоит из 151 оплачи ваемого часа. Стоимость трудозатрат за два года составит в этом случае $8305 * 7,542 = $62636. Обратите внимание на то обстоятельство, что в данном случае ничего не ска зано по поводу того, что какие средства были потрачены на унаследованный COTS- продукт его поставщиком, поскольку значение 362 человеко-месяца было вычислено на основании коэффициента EAF вашей компании, который определялся с учетом особенностей процесса разработки программного обеспечения внутри компании. Кривые кадрового обеспечения модели СОСОМО, взятые из динамической электронной таблицы модели СОСОМО Рэлеевская кривая: |