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

Размышления в стиле ретро

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

Рис. 1. Схема изготовления комплекта документации на ПО для АСУ

При подготовке документации первый выдавал на нее задание, второй разрабатывал, а третий проверял возможность использования при эксплуатации ПО. Все это обязательно отражалось в составе документации и других ее особенностях. Комплекты ТД и ЭД являлись составными частями общей документации на систему. Кроме того, ПО, как правило, передавалось для эксплуатации системы в виде кодов программ, которые включались в состав документации в виде специальных компонентов — текстов программ или таблиц кодов, а также инструкций по работе с ними. Весьма существенно влияло на качество разработки и длительность жизненного цикла ПО проведение испытаний всей системы с одновременной проверкой пригодности ЭД к условиям эксплуатации. Это, конечно, было учтено в системе стандартов, в том числе в ГОСТах. Так, единые стандарты программной и технической документации (ЕСПД и ЕСТД соответственно) были обязательны и удобны для всех участников триады, поскольку обеспечивали универсальный подход к разработке и эксплуатации АСУ и других систем.

Что нового в облике твоем?..

Если повнимательнее приглядеться к суете на рынке ПО, то легко можно заметить, что там доминирует представление о документировании ПО, продвигаемое корпорацией Microsoft. Оно уже не вписывается в схему, представленную на рис. 1. Включение в упомянутую выше триаду менеджера вполне оправданно, но вот противопоставление его вместе с заказчиком и разработчиком пользователю явно не на пользу последнему (рис. 2). Это привело к тому, что один компонент документации на ПО стал заботой лишь самого производителя, а оставшуюся часть назвали ТД, но теперь под этим обозначением стали понимать совсем другое. Так что же сейчас обозначается как ТД?

Рис. 2. Нынешняя схема изготовления документации на программный продукт

В настоящее время комплект ТД практически не привязан к решаемым задачам, т. е. к условиям конкретной эксплуатации. Не стоит искать там рекомендаций, как поступать пользователю в конкретных случаях, за исключением упоминания о том, что с ними всегда можно справиться. Свой вывод я обосновываю следующим: разработчикам документации, в частности из Рэдмонда, не всегда понятно, что именно наиболее важно, скажем, для представителей российского малого бизнеса. Кроме того, обычно ни о каких результатах тестирования продукта и соответствующей корректировке купленной пользователем документации нигде не сообщается, разве что иногда упоминается что-нибудь в Internet. Ведь процесс доработки ТД скрытый, «внутригрупповой» (у производителя), и потому обычно нет сроков обязательного уведомления пользователя о ее завершении и результатах. Маркетинг также оказывает определенное влияние на сроки выпуска документации, а это непременно отразится на ее качестве. Еще одним недостатком современного подхода к изготовлению ТД можно считать то, что она весьма слабо связана с условиями эксплуатации, и при продажах продуктов менеджерам, как правило, приходится предлагать пользователю уповать на различного рода дополнительное обучение или рекомендовать получать недостающую информацию в Internet.

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

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

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

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

Одну из наиболее интересных попыток стандартизовать разработку документации на ПО предприняла фирма «Философт», выпустившая «Руководство для разработки технической документации к программному обеспечению». Такой подход был выработан ею в результате самостоятельного выпуска комплекта ТД для компании Cognitive Technologies. Преимущество данного подхода в том, что разработчик документации может учесть внутрикорпоративные ограничения (в частности, фирмы «Философт»), опирающиеся на «типовые» требования к составу ТД, куда включены руководства и справочники, составляемые с учетом ГОСТов, стандартов корпорации Microsoft, собственного опыта сотрудников своей компании, а также других организаций. Причем в этом случае можно обеспечить возможность контроля качества документации, который, следуя упомянутому руководству, зависит, кроме всего прочего, от законов построения текста, психологии его восприятия и практики работы пользователя. Разумеется, в процессе работы над ТД учитываются рекомендации международной организации по стандартизации ISO 9000. Унификация приемов и методик работы приводит к возникновению корпоративных стандартов, помогающих осуществлять контроль, выявлять ошибки и несоответствия, а также регламентировать весь процесс подготовки документации. Такие методики подходят для любых групп участников проекта при подготовке ТД.

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

Другие интересные примеры подготовки документации на программный продукт можно найти у фирм «1С» и TopS. Их ПО имеет достаточно сложную структуру и предназначено для управления предприятием или сложным бизнес-процессом. Так, система программ «1С:Предприятие» состоит из самостоятельных частей: «1С:Бухгалтерия», «1С:Торговля и Склад» и «1С:Зарплата и Кадры», причем в схеме взаимосвязи разработчика документации и пользователя различаются собственно пользователи и специалисты или продвинутые пользователи, способные на самостоятельные шаги. И это обстоятельство не только сказывается на составе предлагаемой документации на продукт, но и определяет его использование для готовых решений или в качестве гибкого средства, приспосабливаемого к условиям эксплуатации системы в целом. Полный комплект такой ТД на продукт включает 13 дискет с программами и 8 книг. Там приведены описания типовой конфигурации, содержащей сведения по переходу с предыдущей версии программы «1С:Бухгалтерия», конфигурирование и администрирование, описание встроенного языка и руководства по установке и запуску программ, ведению учета и бухгалтерский учет для пользователя. Чтобы поддержать эксплуатационные усилия пользователей, фирма «1С» выпускает специальный продукт «Информационно-технологическое сопровождение «1С:Предприятие» (ИТС) на компакт-диске с информацией по следующим трем разделам: технология работы с программами, методология и практика ведения бухучета и правовые аспекты предпринимательства, бухучета и налогообложения (последний раздел формируется компанией «Гарант-Сервис»).

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

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

Итак, ясно, что отношения разработчиков программных продуктов к документации и для ниши коробочного ПО, и для корпоративных систем пока далеки от промышленных стандартов, но примеры комплектов документов для продуктов фирм «1С» и TopS говорят об определенных позитивных сдвигах в этом направлении. Появление же руководства от фирмы «Философт» следует рассматривать как приглашение к обсуждению (или использованию) таких промышленных стандартов де-факто.

Пророчества

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

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

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

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

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

686