Проектирование ИС. Техническое задание (ТЗ). Проектирование ис. Техническое задание (ТЗ)
 Скачать 0.88 Mb.
|
|
Министерство образования и науки РФ АНО ВО «Гуманитарный университет» Факультет компьютерных технологий Курсовая работа на тему: «Проектирование ИС. Техническое задание (ТЗ).» Студент группы: 219 Гениятов Артем Александрович Научный руководитель: Сыромятников Владимир Николаевич Оценка:_________________________ Екатеринбург 2021 г. Содержание.Содержание. 2 Введение. 3 Цель работы. 3 Задачи. 4 1Глава 1. Анализ предметной области. 5 1.1Подготовка к написанию технического задания. 5 1.2Содержание Технического задания. 7 2Глава 2. Разработка методологии. 10 2.1Общие положения. 10 2.2Алгоритмизация процессов. 10 2.2.1Специфика участия заказчика в написании ТЗ. 12 2.2.2Специфика участия исполнителя в написании ТЗ. 17 3Глава 3. Применение методологии. 19 3.1Примеры использования. 19 3.2Перспективы для внедрения и совершенствования методологии. 21 Заключение 23 Список литературы. 24 Введение.Любая сфера деятельности предприятий, в том числе IT-компаний, включает в себя этап поиска договоренности между людьми: представителями власти и предприятием, между клиентом и предприятием, между сотрудниками разных отделов, между начальником и подчиненными. Для этих взаимодействий существуют специальные документы, регламенты поведения, уставы и.т.д. Такая формализация договоренности между сторонами очень важна для профилактики возможных будущих разногласий. По бумагам, описывающим условия договора можно споры, однозначным образом определяя нарушителя своих обязательств. Помимо этого, четко расписанные требования и ожидания помогают ускорить процессы, связанные с достижением общих целей сторон. Техническое задание – это документ из сферы проектирования и разработки программных продуктов. Целью технического задания является преобразование требований заказчика в план действий для исполнителя таким образом, чтобы у обеих сторон было однозначное толкование происходящих в процессе выполнения работ процессов. Чтобы этот документ соответствовал тому, для чего был задуман, в его разработку следует включить ряд процессов. Важно понять, когда ТЗ необходимо, какими способами его можно составить, какова в этом процессе доля действий заказчика и исполнителя, какие пункты оно обязательно должно включать в себя и какими средствами будет достигаться однозначность их толкования. Цель работы.Разработать методику написания технического задания по проектированию информационных систем. Задачи.Проанализировать предметную область: понять, на каких этапах работы возникает потребность в ТЗ, когда без него можно обойтись и какие элементы ТЗ должно в себе содержать. Придумать алгоритмы, шаблоны для написания ТЗ, а также согласования его с обеими сторонами предметной области. Протестировать разработанные методы для написания ТЗ на примере нескольких ситуаций. Предложить варианты дальнейшего применения и развития разработанной методики на предприятиях. Отразить результаты работы в отчете. Глава 1. Анализ предметной области.Подготовка к написанию технического задания.Для появления потребности в техническом задании требуется наличие следующих элементов: Существует исполнитель: компания, отдел внутри компании, независимый разботчик, осуществляющий разработку и проектирование информационных систем. Существует заказчик в лице организации. У заказчика есть спрос на ИС, который может удовлетворить исполнитель. В случае, если мы разрабатываем ИС не для конкретной компании, а для массового использования, то заказчиком будет выступать наша собственная организация, а исполнителем – команда разработчиков внутри нее. По наличию у нас двух действующих сторон можно понять, что последовательность действий в процессе создания ТЗ у них будет разная, значит, методология написания ТЗ должна включать как рекомендации для заказчиков, так и исполнителей. После, в процессе переговоров/согласований, сторонам необходимо понять, способны ли они осуществлять дальнейшее сотрудничество без ТЗ. Для этого заказчику следует сначала описать общее понимание задачи: описать следующее: Для чего нужна ИС. Какие функции от нее ожидаются. Как и кто будет ее использовать. Что в нем обязательно должно присутствовать. Каких элементов обязательно следует исключить. Исполнитель оценивает эти данные и, в зависимости от своего опыта и ресурсов, объема и сложности работ или подтверждает, что ТЗ необходимо, или задача достаточно простая и типовая, чтобы обойтись без этого. В последнем случае некоторые разработчики предлагают сразу создавать прототипы продуктов, и дополнять их по мере появления правок и замечаний со стороны заказчика. В случае согласия с этим методом работы наш анализ заканчивается. Если исполнитель до конца не уверен, справится ли он без технического задания, он или заказчик (в зависимости от принцпов работы организаций или договоренности) может провести предпроектное обследование. Данные, полученные в результате него или подтвердят нецелесообразность ТЗ в данном проекте, или лягут в основу будущего технического задания. Предпроектное обследование установит текущий способ работы заказчика: Организационная структура компании в целом, отделов и их взаимодействий между собой. С какими данными работают сотрудники (Списки контрагентов, сведения о номенклатуре, нормативно-справочная информация, документооборот). Как потоки этих данных перемещаются между сотрудниками на уровне программных средств. Это определит как условия для проектирования ИС по требованиям заказчика, так и затраты на внедрения: интеграцию с текущими средствами или полный перенос их функций на новую ИС. Уровень технической подготовки сотрудников для выявления возможной потребности в обучении Рассматриваем ситуацию, когда для проведения работ все же нужно ТЗ. Окончательное техническое задание на основе предпроектного обследования можно осуществить следующими способами: Если, заказчик проводил предпроектное обследование сам, или у него, например, есть технические специалисты в штате, которых выделили на этот проект, а исполнитель выступает больше как подрядчик, то в силах заказчика и самому написать ТЗ. Так же, традиционно заказчик пишет его сам в случае, если исполнителем является фрилансер, проводящий только конкретные работы по реализации, а проектированием не занимается. Если у заказчика мало технических компетенций, и он в поисках такого исполнителя, который выполнит все этапы проектных работ самостоятельно в формате «Все включено» - то исполнителю отводится роль составить ТЗ и после согласовать его, и, возможно, вносить правки. Из представителей обеих сторон может быть сформирована общая группа ответственных за проект. Они совместными усилиями будут писать ТЗ, а после сотрудничать по проекту в дальнейшем. На этом все этапы подготовки перед техническим заданием выполнены, и можно приступать к его написанию. Содержание Технического задания.ТЗ должно обеспечивать следующие функции: Организационная – упорядочивание процесса работы для исполнителя. Информационная – изложение достаточно подробной для выполнения проекта информации. Коммуникационная – разрешение всех возникающих между заказчиком и исполнителем вопросов касательно проектирования ИС. Юридическая – в случае возникновения разногласий права и обязанности сторон, перечисленные в ТЗ, помогут разрешить конфликт. Помимо этого, ТЗ должно соответствовать государственным стандартам. В России техническое задание регулируется ГОСТами: ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы»; ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». Первый стандарт технического задания используется в случае создания ИС под конкретное предприятие, второй – если проектируемое решение рассчитана на массовое использование. Наличие этих стандартов значительно упрощает составление методологии для ТЗ, состав и нужные разделы мы возьмем оттуда: Таблица 1. Разделы технического задания в соответсвии с государственными стандартами.
В дальнешем исследовании будем предполагать, что при составлении ТЗ стороны обладают знаниями о содержании ГОСТов, или они имеют отдельного специалиста по этим вопросам. Стандарты являются достаточными, чтобы удовлетворить все потребности сторон в ТЗ при проектировании ИС. Составленное по стандартам техническое задание проходит согласование сторон, и в случае несогласия проходит через необходимое количество циклов правок. Готовое ТЗ вкладывается в договор между сторонами. Глава 2. Разработка методологии.Общие положения.Обобщая процесс составления технического задания, мы можем разделить его на ключевые этапы: Этап 1: Заказчик озвучивает первоначальные требования к ИС. Этап 2: Проводится предпроектное обследование. Этап 3: Техническое задание пишется на основании предпроектного обследования. Этап 4: ТЗ проходит согласование. Окончание процесса создания ТЗ и переход к проектированию ИС. Исходя из исследования предметной области , мы имеем несколько условий, влияющих на разработку: ТЗ в проекте может не понадобится, что приводит к досрочному завершению этапа его написания. ТЗ и предпроектное обследование могут писать разные лица в зависимости от решения сторон. ТЗ может писаться по разным ГОСТам. ТЗ может быть согласовано с первого раза, а может дорабатываттся в несколько циклов. Алгоритмизация процессов.Располагая этой информацией, составим алгоритм для действий при написании ТЗ. Оформим это как блок-схему:  Рисунок 1. Блок-схема алгорима написания ТЗ Эта схема в общем виде описывает порядок действий, описанных в анализе предметной области. Однако на практике действия сторон заказчика и исполнителя не согласованы в одну последовательность, и для наглядного руководства к детвию необходимо составить по алгоритму для каждой из сторон. Специфика участия заказчика в написании ТЗ.Рассматривая предметную область в общем виде, мы не учитывали, что заказчик играет активной роль в процессе, то есть ему следует сначала найти исполнителя внутри собственной компании и на стороне, оценить его компетенции и принять решение о сотрудничестве. Понимание заказчика происходит на начальных этапах работы по проектированию ИС: написании ТЗ и предпроектном обследовании. Соответственно, это следует отразить на блок схеме.  Рисунок 2. Алгоритм написания ТЗ для заказчика. Общий вид.  Рисунок 3. Алгоритм написания ТЗ для заказчика. Фрагмент 1.  Рисунок 4. Алгоритм написания ТЗ для заказчика. Фрагмент 2.  Рисунок 5. Алгоритм написания ТЗ для заказчика. Фрагмент 3.  Рисунок 6.Алгоритм написания ТЗ для заказчика. Фрагмент 4. Заказчику, как конечному пользователю ИС приходится принимать много решений, чтобы не ошибиться с проектом, поэтому блок-схема имеет большое число развествлений. Специфика участия исполнителя в написании ТЗ.У исполнителя также должна быть собственная последовательность действий, обозначенная алгоритмом. По блок-схеме для исполнителя можно увидеть, что она не сильно отличается от общей, за исключением того, что на разных этапах требуется дождаться решения заказчика:  Рисунок 7.Алгоритм написания ТЗ для исполнителя. Глава 3. Применение методологии.Примеры использования.Нам удалось составить алгоритмы действий, выполняя которые, написание технического задания становится однозначным процессом, не вызывающим трудности при соглашении сторон. Для того, чтобы наглядность показать эффективность получившегося метода, рассмотрим его работу на примере нескольких ситуаций В одной из практических работ по дисциплине мы составляли схему отделов предприятия:  Рисунок 8. Схема организационной структуры компании "Решения для предприятий". Рассмотрим ситуацию. Предприятие занимается разработкой и продажей своих программных решений. В отдел разработки компании активно поступают предложения по доработке их программного продукта. Группа поддержки ПП принимает решение разработать дополнение к ИС, которое объединит все желаемые клиентами функции в единое целое. Поскольку это компетенция отдела нетиповых решений, группа поддержки ПП обращается к ним за разработкой такого дополнения. Исходя из нашей методологии, группа поддержки ПП выступает заказчиком, а группа нетиповых решений – исполнителем. Руководитель отдела разработки организует для команд встречу, где заказчик рассказывает о планируемых доработках к текущему программному решению. Группа нетиповых решений принимает решение, что эту работу они могут выполнить без ТЗ: ИС уже давно им знакомая, они регулярно сталкиваются с ней в своей работе, а доработки не такие масштабные, чтобы их документировать. Исполнитель предлагает сразу составить тестовый прототип новой версии программы, с чем соглашается заказчик. В результате, на предварительном этапе удалось избежать излишней бумажной работы и сразу приступить к, непосредственно, проекту. Возьмем другой пример. Ателье планирует расширение сферы деятельности: помимо частных заказов они собираются изготавливать одежду и униформу партиями для предприятий малого бизнеса, и для этого им нужна ИС, которая помогала бы вести учет по материалам на складе, отправке партий по нужным адресам, и другим управленческим задачам. Планируется также перенести в эту ИС начисление зарплат швеям. Они нашли компанию «Решения для предприятий», и те согласились спроектировать для них ИС. Приняв к сведению большое количество нововведений в процесс производства ателье, было принято решение провести предпроектное обследование. У заказчика нет в штате технических специалистов, поэтому «Решения для предприятий» проводит его самостоятельно. ИС будет спроектирована для ателье в индивидуальном порядке, и исполнитель выбирает для ТЗ соответствующий этому ГОСТ. Заказчик очень доволен профессионализмом исполнителя и принимает ТЗ без дополнительных правок. В данном примере стороны успешно прошли через все стадии согласования, разработанные нашей методикой, и в результате успешно осуществили проект. Приведем ситуацию, когда от исполнителя компания-заказчик в результате отказывается. Горнодобывающая компания решает сэкономить на собственном штате технических специалистов, и для проектирования ИС для бухгалтерского учета обращается к фрилансеру. Начальник компании ничего не понимает в информационных технологиях, и предпроектное обследование ложится на исполнителя. Поняв, что специфику учета объектов горной промышленности он не в силах, фрилансер предлагает компании самостоятельно составить требования к будущей программе. Привыкший получать только готовый результат заказчик в результате решает не прибегать к помощи такого малоопытного специалиста. Следуя шагам в алгоритме, обеим сторонам не хватило компетенции для написания технического задания, и потому их деловые отношения были своевременно прекращены. Перспективы для внедрения и совершенствования методологии.Составленная нами система по написанию ТЗ может быть использована разными способами. Наиболее простой и понятный способ применения – памятки и методические материалы для менеджеров и технических специалистов, помогающие правильно выстраивать взаимоотношения между сторонами в процессе написания ТЗ. Поскольку правила по написанию ТЗ, придуманные нами, представляют собой алгоритм, его можно написать на любом объектно-ориентированном языке программирования и использовать как самостоятельную программу-помощник для принятия решений менеждерам компаний. Алгоритм можно совместить с базой данных контрагентов компании, текстовым редактором, разработать типовые печатные формы для формирования ТЗ по ГОСТу, и все это объедить в CRM для общения с участниками проекта, и тогда может получиться комплексная система по проектированию ИС на заказ. Применимость методологии на практике, а также возможность ее внедрения в процессы компании разными способами говорит об универсальности и полезности составленной нами работы. ЗаключениеВ процессе выполнения курсовой работы мы разработали методику написания технического задания по проектированию информационных систем. Мы проанализировали предметную область того, как пишется ТЗ, какие средства применяются в процессе его написания, Адаптировали процесс в наглядную схему, рассмотрели ее применимость в различных ситуациях и обозначили перспективы ее применения в конкретных решениях. Все это помогло сделать написание ТЗ более простым и понятным процессом, улучшили качество работы для предприятий, который будут опираться на методологии в процессе своей работы. Список литературы.Карл И. Вигерс, Джой Битти «Разработка требований к программному обеспечению», М. – 2014 Селиверстова П.О., Точилкина Т.Е. Методика выполнения учебного реинжиниринга бизнес-процессов для студентов // Экономика и менеджмент инновационных технологий. - 2015. - № 4.-С. 81-87. Как составить техническое задание и получить то, что нужно – Контур | журнал [Электронный ресурс]. URL: https://kontur.ru/articles/5945 ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы Предпроектное обследование - как сэкономить на автоматизации – Инфософт [Электронный ресурс]. URL: https://is1c.ru/about/pc/article/predproektnoe-obsledovanie-kak-sekonomit-na-avtomatizatsii/ Техническое задание: для чего оно нужно – Многостраничные журналы [Электронный ресурс]. URL: https://mnogostranichka.ru/blog/texnicheskoe-zadanie-chto-eto-takoe-i-dlya-chego-ono-nuzhno/ Предпроектное обследование – Шеф Консалтинг [Электронный ресурс]. URL: http://chiefcons.ru/services/komplexnaya_avtomatizacia/predproject/ Зараменских Е.П. Основы бизнес-информатики: Учебник для бакалавриата и магистратуры. – Москва: Юрайт, 2017. – 407 с. Селиверстова П.О., Точилкина Т.Е. Методика выполнения учебного реинжиниринга бизнес-процессов для студентов // Экономика и менеджмент инновационных технологий. - 2015. - № 4.-С. 81-87. |