Что такое чтз техническое задание
Документирование в разработке ПО
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 были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.
Частные технические задания
Понятие ТЗ
Техническое задание — исходный документ на проектирование технического объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.).
В соответствии с Гражданским кодексом, проектирование — это один из видов подрядных работ, результатом которых является продукция (проект), то есть комплект проектной документации на другой продукт (объект проектирования). Проект предназначен для создания объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых этот объект был разработан.
Слово «проект» в области деятельности «управление проектами» и «управление проектированием» применяется в значении «программа», «план действий», «комплекс работ».
Участников проектных работ разделяют на потребителей (заказчиков этих работ) и поставщиков (исполнителей этих работ, подрядчиков). Исполнителя-специалиста называют проектировщиком или разработчиком. Поставщиком, как и потребителем продукции, может быть организация (юридическое лицо) или конкретный человек (физическое лицо).
Объектом проектирования может быть материальное устройство, или выполнение работы, или оказание услуги, например, сооружение или промышленный комплекс, техническое устройство (прибор, машина, аппарат), система управления,информационная система
, нормативная документация (например, стандарт) и т. д.
Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения.
Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков.
Место ТЗ в структуре проектирования
Проектирование— это процесс (разработки проекта), который обладает определённой структурой, то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.
Стадии проектирования регламентированы стандартами. Это следующая последовательность:
· Техническое задание (по ГОСТ 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] (приложен образец технического задания на разработку в рамках ГОЗ)
ТЗ и ЧТЗ
Столбняк в Санкт-Петербурге
Столбняк существует. Я в этом убедился на личном опыте. Но самая страшная болезнь в России не столбняк, а бюрократия.
Я думаю, эта история заслуживает внимания общества и широкой огласки.
Помогите распространить это сообщение как можно дальше. На всех уровнях. Соцсети, репосты, газеты, телефон, письма, рассказы знакомым, возможно кто то из вас спасёт жизнь одного, пусть и незнакомого человека.
ЛЮБОЙ из вас может оказаться на моём месте.
22 сентября я удалил дома вросший ноготь.
Через два дня палец дёргаться перестал. И я забыл эту историю.
Ещё через две недели место пореза стало вновь дёргать, затем потихоньку нога, другая, и мышцы по всему телу. Свело слегка челюсти, стало тяжело глотать и напряглись мышцы по всей спине.
И дальше начался двухмесячный кошмар. С больничного на больничный. От врача к врачу, на обследования я потратил всё что было, и безрезультатно. Инфекционисты, терапевты, неврологи- никто не мог поставить диагноз.
Сон, аппетит, работа, нормальная жизнь, общение, внешний вид- всё было потеряно.
В течение примерно 2-3 недель было ухудшение вплоть до единичных судорог, затем пошёл на поправку, затем заживший палец снова начинал болеть и шло ухудшение. И так снова и снова.
Внимание. Это Питер. Не ржавый гвоздь, не болото, не отходы какие то. Просто дома кусачками.
Долго долго ничего не писал, так как казалось, что всё решаемо, но вот увы настал момент и я пишу.
Значит ситуация следующая. После почти трёх месяцев мытарств врачи в поликлинике по месту жительства собрали консилиум и дружно мне поставили диагноз подозрение на столбняк(уже появился первый довольно чёткий симптом, сжимание мышц челюстей(тризм), не хотели дожидаться всех остальных). Инфекционист написала направление на экстренную госпитализацию с подозрением на столбняк(А35) и позвонила в эпиднадзор в моём присутствии. Эпиднадзор отказал в постановке диагноза, не видя меня, просто на основании того, что должна быть открытая рана, и срок смерти в течение недели. (Это тяжёлая форма столбняка). Всё. Никаких других форм столбняка в документации у них нет, они в первую очередь юристы, а не врачи. Они за свой отказ по телефону ответственности не несут.
На данный момент я с трудом могу кушать твёрдую пищу, рот тяжело открывается. Периодически наступает улучшение, раз в две три недели, потом опять ухудшение. Раненый когда то палец ноет и дёргается перед каждым ухудшением. Затем начинаются подёргивания мышц, спазмы, сводит челюсти и становится тяжело глотать. Сбиваются эти симптомы только баклофеном(препарат, тормозящий возбуждение двигательных нейронов нервной системы)
Диагноз ставится только по клиническим признакам, нет ни одного анализа который мог бы показать наличие яда в крови или столбнячных палочек. Доказательную диагностику провести нельзя. Только в разгар болезни, когда человек ложится доской, начинаются изменения в анализах из за гипоксии мозга, голодания и разрушения мышц.
Врачи из поликлиники бессильны перед эпиднадзором, а без направления на госпитализацию ни одна больница не берётся за это. Они хотят помочь, но боятся эпиднадзора. Сегодня я был на приёме у кандидата наук инфекциониста со стажем 46 лет, он подтвердил диагноз, но сказал, что даже он бессилен ставить диагноз вопреки эпиднадзору. Поставил полинейропатию после перенесённого столбняка. Пожелал мне удачи и посочувствовал.
Когда прихожу в поликлинику на обследования и консультации после очередного пинка из больницы, создаётся ощущение, что
моя поликлиника знает меня в лицо, врачи здороваются со мной и переживают за меня.
Нервы за эти три месяца абсолютно уничтожены. Я чувствую бессилие и если хоть кто то знает, куда, как обратиться, как законно получить своё право на мед помощь, пожалуйста, в любое время жду ваших советов. Пока ещё не поздно.
P.S.:Эпиднадзор запретил ставить даже подозрение. Это в их интересах, так как каждая постановка такого диагноза ставит под сомнению систему прививок и профилактики столбняка.(Как в моём случае, мне поставили не тот укол)
Мне всё равно где получать лечение. В любой больнице. От меня отказались без согласия надзора уже в четырёх больницах. Врачи пытались подсказать мне, где получить помощь, давали направление в больницу со смежными диагнозами, ещё как то, но всё было бесполезно.
Мне так и не сделали за 3 месяца укол противостолбнячной сыворотки, так как не имеют права без отчётности. И это делается только в больнице.
И самое что главное, почему я до сих пор жив, мне объяснили. Ранка была небольшая, далеко от ЦНС, какая никакая профилактика хоть и запоздалая была, и. Здравствуйте, последствия. Хроническая форма с рецидивами. Я не могу нормально жить, работать, общаться. В любой момент может произойти генерализация процесса и меня могут не спасти. Мы ищем любые нити для спасения. Спасибо что дочитали до конца.
Если так и будет продолжаться, я долго не протяну, поэтому репост даже на неделю с последующим удалением это уже большое дело. Помогите пожалуйста!
Необходимо найти хирурга, который сможет провести хирургическое вмешательство в очаг инфекции(четвёртый палец левой стопы), обколоть его ПСЧИ(ПСС), и прекратить поступление яда столбнячных палочек в организм. Если этот вопрос решается только удалением пальца- я согласен.
Либо нужен юрист, который поможет договориться с врачами и эпиднадзором.
Дальше, лечение последствий это уже проще. Оно чисто симптоматическое. Да, последствия могут быть уже довольно серьёзными, в случае генерализации мне требуется реанимация и специализированная помощь для столбнячных больных, это очень тяжёлый процесс, но в данном случае- главное- убрать источник яда из организма. Иначе лечение последствий не приведёт ни к чему
На всякий случай- это НЕ ЗАРАЗНО.
Я понимаю, что моя история уже тянет на то, чтобы меня показали в новостях по первому каналу, так как в Петербурге около 10-20 лет не было зарегистрировано ни одного случая столбняка. Видимо усилиями Эпиднадзора.
Для любопытных, в конце прикреплю статью о столбняке.
Советы всем тем, кто не хотел бы оказаться на моём месте-
1)Делайте ревакцинацию АДСМ вовремя. 2)Детям ставьте прививки от столбняка. Без колебаний. Обязательно.
3)Не замазывайте раны мазью, никакой, никогда.
4)Не удаляйте вросший ноготь дома самостоятельно..
5)Первый и самый важный симптом- подёргивания в ране, боль в жевательных мышцах и спазмы. Если не дай бог откуда то взялось что то из этого, СРОЧНО в травмпункт и требуйте вколоть вам СЫВОРОТКУ, не АНАТОКСИН. Перестрахуйтесь. Здоровья вам и вашим близким.
В словах поддержки я сейчас уже не столько нуждаюсь, сколько в советах, что делать, в любой помощи по распространению этой информации и решению экстренной ситуации- на переживания и рефлексии у меня осталось слишком мало времени.
Нормы оказания медицинской помощи при столбняке и даже подозрении на нём прикреплю в ссылке снизу.