Регистрация на ръководството за потребителя за GOST. LLC „Техническа документация

Здравейте отново, скъпи habralyud!

Продължавайки публикацията си, реших да напиша как най-добре да създам инструкции за потребители и администратори.

Който се интересува моля за хабракат.

ЦЕЛУВКА

Принципът Keep It Simple Stupid е добре познат в програмирането, но по някаква причина рядко се използва за писане на инструкции и насоки, предпочитайки да разпространява мисли по дървото. В 70% от ситуациите тази документация е необходима само за да се отървем от нашите весели регулатори, но в същото време забравят, че тази документация ще трябва да работи, а не винаги технически разбиращи и грамотни по информационна сигурност хора.

Като начало ще напиша няколко правила, които ще ви помогнат да създадете работещ и удобен документ:

1. Опитайте се да отделите инструкциите за потребители от инструкциите за администратори и служители по сигурността. и първият не трябва да съдържа връзки към втория (може да съдържат препратки една към друга).
2. Правете инструкции стъпка по стъпка като „вземете го и го направете“. Тоест инструкциите трябва да описват алгоритъма на действията на този, към когото са насочени.
3. Опишете всеки артикул като отделно действие със задължително посочване на отговорното лице и контакти, ако е необходимо.
4. За по-голяма яснота можете допълнително да нарисувате блок-схема на действията в инструкцията. Това ще помогне на потребителя ясно да разбере и оцени действията, както и да ви обясни алгоритъма по време на обучението.
5. Психологическият момент - инструкцията ще бъде зле изпълнена и ще работи, ако алгоритъмът не е ясно и лесно обяснен на потребителите с пръсти и примери. Така - НЕ ЗАБРАВЯЙТЕ ЗА УЧЕНЕТО!

Примерна инструкция за потребители

По-долу е даден пример за инструкции за настройка на потребителски акаунт в корпоративна мрежа.

Ясен екран/чисто бюро

Спецификата на руските организации, които работят от съветско време и със същия изтънчен опит на служителите, е такава, че по правило бюрото им е осеяно с документи. Компютърът понякога не се изключва и не блокира, дори когато се приберат вкъщи. Наскоро лично видях късно вечерта, минавайки покрай общинско предприятие, зад отворените щори в заключена сграда гори монитор с отворен документ на Ворд.
Потребителите понякога не са наясно с възможните неволни изтичания на информация. Дори и да не е поверителен, може да е само за вътрешна употреба. Но това дава разбиране, че тази организация не се грижи за тяхната безопасност и може да направи това с поверителни файлове. Освен това е възможно да има информация, която все още не е класифицирана като затворена, но вече съществува във вътрешното обръщение на организацията.

Добър пример за най-добра практика тук е политиката за ясно бюро и ясен екран. Те могат да бъдат описани по същия начин, както дадох пример по-рано, но ще изглежда малко глупаво, тъй като действията там са много прости. По-добре е просто да го направите набор от правила:

P.S.Публикацията съдържа екранни снимки на действително приложени и работещи инструкции и политики. Всички съвпадения със съществуващите организации са случайни. Всички имена на отдели и бюра са променени.

Ръководство за потребителя като софтуерна (оперативна) потребителска документация

Документът "Ръководство за потребителя" се отнася до пакета от оперативна документация. Основната цел на ръководството за потребителя е да предостави на потребителя необходимата информация за самостоятелна работа с програмата или автоматизираната система.

По този начин документът Ръководство за потребителя трябва да отговори на следните въпроси: каква програма е, какво може да прави, какво е необходимо, за да се осигури правилното й функциониране и какво да се прави в случай на повреда на системата.

Документация: софтуерна / оперативна / потребителска документация

Нещо: програма, софтуерен компонент на комплекс или система

Лекционна зала: потребители на програмата, тоест лица, които я използват за решаване на свои собствени приложни проблеми

Задачи: да предостави на потребителите възможността да овладеят и използват програмата напълно самостоятелно

Ръководните стандарти за създаване на документ Ръководство за потребителя могат да бъдат както следва: РД 50-34.698-90 в п.п. 3.4. "Упътване за употреба"и GOST 19.505-79 „Ръководство за оператора. Изисквания за съдържание и дизайн".

Могат да се разграничат следните основни раздели на ръководството за потребителя:

Предназначение на системата;

Условия за приложение на системата;

Подготовка на системата за работа;

Описание на операциите;

Извънредни ситуации.

Предназначение на системата

Този раздел от Ръководството за потребителя трябва да съдържа информация за предназначението на системата, нейните цели и задачи.

пример:

„Корпоративният интранет портал е предназначен да подобри корпоративната култура за организиране на ефективно взаимодействие между служителите.

Основната цел на Пристанището е да създаде единно информационно пространство на предприятието и да оптимизира работата на служителите чрез улесняване на комуникацията между тях и оптимизиране на редица бизнес процеси.

Условия за приложение на системата

Този раздел от ръководството за потребителя трябва да включва всички онези фактори, които са необходими за правилната работа на системата. Тук могат да се разграничат няколко подсекции:

Хардуерни изисквания - тук можете да включите изисквания за конфигурация на компютъра на потребителя, необходим софтуер за работата на Системата, както и наличието на допълнително оборудване (принтер, скенер и др.), ако е необходимо;

Квалификации на потребителя - този подраздел трябва да съдържа изисквания за уменията и знанията на потребителя ( пример: "Потребителите трябва да са запознати с операционната система Windows.");

Подготовка на системата за работа

Този раздел от Ръководството за потребителя трябва да съдържа инструкции стъпка по стъпка за стартиране на приложението. Етапът на подготовка на системата за работа включва инсталиране на допълнителни приложения (при необходимост), идентификация, удостоверяване и др.

Описание на операциите

Това е основният раздел на Ръководството на потребителя, който съдържа инструкции стъпка по стъпка за извършване на действие от потребителя.

Ако работата на автоматизирана система засяга цял бизнес процес, тогава в ръководството за потребителя, преди да се опишат операциите, е препоръчително да се предостави информация за този процес, неговата цел и участниците. Такова решение позволява на човек ясно да си представи своята роля в този процес и функциите, които се изпълняват за него в системата.

По-нататък в документа Ръководството за потребителя трябва да предостави описание на функциите, разделени на отделни операции. Необходимо е да се подчертаят подразделите, описващи функциите на този процес и действията, които трябва да бъдат извършени за тяхното изпълнение.

пример:

„4.1 Одобрение на проекта

Този процес е предназначен да организира работата на служителите, участващи в разработването и одобрението на проекта.

Авторът на проекта създава запис в Системата и прилага пакет от необходимата документация, след което проектът се представя за одобрение от ръководителите. След преглед на проекта, мениджърите могат да го потвърдят или да го изпратят на Автора за ревизия.

4.1.1 Създайте проект

За да създадете проект, щракнете върху бутона "..." в панела "..." и попълнете следните полета във формуляра, който се показва:

Име на проекта;

Описание на проекта;

Следните полета се попълват автоматично:

Дата на създаване на проекта - текуща дата;

Колкото по-подробно са описани действията със системата, толкова по-малко въпроси ще има потребителят. За по-лесно разбиране на всички принципи на работа с програмните стандарти в документа Ръководство за потребителя е позволено да се използват диаграми, таблици, илюстрации, изобразяващи екранни форми.

За големи автоматизирани системи се препоръчва да се създаде отделно ръководство за всяка категория потребител (потребител, модератор и т.н.). Ако при работа със системата се разпределят допълнителни потребителски роли, тогава е препоръчително да поставите таблица за разпределение на функциите между ролите в Ръководството за потребителя.

Извънредни ситуации

Този раздел на документа Ръководство за потребителя трябва да съдържа инструкции стъпка по стъпка за действията на потребителя в случай на повреда на системата. Ако на потребителя не са били представени специални изисквания за администриране на операционната система и т.н., тогава можете да се ограничите до фразата „Ако системата се повреди или не работи, трябва да се свържете със системния администратор“.

Методология и стил на представяне на ръководството за потребителя

Ръководството за потребителя може да бъде както кратко ръководство за основната функционалност на програмата, така и пълен урок. Методът на представяне на материала в този случай ще зависи от обхвата на самата програма и изискванията на клиента.

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

Ако програмата е инструмент, който ви позволява да решавате практически задачи от някакъв краен набор, ръководството предоставя типични процедури за решаване на всеки от тях. Например, потребителят на имейл клиент трябва да знае как да пише и изпраща съобщение, как да изтегля нови съобщения от сървъра, как да отговаря на съобщение и т.н. Всяко от тези действия може да бъде разложено на последователни елементарни стъпки, поне за типични ситуации. В голяма програма на подобни персонализирани задачиможе да има много, но не безкрайно много. Ръководството за потребителя, изградено на принципа на потребителските задачи, прилича на учебник, въпреки че по правило в него липсва методическият апарат, присъщ на учебниците: тестови задачи, въпроси, упражнения.

Ако програмата е среда, в която потребителят може сам да решава поставените от него задачи, ръководството за потребителя трябва да е по-близо до справочното. Тя трябва последователно и систематично да описва всички функции на програмата и реда на тяхното прилагане. Какво да прави с тях, какво да насочва, потребителят ще помисли сам (или ще се запише за курсове за обучение). И така, в ръководството за потребителя на графичния редактор ще намерим описание на всички графични примитиви, инструменти, филтри, но няма да каже директно как да изобразим сграда, кола или, да речем, куче. Потребителят или знае как да го нарисува, или не.

Възможни са и други персонализирани перспективи. Има програми, чрез които потребителят контролира състоянието на обект, да речем, индустриално предприятие. След това ръководството за потребителя е структурирано по принципа на таблица: съобщението на програмата е реакцията или възможните реакции на потребителя.

Ако потребителят използва програмата за решаване на проблеми в нетривиални предметни области, силно се препоръчва да включите концептуален раздел в ръководството на потребителя. Той трябва да описва метода, внедрен в програмата за представяне на обекти от реалния свят, така че потребителят да разбира добре кои от тях и на какво ниво на абстракция може да работи.

ръководства за ESPD и IEEE Std 1063-2001, като се вземат предвид "Манифеста на Кагарлицки". Показано е, че обобщената структура на ръководството за потребителя, сглобена в съответствие с изискванията на "остарялата" система GOST 19, значително надвишава структурата на ръководството, препоръчана от ултрамодерния IEEE Std 1063-2001. Издание от 20.06.2018г.

Как да напиша ръководство за потребителя? Част I - обобщена структура на ръководството за потребителя в съответствие с GOST система 19 и неговия сравнителен анализ с препоръките на IEEE Std 1063-2001

Създаден на 02/11/2005 11:14:22 AM

Когато надеждата умира, идва отчаянието.

Мъдра латинска поговорка

Как да напиша ръководство? Създайте дървовидно ръководство за потребителя и попълнете секции от него. И цялата любов.

Къде мога да получа структурата на разделите на ръководството за потребителя? С включени ръководства (инструкции за работа за) и включени (), всичко е повече или по-малко ясно. Но документът "Ръководство за потребителя" на самата програма отсъства като клас в GOSTs на 19-та система.

Какво съдържание да попълните в разделите на ръководството за потребителя? Как да бъде? Основното нещо е да не се отчайвате.

Цели и задачи на статията

Както винаги - опитайте се да улесните живота на ръководството за потребителя на програмата.

• анализирайте съществуващите и развиващите се, идентифицирайте предимствата и недостатъците на всеки документ поотделно;
• извеждане на определена обобщена структура на ръководството за потребителя в съответствие със система GOST 19 от съществуващия набор от оперативни програмни документи;
• сравнете го със структурата, препоръчана от IEEE Std 1063-2001;
• и всички други задачи мигрират към 2-ра част на статията ...

Бележка от 10 юли 2014 г. - През февруари 2005 г. може би дори не беше извършен сравнителен анализ, а по-скоро сравнителни тестове, които показаха безспорното превъзходство на системата от стандарти GOST 19 над буржоазните и почти пълното несъответствие на последните .

Въпроси, на които трябва да отговори ръководството за потребителя

Подарете електронна играчка, която не е позната на вашето дете. Списъкът с въпроси ще бъде нещо подобно (освен ако не се счупи веднага):

• какво е;
• и какво могат да направят;
• и какво не трябва да правят (сред надарените);
• и какво е необходимо, за да работи;
• и какво е вътре в него (при деца, склонни към дълбоко);
• но как да го конфигурирам да работи както искам;
• как да го проверите, дали работи или не;
• и какво и къде да натиснете;
• и какво друго може да направи;
• и какво пише, ако натиснете нещо нередно?

Последователността на въпросите може да бъде много разнообразна. И документ, наречен "Ръководство за потребителя", трябва да даде отговори на всички поставени въпроси. Просто е. Дяволът не е толкова страшен, колкото го рисуват.

Ръководство за потребителя: Четири източника и четири компонента

Ние имаме:

• „метагида” на Кагарлицки;
• най-съвременен IEEE Std 1063-2001, "IEEE Standard за софтуерна потребителска документация";
• класически вътрешни ГОСТ от 19-та система, която включва следните документи с "описателен" характер:

Последните четири от списъка са оперативни програмни документи.

Може би има и други документи, но авторът, който старателно се рови в сметището на Рунет, все още не е успял да намери нещо по-подходящо. Yandex откри в недрата си друга страница със заглавие „Как да си направим добро ръководство за потребителя“, чийто автор се нарича американец Бстил (като Джон П. Морган). "Предупреждението" от две страници с наздравици веднага беше изпратено в кошчето за боклук.

Манифестът на Кагарлицки

Метагайдът на Кагарлицки изглеждаше обещаващ. Единствено авторът на тази статия не разбра какво е „метагид“, затова се осмели да нарече метагида „манифест“. И той не съгреши срещу истината (но тя се разкри по-късно - по-долу).

(цитати от манифеста на Кагарлицки)

Опитахме се да обединим в единна система целия набор от стандартни изисквания, които от наша гледна точка трябва да бъдат представени в техническата документация: ръководства, справочници и др. При това ние се основаваме на стандарти (!!!)ГОСТ , стандартите на Microsoft, опита на нашите служители и други разработчици на техническа документация.

Обнадеждаващо начало.

Техническата документация включва две основни части, които ще наречем съответно ръководство за потребителя и справка за потребителя, или накратко: ръководство и справочник (по аналогия с английските фрази User "s Guide и User" s Reference). Те могат да бъдат съставени под формата на отделни документи (за големи софтуерни продукти) или, напротив, да съществуват в интегрирана форма. Може дори да няма ясна граница между тях: един текст е в състояние да съчетае характеристиките на справочник и характеристики на справочник.

Ръководството и справочникът не са толкова части от документацията, колкото въплъщават два подхода за описание на софтуерен продукт.

По отношение на понятията, така че по отношение на понятията, само момчетата започват да се изнервят. Лидерството не е концепция, а е.

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

Звезда на име Надежда блесна на небето - сега уважаемият г-н Кагарлицки ще даде на нас, лишените от права, изчерпателна йерархична структура от ръководства за употреба на всички времена и народи. Хайде?!

Преди да се пристъпи към разработването на документацията като такава, е необходимо да се очертае и планира общата логика на представяне. Може да изглежда, че жанрът на техническата документация е изключително прост: в края на краищата неговата задача е „просто“ да информира потребителя за някаква информация за продукта. Ако обаче изхождате от това в работата си, ще създадете образци на документация, които са напълно неизползваеми или трудно подходящи за практическа употреба - дори ако цялата необходима информация се съдържа там. Вашата задача е да преведете потребителя през прохода, тоест да намерите място в планинската верига, което, дори и с трудност, все още е проходимо за вашия „отдел“.

Жалко... Но всичко започна добре. От стандартите ГОСТ"-" стандарти "- извинете г-н Кагарлицки за тавтологията. Само сега няма решение на първия проблем, поставен от автора на тази статия в манифеста от седемдесет и две страници (Arial "om 12pt). Уважаеми авторе на манифеста, само комплект наша задача ... Е, няма пророк в собствената му страна. Може би в буржоазното отечество има пророк?

Ръководство за потребителя на IEEE Std 1063-2001 "IEEE Standard за софтуерна потребителска документация"

Чуждият "пророчески" документ IEEE Std 1063-2001 (IEEE в обикновените хора - "ay-ay-ay") в подраздел 1.2 (Puprose) съдържа следния ред:

Тази ревизия предоставя изисквания за структурата, информационното съдържание и формата както на печатната, така и на електронната документация.

Според разбирането на автора, целта (намерение, цел, намерение, стремеж) на документа IEEE Std 1063-2001 е „да предостави изисквания за структурата, съдържанието, (дизайна), както и печатната потребителска документация за софтуера“. Е, това е добре. Каква е структурата на ръководството за потребителя, предложено от IEEE Std 1063-2001?

Структура на ръководството за потребителя на IEEE Std 1063-2001

Незадължителна обща структура на потребителското ръководство се съдържа в таблицата от раздела Структура на документацията за потребителя на софтуера на IEEE Std 1063-2001:

Идентификационни данни (етикет на опаковката/заглавна страница)
Съдържание		Да, в документи от повече от осем страници след идентификационни данни
Списък с илюстрации
Концепция за операции
		Да (режим на обучение)
		Да (референтен режим)
		Да, ако документацията съдържа непознати термини
Свързани източници на информация
Навигационни функции
		Да, ако документи са повече от 40 страници
Възможност за търсене		Да, в електронни документи

За целите на този стандарт, следната незадължителна номенклатура се използва за структурните части на документацията на потребителя на софтуера. Печатният документ е структуриран в логически единици, наречени глави, подразделен на теми, които могат да бъдат подразделени на подтеми и отпечатани на физически единици, наречени страници.

Страхотен. IEEE Std 1063-2001 предлага „вземете и споделяйте всичко“ – разделяне на раздели от ръководството на глави, теми, подтеми и т.н. И всички ще бъдат щастливи.

Откроените раздели представляват практически интерес (в рамките на целите на статията). Нека да видим как да разделим раздели от ръководството за потребителя на по-малки структурни единици и какво съдържание трябва да запълни посочените структурни единици.

Въведение

Каква информация трябва да бъде включена в раздела Въведение на IEEE Std 1063-2001? Но какво

Въведението описва предназначената аудитория, обхват и цел на документа и включва кратък преглед на предназначението, функциите и работната среда на софтуера.

Е, това е страхотно. Структурата на подразделите Въведение започва да се оформя.

Информация за използване на документацията

Документацията трябва да включва информация за това как трябва да се използва (например помощ за помощ) и обяснение на нотацията (описание на форматите и конвенциите – вижте 5.8). Най-малко един документ в набор от документи трябва да идентифицира всички документи в комплекта по заглавие и предназначение, включително препоръки за това кои членове на аудиторията трябва да се консултират с кои раздели на документацията. В набори от документи, съдържащи много томове или продукти, тази информация може да бъде предоставена в отделна „пътна карта“ или ръководство за комплекта документи. Документацията може да включва идентифициране и обсъждане на забележителни промени от предишната версия на набора от документи и софтуера.

Много полезен раздел (при разработването на ръководство за потребителя). Ръководство за лидерство.

Концепция за операции

Документацията обяснява концептуалната основа за използване на софтуера, като се използват методи като визуален или вербален преглед на процеса или работния процес; или теорията, обосновката, алгоритмите или общата концепция за действие. Обясненията на концепцията за работа трябва да бъдат адаптирани към очакваното запознаване на потребителите с всяка специализирана терминология за потребителски задачи и софтуерни функции. Документацията трябва да свързва всяка документирана функция с цялостния процес или задачи. Концептуалната информация може да бъде представена в един раздел или непосредствено преди всяка приложима процедура.

Концептуалната информация определено е важна.

Процедури

Документацията за ориентиран към задачи режим на обучение включва инструкции за рутинни дейности, които се прилагат към няколко функции:

Инсталиране и деинсталиране на софтуер, ако се извършва от потребителя

Ориентация към използването на функциите на графичния потребителски интерфейс (вижте 5.6)

Достъп или влизане и излизане от софтуера

Навигация през софтуера за достъп и излизане от функции

Операции с данни (въвеждане, запазване, четене, печат, актуализиране и изтриване)

Методи за отмяна, прекъсване и рестартиране на операции

Тези общи процедури трябва да бъдат представени веднъж, за да се избегне излишък, когато се използват в по-сложни функции.

И конктериката отиде. Браво, буржоа!

Информация за софтуерни команди

Документацията обяснява форматите и процедурите за въведени от потребителя софтуерни команди, включително задължителни параметри, незадължителни параметри, опции по подразбиране, ред на командите и синтаксис. Може да бъде предоставена документация относно разработването и поддръжката на макроси и скриптове. Документацията на референтния режим трябва да съдържа списък на всички запазени думи или команди. Примерите трябва да илюстрират използването на команди. Документацията обяснява как да прекъснете и отмените операцията по време на изпълнение на команда и как да я рестартирате, ако е възможно. Документацията трябва да описва как да разпознаем, че командата е изпълнена успешно или ненормално прекратена.

Съобщения за грешки и разрешаване на проблеми

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

Заключения относно IEEE Std 1063-2001

Но щастието се оказа непълно ... Структурата на разделите от първо ниво на ръководството е показана в таблицата изрично. И след това - "мила моя, добре, познай се" ("познай, казват, сам"). IEEE Std 1063-2001, разбира се, "предоставя изисквания за структурата", но не предлага изрично структури ръководства за потребителя до препоръчания GOST 2.105 от четвърто ниво на гнездене.

Препоръки като "Документацията трябва да обясни ...", "Примерите трябва да илюстрират ...", "Документацията трябва да описва ..." и други подобни със сигурност са изпитани във времето. В ръководството за потребителя е необходимо да се обясни, илюстрира и опише - без съмнение. Но всичко това е разбираемо за козата и е посочено в GOSTs на 19-та система.

Така че е малко вероятно да се разработят ръководства за потребителя, базирани единствено на препоръките на IEEE Std 1063-2001. Има поне две причини:

• липсата на ясно дефинирана структура на ръководството за потребителя в IEEE Std 1063-2001;
• "Повърхност" IEEE Std 1063-2001, липса на "широчина на покритие" и "дълбочина на изследване".

Липсата на ясно регламентирана структура на ръководството за потребителя ще направи това възможно ЛЕЧЕНИЕ, вижте поне. Лошият разработчик ще бъде принуден, по искане на клиента, да разменя раздели от ръководството за потребителя всеки ден (гарантиран минимум, получен емпирично).

Липсата на добре дефинирана структура се превръща в хаос веднага щом нивото на гнездене падне до второ или трето. Потребителят просто ще хвърли такова ръководство в ада и ще нарече автора му маниак.

Според автора препоръките на IEEE Std 1063-2001, разработени с участието на стотици чуждестранни специалисти, са много, много повърхностни. Разработчик, работещ в съответствие с IEEE Std 1063-2001, няма да може да покрие максималните "характеристики", присъщи на програмата. Много от тях просто не са описани в IEEE Std 1063-2001. Няма „широчина на обхвата“ и „дълбочина на изработване“, характерни за вътрешните документи.

В крайния раздел на тази статия има таблица на съответствието между GOST 19 и IEEE Std 1063-2001, която авторът на статията започна да компилира, след това я изпусна и не я провери. И нека всеки сам си прави изводите. И може би той ще коригира автора по някакъв начин.

Потребителски документи в съответствие с GOST 19 (ESPD)

За разлика от ултрамодерния буржоазен IEEE Std 1063-2001, древните, много злоупотребявани вътрешни стандарти на 19-та система (Единна система за програмна документация - ESPD) не съдържат дълги аргументи за това какво и как трябва да обяснява, илюстрира и описва ръководството за потребителя , но специфични изисквания към структурата и съдържанието на потребителските (оперативни) документи.

Списъкът на GOST 19 с "описателен" характер, въз основа на който е възможно, без повече излишни думи, да се формира ясна структура от раздели на всеки от "описателните" документи, е даден в раздела Източници. Основната техника - детайлизиране - е описана подробно в статията "". По-нататък - формира се чрез "детайлизиране" на структурата на разделите от документи в съответствие с GOSTs от списъка.

Структурата на разделите на описанието на програмата съгласно GOST 19.402-78

Структурата на разделите на описанието на приложението съгласно GOST 19.502-78

Структурата на разделите на ръководството на системния програмист в съответствие с GOST 19.503-79

Структурата на разделите на ръководството на програмиста в съответствие с GOST 19.504-79

Структурата на разделите на ръководството за оператора в съответствие с GOST 19.505-79

Заключения съгласно GOST 19.xxx

Нито, нито, нито, взети поотделно, не могат да се похвалят с достатъчна пълнота на структурата.

Но структурите на "описателните" документи на GOST 19 имат както напълно идентични (в текста на заглавията), така и подобни в текста на заглавията на раздели и подраздели. Идентичните раздели включват например разделите "", които се появяват във всички документи според. Подразделите "Цел на програмата" и "" могат да бъдат класифицирани като сходни (всъщност - идентични).

Защо не опитате да комбинирате всички "описателни" документи? Комбиниране на идентични и подобни раздели от документи, подчертаване на конкретни раздели? Може би ще бъде възможно да се отървем от непълнотата на GOST 19.505-79, GOST 19.504-79 и GOST 19.503-79 и да получим обобщена структура на "описателен" документ и да наречем самия документ ръководство за потребителя на програмата?

GOST 19.xxx позволява "да се въвеждат допълнителни раздели или да се комбинират отделни раздели", както и да се "въвеждат нови". Съгласно GOST 19.101-77 „Разрешено е да се комбинират определени видове оперативни документи (с изключение на и). Необходимостта е посочена в. На обединения документ се присвоява и обозначението на един от обединените документи. Комбинираните документи трябва да съдържат информация, която трябва да бъде включена във всеки комбиниран документ [от точка 2.6 от GOST 19.101-77] "

Не по-рано казано, отколкото направено. Само ние ще нарушим GOST и ще създадем унифициран документ, наречен "Ръководство за потребителя".

Обобщена структура на ръководството за потребителя в съответствие със системата GOST 19

Чрез сливане на структурите на „описателните“ документи на GOST система 19 в една структура, премахване на „ненужни“ едноименни раздели, сливане на подобни раздели, се формира общата структура на ръководството за потребителя на програмата. Табелата съдържа и „ * »Маркира секциите, които се появяват във всеки отделен документ.

GOST 19.xxx - обобщена структура на ръчните раздели	GOST 19.402-78	GOST 19.502-78	GOST 19.503-79	GOST 19.504-79	GOST 19.505-79
анотация
Предназначение на документа
Обща информация за програмата
Обозначение и програми
На който е написана програмата
Информация за целта на програмата
Информация, достатъчна за разбиране и
Характеристики на програмата
Класове задачи за решаване
Описание на задачите
Методи за решаване на проблеми
Характеристики на времето
Работни часове
Условия за ползване на програмата
Информация за и осигуряване на изпълнението на програмата
Типове, използвани, когато програмата работи
Изисквания за състав и параметри
Описание на логическата структура
Програми
Използвани методи
Информация относно
Информация за програмата
Информация за и
Подробности за въвеждане
Подробности за изхода
Формат, описание и начин на извеждане
Избор на функция
Илюстративни примери
Описание на начините за проверка на програмата
Тестови случаи
Методи за изпълнение
резултати
Изпълнение на програмата
Стартиране на програмата
Точки за влизане в програмата *
Методи за предаване на контрол и данни
Изпълнение на програмата
Формат и опции за изпълнение на функция 1
Допълнителни функции
Текстове, издадени по време на (настройка, проверка, изпълнение) на програмата
Описание на съдържанието

Заключения относно обобщената структура на ръководството за потребителя в съответствие с GOST 19.xxx

Обобщената структура на ръководството за потребителя в съответствие с GOST 19.xxx очевидно не страда, подобно на IEEE Std 1063-2001, от липсата на покритие. Излишъкът, както знаете, води до качество. Всичко, което програмата може да характеризира е изброено. Отделни подраздели може дори да изглеждат излишни, например подраздел „Езици за програмиране, на които е написана програмата“.

Изглежда, какво го интересува потребителя на какъв език е написан изходният код на програмата? От друга страна, може би „... някой има ли нужда от това? Това означава, че е необходимо...“. В крайна сметка, когато купувате буржоазен телевизор, искате да получите схематична диаграма за него. Самсунг и Соня също се провалят. Ами ако неизправността е незначителна и изглежда възможно да я поправите у дома, без пътуване до сервизен център?

В същото време, при цялата широта на покритие, няма изрично:

• Инсталиране и деинсталиране на софтуер, ако се извършва от потребителя;
• Ориентация към използване на функциите на графичния потребителски интерфейс;
• Достъп или влизане и излизане от софтуера;
• Навигация през софтуера за достъп и излизане от функции и много други.

Авторът успя да разпръсне нещо в раздела Таблица на съответствието на GOST 19.xxx и IEEE Std 1063-2001, но винаги няма достатъчно време да "набръчка ума", ръководството за потребителя, както винаги, трябваше да е готово последно седмица.

Авторът беше твърде мързелив да покаже връзките между разделите на обобщеното ръководство за потребителя и секциите, тъй като посочените връзки са очевидни.

Заключения от източници

Така че, ако първите три задачи са общо взето решени, екстремната задача остава нерешена.

Авторът на манифеста е по-склонен да препоръчва избор думи * и изграждането на изречения, IEEE Std 1063-2001, в най-добрия случай води до изисквания за структурата на ръководството за потребителя, но не дава особена специфика, в GOST 19.xxx процедурите за попълване на разделите на ръководството не са предписани. Може би организирайте един вид смесица от френски и Нижни Новгород? Да използвате и четирите източника като четири градивни елемента?

* Днес на мода е буржоазното – т.нар. контролиран език ... Сред представителите на "просветената руска интелигенция" най-популярен е руският аналог в глаголната форма на повелителното наклонение - филтър базар !

Смес от френски с Нижни Новгород

Защо не? Вземете най-доброто от GOST на 19-та система, - обобщена структура на ръководството за потребителя, добавете към него няколко обяснителни от IEEE Std 1063-2001 и го разредете с неизчерпаема стилистична култура и ресурси от манифеста на Кагарлицки? Придайте на сместа тънък, строг вид, оформете следващата с подробни коментари? Но какво ще стане, ако нито един от горните източници и компоненти поотделно не е в състояние да даде отговори на всички поставени въпроси?

Таблица за съответствие на GOST 19 и IEEE Std 1063-2001

ГОСТ 19.xxx	IEEE Std 1063-2001
анотация
	Въведението описва предназначената аудитория, обхват и цел на документа и включва кратък преглед на предназначението, функциите и операционната среда на софтуера
Предназначение на документа	цел на документа (Въведение)
Резюме на основната част на документа	обхват (Въведение)
Обща информация за програмата
Обозначение и име на програмата
Езици за програмиране, на които е написана програмата
Информация за целта на програмата	кратък преглед на предназначението на софтуера (Въведение)
Информация, достатъчна за разбиране на функциите на програмата и нейната работа	няма подобен подраздел
Характеристики на програмата
Класове задачи за решаване
Описание на задачите
Методи за решаване на проблеми	Документацията трябва да свързва всяка документирана функция с цялостния процес или задачи
Функции, изпълнявани от програмата	кратък преглед на софтуерните ... функции (Въведение)
Описание на основните характеристики и характеристики на програмата	няма подобен подраздел
Характеристики на времето
Работни часове
Контролни инструменти за правилно изпълнение и самовъзстановяване на програмата
Ограничения на обхвата на програмата
Информация за функционални ограничения
Условия за ползване на програмата	Ако са налични различни версии на софтуера за различни операционни среди, заглавната страница трябва да посочи приложимата операционна среда(и), включително версия(и) на хардуера, комуникациите и операционната(ите) система(и) (4.3. Съдържание на идентификационни данни)
Необходими условия за изпълнение на програмата	няма подобен подраздел
Информация за хардуера и софтуера, които осигуряват изпълнението на програмата	Документация за хардуерната и софтуерната среда (4.11 Информация за свързани източници на информация)
Изисквания към технически средства	няма подобен подраздел
Устройства, използвани при стартиране на програмата
размер на RAM
Минимален и (или) максимален състав на хардуера и софтуера
Изисквания към състава и параметрите на периферните устройства
Софтуер, необходим за работата на програмата	кратък преглед на ... операционната среда (Въведение)
Софтуерни изисквания	няма подобен подраздел
Изисквания за други програми
Изисквания и условия от организационен, технически и технологичен характер
Описание на логическата структура
Алгоритъм на програмата	алгоритми (4.5 Концепция за операции)
Използвани методи	използване на такива методи като визуален или вербален преглед на процеса или работния процес (4.5 Концепция за операции)
Информация за структурата на програмата	няма подобен подраздел
Информация за компонентите на програмата
Описание на функциите на компонентите
Информация за връзките между съставните части на програмата
Информация за връзки с други програми
Входна и изходяща информация
Обща характеристика на входната и изходната информация	няма подобен подраздел
Подробности за въвеждане
Същност, организация и предварителна подготовка на входните данни
Подробности за изхода
Същност и организация на продукцията
Формат, описание и метод на кодиране на изходните данни
Описание на кодирането на информация
Настройка на програмата	Идентифициране на технически или административни дейности, които трябва да бъдат извършени преди започване на задачата (4.7 Информация за процедури и уроци)
Описание на стъпките за конфигуриране на програмата	няма подобен подраздел
Корекция на състава на техническите средства
Избор на функция
Илюстративни примери
Проверка на програмата
Описание на начини за проверка на функционалността на програмата	няма подобен подраздел
Тестови случаи	Примерите трябва да илюстрират използването на команди (4.8 Информация за софтуерните команди)
Методи за изпълнение	няма подобен подраздел
резултати
Изпълнение на програмата
	Инсталиране и деинсталиране на софтуера, ако се извършва от потребителя (4.6 Информация за общо ползване на софтуера)
Стартиране на програмата	няма подобен подраздел
Точки за влизане в програмата *	Достъп или влизане и излизане от софтуера (4.6 Информация за общо ползване на софтуера)
Методи за прехвърляне на параметри на управление и данни	няма подобен подраздел
Изпълнение на програмата
Описание на изпълняваната функция 1	Кратък преглед на целта на процедурата и дефиниции или обяснения на необходимите понятия, които не са включени другаде (4.7 Информация за процедури и уроци)
Формат и възможни опции за команди за изпълнение на функция 1	Навигация през софтуера за достъп до ... функции (4.6 Информация за общо ползване на софтуера) Стъпките на обучение трябва да бъдат представени в реда на изпълнение (4.7 Информация за процедури и уроци) Документацията обяснява как да прекъснете и отмените операцията по време на изпълнение на команда и как да я рестартирате, ако е възможно. Документацията обяснява форматите и процедурите за въведени от потребителя софтуерни команди, включително задължителни параметри, незадължителни параметри, опции по подразбиране, ред на командите и синтаксис (4.8 Информация за софтуерните команди)
Програмирайте отговорите на команди за изпълнение на функция 1	Документацията описва как да разпознаем, че командата е изпълнена успешно или ненормално прекратена (4.8 Информация за софтуерните команди)
Край на изпълнението на програмата	Навигация през софтуера ... за излизане от функции Методи за отмяна, прекъсване и рестартиране на операции (4.6 Информация за общо ползване на софтуера)
Допълнителни функции
Описание на допълнителната функционалност на програмата	няма подобен подраздел
Описание на използването на допълнителна функционалност на програмата
Програмни съобщения	Съответни предупреждения, предупреждения и бележки, които се отнасят за цялата процедура (4.7 Информация за процедури и уроци)
Текстове на съобщения, издадени по време на (настройка, проверка, изпълнение) на програмата	няма подобен подраздел
Описание на съдържанието
Описание на действията, които трябва да се предприемат по отношение на тези съобщения

Има много видове предоставяне на помощна информация на потребителя - това са FAQ (често задавани въпроси, често задавани въпроси) и онлайн помощ и ръководство за потребителя (ръководство за потребителя) и популярни съвети (коучмаркове, вижте примера по-долу), видеоклипове за обучение и други.

Има различни причини, поради които трябва да напишете ръководство за потребителя на системата. Като се започне от заявките на клиента (в моята практика имаше случай, когато клиентът трябваше да предостави ръководство за потребителя след всяка итерация, за да може с негова помощ да проведе тест за приемане на функционалността на итерацията) и завършвайки с условията на договора относно доставката на готов софтуер, ако говорим за разработка на софтуер по поръчка. В случай на разработване на собствен продукт, често се случва и писане на ръководство за потребителя.

Често се наема анализатор, за да създаде ръководство, ако няма начин да го възложите на технически писател. В преобладаващото мнозинство от случаите анализаторът е този, който притежава най-пълни познания за системата; той също така има способността да изразява ясно мислите си в писмен вид поради спецификата на професията. Ето защо ми се е налагало да се занимавам със създаването на ръководства за потребителя повече от веднъж.

По-долу са дадени някои практики за писане на добро ръководство за потребителя. Някои от тях може би ще бъдат полезни на някого, когато пише спецификации на изискванията.

1. Стандарти

Често се налага да се напише документ, който да отговаря на изискванията на действащите стандарти. Не може да бъде:

• IEEE Std 1063-2001, "IEEE Standard за софтуерна потребителска документация";
• GOST 19:
  • GOST 19.402-78 ESPD. Описание на програмата;
  • GOST 19.502-78 ESPD. Общо описание. Изисквания за съдържание и дизайн;
  • GOST 19.503-79 ESPD. Ръководство на системния програмист. Изисквания за съдържание и дизайн;
  • GOST 19.504-79 ESPD. Ръководство за програмиста. Изисквания за съдържание и дизайн;
  • GOST 19.505-79 ESPD. Ръководство за оператора. Изисквания за съдържание и дизайн.

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

Книгата на Юрий Кагарлицки MetaGuide също може да бъде полезна. Ръководство за разработчици на техническа документация за софтуер.

2. Структура

Помислете добре структурата на документа: тя трябва да обхваща цялата функционалност на системата, да бъде пълна и разбираема.

Доброто ръководство за употреба трябва да съдържа:

• Анотация, която предоставя обобщение на съдържанието на документа и неговата цел. Също така се препоръчва да напишете кратко резюме в началото на всеки основен раздел.
• Въведениесъдържаща информация как най-добре да използвате това ръководство
• Съдържание
• Главиописвайки как използванеНА
• Терминологичен речники
• Предметен индекс

Също така, ръководството за потребителя може да съдържа:

• ЧЗВи отговори на тях
• Връзкиза допълнителна информация за системата
• Главаописване възможно Проблемии начини за решаването им

Всички глави и параграфи, както и фигури и таблици, са най-добре номерирани, така че да могат да бъдат препратени в рамките на този документ или от друг документ.

3. Потребители

Помислете за типичните потребители на този софтуер: документът ви е необходим, за да им помогне да решават ежедневните си задачи.

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

Уважавайте потребителите на системата, не пишете инструкции в пренебрежителен стил.

4. Характеристики на презентацията

Не забравяйте, че речта и деловото писане се различават по стил от техническата документация и по-специално от ръководството за потребителя.

Стилът на лидерство трябва да бъде неутрално-формален - използването на стилистично оцветени думи отвлича вниманието на потребителя от същността.

Познанията по граматика и малко психология ще ви бъдат полезни, за да напишете добър документ.

4.1 Пишете кратко и логично.Не давайте ненужни подробности, не дублирайте информация. Последователността, в която информацията се споменава в ръководството за потребителя, трябва да съответства на последователността на действията на потребителя:

добре: В меню Файл изберете Запазетевещ.
по-лошо: Изберете Запазетеелемент от менюто Файл.

4.2 Използвайте императива, не използвайте учтиви фрази (моля, може и т.н.) - прекомерната учтивост ще бъде пречка тук.

добре: Щракнете върху Излез от профила си.

по-лошо: Необходимо е за щракване Излез от профила сиза да излезете от текущия потребителски акаунт от системата .

по-лошо: Ако потребителят иска да излезе от текущия потребителски акаунт от системата(ите), трябва да щракне Излез от профила си.

4.3 Структуриране на информацията.Често можете да намерите съвети да се опитате да избегнете списъците, но информацията стъпка по стъпка винаги се възприема по-добре.

Добре:
Да сесъздавайпроект:

1. Щракнете върху Създайтебутон на лентата с инструменти.
2. На Създайте Проектнаслагване попълнете всички задължителни полета.
3. Щракнете върху Запазетебутонза да запазите проекта.

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

4.4 Не използвайте бъдеще или минало време... Например, често се срещат ръководства, в които отговорът на системата към действието на потребителя се предава във фрази, формулирани в бъдеще време. Софтуерът няма минало или бъдеще: всичко се случва в настоящето като пряк резултат от конкретно действие на потребителя. Веднага щом настъпи събитие, софтуерът реагира.

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

по-лошо: Когато потребителят щракне върху Започнетебутон, програмата ще започнепроцеса.

4.5 Проверете значението на думите.Ако е необходимо да напишете документ на чужд език, трябва да се опитате да избегнете възможно най-много грешки, свързани с недостатъчно познаване на езика.

Например, глаголът „натиснете“ означава натискане на клавиш на клавиатурата, а „щракване“ означава натискане на бутон или икона в прозореца на програмата с помощта на мишката, а „hit“ обикновено е жаргонна дума.

Разбира се, правописните грешки са недопустими.

4.6 Не използвайте синоними за един и същи термин.ИТ литературата на английски (или всеки друг) език има стандартен набор от глаголи, обозначаващи действия (щракване, двукратно щракване, избор, въвеждане, натискане и т.н.) и същия стандартен набор от имена на контроли. Решете терминологията и се придържайте към нея в целия документ.

Например, не позволявайте падащо меню да бъде наречено падащо меню в една част на документа и комбо поле или падащ списък в друга. Това обърква потребителя.

4.7 Използвайте съкращенията разумно и премахнете жаргона.

Смята се, че съкращенията не трябва да се използват, но ако се използва дълъг термин няколко пъти, тогава при първото споменаване в текста е необходимо да се напише пълното име и до него - съкращението в скоби и по-нататък в текст можете да използвате само съкращението. Ако документът съдържа речник или раздел със съкращения, те трябва да бъдат транскрибирани там.

Не използвайте жаргонни думи, метафори и термини, заети от език, различен от езика на ръководството.

5. Външен вид

5.1 Помислете за стила на документа... Това може да бъде корпоративен шаблон или софтуерна цветова схема или дизайн, направен специално за документ.

Когато пишете, не се колебайте да подчертавате важни неща със стилове или цветове (например удебелени имена на бутони). Важно е обаче да се разбере, че неправилно избраните шрифтове и цветове могат да затруднят възприемането на съдържанието на документа.

5.2 Не пестете място- разбийте текста на кратки абзаци, използвайте относително големи заглавия, започнете нов раздел на нова страница. Това ще улесни възприемането на прочетената информация от потребителя.

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

6. Подкрепа

Не губете от поглед факта, че софтуерът се променя с течение на времето, което означава, че вашият документ също трябва да се промени, за да остане актуален.

Заключение

Моля, имайте предвид, че раздразнението от документ с лошо качество може да бъде проектирано от потребителя върху софтуера и по този начин да повлияе на решението за използване на продукта.

Запомнете основното: документът трябва да помага на потребителите.

Статията е изготвена от

Тарасюк Надежда, член на сайта на общността,

анализатор с 6 години опит в областта.

@ Журавлев Денис

Много ИТ компании, които разработват и поддържат софтуер и автоматизирани системи, са изправени пред задачата да създават потребителска документация за своите продукти в съответствие с изискванията на GOST.

По правило необходимостта от документация в съответствие с GOST възниква в сътрудничество с правителствени организации, големи индустрии и компании, с разработване на софтуер по поръчка за търгове и държавни поръчки или, ако е необходимо, добавяне на софтуерен продукт към „Единния регистър на руските Програми за електронни компютри и бази данни (регистър на домашен софтуер)“.

Има две серии (комплект) от стандарти, които регулират набора от създадени документи и правилата за тяхното проектиране при разработването на автоматизирани системи, комплекси и софтуер:

• GOST 34 - Автоматизирани системи
• GOST 19 - Единна система за програмна документация (ESPD)

От една страна, тези два стандарта се конкурират помежду си, предлагам различни варианти за пълнота на документацията за проекта. От друга страна, те се фокусират върху различни аспекти и следователно се допълват добре.
GOST 34 определя главно пълнотата, видовете, структурата и съдържанието на създадените документи.
GOST 19 до голяма степен определя правилата за документиране.
Следователно на практика и двата GOST често се използват наведнъж.

Ако говорим конкретно за документацията за крайния потребител на системата, тогава от списъка с документи, описани в GOST 34, се интересуваме от "Ръководството на потребителя". В GOST 19 подобен по значение документ се нарича "Ръководство на оператора", но за софтуера това е първата опция, която се използва по-често.

Ръководството за потребителя се доставя с всеки продукт, програма, система. Той трябва да предоставя на потребителя информация за свойствата на продукта, неговата функционалност, как да използва и работи с него.

За начинаещ технически писател или прост специалист, на когото неочаквано е възложена задачата да подготви ръководство за потребителя за GOST, тази задача е сериозен проблем.

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

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

За опитен технически писател документацията по GOST може да не е твърде трудна. Дори и за него обаче подготовката на шаблони за нови документи, привеждането на съществуваща документация към стандартите или проверката на окончателния документ за съответствие с тези изисквания може да отнеме значително време.

Dr.Explain опростява създаването на ръководство за потребителя по GOST

Започвайки от версия 5.5.1100, програмата за създаване на потребителска документация Dr.Explain предлага функцията за автоматизирана поддръжка на GOST в проекти. Тази функция е предназначена да улесни живота много на потребителите, които са изправени пред задачата да създадат ръководство за потребителя в съответствие с изискванията на държавните стандарти.

По-специално, програмата Dr.Explain контролира и автоматизира поддръжката на следните стандартни изисквания:

• Наличието на задължителни раздели от документа "Ръководство на потребителя" [GOST 34 RD 50-34.698-90]. Всички раздели са снабдени с обяснения за тяхното съдържание.
• Регистрация на заглавни страници, анотации и съдържание [GOST 19.105-78, 19.104-78].
• Параметри на отпечатаните страници на документа и разположението на основните елементи върху тях [GOST 19.106-78].
• Структурата и дизайна на горните и долните колонтитули [GOST 19.106-78].
• Дизайн на текстовата част на документа: стилове на шрифтове, отстъпи на абзаци, разстояние между редовете [GOST 19.106-78].
• Формиране и проектиране на заглавия, раздели, изброявания (списъци) [GOST 19.106-78].

Управлението на функцията за поддръжка на GOST за проект е достъпно в Настройки на проекта в раздела Чести са.

Когато режимът на поддръжка на GOST за проекта е активиран, съответните потребителски настройки за форматите за печат RTF \ DOC и PDF автоматично се отменят от програмата, което гарантира, че параметрите на изходните документи напълно отговарят на изискванията на стандартите.

Персонализираните настройки ще се използват за изходните формати HTML и CHM, независимо дали е активен режимът на поддръжка на GOST. Това премахва ограничението за безплатното оформяне на тези формати и позволява например да се издава онлайн помощ изцяло в корпоративен или тематичен стил.

Важно:

Важно:Функцията за поддръжка на GOST е налична в Dr.Explain само в рускоезичната версия на интерфейса. Езикът на интерфейса на програмата се избира в менюто Настройки \ Избор на език на програмата (Опции \ Език на приложението).

Създаване на ново ръководство за потребителя в съответствие с GOST

За да създадете ново ръководство за потребителя за изискванията на GOST 34 в програмата Dr.Explain, можете да използвате командите на менюто Файл \ Създаване на локален проект - Ръководство за потребителя GOST 34или Файл \ Създайте споделен проект на tiwri.com - Ръководство за потребителя в съответствие с GOST 34

или подобни бутони на началния екран на приложението.

Програмата ще създаде нов проект, който вече съдържа шаблон за заглавна страница, анотация, съдържание и задължителни раздели, проектирани в съответствие с GOST.

В текста на всеки раздел ще има кратък намек какво да включите в този раздел. Потребителят трябва само да попълни секциите с подходящо съдържание.

Настройките на оформлението за форматите за печат RTF / DOC и PDF ще бъдат зададени в съответствие с изискванията на GOST 19.

Привеждане на съществуваща потребителска документация в съответствие с изискванията на GOST

Също така програмата Dr.Explain ви позволява да приведете съществуваща потребителска документация в съответствие с изискванията на GOST.

Важно:Преди да активирате режима на поддръжка на GOST за проекти, които вече съществуват във формат Dr.Explain, трябва да направите резервно копие на файла с графичния интерфейс на проекта.

Ако оригиналната документация все още не се съхранява в Dr.Explain, но се съхранява в други формати, първата стъпка е да импортирате съществуващите документи в програмата. Dr.Explain поддържа импортиране на документи от редица популярни формати. Командите за импортиране са налични както в стартовия прозорец на програмата, така и в менюто Файл.

След това трябва да активирате режима на поддръжка на GOST в свойствата на проекта, както е описано по-рано. Програмата ще провери структурата на документа за наличието на задължителни секции и, ако липсват, ще ги създаде. Останалите съществуващи секции, чието присъствие не се регулира от GOST, ще бъдат преместени в раздела, скрит от експорта “ Старо дърво за дялове”.

Потребителят ще трябва да прехвърли съдържанието на тези раздели или секции изцяло чрез плъзгане и пускане в основното дърво на проекта и да ги редактира според нуждите.

Както в първия случай, настройките за оформление за форматите за печат RTF / DOC и PDF ще бъдат зададени в съответствие с изискванията на GOST 19.