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

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

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

Любая информационная система состоит из аппаратного и программного обеспечения (ПО). В начале развития компьютерной техники аппаратная часть была более сложной и значительно более дорогостоящей, стоимость программной части оценивалась примерно в 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)  — способность

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