Требования к тексту программы

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

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

ЕДИНАЯ СИСТЕМА
ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

ТЕКСТ ПРОГРАММЫ
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

United System for Program Documentation.
Text of program
Requirements to contents and form of presentation

Постановлением Государственного комитета СССР по стандартам от 18декабря 1978 г. № 3350 срок введения установлен

1. Настоящий стандартустанавливает требования к содержанию и оформлению программного документа«Текст программы», определенного ГОСТ19.101-77.

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

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

2. Структуру и оформление документаустанавливают в соответствии с ГОСТ19.105-78.

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

Пример оформления по ГОСТу реферата, курсовой и дипломной работы

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

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

Допускается вводитьнаименование также и для совокупности разделов.

4. Каждый из этих разделовреализуется одним из типов символической записи, например:

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

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

символическое представлениемашинных кодов и т. п.

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

* Переиздание (Ноябрь1987 г.) с Изменением № 1, утвержденным в марте 1983 г. (ИУС 7-83)

allgosts.ru

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

Источник: allgosts.ru

ГОСТ Стандарт документирования программного обеспечения

Единая система документации программной продукции – ЕСПД – относится к ГОСТ класса 19 и подразделяется на 10 групп:
1. Основополагающие стандарты.
2. Правила выполнения документации разработки.
3. Правила выполнения документации изготовления.
4. Правила выполнения документации сопровождения.
5. Правила выполнения эксплуатационной документации.
6. Правила обращения программной документации.

Стандарт с номером 0 содержит общие положения, стандарты 7 и 8 являются зарезервированными и к номеру 9 относятся прочие стандарты, не вошедшие в первые 6.

Это краткие описания ГОСТов класса 19, для более подробного ознакомления с ними необходимо обратиться к справочникам.

• ГОСТ 19.001-77 – единая система программной документации.
• ГОСТ 19.101-77 – виды программ и программных документов.
• ГОСТ 19.102-77 – стадии разработки программ и программной документации.
• ГОСТ 19.105-78 – требования к оформлению программных документов, комплексов и систем независимо от их назначения и области применения. ГОСТ 19.105-78 содержит полный перечень документации, которая должна сопровождать законченный программный продукт.

Перечень документации, декларируемой ГОСТ 19.105-78:

Как 1 раз настроить стиль форматирования текста при создании нового документа Word

1. Документы, содержащие сведения, необходимые для разработки программного продукта, его изготовления.
1.1. Спецификация – состав программы и документации на нее.
1.2. Ведомость держателей подлинников – перечень предприятий, на которых хранятся подлинники программной документации.
1.3. Текст программы – запись текста программы с необходимыми комментариями.
1.4. Описание программы – сведения о логической и функциональной структуре программы.
1.5. Программа и методика испытаний – требования, подлежащие проверке при испытании программы, порядок и методы их контроля.
1.6. Техническое задание – назначение и область применения программы, технические и специальные требования, необходимые стадии и сроки разработки, виды испытаний.
1.7. Пояснительная записка – схема алгоритма, общее описания алгоритма, выполняемая программой функция. Объяснение принятых технических решений.

2. Документы, используемые при эксплуатации программного продукта.
Ведомость эксплуатационных документов – перечень эксплуатационных документов на программу.
Формуляр – основные характеристики программы, комплектность, общие сведения об эксплуатации программы.
Описание применения – сведения о назначении программы, области применения, классе решаемых задач, ограничения на применение, необходимая конфигурация технических средств.
Руководство системного программиста – сведения для проверки и обеспечения функциональности, настройки программы.
Руководство программиста – сведения для эксплуатации настроенной программы.
Руководство оператора – сведения для обеспечения процедуры общения оператора с ЭВМ в процессе выполнения программы.
Описание языка – описание синтаксиса и семантики языка, используемого в программе.
Руководство по техническому обслуживанию – сведения для применения тестовых программ при обслуживании технических средств.

Другие ГОСТы класса 19:

Источник: www.tadviser.ru

Система регламентов (часть 2): требования к функционалу текстового редактора для составления регламентов

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

Автор книги «Системное управление на практике: 50 историй из опыта руководителей для развития управленческих навыков» https://50stories.ru/

генеральный директор и собственник агентства управленческого консалтинга «Открытая Студия»: http://openstud.ru и основатель «Школы регулярного менеджмента» (обучение для собственников и руководителей): https://regular-management.ru/

эксперт по системному управлению
Перестав быть спорной, мысль перестает быть интересной
Уильям Хэзлитт

кому: собственникам, топ-менеджерам

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

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

Сегодня я расскажу про требования к текстовому редактору документов, используемому для разработки и написания регламентов. От текстового редактора зависит: скорость и удобство написания документа-инструкции; возможность постоянного развития и оперативного обсуждения регламента и многое другое.

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

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

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

Рассчитываю, что вы прочитали первую часть и уже “погрузились в тему”. Поэтому без лишних предисловий — поехали!

Оглавление статьи

• Ключевые требования к текстовому редактору для создания и хранения регламентов
• 1. Абсолютная ссылка на документ в рамках всей системы регламентов
• 2. Создание нового документа на основе шаблона
• 3. Создание кастомизированных (своих) стилей в документе
• 4. Иерархия заголовков: как создавать и в чём смысл
• 5. Абзацы, маркированные списки
• 6. Генерация оглавления документа на основании заголовков
• 7. Правильная вставка текста из других источников
• 8. Кросс-ссылки в тексте на связанные документы
• 9. Кросс-ссылки в тексте на другие разделы текущего документа
• 10. Закладки на произвольное место в документе
• Подведение итогов, или Как выбирать программное обеспечение для системы регламентов

Ключевые требования к текстовому редактору для создания и хранения регламентов

1. Абсолютная ссылка на документ в рамках всей системы регламентов

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

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

Продемонстрирую на примере. Допустим, вы решили перенести регламент “Обработка входящих писем” из папки “Managers” (для менеджеров) в папку “ALL” (для всех). Если бы у нас не было абсолютной ссылки, то пришлось бы искать и заменять во всех существующих документах все ссылки на регламент “Обработка входящих писем”.

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

2. Создание нового документа на основе шаблона

Шаблон — это заранее подготовленный документ, где есть примеры оформления текста: заголовки h1-h6, абзацы, списки, таблицы и т.д. Все новые документы создаются только на основе разработанного вами шаблона путём его копирования.

На скриншоте пример шаблона для создания новых документов + показана иерархия заголовков (Google Docs)

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

3. Создание кастомизированных (своих) стилей в документе

Что означает возможность определять и создавать собственные стили в документе? Представьте, что у вас есть некий заголовок (например, второго уровня — h2). Вы отформатировали его и присвоили определенный размер шрифта и цвет шрифта. Теперь у вас есть возможность “по нажатию одной кнопки” применить этот стиль ко всем остальным заголовкам “второго уровня” в документе.

На скриншоте пример создания кастомизированных стилей (для Google Docs)

Важно, чтобы заданные стили оставались стилями “по-умолчанию” в том числе для документов, полученных путём копирования исходного. Эта возможность как раз используется при копировании шаблона (см. пункт выше).

С чего начать наведение порядка и переход на системное управление? Пройдите индивидуальную диагностику своего управленческого стиля по методике Евгения Севастьянова

Стоимость: 9 970 р Бесплатно только 2 места до 26 июня 2023!

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

Звоните и задавайте вопросы:

• +7 (812) 643-42-70 (будни)

• +7 (495) 540-47-72 (будни)

Источник: openstud.ru