Реферат причины и свойства дефектов ошибок и модификаций в сложных информационных системах
Обновлено: 05.07.2024
ИТ-индустрия – самая быстро развивающаяся отрасль в истории человечества, опережающая радио, телевидение и телефонию. Динамичность изменений приводит к тому, что современная система образования просто не успевает готовить квалифицированные ИТ-кадры – программистов, архитекторов, аналитиков. Требования к компетенциям таких специалистов растут быстрее, нежели они успевают обучаться. Отсюда – постоянный кадровый голод на этом рынке, как следствие, нередко результаты работы ИТ-команд имеют дефекты. Сегодня уже никого не удивляет, что программные продукты даже самых известных производителей часто бывают несовершенны. Мы принимаем это как данность и работаем с тем ПО, которое нам выдают разработчики. В свою очередь они, как и другие ИТ-специалисты, прилагают все усилия, чтобы недостатков становилось меньше.
Задача высококлассного менеджера состоит в умении не только подбирать команду, но и укладываться в бюджеты. Зачастую они не позволяют нанимать специалистов с безупречной квалификацией. В этой ситуации необходимо создавать такие условия работы и процессы ее выполнения, которые даже при среднем уровне компетенций исполнителей позволяли бы получать результаты, превышающие аналогичные показатели по рынку. Тем самым достигаются конкурентные преимущества.
Какие дефекты присутствуют в ПО и все ли они одинаковы? На этот вопрос можно отвечать по-разному, строя различные теории их классификации. Здесь мы приведем разделение дефектов программного обеспечения на классы с точки зрения различий в управлении ими в процессе повышения качества ПО в соответствии с требованиями информационной безопасности.
Самый распространенный дефект – это ошибки программистов при разработке кода. Зачастую причиной их появления является дефицит времени или потеря внимания во время работы. Например, программист разрабатывает код, который в определенных условиях должен выполнять одни действия, а во всех остальных случаях – другие. Программист уделяет большое внимание разработке кода, который будет выполняться в 90% случаях исполнения ПО. Когда же дело доходит до обработки альтернативы, он устает, его внимание рассеивается, и какие-то важные аспекты, такие как оператор, определяющий выполнение данного фрагмента кода, только если условие выполнения основного фрагмента не выполнилось, теряются.
Другая характерная причина появления ошибок в программном коде – внесение в него изменений. Разработчик меняет один кусок кода, который может влиять на функциональность другого фрагмента программы. Тогда та функциональность, трансформация которой не предполагалась, становится измененной.
Обычно такие ошибки обнаруживаются на этапе тестирования либо самими разработчиками, либо специальной группой тестировщиков. Для обнаружения таких ошибок существуют различные теории и успешные практики разработки наборов тестов по техническому заданию, регрессионные тесты и другие методы, позволяющие написать качественный набор исходных данных, чтобы проверить больший процент возможных сценариев выполнения программы.
Другие дефекты, которые в большей степени интересуют специалистов по информационной безопасности, нежели разработчиков, – это уязвимости. Уязвимость – ошибка разработчика, которая потенциально может эксплуатироваться злоумышленниками с целью получения несанкционированного доступа к управлению программным приложением. Уязвимость – это код, который выполняет правильные действия с точки зрения требуемого функционала, но его исполнение имеет побочный эффект, о наличии которого программист зачастую может не знать. Наличие таких фрагментов кода не является следствием усталости, невнимательности или отсутствия достаточного времени на тестирование у разработчика, как в случае ошибки. Нередко причиной появления уязвимостей является незнание программистов о наличии побочных возможностей тех языковых конструкций, которые они используют для реализации задуманного функционала.
Уязвимости выявляют эксперты в области анализа кода, знающие о наличии побочных эффектов у тех или иных языковых конструкций. Также многие уязвимости можно обнаруживать в результате тестирования ПО по требованиям информационной безопасности специальными тестами на проникновение. Однако более эффективный метод их обнаружения – это полуавтоматический статический анализ кода, который выполняется экспертами с применением специальных инструментальных средств.
Самые неприятные с точки зрения возможности обнаружения дефекты – недекларированные возможности ПО (НДВ). Недекларированные возможности – это правильный код с точки зрения и функциональности, и информационной безопасности, поэтому его трудно обнаружить автоматическими методами. Однако этот код реализует функциональность, которая не была задумана заказчиком – ее для своих целей привнес разработчик. Обычно НДВ разделяют на закладки и секретный вход (back door).
Закладка – это функциональность, которая выполняется при наступлении определенных условий и выполняет действия, задуманные разработчиком. Часто закладки используются для того чтобы неявно манипулировать программным обеспечением. Один из наиболее известных случаев наличия закладки – история разработчика City Bank. Программист не знал, что делать с разницей, возникающей при округлении результатов арифметических операций при начислении процентов на вклады клиентов, и не придумал ничего лучше, чем накапливать ее на своем персональном счете.
Секретный вход – это код, позволяющий программисту получать контроль над ПО в обход правил, указанных в техническом задании. Наиболее часто секретными входами наполняют программное обеспечение, которое разрабатывается на заказ, для того, чтобы можно было выполнять удаленную диагностику ошибок при эксплуатации программного приложения заказчиком.
Обнаружить недекларированные возможности полностью в автоматическом режиме нельзя, так как такой код является правильным. Подобные дефекты эксперты в области информационной безопасности находят посредством ручного анализа кода или с помощью программных инструментов, позволяющих обнаруживать в исходном коде шаблоны языковых конструкций, характерных для построения НДВ.
Откуда берутся дефекты в программном коде?
Ошибки и уязвимости в программном коде обычно появляются не только вследствие того, что технологии меняются, а разработчики не успевают к ним адаптироваться, но также по причине неправильного построения процесса разработки ПО.
Зачастую требования к программному обеспечению меняются быстрее, чем ИТ-команда успевает их реализовывать. Дается одно техническое задание, оно прорабатывается архитектором, конструкторами и передается в работу. Но в процессе заказчик разработки понимает: новые условия рынка требуют, чтобы разрабатываемое ПО выполняло другой функционал. Несмотря на возражения ИТ-команды, вносятся изменения в проектную документацию, а зачастую и непосредственно в код, ломая при этом проработанную архитектуру.
Другой причиной появления ошибок и уязвимостей является сложность технологий, использующихся в современной ИТ-индустрии.
Разработчики вынуждены использовать технологии, которые сами по себе могут содержать ошибки и уязвимости, а также способствовать появлению новых в результате их неправильного внедрения в разрабатываемое ПО. Современные программные продукты многоязычные, кроссплатформенные, связи между компонентами, из которых они состоят, настолько обширны, что программист просто не в состоянии удерживать все особенности в поле своего внимания. Помимо этого, поскольку программные системы разрабатываются командой специалистов, ошибки и уязвимости часто прячутся на стыке компонент, за которые отвечают разные люди.
Появление в коде недекларированных возможностей носит исключительно личностный характер и с трудом контролируется посредством внедрения современных технологий разработки ПО. Хотя практика перекрестного контроля разработки (прежде чем код попадает в основную ветку разработки, его обязательно проверяет другой программист) и другие организационные меры имеют определенный успех. Обнаружить недекларированные возможности в коде, который разрабатывался на заказ и куда НДВ были внедрены специально, можно только посредством его анализа.
Можно ли контролировать наличие дефектов в программном коде?
- Самостоятельная разработка – это ПО, которое разрабатывается либо силами своей ИТ-команды, либо сторонним разработчиком по выданному заказчиком техническому заданию.
- Стандартное ПО, разработанное российским производителем, возможно, настроенное и адаптированное под бизнес.
- ПО, разработанное небольшим иностранным производителем.
- ПО, разработанное мировым ИТ-гигантом и поставляемое в виде набора готовых модулей.
Если программное обеспечение разрабатывается на заказ, то при приемке оно обязательно должно подвергаться проверке на наличие дефектов. Это может сделать внутренняя команда по контролю качества программных продуктов в части функциональности и требований информационной безопасности. Проверка также может быть сторонней, что подразумевает привлечение независимых экспертов.
Сопровождение комплекса программных продуктов, функционирующих на отдельно взятом предприятии и составляющих его корпоративную информационную систему (КИС), — один из важнейших процессов управления его инфраструктурой. Неотъемлемой частью процесса сопровождения программного обеспечения (ПО) является сбор и консолидация данных об ошибках, возникающих в процессе его работы.
Источниками данных об ошибках могут быть как пользователи ПО, так и средства мониторинга вычислительных систем. В работе [1] для сопровождения ПО (в том числе для проведения мониторинга и организации обратной связи) был предложен подход на основе программных агентов. В работе [2] указанный подход был применён авторами при создании системы сбора и анализа протоколов, генерируемых ПО.
Целью настоящей работы является разработка концепции и структуры централизованной системы сбора и консолидации данных об ошибках в работе КИС.
Система анализа протоколов
Разработанный макет системы анализа протоколов [2] включает программный агент, систему управления бизнес-правилами и базу прецедентов ошибок (рис. 1). В его функции входит:
сбор программных протоколов;
идентификация ошибок на основе последовательностей записей протокола;
поиск аналогов ошибок в базе прецедентов;
управление обратной связью с пользователем.
Вместе с тем для создания полноценной системы сбора и анализа ошибок как части комплекса сопровождения программного обеспечения необходимо расширить функционал системы за счёт:
расширения средств сбора сведений об ошибках;
расширения адаптационных возможностей системы;
включения функций обеспечения безопасности передаваемых данных;
интеграции с корпоративной базой знаний.
Расширение средств сбора данных об ошибках
Сбор протоколов (англ. logcollection) представляет собой процесс исследования накопления и записей, сформированных программным продуктом, с цельюих последующего анализа и может быть двух видов:
активный: средства сбора интегрированы с подсистемой протоколирования и, как следствие, могут работать в режиме реального времени;
пассивный: средства сбора производят сканирование уже записанных протоколов через определённые интервалы времени.
Несмотря на эффективность активных средств анализа, их применение на практике затруднено из-за различий в языках программирования, использованных для разработки ПО. Для решения этой проблемы можно использовать специализированные средства сбора протоколов, такие как Apache Flume, Lilith, log.io или Log Expert.
Зачастую анализ протоколов не может выявить всех проблем в работе ПО. В этом случае можно воспользоваться средствами мониторинга процесса выполнения приложений.
Рис. 1. Структура системы анализа протоколов
Предметная область, занимающаяся исследованием возможностей и средств наблюдения за выполнением приложений, называется управлением производительностью приложений (англ. Application performance management) [3]. Для сбора дополнительных данных о производительности программ в программной инженерии разработаны следующие методы:
Профилирование (англ. profiling). Это процесс сбора низкоуровневых характеристик выполняемой программы. Обычно применяется на стадии разработки ПО для выявления проблем в производительности. Существует два основных вида профилирования: (а) событийное — основанное на механизмах перехвата событий, встроенных в язык программирования; (б) статистическое — основанное на сканировании контекста выполнения программы через определённые интервалы времени.
Инструментирование (англ. instrumentation). Это процесс анализа производительности программы, происходящий благодаря внедрению в программный код специальных блоков, собирающих данные о процессе её выполнения.
Анализ процесса выполнения (англ. runtime intelligence). Это комплексный процесс исследования статистики использования пользователями одного или нескольких программных продуктов. Связан с областью бизнес-аналитики и, как правило, применяется в корпоративных системах.
Не все перечисленные методы могут быть применены при разработке агента системы сопровождения. При выборе подходящих средств должны быть выполнены следующие условия:
оригинальный программный продукт не должен быть изменён указанными средствами ни на этапе разработки, ни на этапе выполнения;
применение указанных средств не должно приводить к нестабильной работе продукта.
Применение указанных средств не должно приводить к существенному падению производительности рабочей станции.
Полезную информацию о причинах возникшей ошибки может дать также наблюдение за окружением нестабильно работающей программы, например, аппаратными ресурсами, сервисами операционной системы, загрузкой сети. Подобная информация может быть получена при использовании средств мониторинга сетевыхресур- сов (англ. network monitorin gsystems).
Данный класс систем предназначен, в первую очередь, для отслеживания статуса серверов и сетевого оборудования. Большинство систем данного класса поддерживают также мониторинг рабочих станций, включая наблюдение за использованием жёсткого диска, памяти, процессорного времени и т. д. Примерами подобным систем являются Cacti, Nagios, Pandora FMS, Zabbix, Zenoss.
Традиционными средствами сбора описаний ошибок и заявок на модификацию ПО от пользователей являются системы отслеживания ошибок (англ. Bug tracking systems) [4]. Большинство подобных системы не выполняют каких-либо сложных бизнес-процессов, требующих высокой производительности и надёжности, а являются, фактически расширенными веб-интерфейсами к базам данных, хранящим информацию о запросах.
Как следствие, их функциональность практически одинакова; различия могут наблюдаться в следующем:
удобство пользовательского интерфейса;
перечень состояний (этапов обработки) запросов на модификацию;
перечень полей, описывающих запрос на модификацию;
перечень способов добавления запросов на модификацию.
Примерами подобных систем являются Bugzilla, Fossil, Mantis, Redmine, Trac.
Повышение адаптационной способности системы
На эффективность системы анализа ошибок, выражающуюся в сокращении трудозатрат её пользователей и снижении потребляемых аппаратных ресурсов (в первую очередь — пропускной способности сети передачи данных), влияет также возможность системы к адаптации под изменяющиеся условия рабочей среды.
Последовательности событий, приводящие к ошибкам, могут автоматически выявляться на основе методов ассоциации, широко применяющихся в настоящее время для анализа рыночной корзины (англ. market basket analysis) [5, с. 281]. Автоматически созданные таким образом правила далее могут предоставляться пользователю для утверждения.
Полнота и детализированность данных, принимаемых системой анализа ошибок, сильно влияет на качество принимаемых ей решений. Очевидно, отслеживание записей только наивысшего уровня критичности (“ERROR”) не позволит в полной мере применить методы анализа цепочек событий. Включение наблюдения за наименее критичными записями (“TRACE”) сильно увеличит нагрузку на сеть. Решение этой проблемы заключается в создании “толстого клиента”, когда программным агентом будет осуществляться предварительная фильтрация явно бесполезных записей протоколов.
Очевидно также, что это потребует внедрения средств сетевой синхронизации для поддержании в актуальном состоянии локальных баз знаний агентов. В качестве таких средств могут выступить системы управления конфигурацией (англ. configuration management software). Данный класс систем предназначен для автоматизированного управления настройками рабочих станций, серверов и прочих узлов локальной (как правило, корпоративной) сети. Подобные системы могут быть выполнены в 2-х вариантах:
клиент-серверном, где клиентская часть представляет собой агента, периодически обращающегося к серверу за информацией об обновлениях конфигурации;
децентрализованном, где каждый узел может выступать в виде источника конфигурации.
Большинство популярных систем управления конфигурацией являются кроссплатформен- ными. Примерами систем управления конфигурацией являются Chef, Opsi, Puppet, Smart Frog, Spacewalk.
пользователь может дать неправильное или неполное описание ошибки;
отчёты об ошибках, выраженные в текстовом виде, сложно классифицировать.
Первая проблема может частично решаться путём фиксации набора полей, которые должен заполнить пользователь, после чего проверять данные на достаточность и корректность.
Для решения второй проблемы могут применяться различные методы интеллектуального анализа текстов (англ. Text mining)[6], в частности, алгоритмы извлечения информации (англ. Information extraction). Применение подобных технологий, однако, требует проведения специальных исследований по предметной области. В то же время для анализа текстовых пояснений к событиям, автоматически сгенерированных программой-источником ошибки, можно использовать более простые подходы, например, извлечение фрагментов с помощью регулярных выражений.
Распределённый характер информационной системы предъявляет усиленные требования к обеспечению безопасности как системы в целом, так и отдельных её компонентов.
Не менее важной задачей следует считать повышение стабильности работы программного агента и его взаимодействия с пользователем. Испытания макета показали, что неполнота описания предметной области приводит повышенной “чувствительностью” к новым ошибкам. Неосторожное создание пользовательских правил может существенно повредить эргономичности системы. Поэтому при создании действующего комплекса необходимо обеспечить предотвращение неадекватной реакции агента из-за неправильной или неполной конфигурации базы знаний путём разработки набора ограничений для создания пользовательских правил, а также предусмотреть возможности работы агента в автономном режиме, не требующим ответа пользователя.
Разработка корпоративном базы знаний
Часто ошибка в программном обеспечении связана с некоторыми особенностями предметной области или специфичностью взаимодействия участников процесса сопровождения. Разработка онтологии предметной области [7], создание централизованной корпоративной базы знаний и интеграция её, в частности, с системой анализа ошибок позволит повысить качество сопровождения ПО [8]. Общий интерфейс для базы знаний может быть реализован на базе Drools Guvnor или аналогичной системы.
Создание комплексной системы сопровождения (особенно основанной на знаниях) потребует проектирования эффективной системы пользовательского интерфейса и визуализации данных, что является одним из критериев качества современных систем бизнес-аналитики [5, с. 173].
Пользовательский интерфейс может также предоставлять инструменты для поддержки процесса поиска первичных ошибок (анализа первопричин — англ. root cause analysis), в том отображать результаты в виде специализированных диаграмм, таких как деревья ошибок (англ. faulttrees) и др.[9].
Рис. 2. Структурная схема комплекса анализа ошибок на предприятии
Общая схема комплекса
Перечисленные выше средства можно представить в виде комплекса (рис. 2).
Ключевым компонентом системы является программный агент, устанавливаемый на каждой рабочей станции и взаимодействующий с пользователем. В его функции входят:
обеспечение обратной связи пользователя с администратором (получение отчётов);
выдача уведомлений об возникших ошибках и методах их устранения;
мониторинг ПО (сбора протоколов, отслеживание процесса выполнения);
мониторинг операционной системы и ресурсов рабочей станции;
первичный (локальный) анализ ошибок.
Консолидация поступающих от программных агентов данных выполняется централизованной системой анализа ошибок, управляемой администратором. Помимо сбора и анализа данных о выполнении ПО и текстовых отчётов пользователей, в её функции входит удалённое управление программными агентами.
Важным компонентом комплекса является подсистема интеграции с корпоративной базой знаний, которая позволяет накапливать информацию об ошибках и производить более тщательный их анализ и поиск первопричин. Накопленная информация может также передаваться разработчику ПО для устранения ошибок.
Обобщённый алгоритм анализа ошибки с помощью данного комплекса выглядит следующим образом:
Программный агент собирает данные о работе ПО, состоянии операционной системы и потреблении аппаратных ресурсов.
Через определённые промежутки времени собранные данные передаются подсистеме локального анализа ошибок. Результатом анализа является заключение о том, соответствуют ли данные потенциальной ошибке.
При положительном решении программный агент формирует заявку на обслуживание, в которую включает информацию о рабочей станции, вызвавшем ошибку ПО и перечень программных протоколов, соответствующих ошибке.
Центральная подсистема анализа ошибок производит поиск аналогов ошибки в базе прецедентов. При обнаружении прецедента агенту передаётся указание на выполнение действия, ассоциированного с прецедентом. Если прецедент не был найден, агенту передаётся указание на запрос от пользователя дополнительной информации.
Дополнительная информация от пользователя собирается программным агентом и передаётся подсистеме анализа текстов отчётов.
Консолидированная информация, полученная в результате анализа данных о рабочей станции, ПО, ошибке и отчёте пользователя, передаётся на рассмотрение администратора.
Администратор либо утверждает, либо отклоняет полученную информацию. В первом случае администратор также принимает решение по возникшей ошибке.На основе полученной информации и принятого решения формируется прецедент, который сохраняется в базе знаний предприятия.
При необходимости копия прецедента передаётся разработчику для возможности исправления возникшей ошибки.
Разработанная концепция системы анализа ошибок позволяет создать программный комплекс, обеспечивающий эффективное выполнение всех основных процессов, связанных с идентификацией и анализом ошибок, возникающих в процессе функционирования корпоративных программных систем.
Приоритетными направлениями при разработке комплекса анализа ошибок должны стать: использование специализированных средств сбора протоколов, повышение стабильности работы и повышение безопасности. Перспективными направлениями, требующими проведения дополнительных научных исследований, являются: автоматическая генерация правил, анализ текстов пользовательских протоколов и разработка корпоративной базы знаний.
Работа выполнена в рамках государственного задания Министерства образования и науки Российской Федерации.
Захаров В. Г., Крайнов А. Ю., Липатова С. В., Смагин А. А. Построение системы доставки обновлений программных продуктов // Учёные записки Ульяновского государственного университета. 2012. № 1 (4). С. 161-174.
Крайнов А. Ю., Смагин А. А. Автоматизация сбора протоколов в системе сопровождения программного обеспечения на основе обработки сложных событий // Автоматизация процессов управления. 2013. № 2 (32). [В печати].
КолинА. Обзор систем отслеживания ошибок [Электронный ресурс] / / Центр Компетенций Atlassian.
Паклин Н., Орешков В. Бизнес-аналитика. От данных к знаниям. 2-е изд. Питер, 2013. 704 с.
Пескова О.В. Алгоритмы классификации полнотекстовых документов // Автоматическая обработка текстов на естественном языке и компьютерная Лингвистика. М.: МИЭМ, 2011. С. 170-212.
Куприянов А.А., Мельниченко А.С. Модели структуризации и формализации онтологии предметной области на стадиях проектирования автоматизированных систем // Автоматизация процессов управления. 2010. № 2 (20). С. 70-75.
Рассмотрены дефекты программного обеспечения и их последствия на примере системы управления движением судов.
Ключевые слова: дефект, программное обеспечение, отказ, система управления движением судов
Согласно ГОСТам и другим нормативно-правовым документам РФ отдельного понятия для программной ошибки, программного дефекта или уязвимости в программном коде не существует, однако в [1] дефект или ошибка определяется как каждое отдельное несоответствие продукции установленным к ней требованиям. Помимо этого, этот же документ определяет термин тестирование. Тестирование — деятельность, направленная на обнаружение дефектов в программном обеспечении.
Под дефектом или ошибкой безопасности ПО следует понимать каждое отдельное несоответствие ПО установленным требованиям к безопасности. В свою очередь, под уязвимостью в ПО будем понимать ошибку, обуславливающую возможность реализации угроз безопасности к обрабатываемой в ПО защищаемой информации.
Защищаемая информация — информация, являющаяся предметом собственности и подлежащая защите в соответствии с требованиями правовых документов или требованиями, устанавливаемыми собственником информации [2].
Различают два основных уровня, на которых происходит диагностика структуры ПО: анализ исходного и бинарного (исполняемого) кодов.
Каждый уровень диагностики обладает своими преимуществами и недостатками. Однако в основном дефекты возникают вследствие того, что разработчики ПО не могут учесть всех особенностей исполняемого кода программы, возникающих из-за использования оптимизирующих компиляторов и бинарных трансляторов.
Согласно приведенным определениям, дефекты ПО можно разделить на:
– уязвимости (критические ошибки), приводящие к нарушению работоспособности, отказу в обслуживании, изменению защищенности информационных ресурсов;
– ошибки (некритические), влияющие лишь на качество программной системы (например, программа использует больше памяти для работы, чем необходимо, из-за утечек памяти при работе с ней) (рис. 1).
Рис. 1. Классификация дефектов ПО
Наибольший интерес представляет поиск критических ошибок, однако некритические ошибки также сказываются на процессе эксплуатации ПО, поэтому современные системы диагностики направлены на идентификацию обоих типов дефектов [3].
– переполнение буфера возникает в том случае, если программа позволяет записать больше данных в буфер меньшего размера или тогда, когда программа позволяет записать данные за границы выделенного буфера;
– ошибки при работе с динамической памятью (утечка памяти, разыменование нулевых указателей и др.);
– ошибки обработки пользовательских данных;
– ошибки форматных строк;
– ошибки синхронизации (взаимные блокировки, отсутствующие блокировки и т. п.);
– утечки памяти и других ресурсов системы;
– некорректная работа с временными файлами и другими интерфейсами ОС;
– уязвимости безопасности (слабое шифрование, хранение пароля в явном виде и т. п.), не вытекающие непосредственно из дефектов, можно выделить в отдельный класс уязвимостей.
Уязвимости могут быть классифицированы с помощью различных подходов. Dowd и другие в своей работе [6] выделили уязвимости в три базовых класса в зависимости от этапа разработки:
– Уязвимости в архитектуре. Возникают вследствие неправильной реализации требований по безопасности на уровне архитектуры будущего программного средства или неправильной идентификации потенциальных угроз. Тривиальным примером может служить отсутствие механизма проверки длины пользовательских данных при их обработке на сервере.
– Уязвимости в реализации. Возникают вследствие некорректной реализации программного продукта. Продолжая предыдущий пример, такой уязвимостью может являться некорректно реализованная проверка длины пользовательских данных, когда для хранения этой длины используется тип данных слишком маленького размера.
– Уязвимости на этапе эксплуатации, которые возникают не из-за ошибок в коде программного продукта, а по ряду других причин, связанных со средой выполнения или ошибок конфигурации. Например, пользуясь предыдущим примером, уязвимость, возникающая при отключении в настройках проверки пользовательских данных на сервере.
Рассмотрим последствия дефектов программного обеспечения на примере системы управления движением судов (СУДС).
СУДС работает согласно международным и национальным правовым и нормативным актам, над повышением уровня безопасности мореплавания путем сбора, обработки информации и выдачи ее на суда, оказание помощи в судовождении и организации движения объектов по акватории, которая оборудована современными средствами радиолокации, связи, телевидения и программно-аппаратными комплексами [7]. Под программно-аппаратными комплексами (ПАК) понимаем программное обеспечение, вычислительную технику и локальную вычислительную сеть. Программное обеспечение (ПО) — совокупность программ для управления процессом работы компьютера. В него входят: операционная система и вспомогательные программы.
На сегодняшний день в России функционируют 16 СУДС, программное обеспечение которых представлено в таблице 1 (рис. 2).
Для эффективной организации процессов производства руководителям и специалистам необходимо знать и учитывать основные источники и типы дефектов и ошибок, возможные в сложных комплексах программ, которые следует изучать, прогнозировать и устранять при производстве.
Понятие дефекта или ошибки в программе подразумевает неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба - риска при функционировании и применении программного продукта. При этом должно быть известно или задано требование или правильное, эталонное состояние объекта или процесса, по отношению к которому может быть определено наличие отклонения - ошибка или дефект. Исходным эталоном обычно является специфи - кация требований заказчика или потенциального пользователя, предъявляемая к программному компоненту или комплексу. Любое отклонение результатов функционирования программы от предъявляемых к ней требований и сформированных по ним эталонов - тестов, следует квалифицировать как ошибку - дефект в программе, наносящий некоторый ущерб при ее применении. Различие между ожидаемыми и полученными результатами функционирования комплекса программ могут быть следствием ошибок не только в созданных программах, но и ошибок в первичных требованиях спецификаций, явившихся базой при создании эталонов. Тем самым проявляется объективная реальность, заключающаяся в невозможности абсолютной корректности и полноты исходных требований и эталонов для программных компонентов и комплексов.
Источниками ошибок в комплексах программ являются специалисты - конкретные люди с их индивидуальными особенностями, квалификацией, талантом и опытом. При этом можно выделить дефекты требований, расширения или совершенствования компонентов и комплексов программ, и необходимые изменения, обусловливаю - щие выявление случайных, непредсказуемых дефектов и ошибок.
Однако в сложных комплексах программ статистика и распределение типов ошибок и выполняемых изменений для коллективов разных специалистов нивелируются и проявляются достаточно общие закономерности, которые могут использоваться как ориентиры при их выявлении. Каждому типу необходимых корректировок соответствует более или менее определенная категория специалистов, являющихся источником дефектов данного типа (таблица 2.1). Такую корреляцию целесообразно учитывать как общую качественную тенденцию при анализе и поиске причин ошибок.
Статистика ошибок и дефектов в компонентах и комплексах программ, и их характеристики в сложных заказных продуктах, могут служить ориентирами для разработчиков при распределении ресурсов в жизненном цикле комплексов программ и предохранять их от излишнего оптимизма при оценке достигнутого качества программных продуктов. Изучение и прогнозирование характеристик дефектов и ошибок в программах непосредственно связано с дости - гаемой корректностью, безопасностью и надежностью функционирования комплексов программ и помогает: оценивать реальное состояние проекта и планировать необходимую трудоемкость и длительность для его завершения и устранения доступных ошибок; выбирать методы и средства автоматизации тестирования компонентов комплекса программ, адекватные текущему состоянию производства, наиболее эффективные для устранения определенных видов дефектов; рассчитывать необходимую эффективность контрмер и дополнительных средств оперативной защиты от потенциальных дефектов и не выявленных ошибок; оценивать требующиеся ресурсы, при модификации программ для устранения дефектов и ошибок, с учетом затрат на реали - зацию контрмер.
На практике исходные требования - эталоны поэтапно уточняются, модифицируются, расширяются и детализируются по согласованию между заказчиком и разработчиками. Базой таких уточнений являются неформализованные представления и знания специали- стов - заказчиков и разработчиков, а также результаты промежуточ - ных этапов проектирования и тестирования.
Однако установить не корректность таких эталонов еще труднее, чем обнаружить дефекты в программах, так как принципиально отсутствуют точные, формализованные данные, которые можно использовать как исходные эталоны. В процессе декомпозиции и верификации исходной специфика - ции требований, возможно появление ошибок в спецификациях на компоненты программ и на отдельные модули. Это способствует расширению спектра возможных дефектов и вызывает необходимость создания гаммы методов и средств тестирования для выявления некорректностей в спецификациях на компоненты разных уровней.
Важной особенностью процесса выявления ошибок в программах обычно является отсутствие полностью определенной программы-эталона, которой должны соответствовать текст и результа - ты функционирования разрабатываемой программы. Поэтому установить наличие и локализовать дефект непосредственным сравнением с программой без ошибок в большинстве случаев невозможно. При тестировании обычно сначала обнаруживаются вторичные ошибки и риски, т.е. последствия и результаты проявления некоторых внутрен- них дефектов или некорректностей программ. Эти внутренние дефекты следует квалифицировать как первичные ошибки или причи- ны обнаруженных аномалий результатов. Последующая локализация и корректировка таких первичных ошибок должна приводить к устранению ошибок, первоначально обнаруживаемых в результатах функционирования программ.
Потери эффективности и риски программ за счет неполной корректности в первом приближении можно считать пропорциональными вторичным ошибкам в выходных результатах. Типичным является случай, когда одинаковые по величине и виду вторичные ошибки в различных результирующих данных существенно различаются по своему воздействию на общую эффективность и риски применения комплекса программ. Таким образом, оценка последствий, отражаю - щихся на вторичных ошибках и функционировании программ, может, в принципе, производиться по значениям ущерба - риска вследствие не устраненных их причин - первичных ошибок в программе.
Вторичные ошибки являются определяющими для эффективности функционирования программ, однако не каждая первичная ошибка вносит заметный вклад в выходные результаты. Вследствие этого ряд первичных ошибок может оставаться не обнаруженным и, по существу, не влияет на функциональные характеристики компонента или комплекса программ.
При производстве наибольшее число первичных ошибок вносится на этапах системного анализа, программирования, разработки или модификаций текстов программ. При этом на долю системного анализа приходятся наиболее сложные для обнаружения и устранения дефекты. Общие тенденции состоят в быстром росте затрат на выполнение каждого устранения ошибки на последовательных этапах процессов разработки компонентов и комплекса программ. При системном анализе интенсивность обнаружения ошибок относительно не велика, и ее трудно выделить из процесса проектирования компонента или комплекса программ. Интенсивность проявления и обнаружения вторичных ошибок наиболее велика на этапе активного тестирования и автономной отладки программных компонентов. Различия интенсивностей устранения первичных ошибок, на основе их вторичных проявлений, и внесения первичных ошибок при корректировках программ определяют скорость достижения заданного качества компонентов и комплексов программ.
Практический опыт показал, что наиболее существенными факторами, влияющими на характеристики обнаруживаемых ошибок, являются. методология, технология и уровень автоматизации системного и структурного проектирования компонентов и комплекса программ, а также непосредственного программирования компонентов; длительность с начала процесса тестирования компонентов и комплекса, и текущий этап производства или сопровождения комплекса программ; класс комплекса программ, масштаб (размер) и типы компонентов, в которых обнаруживаются ошибки; методы, виды и уровень автоматизации верификации и тести - рования, их адекватность характеристикам компонентов и потенциально возможным в программах ошибкам; виды и достоверность эталонов - тестов, которые используются для обнаружения ошибок.
Одной из основных причин ошибок в сложных комплексах программ являются организационные дефекты создания требований и эталонов к программному продукту, которые отличаются от остальных типов. Ошибки и дефекты этого типа появляются из-за недостаточного понимания руководителями и коллективом специали- стов целей и функций комплекса программ, а также вследствие отсутствия четкой их организации и поэтапного контроля требований качества компонентов и продуктов. Это порождается пренебрежени - ем руководителей к организации всего технологического процесса формализации требований сложных программных продуктов и приводит к серьезной недооценке их дефектов, а также к трудоемкости и сложности их выявления. При отсутствии при производстве планомерной и методичной разработки и тестирования требований и эта - лонов может оставаться не выявленным значительное количество ошибок, и, прежде всего, дефекты требований к взаимодействию отдельных функциональных компонентов между собой и с внешней средой. Для сокращения этого типа массовых ошибок, активную роль должны играть лидеры - менеджеры и аналитики - системотехники, способные вести контроль и конфигурационное управление требованиями, изменениями и развитием версий и компонентов комплексов программ.
Системные ошибки и недостатки определения требований к программному продукту характеризуются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. Кроме того, эти процессы зачастую зави - сят от самих алгоритмов и поэтому не могут быть достаточно определены и описаны заранее без исследования функционирования комплекса программ во взаимодействии с внешней средой. На начальных этапах разработки не всегда удается точно и полно сформулировать целевую задачу всей системы, а также целевые задачи основных функциональных групп программ, и эти задачи уточняются в процессе проектирования. Во многих случаях отсутствует полная адекватность условий получения предполагаемых и реальных характеристик внешней среды, что может являться причиной сложных и трудно обнаруживаемых системных ошибок.
Ошибки определения характеристик системы и внешней среды, принятых в процессе производства комплекса программ за исходные, могут быть результатом аналитических расчетов, моделирования или исследования аналогичных систем. В ряде случаев может отсутствовать полная адекватность предполагаемых и реальных ха - рактеристик, что является причиной сложных и трудно обнаруживаемых системных ошибок и дефектов развития проекта.
Сложность обнаружения и устранения ошибок значительно конкретизируются и становятся измеримой, когда устанавливается связь этого понятия с конкретными ресурсами, необходимыми для решения соответствующей задачи и возможными проявлениями дефектов. При разработке и сопровождении программ основным ли - митирующим ресурсом обычно являются допустимые трудозатраты специалистов, а также ограничения на сроки разработки, техноло - гию проектирования корректировок комплекса. К факторам, влияющим на сложность обнаруживаемых ошибок комплексов программ, относятся: величина - размер создаваемой или модифицируемой программы, выраженная числом строк текста, функциональных точек или количеством программных компонентов в комплексе; количество обрабатываемых переменных или размер и структура памяти, используемой для размещения базы данных корректировок; трудоемкость разработки изменений компонентов и комплекса программ; длительность разработки и реализации корректировок; число специалистов, участвующих в производстве компо - нентов и комплекса программ.
Убывание ошибок в компонентах и комплексе программ и ин - тенсивности их обнаружения в процессе производства не беспредельно. После тестирования в течение некоторого времени интенсив - ность обнаружения дефектов при самых жестких внешних условиях испытаний снижается настолько, что коллектив, ведущий разработку и тестирование, попадает в зону нечувствительности к ошибкам и возможным отказам функционирования. При такой интенсивности отказов вследствие их редкого проявления трудно прогнозировать затраты времени, необходимые для обнаружения очередной ошибки или дефекта. Создается представление о полном отсутствии случай - ных проявлений дефектов, о невозможности и бесцельности их поиска, поэтому усилия на тестирование сокращаются, и интенсивность обнаружения ошибок еще больше снижается. Этой предельной интенсивности обнаружения отказов соответствует наработка на обнаруженную ошибку, при которой прекращается улучшение характеристик программного комплекса на этапах тестирования или испытаний.
При серийном выпуске программного продукта, благодаря зна - чительному расширению вариантов исходных данных и условий эксплуатации, возможно в течение некоторого времени возрастание суммарной (по всем экземплярам системы) интенсивности обнаружения дефектов и ошибок. Это позволяет дополнительно устранять ряд дефектов и тем самым увеличивать длительность между проявлениями ошибок в процессе эксплуатации.
Читайте также: