6. Как правило, автор в состоянии исправить все дефекты. Это называется фазой доработки. Если инспекционное собрание решает, что дефекты настолько серьезны, что требуется повторное инспектирование данного объекта, то объект еще раз запускается в процесс.

7. Если дефекты появляются из-за недопонимания или просто плохого представления, то, возможно, необходимо организовать встречу по анализу причин появления дефектов. Опять же в силу дороговизны такие встречи должны проводиться только в исключительных случаях.

8. Окончательное собрание по завершению работы должно быть коротким. На нем корректор и автор убеждаются в том, что все дефекты исправлены. Однако это не предполагает детальной ревизии всей работы корректором. Все исправления остаются на совести автора, ответственного за свою работу.

9. Как и после других процессов, группа встречается для обсуждения самого процесса инспектирования и решает, как он может быть улучшен. Сюда же входит и улучшение инспекционных списков контрольных вопросов.

16. Понятия отладки и тестирования. Стратегия проектирования тестов. Комплексное тестирование.

Тестирование программы  является одной из составных частей более общего понятия - «отладка программы». Отладка - процесс, позволяющий получить программу, функционирующую с требуемыми характеристиками в заданной области изменения входных данных.

Процесс отладки включает:

• действия, направленные на выявление ошибок (тестирование);
• диагностику и локализацию ошибок (определение характера и местоположения ошибок);
• внесения исправлений в программу с целью устранения ошибок.

Тестирование - это процесс многократного выполнения программы с целью обнаружения ошибок. Цель тестирования - выявить как можно большее число ошибок.

Тестирование программного обеспечения охватывает целый ряд видов деятельности, аналогичных последовательности процессов разработки программного обеспечения. В него входят:

 а) постановка задачи  для теста,

 б) проектирование теста,

 в) написание тестов,

 г) тестирование тестов,

 д) выполнение тестов,

 е) изучение результатов  тестирования.

 Решающую роль играет  проектирование тестов. Возможен  целый ряд подходов к стратегии  проектирования тестов. Чтобы ориентироваться  в них, рассмотрим два крайних  подхода. Первый состоит в том,  что тесты проектируются на  основе внешних спецификаций  программ и модулей либо спецификаций  сопряжения программы или модуля. Программа при этом рассматривается  как черный ящик (стратегия “черного ящика”). Существо такого подхода - проверить, соответствует ли программа внешним спецификациям. При этом логика модуля совершенно не принимается во внимание.

Второй подход основан  на анализе логики программы (стратегия “белого ящика”). Существо подхода - в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается.

 

Ни один из этих подходов не является оптимальным. Из анализа существа первого подхода ясно, что его реализация сводится к проверке всех возможных комбинаций значений на входе программы. Рассмотрим в качестве примера задачу тестирования тривиальной программы, получающей на входе три числа и вычисляющей их среднее арифметическое. Тестирование этой программы для всех значений входных данных невозможно, так как их бесконечное множество. Как правило, исчерпывающее тестирование для всех входных данных программы неосуществимо, поэтому ограничиваются меньшим объемом тестирования. При этом исходят из максимальной отдачи теста по сравнению с затратами на его создание. Она измеряется вероятностью того, что тест выявит ошибки, если они имеются в программе. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста.

Комплексное тестирование показывает, что основные подсистемы, из которых состоит проект, работают и нормально взаимодействуют друг с другом. При наличии удачных и хорошо проверенных контрактов обнаружить любые проблемы интеграции не составляет особого труда. В противном случае интеграция становится благодатной почвой для размножения дефектов. Фактически в многих случаях она является единственным и самым крупным источником дефектов в системе. В реальности комплексное тестирование является продолжением модульного тестирования, описанного выше, с той лишь разницей, что теперь вы проверяете, как целые подсистемы соблюдают свои контракты.

17. Критерии качества ПО. План контроля качества. Верификация и валидация.

Качество определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.

Основными критериями качества ПО являются:

1. · функциональность – способность ПО выполнять набор функций (действий), удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПО;
2. · надежность – это его способность с достаточно большой вероятностью безотказно выполнять определенные функции при заданных условиях и в течение заданного периода времени;
3. · эффективность – соотношение уровня услуг, предоставляемых ПО пользователю при заданных условиях, и объема используемых для этого ресурсов. К числу таких ресурсов могут относиться требуемые аппаратные средства, время выполнения программ, затраты на подготовку данных и интерпретацию результатов;
4. · эргономичность – характеристики ПО, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПО и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя;
5. · модифицируемость – характеристики ПО, которые позволяют минимизировать усилия по внесению изменений для устранения ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей. Модифицируемость ПО существенно зависит от степени и качества его документированности;
6. · мобильность – способность ПО быть перенесенным из одной среды (окружения) в другую, в частности, с одной аппаратной платформы на другую.

План контроля качества (SQAP): стандарт IEEE

Данный  документ определяет:

• кто будет нести ответственность за качество — физическое лицо, менеджер, группа, организация и т. п;
• какая документация требуется;
• какие методы будут использоваться для гарантии качества — инспектирование, доказательство корректности, тестирование и т. д;
• какие мероприятия должны быть проведены в ходе управления процессом — собрания, аудиты, обзоры и т. п.

 

Верификация и валидация (V&V — Verification and Validation) являются составной частью плана контроля качества. Верификация отвечает на вопрос «Правильно ли построен наш объект?». Или более детально: «Делаем ли мы на данной фазе в точности то, что было запланировано в предыдущей фазе?». Валидация же отвечает на вопрос: «Делаем ли мы то, что нужно?». Или другими словами: «Отвечает ли построенный объект пожеланиям и нуждам заказчика?». Разницу между этими понятиями иллюстрирует рис. 1.18. К сожалению, в литературе термины верификация и валидация часто путаются. Мы же далее будем использовать эти термины именно в соответствии с данным определением.

Чтобы закрепить  наше понимание различия между верификацией и валидацией, приведем простой пример. Заказчик хочет, чтобы мы разработали приложение, которое «решает линейные уравнения вида ах + b = с». Мы формулируем это пожелание в виде следующих детальных требований.

1. Пользователь вводит числа я, b и с, состоящие не более чем из десяти цифр, включая максимум четыре цифры после запятой.

2. Приложение отыскивает решение уравнения ах + b = с с точностью до 1/1000.

Затем мы пишем  программу, реализующую эти требования.

Валидация нашей программы состоит в прогоне набора тестов. Например, мы 
вводим а = 1, b = 1, с = 1 и проверяем, что программа выдает x = 0. Тестирование выявляет наличие каких-либо дефектов в программе, но не позволяет убедиться, что дефекты в программе отсутствуют. Иными словами, на основе валидации мы не можем гарантировать, что наша программа не содержит дефектов.

Верификация состоит в том, что мы анализируем процесс построения программы и убеждаемся, что в этом процессе все сделано правильно. Процесс разработки нашей программы включает в себя следующие шаги.

1. Получение требований заказчика.

2. Подготовка детальных требований.

3. Подготовка кода программы.

4. Тестирование программы.

Верификация будет заключаться  в следующих проверках.

♦ 1 → 2. Соответствуют ли детальные требования тому, что заказчик действительно хочет? Здесь верификация может включать в себя следующие пункты: может ли быть а = 0? Если да, то что в этом случае должна делать программа? Если нет, то возможно, заказчику требуется решать уравнения вида: x + b = с; вообще, возможно, что заказчику естественнее задавать линейное уравнение в каком-либо другом виде; обсуждение с заказчиком вопроса точности задания входных данных и получаемого решения и т. д. 
Инспектирование требований также относится к процессу верификации.

♦ 2 → 3. Реализует ли код программы сформулированные требования? Это подразумевает инспектирование кода, в процессе которого код анализируется с точки зрения соответствия каждому отдельному требованию. Анализ может включать в себя математические доказательства или основываться на них.

♦ 3 → 4. Достаточно ли выполненный (или подготовленный) набор тестов охватывает область применимости программы? Инспектирование тестов.

 

18. Документация, создаваемая и используемая  в процессе разработки программных  средств.

Разработка программного обеспечения живет документацией. Документация может быть отделена от программного кода, а может быть тесно с ним связана. Для того чтобы понять важность исчерпывающей документации, представьте, что вам предложили участие в уже полным ходом идущем программном проекте. По уровню сложности это примерно соответствовало бы тому, как если бы вас заставили изучить, например, некоторые аспекты патологии крови. Чтобы сделать это, вам, скорее всего, захотелось бы получить общее представление о предмете, узнать причины необходимости его изучения, затем от обзора постепенно перейти к изучению деталей, диаграмм, демонстрирующих внутренние связи, описаниям частных случаев и т. д. Упущения или противоречия могут привести к частичному, а возможно, и полному непониманию изучаемого материала.

Чтобы проиллюстрировать  важность документирования программного обеспечения на различных уровнях, обратимся к фрагменту программного кода (листинг 1.1). Без полной документации этот код невозможно интерпретировать, поэтому его ценность невелика, если он вообще хоть чего-то стоит. Если мы добавим комментарии и сделаем имена функций более информативными (листинг 1.2), то получим несколько лучший результат. Этот результат даже может ввести нас в заблуждение, заставив поверить, что мы знаем значение и контекст кода; при этом последствия могут оказаться более катастрофичными, чем в том случае, если бы мы признали непонимание значения текста программы.

Листинг 1.1. Недокументированный код int a(int i, char c) {

if(c== "m")

if(i< 1000)

return 0;

else

if(i< 10000)

return 500;

else

return 1200;

else

return 1300; }

Листинг 1.2. Частично документированный код int tax(int anEarning, char aStatus) {

if(aStatus == "m")

if(anEarning < 1000)

return 0; // Женатые не облагаются налогом, <$1000

else

if(anEarning < 10000)

return 500; // Женат, $1000–$10000

else

return 1200; // Женат, >=$10000

// Если не женат, то использовать ставку налога в размере $1300

else

return 1300; }

 

Когда мы смотрим на тщательно  документированный программный  код (листинг 1.3), его значение становится намного понятнее. Благодаря документированию мы узнаем очень важный новый факт, заключающийся в том, что приведенные ставки заработной платы действительны только для ограниченного отрезка времени.

Листинг 1.3. Документированный код /** 
* Этот метод реализует требование 4.3: 
* "Установить действие налога с 01.09.98 по 31.12.99". 
* @ author Э. Брауде 
* @ version 2.3.4 (08.06.98) 
* @ param anEarning: зарплата 
* @ param aStatus: 'm' означает "женат", иное означает "не женат" 
*/ 
int tax(int anEarning, char aStatus) 
{ . . .

Благодаря управлению конфигурациями из документа План управления конфигурациями ПО мы узнаем, что текущей версией tax() является 2.7.3, а используется версия 2.3.4. 
Другими словами, фрагмент кода, рассмотренный нами, во многом уже не относится к делу, так как текущая версия 2.7.3 может выглядеть совсем по-другому.

До сих пор у нас  еще не сложилось представление  об общем положении вещей. Например, мы не знаем, работает ли версия 2.3.4 функции  tax() как требуется? Какому классу принадлежит эта функция? Какому пакету? Даже если мы знаем имя пакета, то каково его предназначение? Как он соотносится с другими пакетами? То есть, документация обретает смысл не только из текста своего содержания, но еще и из контекста. «Лакмусовой бумажкой» для определения хорошего ведения документации является готовность нового инженера включиться в проект за разумное время. Подводя итоги, отметим, что проект — это полное множество согласованных, хорошо разработанных артефактов, включающее набор документов, результаты тестов и программный код.