Разработка информационной системы учета товаров на складе: структура и содержание курсовой работы

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

Глава 1. Аналитическая часть, где мы исследуем проблему и ее контекст

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

• Приемка: Сотрудники вручную сверяют фактическое количество товара с бумажными накладными, что замедляет процесс и не защищает от ошибок поставщика.
• Размещение: Товар размещается на стеллажах по усмотрению кладовщика, без фиксированной системы адресного хранения. Это приводит к долгому поиску нужных позиций.
• Комплектация и отгрузка: Сборка заказов происходит по распечатанным спискам, что регулярно вызывает ошибки, связанные с человеческим фактором (пересортица, недовложения).

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

Глава 1. Аналитическая часть, где мы изучаем существующие аналоги

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

1. Полнофункциональные WMS (Warehouse Management System): Это мощные коробочные решения, которые предлагают комплексную автоматизацию всех складских процессов. Их сильная сторона — богатый функционал, позволяющий достигать точности комплектации заказов свыше 99%. Однако их стоимость и сложность внедрения часто избыточны для малого бизнеса.
2. Модули учета в ERP-системах (Enterprise Resource Planning): Крупные системы управления предприятием часто включают складские модули. Их преимущество — глубокая интеграция с другими бизнес-процессами (финансы, закупки). Минусом является меньшая гибкость и специализация по сравнению с WMS.
3. Простые облачные сервисы: Эти решения предлагают базовый функционал по учету остатков и заказов по подписке. Они доступны по цене, но часто не поддерживают специфические процессы, например, адресное хранение.

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

Глава 2. Проектная часть, где мы формулируем требования к системе

Основой для проектирования любой системы является четко сформулированное техническое задание. Требования к нашей будущей ИС делятся на две категории: функциональные (что система должна делать) и нефункциональные (какими свойствами она должна обладать).

Функциональные требования:

• Учет запасов: Система должна обеспечивать операции прихода, расхода, списания и инвентаризации товаров.
• Управление хранением: Реализация механизма адресного хранения с возможностью присвоения уникального кода каждой ячейке стеллажа.
• Управление заказами: Функционал для создания, комплектации и отгрузки заказов клиентов.
• Генерация отчетов: Возможность формировать отчеты по остаткам товаров, движению за период и исполнению заказов.
• Управление пользователями: Наличие ролевой модели (например, кладовщик, менеджер) с разграничением прав доступа. Для визуализации этих взаимодействий на этапе проектирования могут использоваться диаграммы UML.

Нефункциональные требования:

• Надежность: Система должна обеспечивать время безотказной работы на уровне не менее 99.5%.
• Производительность: Время отклика на ключевые операции (поиск товара, создание заказа) не должно превышать 2 секунд.
• Безопасность: Все пароли пользователей должны храниться в зашифрованном виде, доступ к данным должен строго регулироваться ролевой моделью.

Глава 2. Проектная часть, где мы проектируем архитектуру базы данных

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

Логическая структура базы данных включает в себя следующие ключевые сущности:

• Products (Товары): Хранит информацию о товарных позициях.
  • id (Primary Key): Уникальный идентификатор
  • name: Наименование товара
  • sku: Артикул
  • description: Описание
• StorageLocations (Места хранения): Описывает ячейки склада.
  • id (Primary Key): Уникальный идентификатор
  • code: Уникальный код ячейки (например, ‘A-01-03’)
  • product_id (Foreign Key): Ссылка на товар в ячейке
  • quantity: Количество товара в ячейке
• Orders (Заказы): Содержит информацию о заказах клиентов.
  • id (Primary Key): Уникальный идентификатор
  • order_date: Дата создания заказа
  • status: Текущий статус (новый, в сборке, отгружен)
• Users (Пользователи): Таблица для хранения учетных данных сотрудников.
  • id (Primary Key): Уникальный идентификатор
  • username: Логин
  • password_hash: Хеш пароля
  • role: Роль пользователя (менеджер, кладовщик)

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

Глава 2. Проектная часть, где мы создаем интерфейсы и общую архитектуру

После проектирования базы данных необходимо определить общую архитектуру приложения и то, как пользователь будет с ним взаимодействовать. Для проекта выбрана классическая трехуровневая архитектура «клиент-сервер-БД». Этот выбор обусловлен ее надежностью, масштабируемостью и четким разделением логики: клиентская часть отвечает за отображение, серверная — за бизнес-логику, а СУБД — за хранение данных.

Пользовательский интерфейс (UI) проектируется в виде набора экранов (макетов), которые соответствуют основным сценариям работы. Вот примеры ключевых интерфейсов:

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

Такой модульный дизайн, где каждый экран отвечает за свою задачу, упрощает разработку и дальнейшую поддержку системы. Логику взаимодействия пользователя с этими экранами удобно визуализировать с помощью UML-диаграмм вариантов использования (Use Case), которые детально описывают все возможные сценарии.

Глава 3. Технологическая часть, где мы выбираем инструменты и пишем код

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

• Бэкенд (серверная часть): Язык программирования Python и фреймворк Django. Этот выбор обусловлен высокой скоростью разработки, наличием мощной ORM (Object-Relational Mapping) для удобной работы с базой данных и встроенными механизмами безопасности.
• База данных: PostgreSQL, как было обосновано ранее, за ее надежность и строгость данных.
• Фронтенд (клиентская часть): Библиотека React. Она позволяет создавать современные, быстрые и интерактивные пользовательские интерфейсы, что крайне важно для комфортной работы сотрудников склада.

Процесс разработки велся по методологии Agile, что позволяло итеративно создавать и тестировать функционал. В качестве примера реализации приведем упрощенную модель Django для товара:


from django.db import models

class Product(models.Model):
name = models.CharField(max_length=200, verbose_name="Наименование")
sku = models.CharField(max_length=50, unique=True, verbose_name="Артикул")
description = models.TextField(blank=True, verbose_name="Описание")

def __str__(self):
return f"{self.name} ({self.sku})"


Этот небольшой фрагмент кода демонстрирует, как с помощью Django ORM описывается структура таблицы `Products` в базе данных. Подобный подход значительно ускоряет разработку, абстрагируя программиста от написания прямых SQL-запросов.

Глава 3. Технологическая часть, где мы проверяем работоспособность системы

Разработка программного продукта немыслима без его тщательной проверки. Тестирование — это процесс, который доказывает, что система работает корректно и соответствует заявленным требованиям. В рамках курсовой работы была применена многоуровневая стратегия тестирования:

1. Модульное (Unit) тестирование: Проверка работоспособности отдельных мелких компонентов системы (функций, методов) в изоляции от остального кода.
2. Интеграционное тестирование: Проверка корректности взаимодействия нескольких модулей между собой. Например, связка «создание заказа -> списание товара со склада».
3. Ручное тестирование пользовательских сценариев: Имитация действий реального пользователя по заранее подготовленным тест-кейсам для проверки всей цепочки операций.

Пример простого тест-кейса для ручной проверки:

Название: Создание нового товара.
Шаги для воспроизведения: 1. Зайти в систему под ролью «менеджер». 2. Открыть раздел «Товары». 3. Нажать кнопку «Добавить товар». 4. Заполнить все поля (наименование, артикул). 5. Нажать «Сохранить».
Ожидаемый результат: Товар успешно создан и появился в общем списке.
Фактический результат: Соответствует ожидаемому.

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

Заключение и финальное оформление

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

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

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

1. РД 50-34.698-90
2. ГОСТ 34.601-90
3. ГОСТ 34.602-89
4. ГОСТ 19.701-90
5. РД IDEF0 2000
6. Федеральный закон № 149-ФЗ от 27.07.2006 «Об информации, информационных технологиях и о защите информации»
7. Федеральный закон № 152-ФЗ от 27.07.2006 «О защите персональных данных»
8. Постановление правительства №612 от 27.09.2007 «Об утверждении правил продажи дистанционным способом»
9. Закон РФ № 2300-1 от 7.02.92 «О защите прав потребителей»
10. Гвоздева Т.В. Проектирование информационных систем.-Москва: Феникс, 2009.-508с.
11. Фёдоров Н.В. Проектирование информационных систем на основе современных CASE технологий-Москва:МГИУ, 2008.-280с.
12. Мацяшек Л. Анализ и проектирование информационных систем с помощью UML 2.0.-Москва: Вильямс, 2008.-816 с.
13. Производительность WEB-служб. Анализ, оценка и планирование: Пер. с англ./Дэниел А. Менаске, Виргилио А.Ф., Алмейда.-СПб: ООО ДиаСофтЮП, 2003.-480 с.