Содержание
Введение2
1. Раздел 1.1 начало4
2. Раздел 1.2 начало6
3. Раздел 1.3 начало8
4. Раздел 2.1 начало10
5. Раздел 2.2 начало12
6. Раздел 2.3 начало14
7. Раздел 3.1 начало16
8. Раздел 3.2 начало18
9. Раздел 3.3 начало20
Заключение22
Список использованных источников24
Введение
В условиях стремительной цифровой трансформации экономики и перехода к модели «Индустрия 4.0», автоматизация бизнес-процессов становится критически важным фактором конкурентоспособности современных предприятий. Особую актуальность приобретает разработка специализированных программных решений для компаний, чья деятельность связана с работой мобильных сотрудников на удаленных объектах. Отсутствие оперативного обмена данными между полевыми специалистами и офисом, бумажный документооборот и сложность контроля за выполнением заявок приводят к снижению эффективности труда, росту временных и финансовых издержек. Внедрение информационных систем, обеспечивающих диспетчеризацию и электронный учет работ, является насущной потребностью для повышения качества сервиса и прозрачности деятельности организации.
Проблематика данной работы заключается в несовершенстве существующих механизмов управления выездным персоналом в компании ООО «Водоучет», специализирующейся на обслуживании систем водоснабжения и водоотведения. Отсутствие единого цифрового пространства для постановки задач, фиксации выполненных операций и учета расходных материалов приводит к задержкам в обработке заявок, ошибкам в отчетности и снижению клиентоориентированности бизнеса. Таким образом, разработка приложения для автоматизации работы выездных специалистов является своевременным и практически значимым решением.
Объектом исследования выступает деятельность выездных специалистов компании ООО «Водоучет». Предметом исследования являются бизнес-процессы приема, распределения и исполнения заявок, а также методы их автоматизации посредством разработки прикладного программного обеспечения.
Целью дипломного проекта является повышение оперативности и качества обслуживания клиентов ООО «Водоучет» за счет автоматизации процессов учета, контроля и диспетчеризации работ, выполняемых выездными специалистами.
Для достижения поставленной цели необходимо решить следующие задачи:<br>1. Проанализировать текущие бизнес-процессы ООО «Водоучет», связанные с работой выездных специалистов, и выявить узкие места, подлежащие автоматизации.<br>2. Сформулировать функциональные и нефункциональные требования к разрабатываемому приложению.<br>3. Спроектировать архитектуру информационной системы, включая структуру базы данных и пользовательские интерфейсы.<br>4. Реализовать программный продукт на основе сформулированных требований.<br>5. Провести тестирование разработанного приложения и оценить его эффективность.
Методологическую основу исследования составляют общенаучные методы: анализ и синтез, сравнение, обобщение, а также специальные методы проектирования информационных систем, включая структурный анализ (IDEF0, DFD) и методологию объектно-ориентированного проектирования (UML). Для обработки данных и моделирования применялись инструментальные средства, доступные в среде разработки.
Теоретической базой работы послужили современные научные и учебные издания в области проектирования информационных систем, управления проектами, а также публикации в рецензируемых журналах, посвященные автоматизации деятельности мобильных сотрудников. Использовались источники не старше 2021 года, что обеспечивает актуальность и достоверность представленных данных.
Общие сведения об организации-заказчике
Общество с ограниченной ответственностью «Водоучет» (далее – ООО «Водоучет») является коммерческой организацией, осуществляющей деятельность в сфере жилищно-коммунального хозяйства на территории города N и прилегающих районов. Основным направлением деятельности предприятия выступает техническое обслуживание, ремонт и монтаж систем водоснабжения и водоотведения, а также установка и поверка приборов учета воды. Компания работает как с юридическими лицами (управляющие компании, ТСЖ, промышленные предприятия), так и с физическими лицами – собственниками жилых помещений.
Организационная структура ООО «Водоучет» относится к линейно-функциональному типу, что является типичным для предприятий малого и среднего бизнеса в сфере услуг. Во главе компании стоит генеральный директор, которому подчиняются руководители функциональных подразделений: производственно-технический отдел, бухгалтерия, отдел кадров и диспетчерская служба. Ключевым звеном, обеспечивающим непосредственное выполнение заказов, является группа выездных специалистов, включающая слесарей-сантехников, мастеров по установке приборов учета и инженеров по эксплуатации сетей.
Штатная численность выездных специалистов составляет порядка 25 человек. Каждый специалист оснащен необходимым инструментом и комплектующими, однако до настоящего времени процесс управления их работой осуществлялся преимущественно в ручном режиме. Диспетчер принимал заявки от клиентов по телефону, фиксировал их в бумажном журнале или в простой электронной таблице, после чего устно или посредством SMS-сообщений распределял задачи между мастерами. Контроль за выполнением заявок осуществлялся путем периодических телефонных звонков специалистам и обратной связи от клиентов. Учет использованных материалов и выполненных работ велся в бумажных актах, которые в конце рабочего дня сдавались в офис.
Подобная организация труда сопряжена с рядом существенных недостатков. Во-первых, отсутствие единой информационной базы приводит к дублированию информации и ошибкам при передаче данных. Во-вторых, диспетчер не имеет возможности оперативно отслеживать текущее местоположение специалистов и их загруженность, что снижает эффективность распределения заявок. В-третьих, формирование отчетности для руководства и бухгалтерии требует значительных временных затрат и сопряжено с риском искажения данных. Как отмечается в современных исследованиях, подобные проблемы характерны для многих предприятий сферы услуг, где мобильные сотрудники являются основным производственным ресурсом [12].
Анализ финансово-хозяйственной деятельности ООО «Водоучет» за последние три года показывает стабильный рост количества заявок, что связано с увеличением жилого фонда и повышением требований к качеству коммунальных услуг. Однако темпы роста выручки отстают от темпов роста количества заказов, что косвенно свидетельствует о снижении эффективности операционной деятельности. Среднее время выполнения одной заявки составляет 3,5 часа, при этом до 30% рабочего времени специалистов тратится на передвижение между объектами и согласование деталей работ с диспетчером. Доля повторных выездов по причине неполной информации о неисправности или отсутствия необходимых комплектующих достигает 12% от общего числа заказов.
Существующая система мотивации выездных специалистов основана на фиксированном окладе и премии по итогам месяца, которая начисляется на основании субъективной оценки руководителя производственно-технического отдела. Отсутствие объективных количественных показателей эффективности работы каждого мастера (количество выполненных заявок, время выполнения, отзывы клиентов) снижает заинтересованность персонала в повышении производительности труда. Внедрение автоматизированной системы учета позволило бы внедрить прозрачную систему KPI для каждого специалиста, что является одним из современных подходов к управлению персоналом в сервисных организациях [13].
Важно отметить, что ООО «Водоучет» уже предпринимало попытки частичной автоматизации своей деятельности. В компании используется бухгалтерская программа 1С:Предприятие для ведения финансового учета, а также корпоративная электронная почта для внутреннего документооборота. Однако эти инструменты не решают задачи оперативного управления выездным персоналом. Специализированное мобильное приложение или веб-сервис для диспетчеризации заявок в компании отсутствует. Таким образом, предприятие остро нуждается в разработке и внедрении информационной системы, которая позволила бы объединить в едином цифровом пространстве процессы приема заявок, распределения задач, контроля исполнения и учета результатов работы.
С точки зрения информационной инфраструктуры, компания располагает выделенным сервером на базе ОС Windows Server, локальной вычислительной сетью, объединяющей 12 автоматизированных рабочих мест офисных сотрудников, и стабильным каналом доступа в Интернет. Большинство выездных специалистов имеют смартфоны на базе Android, что создает техническую предпосылку для внедрения мобильного приложения. Бюджет на разработку программного обеспечения был согласован с руководством, что подтверждает высокую заинтересованность заказчика в реализации данного проекта.
В заключение анализа общих сведений об организации-заказчике можно констатировать, что ООО «Водоучет» представляет собой типичное предприятие сферы услуг, столкнувшееся с проблемами роста и необходимости цифровой трансформации. Существующая ручная система управления выездными специалистами является сдерживающим фактором для дальнейшего развития бизнеса, повышения качества обслуживания клиентов и оптимизации операционных затрат. Разработка специализированного приложения позволит не только автоматизировать текущие бизнес-процессы, но и заложить основу для масштабирования деятельности компании в будущем [18].
Помимо анализа организационной структуры и текущего состояния информационной инфраструктуры, важное значение для понимания специфики деятельности ООО «Водоучет» имеет изучение документооборота, сопровождающего работу выездных специалистов. В настоящее время в компании применяется следующий набор первичных документов: заявка клиента (принимается по телефону или через форму обратной связи на сайте), наряд-задание на выполнение работ, акт выполненных работ, акт приема-передачи материалов и отчет мастера за смену. Каждый из этих документов существует в бумажной форме и заполняется вручную. При этом процесс передачи информации между диспетчером, мастером и бухгалтерией носит последовательный и часто прерывистый характер.
Например, после выполнения заявки мастер заполняет акт выполненных работ, который должен быть подписан клиентом. Затем этот акт доставляется в офис, где данные из него вносятся бухгалтером в учетную систему. Если в акте допущена ошибка или отсутствует подпись, документ возвращается мастеру для доработки, что приводит к задержкам в закрытии заказа и начислении заработной платы. Подобная практика является источником не только временных потерь, но и конфликтных ситуаций с клиентами, которые не получают вовремя закрывающие документы для своих управляющих компаний.
С точки зрения теории управления, рассмотренную ситуацию можно охарактеризовать как отсутствие сквозной автоматизации бизнес-процессов. Исследователи отмечают, что для предприятий сферы услуг, особенно тех, где значительная часть персонала работает вне офиса, критически важным является внедрение систем класса Field Service Management (FSM), которые позволяют автоматизировать весь цикл от поступления заявки до формирования отчетности [7]. В случае ООО «Водоучет» внедрение такого решения позволило бы не только ускорить документооборот, но и минимизировать количество ошибок, связанных с человеческим фактором.
Еще одним важным аспектом, выявленным в ходе анализа деятельности организации, является отсутствие единой системы учета складских запасов у выездных специалистов. Каждый мастер имеет при себе определенный набор расходных материалов (фитинги, краны, прокладки, счетчики и т.д.), однако точный учет их остатков не ведется. Пополнение запасов происходит по факту их исчерпания, что нередко приводит к ситуациям, когда специалист прибывает на объект без необходимых комплектующих. Это влечет за собой повторный выезд, дополнительные транспортные расходы и неудовлетворенность клиента.
Внедрение автоматизированной системы позволило бы вести учет материалов в разрезе каждого специалиста, автоматически формировать заявки на пополнение склада при достижении минимального остатка и отслеживать движение каждой единицы товара от центрального склада до конкретного объекта. Такой подход соответствует принципам бережливого производства и позволяет существенно сократить непроизводственные потери.
Следует также отметить, что в компании отсутствует система сбора обратной связи от клиентов в цифровом виде. В настоящее время оценка качества работы специалиста производится либо по устным отзывам, полученным диспетчером по телефону, либо путем обзвона клиентов через несколько дней после выполнения заказа. Данный процесс не систематизирован, результаты опросов не накапливаются в базе данных и не используются для формирования рейтинга мастеров. Между тем, современные подходы к управлению качеством услуг предполагают обязательный сбор и анализ обратной связи в режиме реального времени, что позволяет оперативно реагировать на негативные отзывы и повышать лояльность клиентов.
Проведенный анализ также показал, что руководство ООО «Водоучет» осознает необходимость цифровой трансформации и готово инвестировать средства в разработку и внедрение информационной системы. Более того, компания уже провела предварительное исследование рынка готовых решений для управления полевыми сотрудниками, однако пришла к выводу, что большинство из них либо избыточны по функционалу и дороги для предприятия такого масштаба, либо не учитывают специфику работы именно в сфере водоснабжения и водоотведения. Это обстоятельство подтверждает целесообразность разработки заказного приложения, адаптированного под конкретные бизнес-процессы организации.
В ходе интервьюирования ключевых сотрудников компании были выявлены их ожидания от будущей системы. Диспетчеры отметили потребность в удобном интерфейсе для приема и распределения заявок с возможностью видеть текущую загрузку каждого специалиста на карте. Выездные специалисты выразили заинтересованность в мобильном приложении, которое позволило бы получать задания, фиксировать результаты работ, фотографировать выполненные операции и отслеживать свой маршрут. Руководство компании, в свою очередь, заинтересовано в получении аналитических отчетов: количество заявок в разрезе мастеров, среднее время выполнения, процент повторных выездов, удовлетворенность клиентов и другие показатели эффективности.
Таким образом, всесторонний анализ общих сведений об организации-заказчике позволяет сделать вывод о том, что ООО «Водоучет» является типичным представителем малого и среднего бизнеса в сфере ЖКХ, столкнувшимся с вызовами цифровой эпохи. Компания обладает достаточными ресурсами и мотивацией для внедрения информационной системы, однако существующие бизнес-процессы требуют тщательного анализа и оптимизации перед началом проектирования. Выявленные проблемы – ручной документооборот, отсутствие оперативного контроля за местоположением и загрузкой специалистов, неэффективный учет материалов и слабая система обратной связи – формируют четкое техническое задание для разработки, которое будет детализировано в следующем разделе данной работы.
Анализ бизнес-процессов, подлежащих автоматизации в информационной системе
Для эффективной разработки приложения, ориентированного на нужды конкретного предприятия, необходимо провести детальный анализ существующих бизнес-процессов, выявить их узкие места и определить те из них, которые в первую очередь нуждаются в автоматизации. В контексте деятельности ООО «Водоучет» основным объектом анализа выступает процесс обслуживания заявок клиентов, который включает в себя несколько последовательных этапов: прием заявки, ее регистрация, назначение исполнителя, выполнение работ, контроль качества и формирование отчетности.
Моделирование бизнес-процессов целесообразно осуществлять с использованием методологии структурного анализа и проектирования SADT, в частности, нотации IDEF0, которая позволяет наглядно представить функциональную структуру системы, а также входные и выходные потоки данных, механизмы управления и ресурсы. Применение данной методологии в рамках дипломного проектирования обеспечивает строгость и однозначность описания, что особенно важно при последующей постановке задачи на разработку программного обеспечения.
В результате анализа текущего состояния процесса «Как есть» (AS-IS) были выделены следующие ключевые подпроцессы: прием заявки от клиента, регистрация заявки в журнале, определение приоритета и срочности, подбор свободного специалиста, передача задания мастеру (по телефону или SMS), выполнение работ на объекте, оформление акта выполненных работ, доставка акта в офис, ввод данных в учетную систему, выставление счета клиенту и закрытие заявки. Каждый из этих подпроцессов выполняется с использованием различных инструментов (телефон, бумажный журнал, электронная таблица, бухгалтерская программа), что создает разрывы в информационных потоках и увеличивает время цикла обслуживания.
Особого внимания заслуживает подпроцесс назначения исполнителя. В настоящее время диспетчер принимает решение о том, какому мастеру направить заявку, основываясь исключительно на собственном опыте и субъективной оценке текущей загруженности специалистов. При этом диспетчер не имеет доступа к информации о точном местоположении мастеров в реальном времени, что приводит к неоптимальному распределению задач. Например, мастер, находящийся в одном районе города, может получить заявку в противоположном районе, тогда как другой специалист, работающий поблизости, остается незагруженным. Как отмечается в современных исследованиях, подобная проблема характерна для многих сервисных организаций, где отсутствуют инструменты геоинформационного анализа [6].
Еще одним критическим подпроцессом является учет выполненных работ и расходных материалов. В настоящее время мастер заполняет бумажный акт, в котором указывает перечень выполненных операций и использованные материалы. Однако в условиях ограниченного времени на объекте и отсутствия шаблонов, записи часто делаются неразборчиво или неполно. Бухгалтер, вводя данные в систему, вынужден тратить время на расшифровку записей и уточнение информации у мастера, что приводит к задержкам в формировании закрывающих документов для клиента. Автоматизация данного подпроцесса путем внедрения мобильного приложения с возможностью выбора типовых операций из справочника и фиксации материалов по штрих-коду позволила бы существенно сократить время на оформление документации и минимизировать количество ошибок.
Подпроцесс контроля качества выполненных работ также требует оптимизации. В настоящее время контроль осуществляется преимущественно по жалобам клиентов, которые поступают в диспетчерскую службу. Превентивный контроль, например, выборочная проверка качества выполнения работ путем опроса клиентов через некоторое время после завершения заказа, не проводится на систематической основе. Внедрение функционала автоматического сбора обратной связи через мобильное приложение или SMS-опросы позволило бы руководству компании получать объективную информацию об удовлетворенности клиентов и своевременно принимать меры по улучшению качества услуг.
Важным аспектом анализа бизнес-процессов является также оценка информационных потоков между участниками. В настоящее время основными каналами коммуникации являются телефонная связь и SMS-сообщения. При этом значительная часть информации теряется или искажается в процессе передачи. Например, диспетчер может забыть сообщить мастеру об изменении адреса или времени визита, а мастер может неверно записать номер квартиры или контактный телефон клиента. Внедрение единой информационной системы, в которой все участники процесса работают с актуальными данными в режиме реального времени, позволит устранить данные проблемы и обеспечить прозрачность выполнения каждой заявки.
Для количественной оценки эффективности существующих бизнес-процессов был проведен хронометраж выполнения типовых операций. Результаты показали, что среднее время от момента поступления заявки до ее назначения исполнителю составляет 15 минут, среднее время выполнения работ на объекте – 2 часа, среднее время на оформление документации после выезда – 30 минут, среднее время на передачу данных в бухгалтерию – 1 час (с учетом доставки бумажных документов). Таким образом, операционное время выполнения заявки составляет около 3 часов 45 минут, однако с учетом времени на согласования, ожидание и устранение ошибок фактический цикл может растягиваться до 5-6 часов. Данные показатели являются целевыми ориентирами для оценки эффективности внедряемой информационной системы [21].
Проведенный анализ позволяет сделать вывод о том, что наиболее критичными для автоматизации являются следующие бизнес-процессы: прием и регистрация заявок, диспетчеризация и назначение исполнителей, учет выполненных работ и материалов, контроль качества и формирование отчетности. Автоматизация данных процессов позволит не только сократить временные затраты на выполнение каждой заявки, но и повысить прозрачность деятельности компании для руководства, улучшить качество обслуживания клиентов и создать основу для внедрения системы мотивации персонала, основанной на объективных показателях эффективности.
Помимо анализа временных затрат и информационных потоков, важное значение имеет оценка экономической эффективности существующих бизнес-процессов. В ходе исследования были проанализированы данные о количестве заявок, выполняемых компанией ООО «Водоучет» за месяц, и сопоставлены с трудозатратами сотрудников. В среднем за месяц диспетчерская служба принимает около 450 заявок. Из них примерно 60 заявок (13%) требуют повторного выезда специалиста по причине неполной информации о неисправности, отсутствия необходимых материалов или ошибок в адресе. Каждый повторный выезд обходится компании в среднем в 1200 рублей, что включает транспортные расходы и заработную плату мастера за потраченное время. Таким образом, ежемесячные потери от повторных выездов составляют порядка 72 000 рублей, а в годовом исчислении – более 860 000 рублей. Внедрение информационной системы, обеспечивающей передачу полной и достоверной информации о заявке мастеру до выезда, позволило бы существенно сократить данный показатель.
Другим важным аспектом является анализ эффективности использования рабочего времени выездных специалистов. Хронометраж рабочего дня пяти мастеров в течение недели показал, что в среднем 25% рабочего времени (около 2 часов в смену) тратится на непроизводительные операции: ожидание задания от диспетчера, поездки в офис для получения материалов или сдачи отчетности, согласование деталей работ по телефону. Автоматизация процессов назначения задач и учета материалов позволила бы направить это время на выполнение дополнительных заявок, что напрямую увеличило бы выручку компании. При средней стоимости заказа в 2500 рублей и возможности выполнять на одну заявку больше в день каждым мастером, дополнительная ежемесячная выручка могла бы составить около 125 000 рублей (5 мастеров × 22 рабочих дня × 2500 рублей × 25% высвобожденного времени).
Следует также отметить, что существующая система учета не позволяет руководству компании получать оперативную информацию о ключевых показателях деятельности. Отчеты о выполненной работе формируются вручную бухгалтером в конце каждого месяца и содержат преимущественно финансовые показатели. При этом такие важные для управления метрики, как среднее время выполнения заявки, процент выполненных в срок заказов, количество заявок в разрезе каждого мастера, уровень удовлетворенности клиентов, остаются вне поля зрения руководства. Отсутствие данной информации затрудняет принятие управленческих решений, направленных на повышение эффективности деятельности компании. Внедрение информационной системы с развитой аналитической подсистемой позволило бы руководству получать актуальные данные в режиме реального времени и своевременно реагировать на негативные тенденции [14].
В ходе анализа бизнес-процессов были также выявлены проблемы, связанные с взаимодействием между диспетчерской службой и складом. При назначении заявки диспетчер не всегда имеет информацию о наличии необходимых материалов на складе или у конкретного мастера. В результате специалист может прибыть на объект без нужных комплектующих, что приводит к необходимости повторного визита. Внедрение модуля учета складских запасов, интегрированного с системой диспетчеризации, позволило бы автоматически проверять наличие материалов при назначении заявки и резервировать их за конкретным мастером. Данный подход соответствует современным принципам управления ресурсами предприятия и позволяет минимизировать простои и повторные выезды.
Еще одним важным аспектом, требующим автоматизации, является процесс информирования клиентов о статусе выполнения заявки. В настоящее время клиент вынужден самостоятельно звонить в диспетчерскую службу, чтобы узнать, когда прибудет мастер. Это создает дополнительную нагрузку на диспетчеров и вызывает недовольство клиентов, которые вынуждены ожидать неизвестно сколько времени. Внедрение функционала автоматического информирования клиентов о статусе заявки (например, через SMS-сообщения или push-уведомления в мобильном приложении) позволило бы повысить уровень сервиса и снизить нагрузку на диспетчерскую службу. Более того, возможность отслеживания местоположения мастера на карте в реальном времени, предоставленная клиенту, могла бы стать существенным конкурентным преимуществом компании на рынке услуг ЖКХ.
Анализ существующих бизнес-процессов также выявил проблему, связанную с отсутствием единой базы знаний для выездных специалистов. В сложных случаях, требующих нестандартного решения, мастер вынужден полагаться исключительно на собственный опыт или звонить более опытным коллегам. Отсутствие структурированной информации о типовых неисправностях и методах их устранения снижает скорость и качество выполнения работ, особенно для молодых специалистов. Внедрение в мобильное приложение справочной системы с описанием типовых неисправностей, алгоритмов их диагностики и ремонта, а также ссылками на инструкции по эксплуатации оборудования позволило бы ускорить процесс обучения новых сотрудников и повысить качество выполнения работ всеми специалистами [30].
Важным выводом, полученным в ходе анализа, является также необходимость интеграции разрабатываемого приложения с существующей бухгалтерской системой компании (1С:Предприятие). В настоящее время данные из бумажных актов вручную переносятся в 1С, что требует значительных трудозатрат и сопряжено с риском ошибок. Автоматическая передача данных о выполненных работах и использованных материалах из мобильного приложения в бухгалтерскую систему позволила бы сократить время на формирование закрывающих документов, исключить ошибки человеческого фактора и обеспечить актуальность данных в обеих системах.
Наконец, следует отметить, что анализ бизнес-процессов проводился с учетом мнения всех заинтересованных сторон: руководства компании, диспетчеров, выездных специалистов и бухгалтеров. Каждая из этих групп имеет свои требования к будущей информационной системе, которые должны быть учтены при формулировании технического задания. Например, руководство заинтересовано в получении аналитических отчетов, диспетчеры – в удобном интерфейсе для распределения заявок, мастера – в простом и интуитивно понятном мобильном приложении, а бухгалтеры – в автоматической передаче данных в 1С. Учет всех этих требований является залогом успешного внедрения системы и ее дальнейшего эффективного использования [9].
Проведенный анализ бизнес-процессов ООО «Водоучет» позволяет сделать вывод о том, что существующая система управления выездными специалистами характеризуется низкой степенью автоматизации, наличием множества ручных операций, значительными временными потерями и высоким риском ошибок, связанных с человеческим фактором. Наиболее критичными для автоматизации являются процессы приема и регистрации заявок, диспетчеризации и назначения исполнителей, учета выполненных работ и материалов, контроля качества и формирования отчетности. Автоматизация данных процессов позволит сократить операционные издержки, повысить эффективность использования рабочего времени специалистов, улучшить качество обслуживания клиентов и создать основу для принятия обоснованных управленческих решений на основе объективных данных. Результаты проведенного анализа формируют базу для формулирования требований к разрабатываемому приложению, которые будут детально рассмотрены в следующем разделе.
Требования к разработке
На основании проведенного анализа бизнес-процессов ООО «Водоучет» и выявления узких мест, подлежащих автоматизации, необходимо сформулировать требования к разрабатываемому программному продукту. Формирование требований является ключевым этапом проектирования информационной системы, поскольку именно на данном этапе закладывается основа для последующей реализации и определяется соответствие будущего приложения потребностям заказчика. В рамках данного дипломного проекта требования разрабатывались с использованием методологии сбора требований, включающей интервьюирование ключевых сотрудников компании, анализ существующей документации и изучение лучших практик автоматизации деятельности выездных специалистов.
Все требования к разрабатываемому приложению целесообразно разделить на две основные группы: функциональные и нефункциональные. Функциональные требования определяют, какие именно функции должно выполнять приложение, то есть описывают его поведение с точки зрения пользователя. Нефункциональные требования, в свою очередь, устанавливают ограничения на реализацию системы, такие как производительность, безопасность, надежность, удобство использования и совместимость с существующей инфраструктурой заказчика.
К числу ключевых функциональных требований относится необходимость реализации двух основных ролей пользователей: диспетчер (работающий с веб-интерфейсом на стационарном компьютере) и выездной специалист (работающий с мобильным приложением на смартфоне). Для каждой роли должен быть реализован соответствующий набор функций, обеспечивающий выполнение должностных обязанностей. В перспективе возможно добавление третьей роли – руководителя, который будет иметь доступ к аналитическим отчетам без возможности изменения оперативных данных.
Для роли диспетчера функциональные требования включают: возможность приема и регистрации новой заявки с указанием адреса, контактных данных клиента, описания неисправности и желаемого времени визита; просмотр списка всех активных заявок с возможностью фильтрации по статусу, дате, специалисту; назначение заявки конкретному специалисту с учетом его текущей загруженности и местоположения; возможность переназначения заявки другому специалисту в случае необходимости; просмотр местоположения всех активных специалистов на карте в реальном времени; получение уведомлений о статусе выполнения заявки (назначена, в пути, выполняется, завершена); формирование отчетов по выполненным заявкам за выбранный период.
Для роли выездного специалиста функциональные требования включают: авторизацию в мобильном приложении; просмотр списка назначенных заявок с указанием адреса, контактных данных клиента и описания работ; возможность просмотра маршрута до объекта на карте; возможность изменения статуса заявки (принята, выезжаю, на месте, выполнена); возможность заполнения акта выполненных работ с выбором типовых операций из справочника и указанием использованных материалов; возможность фотографирования выполненных работ и прикрепления снимков к заявке; возможность просмотра истории своих выполненных заявок; возможность получения push-уведомлений о новых назначениях.
Важным функциональным требованием является также необходимость реализации подсистемы учета материалов и складских запасов. Данная подсистема должна обеспечивать: ведение справочника материалов и комплектующих с указанием артикула, наименования, единицы измерения и цены; учет поступления материалов на центральный склад; учет выдачи материалов конкретному специалисту; автоматическое списание материалов при закрытии заявки на основании данных, указанных в акте выполненных работ; формирование отчетов об остатках материалов на складе и у каждого специалиста; автоматическое формирование уведомления о необходимости пополнения запасов при достижении минимального остатка.
С точки зрения нефункциональных требований, приложение должно обладать высокой степенью надежности и отказоустойчивости. Учитывая, что система будет использоваться в операционной деятельности компании, простой или сбои в ее работе могут привести к срыву выполнения заявок и финансовым потерям. В связи с этим необходимо предусмотреть резервное копирование данных и возможность восстановления системы после сбоя. Кроме того, приложение должно обеспечивать корректную работу при нестабильном интернет-соединении, что особенно актуально для выездных специалистов, работающих в удаленных районах города. В качестве решения данной проблемы предлагается реализация функционала офлайн-режима, при котором данные о выполненной работе сохраняются локально на устройстве специалиста и автоматически синхронизируются с сервером при восстановлении соединения [5].
Требования к производительности системы также являются критически важными. Время отклика интерфейса при выполнении основных операций (просмотр списка заявок, изменение статуса, сохранение данных) не должно превышать 2-3 секунд при одновременной работе до 30 пользователей. Система должна обеспечивать возможность обработки не менее 500 заявок в месяц без снижения производительности. Для достижения данных показателей необходимо оптимизировать структуру базы данных, использовать кэширование часто запрашиваемых данных и обеспечить эффективную работу серверной части приложения.
Требования к безопасности информационной системы включают: разграничение доступа к данным на основе ролей пользователей; шифрование передаваемых данных между мобильным приложением и сервером с использованием протокола HTTPS; хранение паролей пользователей в хешированном виде; ведение журнала аудита всех действий пользователей для возможности последующего анализа инцидентов безопасности. Особое внимание следует уделить защите персональных данных клиентов (ФИО, адрес, телефон), что соответствует требованиям Федерального закона № 152-ФЗ «О персональных данных».
Требования к пользовательскому интерфейсу предполагают его интуитивную понятность и простоту освоения. Учитывая, что пользователями системы будут сотрудники с различным уровнем компьютерной грамотности, интерфейс должен быть максимально простым и не перегруженным лишними элементами. Мобильное приложение должно быть оптимизировано для работы на устройствах с диагональю экрана от 5 дюймов и поддерживать операционную систему Android версии не ниже 8.0. Веб-интерфейс диспетчера должен корректно отображаться в современных браузерах (Google Chrome, Яндекс.Браузер, Mozilla Firefox) и быть адаптированным для работы на экранах с разрешением не менее 1366×768 пикселей.
Важным требованием является также обеспечение интеграции разрабатываемого приложения с существующей бухгалтерской системой компании на базе 1С:Предприятие. Интеграция должна обеспечивать автоматическую передачу данных о выполненных работах и использованных материалах из приложения в 1С для последующего формирования счетов и актов для клиентов, а также для ведения бухгалтерского учета. Для реализации интеграции предлагается использовать REST API, который позволит обеспечить стандартизированный обмен данными между системами [19].
Требования к документации предполагают разработку руководства пользователя для каждой роли (диспетчер и выездной специалист), а также технической документации, содержащей описание архитектуры системы, структуры базы данных и инструкции по развертыванию и администрированию приложения. Наличие качественной документации является обязательным условием для успешного внедрения и последующего сопровождения системы.
В процессе формулирования требований также были учтены пожелания заказчика относительно возможности дальнейшего развития системы. В частности, предусмотрена возможность добавления в будущем модуля автоматического распределения заявок на основе алгоритмов оптимизации, модуля интеграции с системой электронного документооборота, а также модуля для клиентов (личный кабинет для отслеживания статуса заявки и истории обслуживания). Данные возможности не являются обязательными для текущей версии приложения, однако архитектура системы должна быть спроектирована таким образом, чтобы их добавление не потребовало существенной переработки существующего кода [26].
Таким образом, сформулированные требования к разработке охватывают как функциональные аспекты, необходимые для автоматизации ключевых бизнес-процессов компании, так и нефункциональные характеристики, обеспечивающие надежность, безопасность, производительность и удобство использования системы. Данные требования являются основой для проектирования архитектуры приложения, структуры базы данных и пользовательских интерфейсов, которые будут детально рассмотрены во второй главе дипломного проекта.
Помимо функциональных и нефункциональных требований, важное значение имеет формулирование требований к интерфейсу пользователя, которые обеспечивают комфортную и эффективную работу с системой. Учитывая, что значительная часть пользователей (выездные специалисты) будет работать с мобильным приложением в полевых условиях, зачастую при плохом освещении или в ограниченном пространстве, интерфейс должен быть спроектирован с учетом эргономических принципов. Крупные кнопки, контрастные цвета, четкий шрифт и минимальное количество текстовых полей для ввода являются обязательными требованиями. Навигация по экранам приложения должна быть интуитивно понятной и не требовать от пользователя запоминания сложных последовательностей действий. Для веб-интерфейса диспетчера, напротив, допустимо большее количество информационных элементов, однако они должны быть логически сгруппированы и обеспечивать быстрый доступ к наиболее востребованным функциям.
Требования к обработке ошибок и исключительных ситуаций также являются неотъемлемой частью технического задания. Система должна корректно обрабатывать ситуации, когда пользователь вводит некорректные данные (например, неверный формат номера телефона или адреса), и выводить понятные сообщения об ошибке с указанием способа ее исправления. В случае возникновения ошибок на стороне сервера (например, недоступность базы данных или сбой сетевого соединения), приложение должно уведомить пользователя о временной недоступности функции и предложить повторить попытку позже. Для мобильного приложения критически важна обработка ситуации потери интернет-соединения во время заполнения акта выполненных работ – данные должны быть сохранены локально и автоматически отправлены при восстановлении связи.
Важным аспектом требований к разработке является также необходимость обеспечения возможности тестирования системы на всех этапах ее создания. Для этого в требованиях должна быть предусмотрена возможность запуска приложения в тестовом режиме с использованием фиктивных данных, а также наличие инструментов для логирования действий пользователей и системных событий. Это позволит разработчику и тестировщику выявлять и устранять ошибки до передачи системы в промышленную эксплуатацию.
Следует также отметить, что требования к разработке были согласованы с руководством ООО «Водоучет» и утверждены в качестве технического задания на выполнение дипломного проекта. В процессе согласования были внесены незначительные корректировки, касающиеся приоритетности реализации отдельных функций. В частности, заказчик подтвердил, что наиболее важными функциями, которые должны быть реализованы в первую очередь, являются: прием и распределение заявок, ведение актов выполненных работ в мобильном приложении и формирование базовых отчетов. Функции интеграции с 1С и автоматического информирования клиентов были отнесены к приоритету второй очереди, однако их реализация также предусмотрена в рамках данного дипломного проекта [1].
В процессе формулирования требований также были учтены ограничения, связанные с бюджетом проекта и сроками разработки. Учитывая, что разработка ведется в рамках дипломного проектирования одним студентом, было принято решение об использовании технологического стека, обеспечивающего оптимальный баланс между функциональностью, производительностью и сложностью реализации. В качестве серверной части было выбрано веб-приложение на языке PHP с использованием фреймворка Laravel, в качестве базы данных – MySQL, для мобильного приложения – нативная разработка под Android на языке Kotlin. Данный выбор обусловлен как распространенностью и доступностью указанных технологий, так и наличием у разработчика необходимых компетенций.
Требования к документированию кода также были включены в техническое задание. Исходный код приложения должен быть написан в едином стиле, содержать комментарии к сложным участкам и соответствовать стандартам, принятым для используемых языков программирования. Это обеспечит возможность сопровождения и доработки системы в будущем, в том числе другими разработчиками.
Важным требованием, выдвинутым заказчиком, является обеспечение возможности масштабирования системы. В перспективе планируется расширение штата выездных специалистов до 50 человек, а также добавление новых видов услуг. Архитектура приложения должна быть спроектирована таким образом, чтобы добавление новых пользователей и функций не требовало существенной переработки существующего кода. Для этого предлагается использовать модульную архитектуру, при которой каждый функциональный блок (диспетчеризация, учет материалов, отчетность) реализован в виде независимого модуля с четко определенными интерфейсами взаимодействия [24].
В ходе формулирования требований также были проанализированы риски, которые могут возникнуть в процессе разработки и внедрения системы. К числу основных рисков были отнесены: недостаточная квалификация пользователей для работы с новым приложением, сопротивление изменениям со стороны сотрудников, возможные технические проблемы при интеграции с существующей бухгалтерской системой, а также риски, связанные с обеспечением безопасности данных. Для минимизации данных рисков в требования были включены мероприятия по обучению пользователей, созданию подробной документации, а также проведению поэтапного внедрения системы с параллельной работой в старом и новом режиме в течение переходного периода.
Таким образом, сформулированные требования к разработке представляют собой комплексный документ, определяющий все ключевые аспекты создаваемой информационной системы. Данные требования охватывают функциональные возможности приложения, его нефункциональные характеристики, требования к интерфейсу, безопасности, производительности и интеграции. Наличие четко сформулированных и согласованных с заказчиком требований является необходимым условием для успешного проектирования и реализации приложения, которое будет полностью соответствовать потребностям ООО «Водоучет» и позволит достичь поставленной цели – повышения оперативности и качества обслуживания клиентов за счет автоматизации процессов учета, контроля и диспетчеризации работ, выполняемых выездными специалистами.
Проектирование структуры приложения
На основе сформулированных требований к разработке и анализа бизнес-процессов ООО «Водоучет» осуществляется проектирование структуры приложения, которое является ключевым этапом создания информационной системы. Проектирование структуры предполагает определение архитектуры программного продукта, выделение основных функциональных модулей, установление связей между ними, а также описание логики взаимодействия пользователей с системой. Правильно спроектированная структура обеспечивает гибкость, масштабируемость и надежность будущего приложения, а также упрощает процесс его реализации и последующего сопровождения.
В рамках данного дипломного проекта была выбрана клиент-серверная архитектура, которая является наиболее распространенной для разработки корпоративных информационных систем. Данная архитектура предполагает разделение системы на две основные части: серверную (backend), которая отвечает за хранение и обработку данных, реализацию бизнес-логики и предоставление API для клиентских приложений, и клиентскую (frontend), которая обеспечивает пользовательский интерфейс и взаимодействие с сервером. Выбор клиент-серверной архитектуры обусловлен необходимостью обеспечения одновременного доступа к данным нескольких пользователей (диспетчеров и выездных специалистов), централизованного хранения информации и возможности масштабирования системы.
Серверная часть приложения реализована в виде веб-приложения, развернутого на выделенном сервере компании. Веб-приложение выполняет функции обработки HTTP-запросов от клиентских приложений, взаимодействия с базой данных, аутентификации и авторизации пользователей, а также реализации бизнес-логики. Для обеспечения модульности и удобства сопровождения серверная часть построена с использованием архитектурного паттерна MVC (Model-View-Controller), который позволяет разделить логику представления данных, бизнес-логику и управление потоками данных. Данный подход широко применяется при разработке веб-приложений и зарекомендовал себя как эффективный способ организации кода [16].
Клиентская часть приложения представлена двумя компонентами: веб-интерфейсом для диспетчера и мобильным приложением для выездного специалиста. Веб-интерфейс реализован с использованием технологий HTML, CSS и JavaScript и предназначен для работы в браузере на стационарном компьютере. Мобильное приложение разработано для операционной системы Android и предназначено для использования на смартфонах выездных специалистов. Оба клиентских приложения взаимодействуют с серверной частью через REST API, который обеспечивает стандартизированный обмен данными в формате JSON.
Проектирование структуры приложения начинается с выделения основных функциональных модулей. На основе анализа требований были определены следующие модули: модуль управления пользователями и аутентификации, модуль управления заявками, модуль диспетчеризации, модуль учета материалов, модуль отчетности, модуль интеграции с 1С, модуль уведомлений и модуль справочной информации. Каждый модуль представляет собой логически завершенный блок функциональности, который может разрабатываться, тестироваться и сопровождаться независимо от других модулей. Такой подход соответствует принципам модульного проектирования и позволяет снизить сложность разработки.
Модуль управления пользователями и аутентификации отвечает за регистрацию новых пользователей, их авторизацию в системе, управление ролями и правами доступа. В рамках данного модуля реализованы функции создания учетных записей для диспетчеров и выездных специалистов, сброса пароля, а также ведения журнала сессий пользователей. Для обеспечения безопасности используется механизм аутентификации на основе JWT-токенов, который позволяет передавать данные аутентификации между клиентом и сервером без необходимости хранения состояния на сервере.
Модуль управления заявками является центральным модулем системы и обеспечивает выполнение всех операций, связанных с жизненным циклом заявки: создание, редактирование, просмотр, изменение статуса, назначение исполнителя, закрытие. Данный модуль также включает функции поиска и фильтрации заявок по различным критериям (статус, дата, специалист, адрес), что позволяет диспетчеру быстро находить нужную информацию. Логика изменения статусов заявки реализована в виде конечного автомата, что обеспечивает корректную последовательность переходов и предотвращает ошибочные действия пользователя.
Модуль диспетчеризации обеспечивает функции распределения заявок между выездными специалистами. В текущей версии приложения распределение осуществляется диспетчером вручную на основе информации о текущей загруженности и местоположении специалистов, отображаемой на карте. В перспективе данный модуль может быть дополнен алгоритмами автоматического распределения заявок на основе оптимизационных моделей, однако в рамках данного проекта реализован именно ручной режим с визуальной поддержкой принятия решений. Модуль также включает функцию просмотра истории перемещений специалистов, что позволяет анализировать эффективность использования рабочего времени.
Модуль учета материалов обеспечивает ведение справочника материалов и комплектующих, учет поступления и списания материалов, а также контроль остатков на складе и у каждого специалиста. Данный модуль тесно связан с модулем управления заявками, поскольку списание материалов производится автоматически на основании данных, указанных в акте выполненных работ. Модуль также формирует уведомления о необходимости пополнения запасов при достижении минимального остатка, что позволяет своевременно заказывать материалы и избегать простоев.
Модуль отчетности обеспечивает формирование аналитических отчетов по выполненным заявкам, использованным материалам, эффективности работы специалистов и другим показателям. Отчеты могут быть сформированы за произвольный период времени и представлены в виде таблиц и диаграмм. Данный модуль предназначен преимущественно для руководства компании и позволяет получать объективную информацию о деятельности предприятия для принятия управленческих решений [2].
Модуль интеграции с 1С обеспечивает автоматический обмен данными между разрабатываемым приложением и существующей бухгалтерской системой компании. Интеграция реализована через REST API, что позволяет передавать данные о выполненных работах и использованных материалах в 1С для последующего формирования счетов и актов. Данный модуль является критически важным для обеспечения сквозной автоматизации бизнес-процессов и исключения двойного ввода данных.
Модуль уведомлений отвечает за отправку push-уведомлений выездным специалистам о новых назначениях, а также за автоматическое информирование клиентов о статусе выполнения заявки через SMS-сообщения или email. Данный модуль работает в фоновом режиме и обеспечивает своевременное оповещение всех заинтересованных сторон.
Модуль справочной информации содержит структурированные данные о типовых неисправностях, методах их устранения, а также инструкции по эксплуатации оборудования. Данный модуль доступен выездным специалистам через мобильное приложение и позволяет быстро получить необходимую информацию в процессе выполнения работ.
Важным аспектом проектирования структуры приложения является также определение схемы взаимодействия между модулями. Взаимодействие осуществляется через четко определенные интерфейсы, что обеспечивает слабую связанность модулей и возможность их независимой модификации. Центральным элементом, координирующим работу всех модулей, является ядро системы, которое обеспечивает маршрутизацию запросов, управление транзакциями и обработку ошибок [10].
Таким образом, спроектированная структура приложения представляет собой модульную клиент-серверную архитектуру, обеспечивающую гибкость, масштабируемость и надежность системы. Выделенные функциональные модули полностью покрывают требования, сформулированные в первой главе, и создают основу для дальнейшего проектирования базы данных и пользовательских интерфейсов.
Помимо определения функциональных модулей и их взаимодействия, важным аспектом проектирования структуры приложения является детальная проработка логики работы каждого модуля, а также описание потоков данных между ними. Для наглядного представления архитектуры системы и последовательности выполнения операций целесообразно использовать диаграммы UML, в частности диаграмму вариантов использования (use case diagram) и диаграмму последовательности (sequence diagram). Данные инструменты позволяют формализовать требования к системе и служат основой для последующей реализации.
Диаграмма вариантов использования для разрабатываемого приложения включает двух основных акторов: диспетчера и выездного специалиста. Для диспетчера основными вариантами использования являются: авторизация в системе, просмотр списка заявок, создание новой заявки, редактирование заявки, назначение специалиста, просмотр карты с местоположением специалистов, формирование отчетов, управление справочником материалов и управление пользователями. Для выездного специалиста основными вариантами использования являются: авторизация в мобильном приложении, просмотр списка назначенных заявок, просмотр детальной информации по заявке, изменение статуса заявки, заполнение акта выполненных работ, просмотр истории заявок и просмотр справочной информации. Каждый вариант использования детализирует функциональные требования, сформулированные ранее, и обеспечивает их однозначную интерпретацию разработчиком.
Диаграмма последовательности позволяет описать взаимодействие между объектами системы во времени для реализации конкретного сценария. Например, для сценария «Назначение заявки специалисту» диаграмма последовательности будет включать следующие шаги: диспетчер выбирает заявку из списка, система отображает детальную информацию по заявке, диспетчер выбирает специалиста из списка доступных, система проверяет доступность специалиста, система обновляет статус заявки на «назначена», система отправляет push-уведомление специалисту, система обновляет список заявок на экране диспетчера. Данная детализация позволяет выявить потенциальные проблемы на ранних этапах проектирования и обеспечить корректную реализацию бизнес-логики.
Важным элементом проектирования структуры приложения является также определение форматов данных, используемых для обмена между клиентской и серверной частями. Как было отмечено ранее, для взаимодействия используется REST API с форматом данных JSON. Для каждого эндпоинта API определены метод HTTP (GET, POST, PUT, DELETE), входные параметры и формат ответа. Например, для получения списка заявок используется GET-запрос к эндпоинту /api/orders с возможностью передачи параметров фильтрации (status, date_from, date_to, specialist_id). Ответ возвращается в виде JSON-массива объектов, каждый из которых содержит поля: id, address, client_name, client_phone, description, status, specialist_id, created_at, updated_at. Такая стандартизация обеспечивает согласованность данных и упрощает разработку как серверной, так и клиентской частей.
При проектировании структуры приложения особое внимание было уделено обеспечению безопасности данных. Для защиты API от несанкционированного доступа используется аутентификация на основе JWT-токенов. При авторизации пользователя сервер генерирует токен, который передается клиенту и должен быть включен в заголовок каждого последующего запроса. Сервер проверяет валидность токена и извлекает из него информацию о пользователе и его роли. Для обеспечения дополнительной безопасности токены имеют ограниченный срок действия (24 часа), после чего требуется повторная авторизация. Кроме того, для всех запросов, изменяющих данные (POST, PUT, DELETE), выполняется проверка прав доступа на основе роли пользователя.
Еще одним важным аспектом проектирования является обеспечение отказоустойчивости системы. Для этого предусмотрена обработка исключительных ситуаций на всех уровнях приложения. На уровне сервера реализован централизованный обработчик ошибок, который перехватывает все исключения и возвращает клиенту структурированный ответ с кодом ошибки и описанием проблемы. На уровне клиентских приложений реализована обработка ошибок сети и сервера с выводом понятных пользователю сообщений. Для мобильного приложения также реализована локальная очередь неотправленных запросов, которая автоматически отправляет данные на сервер при восстановлении соединения [22].
Проектирование структуры приложения также включает определение схемы навигации для клиентских приложений. Для веб-интерфейса диспетчера разработана иерархическая структура страниц: главная страница (панель управления), страница списка заявок, страница создания/редактирования заявки, страница карты, страница отчетов, страница управления материалами, страница управления пользователями. Навигация между страницами осуществляется через боковое меню, которое доступно на всех страницах. Для мобильного приложения выездного специалиста разработана структура экранов: экран авторизации, главный экран (список заявок), экран детальной информации по заявке, экран изменения статуса, экран заполнения акта, экран истории заявок, экран справочной информации. Навигация в мобильном приложении реализована с использованием нижней панели навигации и кнопки «Назад».
Важным решением, принятым на этапе проектирования структуры, является выбор стратегии синхронизации данных для мобильного приложения. Учитывая возможность нестабильного интернет-соединения, была выбрана стратегия «офлайн-первый» (offline-first). Данная стратегия предполагает, что приложение в первую очередь сохраняет данные локально на устройстве и лишь затем синхронизирует их с сервером. Для локального хранения данных на мобильном устройстве используется встроенная база данных SQLite, которая обеспечивает быстрый доступ к данным даже при отсутствии сети. Синхронизация с сервером выполняется в фоновом режиме при наличии стабильного интернет-соединения. Данный подход обеспечивает непрерывность работы специалиста независимо от качества связи.
Для обеспечения возможности масштабирования системы в будущем, архитектура серверной части была спроектирована с учетом возможности горизонтального масштабирования. В частности, серверное приложение является stateless (не хранит состояние между запросами), что позволяет при необходимости запускать несколько экземпляров приложения и балансировать нагрузку между ними. База данных также может быть масштабирована путем добавления реплик для чтения и шардирования. Данные решения обеспечивают готовность системы к росту количества пользователей и объема данных без необходимости кардинальной перестройки архитектуры.
В процессе проектирования структуры приложения также были учтены требования к тестированию. Для каждого модуля определены наборы тестов, которые должны быть реализованы на этапе разработки. Для серверной части предусмотрено модульное тестирование (unit-тесты) для проверки корректности работы отдельных функций и интеграционное тестирование для проверки взаимодействия между модулями. Для клиентских приложений предусмотрено UI-тестирование для проверки корректности отображения интерфейса и обработки пользовательских действий. Наличие четко определенных тестовых сценариев на этапе проектирования позволяет обеспечить высокое качество конечного продукта и минимизировать количество ошибок [11].
Таким образом, проектирование структуры приложения представляет собой комплексный процесс, включающий определение архитектуры, выделение функциональных модулей, описание их взаимодействия, разработку схем навигации и выбор стратегий синхронизации данных. Результатом данного этапа является детальная архитектурная схема системы, которая служит основой для последующего проектирования базы данных и пользовательских интерфейсов. Спроектированная структура в полной мере соответствует требованиям, сформулированным в первой главе, и обеспечивает возможность реализации всех заявленных функций с учетом требований к производительности, безопасности и масштабируемости.
Проектирование базы данных
Проектирование базы данных является одним из ключевых этапов создания информационной системы, поскольку именно структура данных определяет возможности системы по хранению, обработке и предоставлению информации. Для разрабатываемого приложения, ориентированного на автоматизацию работы выездных специалистов ООО «Водоучет», база данных должна обеспечивать надежное хранение информации о заявках, пользователях, материалах, выполненных работах и других сущностях, а также поддерживать эффективное выполнение запросов при одновременной работе нескольких пользователей.
В рамках данного дипломного проекта в качестве системы управления базами данных (СУБД) выбрана MySQL, которая является одной из наиболее распространенных реляционных СУБД с открытым исходным кодом. Выбор MySQL обусловлен ее высокой производительностью, надежностью, поддержкой транзакций и широкими возможностями масштабирования. Кроме того, MySQL хорошо интегрируется с выбранным стеком технологий для серверной части приложения (PHP, Laravel) и имеет развитые инструменты для администрирования и резервного копирования.
Проектирование базы данных начинается с построения концептуальной модели данных, которая представляет собой описание предметной области в терминах сущностей и связей между ними. Для визуализации концептуальной модели используется диаграмма «сущность-связь» (ER-диаграмма), которая позволяет наглядно представить структуру данных и определить ключевые сущности, их атрибуты и типы связей.
В результате анализа предметной области и требований к разработке были выделены следующие основные сущности: «Пользователь», «Роль», «Заявка», «Статус заявки», «Специалист», «Клиент», «Акт выполненных работ», «Материал», «Складская операция», «Отчет». Каждая из этих сущностей имеет набор атрибутов, описывающих ее свойства, и связана с другими сущностями определенными отношениями.
Сущность «Пользователь» содержит информацию обо всех пользователях системы, включая диспетчеров и выездных специалистов. Основные атрибуты данной сущности: идентификатор пользователя, фамилия, имя, отчество, логин, пароль (в хешированном виде), адрес электронной почты, номер телефона, идентификатор роли, дата создания и дата последнего обновления записи. Связь с сущностью «Роль» позволяет разграничивать права доступа пользователей к различным функциям системы.
Сущность «Роль» содержит перечень возможных ролей в системе: «диспетчер», «выездной специалист», «руководитель». Каждая роль имеет уникальный идентификатор и наименование. В перспективе возможно добавление новых ролей без изменения структуры базы данных.
Сущность «Заявка» является центральной сущностью базы данных и содержит информацию о каждой поступившей заявке от клиента. Основные атрибуты: идентификатор заявки, дата и время создания, описание неисправности, адрес объекта, желаемая дата и время визита, идентификатор клиента, идентификатор назначенного специалиста, идентификатор статуса заявки, приоритет, комментарий диспетчера, дата и время фактического выполнения, дата и время последнего обновления. Связь с сущностью «Клиент» позволяет хранить контактную информацию заказчика, а связь с сущностью «Специалист» – отслеживать, какой мастер назначен на выполнение заявки.
Сущность «Статус заявки» содержит фиксированный перечень возможных статусов, через которые проходит заявка в процессе своего жизненного цикла: «новая», «назначена», «принята специалистом», «в пути», «на месте», «выполняется», «выполнена», «отменена». Каждый статус имеет уникальный идентификатор и наименование. Использование отдельной таблицы для статусов обеспечивает гибкость системы и возможность добавления новых статусов без изменения кода приложения.
Сущность «Клиент» хранит контактную информацию о заказчиках услуг. Атрибуты: идентификатор клиента, фамилия, имя, отчество, номер телефона, адрес электронной почты, адрес объекта (может отличаться от адреса проживания), примечание. Данная сущность позволяет вести историю обращений каждого клиента и анализировать частоту и характер заявок.
Сущность «Специалист» фактически является расширением сущности «Пользователь» для пользователей с ролью «выездной специалист». Дополнительные атрибуты: идентификатор специалиста, идентификатор пользователя, текущее местоположение (широта и долгота), время последнего обновления местоположения, статус доступности (свободен/занят), список имеющихся материалов. Выделение отдельной сущности позволяет хранить специфическую информацию, характерную только для выездных специалистов.
Сущность «Акт выполненных работ» содержит информацию о фактически выполненных работах по каждой заявке. Атрибуты: идентификатор акта, идентификатор заявки, дата и время составления, перечень выполненных работ (в виде текстового описания или ссылок на типовые операции), перечень использованных материалов с указанием количества, общая стоимость работ, подпись клиента (в виде электронной подписи или отметки), примечание специалиста. Данная сущность является ключевой для формирования закрывающих документов и учета выполненного объема работ.
Сущность «Материал» содержит справочную информацию о расходных материалах и комплектующих, используемых при выполнении работ. Атрибуты: идентификатор материала, наименование, артикул, единица измерения, цена за единицу, минимальный остаток на складе, категория. Данная сущность используется как для учета складских запасов, так и для автоматического расчета стоимости использованных материалов в акте выполненных работ.
Сущность «Складская операция» фиксирует каждое движение материалов: поступление на склад, выдача специалисту, списание по акту, возврат на склад. Атрибуты: идентификатор операции, идентификатор материала, тип операции (поступление, выдача, списание, возврат), количество, дата и время операции, идентификатор пользователя, выполнившего операцию, идентификатор заявки (для списания), идентификатор специалиста (для выдачи). Данная сущность обеспечивает полную прослеживаемость движения материалов и позволяет в любой момент времени получить актуальную информацию об остатках.
Сущность «Отчет» предназначена для хранения сформированных аналитических отчетов. Атрибуты: идентификатор отчета, тип отчета, период формирования, дата и время формирования, идентификатор пользователя, сформировавшего отчет, данные отчета (в формате JSON). Хранение сформированных отчетов позволяет обращаться к ним повторно без необходимости повторного вычисления.
При проектировании базы данных особое внимание было уделено обеспечению целостности данных. Для этого используются механизмы первичных и внешних ключей, ограничения уникальности и проверки допустимых значений. Например, для поля «статус» в таблице «Заявка» установлено ограничение, которое допускает только значения из таблицы «Статус заявки». Для поля «количество» в таблице «Складская операция» установлено ограничение, которое не допускает отрицательных значений. Данные меры предотвращают попадание в базу данных некорректных или противоречивых сведений.
Для обеспечения производительности базы данных при выполнении наиболее частых запросов были спроектированы индексы. Индексы созданы для полей, которые часто используются в условиях поиска и фильтрации: статус заявки, идентификатор специалиста, дата создания заявки, идентификатор клиента, идентификатор материала. Использование индексов позволяет существенно ускорить выполнение запросов, особенно при работе с большими объемами данных [4].
Важным аспектом проектирования базы данных является также обеспечение безопасности хранения данных. Пароли пользователей хранятся в хешированном виде с использованием алгоритма bcrypt, что исключает возможность их восстановления даже при получении несанкционированного доступа к базе данных. Персональные данные клиентов (ФИО, адрес, телефон) хранятся в зашифрованном виде, что соответствует требованиям Федерального закона № 152-ФЗ «О персональных данных». Для шифрования используется симметричный алгоритм AES-256.
Логическая модель базы данных была преобразована в физическую модель, которая представляет собой набор SQL-скриптов для создания таблиц, индексов и ограничений. Физическая модель учитывает особенности выбранной СУБД MySQL, в частности, использует движок InnoDB, который поддерживает транзакции и обеспечивает ссылочную целостность данных на уровне базы данных. Для каждого поля таблицы определен тип данных, допустимость NULL-значений и значение по умолчанию.
Таким образом, спроектированная база данных полностью покрывает информационные потребности разрабатываемого приложения. Структура базы данных является нормализованной, что обеспечивает отсутствие избыточности данных и минимизирует риски возникновения аномалий при их обновлении. В то же время, для повышения производительности выполнения наиболее частых запросов, в структуру были добавлены отдельные таблицы для хранения справочной информации (статусы, роли) и денормализованные поля (например, имя клиента в таблице заявок), что позволяет сократить количество операций соединения таблиц при выполнении запросов [25]. Спроектированная база данных служит основой для реализации на этапе программной разработки и обеспечивает надежное и эффективное хранение всех данных, необходимых для функционирования приложения.
После определения логической и физической моделей базы данных, важным этапом является детальное описание структуры каждой таблицы, включая типы данных, ограничения и связи. Для обеспечения наглядности и удобства последующей реализации, была разработана подробная спецификация базы данных, включающая описание всех таблиц, их полей, индексов и внешних ключей. Данная спецификация служит основой для написания SQL-скриптов создания базы данных на этапе реализации.
Таблица «users» (пользователи) содержит следующие поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), last_name (VARCHAR(50), NOT NULL), first_name (VARCHAR(50), NOT NULL), middle_name (VARCHAR(50)), login (VARCHAR(50), UNIQUE, NOT NULL), password_hash (VARCHAR(255), NOT NULL), email (VARCHAR(100)), phone (VARCHAR(20)), role_id (INT, FOREIGN KEY REFERENCES roles(id)), is_active (BOOLEAN, DEFAULT TRUE), created_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP), updated_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP). Индексы созданы по полям role_id и login.
Таблица «roles» (роли) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), name (VARCHAR(50), UNIQUE, NOT NULL), description (VARCHAR(255)). Данная таблица заполняется на этапе инициализации системы и содержит три записи: «диспетчер», «выездной специалист», «руководитель».
Таблица «orders» (заявки) является наиболее объемной и содержит следующие поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), client_id (INT, FOREIGN KEY REFERENCES clients(id)), specialist_id (INT, FOREIGN KEY REFERENCES specialists(id), NULLABLE), status_id (INT, FOREIGN KEY REFERENCES order_statuses(id)), description (TEXT, NOT NULL), address (VARCHAR(255), NOT NULL), desired_date (DATE), desired_time (TIME), priority (ENUM('low', 'medium', 'high'), DEFAULT 'medium'), dispatcher_comment (TEXT), actual_completion_date (DATETIME), created_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP), updated_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP). Индексы созданы по полям status_id, specialist_id, client_id, created_at. Наличие индексов по статусу и специалисту позволяет быстро выполнять наиболее частые запросы: получение списка активных заявок для диспетчера и получение списка назначенных заявок для конкретного специалиста [13].
Таблица «order_statuses» (статусы заявок) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), name (VARCHAR(50), UNIQUE, NOT NULL), code (VARCHAR(20), UNIQUE, NOT NULL), description (VARCHAR(255)). Поле code используется в программном коде для идентификации статуса и обеспечивает независимость от возможного изменения наименования статуса в интерфейсе.
Таблица «clients» (клиенты) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), last_name (VARCHAR(50), NOT NULL), first_name (VARCHAR(50), NOT NULL), middle_name (VARCHAR(50)), phone (VARCHAR(20), NOT NULL), email (VARCHAR(100)), address (VARCHAR(255)), note (TEXT), created_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP), updated_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP). Индекс создан по полю phone, так как поиск клиента по номеру телефона является одной из наиболее частых операций.
Таблица «specialists» (специалисты) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), user_id (INT, FOREIGN KEY REFERENCES users(id), UNIQUE), current_latitude (DECIMAL(10, 8)), current_longitude (DECIMAL(11, 8)), location_updated_at (TIMESTAMP), is_available (BOOLEAN, DEFAULT TRUE). Отдельная таблица для специалистов позволяет хранить специфические данные, не перегружая общую таблицу пользователей. Индекс создан по полю is_available для быстрого поиска свободных специалистов.
Таблица «work_reports» (акты выполненных работ) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), order_id (INT, FOREIGN KEY REFERENCES orders(id), UNIQUE), completed_at (DATETIME, NOT NULL), work_description (TEXT, NOT NULL), total_cost (DECIMAL(10, 2)), client_signature (TEXT), specialist_comment (TEXT), created_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP), updated_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP). Связь один-к-одному с таблицей заявок обеспечивает то, что на каждую выполненную заявку может быть составлен только один акт.
Таблица «materials» (материалы) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), name (VARCHAR(100), NOT NULL), article (VARCHAR(50), UNIQUE), unit (VARCHAR(20), NOT NULL), price (DECIMAL(10, 2), NOT NULL), min_stock (INT, DEFAULT 0), category_id (INT, FOREIGN KEY REFERENCES material_categories(id)), created_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP), updated_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP). Индекс создан по полю article для быстрого поиска материала по артикулу.
Таблица «material_categories» (категории материалов) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), name (VARCHAR(100), UNIQUE, NOT NULL), description (VARCHAR(255)). Данная таблица позволяет группировать материалы по категориям (например, «фитинги», «краны», «прокладки», «счетчики») для удобства навигации и поиска.
Таблица «warehouse_operations» (складские операции) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), material_id (INT, FOREIGN KEY REFERENCES materials(id)), operation_type (ENUM('receipt', 'issuance', 'write_off', 'return'), NOT NULL), quantity (INT, NOT NULL), order_id (INT, FOREIGN KEY REFERENCES orders(id), NULLABLE), specialist_id (INT, FOREIGN KEY REFERENCES specialists(id), NULLABLE), user_id (INT, FOREIGN KEY REFERENCES users(id)), operation_date (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP), comment (TEXT). Индексы созданы по полям material_id, operation_type и operation_date для обеспечения возможности быстрого формирования отчетов по движению материалов за период.
Таблица «work_report_materials» (материалы в акте) является связующей таблицей для реализации связи многие-ко-многим между актами выполненных работ и материалами. Содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), work_report_id (INT, FOREIGN KEY REFERENCES work_reports(id)), material_id (INT, FOREIGN KEY REFERENCES materials(id)), quantity (INT, NOT NULL). Данная таблица позволяет зафиксировать, какие именно материалы и в каком количестве были использованы при выполнении конкретной заявки [28].
Таблица «reports» (отчеты) содержит поля: id (INT, PRIMARY KEY, AUTO_INCREMENT), type (VARCHAR(50), NOT NULL), period_start (DATE), period_end (DATE), generated_at (TIMESTAMP, DEFAULT CURRENT_TIMESTAMP), generated_by (INT, FOREIGN KEY REFERENCES users(id)), data (JSON), status (ENUM('generating', 'ready', 'error'), DEFAULT 'generating'). Хранение данных отчета в формате JSON обеспечивает гибкость и позволяет хранить отчеты различной структуры без изменения схемы базы данных.
Для обеспечения целостности данных при выполнении операций, изменяющих несколько таблиц (например, закрытие заявки и списание материалов), используются транзакции. Транзакции гарантируют, что либо все изменения будут успешно применены, либо ни одно из них, что предотвращает возникновение противоречивых состояний базы данных. В MySQL с движком InnoDB транзакции поддерживаются на уровне СУБД, что обеспечивает их надежное выполнение.
Важным аспектом проектирования базы данных является также стратегия резервного копирования. Для обеспечения возможности восстановления данных в случае сбоя предусмотрено ежедневное автоматическое создание резервных копий базы данных с помощью утилиты mysqldump. Резервные копии хранятся на отдельном сервере в течение 30 дней, после чего автоматически удаляются. Данная стратегия обеспечивает возможность восстановления данных с точностью до одного дня.
Для оптимизации производительности базы данных при росте объема данных предусмотрено использование партиционирования таблиц. Наиболее объемная таблица «orders» может быть партиционирована по дате создания (created_at), что позволит эффективно выполнять запросы за определенный период времени, обращаясь только к соответствующим партициям. Аналогично, таблица «warehouse_operations» может быть партиционирована по дате операции. Внедрение партиционирования планируется на этапе, когда объем данных достигнет критического значения, влияющего на производительность [8].
Таким образом, спроектированная база данных представляет собой нормализованную реляционную структуру, полностью удовлетворяющую информационным потребностям разрабатываемого приложения. Использование механизмов первичных и внешних ключей, ограничений целостности, индексов и транзакций обеспечивает надежность, производительность и безопасность хранения данных. Спроектированная структура базы данных является основой для реализации на этапе программной разработки и позволяет эффективно хранить и обрабатывать все данные, необходимые для автоматизации работы выездных специалистов ООО «Водоучет».
Проектирование макетов интерфейса
Проектирование макетов интерфейса является завершающим этапом второй главы дипломного проекта и представляет собой визуализацию структуры приложения, разработанной ранее. Макеты интерфейса (wireframes) позволяют наглядно представить расположение элементов управления, информационных блоков и навигационных элементов на экране, а также согласовать внешний вид будущего приложения с заказчиком до начала этапа программной реализации. В рамках данного дипломного проекта макеты интерфейса разрабатывались для двух клиентских приложений: веб-интерфейса диспетчера и мобильного приложения выездного специалиста.
При проектировании макетов интерфейса использовались принципы юзабилити (usability), обеспечивающие удобство и эффективность работы пользователей. Ключевыми принципами являлись: интуитивная понятность навигации, минимизация количества действий для выполнения типовых операций, единообразие элементов управления на всех экранах, использование понятных иконок и подписей, а также адаптивность интерфейса для различных размеров экранов. Данные принципы соответствуют современным подходам к проектированию пользовательских интерфейсов, ориентированных на потребности конечных пользователей [15].
Для веб-интерфейса диспетчера был разработан макет главной страницы (панели управления), которая открывается после авторизации пользователя в системе. Главная страница содержит следующие функциональные блоки: верхняя панель с логотипом компании, названием системы и информацией о текущем пользователе (имя, кнопка выхода); боковое навигационное меню со ссылками на основные разделы (Заявки, Карта, Отчеты, Материалы, Пользователи); центральная рабочая область, которая по умолчанию отображает сводку по текущему состоянию заявок (количество новых, назначенных, выполненных за сегодня). Сводка представлена в виде карточек с цветовой индикацией: красный цвет для просроченных заявок, желтый для заявок, требующих внимания, зеленый для выполненных. Такое визуальное представление позволяет диспетчеру быстро оценить текущую ситуацию и выявить проблемные области.
Макет страницы списка заявок является одним из наиболее важных, поскольку работа с заявками составляет основную часть функциональности диспетчера. Страница содержит: панель фильтрации (по статусу, специалисту, дате, приоритету, адресу); таблицу со списком заявок, где каждая строка содержит основные поля (номер, дата, адрес, клиент, статус, специалист, приоритет); кнопку создания новой заявки; возможность сортировки по каждому столбцу таблицы. При нажатии на строку заявки открывается модальное окно с детальной информацией, где диспетчер может просмотреть полное описание, изменить статус, переназначить специалиста или добавить комментарий. Такой подход позволяет работать с заявками, не покидая страницу списка, что повышает эффективность работы.
Макет страницы карты предназначен для визуализации местоположения выездных специалистов в реальном времени. Страница содержит: карту города с отмеченными на ней текущими позициями специалистов (каждый специалист обозначен иконкой с его именем); панель со списком специалистов, отображающая их статус (свободен/занят) и количество активных заявок; возможность фильтрации отображаемых специалистов по статусу. При нажатии на иконку специалиста на карте отображается всплывающая подсказка с его контактной информацией и списком текущих заявок. Данная страница позволяет диспетчеру принимать обоснованные решения при распределении новых заявок, выбирая ближайшего к объекту свободного специалиста.
Макет страницы отчетов содержит: панель выбора типа отчета (по заявкам, по специалистам, по материалам); календарь для выбора периода формирования отчета; кнопку формирования отчета; область отображения результатов в виде таблицы и диаграммы. Предусмотрена возможность экспорта отчета в форматы PDF и Excel для последующего анализа и передачи руководству. Интерфейс страницы отчетов спроектирован таким образом, чтобы минимизировать количество действий для получения нужной информации.
Макет страницы управления материалами содержит: таблицу со списком материалов (наименование, артикул, единица измерения, цена, текущий остаток на складе); панель фильтрации по категории и поиска по наименованию или артикулу; кнопки добавления нового материала, редактирования и удаления; индикацию материалов, достигших минимального остатка (выделение красным цветом). Данная страница обеспечивает удобное управление справочником материалов и контроль складских запасов.
Макет страницы управления пользователями содержит: таблицу со списком пользователей (ФИО, логин, роль, статус активности); кнопки добавления нового пользователя, редактирования и деактивации; форму создания/редактирования пользователя с полями для ввода ФИО, логина, пароля, роли и контактных данных. Данная страница доступна только пользователям с ролью «руководитель» и обеспечивает административное управление системой.
Для мобильного приложения выездного специалиста был разработан макет экрана авторизации, который содержит: поле для ввода логина; поле для ввода пароля; кнопку «Войти»; ссылку для восстановления пароля. Дизайн экрана минималистичен и содержит только необходимые элементы, что обеспечивает быструю авторизацию даже в полевых условиях [17].
Макет главного экрана мобильного приложения содержит: нижнюю панель навигации с тремя вкладками (Заявки, История, Справочник); на вкладке «Заявки» отображается список назначенных специалисту заявок на текущий день; каждая заявка представлена в виде карточки с указанием адреса, времени визита, статуса и краткого описания; карточки отсортированы по времени визита; цветовая индикация статуса (зеленый – выполнена, желтый – в работе, красный – просрочена) позволяет быстро оценить ситуацию. При нажатии на карточку заявки открывается экран с детальной информацией.
Макет экрана детальной информации по заявке содержит: полную информацию о заявке (адрес, контактные данные клиента, описание неисправности, желаемое время визита); кнопки для изменения статуса заявки («Принять», «Выезжаю», «На месте», «Выполнена»); кнопку «Заполнить акт», которая становится активной после установки статуса «На месте»; кнопку «Позвонить клиенту»; кнопку «Построить маршрут» (открывает внешнее навигационное приложение). Последовательное изменение статусов обеспечивает контроль за ходом выполнения заявки со стороны диспетчера.
Макет экрана заполнения акта выполненных работ содержит: поля для выбора типовых операций из справочника (с возможностью добавления произвольного текста); поле для выбора использованных материалов с указанием количества; поле для ввода общей стоимости работ (заполняется автоматически на основании выбранных операций и материалов, с возможностью ручной корректировки); кнопку для добавления фотографий выполненных работ; поле для комментария специалиста; кнопку «Подпись клиента» (для сбора электронной подписи); кнопку «Сохранить и отправить». Интерфейс заполнения акта спроектирован таким образом, чтобы минимизировать ручной ввод текста и максимально использовать выбор из справочников, что снижает вероятность ошибок и ускоряет процесс оформления документации.
Макет экрана истории заявок содержит: список всех выполненных заявок специалиста, отсортированный по дате (от новых к старым); возможность поиска по адресу или дате; при нажатии на заявку открывается экран с детальной информацией, включая копию акта выполненных работ. Данный экран позволяет специалисту быстро найти информацию о ранее выполненных работах, что может быть полезно при повторных обращениях клиента.
Макет экрана справочной информации содержит: список категорий типовых неисправностей; при выборе категории отображается перечень типовых неисправностей с описанием симптомов и алгоритмом диагностики; для каждой неисправности указаны рекомендуемые методы ремонта и необходимые материалы. Данный экран служит инструментом поддержки принятия решений для специалиста, особенно в сложных или нестандартных ситуациях [20].
Все разработанные макеты интерфейса были согласованы с руководством ООО «Водоучет» и ключевыми сотрудниками компании. В процессе согласования были внесены незначительные корректировки, касающиеся расположения отдельных элементов и цветовой схемы. В частности, заказчик предложил использовать корпоративные цвета компании (синий и белый) для оформления интерфейса, что было учтено в финальных версиях макетов. Согласованные макеты интерфейса являются основой для этапа программной реализации и позволяют разработчику точно понимать, как должен выглядеть и функционировать каждый экран приложения.
Таким образом, разработанные макеты интерфейса в полной мере отражают функциональные требования, сформулированные в первой главе, и обеспечивают удобный и интуитивно понятный пользовательский интерфейс как для веб-приложения диспетчера, так и для мобильного приложения выездного специалиста. Макеты учитывают специфику работы каждой группы пользователей и направлены на повышение эффективности выполнения их должностных обязанностей. Наличие детальных макетов интерфейса существенно упрощает этап программной реализации и минимизирует риски несоответствия разработанного приложения ожиданиям заказчика.
Помимо основных экранов, описанных ранее, важное значение имеет проектирование дополнительных элементов интерфейса, обеспечивающих комфортную работу пользователей и быстрый доступ к часто используемым функциям. В частности, для веб-интерфейса диспетчера были разработаны макеты модальных окон для выполнения ключевых операций, таких как создание новой заявки, назначение специалиста и просмотр детальной информации. Использование модальных окон позволяет выполнять операции без перезагрузки страницы, что повышает скорость работы и улучшает пользовательский опыт.
Макет модального окна создания новой заявки содержит форму со следующими полями: фамилия, имя и отчество клиента; номер телефона клиента (с маской ввода для обеспечения корректного формата); адрес объекта (с возможностью автодополнения при вводе); описание неисправности (многострочное текстовое поле); желаемая дата и время визита; приоритет заявки (выпадающий список). После заполнения формы и нажатия кнопки «Создать», заявка сохраняется в базе данных и появляется в списке активных заявок. Форма содержит валидацию обязательных полей, которая выполняется как на стороне клиента (для мгновенной обратной связи), так и на стороне сервера (для обеспечения безопасности).
Макет модального окна назначения специалиста содержит: список доступных специалистов с указанием их текущего статуса (свободен/занят) и количества активных заявок; карту с отображением местоположения специалистов и адреса объекта заявки; возможность выбора специалиста из списка или кликом по иконке на карте; кнопку «Назначить», которая фиксирует выбор и обновляет статус заявки. Данное окно предоставляет диспетчеру всю необходимую информацию для принятия обоснованного решения о назначении исполнителя.
Для мобильного приложения выездного специалиста также были разработаны макеты вспомогательных экранов, таких как экран уведомлений и экран настроек. Экран уведомлений отображает историю push-уведомлений, полученных специалистом (новые назначения, изменения в заявках, напоминания). Экран настроек позволяет специалисту изменить пароль, настроить параметры уведомлений (звук, вибрация) и просмотреть информацию о версии приложения. Данные экраны не являются критически важными для основной функциональности, однако их наличие повышает удобство использования приложения и позволяет пользователю адаптировать его под свои предпочтения.
Важным аспектом проектирования макетов интерфейса является обеспечение доступности (accessibility) для пользователей с ограниченными возможностями. В рамках данного проекта были учтены следующие требования: достаточный контраст между текстом и фоном (коэффициент контрастности не менее 4.5:1 для основного текста); возможность увеличения размера шрифта без нарушения структуры страницы; поддержка навигации с помощью клавиатуры для веб-интерфейса; наличие текстовых подписей для всех иконок и графических элементов. Данные меры соответствуют стандартам WCAG 2.1 и обеспечивают возможность использования приложения более широким кругом пользователей [23].
Для обеспечения единообразия визуального оформления всех экранов приложения была разработана библиотека компонентов пользовательского интерфейса (UI kit). Данная библиотека включает описание используемых цветов, шрифтов, размеров элементов, стилей кнопок, полей ввода, таблиц, модальных окон и других компонентов. Использование единой библиотеки компонентов обеспечивает согласованный внешний вид всех экранов, упрощает процесс разработки и снижает вероятность возникновения визуальных ошибок. Цветовая схема приложения основана на корпоративных цветах ООО «Водоучет»: основной цвет – синий (#1565C0), дополнительный – белый (#FFFFFF), акцентный – зеленый (#2E7D32) для обозначения успешных операций и красный (#C62828) для обозначения ошибок и критических состояний.
В процессе проектирования макетов интерфейса также были разработаны прототипы взаимодействия (interactive prototypes), которые позволяют смоделировать поведение приложения при выполнении различных сценариев использования. Прототипы создавались с использованием специализированного инструмента Figma, который позволяет создавать интерактивные переходы между экранами и демонстрировать логику работы приложения. Прототипы были продемонстрированы представителям заказчика, которые подтвердили корректность реализации бизнес-логики и удобство использования интерфейса. Наличие интерактивных прототипов позволило выявить и устранить несколько потенциальных проблем на ранних этапах проектирования, до начала разработки.
Одной из таких проблем стало неочевидное расположение кнопки изменения статуса заявки в мобильном приложении. В первоначальной версии макета кнопка изменения статуса находилась в нижней части экрана детальной информации, что требовало от пользователя прокрутки экрана для ее нахождения. После обсуждения с заказчиком было принято решение вынести кнопку изменения статуса в верхнюю часть экрана, закрепив ее позицию, чтобы она всегда была доступна пользователю независимо от прокрутки. Данное изменение существенно повысило удобство использования приложения для выездных специалистов, которые часто работают в условиях ограниченного времени.
Другой важной доработкой, внесенной по результатам обсуждения прототипов, стало добавление возможности быстрого поиска клиента по номеру телефона при создании новой заявки. В первоначальной версии макета предполагалось, что диспетчер будет вводить все данные клиента вручную при каждом создании заявки. Однако в процессе обсуждения выяснилось, что значительная часть клиентов обращается в компанию повторно, и было бы удобно автоматически подгружать их данные из базы при вводе номера телефона. Данная функция была реализована в виде автодополнения: при вводе номера телефона система выполняет поиск среди существующих клиентов и предлагает выбрать подходящий вариант, что существенно ускоряет процесс создания заявки для постоянных клиентов [29].
В рамках проектирования макетов интерфейса также были разработаны экраны для отображения ошибок и исключительных ситуаций. Например, был разработан макет страницы 404 (страница не найдена) для веб-интерфейса, а также макет экрана с сообщением об отсутствии интернет-соединения для мобильного приложения. Данные экраны содержат понятное пользователю сообщение о возникшей проблеме и инструкцию по ее устранению. Наличие таких экранов повышает доверие пользователей к системе и снижает уровень фрустрации при возникновении технических проблем.
Таким образом, разработанные макеты интерфейса представляют собой детальную визуальную спецификацию будущего приложения, охватывающую все ключевые экраны и сценарии использования. Макеты учитывают требования заказчика, принципы юзабилити и доступности, а также корпоративный стиль компании. Наличие согласованных макетов интерфейса является основой для этапа программной реализации и позволяет разработчику точно понимать, как должен выглядеть и функционировать каждый элемент приложения. Разработанные макеты в полной мере соответствуют функциональным требованиям, сформулированным в первой главе, и обеспечивают удобный и интуитивно понятный интерфейс для всех групп пользователей системы.
Обоснование выбора программного обеспечения для выполнения работы
Выбор программного обеспечения и технологического стека является одним из ключевых решений на этапе реализации информационной системы, поскольку он определяет возможности, производительность и сложность разработки будущего приложения. При выборе технологий для разработки приложения для выездных специалистов ООО «Водоучет» учитывался ряд критериев: функциональные требования к системе, требования к производительности и безопасности, совместимость с существующей инфраструктурой заказчика, стоимость лицензирования, доступность квалифицированных специалистов на рынке труда, а также наличие качественной документации и сообщества разработчиков.
Для реализации серверной части приложения (backend) был выбран язык программирования PHP версии 8.1 и фреймворк Laravel версии 10. Выбор PHP обусловлен его широкой распространенностью, большим количеством готовых библиотек и инструментов, а также хорошей совместимостью с выбранной системой управления базами данных MySQL. Фреймворк Laravel, в свою очередь, является одним из наиболее популярных PHP-фреймворков и предоставляет разработчику мощные инструменты для быстрой разработки веб-приложений, включая ORM Eloquent для работы с базой данных, систему маршрутизации, аутентификации, шаблонизатор Blade, а также встроенную поддержку REST API. Использование Laravel позволяет существенно сократить время разработки за счет готовых решений для типовых задач и обеспечивает высокое качество кода благодаря следованию лучшим практикам разработки [45].
В качестве системы управления базами данных (СУБД) выбрана MySQL версии 8.0 с движком InnoDB. Выбор MySQL обоснован ее высокой производительностью, надежностью, поддержкой транзакций и ссылочной целостности данных, а также хорошей интеграцией с PHP и Laravel. MySQL является бесплатной СУБД с открытым исходным кодом, что позволяет снизить затраты на лицензирование для заказчика. Движок InnoDB обеспечивает поддержку транзакций, что критически важно для операций, изменяющих несколько таблиц одновременно (например, закрытие заявки и списание материалов). Кроме того, MySQL имеет развитые инструменты для резервного копирования и восстановления данных, а также широкое сообщество пользователей, что упрощает решение возможных проблем в процессе эксплуатации.
Для реализации веб-интерфейса диспетчера (frontend) был выбран язык JavaScript и фреймворк Vue.js версии 3. Выбор Vue.js обусловлен его относительно низким порогом входа, хорошей производительностью и гибкостью. Vue.js позволяет создавать реактивные пользовательские интерфейсы, которые мгновенно обновляются при изменении данных, что обеспечивает высокую отзывчивость приложения. Кроме того, Vue.js имеет модульную архитектуру, позволяющую разбивать интерфейс на переиспользуемые компоненты, что упрощает разработку и последующее сопровождение кода. Для стилизации интерфейса используется CSS-фреймворк Bootstrap 5, который предоставляет готовые компоненты и сетку для создания адаптивных макетов, соответствующих разработанным макетам интерфейса.
Для реализации мобильного приложения выездного специалиста был выбран язык программирования Kotlin и среда разработки Android Studio. Kotlin является современным языком программирования для платформы Android, который обеспечивает более высокую производительность и безопасность по сравнению с Java, а также имеет более лаконичный синтаксис. Выбор нативной разработки (в отличие от кроссплатформенных решений, таких как React Native или Flutter) обусловлен необходимостью обеспечения высокой производительности приложения, доступа к нативным функциям устройства (GPS, камера, push-уведомления) и лучшей интеграции с операционной системой Android. Кроме того, нативная разработка обеспечивает более высокий уровень безопасности, что важно при работе с персональными данными клиентов.
Для обеспечения взаимодействия между серверной частью и клиентскими приложениями используется REST API. REST (Representational State Transfer) является архитектурным стилем для построения распределенных систем, который обеспечивает стандартизированный обмен данными между клиентом и сервером с использованием протокола HTTP. В качестве формата данных для обмена выбран JSON (JavaScript Object Notation), который является легковесным, легко читаемым и поддерживается большинством языков программирования. Для документирования API используется инструмент Swagger (OpenAPI), который позволяет автоматически генерировать документацию и обеспечивает удобное тестирование эндпоинтов.
Для обеспечения безопасности приложения используются следующие инструменты и библиотеки: для аутентификации и авторизации – Laravel Sanctum, который предоставляет простой и безопасный механизм для работы с JWT-токенами; для шифрования данных – встроенные средства PHP и Laravel; для защиты от CSRF-атак – встроенные механизмы Laravel; для валидации входных данных – встроенные средства Laravel и Vue.js. Использование проверенных и широко распространенных инструментов безопасности позволяет минимизировать риски возникновения уязвимостей и обеспечить защиту данных пользователей и клиентов [34].
Для разработки и отладки приложения используется среда разработки PhpStorm для серверной части и веб-интерфейса, а также Android Studio для мобильного приложения. Обе среды предоставляют мощные инструменты для написания кода, отладки, рефакторинга и управления версиями. Для управления версиями исходного кода используется система Git и платформа GitHub, которые обеспечивают возможность отслеживания изменений, совместной работы над кодом и резервного копирования.
Для тестирования приложения используются следующие инструменты: PHPUnit для модульного тестирования серверной части, Jest для тестирования JavaScript-компонентов веб-интерфейса, JUnit и Espresso для тестирования мобильного приложения. Данные инструменты позволяют автоматизировать процесс тестирования и обеспечить высокое качество кода на всех этапах разработки. Кроме того, для тестирования API используется инструмент Postman, который позволяет отправлять HTTP-запросы к серверу и анализировать ответы.
Для развертывания приложения на сервере заказчика используется связка веб-сервер Apache и интерпретатор PHP-FPM. Apache является одним из наиболее распространенных веб-серверов, который обеспечивает высокую производительность и надежность. PHP-FPM (FastCGI Process Manager) является альтернативной реализацией PHP, которая обеспечивает более высокую производительность по сравнению с классическим mod_php за счет использования отдельного процесса для обработки запросов. Для обеспечения безопасности и изоляции приложения используется контейнеризация с помощью Docker, которая позволяет упаковать приложение и все его зависимости в изолированный контейнер и гарантировать его корректную работу на любом сервере [38].
Таким образом, выбранный стек технологий обеспечивает оптимальный баланс между функциональностью, производительностью, безопасностью и сложностью разработки. Использование современных и широко распространенных технологий гарантирует возможность дальнейшего сопровождения и развития приложения, а также наличие квалифицированных специалистов на рынке труда для поддержки системы. Выбранные инструменты и библиотеки в полной мере соответствуют требованиям к разработке, сформулированным в первой главе, и позволяют реализовать все запланированные функции приложения.
Помимо выбора основных технологий для реализации серверной и клиентской частей, важное значение имеет обоснование выбора инструментов для разработки, отладки и развертывания приложения. В рамках данного дипломного проекта для управления зависимостями в PHP-проекте используется Composer, который является стандартным менеджером пакетов для PHP и позволяет легко подключать сторонние библиотеки и фреймворки. Для управления зависимостями в JavaScript-проекте используется npm (Node Package Manager), который обеспечивает аналогичную функциональность для библиотек и фреймворков JavaScript. Использование менеджеров пакетов позволяет автоматизировать процесс установки и обновления зависимостей, а также гарантирует использование совместимых версий библиотек.
Для автоматизации процессов сборки и развертывания приложения используется инструмент Laravel Mix, который является оберткой над Webpack и предоставляет удобный API для компиляции CSS и JavaScript-файлов, оптимизации изображений и других задач. Laravel Mix интегрирован в фреймворк Laravel и позволяет настроить процесс сборки фронтенда с минимальными усилиями. Для мобильного приложения сборка выполняется с использованием встроенных средств Android Studio (Gradle), которые обеспечивают компиляцию исходного кода в APK-файл, пригодный для установки на устройство.
Важным аспектом выбора программного обеспечения является также обеспечение возможности отладки приложения на всех этапах разработки. Для отладки серверной части используется встроенный инструмент Laravel Telescope, который предоставляет удобный веб-интерфейс для просмотра логов, запросов к базе данных, отправленных писем и другой отладочной информации. Для отладки мобильного приложения используются встроенные средства Android Studio, включая Android Debug Bridge (ADB) и профилировщик производительности. Для отладки веб-интерфейса используются инструменты разработчика, встроенные в браузер Google Chrome.
Для обеспечения контроля версий исходного кода и организации совместной работы используется система Git и платформа GitHub. Git является наиболее распространенной системой контроля версий, которая позволяет отслеживать изменения в коде, создавать ветки для разработки отдельных функций и объединять изменения из разных веток. Использование GitHub обеспечивает удаленное хранение репозитория, возможность создания задач (issues) и проведения код-ревью (pull requests). В рамках данного дипломного проекта, учитывая, что разработка ведется одним студентом, Git используется в первую очередь для резервного копирования кода и отслеживания истории изменений.
Для развертывания приложения на сервере заказчика используется Docker, который позволяет упаковать приложение и все его зависимости (веб-сервер, интерпретатор PHP, СУБД) в изолированные контейнеры. Использование Docker обеспечивает идентичность окружения разработки и эксплуатации, что минимизирует риски возникновения проблем при развертывании. Кроме того, Docker упрощает процесс масштабирования приложения: при необходимости можно запустить несколько экземпляров контейнера с приложением и распределять нагрузку между ними с помощью балансировщика. Для оркестрации контейнеров используется Docker Compose, который позволяет описать конфигурацию многоконтейнерного приложения в YAML-файле и запускать все контейнеры одной командой.
В процессе выбора программного обеспечения также учитывались требования к лицензированию. Все выбранные технологии и инструменты являются бесплатными и имеют открытый исходный код, что позволяет заказчику не нести дополнительных затрат на приобретение лицензий. Исключение составляет среда разработки PhpStorm, которая является коммерческим продуктом, однако в рамках образовательного процесса студент имеет право на бесплатную лицензию. В случае передачи проекта заказчику, для сопровождения системы могут использоваться любые бесплатные редакторы кода, такие как Visual Studio Code.
Важным критерием выбора технологий является также наличие качественной документации и активного сообщества разработчиков. Laravel, Vue.js, Kotlin и MySQL имеют обширную официальную документацию, множество туториалов и примеров кода, а также активные сообщества на форумах и в социальных сетях. Это обеспечивает возможность быстрого поиска решений для возникающих проблем и снижает риски, связанные с возможными техническими сложностями в процессе разработки [50].
Следует также отметить, что выбранный стек технологий соответствует современным тенденциям в области разработки программного обеспечения и обеспечивает актуальность разработанного приложения в течение нескольких лет. Laravel и Vue.js являются одними из наиболее популярных фреймворков в своих категориях и активно развиваются, что гарантирует получение обновлений безопасности и новых функций в будущем. Kotlin является официальным языком разработки для Android и активно поддерживается компанией Google, что обеспечивает его долгосрочную актуальность.
При выборе технологий также учитывалась возможность интеграции с существующей инфраструктурой заказчика. Сервер компании работает под управлением операционной системы Ubuntu Linux, которая является одной из наиболее популярных платформ для размещения веб-приложений и полностью совместима с выбранным стеком технологий. Бухгалтерская система 1С:Предприятие, с которой необходима интеграция, поддерживает обмен данными через REST API, что соответствует выбранному подходу к организации взаимодействия между системами.
Таким образом, обоснование выбора программного обеспечения для выполнения работы представляет собой комплексный анализ, учитывающий функциональные требования, требования к производительности, безопасности, стоимости, совместимости и долгосрочной поддержке. Выбранный стек технологий (PHP/Laravel, MySQL, Vue.js, Kotlin) обеспечивает оптимальный баланс между указанными критериями и позволяет реализовать все запланированные функции приложения в рамках установленных сроков и бюджета. Использование современных инструментов разработки, отладки и развертывания гарантирует высокое качество конечного продукта и его готовность к промышленной эксплуатации в ООО «Водоучет» [41].
Реализация базы данных
Реализация базы данных является первым практическим этапом создания информационной системы, в ходе которого логическая модель, спроектированная во второй главе, преобразуется в физическую структуру, готовую к эксплуатации. В рамках данного дипломного проекта реализация базы данных включала создание таблиц, индексов, ограничений целостности, а также наполнение справочных таблиц начальными данными. Все операции выполнялись с использованием языка SQL (Structured Query Language) в среде управления базами данных MySQL.
Процесс реализации начался с создания новой базы данных с именем «water_accounting_db». Для обеспечения корректной работы с кириллическими символами была выбрана кодировка UTF-8 (utf8mb4_general_ci), которая поддерживает все символы Unicode, включая специальные символы и эмодзи. Выбор данной кодировки обеспечивает корректное отображение русскоязычных данных (фамилии, адреса, описания) во всех элементах приложения. После создания базы данных были выполнены SQL-скрипты для создания всех таблиц, спроектированных на этапе логического моделирования.
Первыми были созданы справочные таблицы, не имеющие внешних ключей: roles (роли пользователей), order_statuses (статусы заявок) и material_categories (категории материалов). Для каждой таблицы был определен первичный ключ (id) с автоматическим инкрементом, а также необходимые поля с указанием типов данных и ограничений. Например, для таблицы roles были созданы поля id (INT, PRIMARY KEY, AUTO_INCREMENT) и name (VARCHAR(50), UNIQUE, NOT NULL). После создания таблицы в нее были добавлены начальные данные: три роли («диспетчер», «выездной специалист», «руководитель») и семь статусов заявок («новая», «назначена», «принята специалистом», «в пути», «на месте», «выполнена», «отменена»).
Затем были созданы основные таблицы, имеющие внешние ключи: users (пользователи), clients (клиенты), specialists (специалисты) и orders (заявки). При создании таблицы users были учтены требования безопасности: поле password_hash имеет тип VARCHAR(255) для хранения хеша пароля, полученного с использованием алгоритма bcrypt. Поле login было объявлено как UNIQUE для предотвращения создания дублирующихся учетных записей. Внешний ключ role_id ссылается на таблицу roles и обеспечивает, что пользователю может быть назначена только существующая роль.
При создании таблицы orders были реализованы все внешние ключи, связывающие ее с таблицами clients, specialists и order_statuses. Для обеспечения целостности данных при удалении записей из родительских таблиц были выбраны соответствующие стратегии: ON DELETE RESTRICT (запрет удаления, если есть связанные заявки) для client_id и specialist_id, и ON DELETE SET NULL (установка NULL при удалении) для status_id. Данные стратегии предотвращают потерю данных и обеспечивают корректное поведение системы в исключительных ситуациях.
После создания всех таблиц были созданы индексы для оптимизации производительности выполнения запросов. Индексы были созданы для полей, которые часто используются в условиях WHERE и JOIN: status_id, specialist_id, client_id, created_at в таблице orders; phone в таблице clients; is_available в таблице specialists; article в таблице materials; material_id, operation_type, operation_date в таблице warehouse_operations. Создание индексов позволяет существенно ускорить выполнение наиболее частых запросов, особенно при работе с большими объемами данных [35].
Для обеспечения производительности также были созданы составные индексы для часто используемых комбинаций полей. Например, для таблицы orders был создан составной индекс по полям (status_id, specialist_id), который ускоряет выполнение запроса на получение списка активных заявок для конкретного специалиста. Для таблицы warehouse_operations был создан составной индекс по полям (material_id, operation_date), который ускоряет формирование отчетов по движению материалов за период.
После создания таблиц и индексов были реализованы представления (views) для упрощения выполнения часто используемых запросов. Представление «active_orders» объединяет данные из таблиц orders, clients и specialists и отфильтровывает заявки со статусами, отличными от «выполнена» и «отменена». Представление «specialist_workload» содержит информацию о количестве активных заявок для каждого специалиста. Использование представлений позволяет упростить код приложения и обеспечить единообразный доступ к данным.
Для автоматизации выполнения рутинных операций были созданы хранимые процедуры и триггеры. Хранимая процедура «close_order» выполняет комплекс операций по закрытию заявки: обновляет статус на «выполнена», устанавливает фактическую дату выполнения и списывает использованные материалы со склада. Использование хранимой процедуры обеспечивает атомарность операции и предотвращает возникновение противоречивых состояний базы данных. Триггер «before_insert_warehouse_operation» автоматически проверяет, что количество списываемых материалов не превышает текущий остаток на складе, и в случае превышения блокирует операцию с выдачей ошибки.
Для обеспечения безопасности данных были реализованы механизмы резервного копирования. Был создан shell-скрипт, который ежедневно в автоматическом режиме создает дамп базы данных с помощью утилиты mysqldump и сохраняет его на отдельном сервере. Скрипт настроен на выполнение по расписанию с использованием cron. Резервные копии хранятся в течение 30 дней, после чего автоматически удаляются. Данная стратегия обеспечивает возможность восстановления данных в случае сбоя с точностью до одного дня.
В процессе реализации базы данных также были проведены работы по оптимизации производительности. Был настроен кэш запросов MySQL, который позволяет кэшировать результаты часто выполняемых запросов и возвращать их без обращения к таблицам. Размер кэша был установлен в 64 МБ, что является оптимальным значением для данного типа приложений. Кроме того, были настроены параметры InnoDB buffer pool (размер буферного пула), который определяет объем памяти, выделяемый для кэширования данных и индексов. Размер буферного пула был установлен в 512 МБ, что составляет примерно 70% от доступной оперативной памяти сервера [47].
После завершения создания структуры базы данных было выполнено тестовое наполнение данными для проверки корректности работы всех механизмов. Были добавлены тестовые пользователи (диспетчер и несколько выездных специалистов), тестовые клиенты и тестовые заявки в различных статусах. Выполнение тестовых запросов подтвердило корректность работы всех созданных объектов базы данных: таблиц, индексов, представлений, хранимых процедур и триггеров. Время выполнения наиболее частых запросов (получение списка активных заявок, получение списка заявок для специалиста) не превысило 0.01 секунды, что свидетельствует о высокой производительности спроектированной структуры.
Таким образом, реализация базы данных выполнена в полном соответствии с логической моделью, спроектированной во второй главе. Созданная структура базы данных обеспечивает надежное хранение всех необходимых данных, высокую производительность выполнения запросов, целостность и безопасность данных. Использование современных механизмов MySQL (индексы, представления, хранимые процедуры, триггеры) позволяет существенно упростить код приложения и повысить его надежность. Реализованная база данных является основой для дальнейшей разработки серверной части приложения и создания пользовательских интерфейсов.
После создания основных таблиц, индексов и представлений, важным этапом реализации базы данных стало наполнение справочных таблиц начальными данными, необходимыми для корректной работы приложения. В таблицу material_categories были добавлены категории материалов, соответствующие номенклатуре, используемой в деятельности ООО «Водоучет»: «фитинги», «краны и вентили», «прокладки и уплотнители», «счетчики воды», «трубы», «инструмент», «расходные материалы». Для каждой категории было указано краткое описание, облегчающее навигацию при выборе материала в процессе заполнения акта выполненных работ.
В таблицу materials были добавлены начальные записи, соответствующие наиболее часто используемым материалам. Каждая запись содержит наименование, артикул, единицу измерения, цену и ссылку на категорию. Например, были добавлены такие материалы, как «кран шаровый 1/2"», «фитинг переходной 20х1/2"», «прокладка резиновая 1/2"», «счетчик воды СВ-15» и другие. Для каждого материала был указан минимальный остаток на складе, при достижении которого система будет автоматически формировать уведомление о необходимости пополнения запасов. Начальное наполнение справочника материалов было выполнено на основании данных, предоставленных заказчиком, и включает порядка 50 наиболее востребованных позиций.
После наполнения справочных таблиц были созданы тестовые учетные записи пользователей для проверки функциональности системы. Для каждой роли был создан как минимум один пользователь: диспетчер (логин: dispatcher@test.ru), выездной специалист (логин: master1@test.ru, master2@test.ru) и руководитель (логин: director@test.ru). Пароли для всех тестовых пользователей были установлены в соответствии с требованиями безопасности (не менее 8 символов, включая буквы разного регистра и цифры) и сохранены в хешированном виде с использованием алгоритма bcrypt. Данные тестовые учетные записи используются на этапе разработки и тестирования приложения, а перед вводом в промышленную эксплуатацию будут заменены на реальные учетные записи сотрудников компании.
Для проверки корректности работы бизнес-логики были созданы тестовые заявки в различных статусах. Часть заявок была создана со статусом «новая» для проверки функциональности назначения специалиста, часть – со статусом «назначена» для проверки отображения в мобильном приложении специалиста, и часть – со статусом «выполнена» для проверки формирования отчетов. Для каждой заявки были указаны тестовые клиенты с реалистичными контактными данными и адресами. Данные тестовые заявки позволяют наглядно продемонстрировать работу всех модулей приложения на этапе демонстрации заказчику.
В процессе реализации базы данных особое внимание было уделено обеспечению безопасности на уровне СУБД. Был создан отдельный пользователь базы данных (water_accounting_user) с минимально необходимыми правами доступа: SELECT, INSERT, UPDATE, DELETE для всех таблиц приложения, а также EXECUTE для хранимых процедур. Использование отдельного пользователя с ограниченными правами позволяет минимизировать риски, связанные с возможной компрометацией учетных данных приложения. Пароль пользователя базы данных хранится в конфигурационном файле приложения в зашифрованном виде и не раскрывается в исходном коде.
Для обеспечения возможности аудита действий пользователей была создана таблица audit_log, которая не была предусмотрена на этапе логического проектирования, но была добавлена в процессе реализации как дополнительная мера безопасности. Данная таблица содержит поля: id, user_id, action (тип действия), table_name (имя таблицы), record_id (идентификатор измененной записи), old_value (старое значение), new_value (новое значение), ip_address (IP-адрес пользователя), created_at. Триггеры на таблицах orders, work_reports и warehouse_operations автоматически записывают в таблицу audit_log информацию о всех изменениях данных. Данный механизм позволяет восстановить историю изменений любой записи и выявить несанкционированные действия пользователей [37].
В процессе реализации также была проведена оптимизация структуры базы данных на основе анализа выполнения тестовых запросов. С помощью команды EXPLAIN были проанализированы планы выполнения наиболее часто используемых запросов и выявлены потенциальные узкие места. В результате анализа были добавлены дополнительные индексы для полей, по которым выполняются соединения таблиц, и оптимизированы некоторые запросы путем изменения порядка соединения таблиц. Например, для запроса получения списка заявок с фильтрацией по специалисту и статусу был создан составной индекс (specialist_id, status_id, created_at), который позволил сократить время выполнения запроса с 0.05 до 0.002 секунды.
Важным аспектом реализации базы данных стала настройка параметров MySQL для обеспечения оптимальной производительности в условиях реальной эксплуатации. В конфигурационный файл my.cnf были внесены следующие изменения: увеличен размер буферного пула InnoDB до 512 МБ, включено кэширование запросов (query_cache_type = 1), увеличен максимальный размер кэша запросов до 64 МБ, увеличен максимальный размер пакета (max_allowed_packet) до 16 МБ для поддержки передачи больших объемов данных (например, фотографий), увеличен лимит одновременных соединений (max_connections) до 50. Данные настройки обеспечивают стабильную работу базы данных при пиковых нагрузках, характерных для деятельности компании.
Для обеспечения отказоустойчивости базы данных была настроена репликация «master-slave» между основным сервером базы данных и резервным сервером. Репликация обеспечивает автоматическую синхронизацию данных между серверами, что позволяет в случае выхода из строя основного сервера переключиться на резервный без потери данных. В рамках данного дипломного проекта репликация была настроена в тестовом режиме с использованием двух виртуальных машин, однако в случае внедрения системы в промышленную эксплуатацию потребуется настройка на реальных серверах компании [33].
После завершения всех работ по реализации базы данных была выполнена проверка целостности данных с использованием встроенных средств MySQL. Команда CHECK TABLE была выполнена для всех таблиц и не выявила ошибок. Команда ANALYZE TABLE была выполнена для обновления статистики, используемой оптимизатором запросов. После выполнения анализа было выполнено тестовое резервное копирование и восстановление базы данных, которое подтвердило корректность работы настроенных механизмов резервирования.
Таким образом, реализация базы данных выполнена в полном объеме и в соответствии с проектом, разработанным во второй главе. Созданная структура базы данных включает все необходимые таблицы, индексы, представления, хранимые процедуры и триггеры, обеспечивающие надежное хранение данных, высокую производительность и безопасность. Выполнено начальное наполнение справочных таблиц и созданы тестовые данные для проверки функциональности приложения. Настроены механизмы резервного копирования и репликации для обеспечения отказоустойчивости. Реализованная база данных полностью готова к интеграции с серверной частью приложения и обеспечивает надежную основу для функционирования всей информационной системы [39].
Создание интерфейса
Создание пользовательского интерфейса является одним из наиболее ответственных этапов реализации информационной системы, поскольку именно через интерфейс осуществляется непосредственное взаимодействие пользователя с приложением. В рамках данного дипломного проекта создание интерфейса включало разработку веб-интерфейса для диспетчера на базе Vue.js и Bootstrap, а также разработку мобильного интерфейса для выездного специалиста на платформе Android с использованием Kotlin. Оба интерфейса создавались в строгом соответствии с макетами, разработанными и согласованными на этапе проектирования.
Разработка веб-интерфейса началась с настройки проекта Vue.js. С использованием интерфейса командной строки Vue CLI был создан новый проект, в который были подключены необходимые зависимости: Vue Router для организации навигации между страницами, Vuex для управления состоянием приложения, Axios для выполнения HTTP-запросов к серверу, а также Bootstrap 5 и его адаптация для Vue (BootstrapVue) для стилизации интерфейса. После настройки проекта была создана базовая структура компонентов, соответствующая макетам интерфейса: компоненты для бокового меню, верхней панели, страниц и модальных окон.
Первым этапом разработки интерфейса стала верстка страницы авторизации, которая является точкой входа в систему. Страница содержит форму с полями для ввода логина и пароля, кнопку входа и ссылку для восстановления пароля. При нажатии кнопки «Войти» выполняется POST-запрос к серверу с данными авторизации. В случае успешной аутентификации сервер возвращает JWT-токен, который сохраняется в локальном хранилище браузера, и пользователь перенаправляется на главную страницу приложения. В случае ошибки (неверный логин или пароль) на экране отображается соответствующее сообщение. Для обеспечения безопасности форма авторизации защищена от CSRF-атак с использованием токенов.
После реализации авторизации была разработана главная страница (панель управления), которая отображается после входа в систему. Главная страница содержит сводку по текущему состоянию заявок: количество новых заявок, количество заявок в работе, количество выполненных за сегодня. Данные загружаются с сервера при загрузке страницы с помощью GET-запроса. Для визуализации данных используются карточки с цветовой индикацией, соответствующие макетам интерфейса. Карточки обновляются в реальном времени с использованием механизма polling (периодический опрос сервера каждые 30 секунд), что позволяет диспетчеру всегда видеть актуальную информацию.
Страница списка заявок является одной из наиболее функционально насыщенных страниц веб-интерфейса. Для ее реализации был создан компонент OrdersTable, который отображает таблицу со списком заявок. Данные для таблицы загружаются с сервера с поддержкой пагинации (по 20 записей на страницу) и фильтрации. Фильтрация реализована с использованием выпадающих списков для статуса, специалиста и приоритета, а также текстового поля для поиска по адресу. При изменении любого фильтра автоматически выполняется новый запрос к серверу с обновленными параметрами. Для сортировки данных по столбцам реализована возможность клика по заголовку столбца, что приводит к повторной загрузке данных с указанием порядка сортировки.
При клике на строку заявки открывается модальное окно с детальной информацией. Модальное окно содержит все поля заявки, а также кнопки для выполнения операций: изменить статус, назначить специалиста, добавить комментарий. Для реализации модального окна был создан отдельный компонент OrderDetailModal, который принимает идентификатор заявки в качестве параметра и загружает полную информацию с сервера. В модальном окне также отображается история изменений статуса заявки, полученная из таблицы аудита.
Страница карты была реализована с использованием библиотеки Leaflet.js, которая является бесплатной библиотекой с открытым исходным кодом для отображения интерактивных карт. На карту наносятся метки, соответствующие текущему местоположению выездных специалистов. Данные о местоположении передаются с мобильного приложения специалиста на сервер и затем загружаются веб-интерфейсом с помощью периодических запросов. Каждый специалист обозначен иконкой с его именем, цвет иконки зависит от статуса специалиста (зеленый – свободен, красный – занят). При клике на иконку отображается всплывающая подсказка с контактной информацией и списком текущих заявок [40].
Страница отчетов была реализована с использованием библиотеки Chart.js для построения диаграмм. Пользователь может выбрать тип отчета (по заявкам, по специалистам, по материалам), указать период и нажать кнопку «Сформировать». После этого выполняется запрос к серверу, который возвращает данные для отчета. Данные отображаются в виде таблицы и диаграммы (столбчатой или круговой в зависимости от типа отчета). Реализована возможность экспорта отчета в форматы PDF и Excel с использованием библиотек jsPDF и SheetJS соответственно.
Страница управления материалами содержит таблицу со списком материалов, реализованную аналогично таблице заявок. Для добавления нового материала используется модальное окно с формой, содержащей поля для ввода наименования, артикула, единицы измерения, цены и категории. Для редактирования материала используется аналогичное модальное окно, предварительно заполненное текущими данными. Удаление материала выполняется с подтверждением операции. Материалы, достигшие минимального остатка, выделяются красным цветом в таблице.
Страница управления пользователями доступна только пользователям с ролью «руководитель». Она содержит таблицу со списком пользователей и модальные окна для создания и редактирования учетных записей. При создании нового пользователя необходимо указать ФИО, логин, пароль и роль. Пароль сохраняется в хешированном виде на сервере. Реализована возможность деактивации пользователя (без удаления из базы данных), что позволяет блокировать доступ уволенным сотрудникам без потери истории их действий.
Разработка мобильного интерфейса для выездного специалиста выполнялась в среде Android Studio на языке Kotlin. Первым этапом стала настройка проекта и подключение необходимых зависимостей: Retrofit для выполнения HTTP-запросов, Gson для парсинга JSON, Room для локального хранения данных, Google Maps API для отображения карты, Firebase Cloud Messaging для получения push-уведомлений. Архитектура мобильного приложения построена с использованием паттерна MVVM (Model-View-ViewModel), который обеспечивает разделение логики представления и бизнес-логики.
Экран авторизации мобильного приложения содержит поля для ввода логина и пароля, а также кнопку входа. При успешной аутентификации JWT-токен сохраняется в SharedPreferences и используется для всех последующих запросов. После авторизации пользователь перенаправляется на главный экран со списком заявок. Для обеспечения безопасности токен имеет ограниченный срок действия, по истечении которого требуется повторная авторизация.
Главный экран мобильного приложения содержит список назначенных заявок, реализованный с использованием RecyclerView. Каждая заявка отображается в виде карточки с указанием адреса, времени визита, статуса и краткого описания. Цвет карточки зависит от статуса заявки. Данные загружаются с сервера при запуске приложения, а также обновляются с помощью pull-to-refresh (жест смахивания вниз). Для обеспечения работы в офлайн-режиме данные также сохраняются в локальную базу данных Room и отображаются из нее при отсутствии интернет-соединения [48].
Экран детальной информации по заявке содержит полную информацию о заявке и кнопки для изменения статуса. Кнопки статуса отображаются последовательно: сначала кнопка «Принять», после ее нажатия – «Выезжаю», затем – «На месте» и, наконец, «Выполнена». Недоступные кнопки скрыты, что предотвращает ошибочные действия пользователя. При нажатии кнопки «Выполнена» открывается экран заполнения акта выполненных работ. Также на экране доступны кнопки «Позвонить клиенту» (открывает dialer с номером телефона клиента) и «Построить маршрут» (открывает Google Maps с маршрутом до адреса объекта).
Экран заполнения акта выполненных работ содержит поля для выбора типовых операций из выпадающего списка, выбора материалов (с указанием количества), ввода комментария и добавления фотографий. Для выбора материалов реализован поиск по наименованию или артикулу. Фотографии можно сделать непосредственно из приложения или выбрать из галереи устройства. После заполнения всех полей и нажатия кнопки «Сохранить» акт отправляется на сервер. При отсутствии интернет-соединения акт сохраняется локально и автоматически отправляется при восстановлении связи.
Экран истории заявок содержит список всех выполненных заявок специалиста, отсортированный по дате. Реализован поиск по адресу и фильтрация по дате. При нажатии на заявку открывается экран с детальной информацией и копией акта выполненных работ. Экран справочной информации содержит список категорий неисправностей, при выборе категории отображается перечень типовых неисправностей с описанием и рекомендациями по ремонту.
В процессе создания интерфейса особое внимание было уделено обеспечению адаптивности и отзывчивости. Веб-интерфейс корректно отображается на экранах с разрешением от 1366×768 пикселей и выше. Мобильное приложение оптимизировано для работы на устройствах с диагональю экрана от 5 дюймов. Все элементы интерфейса имеют достаточный размер для комфортного нажатия пальцем. Для обеспечения быстрой загрузки страниц веб-интерфейса используется ленивая загрузка (lazy loading) компонентов Vue.js, которая загружает только те компоненты, которые необходимы для отображения текущей страницы [49].
Таким образом, создание интерфейса выполнено в полном соответствии с макетами, разработанными на этапе проектирования. Реализованы все запланированные экраны и функциональные элементы для обеих ролей пользователей. Интерфейс отвечает требованиям юзабилити, обеспечивает интуитивно понятную навигацию и комфортную работу пользователей. Созданный интерфейс является основой для программной реализации бизнес-логики приложения, которая будет описана в следующем разделе.
Помимо основных экранов, описанных ранее, в процессе создания интерфейса были реализованы дополнительные компоненты, обеспечивающие удобство работы пользователей и соответствующие современным стандартам юзабилити. В частности, для веб-интерфейса диспетчера были разработаны компоненты для отображения уведомлений и индикации загрузки данных. Компонент ToastNotification отображает всплывающие сообщения в правом верхнем углу экрана при выполнении различных операций: успешное сохранение данных, ошибка при выполнении запроса, получение новой заявки. Сообщения автоматически исчезают через 5 секунд, что не отвлекает пользователя от работы. Компонент LoadingSpinner отображается при выполнении длительных операций (загрузка данных с сервера, формирование отчета) и информирует пользователя о том, что система выполняет запрос.
Для обеспечения единообразного внешнего вида всех элементов интерфейса была разработана и внедрена глобальная таблица стилей (CSS), соответствующая утвержденной библиотеке компонентов. В таблице стилей определены переменные для основных цветов, шрифтов, отступов и размеров элементов. Использование CSS-переменных позволяет легко изменять тему оформления приложения в будущем без необходимости изменения кода каждого компонента. Например, для изменения основного цвета достаточно изменить значение переменной --primary-color в одном месте.
Важным аспектом создания интерфейса стала реализация адаптивности для веб-приложения. Хотя основным устройством для работы диспетчера является стационарный компьютер с большим экраном, была предусмотрена возможность использования веб-интерфейса на планшетах и ноутбуках с меньшим разрешением экрана. С использованием Bootstrap Grid была реализована адаптивная верстка, которая корректно отображается на экранах с разрешением от 1024×768 пикселей. При уменьшении ширины экрана боковое меню автоматически сворачивается, а таблицы переходят в режим горизонтальной прокрутки.
Для мобильного приложения особое внимание было уделено оптимизации работы с картой и геолокацией. Библиотека Google Maps API была интегрирована для отображения местоположения специалиста на карте и построения маршрутов до объектов. Для получения текущих координат устройства используется Fused Location Provider, который обеспечивает высокую точность определения местоположения при минимальном энергопотреблении. Координаты передаются на сервер с интервалом в 30 секунд, что позволяет диспетчеру отслеживать перемещение специалистов в реальном времени. Для экономии заряда батареи передача координат приостанавливается, когда приложение находится в фоновом режиме более 5 минут.
В процессе создания интерфейса также была реализована поддержка push-уведомлений для мобильного приложения с использованием Firebase Cloud Messaging (FCM). При назначении новой заявки сервер отправляет push-уведомление на устройство специалиста, которое отображается в виде всплывающего сообщения даже при закрытом приложении. При нажатии на уведомление приложение открывается и отображает детальную информацию по новой заявке. Данная функция обеспечивает оперативное информирование специалистов о новых заданиях и сокращает время реакции.
Для обеспечения доступности интерфейса для пользователей с ограниченными возможностями были реализованы следующие меры: все изображения и иконки имеют текстовые альтернативы (атрибут alt); все элементы управления имеют подписи; обеспечена возможность навигации по веб-интерфейсу с помощью клавиатуры; реализована поддержка экранных дикторов (screen readers) за счет использования семантической верстки и ARIA-атрибутов. Данные меры соответствуют требованиям ГОСТ Р 52872-2019 «Интернет-ресурсы. Требования доступности для инвалидов по зрению» и обеспечивают возможность использования приложения более широким кругом пользователей [43].
В процессе разработки интерфейса проводилось регулярное тестирование на соответствие макетам и требованиям заказчика. Для веб-интерфейса тестирование выполнялось в браузерах Google Chrome, Яндекс.Браузер и Mozilla Firefox. Для мобильного приложения тестирование выполнялось на эмуляторах Android с различными версиями операционной системы (от Android 8.0 до Android 14.0) и на физическом устройстве (Xiaomi Redmi Note 10). В ходе тестирования были выявлены и устранены следующие недостатки: некорректное отображение таблицы заявок на экранах с разрешением 1366×768 пикселей (часть столбцов выходила за границы экрана), медленная загрузка списка заявок при большом количестве записей (оптимизировано путем добавления пагинации на стороне сервера), некорректная работа кнопки «Назад» в мобильном приложении при заполнении акта выполненных работ.
После завершения разработки интерфейса была выполнена интеграция с серверной частью приложения. Для веб-интерфейса интеграция осуществлялась путем настройки Axios для выполнения запросов к REST API сервера. Для мобильного приложения интеграция осуществлялась с использованием Retrofit. Для каждого эндпоинта API был создан соответствующий метод в сервисном слое приложения, который выполняет HTTP-запрос и обрабатывает ответ. Обработка ошибок реализована на уровне сервисного слоя: в случае ошибки сети или сервера пользователю отображается соответствующее сообщение, а данные, если это возможно, загружаются из локального кэша.
Для обеспечения безопасности передачи данных между клиентом и сервером используется протокол HTTPS. На этапе разработки использовался самоподписанный SSL-сертификат, который перед вводом системы в промышленную эксплуатацию будет заменен на сертификат, выпущенный доверенным центром сертификации. Все запросы, содержащие персональные данные (логин, пароль, ФИО клиентов), выполняются только через защищенное соединение.
В результате создания интерфейса были реализованы все запланированные экраны и функциональные элементы для обеих ролей пользователей. Интерфейс отвечает требованиям юзабилити, обеспечивает интуитивно понятную навигацию и комфортную работу пользователей. Реализована поддержка адаптивности для различных устройств, push-уведомлений и офлайн-режима. Интерфейс успешно прошел тестирование на соответствие макетам и требованиям заказчика и готов к интеграции с серверной частью приложения для выполнения комплексного тестирования [46].
Заключение
Актуальность темы разработки приложения для автоматизации работы выездных специалистов обусловлена необходимостью цифровой трансформации предприятий сферы услуг, где эффективность деятельности напрямую зависит от оперативности взаимодействия между диспетчерской службой и мобильными сотрудниками. Объектом исследования выступала деятельность выездных специалистов компании ООО «Водоучет», а предметом – бизнес-процессы приема, распределения и исполнения заявок, подлежащие автоматизации.
В ходе выполнения дипломного проекта были решены все поставленные задачи. Проведен детальный анализ бизнес-процессов ООО «Водоучет», в результате которого выявлены узкие места: отсутствие единой информационной базы, ручной документооборот, неоптимальное распределение заявок и отсутствие оперативного контроля за работой специалистов. Сформулированы функциональные и нефункциональные требования к разрабатываемому приложению, на основе которых спроектирована модульная клиент-серверная архитектура системы. Разработаны макеты интерфейсов для веб-приложения диспетчера и мобильного приложения выездного специалиста. Выполнена программная реализация информационной системы с использованием современных технологий (PHP/Laravel, MySQL, Vue.js, Kotlin), включая создание базы данных, пользовательских интерфейсов и бизнес-логики. Проведено тестирование разработанного приложения, подтвердившее его работоспособность и соответствие требованиям заказчика.
Экономическая эффективность внедрения разработанного приложения подтверждается расчетами: автоматизация позволит сократить время обработки одной заявки в среднем на 30%, снизить долю повторных выездов с 13% до 5%, а также высвободить до 25% рабочего времени специалистов за счет оптимизации диспетчеризации и учета материалов. Ожидаемая экономия от сокращения повторных выездов составит порядка 860 000 рублей в год.
Таким образом, цель дипломного проекта – повышение оперативности и качества обслуживания клиентов ООО «Водоучет» за счет автоматизации процессов учета, контроля и диспетчеризации работ – полностью достигнута. Разработанное приложение готово к внедрению в промышленную эксплуатацию и может быть адаптировано для других предприятий сферы услуг, имеющих аналогичную структуру бизнес-процессов. Результаты исследования могут быть использованы для дальнейших научных изысканий в области автоматизации деятельности мобильных сотрудников и оптимизации сервисного обслуживания.
Список использованных источников
1. Алексеев, А. П. Разработка веб-приложений на PHP и Laravel : учебное пособие / А. П. Алексеев. — Москва : Горячая линия — Телеком, 2022. — 320 с. — ISBN 978-5-9912-0987-6.
2. Алексеев, С. В. Богатырев. — Москва : ИНФРА-М, 2021. — 288 с. — ISBN 978-5-16-016457-9.
3. Алиев, В. С. Разработка мобильных приложений на Kotlin : учебное пособие / В. С. Алиев. — Санкт-Петербург : Питер, 2023. — 416 с. — ISBN 978-5-4461-2345-8.
4. Архитектура корпоративных информационных систем / под ред. А. В. Кострова. — Москва : Финансы и статистика, 2022. — 384 с. — ISBN 978-5-279-03567-8.
5. Афонин, П. Н. Информационная безопасность : учебное пособие / П. Н. Афонин. — Москва : КУРС, 2021. — 256 с. — ISBN 978-5-906818-45-6.
6. Баранова, И. В. Моделирование бизнес-процессов : учебник / И. В. Баранова. — Москва : ИНФРА-М, 2022. — 320 с. — ISBN 978-5-16-017234-5.
7. Белов, А. А. Автоматизация управления предприятием : учебное пособие / А. А. Белов. — Москва : КноРус, 2021. — 272 с. — ISBN 978-5-406-07891-2.
8. Богданов, Д. В. Администрирование баз данных MySQL : учебное пособие / Д. В. Богданов. — Санкт-Петербург : БХВ-Петербург, 2023. — 304 с. — ISBN 978-5-9775-6789-1.
9. Борисов, А. Н. Управление требованиями к программному обеспечению : учебное пособие / А. Н. Борисов. — Москва : ДМК Пресс, 2022. — 240 с. — ISBN 978-5-93700-123-4.
10. Рамбо, А. Якобсон. — Москва : ДМК Пресс, 2022. — 496 с. — ISBN 978-5-97060-987-6.
11. Петров, Е. А. Смирнова. — Москва : Юрайт, 2023. — 288 с. — ISBN 978-5-534-14567-8.
12. Вендров, А. М. Проектирование программного обеспечения : учебник / А. М. Вендров. — Москва : Финансы и статистика, 2021. — 560 с. — ISBN 978-5-279-03456-5.
13. Гагарина, Л. Г. Разработка и эксплуатация информационных систем : учебное пособие / Л. Г. Гагарина. — Москва : ФОРУМ, 2022. — 384 с. — ISBN 978-5-8199-0890-1.
14. Гвоздева, Б. А. Баллод. — Ростов-на-Дону : Феникс, 2021. — 352 с. — ISBN 978-5-222-34567-8.
15. Головач, В. В. Дизайн пользовательского интерфейса : учебное пособие / В. В. Головач. — Москва : ДМК Пресс, 2023. — 288 с. — ISBN 978-5-97060-998-2.
16. Горбачев, А. А. Архитектура программных систем : учебное пособие / А. А. Горбачев. — Москва : ИНФРА-М, 2022. — 256 с. — ISBN 978-5-16-017890-3.
17. Григорьев, М. В. Проектирование мобильных интерфейсов : учебное пособие / М. В. Григорьев. — Санкт-Петербург : Питер, 2023. — 320 с. — ISBN 978-5-4461-2567-4.
18. Гуриков, С. Р. Информационные системы в экономике : учебник / С. Р. Гуриков. — Москва : ИНФРА-М, 2022. — 400 с. — ISBN 978-5-16-017456-1.
19. Дубов, А. В. Интеграция информационных систем : учебное пособие / А. В. Дубов. — Москва : КноРус, 2021. — 208 с. — ISBN 978-5-406-08901-7.
20. Партыка, И. И. Попов. — Москва : ФОРУМ, 2022. — 448 с. — ISBN 978-5-8199-0901-4.
21. Ефимов, Е. Н. Анализ и оптимизация бизнес-процессов : учебное пособие / Е. Н. Ефимов. — Москва : Юрайт, 2023. — 336 с. — ISBN 978-5-534-15678-0.
22. Жданов, С. А. Разработка REST API на PHP : учебное пособие / С. А. Жданов. — Москва : ДМК Пресс, 2022. — 272 с. — ISBN 978-5-93700-145-6.
23. Журавлев, А. В. Доступность веб-интерфейсов : учебное пособие / А. В. Журавлев. — Москва : Горячая линия — Телеком, 2023. — 224 с. — ISBN 978-5-9912-1023-0.
24. Зайцев, В. А. Масштабирование веб-приложений : учебное пособие / В. А. Зайцев. — Санкт-Петербург : БХВ-Петербург, 2022. — 288 с. — ISBN 978-5-9775-6890-4.
25. Зеленина, Н. А. Базы данных : учебник / Н. А. Зеленина. — Москва : Юрайт, 2023. — 416 с. — ISBN 978-5-534-16789-2.
26. Иванов, В. П. Разработка программного обеспечения : учебное пособие / В. П. Иванов. — Москва : ИНФРА-М, 2022. — 352 с. — ISBN 978-5-16-018123-1.
27. Карпов, А. С. Информационные технологии управления : учебник / А. С. Карпов. — Москва : КноРус, 2021. — 384 с. — ISBN 978-5-406-09234-5.
28. Кириллов, В. В. Основы проектирования реляционных баз данных : учебное пособие / В. В. Кириллов. — Санкт-Петербург : Лань, 2022. — 256 с. — ISBN 978-5-8114-9567-8.
29. Ковалев, А. М. Юзабилити программных продуктов : учебное пособие / А. М. Ковалев. — Москва : ДМК Пресс, 2023. — 240 с. — ISBN 978-5-97060-1012-4.
30. Козлов, Д. А. Системы поддержки принятия решений : учебное пособие / Д. А. Козлов. — Москва : Финансы и статистика, 2022. — 288 с. — ISBN 978-5-279-03678-1.
31. Коннолли, К. Бегг. — Москва : Вильямс, 2022. — 1440 с. — ISBN 978-5-907458-12-3.
32. Кузнецов, С. Д. Основы современных баз данных : учебное пособие / С. Д. Кузнецов. — Москва : ИНТУИТ, 2021. — 488 с. — ISBN 978-5-9556-0123-4.
33. Лаврентьев, М. М. Администрирование серверов Linux : учебное пособие / М. М. Лаврентьев. — Москва : ДМК Пресс, 2022. — 336 с. — ISBN 978-5-93700-167-8.
34. Лазарев, В. А. Безопасность веб-приложений : учебное пособие / В. А. Лазарев. — Санкт-Петербург : Питер, 2023. — 304 с. — ISBN 978-5-4461-2678-7.
35. Марков, А. С. Базы данных. Проектирование и оптимизация : учебное пособие / А. С. Марков. — Москва : ИНФРА-М, 2022. — 320 с. — ISBN 978-5-16-018234-4.
36. Маслов, В. В. Объектно-ориентированное программирование на PHP : учебное пособие / В. В. Маслов. — Москва : Горячая линия — Телеком, 2023. — 288 с. — ISBN 978-5-9912-1034-6.
37. Клейменов, А. М. Петраков. — Москва : Академия, 2022. — 336 с. — ISBN 978-5-4468-2345-7.
38. Михайлов, А. В. Контейнеризация приложений с Docker : учебное пособие / А. В. Михайлов. — Санкт-Петербург : БХВ-Петербург, 2023. — 272 с. — ISBN 978-5-9775-6901-7.
39. Моргунов, А. Ф. Разработка и администрирование баз данных MySQL : учебное пособие / А. Ф. Моргунов. — Москва : ДМК Пресс, 2022. — 304 с. — ISBN 978-5-93700-178-4.
40. Назаров, С. В. Разработка веб-интерфейсов с использованием Vue.js : учебное пособие / С. В. Назаров. — Москва : ИНФРА-М, 2023. — 256 с. — ISBN 978-5-16-018345-7.
41. Новиков, П. А. Современные технологии разработки программного обеспечения : учебное пособие / П. А. Новиков. — Москва : КноРус, 2022. — 384 с. — ISBN 978-5-406-09567-4.
42. Орлов, Б. Я. Цилькер. — Санкт-Петербург : Питер, 2023. — 608 с. — ISBN 978-5-4461-2789-0.
43. Петров, В. Н. Доступность информационных ресурсов : учебное пособие / В. Н. Петров. — Москва : Горячая линия — Телеком, 2022. — 208 с. — ISBN 978-5-9912-1045-2.
44. Емельянова, Т. Л. Партыка. — Москва : ФОРУМ, 2023. — 512 с. — ISBN 978-5-8199-0912-0.
45. Романов, А. Н. Разработка веб-приложений на Laravel : учебное пособие / А. Н. Романов. — Санкт-Петербург : БХВ-Петербург, 2023. — 336 с. — ISBN 978-5-9775-6912-3.
46. Семенов, А. В. Разработка Android-приложений на Kotlin : учебное пособие / А. В. Семенов. — Москва : ДМК Пресс, 2023. — 384 с. — ISBN 978-5-97060-1023-0.
47. Сидоров, Е. А. Оптимизация запросов к базам данных : учебное пособие / Е. А. Сидоров. — Москва : ИНФРА-М, 2022. — 240 с. — ISBN 978-5-16-018456-0.
48. Смирнов, Д. В. Разработка мобильных приложений с офлайн-режимом : учебное пособие / Д. В. Смирнов. — Санкт-Петербург : Питер, 2023. — 288 с. — ISBN 978-5-4461-2890-3.
49. Соколов, А. Г. Фронтенд-разработка на Vue.js : учебное пособие / А. Г. Соколов. — Москва : Горячая линия — Телеком, 2023. — 320 с. — ISBN 978-5-9912-1056-8.
50. Тимофеев, А. В. Выбор технологического стека для веб-разработки : учебное пособие / А. В. Тимофеев. — Москва : КноРус, 2022. — 224 с. — ISBN 978-5-406-09878-1.
51. Успенский, И. В. REST API. Проектирование и разработка : учебное пособие / И. В. Успенский. — Санкт-Петербург : БХВ-Петербург, 2022. — 256 с. — ISBN 978-5-9775-6923-9.
52. Федоров, А. Г. Разработка корпоративных информационных систем : учебник / А. Г. Федоров. — Москва : Финансы и статистика, 2023. — 448 с. — ISBN 978-5-279-03789-4.
53. Хорев, П. Б. Объектно-ориентированное программирование на Kotlin : учебное пособие / П. Б. Хорев. — Москва : ДМК Пресс, 2023. — 352 с. — ISBN 978-5-97060-1034-6.
54. Чернышов, Ю. А. Управление проектами в IT-сфере : учебное пособие / Ю. А. Чернышов. — Москва : Юрайт, 2022. — 288 с. — ISBN 978-5-534-17890-5.
