Виктор Фигурнов (Все сообщения пользователя)

[QUOTE]Andreyka написал:
АРМ - это компонент АПК или компонент инфраструктуры предприятия в телекоммуникационной среде, а также в рамках помещения, грубо говоря, АРМ - это стол, стул, оборудование (ПК и переферия) и программные средства, сопрягаемые с персональным компьютером.
[/QUOTE]
В определении АРМ, данном в ГОСТ 34.003—90, про персональные компьютеры ничего не говорится. Про стул и стол тоже. И это правильно.

[B][COLOR=#333333]ГОСТ Р ИСО/МЭК 15910-2002
[/COLOR][/B]
[B][COLOR=#333333]ПРОЦЕСС СОЗДАНИЯ ДОКУМЕНТАЦИИ ПОЛЬЗОВАТЕЛЯ ПРОГРАММНОГО СРЕДСТВА
[/COLOR][/B]
[B][COLOR=#333333]ПРИЛОЖЕНИЕ F[/COLOR][/B][B][COLOR=#333333] [/COLOR][/B][B][COLOR=#333333](справочное)
[/COLOR][/B]
[B][COLOR=#333333]F[/COLOR][/B][B][COLOR=#333333].2 ПОМИНУТНЫЙ И ПОЧАСОВОЙ МЕТОДЫ
[/COLOR][/B]
[COLOR=#333333]Данные методы предусматривают около 3 ч для написания страницы текста, пригодного для публикации. Время, необходимое для создания графических материалов, определяется их сложностью и количеством черновиков, необходимых для создания соответствующего оригинала
[/COLOR][COLOR=#333333].[/COLOR]
[COLOR=#333333]По общей оценке требуется от 3 до 5 ч для создания и корректировки типового графического материала, используемого в программной документации (исключая экранные распечатки).
[/COLOR]
[COLOR=#333333]В начале проекта трудно оценить общий постраничный объем создаваемой документации. Если для завершения проекта требуется более 2 мес, подсчет страниц должен быть проведен по истечении первого месяца.
[/COLOR]
[COLOR=#333333]Для очень больших проектов номенклатура поставки должна быть разделена на части, поддающиеся управлению. При этом оценка сроков завершения проекта в целом может быть дана только в количестве месяцев, а детально может быть оценена лишь первая часть работы. При использовании данного метода документатор и заказчик должны сверить свои оценки сроков завершения проекта.
[/COLOR]
[COLOR=#333333]В таблице [/COLOR][URL=http://ohranatruda.ru/ot_biblio/normativ/data_normativ/39/39662/#i2108906][COLOR=purple]F.1[/COLOR][/URL][COLOR=#333333] приведены сроки реализации «типового» (гипотетического) проекта. При этом предполагается, что автор готовит материалы непосредственно на персональном компьютере, и для их выпуска используют портативные издательские системы.
[/COLOR]
[COLOR=#333333][B]Таблица F.1[/B][/COLOR][COLOR=#333333][B] - Ориентировочные сроки[/B][/COLOR]
[TABLE][TR][TD] [CENTER]Этап[/CENTER] [/TD][TD] [CENTER]Срок[/CENTER] [/TD][/TR][TR][TD] Определение номенклатуры поставки [/TD][TD] 16 ч на проект [/TD][/TR][TR][TD] Исследование содержания документации [/TD][TD] 24 ч на проект [/TD][/TR][TR][TD] Написание плана документирования [/TD][TD] 48 ч на проект [/TD][/TR][TR][TD] Проектирование структуры документа и правил оформления его страниц [/TD][TD] 8 ч на том [/TD][/TR][TR][TD] Написание первой редакции (документации) [/TD][TD] 1 ч на страницу [/TD][/TR][TR][TD] Разработка графических материалов [/TD][TD] 5 ч на материал [/TD][/TR][TR][TD] Объединение текстовых и графических материалов [/TD][TD] 30 мин на страницу [/TD][/TR][TR][TD] Проверка первой редакции (эксперт) [/TD][TD] 30 мин на страницу [/TD][/TR][TR][TD] Корректировка первой редакции и графики [/TD][TD] 30 мин на страницу [/TD][/TR][TR][TD] Внесение замечаний пользователя [/TD][TD] 30 мин на страницу [/TD][/TR][TR][TD] Грамматическое редактирование [/TD][TD] 15 мин на страницу [/TD][/TR][TR][TD] Подготовка второй редакции (документации) [/TD][TD] 15 мин на страницу [/TD][/TR][TR][TD] Проверка второй редакции (эксперт) [/TD][TD] 15 мин на страницу [/TD][/TR][TR][TD] Окончательная корректировка документации [/TD][TD] 10 мин на страницу [/TD][/TR][TR][TD] Нормоконтроль документации [/TD][TD] 15 мин на страницу [/TD][/TR][TR][TD] Изготовление фотошаблонов [/TD][TD] 3 сут [/TD][/TR][TR][TD] Печать и переплетение оригиналов [/TD][TD] 5 сут [/TD][/TR][TR][TD] Печать и брошюровка копий [/TD][TD] 10 сут [/TD][/TR][TR][TD] Рассылка [/TD][TD] 1 сут [/TD][/TR][/TABLE][B][COLOR=#333333]
[/COLOR][/B][B][COLOR=#333333]F[/COLOR][/B][B][COLOR=#333333].3 МЕТОД НИСХОДЯЩЕГО ПРОЕКТИРОВАНИЯ
[/COLOR][/B]
[B][COLOR=#333333]F.3.1 Общие положения
[/COLOR][/B]
[COLOR=#333333]Данный метод основан на предположении, что число страниц в публикации(ях) может быть оценено достаточно просто с использованием следующих допущений:[/COLOR]
[COLOR=#333333]a) автор может за месяц подготовить 22 страницы нового текста;[/COLOR]
[COLOR=#333333]b) автор может за месяц подготовить 44 страницы текста с изменениями.[/COLOR]
[COLOR=#333333]Например, объем публикации оценен в 150 страниц. Поскольку это новая публикация, получаем: 150/22 = 7чел./мес. В эти 7 мес. входят: планирование публикации, ее написание, редактирование и проверка двух редакций, а также подготовка фотошаблонов.
[/COLOR]
[B][COLOR=#333333]F.3.2 Пропорции[/COLOR][/B]
[COLOR=#333333]Продолжительность 7 чел./мес распределена в следующих пропорциональных отношениях:[/COLOR]
[COLOR=#333333]a) 15 % - планирование (в данном примере - четыре недели);[/COLOR]
[COLOR=#333333]b) 50 % - написание первой редакции (14 недель);[/COLOR]
[COLOR=#333333]c) 25 % - написание второй редакции (семь недель);[/COLOR]
[COLOR=#333333]d) 10 %- подготовка фотошаблонов (три недели).
[/COLOR]
[B][COLOR=#333333]F[/COLOR][/B][B][COLOR=#333333].3.3 Планирование[/COLOR][/B]
[COLOR=#333333]Период планирования охватывает:[/COLOR]
[COLOR=#333333]a) исследования и подготовку плана;[/COLOR]
[COLOR=#333333]b) изучение и проверку плана;[/COLOR]
[COLOR=#333333]c) корректировку плана по результатам проверки.
[/COLOR]
[B][COLOR=#333333]F[/COLOR][/B][B][COLOR=#333333].3.4 Первая редакция[/COLOR][/B]
[COLOR=#333333]Период первой редакции охватывает:[/COLOR]
[COLOR=#333333]a) подготовку содержания (плана-проспекта) документации;[/COLOR]
[COLOR=#333333]b) изучение и проверку содержания (плана-проспекта);[/COLOR]
[COLOR=#333333]c) подготовку пробного куска текста для редактора;[/COLOR]
[COLOR=#333333]d) редактирование пробного куска текста и его переписывание по замечаниям редактора;[/COLOR]
[COLOR=#333333]e) написание всей первой редакции документации;[/COLOR]
[COLOR=#333333]f) редактирование всей первой редакции документации;[/COLOR]
[COLOR=#333333]g) переработку отредактированной документации;[/COLOR]
[COLOR=#333333]h) изучение и проверку переработанной документации.[/COLOR]
[COLOR=#333333]Иллюстративные материалы готовят одновременно с текстом первой редакции.
[/COLOR]
[B][COLOR=#333333]F[/COLOR][/B][B][COLOR=#333333].3.5 Вторая редакция[/COLOR][/B]
[COLOR=#333333]Период второй редакции охватывает:[/COLOR]
[COLOR=#333333]a) внесение в документацию всех изменений, предложенных по результатам проверки первой редакции;[/COLOR]
[COLOR=#333333]b) повторное (второе)редактирование второй редакции документации;[/COLOR]
[COLOR=#333333]c) переработку отредактированной[/COLOR][COLOR=#333333] [/COLOR][COLOR=#333333]документации;[/COLOR]
[COLOR=#333333]d) изучение и проверку переработанной документации.
[/COLOR]
[B][COLOR=#333333]F[/COLOR][/B][B][COLOR=#333333].3.6 Принятая редакция[/COLOR][/B]
[COLOR=#333333]Редакцией для фотонабора является принятая редакция документирования. Ее подготовка охватывает:[/COLOR]
[COLOR=#333333]a) [/COLOR][COLOR=#333333]внесение в документацию всех изменений, предложенных по результатам проверки второй редакции;[/COLOR]
[COLOR=#333333]b) [/COLOR][COLOR=#333333]проверку правильности внесения данных изменений;[/COLOR]
[COLOR=#333333]c) [/COLOR][COLOR=#333333]удаление всех[/COLOR][COLOR=#333333] [/COLOR][COLOR=#333333]редакционных разметок;[/COLOR]
[COLOR=#333333]d) [/COLOR][COLOR=#333333]изготовление фотошаблонов;[/COLOR][COLOR=#333333] [/COLOR]
[COLOR=#333333]e) [/COLOR][COLOR=#333333]отправку фотошаблонов в печать (в типографию)
[/COLOR][COLOR=#333333]. [/COLOR]
[COLOR=#333333]Обычно экспертам (нормоконтролерам) требуется от одной до двух недель для изучения и подготовки замечаний, а сама проверка занимает от одного до нескольких дней.
[/COLOR]
[COLOR=#333333]Метод нисходящего проектирования может быть использован для существующих публикаций. Например, книга объемом 100 страниц может быть переработана так, что половина ее изменяется и добавляется 10 % новых материалов. Используя вышепринятые допущения, получаем: 50/44 = 1,13 чел./мес для существующего материала плюс 10/22 = 0,45 чел./мес для внесения нового материала.
[/COLOR]
[COLOR=#333333]Когда сроки, необходимые для создания документации, превышают допустимые, для выполнения задания следует привлекать несколько авторов. Так же следует поступать при подготовке нескольких документов для одного программного средства.[/COLOR]

Только для [B]очень[/B] маленьких или для небольших стандартно-типовых проектов можно создать документацию за несколько дней.

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

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

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

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

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

Плейлисты от Adobe
[URL=http://www.youtube.com/playlist?list=PLJL3v-Ayk9rQfSxJ-dmOtQWbXLSGBydGZ]http://www.youtube.com/playlist?list=PLJL3v-Ayk9rQfSxJ-dmOtQWbXLSGBydGZ[/URL] Adobe FrameMaker 2015
[URL=http://www.youtube.com/playlist?list=PLJL3v-Ayk9rSSFIFx_efxNhs9IMJFaPGA]http://www.youtube.com/playlist?list=PLJL3v-Ayk9rSSFIFx_efxNhs9IMJFaPGA[/URL] Adobe FrameMaker 12
[URL=http://www.youtube.com/playlist?list=PL1A24WcpwcfVm3q4hAUIQcutQFiMZULua]http://www.youtube.com/playlist?list=PL1A24WcpwcfVm3q4hAUIQcutQFiMZULua[/URL] Adobe FrameMaker 12 Features

[QUOTE]Laya написал:
кнопки в виде графических изображений как правильно называть: кнопки, иконки, значки?[/QUOTE]
Если вы говорите о кнопке, то так и пишете - кнопка (button)
Если об изображении на кнопке - то это значок (icon).

Обратите внимание, что щелчок мышью по этим объектам по-английски обозначается одним глаголом, а по-русски - разными:
click the icon => щелкнуть значок
click the button => нажать кнопку

Это стилистика. Общей литературной нормой является написание с прописной буквы:
[LIST]
[*]имен собственных (имена и прозвища людей, клички животных, географические и астрономические названия и пр.)
[*]наименований (названия учреждений, организаций, объединений, исторических эпох и событий, праздников, массовых мероприятий, орденов, архитектурных памятников, а также выделяемые кавычками названия газет, журналов, наград, произведений искусства, обществ, предприятий, промышленных изделий и т. п.,)
[*]слов в начале предложения.(в стихотворном тексте - возможно также и в начале строки)
[/LIST]Но в особых случаях допустимо написание слов с прописной буквы и в других случаях, например:
[QUOTE][B][I]Правила русской орфографии и пунктуации. Полный академический справочник. [/I][/B]

[B]Названия документов, памятников, предметов и произведений искусства[/B]

§ 194. В составных названиях важнейших документов и сборников документов, государственных законов, а также архитектурных и других памятников, предметов и произведений искусства с прописной буквы пишется первое слово и собственные имена, напр.: Конституция Российской Федерации, Федеративный договор, Устав ООН, Декрет о мире, Всеобщая декларация прав человека, Кодекс законов о труде, Уголовный кодекс РФ

[B]Прописные буквы в особом стилистическом употреблении[/B]

§ 201. С прописной буквы пишутся некоторые наименования в текстах официальных документов, сообщений, договоров, напр.: Высокие Договаривающиеся Стороны, Чрезвычайный и Полномочный Посол — в актах международного значения, в дипломатических документах; Автор, Издательство — в авторском договоре; Президент, Премьер-министр, Император Японии — в документах при встречах на высшем уровне.[/QUOTE]

[QUOTE]perepelini написал:
Здравствуйте, коллеги!
Мне необходимо разработать  регламент управления доступом  на АИС. Хочу понять, каким документом следует руководствоваться при разработке данного регламента? Может быть, у кого-нибудь есть пример уже готового регламента?[/QUOTE]
Довольно неожиданное место для такого запроса.
Я бы понял, если бы такая просьба была высказана на форуме специалистов по информационной безопасности [URL=http://forum.npsib.org/]http://forum.npsib.org/[/URL] или в аналогичном месте.

Регламент [COLOR=#373737]управления доступом на АИС может быть документом самого разного объема - я видел от 3 до 350 страниц. А бывает и больше.
[/COLOR]Объем и сложность регламента зависит от количества и сложности видов объектов доступа, субъектов доступа, лиц, принимающих решения о предоставлении доступа, процедур предоставления доступа, специфики данных и т.д.

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

Еще правильнее - сначала написать концептуальные документы о политике использования и информационной безопасности [COLOR=#373737]АИС.
[/COLOR][COLOR=#373737]А уже на их основе создавать регламенты с описанием конкретных процедур.
[/COLOR]
Многие регламенты информационных систем различных госструктур опубликованы, их можно найти в интернете и в правовых базах данных.[COLOR=#373737]
[/COLOR]

[QUOTE]FSV написал:
1. И много людей получают такую зарплату?
[/QUOTE]
Как обычно, зарплату на уровне средней по региону и выше получает около 1/3 работающих.
Заработную плату 30 тыс. рублей и менее в Москве получает примерно 20% самых низкооплачиваемых работников.
Данные Росстата на апрель 2015 г.
[QUOTE]FSV написал:
2. 30 тыс.руб. за НЕПОЛНУЮ ЗАНЯТОСТЬ.[/QUOTE]
Это уже более приемлемо. Из текста исходного объявления это не следовало.

[QUOTE]Иван Кутейкин написал:
Интересно, Product Manager= Системный аналитик?
[/QUOTE]
Нет[QUOTE]Иван Кутейкин написал:
Project manager может быть системным аналитиком?[/QUOTE]
Может. Но обычно это не получается. У менеджера слишком много управленческих задач, и проводить анализ самому обычно нет времени и возможности.
Обязанность [COLOR=#373737]Project manager - оценить результаты анализа и принять верное управленческое решение.[/COLOR]

[QUOTE]H&M User написал:
Виктор, скажите, у Вас уже есть GOST R ISO 15289-20ХХ или это просто вольный перевод видов документации из ISO/IEC/IEEE 15289:2015?
[/QUOTE]
Такого ГОСТ нет, но юридический статус стандартов ISO и ГОСТ в Российской Федерации одинаков. Согласно закону РФ "О техническом регулировании", стандарты - это документы, в которых [B]в целях добровольного многократного использования[/B] устанавливаются характеристики продукции, правила осуществления и характеристики процессов проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации и утилизации, выполнения работ или оказания услуг (ст. 2 Закона). К документам в области стандартизации, используемым на территории Российской Федерации, относятся как национальные стандарты, так и международные стандарты (ст. 13 Закона).

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

[QUOTE]H&M User написал:
Насколько я помню, спецификацией можно считать только формализованное представление требований, предъявляемых к разрабатываемому продукту (+ условия, эффект действия, описание задачи), без указания способов достижения. [/QUOTE]
Полагаю, что договор можно считать спецификацией прав и обязанностей сторон по поводу предмета договора.  :)

[QUOTE]H&M User написал:
А про заказчиков программной документации по ГОСТ 19 умолчу, для них спецификация это лишь список программных документов (19.202)[/QUOTE]
Русский язык, как и другие естественные языки, не отличается однозначностью. Многие слова имеют несколько значений. В словарях я нашел 6 разных значений слова "спецификация". Например: спецификация -[COLOR=#333333] не обусловленная договором переработка материала, в результате которого создается новая, иного рода вещь (не обусловленное договором изготовление стола из дерева и т.п.).; спецификация - [/COLOR]перечисление подробностей, на которые необходимо обратить особое внимание... :(

По тем же стандартам ГОСТ 19 пользователь - это организация-держатель дубликата.  hi-hi-hi  И что из этого?

[QUOTE]Ovin написал:
Здравствуйте.
Не так давно осваиваю данную специальность. Прочитала госты, темы на форуме..но единообразия не пришло.

Из прочитанного пришла к выводу, что техническая документация разделяется на:
 технологическая
 проектная
 эксплуатационная[/QUOTE]
Иногда выделяются и другие виды документации. Например, по рекомендациям Р 50-605-80-93 техническая документация на военную технику подразделяется на нормативно-техническую, конструкторскую, технологическую и программную.

По моему мнению, все классификации ГОСТов сильно устарели, как и приведенный Вами список документов. В настоящее время международными стандартами ISO техническая документация классифицируется по виду (описание, план, политика, процедура, отчет, запрос, спецификация), и по процессу жизненного цикла системы или услуги, к которому относится документ.

См., например, стандарты:
[LIST]
[*]ISO/IEC 15288:2015 — Процессы жизненного цикла систем,
[*]ISO/IEC 12207:2008 — Процессы жизненного цикла информационных систем,
[*]ISO/IEC 20000-1:2011, ISO/IEC 20000-2:2012 — Процессы жизненного цикла услуг,
[*]ISO/IEC/IEEE 15289:2015 — Содержание информационных продуктов процесса жизненного цикла систем и программного обеспечения (документация).
[/LIST]Стандартом ISO/IEC/IEEE 15289:2015 "Содержание информационных продуктов процесса жизненного цикла систем и программного обеспечения (документация)" предусмотрены следующие виды документации:

[B]Спецификация[/B]
[LIST=1]
[*]Договор
[*]Сервисное соглашение
[*]Техническое задание на программу
[*]Техническое задание на систему (или сервис)
[*]Требования к валидационному тестированию
[/LIST][B]Описание[/B]
[LIST=1]
[*]Концепция деятельности
[*]Описание архитектуры системы
[*]Описание дизайна базы данных
[*]Описание дизайна программной системы
[*]Описание интерфейса
[*]Описание программной архитектуры
[*]Описание программной единицы
[*]Описание элемента системы
[*]Предложение
[*]Служебный каталог
[/LIST][B]Отчет[/B]
[LIST=1]
[*]Отчет о валидации
[*]Отчет о верификации
[*]Отчет о выполнении работ
[*]Отчет о квалификационном испытании
[*]Отчет о мониторинге и контроле
[*]Отчет о признании аудита
[*]Отчет о проведении приемочной проверки и тестирования
[*]Отчет о состоянии конфигурации
[*]Отчет о тестировании программной единицы
[*]Отчет об анализе возможностей улучшения
[*]Отчет об аудите
[*]Отчет об инсталляции
[*]Отчет об интеграции и тестировании
[*]Отчет об инциденте
[*]Отчет об обнаруженных проблемах
[*]Отчет об оценке
[*]Оповещение пользователя
[*]Оценка необходимости продукта
[*]Протокол обзора
[*]Сервисный отчет
[/LIST][B]План[/B]
[LIST=1]
[*]План аудита
[*]План валидации
[*]План верификации
[*]План вывода из эксплуатации
[*]План выпуска
[*]План документирования
[*]План измерений
[*]План инсталляции
[*]План интеграции
[*]План обеспечения информационной безопасности
[*]План обеспечения мощности
[*]План обеспечения непрерывности и доступности сервиса
[*]План обучения
[*]План повторного использования
[*]План приемки
[*]План приобретения
[*]План развития
[*]План сопровождения
[*]План улучшений
[*]План управления активами
[*]План управления информацией
[*]План управления качеством
[*]План управления конфигурацией
[*]План управления проектом
[*]План управления рисками
[*]План управления сервисом
[*]Инженерный план домена
[*]Сервисный план
[/LIST][B]Политика[/B]
[LIST=1]
[*]Политика управления конфигурацией
[*]Политика бюджетирования и учета
[*]Политика выпуска
[*]Политика жизненного цикла системы
[*]Политика обеспечения информационной безопасности
[*]Политика управления качеством
[*]Политика управления конфигурацией
[*]Политика управления рисками
[*]Политика управления услугами
[/LIST][B]Процедура[/B]
[LIST=1]
[*]Пользовательская документация
[*]Учебная документация
[*]Процедура взаимодействия
[*]Процедура представления жалоб
[*]Процедура аудита
[*]Процедура выбора поставщика
[*]Процедура документирования
[*]Процедуры жизненного цикла системы
[*]Процедура квалификационного испытания
[*]Процедура обеспечения информационной безопасности
[*]Процедура осуществления
[*]Процедура оценки процессов
[*]Процедура разрешения проблем
[*]Процедуры сопровождения
[*]Процедура тестирования программной единицы
[*]Процедура улучшений
[*]Процедура управления информацией
[*]Процедура управления инцидентами
[*]Процедура управления конфигурацией
[*]Процедуры управления мощностью
[*]Процедура управления поставщиками
[*]Процедуры эксплуатационного тестирования
[/LIST][B]Запрос[/B]
[LIST=1]
[*]Запрос действий, связанных с рисками
[*]Запрос на изменение
[*]Запрос на предложения
[*]Запрос на ресурсы
[*]Исследование удовлетворенности клиентов
[/LIST]Там же описано соответствие этих видов документации и видов процессов жизненного цикла систем, программного обеспечения и сервисов.

[QUOTE]FSV написал:
Зарплата от 30 тыс.руб. [/QUOTE]
По данным Мосгорстата, средняя зарплата в Москве на июнь 2015 г. составляет 66562 рубля.

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

Например, если портал является программой (комплексом программ), можете применять ГОСТы 19 серии на программную документацию.

Тогда правила оформления титульных листов задаются ГОСТ 19.104-78, всего лишь 37-летней давности.

Нумерация документов может выполняться по ГОСТ 19.103-77. Документы имеют простые и легко запоминаемые номера вида:

A.B.CCCCC-DD EE FF-G

Здесь:
A - код страны, например RU (по стандарту ISO 3166-1)
B - код организации-разработчика. Например, код ОКПО
CCCCC - регистрационный номер программы, который должен присваиваться "в соответствии с Общесоюзным классификатором программ, утверждаемым Госстандартом в установленном порядке". Поскольку Госстандарт и этот порядок давно почили в бозе, можете присвоить его себе сами.
DD - номер редакции документа
EE - код вида документа в соответствии с ГОСТ 19.101-77:
[LIST]
[*]05 Ведомость держателей подлинников
[*]12 Текст программы
[*]13 Описание программы
[*]20 Ведомость эксплуатационных документов
[*]30 Формуляр
[*]31 Общее описание
[*]32 Руководство системного программиста
[*]33 Руководство программиста
[*]34 Руководство оператора
[*]35 Описание языка
[*]46 Руководство по техническому обслуживанию
[*]51 Порядок и методика испытаний
[*]81 Пояснительная записка
[*]90 Документы прочие
[/LIST]FF - номер документа данного вида
G - номер части документа

Начальная часть обозначения A.B.CCCCC-DD может использоваться для обозначения самой программы.

[QUOTE]''Dr.Explain'' написал:
 16 причин, почему ваши пользователи не читают документацию  
 [URL=http://www.drexplain.ru/articles/pochemu_imenno_vashi_polzovateli_ne_chitayut_dok]http://www.drexplain.ru/articles/pochemu_imenno_vashi_polzovateli_ne_chitayut_dok[/URL] ­umentatsiyu/
[QUOTE]... документацией к продукту иногда, действительно, не пользуются. В основном, это происходит по следующим причинам...[/QUOTE]
Статья не о программе Dr.Explain и вполне подошла бы и для раздела  "Введение в специальность"  этого форума, но, поскольку в ней все-таки есть упоминание нашего продукта, я счел более корректным разместить ее в "нашем" подфоруме.[/QUOTE]
Статья хорошая во всем. Кроме рекомендации "для Windows приложения удачным решением будет создать файл справки в формате CHM".

Использование формата встроенной справки CHM считаю крайне нежелательным.  От формата CHM его разработчик (Microsoft) отказался еще в 2002 году, этот формат имеет массу проблем и ограничений.

[QUOTE]tech_writer_1 написал:
[QUOTE]А как работает mail merge? [/QUOTE]
[/QUOTE]
[URL=https://support.microsoft.com/ru-ru/kb/318118]Как использовать функцию слияния в Microsoft Word для создания и печати писем, использующие данные из листа Excel[/URL]

[URL=https://support.office.com/ru-ru/article/%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B8-%D0%BF%D0%B5%D1%87%D0%B0%D1%82%D1%8C-%D0%BF%D0%B8%D1%81%D0%B5%D0%BC-%D0%B8-%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D1%85-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-%D1%81%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D1%8F-f488ed5b-b849-4c11-9cff-932c49474705?ui=ru-RU&rs=ru-RU&ad=RU]Создание и печать писем и других документов с помощью слияния[/URL]

Не вижу необходимости платить 30 евро за утилиту, предоставляющую ровно те же возможности и те же удобства, что и штатный mail-marge, имеющийся в составе Microsoft Word чуть ли не с 1983 года.

Рекомендации Р 50-605-80-93. "Система разработки и постановки продукции на производство. Термины и определения" дают такое определение.
[QUOTE][B]Техническая документация (на продукцию)[/B] - Совокупность документов, необходимая и достаточная для непосредственного использования на каждой стадии жизненного цикла продукции.

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

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

К  исходной  относятся:  заявка  на разработку   и   освоение  продукции,  исходные  требования,  аванпроект, рекомендации  по  разработке  продукции,  выполняемые  в   процессе  НИР, техническое задание.

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

К  рабочей  документации  - рабочая конструкторская, технологическая  документация,  эксплуатационная документация, ремонтная документация.  

К  информационной  документации  - карта технического  уровня  и  качества  продукции,  патентный  формуляр, информационная карта расчета экономической эффективности  и   цен   новой (модернизированной) продукции, каталоги, отчет о латентных исследованиях, экспертное заключение, акты и протоколы об испытаниях, решение  о  снятии продукции с производства и др.[/QUOTE]

Немецкий профессиональный орган по технической коммуникации и информационному дизайну TEKOM дает такое определение:
[QUOTE]Термин «техническая документация» относится к различным документам с данными и информацией о продукции, которые используются и хранятся в таких целях, как определение и спецификации продукции, ее проектирование, производство, контроль качества, ответственность за продукцию, презентация продукции, описание ее возможностей, функций и интерфейсов, описание правильного и безопасного использования, обслуживание и ремонт технического продукта, а также его безопасная утилизация.[/QUOTE]
Очевидно, что понятие [B]Техническая документация[/B] в разных отраслях и областях применения может включать различные документы. Например, техническая документация на услуги или технологии несомненно будет отличаться по составу от технической документации промышленного изделия или объекта строительства.

Попросите текст договора и прочтите его.
Не дадут - просите (лучше в письменном виде) выдержки из договора, относящиеся к документации.

Вы должны делать ровно то, что прописано в договоре.
Можете больше - если есть желание и возможность. Но инициатива обычно наказуема.

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

[QUOTE]clickhelp написал:
А вы используете подобные подходы при создании документации?[/QUOTE]
Конечно. Сниплеты давно реализованы во Flare, Robohelp, Help and Manual, есть аналог и в Author-it (Xtend)....

[QUOTE]Elyssia написал:
есть ли правило по последовательности нумерации выносок (элементов) на рисунке?[/QUOTE]
Общего правила нет. Рисунки бывают очень разными, и нумерации элементов в них тоже. Где-то принято использовать числовую нумерацию, где-то принята буквенная, где-то буквенно-цифровая (например, L1, R2, C15 и т.д.) или более сложная - например, 2L1 = провод 1-й фазы идущий к 2-ому потребителю. Иногда пропуски в нумерации допустимы, а иногда нет.

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

Всё-таки слово "telefon" не исправили. Такого слова в английском языке нет. Это всё равно что по русски написать "тилепон".
Слово "scaner" в одном месте поправили, в другом нет.
Сокращение "WLAN" в одном месте написано с ошибкой "WPAN"
Нетбуки не производятся примерно с 2011 года.
В электрических схемах >> означает разъем, вставленный в розетку, между ними линия не допустима.

[IMG WIDTH=397 HEIGHT=66]http://s7.hostingkartinok.com/uploads/images/2015/07/363e0a935c0fa79b9d84aa16d88e474e.png[/IMG]
Что означают перечеркивания линий электропитания, которые вы нарисовали, мне не известно.
Две концентрические окружности на электрической схеме это не украшение, а символ электрической машины. С какой стати она нужна, не понятно.
Это домашний офис на двух автономных генераторах, что ли?

[IMG WIDTH=500 HEIGHT=346]http://techwriters.ru/bitrix/components/bitrix/forum.interface/show_file.php?fid=4936&width=500&height=500[/IMG]

.... Лучше писать документацию на каком-то одном языке, и не делать ошибок.

Scaner => Scanner
Radio-telefon => Cordless telephone
Presence sensor => Occupancy sensor (скорее всего)

RJ-45 это не интерфейс передачи данных, а вид разъема с 8-позиционным 8-контактным коннектором.

Что изображено рядом с надписью Pilot, мне непонятно. Я знаю не знаю ни одного подходящего значения слова Pilot.
Возможно, вместо надписи Pilot следует написать Surge protector.

Кроме того, стандартное напряжение электрической сети в России не 220 V, а 230 V, согласно ГОСТ 29322-92.

[QUOTE]writer написал:
Вопрос от наших посетителей:
[QUOTE]Есть ли стандартизованный термин "техническая документация" или
необходимо употреблять термин "конструкторская и технологическая
документация"[/QUOTE]
Кто сможет дать ответ?[/QUOTE]
Даже в названиях ГОСТов есть.

ГОСТ 24.301-80 Система технической документации на АСУ. Общие требования к выполнению текстовых документов
ГОСТ 24.302-80 Система технической документации на АСУ. Общие требования к выполнению схем
ГОСТ 24.303-80 Система технической документации на АСУ. Обозначения условные графические технических средств
ГОСТ 24.304-82 Система технической документации на АСУ. Требования к выполнению чертежей
ГОСТ 24.401-80 Система технической документации на АСУ. Внесение изменений
ГОСТ 24.402-80 Система технической документации на АСУ. Учет, хранение и обращение

ГОСТ Р 54089-2010 "Интегрированная логистическая поддержка. Электронное дело изделия. Основные положения" содержит следующее определение:[LIST]
[*][COLOR=#333333][B]техническая документация[/B]: Совокупность конструкторской и технологической документации, используемой для изготовления, испытания, эксплуатации и ремонта изделия.[/COLOR]
[/LIST]

Не знаю такой фразы, а если она и есть, то обязательной силы не имеет.

Согласно Закону "О техническом регулировании", от 27.12.2002 N 184-ФЗ, [I][B]стандарт (в том числе ГОСТ и ОСТ)[/B] — документ, в котором [B][COLOR=#ee1d24]в целях добровольного многократного использования[/COLOR][/B] устанавливаются характеристики продукции, правила осуществления и характеристики
[/I]
Что вы, или ваше начальство, или ваш заказчик, посчитаете целесообразным использовать - то и используйте.
Хотите ГОСТ, хотите ОСТ, хотите - их отдельные положения. Или ничего не используйте. Дело добровольное.