Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Как писать техническое задание?!
|
В разделе: http://www.authorit.ru/HTML/dd_pub/dd_write_tz.htm История Современное состояние Практические приемы Заключение |
|
|
Твой мир пуст. |
|
|
Кто печаль твою разделит? |
|
|
М. Пушкина |
«Как писать техническое задание?!» - вопль отчаяния из уст т.н. начинающего «технического писателя», далее по тексту - техписа.
Цитата из философтовского форума:
Вот она - страшная цена развала Союза. Вернемся к вопросу. При «раскладке» получается:
Третий - самый сложный. Частично ответы на указанный вопрос изложены здесь, частично появятся в ходе изложения.
Цели и задачи статьи:
Цель статьи - облегчить жизнь совсем уж начинающим техписам.
Задачи статьи:
История
|
В разделе: История, леденящая душу Выводы |
Все, что производилось, производится и будет производиться, делится (весьма условно):
Первым изделием, быть может, стал каменный топор. Или (рукотворный) глиняный черепок, позволяющий зачерпнуть водички в ручейке. Первым программным изделием, реализованным на «железном носителе», стал, возможно, «музыкальный автомат» с вращающимся диском, утыканным колышками. Колышки в определенное время ударяли по определенному камертону. Таким образом, мелодия оказывалась запрограммированной, «зашитой» на металлическом носителе - настоящее программное изделие по ГОСТ 19.004-80, только что не промышленного, а кустарного производства.
Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор - «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» - 100% автоматизация.
Далее - леденящая душу история.
История, леденящая душу
...и наказал тогда царь (Заказчик) - построить мельницу, да такую, чтобы от силы ветра работала, круче, чем у короля аглицкого («хотелки» Заказчика), да чтоб на зависть всем буржуям (соответствующую современному уровню развития науки и техники и не уступающую аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам).
Приволокли опричники холопа государева, умепьца местного (Исполнителя), кинули царю-батюшке в ноги. Бился лбом умелец о пол палат каменных - дык, оно, конечно! Сделаем, твое величество, все безоговорочно, точно, в срок и в полном объеме.
Настало время, прибыл царь на мельницу (приемка-сдача работ). Смотрит и диву дается - крылья крутятся, жернова жито молотят, мука сама-собой в мешки сыплется! (Полное соответствие требованиям к функциям (задачам), выполняемым системой). Да возьми и запусти руку в мешок... (что не было предусмотрено ни техническим заданием, ни программой и методиками испытаний, поскольку не существовало таковых).
Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой продукции требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная. Технические условия). Схватили мужика опричники, да долбанули буйну его голову топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата...
Выводы
В стародавние времена в отношениях сторон, Заказчика и Исполнителя, равноправия было маловато. Чем-то, само-собой, отношения регламентировались. Возможно, готовились берестяные грамоты - прообразы современных Договоров. Вряд ли в подобных договорах можно было учесть все, даже качество помола. Да и не было общепризнанных стандартов, документов, в широком смысле регламентирующих все аспекты взаимоотношений Заказчика и Исполнителя.
Издавались Указы, Распоряжения - «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).
Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит Заказчик.
Современное состояние
|
В разделе: Техническое задание и его назначение ГОСТы на технические задания |
|
|
...и было придумано то, что сделали танк... |
|
|
из серии «Армейские приколы» |
Устав от «заказчицкого» беспредела, собрались (в последнюю четверть двадцатого века) исполнители (разработчики), организовали «авторские коллективы» и сделали танк - ГОСТ на структуру и содержание документа под названием «техническое задание». Следует отметить, что авторские коллективы состояли, как правило, из людей технически грамотных, системно мыслящих, смотрящих в будущее.
Может быть, все было иначе, но танк, в целом, получился хорош - что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.
Техническое задание и его назначение
Большому Боссу, непосредственно взаимодействующему с Заказчиком, техническое задание дает возможность избежать участи мастера-умельца (об этом ранее упоминалось неоднократно).
Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:
Крайнее утверждение - палка о двух концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.
В любом случае, способность грамотно разработать техническое задание - показатель высокой квалификации разработчика.
Считаем, что первый вопрос (в первом же приближении) закрыт.
ГОСТы на технические задания
|
|
Куст есть совокупность веток, произрастающих из одной точки. |
|
|
Военная мудрость |
После тяжких трудов (и страданий) увидели свет, как минимум, три документа, соответствующие весьма условному делению продуктов человеческой жизнедеятельности:
Примечание 1. Существуют и иные отечественные ГОСТы, содержащие требования к содержанию и оформлению документа «Техническое задание». Сей факт обусловен спецификой предметных областей. Перечисленная тройка была и остается общей для всех предметных областей.
Примечание 2. Техническое задание было и остается основополагающим документом, той самой «точкой опоры», из которой все и произрастает.
Что общего в разделах перечисленных выше документов? Любое техническое задание должно содержать разделы, отражающие сведения:
Такова обобщенная структура разделов технического задания. Второй вопрос считаем закрытым.
Потребовалось разработать техническое задание на изделие - пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001-88 - кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо ТЗ автоматизированную систему - открываем ГОСТ 34.602-89. На программу - ГОСТ 19.201-78.
Покажем необходимый минимум практических приемов, позволяющих даже самому начинающему техпису немедленно приступить к разработке содержимого разделов технического задания и достичь приемлемых результатов.
Практические приемы
|
В разделе: Детализация Шаблонное построение фраз Формализация при подготовке текста технического задания Штампы и унификация при подготовке текста технического задания Перечни и нумерация разделов Связка «общие сведения, назначение и состав» в техническом задании Предостережение |
Практические приемы разработки технического задания буквально выстраданы на основе опыта взаимодействия с Заказчиком как самого автора, так и его старших товарищей (за что низкий им поклон, почет и уважение во веки веков).
Самый первый прием - создание шаблонного документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на систему, скачивается htm-файл (можно и отсюда), затем просто открывается вордом и сохраняется в формате dot.
Электронные версии ГОСТ, хранящиеся по указанной ссылке, в целом соответствуют официальным бумажным версиям. Сомнительные моменты проверялись автором неоднократно.
Детализация
Детализация - один из основополагающих приемов. Кое кто предпочитает наукообразный термин, заимствованный у буржуев - декомпозиция. Речь пойдет о детализации структуры разделов ГОСТ на техническое задание.
Вспомним родительское - «пока ты не разложишь все по-полочкам, «ничего у тебя не получится (мама)» или «ни хрена у тебя не выйдет (папа)». И мама, и папа, безусловно, были и остаются правы. Несложную задачку по физике решить невозможно, пока векторы сил не будут разбросаны по осям координат. Тройной интеграл взять невозможно, пока не будут поочередно взяты интегралы по dx, dy и dz. За исключением случая, когда «интеграл настолько прост, что взять его можно даже без dx».
Произвольно выбранная цитата из ГОСТ 34.602-89:
«2.6.3.3. Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога».
Здорово, да? Придется разгрести эту свалку. Итак, явным дроблением создаются дополнительные подпункты технического задания (это и можно, и нужно делать).
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. Требования к способам организации диалога
(текст требования)
Увеличился объем технического задания? А следует ли экономить бумагу? Имеется и еще одна мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги - чище з@@@@ца».
Требования к лингвистическому обеспечению стали выглядеть понятнее?
Примечание 3. Термины «понятность», «понимаемость» (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 штатных единиц» - Босс будет сражен наповал. Можно смело готовить Приказ о назначении техписа на должность системного аналитика (которая также отсутствует в общероссийском классификаторе). Или ждать, что подкинут дополнительную работенку, раз такой умный.
Штампы и унификация при подготовке текста технического задания
|
|
Вы, бабы, красивы, |
|
|
А я - без прикрас |
|
|
Но, все же, мужчины |
|
|
Уходят от вас... |
|
|
Ю. Рыбчинский, «Две сестры» |
Унификация текста технического задания достигается применением штампов. Прежде всего, следует усвоить простую истину - никогда, ни в одном документе не следует называть вещи своими именами.
Положим, разрабатывается универсальный преобразователь энергии солнечного излучения в энергию человеческого разума (Существование человеческого разума сомнительно. Разумно ли вешать на свою шею работу по созданию такого преобразователя? А вот рефлексы существуют объективно). Следует сразу, в разделе «Наименование изделия» обозвать этот самый преобразователь Изделием:
Наименование изделия - преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту - Изделие).
И, в тексте - Изделие, Изделие, Изделие...
Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС - автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту - Система).
И, в тексте - Система, Система, Система... Программа, Программа, Программа...
Итог - догнали и завалили сразу двух зайцев. Склонять-спрягать целую кучу слов не потребуется, да и читать построенное таким образом техническое задание будет проще.
Ниже - типовые перечни штампов, долго и успешно применяемых при разработке технических заданий (по основным разделам, выделено жирным):
Любая цель всегда подразумевает положительную динамику, изменение каких-либо показателей в лучшую сторону. К примеру, цель - повышение благосостояния всего советского народа. Цель - повышение удовлетворенности Заказчика. Исключение составляют:
Встречаются еще и не такие фокусы. Пример из практики одного из самых маститых техписов (пример привел он сам, без всякого принуждения, в «философтовском» форуме) - «программа позволяет... программа выполняет... программа делает...». Милостивый государь, технический писатель! Программы еще нет, она еще не разработана, не прошла испытаний и не сдана Заказчику, поэтому еще ничего не позволяет, не делает и не выполняет. Что за непобедимая совковая привычка выдавать желаемое за действительное?!
Если функция автоматизированная, тогда именно обеспечивать возможность выполнения указанной функции. Пользователь может убрать стопор - мельница начнет молоть муку. Но пользователь может стопор и не убрать. В указанном случае мельница (система) будет находиться в режиме ожидания.
Если функция автоматическая, тогда система должна именно обеспечивать выполнение функции. Функция автоматического резервирования базы данных запускается программными средствами системы (без участия персонала) по заданному расписанию и сливает базу данных на резервный носитель.
По части рамок задач. Задачи решаются, а функции выполняются. Чтобы решить задачу, надо выполнить ряд функций, процедур или операций. Иными словами - задача есть более крупный структурный элемент. Пример.
В рамках задачи (или для решения задачи) ведения базы данных программные средства системы должны обеспечивать выполнение перечисленных ниже функций:
И из предыдущего подраздела:
В результате применения штампов тескт технического задания становится унифицированным и формализованным. Никаких прикрас. И Заказчик-мужчина никуда не уйдет от вас, милые девушки-техписы, поскольку требования технического задания будут для него прозрачны.
Перечни и нумерация разделов
Перечни (маркированные или нумерованные списки) весьма уместны при подготовке текста технического задания. Нормальный человек способен воспринять (запомнить и безошибочно воспроизвести) от трех до девяти элементов перечня. Свыше девяти - признак гениальности.
В руководствах, пожалуй, число элементов перечня следует снижать. В техническом задании - необязательно. Следует помнить, что техническое задание взаимосвязано с множеством иных документов, разрабатываемых на стадиях и этапах создания системы (да чего угодно).
Случай первый.
В рамках задачи (или для решения задачи) ведения базы данных программные средства системы должны обеспечивать выполнение перечисленных ниже функций:
Случай второй.
4.3.2.1. В рамках задачи (или для решения задачи) ведения базы данных программные средства системы должны обеспечивать выполнение перечисленных ниже функций:
Отличия, казалось бы, невелики. Но!
В первом случае, в документе «Программа и методики испытаний», придется написать «методика проверки выполнения системой автоматизированной функции добавления записей в таблицы базы данных».
Во втором случае, всего-навсего - «методика проверки выполнения п. 4.3.2.1(1) технического задания».
В Протоколе испытаний, в первом случае - «требования технического задания к выполнению автоматизированной функции добавления записей в таблицы базы данных выполнены».
Во втором случае - «требования п. 4.3.2.1(1) технического задания выполнены».
Есть разница?
Что касается многоуровневой нумерации разделов, подразделов, пунктов и подпунктов - на практике указанные требования в подавляющем большинстве случаев обязательны.
По ГОСТ 2-105-95 списки следует «нумеровать» не цифрами, а буквами:
а) функция такая-то;
б) функция еще какая-то;
в) и так далее.
Вопрос непринципиальный, поскольку техническое задание нормоконтролю не подлежит. А вот последнее - глупость. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектно-сметные и эксплуатационные документы.
Связка «общие сведения, назначение и состав» в техническом задании
Связка «общие сведения, назначение и состав» прекрасно показала себя не только при разработке технического задания. Связка подойдет для любых нехудожественных текстов описательного характера.
Пример - Требования к числу уровней иерархии и степени централизации системы. Вот что можно написать в указанном подразделе технического задания?
Любой человек начнет рефлекторно просматривать разделы ГОСТ на техническое задание, пытаясь найти хоть какую-то зацепку. Человек с опытом сразу вспомнит о назначении системы.
2.2. Назначение системы
Товарищ, непосредственно что-то там паяющий, налаживающий, программирующий, всегда сможет подсказать техпису, для чего система создается. В рамках своей компетенции, разумеется. Системотехник или Босс скажут больше. Допустим,
Система должна обеспечивать выполнение (возможность выполнения) перечисленных ниже задач:
Вот и все. Немного фантазии, и раздел готов:
Система должна обладать иерархической структурой и включать в себя перечисленные ниже уровни иерархии:
Снова оба зайца - и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?
Дальше - применение связки.
2.2.1. Уровень сбора данных
2.2.1.1. Общие сведения
Какие-то общие сведения. Можно, к примеру, написать, что уровень характеризуется территориальной распределенностью - любая водичка сойдет, если она приблизительно соответствует.
2.2.2.2. Назначение
Уровень сбора данных предназначен (еще один штамп):
2.2.2.3. Состав
В состав уровня сбора данных должны входить:
В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание - древовидное и иерархическое.
Далее.
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 бит/с, Заказчик имеет полное право заставить Исполнителя провести испытания по полной программе. Даже при таком явном абсурде.
Заключение
Итак, вспомним еще разок ключевые моменты:
Учебно-тренировочное техническое задание на программное изделие было разработано автором с применением перечисленных в статье практических приемов.
В заключении можно дать ряд дополнительных советов:
Информация об авторских правах - все товарные знаки и торговые марки, упомянутые в материалах сайта, принадлежат законным владельцам. Все материалы, опубликованные на сайте без указания авторства в явном виде, принадлежат исключительно владельцам домена authorit.ru. Все материалы, опубликованные на сайте с явным указанием авторства, принадлежат исключительно авторам, предоставившим указанные материалы. Убедительная просьба ко всем, кто в коммерческих или иных целях намерен использовать материалы сайта - поимейте совесть и ссылайтесь на первоисточник в своих Интернет-ресурсах.