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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 12.01.2024

Просмотров: 73

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.




Рисунок 2. Алгоритм написания ТЗ для заказчика. Общий вид.



Рисунок 3. Алгоритм написания ТЗ для заказчика. Фрагмент 1.



Рисунок 4. Алгоритм написания ТЗ для заказчика. Фрагмент 2.



Рисунок 5. Алгоритм написания ТЗ для заказчика. Фрагмент 3.



Рисунок 6.Алгоритм написания ТЗ для заказчика. Фрагмент 4.

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


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

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



Рисунок 7.Алгоритм написания ТЗ для исполнителя.
  1. Глава 3. Применение методологии.

    1. Примеры использования.


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

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



Рисунок 8. Схема организационной структуры компании "Решения для предприятий".


Рассмотрим ситуацию. Предприятие занимается разработкой и продажей своих программных решений. В отдел разработки компании активно поступают предложения по доработке их программного продукта. Группа поддержки ПП принимает решение разработать дополнение к ИС, которое объединит все желаемые клиентами функции в единое целое. Поскольку это компетенция отдела нетиповых решений, группа поддержки ПП обращается к ним за разработкой такого дополнения.

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

В результате, на предварительном этапе удалось избежать излишней бумажной работы и сразу приступить к, непосредственно, проекту.

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

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

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



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

Следуя шагам в алгоритме, обеим сторонам не хватило компетенции для написания технического задания, и потому их деловые отношения были своевременно прекращены.
    1. Перспективы для внедрения и совершенствования методологии.


Составленная нами система по написанию ТЗ может быть использована разными способами.

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

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

Алгоритм можно совместить с базой данных контрагентов компании, текстовым редактором, разработать типовые печатные формы для формирования ТЗ по ГОСТу, и все это объедить в CRM для общения с участниками проекта, и тогда может получиться комплексная система по проектированию ИС на заказ.

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

Заключение


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

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

Список литературы.


  1. Карл И. Вигерс, Джой Битти «Разработка требований к программному обеспечению», М. – 2014

  2. Селиверстова П.О., Точилкина Т.Е. Методика выполнения учебного реинжиниринга бизнес-процессов для студентов // Экономика и менеджмент инновационных технологий. - 2015. - 4.-С. 81-87.

  3. Как составить техническое задание и получить то, что нужно – Контур | журнал [Электронный ресурс]. URL: https://kontur.ru/articles/5945

  4. ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению

  5. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

  6. Предпроектное обследование - как сэкономить на автоматизации – Инфософт [Электронный ресурс]. URL: https://is1c.ru/about/pc/article/predproektnoe-obsledovanie-kak-sekonomit-na-avtomatizatsii/

  7. Техническое задание: для чего оно нужно – Многостраничные журналы [Электронный ресурс]. URL: https://mnogostranichka.ru/blog/texnicheskoe-zadanie-chto-eto-takoe-i-dlya-chego-ono-nuzhno/

  8. Предпроектное обследование – Шеф Консалтинг [Электронный ресурс]. URL: http://chiefcons.ru/services/komplexnaya_avtomatizacia/predproject/

  9. Зараменских Е.П. Основы бизнес-информатики: Учебник для бакалавриата и магистратуры. Москва: Юрайт, 2017. – 407 с.

  10. Селиверстова П.О., Точилкина Т.Е. Методика выполнения учебного реинжиниринга бизнес-процессов для студентов // Экономика и менеджмент инновационных технологий. - 2015. - 4.-С. 81-87.