Документирование программного обеспечения

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Общая характеристика состояния

1.1 Техническое задание

1.2 Внешние и внутренние языки спецификации

1.3 Руководство пользователя

1.4 Руководство программиста

Заключение

Список использованной литературы

Приложения

Введение

Когда программист-разработчик получает в той или иной форме задание на программирование, перед ним, перед руководителем проекта и перед всей проектной группой встают вопросы:

· что должно быть сделано, кроме собственно программы?

· что и как должно быть оформлено в виде документации?

· что передавать пользователям, а что - службе сопровождения?

· как управлять всем этим процессом?

· что должно входить в само задание на программирование?

Кроме упомянутых вопросов есть и другие.

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

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

1. Общая характеристика состояния

Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации.

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ 19.xxx-xx) носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС (ГОСТ 34.xxx-xx, Международному стандарту ISO/IEC, и др.). Дело в том, что в соответствии с Законом РФ "О стандартизации" эти стандарты становятся обязательными на контрактной основе - то есть при ссылке на них в договоре на разработку (поставку) ПС.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела.

К числу основных недостатков ЕСПД можно отнести:

· ориентацию на единственную, "каскадную" модель жизненного цикла (ЖЦ) ПС;

· отсутствие четких рекомендаций по документированию характеристик качества ПС;

· отсутствие системной увязки с другими действующими отечественными системами стандартов по ЖЦ и документированию продукции в целом, например, ЕСКД;

· нечетко выраженный подход к документированию ПС как товарной продукции;

· отсутствие рекомендаций по самодокументированию ПС, например, в виде экранных меню и средств оперативной помощи пользователю ("хелпов");

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

Итак, ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95 на процессы жизненного цикла ПС об этом стандарте далее будет сказано подробнее).

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

Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию ЖЦ продуктов программного обеспечения (ПО) - казалось бы весьма неконкретный, но вполне новый и отчасти "модный" стандарт.

Стандарты комплекса ГОСТ 34.xxx-xx на создание и развитие автоматизированных систем (АС) - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Но эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости.

Прошло много лет, программирование происходит в среде совершенно новых технологий, многие программисты, работая в стиле drag-and-drop, могут годами не видеть текст своих программ. Это не значит, что исчезла необходимость в их документировании. Более того, вопросы о наличии хоть какой-то системы, регламентирующей эту сторону создания программных средств, продолжают задавать постоянно. Спрашивают и о том, есть ли обязательные для применения стандарты (особенно остро стоит этот вопрос, когда разработка выполняется по заказу государственной организации или предприятия). Интересуются и тем, где можно купить имеющиеся стандарты.

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

Документацию программного продукта условно можно поделить на:

· техническое задание;

· внешние и внутренние языки спецификации;

· руководство пользователя;

· руководство программиста.

1.1 Техническое задание

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

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

Техническое задание на разработку ПО должно включать следующие разделы:

· введение;

· основания для разработки;

· назначение разработки;

· требования к программе;

· требования к программной документации;

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приемки;

· приложения.

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

В разделе “Введение” указывается наименование, краткая характеристика области применения ПО.

В разделе “Основания для разработки” указывается:

· документ (документы), на основание которых ведется разработка;

· организация, утвердившая документ, и дата утверждения;

· наименование (условное обозначение) темы разработки.

В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение ПО.

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

1.2 Внешние и внутренние языки спецификации

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

· Соглашение о требованиях;

· Внешняя спецификация;

· Внутренняя спецификация.

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

Ниже приведена общая структура документа “Внешняя спецификация”, с развернутыми комментариями в тех пунктах, которые касаются технической стороны дела

1. Описание программного изделия

1.1. Наименование и шифры ПО (полное наименование, сокращенные наименования, шифры ПО и проекта).

1.2. Краткое описание ПО (включая сведения об авторском праве, иерархию документов, с указанием документов вышестоящих уровней).

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

2. Цели

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

3. Стратегия

3.1. Соглашения относительно представления материала.

3.1.1. Обозначения (определяются все обозначения, используемые в требованиях: например, если применяются индексы, то дается пример их использования и определяется принцип индексации).

3.1.2. Терминология (особенно специфическая для данного изделия).

3.1.3. Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшего описания требований).

3.2. Генерируемое программное обеспечение (классифицируется как вспомогательное и порождаемое описываемым изделием).

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

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

3.3.n. Общие характеристики функции n. Если технически затруднительно и неестественно рассматривать ПО как один большой функциональный модуль, то следует привести его функциональную декомпозицию, показав связи между функциями (функциональными модулями) и присвоив каждой функции некоторое уникальное имя n. Затем для каждой функции отводится подраздел раздела 3.3 (т.е. 3.3.1, 3.3.2 и т.д.), в заглавии которого используется слово функция с последующим именем функционального модуля. Такая функциональная декомпозиция не указывает, как именно ПО будет фактически разбито на программные модули (это составляет содержание документа Внутренняя спецификация). Для удобства работы, конечно, полезно иметь некоторое соответствие функционального и фактического разбиения, но это не является требованием и не должно уводить с правильного пути проектирования изделия.

3.3.n.1. Внешние ограничения.

3.3.n.1.1. Стандарты (список используемых промышленных стандартов и собственных стандартов предприятия).

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

3.3.n.1.3. Программные ограничения. Описываются программное окружение разрабатываемого ПО, включая указание средств для его загрузки и запуска.

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

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

3.3.n.2. Внешние характеристики.

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

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

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

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

3.3.n.2.3. Входы. Описание подобно п. 3.3.2.1

3.3.n.3. Эргономические характеристики.

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

Остановимся более подробно на двух подразделах: Надежность и Рабочие характеристики.

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

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

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

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

4. Используемые материалы (в т.ч. справочные)

5. Передача заказчику и ввод в действие

1.3 Руководство пользователя

документация программный продукт спецификация

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

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

В связи с этим следует различать две категории пользователей: ординарных пользователей программы и администраторов. Ординарный пользователь программы (end-user) использует программу для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью данной программы. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор программы (system administrator) управляет использованием программы ординарными пользователями и осуществляет сопровождение программного средства, не связанное с модификацией программ. Например, он может регулировать права доступа к программе между ординарными пользователями, поддерживать связь с поставщиками программы или выполнять определенные действия, чтобы поддерживать программу в рабочем состоянии, если оно включено как часть в другую систему.

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

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

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

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

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

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

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

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

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

1.4 Руководство программиста

Документация по сопровождению программного средства (system documentation) описывает программное средство с точки зрения ее разработки.

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

Документация по сопровождению программного средства можно разбить на две группы:

1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;

2. документацию, помогающую вносить изменения в программное средство.

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

Внешнее описание программного средства (Requirements document).

Описание архитектуры программного средства (description of the system architecture), включая внешнюю спецификацию каждой ее программы.

Для каждой программы программного средства - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.

Для каждого модуля - его спецификация и описание его строения (design description).

Тексты модулей на выбранном языке программирования (program source code listings).

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

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

Документация второй группы содержит

Руководство по сопровождению программного средства (system maintenance guide), которое описывает известные проблемы вместе с программным средством, описывает, какие части системы являются аппаратно- и программно- зависимыми, и как развитие программного средства принято в расчет в его строении (конструкции).

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

Заключение

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

В России в области обеспечения жизненного цикла и качества сложных комплексов программ в основном применяется группа устаревших ГОСТов, которые отстают от мирового уровня на 5-10 лет.

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

Список использованной литературы

1. В.Э. Карпов «Об оформлении программной документации» (http://www.raai.org/about/persons/karpov/pages/ofdoc/ )

2. http://www.aanet.ru/~web_k46/textbooks/std_pro/face.htm - Богданов Д.В.,

3. Путилов В.А., Фильчаков В.В. «Стандартизация процессов обеспечения качества программного обеспечения»

4. Ю.В. Кагарлицкий «Техническая коммуникация: к постановке проблемы» (http://www.philosoft.ru/techcomm.zhtml)

5. М. Острогорский «Зачем нужны ГОСТ 19 и ГОСТ 34» (http://www.philosoft.ru/gost34scope.zhtml)

6. М. Острогорский «Как мир устроен? Концепционный раздел руководства пользователя» (http://www.philosoft.ru/kakmirustroen.zhtml)

7. Ю.В. Кагарлицкий «Руководство для разработчиков технической документации к программному обеспечению» (http://www.philosoft.ru/_subsites/tcportal/metaguide/)

Приложение А

Перечень документов ЕСПД

ГОСТ 19.001-77 ЕСПД	Общие положения.
ГОСТ 19.101-77 ЕСПД	Виды программ и программных документов
ГОСТ 19.102-77 ЕСПД	Стадии разработки.
ГОСТ 19.103-77 ЕСПД	Обозначение программ и программных документов.
ГОСТ 19.104-78 ЕСПД	Основные надписи.
ГОСТ 19.105-78 ЕСПД	Общие требования к программным документам.
ГОСТ 19.106-78 ЕСПД	Требования к программным документам, выполненным печатным способом.
ГОСТ 19.201-78 ЕСПД	Техническое задание. Требования к содержанию и оформлению.
ГОСТ 19.202-78 ЕСПД	Спецификация. Требования к содержанию и оформлению.
ГОСТ 19.301-79 ЕСПД	Порядок и методика испытаний.
ГОСТ 19.401-78 ЕСПД	Текст программы. Требования к содержанию и оформлению.
ГОСТ 19.402-78 ЕСПД	Описание программы.
ГОСТ 19.404-79 ЕСПД	Пояснительная записка. Требования к содержанию и оформлению.
ГОСТ 19.501-78 ЕСПД	Формуляр. Требования к содержанию и оформлению.
ГОСТ 19.502-78 ЕСПД	Описание применения. Требования к содержанию и оформлению.
ГОСТ 19.503-79 ЕСПД	Руководство системного программиста. Требования к содержанию и оформлению.
ГОСТ 19.504-79 ЕСПД	Руководство программиста.
ГОСТ 19.505-79 ЕСПД	Руководство оператора.
ГОСТ 19.506-79 ЕСПД	Описание языка.
ГОСТ 19.508-79 ЕСПД	Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
ГОСТ 19.604-78 ЕСПД	Правила внесения изменений в программные документы, выполняемые печатным способом.
ГОСТ 19.701-90 ЕСПД	Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
ГОСТ 19.781-90	Обеспечение систем обработки информации программное

Приложение Б

Эксплуатационная документация на программный продукт

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

Размещено на Allbest.ru