ОГЛАВЛЕНИЕ
1 Введение. Проблемы современного программирования. 8
2 Этапы разработки программного обеспечения. 10
2.1 Анализ требований, предъявляемых к системе. 11
2.2 Определение спецификаций. 12
2.3 Проектирование. 13
2.4 Кодирование. 15
2.5 Тестирование. 16
2.6 Эксплуатация и сопровождение. 19
Контрольные вопросы.. 21
3 Методы разработки программного обеспечения как научная дисциплина 23
3.1 Методы управления разработкой. 23
3.1.1 Выполнение проекта. 25
3.1.2 Методика оценки затрат. 27
3.1.3 Контрольные точки. 32
3.1.4 Средства разработки. 33
3.1.5 Надежность. 34
3.2 Методы проведения разработки программного обеспечения 34
3.3 Развитие методов разработки программного обеспечения. 37
3.3.1 Язык определения задач и анализатор задач. 38
3.3.2 Система структурного анализа и проектирования SADT 40
3.3.3 Система SREM.. 42
3.3.4 Методика Джексона. 42
3.4 Выводы.. 43
Контрольные вопросы.. 44
4 Методы разработки программного обеспечения. 46
4.1 Язык проектирования программ.. 46
4.2 Стратегия проектирования. 50
4.2.1 Нисходящее проектирование и нисходящая разработка 50
4.2.2 Структурное проектирование. 54
4.3 Данные. 59
4.3.1 Обзор структур данных. 59
4.3.2 Абстрактные конструкции. 65
Контрольные вопросы.. 78
5 Правильность программ.. 80
5.1 Аксиомы.. 80
5.2 Правила преобразования данных. 83
5.3 Доказательства правильности программ.. 83
Контрольные вопросы.. 86
6 Тестирование. 87
6.1 Психология и экономика тестирования программ.. 87
6.2 Экономика тестирования. 90
6.2.1 Тестирование программы как черного ящика. 90
6.2.2 Тестирование программы как белого ящика. 91
6.2.3 Принципы тестирования. 94
6.3 Ручное тестирование. 100
6.3.1 Инспекции и сквозные просмотры.. 101
6.3.2 Инспекции исходного текста. 103
6.3.3 Список вопросов для выявления ошибок при инспекции 106
6.3.4 Сквозные просмотры.. 119
6.3.5 Оценка посредством просмотра. 120
6.4 Проектирование теста. 122
6.4.1 Тестирование путем покрытия логики программы.. 123
6.4.2 Эквивалентное разбиение. 132
6.4.3 Анализ граничных значений. 139
6.4.4 Применение функциональных диаграмм.. 146
6.4.5 Предположение об ошибке. 166
6.4.6 Стратегия. 168
Контрольные вопросы.. 169
7 Технология разработки программ.. 170
7.1 Разбиение задачи на независимые подзадачи. 170
7.2 Разбиение задачи на одинаковые по сложности части. 170
7.3 Рекурсия и динамическое программирование. 171
7.3.1 Рекурсия. 171
7.3.2 Динамическое программирование. 172
7.3.3 Моделирование. 172
7.4 Поиск. 172
7.4.1 Поиск в списках. 173
7.4.2 Деревья поиска. 175
7.4.3 Стратегия распределения памяти. 178
7.5 Сортировка. 179
7.6 Алгоритм выбора из конечного состояния. 181
7.7 Сопрограммы.. 181
Контрольные вопросы.. 183
8 Методы управления проектированием программных изделий 184
8.1 Организация управления проектированием программного изделия 184
8.1.1 Понятие изделия как средства общения. 184
8.1.2 Нисходящий анализ процесса управления проектированием программного изделия 185
8.1.3 Организация взаимодействия. 186
8.1.4 Установление целей, средства их достижения. 187
8.1.5 Подбор и обучение кадров. 189
8.2 Организация планирования разработок программного изделия 190
8.2.1 Виды планов. 191
8.2.2 Декомпозиция планов. 194
8.2.3 Организационная структура группы планирования. 195
8.2.4 Планы, связанные с созданием программных изделий. 197
8.2.5 Опытный образец изделия. 200
8.2.6 Организация планирования в фазе исследования. 200
8.2.7 Организация планирования в стадии анализа осуществимости 203
8.2.8 Организация планирования в фазах конструирования и кодирования 203
8.2.9 Организация планирования в фазах оценки и использования 204
8.2.10 Обязанности группы планирования при рассмотрении и утверждении планов разработки программного изделия. 205
8.3 Организация разработки программного изделия. 208
8.3.1 Организация разработки программного изделия в фазе исследований 209
8.3.2 Организация разработки программного изделия в фазе анализа осуществимости 211
8.3.3 Организация разработки программного изделия в фазе конструирования (проектирования) 213
8.3.4 Организация разработки программного изделия в фазе программирования 214
8.3.5 Организация разработки программного изделия в фазе оценки 217
8.3.6 Окончание проекта. 219
8.3.7 Участие группы разработки в фазовых обзорах. 220
8.4 Организация обслуживания разработки программного изделия 222
8.4.1 Организационная структура группы обслуживания. 223
8.4.2 Организация обслуживания программного изделия в фазе исследования 223
8.4.3 Организация обслуживания в фазах анализа осуществимости и конструирования 224
8.4.4 Организация обслуживания в фазе программирования и оценки 226
8.4.5 Организация обслуживания в фазе использования. 228
8.4.6 Участие группы обслуживания в фазовых обзорах. 230
8.5 Организация выпуска документации. 231
8.5.1 Организационная структура группы выпуска документации 231
8.5.2 Стандарты и практические руководства. 233
8.5.3 Организация выпуска документации в фазах исследований и анализа осуществимости 235
8.5.4 Организация выпуска документации в фазах конструирования и программирования 236
8.5.5 Организация выпуска документации в фазах оценки и использования 238
8.5.6 Участие группы выпуска документации в фазовых обзорах 239
8.6 Организация испытаний программных изделий. 240
8.6.1 Современное состояние методов обеспечения качества программного изделия 241
8.6.2 Организационная структура группы испытаний. 246
8.6.3 Организация испытаний в фазах исследований и анализа осуществимости 249
8.6.4 Организация испытаний в фазах конструирования и программирования 250
8.6.5 Организация испытаний в фазе оценки. 251
8.6.6 Организация испытаний в фазе использования. 254
8.6.7 Участие группы испытаний в фазовых обзорах. 254
Контрольные вопросы.. 255
Список литературы.. 257
Введение. Проблемы современного программирования
Первый этап развития программирования в первую очередь был связан с накоплением опыта в приобретении технических (стандартных) навыков написания программ. Однако по мере развития средств вычислительной техники и накопления этих навыков существенно изменилось положение. Возникли естественные вопросы — продолжаем ли мы делать ошибки?; является ли сам процесс написания программ правильным?; не возникла ли необходимость в создании новых методов разработки программного обеспечения?
Ответом на эти вопросы и занимается научная дисциплина — методы (технология) разработки программного обеспечения. Круг вопросов, который рассматривает данная дисциплина, связан с классическими составляющими программирования:
- написанием спецификаций;
- проектированием;
- тестированием и
- функционированием программ.
Практическую значимость данной дисциплины можно проиллюстрировать путем сопоставления состояний дел по разработке технических систем и больших программных систем.
· В 1958 году в США приступили к строительству Веррацано-Нарроуского моста. По расчетам инженеров затраты на строительство определялись в размере 325 млн $, а работы планировалось завершить в 1965 году. Это самый большой подвесной мост в мире. Работы по нему завершились в ноябре 1964 года в соответствии с проектной сметой.
· Приблизительно в это же самое время производилась разработка операционной системы OS фирмы IBM. По планам разработчиков длительность разработки составляла 5000 человеко-лет. Но несмотря на все возможные принятые фирмой меры, завершилась на 4 года позже планируемого срока.
Возникает вопрос, почему в технических системах возможен достаточно точный прогноз, тогда как при разработке программных систем он оказывается несостоятельным?
Частично на этот вопрос можно ответить следующим образом — инженеру проще предусмотреть возрастающую сложность строительства, вызванную увеличением размеров моста, чем разработчику программного обеспечения определить сложность программы большого размера.
В настоящем курсе мы будем рассматривать методы и технические приемы, введение которых позволит уменьшить стоимость и повысить надежность программ.
В общем случае методы разработки программного обеспечения не есть программирование, хотя программирование составляет важную ее часть. Данный предмет также не сводится к проблеме изучения компиляторов и операционных систем, хотя они также играют существенную роль в рассматриваемой технологии. Точно так же проблемы электронной техники, структуры ЭВМ не являются предметом исследований, хотя и их знание в данном предмете необходимо.
Методы разработки программного обеспечения — это синтезированная дисциплина, в которой для составления алгоритмов используются математические методы, для оценки затрат и выбора компромиссных решений — методы инженерных расчетов, для определения требований к системе, учета ситуаций, связанных с потерями, организации работы исполнителей и прогнозирования — методы управления. Все это и будет предметом наших исследований.
Этапы разработки программного обеспечения
1) анализ требований, предъявляемых к системе;
2) определение спецификаций;
3) проектирование;
Анализ требований, предъявляемых к системе
Процесс выполнения работ и оформление результатов на этом этапе проработаны гораздо в меньшей степени, чем на других, и в общем случае не являются… Если предметом разработки является не программная система, а более сложный…
Определение спецификаций
Центральным вопросом определения спецификаций является проблема организации базы данных. При этом решается комплекс вопросов, имеющих отношение к… В случае, когда новая система создается на основе существующих, составной… Все эти вопросы должны быть отражены в функциональных спецификациях, которые представляют собой документ, являющийся…
Проектирование
- реализуемые функции;
- размеры;
- время выполнения и др.
Кодирование
Тестирование
В процессе тестирования используются данные, характерные для системы в рабочем состоянии, т.е. данные для тестирования выбираются случайным образом.… Тестирование подразумевает три стадии:
- автономное;
Эксплуатация и сопровождение
1) анализ требований;
2) определение спецификаций;
3) проектирование;
Контрольные вопросы
1. Этапы разработки программного обеспечения.
2. Анализ требований, предъявляемых к системе.
3. Жизненный цикл программного обеспечения.
4. Функциональные спецификации. Определение спецификаций.
5. Проектирование. Кодирование.
6. Тестирование: программное, системное, оценочное и сравнительное.
7. Сбой системы, выброс, ошибка. Испытания. Верификация системы.
8. Правильность и надежность программ.
9. Эксплуатация и сопровождение. Периоды обновления.
Методы разработки программного обеспечения как научная дисциплина
1) разработка методов управления сложными системами;
2) повышение надежности и правильности программного обеспечения;
3) развитие методов более точного прогнозирования затрат на создание программного обеспечения.
Методы управления разработкой
Обычно наибольшие трудности возникают при построении интерфейса между модулями, написанными различными программистами. Поскольку количество таких… Пример. Программист может написать в течение года программу, включающую 5000…
Выполнение проекта
- управляющие программы (например, операционные системы — ОС);
- системные программы (например, компиляторы);
- прикладные программы (обработка данных, счетная программа и др.).
Методика оценки затрат
Одним из важнейших аспектов процесса разработки программного обеспечения является оценка необходимых ресурсов или требуемых затрат.
Методика инженерно-технической оценки затрат
Шаг 1. Формируются общие требования к системе исходя из существующего технического задания. Потенциальных разработчиков информируют о том, что… Шаг 2. Собирается аналогичная информация, например данные о подобных… Шаг 3. Отбираются основные релевантные данные.
Оценка на основе распределения Рэлея
где E(t) — суммарные затраты к моменту времени t;
К — общая стоимость системы;
Контрольные точки
Существует большое количество «стандартных» контрольных точек:
- выпуск функциональных спецификаций;
- завершение проектирования отдельных модулей;
Средства разработки
Среди таких средств следует особо выделить системы управления базами данных (СУБД), которые помогают управлять организацией разрабатываемого… Одной из первых систем управления базой данных с возможностью ведения…
Надежность
Среди проектировщиков этот метод называется интеллектуальным программированием. Техническим документом, отражающим этот подход, является логическая… Аттестация системы должна осуществляться на всех стадиях разработки. Для… Существенным является то обстоятельство, что такой анализ не ставит целью оценку работы исполнителя.
Методы проведения разработки программного обеспечения
Верификация и испытания. Верификация и испытания занимают почти половину времени, отведенного на создание системы. Для уменьшения затрат, связанных… Дамп — это распечатка содержимого памяти. Однако поиск по дампу неэффективен,… Трассировка — это анализ значения данных переменных после каждого выполнения оператора. В общем случае трассировка…
Развитие методов разработки программного обеспечения
Кроме традиционных хорошо известных методов разработки (проектирования) программного обеспечения, в настоящее время все шире применяются методы, ориентированные на автоматизированную разработку.
Язык определения задач и анализатор задач
1) язык описания задач PSL, предназначенный для отображения функциональных требований и требований к ресурсам. Этот язык содержит набор средств… 2) анализатор определения задач PSA, представляющий собой процессор, с помощью… Язык PSL имеет простой синтаксис и ориентирован на использование ключевых слов. Основными операторами этого языка…
Система структурного анализа и проектирования SADT
Рис. 3.7 — Структура SADT (SA — формальный язык описания взаимосвязей между… Структура системы:
Система SREM
· Трансляция. Разрабатывается система требований, включающая описатели данных и этапы их обработки.
· Декомпозиция. Разрабатываются подробные проекты.
· Распределение. С помощью процессора REVS моделируются отдельные аспекты проектных решений с учетом принятых…
Методика Джексона
Элемент. Функция, которая не может быть разбита на более простые функции.
Последовательность. Ряд функций, реализуемых последовательно и однократно.
Выборка. Одна из возможных последовательностей.
Выводы
Проведенный обзор методов проектирования показал, что всем этим методам присущи общие черты. Хотя такие методы и способствуют получению рациональной структуры системы, тем не менее они не исключают необходимость в творческом процессе вырабатывания основополагающих на этапах анализа требований, определения спецификаций и проектирования. Благодаря использованию этих методов становится возможным уделять больше времени профессиональной стороне разработки программного обеспечения.
Существует ряд стратегий объединения различных методов в единую методологию. Наиболее эффективную стратегию создал Боэм, который сформулировал семь принципов разработки программного обеспечения:
1) управление разработкой на основе последовательной реализации отдельных этапов жизненного цикла программного обеспечения. Применение этого принципа позволяет на каждом этапе принимать обоснованные решения с учетом результатов, достигнутых на предыдущих этапах, и способствует использованию контрольных точек для оценки состояния разработки проекта;
2) выполнение испытаний. На каждом шаге совершенствования модуля осуществляется его аттестация;
3) осуществление строгого контроля над ходом разработки. Вся выходная документация — проекты программ, исходные программы, инструкции пользователю и т.д. — должна быть формально утверждена. Внесение любых изменений в документацию и библиотеки программ должно строго контролироваться и осуществляться лишь с разрешения соответствующих должностных лиц;
4) использование всего диапазона средств структурного программирования. По возможности желательно применять языки, позволяющие реализовать удобные структуры управления и данных. Для описания процессов желательно использовать технику пошагового совершенствования;
5) строгий учет. Для учета достигнутого прогресса в разработке системы необходимо использовать контрольные точки, а для проверки работы каждого исполнителя — системный журнал;
6) использование немногочисленного штата, укомплектованного квалифицированными работниками. Хорошие результаты работы дает использование принципа организации бригады главного программиста;
7) высокий уровень. Необходимо использовать имеющиеся достижения в области технологии и разработки программного обеспечения, не забывая при этом о надежности и возможности модификации программ.
Средства управления и контроля над разработкой программного обеспечения еще требуют совершенствования, однако сам процесс управления при этом приближается к уровню, свойственному другим техническим областям.
Контрольные вопросы
1. Методы разработки программного обеспечения как научная дисциплина.
2. Организация интерфейса между модулями, написанными разными программистами.
3. Выполнение проекта. Бригада главного программиста.
4. Методика оценки затрат. Методика инженерно-технической оценки затрат.
5. Методика экспертных оценок. Метод алгоритмического анализа. Пошаговый анализ. Закон Паркинсона.
6. Затраты на завершение разработки.
7. Оценка длительности разработки на основе распределения Рэлея.
8. Контрольные точки. Средства обработки. Надежность. Концептуальная целостность.
9. Верификация и испытания. Дамп. Трассировка. Анализ графов программ.
10. «Уровни правильности» программ.
11. Методы программирования. Эффективность программ.
12. Определение спецификаций. Язык определения задач и анализатор определения задач (PSL/PSA).
13. Система структурного проектирования SADT.
14. Структурное проектирование. Методика Джексона.
15. Стратегия объединения различных методов проектирования.
Методы разработки программного обеспечения
Проведенный ранее анализ показал, что в настоящее время методы разработки программного обеспечения интенсивно развиваются. Однако далеко не все методы находят широкое практическое применение. Цель наших дальнейших исследований — рассмотреть лишь те методы, которые считаются основными для разработки хороших программ.
Язык проектирования программ
Для создания такой системы записи был разработан язык проектирования программ PDL. Этот язык строится по образу универсальных языков… Язык проектирования обычно состоит из двух частей:
- заданного набора операторов, построенных по образцу языков программирования;
Стратегия проектирования
Нисходящее проектирование и нисходящая разработка
Рис. 4.2 — Пример базисной схемы
На приведенной базисной схеме каждый блок — это модуль системы. При этом вызов каждого модуля производится модулем…
Структурное проектирование
Вначале программист представляет задачу как набор задач:
do task A;
do task B;
Данные
Обзор структур данных
Основным атрибутом переменной является ее тип или множество значений, которые может принимать переменная. Кроме того, существует набор операторов,… Так как программы все более усложняются, требуются все более новые типы данных… Переменные, объявленные как элементарные типы данного языка, называются скалярными переменными, а переменные,…
Массивы
Массивы — это простейшие агрегативные данные в языках программирования. Массивом называется упорядоченный набор данных одного типа
declare A(10) FIXED BINARY;
Объявлен массив A из десяти двоичных переменных с фиксированной точкой с именами A(1), A(2), A(3),…, A(9), A(10). Аналогично
declare B(5:10) FIXED BINARY;
объявлен массив B из шести элементов с именами B(5), B(6), ..., B(10). Массивы могут быть как одномерными, так и многомерными.
Структуры
Самой сложной разновидностью данных в языках программирования являются структуры. Структурой называют поименованную совокупность различных типов данных.
declare 1 X,
2 Y FIXED BINARY,
2 Z BIT(12);
Объявляется структура с именем Х, состоящая из двоичной переменной с фиксированной точкой с именем X.Y и строки длиной 12 бит с именем X.Z.
Структуры могут использоваться для создания переменных нового типа.
Списки
Списком называют упорядоченный набор переменных одного типа. Список отличается от массива тем, что его размер обычно является переменной величиной, т.е. элементы могут добавляться в список и изыматься из него.
Список может быть объявлен как:
declare 1 LIST(N),
2 DATA_ENTRIES TYPE (некоторый тип данных),
SIZE; /* текущий размер списка */
Элементами списка являются DATA_ENTRIES(1), DATA_ENTRIES(2),... , DATA_ENTRIES(SIZE).
Если список может расти неограниченно, то такой способ описания не годится, поскольку SIZE может стать больше, чем N. Другой способ состоит в реализации совокупности базированных переменных.
declare 1 LIST BASED,
2 DATA_ENTRIES TYPE (некоторый тип данных);
2 FPTR POINTER /* указатель следующей записи
в списке */
LIST_HEAD POINTER; /* указатель первого
элемента в списке */
В первом случае элементами списка являются
LIST.DATA_ENTRIES(1),
LIST.DATA_ENTRIES(2),
LIST.DATA_ENTRIES(3),
...
LIST.DATA_ENTRIES(SIZE),
а во втором
LIST_HEAD ® DATA_ENTRIES
(LIST_HEAD ® FPTR) ® DATA_ENTRIES
((LIST_HEAD ® FPTR) ® FPTR) ® DATA_ENTRIES
...
Для работы со списками обычно используются следующие операторы (рис. 4.9, а):
1) ADD — поместить новый элемент в список;
2) DELETE — удалить элемент из списка;
3) SEARCH — проверить наличие элемента в списке.
Рис. 4.9 — Агрегативные структуры и соответствующие им операторы
Очереди
1) INSERT — добавить элемент в очередь;
2) DELETE — удалить элемент из очереди.
Стеки
Стек — это упорядоченный список, в один конец которого элементы добавляются и изымаются из этого же конца. Стек называют списком LIFO — Last In, Fist Out (поступивший последним обслуживается первым). Аналогично очереди, стек может быть организован любым из рассмотренных выше способов, однако использование массивов более эффективно. Для работы со стеком обычно используются три операции (рис. 4.9, в).
1) PUSH — поместить элемент в стек;
2) POP — извлечь элемент из стека;
3) EMPTY — функция, принимающая значение ИСТИННО, если стек не заполнен.
Множества
Множества обрабатываются с использованием следующих операторов (рис. 4.9, г):
1) INSERT — добавить новый элемент во множество;
2) DELETE — удалить элемент из множества;
Графы
Направленный граф — это структура, состоящая из узлов и дуг, причем каждая дуга направлена от одного узла к другому. Графы обычно организовываются с помощью базированных переменных, где дуги являются переменными типа указатель. Если из каждого узла выходит несколько дуг, то граф можно описать следующим образом:
declare 1 GRAPH BASED,
2 DATA_ENTPIES TYPE (некоторый тип данных),
2 EDGES(N) POINTER;
Для ненаправленных графов дугам соответствуют два направления — вперед и назад:
declare 1 GRAPH BASED,
2 DATA_ENTPIES TYPE (некоторый тип данных),
2 FORWARD_EDGES(N) POINTER,
2 BACKWARD_EDGES(N) POINTER;
Операторы для работы с графами представлены на рис. 4.9, д.
Деревья
Дерево — это направленный граф, обладающий следующими свойствами:
1) только один узел не имеет дуг, входящих в него (корневой узел);
2) в каждый узел входит не более одной дуги;
3) в каждый узел можно попасть из корневого узла за несколько шагов.
Абстрактные конструкции
Однако структуры данных за это время изменились в значительной степени. Ранее назначение данных состояло в представлении чисел в системе исчисления,… В более развитых языках, кроме числовых данных, включались данные, состоящие… Поскольку структуры данных становятся все более сложными, это сильно затрудняет процесс тестирования и сопровождение…
Фиксированные типы данных абстрактного типа
Например, для того чтобы задать стек, программист должен добавить следующее объявление в каждую процедуру, которая содержит обращение к стеку.
declare 1 STACK,
2 ENTRIES(100) TYPE(INTEGER),
Размещение указателей
declare STACK POINTER;
call STACK_INITIALIZATION(STACK);
В этом случае процедура STACK_INITIALIZATION должна быть вызвана явным образом для того, чтобы разместить стек в…
Защита данных от несанкционированного доступа
declare X ENVIRONMENT(STACK);
Для пользователя Х — это стек, к которому можно обращаться из процедуры STACK… 1) обработка стека Х происходит в процедуре FUNCTION в модуле с именем STACK;
Контрольные вопросы
1. Язык проектирования программ PDL. Операторы выбора. Операторы цикла. Операторы описания данных. Операторы ввода/вывода и вызова процедур. Оператор leave. Предложения на естественном языке.
2. Нисходящее проектирование и нисходящая разработка.
3. Пошаговое совершенствование.
4. Восходящее проектирование.
5. Подыгрывающие программы (заглушки).
6. Структурное проектирование. Простая программа. Элементарная программа. Управляющие структуры, способы их описания.
7. Скалярные и агрегативные типы данных.
8. Массивы. Структуры. Списки. Очереди. Стеки. Множества. Графы. Деревья.
9. Абстрактные конструкции.
10. Фиксированные данные абстрактного типа.
11. Размещение указателей.
12. Защита данных от несанкционированного доступа.
Правильность программ
«Если P истинно и если выполняется оператор S, то Q истинно».
Предикат P является спецификацией правильного выполнения оператора S, а… Если это утверждение распространить на все операторы программы и если P является спецификацией первого оператора, а Q…
Аксиомы
1) если {P}S{Q} и Q Þ R, то {P}S{R};
2) если {Q}S{R} и P Þ Q, то {P}S{R}.
Первое правило заключается в следующем: «Если P — предусловие для Q и если Q Þ R является теоремой исчисления…
Правила преобразования данных
Коммутативность:
Ассоциативность:
Дистрибутивность:
Вычитание:
Обработка констант:
Доказательства правильности программ
1. MULTIPLY (R,A,B);
2. declare X;
3. declare R; /* R=A*B */
Контрольные вопросы
1. Правильность программ.
2. Правила следствия.
3. Аксиома присвоения.
4. Аксиома следования.
5. Аксиома цикла.
6. Аксиома выбора.
7. Правила целочисленной арифметики — коммутативность, ассоциативность, дистрибутивность, вычитание, обработка констант.
8. Доказательство правильности программ.
Тестирование
Психология и экономика тестирования программ
Поначалу может показаться тривиальным жизненно важный вопрос определения термина «тестирование». Необходимость обсуждения этого термина связана с… Эти определения описывают нечто противоположное тому, что следует понимать под… Тестирование — это процесс исполнения программы с целью обнаружения ошибок.
Экономика тестирования
Дав такое определение тестированию, необходимо на следующем шаге рассмотреть возможность создания теста, обнаруживающего все ошибки программы. Покажем, что ответ будет отрицательным даже для самых тривиальных программ. В общем случае, невозможно обнаружить все ошибки программы. А это, в свою очередь, порождает экономические проблемы, задачи, связанные с функциями человека в процессе отладки, способы построения тестов.
Тестирование программы как черного ящика
При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если… Если такое испытание представляется сложным, то еще сложнее создать… Из изложенного следует, что построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами:…
Тестирование программы как белого ящика
Сравним способ построения тестов при данной стратегии с исчерпывающим входным тестированием стратегии черного ящика. Непосвященному может… Последнее утверждение имеет два слабых пункта. Один из них состоит в том, что…
Принципы тестирования
Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора.
Нарушение этого очевидного принципа представляет одну из наиболее… Необходимость этого подчеркивал логик Копи: «Проблема может быть охарактеризована как факт или группа фактов, которые…
Ручное тестирование
По этой причине, прежде чем перейти к обсуждению традиционных методов тестирования, основанных на применении ЭВМ, рассмотрим процесс тестирования… Следует заметить, что из-за неформальной природы методов ручного тестирования…
Инспекции и сквозные просмотры
Инспекции и сквозные просмотры включают в себя чтение или визуальную проверку программы группой лиц. Эти методы развиты из идей Вейнберга. Оба… Инспекции и сквозные просмотры широко практикуются в настоящее время, но… Эксперименты по применению этих методов показали, что с их помощью для типичных программ можно находить от 30 до 70 %…
Инспекции исходного текста
Инспектирующая группа включает обычно четыре человека, один из которых выполняет функции председателя. Председатель должен быть компетентным… Общая процедура заключается в следующем. Председатель заранее (например, за… 1. Программиста просят рассказать о логике работы программы. Во время беседы возникают вопросы, преследующие цель…
Список вопросов для выявления ошибок при инспекции
Ошибки обращения к данным
2. Не выходит ли значение каждого из индексов за границы, определенные для соответствующего измерения при всех обращениях к массиву?
3. Принимает ли каждый индекс целые значения при всех обращениях к массиву?… 4. Для всех обращений с помощью указателей или переменных-ссылок память, к которой производится обращение, уже…
Ошибки описания данных
2. Если не все атрибуты переменной явно присутствуют в описании, то понятно ли их отсутствие? Например, отсутствие атрибутов, считающееся… 3. Если начальные значения присваиваются переменным в операторах описания, то… 4. Правильно ли для каждой переменной определены длина, тип и класс памяти (например, STATIC, AUTOMATIC, BASED или…
Ошибки вычислений
2. Существуют ли вычисления, использующие данные разного вида? Например, сложение переменной с плавающей точкой и целой переменной. Такие случаи не… DECLARE A BIT(1);
A=1;
Ошибки при сравнениях
2. Сравниваются ли величины различных типов или величины различной длины? Если да, то проверьте, правильно ли интерпретируются (поняты) правила… 3. Корректны ли операторы сравнения? Программисты часто путают такие… 4. Каждое ли булевское выражение сформулировано так, как это предполагалось? Программисты часто делают ошибки при…
Ошибки в передачах управления
2. Будет ли каждый цикл, в конце концов, завершен? Придумайте неформальное доказательство или аргументы, подтверждающие их завершение.
3. Будут ли программа, модуль или подпрограмма, в конечном счете, завершены?
… 4. Возможно ли, что из-за входных условий цикл никогда не сможет выполняться? Если это так, то является ли это…
Ошибки интерфейса
2. Совпадают ли атрибуты (например, тип и размер) каждого параметра с атрибутами соответствующего ему аргумента?
3. Совпадают ли единицы измерения каждого параметра с единицами измерения… 4. Равно ли число аргументов, передаваемых из рассматриваемого модуля другому модулю, числу параметров, ожидаемых в…
Ошибки ввода-вывода
2. Являются ли правильными атрибуты оператора OPEN?
3. Согласуется ли спецификация формата с информацией в операторах…
Другие виды контроля
2. Если компилятор выдает список атрибутов, проверьте атрибуты каждой величины для обеспечения гарантии того, что в программе нет никаких… 3. Если программа оттранслирована успешно, но компилятор выдает одно или… 4. Является ли программа (или модуль) достаточно устойчивой? Иными словами, проверяет ли она правильность своих…
Сквозные просмотры
Подобно инспекции, сквозной просмотр проводится как непрерывное заседание, продолжающееся один или два часа. Группа по выполнению сквозного… 1) высококвалифицированный программист;
2) эксперт по языку программирования;
Оценка посредством просмотра
Оценка посредством просмотра является методом оценки анонимной программы в терминах ее общего качества, ремонтопригодности, расширяемости, простоты… Отобранные программы случайным образом «распределяются между участниками. Им… · Легко ли было понять программу?
Проектирование теста
Если ввести ограничения на время, стоимость, машинное время и т.п., то ключевым вопросом тестирования становится следующий:
Какое подмножество всех возможных тестов имеет наивысшую вероятность… Изучение методологий проектирования тестов дает ответ на этот вопрос.
Тестирование путем покрытия логики программы
Тестирование по принципу белого ящика характеризуется степенью, в какой тесты выполняют или покрывают логику (исходный текст) программы. Как показано в п. 6.2, исчерпывающее тестирование по принципу белого ящика предполагает выполнение каждого пути в программе; но поскольку в программе с циклами выполнение каждого пути обычно нереализуемо, то тестирование всех путей не рассматривается как перспективное.
Покрытие операторов
Если отказаться полностью от тестирования всех путей, то можно показать, что критерием покрытия является выполнение каждого оператора программы, по крайней мере, один раз. К сожалению, это слабый критерий, так как выполнение каждого оператора, по крайней мере, один раз есть необходимое, но недостаточное условие для приемлемого тестирования по принципу белого ящика (рис. 6.5).
Рис. 6.5 — Алгоритм тестируемой программы
Предположим, что на рис. 6.5 представлена небольшая программа, которая должна быть протестирована. Эквивалентная программа, написанная на языке PL/1, имеет вид:
М: PROCEDURE (A,В,Х);
IF ((А>1) & (В=0)) THEN DO;
Х=Х/А;
END;
IF ((A=2) | (Х>1)) THEN DO;
Х=Х+1;
END;
END;
Можно выполнить каждый оператор, записав один-единственный тест, который реализовал бы путь асе. Иными словами, если бы в точке a были установлены значения A = 2, B = 0 и X = 3, каждый оператор выполнялся бы один раз (в действительности X может принимать любое значение).
К сожалению, этот критерий хуже, чем он кажется на первый взгляд. Например, пусть первое решение записано как или, а не как и. При тестировании по данному критерию эта ошибка не будет обнаружена. Пусть второе решение записано в программе как X > 0; эта ошибка также не будет обнаружена. Кроме того, существует путь, в котором Х не изменяется (путь abd). Если здесь ошибка, то и она не будет обнаружена. Таким образом, критерий покрытия операторов является настолько слабым, что его обычно не используют.
Покрытие решений
Согласно данному критерию должно быть записано достаточное число тестов, такое, что каждое решение на этих тестах примет значение истина и ложь, по… Можно показать, что покрытие решений обычно удовлетворяет критерию покрытия… Изложенное выше предполагает только двузначные решения или переходы и должно быть модифицировано для программ,…
Покрытие условий
DO К=0 ТО 50 WHILE (J+K<QUEST);
или его аналог на языке Си
for(K=0; K<=50 && J+K<QUEST; K++)
Комбинаторное покрытие условий
NOTFOUND = ’1’ В;
/* поиск в таблице */
DO I=1 ТО TABSIZE WHILE (NOTFOUND);
Эквивалентное разбиение
Правильно выбранный тест этого подмножества должен обладать двумя свойствами:
а) уменьшать, причем более чем на единицу, число других тестов, которые должны… б) покрывать значительную часть других возможных тестов, что в некоторой степени свидетельствует о наличии или…
Выделение классов эквивалентности
Входные условия
Правильные классы эквивалентности
Неправильные классы эквивалентности
… Рис. 6.7 — Форма таблицы для перечисления классов эквивалентности
Заметим, что различают два типа классов эквивалентности: правильные классы эквивалентности, представляющие правильные…
Построение тестов
1. Назначение каждому классу эквивалентности уникального номера.
2. Проектирование новых тестов, каждый из которых покрывает как можно большее… 3. Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности,…
Анализ граничных значений
1. Выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных значений осуществляется таким образом, чтобы… 2. При разработке тестов рассматривают не только входные условия (пространство… Трудно описать «кухню» анализа граничных значений, так как это требует определенной степени творчества и специализации…
Применение функциональных диаграмм
Тестирование комбинаций входных условий — непростая задача, поскольку даже при построенном эквивалентном разбиении входных условий число комбинаций… Метод функциональных диаграмм или диаграмм причинно-следственных связей… Функциональная диаграмма представляет собой формальный язык, на который транслируется спецификация, написанная на…
Предположение об ошибке
Объясняется это тем, что человек, обладающий практическим опытом, часто подсознательно применяет метод проектирования тестов, называемый… Процедуру для метода предположения об ошибке описать трудно, так как он в… Поскольку данная процедура не может быть четко определена, лучшим способом обсуждения смысла предположения об ошибке…
Стратегия
1. Если спецификация содержит комбинации входных условий, то начать рекомендуется с применения метода функциональных диаграмм.
2. В любом случае необходимо использовать анализ граничных значений. Напомним,… 3. Определить правильные и неправильные классы эквивалентности для входных и выходных данных и дополнить, если это…
Контрольные вопросы
1. Определение процесса тестирования. Определение хорошего теста. Определение хорошего прогона.
2. Тестирование программы как черного и белого ящика.
3. Принципы тестирования.
4. Технологии ручного тестирования. Инспекции исходного текста. Сквозные просмотры. Метод оценки программ посредством просмотра.
5. Принципы проектирования теста.
6. Технологии тестирования по принципу белого ящика. Покрытие операторов. Покрытие решений. Покрытие условий. Покрытие решений/условий. Комбинаторное покрытие условий.
7. Технологии тестирования по принципу черного ящика.
8. Эквивалентное разбиение. Способы формирования классов эквивалентности. Правила создания тестов по классам эквивалентности.
9. Анализ граничных значений.
10. Применение функциональных диаграмм. Способы задания ограничений на вход и выход. Технология построения функциональных диаграмм. Технология построения таблицы решений. Формирование тестов по таблице решений.
11. Предположение об ошибке.
12. Стратегия тестирования.
Технология разработки программ
Хотя разработка программ является в основном творческой деятельностью, существует множество стандартных алгоритмов, которые могут применяться для упрощения данного процесса. Знание этих алгоритмов часто облегчает формулирование задачи.
Разбиение задачи на независимые подзадачи
Основным алгоритмом, используемым для решения задач, является алгоритм разбиения на независимые подзадачи. Для того, чтобы решить задачу A, ее первоначально необходимо разбить на независимые подзадачи B, C, D и т.д.
A: procedure;
Задача B;
Задача C;
Задача D;
end A;
Решение подзадач может производиться по любому алгоритму.
Разбиение задачи на одинаковые по сложности части
- проверить первый элемент;
- if заданный элемент не найден, then продолжить поиск среди оставшихся… Таким образом, задача разбивается на две части: проверку первого элемента и поиск среди оставшихся. Ясно, что такие…
Рекурсия и динамическое программирование
Рекурсия
Примером рекурсивного решения является вычисление факториала fact(N) = 1×2×…×N. Пусть неизвестно значение fact(460), если умножить… 1) F(N) = G(N, F(N – 1)) для некоторой известной функции G и
2) F(1) равно некоторому известному значению.
Динамическое программирование
Динамическое программирование — это табличный метод, при котором используется одна и та же схема вычисления всех подзадач данной задачи. При использовании этого метода однажды найденный результат записывается в таблицу и далее повторно не вычисляется.
Моделирование
Поиск
Поиск — это процесс нахождения нужных значений в некотором множестве. Семейство элементов может быть структурированным либо нет. Если оно не структурировано, поиск обычно означает нахождение нужного элемента в списке. Если семейство элементов структурировано (дерево, граф и др.), то под поиском понимают нахождение правильного пути в структуре.
Обычно каждый элемент имеет три компонента:
- ключ — это элемент, используемый для доступа к данным (он может быть именем в справочнике, словом в индексе или названием раздела в таблице);
- аргумент — это числа, связанные с элементом (адрес, номер телефона и др.);
- структуру — это дополнительная информация, принимаемая для описания данных, такая, как адрес следующего элемента в семействе и т.п.
Поиск в списках
Прямой поиск. При прямом поиске местоположение элемента определяется непосредственно с помощью ключа (комната в здании). Прямой поиск применяется… Линейный поиск. Данный вид поиска наиболее простой для программной реализации,… Двоичный поиск. Для ведения двоичного поиска ключи должны быть упорядочены по величине или алфавиту. В этом случае…
Деревья поиска
Поиск в глубину. При поиске в глубину каждая ветвь дерева просматривается слева направо.
Для двоичных деревьев алгоритм поиска имеет простую рекурсивную структуру…
Стратегия распределения памяти
Дана фиксированная область памяти, задача заключается в том, чтобы занимать и освобождать меньшие области памяти большой областью, без выхода за… Первое возможное размещение. Последовательно просматриваются области памяти,…
Сортировка
Обменная сортировка. При этом способе наименьший элемент выдвигается в начало списка, следующий по величине — на вторую позицию и т.д. Для списка N… Алгоритм:
EXCHANGE_SORT procedure(LIST,N);
Алгоритм выбора из конечного состояния
Переменными в этом случае являются текущее состояние программы и допустимое воздействие, определяемое внешней средой. Пересечение этих значений в… Таблица состояний:
A
B
C
…
I
J
K
…
Y
Z
…
Сопрограммы
Рис. 7.4 — Организация сопрограмм
Использование сопрограмм может быть полезной управляющей структурой.
Контрольные вопросы
1. Стандартные методы проектирования.
2. Разбиение задачи на независимые подзадачи.
3. Разбиение задачи на одинаковые по сложности части.
4. Рекурсия.
5. Динамическое программирование.
6. Моделирование.
7. Поиск. Поиск в списках. Прямой поиск. Линейный поиск.
8. Поиск с возвратом.
9. Стратегия распределения памяти.
10. Алгоритм выбора из конечного состояния.
11. Сопрограммы.
Методы управления проектированием программных изделий
Основная цель управления — организовать и связать взаимодействие исполнителей при создании программного продукта.
Организация управления проектированием программного изделия
Понятие изделия как средства общения
Изделие
Программа
1. Изучение рынка
1. Изучение рынка
2. Планирование
2. …
То есть самые общие действия при создании изделия имеют аналоги при создании программного продукта, таким образом,…
Нисходящий анализ процесса управления проектированием программного изделия
- планирование;
- разработку;
- обслуживание;
Организация взаимодействия
Важнейшим принципом любого вида управления является разделение целого на части, и многие методы и средства основываются именно на этом принципе.
Совокупность точек, в которых две функциональные группы взаимодействуют друг с… Но ни сами документы, ни их коллективное обсуждение не могут обеспечить действенных взаимосвязей, если отсутствуют…
Установление целей, средства их достижения
Основным методическим принципом управления разработкой является целевое управление.
Целевое управление представляет собой концепцию планирования и управления, с… Цели присутствуют в планах самого различного уровня: целевых планах, бюджете, планах выпуска изделий, документации и…
Подбор и обучение кадров
Руководство проектами надо поручать лишь тем специалистам, которые обладают подобным опытом. Здесь очень хорошо работает концепция бригады главного… Но ведь люди где-то должны начинать работать? Так как в настоящее время… С наибольшей вероятностью квалифицированный персонал можно найти среди поставщиков универсального программного…
Организация планирования разработок программного изделия
Программное изделие — это собственно программа плюс документация, гарантия качества, рекламные материалы, обучение, распространение и сопровождение.…
Виды планов
Рис. 8.2 — Иерархия планов
Декомпозиция планов
- план создания семейства программных изделий;
- план создания серии;
- план создания совокупности изделий;
Организационная структура группы планирования
Должностные лица, руководящие выполнением планов, называются администраторами планирования. Однако надо помнить, что слишком большое число людей в… Рис. 8.4 — Схема взаимодействия группы планирования и… В большинстве организаций роль администратора планирования выполняет руководитель целевой программы.
Планы, связанные с созданием программных изделий
Программное изделие — совокупность отдельных программных средств, их документации, гарантии качества (ISO 9000), рекламных материалов, мер по… Совокупность изделий — это группа изделий, имеющих одну или несколько общих… Серия изделий — это сочетание аппаратных и программных средств, которые имеют одну и более общих связей и…
Опытный образец изделия
Опытный образец — это почти законченное изделие. Он включает в себя все компоненты завершенного изделия, в том числе и черновой вариант технической… При создании опытного образца необходимо следовать той же методике управления,… Для принятия решения о том, какую документацию и какой контроль следует предусмотреть для опытного образца, обычно…
Организация планирования в фазе исследования
Рис. 8.5 — Жизненный цикл программного изделия
Деятельность группы планирования наиболее активна в фазе до начала анализа осуществимости, как только подтверждается…
Организация планирования в стадии анализа осуществимости
В конфигураторе перечисляются программные изделия, которые должны функционировать совместно с проектируемым изделием, т.е., во-первых, необходимые… План выпуска изделия имеет то же значение, что и конфигуратор, но охватывает… Конфигуратор и план выпуска необходимо периодически обновлять. Последней задачей, выполняемой группой планирования в…
Организация планирования в фазах конструирования и кодирования
Организация планирования в фазах оценки и использования
Обычно группа поддержки настаивает на возможно более раннем выпуске изделия, чтобы своевременно закончить операции по сбыту или сохранить того или… Группа планирования осуществляет текущий контроль за изделием в фазе…
Обязанности группы планирования при рассмотрении и утверждении планов разработки программного изделия
Сначала определяются фазы и основные события в конце каждой из них. Затем проводится формальный обзор на основе, по крайней мере, одного документа… Таблица 8.2 — Документы обзоров
… IV. Программирование
Организация разработки программного изделия
Администратор проекта (руководитель) занят одним-единственным проектом, каждая функция которого охватывает несколько индивидуальных разработок.
… Администратор изделия регулирует степень участия каждой функциональной группы…
Организация разработки программного изделия в фазе исследований
Для правильного принятия решения на основе результатов фазы I оценивается не только стоимость, но и календарные сроки проектирования. Поэтому один… Если на основании фазового обзора I руководство разрешает начать анализ… Соглашение о требованиях — это договор между руководителем проекта и заказчиком, который также включает субподряды,…
Организация разработки программного изделия в фазе анализа осуществимости
Полученные в ходе фазового обзора II предложения относительно внесения изменений в соглашение о требованиях дают возможность оценить недостатки…
Рис. 8.7 — Границы изменяемости проекта:
Организация разработки программного изделия в фазе конструирования (проектирования)
Для того чтобы провести границу между внутренним и внешним проектом, схему декомпозиции упорядочивают. Схема декомпозиции называется хорошо… С учетом четкого различия между внешним и внутренним проектом, следует… После того, как внешние спецификации приобретают сравнительно стабильный характер, в рамках функции разработки…
Организация разработки программного изделия в фазе программирования
Кодирование начинается на ранней стадии программирования. При этом используется так называемый «волновой эффект» (табл. 8.3), когда составление… Таблица 8.3 — Волновой эффект в разработке модулей изделия
…
Организация разработки программного изделия в фазе оценки
Проводя испытания класса A, группа разработки прогоняет как можно больше контрольных примеров, предложенных группой испытаний. Это ускоряет… Приемочные испытания основываются на наборе тестов, выбранных из общей… Испытания класса B представляют собой независимую проверку программного изделия на соответствие спецификациям.…
Окончание проекта
· опыт преодоления наибольших трудностей, встретившихся при разработке проекта;
· рекомендации по разработке последующих проектов (включая различные… · сводку плановых и фактических сроков выполнения этапов (включая все случаи изменения запланированных сроков);
Участие группы разработки в фазовых обзорах
В фазовом обзоре II в центре внимания находится соглашение о требованиях.
Таблица 8.4 — Участие группы разработки в фазовых обзорах
Фаза
…
Организация обслуживания разработки программного изделия
· производственные операции — приобретение, эксплуатация и обслуживание вычислительного оборудования и программных средств;
· распространение — регистрация и рассылка программных средств;
· системное обеспечение — введение и слежение за соблюдением стандартов, процедур и форматов;
Организационная структура группы обслуживания
Основной ошибкой в деятельности группы обслуживания является «локальная оптимизация» при потере целей глобальной оптимизации (одна ЭВМ вместо двух…
Организация обслуживания программного изделия в фазе исследования
После утверждения первоначального распределения бюджета группа обслуживания вместе с руководителем проекта планирует потребность в машинных… Конфигурационное управление также начинается после утверждения бюджета.…
Организация обслуживания в фазах анализа осуществимости и конструирования
Группа обслуживания обычно имеет в своем распоряжении вычислительный центр или исследовательскую лабораторию, располагающую соответственным… Соглашение о требованиях определяет характер испытаний класса C и необходимую… К этому времени следует принять решение относительно защиты прав собственности на программное изделие. Оно может быть…
Организация обслуживания в фазе программирования и оценки
Другая задача группы обслуживания в фазе программирования состоит в изучении спецификаций испытаний и подготовке необходимого… По мере перехода от фазы программирования к фазе оценки нагрузка на группу… Вскоре после начала испытаний класса B группа обслуживания начинает готовиться к распространению изделия. Основной…
Организация обслуживания в фазе использования
Использование программного изделия продолжается до тех пор, пока оно отвечает интересам производителя программных средств, и в то же время… Все замечания пользователей по дефектам продукта поступают в группу… - заявки на исправление ошибок;
Участие группы обслуживания в фазовых обзорах
Таблица 8.5 — Участие группы обслуживания в фазовых обзорах
Фаза
Фазовый обзор
Форма участия при обсуждении документов
…
В фазовом обзоре II группа обслуживания ведет переговоры о приобретении оборудования и других материалов для…
Организация выпуска документации
Рекламные материалы предназначены преимущественно для административного персонала, в то время как справочные материалы используются операторами,…
Организационная структура группы выпуска документации
Редакторы могут быть прикреплены к конкретному проекту и иметь различные служебные полномочия как в рамках функции выпуска документации, так и по… Производственные бригады должны находиться целиком в подчинении группы выпуска… Для осуществления деятельности группы выпуска документации важное значение имеет установление и соблюдение…
Стандарты и практические руководства
Одним из важнейших стандартов является руководство по стилю. В нем устанавливаются виды документации и даются основные рекомендации по оформлению:… · Техническое описание системы. Это введение, излагающее основные концепции… · Справочное руководство. В нем подробно описаны все внешние характеристики программного изделия. Оно обеспечивает…
Организация выпуска документации в фазах исследований и анализа осуществимости
В фазовом обзоре I начинается рассмотрение извещения о календарных сроках. На этом этапе необязательно готовить подробный план выпуска документации.… В утвержденном соглашении о требованиях указывается, какие виды документации… Если группа выпуска документации не планирует издание каких-либо документов, отличающихся от стандартных, то…
Организация выпуска документации в фазах конструирования и программирования
В фазе конструирования группа разработки передает внешние спецификации на рассмотрение другим группам. Группа выпуска документации убеждается в том,… Если для программного продукта предусмотрен выпуск справочного материала в… Максимальная нагрузка группы выпуска документации наступает в фазе программирования. Группа изучает план группы…
Организация выпуска документации в фазах оценки и использования
В фазе оценки группа обслуживания подготавливает руководство по вводу программного изделия в действие — информационный листок выпуска. Этот листок… Группа выпуска документации привлекается к обсуждению решения о выпуске… После того, как изделие вступило в фазу использования, сопровождение документации осуществляется по той же схеме, что…
Участие группы выпуска документации в фазовых обзорах
В ходе фазового обзора II группа пересматривает свои исходные позиции в отношении соглашения о требованиях, руководствуясь окончательным бюджетом, и… Таблица 8.6 — Участие группы выпуска документации в фазовых обзорах
… До фазового обзора III группа участвует в работе над внешней спецификацией. Ко времени фазового обзора III она должна…
Организация испытаний программных изделий
Современное состояние методов обеспечения качества программного изделия
- проведение испытаний;
- выработка оценок;
- участие в фазовых обзорах с целью влияния на ход разработок.
Виды испытаний программного изделия. Стадии испытаний
К первой стадии относятся испытания класса A, которые проводятся в конце фазы программирования после того, как будут отлажены и включены в систему… Ко второй стадии относятся испытания класса B, когда осуществляется… Испытания класса C осуществляются после того, как группа испытаний рекомендует выпуск изделия и его распространение.…
Режимы испытаний программ
Режим I подразумевает полный цикл деятельности группы испытаний, включая планирование испытаний, разработку тестов, их прогон и анализ результатов.… Режим II позволяет проводить ускоренные испытания изделия, поскольку в этом… Режим III реализуется без участия группы испытаний. Этот режим используется лишь в случаях крайней необходимости,…
Категории испытания программного изделия
· Демонстрация в действии. Во время демонстрации прогоняют специально подобранные тесты, обеспечивающие желаемый результат. Тесты обычно подбираются… · Аттестация. Аттестация призвана гарантировать способность данного… · Полная функциональная проверка. Цель этой категории испытаний — показать, что изделие обладает всеми функциональными…
Организационная структура группы испытаний
Организуя испытания программного изделия, необходимо иметь четкий ответ на вопрос: «где кончается процесс оценки и начинается процесс отладки…
Рис. 8.9 — Организация взаимосвязи при проведении испытаний
Организация испытаний в фазах исследований и анализа осуществимости
На этой стадии составляется предварительный бюджет, обычно этот документ составляет кто-либо из сотрудников группы разработки на основании данных,… В стадии анализа осуществимости группа обработки готовит соглашение о… Соглашения о требованиях являются одновременно и планом разработки, они содержат довольно много сведений о путях…
Организация испытаний в фазах конструирования и программирования
При составлении плана испытаний используется принцип декомпозиции планов. План испытаний является детализацией соглашения о требованиях и содержит… Фаза программирования начинается с момента появления внешней спецификации.… После завершения работ над внешней спецификацией группа испытаний начинает готовить спецификацию испытаний.…
Организация испытаний в фазе оценки
Если испытания класса B начались, то прогону подлежат все контрольные примеры, сначала в логически обоснованном порядке, а затем в любом… После первой передачи изделия испытателям редко удается с успехом выполнить… Обнаруживая тот или иной дефект, испытатели доказывают факт его наличия с помощью различных материалов (консольных…
Организация испытаний в фазе использования
Ввод в действие и эксплуатация изделия пользователями позволяют выявить новые дефекты. По мере поступления сообщений о выявленных дефектах группа…
Участие группы испытаний в фазовых обзорах
Таблица 8.8 — Участие группы выпуска документации в фазовых обзорах
Фаза
Фазовый обзор
Форма участия при обсуждении…
В фазовом обзоре I группа испытаний дает предварительную оценку ресурсам, необходимым для обеспечения ее деятельности,…
Контрольные вопросы
1. Понятие изделия как средства общения.
2. Нисходящий анализ процесса управления созданием программного изделия.
3. Установление целей и средства их достижения.
4. Подбор и обучение кадров.
5. Организация планирования разработки программного изделия. Виды планов. Декомпозиция планов.
6. Организационная структура группы планирования.
7. Виды планов, связанных с созданием программного изделия.
8. Организация планирования разработки программного изделия.
9. Вопросы, рассматриваемые в фазовых обзорах группой планирования.
10. Управление проектом.
11. Организация работы группы разработки в фазах создания программного изделия.
12. Организация работы группы обслуживания в фазах создания программного изделия.
13. Организация работы группы выпуска документации в фазах создания программного изделия.
14. Организация испытаний программного изделия.
Список литературы
1. Зельковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения. — М.: Мир, 1982. — 368 с.
2. Гантер Р. Методы управления проектированием программного обеспечения. — М.: Мир, 1981. — 388 с.
3. Вольховер В.Т., Иванов Л.А. Производственные методы разработки программ. — М.: Финансы и статистика, 1983. — 236 с.
4. Гласс Р. Руководство по надежному программированию. — М.: Финансы и статистика, 1983. — 176 с.