doc_kr35_2009 (Домашнее задание (вариант 20))

12

3/4/5-семестр 2009 – Большаков С.А.

СП/ООП – Системное программирование ИУ5

Методические указания к оформлению документации для курсовой работы 5-го семестра по дисциплинам "Системное программирование" и "Объектно-ориентированное программирование".

ЕДИНЫЙ ТИТУЛЬНЫЙ ЛИСТ ДЛЯ ВСЕХ ДОКУМЕНТОВ ПРИВЕДЕН НА ПОСЛЕДНЕЙ СТРАНИЦЕ!!!

Перечень документов, разрабатываемых по программному продукту КР или ДЗ:

1. Техническое задание (ТЗ) на разработку программного продукта (заказчик – преподаватель, исполнитель - студент).

2. Описание применения программного продукта.

3. Техническое описание программного продукта.

4. Исходный (листинг) текст программ программного продукта.

5. Программа и методика испытаний для сдачи программного продукта по ТЗ.

6. Эксплуатационная документация. Руководство пользователя программного продукта.

7. Эксплуатационная документация. Руководство системного программиста программного продукта.

8. (Для ООП) Описание тестового примера для проверки системы классов.

9. (Для СП) 3 листа формата А1, поясняющие работу и конструкцию программного продукта (по договоренности с преподавателем их можно распечатать на листе форматов А4 или А2-3).

10. (Для ООП) Приложение с рисунками в виде блок-схем и структур данных, поясняющих систему классов и алгоритмы методов классов.

11. Дискета с исходными текстами, документацией и программным продуктом готовым к выполнению.

Примечание: Для курсовой работы по дисциплине СП все документы представляются отдельно с титульными листами. Для ДЗ по ООП документы могут быть объединены в единый файл с одним титульным листом, но каждый документ должен иметь заголовок первого уровня и начинаться с нового раздела.

Пояснения к разработке и содержанию документов, разрабатываемых по программному продукту КР.

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

2. Техническое задание (ТЗ) на разработку программного продукта (заказчик – преподаватель, исполнитель - студент).

   1. Структура оглавления и содержание ТЗ:

1. НАИМЕНОВАНИЕ

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

4. ИСПОЛНИТЕЛЬ

5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

5.1. Требования к функциональным характеристикам

5.2. Требования к программному обеспечению

5.3. Требования к условиям эксплуатации

5.4. Требования к информационному обеспечению

5.5. Требования к надежности

5.6. Требования к составу и характеристикам технических средств

5.7. Требования к программной совместимости

6. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

6.1. Разрабатываемые технические и эксплуатационные документы

7. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ

1. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ

8.1. Сроки выполнения отдельных этапов работ

1. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ЗАДАНИЯ

9.1. Требования к сдаче и условия приемки

10. ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ

1. Стиль изложения ТЗ – декларативный (предписывающий): все предложения должны соответствовать предписывающему стилю ("программа должна обеспечивать …" или "в процедуре необходимо обеспечить" или "система должна выполнять" и т.д.).

2. Главные требования к основным разделам ТЗ (на выполнение этих требований будет обращаться повышенное внимание при предъявлении программ):

   1. В пункте 3 (НАЗНАЧЕНИЕ РАЗРАБОТКИ) очень кратко (2-3 предложения) формулируется назначение разработки: какие преимущества возникают при его применении, какие новые возможности появляются у пользователя, какие операции автоматизируются при использовании программного продукта.

   2. В раздел 5.1 на должны быть включены основные функции резидентной программы, которые соответствуют варианту задания (для русификатора клавиатуры - "программа должна обеспечивать переключение в режим ввода русских символов", " программа должна обеспечивать переключение в режим ввода латинских символов " и т.д.). Эти основные функции должны быть размещены в начале раздела 5.1. Кроме того, должны быть отражены и дополнительные функции (загрузка, выгрузка и т.д.).

   3. Все позиции в ТЗ (для ссылок на них) должны быть пронумерованы с помощью многоуровневой нумерации (5.1.1, 5.1.2 и т.д.)

   4. В разделах п.7 и п.10 информация может отсутствовать.

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

1. Описание применения (ОП) программного продукта (данные документ ориентируется на потенциального пользователя ПП и потенциального покупателя ПП). Документ должен отвечать на вопросы, как и при каких условиях можно использовать ПП. Условно можно считать, что данный документ имеет рекламное назначение: прочитав документ, пользователь должен оценить возможности программного продукта и определиться с его приобретением.

1. Структура оглавления описания применения:

1. НАЗНАЧЕНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2. ВОЗМОЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

4. УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

4.1. Требования к составу и параметрам технических средств

4.2. Требования к информационной совместимости

4.3. Требования к маркировке и упаковке

4.4. Требования к хранению

5. ОБЩИЕ ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1. Стиль изложения описание применения должен быть скорее описательным ("программа имеет возможности …", "программа работает в среде ДОС, WINDOWS …", "Система позволяет автоматизировать …", "Объекты, создаваемые на основе классов, обеспечивают построение …" и т.д.)

2. Главные требования к основным разделам описания применения (на выполнение этих требований будет обращаться повышенное внимание при предъявлении ПП):

   1. В п.1 дается более подробное, чем в ТЗ, назначение разрабатываемого программного продукта (ПП). Стиль должен быть простым и ориентированным на неподготовленного пользователя, как в рекламных объявлениях и рекламной информации. Документ может быть ориентирован на менеджеров и руководящих работников.

   2. В п.2 приводятся все положительные свойства ПП, с пояснением, если нужно, условий функционирования и выгод его использования по сравнению с подобными программными продуктами.

   3. В п.3 приводятся основные технические характеристики ПП. Эти характеристики можно оформить, для наглядности, в виде таблицы. Здесь отображаются: размеры используемой оперативной памяти, задействованные прерывания, ограничения на возможности создания объектов на основе системы классов (для нашего случая), объемы в ОП и т.д., все, что характеризует и отличает данный программный продукт. Можно давать сравнительные характеристики по сравнению с аналогичными программными продуктами.

   4. В п.4 приводятся все ограничения и требования к применению ПП. В частности в п.4.1 отображается тип кодировки символов (для русификаторов), типы форматы файлов для хранения информации и т.д., в зависимости от назначения и конструкции ПП.

   5. В п.5 сведены общие и самые существенные характеристики ПП из предыдущих разделов. Эту информацию желательно тоже оформить в виде таблицы.

1. Техническое описание (ТО) программного продукта. Это фактически материалы технического проектирования ПП. Описывается конструкция (модульный состав и связи). Здесь должно быть описано: как устроен ПП, как он сделан, из каких частей состоит, какие связи есть, какие внешние данные использует и т.д. В данном документе даются все необходимые диаграммы для описания ПО: блок-схемы алгоритмов (можно ссылаться на листы), диаграммы классов, временные диаграммы, диаграммы состояний и т.д. Документ предназначен для разработчиков или специалистов, которые будут сопровождать программный продукт или его модифицировать.

   1. Структура оглавления и содержание технического описания (она сильно зависит от самого ПП, его конструкции и его частей). Для нашего случая резидентной программы ТО (СП) и системы классов (ООП) оглавление может включать следующие разделы:

   2. СП

1. ОБЩИЕ СВЕДЕНИЯ О ПРОГРАММНОМ ОБЕСПЕЧЕНИИ

2. МОДУЛЬНАЯ СТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3. ОПИСАНИЕ МОДУЛЕЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

4. ДАННЫЕ И ФАЙЛЫ ДАННЫХ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5. ОСНОВНЫЕ АЛГОРИТМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6. ПРОЦЕДУРЫ И ФУНКЦИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

7. ВЕКТОРА ПРЕРЫВАНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ПЕРЕОПРЕДЕЛЯЕМЫЕ В ПРОГРАММЕ

1. ООП

1. ОБЩИЕ СВЕДЕНИЯ О ПО

2. МОДУЛЬНАЯ СТРУКТУРА ПО

3. ДИАГРАММА КЛАССОВ ПО

4. ОПИСАНИЕ МЕТОДОВ И ДАННЫХ КЛАССОВ ПО

5. ДАННЫЕ И ФАЙЛЫ ДАННЫХ ПО

6. ОСНОВНЫЕ АЛГОРИТМЫ МЕТОДОВ КЛАССОВ ПО

7. ОПИСАНИЕ ПРОЦЕДУР И ФУНКЦИЙ ПО

8. КЛАССЫ ПЕРЕОПРЕДЕЛЯЕМЫЕ В ПО

1. Стиль изложения должен быть описательным, но основан на техническом языке, принятом программистами и специалистами по разработке ПП (программистский жаргон недопустим). Например, "файл имеет следующую структуру: …", "Процедура … имеет следующие входные и выходные параметры …", "класс имеет следующее назначение", "создаваемые объекты могут …" и т.д. Материал может быть организован в виде таблиц и диаграмм.

2. Главные требования к основным разделам технического описания ПП (на выполнение этих требований будет обращаться повышенное внимание при предъявлении ПП). Ниже требования, характерные для нашего конкретного случая КР/ДЗ:

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

   2. (СП) В п.2 приводится описание структуры программы, дается перечень и связность модулей (исходных, объектных и библиотек). В нашем случае это будет модули и процедуры. Если используются разные файлы, то дается их описание и назначение.

   3. ( ООП) В п.2 приводится описание структуры ПО, дается перечень и связность модулей (исходных, объектных, библиотек и включаемых). В нашем случае это будет описание классов и их реализация. Если используются разные файлы, то дается их описание и назначение.

   4. (СП) В п.3 дается детальное краткое описание отдельных процедур, включая имена, данные, файлы, конструкцию классов, их назначение (параметры процедур, описание типа и назначения возврата функций). Дается ссылка на листы с алгоритмами и блок-схемами, если эти описания вынесены отдельно.

   5. (ООП) В п.3 дается детальное краткое описание отдельных процедур, включая имена, данные, файлы, конструкцию классов, их назначение (параметры процедур, описание типа и назначения возврата функций)..

Примечание: Материалы с описанием процедур и членов классов необходимо размещать в специальной таблицы с графами типа: название процедуры, способ обращения, входные параметры, выходные параметры, назначение, примечание и т.д.

1. (ООП) Если класс наследует свойства базового класса, то нельзя делать ссылки на базовый класс, а повторить описание данных и методов.

2. (СП) В п.4 даются описания всех общих (глобальных) для всех модулей данных (переменных, структур, файлов), используемых в программе (расположение классов в файлах-модулях). Описываются связи между модулями: внешние (EXTRN) и доступные (PUBLIC) данные исходного модуля. Здесь могут быть отражены: наименования, типы данных класса, структуры данных и файлов, возможные значения полей данных и наличие первоначальной инициализации данных и т.д. Предпочтительное описание данных в виде таблиц.

3. (СП и ООП) В п.5/6 дается общее описание алгоритмов функционирования процедур, если эти алгоритмы имеют уникальный характер. В частности должно быть приведено описание блок-схем программ методов, которые должны быть представлены в виде приложении к документу ТО.

4. (СП и ООП) В п.6/7 должны быть описаны все процедуры и функции ПП. Описание каждой функции сводиться в таблицу, в которой отображаются: входные, промежуточные и выходные данные процедур (как в п.4).

5. (ООП) Приводится краткое описание классов переопределяемых в программе и дается ссылка о том, в каких библиотеках базовые классы описаны.

1. Исходный текст всех программ ПО.

   1. Исходный текст должен быть представлен в формате распечатки языка Ассемблера (или исходных модулей на С++, в зависимости от типа задания).

   2. В тексте должны быть комментарии (но не на каждой строке). Комментарии должны помогать ориентироваться разработчикам в исходном тексте программы. Должны быть выделены процедуры, для которых в комментариях выделяются: назначение, входные и выходные параметры методов, если это необходимо.

Примечание: Если Вы комментируете каждую строку исходного текста, то у проверяющего создается мнение, что Вы не самостоятельно выполнили эту разработку. Он предполагает, что данная разработка выполнена другим программистом, а комментарии сделаны для ответов и трактуются как шпаргалки!

1. Распечатку текста (листинг на ассемблере) лучше выполнять либо в текстовом формате, либо использовать непропорциональный шрифт для текстового редактора (MS WORD).

2. В исходном тексте программы и строковых константах программы русские буквы должны отображаться корректно. Использование транслитерации не допускается!

1. Программа и методика испытаний (ПМИ) для сдачи программного продукта по ТЗ. Данный документ ориентирован на заказчика, который будет выполнять приемку программного продукта. Возможны различные варианты построения документа (ПМИ), который устанавливается по соглашению с заказчиком: приемка на основе проверки выполнения пунктов ТЗ (5 раздел ТЗ в первую очередь); приемка ориентированная на проверку работоспособности системы; комбинированная приемка по ТЗ и работоспособности и т.д. Для нашего случая используется вариант приемки на основе пунктов ТЗ и проверки работоспособности системы, поэтому, отметим еще раз, что в ТЗ все позиции должны быть пронумерованы, для того, чтобы на них можно было ссылаться в ПМИ.

   1. Структура оглавления программы и методики:

1. ОБЪЕКТ ИСПЫТАНИЙ