что такое технологическое описание объекта

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

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

Технический план (техплан) является документом, без которого невозможно поставить ОКСы (объекты капитального строительства) на кадастровый учёт и внести сведения об объекте в ЕГРН.

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

Что такое технический план (техплан)

Технический план представляет собой документ, который содержит полную характеристику объекта недвижимости: площадь, планы этажей, число помещений, положение на земельном участке, указание назначения и иных характеристик и параметров. Форму и содержание техплана регламентирует ФЗ №218 «О государственной регистрации недвижимости», а именно Статья 24. Требования к техническому плану.

Кто делает технический план

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

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

Содержание технического плана

Форма техплана состоит из текстовой и графической глав.

В текстовой части отражены следующие разделы:

Текстовая часть технического плана

В графической части технического плана отображается информация:

Графическая часть техплана

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

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

Когда нужен технический план

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

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

Виды технических планов

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

Технический план объекта индивидуального жилищного строительства (ИЖС) в 2021 году

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

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

Уведомление о планируемых строительстве или реконструкции объекта индивидуального жилищного строительства или садового дома

Уведомление о планируемом строительстве

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

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

Технический план дома в СНТ

Для постановки на кадастровый учёт садового дома до 1 марта 2026 года вам понадобиться только технический план.

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

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

Технический план жилого/нежилого помещения

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

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

Технический план нежилых помещений

План нежилого помещения после перепланировки и переустройства

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

Технический план сооружения

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

Технический план сооружения

К сооружениям относятся следующие объекты недвижимости:

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

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

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

Технический план на многоквартирный дом

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

Куда обращаться за техническим планом

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

Квалифицированные специалисты нашей компании имеют существенный опыт в подготовке всех видов технических планов:

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

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

Источник

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

Основные функции технического описания оборудования

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

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

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

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

Составление технического описания оборудования

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

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

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

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

Разработка технического описания оборудования

Как было сказано выше, техническое описание оборудования разрабатывается на основе государственного стандарта ГОСТ 2.105-95 ЕСКД, который является основным стандартом для разработки любой конструкторской документации. Им руководствуются в случаях, если на разрабатываемый документ не предполагается другого отдельного стандарта.

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

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

В ГОСТе 2.105-95 ЕСКД можно найти детальное описания оформления документа: каким должно быть расстояние между буквами и строками, каким шрифтом писать текст и какое расстояние должно быть от рамки формы до границ текста.

Сам текст технического описания оборудования, как уже был сказано, должен разделяться на разделы и подразделы. Предусмотрены случаи, когда объём текста очень большой. В таких случаях разрешает вводить в документ части и даже тома. Каждая часть или том должен быть разработан и укомплектован отдельно.

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

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

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

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

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

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

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

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

Источник

Технологическая характеристика объекта

МИНИСТЕРСТВО ОБРАЗОВАНИЯ и НАУКИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ТОЛЬЯТТИНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Л.Н. Горина

Раздел выпускной квалификационной работы «Безопасность и экологичность технического объекта»

Учебно-методическое пособие

Описаны структура выполнения раздела выпускной квалификационной работы «Безопасность и экологичность технического объекта»

Для подготовки бакалавров.

Рецензент: д.т.н., профессор кафедры безопасности жизнедеятельности Самарского государственного технического университета, заслуженный деятель науки РФ Г.Н. Яговкин;

Утверждено научно- методическим советом Тольяттинского государственного университета.

Ó Тольяттинский государственный

Ó Горина Л.Н., 2016 г.

Общие правила разработки раздела «Безопасность и экологичность технического объекта». 4

Структура раздела «Безопасность и экологичность технического объекта». 4

Содержание разделов. 5

1. Технологическая характеристика объекта. 5

2. Идентификация профессиональных рисков. 6

3. Методы и средства снижения профессиональных рисков. 6

4. Обеспечение пожарной безопасности технического объекта. 7

5. Обеспечение экологической безопасности технического объекта. 10

Введение

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

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

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

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

Общие правила разработки раздела «Безопасность и экологичность технического объекта»

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

Расписание консультаций по разделу «Безопасность и экологичность технического объекта» размещается на информационном стенде кафедры «Управление промышленной и экологической безопасности» согласно графику дипломного проектирования.

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

Структура раздела «Безопасность и экологичность технического объекта»

1. Технологическая характеристика объекта.

2. Идентификация профессиональных рисков.

3. Методы и средства снижения профессиональных рисков.

4. Обеспечение пожарной безопасности технического объекта.

5. Обеспечение экологической безопасности технического объекта.

Содержание разделов.

Технологическая характеристика объекта

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

1 Приводится наименование технологического процесса

2 Приводится наименование технологической операции

3 Приводится наименование должности работника, выполняющего технологический процесс, операцию по Постановлению Госстандарта РФ от 26.12.1994 №367 (ред. от 19.06.2012) О принятии и введении в действие Общероссийского классификатора профессий рабочих, должностей служащих и тарифных разрядов ОК 016-94 (вместе с «ОК 016-94. Общероссийский классификатор профессий рабочих, должностей служащих и тарифных разрядов») (дата введения 01.01.1996)

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

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

Источник

Техническое описание объекта

Появились вопросы по услуге?

Поделиться:

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

Состав документации

Техническое описание объекта – это единственный документ, служащий подтверждением фактического существования строения и его соответствия государственным нормам. Является основанием для составления техплана здания или сооружения.

Техописание жилого строения содержит:

Содержание может незначительно отличаться в зависимости от типа недвижимого имущества:

Зачем нужно техописание

Разработка документации необходима во многих ситуациях:

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

Когда документ не требуется

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

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

Особенности составления техописания

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

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

Требуемые сведения от собственника

При обращении к кадастровым инженерам владелец недвижимого имущества должен подготовить:

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

Квалифицированная помощь для быстрого решения

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

Источник

Разработка Технического задания по ГОСТ 34 легко и просто

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

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

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

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

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

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

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

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

2. Характерные особенности Технического задания по ГОСТ 34

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

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

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

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

2.2. Зачем нужен ГОСТ на Техническое задание?

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

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

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

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

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

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

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

3. Общие принципы составления ТЗ по ГОСТ 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. Зачем в разных разделах говорится об одном и том же?

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

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

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/

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

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

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

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

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

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

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

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

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. Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы.

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

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

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

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

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

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

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.5. Пункт 4.1.5. «Требования к безопасности» /п. 2.6.1.5 ГОСТ 34.602-89/

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

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

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

7.1.7. Пункт 4.1.7. «Требования к транспортабельности для подвижных АС» /п. 2.6.1.7 ГОСТ 34.602-89/

7.1.8. Пункт 4.1.8. «Требования к эксплуатации, техническому обслуживанию, ремонту и хранению» /п. 2.6.1.8 ГОСТ 34.602-89/

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

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

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

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

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

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

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

7.1.11. Пункт 4.1.11. «Требования к защите от влияния внешних воздействий» /п. 2.6.1.11 ГОСТ 34.602-89/

7.1.12. Подраздел 4.1.12. «Требования по патентной чистоте» /п. 2.6.1.12 ГОСТ 34.602-89/

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

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

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

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

7.1.14. Пункт 4.1.14. «Дополнительные требования» /п. 2.6.1.14 ГОСТ 34.602-89/

7.2. Подраздел 4.2. «Требования к функциям (задачам), выполняемым системой» /п. 2.6.2 ГОСТ 34.602-89/

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

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

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

7.2.2. Виды функций с точки зрения их выполнения

По сути, все функции (или их задачи; в функции может присутствовать сразу несколько задач) можно разделить на следующие типы:

7.2.3. Виды функций с точки зрения их роли

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

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

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

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

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

7.2.6. Пример описания функции

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

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

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

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

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

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

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

7.3.1. Пункт 4.3.1 «Математическое обеспечение» /п. 2.6.3.1 ГОСТ 34.602-89/

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/

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

7.3.4. Пункт 4.3.4 «Программное обеспечение» /п. 2.6.3.4 ГОСТ 34.602-89/

7.3.5. Пункт 4.3.5 «Техническое обеспечение» /п. 2.6.3.5 ГОСТ 34.602-89/

7.3.6. Пункт 4.3.6 «Метрологическое обеспечение» /п. 2.6.3.6 ГОСТ 34.602-89/

7.3.7. Пункт 4.3.7 «Организационное обеспечение» /п. 2.6.3.7 ГОСТ 34.602-89/

7.3.8. Пункт 4.3.8 «Методическое обеспечение» /п. 2.6.3.8 ГОСТ 34.602-89/

7.3.9. Другие виды обеспечения

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

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

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

9. Раздел 6 «Порядок контроля и приемки системы» /п. 2.8 ГОСТ 34.602-89/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Пример перечня документации

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

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

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

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

Заключение

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

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

Источник