Техзадание на разработку по образец. Пишем техническое задание

О технических заданиях, об их важности и о правильном составлении приходится слышать постоянно. Техническое задание на создание сайтов, техническое задание на дизайн-проекты, техническое задание на разработку программ, техническое задание на то, техническое задание на это… Так ли важно это самое, техническое задание, панибратски именуемое, ТЗ? А давайте разберемся!

Для примера выделим одно из самых распространенных направлений – составление технического задания на разработку программ. И, пожалуй, начнем постепенно отвечать на возникающие вопросы.

Зачем техническое задание?

Отвечая на вопрос: «зачем?» важно понимать, о чем в действительности идет речь. Как уже было обозначено выше, в качестве примера составления технического задания, была выбрана разработка программ. А это означает, что у предприятия, фирмы, организации возникли реально существующие, текущие задачи, которые можно и нужно решать эффективнее, чем это делается на данный момент. Другими словами, необходимо заменить человеческий труд, дорогостоящий и переменного качества, на эффективную, и гораздо менее затратную работу программного обеспечения.

Действительно, сотрудникам нужен отпуск, все они хотят вовремя получать заработную плату, периодически «ходят на больничные», и, как правило, не изъявляют желания работать в выходные дни. Разработка программ, напротив, не только не приносит обозначенных проблем, с завидной регулярностью сменяющих одна другую, но и наоборот, решает их!

А вот на решениях остановимся более подробно. Поскольку список текущих проблем, необходимых для устранения посредством программного обеспечения, уже сформирован, настало время подумать и о самом процессе решения. Собираемся, заседаем, спорим, выясняем, и в итоге, вот оно, более-менее общее мнение ответственных лиц, о том, чего же будет делать будущая программа. Вот так и зарождается, предпосылка к составлению технического задания на разработку программ, медленно, но верно.

Конечно, всё может обстоять и совсем иначе. Поручаем составление технического задания специалистам фирмы, предлагающей разработку программ. Пара-тройка встреч в деловой, но дружеской обстановке, готовые брифы, бланки, договора, формы. Всё заполнили, все довольны. По крайней мере, пока.

Хозяин, как говориться, барин, и всегда волен выбирать оптимальный вариант, и по цене, и по качеству. В идеале, конечно, чтобы и то, и другое соизмерялось, но всегда приходится идти на компромиссы. При слишком низкой цене, компромисс по разработке программ, естественно сдвигается в сторону резкого ухудшения качества программного обеспечения. Однако, как ни парадоксально, то же самое происходит и при неграмотном составлении технического задания на разработку программ. Деньги заплачены, продукт получен, работает, да не так.

Вот, собственно, ответ на вопрос, зачем нужно составлять грамотное техническое задание на разработку программ, очевиден. Идем дальше.

Для кого техническое задание?

Техническое задание на разработку программ составляется, прежде всего, для тех людей, которые буду осуществлять эту самую разработку. Соответственно, оно должно быть понятно тому человеку, который ничего не знает о клиенте, и уж тем более, о его задачах и проблемах. По крайней мере, не знает пока.

Следовательно, техническое задание на разработку программ должно рассказать исполнителю и о фирме, и о целях, и о задачах. При этом чем конкретнее будет рассказ, тем лучше – и для повествователя, то бишь Заказчика разработки программ, и для слушателя, то есть для исполнителя проекта.

В общем виде, техническое задание преследует несколько целей, и хотя об этом, возможно надо было сказать в самом начале, исправлять упущения не поздно никогда. И так, цели:

• Организация
• Информация
• Коммуникация
• Юрисдикция.

Организация должна быть направлена на сам процесс, иначе говоря, упорядочить творчество и созидание программы, или программного комплекса. Строго, структура технического задания на разработку программ должна быть четкой и в тоже время лаконичной. Поскольку читать 120-150, а то и более, страниц неудобоваримого технического текста, творческая личность программиста попросту не сможет. А значит, краткость – сестра таланта.

Информационная составляющая ТЗ должна быть полной, но сжатой.

И опять же простое правило, «необходимо и достаточно». Его, как водится, нужно придерживаться всегда и везде, но при составлении технического задания по разработке программ, это правило становится номер один. Грамотное техническое задание – первый и последний документ, который расскажет обо всех желаниях заказчика в удобной для понимания программиста форме. Хотите перевернуть жизнедеятельность Вашей фирмы или предприятия на принципиально новый уровень? Тогда, техническое задание на разработку программ – та самая точка опоры, с помощью которой мир перевернется в указанном Вами направлении. А этим, согласитесь, пренебрегать, ну никак нельзя.

С коммуникациями несколько сложнее. Почему? Да потому что коммуникации, да ещё и в процессе относительно творческом, сложны всегда. Особенно, если говорить на разных языках. А языков тут может быть несколько, более точно – по числу участников проекта под кодовым названием «разработка программ».

Проще говоря:

• Клиент, он же Заказчик
• Менеджер проекта
• Исполнители проекта, они или он: программист(ы)
• Другие возможные участники, имеющие мнение: как сделать, как сделать лучше, и чем всё должно закончиться.

Естественно, создавая общий проект, эти участники вынуждены искать язык, доступный для общего понимания каждым. Таким языком и призвано стать техническое задание на разработку программ. В идеале, главное – установить канал связи между первым и третьим звеном, и чем меньше помех при этом будет вносить второе и четвертое звенья, тем качественнее будет результат, а разработка программ принесет желаемый результат при минимальных нервопотерях.

Вот и добрались до юрисдикции, попутно затронув вопрос о «потере нервов». Благодаря техническому заданию, можно судить о соответствии результата разработки программ и заданных начальных условий. Надо сказать, что кратковременностью памяти, страдают как Заказчики проекта, так и псполнители. Первые забывают об оговоренной стоимости, количестве правок, возможностях внедрения и отладки, а вторые – в принципе о том, что и когда они должны были сделать. Дабы свести амнезию и её последствия к минимуму, необходимо опять же, четкое и конкретное ТЗ на разработку программ!

Как составлять техническое задание?

Убедившись о необходимости, и даже бесценности технического задания при разработке программ, можно продолжать разговор дальше. Теперь мы подошли к самому серьезному вопросу: как составлять ТЗ, чтобы оно было грамотным, четким, лаконичным, но конкретным?! А ведь другого нам и не надо.

Об этом позаботились ещё в стародавние времена СССР, разработав целую концепцию стандартов, называемых ГОСТами. Удивительно, но разработка программ, этими стандартами также предусмотрена, что согласитесь, не может не радовать.

Разработка программ и составление технического задания по этому направлению регламентируется ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.

Также не лишними будут ещё два руководства:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
• ГОСТ 34.602-89 информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Эту троицу, несомненно, можно считать «святая святых» при разработке и составлении технического задания практически любой предметной области. Есть, конечно, и другие стандарты, руководствоваться которыми можно и нужно, но вспомним о «необходимом и достаточном».

Что мы имеем в итоге?

Ответ: общую структуру технического задания, в том числе и на разработку программ.

• Что нужно сделать в рамках проекта;
• Зачем это нужно, и для каких конкретно целей;
• Где будет использоваться результат проекта (читай, разработка программ), в какой сфере деятельности, и на каком уровне;
• Какие требования должна удовлетворять разработка программ;
• Что нужно сделать в процессе работы над проектом;
• Как будет оцениваться результат со стороны Заказчика;
• Какими документами устанавливается порядок взаимодействия по проекту;
• На чем основана инициация работы над проектом по разработке программ.

Более детально составить техническое задание на разработку программ поможет вторая часть указанного ГОСТа 19.201-78, предписывающая содержание разделов.

Отдельным пунктом нашей специфики – разработка программного обеспечения, хотелось бы выделить раздел требований к программному обеспечению. При составлении этого раздела, к вопросу нужно подходить формально. Иначе говоря, «открывать новое окно», «редактировать текущий файл посредством команд с пользовательских консолей», и «сохранять изменения при закрытии основного окна программы» — это четкий и формальный подход.

Также, разработка программ должна удовлетворять ряду требований, которые необходимо изложить в техническом задании. Вот список требований:

• к набору выполняемых программой функций;
• по организации входных и выходных данных;
• к быстродействию;
• к надежности функционирования;
• к длительности восстановления при отказах;
• по отказам в связи с некорректными действиями пользователя;
• к видам обслуживания;
• к числу и квалификации персонала, взаимодействующего с программой;
• к параметрам технических средств, на которых будет обеспечиваться нормальная работоспособность программы;
• к исходным языкам и кодам программирования, информационным структурам и сторонним программным средствам;
• по защите и информационной безопасности;
• к маркировке и упаковке;
• к условиям транспортировки и хранения.

Также список требований на разработку программ может быть изменен: дополнен или сокращен в зависимости от конкретных условий проекта.

Кто составляет техническое задание?

Пришла пора подводить итоги. Кто же должен взвалить на свои, наверняка, хрупкие плечи, столь тяжкий груз – составление технического задания на разработку программ. Естественно, менеджер проектов! именно этот человек непосильным трудом прокладывает дорогу к совместному счастью, гармонии и взаимопониманию Исполнителя и Заказчика.

Естественно, работа менеджера не менее творческая, чем того же программиста, и дабы избежать креативного хаоса и беспорядка, она также нуждается в четком оформлении. Расставим всё, что касается функций менеджера проектов при разработке, по своим местам:

1. Постановка задачи проекта;
2. Формирование и конкретизация требований к технической реализации;
3. Формулировка требований к разрабатываемой программе;
4. Согласование этапов, их длительности, и составление документации;
5. Указание языков и кодов программирования;
6. Составление, корректировка и утверждение у Заказчика технического задания.

Несмотря на кажущуюся простоту перечисленных функций, лишь небольшой процент менеджеров способен к их качественному выполнению. п чтобы не нашлось виноватых, необходимо техническое задание утверждать подписями представителей обоих сторон, обозначенных условиями Договора на разработку программ.

Ну а сторонам этим, необходимо руководствоваться ГОСТ 19.201-78, которому ни много, ни мало, а почти 30 лет.

Related Posts

Понятие «обратный инжиниринг» является современной формулировкой прежнего понятия – копирование, усовершенствование… С развитием компьютерных технологий,…

По сути, с информационными технологиями человечество сталкивалось и сталкивается на каждом шагу своей жизнедеятельности. Просто…

Понятие реинжиниринга родилось в 90-е годы, как осмысленный ответ на возникшие проблемы при массовой автоматизации…

Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Стандарт полностью соответствует СТ СЭВ 1627-79.

Правила оформления

Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

Лист утверждения и титульный лист

Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

Изменения и дополнения

Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

Учесть все детали на начальном этапе разработки невозможно. На практике указанный подход применяется весьма часто. В разделе «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с Заказчиком».

Состав разделов технического задания

Техническое задание должно содержать следующие разделы:

введение;

основания для разработки;

назначение разработки;

требования к программе или программному изделию;

требования к программной документации;

технико-экономические показатели;

стадии и этапы разработки;

порядок контроля и приемки;

в техническое задание допускается включать приложения.

В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. Строго по согласованию с Заказчиком. Согласие Заказчика обязательно должно быть отражено в тексте технического задания.

В качестве учебно-тренировочной будем использовать реальную программу с графическим пользовательским интерфейсом, обеспечивающую возможность выполнения нескольких шаблонных функций (например, несложный текстовый редактор).

Введение

В разделе указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

Основное правило работы с текстом – детализация, дробление текста на структурные единицы, подразделы, пункты и подпункты. Оглавление текста будет иметь четкую структуру, способствующую легкому поиску требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:

Наименование программы

Наименование – «Текстовый редактор для работы с файлами формата rtf».

Краткая характеристика области применения

Программа предназначена к применению в профильных подразделениях на объектах Заказчика.

Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. Правку можно будет внести на этапе согласования технического задания с Заказчиком.

Основания для разработки

В разделе должны быть указаны:

документ (документы), на основании которых ведется разработка;

организация, утвердившая этот документ, и дата его утверждения;

наименование и (или) условное обозначение темы разработки.

В подразделе следует привести сведения, содержащиеся в Договоре.

Основание для проведения разработки

Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 15 марта 2004 года (входящий № такой-то от такого-то). Договор согласован с Директором ГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то марта 2008.

Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89, поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в Договоре. Следует ли приводить их в Техническом задании – зависит от конкретного случая.

Техническое задание (ТЗ) - исходный документ,который является основанием для разработки и испытания программы или автоматизированной системы. Техническое задание на программу и программное обеспечение разрабатывается в соответствии с требованиями . Основанием для разработки ТЗ чаще всего является договор.

ТЗ на программу разрабатывается, прежде всего, для тех людей, которые в последствии будут разрабатывать программный продукт. Как и любое другое ТЗ на программу должно быть предельно ясно и не содержать двусмысленные формулировки и должно максимально полно описывать все требования и пожелания Заказчика к создаваемой программе, но при этом не стоит забывать, что программисты люди творческие и освоить 150 листов технического текста им не всегда под силу.

Кому поручить написание ТЗ на программу

Хочется акцентировать внимание на часто совершаемой ошибке – поручить написание технического задание на программный продукт программисту, обосновывая тем, что программисту будет проще потом реализовывать собственное техзадание.

Техническое задание на программу должно разрабатываться техническим писателем! Во-первых, помимо знания ГОСТ 19.201-78, необходимо знание и других стандартов (например, ГОСТ 19.106-78 , ГОСТ 19.104 – 78 и др.), не многие программисты знают эти ГОСТы, а ещё меньше согласятся их изучить. Во-вторых, необходимы знания и опыт владения техническим письменным языком (не путать с написанием кода программного обеспечения). В-третьих, только совместно работающая команда (технический писатель, программист, менеджер проекта) смогут вместе разработать полноценное техническое задание на программу и программное обеспечение.

Структура технического задания

Крамского Романа ИТ-09-2

Лабораторная работа № 3

Формализация требований к программной системе с использованием Диаграммы прецедентов (Use сase diagram)

Цель работы : научиться анализировать и формализовать требования заказчика с использованием UML, выполнять планирование работ и составлять техническое задание на создание программного продукта.

Ход выполнения работы

Изучить теоретические сведения.

Выполнить анализ и формализацию требований заказчика на разработку программного продукта в соответствии с индивидуальным заданием.

Разработать диаграмму прецедентов использования и выполнить описание прецедентов.

Выполнить планирование работ по созданию программного продукта.

Разработать техническое задание на создание программного продукта.

Сделать выводы о выборе модели создания программного продукта.

Требования к содержанию работы

1. Название работы.

   Цель работы.

   Формулировка индивидуального задания.

   Диаграмма прецедентов использования с ее описаним (особое внимание уделить полноте описания прецедентов и ролей пользователей программной системы).

   Техническое задание на создание программного продукта (особое внимание уделить планированию работ по созданию программного продукта, формулировке этапов с использование терминов глоссария и предметной области в целом, а также описанию ролей пользователей программной системы).

   Выводы о выборе модели создания программного продукта.

Техническое задание на разработку «ПМК для а втоматизации обработки и аппроксимации экспериментальных данных »

Основания для разработки

Основанием для разработки является тема индивидуального задания для дипломной работы «ПМК для автоматизации обработки и аппроксимации экспериментальных данных» и дисциплины ППС.

Спец часть: Разработка ПО для распознавания делительных сеток и аппроксимации.

Назначение разработки

Программный комплекс предназначен для обработки и аппроксимации экспериментальных данных и должен выполнять следующие функции:

Распознавать изображение;

Выполнять сглаживание изображения;

Выделять делительные узлы.

Требования к программному изделию

При реализации и использовании информационной системы должны быть учтены требования к функциональным характеристикам, надежности проекта, параметрам технических средств, информационной и программной совместимости.

Требования к функциональным характеристикам

Программный комплекс должен выполнять следующие функции:

Распознание изображения (разрешающая способность не менее 600×300 DPI);

Выделение делительных узлов (не более 1000 узлов) ;

Вычисление координат делительных узлов (с точностью 0,01 мм);

Формирование массива данных (не более 30 секунд);

Сглаживание изображения (2 и более метода для аппроксимации в зависимости кривые или поверхности);

Сохранение результата (более 3 форматов).

Требования к надежности

Программный продукт должен устойчиво функционировать и не приводить к сбоям операционной системы в аварийных ситуациях. В случае возникновения сбоя должны выдаваться корректные сообщения с указанием дальнейших действий. Для предупреждения возникновения ошибок необходимо наличие руководства по эксплуатации ПМК.

Программный продукт должен обеспечивать контроль входной и выходной информации на соответствие заданным форматам данных.

Программный продукт должен обеспечивать обработку ошибочных действий пользователя с выдачей соответствующих сообщений.

Надежное функционирование разрабатываемого ПМК будет обеспечиваться при использовании современных ЭВМ, четком соблюдении рекомендаций. Запрещается удалять любые файлы проекта, доступ к ним должен быть ограничен.

Должно иметься резервное копирование таблиц для последующего их восстановления в случае необходимости.

Условия эксплуатации

Условия эксплуатации должны соответствовать санитарным и техническим нормам эксплуатации ЭВМ. Для работы с ПК допускаются работники, имеющие достаточный уровень знаний в предметной области. Для обслуживания данного программного комплекса нужен 1 человек.

Требования к составу и параметрам технических средств

Минимальные требования к программным и аппаратным средствам для нормального функционирования приложения:

Процессор: AMDилиIntel с частотой 1GHzи выше;

ОЗУ: 256 Mbи выше;

ОС: WindowsXPи выше;

Монитор: SVGA монитор;

Емкость ЖД: свободного места не менее 500 Mb;

Другие требования: сетевая карта, клавиатура, манипулятор мышь.

Требования к информационной и программной совместимости

Программная система функционирует в среде Windows XP и выше. Программный продукт создается с использованием инструментального средства разработки приложений С Sharp.

Требования к программой документации

Предварительный состав программной документации установлен в со-ответствии с ГОСТ 19.101-77. Ниже перечислен список программных документов и их содержание.

Текст программы – запись программы с необходимыми пояснениями и комментариями.

Описание программы – сведения о логической структуре и функциони- ровании программы.

Программа и методика испытаний – требования, подлежащие проверке при испытании программы, также порядок и методы контроля.

Техническое задание – настоящий документ.

Пояснительная записка – схема алгоритма, общее описание алгоритма или функционирования программы, а также обоснование принятых технических и технико-экономических решений.

Эксплуатационные документы – описание применения, руководство пользователя.

Стадии и этапы разработки

Разработка ведется в несколько этапов, в соответствии с ГОСТ 19.101-77 и включает этапы, приведённые в таблице 1.5.

Таблица – Этапы разработки

	Срок выполнения
	Техническое задание	Анализ и формализация требования к ПО, планирование работ
	Эскизный проект	Предварительная разработка проекта ПО с использованием UML: диаграммы прецедентов использования, диаграммы классов и последовательности
	Технический проект	Реализация рабочей версии ПО с основной функциональностью; тестирование
	Рабочий проект	Корректировка и доработка программного обеспечения; разработка документации
	Внедрение	Разработка мероприятий по внедрению и сопровождению ПО

Порядок контроля и приемки

ПМК автоматизации работы обработки и аппроксимации экспериментальных данных должен соответствовать требованиям заказчика и отвечать всем поставленным функциональным требованиям.

Контроль программного продукта осуществляется в следующем порядке.

–проверка функциональности разработанного ПО;

–проверка реакции программы на различные действия пользователя;

–проверка выходных данных;

–после выхода из программы операционная система должна продолжать работать корректно.

Принятие созданной системы заключается в тестировании его на рабочих местах после настройки программного продукта.

17.11.2014

Любая работа начинается с задания, а работа технического писателя должна начинаться с технического задания. Осталось только разобраться, что это такое и зачем оно нам нужно. Прочитайте статью Кимберли Чан, чтобы не попасть в такую же ситуацию, как разработчик из уже любимой нами серии комиксов.

Что такое техническое задание на разработку программного обеспечения?

Большинство разработчиков предпочитают работать с техническим заданием на разработку программного обеспечения, так как этот документ обычно содержит следующее:

• Полное описание целей и функциональности программного обеспечения;
• Детали того, как программа будет работать с точки зрения скорости, времени отклика, доступности, мобильности, надёжности, скорости восстановления и т.д.;
• Варианты того, как пользователи будут использовать программное обеспечение;
• Определение того, как приложение будет взаимодействовать с оборудованием или другими программами;
• Нефункциональные требования (например: требования к обеспечению эффективности, стандарты качества, или проектные ограничения)

Почему это важно ?

ТЗ позволяет разработчикам ясно понять цели программного обеспечения и то, на чём нужно фокусироваться. Кроме того, оно:

Как написать ТЗ на разработку программного обеспечения?

Нет стандартного метода написания ТЗ, но мы можем дать несколько советов:

Создайте схему

Если у вас ещё нет шаблона, их можно найти в Интернете. Используйте шаблон для создания плана документа. Измените его в соответствии с потребностями вашей организации.

Планы технических заданий различаются в зависимости от организации и её процессов. Некоторые из них могут быть простыми, другие являются более подробными и сложными.

Вот пример простого плана ТЗ на ПО:

1. Сфера применения
2. Обзор системы
3. Ссылки
4. Определения
5. Примеры использования
6. Функциональные требования
7. Нефункциональные требования

После создания плана можно писать спецификацию. Вот несколько советов:

Выберите для написания лучшего

Писатель должен иметь превосходные коммуникационные навыки. Цель спецификации в том, чтобы её мог понять каждый. Всё, что остается неясным или недопонятым, может привести к не особо приятным последствиям. Многие предполагают, что участие в процессе технического писателя помогает предотвратить непонимание. Есть писатели, более опытные, чем разработчики, с талантом вносить точность и ясность. Технические писатели знают, как собирать и обрабатывать нужную информацию; они также знают, как донести требования заказчика.

Сделайте информацию визуальной

Изображение может сэкономить 1000 слов. Включите визуальную информацию, например, таблицы и графики, чтобы лучше донести идеи.

Не документируйте слишком много

Старайтесь не включать в документ пункты, которые не нужно документировать. ТЗ может стать слишком длинным, поэтому избегайте лишней информации.

Создайте онлайн-версию ТЗ и постоянно обновляйте её

По мере выполнения задач или если произошли изменения в штате или процессах, ТЗ необходимо будет обновлять. По этой причине сохраняйте виртуальную версию­ – это поможет убедиться, что вся команда при любом изменении получит обновлённый документ.