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

С точки зрения ГОСТов:

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

Там про оформление сказано (если не полениться до конца прочитать). Целый раздел даже есть.

А сказать нечто типа "Требования не предъявляются"?
Если не указано в ТЗ, то пусть либо этой фразой довольствуются, либо дополнение к требованиям ТЗ делают и там сами требования выдвигают.

То что никакого "повелевающего наклонения" нет - это ёжику понятно. Поэтому я его при первом использовании в кавычки взял (во втором - кавычки потерялись, к сожалению).

К сожалению, несуразицу, написанную в ГОСТе, в научных терминах объяснить не получается. Приходится произвольным словообразованием заниматься, которое тоже ГОСТом запрещено, кстати

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

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

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


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

Уместнее трактовать словосочетание "повелительное наклонение" как.. назовём это "повелевающее наклонение" или "повелевающая интонация". Если смотреть на примере про "нажать кнопку", то  , вместо "...кнопку нажимают чтобы включить прибор..." авторы ГОСТа хотели бы увидеть нечто типа читать "[повелеваю/требуется] нажать кнопку чтобы включить прибор". Т.е. тут идёт разграничение в плане "делают"/"требуется сделать".

Документы на АС регламентируются ГОСТами 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
и т.д.

Чтобы дать ответ на вопрос каким ГОСТом пользоваться нужно понимать что за документ будет. Хотя бы приблизительно.

По поводу вопроса о том может ли АС включать другую АС - можно посмотреть ГОСТ 34.003 (в частности определения 2.13 и 2.15). Там явных запретов нету - компонентом АС может быть что угодно.


Да и по здравому смыслу - тоже не вопрос. Как аналогия:
АС-2 - система оплаты штрафов ГИБДД.
АС-1 - система госуслуг в целом.

В общем случае АС = железо + софт.

В ГОСТ 34.201 сказано

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

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

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


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


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

2. АС-1 - видимо это полноценная система, соответственно нужно всё вышеописанное для общего случая.

Согласно ГОСТ 34.201 документ "Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)", код которого установлен в соответствии с требованиями стандартов ЕСКД. Видимо, тут всё-таки отсылка на ГОСТ 2 идёт. Соответственно не через точку надо обозначать.

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

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


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

Без обид - ни разу не аргумент. Предлагаю оперировать цитатами из ГОСТов.

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

Полагаю конкретно для автора уже не актуально, но всё же. Пригодится другим.

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

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

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


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

ГОСТ 2.105ГОСТ 2.201
3. Другой вариант

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

ГОСТ 2.106

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

2) Можно и даже нужно, скажем, в паспорте/формуляре. Например, всякие "ответственные разделы" типа гарантии и т.д.: там полное наименование печатать - достаточно аристократично. А, в целом, сокращения нужны чтобы место сэкономить и текст разгрузить.

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

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

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

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

Как видно из строки выше - в куче общих слов (42 слова, не считая первого "Например") видна чёткая последовательность (всего 3 слова) "Вставить" => "Рисунок" => "Вставить". Человеку знакомому с программой (который просто не может всего запомнить или не хочет этого делать) будет очень легко "скакать глазами" по полужирному шрифту документа.

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

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

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

Так что отталкиваться лучше от задач, которые решает программа.

Тогда по ГОСТ 2.114 нужно делать ТУ на "компакт диск с ПО".

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

Видимо вопрос тогда не совсем правильно понял. Спорить не буду.

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

P.S. Про целевую аудиторию вне контекста мы можем только догадываться .

По опыту работы (в том числе с военпредами в рамках ГОЗ) могу сказать следующее:

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

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

Да нужно.

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

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



В 19.201:
В 19.106:


В 34.602:
В 2.105:

Выскажусь как человек не чуждый программированию.

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

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

Все программные документы перечислены в ГОСТ 19.101-77. ТУ на ПО там нету. ТУ на ПО быть не нужно в принципе - поясню почему.

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

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

К сожалению, не все осознают, что система = ПО + железо, а не система = ПО. Соответственно, такие нелепые документы возникают.