Задания для самопроверки
Выполните формализацию задачи о железнодорожном переезде в каком-либо известном Вам формализме и проанализируйте полноту и непротиворечивость полученной модели.
Постройте полную формализацию простой телефонной системы с рядом дополнительных функций (переадресация, ожидание, конференц-связь и т.д.)
Проведите формализацию какой-либо заметной части исходных требований для известного Вам программного продукта в каком-либо формализме и определите, сколько при этом будет выявлено неточностей и даже ошибок в этих требованиях.
7.Некоторые общие технологические приемы
В данном разделе рассматриваются несколько известных технологических приемов, предложенных в разное время для отдельных деятельностей по разработке ПО. Как оказалось, эти приемы имеют более широкую область применения и полезны в других областях.
Инспекции по Фейгану
Инспекции – это один из действенных и экономичных способов обнаружения ошибок в документах. Для программ он существенно менее затратен, чем тестирование. Структурированный подход к инспекциям был предложен Фейганом (Michael Fagan) и с тех пор широко используется в индустриальном производстве программных продуктов. В идеале, цель инспекций по Фейгану – найти и исправить ВСЕ дефекты в продукте прежде любого тестирования и тем самым устранить из процесса разработки ВСЕ системные дефекты. В результате пользователю остается меньше невыявленных операционных дефектов, и сокращаются как время разработки, так и ее стоимость.
Процесс инспекций по Фейгану рассматривает два круга проблем в разработке ПО: проблемы зрелости процесса разработки и проблемы исполнения этого процесса.
В первом случае, как правило, причиной проблем является отсутствие определения процесса и стандартов, особенно в отношении измеряемых критериев на входе и на выходе каждого шага в процессе или, в случае наличия таких критериев, несоответствие критериев на выходе операции-поставщика критериям на входе операции-получателя. Кроме того, свой негативный вклад вносит отсутствие формального контроля за изменениями процесса и отсутствие процесса по устранению системных (systemic) дефектов.
Во втором случае проблемы чаще всего возникают из-за неполного или неправильного исполнения («срезание углов» – cutting corners), незнакомства разработчиков с самим процессом и из-за низкого или несогласованного упора на процесс и качество на всех уровнях руководства, приводящий к «срезанию углов».
Инспекции по Фейгану нацелены на устранение всех перечисленных причин дефектов. Общая структура процесса инспекций представлена на Рис. 46.
Рис. 46. Схема процесса инспекций по Фейгану
Первым шагом является запуск – надо убедиться, что материалы отвечают критериям на входе, подобрать участников и распределить их роли, спланировать следующие 4 операции и определить место проведения операций 2, 4, 5.
Обзор (представление) документа всем участникам инспекции проводит его автор с целью ознакомить участников с материалами и затем раздать их для последующей индивидуальной подготовки к инспекционному совещанию.
На этапе индивидуальной подготовки каждый участник изучает представленный материал и подготавливается к выполнению свой роли.
Центральный этап инспекции – подготовленное инспекционное совещание, задача которого – искать и находить дефекты, но без того, чтобы предлагать какие-либо решения или улучшения. Если по результатам этого совещания принимается решение о необходимости переделок в инспектированном документе, то он возвращается автору на доработку с учетом сделанных замечаний, после чего цикл повторяется.
На этапе переделки автор устраняет все дефекты и проясняет «вопросы для изучения» – т.е., замечания, которые требуют дополнительного исследования.
Если же серьезных замечаний на инспекционной сессии не прозвучало, то процесс инспекции переходит к этапу выводов, на котором в случае переделок проверяются все исправления дефектов и правильное разрешение всех вопросов для изучения, а также подводя ся итоги данной инспекции.
Последним шагом является утверждение, на котором проинспектированный документ утверждается, а также оценивается улучшение выявления дефектов через инспекции и их воздействие на постоянное улучшение процесса разработки.
Длительность одной сессии инспекционного совещания не должны превышать 2-х часов. В редких случаях может назначаться «третий час». Оптимальный темп шагов инспекции приводится в Табл. 20.
Табл. 20. Оптимальный темп инспекций
Шаг инспекции |
Код |
Текст |
Запуск |
15 мин |
30 мин |
Обзор |
500 строк кода в час |
560 строк текста в час |
Подготовка |
100 строк кода в час |
140 строк текста в час |
Инспекционное совещание |
125 строк кода в час |
140 строк текста в час |
Выводы |
30 мин |
45 мин |
Для того, чтобы документ мог быть подвергнут инспекции, он должен удовлетворять ряду критериев, которые разные для разных типов документов.
Программный код. Код компилируется чисто (без ошибок) и прошел синтаксическую проверку LINT-ом или аналогичными инструментами. В листинге все строки кода пронумерованы. Размер кода – до 250 LOC на 1 сессию инспекционного совещания. Распечатка кода, заголовок, комментарии и формат должны отвечать стандартам. Если код не является независимым, то должны быть обеспечены перекрестные ссылки. Спецификация проектирования, которую реализует данный код, должна содержать все изменения и быть своевременной. Перед этим она должна пройти инспекцию. Подготовлен материал для обзорной презентации (диаграммы и рисунки приветствуются, только словесные описания недостаточны).
Детальный проект. Спецификация проектирования удовлетворяет стандарту проектирования (содержание, формат, специфицированные интерфейсы, уровень абстракции, словарь терминов, ссылочная документация). Уровень абстракции – примерно 1 утверждение на 3-10 LOC (или иной уровень подробности, требуемый стандартом проектирования). Строки спецификации пронумерованы в распечатке. Размер – не более 250 строк псевдокода или 280 строк текста на 1 сессию инспекционного совещания. Имеется проинспектированный проект высокого уровня (или спецификация требований и интерфейсная спецификация, если его нет), который реализует данный детальный проект. Все эти спецификации должны соответствовать текущей дате. В наличии диаграммы для обзорной презентации.
Проект верхнего уровня. Спецификация проектирования удовлетворяет стандартам проектирования (содержание, формат, специфицированные интерфейсы, уровень абстракции, словарь терминов, ссылочная документация). Уровень абстракции – примерно 1 утверждение на 20-30 LOC. Строки спецификации пронумерованы в распечатке. Размер – не более 280 строк текста на сессию. В наличии проинспектированная спецификация требований, которую реализует данный проект верхнего уровня. Она должна соответствовать текущей дате. В наличии диаграммы для обзорной презентации.
Требования. Представлена самая последняя версия документа «Спецификация требований», разделенная на сегменты размером не более 280 строк текста каждый. Документ должен отвечать требованиям стандартов. Строки текста должны быть пронумерованы. В наличии контракт или иные документы, послужившие источником для данного документа. В наличии необходимые ссылочные документы (по продукту или предметной области) и стандартам (по процессу), включая стандарт на построение документа «Спецификация требований» (или иных документов) с особенным вниманием к его формату и критериям на выходе для каждого раздела. Представлена обзорная презентация, дающая область, контекст и обоснование для документа с требованиями.
Между участниками инспекции распределяются следующие роли:
Ведущий – Moderator. Ведет команду в соответствии с процессом, стимулирует синергетику работы в команде. Должен разбираться в подготовке данного типа рабочего продукта, подлежащего инспекции, быть тактичным, дипломатичным и уметь хорошо работать с другими людьми. Его обязанности на этапах инспекции:
1. ЗАПУСК: Проверить, удовлетворяет ли рабочий продукт критериям на входе, совместно с автором решить, нужно ли проводить его обзор (overview) для всех участников.
2. ОБЗОР: Назначить дату и время встречи, зарезервировать помещение; продолжительность обзора – примерно 1/5 от предполагаемой длительности всей встречи.
3. ПОДГОТОВКА: Меньше, чем у остальных участников.
4. ИНСПЕКЦИЯ: Огласить цель данной встречи-инспекции, собрать начальные метрики от всех участников, быть готовым отменить встречу, если какой-либо участник не подготовился, поддерживать нацеленность встречи-инспекции на нахождение ошибок в инспектируемом рабочем продукте, останавливая лишние обсуждения, задавать темп встрече, определить результаты инспекции.
5. ПЕРЕДЕЛКА: Получить данные по переделке от автора.
6. ВЫВОДЫ: Собрать все метрические данные по инспекции.
7. УТВЕРЖДЕНИЕ: После того, как все замечания исправлены, утвердить рабочий продукт, получить от автора финальные данные по переделке, заполнить и подписать все необходимые метрические формы и представить их в группу качества.
Автор – Author. Создатель данного рабочего продукта, подлежащего инспекции. Активный участник инспекции. Заинтересован в нахождении всех дефектов, чтобы избежать их проявления впоследствии и в силу этого не стоит в обороне.
1. ЗАПУСК: Решить, готов ли материал к инспекции, вместе с руководителем своего проекта выбрать доступного ведущего, решить, нужно ли представление материала участникам инспекции, определить минимальное потребное время для инспекционного совещания и разделить материал по секциям в соответствии с ним, выбрать чтеца, тестировщика и других участников инспекции, получить экземпляры раздаточного материала для всех участников, если нет обзора, то раздать подготовленный материал участникам.
2. ОБЗОР: Подготовить презентацию и(или) выступление, сделать обзор, ответить на вопросы, раздать подготовленный материал для изучения.
3. ПОДГОТОВКА: Пересмотреть всю сопроводительную документацию.
4. ИНСПЕКЦИЯ: Искать ошибки вместе с остальными участниками.
5. ПЕРЕДЕЛКА: Сообщить ведущему оценку времени, необходимого на переделку, а после переделки – фактически затраченное время; сообщить ведущему предполагаемую дату завершения переделок по сделанным в ходе инспекционного совещания замечаниям; исправить все замеченные отклонения (anomalies).
6. ВЫВОДЫ: Сдать (submit) рабочий продукт.
7. УТВЕРЖДЕНИЕ: Получить утверждение рабочего продукта от ведущего.
Чтец – Reader. Обычно лицо, работа которого зависит от инспектируемого рабочего продукта. Во время инспекционного совещания может перефразировать каждое утверждение своими словами, выражая его значение на уровне понимания, достаточном для выполнения следующего шага разработки или полномасштабного использования данного продукта.
2. ОБЗОР: Прийти на обзор
3. ПОДГОТОВКА: Подготовиться достигать подробное понимание материала в рекомендованном темпе. Быть готовым перефразировать каждую строку или абзац материала во время встречи-инспекции
4. ИНСПЕКЦИЯ: Зачитывать вслух и объяснять или переформулировывать каждую строку или абзац инспектируемого материала. При необходимости останавливаться для рассмотрения других материалов, таких как предшествующая документация, стандарты, руководства или интерфейсные процедуры. Следовать указаниям ведущего по поддержанию темпа, искать ошибки вместе с остальными участниками инспекции.
Тестировщик – Tester. Учитывает, как будет тестироваться данный рабочий продукт и задает вопросы, напоминающие тесты (test cases) – например, для инспекций кода: «Какие возможны пути, данные, состояния, граничные условия, исключения, коды возврата?»
2. ОБЗОР: Прийти на обзор.
3. ПОДГОТОВКА: Подготовиться к рекомендованному темпу инспекционного совещания в роли тестировщика.
4. ИНСПЕКЦИЯ: Искать ошибки, глядя на инспектируемый рабочий продукт с точки зрения тестировщика.
Остальные – Others. Коллеги автора, компетентные в данном вопросе.
2. ОБЗОР: Прийти на обзор.
3. ПОДГОТОВКА: Изучить переданные материалы и подготовиться к рекомендованному темпу инспекционного совещания.
4. ИНСПЕКЦИЯ: Искать ошибки.
Таким образом, главное отличие процесса инспекций от другого основного метода поиска ошибок – тестирования – состоит в том, что инспекции – это более практичный подход к тестированию по принципу «белого ящика», поскольку они используют человеческую интуицию для задавания вопросов, по сути своей являющихся тестовыми примерами, более глубокими, чем для тестирования на ЭВМ.
Табл. 21. Типичная структура затрат на поиск дефектов тестированием
Шаги по устранению дефекта |
Среднее время |
|
Модульное |
Системное |
|
Определение проблемы |
|
|
Местонахождение проблемы |
|
|
Заплатка (включая отладку заплатки) |
|
|
Исправление в исходном коде |
|
|
Тестирование исправления в исходном коде |
|
|
Интеграция исправления в исходном коде |
|
|
Системное тестирование исправления |
|
|
Регрессионное тестирование исправления |
|
|
Изменения в документации |
|
|
Отчет по дефекту (включая совещания) |
|
|
Всего человеко-часов: |
|
|
Хотя покрытие кода вопросами, которые задаются участниками инспекции в процессе подготовки и по ходу инспекционного совещания, по-прежнему не известно, оно значительно больше, чем любое возможное покрытие при тестировании с помощью тестов. Если в организации собираются данные по трудоемкости поиска и исправления дефектов путем тестирования (Табл. 21), то их можно сравнить с данными, получаемыми при поиске и исправлении дефектов методом инспекций, и только на основании этих данных при статистически представительной выборке и качественного исполнения процессов делать вывод об их преимуществах или недостатках.