«правильная постановка задачи — это уже половина ее решения»
(Д. Гильберт)
Техническое задание является основным проектным документом для создания программного продукта.
Как правило, техзадание оформляется в виде приложений к договору на разработку программного обеспечения и является его неотъемлемой частью с момента подписания сторонами.
Если подготовку договора на создание ПО лучше поручить юристу (специалисту в составлении правовой документации), написание техзадания требует иных, технических (а не юридических) знаний, поэтому его разработкой должно заниматься лицо, обладающее знаниями в области программирования: программист, технический директор, иные лица при наличии достаточных знаний.
Ниже рассмотрена структура и требования к содержания ТЗ (образец техзадания), руководствуясь которыми можно грамотно составить техзадание. Представленный образец техзадания подойдет как к договору на создание ПО, так и договору авторского заказа (в отличие от первого, он заключается непосредственно с автором).
Поскольку программа для ЭВМ согласно ст.1261 ГК РФ включает в себя также «подготовительные материалы, полученные в ходе разработки программы», автор «технического проекта» по праву может считаться соавтором программы. В то время как разработчик «эскиза», остается лишь автором документа под названием «техническое задание».
Общие требования к составу, содержанию и оформлению техзадания (образец техзадания) изложены в ГОСТ 34.602-89 и ГОСТ 19.201-78.
Так, согласно положениям ГОСТ, техзадание, как правило, включает следующие основные разделы:
1) общие сведения о программе (указываются полное/сокращенное наименования ПО и его область применения, также в данном разделе следует указать перечень терминов и сокращений, используемых в ТЗ);
2) назначение, цели и задачи ПО;
3) требования к ПО (в частности, его функциональным характеристикам, надежности, безопасности, условия эксплуатации и т.п.);
4) требования к программной документации (указывается предварительный состав проектной (пояснительная записка к ТЗ, программа испытаний ПО и др.) и эксплуатационной (руководство пользователя, администратора и т.п.) документации);
5) стадии и этапы разработки ПО (поэтапное содержание работ, сроки разработки);
6) порядок контроля и приемки (описание процесса сдачи созданного ПО и требования к приемке работы).
Вне зависимости от того, какой из сторон договора поручена разработка техзадания, руководствуясь ГОСТом, стороны смогут избежать многих разногласий.
Максимально детализированное ТЗ может быть выгодно обеим сторонам договора:
— исполнителю, поскольку позволит четко определить свои обязательства относительно характеристик создаваемого ПО и, соответственно, избежать включения заказчиком дополнительных требований за рамками согласованного ТЗ;
— заказчику, соответственно, позволит четко сформулировать свои требования к продукту в целях его последующей идентификации (созданное ПО должно соответствовать характеристикам, изложенным в ТЗ; если условия техзадания не позволяют четко установить какое ПО должно быть создано в результате его реализации, заказчику будет проблематично подтвердить свои права на программный продукт).
Таким образом, технической задание является основополагающим документом не только в процессе создания ПО, но и для последующего закрепления прав на него, поэтому к его составлению необходимо подходить с особой внимательностью.
Профессор кафедры ВС
на разработку «Модуля автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского
Работа выполняется в рамках проекта «Автоматизированная система оперативно-диспетчерского управления электротеплоснабжением корпусов Московского института».
- 2. Основание для разработки
- 2.1. Основанием для данной работы служит договор № 1234 от 10 марта 2003 г.
- 2.2. Наименование работы:
«Модуль автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института».
- 2.3. Исполнители: ОАО «Лаборатория создания программного обеспечения».
- 2.4. Соисполнители: нет.
- 3. Назначение разработки
Создание модуля для контроля и оперативной корректировки состояния основных параметров теплообеспечения корпусов Московского института.
- 4. Технические требования
- 4.1. Требования к функциональным характеристикам.
- 4.1.1. Состав выполняемых функций.
Разрабатываемое ПО должно обеспечивать:
- • сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков 5А-94 на всех тепловых выходах;
- • сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);
- • предварительный анализ информации на предмет нахождения параметров в допустимых пределах и сигнализирование при выходе параметров за пределы допуска;
- • выдачу рекомендаций по дальнейшей работе;
- • отображение текущего состояния по набору параметров — циклически постоянно (режим работы круглосуточный), при сохранении периодичности контроля прочих параметров;
- • визуализацию информации по расходу теплоносителя:
- — текущую, аналогично показаниям счетчиков;
- — с накоплением за прошедшие сутки, неделю, месяц — в виде почасового графика для информации за сутки и неделю;
- — суточный расход — для информации за месяц.
Для устройств управления приточной вентиляцией текущая информация должна содержать номер приточной системы и все параметры, выдаваемые на собственный индикатор.
По отдельному запросу осуществляются внутренние настройки.
В конце отчетного периода система должна архивировать данные.
4.1.2. Организация входных и выходных данных.
Исходные данные в систему поступают в виде значений с датчиков, установленных в помещениях института. Эти значения отображаются на компьютере диспетчера. После анализа поступившей информации оператор диспетчерского пункта устанавливает необходимые параметры для устройств, регулирующих отопление и вентиляцию в помещениях. Возможна также автоматическая установка некоторых параметров для устройств регулирования.
Основной режим использования системы — ежедневная работа.
4.2. Требования к надежности.
Для обеспечения надежности необходимо проверять корректность получаемых данных с датчиков.
4.3. Условия эксплуатации и требования к составу и параметрам технических средств.
Для работы системы должен быть выделен ответственный оператор.
Требования к составу и параметрам технических средств уточняются на этапе эскизного проектирования системы.
4.4. Требования к информационной и программной совместимости.
Программа должна работать на платформах Yindows 98/
- 1ЧТ/2000.
- 4.5. Требования к транспортировке и хранению.
Программа поставляется на лазерном носителе информации.
Программная документация поставляется в электронном и печатном виде.
- 4.6. Специальные требования:
- • программное обеспечение должно иметь дружественный интерфейс, рассчитанный на пользователя (в плане компьютерной грамотности) квалификации;
- • ввиду объемности проекта задачи предполагается решать поэтапно, при этом модули ПО, созданные в разное время, должны предполагать возможность наращивания системы и быть совместимы друг с другом, поэтому документация на принятое эксплуатационное ПО должна содержать полную информацию, необходимую для работы программистов с ним;
- • язык программирования — по выбору исполнителя, должен обеспечивать возможность интеграции программного обеспечения с некоторыми видами периферийного оборудования (например, счетчик ЗА-94 и т. п.).
Основными документами, регламентирующими разработку будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): руководство пользователя, руководство администратора, описание применения.
6. Технико-экономические показатели
Эффективность системы определяется удобством использования системы для контроля и управления основными параметрами теплообеспечения помещений Московского института, а также экономической выгодой, полученной от внедрения аппаратно-программного комплекса.
7. Порядок контроля и приемки
После передачи Исполнителем отдельного функционального модуля программы Заказчику последний имеет право тестировать модуль в течение 7 дней. После тестирования Заказчик должен принять работу по данному этапу или в письменном виде изложить причину отказа принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль.
Собсвтенно сабж, можно английский.
гугл и яндекс дают какой-то хлам типа:
1. ОБЩИЕ ТРЕБОВАНИЯ
1.1 Техническое задание оформляется в соответствии с ГОСТ 19.106-78 на листах формата А4 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2 Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
нет, это не нужно.
1. ТЗ на разработку успешного продукта, например, (простихосподи) Экселя
2. чек-лист, что в хорошем ТЗ должно быть, а что нет.
- Вопрос задан более трёх лет назад
- 8194 просмотра
Все зависит от того какими методологиями разработки Вы пользуетесь.
Чаще все это выглядит так:
1) Сначала накидываются пользовательские истории (user story), тот функционал, который Вы хотите иметь в программе. Они состоят из одного-двух предложений, кратко описывают одну единственную функцию. Например: хочу, чтобы была авторизация пользователей с подтверждением по email; хочу, чтобы у пользователя с ролью "админ" была собственная страничка для администрирования; и.д. В историях не должно быть никаких технических нюансов, только "хочу" заказчика (ну или Ваши).
2) Затем составляется карта (roadmap), в которой Вы описываете каждый шаг работы этой функции (пользовательской истории) с точки зрения пользователя:
1. Главная страница.
1.1 В правом верхнем углу находятся поля для аутентификации (для логина и пароля). Рядом находится кнопка "войти" и ссылка "зарегистрироваться".
1.2 При удачной аутентификации происходит переход на страницу . и выводится сообщение "Добро пожаловать . "
Потом на основе этой карты, делается прототипирование, выделяются задачи, если надо, разбиваются на более мелкие подзадачи.
Чтоб увидеть чужие ТЗ, полазите по чужому коду на гитхабе. Там очень часто люди описывают свой roadmap.
