Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 11. Разработка и использование показателей тестирования 259 LD ТС EU DO LD ТС EU Уровень детализации Техническое содержание Применение языка Документация DO ST ID TR CM ST ID TR CM Типы дефектов Стандарты Унаследованные Прослеживаемость Полнота DA IF ОТ MR DA Данные IF Интерфейс ОТ Прочие MR Пригодность для сопровождения и повторного использования Рис. 11.9. Проектно-ориентированная модель ошибок. Программа оценки ошибок программного обеспечения (SWEEP) Программа оценки ошибочности программного обеспечения (Software Error Estima tion Program, SWEEP), разработанная консорциумом Software Productivity Consortium, является средством прогнозирования для расчета коэффициентов ошибок, в том числе и скрытых. Скрытой ошибкой считается любая ошибка, остающаяся в про граммном продукте, т.е. такая ошибка, которая существует, но еще не обнаружена. Ценность модели SWEEP состоит в том, что она упрощает управление и прогнозиро вание ошибок в системах с интенсивным использованием программного обеспече ния. Эта модель поддерживает определение целей обнаружения ошибок во время разработки программного обеспечения и помогает отслеживать продвижение по пу ти реализации этих целей. За счет прогнозирования количества ошибок, остающихся в программной системе, SWEEP осуществляет мониторинг и помогает контролиро вать качество программных продуктов. Н и ж е приведен перечень допущений, лежа щих в основе модели: • Все обнаруженные ошибки должны быть записаны в момент их обнаружения. • Ошибки исправляются после их обнаружения, и во время устранения обнару женных ошибок не вносятся новые ошибки. • Трассировка ошибок должна выполняться единообразно в течение всех этапов жизненного цикла. 260 Часть II. Технологии быстрого тестирования и советы • Ошибки в документации должны отслеживаться отдельно от программных ошибок. • Входные данные программы SWEEP должны регулярно проверяться и обнов ляться. • Точность результатов выполнения программы SWEEP будет повышаться про порционально вводу фактических количеств ошибок, полученных на других этапах процесса разработки. Определения трех режимов использования программы SWEEP приведены в таб лице 11.7. Таблица 11.7. Определения режимов программы SWEEP Режим Название Особенности 1 Модель с привязкой Позволяет оценивать и отслеживать ошибки на этапах ко времени системных и комплексных испытаний. 2 Модель с привязкой Позволяет прогнозировать и отслеживать ошибки на к этапам нескольких этапах и может предоставить информацию об ошибках до выполнения какого-либо кода. 3 Модель поддержки Дает возможность пользователю определить цели об- планирования наружения ошибок в программном проекте, исходя из опыта предыдущих проектов. Затем на основе ранее собранных данных модель генерирует профиль обна ружения ошибок, помогающий в достижении сформули рованных целей. Тестировщикам программного обеспечения SWEEP предлагает понятное графи ческое представление обнаруженных ошибок и прогноза оставшихся ошибок. Кроме того, она дает возможность пользователям выполнять сравнение с ранее полученны ми данными, что делает реальной точную оценку состава скрытых ошибок на различ ных этапах жизненного цикла. Руководителю подразделения обеспечения качества программа SWEEP позволяет точно прогнозировать количество циклов тестирова ния, которые потребуются для удовлетворения требований заданного стандарта ка чества. Пример модели SWEEP, в которой используется привязка к этапам, приведен на рис. 11.10. Обратите внимание, что в данном проекте только что завершилась ин спекция начального исходного кода на предмет его соответствия рабочей проектной документации, в ходе которой было обнаружено 3,48 ошибок на тысячу строк кода. Наибольшее совпадение рэлеевскои кривой распределения ошибок с фактическими данными наблюдается для момента получения самых последних данных, и ему соот ветствует значение, равное 3,48. Значения 3,3 и 7,8, полученные, соответственно она этапах эскизного и рабочего проектирования, проходят через это же значение 3,48. В соответствии с этой рэлеевскои кривой распределения на следующем этапе тестиро вания блоков следует ожидать обнаружения около 2,12 ошибок на тысячу строк ис ходного кода. В случае сохранения той же тенденции в момент поставки клиенту про граммный продукт должен содержать менее 0,07 ошибок на тысячу строк кода. Глава 11. Разработка и использование показателей тестирования 261 Гистограммы данных обнаружения и рэлеевской функции распределения ошибок Системные испытания 10.07 Ш Рэлеевская функция распределения • Фактические данные Комплексные испытания Тестирование модулей Кодирование Рабочее проектирование Эскизное проектирование 2 3 4 5 6 7 Количество ошибок на тысячу строк кода Рис. 11.10. Режим 2 SWEEP: модель с привязкой ко времени Следующим логическим шагом процесса было бы усреднение для большого числа проектов фактических данных о количестве ошибок, приходящихся на тысячу строк кода, которые обнаружены на каждом из этапов (ЭП, РП, ТКМ, КИ и СИ). В следую щем проекте должна иметься возможность использования этих данных, обозначен ных на рис. 11.11 как "Номинальные значения", в качестве меры количества ошибок, обнаружение которых следует ожидать при выполнении проекта с таким же уровнем качества, или даже меры прекращения дальнейшего тестирования во имя повышения производительности инспекций. Верхний и н и ж н и й пределы уровня контроля каче ства могут быть установлены, например, равными трем сигма от номинальных значе ний данных. Рэлеевская функция распределения ошибок представляет собой важный инстру мент в арсенале инженера системного тестирования. На этапе системного тестиро вания все существующие случаи тестирования применяются методично день за днем, в ходе выполнения тестирования новых подсистем и регрессивного тестирования новых сборок, в которых устранены ошибки, обнаруженные в предыдущих сборках. На рис. 11.12 показаны фактические данные ошибок, собранные в ходе выполнения ряда системных испытаний кандидатов на роль выпусков. П р и этом сборки выполня лись еженедельно, а обнаруженные ошибки наносились на столбчатую диаграмму ежедневно. Вычерчивание огибающей было выполнено автоматически при помощи модели с использованием привязки ко времени программы SWEEP. Обратите внима ние, что если заранее было определено допустимое количество ошибок на тысячу строк кода, которое может быть поставлено клиенту, тестировщики могут смело ис пользовать эту диаграмму для определения условий прекращения этапа системных испытаний. 262 Часть II. Технологии быстрого тестирования и советы Статистическая диаграмма контроля качества Системные испытания Комплексные испытания Тестирование модулей Кодирование Рабочее проектирование Эскизное проектирование • Нижнее предельное значение • Номинальное значение • Верхнее предельное значение 30 35 40 45 Количество ошибок Рис. 11.11. Совмещенная модель поддержки планирования и модель с привязкой к этапам программы SWEEP. i i i 11 l м i i 11 i i i i i 111 11 i 11 11 i i nTnPi'Wxw^ ,,-. Дни Рис. 11.12. Использование модели с привязкой ко времени программы SWEEP для оценки данных по ошибкам на этапе системных испытаний. Глава 11. Разработка и использование показателей тестирования 263 Резюме Проблемы и их решения, выбранные для исследования в этой главе, связаны с при менением программных показателей к выполнению тестирования как с учетом инте ресов данного проекта, так и с учетом интереса всей организации в целом. Н и ж е приведен краткий перечень вопросов, рассмотренных в главе: • Различия между показателями и данными измерений. • Двухуровневый подход к сбору и анализу данных измерений. • Полезные общеорганизационные показатели, а именно: показатели объема, трудоемкости, календарного графика и качества. • Принцип выбора показателей уровня проекта, названный принципом "цель- вопрос-показатель" (ЦВП). • Использование показателей для управления и совершенствования процесса разработки программного обеспечения. • Перечень показателей тестирования (относящихся ко второму уровню). • Разработка модели ошибок, которая может применяться при отслеживании процесса и повышении качества. • Определение конечной цели тестирования, а именно: применение прогнози рования плотности ошибок, использование программы SWEEP и достижение конечного качества, т.е. количества скрытых ошибок, приходящегося на тыся чу строк кода, которые поставляются конечному пользователю. Во многих успешных проектах показатели используются для повышения нагляд ности и контролепригодности календарного графика, характеристик качества и стоимости. Лишь в отдельных неудачных проектах применение показателей приво дило к разрушению доверительных отношений, столь необходимых во время разра ботки программного обеспечения. Основной причиной возникновения сбоев в про граммах определения показателей проекта практически всегда является "поиск ви новных". Поиск виновных в ошибке (будь то отдельный исполнитель или группа лиц, принимавших участие в разработке) вовсе не является целью применения показате лей. О н и предназначены исключительно для эффективного управления разработкой программного обеспечения и качеством продукта. Технологии оценки \ трудозатрат на \ тестирование и советы Темы, рассматриваемые в главе: • П р и м е н е н и е м а т е м а т и ч е с к и х методов для о ц е н к и п р о г р а м м н о г о о б е с п е ч е н и я • Т е х н о л о г и я ф у н к ц и о н а л ь н ы х баллов • Р е з ю м е Целью настоящей главы является описание точного метода прогнозирования кадро вого обеспечения по месяцам для подготовки тестирования и прогона тестов, кото рое обычно называется верификацией и аттестацией (verification and validation. V&V). Выбранный нами подход основан на изучении последовательности примеров, в рамках которых используется набор инструментальных средств, разработанных авторами. Существует целый ряд методов построения графиков работ и календарного пла нирования ресурсов для проведения тестирования проекта. Простейший метод по лучил название прогнозирование с использованием модели с базисом оценок (basis of estimates, BOEs). Оценка по аналогии (by-analogy estimate) основана на фактических данных о распределении ресурсов на некотором множестве прошлых проектов ана логичной архитектуры, с одними и теми же языками программирования и аналогич ными подходами к тестированию. Оценки будущего проекта, если в их основу поло жены оценки по аналогии, строятся на правдоподобии за счет использования эмпи рических фактов с инкрементальным совершенствованием, которые основаны на объединении решений мелкого масштаба. Инкрементальное совершенствование уве личивает точность прогнозирования. В число предлагаемых примеров входит клас сификация программных продуктов по их размерам и оценка ресурсов групп под держки, например, группы обеспечения качества, группы управления конфигурацией и руководство разработкой программы. Глава 12. Технологии оценки трудозатрат на тестирование и советы 265 ПРИМЕР 1. П О Д Х О Д К ОЦЕНКЕ (ГЭРИ КОББ) Одним прекрасным утром я получил по электронной почте письмо, которое начиналось так: "Можете ли вы предложить какие-либо методы оценки объемов трудозатрат и не о б х о д и м ы х ресурсов для проведения работ по тестированию программного обеспече н и я , а также для расчета графика этих работ?" Далее в письме говорилось: "Наша груп- па разработала таблицу результатов, в которую сводятся результаты измерений харак- теристик нашего процесса и прогнозы относительно текущего состояния проекта в це- лом, в зависимости от которых ему присваивается "красное", "желтое" или "зеленое" состояние. Чтобы осуществить это мероприятие, мы назначили некоторым из наших групп статус ведущих, в то время как другие получили такие названия, как, например, консультант PCQA (Product Certification and Quality Assessment — сертификация и управ л е н и е качеством программного продукта). Принимая во внимание состояние наших по- следних разработок, можете ли вы предложить какой-то способ оценки объемов тру- дозатрат и ресурсов, необходимых для проведения работ по тестированию программ ного обеспечения, а также для расчета графика этих работ?" В ответ я направил следующее предложение: метод оценки качества программного обеспечения, который, по моему мнению, м о ж н о будет внедрить в вашем подразделе- нии, принимает следующий вид (за цель принимается уровень качества): 1. Разбейте весь персонал разработчиков по исполняемым каждым сотрудником ролям (т.е. специалисты по формулированию технических требований, архитекторы программ ного обеспечения, разработчики, кодировщики, тестировщики, руководитель разработ ки, персонал, управляющий конфигурацией средств тестирования, персонал, выполняю щий сертификацию программного продукта, группа контроля качества и другие). 2. Воспроизведите полный рабочий график двух последних успешно завершенных про ектов, например, поставленных заказчику в установленные сроки, без перерасхода сметной стоимости и приемлемого качества, и распределите временной ресурс и финансовую смету по ролям, определенным в пункте 1. 3. Вычислите величину показателя LOE (Level Of Effort — уровень трудозатрат) для ка ждой роли, т.е. LOE(j) для каждого j = 1,...,п, где п есть число ролей, выраженное через временной эквивалент FTE (Full-Time-Equivalent — эквивалент полного рабочего дня) в человеко-месяцах. ' 4. Вычислите сумму S в человеко-месяцах для каждого из этих показателей LOE по ка ж д о м у проекту. Подсчитайте, какая доля в процентном отношении от общих трудо затрат приходится на каждую такую роль, например, как LOE(j)/S, для j = 1 п в рамках каждого проекта, и сравните обе таблицы процентных отношений. 5. Вычислите среднее значение LOE(j)/S, для j = 1,...,n для обоих проектов, чтобы ка либровать модель значений LOE(j), предназначенную для прогнозирования значений LOE(j) для новых проектов. 6. Оцените размер программного продукта в тысячах строк KESLOC (Estimated Source Lines Of Codes — предполагаемое количество строк исходного кода) для каждого проекта. KESLOC можно получить путем прямого подсчета строк исполняемого к о да, отличных от комментариев, включая строки всех сценариев, которые не являются частью продукта, но были разработаны для вспомогательных целей. В качестве аль тернативы можно подсчитать все функциональные баллы (рассмотренные далее в главе) и при помощи таблицы перевода Кейперса Джонса (Capers Jones), которая приводится в таблице 12.1, получить KESLOC для функциональных баллов. 7. Вычислите коэффициент EAF (Effort Adjustment Factor — коэффициент уточнения трудозатрат) из уравнения EAF = S/(2.4*(KESLOC**1,05)). Отсюда может быть вы ведена формула перевода размера продукта в трудозатраты: S = EAF*2.4*(KESLOC**1,05), где EAF получена на основании базиса оценок, a KESLOC прогнозируется на основе задокументированных требований. 266 Часть II. Технологии быстрого тестирования и советы На мой первый ответ по электронной почте пришло письмо следующего содержания: "Я благодарю вас за то, что вы не пожалели своего времени, чтобы ответить мне, однако ваш ответ привел меня в еще большее замешательство. Вот почему я так долго не от- вечал вам — я даже не знаю, что больше всего меня озадачило. Предложенный вами подход хорош, однако он предполагает, что необходимые данные находятся где-то ря- дом. В то же время у нас нет доступа к данным о трудозатратах, а то, что у нас есть, особой ценности не представляет. Единственное, что приходит в голову, так это найти аналогичный завершенный проект и воспользоваться фактическим количеством строк кода в нем как оценкой текущего проекта. Находите ли вы мое суждение имеющим СМЫСЛ?" Я отправил по электронной почте второе послание, в котором заметил: "Да, это один из способов стабилизации вашей оценки, например, с помощью базиса оценки программ- ного кода предыдущего проекта. Вы также можете собрать меньшие оценки уровней LOE для используемого набора ролей и количество исполнителей на каждой роли, на- пример, число руководителей проектов, программистов, тестировщиков различных cne- циальностей, специалистов по управлению конфигурациями, лиц, ответственных за каче- ство программного продукта, специалистов по подготовке сборок, по проведению ис- пытаний, лиц, осуществляющих контроль производством и прочих. Сюда следует вклю- чить и расширенные группы, такие как группа подготовки документации, группа инст- рукторов, занимающихся обучением пользователей, группа специалистов, проводящих пробные испытания, группа экономистов, решающих вопросы конъюнктуры, группа суб- подрядчиков и т.п. Если вы располагаете такими сведениями, разделите соответствую- щие значения на общее число сотрудников, чтобы получить процентное отношение тру- дозатрат, а затем воспользуйтесь этими данным для нового подсчета трудозатрат. Точ ность этих расчетов находится в пределах 30%. Между прочим, 3 0 % — это, на мой взгляд, несколько лучше, чем ошибки в 2 или даже в 4 раза, которые допускают раз- работчики программного обеспечения, раздувая сметную стоимость и трудозатраты. Удачи." Формулы, используемые в этом исследовании, заимствованы из модели СОСОМО, предложенной Боемом (Boehm). Описанные выше семь шагов используют для полу чения коэффициента EAF скорее метод инженерного анализа, а не подход д-ра Бое- ма, описание которого можно будет найти далее в главе. П р и получении оценок возможны просчеты, причина которых кроется в стати стических данных за прошлый период: • В предыдущем и текущем проектах могли использоваться различные языки программирования, различные этапы жизненного цикла, различные техноло гии экспертных оценок и т.д. Из-за несоответствий в упомянутых областях применение статистических данных может привести к получению неточных рабочих графиков и оценок затрат. • Часто трудно противиться желанию вычислять временные затраты и трудоза траты, исходя из предположения их линейной зависимости от производитель ности, вычисленной для прошлого проекта. Например, в рамках прошлого проекта была достигнута производительность в размере 1 строки программно го кода за один рабочий час на программе в 5 KESLOC, следовательно, для раз работки программы, состоящей из 50 KESLOC, при производительности 1 строка программного кода за один рабочий час, потребуется в 10 раз большее время. Это неверно, поскольку с увеличением размеров программы трудозатра ты возрастают по экспоненциальному закону, а не по линейному. |