Категория: Бланки/Образцы
Исходный документ на проектирование технического объекта называется техническим заданием к договору подряда. Техническое задание содержит основные характеристики объекта, его назначение, технико-экономические, качественные и специальные требования, а также предписания по созданию необходимой документации. Техническое задание включается в договор на выполнение проектных работ и является его основой, определяющей порядок и условия работ, их цель, задачи, принципы, ожидаемые результаты и сроки выполнения.
Сторонами проектных работ являются: их заказчик (юридическое или физическое лицо) и исполнитель (проектировщик или разработчик). Исполнителем проектных работ может выступать только специалист, имеющий разрешение на их проведение. Изменения, дополнения и уточнения к техническому заданию совершаются с согласия сторон и утверждаются заказчиком. Исходной информацией для составления технического задания часто являются результаты предварительных исследований, расчетов, моделирования.
Целью составления технического задания является перевод задания заказчика, который не является специалистом в области проектирования, на язык предметной области. Текст задания составляется в произвольной форме. Рекомендуемыми разделами технического задания являются: полное наименование сторон; цель и исходные данные; требования сторон к выполнению работ; технико-экономическое обоснование; патентно-лицензионное обоснование; количество этапов проведения работ в соответствии с календарным планом.
Скачать образец технического задания к договору подряда
В этом разделе необходимо наиболее полно и точно описать следующее.
1. Качественные, технические и функциональные характеристики. Качество товара должно соответствовать как требованиям законодательства, так и условиям контракта.
При этом заказчику при описании технических и качественных характеристик необходимо использовать стандартные показатели (требования, условные обозначения и терминологию). Для этого нужно руководствоваться обязательными требованиями, в частности, ГОСТами, СНиПами, гражданским законодательством (ст. 469, 721 ГК РФ). Например, требования к качеству пищевых продуктов установлены в Федеральном законе от 2 января 2000 г. № 29-ФЗ.
Если стандартные показатели невозможно взять из техрегламентов, стандартов (других законодательных актов о техническом регулировании), то нужно обосновать использование других показателей (требований, обозначений, терминологии).
Совет: Не стоит применять точные значения показателей. Лучше заменить их на условия с максимальными и (или) минимальными значениями, а также значениями, которые не могут меняться. То есть такие показатели, которые позволят участникам определить, соответствуют ли закупаемые товары (работы, услуги) установленным требованиям. Например, при закупке системного блока правильнее будет указать в техническом задании «Объем жесткого диска – не менее 500 Гб», а не «Объем жесткого диска – 500 Гб».
Об этом сказано в части 2 статьи 33 Закона № 44-ФЗ и разъяснено в письме Минэкономразвития России от 10 декабря 2014 г. № Д28и-2796.
2. Эксплуатационные характеристики (при необходимости).
3. Общее количество товаров (объем работ, услуг). Когда это сделать невозможно, заказчик может указать цену единицы работы (услуги).
4. Требования к упаковке. Это дополнительное требование. В техническом задании можно указать, например, что упаковка товара должна обеспечивать его сохранность при транспортировке и хранении.
5. Требования к безопасности объекта закупки.
6. Сроки и порядок поставки товара, выполнения работы, оказания услуги. В частности, нужно определить место поставки товара (выполнения работы, оказания услуги). При этом можно указать:
Это нужно для того, чтобы при подаче заявок участники имели представление, куда им нужно поставить товар (в каком месте оказать услугу или выполнить работу). Тогда при решении о подаче заявки они будут понимать, смогут ли выполнить заказ именно в этом месте. Заказчик, в свою очередь, обезопасит себя от риска, что выигравший закупку участник откажется от исполнения.
7. Гарантийный срок и гарантийное обслуживание (ч. 4 ст. 33 Закона № 44-ФЗ). Гарантийный срок нужно установить в днях, месяцах и годах.
После этого важно прописать условия гарантийного обслуживания, то есть полный перечень действий поставщика (подрядчика, исполнителя) по содержанию либо доведению объекта закупки до состояния, необходимого заказчику.
Например, при закупке кондиционера стоит установить срок гарантии не менее двух лет, в течение которых поставщик будет обязан бесплатно в течение трех дней с момента выявления поломки произвести осмотр оборудования и устранить выявленные нарушения в его работе.
8. Другие характеристики, являющиеся важными при описании конкретного вида товара, работы, услуги. Так, при покупке товара в техническом задании заказчику обязательно нужно указать, что он должен быть новым и свободным от прав третьих лиц. То есть никто не использовал и не ремонтировал товар ранее. В противном случае заказчик рискует получить товар, бывший в употреблении. Об этом сказано в пункте 7 части 1 статьи 33 Закона № 44-ФЗ.
Если нужно, в техническое задание также следует включить дополнительные требования к объекту закупки. Это могут быть:
Перечень сведений и требований может варьироваться в зависимости от каждого конкретного объекта закупки.
Пример описания объекта закупки
В соответствии с планом-графиком ГУ «Альфа» закупка партии бумаги для офисной техники запланирована на май 2016 года. При подготовке к проведению электронного аукциона контрактный управляющий А.С. Глебова приступила к подготовке документации о закупке, в частности, составила техническое задание .
Внимание! Данные об объекте, которые не отражены в техническом задании, участник вправе не учитывать и не выполнять.
Если товар (работа, услуга), который предложил победитель, не устраивает заказчика, но в то же время соответствует техническому заданию, он не вправе отказаться от заключения контракта.
Совет: В качестве источника информации стоит использовать:
Все это поможет отразить в техническом задании именно те характеристики товара (работы, услуги), которые необходимы заказчику.
Внимание! Если заказчик в документации о закупке укажет сведения, которые могут привести к ограничению количества участников, то возникнет риск понести административную ответственность. Так, на должностных лиц (контрактный управляющий, сотрудники контрактной службы) могут наложить штраф в размере 1 процента начальной (максимальной) цены контракта (НМЦК), но не менее 10 000 руб. и не более 50 000 руб. (ч. 4.1 ст. 7.30 КоАП РФ).
Внимание! При описании объекта закупки нельзя указывать наименования организаций-изготовителей, товарные знаки, знаки обслуживания и т. д. Это приведет к ограничению конкуренции и, как следствие, к нарушению законодательства о закупках. Исключения – техническое задание может содержать упоминание товарных знаков, если нужно:
Об этом сказано в пункте 1 части 1 статьи 33 Закона № 44-ФЗ.
Внимание! Нельзя в рамках одной закупки (одного лота) приобрести разноплановую продукцию (товары, работы, услуги), технологически и функционально не связанную между собой. Это приведет к ограничению количества участников. Так, например, в рамках одной закупки нельзя объединить услуги:
ФАС России разъяснила, что это относится к разным рынкам услуг. Ведь охранные организации, как правило, обслуживанием сигнализаций не занимаются. И если включить такие услуги в одну закупку, это приведет к ограничению количества участников.
Это следует из части 3 статьи 17 Федерального закона от 26 июля 2006 г. № 135-ФЗ и разъяснено в письмах Минэкономразвития России от 10 марта 2015 г. № Д28и-442, ФАС России от 21 мая 2014 г. № АЦ/20578/14.
Поэтому при планировании закупки и составлении документации заказчику нужно проанализировать этот момент и при необходимости:
В техническом задании нужно прописать требование о том, что участники закупки должны соответствовать законодательству России. Это может быть, например, информация о наличии лицензии на определенный вид деятельности.
Кроме того, в некоторых случаях Правительство РФ может установить дополнительные требования к участникам закупки, в частности, к наличию финансовых, материальных ресурсов, опыта работы, аналогичного предмету контракта (ч. 2 ст. 31 Закона № 44-ФЗ). Так, в постановлении Правительства РФ от 4 февраля 2015 г. № 99 есть дополнительные требования к участникам закупки на работы по сохранению объектов культурного наследия. Участник такой закупки должен представить сведения о контракте, который он исполнил без штрафных санкций в течение последних трех лет. Сумма такого контракта должна быть не менее 20 процентов НМЦК, на заключение которого проводят закупку.
Кто печаль твою разделит?
«Как писать техническое задание?!» - вопль отчаяния из уст т. н. начинающего «технического писателя», далее по тексту - техписа. Цитата из одного техписовского форума:
Вот она - страшная цена развала Союза. Вернемся к вопросу. При «раскладке» получается:
Третий - самый сложный. Ответы на указанные вопросы появятся в ходе изложения.
Цели и задачи статьиЦель статьи - облегчить жизнь совсем уж начинающим техписам.
Все, что когда-либо производилось, производится и будет производиться, делится (условно, разумеется) на:
Первым (специфицированным ) изделием, быть может, стал каменный топор. Или (рукотворный) глиняный черепок (неспецифицированное изделие ), позволяющий зачерпнуть водички в ручейке.
Первым программным изделием, реализованным на «железном носителе», стал, возможно, «музыкальный автомат» с вращающимся диском, утыканным колышками. Колышки в определенное время ударяли по определенному камертону. Таким образом, мелодия оказывалась запрограммированной, «зашитой» на металлическом носителе - настоящее программное изделие по ГОСТ 19.004-80. только что не промышленного. а кустарного производства. Увидеть это чудо чудное можно в Политехническом Музее г. Москвы.
Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор - «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» - 100-процентная автоматизация.
Далее - леденящая душу история.
История, леденящая душуи наказал тогда царь (заказчик ) - построить мельницу, да такую, чтобы от силы ветра работала, круче, чем у короля аглицкого («хотелки» заказчика), да чтоб на зависть всем буржуям (соответствующую современному уровню развития науки и техники и не уступающую аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам).
Приволокли опричники холопа государева, умепьца местного (разработчика ), кинули царю-батюшке в ноги. Бился лбом умелец о пол каменный - дык, оно, конечно! Сделаем, твое величество, все безоговорочно, точно, в срок и в полном объеме!
Настало время, прибыл царь на мельницу (приемка-сдача работ). Смотрит и диву дается - крылья крутятся, жернова жито молотят, мука сама собой в мешки сыплется! (Полное соответствие требованиям к функциям (задачам), выполняемым системой). Да возьми и запусти руку в мешок. (что не было предусмотрено ни техническим заданием. ни программой и методикой испытаний. поскольку не существовало таковых).
Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет. (Несоответствие производимой народно-хозяйственной продукции требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная. Технические условия ). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата.
В стародавние времена в отношениях сторон, заказчика и исполнителя (разработчика), равноправия было маловато. Чем-то, само-собой, отношения регламентировались. Возможно, готовились берестяные грамоты - прообразы современных договоров. Вряд ли в подобных договорах можно было учесть все, даже качество помола. Да и не было общепризнанных стандартов. нормативных документов. в широком смысле регламентирующих все аспекты взаимоотношений заказчика и исполнителя.
Издавались Указы, Распоряжения - «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).
Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит заказчик.
Современное состояниеи было придумано то, что сделали танк.
из серии «Армейские приколы»
Устав от «заказчицкого» беспредела, собрались (в последнюю четверть двадцатого века) исполнители (разработчики), организовали «авторские коллективы » и сделали танк - ГОСТ на структуру и содержание (содержимое. если быть более точным) документа под названием «техническое задание». Следует отметить, что авторские коллективы состояли, как правило, из людей технически грамотных, системно мыслящих, смотрящих в далеко будущее.
Может быть, все было иначе, но танк, в целом, получился хорош - что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.
Техническое задание и его назначениеБольшому Боссу, непосредственно взаимодействующему с заказчиком, техническое задание дает возможность избежать участи мастера-умельца (об этом ранее упоминалось неоднократно).
Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:
Крайнее утверждение - палка о двух концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.
В любом случае, способность грамотно разработать техническое задание (особенно - владение терминологией ) - показатель высокой квалификации разработчика.
Считаем, что первый вопрос (в первом же приближении) закрыт.
ГОСТы на технические заданияКуст есть совокупность веток, произрастающих из одной точки.
После тяжких трудов (и страданий) увидели свет, как минимум, три документа, соответствующие весьма условному делению продуктов человеческой жизнедеятельности:
Что общего в разделах перечисленных выше документов? Любое техническое задание должно содержать разделы, отражающие сведения:
Такова обобщенная структура разделов технического задания. Второй вопрос считаем закрытым.
Потребовалось разработать техническое задание на изделие - пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001-88 - кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо ТЗ автоматизированную систему - открываем ГОСТ 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. Требования к применению в системе языков программирования высокого уровня
В системе должны быть (именно должны - это же требования !) применены перечисленные ниже языки программирования высокого уровня:
Для тех, кто не прочувствовал, как построить фразу, ниже приведена схема ее построения:
Еще один пример - Требования к численности и квалификации персонала системы и режиму его работы. Настоятельно рекомендуется не забывать о детализации, за детализацию разделов технического задания никто никого еще не наказывал. Итак, пишем пункт технического задания:
«2.3.4. Требования к численности и квалификации персонала системы и режиму его работы»
«2.3.4.1. Требования к численности персонала»
(правильно формулируем текст подпункта - отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)
«Численность персонала должна удовлетворять требованиям :
2.3.4.2. Требования к квалификации персонала
Квалификация персонала должна обеспечивать эффективное функционирование технических и программных средств системы во всех режимах работы системы»
В пояснительной записке. в решениях по квалификации персонала, можно будет указать, что, на основании опыта эксплуатации более сотни ранее разработанных аналогичных систем, персонал должен иметь образование не ниже трех классов церковно-приходской школы. Сие утверждение порадует заказчика. Можно будет воспользоваться сверхдешевой рабочей силой. Но об этом в следующих статьях.
«2.3.4.3. Требования к режиму работы персонала
Режим работы персонала - трехсменный круглосуточный».
В подразделе предусмотрен также порядок подготовки персонала, контроля знаний и навыков. О составе - ни слова. И это правильно. Состав персонала, деление его на оперативный (пользователей ), эксплуатационный. ремонтный и пр. определяется при проектировании системы. Хотя никто не может запретить добавить в техническое задание Требования к составу персонала. Пожалуй, не стоит.
Простенько, но со вкусом. Чистая практика, без глубокого погружения в языковые тонкости. Детализация плюс анализ конктерных требований технического задания.
Формализация при подготовке текста технического заданияВозможно Двести Вариантов
Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»
Вернемся к примеру из предыдущего подраздела статьи.
«2.3.4.1. Требования к численности персонала
Численность персонала должна удовлетворять требованиям:
Лапша полнейшая, но формально все верно. Рекомендуется к применению, если невозможно конкретизировать какой-либо пункт технического задания. Если Большой Босс будет неудовлетворен, можно вежливо попросить его уточнить требования заказчика по данному пункту, дать более точную информацию. Это право техписа, не контактирующего непосредственно с заказчиком.
Можно добавить - «численность персонала уточняется на стадии «Технический проект»». Большой Босс будет поражен такой осведомленностью техписа (даже если и сам ни черта не знает) в части стадий и этапов создания автоматизированных систем. А если устно предложить Боссу добавить (потом) в пояснительную записку к проекту фразу - «на основе опыта эксплуатации более сотни ранее разработанных подобных систем численность персонала должна составлять 10 штатных единиц» - Босс будет сражен наповал. Можно смело готовить приказ о назначении техписа на должность системного аналитика (которая также отсутствует в общероссийском классификаторе). Или ждать, что подкинут дополнительную работенку, раз такой умный.
Штампы и унификация при подготовке текста технического заданияВы, бабы, красивы,
А я - без прикрас
Но, все же, мужчины
Ю. Рыбчинский, «Две сестры»
Унификация текста техзадания достигается применением штампов. Прежде всего следует усвоить простую истину - никогда, ни в одном документе не следует называть вещи своими именами .
Положим, разрабатывается универсальный преобразователь энергии солнечного излучения в энергию человеческого разума (Существование человеческого разума сомнительно. Разумно ли вешать на свою шею работу по созданию такого преобразователя? А вот рефлексы существуют объективно). Следует сразу, в разделе «Наименование изделия» обозвать этот самый преобразователь Изделием:
Наименование изделия - преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту - Изделие ).
И, в тексте - Изделие, Изделие, Изделие.
Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС - автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту - Система ).
И, в тексте - Система, Система, Система. Программа, Программа, Программа.
Итог - догнали и завалили сразу двух зайцев. Склонять-спрягать целую кучу слов не потребуется, да и читать построенное таким образом техническое задание будет проще.
Примечание от 05 февраля 2010 г. - При автоматизированной разработке техдокументации с применением single source приемлем как вариант со всякими склонениями-спряжениями, так и без них. К примеру, можно единожды создать переменную <ЗАО «Заказчик»> и вставлять в требуемые топики библиотеки документов - так иногда бывает удобнее.
Ниже - типовые перечни штампов, долго и успешно применяемых при разработке технических заданий (по основным разделам, выделено жирным):
Любая цель всегда подразумевает положительную динамику . изменение каких-либо показателей в лучшую сторону. К примеру, цель - повышение благосостояния всего советского народа (но не коммунизм: коммунизм - это мишень!). Цель - повышение удовлетворенности заказчика. Исключение составляют:
Встречаются еще и не такие фокусы. Пример из практики одного из самых маститых техписов (пример привел он сам, без всякого принуждения, в одном из техписовских форумов) - «программа позволяет. программа выполняет. программа делает. ». Милостивый государь, технический писатель! Программы еще нет, она еще не разработана, не проверена. не отлажена. не настроена. не испытана и не сдана заказчику, поэтому еще ничего не позволяет, не делает и не выполняет. Что за непобедимая совковая привычка выдавать желаемое за действительное?!
Если функция (как и процесс) автоматизированная. тогда именно обеспечивать возможность выполнения указанной функции. Пользователь может убрать стопор - мельница начнет молоть муку. Но пользователь может стопор и не убрать. В указанном случае мельница (система) будет находиться в режиме ожидания (простоя).
Если функция (как и процесс) автоматическая. тогда система должна именно обеспечивать выполнение функции. Функция автоматического резервирования базы данных запускается программными средствами системы (без участия персонала) по заданному расписанию и сливает базу данных на резервный носитель .
По части рамок задач. Задачи решаются. а функции выполняются. Чтобы решить задачу, надо выполнить ряд функций, процедур или операций. Иными словами - задача есть более крупный структурный элемент вопреки измышлениям ГОСТ 34.003-90 .
В ГОСТ 34.003-90 функция поставлена впереди задачи. задача является как бы частью функции. И это странно: еще в школе все решали задачки, вычисляя внутри них значения различных функций. И представьте себе, как дико звучала бы декларация: «Цель партии и правительства - повышение благосостояния всего советского народа. Ради достижения цели партия ставит перед собой функцию обеспечить к 2ххх году каждую семью отдельной квартирой». (Кстати, заниматься уборкой домов и квартир самостоятельно сейчас уже не модно и некогда особенно - для этого есть клининговые компании). Таким образом, функция является частью задачи, а не наоборот. Пусть даже вопреки священному ГОСТ 34.003-90.
В рамках задачи (или для решения задачи ) ведения базы данных программные средства системы должны обеспечивать выполнение перечисленных ниже функций :
И из предыдущего подраздела:
В результате применения штампов тескт технического задания становится унифицированным и формализованным. Никаких прикрас . И заказчик-мужчина никуда не уйдет от вас, милые девушки-техписы, поскольку требования технического задания будут для него прозрачны .
Перечни и нумерация разделовПеречни (маркированные или нумерованные списки) весьма уместны при подготовке текста технического задания. Нормальный человек способен воспринять (запомнить и безошибочно воспроизвести) от трех до девяти элементов перечня. Свыше девяти - признак гениальности.
В эксплуатационных документах. пожалуй, число элементов перечня следует снижать. В техническом задании - необязательно. Следует помнить, что техническое задание взаимоувязано с множеством иных документов, разрабатываемых на различных стадиях и этапах создания системы (да чего угодно).
«В рамках задачи (или для решения задачи ) ведения базы данных программные средства системы должны обеспечивать возможность выполнения перечисленных ниже функций :
«4.3.2.1. В рамках задачи (или для решения задачи ) ведения базы данных программные средства системы должны обеспечивать возможность выполнения перечисленных ниже функций :
Отличия, казалось бы, невелики. Но!
В первом случае, в документе «Программа и методика испытаний», придется написать «методика проверки выполнения системой автоматизированной функции добавления записей в таблицы базы данных».
Во втором случае, всего-навсего - «методика проверки выполнения п. 4.3.2.1(1) технического задания».
В протоколе испытаний. в первом случае - «требования технического задания к выполнению автоматизированной функции добавления записей в таблицы базы данных выполнены». Во втором случае - «требования п. 4.3.2.1(1) технического задания выполнены». Есть разница?
Что касается многоуровневой нумерации разделов, подразделов, пунктов и подпунктов - на практике указанные требования в подавляющем большинстве случаев обязательны.
По ГОСТ 2.105 списки следует «нумеровать» не цифрами, а буквами:
а) функция такая-то;
б) функция еще какая-то;
Вопрос не принципиальный, поскольку техническое задание нормоконтролю не подлежит (якобы. ). А вот последнее - глупость. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектные и эксплуатационные документы.
Примечание от 15.05.2011 г. - И на старуху бывает проруха. Что ж делать, если глаз давно уже «замылен»? Итак, «ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой нормоконтроля организации-разработчика ТЗ и, при необходимости, подвергнуто метрологической экспертизе». Это из п. 8 Приложения 1 ГОСТ 34.602-89. Век живи - век учись! (дураком останешься)
Чуть-чуть о метрологической экспертизе. Если в ТЗ имеется раздел «Метрологическое обеспечение. », то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений физических величин согласно ГОСТ 8.417. И только.
Связка «общие сведения, назначение и состав» в техническом заданииСвязка «общие сведения, назначение и состав» прекрасно показала себя не только при разработке технического задания. Связка подойдет для любых нехудожественных текстов описательного характера.
Пример - Требования к числу уровней иерархии и степени централизации системы. Вот что можно написать в указанном подразделе технического задания?
Любой человек начнет рефлекторно просматривать разделы ГОСТа на техническое задание, пытаясь найти хоть какую-то зацепку. Человек с опытом сразу вспомнит о назначении системы.
«2.2. Назначение системы»
Товарищ, непосредственно что-то там паяющий, налаживающий, программирующий. всегда сможет подсказать техпису, для чего система создается. В рамках своей компетенции, разумеется. Системотехник или Босс скажут больше. Допустим,
«Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:
Вот и все. Немного фантазии, и раздел готов:
«Система должна обладать иерархической структурой и включать в себя перечисленные ниже уровни иерархии:
Снова оба зайца - и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?
Дальше - применение связки.
«2.2.1. Уровень сбора данных
2.2.1.1. Общие сведения»
Какие-то общие сведения. Можно, к примеру, написать, что уровень характеризуется территориальной распределенностью - любая водичка сойдет, если она приблизительно соответствует.
Уровень сбора данных предназначен (еще один штамп):
В состав уровня сбора данных должны входить:
В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание - древовидное и иерархическое.
«2.2.2.3.1. Датчики такие-то
2.2.2.3.1.1. Общие сведения (о таких-то датчиках)
2.2.2.3.1.2. Назначение (таких-то датчиков)
2.2.2.3.1.3. Состав (таких-то датчиков)»
Главное - вовремя остановиться.
ПредостережениеПри разработке и документировании наибольший интерес представляют перечисленные ниже нормативные документы :
Не следует особенно увлекаться подобными «тематическими» ГОСТами, содержащими очень уж конкретные требования к компонентам системы. Характерная ошибка начинающих - «каналы связи должны удовлетворять требованиям ГОСТ такому-то». Это фатальная ошибка. Известно, что приемке-сдаче работ по созданию системы, изделия, программного изделия всегда предшествует проведение испытаний .
Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую подпись (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание утверждено и внести в него изменения или корректировки возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.
Настало время проведения испытаний системы (программы, изделия) на соответствие требованиям технического задания. Заказчик, само собой, потребует показать, что каналы связи соответствуют требованиям ГОСТа такого-то.
Что делать? Полбеды, если каналами связи занимался субподрядчик. готовый предоставить Большому Боссу сертификаты соответствия. Босс отмажется перед заказчиком и техпис будет жить (до очередного прокола). Но неприятный осадок в душе Большого Босса останется навсегда. Повышения ждать не приходится.
Совсем беда, если сертификатов нет. Придется Боссу платить (не предусмотренные бюджетом) денежки органу сертификации. дабы заполучить вожделенный сертификат, предъявить заказчику и закрыть работу. Такую ошибку техпису могут и не простить.
Короче, писать надо примерно так, русским по белому:
«В качестве каналов связи могут быть применены (использованы):
Ни в коем случае нельзя указывать скорость обмена данными канала связи, т.е. конкретику. Если канал связи будет реализован на базе Ethernet, а в техническом задании будет явно указана скорость обмена не ниже 1200 бит/с, заказчик имеет полное право заставить исполнителя провести испытания по полной программе. Даже в такой, явно абсурдной ситуации.
ЗаключениеИтак, вспомним еще разок ключевые моменты:
Учебно-тренировочное техническое задание на программу было разработано автором с применением перечисленных в статье практических приемов.
В заключении можно дать ряд дополнительных советов:
Внимание! Форум закрыт по причине потери базы данных при попытке обновления движка сайта. Задать вопрос можно с использованием формы Контакты .
