Верификация – это ответ на вопрос «Выполнено ли программное обеспечение правильно?», а валидация – «Сделано ли правильное программное обеспечение?».

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

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

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

 

Контрольные вопросы

 

1. Каково назначение этапа тестирования в жизненном цикле разработки программного продукта?

2. Что подвергается тестированию?

3. Какие существуют принципы тестирования?

4. Перечислите аксиомы тестирования.

5. Перечислите виды тестирования. Каково их назначение?

6. Какие стратегии тестирования вы знаете?

7. В чем суть метода «черного ящика»?

8. Какова цель тестирования документации?

9. Что является программной ошибкой?

10. Какие существуют категории программных ошибок?

11. Какими характеристиками должен обладать хороший тест?

12. Охарактеризуйте понятие «верификация».

13. Охарактеризуйте понятие «валидация».

 

НАДЕЖНОСТЬ ПРОГРАММНЫХ ПРОДУКТОВ

Используемые термины

 

При определении надежности ПП пользуются следующими принятыми терминами.

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

Ошибка классифицируется как проблема, обнаруженная на этапе ее зарождения.

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

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

Проблема — отклонение от заданных технических характеристик или ожидаемых результатов.

Ошибка при обработке — вывод некорректных результатов при выполнении процесса обработки.

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

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

Сбой при выполнении процесса — сбой, имеющий отношение к используемым в процессе некорректным входным данным и вызывающий неправильное состояние процессе или системы, к которой относится процесс.

Устойчивость — это свойство объекта существовать во времени (независимо от процесса, породившего данный объект) и (или) в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

 

Основные источники ошибок

 

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

При определении требований пользователь может неадекватно выразить свои требования, они могут быть неверно поняты или реализованы не в полном объеме. Ошибки этого этапа – наиболее дорогостоящие.

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

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

При проектировании модели представления осуществляется несколько процессов перевода ¾ от внешнего описания готового продукта до получения детального проекта, описывающего множество составляющих программу предложений, выполнение которых должно обеспечить поведение системы, соответствующее внешним спецификациям. Этот шаг включает такие процессы, как создание модели представления данных и перевод внешнего описания в структуру компонент программы (модель управления данными). Здесь могут быть допущены ошибки, связанные во - первых, с неточным или неполным отображением данных, во-вторых, с неприемлемым или неудобным для пользователя интерфейсом, в-третьих, неправильно спроектированной архитектурой комплекса.   

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

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

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

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

Непонимание синтаксиса и семантики языка программирования также является причиной ошибок.

Если пользовательский интерфейс разработан без учета психологии пользователя, то увеличивается вероятность ошибок пользователя, которые ставят систему в непредвиденные обстоятельства, тем самым, повышая шансы проявления оставшихся в программном обеспечении ошибок.

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

 

Психологические факторы

 

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

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

2) Содержание сообщений. Пользовательский интерфейс должен содержать подсказки на экране, поясняющие смысл элементов управления; сообщения, которые объясняют пользователю его ошибки; аварийные сообщения при сбоях программного или аппаратного обеспечения. Текст этих сообщений должен быть кратким, но максимально содержательным. Желательно также организовать работу справки (в т. ч. контекстной), которая описывает возможности системы и способы их реализации.

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

 

Сложность

 

Сложность является одной из главных причин ненадежности программного обеспечения. В общем случае сложность объекта является функцией взаимодействия между его компонентами. Например, сложность проекта программной системы в некоторой степени определяется связями между командами пользователя и соотношениями между входной и выходной информацией системы. Сложность архитектуры системы определяется связями между подсистемами, сложность подсистемы ¾ функция связей между модулями, сложность модуля ¾ функция связи между его командами.

Существует три основных принципа, позволяющих минимизировать сложность системы:

1) Максимальная независимость компонент системы. Наиболее полно эта концепция реализована в объектно-ориентированных языках. Определение объекта как экземпляра класса позволяет рассматривать его как замкнутый объект, обладающий заданными свойствами и позволяющий применять определенные методы. Тем самым система рассматривается как набор компонент, доступ к внутренней структуре которых невозможен.

2) Иерархическая структура. Иерархия позволяет распределить систему по уровням понимания. Каждый уровень представляет собой совокупность структурных отношений между элементами нижних уровней. Концепция уровня позволяет понять систему, скрывая несущественные уровни детализации. В частности, определение класса позволяет работать с его экземплярами, не уточняя их внутренней структуры.

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

 

Защитное программирование

 

К защитному программированию относятся функции программного обеспечения, которые предназначены для выявления и исправления ошибок или их последствий. Устойчивость к ошибкам ¾ это мера способности системы продолжать функционировать при наличии ошибок. Устойчивость к ошибкам является одним из основных факторов, обеспечивающих надежность системы. Методы защитного программирования предназначены для того, чтобы выявить ошибки пользователя, аппаратные и программные сбои и обеспечить адекватную реакцию программы. Основными принципами поиска ошибок являются:

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

2) Немедленное обнаружение. Ошибки необходимо обнаруживать как можно раньше.

3) Избыточность. Все средства обнаружения ошибок основаны на некоторой форме избыточности, явной или неявной.

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

Защитное программирование основано на предпосылке: худшее, что может сделать модуль ¾ это принять неправильные входные данные и затем вернуть неверный, но правдоподобный результат. Чтобы избежать этого, в начале каждого модуля следует помещать проверки входных данных на соответствие их свойств атрибутам и диапазонам измерения, на полноту и осмысленность. При выборе надлежащих проверок важно по тексту программы модуля выявить все предположения, которые в нем сделаны относительно входных данных, а затем рассмотреть возможность проверки входных данных на соответствие этим предположениям при каждом вызове модуля.

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

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

 

Планирование изменений

 

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

1) в течение всего цикла работы над проектом поддерживать документацию на уровне последних решений.

2) в определенный момент результаты каждого этапа «замораживаются», т. е. любые изменения должны проходить формальную процедуру утверждения, поскольку на принятом ранее решении основаны и другие решения. Таким образом, процедура внесения изменений принимает каскадный характер.

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

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

 

 

Контрольные вопросы

 

1. Дайте определение понятия «надежность программного продукта».

2. Перечислите основные источники ошибок.

3. Какие психологические факторы влияют на надежность?

4. В чем суть защитного программирования?

5. Почему сложность программного продукта влияет на его надежность?

6. Почему необходимо заранее планировать возможность изменения программного продукта?