МУ_ДЗ_2014 (1079920), страница 17
Текст из файла (страница 17)
6.1. АЛГОРИТМ ...
6.2. АЛГОРИТМ ...
…
7. ОПИСАНИЕ ПРОЦЕДУР И ФУНКЦИЙ ПО
7.1. ПРОЦЕДУРА ...
7.2. ПРОЦЕДУРА ...
…
8. ОПИСАНИЕ ПРОЦЕССА ОТЛАДКИ КЛАССОВ.
9. КЛАССЫ И МЕТОДЫ, ПЕРЕОПРЕДЕЛЯЕМЫЕ В ПО
Разделы 6 и 7 могут иметь несколько подпунктов, в зависимости от состава ПО.
85 Требования к ТО
Главные требования к основным разделам технического описания ПП (на выполнение этих требований будет обращаться повышенное внимание при предъявлении ПП). Ниже требования, характерные для нашего конкретного случая КР/ДЗ:
В п.1 (“ОБЩИЕ СВЕДЕНИЯ О ПРОГРАММНОМ ОБЕСПЕЧЕНИИ ”), приводятся общие характеристики программного обеспечения, дается назначение ПО, его шифр и краткая характеристика содержания документа ТО.
В п.2 (“МОДУЛЬНАЯ СТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ”) приводится модульная структура ПО, либо в виде чертежа-схемы, либо в виде таблицы, если модулей в проекте немного. Возможно наличие и таблицы и чертежа. Дается перечень и связность модулей (исходных, объектных, библиотек и включаемых). В нашем случае это будет описание классов и их реализация. Если используются разные файлы, то дается их описание и назначение, а также распределение описаний по исходным модулям.
В п.3 (“ДИАГРАММА КЛАССОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ”) должна быть представлены диаграмма классов ПО и краткое их описание на содержательном уровне. Можно располагать диаграмму классов на отдельном чертеже, но желательно в формате рисунка ее повторить и в данном документе.
В п.4 (“ОПИСАНИЕ МЕТОДОВ И ДАННЫХ КЛАССОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ”) желательно в виде структурированной таблицы дается детальное описание классов ПО, их методов и свойств. Если класс наследует свойства базового класса, то нельзя делать ссылки на базовый класс, а нужно повторить описание данных и методов.
Примечание: Материалы с описанием процедур и членов классов необходимо размещать в специальной таблице с графами типа (см. методические указания к КЛР/ДЗ): название процедуры, способ обращения, входные параметры, выходные параметры, назначение, примечание и т.д.
В п.5 (“ДАННЫЕ И ФАЙЛЫ ДАННЫХ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ”) описываются структуры данных и файлов, используемых в ПО. Желательно оформить каждую структуру и файл в виде отдельной таблицы и снабдить необходимыми пояснениями полей данных.
В п.6 (“ОСНОВНЫЕ АЛГОРИТМЫ МЕТОДОВ КЛАССОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ”) дается общее описание алгоритмов функционирования процедур По и методов классов, если эти алгоритмы имеют уникальный характер. В частности должно быть приведено описание блок-схем программ методов, которые могут быть представлены в тексте документа или быть оформлены в виде приложении к документу ТО или отдельных листов конструкторской документации.
В п.7 (“ОПИСАНИЕ ПРОЦЕДУР И ФУНКЦИЙ ПО ”) должны быть описаны все процедуры и функции ПП. Описание каждой функции сводиться в таблицу, в которой отображаются: назначение, входные, промежуточные и выходные данные процедур (как в п.4).
В п.8 (“ОПИСАНИЕ ПРОЦЕССА ОТЛАДКИ КЛАССОВ ”) приводится описание процесса отладки ПО и специальные прогрммы, разработанные для отладки.
В п.9 (“КЛАССЫ И МЕТОДЫ, ПЕРЕОПРЕДЕЛЯЕМЫЕ В ПО ”) приводится краткое описание классов переопределяемых в программе и дается ссылка о том, в каких библиотеках базовые классы описаны. В документе приводиться также список библиотечных классов с указанием стандартной библиотеки.
86 Разработка ТО
Разработка ТО выполняется разработчиками ПО или специалистами по разработке документации совместно с разработчиками ПО. Начинается разработка ТО фактически с началом проекта, а завершается (или уточняется содержание ) в конце проекта. Поэтому желательно сразу, на основе шаблона, создать такой документ и постоянно в него добавлять информации. Например, завершена разработка и отладка одного класса, можно его описание отобразить в ТО. Иногда, и даже более правильно, сделать описание класса или алгоритма в формате ТО, а только затем выполнить его реализацию, внося, при необходимости, уточнения и изменения в документ ТО.
87 Руководство пользователя
88 Документ руководство пользователя (РП) ПО и его назначение
Документ “Руководство пользователя” (РП) программного продукта (данные документ ориентируется на потенциального пользователя ПО). Он является, своего рода, инструкцией по эксплуатации программного изделия. Документ должен описывать, включая примеры, все свойства и методы классов, разрабатываемых в проекте. Кроме этого в документе приводится: условия применения и общая характеристики ПО. Данный документ ориентирован на конечного пользователя, который применяет данный программный продукт. В нашем случае – это пользователь применяющий – программист, использующий систему классов в своих программных разработках.
89 Стиль изложения РП
Стиль изложения руководства пользователя должен быть описательным и исчерпывающим. Описание необходимо давать простым языком, без злоупотреблений техническими терминами. Должны рассматриваться различные примеры и рисунки для различных режимов работы, рассматриваться ошибочные ситуации и диагностические сообщения. Данный документ должен понимать тот пользователь, на которого рассчитан программный продукт. В тексте документа не должно содержаться пространных рассуждений и материала, не относящегося к программному продукту. Должна быть дана подробная инструкция применения программы, включая запуск, использование и выгрузку. системы классов: подключения в программу, создания и манипулирования объектами, использование всех методов. Должны быть даны наглядные примеры для всех случаев использования.
90 Разработка РП
Разработка документа РП выполняется в конце всей разработки программного продукта разработчиками совместно с техническими “писателями”. Для создания РП возможно разрабатывается специальная программа с использованием классов, примеры из которой должны быть помещены в документ. Все примеры в РП должны быть тщательно проверены. Они должны быть наглядными и охватывать весь спектр возможных применений программного обеспечения.
91 Содержание РП
Содержание документа РП по пунктам приведено ниже. В образце документа РП приведено РП для варианта улиц и домов, описанного в общем пособии по курсу [3]. В шаблоне документа РП (см. в конце данных методических указаний) даны методические указания к написанию и приспособлению документа шаблона применительно к конкретному варианту студента.
Содержание документа РП:
1. НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ СИСТЕМЫ КЛАССОВ
2. ПОДКЛЮЧЕНИЕ СИСТЕМЫ КЛАССОВ И ДИАГРАММА КЛАССОВ
3. РАБОТА С СИСТЕМОЙ КЛАССОВ
4. КЛАСС ХХХ
4.1 Использование свойств ХХХ класса ХХХ с примером…
4.2 Использование метода ХХХ класса ХХХ с примером…
5. ОТКЛЮЧЕНИЕ СИСТЕМЫ КЛАССОВ
6. ОПИСАНИЕ СООБЩЕНИЙ ОБ ОШИБКАХ И ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ ПРИ РАБОТЕ С ПРОГРАММОЙ
92 Требования к РП
Главные требования к основным разделам документа “Руководства пользователя” (на выполнение этих требований будет обращаться повышенное внимание при сдаче ПО) рассмотрены ниже:
В п.1 (“НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ СИСТЕМЫ КЛАССОВ”) приводится назначение ПО и подчеркиваются качественные характеристики изделия. В этом разделе характеризуются предметные области применения программного продукта.
В п.2 (“ПОДКЛЮЧЕНИЕ СИСТЕМЫ КЛАССОВ И ДИАГРАММА КЛАССОВ”) рассматривается по шагам процесс подключения программного обеспечения с собственные проекты.
В п.3 (“РАБОТА С СИСТЕМОЙ КЛАССОВ”) приводятся качественное описание системы классов и дается диаграмма классов проекта. Рассмотрены вопросы подключения системы классов в программы, а также используемые общие переменные и функции во всех классах.
В п.4 (“КЛАСС ХХХ”) приводятся описание конкретного класса с методами и свойствами.
В п.4.1-Х (“Использование метода/свойства ХХХ класса ХХХ с примером”) дается описание с примерами использования свойств и методов класса.
В п.5 (“ОТКЛЮЧЕНИЕ СИСТЕМЫ КЛАССОВ”) приведено описание действий, необходимых для отключения системы классов из проекта.
В п.6 (“ОПИСАНИЕ СООБЩЕНИЙ ОБ ОШИБКАХ И ИСКЛЮЧИТЕЛЬНЫХ СИТУАЦИЙ ПРИ РАБОТЕ С ПРОГРАММОЙ ”) описываются диагностические сообщения системы и дается описание этих сообщений и ситуаций. Желательно эти сведения собрать в таблицу. Должны быть описаны действия, которые нужно предпринять при возникновении исключительных ситуаций.
93 Руководство системного программиста
94 Документ руководство системного программиста (РСП) ПО и его назначение
Документ Руководство системного программиста разрабатывается программистом для системного программиста или системного администратора той организации, в которой программный продукт будет использоваться. Этот специалист отвечает за работоспособность техники и операционных систем и выполняет функции по установке и сопровождению ПП на конкретных компьютерах. В этот документ должна быть собрана вся необходимая информация для выполнения этих работ, в том числе и та, которая присутствует в других документах. Поэтому ряд пунктов в этом документе совпадает с пунктами в других документах комплекта ПД.
95 Стиль изложения РСП
Стиль изложения руководства системного программиста должен быть предписывающим (все термины должны быть техническими): "Для установки ПП нужно выполнить следующие действия …", "ПП состоит из набора следующих компонент …". Здесь могут использоваться специальные термины, но не жаргон программистов.
96 Содержание РСП
Содержание документа РСП по пунктам приведено ниже. В образце документа РСП приведен документ РСП для варианта улиц и домов, описанного в общем пособии по курсу [3]. В шаблоне документа РСП (см. в конце данных методических указаний) даны методические указания к написанию и приспособлению документа применительно к конкретному варианту студента.
Содержание документа РСП:
1. НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММЫ
2. ТРЕБОВАНИЯ К СОСТАВУ И ПАРАМЕТРАМ ТЕХНИЧЕСКИХ СРЕДСТВ
3. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
4. СОСТАВ ПРОГРАММНОГО ПРОДУКТА
5. УСТАНОВКА ПРОГРАММНОГО ПРОДУКТА
6. УДАЛЕНИЕ ПРОГРАММНОГО ПРОДУКТА
7. ЗАПУСК ПРОГРАММЫ
8. ЗАВЕРШЕНИЕ РАБОТЫ ПРОГРАММЫ
9. СООБЩЕНИЯ ОБ ОШИБКАХ ПРОГРАММНОГО ПРОДУКТА
10. УСЛОВИЯ ЭКСПЛУАТАЦИИ ПРОГРАММНОГО ПРОДУКТА
11. ПРОВЕРКА РАБОТОСПОСОБНОСТИ ПРОГРАММНОГО ПРОДУКТА
12. ПОДГОТОВКА К РАБОТЕ С ПРОГРАММОЙ
13. ОБШИЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ПРОДУКТА
97 Требования к РСП
Главные требования к основным разделам руководства системного программиста программного обеспечения приведены ниже.
В п.1 (“НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММЫ”) рассмотрено назначение и условия применения программного продукта.
В п.2 (“ТРЕБОВАНИЯ К СОСТАВУ И ПАРАМЕТРАМ ТЕХНИЧЕСКИХ СРЕДСТВ”) приводятся требования к техническим характеристикам для работы программного обеспечения.
В п.3 (“ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ”) приводятся требования к программному обеспечению для функционирования программного продукта.
В п.4 (“ СОСТАВ ПРОГРАММНОГО ПРОДУКТА”) приводится перечень составляющих модулей программного продукта.
В п.5 (“ УСТАНОВКА ПРОГРАММНОГО ПРОДУКТА”) описывается процесс развертывания программного продукта на отдельном компьютере в среде программирования С++. Подключения системы классов в используемую систему программирования по шагам. Описываются все ситуации, включая и нештатные, когда продукт установить нельзя. Если, при установке, для конкретного шага, выдается информационное сообщение, то оно должно быть тоже приведено.
В п.6 (“6. УДАЛЕНИЕ ПРОГРАММНОГО ПРОДУКТА”) описывается процесс удаления программного продукта с отдельного компьютера. Описание нужно дать по шагам. Описываются все ситуации, включая и нештатные, когда продукт удалить нельзя. Если, при удалении, для конкретного шага, выдается информационное сообщение, то оно должно быть тоже приведено.
В п.7 (“7. ЗАПУСК ПРОГРАММЫ”) рассмотрены действия для запуска программы тестового примера.
В п.8 (“8. ЗАВЕРШЕНИЕ РАБОТЫ ПРОГРАММЫ”) описаны действия для завершения работы программы тестового примера.
В п.9 (“9. СООБЩЕНИЯ ОБ ОШИБКАХ ПРОГРАММНОГО ПРОДУКТА”) приводятся диагностические сообщения об ошибках и исключительных ситуациях, которые могут появиться при эксплуатации программного продукта.
В п.10 (“10. УСЛОВИЯ ЭКСПЛУАТАЦИИ ПРОГРАММНОГО ПРОДУКТА”) дается описание условий эксплуатации программного продукта.
В п.11 (“11. ПРОВЕРКА РАБОТОСПОСОБНОСТИ ПРОГРАММНОГО ПРОДУКТА”) описывается процесс проверки работоспособности программного продукта.
В п.12 (“12. ПОДГОТОВКА К РАБОТЕ С ПРОГРАММОЙ”) рассмотрены вопросы подготовки использования программного продукта.
В п.13 (“13. ОБШИЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ПРОДУКТА”) приводятся общие характеристики программного продукта.
Описания пунктов 3, 4, 9, 10, 11 и 13 более были рассмотрены при изучении других программных документов, поэтому здесь мы не повторяем это описание.
Примечание. Последнее замечание нужно учитывать в двух аспектах: нужно согласовывать описание одинаковых пунктов в разных документах и не тратить лишнее время на повторную разработку раздела документа.
98 Разработка РСП
Разработка РСП выполняется грамотным системным программистом после завершения всей разработки и программного обеспечения и программной документации. Все пункты РСП должны быть проверены на практике. Они должны корректироваться при изменении условий эксплуатации и доработках программного обеспечения.
99 Программа и методика испытаний
100 Документ программа и методика испытаний (ПМИ) ПО и его назначение
Документ “Программа и методика испытаний” (ПМИ) разрабатывается специально для проведения приемно-сдаточных испытаний для сдачи ПО. В нашем случае этот документ разрабатывается для проведения испытаний на основе пунктов ТЗ.
Данный документ ориентирован на заказчика, который будет выполнять приемку программного продукта. Возможны различные варианты построения документа (ПМИ), который устанавливается по соглашению с заказчиком: приемка на основе проверки выполнения пунктов ТЗ (5.1 раздел ТЗ в первую очередь); приемка ориентированная на проверку работоспособности системы; комбинированная приемка по ТЗ и работоспособности и т.д. Для нашего случая используется вариант приемки на основе пунктов ТЗ и проверки работоспособности системы, поэтому, отметим еще раз, что в ТЗ все позиции должны быть пронумерованы, для того, чтобы на них можно было ссылаться в ПМИ.
Документ ПМИ должен быть фактически пошаговой инструкцией для проведения испытаний, специалист, принимающий испытания должен без подсказок разработчика самостоятельно выполнить действия по проверке и удостоверится в работоспособности программного продукта и выполнения всех пунктов ТЗ.
101 Стиль изложения документа ПМИ
Стиль изложения должен быть предписывающим, и основан на техническом языке, принятом программистами и специалистами по разработке ПП (программистский жаргон здесь недопустим). Недопустимо, также, использование бытовых терминов. Все тексты должны трактоваться однозначно. Например, "нажмите … клавишу", "получите на экране …", "испытания должны проводиться в режиме командной строки для CMD.EXE" и т.д. Неоднозначностей и ошибок в тексте документа ПМИ не должно быть. Данный документ должен быть лаконичным и четким. Не нужно строить сложные предложения.
102 Разработка документа ПМИ
Разработка документа ПМИ выполняется в конце всей разработки программного продукта специалистами по программированию и заказчиком, но ее план задумывается уже при составлении ТЗ на программное обеспечение. Перед разработкой ПМИ должен быть подготовлен специальный тестовый пример, ориентированный для проверки пунктов ТЗ. Нужно иметь в виду, что при разработке ТЗ вы уже должны понимать, как могут быть проверены эти пункты в документе ПМИ. Для проверки правильности документа необходимо провести испытания самостоятельно, использую в роли заказчика представителя не связанного с вашим проектом.
103 Содержание документа ПМИ
Содержание документа ПМИ по пунктам приведено ниже. В образце документа ПМИ приведен документ ПМИ для варианта улиц и домов, описанного в общем пособии по курсу [3]. В шаблоне документа ПМИ (см. в конце данных методических указаний) даны методические указания к написанию и приспособлению документа шаблона применительно к конкретному варианту студента.
Содержание документа ПМИ:
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
