Экспертиза технических заданий

Содержание страницы:

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

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

Можно ли обойтись без технического задания?

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

Что нужно учитывать при составлении технического задания?

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

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

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

Проводит ли участник закупки экспертизу технического задания?

Заказчик разместил техническое задание на официальном сайте в составе закупочной документации. Может ли участник закупки проводить экспертизу этого задания?

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

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

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

Срок годности в процентах — возможно ли?

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

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

При описании объекта закупки заказчик может указать в документации, в частности, требования к гарантийному сроку (ч. 4 ст. 33 44-ФЗ). Но в описание объекта закупки нельзя включать требования к товарам и информации, которые влекут ограничение количества участников закупки. Исключение составляют случаи, когда нет другого способа более точно и четко описать объект закупки (п. 1 ч. 1 ст. 33 44-ФЗ).

ФАС России в разъяснениях придерживается мнения, согласно которому установление требования к остаточному сроку годности в процентах неправомерно (Письмо от 26.08.2014 № АК/34487/14).

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

Ранее при рассмотрении аналогичных споров, еще в период действия 94-ФЗ, ФАС России и арбитражные суды признавали такое требование правомерным (Решения ФАС России от 13.10.2011 по делу № К-2255/11, от 13.10.2011 по делу № К-2254/11, Постановление ФАС Центрального округа от 21.11.2012 по делу № А08-10203/2011). Но все-таки лучше определить остаточный срок годности периодом (например, в годах, месяцах, днях) либо конкретной датой, до которой товар должен сохранять свою пригодность. Это позволит избежать обвинений в ограничении конкуренции и снизит вероятность возникновения претензий со стороны контролирующих органов.

Детализация не бывает излишней?

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

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

Наличие ГОСТов при отсутствии технических характеристик

Заказчик при описании объекта закупки в техническом задании сослался на нормативно-технические документы (ГОСТы, СНиПы) и не указал при этом конкретные технические характеристики и показатели качества ТРУ. Вправе ли заказчик устанавливать требования к ТРУ таким способом?

Ссылки на ГОСТы, СНиПы и другие нормативно-технические документы в конкурсной документации фактически не устанавливают показатели, связанные с определением соответствия выполняемых работ, оказываемых услуг потребностям заказчика, что является нарушением ч. 1 ст. 33 44-ФЗ.

В данном случае заказчик не должен устанавливать требования в техническом задании таким способом. Заказчик вправе сослаться на ГОСТы и СНиПы, только если нормативно-технические документы содержат все необходимые требования к ТРУ и показатели их качества.

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

Бывают случаи, когда ФАС признает указания на ГОСТы, СНиПы и другие нормативно-технические документы неправомерными. Арбитражные суды, как правило, признают такие указания правомерными, только если нормативно-технические документы содержат все необходимые показатели качества, а также требования к товарам, работам, услугам в виде измеряемых величин.

Метрологическая экспертиза отдельных видов технической документации

Напоминаем читателям, что одной из принципиально важных «новаций» Федерального закона «Об обеспечении единства измерений» (№ 102-ФЗ от 26.06.2008 г.) является включение в него статьи 14, содержащей ряд положений, регламентирующих проведение метрологической экспертизы стандартов, проектной, конструкторской и технологической документации, а также других объектов. В связи с этим отмечается явно возросший интерес метрологов-практиков к вопросам проведения метрологической экспертизы, которая представляет, как известно, одно из важных направлений работы по обеспечению единства измерений.

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

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

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

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

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

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

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

Переходим к метрологическая экспертиза технической документации и рассмотрим метрологическая экспертиза технического задания (ТЗ) на разработку продукции.

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

— основание для разработки;

— цель и назначение;

— требования по видам обеспечения;

— этапы разработки (выполнения);

— порядок выполнения и приемки;

Метрологическую экспертизу ТЗ проводят в следующей последовательности:

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

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

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

Техническое задание на проведение строительной экспертизы

Мы проводим судебные и несудебные строительно-технические экспертизы по всей России.

Для определения возможности проведения строительной экспертизы в АНО «Бюро судебных экспертиз» нашим экспертам необходимо получить информацию об объекте строительной экспертизы.

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

Заполненное Техническое задание отправьте нам на электронную почту: [email protected]

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

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

Тип назначаемой экспертизы: судебная или досудебная;

Наименование объекта экспертизы: жилое/нежилое, частный дом, завод, склад, квартира, жилой дом и т.д.;

Характеристики объекта: этажность, объем, общая площадь объекта или площадь/объем, подлежащие исследованию;

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

Состояние объекта экспертизы: незавершенное или завершенное строительство, сдан в эксплуатацию, самовольное строительство и т.д.;

Читайте так же:  Дан приказ ему на запад ютуб

Местонахождение объекта экспертизы: населенный пункт;

Имеющаяся документация на объект: проектная, договорная, сметная, отчетная или исполнительная документация.

Техническое задание и Экспертиза ТЗ

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

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

• не полностью соответствует существующему документообороту в организации

• не отвечает всем требования законодательства или корпоративных стандартов

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

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

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

Документ «Экспертиза техничного задания» должен проконтролировать следующие пункты:
• Правильность постановки задачи (отсутствие двусмысленных моментов)
• Оптимальность: предложенного технического решения разработчиком
• Отсутствие дублирования функционала
• Применимость полученного результат для решения поставленной задачи
Выкладываю реальные примеры документов ТЗ и Экспертиза ТЗ.

Отчет «ТЗ Отчет Товары на складах в суммовом выражении»

В базе УПП необходимо создать отчет, который будет брать основу с отчета Товары на складах, но при этом необходимо добавить поле Цены, которая будет браться либо

1) Административная цена

2) Закупочная (планирование)

3) Цена в последний закрытый месяц

Данные цены будут выбираться на конец периода.

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

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

Требуемый функционал

Необходимо реализовать следующие возможности:

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

Группировки: Склад, номенклатура.

Замечание: Группировка по периодам не предполагается.

Планируемый результат

Отчет формируется в среднем от 2 до 4 раз в месяц, время, затрачиваемое на ручное формирование отчета приблизительно равно 1 рабочий день, таким образом на формирование отчета затрачивается от 16 до 32 ч.часов в месяц.

Трудозатраты на формирование одного автоматизированного отчета 3-5 минут, таким образом на формирование отчета будет затрачиваться от 0,1 до 0,3 ч.часов в месяц.

Ожидаемый эффект – экономия трудозатрат в размере от 15,7 до 31,9 ч.часов в месяц.

Интеллектуальная Система Тематического Исследования НАукометрических данных

Экспертизы технического задания и технического предложения по модернизации аппаратуры МСУ-ГС и научно-методическое сопровождение наземной отработки и летных испытаний МСУ-ГС в части радиометрич. измерений и геометрич. привязки изображений для «Электро-Л» НИР

  • Руководители НИР: Жуков А.О., Миронов А.В.
  • Участники НИР: Жуков А.О., Захаров А.И., Крусанова Н.Л., Миронов А.В., Мошкалев В.Г., Николаев Ф.Н., Прохоров М.Е., Тучин М.С.
  • Подразделение: Лаборатория космических проектов
  • Срок исполнения: 1 января 2012 г. — 31 декабря 2016 г.
  • Номер договора (контракта, соглашения): 80/3441-12
  • Номер ЦИТИС: 01201277326
  • Тип: Прикладная
  • Приоритетное направление научных исследований: Аппаратура и методика астрономических наблюдений. История астрономии
  • ПН России: Рациональное природопользование
  • Ключевые слова: экспертиза космическая метеорология дистанционное зондирование земли
  • Описание:

Цель экспертиз: 1. Оценка полноты и научно-технического уровня решения задач по обеспечению соответствия разрабатываемого (модернизируемого) ТЗ на СЧ ОКР «Многозональное сканирующее устройство (МСУ-ГС) для геостационарного гидрометеорологического космического комплекса «Электро»» в части радиометрических измерений и геометрических привязок требованиям ТТЗ на ОКР «Геостационарный гидрометеорологический космический комплекс и космическая система на его основе в составе трех космических аппаратов (шифр «Электро»)». 2. Проверка объемов работ и результатов теоретических и экспериментальных исследований по оценке достигаемых значений параметров технических характеристик и выявления фактов несоответствия ТТХ модернизируемого МСУ-ГС требованиям ТТЗ на ГГКК «Электро». 3. Сравнение образца с лучшими зарубежными аналогами для оценки его соответствия мировому уровню.

В экспертном заключении представлены результаты рассмотрения Технического предложения по модификации Многозонального сканирующего устройства (МСУ-ГС) для КА «Электро-Л» №2. Отмечено, что работа, проделанная по доработке ИК модуля, заслуживает высокой оценки. Ряд имеющихся замечаний не снижают этой высокой оценки. Однако нельзя согласиться с утверждением разработчика об отсутствии претензий к ВД модулю МСУ-ГС. Такие недостатки есть, необходимо выявление их причин и действия по их устранению. 10-разрядный формат оцифровки кадров существенно затрудняет проведение геометрических и радиометрических калибровок. Выбор такой разрядности в МСУ-ГС КА «Электро-Л» № 1 был связан с временем передачи изображений на Землю. Уменьшение времени сеанса делает возможным передачу не 10, а 14 разрядных данных. Рекомендуется перейти к передаче на Землю данных с разрядностью 14 бит. Замечание относится как к ВД, так и к ИК каналам МСУ-ГС. В Технических предложениях по модернизации МСУ-ГС отсутствуют предложения по наземной отработке модифицированного прибора. Отметим, что ЛКИ МСУ-ГС № 1 показали, что практически все замечания и недоработки могли быть выявлены и устранены именно в процессе наземной отработки как модулей ВД, так и модулей ИК каналов.

Большая Энциклопедия Нефти и Газа

Метрологическая экспертиза — техническое задание

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

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

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

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

Метрологическую экспертизу технических заданий на образцовые средства измерений, разрабатываемые метрологическими институтами Госстандарта СССР, проводит ВНИИМС. [5]

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

Метрологическую экспертизу технических заданий на образцовые средства измерений, разрабатываемые метрологическими институтами Госстандарта СССР, проводит ВНИИМС. [7]

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

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

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

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

Метрологическое обеспечение включает метрологическую экспертизу технических заданий , конструкторской и технологической документации; проведение государственных испытаний, метрологической аттестации и поверок приборов, а также изготовление необходимых для этого средств; организацию государственного надзора и ведомственного контроля за состоянием и применением аналитических приборов. Однако действующие стандарты не отражают специфику метрологического обеспечения и эксплуатации аналитических приборов многоцелевого назначения — приборов с неограниченным числом возможных гра-дуировочных характеристик. [12]

Эксперты Главного центра СО при метрологической экспертизе технического задания на СО в зависимости от специфики материала СО и его назначения идут навстречу пожеланиям разработчиков СО. [13]

Работа по государственным испытаниям СИ начинается с проведения метрологической экспертизы технических заданий на их разработку. При этом оценивается необходимость разработки СИ с метрологическими характеристиками, приведенными в техническом задании, соответствие этих характеристик и способов их нормирования требованиям НТД, а также обеспеченность разрабатываемых СИ поверкой. Метрологическую экспертизу технических заданий на разработку рабочих СИ осуществляют в порядке, установленном министерством. Технические задания на разработку образцовых СИ подвергаются метрологической экспертизе в метрологических институтах ( по специализации) Госстандарта СССР. Проведение экспертизы играет важную роль в формировании качества отечественной измерительной техники. [14]

В производственных объединениях ( прбМЫШЭТенйЬК разрабатывающих и изготавливающих, а также применяющих нестандарти-зовавдые средства измерений, осуществляется метрологическая экспертиза технических заданий , конструкторской и технологической документации на нестандартизованные средства измерений и метрологическая аттестация и поверка нестандартизованных средств измерений. [15]

ООО «Техническая документация»

разработка техдокументации

Как писать техническое задание?!

Методика разработки технического задания на автоматизированную систему по ГОСТ 34.602-89 (и не только), практические приемы подготовки содержимого разделов, подразделов, пунктов и подпунктов технического задания. Большая часть уже готовых к применению логических элементов ТЗ приведены в конце статьи. Редакция от 20.06.2018.

Как писать техническое задание?!

Создан 05.02.2005 11:41:19

Кто печаль твою разделит?

«Как писать техническое задание?!» — вопль отчаяния из уст т. н. начинающего «технического писателя», далее по тексту — техписа. Вот она — страшная цена развала Союза и переход российской высшей школы на двухступенчатую систему образования.

Вернемся к вопросу. При «раскладке» получается:

  • первый вопрос — «а зачем оно надо»;
  • второй вопрос — какова должна быть структура разделов документа «Техническое задание»;
  • третий вопрос — какие существуют способы подготовки текстов содержимого разделов технического задания?

Третий — самый сложный. Ответы на указанные вопросы появятся в ходе изложения.

Цели и задачи статьи

Цель статьи — облегчить жизнь совсем уж начинающим техписам.

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

Все, что когда-либо производилось, производится и будет производиться, делится (условно, разумеется) на:

Читайте так же:  Лицензия eset endpoint antivirus 5

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

Первым программным изделием, реализованным на «железном носителе», стал, возможно, «музыкальный автомат» с вращающимся диском, утыканным колышками. Колышки в определенное время ударяли по определенному камертону. Таким образом, мелодия оказывалась запрограммированной, «зашитой» на металлическом носителе — настоящее программное изделие по ГОСТ 19.004-80, только что не промышленного, а кустарного производства. Увидеть это чудо чудное можно в Политехническом Музее г. Москвы.

Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор — «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» — 100-процентная автоматизация.

Далее — леденящая душу история.

История, леденящая душу

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

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

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

Побагровел царь — что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой народно-хозяйственной продукции требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная. Технические условия). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата.

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

Издавались Указы, Распоряжения — «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).

Равноправия нет и сейчас — кто платит, тот и заказывает музыку. А платит заказчик.

Примечание от 10.05.2014 г. — Но не все так печально Если действовать с умом, то можно запросто прогнуть любого заказчика, см. Как писать техническую документацию? и Урегулирование разногласий и разрешение споров между заказчиком и исполнителем.

Современное состояние

. и было придумано то, что сделали танк.

из серии «Армейские приколы»

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

Может быть, все было иначе, но танк, в целом, получился хорош — что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.

Техническое задание и его назначение

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

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

  • средство заработать себе «таки на покушать»;
  • способ показать, что техпис — не тварь дрожащая, а право имеет — способ вырасти в глазах Большого Босса.

Крайнее утверждение — палка о трех концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.

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

Считаем, что первый вопрос (в первом же приближении) закрыт.

ГОСТы на технические задания

Куст есть совокупность веток, произрастающих из одной точки.

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

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

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

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

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

Потребовалось разработать техническое задание на изделие — пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001 — кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо ТЗ автоматизированную систему — открываем ГОСТ 34.602-89. На программу — ГОСТ 19.201-78.

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

Практические приемы

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

Самый первый прием — создание шаблонного документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на автоматизированную систему, скачивается ГОСТ 34.602-89 в виде htm-файла, затем просто открывается вордом и сохраняется в формате dot.

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

Примечание от 25.12.2011 г. — На сайте Ростехрегулирования (protect.gost.ru) не так давно стали публиковать официальные версии ГОСТов, правда, далеко не в редактируемом формате.

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

Вспомним родительское — «пока ты не разложишь все по-полочкам, «ничего у тебя не получится (мама)» или «ни хрена у тебя не выйдет (папа)». И мама, и папа, безусловно, были и остаются бесконечно правы. Несложную задачку по физике решить невозможно, пока векторы сил не будут разбросаны по осям координат. Тройной интеграл взять невозможно, пока не будут поочередно взяты интегралы по dx, dy и dz. За исключением случая, когда «интеграл настолько прост, что взять его можно даже без dx».

Произвольно выбранная цитата из ГОСТ 34.602-89:

Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога [из п. 2.6.3.3 ГОСТ 34.602-89]

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

4.3.2.1 Требования к лингвистическому обеспечению системы

4.3.2.1.1 Требования к применению в системе языков программирования высокого уровня

4.3.2.1.2 Требования к языкам взаимодействия пользователей и технических средств системы

4.3.2.1.3 Требования к кодированию данных

4.3.2.1.4 Требования к декодированию данных

4.3.2.1.5 Требования к языкам ввода-вывода данных

4.3.2.1.6 Требования к языкам манипулирования данными

4.3.2.1.7 Требования к средствам описания предметной области (объекта автоматизации)

4.3.2.1.8 Требования к способам организации диалога

Увеличился объем технического задания? А стоит ли экономить бумагу? Имеется и еще одна военная мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги — чище з@@@@ца». Требования к лингвистическому обеспечению стали выглядеть понятнее?

Примечание — Термины «понятность», «понимаемость» (understandability) фигурируют сразу в нескольких ГОСТах. Вот квинтэссенция — «совокупность свойств чего-то, характеризующая затраты усилий человека на понимание логической концепции этого чего-то».

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

Детализация, детализация и еще раз детализация. До приемлемого (атомарного) уровня.

Шаблонное построение фраз

Следует взять на вооружение тот факт, что в каждом вопросе (правильно поставленном) — половина ответа. Допустим, необходимо сформулировать текст подпункта «Требования к применению в системе языков программирования высокого уровня». Итак:

4.3.2.1 Требования к применению в системе языков программирования высокого уровня

В системе должны быть (именно должны — это же требования!) применены перечисленные ниже языки программирования высокого уровня:

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

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

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы

(детализируем — создаем подпункты 4.1.2.1, 4.1.2.2 и 4.1.2.3)

4.1.2.1 Требования к численности персонала

(правильно формулируем текст подпункта — отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)

Численность персонала должна удовлетворять требованиям:

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

4.1.2.2 Требования к квалификации персонала

Квалификация персонала должна обеспечивать эффективное функционирование технических и программных средств системы во всех режимах работы системы»

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

4.1.2.3 Требования к режиму работы персонала

Режим работы персонала — трехсменный круглосуточный.

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

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

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

Возможно Двести Вариантов

Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»

Вернемся к примеру из предыдущего подраздела статьи.

4.1.2.1 Требования к численности персонала

Численность персонала должна удовлетворять требованиям:

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

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

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

Читайте так же:  Приказ на выдачу премии

Примечание от 17.04.2018 г. — В ОКПДТР должность технического пейсателя тоже отсутствует. А должность укладчика текста так и осталась с прежних времен

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

Вы, бабы, красивы,

А я — без прикрас

Но, все же, мужчины

Ю. Рыбчинский, «Две сестры»

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

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

Наименование изделия — преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту — Изделие).

И, в тексте — Изделие, Изделие, Изделие.

Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС — автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту — Система).

И, в тексте — Система, Система, Система. Программа, Программа, Программа.

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

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

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

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

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

  • получение прибыли (в контексте технического задания);
  • подписание Акта завершения работ заказчиком.

Встречаются еще и не такие фокусы. Пример из практики одного из самых маститых техписов (пример привел он сам, без всякого принуждения, в одном из техписовских форумов) — «программа позволяет. программа выполняет. программа делает. ». Милостивый государь, технический писатель! Программы еще нет, она еще не разработана, не проверена, не отлажена, не настроена, не испытана и не сдана заказчику, поэтому еще ничего не позволяет, не делает и не выполняет. Что за непобедимая совковая привычка выдавать желаемое за действительное?!

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

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

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

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

В ГОСТ 34.003-90 функция поставлена впереди задачи, задача является как бы частью функции. И это странно: еще в школе все решали задачки, вычисляя внутри них значения различных функций. И представьте себе, как дико звучала бы декларация: «Цель партии и правительства — повышение благосостояния всего советского народа. Ради достижения цели партия ставит перед собой функцию обеспечения к 2ххх году каждой семьи отдельной квартирой». (Кстати, заниматься уборкой домов и квартир самостоятельно сейчас уже не модно и некогда особенно — для этого есть клининговые компании). Таким образом, функция является частью задачи, а не наоборот. Пусть даже вопреки священному ГОСТ 34.003-90.

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

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

И из предыдущего подраздела:

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

Перечни и нумерация разделов

Перечни (маркированные или нумерованные списки) весьма уместны при подготовке текста технического задания. Нормальный человек способен воспринять (запомнить и безошибочно воспроизвести) от трех до девяти элементов перечня. Свыше девяти — признак гениальности.

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

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

  • автоматизированной функции добавления записей в таблицы базы данных;
  • автоматизированной функции удаления записей из таблиц базы данных;
  • автоматизированной функции сортировки записей в таблицах базы данных. ;»

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

  1. автоматизированной функции добавления записей в таблицы базы данных;
  2. автоматизированной функции удаления записей из таблиц базы данных;
  3. автоматизированной функции сортировки записей в таблицах базы данных. ;»

Отличия, казалось бы, невелики. Но!

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

Во втором случае, всего-навсего — «методика проверки выполнения п. 4.3.2.1(1) технического задания».

В протоколе испытаний, в первом случае — «требования технического задания к выполнению автоматизированной функции добавления записей в таблицы базы данных выполнены». Во втором случае — «требования п. 4.3.2.1(1) технического задания выполнены». Есть разница?

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

По ГОСТ 2.105 списки следует «нумеровать» не цифрами, а буквами:

а) функция такая-то;

б) функция еще какая-то;

Вопрос принципиальный, поскольку ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой нормоконтроля организации — разработчика ТЗ и, при необходимости, подвергнуто метрологической экспертизе [из п. 8 прил. 1 ГОСТ 34.602-89]. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектные и эксплуатационные документы.

Чуть-чуть о метрологической экспертизе. Если в ТЗ имеется подраздел «Метрологическое обеспечение. », то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений физических величин согласно ГОСТ 8.417. И только.

Связка «общие сведения, назначение и состав» в техническом задании

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

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

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

2.1 Назначение системы

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

Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:

  1. задачи сбора данных с каких-то, допустим, датчиков;
  2. задачи обработки, хранения, отображения и пр. информации в центре сбора.

Вот и все. Немного фантазии, и раздел готов:

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

  1. 1-й уровень — уровень сбора данных;
  2. 2-й уровень — уровень консолидации данных (централизованная обработка, хранение и пр.).

Снова оба зайца — и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?

Дальше — применение связки.

2.1.1 Уровень сбора данных

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

Какие-то общие сведения. Можно, к примеру, написать, что уровень характеризуется территориальной распределенностью — любая водичка сойдет, если она приблизительно соответствует.

Уровень сбора данных предназначен (еще один штамп):

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

В состав уровня сбора данных должны входить:

  1. датчики такие-то;
  2. датчики еще какие-то.

В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание — древовидное и иерархическое.

2.2.2.3.1 Датчики такие-то

2.2.2.3.1.1 Общие сведения (о таких-то датчиках)

2.2.2.3.1.2 Назначение (таких-то датчиков)

2.2.2.3.1.3 Состав (таких-то датчиков)

Главное — вовремя остановиться.

Предостережение

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

Не следует особенно увлекаться подобными «тематическими» ГОСТами, содержащими очень уж конкретные требования к компонентам системы. Характерная ошибка начинающих — «каналы связи должны удовлетворять требованиям ГОСТ такому-то». Это фатальная ошибка. Известно, что приемке-сдаче работ по созданию системы, изделия, программного изделия всегда предшествует проведение испытаний.

Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую подпись (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание утверждено и внести в него изменения или корректировки возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.

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

Что делать? Полбеды, если каналами связи занимался субподрядчик, готовый предоставить Большому Боссу сертификаты соответствия. Босс отмажется перед заказчиком и техпис будет жить (до очередного прокола). Но неприятный осадок в душе Большого Босса останется навсегда. Повышения ждать не приходится.

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

Короче, писать надо примерно так, русским по белому:

«В качестве каналов связи могут быть применены (использованы):

  1. каналы связи Интернет-провайдеров;
  2. каналы операторов сотовой связи;
  3. каналы операторов спутниковой связи;
  4. коммутируемые телефонные линии общего пользования;
  5. локальная сеть объекта заказчика;
  6. и так далее»

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

Итак, вспомним еще разок ключевые моменты:

  1. подготовка шаблона технического задания импортом электронной версии требуемого ГОСТа;
  2. детализация — дробление больших по объему разделов технического задания на короткие простые подразделы;
  3. шаблонное построение предложений в разделах (подразделах и пр.) технического задания так, чтобы «в ответе оказывалась половина вопроса»;
  4. формализация содержимого тех разделов, где невозможно (или опасно) давать конкретику;
  5. применение штампов;
  6. применение перечней (маркированных или нумерованных списков);
  7. применение связки «общие сведения, назначение и состав»;
  8. минимальное применение «тематических» ГОСТов.

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

В заключении можно дать ряд дополнительных советов:

  • отыскать «рыбу» технического задания и, после критического ее осмысления, позаимствовать содержимое подходящих разделов (только не с известного всем ресурса закупки.гов.ру — там лежит чушь полнейшая);
  • пользоваться учебно-тренировочными документами;
  • без стеснения задавать вопросы.
Экспертиза технических заданий