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

Обновлено: 02.07.2024

Документа́ция на программное обеспечение — печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст, описывающие, как пользоваться программным продуктом [1] .

Документ — элемент документации: целевая информация, предназначенная для конкретной аудитории, размещенная на конкретном носителе (например, в книге, на диске, в краткой справочной карте) в заданном формате [1] .

Программная документация — документы, содержащие в зависимости от назначения данные, необходимые для разработки, производства, эксплуатации, сопровождения программы или программного средства [2] .

Содержание

Типы документации [ | ]

Существует четыре основных типа документации на ПО:

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

Архитектурная/проектная документация [ | ]

Техническая документация [ | ]

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

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

Часто при составлении технической документации используются автоматизированные средства — генераторы документации, такие как Doxygen, javadoc, NDoc и другие. Они получают информацию из специальным образом оформленных комментариев в исходном е, и создают справочные руководства в каком-либо формате, например, в виде текста или HTML.

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

Пользовательская документация [ | ]

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

В случае если продуктом является программная библиотека, пользовательская документация и документация на становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так.

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

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

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

Маркетинговая документация [ | ]

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

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

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

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

Для включения в Единый реестр ПО должно пройти проверку в Экспертном совете при Минкомсвязи России. Проверка ПО осуществляется на предмет соответствия Правилам формирования и ведения Единого реестра.

Данные рекомендации разработаны Центром компетенций по импортозамещению в сфере ИКТ и предназначены для применения правообладателями ПО в процессе подготовки к процедуре проверки Экспертным советом.

1. Проверка технологического стека

1. Подготовьте список необходимых для установки и работы вашего ПО сторонних компонентов/систем;

2. Проверьте, что для всех компонентов/систем отсутствуют ограничения по распространению и использованию на территории Российской Федерации, включая отдельные субъекты (Республика Крым, Севастополь);

3. Проверьте соответствие вашего ПО на требования к операционным системам как среде функционирования:

1. Серверные операционные системы

- не менее 2 различных ОС из Реестра;
- Microsoft Windows Server (2008 и выше);

2. Десктопные операционные системы

- не менее 2 различных ОС из Реестра;
- Microsoft Windows (7 и выше);

3. Мобильные операционные системы

- мобильная ОС из Реестра (в настоящий момент - Аврора);

3.2. Для остальных классов ПО - дополнительные требования к ОС не установлены.

4.1. СУБД

1. EnterpriseDB
2. IBM DB2
3. InterSystems Caché
4. Microsoft Access
5. Microsoft SQL Server
6. Oracle Database
7. Oracle MySQL (Standard Edition, Enterprise Edition, Cluster Carrier Grade Edition)
8. Oracle NoSQL Database
9. Redis Enterprise
10. SAP HANA
11. SAP Adaptive Server Enterprise (ASE) / Sybase Adaptive Server Enterprise (ASE)
12. SAP SQL Anywhere / Sybase SQL Anywhere
13. Splunk

1. Любые СУБД из Единого реестра

2. СУБД с открытой лицензией, в частности:

а) CouchDB
б) Elasticsearch
в) Firebird (рекомендуется перейти на российский аналог Ред База Данных)
г) Hive
д) MariaDB
е) MongoDB
ж) Oracle MySQL (Community Edition)
з) PostgreSQL (рекомендуется перейти на российский аналог PostgresPro)
и) Redis (open-source edition)

3. СУБД стран, не налагающих санкции, например:

a. Tmaxsoft Tibero

4.2. Серверы приложений

1. Adobe ColdFusion
2. IBM WebSphere Application Server
3. Oracle Weblogic Application Server
4. RedHat JBoss Enterprise Application Platform
5. RogueWave Zend Server
6. SAP NetWeaver Application Server

1. Любые серверы приложений из Реестра (например, Liberica JDK)

2. Серверы приложений с открытой лицензией, в частности:

а) Enhydra Server
б) Geronimo
в) GlassFish
г) OpenJDK
д) Resin Java Application Server
е) TomEE
ж) WildFly

3. Серверы приложений стран, не налагающих санкции

4.3. Платформы

1. Amazon Web Services
2. IBM FileNet
3. IBM Lotus Domino / Notes
4. Microsoft Azure
5. Microsoft Dynamics
6. Microsoft SharePoint
7. SAP

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

Свидетельство Роспатента;
[или] Договор отчуждения исключительного права;
[или] Комплект внутренних актов компании на создание и принятие на учет соответствующего нематериального актива и т.п.

2. Проверьте корректность указания Правообладателя на экземпляре ПО, в частности:

3. Подготовьте список использованных при разработке ПО сторонних компонентов с указанием их правообладателей и лицензий их распространения.

4. Проверьте, что использованные при разработке ПО сторонние компоненты:

3. Подготовка проверочного экземпляра

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

4. Определение классов

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

3. Выберите подходящие для вашего ПО классы.

5. Наличие необходимых лицензий

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

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

6. Информация о процессах разработки и поддержки

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

1. Подготовьте информацию о процессе разработки:

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

2. Подготовьте информацию о процессе сопровождения:

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

В качестве минимально необходимых должны быть описаны следующие процессы:

Процессы реализации (разработки) ПО – проектирование, конструирование, сборка, тестирование;
Процессы поддержки ПО – менеджмент конфигурации ПО, процесс решения проблем в ПО.

7. Актуализация информации на официальном сайте

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

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

3. Проверьте, что страница содержит описание функциональных характеристик ПО;

4. Проверьте, что страница:

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

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

Зачем формализовывать разработку компьютерной программы

Чтобы определить, какие нужны документы, разберемся, для чего они нужны.

1. Авторское право на любое произведение возникает в силу факта его создания . Это значит, что с того момента, как КП разработана, возникает и ее правовая охрана. В случае возникновения споров (в том числе судебных) относительно прав на КП разработчику надо будет подтвердить, что она была создана им раньше, чем оппонентом.

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

3. Исключительное право на КП признается в целях бухучета нематериальным активом при выполнении ряда условий. В частности, нематериальные активы принимаются к бухучету по первоначальной стоимости на основании акта о приеме-передаче нематериальных активов .

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

Как формализовать разработку компьютерной программы

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

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

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

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

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

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

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

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

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

4) акт о приеме-передаче нематериальных активов по установленной форме.

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

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

Что защищает авторское право

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

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

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

Как известно, авторское право охраняет форму произведения, а не его содержание. Содержание охраняется лишь через форму произведения.

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

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

На заметку
Алгоритмы и программы для ЭВМ не являются изобретениями с точки зрения патентного права . То есть нельзя получить патент на алгоритм.

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

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

Как защитить то, что не защищает авторское право

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

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

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

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

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

В случае если продуктом является программная библиотека, пользовательская документация и документация на код становятся очень близкими, почти эквивалентными понятиями. Но в общем случае, это не так.

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

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

Маркетинговая документация

· подогреть интерес к продукту у потенциальных пользователей

· информировать их о том, что именно делает продукт, с тем чтобы их ожидания совпадали с тем, что они получат

· объяснить положение продукта по сравнению с конкурирующими решениями

Документация на техническое обеспечение

ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Документация по техническому обеспечению АСУ предназначена для описания проектных решений по техническому обеспечению в документах:

· описание комплекса технических средств;

· структурная схема комплекса технических средств;

· перечень заявок на разработку новых технических средств;

· перечень заданий заказчику АСУ (Генпроектировщику) на проектирование в смежных частях проекта объекта, связанное с созданием АСУ;

· ведомость оборудования и материалов;

· технические требования к технологическому объекту управления;

· задание на проектирование в смежной части проекта объекта, связанное с созданием АСУ;

· проектная оценка надежности комплекса технических средств;

· таблица соединений и подключений;

· схема соединений внешних проводок;

· чертеж общего вида;

· схема подключений внешних проводок;

· чертеж установки технических средств;

· ведомость потребности в материалах.

(Измененная редакция, Изм. № 1)

1.2. При разработке документов на подсистему содержание разделов каждого документа ограничивают рамками данной подсистемы.

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

1.4. Отсутствие проектных решений по разделу документа фиксируют в соответствующем разделе с необходимыми пояснениями.

ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

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

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

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰).

Читайте также: