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

КУЛЬТУРА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

• надежности;
• адекватной обработке нештатных ситуаций;
• легкой модернизируемости.

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

Общие этапы разработки программ :

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

Для определения требований к программе разработчику необходимо получить ответ на вопрос: «Насколько заказчик заинтересован в разработке программы?»

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

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

• Какова(-ы) цель(-ли) программы?
• Круг пользователей программы.
• Нормативная (правовая, справочная) база, на которую опираются процессы, алгоритмизируемые в программе.
• Возможность и необходимость дальнейшего развития программы.
• Контактное лицо, уполномоченное решать все вопросы от лица заказчика.
• Наличие материалов, которые есть или заказчик планирует подготовить для использования в программе (!!! Этот пункт особенно важен для разработки Web-сайтов).

Разработка технического задания в идеале должна осуществляться заказчиком. На практике зачастую это делает разработчик по причине отсутствия у заказчика квалифицированных специалистов, сведущих в области разработки программного обеспечения. Техническое задание, как правило, разрабатывается на основе ГОСТа 19.201-78 «ЕСПД. Техническое задание. Требования к содержанию и оформлению». В случаях разработки технического программного обеспечения в составе автоматизированных систем применяется ГОСТ 34.602-89 «Информационная технология. Техническое задание на создание автоматизированной системы».

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

На основе утвержденного технического задания разрабатывается проектная документация (проект ). Содержание проекта зависит от типа программного обеспечения и традиций предприятия разработчика.

Обязательными составляющими проекта должны быть:

• пояснительная записка (по ГОСТу 19.404-79 «ЕСПД. Пояснительная записка. Требования к содержанию и оформлению»).
• описание программы (по ГОСТу 19.402-78 «ЕСПД. Описание программы»).
• перечень терминов, используемых в проекте. Для web-сайтов в состав проекта включаются:
• эскиз дизайна сайта;
• перечень материалов, используемых в составе сайта;
• структура баз данных (в случае наличия таковых)

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

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

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

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

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

Тестирование программы производится следующим образом:

1. Определяется набор аппаратуры для производства тестирования.
2. Разрабатываются сценарии (контрольные примеры) для тестирования.
3. На основе сценариев проверяется работа программы в штатном режиме (проверяется правильность выполнения тех функций, которые программа и должна выполнять).
4. Проверяется работа программы в нештатных режимах (проверяется, устойчиво ли работает программа в режимах, которые могут возникать только при нарушении пользователями правил эксплуатации программы, например, ввод букв в цифровое поле).
5. Производится тестирование на удобство управления программой и качество интерфейсов.
6. Данные тестирования и его результаты обрабатываются и оформляются в соответствии с ГОСТом 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».
7. По мере выявления ошибок последние исправляются, и тестирование производится повторно.
8. После исправления всех ошибок программа передается в опытную эксплуатацию.

Заказчику на стадии опытной эксплуатации передается программа и обязательный пакет документации:

• ведомость эксплуатационных документов (по ГОСТу 19.507-79 «ЕСПД. Ведомость эксплуатационных документов»)
• формуляр (по ГОСТу 19.501-78 «ЕСПД. Формуляр. Требования к содержанию и оформлению»)
• описание применения (по ГОСТу 19.502-78 «ЕСПД. Описание применения. Требования к содержанию и оформлению»)
• руководство системного программиста (по ГОСТу 19.503-79 «ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению»)
• руководство оператора (по ГОСТу 19.505-79 «ЕСПД. Руководство оператора. Требования к содержанию и оформлению»).

В зависимости от вида задачи дополнительно могут передаваться:

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

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

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

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

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

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

Только грамотный процесс разработки программ обеспечивает их высокое качество и долгую жизнь!!!

ИСПОЛЬЗОВАНИЕ ТРЕБОВАНИЙ ГОСТ 19 и 34 СЕРИИ ПРИ ОФОРМЛЕНИИ ДОКУМЕНТАЦИИ В IT-ПРОЕКТАХ ДЛЯ ГОСУДАРСТВЕННЫХ СТРУКТУР

Введение

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

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

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

Определение стандартов оформления документации

Оформление документов в ГОСТ 34 зависит от вида документа (конструкторский или программный), и стадии создания АС, на которой готовится документ.

Перечень документов, разрабатываемых на различных стадиях создания АС приведен в ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем». В нем приведены следующие требования:

• На стадии «Техническое задание» разрабатывают ТЗ на создание АС по ГОСТ 34.602 -89 «Техническое задание на создание автоматизированной системы»;
• Виды программных документов ГОСТ 19.101-77 «Единая система программной документации. Виды программ и программных документов». К ним относятся различные руководства, например, руководство пользователя.
• Виды конструкторских документов , разрабатываемых на различных стадиях создания АС определяются по ГОСТ 2.102-2013 «Единая система конструкторской документации. Виды и комплектность конструкторских документов». Например, к ним относятся ведомости эскизного и технического проекта, ведомость покупных изделий, пояснительные записки к эскизному, техническому проектам.

Теперь разберем подробнее, как определить стандарты оформления в различных проектах.

Оформление ТЗ

С ТЗ всё достаточно ясно: в ГОСТ 34.602-89 приведен стандарт его оформления: п.3.2. гласит, что «ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней».

Оформление программной документации

С программными документами, разрабатываемыми в рамках ИТ-проекта, также есть чёткое указание использовать ГОСТ 19 серии в части оформления: вышеприведённый ГОСТ 19.101-77 входит в серию ГОСТов 19-й серии «Единая система программной документации» (ЕСПД). ЕСПД - комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

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

Оформление конструкторской документации

Теперь рассмотрим ГОСТ 2.102-2013. Этот стандарт входит в серию ГОСТов 2-й серии «Единая система конструкторской документации» (ЕСКД). ЕСКД - межгосударственный комплекс стандартов, устанавливающих взаимосвязанные нормы и правила по разработке, оформлению и обращению конструкторской документации, разрабатываемой и применяемой на всех стадиях жизненного цикла изделия (при проектировании, изготовлении, эксплуатации, ремонте и др.)

Документация в ЕСКД оформляется по нескольким стандартам. Наиболее часто используемыми из них (применительно к ИТ-сфере) являются ГОСТ 2.105-95 «Единая система конструкторской документации. Общие требования к текстовым документам» и ГОСТ 2.106-96 «Единая система конструкторской документации. Текстовые документы».

На первый взгляд из ГОСТ 34 серии непонятно, как оформлять документацию на АС. Нередко в рамках ИТ-проекта, особенно для государственных заказчиков, в ТЗ бывают требования по оформлению документации согласно ГОСТ 2.105-95 и ГОСТ 2.106-96. Но следует ли оформлять документы по этим ГОСТам в случае, если в явном виде требования к оформлению отсутствуют?

Как правильно оформить?

В ГОСТ 2-й серии приведены требования к назначению каждого стандарта и обозначена отрасль его применения: ГОСТ 2.102-2013 – стандарт устанавливает виды и комплектность конструкторских документов на изделия всех отраслей промышленности.

Если ГОСТ 2.102-2013 распространяется на изделия всех отраслей, в том числе и ИТ-сферу, давайте разберёмся, а что является конструкторским документом?

Согласно ГОСТ 2.001-2013 «Единая система конструкторской документации (ЕСКД). Общие положения»:

А) «3.1.2 конструкторский документ: Документ, который в отдельности или в совокупности с другими документами определяет конструкцию изделия и имеет содержательную и реквизитную части, в том числе установленные подписи»

Б) «3.1.5 конструкторская документация: Совокупность конструкторских документов, содержащих данные, необходимые для проектирования (разработки), изготовления, контроля, приемки, поставки, эксплуатации, ремонта, модернизации, утилизации изделия»

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

Основные ГОСТы 2-й серии для ИТ-проекта в части оформления

Теперь посмотрим на основные ГОСТы 2-й серии, наиболее часто применяемые для оформления документов в ИТ-проекте. Как правило, в части оформления используют:

ГОСТ 2.105-95 – стандарт устанавливает общие требования к выполнению текстовых документов на изделия машиностроения, приборостроения и строительства;

ГОСТ 2.106-96 – стандарт устанавливает формы и правила выполнения конструкторских документов изделий машиностроения и приборостроения.

У читателя может возникнуть вопрос, можем ли мы применять эти ГОСТы для АС, если они предназначены для изделий машиностроения и приборостроения?

Согласно определению «Большой Советской энциклопедии», «Приборостроение -отрасль машиностроения, выпускающая средства измерения, анализа, обработки и представления информации, устройства регулирования, автоматические и автоматизированные системы управления; область науки и техники, разрабатывающая средства автоматизации и системы управления», то есть всё, что нужно по нашей теме современных информационных технологий.

Кроме этого, если заглянуть в ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения», этот стандарт определяет АС как «систему, состоящую из персонала и комплекса средств автоматизации его деятельности, реализующую информационную технологию выполнения установленных функций».

Таким образом, АС относится к отрасли приборостроения и, следовательно, конструкторские документы АС оформляются по ГОСТ 2.105-95 и ГОСТ 2.106-96.

Теперь давайте рассмотрим основные моменты оформления проектной документации по ГОСТ 2.105-95 и ГОСТ 2.106-96.

Основные моменты при оформлении по ГОСТ 2. 105

Рассмотрим основные параметры оформления по ГОСТ 2-й серии.

Согласно ГОСТ 2.105-95 расстояние от рамки формы до границ текста в начале и в конце строк должно быть не менее 3 мм. Расстояние от верхней или нижней строки текста до верхней или нижней рамки должно быть не менее 10 мм. Абзацы в тексте начинают отступом, равным пяти ударам пишущей машинки (15 - 17 мм).

В ГОСТ 2.105-95 не определены параметры для оформления текста в электронном виде: название шрифта, высота шрифта, межстрочный интервал. Поэтому параметры оформления документов в электронном виде это, как правило, предмет договоренности с заказчиком.

В начале работы по оформлению в электронном виде определяются параметры для форматирования:

• Формат абзацев текста – используемый шрифт, высота шрифта, размер межстрочного интервала;
• Формат для каждого заголовка по уровням (1, 2, 3) – используемый шрифт, высота шрифта, отступ в см, размер межстрочного интервала;

Таблица - используемый шрифт текста, межстрочный интервал, толщина границ таблицы, ширина таблицы, отступ в ячейке, название размещается над таблицей. Форматирование названия Таблицы выполняется таким же образом, как у основного текста документа. По ГОСТ 2.105-95 высота строк таблицы должна быть не менее 8 мм. Высота шрифта строк таблицы также может быть согласована с заказчиком.

Иллюстрации в документе следует располагать по центру. Название размещается непосредственно под иллюстрацией. Форматирование названия – как у текста документа.

Правила оформления таблиц

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

Таблицы, за исключением таблиц приложений, нумеруют арабскими цифрами сквозной нумерацией. Например: «Таблица 1».

Таблицы каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например: «Таблица В.1».

Допускается нумеровать таблицы в пределах раздела. В этом случае номер таблицы состоит из номера раздела и порядкового номера таблицы, разделенных точкой. Например, в разделе 4 номер будет «Таблица 4.3».

Название таблицы должно отражать ее содержание, быть точным, кратким. Название состоит из слова «Таблица», номера таблицы и текста. В ГОСТ 2.105-95 не определено использование в названии таблицы дефиса или тире. На практике может использоваться тире, по аналогии использования в названии рисунка тире. Например, «Таблица 5 – Выполняемые работы, содержание и сроки». Точка в конце названия не ставится. Название размещают над таблицей слева.

В ГОСТ 2.105-95 в п.п 4.4.3 приведено следущее требование: «На все таблицы документа должны быть приведены ссылки в тексте документа, при ссылке следует писать слово «таблица» с указанием ее номера». На практике слово «таблица» склоняется в тексте по правилам русского языка. Например: «Краткое описание назначения и основных характеристик подсистем ИС МП второй очереди представлено в таблице 1».

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

В ГОСТ 2.105-95 есть необязательное требование в п.4.4.7: «если в конце страницы таблица прерывается и ее продолжение будет на следующей странице, в первой части таблицы нижнюю горизонтальную линию, ограничивающую таблицу, допускается не проводить.». На практике нижнюю горизонтальную линию, проводят, так ее отсутствие ухудшает восприятие таблицы пользователем.

Правила оформления иллюстраций

К иллюстрациям относятся графические изображения (схемы, графики, фотографии, рисунки).

Иллюстрации, за исключением иллюстраций приложений, нумеруются арабскими цифрами, при этом нумерация сквозная. Например: «Рисунок 3».

Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения. Например: «Рисунок В.6».

Допускается нумеровать иллюстрации в пределах раздела. В этом случае номер иллюстрации состоит из номера раздела и порядкового номера иллюстрации, разделенных точкой. Например, в разделе 5 номер будет «Рисунок 5.2».

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

Требования ГОСТ 2.105-95 к расположению: «иллюстрации могут быть расположены как по тексту документа (возможно ближе к соответствующим частям текста), так и в конце его».

В ГОСТ 2.105-95 в п. 4.3.1 указано следующее: «при ссылках на иллюстрации следует писать "... в соответствии с рисунком 2" при сквозной нумерации и "... в соответствии с рисунком 1.2" при нумерации в пределах раздела».

Название пишется под иллюстрацией в формате «Рисунок 1 – Детали прибора».

Интересный факт: если ошибку в бумажном документе замазать и поверх написать исправление черными чернилами, это будет по ГОСТу. ГОСТ 2.105-95 допускает исправления документов в бумажном виде. Об этом гласит п.3.7: «Опечатки, описки и графические неточности, обнаруженные в процессе выполнения документа, допускается исправлять подчисткой или закрашиванием белой краской и нанесением на том же месте исправленного текста (графика) машинописным способом или черными чернилами, пастой или тушью рукописным способом. Повреждения листов текстовых документов, помарки и следы не полностью удаленного прежнего текста (графика) не допускаются».

То есть, если вы что-то распечатали и нашли ошибку, то её можно исправить вручную приведенным выше способом.

Оформление по ГОСТ 2. 106-96

ГОСТ 2.106-96 устанавливает формы и правила выполнения конструкторских документов. Для каждого типа документа в ГОСТ 2.106-96 приведен шаблон оформления рамок документа.

ГОСТ 2.106-96 определяет не только форму рамок, но и основную надпись в рамке. Пример из ГОСТ 2.106-96: «ПЗ составляют на формах 9 и 9а приложения А, а необходимые схемы, таблицы и чертежи в бумажной форме допускается выполнять на листах любых форматов, установленных ГОСТ 2.301, при этом основную надпись и дополнительные графы к ней выполняют в соответствии с требованиями ГОСТ 2.104 (форма 2а)».

Резюме

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

• Программные документы, разрабатываемые на различных стадиях создания АС оформляются по ГОСТ 19.104-78, ГОСТ 19.105-78, ГОСТ 19.106-78;
• Конструкторские документы, разрабатываемые на различных стадиях создания АС оформляются по ГОСТ 2.105-95 и ГОСТ 2.106-96. При этом требования к содержанию регламентируются РД 50.34-698-90.

Необходимо проверять ГОСТы на актуальность и использовать последнюю редакцию стандартов, поскольку они, хотя и редко, но всё же обновляются. Надеюсь, статья поможет вам лучше ориентироваться в требованиях ГОСТ, а в случае необходимости вы всегда можете

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Постановлением Государственного комитета СССР по стандартам от 14 мая 1980 г. № 2101 срок введения установлен

с 01.01 1981 г.

Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления (кроме общегосударственного), и устанавливает требования к содержанию документов, входящих в соответствии с ГОСТ 24.101-80 в состав документации программного обеспечения в проектах АСУ.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Документация программного обеспечения предназначена:

• для описания проектных решений по программному обеспечению в документе «Описание программного обеспечения АСУ».
• для установления требований к программе (комплексу программ) в документе «Техническое задание»;
• для описания решений, обеспечивающих сопровождение, изготовление и эксплуатацию программы (комплекса программ) в документах «Пояснительная записка», «Описание применения», «Описание программы», «Спецификация», «Руководство программиста», «Руководство оператора», «Текст программы», «Формуляр», «Порядок и методика испытаний»;
• для проверки работоспособности программы (комплекса программ) в документе «Описание контрольного примера».

1.2. При разработке документов на части АСУ содержание разделов каждого документа ограничивают рамками соответствующей части.

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

1.4. Требования к содержанию документов «Техническое задание», «Пояснительная записка», «Описание применения», «Спецификация», «Руководство оператора», «Текст программы», «Формуляр», «Порядок и методика испытаний» установлены ГОСТ 19.201-78 , ГОСТ 19.404-79 , ГОСТ 19.502-78 , ГОСТ 19.202-78 , ГОСТ 19.505-79 , ГОСТ 19.401-78 , ГОСТ 19.501-78 и ГОСТ 19.301-79 .

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

2. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

2.1. Описание программного обеспечения АСУ

2.1.1. Документ должен содержать вводную часть и разделы:

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

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

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

2.1.4. Раздел «Основные функции частей программного обеспечения» должен содержать подразделы, в которых для каждой части программного обеспечения приводят назначение и описание основных функций

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

2.1.5. Раздел «Методы и средства разработки программного обеспечения» должен содержать перечень методов программирования и средств разработки программного обеспечения АСУ с указанием частей программного обеспечения, при разработке которых следует использовать соответствующие методы и средства.

2.1.6. Раздел «Операционная система» должен содержать:

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

2.1.7. Раздел «Средства, расширяющие возможности операционной системы» должен содержать подразделы, в которых для каждого используемого средства, расширяющего возможности операционной системы, следует указать:

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

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

2.2.2. Для программы (комплекса программ), получаемой за счет использования ранее разработанных программных средств, документ «Описание программы» следует дополнять разделом «Настройка программных средств».

2.2.3. Раздел «Настройка программных средств» должен содержать:

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

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

2.3.1. Документ по составу разделов и их содержанию должен соответствовать ГОСТ 19.504-79 и, кроме того, включать раздел «Сведения о форме представления программы (комплекса программ)».

2.3.2. Раздел «Сведения о форме представления программы (комплекса программ)» должен содержать сведения о носителе, на котором записана программа, о содержании и системе кодирования информации, записанной на носителе, а также сведения, необходимые для чтения информации с носителя.

2.3.3. Для программы (комплекса программ), допускающей настройку на условия конкретного применения, в документ «Руководство программиста» включают разделы:

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

2.3.4. Разрешается для программы (комплекса программ), допускающей настройку на условия конкретного применения, вместо разделов, перечисленных в п. 2.3.3, разрабатывать отдельный документ «Руководство системного программиста», удовлетворяющий требованиям ГОСТ 19.503-79 .

2.4. Описание контрольного примера

2.4.1. Документ должен содержать разделы:

• назначение;
• исходные данные;
• результаты расчета;
• проверка программы (комплекса программ).

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

2.4.3. Раздел «Исходные данные» должен содержать описание исходных данных для проверки программы (комплекса программ) с приведением исходных данных. Допускается исходные данные представлять в виде распечатки с АЦПУ.

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

2.4.5. Раздел «Проверка программы (комплекса программ)» должен содержать:

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

Введение

В современном мире каждый день появляется десятки и сотни различных программ, приложений, информационных систем. Они могут быть разработаны как для государственного или коммерческого сектора, так и для обычных пользователей. 90% всех пользователей не читает документацию, считает её скучной, занудной и неинтересной, а открывает руководство пользователя только тогда, когда что-то не получается или разобраться без инструкции уж совсем невозможно. Общепринято теперь строить пользовательский интерфейс таким образом, чтобы он был интуитивно понятен, и пользователь мог разобраться с системой, не прибегая к чтению длиннейших мануалов. Однако, при работе с крупными заказчиками практически всегда необходимо сдать определённый пакет документов – руководств, инструкций, проектных решений, оформленных по ГОСТу.
Когда впервые сталкиваешься с написанием документации по ГОСТу, то приходишь в ступор и полный шок, так как этих ГОСТов «море» и, как и чего по ним писать становится неясно.
В этой статье рассмотрены ГОСТы для написания документации и их основные моменты.

Какие бывают ГОСТы?

Для начала надо разобраться какие бывают ГОСТы. Все лишь знают, что ГОСТ — это нечто, что разрабатывалось при Союзе и их просто бесконечное количество. Спешу вас успокоить для сферы IT ГОСТов не так много, и они все, несмотря на свой срок создания, не потеряли своей актуальности.
В первую очередь стандарты для написания документации делятся на два типа:

1. Международные стандарты (ISO, IEEE Std);
2. Российские или Советские ГОСТы.

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

1. IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» - стандарт для написания руководства пользователя;
2. IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» - стандарт для написания технического описания программы;
3. ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» - ещё один стандарт для написания руководства пользователя. В данном документе есть большое количество примеров. Так сказать, это больше похоже на руководство по написанию руководства пользователя. Начинающим специалистам будет особенно полезен;
4. ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» - ещё один стандарт для дизайнеров и разработчиков пользователей документации.

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

Российские стандарты
Российские стандарты разрабатываются на государственном уровне. Они все абсолютно бесплатны и каждый из них легко найти в интернете. Для написания документации на программу используются две серии ГОСТов 19 и 34. Именно о них и будет идти речь дальше.

Чем отличаются ГОСТы серий 19 и 34?

Первый вопрос, который возникает, а чем, вообще, эти ГОСТы 19 и 34 отличаются друг от друга.
В ГОСТе 19.781-90 «Единая система программной документации. Программное обеспечение систем обраб0отки информации. Термины и определения» указаны определения:

1. Программа - данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определённого алгоритма.
2. Программное обеспечение - совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.

В ГОСТе 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» указано определение:

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

В зависимости от вида управляемого объекта (процесса) АСУ делят, например, на: АСУ технологическими процессами (АСУТП), АСУ предприятиями (АСУП) и т.д.
Также ГОСТ 34 делает разделение на виды обеспечения АС:

1. Организационное;
2. Методическое;
3. Техническое;
4. Математическое;
5. Программное обеспечение;
6. Информационное;
7. Лингвистическое;
8. Правовое;
9. Эргономическое.

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

ГОСТ 34

Серия ГОСТов 34 (ГОСТ 34.ххх Стандарты информационной технологии) состоит:

1. ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем - данный стандарт устанавливает виды, наименование, комплектность и номера документов. Является одним из основных документов серии ГОСТов 34. По сути, это базовый документ, так что новичкам необходимо ознакомиться с ним в первую очередь.
2. ГОСТ 34.320-96 Концепции и терминология для концептуальной схемы и информационной базы - настоящий стандарт устанавливает основные понятия и термины концептуальных схем и информационных баз, охватывающие разработку, описание и применение концептуальных схем и информационных баз, манипулирования информацией, а также описание и реализацию информационного процесса. Стандарт определяет роль концептуальной схемы. Положения, изложенные в нём, носят рекомендательный характер и могут использоваться для оценки систем управления базами данных (СУБД). Этот документ не описывает конкретные методы применения средств поддержки концептуальных схем. Описанные в стандарте языки концептуальных схем не следует рассматривать как стандартные.
3. ГОСТ 34.321-96 Информационные технологии. Система стандартов по базам данных. Эталонная модель управления - данный документ устанавливает эталонную модель управления данными.
   Эталонная модель определяет общую терминологию и понятия, относящиеся к данным информационных систем. Такие понятия используются для определения услуг, предоставляемых системами управления базами данных или системами словарей данных.
   Эталонная модель не рассматривает протоколы для управления данными.
   Область применения эталонной модели включает процессы, которые касаются управления постоянными данными и их взаимодействия с процессами, отличающимися от требований конкретной информационной системы, а также общие услуги управления данными, для определения, хранения, поиска, обновления, ввода, копирования, восстановления и передачи данных.
4. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания - стандарт устанавливает стадии и этапы создания АС.
5. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85) - устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы».
   Данный документ является одним из часто используемых документов серии ГОСТ 34. При разработке ТЗ по этому ГОСТу следует помнить и о других стандартах, даже если в этом документе нет ссылок на эти стандарты.
6. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем - стандарт устанавливает виды испытаний АС автономные, комплексные, приёмочные испытаний и опытная эксплуатация) и общие требования к их проведению.
7. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов - один из важнейших документов 34 ГОСТа, так как именно в нём описано содержание практически всех документов, а также описание каждого пункта документа.
8. ГОСТ Р ИСО/МЭК 8824-3-2002 Информационная технология. Абстрактная синтаксическая нотация версии один - настоящий стандарт является частью абстрактной синтаксической нотации версии 1 (АСН.1) и устанавливает нотацию для спецификации ограничений, определённых пользователем, и табличных ограничений.
9. ГОСТ Р ИСО/МЭК 10746-3-2001 Управление данными и открытая распределённая обработка.
   В настоящем стандарте:
   • определено, как специфицируются системы открытой распределённой обработки (ОРО) с использованием понятий, введённых в ГОСТ Р ИСО/МЭК 10746-2;
   • идентифицированы характеристики, по которым системы относятся к системам ОРО.

   В стандарте установлен каркас для координации разработки стандартов по системам ОРО.

10. ГОСТ Р ИСО/МЭК 15271-02 Процессы жизненного цикла программных средств - данный ГОСТ необходимо больше, на мой взгляд, для аналитиков при проектировании и моделировании АС.
    Этот документ полезен, с моей точки зрения, в чисто образовательных целях.
11. ГОСТ Р ИСО/МЭК 15910-2002 Процесс создания документации пользователя программного средства - определяет минимально необходимый процесс создания документации пользователя всех видов для программного средства, имеющего интерфейс пользователя. Данные виды охватывают печатную документацию (например, руководства пользователя и краткие справочные карты), диалоговую (оперативную) документацию, справочный текст («хелпы») и системы диалоговой документации.

Итак, исходя из всего выше написанного, видно, что основных документов в 34 ГОСТе 3: ГОСТ 34.201-89, РД 50-34.698-90 и ГОСТ 34.602-89.
При разработке пакета документации, для начала, необходимо открыть ГОСТ 34.201-89 и выбрать стадию создания Эскизный проект, Технический проект и Рабочая документация. Далее, следует выбрать документы для разработки, которые соответствуют стадии создания.

Перечень документов 34 ГОСТа

Примечание к таблице:

1. В таблице приняты следующие обозначения:
   • ЭП — эскизный проект;
   • ТП — технический проект;
   • РД — рабочая документация;
   • ОР — общесистемные решения;
   • ОО — решения по организационному обеспечению;
   • ТО — решения по техническому обеспечению;
   • ИО — решения по информационному обеспечению;
   • ПО — решения по программному обеспечению;
   • МО — решения по математическому обеспечению.
2. Знак Х — обозначает принадлежность к проектно-сметной или эксплуатационной документации.
3. Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.

Когда перечень документов определён, то в РД 50-34.698-90 следует найти выбранные документы и разработать их строго по указанным пунктам. Все пункты содержания, которые указаны, обязательно должны быть в документе.
Если разрабатывается Техническое задание, то сразу нужно открыть ГОСТ 34.602-89 и разработать ТЗ строго согласно пунктам.

ГОСТ 19

Серия ГОСТов 19 (ГОСТ 19.ххх Единая система программной документации (ЕСПД)) состоит:

1. 1. ГОСТ 19.001-77 Общие положения - слишком общий документ, практической пользы он не несёт. Поэтому его можно пропустить.
   2. ГОСТ 19781-90 Термины и определения - хороший список определений в области программного обеспечения систем обработки информации. Кроме как определений больше не содержит ничего.
   3. ГОСТ 19.101-77 Виды программ и программных документов - один из главных документов 19 ГОСТа. Именно с него следует начинать работу с 19 ГОСТом, так как в нём содержится полный перечень и обозначения документов ГОСТа.

Перечень документов 19 ГОСТа

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

1. ГОСТ 19.102-77 Стадии разработки - содержит описание стадий разработки. Полезен в образовательных целях. На мой взгляд, особой практической пользы не несёт.
2. ГОСТ 19.103-77 Обозначения программ и программных документов - содержит описание присвоения номера (кода) документу. Даже после прочтения этого ГОСТа остаётся куча вопросов о том, как же присвоить этот самый номер документу.
3. ГОСТ 19.104-78 Основные надписи - устанавливает формы, размеры, расположение и порядок заполнения основных надписей листа утверждения и титульного листа в программных документах, предусмотренных стандартами ЕСПД, независимо от способов их выполнения. Так как документы 19 ГОСТа оформляются в рамочках, то данный документ очень важен.
4. ГОСТ 19.105-78 Общие требования к программным документам - устанавливает общие требования к оформлению программных документов. Требования слишком общие. Как правило для разработки документа этот ГОСТ почти не применяется, так как хватает специального ГОСТа на документ, но для общих знаний в данный ГОСТ все же лучше заглянуть разок.
5. ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом - содержит требования к оформлению всех документов 19 ГОСТа.
6. ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению - устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия.

   Пункты ТЗ 34 ГОСТа и 19 ГОСТа отличаются.

7. ГОСТ 19.601-78 Общие правила дублирования, учёта и хранения - общие правила дублирования, обращения, учёта и хранения программных документов. В ГОСТе в нескольких пунктах описано как сделать так, чтобы документы не потерялись.
8. ГОСТ 19.602-78 Правила дублирования, учёта и хранения программных документов, выполн-х печ. Способом - дополнение к ГОСТу 19.601-78.
9. ГОСТ 19.603-78 Общие правила внесения изменений - устанавливает общие правила внесения изменений в программные документы. По сути, описывает длинный бюрократический алгоритм внесения изменений в документы.
10. ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненных печатным способом - описывает порядок работы и заполнения с Листа регистрации изменений.

Список специализированных ГОСТов, то есть в каждом из них описано содержание и требования к определённому документу:

1. ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению;
2. ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению;
3. ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению;
4. ГОСТ 19.402-78 Описание программы;
5. ГОСТ 19.403-79 Ведомость держателей подлинников;
6. ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению;
7. ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению;
8. ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению;
9. ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению;
10. ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению;
11. ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению;
12. ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению;
13. ГОСТ 19.507-79 Ведомость эксплуатационных документов;
14. ГОСТ 19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

Порядок работы с 19 ГОСТом:

1. В ГОСТе 19.101-77 выбрать документ и его код согласно стадии разработки.
2. Согласно ГОСТу 19.103-77 присвоить номер документу.
3. Затем по ГОСТам 19.104-78 и 19.106-78 оформить документ.
4. Из специализированного списка ГОСТов следует выбрать тот, который соответствует разрабатываемому документу.

Заключение

ГОСТ - это не страшно и несложно! Главное понять, что нужно написать и какой для этого ГОСТ используется. Наши основные ГОСТы 19 и 34 для написания документации очень старые, но и по сей день актуальны. Написание документации по стандарту снимает множество вопросов между исполнителем и заказчиком. Следовательно, несёт в себе экономию времени и денег.

ГОСТ 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