Стандарти, що регламентують експлуатаційну документацію

 

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

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

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

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

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

- консультация разработчиков программ и данных по особенностям применения операционной системы и системы управления базой данных (СУБд);

- планирование использования памяти и производительности вычислительной системы в рабочем режиме применения ПС;

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

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

- управление, корректировка и учет внешней среды при реконфигурации конкретного ПС;

- оперативное управление, учет и распределение ресурсов системы и компонентов ПС;

- управление средствами защиты информации и санкционированный доступом пользователей, анализ попыток взлома системы защиты;

- защита и восстановление информации баз данных при дефектах и искажениях;

- сбор статистики о функционировании системы обработки информации и ПС.

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

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

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

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

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

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

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

- визуализации и непосредственного взаимодействия пользователей с различными типами терминалов;

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

- интерфейсов программных средств визуализации с приложениями.

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

Основу современного пользовательского интерфейса с ПС составляют наборы текстовых и графических элементов и действий над ними, представляемые как меню и системы окон для манипулирования с изображениями. Основные особенности современного интерфейса с пользователями состоят в следующем [4, 16, 19]:

-наличие механизмов управления окнами;

-использование готовых графических символов (икон) для отображения управляемых объектов;

-непосредственное манипулирование графическими объектами и окнами посредством «мыши»;

-объектно- и проблемно-ориентированное проектирование диалоговых систем.

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

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

-соответствие между элементами интерфейсов пользователя (экранными формами) и типовыми процедурами;

-последовательность допустимых операций и переходы между экранными формами;

-формы идентификации ошибочных действий и/или ситуаций;

-формы входных и выходных документов.

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

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

- определение видов и уровней обучения и категорий персонала, требующих обучения;

- разработка и документирование планов и требований к обучению;

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

- планирование должно обеспечить регулярное обучение персонала, контроль и учет результатов обучения с оценкой достигнутой квалификации специалистов;

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

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

СтандартISO 15910 является наиболее современным нормативным документом, регламентирующим процессы создания эксплуатационной документации для пользователей сложных программных средств. Целью стандарта является стимулирование разработчиков программных средств к методичному использованию процесса документирования. Он построен по традиционной схеме стандартов ISO и первые семь разделов являются вводными, а также определяют терминологию. Основное, функциональное содержание стандарта сосредоточено в 8-м разделе - Требования к документированию ПС. В разделе 8.1 — Процессы документирования программных средств представлена общая схема процессов и их взаимодействие. Изложена детальная структура плана документирования, ориентированного на разработчиков документов, и процедуры контроля реализации плана (рис.2.2). Обзоры — описания документов, рекомендуется подготавливать в виде двух последовательно уточняющихся и детализирующихся редакций с окончательной корректурой и проверкой их адекватности путем тестирования.

Рисунок 2

 

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

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

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

Процесс документирования должен быть выполнен в два этапа в последовательности, представленной на рис. 3.

Рисунок 3

 

Поэтапные работы выполняются не одновременно. На отдельных этапах работы могут проводиться параллельно. Возможные итерации работ показаны пунктирными линиями. Минимальный состав документации определяется заказчиком (например, с использованием ISO12207 или ISO 6592), что должно быть учтено документатором при разработке плана документирования.

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

- конкретной эксплуатационной среды и ее характеристики;

- основных компонентов системы и связей между ними;

- внешних интерфейсов системы;

- возможностей и функций системы;

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

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

- уровней и циклов технического обслуживания;

- форм регистрации обнаруженных дефектов;

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

- концепцию поставки новой или модифицированной версии, эксплуатационный сценарий;

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

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

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

- к рабочей копии программного средства (при необходимости);

- к аналитикам и программистам, включая своевременное правильное решение вопросов, возникающих у персонала разработчиков документации;

- к типичным пользователям (по возможности) для анализа аудитории и тестирования на практичность.

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

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

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

- рабочее наименование, назначение, область применения и ограничения по использованию планируемой документации;

- спецификацию стиля документов;

- определение аудитории и квалификации пользователей;

- обоснование причин использования документов данной аудиторией и ее целевое назначение;

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

- номенклатуру поставки — число печатных копий, наличие электронных копий, форматы дисков и файлов (включая версии программных средств) и откуда они могут быть поставлены;

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

- уровни (грифы) секретности и конфиденциальности (при необходимости);

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

- методы и средства производства (тиражирования) и используемые версии программных средств;

- структуру коллектива разработчиков документов и, возможно, плана выбора данной структуры;

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

- метод передачи документатору информации об изменениях программного средства в процессе его разработки;

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

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

- календарное планирование (графики) по контрольным точкам, включая (при необходимости):

* утверждение плана документирования;

* подготовку, проверку и корректировку проекта каждого

документа;

* тестирование на практичность;

* подготовку оригиналов шаблонов;

* распечатку, переплетение и распространение документации.

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

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

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

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

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

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

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

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

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

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

- этапы жизненного цикла разработки, на которых должно проводиться тестирование;

- цели тестирования;

- используемые показатели (например, время реакции задач);

- среду тестирования;

по ним;

число и вид привлекаемых пользователей;

процесс описания результатов тестирования и рекомендаций

- процесс обеспечения реализации рекомендаций по результатам тестирования;

- процесс доведения результатов тестирования до всего персонала разработчиков документов и заказчика;

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

- процесс определения необходимости последующего тестирования.

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

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

Контроль изменений и сопровождение документации. В плане документирования должны быть предусмотрены следующие типы изменений документации:

- функциональные изменения данной версии — изменения функции ПС, внесенные при разработке документации и отраженные в опубликованной документации;

- функциональные изменения последующей версии — изменения функции ПС, внесенные при разработке документации и не отраженные в опубликованной документации, но подлежащие учету в последующей редакции;

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

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

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

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

- наименование документа и номер версии или дата были указаны в верхнем или нижнем колонтитуле конкретного документа;

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

- дополнительно был предусмотрен метод, позволяющий пользователю контролировать соответствие конкретной копии данного документа используемой версии ПС.

В стандарте ISO 15910 представлены рекомендации по созданию и применению электронной документации, справочной и диалоговой информации. В спецификации документации могут быть указаны один или несколько из следующих типов справочной информации:

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

- расширенная справка — информация о текущем экране или окне, включая ее назначение и требуемый режим использования;

- справка о клавишах — о применении клавиатуры, функциональном назначении клавиш и их наименовании (обозначении);

- справка о сообщении — о том, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;

- терминологическая справка — определения конкретных элементов, связей с конкретной тематикой и расшифровка обозначений и сокращений.

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

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

- командные справки — определяют синтаксис, результаты и целевое назначение каждой команды (только для команд управления системой);

- рекомендации по сообщению определяют, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;

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

В стандарте ISO 15910 представлено восемь приложений, содержащих примеры и расширяющих некоторые концепции базовой части стандарта:

Приложение А. Перекрестные ссылки с стандартом ISO 12207.

Приложение В. Использование настоящего стандарта в договоре и практическое применение настоящего стандарта.

Приложение С. Образец плана документирования. документация пользователя для системы АВС:

С.1. Введение

С.2. Область применения и ограничения

С.3. Оформление и стиль описания

С.4. Аудитория

С. 5. Проект содержания до