Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2010-10-24 03:20    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

Разработка полезного ТЗ по ГОСТ 34.602

Введение
Почему ГОСТ?
Почему ТЗ - ключевой документ
Автоматизированная система
Виды обеспечения
Стадии создания АС
ТЗ по ГОСТ 34.602
   Общие сведения
   Назначение и цели создания (развития) системы
   Характеристики объекта автоматизации
   Как пишутся требования в ТЗ
   Требования к системе в целом
      Требования к структуре и функционированию
      Персонал
      НФТ
   Требование к функциям (задачам)
   Требования к видам обеспечения
   Работы по созданию, контролю и приемке, подготовке объекта автоматизации
   Требования к документированию
В итоге

Введение  ^

Этот текст висит в разработке со 2 января 2008 года. Я знаю, что некоторые из моих читателей давно хотели его прочитать, но, вероятно, уже не ждут эту статью.

И все же долги надо отдавать. Я отчаялся написать исчерпывающий текст, так как тема ТЗ по ГОСТ 34.602 требует объяснения идеологии системы ГОСТов серии 34 и 19, а они, сами по себе основны на всем богатстве российской инженерной школы в ее лучшем проявлении. В итоге, тема бездонна и мне остается только пытаться дать определенный (свой) взгляд.

Пока я чесался, были написаны и опубликованы замечательные статьи по теме ГОСТов серий 19 и 34. Вот лучшие из встреченных мной:
Влад Балин. ГОСТ-овский стиль управления
Серия статей Михаила Острогорского:
Зачем нужны ГОСТ 19 и ГОСТ 34
Автоматизированная система с точки зрения ГОСТ 34.
Автоматизированная система с точки зрения ГОСТ 34. Продолжение
A Ghost of the GOST

Сами стандарты и связанные материалы можно найти здесь или воспользовавшись поисковиком.

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

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

Не секрет, что ГОСТ часто используют у нас при работе с государственным заказчиком. Государственный заказчик - это госзакупки, очень часто связанные с освоением бюджета. В таких проектах действует тезис: "по пальцу на миллион", где "палец" - это единица толщины написанной и сданной заказчику пачки бумаги. В таких проектах очень часто возникают методологические споры (с заказчиком или внутри рабочей группы) о том, что, как и куда писать. И именно оттуда задается очень много вопросов о том, "как правильно" использовать ГОСТ серии 34.

На этот вопрос - "как правильно", я отвечу в первую очередь. В проектах, которые я описал чуть выше, нечему учиться и нечего делать.

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

В итоге я предлагаю не читать дальше тем, кто хочет знать, что "правильно", а что нет.

Я предлагаю в этой статье взглянуть на ГОСТ серии 34, с двух сторон:
- как на отличный контрольный список, с помощью которого можно обеспечить выполнение всех работ, "выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям" (как указано в ГОСТ 34.601 п1.1).
- как на исчерпывающий шаблон контракта на создание АС между исполнителем и заказчиком.

Я повторю, так как это важно:

ГОСТ серии 34 содержит ИСЧЕРПЫВАЮЩИЕ контрольные списки, позволяющие нам успешно построить автоматизированную систему.

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

По этому в первой части статьи мы обсудим модель автоматизированной системы (АС), как представлено в ГОСТ, а во второй части перейдем к ключевому документу - техническому заданию. А перед эти обсудим роль ТЗ в процессе создания АС.

Почему ГОСТ?  ^

Но сначала последнее отступление: чем же все-таки хорош ГОСТ серии 34, который перестал обновляться 20 лет назад и чем он лучше чем методологии западного образца, доступные нам сегодня?

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

2. ГОСТ серии 34 в отличие от методологий проектного управления рассматривает предпроектные стадии и говорит, что должно быть выполнено до начала проекта по построению АС - как сформировать его цели.

3. ГОСТ серии 34 в отличие от процессных и бизнес-аналитических методологий рассматривает информационную технологию и средства автоматизации достаточно подробно.

4. ГОСТ серии 34 не диктует, как выполнять работы - он говорит, что надо сделать и какие решения надо принять, по этому он может быть состыкован с любыми методологиями: проектными, процессными, методологиями программной инженерии и т.п.

В итоге ГОСТ серии 34 более ориентирован на конечный результат: построение работающих автоматизированных систем.

Для интегратора, внедряющего программное обеспечение ГОСТ серии 34 дает отличную возможность планировать проект, ничего не упуская. Для заказчика - это отличная возможность получить ПО, приносящее пользу, а не стоящее на полке.

Почему ТЗ - ключевой документ  ^

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

Проекту ПОЛЕЗНО иметь ключевой контракт, выраженный в документальной форме

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

Перечисленные вопросы обычно находят свое отражение в уставе проекта.

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

С точки зрения ГОСТ 34.602 ТЗ - это ключевой контракт проекта, в котором исполнитель договоривается с заказчиком о целях, границах системы и проекта, а так же о работах, которые предстоит выполнить.

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

Так, как это важно, я повторю сказанное и отвечу на вопрос, заданный в названии статьи:

ТЗ по ГОСТ 34.602 будет полезным, когда оно пишется, как ключевой технический контракт проекта - приложение №1 к договору на оказание услуг или, как часть плана проекта при внутренней разработке и внедрении.

Чтобы более точно понять суть ТЗ, разберем назначение основных разделов.

Общие сведения - как ни странно - это не просто учетная карточка с именами и реквизитами заказчика и исполнителя, а практически полноценная преамбула договора на создание АС, так что иногда даже кажется, что называть раздел надо было "общие положения" (это единствтвенная не совсем техническа часть ТЗ).

Назначение и цели создания (развития) системы - в этом разделе устанавливаются измеримые критерии успеха проекта. В ГОСТ серии 34 рассматривается только проект по созданию АС, по этому целью проекта всегда будет достижение автоматизируемой деятельностью установленных показателей, а задачами - сама автоматизация деятельности в достаточном для достижения показателей объеме.

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

Требования к системе - задание границ системы и требований как к системе в целом, так и к отдельным компонентам.

Состав и содержание работ по созданию системы - границы работ (укрупненное деление) и разделение ответственности за выполнение.

Порядок контроля и приемки системы - укрупненный план передачи результатов заказчику.

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

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

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

При этом есть и ошибочные толкования текста стандарта, которые появились в разное время в угоду специфическим интересам в конкретной ситуации и не имеют никакого отношения к самому стандарту. Вот самые распространенные из них:
1. ГОСТ серии 34 диктует водопадный цикл разработки - это не правда. ГОСТ ориентирован на итерационный цикл разработки, ничто не запрещает даже работу над несколькими очередями параллельно. Говорят, что подобные мифы распространяют внедренцы крупных западных систем (типа SAP или OEBS), так как у подобных систем есть собственные фирменные методологии внедрения со своими наборами артефактов и ролевой раскладкой. Естественно, подгонять свои шаблоны под ГОСТ, как минимум, накладно.
2. ГОСТ не приспособлен к работе с незафиксированными границами системы (что не редкость при применении гибких методологий). Это не совсем так: ГОСТ склоняется к постановке измеримых бизнес-целей и при внедрении крупных человеко-машинных систем для групповой работы по другому нельзя. При этом механизм версионности документов и деление ТЗ на частные технические задания вполне "законный" механизм наращивания границ и работы с не до конца определенными границами.
3. ГОСТ требует слишком много документации. Дело в том, что в стандарте описаны ВСЕ решения, которые надо принять для успеха проекта. Документировать их или нет решают заказчик и исполнитель. Частой ошибкой является написание крупных монолитных документов "точно как написано в ГОСТ" без деления на части, привязанные к разным участкам объема результата, а так же нежелание выкидывать избыточные, в данном случае, документы.

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

Автоматизированная система  ^

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

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

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

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

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

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

Согласно определению из ГОСТ 34.003 Автоматизированная Система (АС) - это система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Там же определено, что функция АС - это совокупность действий АС, направленная на достижение определенной цели.

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

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

В составе информационной технологии находятся алгоритмы.

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

Удобно выделить 2 слоя в которых определяется АС:
- цели и деятельность, в которой функции выполняются по определенной информационной технологии
- система на физическом уровне, состоящая из персонала и комплекса средств автоматизиции и осуществляющая деятельность.

Функции и действия АС выделяются по достигаемым целям/результатам и реализуют информационную технологию. Так как речь идет об информации, то функции АС достаточно легко разделить на самые простые классы:
- ввод (получение) информации
- переработка
- вывод
- хранение
- транспортировка

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

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

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

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

На физическом уровне АС имеет структуру, показанную на рисунке:

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

В составе комплекса средств автоматизации информация отделяется от средств автоматизации, которые далее делятся на аппаратные компоненты и программные средства.

Информация делится на два класса: предназначенная для машины (машинная информационная база) и для человека (внемашинная информационная база).

Виды обеспечения  ^

Для понимания идеологии ГОСТ серии 34 необходимо разобраться в понятии "вид обеспечения" и связанных с ним понятиях.

Предполагается, что "сборка" (а на самом деле - ввод в действие) АС производится на основе двух вещей:
- комплектующие изделия,
- проектные решения: технические, методические и организационные.

Комплектующие изделия так же собираются на основе более мелких комплектующих изделий и проектных решений.

И то и другое являтся "обеспечением" АС.



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

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

Для ввода в действие АС необходимо позаботиться о наличии обеспечения: все проектные решения приняты, все комплектующие компоненты разработаны или куплены. На картинке выше пунктирными стрелками показано влияние видов обеспечения друг на друга и на части АС.

Стадии создания АС  ^

ГОСТ 34.601 устанавливает стадии создания АС и виды работ, которые можно выполнять на данной стадии.

Стадии разбиваются на этапы - это куски работ, имеющие результат, видимый для заказчика.

АС может вводиться в действие очередями. Очередь характеризуется сроком ввода и набором реализуемых функций.

Стадии и очереди ортогональны, то есть в рамках ввода каждой очереди АС могут выполняться все (или часть) предписанных ГОСТом стадий.

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

Вот стадии создания АС с разбивкой по фазам из проектных методологий:
Предпроект:
1. Формирование требований к АС
2. Разработка концепции АС.
Планирование
3. Техническое задание.
Принятие проектных решений (проектирование/создание технических спецификаций)
4. Эскизный проект.
5. Технический проект.
Разработка самописного ПО, кастомизация и документация
6. Рабочая документация.
Комплектация и развертывание АС
7. Ввод в действие.
Эксплуатация и поддержка
8. Сопровождение АС

Предпроектные стадии заказчиваются проработкой концепции АС, что делает возможным оценить объемы работы с точностью, достаточной для планирования и запуска проекта (сегодня это где-то +-50%).

На стадии "Техническое задание" разрабатывается одноименный документ, который в современных проектных методологиях соответствует ключевым разделам плана проекта. Техническое задание, согласно ГОСТ 34.602, является основным документом (ключевым контрактом проекта), на основании зафиксированных там решений производится дальнейшая разработка и ввод в действие АС.

ТЗ по ГОСТ 34.602  ^

Переписывать стандарт здесь нет смысла. По этому я предлагаю читателю по необходимости обращаться к тексту ГОСТ 34.602. А в этом разделе будут приведены комментарии по ходу написания ТЗ.

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

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

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

Общие сведения  ^

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

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

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

Мои тезисы выше про "индикатор" и "дело нечисто" помещены в статью для аналитиков, на долю которых выпадает написание ТЗ по ГОСТ 34.602. Я поясняю, какая информация должна быть подготовлена до написания ТЗ, чтобы еще раз снять массу вопросов "что и куда писать". Если иНформация есть, остается расположить ее в разделах. Если информации нет, задавать вопросы "что писать" бесполезно.

А конкретно, до написания ТЗ должны быть:
- обследование и документ, отражающий потребности заказчика;
- выбор исполнителя, обследование силами исполнителя и концептуальный документ с просчитаными стоимостью, сроками и этапностью создания АС, не говоря уже об измеримых целях, описании ситуации у заказчика и других деталях;
- задокументированная отмашка заказчика "давайте писать договор".

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

Если этого всего нет - спрашивать "что писать" бесполезно.

Назначение и цели создания (развития) системы  ^

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

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

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

Характеристики объекта автоматизации  ^

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

Что же все-таки здесь писать?

Первый вариант - здесь может быть показана связь между объектами автоматизации и приведена схема деятельности, показывающая, как автоматизация на участках деятельности позволяет добиться целевых значений показателей, установленных в предыдущем разделе ТЗ. При большей детализации эта схема превращается в описание бизнес-процессов. Можно так же добавить доменную модель, отражающую ключевые сущности и связи между ними. Если описание становится слишком большим, его рекомендуется выносить в приложение или другие документы (это все может быть в отчете об обследовании с предыдущей стадии или в концепции).

Второй вариант - здесь надо привести опись текущего состояния деятельности, информации и технических средств заказчика с целью в дальнейшем составить план "расчистки площадки", то есть подготовки оьбъекта автоматизации к вводу АС в эксплуатацию. Я имею ввиду такие пункты, как состояние имеющейся вычислительной техники, каналов связи, сети, наличие серверов, уровень подготовки пользователей, режим их работы и т.п.

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

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

Как пишутся требования в ТЗ  ^

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

ТЗ - это ключевой контракт (и план) проекта по созданию АС. В этом контракте 2 стороны: заказчик и исполнитель, каждый из которых берет на себя определенные обязательства. Так же у нас есть предмет договора - работы по построению АС и сама АС.

Исполнитель выполняет создание АС при том, что заказчик обеспечивает для этого все необходимое. Таким образом, когда мы формулируем требования к АС мы можем указывать не только "система должна", но и "заказчик обеспечивает", "исполнитель обеспечивает". Это, пожалуй, самое важное отличие ТЗ от функциональных спецификаций из метдологий программной инженерии.

Кроме описанных выше требований необходимо учесть еще и то, что требования могут накладываться на работы по построению АС и на отдельные компоненты АС.

При записи требования можно не только указывать конкретные формулировки, но и определять, что это требование не указано заказчиком или должно/может быть сформулировано/уточнено.

Таким образом мы имеем несколько возможных шаблонов формулировок, вот некоторые:
- Система (должна) ТРЕБОВАНИЕ
- Заказчик обеспечивает ТРЕБОВАНИЕ
- Исполнитель обеспечивает ТРЕБОВАНИЕ
- Компонент ХХХ должен ТРЕБОВАНИЕ
- Работа ХХХ должна ТРЕБОВАНИЕ
- Требование не предъявляется (на усмотрение исполнителя)
- ... требование должно быть сформулировано и согласовано с заказчиком на этапе ХХХ
- ... требование может/должно быть уточнено на этапе ХХХ по согласованию с заказчиком.

В качестве примера можно привести формулирование требований к численности и квалификации первонала.

Персонал системы выполняет следующие роли: пользователь, оператор участка сканирования, администратор НСИ, администратор сети и БД.

Система должна сохранять нормальное функционирование при численности пользователей не более 2000 человек при режиме работы 8 часов 5 дней в неделю (все пользователи в одном часовом поясе);

Заказчик обеспечивает наличие 5 операторов участка сканирования с продолжительностью рабочей недели - 40 часов;

Заказчик обеспечивает наличие администратора сети и БД с продолжительностью рабочей недели - 40 часов;

Заказчик обеспечивает вложение трудовых ресурсов администраторов НСИ на 10 часов в неделю.

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

Операторы участка сканирования и администраторы НСИ должны пройти обучение и аттестацию длительностью 16 аудиторных часов силами и на территории исполнителя.

Администратор сети и БД должен знать и уметь ...(квалификационные требования)...

И еще момент: не так страшно что-то написать не в тот раздел, чем не указать в контракте существенные условия. По этому важно записать все условия, при которых достигается построение работающей АС и защита интересов обеих сторон: заказчика и исполнителя. Потом уже можно перекидывать требования из раздела в раздел. По этому любые попытки сторон при согласовании ТЗ выкинуть требвание по тому, что "это не тот раздел", надо встречать обязательным вопросом "куда переносим" и пока не получится ответ, не торопиться с удалением.

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

Требования к системе в целом  ^

Как уже было сказано, здесь задаются границы системы, которую мы строим.

В этом разделе можно выделить три части:
- требования к структуре и функционированию системы - концептуальная архитектура системы;
- требования к численности и квалификации персонала системы и режиму его работы;
- все остальное - нефункциональные требования.

Требования к структуре и функционированию  ^

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

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

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

Персонал  ^

Требования к персоналу АС имеют две стороны:
- пользователи АС, получающие результаты работы АС - это первичная потребность, продиктованная схемой деятельности заказчика и целями создания системы;
- пользователи, обеспечивающие ввод необходимых данных и эксплуатационный персонал - это вторичная потребность, продиктованная устройством системы.

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

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

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

НФТ  ^

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

Требование к функциям (задачам)  ^

В этом разделе каждая функциональная подсистема детализируется до функций. ГОСТ предусматривает 2 аспекта рассмотрения функций, которые не надо путать между собой:
- план реализации;
- спецификация функций.

С точки зрения плана мы указываем распределение функций по очередям, а так же ключевые даты реализации функций. Например, даты выхода из тестирования у исполнителя, даты приемочных испытаний у заказчика, даты ввода в опытную и промышленную эксплуатацию.

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

Требования к видам обеспечения  ^

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

Переписывать ГОСТ нет смысла, по этому я укажу лишь некоторые акценты.

В первую очередь ТЗ - это план. И в разделе по видам обеспечения должны быть отражены списки комплектующих компонентов АС и списки проектных решений, которые необходимо принять. Данный раздел задает большую часть объема ПРОМЕЖУТОЧНЫХ результатов проекта, разрабатываемых и покупных. Здесь же предьявляются и требования к этим результатам.

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

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

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

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

Математическое обеспечение - описание, ссылки на алгоритмы функционировния АС или указания о необходимости их создания.

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

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

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

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

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

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

Работы по созданию, контролю и приемке, подготовке объекта автоматизации  ^

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

Порядок контроля и приемки системы - ключевые моменты, описывающие приемочные испытания АС.

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

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

Требования к документированию  ^

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

В разделе с требованиями к документированию мы перечисляем состав и требования к обеим группам документов.

Комплектующие документы АС, в целом, ясны - они являются частью объема результата в дополнение к разделам "требования к системе в целом" и "требования к видам обеспечения".

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

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

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

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

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

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

В итоге  ^

Как мы выяснили - ТЗ по ГОСТ 34.602 - это ключевой контракт проекта - техническая часть устава и плана.

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

Если ТЗ не пишется, как документ, текст стандарта можно использовать в качестве контрольного списка при планировании проекта - это даст возможность ничего не забыть из важных видов работ и проектных решений.

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

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

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