Помощь Юриста

Особенности составления технического задания на выполнение подрядных работ

Pin
Send
Share
Send
Send


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

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

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

Правила оформления техзадания к договору подряда

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

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

С чего начать?

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

Казалось бы, все просто. Однако на практике возникает много нюансов, и на них следует обращать пристальное внимание. Рассмотрим на примере, как именно результаты проверок трансформируются в техническое задание. Предположим, что после визита представителя противопожарной службы руководитель АУ получил следующие предписания:

  1. Заменить аварийную электропроводку в помещении N 312.
  2. Дооборудовать средствами пожаротушения (дополнительным огнетушителем) пост N 2 на втором этаже.
  3. Заменить глухие металлические решетки на окнах в кабинетах N N 101 - 120 на открывающиеся. Оборудовать специализированный пост для хранения ключей от них.
  4. Расширить дверной проем аварийного выхода на втором и третьем этажах до 1200 мм.
  5. Согласовать в противопожарной службе план эвакуации с третьего этажа.
  6. Заменить электрические выключатели в кабинетах N N 118, 119, 207, 314.
  7. Очистить от посторонних предметов лестничный пролет между вторым и третьим этажами для доступа к запасному выходу.
  8. На третьем этаже заменить электрические автоматы (электрические предохранители), установить устройство защитного отключения.

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

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

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

  1. Замена электропроводки - 100 м кабеля на освещение, 50 м на подключение розеток и выключателей. Общая максимальная мощность осветительных приборов составляет 760 Вт, общая максимальная мощность источников - потребителей электроэнергии равна 5 кВт.
  2. Штробление стен - 15 пог. м.
  3. Укладка кабеля в штробы с дальнейшей заделкой их материалом на основе гипсовых смесей - 15 пог. м.
  4. Шпаклевка, ошкуривание, грунтовка, финишная отделка - 15 пог. м.
  5. Замена розеток, выключателей (в случае необходимости) - 10 шт.

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

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

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

Техническое задание по данному пункту будет выглядеть следующим образом:

  1. Демонтаж решеток глухих 80 кв. м - 20 шт.
  2. Монтаж решеток открывающихся (составных из двух элементов) 80 кв. м - 20 шт.
  3. Демонтаж, монтаж наружных отливов (сандриков) - 40 пог. м.
  4. Штукатурка наружных откосов - 80 пог. м.
  5. Шпаклевка, грунтовка, окраска наружных откосов - 80 пог. м.

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

  1. Демонтаж дверей второго и третьего этажей - 3,2 кв. м.
  2. Расширение дверных проемов аварийного выхода на втором и третьем этажах с 800 до 1200 мм.
  3. Вывоз строительного мусора.
  4. Монтаж распашных дверей - 4,8 кв. м.
  5. Монтаж дверной окладки - 10,4 пог. м.
  6. Установка дверной фурнитуры (замков, петель, ручек, защелок) - 2 комплекта.
  7. Ремонт наружных откосов (шпаклевка, грунтовка, окраска) - 10,4 пог. м.

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

Структура технического задания

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

  1. Общие положения технического задания.

1.1. Объект расположен по адресу: г. Москва, пр. Андропова, д. 24, кор. 3.

1.2. Объект представляет собой пять раздельных помещений общей площадью 217 (двести семнадцать) кв. м. Кабинет N 101 - 97 кв. м, кабинет N 102 - 80 кв. м, техническое помещение N 103 - 10 кв. м, женский туалет - 15 кв. м., мужской туалет - 15 кв. м.

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

1.4. При разработке методов строительства и выборе материалов, используемых в настоящем проекте, необходимо учитывать климатические условия, характерные для города Москвы.

1.5. Требования к проектированию и производству работ определяются следующими документами:

  • настоящим техническим заданием,
  • инструкциями санитарно-эпидемиологических служб, санитарными нормами и правилами,
  • строительными нормами и правилами, действующими на территории Российской Федерации,
  • требованиями и нормами пожарной безопасности НПБ 110-99.

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

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

2.1. В кабинетах N N 101, 102 смонтировать пластиковые окна - 8 шт. (общей площадью 32 кв. м). Окна должны иметь трехкамерные стеклопакеты с защитной пленкой и поворотно-откидную систему открывания. В туалетах смонтировать пластиковые окна - 2 шт. (общей площадью 8 кв. м). Они должны иметь двухкамерные стеклопакеты с защитной пленкой и поворотную систему открывания.

2.2. Перегородки помещений и кабинетов выполнить из гипсокартона толщиной 12 мм с изоляционным слоем на металлическом каркасе.

2.3. На все скрытые работы представить акты скрытых работ.

2.4. В техническом помещении реставрировать оконные рамы, выходящие на обратную сторону фасада, применить высококачественную покраску и заменить фурнитуру.

2.5. Установить с внутренней стороны оконных проемов раздвижные решетки с замками - общей площадью 32 кв. м (помещения N N 101, 102).

2.6. Смонтировать плинтусы, порожки, защитные уголки на углы стен (места установки согласовать с заказчиком).

2.7. Смонтировать пластиковые двери (2 шт.) общей площадью 4 кв. м (помещения N N 101, 102).

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

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

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

3.1. Произвести подготовку электропитания к местам установки фасадной вывески автономного учреждения и заменить электропроводку наружного освещения.

3.2. Подвести кабели для установки кондиционеров в помещениях N N 101, 102.

3.3. Слаботочные системы.

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

Следующий раздел посвящен непосредственно отделке.

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

4.1. Полы выполняются из керамического гранита (мужской и женский санитарные узлы) - 30 кв. м и коммерческого линолеума (кабинеты N N 101, 102, техническое помещение) - 187 кв. м. Цветовую гамму напольных покрытий, а также места расположения порожков, стыков линолеума, плиточного бордюра необходимо дополнительно согласовать с заказчиком.

В кабинетах N N 101, 102 устанавливаются потолки с применением комбинированных материалов в разных уровнях ("Армстронг" + гипсокартон), комбинированного освещения (энергосберегающие люминесцентные + люминесцентные светильники) в соответствии с отдельно разработанным дизайн-проектом потолков помещений N N 101 и 102.

В техническом помещении устанавливаются подвесные потолки "Армстронг" с люминесцентными светильниками мощностью 18 Вт согласно нормам освещенности, высота фальшпотолка - 2 м 70 см.

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

4.3.1. Для отделки стен помещений N N 101 и 102 применить гипсокартонные листы на металлическом каркасе с утеплением и оклеить флизелиновыми обоями с последующей покраской высококачественными моющимися красками светлых оттенков (цветовую гамму согласовать с заказчиком).

4.3.2. Стены технического помещения оштукатурить и окрасить.

4.3.3. Стены санузлов выложить керамической плиткой (цветовую гамму согласовать с заказчиком).

4.3.4. Плинтусы устанавливать в соответствии с колером и материалом пола.

4.3.5. Изготовить декоративные экраны с теплообменными решетками на радиаторы отопления в помещениях N N 101, 102. Все элементы центрального отопления должны быть обслуживаемыми.

4.3.6. Произвести ревизию систем отопления и канализации. В случае необходимости заменить проблемные участки.

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

4.4. Сантехнические работы.

В санитарных узлах заменить раковины (4 шт.), смесители (4 шт.). Также заменить подводящие шланги, установить унитазы (4 шт.), писсуары (2 шт.), биде (1 шт.). План расположения сантехники согласовать с заказчиком.

4.5.1. Материал и степень огнестойкости всех дверей должны соответствовать действующим противопожарным нормам.

4.5.2. Входные двери в кабинеты N N 101 и 102 заменить на пластиковые.

4.5.3. Двери в санузлы заменить на деревянные, покрашенные в белый цвет.

4.5.4. На все двери установить упоры (ограничители хода двери), на путях эвакуации установить доводчики.

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

  1. Внутреннее инженерное оборудование.

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

5.1. Отопление, вентиляция и кондиционирование.

5.1.1. Система отопления - существующая.

5.1.2. Смонтировать в кабинетах N 101 и 102 систему кондиционирования воздуха (сплит-системы) для обеспечения температуры в пределах 20 - 22 град. Цельсия в летнее время года.

5.1.3. Запроектировать и смонтировать автономную вытяжку из санузлов.

5.2. Электротехническая часть.

Необходимо запроектировать электроснабжение в соответствии с требованиями СНиП РФ. Напряжение сети - 380/220 В с глухозаземленной нейтралью.

5.2.1. Электропитание компьютеров должно быть выполнено от одной фазы.

Провода распределительной сети должны иметь следующую расцветку: PE - желто-зеленый, N - синий, голубой, фазы A, B, C - любой цвет, кроме вышеуказанных.

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

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

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

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

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

Освещенность всех рабочих мест в кабинетах N N 101, 102 должна составлять не менее 400 люкс. Освещенность технического помещения и санитарных узлов регламентируется из расчета не менее 100 люкс.

В кабинетах N 101 и 102 применить энергосберегающие светильники с зеркальными отражателями (2 x 26 w) и точечные светильники (количество и тип должны соответствовать разработанному дизайн-проекту).

5.3. Силовые сети.

5.3.1. Разводка электрической проводки по комнатам осуществляется в скрыто прокладываемых пластмассовых трубках в стенах или в пластиковом коробе по каналу, предназначенному для силовых сетей. Канал для силовых сетей отделяется от канала для слаботочных сетей перегородкой.

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

5.3.3. Все электрические кабели со стороны шкафов должны быть промаркированы надписями: тип провода, длина до самой дальней розетки, номер линии или ее наименование. Маркировка должна быть выполнена с помощью:

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

5.3.4. Установить на каждое рабочее место три розетки для питания компьютеров и две розетки для другого оборудования. Всего установить 21 компьютерную и 14 универсальных розеток. В местах, где электрические розетки устанавливаются не в электротехнический короб, помимо силовых розеток, на каждом рабочем месте установить по две коробки для монтажа компьютерных розеток. Также установить закладные в стенах в виде пластиковых труб с затянутой в них стальной проволокой от рабочего места до запотолочного пространства или ближайшей магистрали компьютерной или телефонной сети.

5.4. Система пожаротушения.

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

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

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

1. О чем статья

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

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

Кстати, ТЗ — это не первый документ, который разрабатывается в ходе проекта автоматизации. Об этом прямо говорится в пункте 1.5. ГОСТ 34.602-89: «ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии “Исследование и обоснование создания АС”». Подробнее см. в моей статье Предпроектное обследования при разработке информационной системы.

ВНИМАНИЕ: ЦЕЛЬ ЭТОЙ СТАТЬИ — НЕ ЗАМЕНИТЬ ГОСТ, А РАЗЪЯСНИТЬ НЕКОТОРЫЕ ЕГО ПОЛОЖЕНИЯ.

Цель и исходные данные

Для реализации потребностей по договору подряда обе стороны согласуют исходные данные:

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

Требования заказчика

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

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

2.1. По какому стандарту составляется ТЗ?

Полное наименование стандарта на ТЗ по ГОСТ 34 следующее: ГОСТ 34.602-89 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

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

Действительно, в стандарте используется много непонятных терминов. Что, например, имеется в виду под лингвистическим обеспечением? Для прояснения использующихся понятий следует обратиться к ГОСТ 34.003-90 «Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения».

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

Чтобы подрядчик мог выполнять работы согласно ТЗ, согласуются условия для качественного исполнения этапов договора:

  • сроки начала и окончания работ,
  • предоплата, аванс, этапы финансирования,
  • предоставление жилья для командируемых сотрудников (при наличии такого пункта в договоре между сторонами).

2.3. Какую роль Техническое задание занимает в проекте?

Согласно пункту 1.7 стандарта РД 50-682-89, «техническое задание является основным документом, в соответствии с которым проводят создание АС и приемку его заказчиком». И это действительно главный документ. В нем должно описываться все, что необходимо для разработки и внедрения системы.

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

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

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

2.4. Насколько ГОСТ 34.602-89 устарел и есть ли более новые стандарты?

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

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

  • IEEE 830-1998. Методика составления спецификаций требований к программному обеспечению.
  • ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.
  • ISO/IEC/IEEE 29148-2011. Systems and software engineering — Life cycle processes — Requirements engineering.
  • ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом.
  • Ну и ГОСТы серии 34.

3.1. Какой специалист должен составлять Техническое задание по ГОСТ 34?

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

Техническое задание должен составлять бизнес-аналитик, потому что он является «переводчиком» между заказчиком и командой разработки. Задача бизнес-аналитика — разобраться в том, что нужно заказчику и выразить это так, чтобы было понятно команде. И выразить это в виде технического задания. Причем от бизнес-аналитика требуется не просто выслушать заказчика и его сотрудников, а узнать то, о чем они не сказали (а такого обычно более 50%). Поэтому аналитик должен хорошо знать автоматизируемые процессы и за счет своего знания заполнять пробелы, которые остались по результатам обследования.

Технико-экономическое

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

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

3.2. Какая сторона должна составлять Техническое задание?

В основном Техническое задание составляется исполнителем? Почему?

Не только потому что так рекомендуется в Приложении 1 к ГОСТ 34-602-89. На самом деле, у заказчика, как правило, отсутствуют соответствующие специалисты. Но ТЗ в обязательном порядке прорабатывается и согласовывается заказчиком. И вот здесь нужно обязательно добиться того, чтобы согласование не было формальным. Я всегда стараюсь настоять на том, чтобы мы вместе с заказчиком подробно разобрали каждый пункт. Ваша цель — вовлечь заказчика в проект. Иначе он так и не сформирует свои ожидания от системы, а значит, во-первых, будет недоволен любым результатом, а, во-вторых, не сможет провести необходимые организационные мероприятия.

3.3. Насколько далеко можно отходить от ГОСТ 34?

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

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

Не верите? Тогда читайте пункт 2.2 ГОСТ 34.602-89 (кстати, цифры после дефиса — год публикации стандарта или его редакции): «В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ». Также в п. 1.2. РД 34.698-90 указано: «Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы».

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

3.4. Зачем в ТЗ по ГОСТ 34 описывается так много требований, напрямую не относящихся к функциям системы?

Действительно, в ТЗ из 30-и страниц может только 7-10 страниц быть посвящено функциям. У этого есть объяснение. Дело в том, что разработчики ГОСТ 34 совершенно по-другому смотрели на проект автоматизации, чем мы. И смотрели более правильно, более комплексно.

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

Во-вторых, составители ГОСТ 34 видели систему в первую очередь как людей, а затем уже как программно-аппаратный комплекс. Вот как ГОСТ 34.003-90 определяет автоматизированную систему: «Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций». Таким образом, информационная система — это обученный персонал, программное обеспечение и аппаратный комплекс, все вместе. И правда, отбери у бухгалтеров компьютеры, они с трудом, но смогут выполнять свою работу, пусть и с бумажными реестрами. А вот 1С без бухгалтера самостоятельно работать не будет. Отсюда и множество разделов ТЗ, посвященных организационным мерам. Как говорят, ИТ-система на 20% — это ИТ, все остальное — организационные мероприятия. То есть ТЗ — это документ, в котором прописывается все необходимое для внедрения системы, от А до Я.

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

В-четвертых, ТЗ представляет собой документ, по которому можно ставить галочки: приняли мы во внимание данное требование или нет. Может, вы поставите 10 галочек чисто автоматически, потому что это будут стандартные решения. Но галочка номер 11 выявит очень большую проблему, и если эту проблему сейчас пропустить, то она всплывет где-то в процессе внедрения, когда уже определены все сроки и бюджеты.

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

Этапы проведения

Сроки начала и завершения этапов оговариваются при составлении техзадания. Их согласуют перед подписанием договора.

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

3.5. Зачем в разных разделах говорится об одном и том же?

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

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

Приложения

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

В качестве приложений могут быть:

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

3.6. Нужно ли качественно оформлять ТЗ?

Хотя требования к оформлению ТЗ приводятся в пункте 3 ГОСТ 34.602-89, скажем несколько слов о данном аспекте.

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

Приведем несколько пожеланий к оформлению больших документов, как ТЗ.

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

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

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

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

Заметим, что, по строгим правилам, ТЗ оформляется без рамки (об этом сказано в п. 3), а вот остальные документы — с рамкой. Это установлено в ГОСТ 24.301-80 «Система технической документации на АСУ. Общие требования к выполнению текстовых документов (с Изменениями № 1, 2)». Данный стандарт устанавливает правила оформления всех документов, кроме ТЗ и документов, создаваемых на предпроектных стадиях. Хотя лично мне рамка не нравится ни в каких документах.

4. Раздел 1. «Общие сведения» /п. 2.3 ГОСТ 34.602-89/

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

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

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

5. Раздел 2. «Назначение и цели создания (развития) системы» /п. 2.4 ГОСТ 34.602-89/

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

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

С целью все по-другому. Цель — это ради чего мы затеваем проект. Можно назвать это бизнес-целями. Я выделяю следующие возможные цели проектов автоматизации:

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

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

6. Раздел 3. «Характеристики объекта автоматизации» /п. 2.5 ГОСТ 34.602-89/

Очень важный, и при этом часто описываемый часто формально раздел. Хотя, на мой взгляд, это самый важный раздел ТЗ, без него мы просто не понимаем, о чем вообще создаваемая система.

Давайте сначала определим, что такое «объект автоматизации». Если мы автоматизируем склад или завод, отдел бухгалтерии, то все понятно. А если, например, создаем новую социальную сеть, то объекта как бы и нет. Но на самом деле, под объектом скорее имеются в виду автоматизируемые процессы. И даже в случае со складом мы же автоматизируем не сам склад (как можно автоматизировать хранение коробок?), а складские процессы.

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

В данном разделе следует приводить:

  1. Описание заказчика: виды деятельности заказчика, количество филиалов, сотрудников. Конечно, характеризовать заказчика нужно в той части, которая непосредственно касается создаваемой системы.
  2. Сведения о пользователях системы: виды пользователей, какую роль играет система для разных пользователей.
  3. Описание автоматизируемых объектов. Например, если мы автоматизируем склад, до должны описать, какой он площади, сколько проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная зона сборки, сколько работает человек и какие у них обязанности. Тогда мы поймем, что конкретно автоматизируем, как должен выглядеть складской процесс, и какое оборудование используется.
  4. Описание автоматизируемых процессов. Конечно, не стоит в ТЗ расписывать процессы подробно. Но привести общие сценарии — обязательно. Только тогда нам становится ясно, какие должны иметься функции.
  5. Перечень документов, в которых приводится подробное описание объекта автоматизации.

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

7. Раздел 4 «Требования к системе»

В ТЗ по ГОСТ 34 имеется один гигантский раздел: раздел 4 «Требования к системе». В нем имеется три подраздела:

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

Эти подразделы мы рассмотрим по отдельности.

7.1. Подраздел 4.1. «Требования к системе в целом» /п. 2.6.1 ГОСТ 34.602-89/

В подразделе 4.1 «Требования к системе в целом» приводят так называемые нефункциональные, общие, требования, которые описывают создаваемую систему с разных сторон.

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

7.1.1. Пункт 4.1.1. «Требования к структуре и функционированию системы» /п. 2.6.1.1 ГОСТ 34.602-89/

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

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

В данном пункте я обычно привожу:

  • схему внутренней структуры (сервер приложения, модуль хранения данных, толстый клиент в виде нативного приложения, публичное веб-приложение, панель администрирования, мобильные приложения, сервер отчетов) и внешних, смежных систем (другие системы заказчика, почтовый сервер SMTP, сервис SMS-рассылки, банк-эквайер, онлайн-касса, картографический сервис, адресный сервис, сервис проверки адресов электронной почты и т.п.),
  • требования к элементам приведенной структуры.

Если вы планируете микросервисную архитектуру, то имеет смысл перечень и описание функциональности сервисов.

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

2. Требования к способам и средствам связи для информационного обмена между компонентами системы.

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

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

  • перечень передаваемых сведений, хотя бы общее описание, чтобы вообще понять, зачем мы интегрируемся с конкретной системой,
  • описание протоколов (или ссылки на описание), особенно в случае присоединения устройств,
  • структура локальных сетей,
  • требуемая скорость передачи данных,
  • применение мобильного интернета или WiFi,
  • описание неавтоматизированных способов передачи данных.

4. Требования к режимам функционирования системы.
Режимы функционирования могут иметь несколько классификаций:

  • по готовности к эксплуатации: штатный режим, аварийный режим, режим технического обслуживания (например, в аварийном режиме должна присутствовать заставка на сайте, нагрузка переводиться на другой сервер, выводиться особые сообщения при обращении к данной системе по API, в режиме технического обслуживания некоторые функции могут быть доступны),
  • по готовности к эксплуатации частей системы: как должна функционировать система, если, например, недоступен один из внешних или внутренних сервисов,
  • по графику работы: 24/7 или пятидневка (от этого зависит как минимум работа технической поддержки),
  • по возможности изменения данных: режим просмотра или редактирования,
  • по уровню доступа к данным и операциям системы: режим авторизованного пользователя, режим администратора, гостевой режим (для неавторизованных пользователей),
  • по средству доступа к системе: через веб-приложение, через толстый клиент, через мобильное приложение (согласитесь, что функциональность может несколько отличаться, эти ограничения можно описать здесь),
  • по виду взаимодействия: диалоговый (через интерфейс), взаимодействие посредством изменения настроек в конфигурационных файлах или иным способом, неавтоматизированный (например, информация передается другому сотруднику, который вносит данные в систему, производится ручной съем показаний),
  • по степени автоматизации: автоматический или полуавтоматический режим, «режим советчика»,
  • по видимости приложения: диалоговый или фоновый режим,
  • по возможному воздействию на систему: штатный, обучающий, тестовый режимы.

5. Требования по диагностированию системы.

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

6. Перспективы развития, модернизации системы.

Кажется, какое отношение имеют перспективы развития системы к подразделу «Требования к структуре и функционированию системы»? Но представьте, сейчас вы создаете альфа-версию, рассчитанную на 100 человек, а через год хотите получить уже более миллиона одновременно работающих пользователей в разных частях света. Тогда вам на стадии создания сразу потребуется предусмотреть кластерную архитектуру.

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

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

7.1.2. Пункт 4.1.2. «Требования к численности и квалификации персонала» /п. 2.6.1.2 ГОСТ 34.602-89/

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

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

Понятно, что требования к персоналу часто устанавливаются заказчиком, зачем их тогда приводить? Но, во-первых, мы уже говорили, что ТЗ составляется для обеих сторон, а во-вторых, так исполнитель будет защищен: не выполнено условие по подбору персонала, чего же тогда заказчик хочет, если система не внедрена?

7.1.3. Пункт 4.1.3. «Требования к показателям назначения» /п. 2.6.1.3 ГОСТ 34.602-89/

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

Тем не менее, в самом тексте «показатели назначения» определяются как «параметры, характеризующие степень соответствия системы ее назначению». В современных компьютерных системах количественные значения, характеризующие эту систему, в основном относятся к производительности и объему хранения данных.

К показателям назначения можно отнести:

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

Все эти характеристики влияют на выбор серверного оборудования, архитектуры сервера приложения и СУБД, реляционной или нереляционной СУБД, микросервисов и т.д.

7.1.4. Пункт 4.1.4. «Требования к надежности» /п. 2.6.1.4 ГОСТ 34.602-89/

В тексте ГОСТа достаточно подробно описывается, что необходимо указывать в требованиях к надежности. Тем не менее, для понимания подхода к обеспечению надежности, заложенного в данном стандарте, следует изучить ГОСТы серии 27. Для начала стоит ознакомиться с терминологией: этого будет достаточно для понимания самого понятия надежности, как она измеряется и чем обеспечивается. Поэтому обращайтесь к ГОСТ 27.002-89. «Надежность в технике. Основные понятия. Термины и определения».

Основным понятием, которое можно применить для автоматизированных систем, является коэффициент готовности: 99%, 99,9%, 99,99%. Каждое количество «девяток» обеспечивается определенными мерами.

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

7.1.6. Пункт 4.1.6. «Требования к эргономике и технической эстетике» /п. 2.6.1.6 ГОСТ 34.602-89/

Приведем требования ГОСТа: «В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала».

Обычно в этом пункте пишется, что у системы должен быть удобный и красивый интерфейс. Но как измерить удобство и красоту? Поэтому либо данное требование опускаем, либо говорим о том, что интерфейс будет соответствовать разработанному позже дизайн-проекту, либо приводим стандарты, например, так называемые «гайдлайны» для разработки мобильных приложений: Material Design для Android и Human Interface Guidelines для iOS.

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

7.1.9. Пункт 4.1.9. «Требования к защите информации от несанкционированного доступа» /п. 2.6.1.9 ГОСТ 34.602-89/

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

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

Так, для финансовых систем следует использовать «Стандарт безопасности данных индустрии платежных карт» (PCI DSS). Для систем, в которых хранятся персональные данные, — Постановление Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных». В вашей предметной области могут иметься и другие стандарты.

В общем и целом, средства защиты можно разделить на следующие типы:

  1. Средства, обеспечиваемые создаваемым программным продуктом.
  2. Меры, обеспечиваемые системным администратором.
  3. Меры физической защиты.
  4. Общие организационные меры.
  5. Меры, принимаемые в процессе разработки программного обеспечения.

1. Средства защиты, обеспечиваемые создаваемым программным продуктом:

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

2. Меры, обеспечиваемые системным администратором:

  • Применение межсетевых экранов (файерволов).
  • Документирование и мониторинг используемых служб и протоколов.
  • Конфигурирование демилитаризованной зоны (DMZ).
  • Контроль выполнения правил использования портативных компьютеров: подключение к внутренней сети, использование межсетевых экранов.
  • Отключение учетных записей по умолчанию перед подключением в сеть оборудования и систем.
  • Настройка устройств беспроводного доступа: установка паролей и изменение настроек доступа, установленных по умолчанию.
  • Установка обновлений, устраняющих выявленные уязвимости оборудования и программного обеспечения.
  • Обеспечение безопасности при удаленном доступе в систему (например, использование VPN).
  • Установка, обновление и мониторинг работы антивирусного программного обеспечения.
  • Проведение периодического сканирования сети и сканирования после внесения важных изменений.
  • Назначение каждому работнику уникальной учетной записи, периодические проверки на наличие неудаленных учетных записей уволенных сотрудников, смена паролей. Выдача и учет токенов электронной подписи.
  • Настройка ограничения доступа к базам данных.
  • Контроль синхронизации времени на всех серверах и рабочих станциях (с целью обеспечения корректности времени, регистрируемого в журналах регистрации событий).
  • Настройка журналов регистрации событий.
  • Периодическая инвентаризация точек беспроводного доступа и другого оборудования, установленного программного обеспечения.

3. Меры физической защиты:

  • Ограничение доступа в критические помещения.
  • Отключение сетевых разъемов в общедоступных местах.
  • Установка камер видеонаблюдения за критически важными помещениями.

4. Общие организационные меры:

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

5. Меры, принимаемые в процессе разработки программного обеспечения:

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

7.1.10. Пункт 4.1.10. «Требования по сохранности информации при авариях» /п. 2.6.1.10 ГОСТ 34.602-89/

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

  • потеря питания,
  • выход из строя сервера,
  • выход из строя устройства хранения (жесткого диска).

7.1.13. Пункт 4.1.13. «Требования к стандартизации и унификации» /п. 2.6.1.13 ГОСТ 34.602-89/

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

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

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

7.2.1. Структура функционального описания

Сначала рассмотрим структуру функциональных требований к системе: подсистема — комплекс функций — функция — задача. Задача — это часть функции, причем задача может быть описана в виде отдельной функции. Например, для функции входа в систему в качестве одной из задач мы приводим ввод пароля. А процедуру ввода пароля мы можем расписать уже как отдельную функцию: проверка на правильность, восстановление пароля, отображение подсказок и т.д. Комплекс — это то, что объединяет функции. Например, «Учет основных сведений», «Проведение аукциона» и т.д. В Комплексе две и более функции.

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

7.2.4. Требование, а не сценарий

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

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

7.2.5. Оформление функциональных требований

Приведем некоторые рекомендации по тому, как оформлять описание функций:

  1. Требования к функциям и задачам обычно следует выносить в приложение. Таким образом документ органично делится на нефункциональную и функциональную части. Кроме того, приложение всегда можно распечатать и рассматривать отдельно.
  2. Избегайте больших абзацев. Лучше всего, если требования разбиты по пунктам и подпунктам: так легче их воспринимать и контролировать их выполнение (галочки ставить). Если приводится перечень требований или сведений, пусть он приводится нумерованным или маркированным списком.
  3. Для функций, назначение которых не очевидно из их названия, следует обязательно указать цель и решаемую задачу. В противном случае даже составитель ТЗ рискует забыть, зачем он описывал ту или иную функциональность.

5.6. Регистрация транспортного средства в Системе

Предъявляются следующие требования:

1) Система должна позволять учитывать следующие общие сведения:

  • государственный регистрационный знак (ГРНЗ),
  • ФИО собственника,
  • адрес собственника,
  • данные от сервиса получения данных о ТС (см. п. 3.3, Приложение Б),
  • примечание.

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

  • текущий класс ТС (см. п. 3.3, Приложение А),
  • текущий тариф (см. п. 5.1, Приложение А),
  • текущий договор (см. п. 5.5, Приложение А),
  • класс ТС по сведениям из системы МВД РК,
  • сведения о лицевом счете и его состоянии (см. п. 3.6, Приложение А),
  • сведения о нахождении в реестре ТС с льготным проездом (см. п. 3.5, Приложение А).

3) Система должна позволять регистрировать и изменять сведения о ТС следующими способами:

  • вручную оператором,
  • при поступлении сведений из системы регистрации RFID-меток (см. п. 1.1, Приложение Б),
  • при идентификации ТС с помощью камеры ГРНЗ.

4) При регистрации в системе нового ТС система должна запрашивать данные о ТС от сервиса получения данных о ТС (см. п. 3.3, Приложение Б). Должна иметься возможность обновить указанные сведения отдельного ТС.

7.3. Подраздел 4.3. «Требования к видам обеспечения» /п. 2.6.3 ГОСТ 34.602-89/

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

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

При чтении данного подраздела задаешься вопросом, что имели в виду составители стандарта под «математическим обеспечением», «лингвистическим обеспечением», «информационным обеспечением» и т.д. Ответы следует искать в ГОСТ 34.003-90, где расшифровываются все эти термины.

7.3.2. Пункт 4.3.2 «Информационное обеспечение» /п. 2.6.3.2 ГОСТ 34.602-89/

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

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

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

7.3.3. Пункт 4.3.3 «Лингвистическое обеспечение» /п. 2.6.3.3 ГОСТ 34.602-89/

В данном пункте приводятся:

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

8. Раздел 5 «Состав и содержание работ по созданию (развитию) системы» /п. 2.7 ГОСТ 34.602-89/

Данный раздел организационный и его нередко выносят в договор. Тем не менее, данные сведения в ТЗ могут уточняться.

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

  • Наименование этапа (подэтапа).
  • Содержание работ (краткое описание, перечень задач).
  • Результат работ (утвержденные документы, разработанные и сданные решения).
  • Проектная, рабочая или отчетная документация.
  • Ответственные (кто выполняет данную работу: заказчик, исполнитель или иное лицо). Если обе стороны должны выдать совместный результат, указываются роли.
  • Длительность (сроки, даты, начало отсчетов сроков).

Пример содержания данного раздела приведен в таблице ниже.

ЭтапСодержание работПорядок приемки и документыСрокиОтветственный
1. Составление технического задания (ТЗ)Разработка функциональных и нефункциональных требований к системеУтверждение ТЗ60 дней со дня предоплаты. Заказчик предоставляет первый вариант на согласование через 45 днейРазработка — Исполнитель, согласование — Заказчик
2. Техническое проектирование (ТП)Разработка сценариев работы системы и макетов интерфейса веб-приложенийУтверждение документа «Описание автоматизированных функций»60 дней со дня согласования ТЗ. Заказчик предоставляет первый вариант на согласование через 45 днейИсполнитель
Разработка фирменного стиля оформления веб-сайта и мобильных приложенийУтверждение фирменного стиляЗаказчик
Разработка наполнения сайта (публичное веб-приложение)Утверждение наполненияЗаказчик
Разработка дизайн-макета публичного веб-приложенияУтверждение дизайн-макетаИсполнитель
Разработка дизайн-макетов публичных мобильных приложенийУтверждение дизайн-макетаИсполнитель
Выбор SMS-агрегатора, подготовка правил обмена с серверным модулемУтверждение дизайн-макетаЗаказчик, по рекомендациям Исполнителя
3. Разработка программной частиРазработка серверного модуля, модуля хранения данных и модуля хранения файловПриемка осуществляется в процессе испытаний100 дней со дня согласования ТПРазработка — Заказчик. Исполнитель предоставляет данные для наполнения справочников
Разработка панели администрированияПриемка осуществляется в процессе испытанийЗаказчик
Разработка статического веб-сайта (публичное веб-приложение)Приемка осуществляется в процессе испытанийИсполнитель
Разработка интеграции публичного веб-приложения и серверного модуляПриемка осуществляется в процессе испытанийИсполнитель
Разработка мобильных приложений iOS (включая интеграцию с серверным модулем)Приемка осуществляется в процессе испытанийИсполнитель
Разработка мобильных приложений Android (включая интеграцию с серверным модулем)Приемка осуществляется в процессе испытанийИсполнитель
Разработка рабочей и эксплуатационной документацииУтверждение документов:
— «Программа и методика предварительных автономных испытаний».
— «Программа и методика предварительных комплексных испытаний».
— «Программа опытной эксплуатации»
Исполнитель
4. Предварительные автономные испытания— Проверка соответствия нефункциональным требованиям (дизайн).
— Проверка комплекта документации.
— Проверка работоспособности системы, без взаимодействия со смежными (внешними) системами.
— Доработки и повторные испытания до устранения недостатков
Утверждение протокола предварительных автономных испытаний14 дней со дня завершения разработкиИсполнитель — проведение испытаний. Заказчик — подготовка инфраструктуры и организация испытаний
5. Предварительные комплексные испытания— Проверка взаимодействия со смежными внешними системами.
— Доработки и повторные испытания до устранения недостатков
Утверждение протокола предварительных комплексных испытаний14 дней со дня завершения автономных испытанийИсполнитель — проведение испытаний. Заказчик — подготовка инфраструктуры и организация испытаний
6. Подготовка к опытной эксплуатации— Разворачивание системы на промышленных серверах.
— Выполнение комплекса работ по подготовке (подробнее см. п. 7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие)
Приемка отсутствует5 дней со дня завершения предварительных испытанийПодготовка программной части и заполнение справочников — Заказчик. Исполнитель предоставляет данные для наполнения справочников и осуществляет организацию ОЭ
7. Опытная эксплуатация— Эксплуатация с привлечением небольшого количества участников (несколько аукционов среди знакомых).
— Доработки и повторные испытания до устранения недостатков
Протокол опытной эксплуатации (журнал ошибок и итогов их исправления)30 днейИсполнитель — устранение недостатков. Заказчик — проведение ОЭ
8. Ввод в промышленную (коммерческую) эксплуатациюСм. этап подготовки к опытной эксплуатацииПриемка отсутствуетПодготовка программной части и заполнение справочников — 10 днейПодготовка программной части и заполнение справочников — Заказчик. Исполнитель осуществляет организацию промышленной эксплуатации
9. Промышленная (коммерческая) эксплуатацияПромышленная эксплуатацияПриемка отсутствует

9.1. Подраздел 6.1. «Виды, состав, объем и методы испытаний системы и ее составных частей» /п. 2.8.1 ГОСТ 34.602-89/

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

Остановимся подробнее на видах испытаний. Виды испытаний, их состав, требования к документам устанавливаются ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Поэтому при разработке данного раздела и технического проекта обязательно обращайтесь к этому стандарту, здесь мы разъясним только основные моменты.

Давайте попробуем разобраться в том, какие бывают испытания:

1. Испытания делятся на следующие виды:

  • Предварительные.
  • Опытная эксплуатация.
  • Приемочные.

2. Предварительные (а частично и приемочные) испытания в свою очередь делятся на:

  • Автономные (без интеграции со смежными системами).
  • Комплексные (в комплексе со смежными системами).

Зачем испытания делятся на разные стадии? Во-первых, потому что ГОСТ 34.603-92 не разделяет внутреннюю приемку и внешнюю, часть испытаний может проводиться без заказчика. Во-вторых, описывается последовательный процесс тестирования, часть за частью, а потом уже все в комплексе.

Давайте попробуем описать процесс испытаний простыми словами:

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

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

3. Предварительные комплексные испытания. Система испытывается в комплексном режиме, то есть во взаимодействии со смежными системами. В таком виде система передается заказчику для опытной эксплуатации.

4. Опытная эксплуатация. ОЭ может проходить в разных режимах. Самое лучшее —это эксплуатация на реальных данных, с реальными пользователями и с выполнением реальных задач. Только такой вид испытаний позволит убедиться, что система действительно работоспособна. В ходе опытной эксплуатации устраняются недостатки.

5. Приемочные испытания. Это последний вид проверки. Скажете, а почему опытная эксплуатация после устранения всех недостатков плавно не перейдет в промышленную? Так оно обычно и происходит. Но ведь высоким дядям надо увидеть, что система реально работает, «пощупать» ее. Для них, для высокой комиссии и предназначены приемочные испытания. Таким образом, приемочные испытания отличаются от предварительных в первую очередь статусом комиссии.

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

  • Для предварительных и приемочных испытаний это «Программа и методика предварительных (приемочных) испытаний». Указания для составления документа содержатся сразу в двух стандартах. Вкратце — в ГОСТ 34.603-92 (п. 2.2.2 и 4.1) и более подробно — в РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
  • Для опытной эксплуатации предусматривается документ «Программа опытной эксплуатации», содержание которого приводится в п. 3.1 ГОСТ 34.003-90. Также следует прописать использование «Журнала опытной эксплуатации» (см. п. 3.2 ГОСТ 34.603-92), в который будут заноситься недостатки и результаты их устранения.

9.2. Подраздел 6.2. «Общие требования к приемке работ по стадиям» /п. 2.8.2 ГОСТ 34.602-89/

В данном разделе я обычно указываю:

  1. На чьей территории и на чьем оборудовании будут проводиться испытания: заказчика или исполнителя.
  2. Общее описание, каким образом будут проводиться испытания (например, что будут проверяться документы, наличие элементов пользовательского интерфейса, отрабатываться сценарии).
  3. Список участников.
  4. Перечень документов, которыми оформляют результат испытаний:

  • Для предварительных и приемочных испытаний это протокол испытаний, в котором приводится перечень проверок и их результаты.
  • Для опытной эксплуатации — журнал опытной эксплуатации.

10. Раздел 7 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» /п. 2.9 ГОСТ 34.602-89/

Процесс, описываемый в данном разделе, часто называют внедрением. Обратите внимание на то, что данные работы также приводятся в разделе 5 «Состав и содержание работ по созданию (развитию) системы». Но, в разделе 5 они лишь кратко упоминаются, здесь же приводится подробное описание.

При подготовке объекта, как правило, следует выполнить следующие работы:

  1. Проведение реорганизации, набор нового персонала, в случае необходимости.
  2. Обучение персонала.
  3. Для веб-приложений: разработка общих разделов сайта и пользовательского соглашения (согласия на обработку персональных данных).
  4. Заполнение справочников и иных исходных сведений.
  5. Перенос данных из прежней системы.
  6. Развертывание системы на промышленных серверах.
  7. Настройка интеграции со смежными системами.
  8. Настройка системы доступа и создание учетных записей.

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

11. Раздел 8 «Требования к документированию» /п. 2.10 ГОСТ 34.602-89/

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

Документирование проекта автоматизации по ГОСТ 34 регламентируется следующими стандартами:

  • ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем.
  • РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
  • Для Технического задания — ГОСТ 34.602-89, который мы сейчас и обсуждаем.

В первом стандарте (ГОСТ 34.201-89) приводится перечень и структура документации. Во втором — РД 50-34.698-90 — указывается содержание следующих документов:

  • Документы эскизного и технического проектов.
  • Документы, разрабатываемые на предпроектных стадиях.
  • Организационно-распорядительные документы (акты, протоколы и пр.)

11.1 Особенности структуры документации

При составлении перечня необходимых документов обычно просматривают РД 50-34.698-90 и выбирают требуемые. При этом делается немало ошибок, поскольку документация имеет довольно сложную структуру, которая описывается в ГОСТ 34.201-89.

Давайте попытаемся выявить несколько правил, которые помогут при составлении перечня документов.

1. Для каждого из этапов предназначен свой комплект документации.

Для каждого из этапов предназначен свой комплект документации. Это очень важно уяснить. Не надо прописывать разработку эксплуатационных документов на проектных стадиях и наоборот. Получаются чисто формальные бумаги, на которые вы потратите значительное время. И если «Руководство пользователя» до окончания разработки системы обычно никто не составляет (хотя встречал и таких деятелей), то «Описание автоматизированных функций», в котором обычно приводятся сценарии для программистов, постоянно составляют уже после окончания разработки. Также при чтении РД 50-34.698-90 может создаться впечатление, что у некоторых документов содержание пересекается: это тоже связано с тем, что документы предназначаются для различных этапов.

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

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

2. Документы делятся на темы (части проекта).

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

3. Документы можно объединять.

В ГОСТ 34.201-89 прямо указывается, в каких случаях один документ включается в состав другого. Это сделано для того, чтобы не оставалось вырожденных документов, с одной или двумя страничками. Если что-то требуется описать, но объем очень маленький, лучше всего включить текст в другой документ. В большинстве случаев имеется такой документ как «Пояснительная записка к техническому проекту», в который можно добавлять разделы.

4. Эксплуатационная и проектно-сметная документация выделены отдельно.

Составители ГОСТ 34.201-89 в отдельных столбцах таблицы с перечнем документов обозначили принадлежность к эксплуатационной и проектно-сметной документации.

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

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

11.2 Особенности оформления списка документов

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

В правилах документирования обычно я привожу таблицу со следующими столбцами:

  • Этап.
  • Наименование документа.
  • Примечание: указывается стандарт разработки, назначение, краткое содержание и основные особенности документа.

11.3 Пример перечня документации

Для большого проекта внедрения сложной системы может потребоваться достаточно большой перечень документации. Приведем пример такого перечня в таблице ниже.

ЭтапДокументСодержание документаПримечания
1. Техническое проектированиеВедомость технического проектаПеречень документов технического проекта
Пояснительная записка к техническому проекту— описание основных технических решений,
— описание процесса деятельности с применением системы,
— мероприятия по подготовке объекта автоматизации к вводу системы в действие
При поставке типовых продуктов не разрабатывается
Описание автоматизируемых функций— детальные сценарии работы системы,
— макеты пользовательского интерфейса с подробным описанием элементов,
— перечень подсистем (модулей) с описанием выполняемых функций,
— описание структуры данных, где это необходимо,
— формы и правила формирования отчетов
При модернизации приводится описание модернизируемых функций в формате «как должно быть».
— При поставке типовых продуктов не разрабатывается
Описание комплекса технических средств— описание комплекса оборудования: серверов, файерволов, свичей и пр.,
— описание локальной сети и подсетей, параметров выхода в Интернет
При модернизации разрабатывается в случае внесения изменений в КТС, описываются изменения.
Описание интеграционных решенийОписание разрабатываемых протоколов интеграции со смежными системами, периодичность обменных операцийДокумент разрабатывается вместо ГОСТовских «Перечень входных сигналов и данных» и «Перечень выходных сигналов (документов)».
— При модернизации разрабатывается в случае внесения изменений, описывается в формате «как должно быть»
Описание организационной структурыИзменения в организационной структуре, необходимые для функционирования системыПри модернизации разрабатывается в случае внесения изменений в оргструктуру
СметаУточненная стоимость работ по созданию и внедрению системы
2. Разработка рабочей и эксплуатационной документацииВедомость рабочей и эксплуатационной документацииПеречень рабочих (эксплуатационных) документов технического проекта
Формуляр— общие указания по эксплуатации системы,
— перечень документации для ознакомления персоналом,
— объем сопровождения,
— сведения, необходимые для организации, занимающейся сопровождением системы,
— перечень возникших аварийных ситуаций и сведения об их устранении,
— сведения о ремонте технических средств,
— сведения об изменениях ПО,
— сведения о выполнении регламентных работ,
— сведения о рекламациях и устранении замечаний
— При модернизации системы документ актуализируется.
— При поставке типовых продуктов не разрабатывается
Общее описание системы— структура системы,
— перечень смежных систем и связей между системами,
— описание подсистем,
— схема структурная комплекса технических средств,
— перечень эксплуатационных документов
В случае доработки типового продукта может разрабатываться в полном объеме
Руководство пользователя (администратора)Описание операций по работе с системой
Спецификация закупаемого оборудованияДля каждой позиции указывается:
— наименование оборудования,
— тип, марка,
— изготовитель, поставщик,
— количество
Разрабатывается в случае необходимости
Технологическая инструкцияИнструкция на операцию или комплекс операций, связанных с использованием системыПри модернизации — актуализируется в случае необходимости
Описание интеграционных решенийАктуализированный документ, созданный на этапе технического проектирования
Программа подготовки пользователей— план самостоятельной подготовки,
— план занятий, количество часов,
— перечень тем изучения на занятиях,
— раздаточные материалы,
— контрольные примеры
Программа и методика испытаний (для каждого испытания отдельно)— сценарии проверки функций системы,
— сценарии проведения нагрузочного тестирования
При поставке типовых продуктов в ходе испытаний производится проверка:
— общей работоспособности системы и ее интеграции со смежными системами,
— уровня готовности пользователей
3. Ввод в действиеПротокол подготовки персоналаПеречень персонала с отметками о прохождении обучения и выполнении контрольных заданий
Протокол развертывания системы
Протокол первоначального заполнения БД
Протокол предварительных испытанийПеречень испытаний с отметками о прохождении и замечаниями
Акт приемки в опытную эксплуатацию
Журнал опытной эксплуатацииПеречень замечаний и сведения об их устранении
Акт о завершении опытной эксплуатации
Протокол приемочных испытанийПеречень испытаний с отметками о прохождении и замечаниями
Акт приемки системы в постоянную эксплуатацию
4. Гарантийное и послегарантийное обслуживание (сопровождение)ФормулярДокумент разрабатывается на стадии 5 (Разработка рабочей и эксплуатационной документации) и заполняется по ходу сопровождения

12. Раздел 9 «Источники разработки» /п. 2.11 ГОСТ 34.602-89/

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

Если источников много, то следует разбивать их на подразделы, например:

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

Заключение

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

Пишите в комментариях, если считаете необходимым что-то уточнить или дополнить. Обязательно внесу изменения в статью.

Смотрите видео: Техническое задание на ремонт. (June 2021).

Pin
Send
Share
Send
Send