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

Обновлено: 04.07.2024

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Валеев К.А., Квасницкий В.Н.

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

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Валеев К.А., Квасницкий В.Н.

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

К.А. Валеев, В.Н. Квасницкий

THE SOFTWARE STANDARDS DOCUMENTATION IN INFORMATION SYSTEMS

К.А. Valeev, V.N. Kvasnitsky

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

Ключевые слова: программная документация, стандарты, ГОСТ-19, ГОСТ-34, IEEE.

Abstract. The article focuses on review of existing standards in the field of software and information system documentation development and management. Special attention is given to Russian standards in the field.

Keywords: software documentation, standards, GOST-19, GOST-34, IEEE.

Программная документация - документация, содержащая данные, необходимые для разработки, производства, эксплуатации и сопровождения - необходимая и неотъемлемая составляющая программного средства или информационной системы на всем протяжении их жизненного цикла [5].

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

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

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

МОСКОВСКИЙ ФИНАНСОВО-ЮРИДИЧЕСКИЙ УНИВЕРСИТЕТ МФЮА

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

Большинство основных международных стандартов и методик собраны в периодически обновляющемся обзорном документе Software Engineering Body of Knowledge (SWEBOK), который сам является отдельным стандартом ISO/IEC TR 19759:2005.

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

Сбор и документирование требований к программному обеспечению и системам:

- IEEE Guide to Software Requirements Specifications, IEEE Standard 830-1984;

- IEEE Recommended Practice for Software Requirements Specifications, IEEE Standard 830-1998;

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

ОБЩИЕ ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ

Unified system for program documentation. General requirements for program documents

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

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

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

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

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

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

1. ОБЩИЕ ТРЕБОВАНИЯ

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

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

1.3. Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.

2. ТИТУЛЬНАЯ ЧАСТЬ

2.1. Титульная часть состоит из листа утверждения и титульного листа.

Правила оформления листа утверждения и титульного листа - по ГОСТ 19.104-78.

3. ИНФОРМАЦИОННАЯ ЧАСТЬ

3.1. Информационная часть должна состоять из аннотации и содержания.

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

3.3. В аннотации приводят сведения о назначении документа и краткое изложение его основной части.

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

обозначение структурного элемента (номер раздела, подраздела и т.п.);

наименование структурного элемента;

адрес структурного элемента на носителе данных (например, номер страницы, номер файла и т.п.).

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

4. ОСНОВНАЯ ЧАСТЬ

4.1. Состав и структура основной части программного документа устанавливаются стандартами ЕСПД на соответствующие документы.

5. ЧАСТЬ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ

5.1. О каждом изменении программного документа в этой части делается запись в соответствии с требованиями ГОСТ 19.603-78.

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

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

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

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

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

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

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

В состав ЕСПД входят:

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

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

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

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

Стандарты ЕСПД носят рекомендательный характер.

Стандарты ЕСПД разделяются на группы:

- 0 код - группы об общем положении;

- 1 код - группы основополагающей стандартов;

- 2 код - правила выполнения документации разработки;

- 3 код - правила выполнения документации изготовителя;

- 4 код - правила выполнения документации сопровождения;

- 5 код - правила выполнения эксплуатационных документов;

- 6 код - правила обращения программной документации;

- 7-8 резервные группы;

- 9 прочие стандарты.

Обозначение стандартов ЕСПД строятся по классификационному признаку.

В обозначении стандартов ЕСПД должны входить:

- цифры 1 и 9 присвоены классу стандартов ЕСПД;

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

- двузначное число, определяющее порядковый номер группы;

- двузначное число после тире (-) указывающее год регистрации стандартов (рисунок 27.1).


Рисунок 27 – Схемы алгоритмов программ данных и систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основополагающие стандарты

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

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

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

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

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

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

1. Спецификация – содержит состав, программу и документацию на нее.

2. Ведомость держателей подлинников - это перечень предприятий, на которых хранят подлинники программных документов (код 05).

3. Текст программы – это запись программы с необходимыми комментариями (код 12).

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

5. Программа и методика испытаний содержит требования подлежащие проверке при испытании программы, а так же порядок и методы их контроля (код 51).

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

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

Эксплуатационные документы содержат сведения для обеспечения функционирования и эксплуатации программы. К эксплуатационным документам относятся:

а) ведомость эксплуатационных документов, содержащая перечень эксплуатационных документов на программу (код 20);

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

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

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

д) руководство программиста, содержащее сведения для эксплуатации программ (код 32);

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

ж) описание языка, содержащее описание синтаксиса и семантики языка (код 35);

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

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

Стадии разработки программ

Существуют следующие стадии разработки программ:

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

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

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

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

5. Внедрение. На этапе подготовки передачи программ осуществляют подготовку передачи программы и программной документации для сопровождения и изготовления, оформляют и утверждают акт о передаче программы на сопровождение и изготовление, передают программу в фонд алгоритмов и программ. [29]

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

500
500
500
500
500
500
500
500
500
500
500
500
500
500
500
500
500

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

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

Стандарты имеют большое значение – они обеспечивают возможность разработчикам программного обеспечения использовать данные и программы других разработчиков, осуществлять экспорт/импорт данных. Такие стандарты регламентируют взаимодействие между различными программами. Для этого предназначены стандарты межпрограммного интерфейса, например OLE (Object Linking and Embedding – связывание и встраивание объектов). Без таких стандартов программные продукты были бы “закрытыми” друг для друга Стандарты имеют большое значение – они обеспечивают возможность разработчикам программного обеспечения использовать данные и программы других разработчиков, осуществлять экспорт/импорт данных. Такие стандарты регламентируют взаимодействие между различными программами. Для этого предназначены стандарты межпрограммного интерфейса, например OLE (Object Linking and Embedding – связывание и встраивание объектов). Без таких стандартов программные продукты были бы “закрытыми” друг для друга

5. Стандарты, определяющие термины по программному обеспечению (ГОСТ Р ИСО/МЭК 2382-23-2004, ГОСТ 28806-90, ГОСТ 20886-85, ГОСТ 24402-88, ГОСТ 15971-90, ГОСТ 19781-90). 5. Стандарты, определяющие термины по программному обеспечению (ГОСТ Р ИСО/МЭК 2382-23-2004, ГОСТ 28806-90, ГОСТ 20886-85, ГОСТ 24402-88, ГОСТ 15971-90, ГОСТ 19781-90). 6. Стандарты на процессы жизненного цикла программного обеспечения (ГОСТ Р ИСО/МЭК 12207-99, ГОСТ Р 51904-2002, ГОСТ Р 51189-98, ГОСТ Р ИСО/МЭК 15504-2009, а также отнесем сюда КТ-178В). 7. Обучающие стандарты (ГОСТ Р ИСО/МЭК ТО 12182-2002, ГОСТ Р ИСО/МЭК 15026-2002).

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

Эффективность Эффективность Эффективность (Efficiency): способность ПО обеспечивать требуемую производительность относительно количества используемых ресурсов в установленных условиях. Временная эффективность (Time behaviour): способность ПО обеспечивать приемлемые времена отклика и обработки, а также пропускную способность при выполнении его функций в установленных условиях. Использование ресурсов (Resource utilization): способность ПО использовать приемлемые ресурсы в течение приемлемого времени при выполнении его функций в установленных условиях. Согласованность (Compliance): способность ПО придерживаться стандартов или соглашений, связанных с эффективностью.

Практичность Практичность Практичность (Usability): способность ПО, обусловливающая легкость его понимания, изучения и использования, а также привлекательность для пользователя при использовании в указанных условиях. Понятность (Understandability): способность ПП, обеспечивающая пользователю понимание, является ли ПО пригодным, и как его можно использовать для конкретных задач и условий использования. Изучаемость (Learnability): способность ПП, обеспечивающая изучение пользователем его применения. Легкость использования (Operability): способность ПП, обеспечивающая пользователю возможность его эксплуатировать и управлять им. Привлекательность (Attractiveness): способность ПП нравиться пользователю. Согласованность (Compliance): способность ПО придерживаться стандартов, соглашений, руководств по стилю или норм, связанных с практичностью.

Надежность Надежность Надежность (Reliability): способность ПО сохранять свой уровень качества функционирования при использовании в указанных условиях. Завершенность (Maturity): способность ПО предотвращать отказ как следствие ошибок в ПО. Устойчивость к ошибке (Fault tolerance): способность ПО поддерживать заданный уровень качества функционирования в случаях ошибок в ПО или нарушения установленного интерфейса. Восстанавливаемость (Recoverability): способность ПО в случае отказа восстанавливать уровень качества функционирования и поврежденные данные. Согласованность (Compliance): способность ПО придерживаться стандартов, соглашений или норм из законов и подобных предписаний, связанных с надежностью.

Функциональные возможности Функциональные возможности Функциональные возможности (Functionality): способность ПО обеспечивать функции, удовлетворяющие установленные и подразумеваемые потребности при использовании ПО в заданных условиях. Пригодность: способность ПО обеспечивать соответствующий набор функций для указанных задач и целей пользователя. Правильность : способность ПО обеспечивать правильные или приемлемые результаты или эффекты. Способность к взаимодействию. : способность ПО взаимодействовать с одной или большим числом указанных систем. Защищенность : способность ПО защищать информацию и данные так, чтобы не уполномоченные субъекты или системы не могли читать или изменять их, а уполномоченные субъекты или системы не получали отказа на доступ к ним. [ISO 12207: 1995] Согласованность : способность ПО придерживаться стандартов, соглашений или норм из законов и подобных предписаний, связанных с областью применения.

Сопровождаемость Сопровождаемость Сопровождаемость (Maintainability): способность ПО к модификации. Изменения могут включать исправления, усовершенствования или адаптацию ПО к изменениям в среде, а также в требованиях и функциональных спецификациях. Анализируемость (Analyzability): способность ПП к диагностике его недостатков или причин отказов в ПО, а также к идентификации его частей для модификации. Изменяемость (Changeability): способность ПП к обеспечению реализации специфицированных изменений. Стабильность (Stability): способность ПО минимизировать непредвиденные эффекты от его изменений. Тестируемость (Testability): способность ПП, обеспечивающая проверку и приемку модифицированного ПО. Согласованность (Compliance): способность ПО придерживаться стандартов или соглашений, связанных с сопровождаемостью.

Мобильность Мобильность Мобильность (Portability): способность ПО к переносу из одной среды в другую. Адаптируемость (Adaptability): способность ПО к модификации для различных указанных сред без применения других действий или средств, чем те, что предназначены для этой цели для рассматриваемого ПО. Легкость установки (Installability): способность ПО к установке в указанной среде. Сосуществование (Co-existence): способность ПО сосуществовать с другим независимым ПО в общей среде, разделяя общие ресурсы. Заменяемость (Replaceability): способность ПО к использованию вместо другого указанного ПО в среде заменяемого ПО. Согласованность (Compliance): способность ПО придерживаться стандартов или соглашений, связанных с мобильностью.

Ответить на вопросы: Ответить на вопросы: Почему считается, что стандарты помогают пользователям, заказчикам и разработчикам? Почему стандарты важны для разработчика сайта?

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

Общие моменты

С 1 июля 2020 года вступит в силу приказ Федерального агентства по техническому регулированию и метрологии от 29.04.2019 № 175-ст, которым предусмотрено два нововведения:

  • ГОСТ 2.105-95 утрачивает силу в качестве национального стандарта, но сохраняет действие в качестве межгосударственного;
  • ГОСТ Р 2.105-2019 признают национальным.

Дополнительно в этой сфере приняты:

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

Способы оформления

Разрешается заполнять документацию:

  • машинописным способом в соответствии с ГОСТ 13.1.002-2003. Межгосударственный стандарт. Репрография. Микрография. Документы для микрофильмирования. Общие требования и нормы (введен в действие Постановлением Госстандарта России от 26.02.2004 № 63-ст);
  • рукописным методом, используя положения ГОСТ 2.304-81. Межгосударственный стандарт. Единая система конструкторской документации. Шрифты чертежные (утв. Постановлением Госстандарта СССР от 28.03.1981 № 1562);
  • применяя ЭВМ, согласно ГОСТ 2.004-88. Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ (утв. Постановлением Госстандарта СССР от 28.11.1988 № 3843);
  • на электронных носителях информации.

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

Техническое оформление: общие требования

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

Межгосударственный стандарт ГОСТ 2.105-95

Национальный стандарт ГОСТ Р 2.105-2019

Высота символов — не менее 2,5 мм

· шрифт Times New Roman или Arial размером 14 для основного текста и размером 12 для приложений, примечаний, сносок и примеров;

· допускается использование шрифта размером 13 и 11 для основного текста и размером 12 и 10 для приложений, примечаний, сносок и примеров соответственно.

Расстояние между боковыми линиями формы и текстом должно составлять минимум 3 мм

Абзац начинается с красной строки, минимальный отступ — 15 — 17 мм

Абзацы начинается с отступа, равного 12,5 — 17 мм

От нижней и верхней границ следует отступать не менее 10 мм

Интервал между строками — не менее 8 мм

· текст оформляют с использованием полуторного межстрочного интервала;

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

· расстояние между заголовком и текстом при выполнении документа машинописным способом равно 3, 4 интервалам, при выполнении рукописным способом — 15 мм;

· расстояние между заголовками раздела и подраздела — 2 интервала, при выполнении рукописным способом — 8 мм.

· расстояние между заголовком и текстом, между заголовками раздела и подраздела — не менее 4 высот шрифта, которым набран основной текст. Расстояние между строками заголовков подразделов и пунктов принимают таким же, как в тексте;

· при выполнении машинописным способом интервал равен 3 или 4 интервалам, при выполнении рукописным способом — не менее 15 мм.

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

Относительно копий в ГОСТ 2.105-95 заявлено, что их (здесь и далее приведены выдержки из текста):

выполняют одним из следующих способов:

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

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

  • сканированием исходного бумажного документа;
  • конвертированием или трансформированием ТДЭ из одного формата в другой или из одной схемы данных в другую;
  • цифровым копированием.

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

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

Что касается нумерации, ЕСКД при оформлении документов позволяет сделать ее как сквозной, так и отдельной для каждого раздела.

Чего делать нельзя

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

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

Помимо этого, требования ЕСКД 2020 года запрещают:

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

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

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

2

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

Читайте также: