Что такое вторичные ошибки

Вторичная ошибка

Cтраница 1

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

Одинаковые по величине вторичные ошибки в различных результирующих данных существенно различаются по своему воздействию на общую эффективность КП. Это влияние для вторичных ошибок в каждой / — и переменной может быть учтено коэффициентом х /, который позволяет взвешивать последствия ошибок. Формальная оценка значений X; и А / в настоящее время затруднительна, в лучшем случае их можно оценить методами экспертного опроса при предварительной четкой классификации т типов первичных ошибок в программах и q выходных величин.
 [2]

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

В первом приближении величину вторичной ошибки ст / в / — х результатах решения задачи за счет пропущенных при отладке первичных ошибок можно оценить статистически следующим образом.
 [5]

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

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

Описаны несколько математических моделей [4, 17, 18], основой которых являются различные гипотезы о характере проявления вторичных ошибок в программах. Эти гипотезы в той или иной степени апробированы при обработке данных реальных разработок, и их можно разделить на три группы. В первую группу входят очевидные допущения, статистическая проверка которых невозможна и нецелесообразна. Вторую группу составляют допущения, определяющие специфические характеристики модели и требующие статистической проверки и обоснования на базе экспериментальных исследований. В третью группу включены второстепенные допущения, расширяющие и уточняющие возможности применения модели и частично доступные экспериментальной проверке.
 [8]

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

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

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

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

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

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

Страницы:  

   1

   2

10.1. Общие
особенности дефектов, ошибок и рисков
в сложных программных средствах

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

10.3. Риски
в жизненном цикле сложных программных
средств

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

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

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

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

Характеристики
дефектов и рисков непосредственно
связаны с достигаемой
корректностью, безопасностью и надежностью
функционирования
программ и помогают:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица
10.1

Специалисты— источники дефектов и ошибок	Типы первичных дефектов и ошибок программного средства и документации
Заказчики проекта	Дефекты организации проекта и исходных требований заказчика
Менеджер проекта	Дефекты, обусловленные реальной сложностью проекта
Менеджер-архитектор комплекса программ	Ошибки планирования и системного проектирования программного средства
Проблемно-ориентированные аналитики и системные архитекторы	Системные и алгоритмические дефекты и ошибки проекта
Спецификаторы компонентов проекта	Алгоритмические ошибки компонентов и документов программного средства
Разработчики программных компонентов — программисты	Программные дефекты и ошибки компонентов и документов программного средства
Системные интеграторы	Системные ошибки и дефекты реализации версий программного средства и документации
Тестировщики	Программные и алгоритмические ошибки программного средства и документации
Управляющие сопровождением и конфигурацией, инструкторы интерфейсов	Ошибки проектирования и реализации версий программного продукта
Документаторы	Дефекты и ошибки обобщающих документов

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

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

---

С этим файлом связано 1 файл(ов). Среди них: Rekun.docx.
Показать все связанные файлы

---

Подборка по базе: Общие сведения о горении и горючих веществах, пожаре и его разви, 01. Введение. Основные уравнения электродинамики.pdf, 1 Основные понятия и определения ИС.docx, Статья 3. Основные понятия, используемые в настоящем Федеральном, Тема 1. Первая помощь содержание, объем, организационные и юриди, Вредители свеклы. Основные вредители свеклы. Меры борьбы с ними., 3. Этические нормы и принципы оказания психологической помощи (1, Психическое здоровье и личное развитие. Критерии психического зд, МЕТОДИЧЕСКИЕ ОСНОВЫ СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ , ПРАКТИЧЕСКАЯ РАБОТА № 3 Основные типы и форматы данных в электро

---

1. CALS-технологии

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

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

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

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

Основные принципы CALS-технологий базируются на контроле и организации этапов существования продукции. К ним относят:

• Обеспечение системного управления (использование специальных информационных пространств);
• Минимизацию затрат на всех стадиях;
• Использование стандартных механизмов описания управляемых объектов (интеграция информационных потоков);
• Дифференциацию программных элементов на основе использования общих стандартов (данных и интерфейсов доступа) и применение платформ на коммерческой основе;
• Представление информации на безбумажной основе с приоритетом использования электронной подписи;
• Сопутствующий инжиниринг все процессов;
• Непрерывное корректирование и усовершенствование с целью создания оптимальной модели управления.

Создание информационной плоскости предполагает решение задачи на двух уровнях:

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

К преимуществам интегрированной среды можно отнести:

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

Перспективы применения CALS на промышленных предприятиях заключаются в формировании специализированной организационно-информационной среды, позволяющей:

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

Применение основ CALS-технологий крайне важно для соответствия уровня развития предприятия современным тенденциям на международной промышленной арене.

Примерами CALS-технологий являются цифровые методы проектирования производств, поддерживающие контроль жизненного цикла продукции (Product LifecycleManagement) — так называемые PLM-системы. К ним относят следующие классы систем:

• CAD – (Computer Aided Design) – решение задач проектирования изделий и элементов; моделирование объектов на плоскости (2D-модель) и в пространстве (3D-модель); средства получения чертежей; архивы данных по элементам конструкций и создание шаблонов документов.
• CAE – (Computer Aided Engineering) – исследование свойств объектов (при изготовлении и эксплуатации); создание проверочных систем анализа объекта по разработанной модели; оптимизация параметров объекта по заданным условиям и ограничениям.
• CAM — (Computer Aided Manufacturing) – программирование контроллеров станков с ЧПУ; исследование вариантов траектории инструмента по алгоритмам обрабатываемой поверхности; анализ геометрических конфликтов; подгонка к оборудованию.
• PDM — (Product Data Management) — хранение данных и контроль документации; создание архива образцов; обеспечение доступа к информации и ее защита.

CALS-технологии — это прежде всего методика информационной поддержки бизнес процессов, которая нашла свое применение в различных сферах производственной деятельности. Эффективность ее распространения и использования базируется на системной разработке соответствующей информационной среды. Для реализации данной цели необходимым условием является использование специальных композиционных подходов по формированию новых систем поддержки. Примером подобной компании на рынке России является НИЦ CALS-технологий «Прикладная логистика». Основные задачи компании лежат в плоскости прогрессивных платформ и нормативов их использования. Основными направлениями деятельности есть: осуществление оперативного наблюдения различных проектных данных и минимизация потерь продукции. НИЦ CALS-технологий — разработчик нескольких известных авторских платформ. Сделаем их краткий обзор.

Еще одной важной функцией вычислительных методов является управление различными ресурсами и потоками предприятия в реальном времени — материально-техническими, финансовыми, процессами складирования, персоналом, планированием и сбытом продукции. Системы, реализующие выполнение перечисленных задач относятся к ERP-системам (Enterprise Resource Planning − управление ресурсами предприятия).

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

К типовым функциям данного класса программных продуктов относят:

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

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

2 Первичные ошибки, вторичные ошибки и их проявления

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

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

Распределение выявленных ошибок

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

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

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

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

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

• системные ошибки;
• ошибки в выборе алгоритма;
• алгоритмические ошибки;
• технологические ошибки;
• программные ошибки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Модульная декомпозиция. Каждая определенная на первом этапе подсистема разбивается на определенные модули. Определяются модули и типы взаимосвязей.

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