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



Методические указания к практическому занятию № 32.

Тема: «Разработка технического задания на ИС»

Количество часов : 2.

Цели:

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

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

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

Задания:

1. Ознакомьтесь с методическими указаниями.

2. Для курсового проекта подготовить техническое задание на разработку информационной системы в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» или ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».

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

 

МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ВЫПОЛНЕНИЮ:

Основные понятия

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

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

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

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

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

На рис. 1 схематически показаны основные факторы, определяющие характеристики разрабатываемого программного обеспечения. Такими факторами являются:

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

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

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

 

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

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

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

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

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

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

2.  Заказчик может оценить сколько на проект потребуется времени.

Если нет четкой схемы проекта - нельзя даже приблизительно сказать,

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

3.  Заказчик может оценить сколько на проект потребуется денег.

Грамотное техническое задание позволяет достаточно точно

определить, какие дополнительные издержки вас ожидают. Зная сколько времени потребуется для работы над проектом, можно определить стоимость труда исполнителей. Не имея перед глазами точных данных о продолжительности проекта, как вы можете определить срок, на который вам необходимо нанять, например, высококлассного программиста или специалиста по базам данных? Никак. Зная технические требования проекта, можно сделать выводы, какие сервера, программное обеспечение и лицензии потребуются. Это очень важный момент. Если не озаботиться этим вопросом заранее, запросто может сложиться ситуация, при которой у заказчика на руках будет готовый проект, но необходимые лицензии стоят в десятки раз больше, чем вся разработка проекта. То же самое касается техники - достаточно простой в реализации проект может потребовать дорогостоящего оборудования, каналов связи, обслуживающего персонала.

4.  Возможность организации процесса приема - передачи готового продукта. Заказчик получает возможность требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.

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

5.  Исполнитель может глубже понять суть задачи, показать заказчику «технический облик» будущего программного продукта.

6.  Снижение числа проблем между заказчиком и исполнителем, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).

7.  Исполнитель может спланировать выполнение проекта и работать по намеченному плану.

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

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

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

10.  Заказчик меньше зависит от конкретного исполнителя.

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

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


Дата добавления: 2020-04-25; просмотров: 421; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!