Техническое задание. Порядок разработки, согласования и утверждения тз на ас

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

Что и как

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

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

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

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, Корпоративный шаблон, ваш собственный шаблон (или шаблон компании, в которой вы работаете).

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

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

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

Техническое задание на АСУТП разрабатывается по ГОСТ 34.602-89 и содержит следующие разделы:

1. Общие сведения
1.1. Полное наименование Системы
1.2. Шифр темы
1.3. Наименование Организаций - разработчиков, проектировщиков, заказчика, и их реквизиты
1.4. Перечень документов, на основании которых создается Система
1.5. Сроки выполнения работ
1.6. Источники и порядок финансирования
1.7. Порядок оформления и предъявления заказчику результатов работы
2. Назначение и цели создания Системы
2.1. Назначение Системы
2.2. Цели создания Системы
3. Характеристика объекта автоматизации
4. Требования к Системе
4.1. Требования к Системе в целом
4.1.1. Требования к структуре и функционированию Системы
4.1.2. Требования к численности и квалификации персонала
4.1.3. Требования к показателям назначения
4.1.4. Требования к надёжности
4.1.5. Требования безопасности
4.1.6. Требования по эргономике и технической эстетике
4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению
4.1.8. Требования к защите информации от несанкционированного доступа
4.1.9. Требования по сохранности информации при авариях
4.1.10. Требования к средствам защиты от внешних воздействий
4.1.11. Требования к патентной чистоте
4.1.12. Требования по стандартизации и унификации
4.1.13. Дополнительные требования
4.2. Требования к функциям, реализуемым Системой
4.2.1. Перечень задач РСУ и требования к качеству их выполнения
4.2.2. Перечень и критерии отказов для каждой функции РСУ
4.2.3. Перечень задач системы ПАЗ
4.2.4. Перечень и критерии отказов для каждой функции системы ПАЗ
4.3. Требования к видам Обеспечения
4.3.1. Требования к Прикладному программному обеспечению
4.3.2. Требования к Информационному обеспечению
4.3.3. Требования к Лингвистическому обеспечению
4.3.4. Требования к Стандартному программному обеспечению
4.3.5. Требования к Техническому обеспечению
4.3.6. Требования к Метрологическому обеспечению
4.3.7. Требования к Организационному обеспечению
5. Состав и содержание работ по созданию АСУТП
5.1. Первое организационное совещание
5.2. Обработка исходных данных
5.3. Разработка Технического проекта
5.4. Рассмотрение Технического проекта
5.5. Конфигурация функций контроля и управления
5.6. Конфигурация функций представления информации
5.7. Приемка Рабочего проекта
5.8. Шефмонтаж и пусконаладка
5.9. Пуск АСУТП в эксплуатацию
5.10. Гарантийный срок
6. Порядок контроля и приемки
7. Требования к составу и содержанию работ по подготовке объекта к вводу АСУТП в действие
8. Требования к документированию
9. Источники разработки
10. ПРИЛОЖЕНИЯ
11. СОСТАВЛЕНО
12. СОГЛАСОВАНО

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.).

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

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

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

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

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.

7. Утверждение ТЗ на АС осуществляют руководители предприятия (организаций) разработчика и заказчика системы.

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

9. Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

1О. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы или ее очереди на приемо-сдаточные испытания.

ФОРМА ТИТУЛЬНОГО ЛИСТА

Наименование организации-разработчика ТЗ на АС

наименование вида АС

наименование объекта автоматизации

сокращенное наименование АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На______листах

Действует с “ ”________ г

СОГЛАСОВАНО

Руководитель (должность, наименование

согласующей организации)

Личная Расшифровка

подпись подписи

ФОРМА ПОСЛЕДНЕГО ЛИСТА ТЗ НА АС

СОСТАВИЛИ

СОГЛАСОВАНО

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

– стадия 4 Эскизный проект ;

– стадия 5 Технический проект ;

– стадия 6 Рабочая документация .

По сокращенной схеме стадии 4, 5 и 6 реализуют как технорабочий (ТРП) проект. Его содержание определяется подразделом 4 ТЗ – разработка общесистемных требований, требований к функционированию и обеспечения АС по видам. Это – ПРОЕКТ. А реализация – в форме информационного, программного и технического обеспечений (остальные входят в их состав или, как организационное, - в виде положений, руководств и распоряжений). Проект предписывает, какие работы должны проводиться в интересах практической реализации проектных решений. То есть ТЗ предписывает ЧТО должно быть сделано, а ТРП – КАК.

Создание автоматизированной системы

После согласования и утверждения Технического задания на АС приступают непосредственно к разработке – стадиям эскизного, технического проекта и стадии рабочей документации, оканчивающейся вводом системы в действие. По составу документации эскизный и технический проекты совпадают. Эскизный проект разрабатывают для сложных и уникальных АС, требующих тщательную предварительную отработку, обоснование и согласование ключевых проектных решений. Технический проект – это разработка окончательных проектных решений как по функциям системы, так и по всем видам обеспечения. По большей части систем, как правило, стадию эскизного проекта опускают, а стадии технического проекта и рабочей документации объединяют в стадию техно-рабочего проекта (ТРП).

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

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

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

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

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

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

Разработка и утверждение технического задания на создание АС - этап 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].

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