Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Статистическая диаграмма контроля качества
Системные испытания
Комплексные испытания
Тестирование модулей
Кодирование
Рабочее проектирование
Эскизное проектирование
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 для оценки данных по ошибкам на этапе системных испытаний.
Резюме
Проблемы и их решения, выбранные для исследования в этой главе, связаны с при менением программных показателей к выполнению тестирования как с учетом инте ресов данного проекта, так и с учетом интереса всей организации в целом. Ниже приведен краткий перечень вопросов, рассмотренных в главе:
• Различия между показателями и данными измерений.
• Двухуровневый подход к сбору и анализу данных измерений.
• Полезные общеорганизационные показатели, а именно: показатели объема, трудоемкости, календарного графика и качества.
• Принцип выбора показателей уровня проекта, названный принципом " цель-вопрос-показатель" (ЦВП).
• Использование показателей для управления и совершенствования процесса разработки программного обеспечения.
• Перечень показателей тестирования (относящихся ко второму уровню).
• Разработка модели ошибок, которая может применяться при отслеживании процесса и повышении качества.
• Определение конечной цели тестирования, а именно: применение прогнози рования плотности ошибок, использование программы SWEEP и достижение конечного качества, т.е. количества скрытых ошибок, приходящегося на тыся чу строк кода, которые поставляются конечному пользователю.
Во многих успешных проектах показатели используются для повышения нагляд ности и контролепригодности календарного графика, характеристик качества и стоимости. Лишь в отдельных неудачных проектах применение показателей приво дило к разрушению доверительных отношений, столь необходимых во время разра ботки программного обеспечения. Основной причиной возникновения сбоев в про граммах определения показателей проекта практически всегда является " поиск ви новных". Поиск виновных в ошибке (будь то отдельный исполнитель или группа лиц, принимавших участие в разработке) вовсе не является целью применения показате лей. Они предназначены исключительно для эффективного управления разработкой программного обеспечения и качеством продукта.
Темы, рассматриваемые в главе:
• Применение математических методов для оценки программного обеспечения
• Технология функциональных баллов
• Резюме
Целью настоящей главы является описание точного метода прогнозирования кадро вого обеспечения по месяцам для подготовки тестирования и прогона тестов, кото рое обычно называется верификацией и аттестацией (verification and validation. V& V). Выбранный нами подход основан на изучении последовательности примеров, в рамках которых используется набор инструментальных средств, разработанных авторами.
Существует целый ряд методов построения графиков работ и календарного пла нирования ресурсов для проведения тестирования проекта. Простейший метод по лучил название прогнозирование с использованием модели с базисом оценок (basis of estimates, BOEs). Оценка по аналогии (by-analogy estimate) основана на фактических данных о распределении ресурсов на некотором множестве прошлых проектов ана логичной архитектуры, с одними и теми же языками программирования и аналогич ными подходами к тестированию. Оценки будущего проекта, если в их основу поло жены оценки по аналогии, строятся на правдоподобии за счет использования эмпи рических фактов с инкрементальным совершенствованием, которые основаны на объединении решений мелкого масштаба. Инкрементальное совершенствование уве личивает точность прогнозирования. В число предлагаемых примеров входит клас сификация программных продуктов по их размерам и оценка ресурсов групп под держки, например, группы обеспечения качества, группы управления конфигурацией и руководство разработкой программы.
|