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