Тз на программное обеспечение пример – Техническое задание на создание автоматизированной системы ГОСТ 34.602-89. Пример технического задания. Пример техзадание. Проектирование хранилища данных. Проектная документация | Дропшиппинг

Содержание

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

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

Стоит отметить, что в повседневной аналитической работе мы стараемся избегать термина «Техническое задание». Этот термин слишком перегружен смыслами и часто неясно, что за ним стоит. Мы используем термины «Бизнес-требования» (BRD — Business requirements document), «Функциональные требования» (FRD – Functional requirements document) и Технико-архитектурные требования (TAD – Technical Architecture document). Однако здесь, чтобы не усложнять описание, мы будем использовать именно термин «Техническое задание». Документ, который мы в большинстве случаев используем для взаимодействия с заказчиками состоит на 70% — из бизнес-требований, на 20% из функциональных требований и только на 10% — из технико-архитектурных требований. Конечно, эта пропорция варьируется в зависимости от специфики и технической сложности системы.

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

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

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

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

1. Оглавление
2. История изменений документа
3. Участники проекта
4. Назначение документа
5. Терминология
6. Общий контекст

class=»fs-13″>

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

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

class=»fs-13″>

7. Система размещения баннеров
8.

Взаимодействие с биллингом
9. Banner Engine
10. Техническое описание компонента Banner Engine

class=»fs-13″>

Самый объемный раздел описываемого нами технического задания – «Система размещения баннеров»; он посвящён ядру разрабатываемой системы и содержит все требования непосредственно к системе управления рекламными местами.

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

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

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

Каждое техническое задание отличается по размеру, числу иллюстраций, количеству версий. Для примера, документ на баннерку представлен на 44 страницах и содержит 15 иллюстраций. Процесс подготовки этого документа занял около месяца и включал около 8 итераций с заказчиком.

class=»fs-13″>

Бизнес vs Функциональные требования

В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:

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

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

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

Пример бизнес-требования:

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

Пример функционального требования:

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

Обычно мы включаем

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

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

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

Название сценария: Создание рекламного места

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

Основные принципы

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

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

Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

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

Требования должны быть написаны «живым человеческим» языком, понятным бизнес-пользователю в т.ч. руководителю высшего звена, не обладающему техническими навыками; в них должен содержаться минимум технической терминологии. Чем быстрее пользователь «вникнет» в содержания технического задания, тем более эффективно будет выстраиваться наше с ним общение.

Опыт в предметной области

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

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

1. Введение
1.1. Наименование программы
1.2. Назначение и область применения программы
2. Требования к программе
2.1. Требования к функциональным характеристикам программы
2.2. Требования к надежности программы
2.2.1. Требования к обеспечению надежного функционирования программы
2.2.2. Время восстановления программы после отказа
2.2.3. Отказы программы из-за некоректных действий оператора
3. Условия эксплуатации программы 3.1. Климатические условия эксплуатации программы
3.2. Требования к квалификации и численности персонала
3.3. Требования к составу и параметрам технических средств
3.4. Требования к информационной совместимости
3.4.1. Требования к информационным структурам и методам решения
3.4.2. Требования к исходным кодам и языкам программирования
3.4.3. Требования к программным средствам, используемым программой
3.4.4. Требования к защите информации и программ
3.5. Специальные требования
4. Требования к программной документации
4.1. Предварительный состав программной документации
5. Технико-экономические показатели
5.1. Экономические преимущества разработки программы
6. Стадии и этапы разработки программы
6.1. Стадии разработки программы
6.2. Этапы разработки программы
6.3. Содержание работ по этапам
7. Порядок контроля и приемки
7.1. Виды испытаний
7.2. Общие требования к приемке работы

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

Наименование программы: «Тестовая программа»

1.2. Назначение и область применения

Программа предназначена для…

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

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

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

2.2.1 Требования к обеспечению надежного функционирования программы

Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
а) организацией бесперебойного питания технических средств;
б) использованием лицензионного программного обеспечения;
в) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г.
Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
г) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов

2.2.2. Время восстановления после отказа

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

2.2.3. Отказы из-за некоректных действий оператора

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

3.1. Климатические условия эксплуатации

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

3.2. Требования к квалификации и численности персонала

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

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

3.3.1. В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), выполняющий роль сервера, включающий в себя:
3.3.1.1. процессор Pentium-2.0Hz, не менее;
3.3.1.2. оперативную память объемом, 1Гигабайт, не менее;
3.3.1.3. оперативную память объемом, 1Гигабайт, не менее;
3.3.1.4. операционную систему Windows 2000 Server или Windows 2003;
3.3.1.5. операционную систему Windows 2000 Server или Windows 2003;
3.3.1.6. Microsoft SQL Server 2000

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

3.4.1. Требования к информационным структурам и методам решения

База данных работает под управлением Microsoft SQL Server. Используется много поточный доступ к базе данных. Необходимо обеспечить одновременную работу с программой с той же базой данной модулей экспорта внешних данных.

3.4.2. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются

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

Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 2000 Server или Windows 2003 и Microsoft SQL Server 2000

3.4.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются

3.5. Специальные требования

Специальные требования к данной программе не предьявляются

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

Состав программной документации должен включать в себя:
4.1.1. техническое задание;
4.1.2. программу и методики испытаний;
4.1.3. руководство оператора;

5.1. Экономические преимущества разработки

Ориентировочная экономическая эффективность не рассчитываются. Аналогия не проводится ввиду уникальности предъявляемых требований к разработке.

6.1. Стадии разработки

Разработка должна быть проведена в три стадии:
1. разработка технического задания;
2. рабочее проектирование;
3. внедрение.

6.2. Этапы разработки

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

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:
1. постановка задачи;
2. определение и уточнение требований к техническим средствам;
3. определение требований к программе;
4. определение стадий, этапов и сроков разработки программы и документации на неё;
5. согласование и утверждение технического задания.
На этапе разработки программы должна быть выполнена

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

Техническое задание на разработку программы «Анализатор плоских механизмов»

Содержание

1. Наименование и область применения	2
2. Основания для разработки	2
3. Назначение разработки	2
4. Технические требования к программе или программному изделию	2
4.1. Требования к функциональным характеристикам	2
4.2. Требования к надежности	3
4.3. Условия эксплуатации	3
4.4. Требования к составу и параметрам технических средств	3
4.5. Требования к информационной и программной совместимости	3
4.6. Требования к маркировке, упаковке программного изделия	3
4.7. Специальные требования	3
5. Технико-экономические показатели	4
5.1. Экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами	4
6. Стадии и этапы разработки	4
6.1. Стадии разработки	4
6.2. Этапы разработки и содержание работ по этапам	4
7. Порядок контроля и приемки	6

1. Наименование и область применения

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

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

Задание на курсовое проектирование по дисциплине лингвистическое и программное обеспечение САПР, выданное 10 октября 2011 года.

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

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

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

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

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

Исходные данные: файл в формате .DXF экспортированный из системы Компас.

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

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

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

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

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

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

Необходимо наличие ПЭВМ IBM PC совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 500КБайт. Желательно наличие манипулятора типа «мышь».

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

Программа должна работать, автономна под управлением любой операционной системе. Базовый язык программирования: Java Script. Базовый язык гиперразметки: HTML5. Базовый язык стилизации: CSS.

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

Программное изделие может транспортироваться на любом внешнем носителе.

4.7. Специальные требования

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

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

5.1. Экономические преимущества разработки по сравнению с лучшими отечественными образцами и аналогами

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

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

6.1. Стадии разработки

— техническое задание

— эскизное проектирование

— технический проект

— рабочий проект

— внедрение

6.2. Этапы разработки и содержание работ по этапам

Техническое задание

Обоснование необходимости разработки программы — на этом этапе выполняются:

— постановка задачи;

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

— выбор и обоснование критериев эффективности и качества разрабатываемой программы.

Научно-исследовательские работы — на этом этапе выполняются:

— определение структуры входных и выходных данных;

— предварительный выбор методов решения задачи;

— обоснование целесообразности применения ранее разработанных программ;

— определение требований к техническим средствам;

— обоснование принципиальной возможности решения поставленной задачи.

Разработка и утверждение технического задания — на этом этапе выполняются:

— определение требований к программе;

— разработка технико-экономического обоснования разработки программы;

— определение стадий, этапов и сроков разработки программы и документации на нее;

— выбор языков программирования;

Эскизный проект

Разработка эскизного проекта — на этом этапе выполняются:

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

— уточнение методов решения задачи;

— разработка общего описания алгоритма решения задачи;

— разработка технико-экономического обоснования.

Утверждение эскизного проекта — на этом этапе выполняются:

— разработка пояснительной записки;

— согласование и утверждение эскизного проекта.

Технический проект

Разработка технического проекта — на этом этапе выполняются:

— уточнение структуры входных и выходных данных;

— разработка алгоритма решения задачи;

— определение формы представления входных и выходных данных;

— определение семантики и синтаксиса языка;

— разработка структуры программы;

— окончательное определение конфигурации технических средств.

Утверждение технического проекта — на этом этапе выполняются:

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

— разработка пояснительной записки;

— согласование и утверждение технического проекта.

Рабочий проект

Разработка программы — на этом этапе выполняется:

— программирование и отладка программы.

Разработка программной документации — на этом этапе выполняется:

— разработка программных документов в соответствии с требованиями ЕСПД

Испытания программы — на этом этапе выполняются:

— разработка согласование и утверждение программы и методики испытаний;

— проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний;

— корректировка программы и программной документации по результатам испытаний.

Внедрение

Подготовка и передача программы — на этом этапе выполняются:

— подготовка и передача программы и программной документации для сопровождения и /или изготовления;

— оформление и утверждение акта о передаче программы на сопровождение и/или изготовление;

— передача программы в фонд алгоритмов и программ.

7. Порядок контроля и приёмки

Предоставление работающего программного продукта на научном семинаре кафедры.

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

Техническое задание на разработку программы «Анализатор плоских механизмов»

1. Наименование и область применения
2. Основания для разработки
3. Назначение разработки
4. Технические требования к программе или программному изделию
4.1. Требования к функциональным характеристикам
4.2. Требования к надежности
4.3. Условия эксплуатации
4.4. Требования к составу и параметрам технических средств
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке, упаковке программного изделия
4.7. Специальные требования
5. Технико-экономические показатели
5.1. Экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами
6. Стадии и этапы разработки
6.1. Стадии разработки
6.2. Этапы разработки и содержание работ по этапам
7. Порядок контроля и приемки

1. Наименование и область применения
Наименование программы: «Структурный анализатор плоских механизмов». Программа используется в виде прикладного приложения для анализа файла данных формата.DXF систем автоматизированного проектирования, которые поддерживают этот формат.
2. Основания для разработки
Задание на курсовое проектирование по дисциплине лингвистическое и программное обеспечение САПР, выданное 10 октября 2011 года.
3. Назначение разработки
Программный продукт представляет собой веб приложение для анализа информации хранящейся во внешней памяти и использование её для построения схемы и визуализации динамики движения исследуемого механизма.
4. Технические требования к программе или программному изделию
4.1. Требования к функциональным характеристикам
Программа должна позволять анализировать файл в формате.DXF. Представлять информацию в виде таблицы координат найденных примитивов. Строить по заданным координатам схему плоского механизма и создавать анимацию исследуемого механизма.
Исходные данные : файл в формате.DXF экспортированный из системы Компас.
Выходные данные : графическое представление плоского механизма, динамическая модель, данные о найденных примитивах и их координатах.
4.2. Требования к надёжности
Программа должна работать с абсолютно корректными данными. Программа должна поддерживать диалоговый режим.
4.3. Условия эксплуатации
Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК. Программа должна быть рассчитана на непрофессионального пользователя т.п.
4.4. Требование к составу и параметрам технических средств
Необходимо наличие ПЭВМ IBM PC совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 500КБайт. Желательно наличие манипулятора типа «мышь».
4.5. Требование к информационной и программной совместимости
Программа должна работать, автономна под управлением любой операционной системе. Базовый язык программирования: Java Script. Базовый язык гиперразметки: HTML5. Базовый язык стилизации: CSS.
4.6. Требование к упаковке, маркировке программного изделия
Программное изделие может транспортироваться на любом внешнем носителе.
4.7. Специальные требования
Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к ёмкостным характеристикам программы не предъявляется. Программное изделие может транспортироваться на любом внешнем носителе.
5. Технико-экономические показатели
5.1. Экономические преимущества разработки по сравнению с лучшими отечественными образцами и аналогами
Данная программная разработка используется в рамках обучения, поэтому не представляет никакой экономической эффективности.
6. Стадии и этапы разработки
6.1. Стадии разработки
Техническое задание
Эскизное проектирование
Технический проект
Рабочий проект
Внедрение
6.2. Этапы разработки и содержание работ по этапам
Техническое задание
Обоснование необходимости разработки программы — на этом этапе выполняются:
Постановка задачи;
Сбор исходных материалов;
Выбор и обоснование критериев эффективности и качества разрабатываемой программы.
Научно-исследовательские работы — на этом этапе выполняются:
Определение структуры входных и выходных данных;
Предварительный выбор методов решения задачи;
Обоснование целесообразности применения ранее разработанных программ;
Определение требований к техническим средствам;
Обоснование принципиальной возможности решения поставленной задачи.
Разработка и утверждение технического задания — на этом этапе выполняются:
Определение требований к программе;
Разработка технико-экономического обоснования разработки программы;
Определение стадий, этапов и сроков разработки программы и документации на нее;
Выбор языков программирования;
Эскизный проект
Разработка эскизного проекта — на этом этапе выполняются:
Предварительная разработка структуры входных и выходных данных.
Уточнение методов решения задачи;
Разработка общего описания алгоритма решения задачи;
Разработка технико-экономического обоснования.
Утверждение эскизного проекта — на этом этапе выполняются:
Согласование и утверждение эскизного проекта.
Технический проект
Разработка технического проекта — на этом этапе выполняются:
Уточнение структуры входных и выходных данных;
Разработка алгоритма решения задачи;
Оп
Техническое задание на программу по гост 19.201-78
Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1627-79.
Правила оформления
Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.
Лист утверждения и титульный лист
Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
Изменения и дополнения
Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Учесть все детали на начальном этапе разработки невозможно. На практике указанный подход применяется весьма часто. В разделе «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с Заказчиком».
Состав разделов технического задания
Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. Строго по согласованию с Заказчиком. Согласие Заказчика обязательно должно быть отражено в тексте технического задания.
Содержание разделов
В качестве учебно-тренировочной будем использовать реальную программу с графическим пользовательским интерфейсом, обеспечивающую возможность выполнения нескольких шаблонных функций (например, несложный текстовый редактор).
Введение
В разделе указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
Основное правило работы с текстом – детализация, дробление текста на структурные единицы, подразделы, пункты и подпункты. Оглавление текста будет иметь четкую структуру, способствующую легкому поиску требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:
Наименование программы
Наименование – «Текстовый редактор для работы с файлами формата rtf».
Краткая характеристика области применения
Программа предназначена к применению в профильных подразделениях на объектах Заказчика.
Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. Правку можно будет внести на этапе согласования технического задания с Заказчиком.
Основания для разработки
В разделе должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.
В подразделе следует привести сведения, содержащиеся в Договоре.
Основание для проведения разработки
Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 15 марта 2004 года (входящий № такой-то от такого-то). Договор согласован с Директором ГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то марта 2008.
Удобно воспользоваться разделом «Общие сведения» ГОСТ 34.602-89, поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в Договоре. Следует ли приводить их в Техническом задании – зависит от конкретного случая.
Пример технического задания на разработку программы
Техническое задание
Введение.
Наименование программы: «Вектор в n-мерном пространстве».
Краткая характеристика области применения.
Программа разрабатывается для решения задач линейной алгебры.
Основание для разработки.
Учебный план по направлению 231300 «Прикладная математика» (бакалавры).
Назначение разработки.
Программа предназначена для выполнения операций с векторами.
Требования, предъявляемые к программе.
Требования к функциональным характеристикам программы.
В программе должны быть реализованы следующие операции:
создание вектора заданного размера с нулевыми значениями элементов;
ввод вектора;
вывод вектора;
доступ к элементу вектора по индексу;
сложение векторов;
изменение знаков элементов на противоположные;
присваивание одного вектора другому;
сравнение двух векторов на равенство.
Требования к техническим средствам, используемым при работе программы.
Работа программы должна осуществляться на ПЭВМ с микропроцессором типа Pentium в стандартном окружении.
Требования к языкам программы и среде разработки программы.
Исходный код программы должен быть записан на языке программирования С++. В качестве среды разработки должна быть использована среда С++ Builder.
Требования к информационным структурам на входе и выходе программы.
Входными данными программы являются числовые данные, вводимые с клавиатуры, выходными данными – числовые данные, выводимые на экран.
Требования к программной документации.
Состав программной документации должен включать:
Этапы разработки.
Обзор способов организации данных и обоснование выбора структуры данных для эффективного выполнения операций 01.10.2011-15.10.2011.
Разработка программы: 16.10.2011-30.11.2011.
Разработка программной документации: 01.12.2011-10.12.2011.
Оформление пояснительной записки 11.12.2011-15.12.2011.
Защита курсовой работы: 16.12.2011-26.12.2011.
Приложение 2
Пример описания программы
Общие сведения.
Наименование программы: «Вектор в n-мерном пространстве».
Программное обеспечение, необходимое для функционирования программы: С++ Builder.
Язык программирования, на котором написана программа: С++.
Функциональное назначение программы: «Вектор в n-мерном пространстве» предназначен для выполнения операций с векторами.
Технические средства, которые используются при работе программы: ПЭВМ с микропроцессором типа Pentiumв стандартном окружении.
Вызов программы: запустить файл test.exe.
Входные данные: значения элементов вектора, вводимые с клавиатуры.
Выходные данные: значения элементов вектора, выводимые на экран.
Приложение 3
Титульный лист

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И
АВТОМАТИКИ»
ФАКУЛЬТЕТ ИТ
Кафедра «Прикладная математика»
КУРСОВАЯ РАБОТА
Тема:_______________________________
Дисциплина: Программирование для ЭВМ
Студент _
Группа _
Руководитель работы_______
Москва 2012
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
Павловская Т.А. С/С++. Программирование на языке высокого уровня. – СПб.: Питер, 2002. – 464 с.
Павловская Т.А., Щупак Ю.А. C/С++. Структурное программирование: Практикум. – СПб.: Питер, 2002. – 240 с.
Литературный редактор _
Подписано в печать /////////2007. Формат 60×84 1/16.
Бумага офсетная. Печать офсетная.
Усл. печ. л. /// Усл.кр.-отт. ////. Уч.-изд.л. ////.
Тираж 100. Заказ ////. Бесплатно.
Государственное образовательное учреждение высшего профессионального образования «Московский государственный институт радиотехники, электроники и автоматики (технический университет)»
Техническое задание на программу (ПО)
Техническое задание (ТЗ) — исходный документ,который является основанием для разработки и испытания программы или автоматизированной системы. Техническое задание на программу и программное обеспечение разрабатывается в соответствии с требованиями ГОСТ 19.201-78. Основанием для разработки ТЗ чаще всего является договор.
ТЗ на программу разрабатывается, прежде всего, для тех людей, которые в последствии будут разрабатывать программный продукт. Как и любое другое ТЗ на программу должно быть предельно ясно и не содержать двусмысленные формулировки и должно максимально полно описывать все требования и пожелания Заказчика к создаваемой программе, но при этом не стоит забывать, что программисты люди творческие и освоить 150 листов технического текста им не всегда под силу.
Кому поручить написание ТЗ на программу
Хочется акцентировать внимание на часто совершаемой ошибке – поручить написание технического задание на программный продукт программисту, обосновывая тем, что программисту будет проще потом реализовывать собственное техзадание.
Техническое задание на программу должно разрабатываться техническим писателем! Во-первых, помимо знания ГОСТ 19.201-78, необходимо знание и других стандартов (например, ГОСТ 19.106-78, ГОСТ 19.104 – 78 и др.), не многие программисты знают эти ГОСТы, а ещё меньше согласятся их изучить. Во-вторых, необходимы знания и опыт владения техническим письменным языком (не путать с написанием кода программного обеспечения). В-третьих, только совместно работающая команда (технический писатель, программист, менеджер проекта) смогут вместе разработать полноценное техническое задание на программу и программное обеспечение.
Структура технического задания
Состав разделов техзадания на программу указан всё в том же ГОСТ 19.201–78 (п.1.4).
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и разработки;
в техническое задание допускается включать приложения.
В стандарте очень чётко описан состав ТЗ на программное обеспечение, но в тоже время стандарт (всё тот же п.1.4) даёт поле для творчества разработчику Технического задания.
Как заказать ТЗ
Несмотря на столь почтенный возраст стандарта, он позволяет составить и разработать полноценное техническое задание на программное обеспечение. Если у Вас возникла необходимость в написании и разработке технического задания на программу удовлетворяющего всем требованиям стандартов, Вы можете обратиться к нашим специалистам по телефону +7(499)755-74-33 или электронной почте и мы с удовольствием поработаем над проектом.