- •Ю.М. Бородянский
- •Содержание
- •1. Верификация информационных систем
- •1.1. Концепция тестирования
- •1.2. Основная терминология
- •1.3. Организация тестирования
- •1.3.1. Три фазы тестирования
- •1.4. Требования к идеальному критерию тестирования
- •1.5. Классы критериев
- •1.5.1. Структурные критерии (класс I).
- •1.5.2. Функциональные критерии (класс II)
- •1.5.3. Стохастические критерии (класс III)
- •1.5.4. Мутационный критерий (класс IV)
- •1.6. Оценка Покрытия Программы и Проекта
- •1.7. Типы процессов тестирования и верификации и их место в различных моделях жизненного цикла
- •1.7.1. Модульное тестирование
- •1.7.2. Интеграционное тестирование
- •1.7.3. Системное тестирование
- •1.7.4. Нагрузочное тестирование
- •1.7.5. Формальные инспекции
- •1.8. Системное тестирование
- •1.8.1. Задачи и цели системного тестирования
- •1.8.2. Виды системного тестирования
- •1.8.3. Системное тестирование, приемо-сдаточные и сертификационные испытания при разработке сертифицируемого программного обеспечения
- •1.9. Задачи и цели процесса верификации
- •1.10. Тестирование, верификация и валидация – различия в понятиях
- •1.11. Документация, создаваемая на различных этапах жизненного цикла
- •1.12. Документация, сопровождающая процесс верификации и тестирования
- •1.12.1. Технологические процессы верификации и роли в проекте, документация, создаваемая в ходе жизненного цикла проекта, ее назначение
- •1.12.3. Стратегия и планы верификации
- •1.13. Тест-требования
- •1.13.1. Технологические цепочки и роли участников проекта, использующих тест-требования. Связь тест-требований с другими типами проектной документации.
- •1.13.2. Свойства тест-требований
- •1.13.3. Тест-планы
- •1.13.3.1 Технологические цепочки и роли участников проекта, использующих тест-планы. Связь тест-планов с другими типами проектной документации.
- •1.13.4. Возможные формы подготовки тест-планов
- •1.13.5. Сценарии
- •1.14. Формальные инспекции
- •1.14.1. Задачи и цели проведения формальных инспекций
- •1.14.2. Этапы формальной инспекции и роли ее участников
- •1.14.2.1. Инициализация
- •1.14.2.2. Планирование
- •1.14.2.3. Подготовка
- •1.14.2.4. Обсуждение
- •1.14.2.5. Завершение
- •1.14.3. Документирование процесса формальной инспекции
- •1.14.3.1. Бланк инспекции
- •1.14.3.2. Титульный лист
- •1.14.3.3. Список контрольных вопросов
- •1.14.3.4. Список несоответствий
- •1.14.3.5. Колонтитул
- •1.14.4. Жизненный цикл инспектируемого документа
- •1.14.5. Формальные инспекции программного кода
- •1.14.5.1.. Особенности этапа просмотра инспектируемого кода
- •1.14.5.2. Особенности этапа проведения собрания
- •1.14.5.3. Особенности этапа завершения и повторной инспекции
- •1.14.6. Формальные инспекции проектной документации
- •1.14.6.1. Особенности этапа просмотра документации
- •1.14.6.2.. Особенности этапа завершения
- •2. Сопровождение информационных систем
- •2.1. Введение
- •2.2. Организация процесса сопровождения
- •2.3. Методы сопровождения
- •2.3.1. Анализ влияния факторов
- •2.3.2. Обратное проектирование
- •2.3.3. Реинжиниринг
- •2.3.4. Рефакторинг
- •2.3.5. Унаследованные приложения
- •2.3.6. Обновление документации
- •2.4. Стандарт ieee 1219-1992
- •5. Системное тестирование
- •2.5. Управление сопровождением
- •2.6. Качество сопровождения
- •2.6.1. Метрики сопровождения
- •2.6.2. Применение метрик сопровождения
- •2.6.3. Удобство сопровождения
- •2.7. Подведение итогов
2.6.2. Применение метрик сопровождения
В этом разделе обсуждаются вопросы применения метрик для управления действиями по сопровождению. Доля комментариев в общем числе строк исходного кода позволяет предсказать масштаб трудозатрат на сопровождение (рис. 2.10). По сравнению с тремя другими модулями модуль «Запись неудачных дней» создаст больше всего трудностей при сопровождении из-за большой доли некомментированных строк и своего большого объема. Сопровождать модуль «Отчет о прибылях» будет проще всего, потому что он имеет наименьшие размеры и высокую долю комментариев. Долю комментариев можно вычислить при помощи специальной программы или путем изучения взятых наугад участков кода.
Рис. 2.10. Оценка трудозатрат на сопровождение
Для управления затратами на сопровождение полезны графики, аналогичные приведенному на рис. 2.11. В соответствии с этим графиком большое количество запросов на исправления и усовершенствования прибывает в первые два года, в результате чего на второй год эксплуатации возникает пик задержек выполнения запросов. Постепенно задолженность устраняется. Общий вид кривых на этом графике достаточно типичен, изменяется только масштаб по оси времени (годы, месяцы, недели).
Рис. 2.11. Профиль количества запросов на устранение недостатков
Ранее в этой главе мы подчеркивали разницу между исправлением недостатков и усовершенствованием приложения. Обычно руководитель отдела сопровождения старается учитывать затраты на эти два вида деятельности отдельно друг от друга, чтобы усовершенствования оплачивались заказчиком. Для достижения эффективного распределения объема работ полезны графики, подобные рис. 2.12. На графике показано среднее количество недель ожидания решения по запросу на сопровождение. Время отсчитывается с момента поступления первого отчета. Для исправлений средний срок составляет около одной недели, а для усовершенствований – около четырех недель.
Рис. 2.12. Пример профиля задержки до принятия решения о выполнении запроса.
2.6.3. Удобство сопровождения
Оман [85] выделил основные параметры исходного кода, влияющие на удобство сопровождения приложения. Проведенное им разбиение исходного кода по типам показано на рис. 2.13. Автор изменил предложенное Оманом представление, чтобы сделать рисунок доступнее. Более полный вариант той же схемы приведен на рис. 2.14.
Например, чем лучше система разбита на модули, тем проще ее сопровождать (рис. 2.14, Исходный код ► Управляющая структура ► Система). Чем лучше данные инициализируются, тем проще их сопровождать (рис. 2.14, Исходный код ► Информационная структура ► Компонент). Читатель, несомненно, обратит внимание на то, что большинство перечисленных качеств уже рассматривались в этой книге с точки зрения качества проектирования и реализации.
Вспомните, что основным мотивом использования образцов проектирования является обеспечение удобства сопровождения приложений. Например, образец проектирования State позволяет с легкостью добавлять новые состояния, не изменяя функциональность имеющихся. К сожалению, усовершенствованные методы разработки систем обычно приводят к увеличению, а не к уменьшению затрат на сопровождение [23]. Судя по всему, это связано с тем, что хорошо разработанные приложения проще изменять, поэтому мы чаще прибегаем к их адаптации к новым условиям.
Рис. 2.13. Влияние параметров исходного кода на удобство сопровождения (1).
Рис. 2.14. Влияние параметров исходного кода на удобство сопровождения (2).