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

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

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

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

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

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

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

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

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

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

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

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

Содержание документа ТЗ по пунктам приведено ниже. В образце документа ТЗ приведено ТЗ для варианта улиц и домов, описанного в общем пособии по курсу [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. Кроме того, должны быть отражены и дополнительные функции.

Все позиции в ТЗ (для ссылок на них) должны быть пронумерованы с помощью многоуровневой нумерации (5.1.1, 5.1.2 и т.д.). В разделах п.7 и п.10 информация может отсутствовать при выполнении ДЗ/КЛР. В раздел 5 могут быть добавлены новые позиции по соглашению с заказчиком (Например, функции защиты информации, безопасность использования программного и технического обеспечения и т.д.).

13 Раздел ТЗ – 5. Технические требования (общее)

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

14 Раздел ТЗ – 5.1 Требования к функциональным характеристикам

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

15 Разделы ТЗ – Другие технические требования

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

16 Раздел ТЗ – требования к документации

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

17 Раздел ТЗ – этапы сроки выполнения

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

18 Раздел ТЗ – порядок приема и контроля

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

• Проверка принципов построения продукта на макете и ТЗ (ранние стадии).

• Проверка работоспособности продукта – целенаправленно проверяется наличие ошибок в ПО (завершение разработки).

• Проверка документации на соответствие требованиям (завершение разработки).

• Выборочная проверка работоспособности на основе ТЗ и его выполнения, на основе программы и методики испытаний (ПМИ). По завершению разработки.

• Полная комплексная проверка работоспособности и документации на программный продукт. Такая проверка выполняется на основе специального согласованного документа ПМИ.

• Выборочная проверка работоспособности и документации на программный продукт. Такая проверка выполняется на основе специального согласованного документа ПМИ.

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

19 Порядок изменения и корректировки ТЗ

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

20 Порядок работы и методические указания (основные требования)

21 Прочитать и усвоить основные понятия данной лабораторной работы.

Предварительно перед началом лабораторной работы, а желательно и до ее начала в дисплейном классе, необходимо прочитать раздел этого документа “Основные понятия”. Необходимо усвоить понятия: программная документация; комплект ПД; техническое задание; “технический писатель”; требования к сути документа и его оформлению; группы специалистов, имеющих отношение к ПД; стиль изложения документа; назначение ТЗ; содержание ТЗ; стиль изложения ТЗ; требования к ТЗ; технические требования; приемно–сдаточные испытания и их разновидности; функциональные требования; макетирование и его назначение.

22 Прочитать документ требования к ДЗ/КЛР.

Нужно познакомиться с документом “Методические указания к выполнению комплексной лабораторной работы (ДЗ/КЛР)”, размещенному на сайте и/или с документом “Методические указания по ЛР ПКШ”[3]. Их найдете на закрытой страничке со ссылкой “Домашнее задание”. Необходимо составить представление о том, какой объем работ предстоит, и какую работу необходимо сделать в рамках работы над домашним заданием.

23 Определить номер своего варианта и получить тему ДЗ.

У старосты, по журналу группы определить свой номер, применительно к данному семестру. Познакомиться и переписать свою тему ДЗ к себе в тетрадь. Варианты тем представлены в данных МУ (ЛР№12) или в отдельном документе вариантов на сайте.

24 Познакомиться с требованиями к оформлению документа ТЗ.

Далее необходимо познакомиться с документом “ Методические указания для выполнения ДЗ/КЛР по дисциплине Программирование на основе классов и шаблонов кафедры ИУ5”, он размещен на сайте дисциплины. Особое внимание обратите на перечень документов и на описание документа – Техническое задание. Все полученные документы сохраните для последующей работы.

25 Проработать предметную область ДЗ/КЛР.

Выявить содержательно основные объекты, которые будут использоваться для ДЗ [6].

26 Выполнить предварительную модульную декомпозицию ПО проекта.

Присвоить названия основным модулям проекта и определить их предварительное назначение [6].

27 Познакомиться с образцом документа ТЗ.

Далее необходимо познакомится с образцом документа техническое задание, ссылка на который дана в конце настоящих методических указаний к ЛР №12. Представленный образец ТЗ соответствует теме разобранной в Общих МУ[7] и в МУ по ДЗ/КЛР[6].

(Для тех, кто ранее освоил создание проектов VS и русификацию консольного ввода и вывода хорошо следующие пункты можно пропустить).

28Создать в VS макет консольного проекта ДЗ (DZ_XXXXX_ХDD).

Для создания макета консольного проекта необходимо, на основе декомпозиции ПО:

• Запустить систему программирования VS 2005/08/10/12;

• В меню “File” выбрать пункт “New” и в подменю выбрать позицию “Project…”;

• В списке “Project types” выбрать “Visual C++/Win32”, а в списке “Templates” выбрать “Win32 Console Application”;

• В поле “Name” ввести: DZ_XXXXX_ХDD (где: XXXXX - часть шифра разработки, X – номер группы, а DD – номер варианта по журналу группы текущего семестра. Например, для студента группы ИУ5-22 с вариантом 15 и темой Street – введем – DZ_Street_215). Далее нажать “OK”;

• В новом окне мастера проектов нажать “Next”. Проверить настройки проекта: “Application Type” должно быть – “Console Application”, “Additional option” -> “Empty Project” должен быть выключен, “Add common header files”-> “MFC” и “ATL” должны быть включены.

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

• Необходимо убрать из главных моделей проекта (DZ_Street_ХDD.CPP и DZ_ Street_ХDD.H) все лишнее. Этого: в файле DZ_XXXXX_ХDD.H (у нас в примере DZ_Street_215.H) уберем все, а в файле DZ_XXXXX_ХDD.CPP (DZ_Street_215.CPP) оставим следующий текст:

#include "stdafx.h"