ГОСТ 34-й серии для сисадминов, начинающих фрилансеров и всех заинтересованных (часть 4)

Данная статья является продолжением моих статей (Часть 1, Часть 2, Часть 3) о применении ГОСТов 34й серии. Сегодня мы поговорим о таком важном и, не побоюсь этого слова, ключевом моменте в создании автоматизированной системы как Техническое задание.

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

Начнем с общих положений.

Техническое задание настолько важный документ, что имеет свой собственный ГОСТ 34.602-89. В первом же пункте этого ГОСТа в общих положениях мы читаем следующее «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие». Что следует из этих строчек? А следует из них то, что ТЗ покрывает весь проект. От разработки до ввода в действие. А ввод в действие, как мы помним из ГОСТа 34.601-90 (стадии создания АС), предпоследняя стадия в создании АС с точки зрения ГОСТа и последняя с человеческой точки зрения, т.к. гарантийное обслуживание и сопровождение происходят тогда, когда все деньги от заказчика получены, и вся работа ему уже сдана. Поэтому создание правильного ТЗ очень важная стадия и ГОСТ 34.602-89 проведет нас по нужному маршруту, напомнив о важном.

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

— общее ТЗ на создание АС «почтовая система на базе Exchange» (обязательно)
— частное ТЗ на создание части АС «Exchange» (опционально)
— частное ТЗ на создание части АС «Кластер» (опционально)

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

Интересный пункт 1.4 из общих положений. Он гласит «Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений.» Что тут важного? Нам, как разработчикам АС дается понять, что разрабатывать АС надо на современных платформах. Как это применить на практике? Давайте поразмышляем. Нам, например, по проекту надо создать маршрутизатор. Хорошо ли в качестве платформы для него использовать древний Рentium 1? Сомнительно. Оно, как говорится, хоть и валяется, но если выйдет из строя, какой либо компонент, что будем делать? Где искать замену? Хорошо, если у нас есть на что менять. А если нет? Поэтому ГОСТ настаивает на современном уровне. И второе, что разработчик не должен быть ограничен в поиске наиболее эффективных путей реализации. Т.е., например, если заказчик имеет локальную сеть, Active Directory и хочет получить функционал MS Exchange, то ТЗ не должно требовать создание АС с функционалом Exchange, т.к. он уже есть и по ряду причин (экономических, временных и т.д.) разработка аналогичного функционала будет бессмысленна. Тем не менее, именно с этим я периодически сталкиваюсь в своей работе проектировщика. ГОСТ писали, я повторюсь, очень неглупые люди. Каждый пункт наполнен смыслом.

Согласно пункту 1.5 общих положений ТЗ создается на основе стадий создания АС «Исследование и обоснование создания АС». Вот почему эти две стадии так важны и почему я обращал на них столь пристальное внимание в первой части. Ошибка на этих стадиях приведет к ошибкам в последующих. И если предположить, что вы обнаружите ошибку (например, вы проигнорировали стадию исследования), например, на стадии «Рабочий проект», то посмотрите, какой пласт проектной работы вам придется переделывать. Огромный!

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

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

Теперь более конкретно. Часть вторая «состав и содержание ТЗ»

Как и ГОСТ на стадии создания АС, ГОСТ на ТЗ являет нам иерархическую структуру разделов этого документа. Приведу рисунок

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

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

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

Требования к системе. Один из самых больших разделов ТЗ. ГОСТ предлагает нам заполнить три подраздела:

• требования к системе в целом;
• требования к функциям (задачам), выполняемым системой;
• требования к видам обеспечения;

Тут отражается все, что необходимо для проекта. Опять же, сохраняется направление от общего к частному.

Требования:
В целом — что должна выполнять система вообще. Процитирую ГОСТ:

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

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

Требования к функциям (задачам), выполняемым системой – более подробно расписываются требования к подсистемам АС. Т.е. более детализировано описывается (сохраняется механизм от общего к частному) требование к тому, что делает система. Например, в общих требованиях у нас указано, что ведется аудит безопасности. А тут мы указываем, что при возникновении события идет оповещение администратора и СБ почтовым сообщением. И т.п.

Требования к видам обеспечения – что нужно, чтобы все было, как говорится. Тут можно процитировать из ГОСТа «В подразделе “Требования к видам обеспечения” в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.» Другими словами, тут мы отражаем что надо, чтобы все работало. Какое «железо», какой «софт», какие ресурсы нужны со стороны заказчика, а какие – со стороны исполнителя, какого уровня должен быть персонал и т.п. Как верно отражено в цитате, в зависимости от вида системы. Тут все индивидуально. Этот пункт важен тем, чтобы не сложилось ситуации, когда мы, например, собрались внедрять Exchange и вдруг выяснили (на стадии «Ввод в действие», как оно обычно бывает), что у заказчика нет Active Directory.
Следующий раздел… так и хочется сказать «очень важный» Но они все очень важные, если подумать (смайлик). Итак, следующий раздел – «Состав и содержание работ; по созданию (развитию) системы». В составе и содержании работ мы отражаем стадии, с которыми мы познакомились в ГОСТе 34.601-90 «Стадии создания АС». Тут мы указываем, когда какие стадии будут выполняться, кто их будет выполнять (исполнитель или субподрядчик), приводим доказательства готовности субподрядчика (если есть необходимость). Еще указываем, какие документы по окончании и на каких стадиях и этапах будут готовы. Указываем вид и порядок. Можно следовать ГОСТ 34.201, но стоит ли?

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

Следующий раздел – «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие». Понятное дело, что для начала внедрения АС объект автоматизации должен быть подготовлен. Например, если мы мигрируем с Exchange 5.5 на Exchange 2003, то на Exchange 5.5 должны быть проведены некоторые работы, как, например, принятие решения что делать с почтовыми ящиками в ситуации, когда один аккаунт пользователя является владельцем нескольких почтовых ящиков. Такая вольность в 2003 уже не пройдет. Тут же мы пишем о всем прочем, что требуется от объекта автоматизации, что в ГОСТе отражено следующей цитатой «изменения, которые необходимо осуществить в объекте автоматизации; создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;». Например, если у заказчика нет штатного администратора, то к началу внедрения он должен быть запланирован.

Следующий раздел – «Требования к документированию». Тут все просто. Какие документы будут в проекте, описываем тут. Можем взять ГОСТ 34.201 и по стадиям-этапам посмотреть, что может потребоваться и зачем. Все что нужно и будет использовано – прописываем тут. Т.е. есть документ «методика проведения испытаний»? Зафиксировали. Есть акты передачи? Так же зафиксировали.

И последний раздел – «Источники разработки». Тут мы можем приводить ссылки на различные базы знаний и документы бест практикс, из которых мы черпали основания для разработки ТЗ. Например, заказчик может задать вопрос «на кой вы добавили в ТЗ требование о двух контроллерах домена» в пустом рутовом домене во многодоменной инфраструктуре. И вы приводите требование безопасности Microsoft по созданию многодоменных схем.

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

Автор: sudden_buben