Особенности анализа программ

Информационные технологии являются одним из основных элементов

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

Любая информационная система состоит из аппаратного и программного обеспечения (ПО). В начале развития компьютерной техники аппаратная часть была более сложной и значительно более дорогостоящей, стоимость программной части оценивалась примерно в 5% стоимости всей системы. Однако  гибкость программного обеспечения и (как оказалось впоследствии, обманчивая) простота внесения в него изменений побуждали использовать его для решения разнообразнейших задач на одном и том же или стандартизированном аппаратном обеспечении. Поэтому постепенно ПО усложнялось, приобретало  все большую ценность, и в последние десятилетия его стоимость достигает от 30% до 90% стоимости систем, в зависимости от их типа.

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

Возрастающая сложность ПО приводит к увеличению количества ошибок в нем, а одновременный рост количества и критичности  выполняемых им функций влечет рост ущерба от  этих ошибок. Оценки потерь одной экономики США от некачественного программного обеспечения дают около 60 миллиардов долларов в год. Известны также примеры серьезных ошибок в ПО, приведших к потере человеческих жизней, космических аппаратов или к масштабным нарушениям работы инфраструктурных сетей. Одна из первых хорошо описанных ошибок такого рода — ошибка в системе управления космическим аппаратом Mariner 1 , которая привела к потере этого аппарата 22 июля 1962 года. Ошибка заключалась в том, что в одном месте была пропущена операция усреднения скорости корабля по нескольким последовательно измеренным значениям. В результате колебания значения скорости, вызванные ошибками измерений, стали рассматриваться системой как реальные, и она попыталась предпринять корректирующие действия, которые привели к полной неуправляемости аппарата. Именно после этого инцидента управление военно-воздушных сил США приняло решение использовать  в процессе разработки ПО экпертизу кода  — его просмотр и анализ другими людьми, помимо  самого разработчика.

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

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

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

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

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

1.1. Верификация и валидация

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

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

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

1.2. Характеристики качества программного обеспечения

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

Наиболее широко используется определение качества ПО в виде системы атрибутов или факторов, которые могут быть оценены с помощью ряда метрик. Такой подход позволяет конструктивно оценивать качество ПО в целом, во всех необходимых аспектах. Впервые он был  сформулирован в 1977 году в работе МакКола с соавторами , затем несколько раз пересматривался в работах , и в итоге был принят в качестве стандартной модели качества ISO 9126  в 1991 году.  Ниже описана модель качества ПО,  описанная в действующей на сегодняшний день  версии этого стандарта,  принятой в 2001 году. В ходе идущей переработки этого и других связанных с оценкой качества ПO стандартов по новой схеме SQauRE серьезные изменения в модели качества не планируются.

Стандарт ISO 9126 [21-24] предлагает учитывать три разных точки зрения при

рассмотрении качества ПО: точку зрения разработчиков, которые воспринимают

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

Для двух точек зрения — внешнего качества и внутреннего качества — в рамках ISO 9126 предложена модель качества, состоящая из 6 факторов и 27 атрибутов.

Определения факторов и атрибутов качества в этой модели приведены ниже.

      Функциональность

      Способность к взаимодействию

      Функциональная пригодность

      Соответствие стандартам

      Защищенность

      Точность

      Надежность

      Зрелость

      Способность к восстановлению

      Соответствие стандартам

      Устойчивость к отказам

      Качество

      ПО Удобство использования

      Соответствие стандартам

      Удобство обучения

      Привлекательность

      Удобство работы

      Понятность

      Производительность

      Соответствие стандартам

      Временная эффективность

      Эффективность использования

      ресурсов

      Переносимость

Адаптируемость

      Удобство замены

      Способность к сосуществованию

      Соответствие стандартам

      Удобство установки

      Удобство сопровождения

            Удобство внесения изменений

          Соответствие стандартам

        Удобство проверки

         Анализируемость

      Стабильность

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

o Точность (accuracy) — способность выдавать нужные результаты.

o Способность к взаимодействию, совместимость (interoperability)  —

способность взаимодействовать с нужным набором других систем.

o Соответствие стандартам и правилам (compliance)  — соответствие ПО

имеющимся стандартам, нормативным и законодательным актам, другим

регулирующим нормам.

o Защищенность (security)  — способность предотвращать

неавторизованный и не разрешенный доступ к данным, коммуникациям и

др. элементам ПО.

 Надежность (reliability)  — способность ПО поддерживать определенную

работоспособность в заданных условиях.

o Зрелость, завершенность (maturity) — величина, обратная частоте отказов

ПО. Определяется средним временем работы без сбоев и величиной,

обратной вероятности возникновения отказа за данный период времени.

o Устойчивость к отказам (fault tolerance)  — способность поддерживать

заданный уровень работоспособности при отказах и нарушениях правил

взаимодействия с окружением.

o Способность к восстановлению (recoverability)  — способность

восстанавливать определенный уровень работоспособности и

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

o Соответствие стандартам надежности (reliability compliance).

 Удобство использования (usability) или практичность — способность ПО быть

удобным в обучении и использовании, а также привлекательным для

пользователей.

o Понятность (understandability)  — показатель, обратный к усилиям,

которые затрачиваются пользователями на восприятие основных понятий

ПО и осознание способов их использования для решения своих задач.12

o Удобство обучения (learnability)  — показатель, обратный к усилиям,

затрачиваемым пользователями на обучение работе с ПО.

o Удобство работы (operability)  — показатель, обратный трудоемкости

решения пользователями задач с помощью ПО.

o Привлекательность (attractiveness)  — способность ПО быть

привлекательным для пользователей.

o Соответствие стандартам удобства использования (usability compliance).

 Производительность (efficiency) или эффективность  — способность ПО при

заданных условиях обеспечивать необходимую работоспособность по

отношению к выделяемым для этого ресурсам.

o Временная эффективность (time behaviour)  — способность ПО решать

определенные задачи за отведенное время.

o Эффективность использования ресурсов (resource utilisation)  —

способность решать нужные задачи с использованием заданных объемов

ресурсов определенных видов. Имеются в виду такие ресурсы, как

оперативная и долговременная память, сетевые соединения, устройства

ввода и вывода, и пр.

o Соответствие стандартам производительности (efficiency compliance).

 Удобство сопровождения (maintainability)  — удобство проведения всех видов

деятельности, связанных с сопровождение программ.

o Анализируемость (analyzability) или удобство проведения анализа  —

удобство проведения анализа ошибок, дефектов и недостатков, а также

удобство анализа необходимости изменений и их возможных

последствий.

o Удобство внесения изменений (changeability)  — показатель, обратный

трудозатратам на выполнение необходимых изменений.

o Стабильность (stability)  — показатель, обратный риску возникновения

неожиданных эффектов при внесении необходимых изменений.

o Удобство проверки (testability) — показатель, обратный трудозатратам на

проведение тестирования и других видов проверки того, что внесенные

изменения привели к нужным результатам.13

o Соответствие стандартам удобства сопровождения (maintainability

compliance).

 Переносимость (portability)  — способность ПО сохранять работоспособность

при переносе из одного окружения в другое, включая организационные,

аппаратные и программные аспекты окружения.

Иногда в русскоязычной литературе эта характеристика называется

мобильностью. Однако термин «мобильность» стоит зарезервировать для

перевода «mobility»  — способности ПО и системы в целом сохранять

работоспособность при ее физическом перемещении в пространстве.

o Адаптируемость (adaptability)  — способность ПО приспосабливаться к

различным окружениям без проведения для этого действий, помимо

заранее предусмотренных.

o Удобство установки (installability)  — способность ПО быть

установленным или развернутым в определенном окружении.

o Способность к сосуществованию (coexistence)  — способность ПО

сосуществовать в общем окружении с другими программами, деля с ними

ресурсы.

o Удобство замены (replaceability) другого ПО данным  — возможность

применения данного ПО вместо других программных систем для

решения тех же задач в определенном окружении.

o Соответствие стандартам переносимости (portability compliance).

Указанные выше характеристики используются для описания качества ПО с

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

т.е. качества ПО при использовании, стандарт ISO 9126  предлагает другую систему

факторов.

 Эффективность (effectiveness)  — способность решать задачи пользователей с

необходимой точностью при использовании в заданном контексте.

 Продуктивность (productivity)  — способность предоставлять определенные

результаты в рамках ожидаемых затрат ресурсов.14

 Безопасность (safety) — способность обеспечивать необходимо низкий уровень

риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или

окружающей среде.

 Удовлетворение пользователей (satisfaction)  — способность приносить

удовлетворение пользователям при использовании в заданном контексте.

В дальнейшем мы будем использовать систему из шести факторов,

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

Хотя общую структуру жизненного цикла произвольной программной системы определить невозможно, существует несколько наиболее часто используемых способов организации различных видов деятельности в рамках жизненного цикла. Их называют моделями жизненного цикла ПО. Чаще всего работы организуются либо в соответствии с каскадной (или водопадной) моделью [26,, либо в рамках одной из многочисленных разновидностей  итеративной модель жизненного цикла, впервые описанной в 1970 году.

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

      Определение и анализ требований

      Тестирование

      Кодирование

      Проектирование

      Эксплуатация

      Определение концепции системы

      Определение и анализ требований

      Эксплуатация

      Тестирование

      Кодирование

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

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

2.1. Задачи верификации в рамках жизненного цикла ПО

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

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

 Выявление наиболее критичных  и наиболее подверженных ошибкам частей

создаваемой или сопровождаемой системы.

 Контроль и оценка качества ПО во всех его аспектах.

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

 Предоставление  руководству проекта и разработчикам  информации для планирования дальнейших работ, а также для принятия решений о продолжении

проекта, его прекращении или передаче результатов заказчику.

2.2.  Верификация и другие процессы разработки и сопровождения ПО

Процессом жизненного цикла ПО называется группа видов деятельности, выполняемых для решения определенного набора связанных задач по разработке или сопровождению ПО. На сегодняшний день  нет четко определенного  общего  списка процессов, который не вызывал бы возражений у  тех или иных исследователей и практиков. Международные стандарты ISO 12207, IEEE 1074, ISO 15288, ISO 15504 используют несколько отличающиеся системы процессов.

 По ISO 12207 к верификации имеют отношение 5 процессов: обеспечение качества (quality assurance), собственно верификация, валидация, совместные экспертизы (joint review) и аудит (audit).  Тестирование целиком отнесено к валидации.  Кроме того, выделен процесс разрешения проблем (problem resolution), для которого верификация и валидация поставляют входные данные (те самые проблемы).

 IEEE 1074 выделяет только один связанный с верификацией процесс — группу деятельностей по оценке (evaluation), которая включает  экспертизы (review), аудиты, прослеживание требований и тестирование. Еще несколько видов деятельности, которые можно отнести к верификации и валидации, разбросаны по другим процессам  — сбор и анализ метрик, анализ осуществимости, определение потребностей в улучшении ПО, валидация программы обучения.

 ISO 15288 считает отдельными процессами управление качеством, оценивание, верификацию и валидацию.

 В ISO 15504 (SPICE) в качестве процессов выделены совместные экспертизы и аудиты (один процесс), управление качеством, обеспечение качества и экспертизы (review). Тестирование считается частью других процессов  — реализации и интеграции ПО и интеграции программно-аппаратной системы в целом.

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

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