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

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

«правильная постановка задачи — это уже половина ее решения»
(Д. Гильберт)

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

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

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

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

Поскольку программа для ЭВМ согласно ст.1261 ГК РФ включает в себя также «подготовительные материалы, полученные в ходе разработки программы», автор «технического проекта» по праву может считаться соавтором программы. В то время как разработчик «эскиза», остается лишь автором документа под названием «техническое задание».

Общие требования к составу, содержанию и оформлению техзадания (образец техзадания) изложены в ГОСТ 34.602-89 и ГОСТ 19.201-78.

Так, согласно положениям ГОСТ, техзадание, как правило, включает следующие основные разделы:

1) общие сведения о программе (указываются полное/сокращенное наименования ПО и его область применения, также в данном разделе следует указать перечень терминов и сокращений, используемых в ТЗ);
2) назначение, цели и задачи ПО;
3) требования к ПО (в частности, его функциональным характеристикам, надежности, безопасности, условия эксплуатации и т.п.);
4) требования к программной документации (указывается предварительный состав проектной (пояснительная записка к ТЗ, программа испытаний ПО и др.) и эксплуатационной (руководство пользователя, администратора и т.п.) документации);
5) стадии и этапы разработки ПО (поэтапное содержание работ, сроки разработки);
6) порядок контроля и приемки (описание процесса сдачи созданного ПО и требования к приемке работы).

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

Максимально детализированное ТЗ может быть выгодно обеим сторонам договора:

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

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

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

Разработка прикладного программного обеспечения

контроллера и панели оператора

АННОТАЦИЯ

Настоящий документ содержит программу и методику испытаний (ПМИ) прикладного

программного обеспечения (ППО) для щитов постоянного тока серии В производства ОАО «Заказчик», установленных на Электростанции.

Техническое задание определяет технические требования, стадии и этапы разработки, состав

эксплуатационной документации, а также порядок контроля и приемки ППО для щитов

постоянного тока В.

СОДЕРЖАНИЕ

1.1. Наименование разработки

1.2. Область применения

2. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ

2.1. Наименование предприятия Исполнителя и его реквизиты

2.2. Наименование предприятия Заказчика и его реквизиты

2.3. Перечень документов, на основании которых создается ППО

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

4. ТРЕБОВАНИЯ К ПРОГРАММЕ

4.1. Общие требования к программному обеспечению

4.1.1. Требования к инструментальному программному обеспечению панели предоставления информации

4.1.2. Требования к прикладному программному обеспечению ПЛК

4.1.3. Требования к прикладному программному обеспечению для получения данных по Modbus RTU

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

4.2.1. Общие требования

4.2.2. Требования к отображению информации и сигнализации

4.2.3. Требования к архивированию информации

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

4.2.5. Требования к функциям диагностики

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

Читайте также:  Суп пюре из шампиньонов постный

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

4.5. Требования к сетевому взаимодействию

5. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

5.1. Требования на соответствие нормам и правилам

5.2. Требования к составу документации

6. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ППО

7. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ

7.1. Проведение предварительных испытаний

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

7.3. Оборудование, которое будет необходимо для проведения ПНР, но которое не входит в состав компонентов системы

Таблица ввода-вывода для системы

ПЕРЕЧЕНЬ ПРИНЯТЫХ СОКРАЩЕНИЙ

1. ВВЕДЕНИЕ

1.1. Наименование разработки

Полное наименование разработки – разработка прикладного программного

обеспечения для щитов постоянного тока.

Сокращенное наименование разработки – ППО

1.2. Область применения

Область применения – модернизация систем щитов постоянного тока

Щиты постоянного тока предназначены для обеспечения питания постоянным током

систем аварийного электроснабжения (САЭ), дизель-генератора (ДГС), общеблочной

системы (ОБ), систем управления защит (СУЗ), открытого распределенного устройства,

систем обеспечения сохранности основного оборудования (ОС), управляющих

вычислительных систем (УВС).

2. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ

ППО разрабатывается на основании Договора No от

2.1. Наименование предприятия Исполнителя и его реквизиты

Закрытое акционерное общество « Исполнитель» (ЗАО « Исполнитель»)

2.2. Наименование предприятия Заказчика и его реквизиты

Открытое акционерное общество «Заказчик» (ОАО «Заказчик»)

2.3. Перечень документов, на основании которых создается ППО

Для разработки ППО в качестве исходных данных (ИД) используются

– Техническое задание на ППО .

– ПРИЛОЖЕНИЕ 1 Таблица ввода-вывода для системы

– ПРИЛОЖЕНИЕ 2 Перечень событий

– ПРИЛОЖЕНИЕ 3 Структурная схема

Исполнитель вправе запросить у Заказчика иные ИД, не указанные в настоящем

перечне, необходимость в которых может возникнуть в ходе разработки.

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

ППО входит в состав системы, выполняющей функции индикации и архивирования

входящей в систему информации от сигналов ввода-вывода, а также вывод сообщений

оператору о произошедших событиях с меткой времени.

Целью выполняемых работ является обеспечение:

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

500 сообщений, в виде кольцевого буфера;

– формирования предупредительного или аварийного сообщения при нарушении

(тока, напряжения, сопротивления изоляции) регламентных или аварийных границ;

– обработки входных дискретных сигналов, характеризующих работу защитной и

коммутационной аппаратуры щитов постоянного тока;

– диагностики аппаратного обеспечения контроллера, диагностики связи

аппаратного обеспечения по сети CanOpen.

4. ТРЕБОВАНИЯ К ПРОГРАММЕ

4.1. Общие требования к программному обеспечению

ППО должно быть разработано в инструментальной среде Uniti XL v6.0 и пакет

Vijeo-Designer Lite фирмы Schneider Electric V1.3.

В состав программного обеспечения должны входить:

– базовые системные программные средства, совместимые с аппаратными

– ППО, которое должно быть разработано для реализации функций контроля и

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

ППО должно подразделяться на ППО ПЛК и ППО панели оператора.

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

обеспечения возможности сопровождения должны иметь открытый код. Разработчиком

должны поставляться соответствующие программные (программно-аппаратные) ключи, обеспечивающие возможность сопровождения ПО контроллеров и панели.

4.1.1. Требования к инструментальному программному обеспечению панели

4.1.1.1. Инструментальное программное обеспечение панели должно представлять

собой пакет Vijeo-DesignerLite фирмы Schneider Electric V1.3

4.1.1.2. Интерфейсы ПО ПК должны быть выполнены на русском языке.

4.1.1.3. Программное обеспечение панели должно быть адаптировано и

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

4.1.1.4. Программное обеспечение панели должно быть интуитивно понятным и

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

– Отображение текущего состояния сигналов ввода-вывода на видеокадрах.

4.1.2. Требования к прикладному программному обеспечению ПЛК

4.1.2.1. Программное обеспечение ПЛК должно разрабатываться с использованием

инструментальной системы UNITY PRO XL версии не ниже 6.0, фирмы Schneider Electric на языках по стандарту Международной электротехнической комиссии МЭК 61131-3.

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

4.1.2.3. Программные средства ПЛК должны обеспечивать реализацию следующих

– информационный обмен по коммуникационным каналам;

Читайте также:  Как отремонтировать электрический чайник своими руками

– ввод/вывод по дискретным и аналоговым каналам;

– сбор данных и управление световыми табло;

– конфигурирование системных программных средств под конкретный объект;

– диагностирование программно-аппаратных средств;

4.1.3. Требования к прикладному программному обеспечению для получения

данных по Modbus RTU

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

контроллера информацию в виде «среза» (буфера обмена) в виде файла XLS до 500 строк сообщений.

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

4.2.1. Общие требования

4.2.1.1. ППО должно обеспечивать следующие функции:

– контроль технологических параметров (тока, напряжения, сопротивления

изоляции), состояние коммутационных аппаратов;

– преобразование измерений в единицы физической размерности;

– сглаживание (фильтрация) измерений;

– формирование и выдача команд на внешнюю световую индикацию;

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

параметров в виде мнемосхем (однолинейные схемы);

– регистрация событий: изменения состояния коммутационных аппаратов,

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

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

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

4.2.2. Требования к отображению информации и сигнализации

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

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

Лист вывода сообщений должен нести информацию о точном времени и дате

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

4.2.3. Требования к архивированию информации

4.2.3.1. Должна быть предусмотрена возможность ведения следующих архивов:

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

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

сообщений должна быть сформирована в виде кольцевого буфера.

В архиве должны фиксироваться следующие события:

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

– неисправность аппаратов защит и коммутационных аппаратов;

– неисправности и отказы в программных и технических средствах системы

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

4.2.4.1. Период обновления информации на панели представления информации

должен составлять не более 1 секунды.

4.2.4.2. Периодичность опроса параметров должен соответствовать циклу опроса

контроллера и быть не более 200 мс.

4.2.5. Требования к функциям диагностики

4.2.5.1. ППО должно выполнять следующие диагностические функции:

– проверку на обрыв или короткое замыкание датчиков для токовых каналов

– проверку достоверности (выход за измерительный диапазон);

– диагностику сетевых соединений на шине CanOpen с проверкой на обрыв связи.

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

Центральные процессоры должны иметь тип BMXP3420302. Состав модулей ввода-

вывода указан в приложении 9 и 10 настоящего Технического Задания (ТЗ).

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

ППО ЩПТ должно строиться по модульному принципу, обеспечивающему

автономное создание отдельных программных модулей (ПМ) на базе стандартной

библиотеки функциональных блоков (ФБ) инструментального пакета Unity Pro XL V.6.

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

4.5.Требования к сетевому взаимодействию

4.5.1.1. Взаимодействие на уровне сети Ethernet TCP/IP

Система должна обеспечивать возможность получения текущего состояния сигналов

ввода-вывода в защищенную сеть предприятия. Адреса сетевых устройств и адреса

переменных уточняются при проведении ПНР.

4.5.1.2. Взаимодействие на уровне сети Modbus RTU

Заказчику будет передано приложение, позволяющее получать данные из кольцевого буфера и просматривать сообщения в формате MS OFFICE EXCEL. Заказчику необходимо будет предоставить компьютер с предустановленной системой Windows XP SP3.

5.1. Требования на соответствие нормам и правилам

Разработка и оформление документации ППО должно выполняться в соответствии с требованиями:

Документация должна быть разработана для следующих серий ЩПТ – 4EA, 4EB, 4EC и 4ED в отдельности.

5.2. Требования к составу документации

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

– Техническое задание на разработку ППО.

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

– Программа и методика приемочных испытаний на площадке эксплуатации ( ).

6. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ППО

Читайте также:  Рукомойник для ванной комнаты с шкафом

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

-Разработка и согласование Технического задания на создание ППО щитов

-Доработка ППО в соответствии с требованиями настоящего технического задания.

-Разработка технической документации в соответствии с Календарным планом (таблица 6.1).

-Проведение предварительных испытаний ППО на полигоне Исполнителя с

использованием программного имитатора сигналов нижнего уровня.

Календарный план выполнения работ приведен в таблице 6.1.

Таблица 6.1 – Календарный план выполнения работ

No

этапа

Наименование

работ

Сроки выполнения
Начало Окончание Отчетные материалы 1

1. ТЗ на ПО ПЛК и ПО панели.

2. Описание программы.

3. Программа и методика испытаний.

4. Руководство программиста.

5. Руководство оператора.

6. Программное изделие (CD) c

формуляром по акту приёма-

7. Протокол предварительных

8. Акт сдачи-приёмки работ.

*Существует разночтение по п.6.

На момент сдачи программы ввиду

физического отсутствия модулей

памяти ППО будет передана на

другом носителе информации.

7.1. Проведение предварительных испытаний

Целью предварительных испытаний ППО являются испытания на соответствие

настоящему техническому заданию. Испытания проводятся в соответствии с методикой приемочных испытаний.

Предварительные испытания ППО должны производиться по согласованной

программа +и методика приемочных испытаний (ПМИ) на стенде Исполнителя

При получении неудовлетворительных результатов предварительных испытаний

Исполнитель должен провести анализ причин выявленных неисправностей, принять

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

проводить только по тем требованиям, по которым были получены неудовлетворительные

К предварительным испытаниям должны быть представлены:

– Программа и методика испытаний.

Сдача-приемка осуществляется комиссией, в состав которой входят представители

Заказчика и Исполнителя.

По результатам приемки подписывается Акт предварительных испытаний.

7.2. Последовательность проведения пуско-наладочных мероприятий по каждой

– Загрузка нового системного обеспечения (firmware) для обеспечения

– Проверка и корректировка ППО в части приема полевых сигналов на шине

CanOpen. Настройка шины CanOpen;

– Загрузка ППО в контроллер системы;

– Загрузка ППО в панель визуализации;

– Настройка и устранение выявленных недостатков.

7.3. Оборудование, которое будет необходимо для проведения ПНР, но которое не

входит в состав компонентов системы

Персональный переносной компьютер с предустановленной операционной системой

Windows XP SP3, а также офисным пакетом MS OFFICE 2007(10).

Таблица ввода-вывода для системы 4EA

Собсвтенно сабж, можно английский.

гугл и яндекс дают какой-то хлам типа:

1. ОБЩИЕ ТРЕБОВАНИЯ
1.1 Техническое задание оформляется в соответствии с ГОСТ 19.106-78 на листах формата А4 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
1.2 Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

нет, это не нужно.

1. ТЗ на разработку успешного продукта, например, (простихосподи) Экселя
2. чек-лист, что в хорошем ТЗ должно быть, а что нет.

  • Вопрос задан более трёх лет назад
  • 8211 просмотров

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

Чаще все это выглядит так:
1) Сначала накидываются пользовательские истории (user story), тот функционал, который Вы хотите иметь в программе. Они состоят из одного-двух предложений, кратко описывают одну единственную функцию. Например: хочу, чтобы была авторизация пользователей с подтверждением по email; хочу, чтобы у пользователя с ролью "админ" была собственная страничка для администрирования; и.д. В историях не должно быть никаких технических нюансов, только "хочу" заказчика (ну или Ваши).

2) Затем составляется карта (roadmap), в которой Вы описываете каждый шаг работы этой функции (пользовательской истории) с точки зрения пользователя:
1. Главная страница.
1.1 В правом верхнем углу находятся поля для аутентификации (для логина и пароля). Рядом находится кнопка "войти" и ссылка "зарегистрироваться".
1.2 При удачной аутентификации происходит переход на страницу . и выводится сообщение "Добро пожаловать . "

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

Чтоб увидеть чужие ТЗ, полазите по чужому коду на гитхабе. Там очень часто люди описывают свой roadmap.

Ссылка на основную публикацию
Adblock detector