Зачем нужны ГОСТ 19 и ГОСТ 34

В нашей стране госты серий 19 и 34 часто применяются при создании программ и автоматизированных систем, особенно, когда в качестве заказчиков выступают государственные или крупные коммерческие организации. Стандарты эти таковы, что руководители проектов и разработчики технической документации, сталкиваясь с ними впервые, обычно приходят в замешательство. Отчасти это связано с объемом стандартов и своеобразием употребляемой в них терминологии, но в первую очередь наверно все-таки с тем, что начинающие не видят смысла в стандартизированной технической документации. У них складывается впечатление, что госты — бюрократическое наследие Советского Союза, по недоразумению продолжающее отравлять нам жизнь. Задача предлагаемой статьи в том, чтобы очертить область действия 19-х и 34-х гостов и объяснить, для чего они нужны. Содержания гостов мы здесь касаться не будем, поскольку ему следовало бы посвятить отдельную статью и не одну.

Программы и автоматизированные системы

Бывают программы, а бывают автоматизированные системы. Еще бывают аппаратно-программные комплексы и много разных других видов продукции, но пока мы их для простоты оставим в покое. Под программой обычно подразумевают машинный код (часто еще добавляют, представленный в объективной форме), который может быть выполнен компьютером. Если вы на языке PHP написали скрипт, формирующий страничку с надписью «Слава труду!», то вы произвели на свет программу. Вы можете поместить эту программу в подходящие условия, например, на компьютер, где уже функционируют интерпретатор PHP и какой-нибудь HTTP-сервер, и она будет работать. Если к тому же вы допускаете применение этого скрипта более-менее широким кругом лиц и обеспечили им такую возможность, то получился программный продукт. Теперь представим себе, что Министерство труда и занятости решило в целях повышения трудолюбия населения страны создать сайт, на главной странице которого при загрузке отображается какой-нибудь полезный лозунг. Для этого оно делает следующее: выделяет в здании министерства кабинет; ставит в этот кабинет компьютер и подключает его к Интернету; устанавливает на этот компьютер HTTP-сервер Apache, интерпретатор PHP и ваш скрипт; вменяет в обязанность кому-нибудь из сотрудников раз в неделю менять текст лозунга.

В результате этой работы возникает автоматизированная система. Что она в себя включает? Прежде всего, мы наблюдаем целенаправленную автоматизированную деятельность, в данном случае пропагандистскую работу. Осуществляет ее назначенный для этого персонал, пускай даже в количестве одного человека. Наконец, у системы есть технические средства (компьютер) и программное обеспечение (операционная система, интерпретатор PHP, HTTP-сервер Apache и скрипт).

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

Участники разработки

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

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

Типы и функции технической документации

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

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

Стандартизация документации разработки

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

Пример 1. Если в утвержденном техническом задании (ТЗ) на автоматизированную систему сказано, что посетитель сайта должен видеть лозунг «Слава труду», заказчик не имеет права вдруг потребовать еще и демонстрации рекламного ролика на эту тему. Вполне возможно, что показывать ролик — неплохая идея, но заказчику следовало высказать ее раньше, когда разработчик согласовывал с ним техническое задание. С другой стороны, если вместо положенного текста система будет выдавать рекламу ночного клуба, у заказчика появятся все основания потребовать от разработчика внесения в систему необходимых изменений, и не платить ему денег, пока система не будет приведена в соответствие техническому заданию. Пример 2. Если в утвержденном техническом проекте зафиксировано, что для реализации автоматизированной системы используется скрипт на PHP , разработчик не имеет права огорошить заказчика предложением вместо бесплатного интерпретатора этого языка приобрести Lotos Domino. Но, с другой стороны, и заказчик не может потребовать от разработчика вместо нормального сервера использовать компьютер БК 0010, завалявшийся в кладовке с советских времен. Бюрократически правильное ведение технической документации заставляет всех участников разработки вести себя предсказуемо по отношению друг к другу, что конечном счете, всем выгодно, несмотря на дополнительные затраты. Ведение технической документации позволяет предотвратить многие недоразумения и злоупотребления. В том случае, если заказчик и разработчик так испортят отношения, что дело дойдет до арбитража, техническая документация будет служить для ущемленной стороны средством доказать свою правоту. Без технической документации вероятность и болезненность всевозможных склок и «разборок» сильно повышается.

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

Стандартизация документации продукции

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

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