Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть? Техническое задание: как уберечь себя от ошибок и рисков

Подготовка к лабораторной работе

Ознакомиться с лекционным материалом по теме «Модели ЖЦ ПО. Этапы ЖЦ в соответствии с ГОСТ 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. Разработать программный модуль «Книжный магазин», содержащий сведения о книгах (автор, название, издательство, год издания, цена). Покупатель оформляет заявку на нужные ему книги, если таковых нет, он заносится в базу и оповещается, когда нужные книги поступают в магазин.

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

I. Общие положения

1.1. Порядок разработки и утверждения технических заданий по подготовке инвестиционных программ организаций коммунального комплекса, осуществляющих эксплуатацию систем коммунальной инфраструктуры и (или) объектов, используемых для утилизации (захоронения) твердых бытовых отходов, на территории муниципального образования «Город Калуга» (далее – Порядок) устанавливает основы организации разработки и утверждения технических заданий по подготовке инвестиционных программ организациями коммунального комплекса (далее - ОКК).

1.2. Понятия и термины, используемые в настоящем Порядке, применяются в значениях, определенных Федеральным законом от 01.01.01 г. «Об основах регулирования тарифов организаций коммунального комплекса».

1.3. Техническое задание разрабатывается на основании действующего законодательства, программы комплексного развития систем коммунальной инфраструктуры (далее - СКИ) и настоящего Порядка.

Организует разработку технических заданий с учетом реального состояния СКИ и определяет перспективу развития СКИ управление городского хозяйства города Калуги (далее – УГХ) совместно с управлением строительства и земельных отношений города Калуги (далее – УСиЗО).

1.4. Техническое задание в части требований к разработке инвестиционной программы организацией коммунального комплекса (далее - ОКК) обуславливает выстраивание системы планов, элементами которой могут быть:

- генеральный план городского округа «Город Калуга»;

Программа комплексного развития СКИ;

Программа выбытия ветхого и аварийного жилищного фонда муниципального образования «Город Калуга»;

Программа модернизации и реформирования жилищно-коммунального хозяйства муниципального образования «Город Калуга».

2. Порядок разработки и содержание технического задания

2.1. Техническое задание разрабатывается индивидуально для каждой ОКК, осуществляющей эксплуатацию СКИ и (или) объектов, используемых для утилизации (захоронения) твердых бытовых отходов (далее - ТБО).

2.2. В техническое задание включаются:

2.2.1. Цели и задачи разработки и реализации инвестиционной программы ОКК по развитию СКИ, которые формируются на основании общих целей, определенных программой комплексного развития. Основными целями программы комплексного развития СКИ, как правило, являются: оптимизация, развитие и модернизация муниципальных систем тепло-, электро-, газо-, водоснабжения и водоотведения для сохранения их работоспособности или обеспечения целевых параметров улучшения их состояния. В качестве цели может ставиться задача снизить параметры износа оборудования. В случае отсутствия программы комплексного развития СКИ цели разработки и реализации инвестиционной программы формулируются непосредственно в рамках разрабатываемого технического задания.

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

2.2.3. Сроки разработки инвестиционной программы.

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

2.3. Цели разработки и реализации инвестиционной программы определяются таким образом, чтобы они были количественно измерены. Цели определяются в виде целевых индикаторов, представляющих собой доступную наблюдению и измерению характеристику состояния и развития СКИ, условия эксплуатации указанных систем ОКК, которые необходимо обеспечить за счет реализации инвестиционной программы (далее - целевые индикаторы).

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

Прогноза социально-экономического развития муниципального образования «Город Калуга»;

Планируемых на период реализации разрабатываемой инвестиционной программы объемов ввода объектов жилищного и промышленного строительства , а также характеристик вводимых объектов;

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

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

2.3.2. Информация о планируемых на период реализации разрабатываемой инвестиционной программы объемах ввода объектов жилищного и промышленного строительства, а также характеристики земельных участков, обеспечиваемых инженерной инфраструктурой в целях подключения объектов строительства (реконструкции), представляется УСиЗО по запросу УГХ и должна содержать:

Перечень строительных площадок, а также перечень зданий, строений и сооружений, подключаемых к СКИ, с указанием планируемого адреса;

Предельное количество этажей и (или) предельную высотность застройки каждого из зданий, строений, сооружений в границах строительных площадок;

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

Красные линии соответствующих территорий;

Границы зон действия установленных и частных сервитутов;

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

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

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

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

Финансовое состояние ОКК (в том числе кредиторской и дебиторской задолженности , плановой и фактической выручки);

Показатели производственной программы ОКК;

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

2.3.5. Для разработки технического задания, в том числе для определения целевых индикаторов, УГХ запрашивает от ОКК в письменной форме необходимую информацию с указанием перечня, формы и сроков ее предоставления.

2.3.6. Целевые индикаторы инвестиционной программы определяются таким образом, чтобы они отражали потребности муниципального образования «Город Калуга» в товарах и услугах ОКК, требуемый уровень качества и надежности работы СКИ при соразмерных затратах и экологических последствиях.

Целевые индикаторы могут быть сгруппированы, в том числе в следующие группы:

Надежность (бесперебойность) снабжения потребителей товарами (услугами) ОКК;

Доступность товаров и услуг для потребителей (в том числе обеспечение новых потребителей товарами и услугами ОКК);

Эффективность деятельности ОКК;

Обеспечение экологических требований.

2.3.7. Целевые индикаторы могут определяться с учетом показателей и индикаторов мониторинга, устанавливаемых Методикой проведения мониторинга выполнения производственных и инвестиционных программ организаций коммунального комплекса, утверждаемой Минрегионом России по согласованию с Минэкономразвития России и Федеральной службой по тарифам Российской Федерации.

2.3.8. Основные требования при определении целевых индикаторов:

Однозначность - изменения целевых индикаторов должны однозначно характеризовать положительную или отрицательную динамику происходящих изменений состояния СКИ, а также не иметь различных толкований;

Измеримость - каждый целевой индикатор должен быть количественно измерен;

Доступность - проведение расчета значений индикаторов не должно быть связано с проведением дополнительных исследований и должно минимизировать затраты времени и ресурсов на расчет значений;

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

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

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

2.3.11. В целях обеспечения единых подходов к формированию целевых показателей развития СКИ необходимо в максимальной степени обеспечить синхронизацию разработки целевых индикаторов в технических заданиях, разрабатываемых для различных ОКК.

2.4. Требованиями к инвестиционной программе определяются условия, на соответствие которым УГХ будет проводить проверку инвестиционной программы.

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

2.5.1. В случае отсутствия в муниципальном образовании «Город Калуга» программы комплексного развития в техническом задании могут быть обозначены приоритеты развития инженерной инфраструктуры муниципального образования «Город Калуга» на среднесрочную перспективу, в рамках которой ОКК разрабатывает технические мероприятия по строительству и (или) модернизации СКИ и объектов, используемых для утилизации (захоронения) ТБО. Обозначение приоритетов развития инфраструктуры может заключаться в определении не только значений целевых индикаторов для всей СКИ, но и для отдельных элементов системы (технологических и производственных этапов производства и реализации товаров и услуг).

В техническом задании могут быть сформулированы требования по проведению работ, которые должны были войти в указанную программу. К таким работам можно отнести анализ существующего состояния СКИ и объектов, используемых для утилизации (захоронения) ТБО, с выявлением основных проблем, не позволяющих обеспечить необходимый уровень объемов и качества предоставления товаров и услуг ОКК.

2.5.2. Разработка плана технических мероприятий по строительству и (или) модернизации СКИ и объектов, используемых для утилизации (захоронения) ТБО. При разработке мероприятий учитывать: существующее состояние указанных систем и объектов и обеспечивать доведение их состояния, а также условий их эксплуатации до уровня, задаваемого целевыми индикаторами технического задания; обеспечивать подключение строящихся (реконструируемых) объектов, указанных в техническом задании, к СКИ, а также обеспечивать земельные участки инженерной инфраструктурой. В случае отсутствия программы комплексного развития перечень указанных объектов и земельных участков с их характеристиками и характеристиками планируемых подключаемых объектов (в том числе нагрузок) рекомендуется проводить в приложении к техническому заданию.

2.5.3. В рамках разработки инвестиционной программы в соответствии с частью 3 статьи 11 Федерального закона от 01.01.01 г. должны быть определены финансовые потребности на ее реализацию, которые определяются на основании финансовых потребностей по реализации каждого из мероприятий программы.

2.5.4. Реализация инвестиционной программы, включая отдельные ее мероприятия, в соответствии с частью 1 статьи 10 Федерального закона от 01.01.01 г. обеспечивается соответствующими источниками финансирования, которые гарантируют своевременность инвестиций в необходимом объеме.

2.5.5. Могут быть сформулированы требования по предварительному расчету надбавок к тарифам и тарифов на подключение.

2.5.6. Может быть сформулировано условие о необходимости подготовки ОКК проекта инвестиционного договора в целях развития СКИ. Реализация инвестиционной программы в соответствии с частью 13 статьи 11 Федерального закона от 01.01.01 г. основывается на договоре, заключаемом Городской Управой города Калуги с ОКК, определяющем условия реализации утвержденной инвестиционной программы.

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

2.5.8. Требование к форме инвестиционной программы, отражающей требования к ее разработке.

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

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

2.7. По решению УГХ в техническое задание могут быть включены иные требования.

3. Порядок согласования, утверждения

и изменения технического задания

3.1. Техническое задание разрабатывается и утверждается в сроки, учитывающие период подготовки ОКК инвестиционной программы и сроки утверждения данной программы.

3.2. Проект технического задания предварительно согласовывается УГХ с ОКК, разрабатывающей инвестиционную программу.

3.3. Разработанный проект технического задания в случае необходимости рассматривается на рабочей группе, в состав которой входят представители УГХ, УСиЗО, управления архитектуры и градостроительства города Калуги, управления экономики города Калуги, Городской Думы города Калуги, ОКК, а также по согласованию могут входить и заинтересованные организации, планирующие осуществить строительство (реконструкцию) объектов капитального строительства с подключением новой (дополнительной) нагрузки к СКИ.

3.4. Рассмотренный рабочей группой проект технического задания утверждается правовым актом Городской Управы города Калуги.

3.5. Подготовку проекта правового акта Городской Управы города Калуги об утверждении технического задания осуществляет УГХ.

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

3.7. В качестве оснований для пересмотра (внесения изменений) в утвержденное техническое задание рекомендуется определять:

Принятие или внесение изменений в программу комплексного развития муниципального образования «Город Калуга»;

Принятие или внесение изменений в программы социально-экономического развития муниципального образования «Город Калуга» и иные программы, влияющие на изменение условий технического задания;

Вынесение органом регулирования муниципального образования «Город Калуга» решения о недоступности для потребителей товаров и услуг ОКК с учетом надбавки к ценам (тарифам), предлагаемой ОКК для обеспечения реализации инвестиционной программы;

Объективные изменения условий деятельности ОКК, влияющие на стоимость производимых ею товаров (оказываемых услуг), и невозможность пересмотра надбавки к тарифам на товары и услуги ОКК и (или) тарифа ОКК на подключение;

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

3.8. Пересмотр (внесение изменений) технических заданий может производиться не чаще одного раза в год.

3.9. При пересмотре или внесении изменений в техническое задание предусматриваются изменение значений целевых индикаторов, определенных в техническом задании, и (или) корректировка перечня подключаемых к СКИ строящихся (реконструируемых) объектов, а также перечня земельных участков, обеспечиваемых инженерной инфраструктурой.

3.10. В случае если пересмотр, внесение изменений технического задания осуществляется по инициативе ОКК, заявление о необходимости пересмотра технического задания направляется ОКК Городскому Голове города Калуги. Заявление ОКК о пересмотре или внесении изменений в техническое задание должно сопровождаться обоснованием причин пересмотра или внесения изменений в техническое задание с приложением необходимых документов.

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

3.12. Решение об утверждении или пересмотре технического задания, внесение изменений в техническое задание доводятся до ОКК, осуществляющей разработку инвестиционной программы, УГХ в письменном виде в недельный срок со дня его принятия.

Что делать, если разработка ТЗ не самого сложного проекта занимает пару месяцев? Какие шаги при разработке ТЗ могут уберечь от рисков и ошибок? В данной статье мы рассмотрим проблему не содержания документа, а методологию его разработки.

Что и как

Техническое задание - лишь часть проекта. Будь то стартап или новый сервис внутри уже существующего продукта.

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

Этапы разработки технического задания

1. Предварительное изучение брифа/задачи

Как правило, есть эфемерное представление того, что хочет заказчик - в виде брифа, письма с «хотелками», ТЗ. Изучите предметную область, составьте список вопросов.

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

2. Проведение встречи

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

Не проводите встречу как анкетирование, заказчик может почувствовать себя на допросе и замкнуться. Начать следует с «расскажите о проекте, что вы ожидаете получить от него». Заказчик расслабится, будет много говорить, а вы, тем временем, будете делать заметки, что совпало с вашим видением и пониманием, а что нет.

Ответы фиксируйте рядом с вопросами, перечитывайте их.

Если ответ так и не получен (бывает, что заказчик абстрактно отвечает на вопрос, и в итоге ответа нет), задайте вопрос снова, изменив формулировку. Например, «я представляю себе этот функционал так… Верно я вас понимаю? Это совпадает с вашим видением?»

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

3. Разработка концепции

Концепция обычно содержит краткие тезисы будущего ТЗ, а именно:

• Цели и задачи;
• Назначение;
• Роли;
• Структура;
• Содержание;
• Список возможностей (в виде сервисов - кратко).
• Порой концепция содержит подробное описание бизнес-идеи, для понимания, чем выигрышен проект.

Всегда разрабатывайте концепцию - набросок будущего проекта. Зачастую это позволяет сократить риски, а также расставить все точки над i и для вас, и для заказчика.

4. Уточнение требований

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

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

Даже если все кажется понятным и очевидным, нужно задать вопрос, верно ли вы понимаете. Это сократит кучу времени и нервов. Даже говоря о простых новостях, не стоит забывать, что есть понятия «частота публикации», кто обновляет, какие материалы могут быть в новостях, etc. От ответов на подобные вопросы может кардинально меняться структура страницы и приоритетность информации.

5. Утверждение ТЗ

Заказчики делятся на два типа - те, кто несерьезно относятся к ТЗ и думают «все равно потом сделают, как я скажу» и на тех, кто старается уместить в ТЗ возможное и невозможное. В проекте важно сделать хороший рабочий продукт. Без избытков.

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

Старайтесь всегда думать о том, кто будет пользоваться продуктом. Предоставить все возможности пользователю - можно, но либо во вред удобству, либо во вред времени реализации.

Трудности и как избежать

1. Срыв сроков

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

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

2. Цена-сроки-объем работ

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

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

4. Старайтесь фиксировать все, о чем договариваетесь

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

Если заказчик присылает по 15 писем в день с пожеланиями, попросите заказчика собирать пожелания в одно письмо. Так вы уменьшите риски, что часть информации затеряется в переписке, а вам придется потратить время на внесение изменений.

5. Презентуйте результат

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

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

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

Ментальные карты

Техника Mind Maps. Разрабатывайте ТЗ при помощи ментальных карт. Суть процесса состоит в том, что вы изначально рисуете будущий проект в виде схемы. Вы делите продукт на сущности, понятия; при этом в каждом пункте дерева не должно быть больше 3-4 слов. Подобная схема быстро считывается всеми участниками проекта, легко изменять и дополнять дерево. Существует множество программ для разработки таких карт.

Версии и названия файлов

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

По опыту удобно делать названия и версии следующего вида:

NameProject.0.1.doc ,

Где NameProject - название проекта,

0 - версия, отправленная клиенту; если 0 - значит, не отправлялось, пока работаете внутри компании (отдела);

1 - версия, которую вы создаете внутри компании (отдела).

Например, вы отправили клиенту версию 0.1, при этом работаете над ТЗ дальше. Вы создаете версию 0.2, потому что это изменение, но уже ваши внутренние или внутри компании. Вы получаете комментарии от клиента и создаете еще более новую версию - 1.3.

Если документов несколько (например, концепция, ТЗ), добавьте тип документа в название документа - NameProject.Concept.0.1.

Структура

Имейте четкую структуру ТЗ. При сборе информации, а также разработке документа, следуйте ей. В зависимости от ожиданий заказчика существует 4 альтернативы для выбора шаблона технического задания. Это может быть ГОСТ, IEEE, Корпоративный шаблон, ваш собственный шаблон (или шаблон компании, в которой вы работаете).

Форматирование

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

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

Разработка и утверждение технического задания на создание АС - этап 3.1 стадии технического задания. Редакция от 20.06.2018.

Разработка и утверждение технического задания на создание АС

Создан 18.05.2018 11:24:34

Из толкового словаря

Разработка - это построение, создание, утверждение - придание документу законной (юридической) силы. В текущем это заполнение структурных ТЗ и получение утверждающей подписи на его титульном листе. И оттиска печати утверждающей.

Термины и определения

Утверждение - Официальное удостоверение уполномоченного на это должностного лица или в том, что разработанный вводится в действие. Удостоверение может быть зафиксировано на утверждаемом документе непосредственной или ссылкой на другой документ, содержащий решение об утверждении (акт, протокол, письмо и т.д.) [из п. 1.4.74 Р 50-605-80-93].

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

На титульном листе помещают заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. При необходимости титульный лист оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на последнем листе. Форма титульного листа ТЗ на АС приведена в. Форма последнего листа ТЗ на АС приведена в [из п. 3.4 ГОСТ 34.602-89].

На 3.1 «Разработка и утверждение технического задания на создание АС» проводят разработку, и и, при необходимости, технических заданий на части АС [из п. 7 прил. 1 ГОСТ 34.601-90].

Связанные документы

• ГОСТ 34.602-89 ИТ. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

ТЗ — основной документ, без которого не может быть создан полноценный технический проект (ТП), или техно-рабочий проект.

Документ ГОСТ 34.602-89 «ТЗ на создание АС» содержит в первых же строках явное указание:

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

Приступая к написанию ТЗ (ЧТЗ) необходимо собрать первичные сведения, которые будут отображаться на титульном листе.

Следует начинать написание ТЗ (ЧТЗ) с титульного листа. Титульный лист содержит:

1. Наименование заказчика
2. Наименование системы / подсистемы
3. Наименование типа документа (ТЗ / ЧТЗ и т.д.)
4. Наименование очереди создания АС
5. Шифр темы
6. Согласующие надписи

Наименование заказчика

Заказчиков может быть несколько, но лишь один из них будет основным. Сведения о составе и структуре заказчика должны быть отражены в тексте ТЗ. На титульном листе указывается основной согласованный заказчик. Могут быть следующие варианты состава заказчиков:

1. Единственный заказчик (наиболее частая ситуация)
2. Группа заказчиков, в которой кто-то один является основным. Например, один заказчик является функциональным, т.е. АС создаётся непосредственно для него. Другой же заказчик оплачивает разработку. На титульном листе следует отображать лишь одного заказчика. Этот вопрос следует предварительно согласовать с руководством заказчиков. Обычно этот вопрос относится к компетенции менеджера проекта.
3. В отдельных случаях заказчик может потребовать указать наименование исполнителя, без указания собственного наименования. Этот вопрос также следует предварительно согласовать с заказчиком.

Как правило у заказчика два наименования — полное и краткое. Специалисты со стороны заказчика отрицательно относятся к ошибкам в обоих наименованиях. Обычно языковая форма наименования на титульном листе следующая: <Полное наименование заказчика> (<Краткое наименование заказчика>). Если заказчик подчиняется какой-либо вышестоящей организации, возможно следует включить её наименование в наименование заказчика.

Полные наименования госструктур часто содержат языковой фрагмент «Российская Федерация». В полном наименовании не следует сокращать наименование страны; как правило, заказчик весьма жестко реагирует на попытки использовать аббревиатуру РФ в полном наименовании. Служащие государственных учреждений, как правило, относятся подчеркнуто уважительно к государственной атрибутике. Часто подобная позиция способствует составлению длинных официальных текстов. По нашему мнению, сложившееся положение вещей следует принять как данность.

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

Наименование системы / подсистемы

АС может состоять из подсистем. Подсистемы — из модулей. АС состоит из множества элементов, которые могут образовывать иерархию. Языковое обозначение этих элементов может быть различным; главное — согласовать термины с заказчиком, чтобы общаться с ним на одном языке. В явном виде ГОСТ 34.602-89 содержит лишь 2 термина — Система (АС) и Подсистема. Остальные термины д.б. определены заказчиком и исполнителем.

Наименование типа документа

В данном случае м.б. следующие типы документа:

1. Техническое задание (ТЗ) на разработку АС
2. Техническое задание на модификацию АС
3. Частное техническое задание на разработку какой-либо части АС, например Подсистемы, входящей в АС
4. Частное техническое задание на модификацию АС / Подсистемы.

ТЗ и ЧТЗ

Следует определиться с типом документа — ТЗ или ЧТЗ?

ТЗ пишется на всю Систему (АС). ЧТЗ на какую-либо часть АС — на Подсистему.

При наличии общего ТЗ на АС имеет смысл писать ЧТЗ на отдельные подсистемы. ЧТЗ предполагает наличие ТЗ.

Если речь идёт о написании ЧТЗ, тогда на титульном листе следует указывать 2 наименования: наименование АС и наименование Подсистемы.

Документы ГОСТ серии 34 не содержат термина «Частное техническое задание». Вместе с тем в документе ГОСТ 34.003-90 «АС. Термины и определения» читаем:

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т.п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

Разработка и модификация

В требованиях к содержанию документа ТЗ (см. ГОСТ 34.602-89) используются следующие термины:

1. Разработка АС
2. Модификация АС
3. Развитие АС
4. Модернизация АС

Трудно провести чёткую границу между этими понятиями (кроме п.п. 1-2). Поэтому мы предлагаем рабочую версию определений, не претендующую на полноту.

Разработка АС — написание кода, документации, проведение пусконаладочных работ, внедрение и т.д. с нуля.

Модификация АС — внесение согласованных изменений в уже существующую АС.

Развитие АС — дополнение АС какими-либо новыми элементами (например, новой подсистемой)

Модернизация АС — перевод АС на новую платформу (например на новую ОС).

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

От понимания этих терминов будет зависеть состав работ проектной команды, сроки исполнения, объём необходимых ресурсов, характер последующих испытаний и т.д.

Наименование очереди создания АС

Следует различать два понятия:

1. стадии и этапы создания АС (см. ГОСТ 34.601-90 «АС. Стадии создания»)
2. очередь создания АС

ГОСТ 34.003-90 ИТ. «Комплекс стандартов на АС. АС. Термины и определения» так определяет термины:

очередь создания АС — часть АС, для которой в техническом задании на создание АС в целом установлены отдельные сроки ввода и набор реализуемых функций

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

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

ГОСТ 34 в явном виде не объясняет различие между стадиями/этапами создания АС и очередями создания АС.

На практике часто прибегают к следующей схеме: создание АС делится на очереди (1-я, 2-я и т.д.). Внутри каждой очереди работы делятся на стадии и этапы. Схема очередности создания АС должна содержаться в конкурсной документации и дополнительно согласовываться с заказчиком.

Шифр темы

Следует различать понятия:

1. Шифр темы
2. Краткое наименование АС
3. Децимальный номер

Шифр темы — это краткое (как правило буквенное) обозначение АС. Шифр темы может не совпадать с кратким наименованием АС. Шифр темы следует уточнять у заказчика. Качественно написанная конкурсная документация содержит шифр темы (такое случается не часто). Не все заказчики обладают оргструктурой, отвечающей за присвоение системам шифров и децимальных номеров.

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

ТЗ — НЕ имеет децимального номера. Децимальный номер присваивается документам технорабочего проекта (ТРП). ТЗ — не является частью ТРП. Децимальный номер, как правило формируется исполнителем, однако возможен вариант, при котором присвоение номер осуществляет заказчик. Этот вопрос следует уточнять у Заказчика.

Согласующие надписи

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