Файл: Проектирование ис. Техническое задание (ТЗ).docx

Министерство образования и науки РФ

АНО ВО «Гуманитарный университет»

Факультет компьютерных технологий


Курсовая работа

на тему:

«Проектирование ИС. Техническое задание (ТЗ).»

Студент группы: 219

Гениятов Артем Александрович
Научный руководитель:

Сыромятников Владимир Николаевич
Оценка:_________________________

Екатеринбург

2021 г.

Содержание.

Введение.

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

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

---

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

Цель работы.

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

Задачи.

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

1. Глава 1. Анализ предметной области.

   1. Подготовка к написанию технического задания.

Для появления потребности в техническом задании требуется наличие следующих элементов:

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

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

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

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

Для этого заказчику следует сначала описать общее понимание задачи: описать следующее:

• 
  Для чего нужна ИС.
  
• 
  Какие функции от нее ожидаются.
  
• 
  Как и кто будет ее использовать.
  
• 
  Что в нем обязательно должно присутствовать.
  
• 
  Каких элементов обязательно следует исключить.
  

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

---

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

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

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

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

На этом все этапы подготовки перед техническим заданием выполнены, и можно приступать к его написанию.

2. Содержание Технического задания.

ТЗ должно обеспечивать следующие функции:

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

---

Помимо этого, ТЗ должно соответствовать государственным стандартам. В России техническое задание регулируется ГОСТами:

• 
  ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы»;
  
• 
  ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».
  

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

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

Для ГОСТ 34	Для ГОСТ 19
общие сведения;	введение;
назначение и цели создания (развития) системы;	основания для разработки;
характеристика объектов автоматизации;	назначение разработки;
требования к системе;	требования к программе или программному изделию;
состав и содержание работ по созданию системы;	требования к программной документации;
порядок контроля и приёмки системы;	технико-экономические показатели;
требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;	стадии и этапы разработки;
требования к документированию;	порядок контроля и приёмки.
источники разработки.

В дальнешем исследовании будем предполагать, что при составлении ТЗ стороны обладают знаниями о содержании ГОСТов, или они имеют отдельного специалиста по этим вопросам.

---

Стандарты являются достаточными, чтобы удовлетворить все потребности сторон в ТЗ при проектировании ИС.

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

2. Глава 2. Разработка методологии.

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

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

• 
  Этап 1: Заказчик озвучивает первоначальные требования к ИС.
  
• 
  Этап 2: Проводится предпроектное обследование.
  
• 
  Этап 3: Техническое задание пишется на основании предпроектного обследования.
  
• 
  Этап 4: ТЗ проходит согласование.
  
• 
  Окончание процесса создания ТЗ и переход к проектированию ИС.
  

Исходя из исследования предметной области , мы имеем несколько условий, влияющих на разработку:

• 
  ТЗ в проекте может не понадобится, что приводит к досрочному завершению этапа его написания.
  
• 
  ТЗ и предпроектное обследование могут писать разные лица в зависимости от решения сторон.
  
• 
  ТЗ может писаться по разным ГОСТам.
  
• 
  ТЗ может быть согласовано с первого раза, а может дорабатываттся в несколько циклов.
  

2. Алгоритмизация процессов.

Располагая этой информацией, составим алгоритм для действий при написании ТЗ. Оформим это как блок-схему:



Рисунок 1. Блок-схема алгорима написания ТЗ

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

1. Специфика участия заказчика в написании ТЗ.

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

---