ВКР на тему «Разработка информационной системы»

Введение

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

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

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

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

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

1.1 Понятие информационной системы и подходы к её разработке

Определение информационной системы дано в Федеральном законе от 27 июля 2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации»: это совокупность содержащейся в базах данных информации и обеспечивающих её обработку информационных технологий и технических средств. Студенты нередко отождествляют систему с программой, но закон говорит шире, и в систему у него попадают и сами данные, и способы их обработки, и серверы с компьютерами. На практике под разработкой информационной системы обычно понимают создание программного обеспечения и базы данных, но при проектировании приходится учитывать и пользователей, и порядок их работы.

Как создавать такие системы, подсказывают стандарты. Стадии создания автоматизированных систем, начиная с формирования требований и концепции и заканчивая вводом в действие и сопровождением, перечислены в ГОСТ Р 59793-2021, который в 2022 году сменил известный многим ГОСТ 34.601-90, а что должно быть в техническом задании, указано в ГОСТ 34.602-2020. Для программной части есть ещё ГОСТ Р ИСО/МЭК 12207-2010 с процессами жизненного цикла программных средств. Ни один из этих стандартов не требует работать по какой-то одной модели, так что разработчик сам решает, идти ли по этапам строго друг за другом или выпускать систему несколькими версиями.

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

Таблица 1 — Сравнение моделей жизненного цикла информационной системы

1.2 Описание предметной области

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

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

Работы по созданию системы были распределены по стадиям, предусмотренным ГОСТ Р 59793-2021. Примерная трудоёмкость стадий по плану-графику показана на рисунке 1. Наибольшая доля времени отведена на разработку и отладку программы, однако в сумме почти столько же занимают анализ, требования и проектирование, без которых разработка превратилась бы в бесконечные переделки.

1.3 Обзор существующих решений

Прежде чем начинать разработку, были рассмотрены готовые системы учёта заявок. Среди них облачные сервисы Okdesk и модуль «Хелпдеск» платформы Битрикс24, а также система с открытым исходным кодом GLPI. Облачный сервис подключается за вечер, и пользоваться им удобно, но платить за него приходится каждый месяц за каждого пользователя, а данные лежат на серверах поставщика, и некоторым клиентам организации это не нравится. GLPI бесплатна и обладает широкими возможностями учёта оборудования, однако её интерфейс перегружен для диспетчера, а доработка под порядок работы организации требует знания чужого программного кода. По итогам сравнения было решено разработать собственную компактную систему.

1.4 Требования к информационной системе

Требования собирались в беседах с диспетчером, инженерами и руководителем отдела, и у каждого из них оказались свои ожидания. Диспетчеру нужно быстро зарегистрировать заявку, увидеть, не присылал ли клиент такую же вчера, и назначить свободного инженера. Инженеру важно открыть список своих заявок с телефона прямо у клиента, отметить выполненную работу и потраченное время. Руководителя интересуют отчёты: сколько заявок пришло, сколько закрыто в срок по договору, кто из инженеров перегружен.

Если перевести эти пожелания на язык технического задания, получится такой список функций. Заявка попадает в систему из веб-формы или из письма, получает номер, приоритет и срок реакции, взятый из договора с клиентом, затем ей назначают исполнителя, и дальше она проходит через несколько статусов, о каждом из которых клиент узнаёт по почте. Среди нефункциональных требований оказались работа в браузере на компьютере и смартфоне, разграничение прав для четырёх ролей (клиент, диспетчер, инженер, руководитель), защита персональных данных клиентов в соответствии с Федеральным законом № 152-ФЗ и резервное копирование базы данных не реже раза в сутки. Эти требования легли в основу технического задания и проектирования, описанного во второй главе.