5. Этап проектирования
5.1. Проектирование бизнес-процессов
Составление реестра требований позволяет приступить к моделированию бизнес-процессов, чтобы более наглядно описать порядок проведения инвентаризации в спортивном комплексе. Были выбраны графические нотации IDEF0 и BPMN2.0, обеспечивающие проектирование процессов на верхних и нижних уровнях [9]. Верхнеуровневое моделирование дает общее понимание процесса, здесь идеально подходит IDEF0, показывающая ключевые параметры операций, в то время как детали демонстрируются с использованием низкоуровневых моделей, одной из наиболее популярных и востребованных среди которых является BPMN2.0. Проектированию подлежат процессы в состоянии «Как есть / AS-IS» и «Как будет / TO-BE», где первое задает текущий ход исполнения процесса, а второе – то, как операции будет реализовываться после имплементации программного продукта.
Итоги верхнеуровневого описания процесса проведения инвентаризации в нотации IDEF0 для состояния AS-IS показаны ниже (рис. 4). Как видно из рисунка, бизнес-процесс включает в себя три основные операции:
- подготовиться к инвентаризации;
- провести инвентаризацию;
- проанализировать результаты инвентаризации.
Для того, чтобы более подробно охарактеризовать подпроцесс верхнего уровня под названием «Подготовка к инвентаризации», декомпозируем его на три операции:
- составить список инвентаря;
- определить персонал для инвентаризации;
- подготовить список инвентаризации,
где первая описана в нотации BPMN2.0 и изображена ниже на рис. 5.
Следующий подпроцесс верхнего уровня «Провести инвентаризацию» также представим тремя операциями:
- осмотреть предметы инвентаря;
- подсчитать фактическое количество инвентаря;
- зафиксировать результаты.
Детали бизнес-операции подсчета фактического количества инвентаря показаны на рис. 6.
И, наконец, декомпозиция последнего процесса верхнего уровня «Анализ результатов инвентаризации» дает такие операции в AS-IS, как:
- проверка имеющихся данных об инвентаре;
- сверка фактических данных с учетными;
- выявление несоответствий.
Моделирование процессов в состоянии AS-IS позволяют выявить «узкие места» в выполняемых операциях, предпринять корректирующие действия и сформировать картину TO-BE, лишенную идентифицированных недостатков. На рис. 7 показана модель TO-BE для верхнеуровневого описания процесса инвентаризации. По сравнению с рис. 4 и моделью AS-IS, при реализации бизнес-операций в TO-BE используется разрабатываемое программное обеспечение. Подобная закономерность сохраняется для подпроцессов «Провести инвентаризацию» и «Анализ результатов инвентаризации» (рис. 8-9), в то время как начальная бизнес-операция верхнего уровня «Подготовиться к инвентаризации» осталась в TO-BE без изменений.
Используя операции из приведенных выше графических схем в моделях AS-IS и TO-BE, были подготовлены карты бизнес-процессов. Карта процессов отображает процесс в виде иерархического дерева, вершины которого заданы бизнес-операциями. Сквозная нумерация операций обеспечивает прослеживаемость процесса на различных уровнях декомпозиции. Анализируя сформированные карты (рис. 10-11), можно заметить, что большая часть операций в AS-IS и TO-BE совпадают, за исключением тех шагов низкого уровня, которые будут выполняться в разрабатываемой программной системе.
5.2. Моделирование таблиц баз данных
Создание структуры таблиц базы данных является важным шагом для хранения будущей информации и ее отображения в пользовательские интерфейсы программы. Дальнейшая нормализация таблиц баз данных до третьей нормальной формы исключает избыточность и противоречивость информации, а также делает базу данных гибкой в использовании [10]. Рис. 12 демонстрирует выявленные и нормализованные классы данных, справочники данных, а также ER-связи между ними.
5.3. Подготовка схемы пользовательских форм
Понимание деталей создаваемого приложения требует описания будущих пользовательских интерфейсов и взаимосвязей между ними. На рис. 13 показана схема работы веб-приложения, на которой изображена логика следования экранов для таких HTML-страниц как: главная, список инвентаря, из которой можно добавлять инвентарные позиции, а также для проведения инвентаризации, контроля ее истории и выгрузки данных в удобный отчет.
6. Этап разработки приложения
При создании приложения было использовано несколько языков программирования, включающих Python, JavaScript, HTML и CSS. Следуя спроектированной структуре приложения (рис. 13), изначально разрабатывались формы ввода данных для авторизации и/или регистрации пользователя. Для работы с имеющимся инвентарем спортивного комплекса в разделе «Инвентарь» запрограммирована форма обработки данных «Список инвентаря» (рис. 14), где пользователь может увидеть позиции товаров, а также добавить, изменить и удалить выбранные записи.
Для удобства доступна функция поиска оборудования по наименованию, категории, помещению и статусу, пиктограмма которой отображается выше списка позиций. Создание новой карточки инвентаря осуществляется из этого же экрана, требуется указать набор атрибутов, часть которых выбирается из предопределенного справочника значений...
Выходные данные, полная версия статьи
Мальцев В.К. Автоматизация инвентаризации оборудования спортивного комплекса средствами Python, JavaScript и HTML (часть 2) // Корпоративные информационные системы. – 2025. – №2 (30) – с. 28-43. – URL: https://corpinfosys.ru/archive/2025/issue-30/304-2025-30-devopsforinventory.