гр. ИУ5-22 - обязательным является перегрузка операции ввода (>>) из стандартного потока cin для элементного класса. (Пример. Класс домов). Для описания контейнерного класса необходимо использовать базовый шаблонный класс CArray.

гр. ИУ5-23 – обязательным требованием является использование дополнительной, перегруженной операций. Операция выполняет удаление объектов для контейнерного класса (использовать знак "-" - минус). (Пример. Удаление дома с улицы). Для описания контейнерного класса необходимо использовать базовый шаблонный класс CList.

гр. ИУ5-24 - обязательным является перегрузка операции вывода (<<) в стандартный поток cout для элементного класса. (Пример. Класс домов. Смотрите документ требований к КЛР). Для описания контейнерного класса необходимо использовать базовый класс CObList.

Дополнительные требования к вариантам ДЗ изложены в разделе общих требований выше.

57 Программная документация на КЛР/ДЗ

58 Программная документация

Любой программный проект должен сопровождаться разработкой комплекса программной документации. Время, которое затрачивается на разработку такой документации соизмеримо со временем самой программной разработки (не менее 50% времени всего проектирования). Иногда это время превышает время программирования и отладки проекта. Некоторые документы разрабатываются до начала разработки. Например, техническое задание (ТЗ) на программную разработку. Без создания грамотного ТЗ проект вообще нереализуем или, скорее всего, не будет успешным. Кроме того, без хорошо разработанного технического задания, невозможно успешно предъявить и сдать работу заказчику, а также, успешно закрыть работу по проекту (включая и получения оплаты за выполненную работу). Программисты (или специальные разработчики документации) разрабатывая документы, по сути, являются “техническими писателями”, а освоение таких умений является неотъемлемой частью получаемых навыков в рамках подготовки по нашей специальности.

59 Программная документация, разрабатываемая в домашнем задании

Для получения основных навыков в разработке технической документации на программное обеспечение выбраны главные документы из значительного множества документов, требуемых в ГОСТ [8]. Этот комплект документов содержит следующие документы:

• Техническое задание (ТЗ);

• Описание применения программного продукта (ОП);

• Техническое описание программного продукта (ТО);

• Руководство пользователя (РП);

• Руководство системного программиста (РСП);

• Программа и методика испытаний на основе тестового примера (ПМИ);

• Описание тестового примера (ОПТ);

• Исходные тексты программ системы классов и тестового примера (ИТ);

Последний документ (“Описание тестового примера”) может не выделяться отдельно и входить составной частью других документов: “ Руководство пользователя ”, ” Техническое описание программного продукта ”, “ Программа и методика испытаний ”. В рамках домашнего задания и КЛР студенты должны разработать весь комплект документации на программный продукт, разрабатываемый по их варианту. По каждому документу у вас предусмотрена отдельная лабораторная работа, которую вы можете выполнить и заранее в рамках часов, отводимых под самостоятельных работу студентов.

60 Особенности и принципы разработки программной документации (ПД)

При разработке ПД нужно учесть следующие обстоятельства:

• Кто из участников процесса разрабатывает данный документ ПД.

• Для кого разрабатывается данный документ ПД

• Каков стиль изложения данного документа ПД

• Каково содержание данного документа ПД

• На каком этапе проектирования разрабатывается данный документ ПД

• Каковы требования к данному документу.

Четкие ответы на перечисленные вопросы должны быть у каждого разработчика данного документа. В процессе разработки документации на программный продукт могут участвовать следующие группы и разновидности специалистов:

• Руководители проекта.

• Разработчики программисты (или исполнители проекта).

• Заказчики проекта.

• Пользователи разрабатываемого программного обеспечения (ПО).

• Системные программисты, устанавливающие ПО для пользователя.

• Технические писатели (разработчики технической документации).

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

В каждой ЛР из цикла КЛР мы рассмотрим все эти особенности, применительно к каждому типу рассматриваемого документа. Здесь выделим общие особенности стиля изложения и разработки ПД:

• Документы должны содержать информацию, имеющую отношение только к данному проекту и данному документу.

• Документы должны быть написаны на техническом языке и не должны содержать неопределенности и неоднозначности.

• Документы должны быть написаны короткими предложениями, и они должны включать минимум распространенных предложений (с придаточными предложениями).

• Стиль документа должен соответствовать стилю документа данного типа.

• Документы не должны содержать “воды” и отступлений от содержания. Никакой “лирики”.

• Все пункты должны быть пронумерованы (разделы, позиции и т.д.) и допускать ссылки из других документов. Не допускается перечисления в виде маркированных списков (bullets).

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

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

61 Требования к оформлению ПД в ДЗ

В нашем случае требования к оформлению следующие:

• Текстовый редактор - MS WORD (не Open Office!),

• Шрифт - Times New Roman.

• Кегль шрифта - 12,

• Интервал между строками - одинарный,

• Способы форматирования текста – по ширине,

• Размеры страниц – А4 (верх - 2 , низ - 2 , слева - 3 , справа - 2),

• Содержание колонтитулов (вариант, группа, ФИО студента),

• Способы рисования иллюстраций документа (Предпочтительнее MS Visio можно MS WORD),

• Нумерация страниц – центр – верх.

Данные требования необходимо соблюдать при разработке всех документов домашнего задания.

62 Техническое задание

63 Документ техническое задание (ТЗ) и его назначение

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

Документ ТЗ разрабатывается совместно заказчиком и разработчиками (руководителем проекта и исполнителями) и утверждается (подписывается). После этого, не выполнение отдельных пунктов ТЗ может являться основанием для расторжения договора (по закону). Более того, утверждается, что невыполнение ТЗ преследуется по закону.

Примечание. Студенты часто стараются разработать ТЗ после завершения разработки. Это не правильно, так как заказчик (преподаватель у нас) может ТЗ не утвердить это очень рискованно.

ТЗ является, кроме того, основой для самой разработки и основой для разработки других документов.

64 Стиль изложения в ТЗ

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

65 Требования к ТЗ

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

При разработке ТЗ реально сталкиваются разнонаправленные интересы заказчиков и разработчиков (фактически возникают противоречия, которые нужно разрешить). Заказчики хотят с минимальными затратами сделать как можно больше, а разработчики хотят сделать минимум также со своими минимальными затратами трудоемкости.

66 Разработка ТЗ

Разработка ТЗ должна производиться на ранних стадиях проектирования программных продуктов. Иногда, перед разработкой ТЗ выполняют работы по пробному макетированию отдельных частей программы или ее в целом. Макетирование технических решений позволяет проверить правильность формулировок отдельных пунктов ТЗ, определить трудоемкость и сроки выполнения работ. Результаты макетирования можно предъявить заказчику для подтверждения реальности сроков выполнения работ и пояснения согласованности и наглядности функций, возложенных на программный продукт. В макете может быть продемонстрирован интерфейс пользователя с будущей системой.

Для сложных программных разработок (программных систем) предварительно могут проводиться дополнительные научно - исследовательские работы (НИР) или опытно-конструкторские разработки (ОКР). Результатами таких работ должны быть предложения к разработке ТЗ на систему или сам документ ТЗ.

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

67 Содержание ТЗ

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

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. ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ

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

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

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