19.11.2023

Документы на программное обеспечение гост. Правила оформления программной документации. Виды эксплуатационных документов


В.Э. Карпов

Этот документ содержит краткое описание стандартов ЕСПД, знание которых необходимо студентам для оформления курсовых работ и проектов, связанных с созданием программных систем. Кроме того, он может быть полезен и с точки зрения повышения качества оформления программной документации вообще.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ (ГОСТ 19.201-78)

1. Общие положения

СТАДИИ РАЗРАБОТКИ (ГОСТ 19.102-77)

ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78)

ТЕКСТ ПРОГРАММЫ (ГОСТ 19.401-78)

ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ (ГОСТ 19.301-79)

ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ, ВЫПОЛНЕННЫМ ПЕЧАТНЫМ СПОСОБОМ (ГОСТ 19.106-78)

Стандартизация в области документирования программных средств

Как двигаться вперед

Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами

2. Общая характеристика состояния

2.3. Государственные стандарты РФ (ГОСТ Р)

2.4. Международный стандарт ISO/IEC 12207: 1995-08-01

Пожалуй, самым неприятным и тяжелым этапом программистской работы является создание программной документации. К сожалению, обычно этому либо не учат совсем, либо, в лучшем случае, не обращают на качество получаемых документов должного внимания. Тем не менее, владение этим искусством является зачастую одним из важнейших фактором, определяющим качество программиста.

Во-первых, умение создавать программную документацию определяет профессиональный уровень программиста. Заказчик не будет вникать в тонкости и особенности даже самой замечательной программы. Заказчик будет сначала читать документацию. Большую роль играет в этом и психологический фактор. В частности, во всем мире ценилась (и ценится сейчас) былая советская школа программирования. Современные же отечественные программисты котироваться перестали. Класс не тот. Нынче программы уже не пишутся, а составляются (а это - "две большие разницы"). Так вот, созданный в "классическом" стиле пакет программной документации (далее - ПД) создаст у вашего заказчика или работодателя самое что ни на есть благоприятное впечатление. Тем более, если автор ПД будет избегать фраз вида "кликните на скроллбар…", "винт" и т.п. К сожалению, за подобной жаргонной трескотней обычно скрывается либо скудость мыслей, либо полная пустота (неизгладимое впечатление произвел на автора рассказ одного его знакомого о неком "геймере", который с кем-то там то ли "чатился", то ли "модераторством" занимался или что-то в этом роде.). Язык ПД - это своего рода бюрократический, весьма консервативный язык. Есть в нем своя особая прелесть. Согласитесь, что термины НЖМД, НГМД, ручной манипулятор типа "мышь" (или "колобок", как значилось в одном из старинных пакетов ПД) звучат совсем иначе, нежели соответствующие "винт", "флоп" и просто "мышь". Между прочим, дело уже дошло до того, что, говорят, появилась даже особая специальность - технический писатель, т.е. человек, умеющий создавать программную документацию.

Во-вторых, грамотно составленный (точнее, созданный) пакет ПД избавит вас от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно просто отослав пользователя к документации. Это касается прежде всего важнейшего документа - Технического задания. Об этом мы будем говорить ниже, а сейчас можно напомнить о многомиллионном иске к компании IBM. Этот иск предъявило одно крупное издательство, неудовлетворенное качеством ВТ и программного обеспечения. IBM суд выиграла. И выиграла только благодаря тому, что предъявила подписанное обеими сторонами Техническое задание. Было это давно, еще в 70-х гг., однако сути дела это не меняет.

И еще одно. Важно создать первый пакет ПД. Этого будет достаточно, чтобы на его основе строить все последующие, используя его как образец или шаблон. Но сделать это надо очень качественно. Не спеша. Очень основательно.

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

  • ИПК "Издательство стандартов", Территориальный отдел распространения НТД (магазин "Стандарты"), 17961, Москва, ул. Донская, д. 8, тел. 236-50-34, 237-00-02, факс/тел. 236-34-48 (в части ГОСТ и ГОСТ Р).
  • ВНИИКИ Госстандарта России (читальный зал), 103001, Москва, Гранатный пер. д. 4, тел. 290-50-94 (в части международных, зарубежных стандартов и других НТД).

И никаких цитат и вторичных источников. ГОСТ - это закон. И тем более, никаких Интернетов (представьте себе суд, выносящий приговор, пользуясь распечаткой Уголовного Кодекса, скачанного с какого-нибудь сайта). Не верьте никому, кроме оригинала. Тем не менее, далее автору придется прибегать к цитированию ЕСПД, снимая при этом с себя всяческую ответственность.

Начнем с общих положений о Единой системе программной документации (которые тоже определены в соответствующем стандарте ГОСТ 19.001-77).

Единая система программной документации - комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации.

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

  • основополагающие и организационно-методические стандарты;
  • стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;
  • стандарты, обеспечивающие автоматизацию разработки программных документов.

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

  • ГОСТ 19.001-77 ЕСПД. Общие положения.
  • ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов (переиздан в ноябре 1987г с изм.).
  • ГОСТ 19.102-77 ЕСПД. Стадии разработки.
  • ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.
  • ГОСТ 19.104-78 ЕСПД. Основные надписи.
  • ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
  • ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.
  • ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
  • ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
  • ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний.
  • ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
  • ГОСТ 19.402-78 ЕСПД. Описание программы.
  • ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
  • ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
  • ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
  • ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
  • ГОСТ 19.504-79 ЕСПД. Руководство программиста.
  • ГОСТ 19.505-79 ЕСПД. Руководство оператора.
  • ГОСТ 19.506-79 ЕСПД. Описание языка.
  • ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
  • ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
  • ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
  • ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Как видно, основная часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Частично эти стандартны морально устарели, к тому же они не лишены некоторых недостатков. Во-первых, в них не отражены некоторые современные тенденции оформления программ и программной документации, во-вторых, в этих стандартах наличествует многократное дублирование фрагментов программной документации. Тем не менее, за неимением лучшего ориентироваться приходится именно на них.

Итак, стандарты ЕСПД упорядочивают процесс документирования программных систем. Однако, во-первых, предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как может показаться: стандарты позволяют вносить в комплект документации на программной системы (ПС) дополнительные виды, а, во-вторых, исходя из требований заказчика, допустимы некоторые изменения как в структуре, так и в содержании установленных видов ПД. Более того, можно отметить, что стандарты ЕСПД (а это относится и ко всем другим стандартам в области ПС - ГОСТ 34, Международному стандарту ISO/IEC, и др.) носят рекомендательный характер. Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе - т.е. при ссылке на них в договоре на разработку (поставку) ПС.

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

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

Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 1987 г.) устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

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

Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

Техническое задание должно содержать следующие разделы:

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

В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.

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

В разделе Основание для разработки должны быть указаны:

  • документ (документы), на основании которых ведется разработка;
  • организация, утвердившая этот документ, и дата его утверждения;
  • наименование и (или) условное обозначение темы разработки.

Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от __.__. за N ___., договор __.__. за N ___. , и т.п.

В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное - четко определить, для чего нужна эта программа.

Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.

Раздел Технические требования к программе или программному изделию должен содержать следующие подразделы:

  • требования к функциональным характеристикам;
  • требования к надежности;
  • условия эксплуатации;
  • требования к составу и параметрам технических средств;
  • требования к информационной и программной совместимости;
  • требования к маркировке и упаковке;
  • требования к транспортированию и хранению;
  • специальные требования.

Иными словами, здесь начинается конкретика. Описывается то, что должна делать программа и как она должна выглядеть.

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

Например: Программа должна позволять … вычислять … строить… создавать …

Исходные данные: текстовый файл с заданной …

Выходные данные: графическая и текстовая информация - результаты анализа системы…; текстовые файлы - отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.

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

Здесь "выгадать" что-то сложно. В лучшем случае может пройти вариант, при котором ваша программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно.

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

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

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

Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.

Здесь главное - ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой - не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.

Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство - не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".

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

Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.

Требования к маркировке и упаковке и требования к транспортированию и хранению являются достаточно экзотическими. В общем случае здесь указывают требования к маркировке программного изделия, варианты и способы упаковки. А в требованиях к транспортированию и хранению должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

Специальные требования - это весьма ответственная вещь. Их лучше, по возможности, всячески избегать. И заявить об этом сразу.

Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

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

Здесь описываются стандартные этапы. Главное - грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями.

Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты.

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

Это - стандартные требования. Если Заказчик соглашается с тем, что можно представить не весь этот список, то это означает несерьезность его намерений в отношении вас и вашего продукта.

Графического материала может и не быть. Особенно тогда, когда вы не собираетесь докладывать о результатах своей работы. Но для серьезных проектов этот пункт обязателен.

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

    • технико-экономические показатели;
    • структура программы;
    • формат представления входных данных программы;
    • общая схема алгоритма (2 листа);
    • основные вычислительные алгоритмы;
    • пример работы программы.

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

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

В Приложениях к техническому заданию, при необходимости, приводят:

  • перечень научно-исследовательских и других работ, обосновывающих разработку;
  • схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
  • другие источники разработки.

Этот стандарт устанавливает стадии разработки программ, программной документации, а также этапы и содержание работ:

Стадии разработки

Этапы работ

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

Обоснование необходимости разработки программы

Постановка задачи.
Сбор исходных материалов.
Выбор и обоснование критериев эффективности и качества разрабатываемой программы.
Обоснование необходимости проведения научно-исследовательских работ.

Научно-исследователь-ские работы

Определение структуры входных и выходных данных.
Предварительный выбор методов решения задач.
Обоснование целесообразности применения ранее разработанных программ.
Определение требований к техническим средствам.
Обоснование принципиальной возможности решения поставленной задачи.

Разработка и утверждение технического задания

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

Эскизный проект

Разработка эскизного проекта

Предварительная разработка структуры входных и выходных данных.
Уточнение методов решения задачи.
Разработка общего описания алгоритма решения задачи.
Разработка технико-экономического обоснования.

Утверждение эскизного проекта


Согласование и утверждение эскизного проекта

Технический проект

Разработка технического проекта

Уточнение структуры входных и выходных данных.
Разработка алгоритма решения задачи.
Определение формы представления входных и выходных данных.
Определение семантики и синтаксиса языка.
Разработка структуры программы.
Окончательное определение конфигурации технических средств.

Утверждение технического проекта

Разработка плана мероприятий по разработке и внедрению программ.
Разработка пояснительной записки.
Согласование и утверждение технического проекта.

Рабочий проект

Разработка программы

Программирование и отладка программы

Разработка программной документации

Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.

Испытания программы

Разработка, согласование и утверждение программы и методики испытаний.
Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний.
Корректировка программы и программной документации по результатам испытаний.

Внедрение

Подготовка и передача программы

Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.
Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.
Передача программы в фонд алгоритмов и программ.

Примечания:

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

Этот стандарт ориентирован на документирование результирующего продукта разработки.

Строго говоря, существуют два разных документа, имеющих, правда, много общего. Это ОБЩЕЕ ОПИСАНИЕ (ГОСТ 19.502-78) и ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78). Однако, в силу того, что реально создать качественно и тот, и другой, не прибегая к почти полному дублированию, выдирая куски, весьма сложно, было бы достаточно реализовать один, более общий, "гибридный" документ. Назовем его "Описанием программы".

На самом деле "Описание программы" в своей содержательной части может дополняться разделами и пунктами, взятыми и из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора и т.п. В частности, из Пояснительной записки можно взять схему алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений.

Описание программы обязательно должно включать информационную часть - аннотацию и содержание.

Основная часть документа должна состоять из вводной части и следующих разделов:

  • функциональное назначение;
  • описание логики.
  • условия применения;
  • состав и функции.

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

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

Например: Программа "Автоматизированное рабочее место разработчика САУ" предназначена для … реализована на …. Программа поддерживает …

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

Например: Программа предназначена для решения задач … Программа представляет собой ядро автоматизированного рабочего места …

Пользователь имеет возможность …, осуществить …, запустить …, проанализировать …, получить результаты анализа и обработки …, построить … и т.п.

В разделе "Описание логики " указывают:

  • описание структуры программы и ее основных частей

(например: В состав программы входит следующее:

  • пользовательский интерфейс,
  • модуль определения путей в графе,
  • модуль расчета передаточной функции,
  • модуль построения амплитудно- и фазочастотных характеристик,
  • модуль построения реакции на полиномиальное воздействие,
  • текстовый редактор) .
  • описание функций составных частей и связей между ними;

Например: Программа состоит из шести модулей: интерфейсный модуль; модуль определения …; модуль расчета …; модуль …и т.п..

Интерфейсный модуль построен на двух типах диалогов: диалог "вопрос - ответ" и диалог типа "меню". Интерфейсный модуль управляет …

Модуль определения … Он является …

Модуль расчета …и т.д.

  • сведения о языке программирования;

Например: Программа написана на языке …с использованием компилятора …

  • описание входных и выходных данных для каждой из составных частей;

Например: ВХОДНЫЕ ДАННЫЕ. Входными данными для программы является текстовый файл, описывающий расширенную матрицу инциденций графа исследуемой системы.

ВЫХОДНЫЕ ДАННЫЕ. Выходными данными являются:

  • выводимая на экран графическая и текстовая информация (результаты анализа системы);
  • файлы в одном из графических форматов - копии изображения построенных характеристик (АЧХ,ФЧХ и т.д.);
  • текстовые файлы - отчеты о проведенных исследованиях;
  • диагностика состояния системы и сообщения о всех возникших ошибках.
  • описание логики составных частей (при необходимости следует составлять описание схем программ).

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

В разделе Состав и функции указывают описание состава и функции программ, применяемых методов решения задач.

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

Например: Программа эксплуатируется на персональном компьютере (ПК) типа IBM PC/AT. Для работы в диалоговом режиме используется экран дисплея, клавиатура и манипулятор типа "мышь". Для поддержки графического режима необходим адаптер EGA (VGA). Входные данные хранятся на флоппи- и/или жестком дисках. Программа работает под управлением ОС …

В приложение к описанию могут быть включены справочные материалы (иллюстрации, таблицы, графики, примеры и т.п.)

И не забудьте указать имя загрузочного модуля, а также описание всей процедуры

Вызова и загрузки системы

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

По-прежнему обязательным является составление информационной части - аннотации и содержания.

Основная часть документа должна состоять из текстов одного или нескольких разделов, которым даны наименования.

Текст каждого программного файла начинается с "шапки", в которой указывается:

    • наименование программы,
    • автор,
    • дата создания программы,
    • номер версии,
    • дата последней модификации.

Обязательными являются комментарии, а также строгое соблюдение правил отступа. Помните, оправдать можно даже неумение создавать программную документацию. А некрасивый текст программы - никогда. Ссылки на то, что этот текст понятен самому автору всерьез не воспринимаются. Тексты программ должно быть не стыдно давать читать другим людям.

Ниже приведен пример подобного хорошо читаемого текста программы (взят с сайта Николая Гехта, e-mail:[email protected], http://users.omskreg.ru/~geht)

/* Исходные тексты Windows"98

Source Code to Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" #define INSTALL = HARD char make_prog_look_big; void main() { while(!CRASHED) { display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) { make_50_megabyte_swapfile(); do_nothing_loop(); totally_screw_up_HPFS_file_system(); search_and_destroy_the_rest_of_OS/2(); disable_Netscape(); disable_RealPlayer(); disable_Corel_Products(); hang_system(); } write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(still_not_crashed) { display_copyright_message(); do_nothing_loop(); basically_run_windows_3.1(); do_nothing_loop(); do_nothing_loop(); } } if(detect_cache()) disable_cache(); if(fast_cpu()) { set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(action, jumpy); set_mouse(reaction, sometimes); } /* printf("Welcome to Windows 3.11"); */ /* printf("Welcome to Windows 95"); */ printf("Welcome to Windows 98"); if(system_ok()) crash(to_dos_prompt) else system_memory = open("a:\swp0001.swp", O_CREATE); while(something) { sleep(5); get_user_input(); sleep(5); act_on_user_input(); sleep(5); } create_general_protection_fault();

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

Формально этот ГОСТ используется для разработки документов планирования и проведения испытательных работ по оценке готовности и качества программной системы. Документ содержит описание объекта и цели испытаний, требования к программе и к программной документации, средства и порядок испытаний, а также описание тестовых примеров.

Составные части этого документа проще и нагляднее описывать сразу в виде примеров.

Объект испытаний

Пример: Объектом испытаний является программа …, предназначенная для …

Цель испытаний

Пример: Проверка надежности функционирования программы.

Требования к программе

Пример: Функционирование программы не должно приводить к сбою (фатальному нарушению работы системы). Организация диалога должна предусматривать защиту от ввода некорректных данных. Программа должна выдавать диагностику состояния системы и сообщения о любых возникших ошибках … и т.п.

Требования к программной документации

Пример: Состав программной документации, предъявляемой на испытании:

  • описание программы (ГОСТ 19.402-78);
  • программа и методика испытаний (ГОСТ 19.301-79);
  • текст программы (ГОСТ 19.401-78).

Средства и порядок испытаний

Пример: Программа работает в соответствии с условиями эксплуатации ОС MS DOS (версия не ниже 3.0) на ПК типа IBM PC/AT, а также на совместимых с ним. Для работы необходим также адаптер EGA (VGA).

Порядок проведения испытаний:

    1. Запуск программы осуществляется ….
    2. Выбирается …
    3. Нажимается …
    4. Последовательно выбираются …

Тестовые примеры

Пример: Для проведения испытаний предлагаются …, описание которых содержатся в файлах …Содержимое тестовых файлов и результаты работы программы приведены в Приложении 1.

И, наконец, рассмотрим последний стандарт ЕСПД, который называется

Этот стандарт устанавливает правила выполнения программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения и предусмотренных стандартами ЕСПД.

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

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

Повреждение листов документов, помарки и следы не полностью удаленного текста (графики) не допускаются.

Программные документы оформляют на листах формата А4. Кроме того:

  • допустимо оформление на листах формата А3;
  • при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом;
  • при изготовлении документа типографским способом возможно использование листов типографических форматов.

Расположение материалов программного документа осуществляется в следующей последовательности:

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

Построение документа. При необходимости допускается делить документ на части. Деление на части осуществляется на уровне не ниже раздела. Каждую часть комплектуют отдельно, при этом в конце содержания первой части следует перечислить названия остальных частей.

Допускается включение в документ частей текста программы, оформляемых в соответствии с правилами языка, на котором написан текст программы.

Аннотацию размещают на отдельной странице (страницах), снабжают заголовком "АННОТАЦИЯ", нумеруют и включают в содержание документа.

Текст каждого документа, при необходимости, разбивается на пункты, а пункты - на подпункты, независимо от того, разделен документ на части, разделы и подразделы или нет.

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

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

Текст документа. Текст документа должен быть кратким, четким, исключающим возможность неверного толкования. Термины и определения должны быть едиными и соответствовать установленным стандартам, а при их отсутствии - общепринятым в научно-технической литературе, и приводиться в перечне терминов.

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

Если сноска относится к отдельному слову, знак сноски помещается непосредственно возле этого слова, если же к предложению целом, то в конце предложения. Текст сноски располагают в конце страницы и отделяют от основного текста линией длиной 3 см, проведенной в левой части страницы.

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

В приложениях иллюстрации нумеруются в пределах каждого приложения в порядке, установленном для основного текста документа. Ссылки на иллюстрации дают по типу: "рис.12" или "(рис.12)". Иллюстрации могут иметь тематический заголовок и подрисуночный текст, поясняющий содержание иллюстрации.

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

Ссылки в тексте на порядковый номер формулы дают в скобках, например: "в формуле (3)". При делении документа на части номер части ставится перед порядковым номером формулы и отделяется от последней точкой, например: "в формуле (1.4)".

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

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

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

Примечания. В примечаниях к тексту и таблицам указывают только справочные и пояснительные данные. Одно примечание не нумеруется. После слова "Примечание" ставят точку. Несколько примечаний следует нумеровать по порядку арабскими цифрами с точкой. После слова "Примечание" ставят двоеточие. Текст примечаний допускается печатать только через один интервал.

Сокращения. Сокращения слов в тексте и надписях под иллюстрациями не допускаются, за исключением:

  • сокращений, установленных в ГОСТ 2.316-68, и общепринятых в русском языке;
  • сокращений, применяемых для обозначения программ, их частей и режимов работы, в языках управления заданиями, в средствах настройки программы и т.п., обозначаемых буквами латинского алфавита.

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

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

Приложение 1, Приложение 2 и т.д.

При выпуске приложения отдельным документом, на титульном листе под наименованием документа следует указывать слово "Приложение", а при наличии нескольких приложений указывают также его порядковый номер.

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

· · основополагающие и организационно-методические стандарты;

· · стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;

· · стандарты, обеспечивающие автоматизацию разработки программных документов.

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

ГОСТ 19.001-77 ЕСПД. Общие положения.

ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов (переиздан в ноябре 1987г с изм.).

ГОСТ 19.102-77 ЕСПД. Стадии разработки.

ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.

ГОСТ 19.104-78 ЕСПД. Основные надписи.

ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.

ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.

ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.

ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.

ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний.

ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

ГОСТ 19.402-78 ЕСПД. Описание программы.

ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.

ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.

ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.

ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.

ГОСТ 19.504-79 ЕСПД. Руководство программиста.

ГОСТ 19.505-79 ЕСПД. Руководство оператора.

ГОСТ 19.506-79 ЕСПД. Описание языка.

ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.

ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Как видно, основная часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Частично эти стандартны морально устарели, к тому же они не лишены некоторых недостатков. Во-первых, в них не отражены некоторые современные тенденции оформления программ и программной документации, во-вторых, в этих стандартах наличествует многократное дублирование фрагментов программной документации. Тем не менее, за неимением лучшего ориентироваться приходится именно на них.


Итак, стандарты ЕСПД упорядочивают процесс документирования программных систем. Однако, во-первых, предусмотренный стандартами ЕСПД состав программных документов вовсе не такой "жесткий", как может показаться: стандарты позволяют вносить в комплект документации на программной системы (ПС) дополнительные виды, а, во-вторых, исходя из требований заказчика, допустимы некоторые изменения как в структуре, так и в содержании установленных видов ПД. Более того, можно отметить, что стандарты ЕСПД (а это относится и ко всем другим стандартам в области ПС - ГОСТ 34, Международному стандарту ISO/IEC, и др.) носят рекомендательный характер. Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе – т.е. при ссылке на них в договоре на разработку (поставку) ПС.

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

И еще. Описывая свой продукт, разработчик зачастую путает понятия компонента и комплекса. Это – разные виды программ. Компонент определяется как "программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса" , а комплекс – это "программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса" .

Основная задача этого текста - рассказать, что такое Единая система программной документации (ЕСПД) и как эти стандарты применять на практике. Начну с рассказа о том, какие бывают стандарты, и закончу опытом применения каждого из ЕСПДшных стандартов в отдельности.

В свое время, когда я только начинал работать программистом, часто приходилось слышать “напиши, пожалуйста, документацию к своей программе”. Я честно все описывал, отдавал начальнику, после чего начинался сеанс черной магии. Начальник через некоторое время меня вызывал и начинал мычать нечленораздельные звуки, мять распечатку моего “самого лучшего” текста в руках, бегая глазами. Общий смысл его мычания заключался в том, что получилось “не то”, “не так”, и “посмотри, как делают другие”. Так как никакого другого ответа из него вытянуть было невозможно, я шел за примерами документов к “другим”. Как правило, это были веселые ребята, смысл речей которых заключался в том, что “вот примеры”, “вообще то по ГОСТу” и “это все никому не нужно”. Так я узнал впервые, что программист может соприкоснуться со страшными ГОСТами.
Поразительно, что среди многих десятков моих коллег, очень неглупых программистов, не было никого, кто бы относился к ГОСТам по другому. Даже те несколько человек, которые их знали и, вроде как, даже умели оформлять документы, относились к ним презрительно-формально. Ситуация, когда даже люди, ответственные за управление разработкой не понимают, зачем нужны ГОСТы и как их применят, встречается на многих предприятиях, сплошь и рядом. Да, были и компании, в которых понимали, чем “Описание программы” отличается от “Описания применения”, но таких было явное меньшинство. В интернете вообще господствует точка зрения, что ГОСТы для программистов - это явный рудимент, и нужны только если “нагибают” под них. Эскизный проект считают “сравнительно честным способом отъемы лишних дензнаков у заказчика”. Вникнуть и разобраться пришлось относительно недавно - в процессе разработки системы управления требованиями, заточенной под отечественную специфику. Документацию которая, разумеется, должна генерировать “по ГОСТу”.

Здесь я хочу сосредоточиться только на одной теме, с которой приходиться иметь дело программисту в отечественных предприятиях, особенно в НИИ - на наборе стандартов ЕСПД. Не считаю себя большим знатоком ЕСПД - есть люди, которые десятки лет по нему работают, и наверняка меня поправят. Статья скорее пытается набросать контуры «дорожной карты» для тех, кто только входит в курс дела.

Стандарты

Рассмотрим кратко, какие бывают стандарты (фокусируясь на ИТ-области).
  1. международные. Отличительный признак - принят международной организацией. Пример такой организации - ISO (международная организация стандартизации). Пример её стандарта: ISO 2382-12:1988 (Переферийное оборудование). Распространены совместные стандарты ISO и международной электротехнической комиссии(IEC, в по русски - МЭК): например, ISO/IEC 12207:2008 (жизненный цикл ПО);
  2. региональные. Отличительный признак - принят региональной комиссией по стандартизации. К примеру, многие советские ГОСТы сейчас являются региональным стандартом, т.к. приняты межгосударственным советом, куда входят некоторые бывшие советские республики. Этим советом принимаются и новые стандарты - и они тоже получают обозначение ГОСТ. Пример: ГОСТ 12.4.240-2013;
  3. стандарты общественных объединений; К примеру, той же МЭК: IEC 60255;
  4. национальные стандарты. Для России в начале таких стандартов - “ГОСТ Р”. Могут быть трех типов:
    1. точные копии международных или региональных. Обозначаются неотличимо от “самописных” (национальных, написанных самостоятельно);
    2. копии международных или региональных с дополнениями. Обозначаются добавлением к шифру отечественного стандарта шифра международного, который был взят за основу. Например: ГОСТ Р ИСО/МЭК 12207;
    3. собственно, национальные стандарты. Например, ГОСТ Р 34.11-94.

Системы обозначений на каждом уровне и в каждой организации свои, для каждого случая придется разбираться отдельно. Чтобы быстро понять, “чей” стандарт перед глазами, можно использовать шпаргалку .

ГОСТ

Итак: стандарты бывают международные, межгосударственные(региональные) и национальные. ГОСТ, как мы выяснили, это региональный стандарт. ГОСТы имеют достаточно запутанную, на мой взгляд, систему обозначений. Полностью она изложена в ГОСТ Р 1.5-2004, я приведу минимум, что бы в ней ориентироваться. Во первых, надо различать обозначение ГОСТа и его классификацию. Обозначение - это, грубо говоря, уникальный идентификатор стандарта. Код по классификатору - это вспомогательный код, помогающий найти стандарт или определить, к какой области знаний он относиться. Классификаторов может быть много, в основном используются два: КГС (классификатор государственных стандартов) и его наследник ОКС (общероссийский классификатор стандартов). Например: “ГОСТ Р 50628-2000“ - это обозначение стандарта.По обозначению понятно только то, что он принят в 2000 году. Он имеет код по ОКС “33.100;35.160”: т.е. “33” - раздел “Телекоммуникации, аудио, видео”, “100” - подраздел “электромагнитная совместимость”. Однако он также входит в ветвь классификатора 35.160. “35” - “Информационные технологии. Машины конторские”, “160” - “Микропроцессорные системы....”. А по КГС он имеет код “Э02”, что означает “Э” - “Электронная техника, радиоэлектроника и связь”, “0” - “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д.

Если известно обозначение стандарта, то получить его коды по КГС и ОКС можно, к примеру, на вот этом толковом сайте .
Итак, вернемся к обозначениям ГОСТов. Их может быть два варианта:

  1. стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77;
  2. стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628-2000.
Итак, если совсем просто - то обозначение ГОСТа - это либо просто порядковый номер, тире, год, либо номер серии, точка и дальше в зависимости от серии. В реальности все сложнее (к примеру, можно встретить что то типа ГОСТ 11326.19-79, и это будет вовсе не серия 11326 - но программистам такое нужно очень редко. За подробностями - в ГОСТ Р 1.5-2004).

ЕСПД

ЕСПД - одна из таких серий ГОСТов, номер 19. Т.е. все стандарты, относящиеся к ЕСПД, начинаются с префикса “19.”: например, ГОСТ 19.106-78. Расшифровывается как “Единая система программной документации”. Существуют и другие серии:
  • ГОСТ ЕСКД (единая система конструкторской документации, префикс “2.”);
  • ГОСТ ЕСТД (единая система технологической документации, префикс “3.”);
  • ГОСТ Р, Система разработки и постановки продукции на производство, префикс “15.”;
  • ГОСТ РВ, Вооружение и военная техника. Система разработки и постановки продукции на производство, префикс “15.”;
  • ГОСТ, Система технической документации на АСУ, префикс “24.”;
  • ГОСТ, Комплекс стандартов на автоматизированные системы, префикс “34.”.
Итак, ЕСПД содержит в себе набор стандартов, применяемых при разработке программного обеспечения. Далее для каждого стандарта из ЕСПД дается краткая характеристика и пояснение для неочевидных случаев.
19.001-77. Общие положения
Описывает правила присвоения обозначений стандартов в серии ЕСПД. В практической жизни не нужен.
19.102-80. Схемы алгоритмов и программ. Правила выполнения.
Описывает правила построения и оформления алгоритмов. Использует обозначения из 19.103. В моей практике был нужен единственный раз, когда при сертификационная лаборатория уперлась по формальному признаку, что нужна именно схема алгоритма. С моей точки зрения, классические блок-схемы двумя ногами в прошлом, и единственно, где остались более-менее уместными, это если при изложении автор хочет акцентировать внимание читателя именно на алгоритме.
19.003-80. Схемы алгоритмов и программ. Обозначения условные графические
Приведены графические обозначения допустимых типов элементов блок-схемы. Нужен, если используются блок-схемы.
19.004-80. Термины и определения.
Скудный глоссарий. Из интересного - содержит формальные определения программного и эксплуатационного документов.
19.005-85. Р-схемы алгоритмов и программ
Практически забытый язык. В свое время Р-схемы широко использовались в ракетно-космической отрасли, став стандартом де-факто для написания программ управления пусками и моделирования запусков. Однако ныне этот язык полностью предан забвению. В своей работе я ни разу не сталкивался с Р-схемами. Хотя по сравнению с блок-схемами они имеют заметные преимущества: компактны, подходят для визуализации нелинейных алгоритмов (например, классов в С++) или структур данных. При этом в интернете информации по ним практически нет: мне показались полезными вот этот и вот этот сайты. В любом случае, если бы сейчас мне пришлось вставлять в программную документацию схему алгоритма, я бы выбрал Р-схемы, а не блок-схемы.
19.101-77. Виды программ и программных документов
Содержит таблицу соответствия вида документа его коду, а также деление видов документов на эксплуатационные и программные. Вводится понятие комплекса и компонента. Больше ничего полезного нет.
19.102-77. Стадии разработки
Важный и нужный стандарт, в котором описаны виды документов и приведены коды видов программных документов. Этот стандарт (совместно с 19.103-77) является одним из ключей к “разгадке” обозначений документов подобных АБВГ.10473-01 32 01-1.
В стандарте вводится понятие комплекса и компонента (на ряде предприятий добавляют третий вид - комплект, когда речь идет о несвязанных программных элементах), дается разделение: какие документы эксплуатационные, какие нет.
Следует аккуратно относиться к таблице 4, в которой показано, какой документ на какой стадии разработки выполняется. Стадии разработки обычно регламентируются в стандартах на выполнения ОКР, и там-же указывается, какие документы нужно предъявлять заказчику на каждом этапе.
19.102-77. Стадии разработки
На моей памяти этот стандарт не применялся ни разу: кто что делает на каком этапе и чем отчитывается прописывается в ТТЗ или делается отсылка к ГОСТам, где это прописано более четко (например, ГОСТ РВ 15.203). При этом для новичка он содержит неплохой в своей лаконичности конспект работ на основных этапах ОКР.
19.103-77. Обозначения программ и программных документов
Нужен, в основном, для того, что бы научиться читать обозначения документов подобных приведенному выше. Однако понимание схемы обозначений полезно в случае, когда приходиться выходить за рамки типовых работ: к примеру, помнить, что документы с кодами после 90 - пользовательские, т.е. любые. В моей практике мы выпускали документ 93, который назвали “Ведомость программной документации”, 96 документ - “Инструкция по сборке”.
Распространенное словосочетание “вариант исполнения” в ЕСПД отсутствует, и заменяется “номером редакции”. С одной стороны, это не совсем корректно: номер редакции задумывался для отслеживания эволюции программы: вначале выходит первая редакция, потом, к примеру, после доработки - вторая. Но на практике, когда нужно выпустить версию ПО для нескольких операционных систем (кросс-платформенное ПО), другого выхода нет. Точнее - есть, но неправильный: присвоить версии для каждой операционки свое обозначение - и закладывать в архив несколько дисков с исходниками (по числу операционок), разрабатывать (фактически - копировать) весь комплект документации и т.д… Т.е. чистой воды бестолковая и сбивающая с толку деятельность. Решение в виде присвоения версии под каждую операционку своего номера редакции позволяет часть документов сделать общими.
В ЕСПД используется смущающее многих программистов обозначение исходных текстов программы и результата сборки “документами”. Документ “текст программы”, согласно 19.101-77, имеет обозначение 12. Дальше принято, что исходники обозначаются как 12 01 - т.е. 01(первый) документ вида 12, а бинарники - как 12 02 - т.е. второй документ вида 12. В ряде случаев для сборки программы требуются дополнительные инструментальные средства - компиляторы, генераторы инсталляторов и т.д. Т.е. программы, которые не входят в поставку, но нужны для сборки. Решением может быть их обозначение как 12 03 - т.е. третий документ вида 12.
19.104-78. Основные надписи
Описывает два листа документа - лист утверждения (ЛУ) и титульный лист. Лист утверждения в ЕСПД содержит подписи как начальства, утвердившего документ, так и разработчиков, нормоконтролеров, представителей приемки и т.д. Т.е. на нем присутствует достаточно много чувствительной для предприятия информации. Поэтому в стандарте принято, что ЛУ остается на предприятии-разработчике, и высылается только по особому указанию. Еще раз - ЛУ не является частью документа, а является как бы отдельным документом, и в спецификацию его вносят отдельной строкой.
Поначалу смущающая странность в отделении ЛУ от самого документа имеет весьма веские причины:
  • как было уже сказано, часто предприятие не хочет раскрывать информацию о разработчике. Отделение ЛУ и его “зажатие” позволяет это сделать (штампа, в отличии от ЕСКД, в ЕСПД на листах документа нет, вся информация локализована только в ЛУ);
  • на ряде предприятий используется смешанный документооборот: подлинники документов хранятся в электронном виде в архиве предприятия, а ЛУ на них (с оригиналами подписей) - в бумажном;
Что касается оформления ЛУ, то сплошь и рядом на предприятиях используется смесь - часть надписей ЛУ оформляется по ЕСПД, часть - по ЕСКД, а часть - по своему. Поэтому лучше всего прежде, чем делать ЛУ самому, поискать, нет ли стандарта предприятия (СТО), или взять пример у местного нормоконтроля.
Также следует помнить, что ЛУ не нумеруется, и первый лист - титульный, а первый лист, на котором ставится номер - следующий за титульным. Но в том случае, если ЛУ больше одного (это бывает, если все подписи не влезли на лист), то ЛУ нумеруются отдельно.
19.105-78. Общие требования к программным документам
Вводится общая структура документа, не зависящая от способа его исполнения. Т.е. еще в 1978 году было заложено в стандарт, что документ может быть не обязательно бумажным. В частности, вводиться понятие содержания для полностью электронных документов. Для бумажного исполнения, распространенного в то время, был принят ГОСТ 19.106-78.
В настоящее время к этому стандарту приходиться обращаться очень редко: разве что забывается порядок следования основных частей документа.
19.106-78. Общие требования к программным документам, выполненным печатным способом
Самый объемный стандарт из ЕСПД, уступающий разве что описанию R-схем. Является основным рабочим стандартом при оформлении документации. Вводит правила оформления текста, элементов структуры документа, изображений, формул и т.д. Однако в отличии от соответствующего 2.106 из ЕСКД, 19.106 существенно менее подробный, что приводит к многочисленным неопределенностям.
Во первых, стандарт фактически не определяет межстрочное расстояние и величину вертикальных отступов между заголовками. Он вводит три правила определения интервала: для машинописного текста, машинного и типографского.
Машинописный текст - это текст, набранный на печатной машинке. Смещение следующей строки относительно предыдущей производилось автоматически при так называемом «переводе каретки» - переходе к печати следующей строки, производимым перемещением специального рычага. Как правило, интервал мог быть вручную скорректирован поворотом вала протяжки бумаги, и имел “настройку”, позволяющую задать величину интервала - одинарный или двойной.
Машинный - это, скорее всего, и есть распечатанный текст. Но для него есть только указание, что результат должен быть пригоден для микрофильмирования. Это неявная ссылка на 13.1.002-2003, в котором, к сожалению, задается межстрочный интервал (и, кстати, минимальная высота шрифта) только для рукописных документов (п.4.2.5).
Типографский - текст, набранный в типографии. Учитывая год принятия стандарта, скорее всего речь идет о
[высокой печати , где межстрочный интервал определялся используемыми литерами. Я не специалист в типографском деле, а информации о методах набора сейчас очень мало.
Какой интервал использовать в итоге часто определяется местным нормоконтролем или СТО. Типичные значения - полуторный интервал и 14 размер шрифта.
Часто вызывает много вопросов способ структурирования документа. 19.106 считает, что весь документ делится на разделы, подразделы, пункты и подпункты. У всех них (кроме раздела и подраздела) заголовок может быть и или не быть. При этом:
  • “в содержание документа включают номер разделов, подразделов, пунктов и подпунктов, имеющих заголовок” (п. 2.1.4). Это прямое указание на то, что подпункт может иметь заголовок и включаться в оглавление;
  • “допускается помещать текст между заголовками раздела и подраздела, между заголовками подраздела и пункта”. Важно обратить внимание, что ненумерованный текст может быть только между заголовками, и только на верхних 2х уровнях.
В отличии от ЕСКД, в ЕСПД принят странный способ оформления рисунков: сначала идет название рисунка, потом сам рисунок, потом опциональный “подрисуночный текст”, и потом, на новой строке, “Рис. N”.
Этот стандарт имеет ряд “дыр”, недостказанностей. К примеру, сказано: “иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа. “ Но если иллюстрация одна, то она ненумерованная, и как тогда на нее ссылаться? Аналогично и для таблиц. Для сносок ГОСТ не указывает способ их нумерации - в пределах всего документа или в пределах страницы.
Таблицы. В самом документе дана ссылка на ГОСТ 1.5.68. Судя по первой серии, несложно заключить, что это стандарт на разработку стандартов. Причем тут он, неясно. По смыслу он соответствует правилам оформления таблиц в ЕСКД, с небольшими исключениями. Этот стандарт был отменен, взамен веден, через несколько итераций, 1.5-2012, в котором правила оформления таблицы… просто исчезли. Еще в 1.5-2002 были, а уже в 1.5-2004 исчезли. В реальной жизни мы оформляем таблицы согласно ЕСКД.
Приложения. Стандарт не указывает, попадают ли рисунки, формулы и таблицы из приложений в общий перечень. Аналогично не сказано, нужно ли в оглавлении раскрывать структуру приложения, если оно содержит свои разделы, пункты и т.д. В нашей практике мы не раскрываем внутренности приложений.
Наконец, следует сказать об отступах. Абзацный отступ, равный 5 символам, является общим для:
  • красной строки;
  • отступа элемента структуры документа после раздела (подраздел, пункт, подпункт);
  • элемент перечисления.

  • При этом текст, расположенный на следующей строку после строки с отступом, выравнивается уже по левому полю. Часто встречаются ошибки, когда отступ скачет - красная строка - одно значение, номер пункта - нас другим интервалом, в вложенные отступы в списках - так вообще обязательно.

    В следующих частях планирую уже добраться до конца списка стандартов ЕСПД.

Правила оформления и требования к содержанию курсовых

Редакция 2

проектов (работ) и выпускных квалификационных работ

стр. 39 из 73

Сборочный чертёж сборочной единицы

под номером 8, входящей в изделие 1

ПК.760108.000 СБ

Сборочный чертёж отдельной сборочной

единицы 4

ПК.760004.000 СБ

Чертёж общего вида отдельной сборочной

единицы 4

ПК.760004.000 ВО

Чертёж детали под номером 16, входящей в

сборочную единицу 8 изделия 1

Чертёж детали под номером 120, входящей в

отдельную сборочную единицу 4

Схема электрическая принципиальная изделия 1

ПК.760100.000 Э3

Схема кинематическая принципиальная отдель-

ной сборочной единицы 4

ПК.760400.000 К3

Спецификация сборочной единицы 8 изделия 1

10 Оформление технологических документов

10.1 Технологические документы курсовых проектов (работ) и выпускных квалификационных работ оформляются в соответствии с требованиями стандартов ЕСТД.

10.2 Технологические документы должны включать:

титульный лист, оформленный в соответствии с ГОСТ 3.1105-84 «ЕСТД. Форма и правила оформления документов общего назначения» (форма 2а).

маршрутную карту, оформленную по ГОСТ 3.1118-82 «ЕСТД. Формы и правила оформления маршрутных карт»;

операционные карты механической обработки и операционные

расчётно-технологические карты на технологические операции, на станках с ЧПУ − по ГОСТ 3.1404-86 «ЕСТД. Формы и правила оформления документов на технологические процессы и операции обработки резанием»;

операционные карты слесарных, слесарно-сборочных работ по ГОСТ 3.1407-86 «ЕСТД. Формы и требования к заполнению и оформлению документов на технологические процессы (операции), специализированные по методам сборки»;

карты эскизов (в случае необходимости) по ГОСТ 3.1105-84 и ГОСТ 3.1128-93 «ЕСТД. Общие правила выполнения графических технологических документов»;

операционные карты технологического контроля по ГОСТ 3.1502-85 «ЕСТД. Формы и правила оформления документов на технический контроль»;

другие технологические документы (в случае необходимости или по решению руководителя проекта).

10.3 Ремонтные чертежи выполняются в соответствии с правилами, предусмотренными ГОСТ 2.604-88 «Чертежи ремонтные».

10.4 Технологические документы должны быть сброшюрованы

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

11 Оформление программных документов

11.1 Разработанные в курсовых проектах (работах) и выпускных квалификационных работах документы различных проблемных областей должны быть оформлены следующим образом:

программные документы – в соответствии с требованиями ЕСПД,

документы для автоматизированной системы управления – по государственным стандартам системы технологической документации на АСУ. 11.2 Программные документы (листинги программ) должны включать:

текст программы, оформленный согласно ГОСТ 19.401;

описание программы, выполненное согласно ГОСТ 19.402;

описание примечания, приведённое согласно ГОСТ 19.502;

другие программные документы (при необходимости).

11.3 Листинги программ размещаются в приложениях с обязательными ссылками на них в ПЗ.

11.4 Программный код может быть сопровождён комментариями. При оформлении листингов рекомендуется использовать шрифт Courier New, размер – 12 пт, межстрочный интервал – одинарный. Рекомендуется отделять смысловые блоки пустыми строками, а также визуально обозначать вложенные конструкции с помощью отступов.

11.5 Ключевые слова и комментарии в листинге программ могут быть выделены с помощью курсива. В основном тексте ПЗ курсивом следует выделять имена библиотек, подпрограммы, константы, переменные и т.д.

11.6 Листинги программ должны иметь порядковую нумерацию в пределах приложения. Номер листинга должен состоять из обозначения приложения и порядкового номера листинга, разделенных точкой, например: «Листинг А.3» – третий листинг приложения А. Если в проекте (работе) содержится только один листинг, он обозначается «Листинг 1». При ссылке на листинг в тексте ПЗ следует писать слово «Листинг» с указанием его номера.

11.7 Название листинга программы оформляется тем же шрифтом, что и основной текст, и размещается над листингом слева, без абзацного отступа, через тире, после номера листинга.

Пример оформления листинга программы Листинг А.3 – Программа « Вывод двумерного массива»

mas:array of integer; {объявление двухмерного массива } i,j:integer;

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

{ Ввод значений элементов массива} for i:=1 to 5 do

for j:=1 to 5 do readln(mas);

{Вывод значений элементов массива} for i:=1 to 5 do begin

for j:=1 to 5 do write(" ",mas); writeln;

12 Нормоконтроль

12.1 Нормоконтроль является завершающим этапом разработки документов курсового проекта (работы) и ВКР.

12.2 Нормоконтроль должен соответствовать требованиям ГОСТ 2.111.

12.3 Нормоконтролю подлежат выпускные квалификационные работы. Нормоконтроль курсовых проектов (работ) проводится преподавателем при защите работы. Проведение нормоконтроля направлено на правильность выполнения текстовых и графических документов курсовых проектов (работ) и ВКР (далее документов) в соответствии с требованиями ГОСТ, стандартов ЕСКД, ЕСПД и ЕСТД.

12.4 Нормоконтроль выполняется нормоконтролёром с учётом требований, действующих на данный момент, стандартов и нормативно-технических документов.

12.5 В процессе нормоконтроля пояснительных записок курсовых проектов (работ) и ВКР проверяется:

– соблюдение правил оформления согласно настоящему Положению;

– внешний вид ПЗ;

– комплектность ПЗ в соответствии с заданием на проектирование;

– правильность заполнения титульного листа, наличие необходимых подписей;

– правильность заполнения ведомости проекта (работы);

– наличие и правильность рамок, основных надписей на всех страницах;

– выделение заголовков, разделов и подразделов, наличие красных строк;

– правильность оформления содержания, соответствие названий разделов и подразделов в содержании соответствующим названиям в тексте записки;

– правильность нумерации страниц, разделов, подразделов, рисунков, таблиц, формул;

– правильность оформления рисунков;

– правильность оформления таблиц;

– правильность размерностей физических величин, их соответствие СИ;

– соответствие нормам современного русского языка;

– правильность примененных сокращений слов;

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

наличие и правильность ссылок на используемые источники;

наличие и правильность ссылок на нормативные документы;

правильность оформления списка использованных источников;

правильность оформления приложений.

12.6 В процессе нормоконтроля графических документов курсовых проектов (работ) и ВКР проверяется:

соответствие оформления чертежей требованиям действующих стандартов;

выполнение чертежей в соответствии с требованиями нормативных документов;

соблюдение форматов, правильность их оформления;

правильность начертания и применения линий;

соблюдение масштабов, правильность их обозначения;

достаточность изображений (видов, разрезов, сечений), правильность их обозначения и расположения;

соблюдение условных обозначений элементов в схемах и правил их выполнения в соответствии с требованиями ЕСКД.

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

12.8 Перечень замечаний нормоконтролёра составляется в том случае, если контроль проводится в отсутствие студента-разработчика и сущность ошибок может быть им неправильно истолкована.

12.9 Проверенные нормоконтролёром в присутствии студента-разработчика документы вместе с перечнем замечаний (если он составляется) возвращаются студенту для внесения исправлений и переработки. Если замечания существуют, пометки нормоконтролёра сохраняются до подписания им документа. Если документ заново перерабатывается студентом, то на повторный контроль сдаются оба экземпляра: с пометками нормоконтролера и переработанный.

12.10 Предъявляемые на подпись нормоконтролёру документы должны иметь все визы согласования, кроме визы заведующего кафедрой. Чистовые оригиналы курсовых и дипломных проектов (работ) нормоконтролёр подписывает

в графе «Н.контр.» основной надписи.

12.11 Запрещается без ведома нормоконтролёра вносить какие-либо изменения в документ после того, как этот документ подписан и завизирован нормоконтролёром.

12.12 Нормоконтролёр имеет право в обоснованных случаях не подписывать предоставленный документ:

– при невыполнении требований нормативных документов;

– при отсутствии обязательных подписей;

– при небрежном выполнении;

– при нарушении установленной комплектности.

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

12.13 Нормоконтролёр несёт ответственность за соблюдение в разрабатываемой документации требований действующих стандартов и других нормативно-технических документов наравне с разработчиками документации.

13 Рецензирование ВКР

13.1 Для получения дополнительной объективной оценки представляемой к защите выпускной квалификационной работы проводится внешнее рецензирование выпускной квалификационной работы специалистами в соответствующей области.

13.2 Рецензентами выпускных квалификационных работ являются высококвалифицированные специалисты, персональный список которых определяется выпускающей кафедрой. В качестве рецензентов могут привлекаться специалисты-практики и преподаватели других вузов.

Направление на рецензию выдается выпускающей кафедрой, форма, которого представлена в приложении Т настоящих Правил.

13.3 Рецензент должен быть ознакомлен со всеми требованиями, предъявляемыми к выпускной квалификационной работе (ВКР).

13.4 Рецензия оформляется в письменном виде и содержит аргументированные оценки:

– актуальности темы ВКР;

– соответствии содержания ВКР заданию на его разработку;

– правильности логической структуры ВКР;

– эффективности и обоснованности проектных решений;

– достоинства и недостатков ВКР, соответствие ее квалификационным требованиям выпускника по направлению подготовки;

– оформления ВКР.

В заключительной части рецензии даются выводы о полноте разработки темы, в соответствие с поставленными задачами, о теоретическом или практическом значении ВКР, о возможной области использования результатов ВКР. Рецензент оценивает работу по четырёхбалльной шкале («отлично», «хорошо», «удовлетворительно», «неудовлетворительно») и указывает возможность присвоения студенту должной квалификации.

13.5 Объем рецензии на выпускную квалификационную работу должен составлять 2-3 страницы печатного или четко написанного от руки текста. Подписанная рецензия должна быть представлена на кафедру, не позднее, чем за три дня до защиты ВКР.

13.6 Рецензия может быть выполнена на фирменном бланке организации (место работы рецензента), либо на бланке установленной формы, регламентированной настоящими Правилами (приложение У) и заверена печатью организации, либо печатью отдела кадров (общего отдела, канцелярии) с отметкой «подпись верна».

13.7 На защиту ВКР в комиссию по государственной аттестации можно дополнительно представить отзыв ведущей организации, по заказу которой

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

выполнялась ВКР. В отзыве должна быть отмечена практическая ценность полученных результатов.

14 Отзыв на ВКР

14.1 Отзыв на выпускную квалификационную работу составляется непосредственно ее руководителем. Отзыв должен характеризовать ВКР с разных сторон: со стороны содержания, структуры, полноты раскрытия выбранной темы и т.д.

14.2 Руководитель должен изложить в отзыве свое объективное мнение о выпускной квалификационной работе студента. В частности, отзыв должен содержать сведения:

– об актуальности темы работы;

– о соответствии выпускной квалификационной работы требованиям, предъявляемым стандартами;

– о владении студентом методами сбора, обработки и анализа информации применяемой в сфере профессиональной деятельности;

– о способности студента самостоятельно работать с источниками ясно, четко последовательно излагать материал;

– о положительных сторонах работы;

– о недостатках и замечаниях по содержанию работы и др.

14.3 Отзыв на выпускную квалификационную работу научного руководителя может содержать предложения относительно общей оценки работы.

14.4 В заключении отзыва, руководитель делает вывод о возможности представления к защите выпускной квалификационной работы к защите в ГАК.

14.5 Текст отзыва руководителя на ВКР печатается на листах формата А4 и подписывается научным руководителем. Форма отзыва на ВКР представлена в приложении Ф.

15 Доклад и презентация

15.1 Доклад (выступление) – это работа презентативного характера, отражающая суть ВКР.

В докладе необходимо затронуть актуальность выбранной темы, теоретические и методические основы работы, а также суммировать и обобщенно изложить полученные в ходе исследования результаты.

В конце выступления необходимо отразить практическую значимость результатов, возможность их внедрения в практику или использования в преподавании.

15.2 Доклад рассчитан на заданное ограниченное время выступления и неразрывно связан с презентацией (раздаточным материалом).

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

15.3 Презентация (раздаточный материал) – это подготовленный с помощью специальных программ (например, Microsoft PowerPoint) наглядный цифровой, табличный и иллюстративный материал, который непосредственно связан с докладом.

15.4 Для презентации выбирается необходимый иллюстрирующий материал, который можно взять как из текста работы, так и из приложений. Это могут быть таблицы, рисунки, схемы, диаграммы, формулы и др. Таблицы не должны быть громоздкими, рисунки не должны быть чрезмерно детальными, формулы должны быть наглядными.

Материал должен иллюстрировать все тезисы, выведенные в докладе.

15.5 Показ презентации может быть осуществлен двумя способами:

с помощью проектора и на стенде;

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

Объём презентации может быть от 8 до 12 слайдов.

15.6 Доклад должен содержать только суть рассматриваемого вопроса, минимум цифровых данных, специальных названий, перечислений.

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

в 1-2 предложениях рассмотреть рекомендации для решения поставленных проблем.

15.7 Первым должен быть слайд с темой проекта (работы) и данными исполнителя, то есть: фамилия, имя, отчество, группа, специальность (направление). Желательно указать научного руководителя.

15.8 Курсовой проект (работа) и ВКР сдаются в архив вместе с презентацией, выполненной в электронном виде и записанной на цифровом носитель (например, CD/DVD-диск).

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

Приложение А

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

Приложение Б

(наименование факультета)

(наименование кафедры)

____________ ________________

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту (работе) по дисциплине (модулю)__

(наименование учебной дисциплины (модуля))

на тему _________________________________________________________________________

_____

_______________________

______________________________

Направление/специальность, профиль/специализация:

___________ _________________________________________________________________

код направления наименование направления (специальности)

________________________________________________________________________________

наименование профиля (специализации)

Обозначение курсового проекта (работы) _________________________ Группа ________

Ростов-на-Дону

Приложение В

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ДОНСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» (ДГТУ)

Факультет _______________________________________________________

(наименование факультета)

Кафедра _________________________________________________________

(наименование кафедры)

Зав. кафедрой «______________»

____________ ________________

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломному проекту (работе) на тему:

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

__________________________

(подпись, дата)

Обозначение дипломного проекта ______________________

Группа ______________

Направление (специальность) ___________

___________________________________

(наименование)

Руководитель проекта (работы)

____________________________

(подпись, дата)

(должность, И.О.Ф.)

Консультанты по разделам:

_______________________________

_____________________

(наименование раздела)

(подпись, дата)

(должность, И.О.Ф.)

_______________________________

_____________________

(наименование раздела)

(подпись, дата)

(должность, И.О.Ф.)

Нормоконтроль

_____________________

(подпись, дата)

(должность, И.О.Ф.)

Ростов-на-Дону

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

ГОСТ 19.101-77

Группа Т55

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система программной документации

ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ

Unified system for program documentation. Types of programs and program documents

МКС 35.080

Дата введения 1980-01-01


Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. N 1268 дата введения установлена 01.01.80

ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в июне 1981 г. (ИУС 9-81).


Настоящий стандарт устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Стандарт полностью соответствует СТ СЭВ 1626-79.

(Измененная редакция, Изм. N 1).

1. ВИДЫ ПРОГРАММ

1. ВИДЫ ПРОГРАММ

1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.

1.2. Программы подразделяют на виды, приведенные в табл.1.

Таблица 1

Вид программы

Определение

Компонент

Программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса

Комплекс

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

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

1.2, 1.3. (Измененная редакция, Изм. N 1).

2. ВИДЫ ПРОГРАММНЫХ ДОКУМЕНТОВ

2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.

2.2. Виды программных документов и их содержание приведены в табл.2.

Таблица 2

Вид программного документа

Спецификация

Состав программы и документации на нее

Перечень предприятий, на которых хранят подлинники программных документов

Текст программы

Запись программы с необходимыми комментариями

Описание программы

Сведения о логической структуре и функционировании программы

Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля

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

Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний

Пояснительная записка

Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений

Эксплуатационные документы

Сведения для обеспечения функционирования и эксплуатации программы

2.3. Виды эксплуатационных документов и их содержание приведены в табл.3.

Таблица 3

Вид эксплуатационного документа

Перечень эксплуатационных документов на программу

Формуляр

Основные характеристики программы, комплектность и сведения об эксплуатации программы

Описание применения

Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств

Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения

Руководство программиста

Сведения для эксплуатации программы

Руководство оператора

Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы

Описание языка

Описание синтаксиса и семантики языка

Сведения для применения тестовых и диагностических программ при обслуживании технических средств

2.4. В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.

2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл.4.

Таблица 4

Код
вида документа

Вид документа

Стадии разработки

Эскизный проект

Технический проект

Рабочий проект

компонент

комплекс

Спецификация

Ведомость держателей подлинников

Текст программы

Описание программы

Ведомость эксплуатационных документов

Формуляр

Описание применения

Руководство системного программиста

Руководство программиста

Руководство оператора

Описание языка

Руководство по техническому обслуживанию

Программа и методика испытаний

Пояснительная записка

Прочие документы


Условные обозначения:

- документ обязательный;

- документ обязательный для компонентов, имеющих самостоятельное применение;

- необходимость составления документа определяется на этапе разработки и утверждения технического задания;

- - документ не составляют.

2.2-2.5. (Измененная редакция, Изм. N 1).

2.6. Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов.

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

2.7. На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы.

Технические условия разрабатывают на стадии "Рабочий проект".

2.8. Необходимость составления технического задания на компоненты, не предназначенные для самостоятельного применения, и комплексы, входящие в другие комплексы, определяется по согласованию с заказчиком.

(Введен дополнительно, Изм. N 1).



Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
Единая система программной
документации: Сб. ГОСТов. -
М.: Стандартинформ, 2010


© 2024
maccase.ru - Android. Бренды. Железо. Новости