Требования к домашнему заданию по дисциплине СП
(2 курс 4-й семестр)
“Разработка ТЗ для КР по резидентной программе (TSR)”
Содержание и цель домашнего задания
В этом семестре вы выполняете курсовую работу (изменился учебный план), поэтому отдельного домашнего задания нет в программе. ДЗ выполняется в рамках КР, включено в нее. Методические материалы по ДЗ я не убираю с сайта, так как они могут быть вам полезны для выполнения КР.
Цель выполнения домашнего задания по дисциплине Системное программирование заключается в разработке технического задания (ТЗ) для курсовой работы по этой дисциплине, выполняемой в семестре (4-й семестр). Техническое задание разрабатывается в соответствии с требованиями. Студенты получают навыки разработки проектного документа, а также разбираются в теме своего задания.
Требования к курсовой работе представлены в отдельном документе на сайте и продублированы в данном документе. Требования к оформлению ТЗ и другим документам, также размещены в отдельном документе на сайте. Основные требования к ТЗ размещены также ниже.
В приложении 2 (смотрите в конце данного документа) приведены общие понятия и сведения, необходимы для разработки программной документации (ПД) для ДЗ/КР.
Требования к разработке и оформлению ТЗ
Общие требования к документам. Студент должен знать и понимать назначение каждого документа, четко отвечать на вопрос, для какой категории пользователя он предназначен. Также нужно четко представлять основной смысл документа и различать особенности стиля изложения каждого документа (эта информация есть в данных методических указаниях). В конце данного документа смотрите более развернутые требования и пояснения к особенностям разработки ТЗ.
Требования к техническому заданию (ТЗ) на разработку программного продукта (заказчик – преподаватель, исполнитель - студент).
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. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ
8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ
8.1. Сроки выполнения отдельных этапов работ
9. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ЗАДАНИЯ
9.1. Требования к сдаче и условия приемки
10. ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ
2.2 Стиль изложения ТЗ – декларативный (предписывающий): все предложения должны соответствовать предписывающему стилю ("программа должна обеспечивать …" или "в процедуре необходимо обеспечить" или "система должна выполнять" и т. д.).
2.3 Главные требования к основным разделам ТЗ (на выполнение этих требований будет обращаться повышенное внимание при предъявлении программ):
2.3.1 В пункте 3 (НАЗНАЧЕНИЕ РАЗРАБОТКИ) очень кратко (2-3 предложения) формулируется назначение разработки: какие преимущества возникают при его применении, какие новые возможности появляются у пользователя, какие операции автоматизируются при использовании программного продукта.
2.3.2. В раздел 5.1 на должны быть включены основные функции резидентной программы, которые соответствуют варианту задания (для русификатора клавиатуры - "программа должна обеспечивать переключение в режим ввода русских символов", " программа должна обеспечивать переключение в режим ввода латинских символов " и т. д.). Эти основные функции должны быть размещены в начале раздела 5.1. Кроме того, должны быть отражены и дополнительные функции (загрузка, выгрузка и т. д.).
2.3.3. Все позиции в ТЗ (для ссылок на них) должны быть пронумерованы с помощью многоуровневой нумерации (5.1.1, 5.1.2 и т. д.)
2.3.4. В разделах п.7 и п.10 информация может отсутствовать.
2.3.5. В раздел 5 могут быть добавлены новые позиции по соглашению с заказчиком (Например, функции защиты информации, безопасность использования программного и технического обеспечения и т. д.).
2.3.6. Титульный лист ТЗ представлен в приложении к данному документу.
Ниже приведены общие методические указания для разработки курсовой работы 5-го семестра. Варианты, выданные студентам в 4-м семестре, действительны и для следующего семестра, их изменять не нужно, даже если списки изменятся. Если студент включен в список заново, то вариант для выполнения КР он получает отдельно у преподавателя. Для получения полной картины нужно познакомиться с вариантами и требованиями к курсовой работе по СП (для 5-го семестра). Вся информация приведена на сайте. Кроме того, там представлен отдельный документ – требования к документации на КР. Здесь мы приведем общие сведения, характеризующие КР по СП.
Содержание и цель курсовой работы 4-го семестра
Цель выполнения курсовой работы заключается в изучении механизмов написания резидентных программ на языке Ассемблер, освоения навыков тестирования и отладки программных модулей, а также оформления комплекта документации на системные программные продукты.
В курсовой работе студентов 3 курса должна быть разработана резидентная программа на языке Ассемблер PC, оформлена документация на программу и изготовлена конструкторская документация в виде 3 листов формата А1. Варианты курсовой работы определяются номером в списке официального журнала старосты и уточняются у преподавателя.
Резидентная программа должна выполняться под управлением MS DOS версии не ниже 6.21 или в режиме эмуляции ДОС для ОС класса WINDOWS (в режиме командной строки) или в эмуляторе DosBox для Windows 7 и 64-ти разрядных процессоров.
Студенты выполняют сдачу программ и документации курсовой работы на основе программы методики испытаний, демонстрации знаний языка Ассемблер, устройства современных операционных систем и технического обеспечения компьютеров.
Общие требования к резидентной программе
Резидентная программы должна удовлетворять следующим основным требованиям, а именно (эти требования определяют состав ТЗ раздела функциональные характеристики, необходимо не забыть, кроме того, функции собственного варианта задания):
· Программа должны выполнять совокупность функций заданных вариантом (см. варианты заданий для курсовой работы в отдельном файле). Данные функции разрабатываются студентом, конкретизируются и обязательно должны быть отражены в техническом задании на КР.
· Обеспечивать загрузку в оперативную память (ОП) с фиксацией в виде резидента (TSR программы), для чего используются специальные функции и прерывания ДОС;
· Обеспечивать сохранение и вызов старого драйвера (TSR программы) по данному прерыванию, если такой драйвер был ранее установлен в операционной среде;
· Выполнять проверку повторности загрузки данного резидента, выдавая при повторной загрузке специальное сообщение на экран дисплея;
· Выдавать справку по своей работе программы при задании ключа “/?” при запуске в режиме командной строки, при этом проверка повторности и загрузка резидента не производиться;
· Обеспечивать выгрузку резидентной программы с полным освобождением ОП. Должна выгружаться как резидентная часть программы (ее тело) так и PSP – окружение программы (варианты технологии выгрузки программ определяются по группам, контроль освобождения ОП выполняется утилитой MEM по числу свободных байтов до и после выгрузки из памяти).
· При выгрузке программа должна корректно восстанавливать старый обработчик данного прерывания;
· Программа должна выдавать сообщение о своем завершении, очистки ОП и восстановлении старых резидентных программ;
· Программа оформляется в формате *.СОМ – файла (исполнимого модуля).
· В программе методике испытаний (отдельный документ, см. ниже) должны быть четко определены условия проведения испытаний программы на соответствие ТЗ.
Специальные требования вариантов
В курсовой работе, выполняемой по обязательному варианту, по СП студент должен разработать резидентную программу, обеспечивающую выполнение следующие функциональные действия (помимо общих требований к КР):
1. При нажатии заданной клавиши (Fx) вывести через заданное число секунд (n -секунд) в указанное место экрана (низ, верх или центр) текстовое сообщение, содержащее: ФИО студента, индекс группы и номер варианта КР.
2. При нажатии заданной клавиши (Fx) модифицировать изображение заданной русской буквы (<буква>) из обычного шрифта в курсив и обратно в обычный шрифт при повторном нажатии клавиши.
3. При нажатии заданной клавиши (Fx) включить режим русификации клавиатуры для пяти русских букв (по варианту) и выключить его при повторном нажатии функциональной клавиши (Fx).
4. При нажатии заданной клавиши (Fx) ограничить ввод (клавиатура не реагирует) или выполнить замену одних символов, выводимых на экран, на другие символы или звездочку (“*”). При повторном нажатии клавиши (Fx) обычный режим ввода восстанавливается. Набор русских букв для ограничения или замены выбирается из таблицы (поз. 3). Латинские буквы - по клавишам соответствующим этим русским буквам.
Более подробно см. таблицы из документа с вариантами. При выполнении обязательного варианта с дополнительными требованиями необходимо реализовать, помимо перечисленных выше требований, и новые требования. В собственных новых темах, в той или иной степени, основные требования должны присутствовать.
Примечание: В ТЗ должны быть обязательно отражены функции ПО программного изделия в соответствии с собственным вариантом, они должным быть основными и размещены в начале раздела ТЗ №5. Технические требования в пункте 5.1 “Требования к выполняемым функциям”. Кроме того, в процессе проектирования программы и ТЗ, могут появиться дополнительные функции, которые также необходимо отобразить в документации и ТЗ на КР.
Возможности выбора вариантов
Курсовая работа по дисциплине СП выполняется студентами индивидуально основе вариантов по списку группы (в журнале группы текущего семестра). Возможны следующие способы утверждения тем курсовой работы:
1. Курсовая работа выполняется по типовому заданию, в котором уточняются отдельные параметры выполнения работы (клавиши, буквы и т. д.) – такой вариант включен в таблицу обязательных заданий. На титульном листе ПЗ в этом случае помечается - Обязательные варианты.
2. Курсовая работа выполняется на основе обязательного варианта с включением дополнительных требований – таблица дополнительных требований к обязательным вариантам. Выбор дополнительных требований производится по согласованию с преподавателем, но не более одного варианта в потоке 2-го курса. На титульном листе ПЗ в этом случае помечается - Обязательные варианты с дополнительными требованиями.
3. Курсовая работа выполняется на основе дополнительных тем – таблица дополнительных тем. На титульном листе ПЗ в этом случае помечается - Дополнительные темы.
4. Студент может предложить собственную тему, которая не входит ни в одну таблицу тем, заданных преподавателем, но степень сложности такой темы должна соответствовать сложности тем из раздела дополнительных тем. Согласование тем производиться у преподавателя (до 4-й недели включительно). На титульном листе ПЗ в этом случае помечается - Согласованные дополнительные темы
Документация по разработке
Требования к содержанию и форме разрабатываемых документов изложены в специальных методических указаниях, которые предоставляются студентам и размещены на сайте. Разрабатываемая в рамках КР документация должна включать (детальное описание требований к разрабатываемой документации смотрите в специальном документе, размещенном на сайте):
· Техническое задание на разработку программы резидента (техническое задание должно содержать, помимо общих, и конкретные пункты ТЗ для варианта задания, причем эти пункты должны быть первыми в перечне функциональных требований).
· Описание применения ПО.
· Техническое описание программы ПО (описание всех процедур, их входных и выходных параметров, программ и структур данных, включая описание модульной структуры и блок-схем программ, которые выносятся на листы).
· Текст программы в виде листинга, выдаваемого Ассемблером. Только так, распечатка исходного текста программы без листинга Ассемблера не будет приниматься.
· Руководство системного программиста (в том числе обязательно: состав ПО, системные требования к ОС, используемые прерывания, требования к развертыванию и удалению программного обеспечения).
· Руководство пользователя: все от "А" до "Я" по работе пользователя, включая инструкцию командной строки в БНФ. (Бэкуса Нормальная Форма/Бэкуса-Наура Форма - сохранилось две расшифровки этой аббревиатуры). Инструкция должна быть понятна пользователю, и ориентирована именно на такого пользователя, которому функционально предназначен программный продукт. Должны быть приведены примеры запуска и использования программы.
· Программа и методика испытаний (основное - в виде таблицы для проверки всех пунктов ТЗ со ссылкой на них, обязательно условия проведения испытаний и результат выполнения пункта). Обязательно должны быть отражены название испытуемого изделия и программы, условия проведения испытаний, действия для проверки и результаты этих действий (вплоть до нажатия отдельных клавиш). ПМИ разрабатывается для отдельной проверки выполнения каждого пункта ТЗ и работоспособности.
· 3 листа формата А3 или А2 (см. Ниже), поясняющих конструкцию и работу программы.
· Дискета или CD с исходными и загузочными текстами, документацией и резидентной программой готовой к выполнению, откомпилированная для режима ДОС. Дискетки можно взять у преподавателя.
Документация оформляется в соответствии с ГОСТ. Все документы должны иметь отдельный титульный лист (форма титульного листа дана в документе – требования к документации), оформленный по требованиям кафедры. Уточнить требования к КР и оформлению документации можно на консультациях, а на отдельной лекции я постараюсь дать дополнительные пояснения этих требований.
Листы курсовой работы
В курсовой работе разрабатывается 3 листа, конструкторской документации. Листы могут быть выполнены в машинном исполнении, только в этом случае допускается их распечатка на бумаге формата А4 (можно использовать MS Visio (предпочтительно), MetaDesign, CorelDraw и других пакеты).
В листах должно быть отражено:
· Блок схемы алгоритмов программы и процедур (обязательно);
· Модульная структура программы (обязательно);
· Схема взаимодействия резидентной программы с аппаратурой, в которой отражаются: вектор прерываний, резидентные и фоновые программные компоненты, клавиатура компьютера, области памяти где расположены программы и данные, микропроцессор компьютера, технические компоненты, которыми связана программа и др. (обязательно). Разработанная схема должна быть уникальной для конкретного проекта и описана в специальном разделе технического описания. При защите КР студент должен четко пояснить по ней работу собственной программы (пример обобщенной схемы теперь размещен на сайте! Ее необходимо осмыслить и доработать до своего варианта).
· Описание пользовательского интерфейса в виде инструкции командной строки или графа диалога (при наличии), если это не выноситься на лист, то должно быть отражено в руководстве пользователя;
· Структуры данных, используемые в программе (при наличии таковых), структуры файлов, массивов, записей и др.
Требования к выполнению работы
Работа выполняется индивидуально каждым студентом. При выполнении работы может быть использован любой доступный компилятор (QC25, masm, tasm и др. любых версий). При разработке программ и процедур должен использоваться отладчик (либо встроенный в QC или автономный –TD, CV).
Варианты выполнения работы
Варианты выполнения работы по номерам списков студентов в группах (по журналу старосты) приведены в документе - (Var3_kr.zip – см. на сайте), а требования к КР в документе (Treb3_kr. zip - см. на сайте). Нужно внимательно проверить дату документа вариантов, для того чтобы вариант был правильным для текущего семестра.
По согласованию с преподавателем (доц. ) тема может быть изменена или уточнена (до 8-й недели 4-го семестра).
По согласованию с преподавателем (доц. ) студент может выбрать тему из раздела дополнительных требований (до 8-й недели 4-го семестра). В этом случае из студентов (не более 3-х) допускается организовать группу разработки и реализации задачи. За каждым студентом в этом случае закрепляется отдельная подсистема резидента.
Курсовая работа по дисциплине СП выполняется студентами индивидуально основе вариантов по списку группы (в журнале группы текущего семестра). Возможны следующие способы утверждения тем курсовой работы:
5. Курсовая работа выполняется по типовому заданию, в котором уточняются отдельные параметры выполнения работы (клавиши, буквы и т. д.) – такой вариант включен в таблицу обязательных заданий. Обязательные варианты.
6. Курсовая работа выполняется на основе обязательного варианта с включением дополнительных требований – таблица дополнительных требований к обязательным вариантам. Выбор дополнительных требований производится по согласованию с преподавателем, но не более одного варианта в потоке 2-го курса. Обязательные варианты с дополнительными требованиями.
7. Курсовая работа выполняется на основе дополнительных тем – таблица дополнительных тем. Дополнительные темы.
8. Студент может предложить собственную тему, которая не входит ни в одну таблицу тем заданных преподавателем, но степень сложности такой темы должна соответствовать сложности тем из раздела дополнительных тем. Согласование тем производиться у преподавателя. Согласованные дополнительные темы
На титульном листе ТЗ курсовой работы должен быть отмечен один из вариантов назначения темы КР по СП (выделено жирным и подчеркнуто!).
В курсовой работе, выполняемой по обязательному варианту, по СП студент должен разработать резидентную программу, обеспечивающую выполнение следующие функциональные действия (помимо общих требований к КР):
1. При нажатии заданной клавиши (Fx) вывести через заданное число секунд (n -секунд) в указанное место экрана (низ, верх или центр) текстовое сообщение, содержащее: ФИО студента, индекс группы и номер варианта КР.
2. При нажатии заданной клавиши (Fx) модифицировать изображение заданной русской буквы (<буква>) из обычного шрифта в курсив и обратно в обычный шрифт при повторном нажатии клавиши.
3. При нажатии заданной клавиши (Fx) включить режим русификации клавиатуры для пяти русских букв (по варианту) и выключить его при повторном нажатии функциональной клавиши (Fx).
4. При нажатии заданной клавиши (Fx) ограничить ввод (клавиатура не реагирует) или выполнить замену одних символов, выводимых на экран, на другие символы или звездочку (“*”). При повторном нажатии клавиши (Fx) обычный режим ввода восстанавливается. Набор русских букв для ограничения или замены выбирается из таблицы (поз. 3). Латинские буквы - по клавишам соответствующим этим русским буквам.
При выполнении обязательного варианта с дополнительными требованиями необходимо реализовать, помимо перечисленных выше требований, и новые требования. В собственных новых темах, в той или иной степени, основные требования должны присутствовать.
По группам 41,42,43 и 44 введены специальные требования:
ИУ5-41 - резидентная программа должна выгружаться при повторном запуске программы без параметров.
ИУ5-42 - резидентная программа должна выгружаться по горячей клавише Ctrl+u/U.
ИУ5-43 - резидентная программа должна выгружаться при запуске специально разработанной на языке Ассемблер собственной утилиты - UNLDTSR. EXE.
ИУ5-44 - резидентная программа должна выгружаться по ключу “/U” или “/u” при повторном запуске в командной строке.
Уточнение тем КР производится на консультациях до 8-й недели 4-го семестра.
ГРУППА СУЦ – выполняет требования по варианту 1-й группы.
Примечание 2: Темы с дополнительными требованиями могут быть выбраны сильными студентами по согласованию с лектором. Для сложных вариантом может быть, также по предварительной договоренности с преподавателем создана группа (до 3-х студентов), которая совместно выполняет одну тему проекта. В этом случае за каждым участником проекта закрепляется отдельная подсистема и функция в группе проектирования.
Литература для выполнения КР
1. Данные методические указания.
2. Требования к оформлению документации (см. на сайте).
3. Лекции по курсу СП
4. Список литературы по дисциплине (дан на сайте). Особо рекомендую книги Финогенова К. Г. (п. п. 1-3). В частности:
5. “Самоучитель по системным функциям MSDOS”-М.,РиС, Энтроп, 1995 г.
6. , “Программирование на языке ассемблера IBM PC” Обнинск, Принтер, 1997г.
7. , “Основы программирования на языке ассемблера IBM PC Части 1-4” Обнинск, Принтер, 1995г.
8. Р. Джордейн “Справочник программиста персональных компьютеров типа IBM PC”- М.,ФиС, 1991г.
9. Другая литература по дисциплине (см. список литературы к дисциплине и книги на сайте).
10. Методическое пособие для выполнения лабораторных работ и КР по дисциплине СП (2012) – на сайте дисциплины
11. Другие материалы и литература с сайта.
12. Другая литература по дисциплине СП.
13. Список литературы по курсу (на сайте)
Сроки и Защита курсовой работы
Защита курсовой работы производится по предоставлению полного комплекта документации, листов, исходных и загрузочных текстов программ на дискете. Сдача работающей программы обязательна и выполняется на основе ТЗ и утвержденной программы и методики испытаний. На защите задаются вопросы по работе и по лекционному материалу и любые вопросы по листингу программы.
Сроки выполнения работы и ее сдачи:
4-й Семестр:
Получение и уточнение задания 5 неделя 4-го семестра
Разработка ТЗ на КР в виде ДЗ - 6-7 неделя 4-го семестра
Разработка программ и проектирование 1-6 недели 4-го семестра;
Кодирование и отладка 7-11 недели 4-го семестра;
Разработка документации 11-12 недели 4-го семестра;
Защита и проведение испытаний 13-14 недели 4-го семестра.
Время консультаций по курсовой работе назначается преподавателем по согласованию со старостами групп. Консультации по курсовому проектированию проводит преподаватель. Время консультаций согласовывается со старостами групп отдельно. Консультации в Интернет, в оперативном режиме проводятся по адресу: www.sergebolshakov.ru => 2-й курс => Методические материалы => Консультации => “Консультации по дисциплине СП”. Постараюсь оперативно отвечать на ваши вопросы.
Защита курсовой работы принимается только лектором по дисциплине СП.
При обнаружении на дискетах студента и в программах курсовых и лабораторных работ вирусов любой породы, оценка студенту на экзамене и за курсовую работу снижается на один балл!!!
ЕДИНЫЙ ТИТУЛЬНЫЙ ЛИСТ ДЛЯ ВСЕХ ДОКУМЕНТОВ ПРИВЕДЕН НА СЛЕДУЮЩЕЙ СТРАНИЦЕ!!!
Приложение 1 Титульный лист ТЗ
_______________________________________________________________
Московский государственный технический университет им.
_______________________________________________________________
Утверждаю: | |
| "__"_____________2014 г. |
Курсовая работа по курсу Системное программирование
“<тема варианта КР>”
Вариант №___
Техническое задание
(вид документа)
писчая бумага
(вид носителя)
15
(количество листов)
ИСПОЛНИТЕЛЬ: | |
студент группы ИУ5-41 | _____________________ |
А. | "__"_____________2014 г. |
Москва - 2014
_____________________________________________________________________
Приложение 2 Общие понятия для комплекта ПД для КР.
1. Программная документация
Любой программный проект должен сопровождаться разработкой комплекса программной документации. Время, которое затрачивается на разработку такой документации соизмеримо со временем самой программной разработки (не менее 50% времени всего проектирования). Иногда это время превышает время программирования и отладки проекта. Некоторые документы разрабатываются до начала разработки. Например, техническое задание (ТЗ) на программную разработку. Без создания грамотного ТЗ проект вообще нереализуем или, скорее всего, не будет успешным. Кроме того, без хорошо разработанного технического задания, невозможно успешно предъявить и сдать работу заказчику, а также, успешно закрыть работу по проекту (включая и получения оплаты за выполненную работу). Программисты (или специальные разработчики документации) разрабатывая документы, по сути, являются “техническими писателями”, а освоение таких умений является неотъемлемой частью получаемых навыков в рамках подготовки по нашей специальности.
2. Программная документация, разрабатываемая в ДЗ/КР
Для получения основных навыков в разработке технической документации на программное обеспечение выбраны главные документы из значительного множества документов, требуемых в ГОСТ [8]. Этот комплект документов содержит следующие документы:
- Техническое задание (ТЗ);
- Описание применения программного продукта (ОП);
- Техническое описание программного продукта (ТО);
- Руководство пользователя (РП);
- Руководство системного программиста (РСП);
- Исходные тексты программ (ИТ);
- Программа и методика испытаний на основе тестового примера (ПМИ);
- Три листа формата А1.
В рамках домашнего задания и КР студенты должны разработать весь комплект документации на программный продукт, разрабатываемый по их варианту (ТЗ – 4-й семестр, ПД – 5-й семестр).
3. Особенности и принципы разработки программной документации
При разработке ПД важно учесть следующие обстоятельства, связанные с каждым конкретным типом документации:
- Кто из участников процесса разрабатывает данный документ ПД.
- Для кого разрабатывается данный документ ПД
- Каков стиль изложения данного документа ПД
- Каково содержание данного документа ПД
- На каком этапе проектирования разрабатывается данный документ ПД
- Каковы требования к данному документу.
Четкие ответы на перечисленные вопросы должны быть у каждого разработчика данного документа. В процессе разработки документации на программный продукт могут участвовать следующие группы и разновидности специалистов:
- Руководители проекта.
- Разработчики программисты (или исполнители проекта).
- Заказчики проекта (согласование ПД и разработка ТЗ).
- Пользователи разрабатываемого программного обеспечения (ПО).
- Системные программисты, устанавливающие ПО для пользователя.
- Технические писатели (разработчики технической документации).
Эти специалисты могут выполнять следующие роли по отношению к документам комплекта ПД: писать или разрабатывать документы, контролировать содержание документов, согласовывать (подписывать) документы и утверждать документы (подписание документа). В нашем случае, в игровом/ролевом обучающем режиме, студенты могут выполнять разные роли: руководителей, писателей и разработчиков, а преподаватели – роль заказчиков проекта.
В ПД на ДЗ и КР по СП студенты должны реализовать особенности, применительно к каждому типу рассматриваемого документа. Здесь выделим общие особенности стиля изложения и разработки ПД:
- Документы должны содержать информацию, имеющую отношение только к данному проекту и данному документу.
- Документы должны быть написаны на техническом языке и не должны содержать неопределенности и неоднозначности.
- Документы должны быть написаны короткими понятными предложениями, и они должны включать минимум распространенных предложений (с придаточными предложениями).
- Стиль документа должен соответствовать стилю документа данного типа.
- Документы не должны содержать “воды” и отступлений от содержания. Никакой “лирики”!
- Все пункты должны быть пронумерованы (разделы, позиции и т. д.) и допускать ссылки из других документов, и сами однозначно ссылаться на пункты других документов ПД. Не допускается перечисления в виде маркированных списков (bullets), только цифровая многоуровневая нумерация.
- При ссылках на другие документы должны указываться прямые ссылки, содержащие: полное название документа и позицию (пункт), на который производиться ссылка.
- В пределах всего проекта устанавливаются требования к оформлению документов: редактор текста, шрифт, кегль шрифта, интервал, способы форматирования текста, размеры страниц, содержание колонтитулов, способы рисования иллюстраций документа (рисунков), обязательная нумерация страниц в документе.
4. Требования к оформлению ПД в ДЗ/КР
В нашем случае требования к оформлению следующие:
- Текстовый редактор - MS WORD (не Open Office!),
- Шрифт - Times New Roman.
- Кегль шрифта - 12,
- Интервал между строками - одинарный,
- Способы форматирования текста – по ширине,
- Размеры страниц – А4 (верх - 2 , низ - 2 , слева - 3 , справа - 2),
- Содержание колонтитулов (вариант, группа, ФИО студента),
- Способы рисования иллюстраций документа (Предпочтительнее MS Visio можно MS WORD),
- Нумерация страниц – центр – верх.
Данные требования необходимо соблюдать при разработке всех документов домашнего задания и КР.
5. Документ техническое задание (ТЗ) и его назначение
Документ техническое задание (ТЗ) разрабатывается на ранних этапах проектирования программного продукта и содержит требования к разработке: функции, сроки, требования к продукту в различных аспектах и порядок их реализации. Этот документ является важнейшим и иногда разрабатывается до заключения финансового договора с заказчиком. Считается, что после утверждения ТЗ (его подписания сторонами), оно может быть изменено только по обоюдному согласию заказчика и разработчика и только в определенном порядке.
Документ ТЗ разрабатывается совместно заказчиком и разработчиками (руководителем проекта и исполнителями) и утверждается (подписывается). После этого, не выполнение отдельных пунктов ТЗ может являться основанием для расторжения договора (по закону). Более того, утверждается, что невыполнение ТЗ преследуется по закону.
Примечание. Студенты часто стараются разработать ТЗ после завершения разработки. Это не правильно, так как заказчик (преподаватель у нас) может ТЗ не утвердить это очень рискованно.
ТЗ является, кроме того, основой для самой разработки и основой для разработки других документов.
6. Стиль изложения в ТЗ
Стиль изложения документа ТЗ – декларативный (предписывающий): все предложения должны соответствовать предписывающему стилю ("программа должна обеспечивать …" или "в процедуре необходимо обеспечить" или "система должна выполнять" и т. д.). Кроме этого в полной мере при разработке ТЗ нужно учесть общие требования к стилю документов.
7. Требования к ТЗ
Документ ТЗ является важнейшим документом для проектирования и реализации проектов. В частности, проведение приемно-сдаточных испытаний программного продукта основывается (см. пояснения к ЛР по “ Программе и методике испытаний ”). Поэтому все пункты требования должны быть четкими и не допускать разных трактовок. Они должны быть такими, чтобы их можно было бы проверить. В противном случае их из ТЗ нужно исключить, обоснованно доказав это заказчику.
При разработке ТЗ реально сталкиваются разнонаправленные интересы заказчиков и разработчиков (фактически возникают противоречия, которые нужно разрешить). Заказчики хотят с минимальными затратами сделать как можно больше, а разработчики хотят сделать минимум также со своими минимальными затратами трудоемкости.
8. Методические указания по разработке ТЗ
Разработка ТЗ должна производиться на ранних стадиях проектирования программных продуктов. Иногда, перед разработкой ТЗ выполняют работы по пробному макетированию отдельных частей программы или ее в целом. Макетирование технических решений позволяет проверить правильность формулировок отдельных пунктов ТЗ, определить трудоемкость и сроки выполнения работ. Результаты макетирования можно предъявить заказчику для подтверждения реальности сроков выполнения работ и пояснения согласованности и наглядности функций, возложенных на программный продукт. В макете может быть продемонстрирован интерфейс пользователя с будущей системой.
Примечание. Макет простой работающей резидентной программы приведен на сайте. Его можно посмотреть, скомпоновать и проверить его работы.
Для сложных программных разработок (программных систем) могут проводиться предварительно дополнительные научно - исследовательские работы (НИР) или опытно-конструкторские разработки (ОКР). Результатами таких работ должны быть технические предложения к разработке ТЗ на систему или сам документ ТЗ. Такой этап разработки часто называют внешним проектированием.
В любом случае, в тексте ТЗ должны содержаться такие формулировки требований, которые не ограничивают разработчика и предельно понятны заказчику. Так, например, в нашем случае не следует в разделе функциональных требований указывать имена подпрограмм, данных, номера прерываний и т. д. В процессе разработки они могут измениться, но это фактически может привести к формальному невыполнению пунктов ТЗ, на реализации которых заказчик, возможно, будет настаивать. С другой стороны, может быть внесена такая формулировка, которая понимается заказчиком и разработчиком по-разному. Это не правильно. Таких текстов в документе следует избегать.
9. Содержание ТЗ
Содержание документа ТЗ по пунктам приведено ниже:
1. НАИМЕНОВАНИЕ
2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ
3. НАЗНАЧЕНИЕ РАЗРАБОТКИ
4. ИСПОЛНИТЕЛЬ
5. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
5.1. Требования к функциональным характеристикам
5.2. Требования к программному обеспечению
5.3. Требования к условиям эксплуатации
5.4. Требования к информационному обеспечению
5.5. Требования к надежности
5.6. Требования к составу и характеристикам технических средств
5.7. Требования к программной совместимости
6. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
6.1. Разрабатываемые технические и эксплуатационные документы
7. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ
8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ
8.1. Сроки выполнения отдельных этапов работ
9. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ ЗАДАНИЯ
9.1. Требования к сдаче и условия приемки
10. ДОПОЛНИТЕЛЬНЫЕ ТРЕБОВАНИЯ
Дополнительно к методическим указаниям шаблона выделим главные требования к основным разделам ТЗ (на выполнение этих требований будет обращаться повышенное внимание при предъявлении программ и защите документов):
В пункте 3 (НАЗНАЧЕНИЕ РАЗРАБОТКИ) очень кратко (2-3 предложения) формулируется назначение разработки: какие преимущества возникают при его применении, какие новые возможности появляются у пользователя, какие операции автоматизируются при использовании программного продукта, для решения каких задач может использоваться данная система классов.
В раздел 5.1 на должны быть включены основные функции системы классов, включающие способы создания всех типов объектов, использования методов классов. Требования к функциям должны формулироваться на содержательном уровне (а не программистском). Эти основные функции должны быть размещены в начале раздела 5.1. Кроме того, должны быть отражены и дополнительные функции.
Все позиции в ТЗ (для ссылок на них) должны быть пронумерованы с помощью многоуровневой нумерации (5.1.1, 5.1.2 и т. д.). В разделах п.7 и п.10 информация может отсутствовать при выполнении ДЗ/КЛР. В раздел 5 могут быть добавлены новые позиции по соглашению с заказчиком (Например, функции защиты информации, безопасность использования программного и технического обеспечения и т. д.).
10. Раздел ТЗ – 5. Технические требования (общее)
В этом разделе ТЗ перечисляются технические требования к программному изделию. Эти требования должны быть выполнены при реализации программного проекта. Формулировки должны быть однозначными. Требования должны быть выполнимы разработчиком и проверяемы заказчиком при проведении приемно – сдаточных испытаниях. В главный раздел могут выноситься требования общего характера, которые должны быть выполнены (Смотрите шаблон и образец ТЗ).
11. Раздел ТЗ – 5.1 Требования к функциональным характеристикам
Данный раздел – один из основных документа ТЗ. Он разрабатывается на основе изучения поставленной задачи. Набор функциональных требований (или функциональных характеристик) должен быть полным. Требования не должны противоречить друг другу и ясно восприниматься заказчиком – пользователем. (Смотрите шаблон и образец ТЗ). В этом разделе не нужно забывать конкретизацию требований собственного варианта, разрабатываемого документа.
12. Разделы ТЗ – Другие технические требования
Разделы ТЗ, связанные с другими техническими требованиями, задают требования к реализации и эксплуатации программного продукта. Их правильная разработка очень важна. Здесь определяются средства реализации проекта, условия его эксплуатации, форматы данных и файлов, требования к надежности ПО. В нашем случае (ДЗ/КР) эти требования, за исключением некоторых дополнительных вариантов, могут быть одинаковыми для всех заданий. Однако их внимательно необходимо прочитать, проверить и осмыслить. (Смотрите шаблон и образец ТЗ).
13. Раздел ТЗ – требования к документации
В данном разделе определяется перечень документации, разрабатываемый в программном проекте. В нашем случае данный перечень уже задан, если необходимо для реализации проекта в него можно внести дополнения (см. дополнительные варианты). В курсовых работах и проектах в данный перечень добавляются листы: диаграммы классов и объектов, блок-схемы алгоритмов, структуры данных и т. д. В нашем случае диаграммы и блок-схемы можно оформить в виде рисунков, вставляемых в соответствующие документы. (Смотрите шаблон и образец ТЗ).
14. Раздел ТЗ – этапы сроки выполнения
Этапы и сроки выполнения ДЗ определяются учебным планом и длительностью семестра. В нашем случае приведенный список этапов и сроков можно сохранить в неизменном виде. Нужно только учесть, что формально ЛР № 12 выполняется в конце семестра, а работу над заданием необходимо начать как можно раньше. Поэтому желательно познакомиться с темой задания и разработать ТЗ в сроки, определенные в образце и шаблоне документа. (Смотрите шаблон и образец ТЗ).
15. Раздел ТЗ – порядок приема и контроля
В данном разделе ТЗ формулируются требования к приемке программного продукта. Определяются принципы проверки и его этапы. Проверка и сдача программного проекта может выполняться на основе различных принципов, и, даже, в несколько этапов:
- Проверка принципов построения продукта на макете и ТЗ (ранние стадии).
- Проверка работоспособности продукта – целенаправленно проверяется наличие ошибок в ПО (завершение разработки).
- Проверка документации на соответствие требованиям (завершение разработки).
- Выборочная проверка работоспособности на основе ТЗ и его выполнения, на основе программы и методики испытаний (ПМИ). По завершению разработки.
- Полная комплексная проверка работоспособности и документации на программный продукт. Такая проверка выполняется на основе специального согласованного документа ПМИ.
- Выборочная проверка работоспособности и документации на программный продукт. Такая проверка выполняется на основе специального согласованного документа ПМИ.
В нашем случае (сдача КР студентами) мы выполняем выборочную проверку программ и документации на основе специального документа ПМИ. В ПМИ должна быть предусмотрена возможность проверки любого пункта ТЗ на выбор. Допускаются ссылки на номера таблицы проверки, но не на все сразу. Очень важно, чтобы для проверки каждого пункта ТЗ из раздела функциональных требований, была представлена логичная методика/метод проверки (например, 2+2 = 4). Обязательно должны быть отражены результаты, выводимые на экран, а выполняемые действия должны быть конкретизированы до уровня нажатия отдельной клавиши. Причем примеры ввода и результаты должны полностью совпадать. Отсюда следует, что при составлении пунктов самого ТЗ целесообразно продумать вопросы возможности и методики проверки данного пункта.
16. Порядок изменения и корректировки ТЗ
Документ техническое задание может быть, в порядке исключения, изменен или откорректирован даже после его согласования и утверждения (подписи заказчиком и разработчиком). Для этого разрабатывается отдельный документ с названием: “Корректировка ТЗ”. Далее, после всех согласований документ может быть заново переоформлен либо документ корректировки просто прикладывается к основному ТЗ. Эти действия (переоформление или прикладывание) выполняются по обоюдному согласию разработчика и заказчика.
