Защита программного обеспечения — Википедия

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

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

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

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

Локальная программная защита[править | править код]

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

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

Сетевая программная защита[править | править код]

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

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

Если программа работает с каким-то централизованным сервером и без него бесполезна (например, сервера онлайн-игр, серверы обновлений антивирусов). Она может передавать серверу свой серийный номер; если номер неправильный, сервер отказывает в услуге. Недостаток в том, что, существует возможность создать сервер, который не делает такой проверки. Например, существовал сервер battle.da

, который по функциям был аналогичен Battle.net (от компании Blizzard Entertainment), но пускал пользователей неавторизованных копий игр. Сейчас этот сервер закрыт, но существует немалое количество PvPGN-серверов, которые также не проверяют регистрационные номера.

Защита при помощи компакт-дисков[править | править код]

Программа может требовать оригинальный компакт-диск. В частности, такой способ применяется в играх. Стойкость таких защит невелика, ввиду широкого набора инструментов снятия образов компакт-дисков.^[1]

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

Для защиты от копирования используется:

• запись информации в неиспользуемых секторах;
• проверка расположения и содержимого «сбойных» секторов;
• проверка скорости чтения отдельных секторов.

Первые два метода практически бесполезны из-за возможности снятия полного образа с диска с использованием соответствующего прикладного ПО. Третий метод считается более надёжным (используется, в частности, в защите StarForce). Но существуют программы, которые могут эмулировать диски с учётом геометрии расположения данных, тем самым обходя и эту защиту. В StarForce, в числе прочих проверок, также выполняется проверка возможности записи на вставленный диск. Если она возможна, то диск считается не лицензионным. Однако, если образ будет записан на диск CD-R, то указанная проверка пройдет. Существует возможность скрыть тип диска, чтобы CD-R или CD-RW был виден как обычный CD-ROM. Однако, в драйвер защиты может быть встроена проверка на наличие эмуляции.

В настоящее время наибольшую известность в мире имеют системы защиты от копирования SecuROM, StarForce, SafeDisc, CD-RX и Tages.^[2]

Для многих программ указанный метод защиты недоступен ввиду отличного способа распространения (например, shareware-программы).

Защита при помощи электронных ключей[править | править код]

Современные электронные ключи

Электронный ключ (донгл), вставленный в один из портов компьютера (с интерфейсом USB, LPT или COM) содержит ключевые данные, называемые также лицензией, записанные в него разработчиком

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

Достоинства защиты с использованием электронных ключей:

• Ключ можно вставлять в любой компьютер, на котором необходимо запустить программу
• Ключ не занимает/не требует наличия дисковода
• Электронный ключ умеет выполнять криптографические преобразования
• Современные ключи могут исполнять произвольный код, помещаемый в них разработчиком защиты (пример — Guardant Code, Senselock)

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

Основные недостатки:

• Цена (15—30 долларов за штуку)
• Необходимость доставки ключа конечному пользователю

Ранее к недостаткам можно было также отнести невысокое быстродействие ключа (в сравнении с CPU компьютера). Однако современные ключи достигают производительности в 1.25 DMIPS (пример — HASP, Guardant), а техника защиты с их помощью не предполагает постоянного обмена с ключом.

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

Привязка к параметрам компьютера и активация[править | править код]

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

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

Достоинство в том, что не требуется никакого специфического аппаратного обеспечения, и программу можно распространять посредством цифровой дистрибуции (по Интернет).

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

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

До недавнего времени такие защиты разрабатывались и внедрялись разработчиками самого программного продукта. Однако сейчас существуют SDK для работы с программными ключами, например HASP SL от компании Aладдин Р. Д. Также все большее распространение получают сервисы, предлагающие одновременно функцию «навесной» защиты и сервера активации/лицензирования (пример — Guardant Online, Protect online)

[источник не указан 114 дней].

Защита программ от копирования путём переноса их в онлайн[править | править код]

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

Код исполняется на «доверенной» стороне, откуда не может быть скопирован.

Однако, и здесь возникает ряд проблем, связанных с безопасностью:

• стойкость такой защиты зависит, прежде всего, от защищённости серверов, на которых он исполняется (речь идёт о Интернет-безопасности)
• важно обеспечение конфиденциальности запросов, аутентификации пользователей, целостности ресурса (возможности «горячего» резервирования), и доступности решения в целом

Возникают также вопросы доверия сервису (в том числе правовые), так как ему фактически «в открытом виде» передаются как само ПО, так и данные, которые оно обрабатывает (к примеру, персональные данные пользователей).

Защита кода от анализа[править | править код]

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

Защита программного обеспечения на мобильных платформах[править | править код]

Способы защиты программного обеспечения для мобильных платформ от копирования обычно основываются на невозможности рядового пользователя считывать/изменять хранящиеся в ППЗУ аппарата данные. Может также использоваться активация программного обеспечения.

Устаревшие технические средства защиты[править | править код]

В прошлом применялись и другие методы защиты ПО от нелегального использования.

Ключевая дискета[править | править код]

Метод был распространён во времена MS-DOS, сейчас, в силу устаревания технологии FDD, практически не применяется. Есть четыре основных способа создания некопируемых меток на дискетах:

• Считывание конкретного сектора дискеты (возможно, пустого или сбойного). Это самый простой способ защиты, и при копировании «дорожка в дорожку» дискета копируется.
• Запоминание сбойных секторов дискеты. Перед тем, как записать на дискету информацию, её царапают (или прожигают лазером), после этого записывают номера сбойных секторов. Для проверки подлинности дискеты программа пытается записать в эти сектора информацию, затем считать её.
• Нестандартное форматирование дискеты. Известна программа FDA (Floppy Disk Analyzer), которая могла проводить исследование и копирование таких дискет.
• «Плавающий бит». Один бит записывается так, что в некоторых случаях он читается как «0», в некоторых как «1». Проводится многократное считывание дискеты; среди результатов считывания должны быть и нули, и единицы.

Запись некопируемых меток на жёсткий диск[править | править код]

Некоторые старые программы для DOS создавали некопируемые метки на жёстком диске. Например, файл длиной 1 байт занимает на диске один кластер (не менее 512 байт), и в оставшиеся 511 байт можно записать некоторую информацию. Эта практика практически не используется, так как велик риск потери данных.

Привязка к некоторому физическому объекту[править | править код]

Лицензия программы может привязываться к некоторому физическому объекту, к примеру:

• к руководству пользователя. Например, программа выводит: «Введите 5-е слово на 12-й сверху строке 26-й страницы». Более изощрённый способ защиты — в руководстве находится важная информация, без которой невозможно пройти игру, этим известна серия Space Quest. Распространение сканеров и многозадачных операционных систем положило конец этой практике.
• к некоторому механическому устройству. Игра Another World поставлялась с «кодовым колесом». В системе защиты от копирования Lenslok, применявшейся в играх для ZX Spectrum, надо было, посмотрев на картинку через систему призм, увидеть двухбуквенный код.

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

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

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

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

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

Недостатки технических методов защиты ПО[править | править код]

Уязвимости современных методов защиты ПО[править | править код]

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

• Проверка оригинального носителя. Можно обойти при помощи копирования / эмуляции диска (специальная программа полностью копирует диск, затем создаётся драйвер виртуального дисковода, в который помещается образ, который программа принимает за лицензионный диск. Во многих играх применяется вариант этого метода под названием «Mini Image», когда подставной диск имеет маленький размер (несколько мегабайт, содержащие только лицензионную информацию), программа признаёт его лицензионным
• Ввод серийного номера. Основной уязвимостью является возможность беспрепятственного копирования и распространения дистрибутива вместе с серийным номером. Поэтому в настоящее время практически не используется (либо используется в совокупности с другими методами).
• Активация программного обеспечения. В отличие от предыдущего метода, активационный код генерируется с использованием уникальной информации (S/N оборудования, информации о пользователе) и является уникальным. В этом случае, в момент генерации кода активации в процессе установки программы есть риск эмуляции «универсального» аппаратного окружения (как то перехват обращений программы при считывании соответствующей информации, либо запуск программы изначально в виртуальной среде). Также, при неиспользовании запутывания кода защищённого приложения (или использовании слабых методов), злоумышленник может найти код генерации кода активации и вынести его в отдельную утилиту (т. н. «генератор ключей aka keygen»), ровно как и вырезать всю процедуру активации (что, однако, сложнее, так как он может вызываться в разных частях приложения)
• Использование электронных ключей. Часто встречается мнение о возможности эмуляции электронного ключа или библиотек интерфейса API, используемого при обращении к электронному ключу. Это действительно можно сделать при неграмотной реализации защиты на электронном ключе (к примеру, программа только проверяет наличие ключа и читает/пишет в него что-либо). Однако встроенные в программу защитные механизмы собственной разработки, основанные на вызове симметричных и асимметричных алгоритмов электронного ключа практически исключают возможность его эмуляции, так как обращения к ключу происходят каждый раз разные и накопить достаточное количество статистики для создания полного статистического аналога невозможно. Таким образом, стойкость защиты сильно зависит от реализации (в том числе от наличия уникальных защитных механизмов, реализованных разработчиком защиты). Тем не менее потенциально стойкость такой защиты может быть очень высока.
• «Отключение» защиты путём модификации программного кода (к примеру, удаления проверок лицензии). Может быть реализовано при неиспользовании (или использовании слабых) инструментов запутывания кода. В результате программа дизассемблируется (или даже декомпилируется, в худшем случае), код исследуется на наличие защитных механизмов, найденные проверки удаляются.

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

Использование автоматических средств защиты[править | править код]

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

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

Проблема «лучше, чем легальное»[править | править код]

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

• Незащищенная программа работает, в общем случае, быстрее, чем защищённая
• Для работы «взломанной» программы не нужен оригинальный носитель. Если не использовать компакт-дисков, время работы ноутбука существенно увеличивается. Кроме того на некоторых моделях ноутбуков устройство чтения компакт-дисков может отсутствовать вовсе
• При использовании USB-ключа может не хватить портов на всё нужное оборудование или не быть таковых вовсе (к примеру при использовании виртуализации)
• Электронный ключ может создавать физические неудобства при работе с защищённой программой на ноутбуке
• J2ME-программа исчезнет после перепрошивки телефона, и нет возможности сделать её резервную копию.

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

Требования к программному обеспечению — Википедия

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

Требования могут выражаться в виде текстовых утверждений и графических моделей.

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

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

• Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
• Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде сценариев использования (англ. use case), пользовательских историй (англ. user stories), сценариев взаимодействия (scenario).

• Функциональный характер — требования к поведению системы
  • Бизнес-требования
  • Пользовательские требования
  • Функциональные требования
• Нефункциональный характер — требования к характеру поведения системы
  • Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
  • Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным требованиям и ограничениям относятся:
    • Ограничения на программные интерфейсы, в том числе к внешним системам
    • Требования к атрибутам качества
    • Требования к применяемому оборудованию и ПО
  • Требования к документированию
  • Требования к дизайну и юзабилити
  • Требования к безопасности и надёжности
  • Требования к показателям назначения (производительность, устойчивость к сбоям и т. п.)
  • Требования к эксплуатации и персоналу
  • Прочие требования и ограничения (внешние воздействия, мобильность, автономность и т. п.).

• Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
• Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
• Текущая организация деятельности объекта автоматизации
• Модели деятельности (диаграммы бизнес-процессов)
• Представления и ожидания потребителей и пользователей системы
• Журналы использования существующих программно-аппаратных систем
• Конкурирующие программные продукты

Характеристики качества требований по-разному определены различными источниками. Однако, следующие характеристики являются общепризнанными^{[источник не указан 459 дней]}:

Характеристика	Объяснение
Единичность	Требование описывает одну и только одну вещь.
Завершённость	Требование полностью определено в одном месте и вся необходимая информация присутствует.
Последовательность	Требование не противоречит другим требованиям и полностью соответствует внешней документации.
Атомарность	Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершённости.
Отслеживаемость	Требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и документировано.
Актуальность	Требование не стало устаревшим с течением времени.
Выполнимость	Требование может быть реализовано в пределах проекта.
Недвусмысленность	Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.
Обязательность	Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования.
Проверяемость	Реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ.

• Интервью, опросы, анкетирование
• Мозговой штурм, семинар
• Наблюдение за производственной деятельностью, «фотографирование» рабочего дня
• Анализ нормативной документации
• Анализ моделей деятельности
• Анализ конкурентных продуктов
• Анализ статистики использования предыдущих версий системы

Все требования должны поддаваться проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).

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

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

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

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

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

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

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

Спецификацию программного обеспечения часто называют техническим заданием. Это ошибка. Спецификация требований является частью технического задания в случае создания автоматизированных информационных систем.^{[источник не указан 459 дней]}

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

Для графических моделей требований исторически использовались диаграммы или методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

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

• Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2.

Сопровождение программного обеспечения — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 13 марта 2013; проверки требуют 30 правок. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 13 марта 2013; проверки требуют 30 правок.

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

Сопровождение программного обеспечения стандартизовано, имеются национальные стандарты Российской Федерации, идентичные международным (ISO/IEC 12207:2008 System and software engineering — Software life cycle processes, ГОСТ Р ИСО/МЭК 12207-2010 «Национальный стандарт Российской Федерации. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»; ISO/IEC 14764:99 Information tehnology — Software maintenance, ГОСТ Р ИСО/МЭК 14764-2002 «Государственный стандарт Российской Федерации. Информационная технология. Сопровождение программных средств»; IEEE 1219).

Существуют две точки зрения на границы применимости термина «сопровождение ПО»:

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

Согласно ГОСТ 34.601-90 «Государственный стандарт Союза СССР. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» (переиздание — июнь 1997 года) стадия создания автоматизированной системы «сопровождение автоматизированной системы» включает два этапа работ: 1) «выполнение работ в соответствии с гарантийными обязательствами», 2)»послегарантийное обслуживание».

Имеются две разных точки зрения на границы применимости терминов «сопровождение ПО» и «поддержка ПО».

1. Эти два термина — синонимы.
2. Это два разных термина. Сопровождение ПО осуществляется сопроводителем. Сопроводителем может быть внешняя организация или же сама та организация (её отдел, отдельный сотрудник), которая использует ПО в своей работе. Поддержка осуществляется исключительно сотрудниками отдела той организации, которая использует ПО в своей работе (эта организация называется «заказчик» ISO/IEC 14764:99). Это менее квалифицированные специалисты, чем сопроводители, а потому они не выполняют полностью тех работ, которые предусмотрены ISO/IEC 14764:99. Например, сотрудники отдела поддержки не выполняют работы по обнаружению и корректировке скрытых ошибок для предотвращения явного проявления этих ошибок.

В модели водопада, называемой также «каскадная модель жизненного цикла» или «каскадная модель жизненного цикла с обратными связями» (см. Мезенцев К. Н. Автоматизированные информационные системы: учебник. М.: Издат. центр «Академия», 2013, с. 57-58), сопровождение ПО выделяется в отдельную фазу жизненного цикла.

В спиральной модели, возникшей в ходе развития объектно-ориентированного программирования, сопровождение не выделяется как отдельный этап. Тем не менее, эта деятельность занимает значительное место, учитывая тот факт, что обычно около 2/3 жизненного цикла программных систем занимает сопровождение. «Сопровождение программного средства может в стоимостном выражении составлять наибольшую часть жизненного цикла»(ISO/IEC 14764:99).

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

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

«Характеристики, описывающие качественные и количественные требования к сопровождаемости программного средства, устанавливает заказчик. В данных характеристиках должны быть установлены соответствующие критерии и способы их проверки… Разработчики должны реализовывать требования к сопровождаемости, а сопроводители должны контролировать их реализацию»(ISO/IEC 14764:99).

Структура ИТ-сопровождения.^{[источник не указан 1578 дней]}

Принято выделять несколько линий сопровождения (структура приведена на примере внешнего сопровождения ПО):

• 0 линия (call-center, информационный центр, горячая линия) — обработка телефонных обращений от клиентов, передача обращений техническим специалистам (1-я линия сопровождения)
• 1 линия (инженер по сопровождению, инженер технической поддержки, support engineer) — консультация/настройка/устранение ошибок в работе ПО/наполнение базы знаний, составление мануалов
• 2 линия (инженер по сопровождению, инженер технической поддержки, support engineer) — функциональное сопровождение/проектная деятельность на этапе запуска ПО на машинах заказчика
• 3 линия (инженер по сопровождению, инженер технической поддержки, support engineer) — системное сопровождение/проектная деятельность на этапе запуска ПО на оборудовании заказчика

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

Программное обеспечение — это… Что такое Программное обеспечение?

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

Програ́ммное обеспе́чение^[1][2] (допустимо также произношение обеспече́ние^[3][4][5]) (ПО) — все или часть программ, процедур, правил и соответствующей документации системы обработки информации (ISO/IEC 2382-1: 1993. Information technology — Vocabulary — Part 1: Fundamental terms)^[6][7].

Другие определения из международных и отечественных стандартов:

• Компьютерные программы, процедуры и, возможно, соответствующая документация и данные, относящиеся к функционированию компьютерной системы (FCD ISO/IEC 24765. Systems and Software Engineering Vocabulary)^[6].
• Совокупность программ системы обработки информации и программных документов^[8], необходимых для эксплуатации этих программ (ГОСТ 19781-90^[9]).

Программное обеспечение является одним из видов обеспечения вычислительной системы, наряду с техническим (аппаратным), математическим, информационным, лингвистическим, организационным и методическим обеспечением^[10].

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

В компьютерном сленге часто используется слово софт от английского слова software, которое в этом смысле впервые применил в статье в American Mathematical Monthly математик из Принстонского университета Джон Тьюки (англ. John W. Tukey) в 1958 году^[11].

История

Первая теория, касающаяся программного обеспечения, была предложена английским математиком Аланом Тьюрингом в 1935 году в эссе «Computable numbers with an application to the Entscheidungsproblem (Decision problem)»^[12]. Он создал так называемую машину Тьюринга, математическую модель абстрактной машины, способной выполнять последовательности рудиментарных операций, которые переводят машину из одного фиксированного состояния в другое. Главная идея заключалась в математическом доказательстве факта, что любое наперёд заданное состояние системы может быть всегда достигнуто последовательным выполнением конечного набора элементарных команд (программы) из фиксированного набора команд.

Классификация ПО

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

Документация

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

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

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

См. также

Примечания

1. ↑ Ожегов С. И. Словарь русского языка. — М.: Русский язык, 1986. — С. 364.
2. ↑ Акцентологический словарь
3. ↑ Словари русского языка — Проверка слова «обеспечение» Грамота.ру
4. ↑ Издание орфографического словаря Ожегова 2007 года приводит единственный вариант — обеспече́ние. // Орфографический словарь русского языка / Под редакцией С. И. Ожегова. Локид-Пресс, 2007. 912 с. ISBN 5-320-00396-X.
5. ↑ Издание словаря Розенталя 2006 и 2007 года тоже приводит единственный вариант — обеспече́ние // Д. Э. Розенталь. Русский язык. Справочник-практикум. Оникс, Мир и образование, 2007. ISBN 5-488-00712-1, 5-94666-332-1, 978-5-488-01360-5.
6. ↑ ^{1 2} Батоврин В. К., 2012
7. ↑ Система обработки информации — одна или большее число компьютерных систем и устройств, таких как офисное и коммуникационное оборудование, которые выполняют обработку информации //Стандарт ISO/IEC 2382-1
8. ↑ Согласно ГОСТ 19.101-77 К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
9. ↑ Вычислительная техника. Терминология: Справочное пособие. Выпуск 1 / Рецензент канд. техн. наук Ю. П. Селиванов. — М.: Издательство стандартов, 1989. — 168 с. — 55 000 экз. — ISBN 5-7050-0155-X
10. ↑ Липаев В. В. Проектирование программных средств. Учебное пособие — М.: Высшая школа. 302 с. ISBN 5-06-001570-X
11. ↑ John Tukey, 85, Statistician; Coined the Word ‘Software’, Obituaries, New York Times (July 28, 2000).
12. ↑ Hally Mike Electronic brains/Stories from the dawn of the computer age. — London: British Broadcasting Corporation and Granta Books, 2005. — P. 79. — ISBN 1-86207-663-4
13. ↑ ^{1 2} ГОСТ Р ИСО/МЭК 15910-2002 — Процесс создания документации пользователя программного средства
14. ↑ ГОСТ 19781—90 Единая система программной документации. Обеспечение систем обработки информации программное

Литература

• Брауде Э. Технология разработки программного обеспечения. — СПб.: Питер, 2004.
• Брукс Ф. Мифический человеко-месяц или как создаются программные системы. — СПб.: Символ-Плюс, 1999.
• Гагарина Л. Г., Кокорева Е. В., Виснадул Б. Д. Технология разработки программного обеспечения. — М.: ИД «ФОРУМ»; ИНФРА-М, 2008. — ISBN 978-5-8199-0342-1
• Орлов С. А. Технологии разработки программного обеспечения. — СПб.: Питер, 2003.
• Батоврин В. К. Толковый словарь по системной и программной инженерии. — М.: ДМК Пресс, 2012. — С. 280. — ISBN 978-5-94074-818-2

Процесс разработки программного обеспечения — Википедия

Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО)^{[источник не указан 1063 дня]}.

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

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

Водопадная (каскадная, последовательная) модель[править | править код]

Водопадная модель жизненного цикла (англ. waterfall model) была описана Уинстоном Ройсом в статье «Managing the Development of Large Software Systems» в 1970 г. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.

Преимущества:

• Полная и согласованная документация на каждом этапе;
• Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы^[1]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем^[2].

Итерационная модель[править | править код]

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью^[3].

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и того же смысла разными словами со слегка разных точек зрения^[2].

По выражению Т. Гилба, «эволюция — приём, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»^[3].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно висит ощущение, что «всё равно всё можно будет переделать и улучшить позже»^[2].

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

Спиральная модель[править | править код]

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

• риск превышения сроков и стоимости проекта;
• необходимость выполнения ещё одной итерации;
• степень полноты и точности понимания требований к системе;
• целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID^[2].

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

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек^[4]:

1. Concept of Operations (COO) — концепция (использования) системы;
2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

1. ↑ Брукс Ф. Мифический человеко-месяц или как создаются программные системы : пер. с англ. / Ф. Брукс. — Санкт-Петербург : Символ-Плюс, 1999. — 304 с.: ил.
2. ↑ ^{1 2 3 4} Мирошниченко Е. А. Технологии программирования: учебное пособие / Е. А. Мирошниченко. — 2-е изд., испр. и доп. — Томск: Изд-во Томского политехнического университета, 2008. — 128 с.
3. ↑ ^{1 2} Ларман К. Итеративная и инкрементальная разработка: краткая история / К. Ларман, В. Базили // Открытые системы. — 2003.— N 9.
4. ↑ Орлик С. Введение в программную инженерию и управление жизненным циклом ПО. [1]

Программное обеспечение — это… Что такое Программное обеспечение?

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

Програ́ммное обеспе́чение^[1][2] (допустимо также произношение обеспече́ние^[3][4][5]) (ПО) — все или часть программ, процедур, правил и соответствующей документации системы обработки информации (ISO/IEC 2382-1: 1993. Information technology — Vocabulary — Part 1: Fundamental terms)^[6][7].

Другие определения из международных и отечественных стандартов:

• Компьютерные программы, процедуры и, возможно, соответствующая документация и данные, относящиеся к функционированию компьютерной системы (FCD ISO/IEC 24765. Systems and Software Engineering Vocabulary)^[6].
• Совокупность программ системы обработки информации и программных документов^[8], необходимых для эксплуатации этих программ (ГОСТ 19781-90^[9]).

Программное обеспечение является одним из видов обеспечения вычислительной системы, наряду с техническим (аппаратным), математическим, информационным, лингвистическим, организационным и методическим обеспечением^[10].

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

В компьютерном сленге часто используется слово софт от английского слова software, которое в этом смысле впервые применил в статье в American Mathematical Monthly математик из Принстонского университета Джон Тьюки (англ. John W. Tukey) в 1958 году^[11].

История

Первая теория, касающаяся программного обеспечения, была предложена английским математиком Аланом Тьюрингом в 1935 году в эссе «Computable numbers with an application to the Entscheidungsproblem (Decision problem)»^[12]. Он создал так называемую машину Тьюринга, математическую модель абстрактной машины, способной выполнять последовательности рудиментарных операций, которые переводят машину из одного фиксированного состояния в другое. Главная идея заключалась в математическом доказательстве факта, что любое наперёд заданное состояние системы может быть всегда достигнуто последовательным выполнением конечного набора элементарных команд (программы) из фиксированного набора команд.

Классификация ПО

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

Документация

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

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

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

См. также

Примечания

1. ↑ Ожегов С. И. Словарь русского языка. — М.: Русский язык, 1986. — С. 364.
2. ↑ Акцентологический словарь
3. ↑ Словари русского языка — Проверка слова «обеспечение» Грамота.ру
4. ↑ Издание орфографического словаря Ожегова 2007 года приводит единственный вариант — обеспече́ние. // Орфографический словарь русского языка / Под редакцией С. И. Ожегова. Локид-Пресс, 2007. 912 с. ISBN 5-320-00396-X.
5. ↑ Издание словаря Розенталя 2006 и 2007 года тоже приводит единственный вариант — обеспече́ние // Д. Э. Розенталь. Русский язык. Справочник-практикум. Оникс, Мир и образование, 2007. ISBN 5-488-00712-1, 5-94666-332-1, 978-5-488-01360-5.
6. ↑ ^{1 2} Батоврин В. К., 2012
7. ↑ Система обработки информации — одна или большее число компьютерных систем и устройств, таких как офисное и коммуникационное оборудование, которые выполняют обработку информации //Стандарт ISO/IEC 2382-1
8. ↑ Согласно ГОСТ 19.101-77 К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
9. ↑ Вычислительная техника. Терминология: Справочное пособие. Выпуск 1 / Рецензент канд. техн. наук Ю. П. Селиванов. — М.: Издательство стандартов, 1989. — 168 с. — 55 000 экз. — ISBN 5-7050-0155-X
10. ↑ Липаев В. В. Проектирование программных средств. Учебное пособие — М.: Высшая школа. 302 с. ISBN 5-06-001570-X
11. ↑ John Tukey, 85, Statistician; Coined the Word ‘Software’, Obituaries, New York Times (July 28, 2000).
12. ↑ Hally Mike Electronic brains/Stories from the dawn of the computer age. — London: British Broadcasting Corporation and Granta Books, 2005. — P. 79. — ISBN 1-86207-663-4
13. ↑ ^{1 2} ГОСТ Р ИСО/МЭК 15910-2002 — Процесс создания документации пользователя программного средства
14. ↑ ГОСТ 19781—90 Единая система программной документации. Обеспечение систем обработки информации программное

Литература

• Брауде Э. Технология разработки программного обеспечения. — СПб.: Питер, 2004.
• Брукс Ф. Мифический человеко-месяц или как создаются программные системы. — СПб.: Символ-Плюс, 1999.
• Гагарина Л. Г., Кокорева Е. В., Виснадул Б. Д. Технология разработки программного обеспечения. — М.: ИД «ФОРУМ»; ИНФРА-М, 2008. — ISBN 978-5-8199-0342-1
• Орлов С. А. Технологии разработки программного обеспечения. — СПб.: Питер, 2003.
• Батоврин В. К. Толковый словарь по системной и программной инженерии. — М.: ДМК Пресс, 2012. — С. 280. — ISBN 978-5-94074-818-2

Документация на программное обеспечение — Википедия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ↑ ^{1 2} ГОСТ Р ИСО/МЭК 15910-2002 — Процесс создания документации пользователя программного средства
2. ↑ ГОСТ 19781—90 Единая система программной документации. Обеспечение систем обработки информации программное

О документации на программное обеспечение