Как грамотно составить ТЗ для программиста. Основы взаимопонимания
Подготовка к лабораторной работе
Ознакомиться с лекционным материалом по теме «Модели ЖЦ ПО. Этапы ЖЦ в соответствии с ГОСТ 19.102-77. Постановка задачи» учебной дисциплины «Разработка и стандартизация ПС и ИТ».
1.Изучить соответствующие разделы в изданиях .
Теоретическая часть. Разработка технического задания
Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс приемо-сдаточных испытаний. В разработке технического задания участвуют как представители заказчика, так и представители исполнителя. В основе этого документа лежат исходные требования заказчика, анализ передовых достижений техники, результаты выполнения научно-исследовательских работ, предпроектных исследований, научного прогнозирования и т. п.
Порядок разработки технического задания
Разработка технического задания выполняется в следующей последовательности. Прежде всего, устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных. Затем определяют перечень результатов, их характеристики и способы представления.
Далее уточняют среду функционирования программного обеспечения: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного программного обеспечения, с которым предстоит взаимодействовать будущему программному продукту.
В случаях, когда разрабатываемое программное обеспечение собирает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать действия программы в случае сбоев оборудования и энергоснабжения.
1. Общие положения
1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата А4 и A3 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
1.3. Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:
Введение;
Наименование и область применения;
Основание для разработки;
Назначение разработки;
Технические требования к программе или программному изделию;
Технико-экономические показатели;
Стадии и этапы разработки;
Порядок контроля и приемки;
Приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. При необходимости допускается в техническое задание включать приложения.
2.1.Введение должно включать краткую характеристику области применения программы или программного продукта, а также объекта (например, системы), в котором предполагается их использовать. Основное назначение введения - продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных.
2.2.В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
2.3.В разделе «Основание для разработки» должны быть указаны:
Документ (документы), на основании которых ведется разработка. Таким документом может служить план, приказ, договор и т. п.;
Организация, утвердившая этот документ, и дата его утверждения;
Наименование и (или) условное обозначение темы разработки.
2.4. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.
2.5. Раздел «Технические требования к программе или программному изделию» должен содержать следующие подразделы:
Требования к функциональным характеристикам;
Требования к надежности;
Условия эксплуатации;
Требования к составу и параметрам технических средств;
Требования к информационной и программной совместимости;
Требования к маркировке и упаковке;
Требования к транспортированию и хранению;
Специальные требования.
2.5.1.В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
2.5.2.В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. п.).
2.5.3.В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
2.5.4.В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их технических характеристик.
2.5.5.В подразделе «Требования к информационной и программной совместимости о должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования. При необходимости должна обеспечиваться защита информации и программ.
2.5.6.В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
2.5.7.В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
2.5.8. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
2.6.В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также как правило, сроки разработки и определяют исполнителей.
2.7.В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.
2.8.В приложениях к техническому заданию при необходимости приводят:
Перечень научно-исследовательских и других работ, обосновывающих разработку;
Схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
Другие источники разработки.
В случаях, если какие-либо требования, предусмотренные техническим заданием, заказчик не предъявляет, следует в соответствующем месте указать «Требования не предъявляются».
Примеры разработки технического задания приведены в приложениях Б и В.
Контрольные вопросы
1.Дайте понятие модели жизненного цикла ПО.
2.Приведите этапы разработки программного обеспечения.
3. Что включает в себя постановка задачи и предпроектные исследования?
4. Перечислите функциональные и эксплуатационные требования к программному продукту.
5. Перечислите правила разработки технического задания.
6. Назовите основные разделы технического задания.
Приложение А
Варианты заданий
Лабораторные работы № 1-5 выполняются для одного и того же варианта.
1. Разработать программный модуль «Учет успеваемости студентов». Программный модуль предназначен для оперативного учета успеваемости студентов в сессию деканом, заместителями декана и сотрудниками деканата. Сведения об успеваемости студентов должны храниться в течение всего срока их обучения и использоваться при составлении справок о прослушанных курсах и приложений к диплому.
2. Разработать программный модуль «Личные дела студентов». Программный модуль предназначен для получения сведений о студентах сотрудниками деканата, профкома и отдела кадров. Сведения должны храниться в течение всего срока обучения студентов и использоваться при составлении справок и отчетов.
3. Разработать программный модуль «Решение комбинаторно-оптимизационных задач». Модуль должен содержать алгоритмы поиска цикла минимальной длины (задача коммивояжера), поиска кратчайшего пути и поиска минимального связывающего дерева.
4. Разработать программный модуль «Обработка матрицы». Модуль должен содержать алгоритмы поиска сумм и произведения элементов матрицы по строкам и столбцам, а также вычисление средних, минимальных и максимальных величин в матрице.
5. Разработать приложение Windows «Органайзер». Приложение предназначено для записи, хранения и поиска адресов и телефонов физических лиц и организаций, а также расписания, встреч и др. Приложение предназначено для любых пользователей компьютера.
6. Разработать приложение Windows «Калькулятор». Приложение предназначено для любых пользователей и должно содержать все арифметические операции (с соблюдением приоритетов) и желательно (но не обязательно) несколько математических функций.
7. Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата.
8. Разработать программный модуль «Лаборатория», содержащий сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров.
9. Разработать программный модуль «Химчистка». При записи на обслуживание заполняется заявка, в которой указываются ФИО владельца, описание изделия, вид услуги, дата приема заказа и стоимость услуги. После выполнения работ распечатывается квитанция.
10.Разработать программный модуль «Учет нарушений правил дорожного движения». Для каждой автомашины (и ее владельца) в базе хранится список нарушений. Для каждого нарушения фиксируется дата, время, вид нарушения и размер штрафа. При оплате всех штрафов машина удаляется из базы.
11. Разработать программный модуль «Картотека автомагазина», предназначенный для использования работниками агентства. В базе содержатся сведения об автомобилях (марка, объем двигателя, дата выпуска и др.). При поступлении заявки на покупку производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется.
12. Разработать программный модуль «Картотека абонентов АТС». Картотека содержит сведения о телефонах и их владельцах. Фиксирует задолженности по оплате (абонентской и повременной). Считается, что повременная оплата местных телефонных разговоров уже введена.
13. Разработать программный модуль «Автокасса», содержащий сведения о наличии свободных мест на автобусные маршруты. В базе должны содержаться сведения о номере рейса, маршруте, водителе, типе автобуса, дате и времени отправления, а также стоимости билетов. При поступлении заявки на билеты программа производит поиск подходящего рейса.
14. Разработать программный модуль «Книжный магазин», содержащий сведения о книгах (автор, название, издательство, год издания, цена). Покупатель оформляет заявку на нужные ему книги, если таковых нет, он заносится в базу и оповещается, когда нужные книги поступают в магазин.
15. Разработать программный модуль «Автостоянка». В программе содержится информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.
| Техническое задание на разработку программы «______________» к Договору №___ 1. Введение 1. Введение 1.1. Наименование программы Наименование программы: «АСУ «______________»» 1.2. Назначение и область применения Программа предназначена для автоматизации обработки данных клиентов кафе/бара. Она оперирует следующими данными:
2.1. Требования к функциональным характеристикам Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
2.2.1 Требования к обеспечению надежного функционирования программы Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств. Отказы программы вследствие некорректных действий пользователя при взаимодействии с программой. 3.1. Требования к квалификации и численности персонала Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 1 штатной единицы - оператор ПК. В перечень задач, выполняемых оператором ПК, должны входить:
3.2. Требования к составу и параметрам технических средств
3.3.1. Требования к информационным структурам и методам решения Программное обеспечение представляет из себя самостоятельное исполняемое приложение. Формат базы данных совместим с ADO.Пользователи работают с базой данных через системный интерфейс. 3.3.3. Требования к исходным кодам и языкам программирования Дополнительные требования не предъявляются. Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows XP. Требования к защите информации и программ не предъявляются. 3.5. Специальные требования Специальные требования не предъявляются. 4.1. Предварительный состав программной документации Состав программной документации должен включать в себя:
5.1. Экономические преимущества разработки Программа является бесплатным продуктом, финансовые средства не затрачиваются, и преимуществом является ускорение автоматизации обработки данных клиентов кафе/бара 6.1. Стадии разработки Разработка должна быть проведена в три стадии:
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания. На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:
На стадии внедрения должен быть выполнен этап разработки подготовка и передача программы. На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:
На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию на объектах Заказчика. 7.1. Виды испытаний:
7.2. Требования к приемке работы При приёмке необходимо проверить соблюдение следующих условий:
|
| Техническое задание на разработку дизайн проекта помещения. Информация | Техническое задание на разработку проектной документации для строительства зоопарка Положения В границах земельного участка ул. Подлесная, шоссе Космонавтов, ул. Малкова, Дзержинского района г. Перми |
||
| Техническое задание на разработку интернет-сайта структура документа Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного… |
Техническое задание на разработку веб-сайта «Объединение Российских Художников Аэрографии» Основной html контейнер, в который вставляются информационные блоки, должен быть полностью доступен для редактирования. Желательно… |
||
| Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных» Гост 34. 602-89 Техническое задание на создание автоматизированной системы (пример) |
2. Техническое задание на разработку ис В данном курсовом проекте приведен процесс выдачи пенсионного страхового свидетельства. Разработанная система предназначена для упрощения… |
||
| Техническое задание на разработку сайта журнала Настоящее тз представляет… Сайт моделируется с учетом ограничений современных систем контент-менеджмента (открытых WordPress, Joomla, LiveStreet и им подобных… |
Программа демонстрации алгоритмов обхода графов Данное техническое задание регламентирует разработку учебного программного продукта предназначенного, для наглядного представления… |
||
| Техническое задание включает в себя: наименование разработки, основание… Технико-рабочий проект: описание предметной области (объектная модель), управление объектами (события, диаграмма взаимодействия),… |
Проектирование программных средств Этап проектирования подразумевает разработку архитектуры, разработку данных и процедурную разработку программных средств |
Технические требования к системе
Технический облик изделия
Теория решения изобретательских задач — это советская методика сильного мышления, получившая широкое как в России, так и в мире. Она позволяет глубоко проанализировать проблему и найти эффективное решение.
Работа над ТРИЗ была начата Генрихом Сауловичем Альшуллером и его соратниками в 1946 году.
Разработка программы: пример технического задания
В 1956 году вышла первая публикация про то, что техника развивается по определенным законам. Чтобы эффективно изобретать, нужно эти законы выявить и эффективно применять
Со временем ТРИЗ развился в большой набор инструментов, помогающие решать ряд актуальных задать:
— создавать новые прорывные продукты,
— повышать потребительские свойства имеющихся решений,
— снижать себестоимость,
— обходить патенты конкурентов.
Ведущие мировые компании, такие как Samsung, Intel, Procter&Gambel, General Electric и другие используют ТРИЗ в своих R&D центрах.
Термины
Для исключения спорных моментов и недопонимания важно пользоваться одинаковым понятийным аппаратом. Для этого мы составили перечень наиболее часто используемых терминов и сокращений.
Когда речь заходит о разработке технической документации для программного обеспечения, чаще всего мы думаем, пожалуй, о таком документе, как Техническое задание (ТЗ). Почему так происходит?
Назначение технического задания
Во-первых, техническое задание – это, как правило, основной документ в рамках проектной документации. Именно в ТЗ описываются все основные требования на разработку программного обеспечения, будь то создание либо простенькой программы или сайта, либо же разработка крупномасштабной информационной системы или программно-аппаратного комплекса. Причем, говоря языком ГОСТов, техническое задание может разрабатываться как в рамках эскизного проекта (это когда только описание функций и структуры системы без рассмотрения технологий реализации решения), так и в дальнейшем «перекочевать» в технический проект (более детальное описание с учетом выбранных технологий).
Во-вторых, техническое задание может быть как поверхностным (например, общеконцептуальное ТЗ, предназначенное для инвесторов проекта), так и более детальным (например, подробное ТЗ для программиста). Посмотрите раздел Проекты, там как раз приведены примеры различных ТЗ. Вы можете выбрать любой уровень детализации – мы подготовим для вас ТЗ любой сложности по доступным ценам.
В-третьих, в некоторых случаях можно обойтись только подготовкой одного технического задания для описания разрабатываемой системы. Разумеется, в этом случае качество разрабатываемого ТЗ играет ключевую роль, поэтому здесь явно не стоит экономить и лучше доверить разработку такого ТЗ профессионалам, имеющим большой опыт в этом деле. Скупой платит дважды, но в случае провала разработки ПО по причине некачественной документации – вдесятеро, а иногда и еще на несколько порядков выше.
Состав типового технического задания
Давайте рассмотрим, что же включает в себя типовое ТЗ.
Техническое задание программного обеспечения оказалось поверхностным?
Итак, техническое задание, вне зависимости от выбранного ГОСТа, всегда включает следующие основные сведения по разрабатываемому ПО:
1) наименование
– полное и краткое названия, условное обозначение разрабатываемого ПО;
2) назначение
– то, для чего, в какой области и с какой целью разрабатывается ПО;
3) основание для разработки
– документы, на основании которых производится разработка ПО;
4) функции
– перечень и описание функций разрабатываемого ПО;
5) структура
– описание архитектуры и компонентов разрабатываемого ПО;
6) пользовательский интерфейс
– в современном мире обязателен;
7) надежность, безопасность, условия эксплуатации
и проч. важные требования;
8) документация
– какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана;
9) стадии и этапы разработки
– что и в какой последовательности разрабатывается;
10) порядок контроля и приемка
– как именно будет происходить сдача разработанного ПО Заказчику.
Стандарты для технического задания
Существует несколько ГОСТов, регламентирующих разработку ТЗ в нашей области: это ГОСТ 34.602 (автоматизированные системы) и ГОСТ 19.201 (программное обеспечение). Документы, выполненные по этим стандартам, значительно отличаются как по наполнению, так и по содержанию. Оба стандарта представлены на нашем корпоративном портале в разделе Библиотека, вы можете самостоятельно ознакомиться с ними более подробно.
Стоимость разработки технического задания
В целом, составление ТЗ – это достаточно сложная и ответственная задача, но грамотно составленное техническое задание – это уже половина успеха разрабатываемого проекта. Поэтому в процессе разработки ТЗ на ПО вы должны проявить максимальную внимательность и осведомленность в технических и организационных вопросах. Либо можете заказать у нас разработку технического задания «под ключ» прямо сейчас.
Возможно, вас также заинтересует:
– разработка программы и методики испытаний;
– создание пояснительной записки к эскизному и техническому проекту;
– этапы разработки документации.
Написание технического задания — один из первых этапов работы над проектом. Он предваряет разработку самой системы. В техническом задании мы описываем предметную область, существующую инфраструктуру Заказчика, требования к создаваемому функционалу, а также нефункциональные требования. Получившийся документ необходим как бизнес-пользователю для того, чтобы он убедился в том, что все его пожелания к будущей системе учтены, так и нам, чтобы оценить стоимость разработки системы.
Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.
Главным фактором успеха при разработке технического задания является правильно выстроенная коммуникация с заказчиком. Ведь задача аналитиков состоит в том чтобы фактически произвести операцию brain-dump, и результаты расположить на бумаге в структурированном виде. При этом очень важно (1) разговаривать с заказчиком на одном языке, чтобы тому не приходилось разжевывать очевидные для специалиста понятия предметной области и (2) уметь правильно слушать.
Приведем ниже принципы, которыми мы руководствуемся при написании технического задания, и проиллюстрируем их выдержками из разработанного нами технического задания на многокомпонентную систему баннерной рекламы для крупной Интернет-компании.
Структура технического задания
Каждое техническое задание содержит несколько обязательных разделов. В них определяется назначение документа, терминология, общий контекст проекта. Обычно первая часть документа выглядит так:
Class="fs-13">
Если в начале документа даётся общая, концептуальная информация о разрабатываемой системе, то во второй, основной части документа, детально прописываются бизнес-требования и существенные для оценки стоимости разработки функциональные требования к системе.
В разделе «Терминология» технического задания на баннерную систему мы определяем такие понятия как Показы, Клики, CTR, Охват, Частота контакта, Файл бронирования и т.п, а в разделе «Общий контекст» — описываем основные бизнес-процессы компании-заказчика, относящиеся к размещению баннерной рекламы, а также — системное окружение, текущие роли менеджеров компании и права доступа. Стоит отметить, что в данном конкретном случае система строилась не на пустом месте. Ранее менеджеры компании использовали другую, отличную от нашей, систему размещения баннерной рекламы. В противном случае — анализ ролей и прав доступа был бы скорее всего вынесен в отдельную главу.
class="fs-13">
7. Система размещения баннеров
8.
Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine
class="fs-13">
Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.
Учитывая специфику данного проекта, мы посвятили отдельный раздел взаимодействию баннерки с биллинговой системой. Также в отдельный раздел мы выделили требования к достаточно независимой компоненте сбора и отображения статистической информации, которая является для заказчиков рекламных кампаний и менеджеров рекламных агентств едва ли не основным компонентом системы.
Отдельный раздел технического задания описывает требования к компоненту Banner Engine, отвечающему за показ баннеров, учёт статистики, её обработку и сохранение в виде, пригодном для дальнейшего анализа и построения отчетов.
Это – технически самый сложный и самый высоконагруженный компонент баннерной системы. В ТЗ мы включили раздел, содержащий некоторые технические и архитектурные детали, связанные с работой Banner Engine. Прежде всего, это позволяет минимизировать риски при оценке стоимости разработки системы, ведь в зависимости от выбранной архитектуры трудоемкость может отличаться в разы.
Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.
class="fs-13">
Бизнес vs Функциональные требования
В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта.
Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
Пример бизнес-требования:
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
Правильное техническое задание на разработку программного обеспечения – секрет успешного проекта
Роль: Администратор
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест).После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий, разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Основные принципы
При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста. В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е. представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.
У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.
Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.
По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
Прототипы, уже на стадии разработки, дают заказчику понять, как именно будет выглядеть интерфейс системы.
Требования должны быть написаны «живым человеческим» языком , понятным бизнес-пользователю в т.ч. руководителю высшего звена, не обладающему техническими навыками; в них должен содержаться минимум технической терминологии. Чем быстрее пользователь «вникнет» в содержания технического задания, тем более эффективно будет выстраиваться наше с ним общение.
Опыт в предметной области
Большое значение при создании технического задания имеет опыт разработки похожих систем. Он помогает быстрее вникать в бизнес-процессы и потребности заказчика, делать «по аналогии» многие вещи, которые ранее казались бы нам сложными. Накопленный опыт в области управленческих бизнес-систем, крупных интернет-проектов, финансовых систем, e-commerce систем позволяет нам применять свои знания в отношении каждого последующего проекта, которым мы занимаемся. До того, как получить заказ на систему баннерной рекламы, упомянутую выше, мы уже занимались разработкой нескольких баннерных систем. Мы хорошо знали, как работают баннерки, знали характерную терминологию этой предметной области. На основании нашего опыта работы с другими баннерными системами, мы предложили заказчику довольно много упрощений, оригинальных решений, не только в сфере технологий, но и бизнеса.
Поиск Лекций
Техническое задание на объект
При проектировании технического объекта важное место занимает разработка технической и технологической документации: техническое задание (ТЗ) и технические условия (ТУ).
Техническое задание — это основной исходный документ для разработки продукции, содержащий технико-экономические требования к продукции, определяющие ее потребительские свойства и эффективность применения, перечень документов требующих совместного рассмотрения, порядок сдачи и приемки результатов разработки. Техническое задание на проектирование разрабатывается на основании ГОСТ 15.001-88 и оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-68.
В качестве технического задания допускается также использовать любой документ (контракт, протокол, эскиз, образец продукции и др.), содержащий необходимые и достаточные требования для разработки и признанный заказчиком и разработчиком.
Утвержденное техническое задание является документом, которым разработчики должны руководствоваться на всех этапах создания системы и проектирования задач. Изменения, вносимые в техническое задание, должны оформляться протоколом, являющимся частью технического задания. Протокол должен утверждаться заказчиком.
При разработке технического задания следует:
· установить общую цель создания технической системы;
· установить общие требования к проектируемой системе;
· определить этапы создания системы и сроки их выполнения;
· провести предварительный расчет затрат на создание системы.
Техническое задание должно содержать следующие разделы:
1) наименование и область применения;
2) код изделия;
3) основания для разработки;
4) цель и технико-экономическое обоснование;
5) источники для разработки;
6) этапы разработки и запуска производства;
7) технические требования.
В зависимости от назначения разрабатываемых средств измерений, условий их изготовления и эксплуатации допускается изменять структуру технического задания, объединяя отдельные разделы и вводя новые.
В разделе Основание для разработки указывают наименование документа (документов), которым предусмотрена данная разработка, организацию, утвердившую этот документ, и дату его утверждения, наименование и шифр темы разработки.
Основанием для разработки является маркетинговые исследования и выход нового стандарта.
В разделе «Цель и технико-экономическое обоснование разработки» указывают:
1. Конкретное функциональное назначение объекта – для снижения токсичности автомобиля.
Техническое задание на разработку программы
Наличие отечественных и зарубежных аналогов и возможность или целесообразность их применения по данному назначению – на рынке присутствуют зарубежные аналоги, но их стоимость и отечественные аналоги.
3. Предполагаемую потребность в данных объектах у потребителей – данный объект необходим потребителю для соблюдения норм стандарта и сохранения здоровья людей и окружающей среды.
В разделе «Источники разработки» приводят перечень научно-исследовательских и других работ, результаты которых используют в данной разработке, а также перечень образцов или макетов, на базе которых выполняют разработку.
В разделе «Этапы разработки» указывают необходимые этапы работ и ориентировочные сроки их выполнения, состав и ориентировочные сроки представления конструкторской технологической документации на метрологическую экспертизу и организацию, которая ее проводит.
Основываясь на этапы жизненного цикла продукции разрабатываем этапы разработки и запуска в производство.
Основные этапы разработки: маркетинговые исследование; разработка ТЗ; — проектирование объекта; испытание; подготовка производства; запуск в производство.
На первой стадии проектирования производится выбор (или разработка) принципиальной схемы объекта. С этой целью на основании справочных данных, рекомендаций и стандартов формируется ряд вариантов объектов – аналогов, в той или иной степени отвечающих требованиям ТЗ. Далее в случае необходимости производится доработка принципиальных схем объектов – аналогов. Если варианты объектов – аналогов не найдены, переходят к процедуре синтеза вариантов объектов, еще не встречавшиеся в практике машиностроения. При это, как уже отмечалось, максимально используются стандартные элементы и узлы.
Следующая стадия проектирования – конструктивное оформление основных элементов и построение математических моделей функционирования приспособления. Последняя стадия проектирования- окончательное конструкторское оформление принятых решений, выполнение чертежей и текстовой части в соответствии с требованиями ЕСКД .
После успешных испытаний, для заказчика проекта, на основе требований технического задания и стандартов, касающихся данного вида продукции, с учетом результатов испытаний разрабатывается техническое условие на приспособление, которое включает в себя:
1.Технические требования
2. Требования безопасности
3. Требования охраны окружающей среды
4. Правила приемки
5. Методы контроля
6. Транспортирование и хранение
7. Указание по эксплуатации
8. Гарантии изготовителя
9. Утилизация
На основе разработанных документов можно приступать к непосредственному проектированию объекта.
Люди по-разному трактуют события и явления, иначе видят решения задач. В ситуациях, когда есть четкий план, любая неправильная трактовка может привести к неожиданным результатам, и скорее всего, вы получите не то что хотели.
Если по написанному вами ТЗ люди делают то что вы хотите получить, и в процессе работы вы не тратите лишних сил на дополнения и переформулирование собственных мыслей - значит вы умеете круто ставить задачи, и у вас есть чему поучиться.
Если даже после прочтения ТЗ исполнитель делает что-то не так, значит, вам нужно пересмотреть свой подход к постановке задач. Даже самый крутой исполнитель, которого вы нанимаете на проект, сделает не то что вам нужно, если вы составили для него плохое техническое задание.
Чтобы написать хорошее ТЗ, вам необходимо представить себя на месте человека, которому оно адресовано. Проиллюстрируем эту мысль.
Мы делаем видеоролики, и пару месяцев назад для нас было в новинку привлекать к работе иллюстраторов. Первые наши технические задания порождали череду вопросов со стороны исполнителя, и нам приходилось созваниваться и объяснять человеку что мы имеем ввиду в таком-то и таком-то пункте. В какой-то момент мы устали, устал иллюстратор. Это был повод задуматься.
Как нам кажется, проблема заключалась в том, что мы формулировали задание слишком общими фразами, что давало иллюстратору повод додумывать и тратить время на поиски не профильной для него информации.
Что было плохо:
- Мы писали список требований к иллюстрациям для анимации, не сопроводив эти требования примерами с картинками и видео. Это был просто текст вроде: “старайтесь рисовать гнущиеся элементы таким образом, чтобы энкор поинты суставов совпадали друг с другом”. Из-за того что мы поленились это проиллюстрировать, наш иллюстратор сделал то что нужно только с третьего раза.
- Мы насыщали ТЗ слишком большим количеством примеров. Иллюстратор буквально тонул в изобилии работ, которые нам нравятся. Не было четкого стилистического ориентира.
- Много текста. Мы писали лишнюю информацию о проекте. Эта информация никак не могла помочь иллюстратору сделать его работу.
- Раскадровка с недостаточными пояснениями о том что будет происходить в слайде.
- Доступность ТЗ только онлайн, на Гугл Диске.
- Мы не имели четкого представления для кого пишем это ТЗ. Мы не вошли в роль этого человека для нашего проекта.
Конечно, можно предположить что человек, нанятый на проект, сам по себе такой, недогадливый и недалекий. Эту мысль мы откидываем сразу. Цель ТЗ - не проверять интеллектуальные способности человека и не играть с ним в угадайку. Когда вы нанимаете кого-то на проект, как правило, это не самые глупые люди, правда? Вы же видели предыдущие работы человека, вы общались с ним перед началом проекта.
Проанализировав свои ошибки, мы поменяли подход к написанию технического задания. Наш последний проект получился очень легким на подъем, во многом это благодаря тому, что мы стали четче и обдуманнее ставить задачи. Мы значительно меньше времени стали тратить на дополнительные объяснения. ТЗ состояло из 43 страниц. Возможно, мы немного перестарались, но первые слова иллюстратора, после прочтения нового ТЗ, были такими:
Суть нашего нового подхода к написанию ТЗ свелась к следующему:
1. Очень кратко и емко нужно описать для кого этот проект, какие задачи нужно решить по окончанию проекта, и какую конкретную задачу решает человек, которого вы нанимаете на проект. Таким образом, он не будет работать вслепую, понимание “что” и “зачем” позволит ему предложить вам лучшие решения.
2. Сопроводить исполнителя всеми необходимыми материалами, которые нужны для работы: референсы, картинки и видео с объяснениями. Наш последний проект был посвящен работе кухонного прибора. В сети без проблем можно найти тысячи статей, картинок и видео о его работе. Мы сэкономили время иллюстратору и собрали самые очевидные и понятные картинки и видео. Это заняло у нас 15 минут. Но мы уверены что сэкономили гораздо больше времени на работу.
3. По пунктам четко и кратко написать все что требуется сделать, чтобы считать работу завершенной.
4. Любые технические требования теперь мы иллюстрируем и записываем видео . Тут важно побольше задавать вопросов себе: что в нашем пайплайне может быть непонятно? Что может породить дополнительные вопросы?
5. Теперь мы скидываем не только текст в формате Гугл Докс, но еще ссылку на скачивание PDF версии ТЗ, чтобы в случае неполадок с интернетом, ТЗ было под рукой.
Некоторые из этих вещей могут показаться естественными, однако осознание этой естественности пришло с опытом. Надеемся что информация в этой статье была полезна. Хотелось бы в комментариях услышать о ваших пониманиях идельного ТЗ.
В большинстве крупных организаций внутрифирменные отношения «пользователь-отдел IT» неизбежны, особенно при создании рабочих приложений, необходимых пользователю на постоянной основе. Сложность этих отношений может быть обусловлена многими факторами, но чаще всего это непонимание, возникающее из-за того, что стороны говорят на разных «языках» с различной терминологией. Пользователь понимает, что он хочет, но не может это сформулировать, IT-специалист понимает пользователя, но опасается, что результат выйдет иным, чем видит это первый. Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится. Результаты такого непонимания вредят всему производственному процессу: затягиваются сроки решения задач, возникают ошибки и пробелы в системах, которые нужны пользователю, страдает перегруженный неверными действиями сервер, скорость работы снижается.
Одним из способов разрешения такого конфликта является написание задания на проект – технического задания, которое предполагает полное и точно изложение требований внутрифирменного заказчика и является своеобразной инструкцией для IT -специалиста. Однако не каждый пользователь способен изложить свои мысли грамотно и доходчиво.
Приведу несколько советов для написания корректного задания пользователем, по которому можно работать и которое ложится в основу отношения между заказчиком решения и специалистом.
1. Прежде, чем составлять техническое задание, пользователь должен понять, что именно он хочет получить . Следует определить цель задания, ключевые особенности желаемого результата, нарисовать (написать, создать таблицу) для себя желаемый выход работы.
2. Собрать документацию , согласно которой вы выполняете работу, для которой необходимо приложение (программа). Прочитать ее внимательно, с карандашом, отмечая особенности и тонкости.
3. Следует понять, какие параметры следует задавать на входе , какова периодичность работы с желаемой программой (отчетом, приложением, утилитой), сколько данных примерно будет получаться на выходе и все ли они нужны (к примеру, если вам нужна сумма выручки от продаж пяти категорий изделий по категориям без наименований, не стоит требовать создания отчета в миллион строк с указанием каждой продажи с детальными характеристиками). Далеко не каждому специалисту необходима максимально детализированная информация, обработка которой создает значительную нагрузку для вычислительных систем.
4. Подробно описать необходимую информацию , указать ее особенности, исключения, необходимый уровень детализации. Следует продумать все мелочи: формат чисел, округление, доли, ставки и проч.
6. Обсудить написанное задание с непосредственным исполнителем , попытаться разрешить все вопросы, внимательно прислушиваясь к мнению собеседника. Не стоит забывать, что вы свою сферу деятельности знаете лучше и только вы можете точно объяснить, какой инструмент вам необходим для эффективно работы. IT-специалист знает свое дело и не обязан знать нюансы работы каждого отдела в организации.
7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки.
8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.
9. Помните, что ваше задание будет служить справочником для вас - в нем всегда можно посмотреть описание информации, вспомнить забытое требование.
Конечно, только лишь умение писать техническое задание не избавит от всех проблем, но оно позволит отношениям с IT-отделом перейти в серьезную плоскость сотрудничества, позволит пользователю повысить свою техническую грамотность и получить требуемое, а специалиста по IT избавит от ряда проблем и ненужных вопросов.