Материал: Технол_разраб_прогр_обесп_Гагарина_Кокарева

Структурная схема

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

Функциональная схема

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

Разработка алгоритмов

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

Структурные карты

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

Техника структурных карт Джексона основана на методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы. Основное внимание в методе сконцентрировано на соответствии входных и выходных потоков данных (см. разд. 4.3).

Порядок выполнения работы

1. На основе технического задания из лабораторной работы № 1 и спецификаций из лабораторной работы № 2 разработать уточненные алгоритмы программ, составляющих заданный программный модуль. Использовать метод пошаговой детализации (см. разд. 4.1.3).

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

3. Разработать функциональную схему программного продукта (разд. 4.1.2).

4. Представить структурную схему в виде структурных карт Константайна (см. разд. 4.2).

1. Представить структурную схему в виде структурных карт Джексона (см. разд. 4.3).

5. Оформить результаты, используя MS Office или MS Visio в виде технического проекта.

6. Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен состоять из:

1. Структурной схемы программного продукта.

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

3. Алгоритма программы.

4. Структурной карты Константайна.

5. Структурной карты Джексона.

6. Законченного технического проекта программного модуля.

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

Контрольные вопросы

1. Назовите этапы разработки программного обеспечения.

2. В чем заключается проектирование программного обеспечения?

3. Перечислите составляющие технического проекта.

4. Охарактеризуйте структурный подход к программированию.

5. Из чего состоят структурная и функциональная схемы?

6. Охарактеризуйте метод пошаговой детализации при составлении алгоритмов программ.

7. Приведите понятие псевдокода.

8. В чем заключается методика Константайна?

9. В чем заключается методика Джексона?

ЛАБОРАТОРНАЯ РАБОТА № 4.

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

Стадия «Реализация»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе

1. Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Структурный подход к программированию» учебной дисциплины «Технология разработки программного обеспечения».

2. Изучить соответствующие разделы в изданиях [1, 2, 5, 7, 40].

3. Ознакомиться с гл. 6 настоящего пособия.

Теоретическая часть. Составление программной документации

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

Виды программных документов

Документирование программного обеспечения осуществляется в соответствии с Единой системой программной документации (ГОСТ 19.ХХХ). ГОСТ 19.101—77 содержит виды программных документов для программного обеспечения различных типов. В данном ГОСТе перечислены документы следующих типов:

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

• ведомость держателей подлинников (код вида документа — 05) должна содержать список предприятий, на которых хранятся подлинники программных документов. Необходимость этого документа определяется на этапе разработки и утверждения технического задания только для программного обеспечения со сложной архитектурой;

• текст программы (код вида документа — 12) должен содержать текст программы с необходимыми комментариями. Необходимость этого документа определяется на этапе разработки и утверждения технического задания;

• описание программы (код вида документа — 13) должно содержать сведения о логической структуре и функционировании программы. Необходимость данного документа также определяется на этапе разработки и утверждения технического задания;

• ведомость эксплуатационных документов (код вида документа — 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами 30, 31, 32, 33, 34, 35, 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания;

• формуляр (код вида документа — 30) должен содержать основные характеристики программного обеспечения, комплектность и сведения об эксплуатации программы;

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

• руководство системного программиста (код вида документа — 32) должно содержать сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения;

• руководство программиста (код вида документа 33) должно содержать сведения для эксплуатации программного обеспечения;

• руководство оператора (код вида документа — 34) содержит сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы;

• описание языка (код вида документа — 35) — описание синтаксиса и семантики языка программы;

• руководство по техническому обслуживанию (код вида документа — 46) содержит сведения для применения программы при обслуживании технических средств.

Порядок выполнения работы

1. По результатам лабораторных работ № 1—3 написать код
программ для решения поставленной задачи на языке програм-
мирования, выбранном на этапе эскизного проектирования.

2. Отладить программный модуль.

3. Получить результаты работы.

4. Оформить документацию к разработанному программному
обеспечению.

5. Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен состоять из:

1. Листингов программ.

2. Интерфейса пользователя.

3. Документации к программному обеспечению (руководство пользователя, руководство системного программиста, руководство программиста, руководство оператора).

4. Результатов работы программ.

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

Контрольные вопросы

1. В чем состоит этап реализации и отладки программного обеспечения?

2. Какие существуют инструментальные средства разработки?

3. Охарактеризуйте этап стихийного программирования.

4. Охарактеризуйте этапы структурного и модульного программирования.

5. Что такое документация к программному обеспечению?

ЛАБОРАТОРНАЯ РАБОТА № 5. Тестирование программ методами «белого ящика»

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

Подготовка к лабораторной работе

1. Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Тестирование и отладка программных продуктов» учебной дисциплины «Технология разработки программного обеспечения».

2. Изучить соответствующие разделы в изданиях [1, 2, 7, 8, 9, 37, 45].

3. Ознакомиться с разд. 5.2 данного пособия.

Теоретическая часть. Виды тестирования

Тестирование программного обеспечения включает в себя целый комплекс действий, аналогичных последовательности процессов разработки программного обеспечения. В него входят [7]:

• постановка задачи для теста;

• проектирование теста;

• написание тестов;

• тестирование тестов;

• выполнение тестов;

• изучение результатов тестирования.

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

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

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

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

Тестирование методом «белого ящика» также не дает 100%-ной гарантии того, что модуль не содержит ошибок. Даже если предположить, что выполнены тесты для всех ветвей алгоритма, нельзя с полной уверенностью утверждать, что программа соответствует ее спецификациям. Например, если требовалось написать программу для вычисления кубического корня, а программа фактически вычисляет корень квадратный, то реализация будет совершенно неправильной, даже если проверить все пути. Вторая проблема — отсутствующие пути. Если программа реализует спецификации не полностью (например, отсутствует такая специализированная функция, как проверка на отрицательное значение входных данных программы вычисления квадратного корня), никакое тестирование существующих путей не выявит такой ошибки. И наконец, проблема зависимости результатов тестирования от входных данных. Одни данные будут давать правильные результаты, а другие нет. Например, если для определения равенства трех чисел программируется выражение вида: