Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 11. Разработка и использование показателей тестирования 251 Рис. 11.6. Принцип "целъ-вопрос-показатпелъ" (ЦВП). Использование стандартных показателей для внесения усовершенствований Простое выполнение в рамках одной организации множества проектов по разработ ке, направленных на совершенствование процесса, еще не гарантирует создание про фаммного обеспечения мирового класса. Если каждая команда выбирает собствен ное направление совершенствования процесса или продукта, оптимизация процесса будет носить случайный характер. В этом случае локальная оптимизация выливается в одно из направлений глобальной оптимизации. Для обеспечения быстрой оптими зации профаммного обеспечения усилия должны быть согласованы в рамках всей организации с соблюдением общего для нее подхода. Успешность совершенствова ния управления процессом разработки программного обеспечения определяется сле дующими факторами: • Точным прогнозированием взаимосвязи между функциональными возможно стями программного обеспечения и его объемом, количеством занятого в раз работке проекта персонала, календарным графиком и качеством проекта. • Определением задач и ресурсов/качества/стандартов, необходимых для ре шения каждой задачи. • Обеспечением успешности и требуемой производительности при выполнении каждого шага процесса. • Максимально быстрым выявлением дефектов после их появления. • Обработкой дефектов таким образом, чтобы обеспечить максимально быстрое эффективное устранение наиболее важных дефектов. 252 Часть П. Технологии быстрого тестирования и советы Рекомендуемая стратегия создания сопровождающей документации по этой мето дике определения программных показателей состоит из двух частей: 1. Применение стандартного набора определений показателей и последующий сбор и анализ данных программных измерений в рамках всех выполняемых в организации проектов. 2. Применение процесса принятия решений "цель-вопрос-показатель" для выбо ра проектных программных измерений. Одно из наиболее эффективных действий, ведущих к совершенствованию про цесса — это управление способом прогнозирования ресурсов с целью повышения его точности. Если прогнозируемые значения нанести на диаграмму процесса разработ ки с привязкой к каждому из основных промежуточных этапов, после чего сравнить совпадение кривых обучения с фактическими данными, можно отслеживать точность прогнозирования. П р и м е р применения этой технологии к прогнозированию загруз ки персонала показан на рис. 11.7, который взят из [6]. Прогнозируемые данные приводятся к среднему значению А и наносятся на диаграмму, по горизонтальной оси которой отсчитывается время в месяцах. Круглые точки представляют нормализо ванные прогнозируемые значения, причем последнее прогнозируемое значение при ходится на конец 7-го месяца. На диаграмму можно наложить кривые функций U и L (обозначенные квадратиками) и тем самым определить показатель экспоненты В. Чем выше значение В, тем быстрее прогнозируемые значения начинают совпадать с фактическими. 0 5 10 15 Границы кривой обучения (иллюстрирует управление процессом прогнозирования и повышение точности) Рис. 11.7. Совпадение кривых обучения с нормализованными прогнозируемыми данными. Глава 11. Разработка и использование показателей тестирования 253 На основе значений, полученных в ходе предыдущих разработок, можно создать обеспечивающую приемлемую точность модель прогнозирования количества персо нала/календарных сроков разработки программного обеспечения, которая пред ставляется нелинейной функцией от объема программы. Результаты корректно вы полненного моделирования могут избавить руководителей от сложных проблем, воз никающих при использовании простой линейной модели прогнозирования трудоем кости и времени, требующегося для выполнения проекта. Например, в соответствии с простой линейной моделью, если новая разработка вдвое превосходит по объему предыдущую, ее бюджет должен вдвое превосходить стоимость предыдущей разра ботки. В действительности же зависимость между затратами и объемом разработки не линейна, и при использовании неподходящей модели ошибка прогнозирования может оказаться весьма значительной. Прежде чем можно будет воспользоваться нелинейной моделью зависимости от объема программного обеспечения, потребуется выполнить следующие четыре задачи: 1. Собрать данные, полученные в ходе выполнения предшествующих проектов, аналогичных оцениваемому. Сюда должны входить и данные, относящиеся к объему проекта, фактическим финансовым показателям, календарным срокам и факторам среды разработки. 2. По аналогии с предыдущими проектами разработать оценки, сравнивая тру доемкость, фактические финансовые показатели, данные программных пока зателей и факторы среды разработки нового проекта с соответствующими показателями аналогичных проектов. 3. Создать календарный график выполнения основных промежуточных этапов, на базе которого создать календарный график выполнения всего проекта по месяцам. 4. Завершить оценку, определив количество персонала, необходимого для вы полнения каждой задачи, и распределить загрузку персонала по соответст вующим этапам календарного графика разработки. Сообщение всеми группами разработки таких данных измерений, как показатели объема, занятости персонала, стоимости и качества, в центральную организацию на подобие SEPG обеспечивает проверку различных проектов на предмет единообразия выполнения. Кроме того, эти данные измерений поддерживают нелинейное модели рование общеорганизационных процессов разработки, которые определены на ос нове фактических данных измерений, полученных в ходе выполнения предыдущих проектов в аналогичной среде разработки. Точное прогнозирование характеристик новых проектов направлено на резкое снижение хаоса в организации, и сбор и ана лиз данных измерений этих стандартных показателей в значительной степени спо собствует достижению такой цели. Общий для конкретной организации процесс управления данными измерений должен включать в себя каждый из пяти видов дея тельности, перечисленных в таблице 11.3. 254 Часть II. Технологии быстрого тестирования и советы Таблица 11.3. Виды деятельности по подготовке к прогнозированию и их определения Виды деятельности Определения Сбор/упорядочение Прямые данные измерений собираются, а производные данные данных измерений вычисляются, после чего они форматируются для внесе ния в базу данных. Сохранение/ Прямые и производные данные измерений сохраняются в базе дан- извлечение данных ных ранее выполненных разработок, которая служит основным ис точником исходной информации при принятии решений. Анализ данных Данные измерений исследуются для выяснения тенденций и откло нений от среднестатистических данных (значительных отклонений от ожидаемых норм). Обобщение Данные измерений и анализа моделируются, информации Распространение Обобщенные отчеты (о состоянии, прогнозы, анализы вероятности информации возникновения проблем) распространяются среди лиц, принимаю щих решения. Если проекты разработки программного обеспечения поддерживаются общеор ганизационными функциями сбора и анализа данных измерений, это позволяет управлять совершенствованием процесса и сравнивать его результаты с результата ми, полученными в ходе ранее выполнявшихся разработок. В результате снижается доля специализированных или скоропалительных изменений, которые препятствуют организации повышать качество или сокращать сроки поставки программных про дуктов на рынок. Календарные сроки, качество и затраты — основные показатели коммерческой деятельности. Поэтому, чтобы организация, занимающаяся разработ кой программного обеспечения, смогла выжить в условиях конкуренции, процессы создания программного обеспечения должны оцениваться именно с таких коммерче ских позиций. П р и н ц и п быстрого тестирования обеспечивает совершенствование процесса в следующих областях: • Календарного планирования — путем выделения дополнительных ресурсов для действий по тестированию до начала этапа ТКМ, что позволяет ужать кален дарные сроки выполнения действий по тестированию на последующих этапах и способствует ускорению поставки на р ы н о к очередных выпусков программ ных продуктов. • Качества — путем обнаружения и устранения большего количества дефектов, что снижает процент скрытых дефектов в выпущенных продуктах. • Стоимости — путем снижения одноразовых затрат, объем которых выше в тех проектах, где обнаружение и устранение дефектов откладывается до заключи тельных этапов жизненного цикла. Глава 11. Разработка и использование показателей тестирования 255 Показатели тестирования Если вспомнить концепцию двухуровневой программы определения показателей, может возникнуть вопрос о ее применимости к показателям тестирования. Относят ся ли показатели тестирования к более высокому, общеорганизационному уровню, или же к проектно-зависимому уровню этой двухуровневой программы? Как будет показано в этом разделе, почти все показатели тестирования относятся к категории проектно-зависимых показателей. Примеры показателей тестирования, используе мые в проектах, приведены в таблице 11.4. Таблица 11.4. Категории показателей тестирования с примерами Показатель тестирования Определение Ошибки предикативной логики Ошибки индексирования/ пределов циклов Прогресс тестирования Заявки на изменения и изменчивость элементарных действий Отсутствующие/неполные требования Прогресс проектирования Количество ошибок, обнаруженных в утверждениях логических конструкций (IF, WHILE, CASE и т.п.), приходящихся на тысячу эквивалентных строк кода. Количество ошибок, обнаруженных в индексировании или пре делах циклических конструкций (DO, FOR и т.п.) приходящихся на тысячу эквивалентных строк кода. Сравнение количества выполненных случаев тестирования и их общего запланированного количества на определенном промежутке времени (характеризует способность поддержи вать заданный прогресс тестирования). Количество оговоренных изменений продукта и направлений разработки (может служить признаком влияния на календар ный план и затраты). Количество обнаруженных дефектов, появившихся в результа те отсутствующих или неполных требований. Количество задокументированных требований — запланиро ванное по сравнению с фактическим (служит мерой способно сти поддерживать прогресс проектирования на этом раннем этапе). Разработка эффективной программы определения показателей требует строгой дисциплины при выполнении измерений, анализе результатов этих измерений и по строении отчета о тенденциях, о которых свидетельствует анализ. Требуемые для этого усилия и дисциплина могут существенно увеличить трудоемкость программы разработки показателей, но эти дополнительные усилия очень важны для успеха лю бой инициативы по совершенствованию процесса. Когда изменения для совершенст вования процесса вносятся в ходе выполнения проекта, измерения будут единствен ным способом определить ценность проделанных усовершенствований процесса. При сравнении одного проекта с другим сравнение полученных в ходе выполнения проекта данных — единственный способ выявления различий между проектами. 256 Часть II. Технологии быстрого тестирования и советы Плотность ошибок (количество ошибок на тысячу эквивалентных строк кода) Наиболее важные показатели тестирования связаны с ошибками (дефектами). Для проекта представляется вполне естественным выполнение конкретизации ошибок, разделение их по приоритетам и категориям. Как правило, разделение ошибок по приоритетам выполняется в соответствии с нормативами по определению уровня серьезности ошибок, как показано в таблице 11.5. Обратите внимание, что номер уровня серьезности присваивается таким образом, что 1 соответствует категории катастрофических ошибок, а 5 — категории неприятных ошибок. Определения серь езности, перечисленные в таблице 11.5, совпадают с определениями из таблицы 5.2 в главе 5. Таблица 11.5. Код серьезности Номер уровня серьезности Нормативы 1 Катастрофический — приводит к отказу системы, т.е. к пустому экрану или повреждению данных. 2 Серьезный — продукт не пригоден к использованию, т.е. приводит к ошибоч ным ответам, неправильным отчетам. 3 Умеренный — продукт пригоден к использованию, но дефект оказывает влия ние на действия, выполняемые клиентом. 4 Незначительный — продукт пригоден к использованию, дефект не оказывает влияния на действия, выполняемые клиентом. 5 Помеха — дефект может быть устранен в любое удобное время. Сбор данных о дефектах и создание гистограммы с использованием номеров серь езности, присвоенных каждому дефекту, позволяет аналитику описать качество вы пуска программы, который будет проверяться во время формальных пересмотров. П р и м е р гистограммы плотности ошибок, сгруппированных по номерам уровня серь езности, показан на рис. 11.8. Обратите внимание, что эти данные приведены к ожи даемому объему программы, выраженному в тысячах строк эквивалентного кода. Из приведенных на рис. 11.8 данных видно, что большой объем ошибок был обна ружен на ранних этапах жизненного цикла разработки. Из этих данных понятно, что для обнаружения ошибок на этапах разработки требований, проектирования и коди рования применялось статическое тестирование. Обратите также внимание, что на этапах РП и кодирования было обнаружено больше серьезных ошибок, чем на этапе КИ. Это означает, что тщательное тестирование продукта было начато задолго до этапа КИ — подход, который является отличительной чертой быстрого тестирова ния. Если создать программу определения показателей, которая обеспечивает под счет и составление отчетов об ошибках, обнаруженных на каждом из этапов жизнен ного цикла разработки, можно оценить и отобразить эффективность усовершенство ваний процесса по мере их внесения от проекта к проекту. Глава 11. Разработка и использование показателей тестирования 257 Рис. 11.8. Гистограмма плотности ошибок, сгруппированных по нескольким номерам уровня серьезности. Проектно-ориентированная модель ошибок Отдельные языки программирования могут быть более чувствительны к некоторым типам ошибок, чем другие. Например, какой-либо язык программирования может генерировать код, который особенно трудно сопровождать или повторно использо вать в других программах. Код, генерируемый другим языком, может оказаться более пригодным для Сопровождения или повторного использования, но может характери зоваться более низкой производительностью. Один из способов определения чувст вительности проекта к различным типам ошибок предполагает создание модели ошибок для данного проекта. Проекты, в которых используется один и тот же язык программирования, могут сравниваться, только если в них используется та же самая модель ошибок. Если при сравнении с моделью ошибок выясняется, что в данном проекте вероятность возникновения конкретного типа ошибок высока, это может служить признаком наличия систематической проблемы в методе разработки про граммного обеспечения. Иначе говоря, анализ данных ошибок скорее ведет к обна ружению просчетов в процессе разработки, а не в самом продукте. Перечень известных источников ошибок приведен в таблице 11.6. Ошибки могут быть разделены по категориям в ходе процесса пересмотров, когда комиссия прихо дит к согласию относительно категории основной причины проблемы. Например, если основная причина относится к категории ошибок прослеживаемости (TR), ко миссия по пересмотру определяет этап жизненного цикла проекта, на котором эта ошибка была внесена (например, этап эскизного проектирования (ЭП)). Эти катего рии могут быть представлены графически и проанализированы, как показано на 258 Часть II. Технологии быстрого тестирования и советы рис.11.9. Гистограмма, полученная в результате анализа, будет характерной для дан ного языка программирования и для данного жизненного цикла программного обес печения. Таблица 11.6. Категории ошибок проекта Код LD ТС EU DO ST Название категории ошибки Уровень детализации Техническое содержание Применение языка Документация Стандарты Определение категории ID TR СМ DA Унаследованные Прослеживаемость Полнота Данные IF ОТ MR Интерфейс Прочие Пригодность для сопровождения и повторного использования Отклонение от надлежащего уровня детализации: слишком подробно, недостаточно подробно, неполно. Техническое содержание неверно, допускает двоякое толкова ние, не соответствует стандартам. Ошибки орфографии, грамматики, пунктуации, употребления времен и другие ошибки применения языка. Документация не соответствует выполнению программы или другой документации. Несоответствие установленным стандартам форматов или процедур. К этой категории не относятся ошибки несоответст вия стандартам синтаксиса применения языка, орфографии или читабельности. Ошибки в повторно используемом или существующем коде. Несоответствие ранее выпущенным документам; противоре чия, недостаточное количество ссылок, неправильные ссылки. Конечный продукт или его документация требует дополнитель ной информации или реализации дополнительных функцио нальных возможностей. Отсутствие или ввод неправильных данных пользователем или из базы данных. Ошибки в интерфейсе. Ошибки, которые не могут быть отнесены ни к одной из выше указанных категорий. Сложность сопровождения или повторного использования; не достигнут компромисс между высокой сложностью и гибкостью. Еще одно преимущество анализа данных ошибок состоит в возможности автома тического сравнение следующего проекта с предыдущим. Это ведет к двум важным последствиям: во-первых, в ходе пересмотров внимание можно сосредоточить на об наружении наиболее вероятных ошибок и, во-вторых, можно иметь представление о том, оказывает ли некоторое изменение в процессе желаемое влияние на снижение вероятности определенного типа ошибок. Вообще говоря, анализ основных причин возникновения ошибок, подобный вы полненному при определении модели ошибок проекта, является мощным средством совершенствования процесса. Идентификация проблем в процессе разработки, их устранение и оценка эффективности процесса устранения представляют собой ос новные цели создания программы для выбора жестких показателей тестирования. |