- •Разработка сложных программных изделий
- •Раздел 1.Структурные методологии разработки программного обеспечения Глава 1.Структурные методы в программотехнике
- •1.1.Эволюция структурных методов
- •1.2.Основные идеи и принципы структурной методологии
- •1.3.Принципы программотехники
- •1.4.Принципы информационной инженерии
- •1.5.Автоматизация проектирования
- •Глава 2.Структурные методы анализа и проектирования
- •2.1.Структурный системный анализ
- •2.2.Нисходящее проектирование
- •2.3.Структурное проектирование, управляемое потоками данных
- •2.4.Методы проектирования, управляемые структурами данных
- •Глава 3.Структурные методы программирования
- •3.1.Особенности структурных программ
- •3.2.Цели структурного программирования
- •3.3.Программирование с использованием пошаговой детализации
- •3.4.Нисходящее и восходящее программирование
- •Глава 4.Модульное программирование
- •4.1.Основные понятия и определения
- •4.2.Программные модули и схема модуляризации
- •4.3.Оценка качества модульной программы
- •Глава 5.Модели разработки программных изделий
- •5.1.Модель жизненного цикла программного изделия
- •5.2.Модель "возрастающей выдачи"
- •5.3.Модель с использованием прототипа
- •5.4.Спиральная модель
- •Раздел 2.Фазы жизненного цикла программного изделия Глава 6.Определение требований пользователя и требований к программному изделию
- •6.1.Требования пользователя
- •6.2. Требования к программному изделию
- •6.3. Разработка логической модели программного изделия
- •6.4. Классификация требований к программному изделию
- •6.5. Атрибуты требований к программному изделию
- •6.6. Документ Требования к программному изделию
- •6.7 Техническое задание на разработку программного изделия
- •Глава 7.Архитектурное проектирование программного изделия
- •7.1.Общее содержание работ фазы
- •7.2.Виды деятельности
- •7.3.Критерии качества архитектурного проекта
- •Глава 8.Детальное проектирование и изготовление программного изделия
- •8.1.Основные виды деятельности
- •8.2.Кодирование модулей
- •8.3.Тестирование программного изделия
- •8.4.Документирование работ по проектированию программного изделия
- •Глава 9.Отладка программ
- •9.1.Трудности отладки
- •9.2.Средства и методы отладки
- •9.3.Категории ошибок в программном обеспечении
- •9.4.Рекомендации по отладке
- •Глава 10.Эксплуатация и сопровождение программного изделия
- •10.1.Передача программного изделия в эксплуатацию
- •10.2.План испытаний
- •10.3.Работы по эксплуатации и сопровождению программного изделия
- •10.4.Задачи службы сопровождения программного изделия
- •Раздел 3.Управление разработкой программного изделия Глава 11.Управление жизненным циклом программного изделия
- •11.1.Виды деятельности, связанные с управлением жизненным циклом программного изделия
- •11.2.Измерения в программотехнике
- •11.3.Управление проектированием программного изделия
- •11.4.Методы получения оценок для проекта программного изделия
- •11.4.1. Методы функциональной декомпозиции
- •11.4.2. Эмпирические оценочные модели
- •11.5.Управление рисками
- •11.6.Планирование разработки программного изделия
- •Глава 12.Управление качеством программного изделия
- •12.1.Качество программного изделия
- •12.2.Обеспечение качества программного изделия
- •12.3.Измерение качества программного изделия
- •12.4.Управление конфигурацией программного изделия
- •Литература
8.2.Кодирование модулей
Когда завершено проектирование каждого модуля и проведены его обзор и утверждение, можно начинать кодирование (написание программ). При этом также должны быть установлены и документированы требования кодирования, которые определяют правила:
• представления комментариев в программах;
• наименования программ, подпрограмм, файлов, переменных;
• ограничения размеров модулей;
• использования библиотек;
• определения констант; • использования специальных средств компилятора, которых нет в языке;
• обработки ошибок и т.п.
Каждый модуль должен иметь заголовок, оформленный по стандарту, который включается в "шапку" модуля.
Код должен быть непротиворечивым, что уменьшает его сложность. Основой для обеспечения непротиворечивости является строгое соблюдение правил кодирования. Кроме того, непротиворечивость усиливается в результате использования одинаковых решений одинаковых проблем. Для сохранения непротиворечивости кода все вносимые исправления и модификации должны использовать первоначальный стиль кодирования.
Код должен быть структурным, так как это уменьшает ошибки и улучшает сопровождаемость. Процесс кодирования включает компиляцию, которая является первым шагом в верификации кода и способствует накоплению статистики, необходимой для последующего анализа модуля.
После кодирования отдельных модулей начинается их интеграция в единое работающее программное изделие. Интеграция компонент должна проводиться последовательно, функция за функцией. Это позволяет раньше продемонстрировать операционные возможности программного обеспечения, повышая уверенность управленца в том, что проект удовлетворительно продвигается в изготовлении.
Для интеграции модулей применяется нисходящий подход, в котором вместо модулей нижнего уровня применяют программные "заглушки". После завершения разработки и тестирования модулей нижнего уровня они заменяют "заглушки". В ряде проектов необходимость правильного распределения усилий приводит к тому, что на ранних этапах осуществляется интеграция по восходящему принципу, который позже заменяется нисходящим. Независимо от используемого принципа главным критерием остается минимизация общего времени на тестирование программного изделия.
8.3.Тестирование программного изделия
Процесс тестирования проходит несколько этапов: поблочное, комплексное и системное.
Тестирование блоков показывает правильность реализации всех компонент программного изделия, начиная с самого нижнего уровня, определенного в детальном проекте, вплоть до самого нижнего уровня архитектурного проекта (обычно на уровне задач). Модули, которые не вызывают другие модули, — модули нижнего уровня детального проекта.
При тестировании блоков обычно проверяется правильность не только того, что функционально выполняет модуль, но и того, как он это делает. Таким образом, при тестировании блоков используется не только функциональное тестирование (тестирование "черного ящика"), но и структурное тестирование (тестирование "белого ящика").
Стратегия структурного тестирования предполагает такой подбор тестовых данных, при котором, во-первых, каждый оператор программы будет выполнен, по крайней мере, один раз, и, во-вторых, все пути выполнения программы будут охвачены соответствующими тестовыми наборами. Для проведения поблочного тестирования используются также и специальные автоматизированные средства.
Тестирование блоков обычно выполняется отдельными работниками или группой, ответственной за разработку этих компонент.
Комплексное тестирование также выполняется во время фазы детального проектирования, когда формируются основные компоненты программного изделия и объединяются с целью его построения. Комплексное тестирование направлено на верификацию интерфейсов главных компонент. Комплексное тестирование предшествует системному тестированию.
Комплексное тестирование контролирует согласованность всех данных, передаваемых через интерфейсы, со спецификациями структур данных в архитектурном проекте. Комплексное тестирование должно также подтверждать, что потоки управления, определенные в архитектурном проекте программного изделия, полностью реализованы.
Системное тестирование — процесс тестирования интегрированного программного изделия. Оно осуществляется в процессе разработки или в условиях моделирования эксплуатации. Системное тестирование должно подтверждать соответствие разработанного программного изделия целям, установленным в документе Требования пользователя.
Системное тестирование включает:
• передачу данных в систему, проверку корректности обработки данных и вывод результатов;
• прогон тестов с целью проверки выполнения требований пользователя;
• стрессовое тестирование для верификации предельных характеристик программного изделия;
• предварительную оценку надежности и пригодности к сопровождению;
• проверку правильности Руководства пользователя. В системных тестах контролируются возможные тенденции в появлении ошибок в программном обеспечении. Изучение этих тенденций позволяет судить о возможностях последующей приемки программного изделия.
Для большинства программных изделий, которые предназначены для включения в более крупные программные системы, а также для систем, использующих специальную периферию, часто возникает необходимость построения имитаторов окружающей обстановки, т.е. той обстановки, в которой будет функционировать разрабатываемое изделие. Их разработку также необходимо планировать.