Программные ошибки факторы влияющие на характеристики обнаруживаемых ошибок

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

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

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

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

• методология,
  технология и уровень автоматизации
  системного и структурного
  проектирования ПС, а также непосредственного
  программирования
  компонентов;

• длительность
  с начала процесса тестирования и текущий
  этап разработки
  или сопровождения и модификации
  комплекса программ;

• класс
  ПС, масштаб (размер) и типы компонентов,
  в которых обнаруживаются
  ошибки;

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

• виды
  и достоверность эталонов-тестов, которые
  используются для обнаружения
  ошибок.

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

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

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

• ошибки
  планирования и корректности требований
  модификаций часто
  могут быть наиболее критичным для
  общего успеха ЖЦ ПС и системы;

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

• системные
  ошибки, обусловленные отклонением
  функционирования
  ПС в реальной системе, и характеристик
  внешних объектов от предполагавшихся
  при проектировании;

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

• ошибки
  реализации спецификаций изменений —
  программные дефекты,
  возможно, ошибки нарушения требований
  или структуры компонентов ПС;

• программные
  ошибки, вследствие неправильной записи
  текстов программ
  на языке программирования и ошибок
  трансляции текстов изменений
  программ в объектный код;

• ошибки
  в документации, которые наиболее легко
  обнаруживаются и в наименьшей степени
  влияют на функционирование и применение
  версий
  ПС;

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

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

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

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

К
группе факторов, влияющих на сложность
ошибок комплексов
программ, относятся:

• величина
  — размер модифицируемой программы,
  выраженная числом
  строк текста, функциональных точек или
  количеством программных модулей в
  комплексе;

• количество
  обрабатываемых переменных или размер
  и структура памяти, используемой для
  размещения базы данных корректировок;

• трудоемкость
  разработки изменений комплекса программ;

• длительность
  разработки и реализации корректировок;

• число
  специалистов, участвующих в ЖЦ комплекса
  программ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

бок).
Следует также отметить большое количество
команд, корректируемых при исправлении
каждой такой ошибки (около 20—50 команд
на одну ошибку).

Алгоритмические
ошибки программ
трудно поддаются обнаружению
методами статического автоматического
контроля. Трудность их обнаружения
и локализация определяется, прежде
всего, отсутствием для многих логических
программ строго формализованной
постановки задачи,
полной и точной спецификации, которую
можно использовать в качестве
эталона для сравнения результатов
функционирования программ. К алгоритмическим
ошибкам следует отнести, прежде всего,
ошибки, обусловленные
некорректной постановкой требований
к функциональным задачам,
когда в спецификациях не полностью
оговорены все условия, необходимые
для получения правильного результата.
Эти условия формируются и уточняются
в значительной части в процессе
тестирования и выявления ошибок в
результатах функционирования программ.
Ошибки, обусловленные
неполным учетом всех условий решения
задач, являются наиболее
частыми в этой группе и составляют до
50—70% всех алгоритмических ошибок.

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

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

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

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

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

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

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

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

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

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

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

Технологические
ошибки документации
и фиксирования программ в памяти ЭВМ
составляют иногда до 10% от общего числа
ошибок, обнаруживаемых
при тестировании. Большинство
технологических ошибок выявляется
автоматически статическими методами.
При ручной подготовке текстов машинных
носителей при однократном фиксировании
исходные данные
имеют вероятность искажения около 10
«³—
10~⁴
на символ. Дублированной
подготовкой и логическим контролем
вероятность технологической
ошибки может быть снижена до уровня 10
⁵
—
10′⁷
на символ. Непосредственное
участие человека в подготовке данных
для ввода в ЭВМ и
при анализе результатов функционирования
программ по данным на дисплеях определяет
в значительной степени их уровень
достоверности и не позволяет полностью
пренебрегать этим типом ошибок в
программах.

В
примере
анализа ошибок конкретного крупного
проекта было
принято, что завершилась инспекция
начального запрограммированного кода
крупного ПС на предмет его соответствия
рабочей проектной спецификации,
в ходе которой было обнаружено 3,48 ошибки
на тысячу строк кода. Наибольшее
совпадение аппроксимации рэлеевской
кривой распределения
ошибок с фактическими данными установлено
для момента получения этих данных, ему
соответствует значение, равное также
3,48. Значения
числа ошибок на тысячу строк получены
при пересчетах на более ранние
этапы соответственно эскизного — (3,3)
и рабочего — (7,8) проектирования
программ. При прогнозировании в
соответствии с рэлеевской кривой
распределения вероятности проявления
дефектов программ на следующем
этапе квалификационного тестирования
компонентов следовало ожидать
обнаружения около 2,12 ошибки на тысячу
строк исходного кода.

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

В
исследованиях 20 крупных поставляемых
программных продуктов, созданных в 13
различных организациях, коллективы
специалистов добились среднего уровня
0,06 дефекта на тысячу строк нового и
измененного программного
кода. При использовании структурного
метода в пяти проектах достигнуто
0,04—0,075 ошибки на тысячу строк. Таким
образом, уровень
ошибок около 0,05 на тысячу строк кода в
разных публикациях считается близким
к предельному для высококачественных
программных продуктов.

Другим
примером оценок уровня ошибок критического
ПС особенно высокого
качества может служить программный
продукт бортовых систем «Шаттла»,
созданный NASA.
По оценке авторов, в нем содержится
менее
одной ошибки на 10 000 строк кода. Однако
стоимость программного
продукта достигает 1000 $ за строку кода,
что в среднем в сто раз больше,
чем для административных систем, и в
десять раз больше, чем для ряда
ординарных критических управляющих
систем реального времени.

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

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

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

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

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

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

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

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

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

276

рисков:
функциональной пригодности ПС,
конструктивных характеристик качества
и нарушения ограничений ресурсов при
реализации процессов ЖЦ ПС;

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

1. Качество программного средства, уровень качества.

Качество программы (quality) – весь объём признаков и характеристик программы, который относится к её способности удовлетворять установленным или предполагаемым потребностям.

Уровень качества  функционирования (level of performance)  – степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества. Из
приведенной формулировки следует, что не все свойства ПО входят в его качество, а только та их совокупность, которая определяется потребностью в этом ПО. Если по каким-то причинам исчезнет
потребность в данном ПО, то его качество будет нулевым.

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

1. Математическая модель качества программного средства.

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

1. Методы контроля показателей качества программного средства.

В соответствии  с ГОСТ 28195–89 «Оценка качества программных средств» методы определения показателей качества ПО различаются:

• по способам получения информации о ПО – измерительный, регистрационный, органолептический, расчетный;

• по источникам получения информации – традиционный, экспертный, социологический.

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

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

1. Модели оценки качества программного средства с математической точки зрения.

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

1. Измерительные методы контроля качества программного средства.

Измерительный метод основан на получении информации о свойствах и характеристиках ПО с использованием инструментальных средств. Например, с использованием этого метода определяется объём ПО –
число строк исходного текста программ и число строк-комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время
выполнения ветви программы, время реакции и другие показатели.

1. Экспертные методы контроля качества программного средства.

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

1. Традиционные методы контроля качества программного средства.

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

1. Социологические методы контроля качества программного средства.

Социологические методы основаны на обработке специальных анкет-вопросников.

1. Показатель качества программного средства: Функциональная пригодность.

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

1. Показатель качества программного средства: Надёжность.

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

1. Показатель качества программного средства: Применимость.

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

1. Показатель качества программного средства: Эффективность.

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

1. Показатель качества программного средства: Сопровождаемость.

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

1. Показатель качества программного средства: Переносимость.

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

1. Подходы к анализу и оценке соответствия показателей качества предъявляемым требованиям.

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

1. Сбои и отказы. Классификация.

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

Классификация по длительности восстановления:

—  достаточные для нарушения работоспособности системы.

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

1. Показатели надёжности программного средства.

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

1. Понятие «правильной» системы.

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

1. Модель уязвимости программного средства: Объекты уязвимости.

Вычислительный процесс, информация БД, объектный код программы, информация для потребителей.

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

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

1. Модель уязвимости программного средства: Внутренние дестабилизирующие факторы и угрозы.

Ошибки проектирования при постановке задач, ошибки алгоритмизации задач, ошибки программирования, недостаточное качество средств защиты.

1. Модель уязвимости программного средства: Методы предотвращения угроз и повышения надёжности.

Применение CASE-технологий, систематическое тестирование, сертификация.

1. Модель уязвимости программного средства: Оперативные методы повышения надёжности.

Временная, информационная и программная избыточность.

1. Модель уязвимости программного средства: Последствия нарушения надёжности.

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

1. Ошибки в программных средствах. Особенности выявления.

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

1. Ошибки в программных средствах. Первичные и вторичные ошибки. Виды ошибок.

Вторичные – последствия и результаты некоторых дефектов.

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

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

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

Первичные – причины возникновения аномалий.

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

— Программные ошибки из-за неправильной записи исходного текста программ на языке программирования и ошибок трансляции программ в объектный код.

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

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

1. Ошибки в программных средствах. Уровни детализации ошибок.

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

1. Ошибки в программных средствах. Факторы, влияющие на характеристики обнаруживаемых ошибок.

— Методология, технология и уровень структурного проектирования ПС, а также непосредственно программирования его компонент.

— Длительность с начала процесса отладки и текущий этап разработки программ.

— Класс ПС – размер (масштаб), типы тестируемых объектов.

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

— Виды и достоверность эталонов, которые используются при обнаружении ошибок.

1. Зависимость качества программного средства от его структуры. Критерии выбора структуры.

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

Критерии выбора структуры: надёжность функционирования и безопасность применения, эффективное использование памяти или производительности ЭВМ, трудоёмкость или длительность разработки,
модифицируемость ПС.

1. Особенность тестирования и отладки программных компонент.

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

1. Стратегии отладки программных компонент.

1 стратегия: строится граф структуры модуля, в нём выявляются все маршруты. Затем все маршруты тестируются. Завершается отладка при полном покрытии графа программы протестированными маршрутами.
Подходит для программ с малой долей вычислений.

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

Восходящее и нисходящее тестирования.

1. Классификация тестов по объектам тестирования. Тестирование спецификаций.

Тесты проверки:

— полноты и согласованности функций;

— согласованности интерфейсов.

1. Классификация тестов по объектам тестирования. Тестирование программ.

Тесты проверки:

— структуры программы;

— вычисления и преобразования данных;

— полноты выполняемых функций.

1. Классификация тестов по объектам тестирования. Тестирование комплекса.

Тесты проверки:

— структуры комплекса;

— интерфейса компонент;

— ограничений по памяти;

— длительности исполнения;

-полноты решения задач комплекса.

1. Классификация тестов по объектам тестирования. Тестирование при испытаниях.

Тесты проверки:

— соответствие требованиям;

— удобство установки рабочей версии;

— работы комплекса на оборудовании;

— удобство интерфейса пользователя;

— удобства модификации и сопровождения.

1. Тестирование программных компонент. Этапы процесса тестирования.

1. Тестируется идентичность исходного текста программ, представленного на носителе данных с исходным текстом, представленном в программном документе.
2. Производится комплексирование статики программных и информационных модулей, входящих в них компонент,  при этом проверяются все интерфейсы между модулями и выявляются
   их несостыковки с описанием спецификации.
3. Производится анализ потоков управления в тексте программы, выделяющий основные подпрограммы, модули, процедуры и функции, и анализируются операторы управления вычислительным
   процессом. Для всех уровней иерархии программы строятся потоковые графы, которые используются для выделения маршрутов выполнения программ.
4. Выполняется анализ потоков данных, производится тестирование корректности обработки данных без использования программы. Цель этого этапа – установление соответствия между
   областями определения наборов данных и маршрутами их обработки в программе.
5. Устранение неувязок между программными и информационными модулями, входящими в компоненту.
6. Обработка результатов тестирования и оценка качества и коррекции в статике.
7. Проверка полноты наборов тестов.

1. Тестирование программных компонент. Ответственность инженера-тестировщика.

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

Ответственность инженера: программы тестов, тестовые ситуации, тестовые процедуры, оценка тестов, план теста.

1. Принципы тестирования структуры программных модулей.

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

1. Стратегия отладки программного обеспечения по тексту программы.

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

1. Стратегия отладки программного обеспечения по текстовым данным.

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

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

Качество может рассматриваться как компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах заказчика с учётом других ограничений.

1. Верификация и аттестация программного обеспечения.

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

1. Временная избыточность ресурсов для обеспечения надёжности программных средств.

Состоит в использовании некоторой части производительности ЭВМ для контроля исполнения программ и восстановления вычислительного процесса.

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

1. Информационная избыточность ресурсов для обеспечения надёжности программных средств.

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

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

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

1. V-модель разработки ПО.

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

V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи:

• Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания
  соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения в проекте и риски на ранних стадиях и улучшает качество управления проектов, уменьшая риски.
• Повышение и гарантии качества: V-Model — стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты
  могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость.
• Уменьшение общей стоимости проекта: Ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты
  также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты.
• Повышение качества коммуникации между участниками проекта: Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким
  образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком.

1. Линейный подход к разработке ПО.

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

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

1. Компонентное проектирование.

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

1. Разработка требований к ПО.

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

1. Управление требованиями к разработке ПО.

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

1. Поведенческие модели ПО.

Модель – абстрактное представление системы, в котором игнорируются некоторые детали системы. Модели поведения показывают операции, выполняемые объектами.

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

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

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

1. Модели системного окружения ПО.

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

1. Модели потоков данных.

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

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

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

1. Архитектурное проектирование ПО.

Архитектурным проектированием называется первый этап процесса проектирования, на котором определяются подсистемы, а также структура управления и взаимодействия подсистем.

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

1. Структурирование системы. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами.
2. Моделирование управления. Разрабатывается базовая модель управления взаимоотношениями между частями системы.
3. Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на определенные модули. Определяются модули и типы взаимосвязей.

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

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

В этой статье мы обсудим самые распространенные типы ПО дефекты и способы их выявления.

Что такое дефект?

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

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

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

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

Ошибки программного обеспечения подразделяются на три типа:

1. Дефекты программного обеспечения по своей природе
2. Дефекты программного обеспечения по их приоритету
3. Дефекты программного обеспечения по их серьезности

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

#1. Дефекты программного обеспечения по своей природе

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

#1. Функциональные ошибки

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

Функциональные ошибки можно исправить, выполнив функциональное тестирование.

#2. Ошибки на уровне модуля

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

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

#3. Ошибки уровня интеграции

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

Ошибки интеграции можно исправить, выполнив интеграционное тестирование.

#4. Дефекты юзабилити

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

Во время тестирования удобства использования тестировщики программного обеспечения проверяют приложения на соответствие требованиям пользователей и Руководству по доступности веб-контента (WCAG) для выявления таких проблем. Однако они могут оказать существенное влияние на общее качество программного обеспечения.

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

#5. Дефекты производительности

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

Ошибки юзабилити можно исправить, выполнив тестирование производительности.

#6. Дефекты безопасности

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

Ошибки безопасности можно исправить, выполнив тестирование безопасности.

#7. Дефекты совместимости

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

Ошибки совместимости можно исправить, выполнение тестирования совместимости.

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

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

#9. Логические ошибки

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

Общие симптомы логических ошибок включают:

• Неверные результаты или выходные данные
• Неожиданное поведение
• Сбой или зависание программного обеспечения

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

#2. Дефекты программного обеспечения по степени серьезности

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

#1. Критические дефекты

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

#2. Серьезные дефекты

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

#3. Незначительные дефекты

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

#4. Тривиальные дефекты

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

#3. Дефекты программного обеспечения по приоритету

#1. Дефекты с низким приоритетом

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

#2. Дефекты со средним приоритетом

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

#3. Дефекты с высоким приоритетом

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

Некоторые распространенные примеры дефектов с высоким приоритетом включают:

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

#4. Срочные дефекты

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

#4. Дополнительные дефекты

#1. Отсутствующие дефекты

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

#2. Неправильные дефекты

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

#3. Дефекты регрессии

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

Часто задаваемые вопросы — Типы программных ошибок< /h2>

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

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

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

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

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

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

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

Как найти лежащие в основе ошибки программного обеспечения?

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

1) Репликация. Первым этапом является воспроизведение ошибки. Это включает в себя попытку воспроизвести тот же набор шагов, в котором возникла ошибка. Это поможет проверить, является ли ошибка реальной или нет.
2) Изоляция. После того, как ошибка воспроизведена, следующим шагом будет попытка ее изоляции. Это включает в себя выяснение того, что именно вызывает ошибку. Для этого тестировщики должны задать себе несколько вопросов, например:
– Какие входные данные вызывают ошибку?
– При каких различных условиях возникает ошибка?
– Каковы различные способы проявления ошибки?
3) Анализ: после Изолируя ошибку, следующим шагом будет ее анализ. Это включает в себя понимание того, почему возникает ошибка. Тестировщики должны задать себе несколько вопросов, таких как:
– Какова основная причина ошибки?
– Какими способами можно исправить ошибку?
– Какое исправление было бы наиболее эффективным? эффективно?
4) Отчет. После анализа ошибки следующим шагом является сообщение о ней. Это включает в себя создание отчета об ошибке, который включает всю соответствующую информацию об ошибке. Отчет должен быть четким и кратким, чтобы разработчики могли его легко понять.
5) Проверка. После сообщения об ошибке следующим шагом является проверка того, была ли она исправлена. Это включает в себя повторное тестирование программного обеспечения, чтобы убедиться, что ошибка все еще существует. Если ошибка исправлена, то тестер может подтвердить это и закрыть отчет об ошибке. Если ошибка все еще существует, тестировщик может повторно открыть отчет об ошибке.

Заключение

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

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