Технологические нарушения обусловленные ошибками в работе программного обеспечения используемого в

Обновлено: 18.05.2024


Примитивы и критерии качества

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

Назовите принципы обеспечения примитивов качества.

Принципы обеспечения примитивов качества

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

Перечислите примитивы качества.

1. Завершенность 2. Точность 3. Автономность 4. Устойчивость 5. Защищенность 6. П-документированность 7. Информативность 8. Коммуникабельность 9. Временная эффективность 10. Эффективность по ресурсам

11. Эффективность по устройствам 12. С-документированность 13. Понятность 14. Структурированность 15. Удобочитаемость 16. Расширяемость 17. Модифицируемость 18. Модульность 19. Независимость от устройств

Какие примитивы влияют на функциональность и надежность ПС.

Функциональность: завершенность Надежность: завершенность, точность, автономность, устойчивость, защищенность Лёгкость применения: устойчивость, защищенность, п-документированность, информативность, коммуникабельность Эффективность: временная эффективность, эффективность по устройствам

Сопровождаемость: информативность, с-документированность, понятность, структурированность, удобочитаемость, расширяемость, модифицируемость, модульность Мобильность: автономность, структурированность, модульность, независимость от устройств

Дайте определение корректности или правильности программы.

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

ОШИБКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1. Понятие об ошибке

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

2. Источники ошибок программного изделия

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

3. Классификация ошибок

I. Технологические ошибки - возникают на любых этапах создания программы и составляют 5-10 % от общего числа ошибок, обнаруженных при отладке. II. Программные ошибки Количество программных ошибок зависит от квалификации разработчиков, от общего объема комплекса программ, от глубины логического и информационного взаимодействия модулей и ряда других факторов. Они появляются на стадии составления программ и составляют 1/3 от всех ошибок.

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

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

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

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

IV. Системные ошибки Определяются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. Они возникают на начальных этапах проектирования, когда точно не сформулирована целевая задачи всей системы. При автономной и в начале комплексной отладки доля системных ошибок невелика (около 10%), но она существенна возрастает (до 35-40 %) на завершающих этапах комплексной отладки. В процессе эксплуатации системные ошибки являются преобладающими (около 80 % от всех ошибок). Для корректировки системных ошибок приходится использовать около 25 команд.

4. Основные пути борьбы с ошибками

  • 1. Избежание ошибок.
  • Для этого используют:
  • минимизацию сложности;
  • достижение точности реализации процессов создания программ
  • совершенствование;
  • немедленное обнаружение и устранение ошибок
  • 2. Обнаружение:
  • организация проверки любых входных данных,
  • организация проверки любых входных данных на известные ограничения;
  • организация полноты проверки на наличие ошибок.
  • 3. Локализация:
  • применения принципа взаимного подозрения;
  • применения принципа немедленного обнаружения;
  • устранение найденной ошибки любым методом, который может быть применен.


Рассмотрены дефекты программного обеспечения и их последствия на примере системы управления движением судов.

Ключевые слова: дефект, программное обеспечение, отказ, система управления движением судов

Согласно ГОСТам и другим нормативно-правовым документам РФ отдельного понятия для программной ошибки, программного дефекта или уязвимости в программном коде не существует, однако в [1] дефект или ошибка определяется как каждое отдельное несоответствие продукции установленным к ней требованиям. Помимо этого, этот же документ определяет термин тестирование. Тестирование — деятельность, направленная на обнаружение дефектов в программном обеспечении.

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

Защищаемая информация — информация, являющаяся предметом собственности и подлежащая защите в соответствии с требованиями правовых документов или требованиями, устанавливаемыми собственником информации [2].

Различают два основных уровня, на которых происходит диагностика структуры ПО: анализ исходного и бинарного (исполняемого) кодов.

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

Согласно приведенным определениям, дефекты ПО можно разделить на:

– уязвимости (критические ошибки), приводящие к нарушению работоспособности, отказу в обслуживании, изменению защищенности информационных ресурсов;

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


Рис. 1. Классификация дефектов ПО

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

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

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

– ошибки обработки пользовательских данных;

– ошибки форматных строк;

– ошибки синхронизации (взаимные блокировки, отсутствующие блокировки и т. п.);

– утечки памяти и других ресурсов системы;

– некорректная работа с временными файлами и другими интерфейсами ОС;

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

Уязвимости могут быть классифицированы с помощью различных подходов. Dowd и другие в своей работе [6] выделили уязвимости в три базовых класса в зависимости от этапа разработки:

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

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

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

Рассмотрим последствия дефектов программного обеспечения на примере системы управления движением судов (СУДС).

СУДС работает согласно международным и национальным правовым и нормативным актам, над повышением уровня безопасности мореплавания путем сбора, обработки информации и выдачи ее на суда, оказание помощи в судовождении и организации движения объектов по акватории, которая оборудована современными средствами радиолокации, связи, телевидения и программно-аппаратными комплексами [7]. Под программно-аппаратными комплексами (ПАК) понимаем программное обеспечение, вычислительную технику и локальную вычислительную сеть. Программное обеспечение (ПО) — совокупность программ для управления процессом работы компьютера. В него входят: операционная система и вспомогательные программы.

На сегодняшний день в России функционируют 16 СУДС, программное обеспечение которых представлено в таблице 1 (рис. 2).

Узбекское Агентство
Связи и Информатизации

Ташкентский Университет Информационных Технологий

Преподаватель дисциплины


Выдержки из лекций

Глава 8. Ошибка

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

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

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

Отладка Оценка и использование

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

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

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

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

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

- ошибки в выборе алгоритма;

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

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

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

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

При автономной и в начале комплексной отладки ПО доля найденных системных ошибок в нем невелика (примерно 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки. В процессе эксплуатации преоб­ладающими являются системные ошибки (примерно 80% всех ошибок). Следует отметить также большое количество команд и групп программ, которые корректируются при исправлении каждой системной ошибки.

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

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

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

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

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

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

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

Технологические ошибки— это ошибки документации и фик­сирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Боль­шинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором).

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

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

Семантика языка это система правил истолкования пост­роений конструкций. Например, если фрагмент конструкции имеет вид А*(В + С), то правила семантики предписывают, что сначала выполняется сложение величин В и С, а затем результат умножается на величину А. Правила семантики (смысла) конст­рукций обычно вполне естественны и понятны, но в некоторых случаях их надо специально оговаривать, комментировать.

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

Итак, выделяют синтаксические и семантические ошибки.

Семантические (смысловые) ошибки это применение опе­раторов, которые не дают нужного эффекта (например, а—в вместо а+в), ошибка в структуре алгоритма, в логической взаи­мосвязи его частей, в применении алгоритма к тем данным, к которым он неприменим и т.д. Правила семантики не фор­мализуемы. Поэтому поиск и устранение семантической ошибки и составляет основу отладки.

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

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

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

Главная
Теоретический материал
Лабораторные работы

Тесты
Контакты

Материал сайта является электронным пособием
по дисциплине "Технология Программирования"
в помощь студентам ТУИТ.

В предыдущей части мы рассмотрели исходный код и его составляющие.

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

Отладка программы

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

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

отладка программы

Синтаксические ошибки

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

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

Семантические ошибки

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

Рассмотрим данный пример:

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

3 + 5, заключенные в скобки, дадут желаемый результат, а именно 48.

Ошибки в процессе выполнения

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

Вот хороший пример:

Фрагмент кода выше будет скомпилирован успешно, но input 25 приведет к ZeroDivisionError. Это ошибка во время выполнения. Другим популярным примером является StackOverflowError или IndexOutofBoundError. Важно то, что вы идентифицируете эти ошибки и узнаете, как с ними бороться.

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

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

Отладка программы

Вот несколько советов о том, как правильно выполнять отладку:

  1. Использовать Linters. Linters – это инструменты, которые помогают считывать исходный код, чтобы проверить, соответствует ли он ожидаемому стандарту на выбранном языке программирования. Существуют линты для многих языков.
  2. Превалирование IDE над простыми редакторами. Вы можете выбрать IDE, разработанную для языка, который изучаете. IDE – это интегрированные среды разработки. Они созданы для написания, отладки, компиляции и запуска кода. Jetbrains создают отличные IDE, такие как Webstorm и IntelliJ. Также есть NetBeans, Komodo, Qt, Android Studio, XCode (поставляется с Mac), etc.
  3. Чтение кода вслух. Это полезно, когда вы ищете семантическую ошибку. Читая свой код вслух, есть большая вероятность, что вы зачитаете и ошибку.
  4. Чтение логов. Когда компилятор отмечает Error, обязательно посмотрите, где он находится.

Двигаемся дальше

В процессе кодинга измените что-нибудь, чтобы понять, как он работает. Но будьте уверены в том, что сами написали.


Рассмотрены дефекты программного обеспечения и их последствия на примере системы управления движением судов.

Ключевые слова: дефект, программное обеспечение, отказ, система управления движением судов

Согласно ГОСТам и другим нормативно-правовым документам РФ отдельного понятия для программной ошибки, программного дефекта или уязвимости в программном коде не существует, однако в [1] дефект или ошибка определяется как каждое отдельное несоответствие продукции установленным к ней требованиям. Помимо этого, этот же документ определяет термин тестирование. Тестирование — деятельность, направленная на обнаружение дефектов в программном обеспечении.

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

Защищаемая информация — информация, являющаяся предметом собственности и подлежащая защите в соответствии с требованиями правовых документов или требованиями, устанавливаемыми собственником информации [2].

Различают два основных уровня, на которых происходит диагностика структуры ПО: анализ исходного и бинарного (исполняемого) кодов.

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

Согласно приведенным определениям, дефекты ПО можно разделить на:

– уязвимости (критические ошибки), приводящие к нарушению работоспособности, отказу в обслуживании, изменению защищенности информационных ресурсов;

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


Рис. 1. Классификация дефектов ПО

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

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

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

– ошибки обработки пользовательских данных;

– ошибки форматных строк;

– ошибки синхронизации (взаимные блокировки, отсутствующие блокировки и т. п.);

– утечки памяти и других ресурсов системы;

– некорректная работа с временными файлами и другими интерфейсами ОС;

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

Уязвимости могут быть классифицированы с помощью различных подходов. Dowd и другие в своей работе [6] выделили уязвимости в три базовых класса в зависимости от этапа разработки:

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

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

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

Рассмотрим последствия дефектов программного обеспечения на примере системы управления движением судов (СУДС).

СУДС работает согласно международным и национальным правовым и нормативным актам, над повышением уровня безопасности мореплавания путем сбора, обработки информации и выдачи ее на суда, оказание помощи в судовождении и организации движения объектов по акватории, которая оборудована современными средствами радиолокации, связи, телевидения и программно-аппаратными комплексами [7]. Под программно-аппаратными комплексами (ПАК) понимаем программное обеспечение, вычислительную технику и локальную вычислительную сеть. Программное обеспечение (ПО) — совокупность программ для управления процессом работы компьютера. В него входят: операционная система и вспомогательные программы.

На сегодняшний день в России функционируют 16 СУДС, программное обеспечение которых представлено в таблице 1 (рис. 2).

Читайте также: