Виды ошибок программ возникающие на этапе рабочего проектирования

Содержание

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

На основе изучения «ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств» были выявлены основные процессы разработки программного обеспечения:

выявление и анализ требований;
проектирование программного обеспечения;
программирование;
тестирование программного обеспечения.

Выявление и анализ требований

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

Ошибки архитекторов при проектировании складов. Посмотрите, прежде чем проектировать!

1. Двусмысленные требования

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

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

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

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

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

2. Неудобный пользовательский интерфейс

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

3. Неправильная структура базы данных

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

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

4. Неоптимальный выбор структур данных

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

Какие ошибки возникают на этапе проектирования дороги и что грозит подрядчикам?

5. Неоптимальный выбор языка программирования

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

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

Программирование

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

1. Изобретение «велосипеда»

Написание кода без использования возможностей языка и существующих библиотек.

2. Нечитаемый код

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

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

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

4. Нерегулярное резервное копирование кода

Последствие этого риска очень масштабно.

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

На этапе тестирования возможны следующие риски:

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

Список литературы

ГОСТ Р 51275-99. Защита информации. Объект информатизации. Факторы, воздействующие на информацию. — Москва: Изд-во стандартов, 2003. – 12 с.
ДеМарко Т., Листер Т. Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения. — М.: Компания p.m.Office, 2005. – 208 с.

Источник: habr.com

Лекция 8: Методы проверки и тестирования программ и систем

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

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

Известно много различных подходов к классификации ошибок, рассмотрим некоторые из них.

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

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

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

Таблица 7.1. Ортогональная классификация дефектов IBM Контекст ошибки Классификация дефектов

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

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

Фирма Hewlett-Packard использовала классификацию Буча, установив процентное соотношение ошибок, обнаруживаемых в ПО на разных стадиях разработки (рис. 7.2) [7.12].

Это соотношение — типичное для многих фирм, производящих ПО, имеет некоторые отклонения.

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

Рис. 7.2. Процентное соотношение ошибок при разработке ПО

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

В какой программе создать nft

Согласно данным [7.6, 7.11] стоимость анализа и формирования требований, внесения в них изменений составляет примерно 10%, аналогично оценивается стоимость спецификации продукта. Стоимость кодирования оценивается более чем 20%, а стоимость тестирования продукта составляет более 45% от его общей стоимости. Значительную часть стоимости составляет сопровождение готового продукта и исправление обнаруженных в нем ошибок.

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

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

Создаются тесты, проверяющие:

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

Тестовые данные готовятся как для проверки отдельных программных элементов, так и для групп программ или комплексов на разных стадиях процесса разработки. На рис. 7.3. приведена классификация тестов проверки по объектам тестирования на основных этапах разработки.

увеличить изображение
Рис. 7.3. Классификация тестов проверки

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

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

Рис. 7.4. Интегрированное тестирование компонент

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

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

Согласно приведенной схеме сначала тестируются компоненты А, В, D независимо друг от друга и каждый с отдельным тестом. После их проверки выполняется проверка интерфейсов для последующей их интеграции, суть которой заключается в анализе выполнения операторов вызова А -> E, B -> C, D -> G, на нижних уровнях графа: компоненты Е, С, G. При этом предполагается, что указанные вызываемые компоненты, так же должны быть отлажены отдельно. Аналогично проверяются все обращения к компоненту F, являющемуся связывающим звеном с вышележащими элементами.

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

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

Источник: intuit.ru

15 Методы и способы идентификации сбоев и ошибок. Методы и способы идентификации сбоев и ошибок

Единственный в мире Музей Смайликов

Методы и способы идентификации сбоев и ошибок

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

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

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

Ошибки на этапах процесса тестирования .

Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

Характерными ошибками этого процесса являются:

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

Процесс проектирования

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

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

Этап кодирования

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

Процесс тестирования.

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

Источник: topuch.com