- •Оглавление
- •6 Тестирование 88
- •8.3 Организация разработки программного изделия 215
- •8.4 Организация обслуживания разработки программного изделия 230
- •8.5 Организация выпуска документации 239
- •8.6 Организация испытаний программных изделий 248
- •1 Введение. Проблемы современного программирования
- •2 Этапы разработки программного обеспечения
- •2.1 Анализ требований, предъявляемых к системе
- •2.2 Определение спецификаций
- •2.3 Проектирование
- •2.4 Кодирование
- •2.5 Тестирование
- •2.6 Эксплуатация и сопровождение
- •2) Определение спецификаций;
- •3) Проектирование;
- •4) Кодирование;
- •Контрольные вопросы
- •1. Этапы разработки программного обеспечения.
- •2. Анализ требований, предъявляемых к системе.
- •3 Методы разработки программного обеспечения как научная дисциплина
- •3.1 Методы управления разработкой
- •3.1.1 Выполнение проекта
- •3.1.2 Методика оценки затрат
- •3.1.2.1 Методика инженерно-технической оценки затрат
- •3.1.2.2 Оценка на основе распределения Рэлея
- •3.1.3 Контрольные точки
- •3.1.4 Средства разработки
- •3.1.5 Надежность
- •3.2 Методы проведения разработки программного обеспечения
- •3.3 Развитие методов разработки программного обеспечения
- •3.3.1 Язык определения задач и анализатор задач
- •3.3.2 Система структурного анализа и проектирования sadt
- •3.3.3 Система srem
- •3.3.4 Методика Джексона
- •3.4 Выводы
- •Контрольные вопросы
- •1. Методы разработки программного обеспечения как научная дисциплина.
- •4 Методы разработки программного обеспечения
- •4.1 Язык проектирования программ
- •4.2 Стратегия проектирования
- •4.2.1 Нисходящее проектирование и нисходящая разработка
- •4.2.2 Структурное проектирование
- •4.3 Данные
- •4.3.1 Обзор структур данных
- •4.3.1.1 Массивы
- •4.3.1.2 Структуры
- •4.3.1.3 Списки
- •4.3.1.4 Очереди
- •4.3.1.5 Стеки
- •4.3.1.6 Множества
- •4.3.1.7 Графы
- •4.3.1.8 Деревья
- •4.3.2 Абстрактные конструкции
- •4.3.2.1 Фиксированные типы данных абстрактного типа
- •4.3.2.2 Размещение указателей
- •4.3.2.3 Защита данных от несанкционированного доступа
- •Контрольные вопросы
- •2. Нисходящее проектирование и нисходящая разработка.
- •9. Абстрактные конструкции.
- •5 Правильность программ
- •5.1 Аксиомы
- •5.2 Правила преобразования данных
- •5.3 Доказательства правильности программ
- •Контрольные вопросы
- •1. Правильность программ.
- •6 Тестирование
- •6.1 Психология и экономика тестирования программ
- •6.2 Экономика тестирования
- •6.2.1 Тестирование программы как черного ящика
- •6.2.2 Тестирование программы как белого ящика
- •6.2.3 Принципы тестирования
- •6.3 Ручное тестирование
- •6.3.1 Инспекции и сквозные просмотры
- •6.3.2 Инспекции исходного текста
- •6.3.3 Список вопросов для выявления ошибок при инспекции
- •6.3.3.1 Ошибки обращения к данным
- •6.3.3.2 Ошибки описания данных
- •6.3.3.3 Ошибки вычислений
- •6.3.3.4 Ошибки при сравнениях
- •6.3.3.5 Ошибки в передачах управления
- •6.3.3.6 Ошибки интерфейса
- •6.3.3.7 Ошибки ввода-вывода
- •6.3.3.8 Другие виды контроля
- •6.3.4 Сквозные просмотры
- •6.3.5 Оценка посредством просмотра
- •6.4 Проектирование теста
- •6.4.1 Тестирование путем покрытия логики программы
- •6.4.1.1 Покрытие операторов
- •6.4.1.2 Покрытие решений
- •6.4.1.3 Покрытие условий
- •6.4.1.4 Покрытие решений/условий
- •6.4.1.5 Комбинаторное покрытие условий
- •6.4.2 Эквивалентное разбиение
- •6.4.2.1 Выделение классов эквивалентности
- •6.4.2.2 Построение тестов
- •6.4.3 Анализ граничных значений
- •6.4.4 Применение функциональных диаграмм
- •6.4.5 Предположение об ошибке
- •6.4.6 Стратегия
- •Контрольные вопросы
- •3. Принципы тестирования.
- •9. Анализ граничных значений.
- •11. Предположение об ошибке.
- •7 Технология разработки программ
- •7.1 Разбиение задачи на независимые подзадачи
- •7.2 Разбиение задачи на одинаковые по сложности части
- •7.3 Рекурсия и динамическое программирование
- •7.3.1 Рекурсия
- •7.3.2 Динамическое программирование
- •7.3.3 Моделирование
- •7.4 Поиск
- •7.4.1 Поиск в списках
- •7.4.2 Деревья поиска
- •7.4.3 Стратегия распределения памяти
- •7.5 Сортировка
- •7.6 Алгоритм выбора из конечного состояния
- •7.7 Сопрограммы
- •Контрольные вопросы
- •8 Методы управления проектированием программных изделий
- •8.1 Организация управления проектированием программного изделия
- •8.1.1 Понятие изделия как средства общения
- •8.1.2 Нисходящий анализ процесса управления проектированием программного изделия
- •8.1.3 Организация взаимодействия
- •8.1.4 Установление целей, средства их достижения
- •8.1.5 Подбор и обучение кадров
- •8.2 Организация планирования разработок программного изделия
- •8.2.1 Виды планов
- •8.2.2 Декомпозиция планов
- •8.2.3 Организационная структура группы планирования
- •8.2.4 Планы, связанные с созданием программных изделий
- •8.2.5 Опытный образец изделия
- •8.2.6 Организация планирования в фазе исследования
- •8.2.7 Организация планирования в стадии анализа осуществимости
- •8.2.8 Организация планирования в фазах конструирования и кодирования
- •8.2.9 Организация планирования в фазах оценки и использования
- •8.2.10 Обязанности группы планирования при рассмотрении и утверждении планов разработки программного изделия
- •8.3 Организация разработки программного изделия
- •8.3.1 Организация разработки программного изделия в фазе исследований
- •8.3.2 Организация разработки программного изделия в фазе анализа осуществимости
- •8.3.3 Организация разработки программного изделия в фазе конструирования (проектирования)
- •8.3.4 Организация разработки программного изделия в фазе программирования
- •8.3.5 Организация разработки программного изделия в фазе оценки
- •8.3.6 Окончание проекта
- •8.3.7 Участие группы разработки в фазовых обзорах
- •8.4 Организация обслуживания разработки программного изделия
- •8.4.1 Организационная структура группы обслуживания
- •8.4.2 Организация обслуживания программного изделия в фазе исследования
- •8.4.3 Организация обслуживания в фазах анализа осуществимости и конструирования
- •8.4.4 Организация обслуживания в фазе программирования и оценки
- •8.4.5 Организация обслуживания в фазе использования
- •8.4.6 Участие группы обслуживания в фазовых обзорах
- •8.5 Организация выпуска документации
- •8.5.1 Организационная структура группы выпуска документации
- •8.5.2 Стандарты и практические руководства
- •8.5.3 Организация выпуска документации в фазах исследований и анализа осуществимости
- •8.5.4 Организация выпуска документации в фазах конструирования и программирования
- •8.5.5 Организация выпуска документации в фазах оценки и использования
- •8.5.6 Участие группы выпуска документации в фазовых обзорах
- •8.6 Организация испытаний программных изделий
- •8.6.1 Современное состояние методов обеспечения качества программного изделия
- •8.6.1.1 Виды испытаний программного изделия. Стадии испытаний
- •8.6.1.2 Режимы испытаний программ
- •8.6.1.3 Категории испытания программного изделия
- •8.6.2 Организационная структура группы испытаний
- •8.6.3 Организация испытаний в фазах исследований и анализа осуществимости
- •8.6.4 Организация испытаний в фазах конструирования и программирования
- •8.6.5 Организация испытаний в фазе оценки
- •8.6.6 Организация испытаний в фазе использования
- •8.6.7 Участие группы испытаний в фазовых обзорах
- •Контрольные вопросы
- •1. Понятие изделия как средства общения.
- •4. Подбор и обучение кадров.
- •6. Организационная структура группы планирования.
- •Список литературы
4.2 Стратегия проектирования
4.2.1 Нисходящее проектирование и нисходящая разработка
Язык программирования является лишь средством разработки проектов. Важное место в построении правильных проектов играет методология проектирования. При разработке программ на этапе проектирования обычно используется два подхода: нисходящий и восходящий. Суть нисходящего проектирования можно объяснить следующей схемой (рис. 4.2).
Рис. 4.2 — Пример базисной схемы
На приведенной базисной схеме каждый блок — это модуль системы. При этом вызов каждого модуля производится модулем более высокого уровня.
При нисходящем проектировании вначале проектируется управляющая программа — драйвер. Управляющий модуль может быть представлен программой на PDL.
DRIVER: procedure;
Выполнить задачу A;
do while (условие истинно);
Выполнить задачу B;
end;
Выполнить задачу C;
end DRIVER;
Затем более подробно представляются каждый из операторов псевдокода и разрабатываются другие модули. Например, если задачи A, B, C достаточно сложны, их можно оформить как отдельные процедуры. В этом случае проект драйвера можно представить следующим образом:
DRIVER: procedure;
Инициировать задачу A;
call A;
do while (условие истинно);
Инициировать задачу B;
call B;
end;
Инициировать задачу C;
call C;
end DRIVER;
Затем, таким же образом, можно определить процедуры A, B и C. Очевидно, что язык PDL хорошо подходит для нисходящего проектирования.
Нисходящее проектирование также называют пошаговым совершенствованием: программы иерархически структурируются и разбиваются путем последовательного уточнения. На каждом шаге функционирование модуля описывается с помощью ссылок на предыдущие более подробные шаги.
При восходящем проектировании вначале проектируются программы нижнего уровня. Обычно такой подход используется при проектировании операционных систем, где самым нижним уровнем иерархии являются аппаратные средства (технология виртуальных машин). Например, один из модулей может обеспечить доступ к аппаратным средствам страничного механизма ЭВМ и предоставить виртуальную память для всех остальных модулей. Вследствие этого большинство систем реального времени проектируется снизу вверх.
На этапах кодирования и тестирования ситуация противоположная. Хотя большинство систем проектируется сверху вниз, кодирование и тестирование удобнее осуществлять снизу вверх, так как модули ААА и ААВ не вызывают других компонент, их кодируют и тестируют (рис. 4.3).
Рис. 4.3 — Восходящее кодирование и тестирование
Когда задача хорошо определена, пользоваться этим подходом очень удобно.
Однако если решаемая задача не понятна или детально не определена, то тестирование снизу вверх может вызвать серьезные проблемы. Например, пользователь не может убедиться в правильности функционирования системы согласно спецификациям, пока не будет проверен модуль верхнего уровня. Однако этого нельзя сделать до тех пор, пока не будет проверена вся иерархическая структура системы, т.е. до завершения проекта. А внесение изменений на этом этапе сопряжено со значительными затратами и обходится дорого.
Чтобы избежать этого, можно использовать нисходящее кодирование. В этом случае в первую очередь проверяют модули управляющей программы, а также модули A, B, C. Пользователь системы проверяет функционирование верхнего уровня на начальном этапе разработки, поэтому сделать любые необходимые изменения в спецификациях гораздо легче.
Единственное неудобство при таком методе кодирования заключается в том, что для проверки модулей A, B, C требуются также модули АА, АВ, АС, ВА, ВВ и СА. Для этих целей служат подыгрывающие программы — заглушки. Это короткие программы, которые составляются специально для того, чтобы моделировать ненаписанные модули и передавать управляющим программам необходимые тестовые данные (рис. 4.4).
Рис. 4.4 — Нисходящее тестирование
Подобные средства оказываются полезными, если ими пользоваться достаточно осторожно, так как корректность системы не может быть доказана, пока не убрана последняя заглушка.
Нисходящее проектирование не так просто, как это кажется на первый взгляд. Это связано с тем, что в любой программной системе имеется три вершины:
1) начало работ;
2) управляющая программа;
3) программа связи пользователя с системой.
Основные различия между этими моментами можно показать на примере компилятора. Для разработчика аппаратных средств «вершиной» системы является модуль, инициирующий работу системы. Этот модуль — основное средство интерфейса с операционной системой. С его помощью с диска считываются фрагменты программы, реализующие различные этапы компилирования, и передается управление на их выполнение. Все остальные части системы можно рассматривать как подпрограммы этого модуля.
Для системного программиста «вершиной» является управляющая программа. В компиляторе «вершиной» можно считать основной цикл анализа, который осуществляет поиск очередного анализируемого оператора (лексемы). Таким образом, логической вершиной является цикл вида:
do while (продолжить до конца компилирования);
Чтение до начала следующего оператора;
Анализ введенного оператор;
end;
Что касается пользователя, то, с его точки зрения, компилятор читает операторы, а затем их транслирует. Таким образом, для него «вершиной» является программа ввода данных.
От искусства и квалификации программиста зависит правильный выбор вершины для всей системы. Однако для прикладных программ всегда целесообразно «вершиной» считать управляющую программу.
При нисходящей разработке пользователь видит взаимодействие верхних уровней системы на начальных этапах. Изменения в этот период можно вносить относительно легко. Такими же свойствами обладает и метод последовательной модификации (модернизации). При использовании этого метода вначале проектируется и реализуется некоторый вариант системы. Пользователь очень быстро получает работающую систему. Процесс модернизации с последующим расширением функций системы продолжается до тех пор, пока не будет получена окончательная версия.