Технология программирования.

Технология программирования.

 

Качество программных систем.

 

Основные требования к программам, входящим в программную систему:

1. Правильность (функционирует в соответствии с техническим заданием).

2. Точность (результаты имеют допустимые отклонения от аналогичных результатов расчётов по идеальным математическим моделям).

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

4. Надёжность (программа при всех условиях обеспечивает полную повторяемость результата).

5. Универсальность (правильно работает при любых допустимых вариантах исходных данных, предусматриваются средства защиты от неправильных данных).

6. Защищённость (сохраняет работоспособность при возникновении сбоев, защита от несанкционированного доступа).

7. Полезность (решаемая задача представляет практическую ценность).

8. Эффективность (объём требуемых ресурсов не превышает допустимых пределов).

9. Проверяемость (качество программы могут быть продемонстрированы на практике).

10. Адаптируемость (допускает быструю модификацию для приспособления к новым условиям).

 

 

Аспекты качества оценки программных систем.

 

Качество программы определяется с разных точек зрения:

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

а) служащие, подготавливающие документацию на компьютере;

б) инженеры, выполняющие научно-технические расчёты;

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

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

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

а) реальную потребность в такой системе;

б) оценить возможности программной системы, её разработки и примерный объём затрат;

в) оценить ожидаемый эффект от её внедрения.

 

После завершения предварительных исследований составляется список требований, предъявляемых к системе:

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

2. Описание выполняемых системой функций.

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

ВЫВОД: Необходимо всесторонне анализировать эффекты, связанные с внедрением в систему.

 

 

Стадии разработки программного обеспечения.

 

ГОСТ 19102-77

Согласно этому ГОСТу существуют следующие стадии:

1. Техническое задание (т.з.).

2. Эскизный проект (э.п.).

3. Технический проект (т.п.).

4. Рабочий проект (р.п.).

5. Внедрение.

Рассмотрим каждый из них:

1. Техническое задание. Выполнение следующих работ:

Ø постановка задачи;

Ø сбор исходных материалов;

Ø выбор и обоснование критериев эффективности и качества разрабатываемой программы;

Ø обоснование необходимости проведения научно-исследовательских работ;

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

Ø предварительный выбор методов решения задач;

Ø определение требований к техническим средствам;

Ø определение требований и целей разработки программ, стадий, этапов, сроков разработки программы и документаций на неё;

Ø проведение технико-экономического обоснования разработки программ;

Ø согласование и утверждение т.з.

2. Эскизный проект. Виды работ:

Ø внешнее проектирование программного изделия;

Ø уточнение методов решения задач;

Ø предварительное проектирование внутренних структур данных;

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

 

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

При разработке э.п. определяются:

ü способы взаимодействия пользователя с программой,

ü функции пользователей,

ü тип взаимодействия,

ü структура и содержание информационных кадров и шаблонов диалога,

ü структура входных и выходных данных.

3. Технический проект. Виды работ:

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

Ø проектирование структур данных (определяются способы представления, хранения и преобразования входных, выходных и внутренних данных);

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

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

Ø разработка пояснительной записки.

4. Рабочий проект. Виды работ:

Ø кодирование, тестирование и отладка программ;

Ø разработка программных документов согласно требованиям ЕСПД;

Ø проведение приёма сдаточных испытаний;

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

5. Внедрение:

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

 

Разработка спецификаций.

 

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

Выделяет две части:

1. Функциональная спецификация:

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

2. Эксплуатационная спецификация:

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

Спецификации пишутся с использованием специальных языков:

ü графических;

ü текстовых.

Графический язык – спецификация в виде графов (точки и стрелки) и диаграмм.

Текстовый язык – это псевдокод.

 

Проектирование систем.

Система (программная система) – совокупность связанных друг с другом программ и наборов данных.

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

 

Определение потоков данных.

Определение потоков данных производится согласно правилам:

1. Каждому источнику данных соответствует один входной поток;

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

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

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

 

Определение процессов.

Основные правила:

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

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

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

а) процесс для их запоминания;

б) процесс для сопровождения, если требуется корректировка;

в) процесс для поиска и обработки данных.

Примечание:

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

 

Методы разработки данных.

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

1. Графические диаграммы (граф-диаграммы)

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

Граф-диаграммы отображают прохождение потоков данных между процессами. Поэтому их ещё называют графами потоков данных (пример предыдущей темы – граф-диаграмма).

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

 

2. Диаграммы Варнье-Орра.

Здесь в иерархической структуре системы выделяются её основные элементарные составные части, которые отражают носители информации (схематичный рисунок). Сначала система делится на ряд отдельных процессов. Это 1-й уровень. На следующем уровне указываются потоки данных для каждого процесса. 3-й уровень: перечисляются наборы данных. 4-й уровень6 перечисляются соответствующие носители информации. Направление потоков данных отмечаются стрелками.

Исходные данные

Оперативный отчёт

Главный список

Главный список

Изменённые данные

Оперативный отчёт

Главный список

Отчёт

Исходные данные

Оперативный отчёт

Главный список

Главный список

Изменённые данные

Оперативный отчёт

Главный список

Отчёт

 

 

Система сопровождения данных:

 

Создание файла

вход

выход

Корректировка данных

вход

выход

Использование файла

вход

выход

 

Примечания к диаграмме:

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

 

 

3. Функциональные схемы.

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

Пример:

 

Новый главный файл

Программа корректировки

Старый главный файл

Коррекция файла

Отчёт о корректировке

 

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

 

Проектирование программ.

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

Преимущества модульности:

1. Упрощение разработки и реализации программ.

2. Облегчение чтения программ.

3. Упрощение настройки и модификации программ.

4. облегчение работы с данными, имеющие сложную структуру.

5. Возможность избежать чрезмерной детализации алгоритма.

6. Обеспечение более выгодного размещения программ в памяти ЭВМ.

 

Группы методов проектирования программ:

1. Методы нисходящего проектирования.

2. Методы расширения ядра.

3. Методы восходящего проектирования.

4. Методы объектно-ориентированного проектирования.

 

1. Метод нисходящего проектирования.

1-й шаг: формулируется предложение, описывающее функцию всей программы.

2-й шаг: определяются подфункции программы.

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

Пошаговое уточнение.

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

Пример:

1-й шаг:

Процедура! обработка_пакетов;

2-й шаг:

Процедура! обработка_пакетов;

сортировать записи по управляющим полям;

отделить правильные записи от неправильных

и обработать;

ВСЁ – Процедура!

 

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

Пример:

Процедура! обработка пакетов;

сортировать записи по управляющим полям;

взять первую запись;

Цикл – пока не конец входного файла;

Повторять

взять правую управляющую группу;

обработать группу записей;

ВСЁ – цикл;

обработать неправильные управляющие группы;

ВСЁ – Процедура!

 

Операцию сортировки надо написать и оформить в виде независимого модуля.

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

1. Заставляет сформулировать программу.

2. Разбить программу на проблемы.

Преимущества метода пошагового уточнения:

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

Недостаток метода:

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

 

Анализ.

Синтез.

Сопровождение.

Анализ.

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

Синтез.

Отвечают на вопрос каким образом система будет реализовывать предъявляемые к ней требования. Три этапа синтеза:

a) Проектирование;

b) Кодирование;

c) Тестирование.

 

Модель анализа: Ø Информационная; Ø Функциональная; Ø Поведенческая.

 

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

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

Процедурная разработка

Разработка архитектуры

Разработка данных

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

Процедурные модули

 

 

 

Проверенная и объединённая ПС

 

 

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

Функциональная модель выдаёт перечень функций обработки.

Поведенческая модель фиксирует режимы работы ПС.

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

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

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

На проектирование, кодирование и тестирование приходится более 75% стоимости конструирования ПС. Решение принимаемое в ходе проектирования делают его стержневым этапом процесса синтеза.

Структурирование систем.

 

Известны 4 модели системного структурирования:

I. Модель хранилища данных.

 

Редактор проекта

Генератор кода

Хранилище данных проекта

Редактор программы

Анализатор проекта

Проектный транслятор

 

 

В данной модели подсистемы разделяют данные находящиеся в общей памяти. Как правило данные образуют базы данных.Предусматривается система управления этой базой.

II. Модель клиент – сервер.

 

Клиент 1

Клиент 3

Клиент N

Клиент 2

Видео- -сервер

Сервер каталога

Сервер гипер-текстов

Сеть (Протокол взаимодействий TCP/IP)

 

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

 

 

Данная модель используется для распределения систем,где данные распределены по серверам.

III.

Графический интерфейс пользователя

Трёхуровневая модель. (Развитие модели клиент – сервер)

Бизнес - логика

Реляционная СУБД

Уровень графического интерфейса запускается на машине клиента.

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

Реляционная СУБД хранит данные необходимые уровню бизнес – логики. Этот уровень запускается на втором уровне - сервере базы данных(БД).

Преимущества трёхуровневой системы:

Ø Упрощается такая модификация уровня, которая не влияет на другие уровни;

Ø Отделение прикладных функций от функций управления БД;

 

Ø Упрощает оптимизацию всей системы.

IV. Модель абстрактной машины.

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

Управление версиями

Управление объектом

 

 

 

СУБД

 

ОС

 

Моделирование управления.

 

Известно два типа моделей управления:

Характеристики модуля.

1. Связность модуля – это мера независимости его частей.

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

 

Связность	Сила связности
1.функциональная
2.последовательная
3.коммуникативная
4.процедурная
5.временная
6.логическая
7.по совпадению

Функциональная связность.

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

Пример:

Проверить строку символов.

Выделить однотипные поля данных.

Оптимизировать группу команд.

 

2. Последовательная связность.

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

Пример:

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

 

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

 

3. Коммуникативная связность.

Части модуля связаны по данным (работают с одной же структурой данных).

Пример:

Сцепление модулей.

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

Типы сцепления:

1. Сцепление по данным СЦ=1 (сила сцепления)

А

В

элементы данных

А

В

элементы данных

Модуль А вызывает модуль В.

Все входные и выходные параметры вызываемого модуля – простые элементы данных.

 

2. Сцепление по образцу СЦ=3

А

В

структура данных

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

 

3. Сцепление по управлению. СЦ=4

флаг

флаг

выход

В

А

В

флаг

Модуль А явно управляет функциони-рованием модуля В (с помощью флагов или переключателей), посылая ему управ-ляющие данные.

 

 

4. Сцепление по внешним ссылкам. СЦ=5

Модули А и В ссылаются на один и тот же глобальный элемент данных.

 

5. Сцепление по общей области. СЦ=7

Модули разделяют одну и ту же глобальную структуру данных.

 

С

Е

Структура данных

N

 

 

6. Сцепление по содержанию. СЦ=9

Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом (Sin и Cos сдвинуты на 90°).

 

Программная документация.

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

Главный модуль

2.2.1

2.2

2.1

2.2.3

2.2.2

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

 

 

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

Внешняя спецификация модуля должна включать:

1. Имя модуля, используемое при обращении к нему.

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

3. Список параметров: число и порядок задания параметров.

4. Входные параметры: подробное описание и их атрибуты (структура, размер, единица измерения, допустимый диапазон назначений, типы и т.д.).

5. Выходные параметры (аналогично п.4).

6. Внешние эффекты.

Например: печать сообщений, чтение запроса с монитора, вывод сообщений об ошибке.

Внешние эффекты модуля включают все внешние эффекты подчинённых ему модулей.

 

Реализация программ.

Основные методы программирования:

1. Программирование на языках высокого уровня (ЯВУ).

2. Программирование с защитой от ошибок.

3. структурное программирование.

4. Программирование в стандартизированном стиле.

5. Нисходящее программирование.

 

 

1. Программирование на языках высокого уровня:

По сравнению с языками низкого уровня.

1. Чем выше уровень языка программирования, тем меньше ошибок в программе, легче понимать программу.

2. Выше степень автоматического обнаружения ошибок компилятором с этих языков.

3. Большая наглядность программы, что позволяет упростить документирование.

4. Программа на ЯВУ обладает высокой переносимостью.

5. Эти программы менее эффективны.

ВЫВОД:

Основные резервы эффективности программ лежат в области разумного выбора методов и алгоритмов.

 

2. Программирование с защитой от ошибок.

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

Виды проверок:

Ø допустимость значений числовых аргументов;

Ø проверка допустимости типов данных в выражении;

Ø проверка допустимости значений индексов массивов;

Ø допустимости значений управляющих переменных;

Ø проверка операций ввода-вывода с передачей данных.

ВЫВОД:

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

 

3. Структурное программирование.

Программы должны обладать свойствами:

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

2. Модуль представляет собой композицию основных управляющих структур (последовательность ветвления циклов).

3. Модули могут содержать операторы безусловного перехода только в исключительных случаях (go to), при этом передача управления происходит в точку программы, расположенную по тексту ниже самого оператора go to. Оператор go to допускается в том случае, когда в языке программирования отсутствуют операторы, реализующие структуры «если-то-иначе», цикл «пока» и цикл «до».

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

Примеры структурных языков программирования:

­ С++;

­ Pascal;

­ Basic.

Примеры не структурных языков:

­ Assembler;

­ Fortran.

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

 

4. Программирование в стандартизированном стиле.

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

Основные принципы стандартизации стиля программирования:

Комментарии оглавления.

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

Содержат:

­ перечни модулей;

­ краткое описание назначения и указания подчинённости модулей.

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

 

Пояснительные комментарии.

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

 

Правило выбора имён.

Имена должны обладать мневмотичностью, т.е. отражать сущность описываемых объектов. В связи с ограничениями на длину переменных при выборе имён сокращению подлежат не более 3-х первых слов. Абравиатура всегда включает начальные буквы слов. Согласные всегда важнее гласных. Начало слова всегда важнее его конца. Абравиатура включает 6–12 букв.

Тестирование элементов.

Цель: индивидуальная проверка каждого модуля. Используется стратегия белого ящика.

Тестирование интеграций.

Цель: тестирование сборки модулей в программную систему. Используется стратегия чёрного ящика.

Тестирование правильности.

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

Системное тестирование.

Цель: проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализацию всех системных функций.

 

Тестирование элементов.

Объект тестирования – наименьшая единица проектирования программной системы – модуль. Тестированию подвергаются:

ü интерфейс модуля;

ü внутренние структуры данных;

ü независимые пути;

ü пути обработки ошибок;

ü граничные условия.

 

Наиболее общие ошибки в вычислениях:

ü не правильный или не понятный приоритет арифметических операций;

ü смешанная форма операций;

ü некорректная инициализация;

ü несогласованность в представлении точности;

ü некорректное символическое представление выражения.

Источники ошибок сравнения и не правильных потоков управления.

1. Сравнение различных типов данных.

2. Некорректные логические операции и приоритетность.

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

4. Некорректное сравнение переменных.

5. Не правильное прекращение цикла.

6. Отказ в выходе при отклонении в итерации.

7. Не правильное изменение переменных цикла.

Тестирование интеграций.

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

Категории ошибок интерфейса:

­ потеря данных при прохождении через интерфейс;

­ отсутствие в модуле необходимой ссылки;

­ неблагоприятное влияние одного модуля на другой;

­ подфункции при объединении не образуют требуемую главную функцию;

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

­ проблемы при работе с глобальными структурами данных.

Существует 2 варианта тестирования, поддерживающих процесс интеграции:

Ø нисходящее;

Ø восходящее.

Тестирование правильности.

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

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

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

Базовые элементы конфигурации ПС:

1. Системная спецификация.

2. План программного проекта.

3. Спецификация требований к ПС.

4. Предварительное руководство пользователя.

5. Спецификация проектирования.

6. Листинги исходных тестов программ.

7. План и методика тестирования, тестовые варианты и полученные результаты.

8. Руководства по работе и инсталляции.

9. Exe-код выполняемой программы.

10. Описание базы данных.

11. Руководство пользователя по настройке.

12. Документы сопровождения, отчёты о проблемах ПС, запросы сопровождения, отчёты о конструкторских изменениях.

13. Стандарты и методики конструирования.

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