Чтз и тз в чем разница
Частные технические задания
Понятие ТЗ
Техническое задание — исходный документ на проектирование технического объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.).
В соответствии с Гражданским кодексом, проектирование — это один из видов подрядных работ, результатом которых является продукция (проект), то есть комплект проектной документации на другой продукт (объект проектирования). Проект предназначен для создания объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых этот объект был разработан.
Слово «проект» в области деятельности «управление проектами» и «управление проектированием» применяется в значении «программа», «план действий», «комплекс работ».
Участников проектных работ разделяют на потребителей (заказчиков этих работ) и поставщиков (исполнителей этих работ, подрядчиков). Исполнителя-специалиста называют проектировщиком или разработчиком. Поставщиком, как и потребителем продукции, может быть организация (юридическое лицо) или конкретный человек (физическое лицо).
Объектом проектирования может быть материальное устройство, или выполнение работы, или оказание услуги, например, сооружение или промышленный комплекс, техническое устройство (прибор, машина, аппарат), система управления,информационная система
, нормативная документация (например, стандарт) и т. д.
Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения.
Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков.
Место ТЗ в структуре проектирования
Проектирование— это процесс (разработки проекта), который обладает определённой структурой, то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.
Стадии проектирования регламентированы стандартами. Это следующая последовательность:
· Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
· Стадии рабочего проекта.
Решение любой задачи начинается с её осмысления и уточнения исходных данных. Те (технические) требования, которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически четкими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, это и есть главная цель ТЗ, обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком. Фактически это означает, что работа исполнителя над проектом уже началась.
В машиностроении этот этап иногда называют внешним проектированием.
Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.
Частные технические задания
В процессе проектирования сложного объекта (системы), требующего участия нескольких разработчиков, создаются частные технические задания на подсистемы.
В соответствии с полученными техническими требованиями разработчик системы формирует ТЗ и на стадии технического предложения выполняет декомпозицию объекта и подготавливает частные технические задания на подсистемы. После выполнения всех этапов технического предложения разработчик согласовывает и утверждает его у заказчика системы, при этом они совместно уточняют исходное ТЗ.
После утверждения технического предложения разработчик системы распределяет по соисполнителям частные ТЗ, на основании которых могут вырабатываться частные ТЗ для подсистем более низких уровней. Если подсистемы второго уровня отсутствуют, то техническое предложение для подсистем часто не выполняется, поскольку практически было завершено на уровне системы.
По завершении этапа распределения ТЗ разработчики системы и её подсистем приступают к выполнению стадии эскизного проекта. Проработка структуры на этой стадии ведется при тесном взаимодействии всех разработчиков. В процессе такой работы увязываются между собой отдельные части, согласовываются основные параметры проектируемого объекта. Качество проектирования зависит от широты видения разработчиком проблемы, то есть от его кругозора и способности учесть все связи рассматриваемого объекта, и наличия у него знаний, захватывающих смежные области. В процессе эскизного проектирования и согласования частных решений с общим возможна корректировка ТЗ.
После завершения эскизного проектирования, согласования и утверждения полученных технических решений у заказчика переходят к стадии технического проектирования. Здесь выполняется вся основная конструктивная проработка объекта и его частей. Возможно уточнение технических решений с возвратом на предыдущие стадии. Техническое проектирование ведется при тесном взаимодействии всех разработчиков.
Необходимость ТЗ
Исходное задание выдаётся заказчиком. Основными причинами, заставляющими его обратиться к разработчику, являются отсутствие у заказчика соответствующих специальных знаний либо ограниченность его ресурсов (нехватка времени на решение задачи, необходимого количества людей, оборудования).
Задание может быть чётко определено, например, когда всю работу ведет один человек, либо оно выдано авторитетным специалистом, либо не может быть подвергнуто сомнению (госзаказ). Но чаще оно формулируется в общих чертах на языке потребителя-неспециалиста, далёким от языка разработчика и терминов предметной области. Неопределенные требования вызывают неуверенность у всех участников работ, так как допускают различное толкование требований и не позволят объективно оценить качество разработанного изделия. Также, разработчик должен понимать, что заказчик может не знать (или знает частично) специальных требований, что не снимает с разработчика ответственности и обязательности выполнения требований надзорных органов независимо от их наличия в задании. Таким образом, не только заказчик, но и разработчик (исполнитель) являются ответственными за постановку целей разработки и полезность ее результата.
Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, «как корабль назовешь, так он и поплывет»).
Специалисты считают, что грамотное ТЗ — это более 50 % успеха в решении задачи, а время, затраченное на подготовку ТЗ, — одно из лучших вложений, которые фирма может сделать в период проектирования. Недаром составление ТЗ поручается ведущим специалистам — главным конструкторам, руководителям проектов и работ и т. п.
Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!
Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:
· представить (вообразить) готовый продукт,
· выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний),
· уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
· осознать, что именно ему нужно,
· в том числе, опираясь на существующие на данный момент технические возможности и свои ресурсы,
· требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
· понять суть задачи, показать заказчику «технический облик» будущего изделия, программного продукта илиавтоматизированной системы
· спланировать выполнение проекта и работать по намеченному плану,
· отказаться от выполнения работ, не указанных в ТЗ.
Содержание ТЗ
Регламентированное ТЗ
Несмотря на свою важность, содержание ТЗ мало регламентировано нормативными документами (ГОСТ, ОСТ).
· ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению[5] (кратко изложено содержание ТЗ);
· ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы[6] (достаточно подробно изложены состав и содержание ТЗ);
· ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления[1] (приведен порядок построения ТЗ).
В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:
· ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно-конструкторских работ. Основные положения.
· Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома16.09.2004 №95. Техническое задание на научно-исследовательскую работу[7] (приложен образец технического задания на разработку в рамках ГОЗ)
ТЗ и ЧТЗ
Покупай брат
Зачем проходить экзамен на знание нормально машина водить, если ты уже знаешь нормально машина водить?
Уточнение в свете последних событий
Про холодец
Знаете, когда-то давно, в моём сопливом детстве, мы держали скотину.
На семью из пяти человек, в самом начале зимы мы забивали двух свиней.
Это как минимум 200 кг мяса, не считая голов, ливера и копыт.
Гдет в конце декабря мы резали бычка или тёлку.
Это ещё 150-170 кг чистого мяса.
Жена частенько меня подъёбывает по поводу моего «голодного детства»..
Конечно, можно было зайти домой и тебя бы накормили, но ведь потом тебя на улицу не выпустят..
Ладно, сейчас разговор не об этом..
После разделки туш, оставались три головы, 12 ног, 12 мотолыжек, два свинячих хвостика и один бычий хуй хвост.
В один из дней отец говорил:
— 4iLiSH, сходи в сарай. Наруби там на холодец.
К тёще поедем, холодца сварим, тестя угостим.
Видя нас на пороге, бабушка всегда расплывалась в самой искренней улыбке.
Да, во времена моего детства, газа не было и зимой печь топилась круглосуточно.
Вставай, пошли. Поможем немножко старикам..
— Ну ты чего к ребёнку пристал?! Тебе сказали уже, не надо ничего, мы сами всё сделаем! Сиди, внучок! Вот, ещё пирожок возьми..
— Нет, ну правда, пошто мальчишку тиранить, пусть с бабкой сидит, сами управимся..
Отец же, не обращая внимания на пламенные речи деда с бабкой просто смотрел на меня.
Я нехотя поднимался из-за стола и под причитания бабушки о том как сильно заебали её внука физическими нагрузками мы выходили из дома во двор.
Там мы втроём, я, мой батя и мой дед, чистили снег.
Высказывания отца, типа:
— Смотри, дед, стареешь.. Внук-то, быстрее тебя лопатой орудует..
Придавали мне сил и я кидал снег как тот роторный снегоуборщик.
Закончив кидать снег, мы шли колоть дрова.
Дед старый, пусть он и носит! Я же сильнее деда, я и буду колоть.
Дед с отцом улыбались и после недолгих попыток уговорить меня на работу полегче, соглашались с тем что я уже взрослый мужик.
Отец колол чурбаки на плахи. Я колол плахи на поленья, дед носил их в сарай.
Иногда мы заходили домой погреться, отдохнуть, покушать или попить чай.
Бабушка тщетно взывала к совести двух здоровых мужиков, которые маленького мальчишку уже совсем заморили.
Отец с дедом улыбались.
— А мы разве его заставляем?
Если устал, так пусть сидит и отдыхает, мы сами доделаем.
Закончив колоть дрова, я еще успевал помочь деду перетаскать их в сарай.
А потом мы садились за стол разбирать сварившийся к тому времени холодец.
Мы все вместе отделяли мясо от костей.
Бабушка, отрезав кусок хлеба и отщипнув самый смачный кусочек мяса протягивала мне.
— Держи. Больше всех сегодня работал. Устал?
Я мотал головой и говорил что не устал.
Игрушек, вон, полный магазин..
А мы раньше вот эти кости, от холодца, сушили и потом ими в бабки играли..
Отец разливал из привезённой бутылки в две рюмки и они с дедом долго сидели за столом, обсуждая совершенно неинтересные мне вопросы.
Глаза мои постепенно закрывались и бабушка уводила меня в соседнюю комнату, на диван.
А утром, на столе, стоял холодец.
Не знаю кто как, а я холодец люблю.
Вот и сейчас, закусил рюмаху кусочком холодца, прикрыл на секунду глаза, и на меня нахлынули эти воспоминания.
Наглость
Требования
Немного позитива в ленту
Москалї
Только вот давайте без политоты хоть здесь.
Ответ на пост «Разница»
В далеком 2017 году мы с подружкой решили проехаться по странам бывшей Югославии.
Ехали подготовленные, с обновленной повесткой, в частности, гласившей: в Сербии надо есть.
И вот, Белград. Жаркое утро, нам предстоит долгий туристический день поглощения культуры и всего такого. А значит, надо позавтракать! В те времена моя подруга очень увлекалась тренировками с железом, так что ее рацион отличался большими объемами. На завтрак она шла одухотворённая, с вожделеющим желудком.
Мы сели в ресторанчике на главной улице. Официант принес нам меню, которое мы начали пристально изучать. Варианты предлагались достойные, но привычки и фото блюд берут свое, захотелось нам отведать всего-то омлета и блинчика с ветчиной. Точнее, моей оголодавшей подружке. Я потратила минут 15, объясняя, в какой стране мы находимся, что нельзя верить фото, что еда будет огромная, что мы умрем недостойно от заворота кишок, ни одной басни так и не написав.
Короче, приносят блин с ветчиной. Точнее, БЛИН. БЛИНИЩЕ. Сложенный в 4 раза треугольником, где КАЖДЫЙ слой содержит сметану, сыр и ветчину. Поймите меня правильно, это было божественно. Но он рассчитан на целый взвод. Может, на роту. А нас тут две! Но что делать, долг зовет, а мы дамы ответственные.
. подумали мы, но нам вынесли омлетище. С кучей свежих овощей. С сыром. Пушистый нежный омлет, желтый как солнце, вкусный как запретный плод.
Я не знаю, как мы ходили в +40С по улицам, когда объем наших желудков превышал объемы наших туловищ. И все же, мы справились, переварили, и мало того, к вечеру начали нуждаться в пропитании как ни в чем не бывало.
Вечером снова пошли в ресторан. По-моему, даже в тот же самый. Да, прежде чем начнете осуждать, имейте в виду: мы поели местных блюд в другие дни, но тогда, едва прибыв в страну, хватало и культурного шока. В том числе, от размеров порций.
Через полчаса попыток все доесть я обнаружила ласково закинутый целиком кусман пармезана. Варианта три:
1) шеф-повар использовал настолько огромный кусок сыра, что этот ему показался недостойным внимания,
2) он задолбался натирать столь гигантский кусок,
3) я унизила его своим заказом ризотто вместо нормальной человеческой плескавицы. В этом случае, спасибо, что не в рожу, иначе было бы больно.
Моя коллега по чревоугодию никак не могла докопаться до дна тарелки, обнаруживая все новые и новые куски куры. Одному богу известно, сколько куриц погибло ради этого блюда. Посчитать мы не смогли.
Бросив тщетные попытки не оставлять ничего на тарелках, как учили в постсоветском детстве, мы позвали официанта, чтобы попросить завернуть остатки с собой. Его лицо стоило запечатлеть! Это была смесь искреннего беспокойства за наше здравие (вероятно, умственное), отвращения к нашему слабоволию и отчаяния, что с едой могло быть что-то не то. Мы пару минут внушали, что все в полном порядке, нам все очень понравилось и мы просто ходим забрать остатки с собой.
Когда он вернулся с контейнерами, его лик был омрачен полнейшим смятением. Возможно, мы нарушили культурные нормы. Но это не мы, а наши подло сжавшиеся желудки, честное слово.
Утром в картошке нашли еще три куриных ноги. Ризотто я так и не доела.
Документирование в разработке ПО
INTRO
Добрый день, уважаемое сообщество.
Позвольте представиться. Я бизнес-аналитик, уже десять лет работаю в области разработки заказного программного обеспечения, в последнее время совмещаю роли аналитика и руководителя проектов.
Одним из болезненных вопросов в разработке ПО всегда был и остаётся процесс документирования этой самой разработки. Вам доводилось приходить на проект, который делают уже пару лет, но, при этом, вы никак не можете с ним разобраться, потому что из документов есть одно техническое задание, да и то написано в самом начале и не отражает и половины функционала системы? Мне доводилось. И это, честно говоря, очень печальное и байтораздирающее зрелище.
Поэтому на всех своих проектах я стараюсь изначально построить процесс так, чтобы неопознанного и неописанного функционала не было, все члены команды вовремя получали актуальную информацию и вообще был мир во всём
Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.
1. Документация обеспечивает «общее пространство» проекта. Любой участник в любой момент времени может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы.
2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в Use Case №12», чем «о стрёмном баге в той фигне, которую Вася месяц назад делал».
3. Документирование позволяет четко разграничить зоны ответственности между участниками проекта.
4. Только тщательно описанные требования могут быть проверены на полноту и непротиворечивость. «Наколенные записки» — прямой и очень быстрый путь к тому, что границы проекта расползутся резвыми тараканами, а функционал, задуманный вначале, не будет монтироваться с возникающими в процессе «хотелками» заказчика.
Для себя я выработала набор базовых правил, которые позволяют эффективно документировать, планировать и контролировать разработку в комфортных для всех участников условиях.
1. Документация не должна быть избыточной и объемной. Мы пишем документы не за-ради приятного процесса постукивания по клавишам, а для того, чтобы их использовать в работе. Избыточное количество текста – раздражает и затрудняет восприятие.
2. Вся схема документирования проекта должна быть взаимоувязанной и логичной. Если в схеме существует документ, который не связан ссылкой с каким бы то ни было другим документом, то его можно безболезненно из схемы исключить.
3. Вся оценка трудозатрат должна производиться только на основании описанных атомарных задач. Сложно оценить разработку «функционала подсистемы ввода данных», гораздо проще оценить задачи «разработка формы ввода данных марсиан» и «разработка фильтра списка марсиан». Чем мельче оцениваемый элемент – тем точнее будет агрегированная оценка.
4. Всегда необходимо формировать списки оповещения заинтересованных участников. Разработчик, узнающий о необходимости доработки за три дня до релиза – это зло и подлейшая подлость, аналитик, втихаря поменявший требования и не уведомивший всех заинтересованных участников о необходимости доработки – последняя свинья, а РП, допустивший такую ситуацию – чума, холера и неприятный человек, который не справляется со своими обязанностями.
Я предлагаю на суд уважаемого сообщества схему документирования, которая кажется мне удобной, логичной и правильной. И – да, это работает.
Итак, какие типы документов используются в схеме.
1. Техническое задание.
2. Частное техническое задание (опционально).
3. Сценарий использования (Use Case).
4. Сценарий тестирования (Test Case).
5. Отчет об ошибке (Bug Report).
6. Руководство пользователя.
7. Руководство администратора (опционально).
На рисунке ниже — схема связи между этими документами. 
Изначально, при обследовании, формируется Большое Техническое задание.
Оно включает в себя:
• словарь терминов предметной области;
• описание предметной области;
• описание ролевой системы;
• описание функциональных требований;
• описание нефункциональных требований.
Описание требований в этом документе фиксируется на «верхнем уровне», то есть мы описываем не конкретные действия, а только необходимые функции. Требования оптимально разбивать на смысловые группы по подсистемам.
Например, мы описываем подсистему «Администрирование» с функциями «Создание карточки пользователя», «Удаление карточки пользователя», «Редактирование карточки пользователя». Это требования верхнего уровня, ниже в ТЗ опускаться смысла нет.
В случае, если система большая, разумно сделать Частные технические задания на каждую подсистему.
ЧТЗ должны содержать:
• ссылку на пункт ТЗ;
• максимально подробную информацию по каждой функции;
• список UseCases для функции.
Таким образом реализуется преемственность документов, что позволяет, во-первых, унифицировать их форму, во-вторых – частично реализовать повторное использование, то есть снизить затраты времени на «писанину».
Например, мы формируем ЧТЗ на всё ту же подсистему «Администрирование». Оно будет содержать описание функции: «Создание карточки. Необходимо реализовать следующий функционал: вызов карточки посредством кнопки «Создать», интерфейс карточки, содержащий следующий набор полей, сохранение карточки посредством кнопки «Сохранить», отмену сохранения посредством кнопки «Отмена»».
Use Case
Use Case — суть вариант использования, он описывает все действия, которые пользователь может произвести, и реакцию системы на эти действия.
Каждый Use Case должен быть привязан к пункту ЧТЗ.
Наиболее оптимальным, на мой взгляд, является формат описания, включающий в себя:
• Макет экрана. Макеты можно делать и сложные, «кликабельные», но, по опыту, хватает «проволочной диаграммы», сделанной с помощью Visio или аналогичного инструмента. Если на форме предполагается использование модальных окон, то они тоже должны быть прорисованы, нижеописанные таблицы для них должны дублироваться.
• Диаграмму действий экрана, в графическом виде описывающую алгоритм работы функции.
• Таблицу с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
• Таблицу с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.
Также возможно небольшое общее описание функционала но, как правило, оно просто не нужно.
Test Case
Test Case, что вполне самоочевидно, должен содержать описание тестовых сценариев.
В идеале, каждый такой документ привязывается к соответствующему Use Case, но бывает так, что логично объединить несколько Use Cases в один Test Case.
Оптимальным вариантом формата описания является таблица, содержащая в одном столбце описание атомарной операции, влекущей ответное действие системы, во втором – описание правильной реакции системы. Описывать, к примеру, процесс ввода текста в текстовое поле не нужно, а вот проверку валидности данных при сохранении (щелчке по кнопке «Сохранить») – обязательно.
Bug Report
Ещё немного побуду кэпом: Bug Report возникает в процессе тестирования системы как реакция тестировщика на ошибку. Каждый документ должен обязательно ссылаться на соответствующий Test Case.
Содержать документ должен:
• скриншот возникшей ошибки;
• описание предшествующих действий. Лучше всего разработать удобный для всех шаблон такого описания – это сильно экономит время разработчикам при воспроизведении бага;
• текстовое описание самой ошибки.
Руководство пользователя/Руководство администратора
Самые занудные в написании, но, тем не менее, жизненно необходимые документы.
По сути, их формирование можно даже автоматизировать, если все Test Cases и Use Cases были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.