ubm-1986 (Все сообщения пользователя)

Внимание! У нас сбои с почтовым сервером! Если не пришло письмо о регистрации или смене пароля напишите нам на info@techwriters.ru! 
@twriters
 obmen_soobsheniyami.pngчат для технических писателей в Telegram

 Зарегистрируйтесь
Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
Рамки по Гост, Рамки по ГОСТ обязательны ли?
 
С точки зрения ГОСТов:

- пользовательская документация (видимо имеется в виду руководства админов/программистов и т.п.) делается по ГОСТам 19 серии - там рамок нет
- документация на систему (видимо имеется в виду рабочая конструкторская и эксплуатационная документация) делается по ГОСТам 2 серии - там рамки могут быть (видел где-то в ГОСТах, что можно делать без рамки - только наименование документа и страницу ставить наверху/внизу (не помню точно где)).
Гост на оформление, Какой выбрать
 
Цитата
Slon написал:
Там написано содержание, я имел ввиду оформление - шрифты, поля, подписи и прочие нюансы.
Там про оформление сказано (если не полениться до конца прочитать). Целый раздел даже есть.

Цитата
3. ПРАВИЛА ОФОРМЛЕНИЯ
3.2. ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105.95 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней.
Внесение материалов для изготовления ЭД в КД., Проблема с нормоконтролем и ПЗ
 
А сказать нечто типа "Требования не предъявляются"?
Если не указано в ТЗ, то пусть либо этой фразой довольствуются, либо дополнение к требованиям ТЗ делают и там сами требования выдвигают.
Повествовательная или повелительная форма при изложении текста
 
То что никакого "повелевающего наклонения" нет - это ёжику понятно. Поэтому я его при первом использовании в кавычки взял (во втором - кавычки потерялись, к сожалению).

К сожалению, несуразицу, написанную в ГОСТе, в научных терминах объяснить не получается. Приходится произвольным словообразованием заниматься, которое тоже ГОСТом запрещено, кстати :)
Повествовательная или повелительная форма при изложении текста
 
Цитата
Больше меня интересует все-таки вопрос про ТУ.
В ТУ (а тем более в методах контроля) более уместно повелевающее наклонение. Человеку, который изделие на соответствие ТУ проверяет, явным образом приказываю что нужно сделать.

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

в первом случае, если выражаться прилично, то мне мягко говоря всё равно кто, что, каким способом и как часто (вдруг раз в 1000 лет)  делает.
во втором случае мне явно сказано нужно/я должен сделать.


опять же разграничение: в первом случае мне сообщают информацию (говорят что я могу сделать, а могу и не делать), во втором говорят что я должен сделать.
Повествовательная или повелительная форма при изложении текста
 
Уместнее трактовать словосочетание "повелительное наклонение" как.. назовём это "повелевающее наклонение" или "повелевающая интонация". Если смотреть на примере про "нажать кнопку", то  , вместо "...кнопку нажимают чтобы включить прибор..." авторы ГОСТа хотели бы увидеть нечто типа читать "[повелеваю/требуется] нажать кнопку чтобы включить прибор". Т.е. тут идёт разграничение в плане "делают"/"требуется сделать".
Гост на оформление, Какой выбрать
 
Цитата
Slon написал:
Например, руководство пользователя АС, или отчет, протокол, ТЗ на АС..
Документы на АС регламентируются ГОСТами 34 серии. Ознакомиться с ними можно тут:http://www.rugost.com/index.php?option=com_content&view=category&id=22&Itemid=53.

В частности:
- ТЗ на АС - ГОСТ 34.602-89
- Руководство пользователя - РД 50-34.698-90
- отчёт и протокол (опять же, отчёты и протоколы разные бывают - что конкретно нужно можно только догадываться): например, содержание протокола испытаний и протокола согласования описано в том же РД 50-34.698-90.
Гост на оформление, Какой выбрать
 
Вопрос про "почему" немного странный. Не хочу обидеть, но это нечто из серии "Почему для откручивания гайки 12 нужно использовать именно ключ на 12, а не ключ на 10?"

Вот, например, ГОСТ 7.32-2001 " Система стандартов по информации, библиотечному и издательскому делу. ОТЧЕТ О НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ. Структура и правила оформления". Я буду отчёт о НИР оформлять по этому ГОСТу хотя бы потому, что ГОСТ предназначен именно для этого.

Как вариант руководство по эксплуатации:
- содержание и смысловое наполнение разделов по ГОСТ 2.610
- форматирование текста по ГОСТ 2.105 (в плане отступов, рисунков, таблиц и т.д. без привязки к сущности напечатанного)
- основная надпись по ГОСТ 2.104
- список сокращений делается с учётом ГОСТ 2.316
и т.д.

Чтобы дать ответ на вопрос каким ГОСТом пользоваться нужно понимать что за документ будет. Хотя бы приблизительно.
Изменено: ubm-1986 - 21.09.2016 18:57:31
Создание одной АС внутри другой АС ?
 
По поводу вопроса о том может ли АС включать другую АС - можно посмотреть ГОСТ 34.003 (в частности определения 2.13 и 2.15). Там явных запретов нету - компонентом АС может быть что угодно.


Да и по здравому смыслу - тоже не вопрос. Как аналогия:
АС-2 - система оплаты штрафов ГИБДД.
АС-1 - система госуслуг в целом.
Изменено: ubm-1986 - 09.09.2016 11:42:17
Создание одной АС внутри другой АС ?
 
В общем случае АС = железо + софт.

В ГОСТ 34.201 сказано
Цитата
1.3.2. Виды документов на программные средства, используемые при создании АС (ее частей), - по ГОСТ 19.101.77.

1.3.3. Виды документов на технические средства, используемые при создании АС (ее частей), - по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.

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

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

3. Из эксплуатационных документов - одно из [формуляр/паспорт/этикетка] и ведомость эксплуатационных документов.


Это минимальный комплект.


В случае автора:
1. Как я понял АС-2 - это просто ПО (исходя из п.2 автора). Соответственно на АС-2 нужны:
- тексты всех компонентов
- спецификация.

2. АС-1 - видимо это полноценная система, соответственно нужно всё вышеописанное для общего случая.
Каков порядок присвоения дополнительной нумерации документов с одинаковыми обозначениями?
 
Цитата
TechW написал:
Но, повторюсь ещё раз, это стандарт только для АСУ и  "Настоящие правила не распространяются на документы, правила обозначения которых регламентированы государственными стандартами других систем документации", попробуйте найти свой ГОСТ
Согласно ГОСТ 34.201 документ "Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)", код которого установлен в соответствии с требованиями стандартов ЕСКД. Видимо, тут всё-таки отсылка на ГОСТ 2 идёт. Соответственно не через точку надо обозначать.
Каков порядок присвоения дополнительной нумерации документов с одинаковыми обозначениями?
 
Цитата
Виктор Фигурнов написал:
Непонятно, на основании чего вы делаете столь категоричные заявления. Программы и методики испытания, и документы с литерами ПМ в обозначениях могут быть и бывают и для автоматизированных систем (ГОСТ 34), и для программных систем (ГОСТ 19), и для систем разработки и постановки продукции на производство (ГОСТ РВ 15), и др. Я видел такие документы где заказчиками были министерства РФ и крупнейшие коммерческие заказчики.

По поводу ГОСТ 34.
Не вопрос - пусть будет автоматизированная система. Я наличия ПМ для АС не отрицал. Но, как я говорил выше ГОСТ 34 отошлет к ГОСТ 2.

По поводу ГОСТ 19.
Что такое программная система? В терминах и определениях (ГОСТ 19781) такого термина нет, соответственно можно только догадываться что это такое. Но даже не в этом дело.
Согласно ГОСТ 19.101 программа и методика испытаний имеет код 51. Для ЕСПД вообще буквенных кодов не предусмотрено. У автора код "ПМ", соответственно логично, что не ЕСПД, а ЕСКД. Опять же я наличия ПМ в рамках ЕСПД не отрицал.


По поводу ГОСТ 15 не очень понял. Можно ссылку на конкретный ГОСТ? Не особо силён в 15 серии.

Цитата
Виктор Фигурнов написал:
Я видел такие документы где заказчиками были министерства РФ и крупнейшие коммерческие заказчики.
Без обид - ни разу не аргумент. Предлагаю оперировать цитатами из ГОСТов.

Был конкретный вопрос "как поступить?". Соответственно предложил конкретное решение для конкретного варианта с сылками на ГОСТ. Решение каким-то ГОСТам противоречит?
Каков порядок присвоения дополнительной нумерации документов с одинаковыми обозначениями?
 
Полагаю конкретно для автора уже не актуально, но всё же. Пригодится другим.

1. По кукому ГОСТу делать?

В ответах есть ссылки на ГОСТы 19 и 34. Но они именно для данного конкретного случая не совсем уместны, а, скорее, совсем неуместны.

У документа в наименовании ПМ, соответственно, это ЕСКД => 19 ГОСТ тут не актуален ни разу.
Автор упоминает "изделие", соответственно, велика вероятность, что его это не автоматизированная система, а одна железка => 34 ГОСТ тоже не актуален. К тому же, в ГОСТ 34.201 явно идёт ссылка на ЕСКД (если ошибаюсь - поправьте).
Цитата
1.3.3. Виды документов на технические средства, используемые при создании АС (ее частей), - по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.
2.3. Комплектность документации, обеспечивающей разработку, изготовление, приемку и монтаж технических средств, - по ГОСТ 2.102. Комплектность эксплуатационной документации на эти средства - по ГОСТ 2.601.
Получается, что руководствоваться надо требованиям ЕСКД.


2. Требования ЕСКД

ГОСТ 2.105
Цитата
4.1.1 Текст документа при необходимости разделяют на разделы и подразделы.
При большом объеме документа допускается разделять его на части, а части, в случае необходимости, на книги. Каждую часть и книгу комплектуют отдельно. Всем частям дают наименования и присваивают обозначение документа. Начиная со второй части, к этому обозначению добавляют порядковый номер, например: ХХХХ.331112.032 ФО, ХХХХ.331112.032 ФО1, ХХХХ.331112.032 ФО2, и т.д. Всем книгам дают наименование и присваивают порядковый номер.
ГОСТ 2.201
Цитата
Обозначение неосновного конструкторского документа должно состоять из обозначения изделия и кода документа, установленного стандартами ЕСКД.

В коде документа должно быть не более четырех знаков, включая номер части документа.
Примеры:
АВГБ.061341.021 СБ,
АВТБ.061341.021 ТУ1,
АВГБ.061341.021 ИЭ12.

3. Другой вариант

Именно для данного конкретного случая: когда заказчик требует у автора некую ПМ, назовём её "для себя".
Цитата
Документ АБВГ.123456.789ПМ??? не является частью документа АБВГ.123456.789ПМ, так ка в них описаны совершенно разные программы и методики испытаний. На разных предприятиях присвоение выполняется по разному.
В этом случае можно присвоить этому документу код "Д" и дать наименование "Программа и методика испытаний на заводе заказчика такого-то"

ГОСТ 2.106
Цитата
15.1 Документы прочие выполняют на формах 9 и 9а приложения А, допускается применять формат A3 по ГОСТ 2.301, при этом основную надпись и дополнительные графы к ней выполняют в соответствии с требованиями ГОСТ 2.104 (формы 2 и 2а).
15.2 Порядок изложения документов прочих определяется характером излагаемых требований.
Использование сокращений, Если есть список сокращений, в тексте используются только сокращения?
 
Цитата
juklya написал:
Если в документе есть список сокращений, то
1) надо ли писать (далее - ...) при первом упоминании;
2) в дальнейшем тексте документа уже больше нельзя упоминать полное словосочетание, только сокращение и больше никак?

1) Если расшифровка сокращения идёт при первом упоминании, то логично, что это сокращение будет использоваться далее. По мне так лишнее слово.

2) Можно и даже нужно, скажем, в паспорте/формуляре. Например, всякие "ответственные разделы" типа гарантии и т.д.: там полное наименование печатать - достаточно аристократично. А, в целом, сокращения нужны чтобы место сэкономить и текст разгрузить.
Названия кнопок и пунктов меню в руководстве пользователя
 
Цитата
А названия клавиш клавиатуры не выделяются:
To extend the selection, press Shift+Arrow.

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

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

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

Как видно из строки выше - в куче общих слов (42 слова, не считая первого "Например") видна чёткая последовательность (всего 3 слова) "Вставить" => "Рисунок" => "Вставить". Человеку знакомому с программой (который просто не может всего запомнить или не хочет этого делать) будет очень легко "скакать глазами" по полужирному шрифту документа.
Изменено: ubm-1986 - 27.04.2016 14:49:03
Как вы начинаете разрабатывать пользовательскую документацию? Содержание документа Руководство пользователя, Содержание документа, планирование содержания пользовательской документации
 
Цитата
Виктор Фигурнов написал:
Цитата
writer   написал:
нужно написать Руководство пользователя
Вопрос: Как вы решаете, какое содержание будет у документа? Отталкиваетесь от Меню программы, от Задач, которые решает программа, от Бизнес-процессов или...?
Решать надо на основе ГОСТ Р ИСО/МЭК 15910—2002 "Процесс создания документации пользователя программного средства"
Вопрос, скорее всего, затрагивает ту часть руководства где говорится на какие кнопки нажимать и что будет происходить.

Пользователь использует ПО чтобы решить некие конкретные задачи (как было сказано ранее). Соответственно, он должен выполнить некие действия. Вот их и надо описывать. А меню может быть криво (интуитивно непонятно / неудобно / непривычно) скомпоновано.

Например, Word 2007.
Хочу вставить рисунок - выбираю вкладку меню "Вставить", на ней выбираю "Рисунок". Всё прозрачно и понятно: перефразируя "Как слышится так и пишется" получаем нечто типа "Что требуется - то в меню и выбирается".
Хочу вставить примечание - рука тянется выбрать вкладку "Вставить", а нужна вкладка "Рецензирование". С ходу неподготовленный человек может и не догадаться. Приходится шариться по меню или гуглить. А если гуглим, то, опять же, ищем набор конкретных действий.

Так что отталкиваться лучше от задач, которые решает программа.
ТУ на ПО
 
Цитата
Это если рассматривать ПО как Изделие по 2-му ГОСТ, то такой документ может потребоваться.
У нас в таком документе описывались требования к носителю, на котором поставляется ПО, требования к поставке ПО (комплект документации, коробка) и описывался в общих чертах процесс производства ПО как изделия, который начинался с того, что "возьмите сформированный дистрибутив и запишите на диск".
Тогда по ГОСТ 2.114 нужно делать ТУ на "компакт диск с ПО".

Возможно вопрос состоит в том что есть диск и нужно что-то у него проверить? А что у этого диска проверять непонятно?
Если мне бы нужно было написать ТУ на "диск в коробке", то я бы пробежался по пункту 4.3.1 ГОСТ 2.114 и взял оттуда что подходит. Скорее всего могут интересовать: маркировка (как диска так и упаковки), проверка внешнего вида как диска так и упаковки (без царапин, сколов, потёртостей и т.д.), контрольная сумма.
Название поля в форме
 
Видимо вопрос тогда не совсем правильно понял. Спорить не буду.
Название поля в форме
 
Цитата
Виктор Фигурнов написал:
Тут программирование вообще ни при чём. Очевидно, что данная экранная форма сделана не для программистов. Поэтому текст ее полей и ее описание в документации должны быть понятны для ее целевой аудитории, а вовсе не для программистов, сисадминов или прочих IT-шников.

Тут юриспруденция вообще ни при чём. Вопрос был задан про три точки в объекте типа "выпадающий список" и название этого выпадающего списка. Смысловое значение наименования этого выпадающего списка с юридической точки зрения автора не сильно волнует.

P.S. Про целевую аудиторию вне контекста мы можем только догадываться .
Термины и сокращения, Термины и сокращения при разработке документации на создание АС
 
По опыту работы (в том числе с военпредами в рамках ГОЗ) могу сказать следующее:

1. ТЗ должно быть понятно обоим сторонам. Если можно договориться, то можно и не делать сокращения. Главное чтобы они не было разногласий, скажем в таких сокращениях как КБ (коммерческий банк, а не общепринятое конструкторское бюро) или ОС (оконечная станция, а не общепринятая операционная система)
2. После сдачи проекта ТЗ идёт в помойку и все про него забывают, в отличии от эксплуатационной документации, которая остаётся с изделием до конца его биографии.

Соответственно (при условии доверительных отношений), будучи представителем заказчика я бы не заставлял делать список сокращений в ТЗ, а вот в эксплуатационной документации потребовал бы.
Термины и сокращения, Термины и сокращения при разработке документации на создание АС
 
Да нужно.

Есть два ГОСТа (по крайней мере, я знаю), которые регламентируют написание ТЗ:

19.201 - ТЗ на программное обеспечение
34.602 - ТЗ на автоматизированные системы



В 19.201:
Цитата
1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

В 19.106:
Цитата
2.8.1. Сокращения слов в тексте и надписях под иллюстрациями не допускаются, за исключением:
сокращений, установленных в ГОСТ 2.316-68, и общепринятых в русском языке;
сокращений, применяемых для обозначения программ, их частей и режимов работы, в языках управления заданиями, в средствах настройки программы и т.п., в том числе обозначаемых буквами латинского алфавита.
Если в документе принята особая система сокращений слов или наименований, то в нем должен быть приведен перечень принятых сокращений.



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

В 2.105:
Цитата
4.2.6 Перечень допускаемых сокращений слов установлен в ГОСТ 2.316.
Если в документе принята особая система сокращения слов или наименований, то в нем должен быть приведен перечень принятых сокращений, который помещают в конце документа перед перечнем терминов.
Название поля в форме
 
Выскажусь как человек не чуждый программированию.

Автор прав. При этом, могу посоветовать переформулировать примерно так: "В выпадающем списке «Юр/физ лицо» отображаются допустимые определения субъекта права".

P.S. Символы типа трёх точек, плюсиков и т.д. в программировании зачастую сигнализируют пользователю, что часть информации скрыта и если на эти точки/плюсики нажать, то информация отобразится в развёрнутом виде или высветится ещё одно окошко и т.д. Не более того.
ТУ на ПО
 
Все программные документы перечислены в ГОСТ 19.101-77. ТУ на ПО там нету. ТУ на ПО быть не нужно в принципе - поясню почему.

Возьмём, например, стол. Все столы (как объекты реального мира), выходящие с одного и того же завода (даже с одной и той же сборочной линии), немного разные: скажем, длина одного стола 1000,00 мм, другого 999,99 мм, качество покраски тоже может быть разное. Соответственно, есть необходимость проверить, что длина стола не более 1000 мм (используя линейку), стол не имеет непрокрашеных участков (визуальный осмотр). Не факт, что все столы будут соответствовать - получается, что есть смысл проверять.

Программа - объект виртуального мира и тут действуют другие законы. Проверять каждый конкретный экземпляр программы - всё равно, что проверять результат от вычитания 2 из 10. Всегда 8 будет - сколько не проверяй. Так же и с ПО - сделали, записали контрольные суммы, проверили - если все проверки пройдены, то логично, что остальные копии ПО тоже проверки эти пройдут (если не считать отказов/сбоев). Идентичность определяется теми же контрольными суммами.

К сожалению, не все осознают, что система = ПО + железо, а не система = ПО. Соответственно, такие нелепые документы возникают.
Изменено: ubm-1986 - 31.03.2016 17:26:18
Страницы: 1

Рейтинг@Mail.ru