ЕСПД... Ау...
В технических заданиях на разработку программ, нормах к их сертификации государственными органами или в пожеланиях заказчиков еще встречаются требования о соответствии программной документации (ПД) стандартам ЕСПД (Единая система программной документации), но в коммерческих продуктах нет никаких упоминаний о стандартах серии 19 (ЕСПД). Чтобы объяснить этот факт, нам потребуется сравнить советский и американский подход к проектированию ПО и разработке документации для программ.
Два мира - две методологии
Идеология определяет хозяйственные отношения в обществе. В СССР мы все вместе шли к общей цели, не задумываясь о взаиморасчетах между собой. В обществе капиталистическом люди нацелены на собственные, личные цели, что в целом также должно приводить к некоторому общему прогрессу. Именно этим коренным отличием объясняются особенности методологии разработки ПО в капиталистическом и социалистическом обществе:
1. ЕСПД предполагает каскадную модель процесса разработки: группа сторонних программистов пишет основную версию, затем заказчику передается код программы (согласно ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению), который далее поддерживается местным программистом (по ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению и ГОСТ 19.504-79 ЕСПД. Руководство программиста). Американская модель предписывает цикличность - за выпуском коммерческой версии снова следует техническое задание на разработку новой версии. Потребитель не имеет прав на модификацию программного кода, должность программиста не предусмотрена, код программы является коммерческой тайной и программа остается "черным ящиком".
2. ЕСПД предполагает стороннюю разработку с передачей заказчику всех авторских прав, коммерческое программирование - продажу товара, который применяется потребителем без каких-либо изменений. Поэтому основным описательным документом в коммерческом программировании является User Guide (Руководство пользователя), которому в ЕСПД соответствует Руководство оператора (ГОСТ 19.505-79 ЕСПД), хотя новый стандарт "ГОСТ Р ИСО 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов", по крайней мере, реабилитирует само понятие руководства пользователя. Кстати, в документации на бытовые приборы сегодня отсутствуют принципиальные электрические схемы, которые в СССР были обязательными для такой документации.
3. Более чем почтенный возраст ЕСПД объясняет полное отсутствие каких-либо упоминаний о стандартных средствах современных программных продуктов: Quick Start Guide (краткое руководство по установке и началу работы), Administrator Guide (руководство системного администратора - для офисных программ), справочной системе (Help в формате CHM), работе с лицензиями и (или) исправлениями и (или) обновлениями, обращению в службу технической поддержки (вместо этого мы имеем ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению), документации в электронной форме (обычно в формате PDF) и т.д.
4. ЕСПД не предполагает никакой рекламной, маркетинговой или презентационной документации, но сегодня успешные продажи тиражных программных продуктов невозможны без демонстрационных версий с ограничением на срок использования, рекламных публикаций, презентаций в электронной форме и т.д.
5. Основным руководящим документом англоязычного технического писателя является Style Guide (руководство по стилю), определяющее "что и как писать" в справочной документации ПО, а не "как оформлять текстовое описание" (ЕСПД). Это наиболее важное отличие в двух методологиях, которое называется usability (удобство, полезность, пригодность документации). Например, мы пишем справочную систему для приложения Windows. Русскую версию этой операционной системы изучают в школах на уроках информатики, она априори установлена на компьютере потенциального пользователя нашей программы, компания Microsoft имеет специальный исследовательский центр, изучающий usability программных продуктов, - так почему же в документации и справочной системе нашей программы не использовать формулировки, структуру, принципы оформления и т.д., которые десятилетиями проверены на миллионах пользователей? Непрофессионализм российских справочных систем, возможно, объясняется тем фактом, что, по моим личным наблюдениям, только каждый пятый отечественный технический писатель имеет профильное компьютерное образование (хотя любая компания для разработки кода нанимает только профессиональных программистов).
Примечание: если вам не нравится Microsoft, посмотрите документацию компании Apple, которая лидирует в реализации нетривиальных методов для пользовательских интерфейсов. Например, именно эта компания придумала сохранять на КПК снимок экрана при выходе из программы, а затем выводить его при последующем запуске. Пользователю кажется, что программа стартовала мгновенно, но на самом деле он видит только "старые" данные в виде рисунка. Обычно пользователю необходимо две-три секунды на просмотр выведенного изображения, после чего он готов к действиям в интерфейсе. За это время завершается реальный старт программы и данные в интерфейсе обновляются. Проявление этого метода можно наблюдать после зарядки выключенного КПК - на индикаторе зарядки сначала отображается низкий уровень, который через пару секунд мгновенно меняется на высокий, реальный уровень зарядки. Пользователь не видит никаких "песочных часов", "вращающихся кругов" и прочих раздражающих значков, поэтому полностью удовлетворен работой ПО. Аплодисменты компании Apple за прекрасное инженерное решение!
Заключение
Итак, заголовок "ЕСПД... Ау..." вполне можно заменить фразой "Good by, ЕСПД", поскольку стандарты ЕСПД уже давно стали рекомендательными, а не обязательными для исполнения требованиями. А в качестве практических советов можно предложить, как минимум, включать в комплект документации коммерческого ПО руководство Quick Start Guide (одна печатная страничка на плотной бумаге), а для офисных пакетов - дополнительно Administrator Guide.
|
