Ниже я опишу как писать каждый раздел ТЗ по ГОСТ 34.602-89.
1 Общие сведения
1.1 Полное наименование системы и ее условное обозначение
Я не рекомендую использовать два условных обозначения и не рекомендую использовать слово Система. Лучше всего использовать аббревиатуру. Во-первых, аббревиатуру не придется склонять, во-вторых, слово «Система» вы будете путать в контексте со словом «система» (особенно в заголовках разделов по ГОСТ, но гораздо хуже, если вашей Системе заказчик припишет свойства, которые вы просто упомянули для абстрактной системы). Например, писать «Полное наименование Системы и ее условное обозначение» неправильно!
Пример:
Полное наименование системы: Автоматизированная система информатизации всего.
Условное обозначение системы: АСИВ, Система. (неправильно)
Условное обозначение системы: АСИВ. (правильно)
1.2 Шифр темы или шифр (номер) договора
Шифр темы можно взять из номера договора, можно использовать аббревиатуру названия системы, вообще самый простой раздел ТЗ.
5 Ввод и вывод данных python. Команда input()
Номер договора можно исключить из раздела 1.2 (обратите внимание, что в названии раздела стоит ИЛИ, значит можно писать только что-то одно), но если он известен, смело пишите.
Пример:
Шифр темы: АСИВ.
Номер договора: №54-20АСИВ от 21.10.2016.
1.3 Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты
Очень простой раздел, но он поможет вам раздуть ТЗ на целую страницу, так как реквизитов можно понаписать очень много! Кстати, не забудьте про реквизиты!
Пример:
Полное наименование заказчика: Федеральная служба чего-нибудь.
Сокращённое название: ФСЧ.
Юридический и почтовый адрес: 111111, г. Москва, ул. Улица, д. 1Д.
Контактный телефон: .
ИНН: .
КПП: .
Расчетный счет:
а) p/c . в банке ПАО Сбербанк, г. Москва;
б) к/с . ;
в) БИК . ;
г) ОГРН . ;
д) ОКПО .
Полное наименование разработчика: Общество с ограниченной ответственностью «Крутое ПО».
Краткое наименование: ООО «Крутое ПО».
Юридический адрес: . г. Москва, ул. дом .
Почтовый адрес: . г. Москва, . дом .
Контактный телефон: 8 (499) .
ИНН: .
КПП: .
Расчетный счет:
а) p/c . в банке ПАО Сбербанк, г. Москва;
б) к/с . ;
в) БИК . ;
г) ОГРН . ;
д) ОКПО .
1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы
В перечень документов раздела 1.4 включают только НПА, ГОСТы 34 серии (кроме самого ГОСТ 34.602-89, его нужно привести в разделе 9) и вышестоящие документы-основания (для ЧТЗ документ-основание — ТЗ, для ТЗ документ-основание — Техтребования/техзадание к контракту и т.д.). Еще раз напоминаю, не пишите сюда документы, которые вы не читали и не знаете, что в них написано, особенно ГОСТы по интерфейсам человек-машина (в том числе ISOшные) и ГОСТы ИБшные (их сами ИБшники бояться!).
Пример:
Перечень документов, на основании которых создается система:
а) Федеральный закон от 6 апреля 2011 г. № . -ФЗ «. »;
б) . стратегия Российской Федерации на период до 2020 года, утвержденная приказом . № 45;
в) Федеральная целевая программа «. (2010-2020 годы)», утвержденная постановлением Правительства Российской Федерации от . ;
г) Постановление Правительства Российской Федерации от . № . «. »;
д) Распоряжение Правительства Российской Федерации от .
Еще пример:
а) решение Наблюдательного совета АО «. » (Протокол заседания Наблюдательного совета . ).
и т.п.
1.5 Плановые сроки начала и окончания работы по созданию системы
Плановые сроки начала и окончания работы по созданию Системы указываются те, что назовет РП, сами не выдумывайте!
Пример:
Плановый срок начала работ – дата заключения государственного контракта.
Плановый срок окончания работ — 31.12.2015 г.
1.6 Сведения об источниках и порядке финансирования работ
Сведения об источниках и порядке финансирования работ указываются те, что назовет РП, но можно написать про федеральный бюджет, если работы по ГК ведутся.
Пример:
Источником финансирования являются средства Заказчика.
Порядок финансирования определяется Договором.
Еще пример:
Источником финансирования являются средства федерального бюджета.
Порядок финансирования определяется Государственным контрактом.
1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы
Пример:
Порядок предъявления результатов работ по созданию АСИВ и ее испытаний определен в разделе 6 настоящего ЧТЗ. Совместно с предъявлением программного обеспечения АСИВ производится сдача разработанного Исполнителем комплекта документации согласно разделу 8 настоящего ЧТЗ.
Результаты работ передаются Заказчику в порядке, определенном контрактом в соответствии с Календарным планом работ контракта на основании Актов сдачи-приемки выполненных работ (этапа работ).
Документация АСИВ передается на бумажных (два экземпляра, один экземпляр после подписания Заказчиком должен быть возвращен Исполнителю) и на машинных носителях (CD/DVD) (DVD) (в двух экземплярах). Текстовые документы, передаваемые на машинных носителях, должны быть представлены в форматах PDF.
Все материалы передаются с сопроводительными документами Исполнителя.
Не пишите CD/DVD, для вас это означает ИЛИ, а для противного заказчика это означает «а где на CD?», если вы ему на DVD привезете или наоборот.
Формат документов лучше PDF, только в этом формате гарантированно документ в электронном виде будет соответствовать документу в бумажном.
Источник: demondima77.livejournal.com
Содержание разделов. В разделе Наименование и область применения указывают наименование, краткую характеристику области применения программы или программного изделия и объекта
В разделе Наименование и область применения указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
В разделе Основание для разработки должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от __.__. за N ___., договор __.__. за N ___., и т.п.
В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное – четко определить, для чего нужна эта программа.
Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.
Раздел Технические требования к программе или программному изделию должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.
Иными словами, здесь начинается конкретика. Описывается то, что должна делать программа и как она должна выглядеть.
Требования к функциональным характеристикам. Здесь должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.
Например: Программа должна позволять … вычислять … строить… создавать …
Исходные данные: текстовый файл с заданной …
Выходные данные: графическая и текстовая информация — результаты анализа системы…; текстовые файлы — отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.
Требования к надежности. Должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
Здесь «выгадать» что-то сложно. В лучшем случае может пройти вариант, при котором ваша программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно.
Например: Программа должна работать с заданной расширенной матрицей инциденций исследуемого графа в соответствии с алгоритмом функционирования, выдавать сообщения об ошибках при неверно заданных исходных данных, поддерживать диалоговый режим в рамках предоставляемых пользователю возможностей.
Условия эксплуатации. Должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида «Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК», «Программа должная быть рассчитана на непрофессионального пользователя» и т.п.
Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.
Здесь главное – ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой – не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.
Например: Необходимо наличие IBM PC — совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 600 Кб, объем свободной оперативной памяти — не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа «мышь».
Требования к информационной и программной совместимости. Особенности те же, что и в предыдущем пункте. Здесь должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования. При необходимости должна обеспечиваться защита информации и программ.
Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования — Turbo Pascal 6.0.
Требования к маркировке и упаковке и требования к транспортированию и хранению являются достаточно экзотическими. В общем случае здесь указывают требования к маркировке программного изделия, варианты и способы упаковки. А в требованиях к транспортированию и хранению должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
Специальные требования – это весьма ответственная вещь. Их лучше, по возможности, всячески избегать. И заявить об этом сразу.
Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.
Технико-экономические показатели. Этот самый сложный для программиста пункт есть далеко не всегда. Он нужен прежде всего тогда, когда вашей целью является обоснование огромной эффективности и важности выполняемой работы. На Заказчика этот пункт действует, обычно, очень хорошо. По крайне мере, это лучшее обоснование сроков и денежных сумм разработки.
В этом разделе должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность (например: предполагаемое число обращений к комплексу в целом в год — 365 сеансов работы), экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
Помимо этого, желательно привести определение как сметной стоимости разработки программы, так и определение трудоемкости программирования.
Здесь описываются стандартные этапы. Главное – грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу.
Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями.
Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты.
Эскизный проект. На этой стадии детально разрабатываются структуры входных и выходных данных, определяется форма их представления. Разрабатывается общее описание алгоритма, сам алгоритм, структура программы. Разрабатываются план мероприятий по разработке и внедрению программы.
Технический проект. Содержит разработанный алгоритм решения задачи а также методы контроля исходной информации. Здесь же разрабатываются средства обработки ошибок и выдачи диагностических сообщений, определяются формы представления исходных данных и конфигурация технических средств.
Рабочий проект. На этой стадии осуществляется программирование и отладка программы, разработка программных документов, программы и методики испытаний. Подготавливаются контрольно-отладочные примеры. Окончательно оформляются документация и графический материал. Обычно указывается, что в ходе разработки программы должна быть подготовлена следующая документация:
текст программы;
описание программы;
программа и методика испытаний;
описание применения;
руководство пользователя.
Это — стандартные требования. Если Заказчик соглашается с тем, что можно представить не весь этот список, то это означает несерьезность его намерений в отношении вас и вашего продукта.
Графического материала может и не быть. Особенно тогда, когда вы не собираетесь докладывать о результатах своей работы. Но для серьезных проектов этот пункт обязателен.
Например: В ходе разработки программы должен быть подготовлен следующий графический материал:
технико-экономические показатели;
структура программы;
формат представления входных данных программы;
общая схема алгоритма (2 листа);
основные вычислительные алгоритмы;
пример работы программы.
В разделе Порядок контроля и приемки должны быть указаны виды испытаний и общие требования к приемке работы. Если возможно, то в этом пункте укажите, что «контроль и приемка разработки осуществляются на предоставляемой Заказчиком технике», иначе вас могут обязать принести технику с собой.
Например: Контроль и приемка разработки осуществляются на основе испытаний контрольно-отладочных примеров. При этом проверяется выполнение всех функций программы.
В Приложениях к техническому заданию, при необходимости, приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
другие источники разработки.
02.03
03.03Проектирование ПП
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Описания использования программы
Требования к содержанию и оформлению ГОСТ
Unified system for program documentation. 19.401-7-78
Text of program.
Requirements for contents and form of presentation
МКС 35.080
_________________________________________________________________________________
Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. №3350 дата введения установлена
01.01.80
1. Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Текст программы», определенного ГОСТ 19.101-77.
Стандарт полностью соответствует СТ СЭВ 3746-82.
2. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотации и содержания) является необязательным. Для текста программы на исходном языке при наличии аннотации в нее включают краткое описание функций программы.
1,2. (Измененная редакция, Изм. № 1).
3. Основная часть документа должна состоять из текстов одного или нескольких разделов, которым даны наименования.
Допускается вводить наименование также и для совокупности разделов.
4. Каждый из этих разделов реализуется одним из типов символической записи, например:
символическая запись на исходном языке;
символическая запись на промежуточных языках;
символическое представление машинных кодов и т.п.
В символическую запись разделов рекомендуется включать комментарии, которые могут отражать, например функциональное назначение, структру.
___________________________________________________________________________________
Издание официальное Перепечатка воспрещена
Издание с Изменением № 1, утвержденным в марте 1983 г. (ИУС 7-83).
М Е Ж Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т
____________________________________________________________________________
Единая система программной документации
Описание программы ГОСТ
19.402-78
Unified system for program documentation
Program description
Мкс 35.080
_____________________________________________________________________________
Постановление Государственного комитета СССР по стандартам от 18 декабря 1978г.№3350 дата введения установлена
1.Настоящий стандарт устанавливает состав и требования к содержанию программного документа “Описание программы”,определенного Гост 19.101—77.
Стандарт полностью соответствует СТ СЭВ 2092-80
Изменившая редакция, Изм № 1).
2.Структуру и оформление документа устанавливают в соответствии с Гост 19.105-78
Составление информационной части(Аннотации и содержания) является обязательным
3.Описание программы должно содержать следующие разделы.
Общие сведения;
Функциональные назначения;
Описание логической структуры;
Используемые технические средства;
Вызов и загрузка;
Входные данные
выходные данные
В зависимости от особенностей программы допускается вводить дополнительные разделы или объединить отделены разделы
4.В разделе “Общие сведения” должны быть указаны:
Обозначение и наименование программы;
Программное обеспечение ,необходимое для функционирования программы;
языки программирования, на которых написано программа
5.В разделе “Функциональное назначение” должны быть указаны классы решаемых задач и (или) назначение программы и сведения о функциональных ограничениях на применение
6.В разделе “Описание логической структуры” должны быть указаны:
алгоритмы программы;
Используемые методы;
Структура программы с описанием функций составных частей и связи между ними;
связи программы с другими программами.
Описание логической структуры программы выполняют с учетом текста программы на исходном языке
3-6 (Измененная редакция, Изм. №1).
7. В разделе “Используемые технические средства” должны быть указаны типы электронных вычислительных машин и устройств, которые используются при работе программы
_____________________________________________________________________________
| Единая система программной документацииОПИСАНИЕ ПРИМЕНЕНИЯТребование к содержанию и оформлениюUnified system for program documentation.Description of use.Requirements for contents and form of presentation |
| 01.01.80 |
Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978г. №3350 дата введения установлена
- Настоящий стандарт устанавливает состав и требования к содержанию программного документа “Описание применения”, определенного ГОСТ 19.101- 77.
Стандарт полностью соответствует СТ СЭВ 2093 — 80.
(Измененная редакция, Изм. № 1).
- Структура и оформление документа устанавливают в соответствии с ГОСТ 19.05- 78.
Составление информационной части (аннотации и содержания) является обязательным.
- Текст документа должен состоять из следующих разделов:
входные и выходные данные;
4. В зависимости от особенностей программы допускается вводить дополнительные разделы или объединять отдельные разделы.
5. В разделе “Назначение программы” указывают назначение, возможности программы, ее основные характеристики, ограничения, накладываемые на область применения программы.
3-5. (Измененная редакция, Изм. №1).
6. В разделе “Условия применения” указывают условия, необходимые для выполнения программы (требования к необходимым для данной программы техническими средствами, и другим программ, общие характеристики входной и выходной информации, а также требования и условия организационного, технического и технологического и т.п.).
7. В разделе “Описание задачи” должны быть указаны определения задачи и методы ее решения.
(Измененная редакция, Изм. №1).
7а. В разделе “Входные и выходные задачи” должны быть указаны сведения о входных и выходных данных.
(Введен дополнительно, Изм. № 1).
8. В приложение к общему описанию могут быть включены справочные материалы (иллюстрации, таблицы, графики, примеры и т.п.).
Статьи к прочтению:
- Опишите 10 тем, которые вы в принципе смогли бы запустить?
- Оплата услуг индивидуального руководителя
PPC.tool подробное описание программы, советы по использованию Амазон Бизнес США как заработать
Похожие статьи:
- Описание комплекса программ ОСНОВЫ КОМПЬЮТЕРНОГО ПРОЕКТИРОВАНИЯ И МОДЕЛИРОВАНИЯ РАДИОЭЛЕКТРОННЫХ УСТРОЙСТВ Методические указания по расчетно-графическому заданию Для студентов III-V…
- Использование специализированных программ Введение Интернет полностью меняет то, как мы работаем, живем, развлекаемся и учимся. Эти изменения будут происходить в уже известных нам областях…
Источник: csaa.ru