Проектно-аналитическое обоснование и разработка автоматизированной информационной системы товарного учета (на примере ООО «Синтез-8»)

Введение: Актуальность, цели и теоретическая база проекта

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

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

Основные понятия и определения

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

Согласно ГОСТ 34.003-90, который устанавливает термины и определения для автоматизированных систем, Автоматизированная система (АС) — это система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Разрабатываемая АИС товарного учета в ООО «Синтез-8» полностью соответствует этому определению, поскольку она интегрирует программное обеспечение, базы данных и конечных пользователей (кладовщиков, менеджеров, бухгалтеров) для выполнения учетных операций.

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

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

Нормативная база создания АИС

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

Ключевым стандартом, регламентирующим процесс создания ИС, является концепция Жизненного цикла информационной системы (ЖЦ ИС). Согласно ГОСТ Р ИСО/МЭК 12207-02, ЖЦ ИС — это непрерывный процесс, начинающийся с момента принятия решения о создании системы и заканчивающийся ее изъятием из эксплуатации. Этот стандарт определяет основные процессы: приобретение, поставка, разработка, эксплуатация и сопровождение.

Особое внимание в проектной части уделяется оформлению документации. Главным документом, определяющим рамки и требования к проекту, является Техническое задание (ТЗ). ГОСТ 34.602-2020 устанавливает строгие требования к составу, содержанию и оформлению документа «Техническое задание на создание (развитие или модернизацию) автоматизированной системы». Это обеспечивает полноту, однозначность и проверяемость всех требований к разрабатываемой АИС. Дополнительно, в части разработки программного обеспечения, применяется ГОСТ 19.201-78, который регламентирует построение и оформление самого Технического задания на программу.

Системный анализ предметной области и моделирование бизнес-процессов

Системный анализ является фундаментальным этапом, который позволяет перейти от неформализованных проблем бизнеса к четким техническим требованиям. Этот процесс включает анализ текущей ситуации (AS-IS) и проектирование оптимального состояния (TO-BE).

Анализ бизнес-процессов «Как есть» (AS-IS) и выявление узких мест

На начальном этапе проводится построение модели «Как есть» (AS-IS), которая описывает текущую последовательность работ, связанных с товарным учетом в ООО «Синтез-8». Типичными процессами являются: закупка товара, его оприходование, хранение, реализация и возврат. И что из этого следует? Неэффективность процессов, выявленная на этом этапе, напрямую транслируется в потери прибыли и замороженные средства.

Типичные узкие места (Bottlenecks) в ручном или полуавтоматизированном учете:

1. Дезинтеграция данных: Использование разрозненных таблиц Excel, бумажных накладных и различных программ для разных этапов (например, одна программа для продаж, другая — для складского учета).
2. Двойной ввод: Менеджер вводит данные о приходе в 1С, а кладовщик дублирует их в складской журнал. Это — прямой источник ошибок и непроизводительных затрат времени.
3. Сложность сверки: Высокие трудозатраты на ручную инвентаризацию и сверку остатков, что приводит к задержкам в отчетности и искажению реальной картины складских запасов.
4. Задержки в оформлении возвратов: Процесс возврата товара требует множества согласований и ручной проверки документов.

Моделирование целевых бизнес-процессов «Как должно быть» (TO-BE)

Модель «Как должно быть» (TO-BE) фиксирует требуемые изменения, этапы модернизации и автоматизации, устраняя выявленные потери и повышая эффективность. Для формализации этих процессов используется нотация BPMN (Business Process Model and Notation), которая является международным стандартом и позволяет четко определить логику и последовательность действий.

В целевой модели все ключевые бизнес-процессы товарного учета (закупка, оприходование, реализация, инвентаризация) переносятся в единую АИС. Какой важный нюанс здесь упускается? Переход к TO-BE требует не только технической реализации, но и перестройки мышления персонала, поскольку новая система радикально меняет привычный порядок работы.

Процесс	Действие в AS-IS (Ручное)	Действие в TO-BE (Автоматизированное)
Оприходование	Ручной ввод данных из бумажной накладной в таблицу.	Сканирование штрихкода товара, автоматическое создание приходного ордера.
Инвентаризация	Полный пересчет, ручная сверка с журналом, длительный простой склада.	Выборочная или полная инвентаризация с использованием ТСД, автоматическая сверка с БД и формирование акта расхождений.
Сверка остатков	Запрос к бухгалтерии, поиск по нескольким источникам.	Мгновенный запрос к единой БД, получение актуальных остатков в реальном времени.

Детализация процесса оформления возврата с применением BPMN

Процесс оформления возврата товара является классическим примером сложной логики, требующей применения Исключающего шлюза (Exclusive Gateway, XOR). Этот элемент BPMN критически важен, поскольку возврат всегда имеет строго одну причину, которая определяет дальнейший путь обработки:

1. Возврат по причине дефекта (Брак): Процесс направляется на «Проверку качества», где принимается решение о ремонте, уценке или списании.
2. Возврат по причине отказа покупателя (Товар надлежащего качества): Процесс направляется на «Приемку на склад» для восстановления товарного запаса.

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

Оценка потенциальной эффективности автоматизации

Автоматизация должна приносить измеримый экономический эффект. Повышение эффективности в модели TO-BE оценивается через сокращение прямых и косвенных трудозатрат и уменьшение рисков, связанных с ошибками. Разве не ради этого мы инвестируем в технологии?

Количественные показатели:

• Снижение трудозатрат: За счет исключения двойного ввода и автоматизации инвентаризации, время, затрачиваемое персоналом на ручные операции (сверка, перенос данных), сокращается на 40-70%.
• Снижение ошибок: Автоматический контроль ввода, использование сканеров и встроенные проверки целостности данных уменьшают количество ошибок в первичных документах (накладных, актах списания) до 30-50%.

Эти метрики служат веским обоснованием инвестиций в разработку АИС, демонстрируя, что система не просто выполняет функции, но и оптимизирует операционную деятельность ООО «Синтез-8».

Обоснование требований и выбор архитектурных решений

Для создания надежной и долговечной АИС необходимо четко сформулировать требования, которые станут основой для выбора технической архитектуры.

Функциональные и нефункциональные требования к АИС

Требования к системе традиционно разделяют на две категории:

1. Функциональные Требования (ФТ): Определяют, что система должна делать (ввод, обработка, вывод данных).
   • Учет поступления и списания товаров.
   • Формирование складских и финансовых отчетов.
   • Регистрация перемещений между складами.
   • Поддержка операций инвентаризации.
   • Управление карточками товаров и контрагентов.
2. Нефункциональные Требования (НФТ): Определяют, как хорошо система это делает (качество, ограничения). Эти требования критически важны для корпоративной учетной системы и должны быть измеримы.

Нефункциональное требование	Описание и Измеримость
Производительность	Скорость обработки запроса на наличие товара не должна превышать 1 секунды при 100 одновременных пользователях.
Масштабируемость	Система должна поддерживать ежегодный рост объема данных на 30% и увеличение числа пользователей до 50 без деградации производительности.
Надежность	Обеспечение минимального времени простоя и быстрое восстановление после сбоев.
Безопасность	Разграничение прав доступа на уровне ролей (менеджер, кладовщик, администратор) и журнала аудита всех критических операций.
Эргономичность	Интуитивно понятный интерфейс, минимизирующий время обучения новых пользователей (не более 4 часов).

Метрики надежности и доступности системы

Для критически важной корпоративной системы, такой как АИС товарного учета, сбои в работе означают прямые финансовые потери (остановка продаж, невозможность отгрузки). Поэтому требуется высокий уровень Надежности и Доступности.

Надежность измеряется через Коэффициент готовности (К_г), который рассчитывается по соотношению времени наработки на отказ к общему времени (наработка + восстановление):

Кг = Tср / (Tср + Tв)

Где T_ср — среднее время наработки на отказ (MTBF), а T_в — среднее время восстановления (MTTR).

Для АИС товарного учета, работающей в режиме 24/7, требуемый уровень доступности часто устанавливается на уровне 99,99% (так называемые «Четыре девятки»).

Расчет максимально допустимого годового простоя (D) для 99,99% доступности:

Год содержит 365 x 24 x 60 = 525 600 минут.

D = (1 - 0.9999) x 525 600 минут ≈ 52.6 минут

Это означает, что суммарное годовое время простоя системы не должно превышать 52,6 минут, что накладывает жесткие требования на выбор СУБД, архитектуру резервирования и процедур восстановления.

Сравнительный анализ и обоснование выбора СУБД

Выбор СУБД является ключевым архитектурным решением. Для систем товарного учета оптимально подходит реляционная модель, гарантирующая целостность транзакций. Для проекта АИС товарного учета в ООО «Синтез-8» в качестве клиент-серверной реляционной СУБД предлагается использовать PostgreSQL.

Обоснование выбора PostgreSQL:

1. Открытый исходный код и отсутствие лицензионных платежей: Снижает общую стоимость владения (TCO).
2. Надежность и Стандарт SQL: PostgreSQL полностью соответствует стандартам SQL и славится своей отказоустойчивостью и зрелостью.
3. Поддержка MVCC (Multi-Version Concurrency Control): Это критически важный механизм, обеспечивающий высокую Масштабируемость и Производительность в условиях параллельного доступа. В системах товарного учета множество пользователей одновременно читают остатки, проводят продажи и оформляют приходы. MVCC позволяет одновременно выполняющимся транзакциям читать данные, не блокируя пишущие транзакции. Это минимизирует задержки и исключает «очереди» при выполнении операций, что напрямую влияет на удовлетворение требования к Производительности.

СУБД	Модель лицензирования	Производительность (параллелизм)	Поддержка MVCC
PostgreSQL	Свободное ПО	Высокая	Да (Критически важно для учета)
MySQL	Community / Enterprise	Средняя/Высокая	Да (частично/опционально)
MS SQL Server	Коммерческая	Высокая	Да

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

Проектирование базы данных и обеспечение транзакционной целостности

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

Концептуальное и логическое проектирование БД

Проектирование БД ведется поэтапно: от концептуальной модели (определение сущностей и связей) к логической (ER-модель) и, наконец, к физической (схема таблиц).

Ключевые сущности (ER-модель) для товарного учета:

1. Товар (GOODS): Хранит основные характеристики номенклатуры (наименование, артикул, единица измерения).
2. Склад (WAREHOUSE): Хранит информацию о местах хранения.
3. Контрагент (AGENT): Хранит данные о поставщиках и покупателях.
4. Операция (OPERATION): Базовый документ, фиксирующий движение товара (Приход, Расход, Перемещение, Инвентаризация).
5. Позиция Операции (OPERATION_ITEM): Детализация каждой операции (какой товар, в каком количестве, по какой цене).
6. Остатки (BALANCE): Сущность, предназначенная для быстрого получения актуального количества товара на конкретном складе.

Связи:

• Связь между Товар и Склад (через Остатки) — тип «многие ко многим» (M:N).
• Связь между Операция и Контрагент — «один ко многим» (1:N).
• Связь между Операция и Позиция Операции — «один ко многим» (1:N).

Логическая ER-модель, построенная с учетом нормальных форм (минимум 3NF), исключает избыточность и гарантирует непротиворечивость данных.

Физическая модель и механизмы целостности

Физическая модель БД — это реализация ER-модели в среде конкретной СУБД (PostgreSQL). Она включает описание логической структуры таблиц, типов данных (например, INT, VARCHAR, NUMERIC для цен) и ограничений целостности.

Пример структуры ключевой таблицы:

Таблица	Поле	Тип данных	Ограничения	Назначение
GOODS	good_id	SERIAL (PK)	PRIMARY KEY	Уникальный идентификатор товара.
	name	VARCHAR(255)	NOT NULL, UNIQUE	Наименование товара.
	unit	VARCHAR(10)	NOT NULL	Единица измерения.
OPERATION	op_id	SERIAL (PK)	PRIMARY KEY	Идентификатор операции.
	type	VARCHAR(50)	CHECK	Тип операции (‘Приход’, ‘Расход’, ‘Возврат’).
	agent_id	INT (FK)	FOREIGN KEY (AGENT)	Ссылка на контрагента.

Обеспечение транзакционной целостности (ACID):

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

1. Атомарность (Atomicity): Транзакция должна быть выполнена целиком или не выполнена вовсе («все или ничего»). Если при списании товара со склада ��роисходит сбой до фиксации записи в журнале, вся операция откатывается, и остатки не меняются.
2. Согласованность (Consistency): Транзакция переводит БД из одного корректного состояния в другое, не нарушая ограничений (Primary/Foreign Keys, NOT NULL). Например, невозможно создать операцию списания, если указанное количество превышает текущий остаток.
3. Изолированность (Isolation): Параллельно выполняющиеся транзакции не должны влиять друг на друга. В PostgreSQL это достигается через механизм MVCC, который гарантирует, что две одновременные продажи не попытаются списать один и тот же последний товар.
4. Устойчивость (Durability): Результаты успешно завершенной транзакции должны быть сохранены в энергонезависимой памяти и остаться неизменными даже после сбоя системы (обеспечивается через журналы транзакций WAL).

Стратегический анализ аналогов и методология разработки

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

Сравнительный анализ существующих аналогов

Сравнительный анализ позволяет понять, почему разработка собственной АИС является оптимальным стратегическим решением для ООО «Синтез-8» по сравнению с покупкой готового продукта.

Ключевые российские аналоги:

1. 1С: Управление торговлей (1С:УТ): Мощное, глубоко настраиваемое решение, ориентированное на сложные, растущие бизнес-процессы.
2. «МойСклад» (SaaS): Облачный сервис, ориентированный на малый и средний бизнес, обеспечивающий быстрый старт.

Критерий	1С: УТ	«МойСклад» (SaaS)	Собственная АИС
Срок запуска (Time-to-Market)	Длительный (от 3 до 6 месяцев для кастомизации)	Минимальный (Базовая настройка 1-3 дня)	Средний (Зависит от сложности ТЗ)
Гибкость кастомизации	Высокая (требует программиста 1С)	Ограниченная (только настройки в рамках SaaS)	Максимальная (Полная адаптация под уникальные БП)
Стоимость владения	Высокая (лицензии + обслуживание)	Подписка (Прогнозируемая, но постоянная)	Единоразовые затраты на разработку + собственный персонал

Вывод анализа:

Типовое внедрение и кастомизация 1С:УТ требуют значительных временных (3-6 месяцев) и финансовых ресурсов. «МойСклад» обеспечивает минимальный срок запуска, но его ограниченные возможности кастомизации могут перестать удовлетворять уникальным бизнес-правилам ООО «Синтез-8» по мере роста компании. Преимущество собственной разработки заключается в возможности максимальной адаптации системы к уникальным бизнес-процессам предприятия, интеграции с существующим ПО и полной гибкости архитектуры для будущего развития. Собственная АИС, спроектированная с учетом требований к доступности 99,99% и механизма MVCC, обеспечит высокую надежность, недостижимую для типовых коробочных решений.

Выбор методологии и стадий разработки

Для управления процессом создания АИС необходимо выбрать подходящую методологию. Поскольку проект требует строгой документации, четкого планирования и последовательного выполнения фаз (Анализ, Проектирование, Разработка, Тестирование), целесообразно использовать подход, близкий к классической Каскадной модели (Водопад). Эта модель по своей структуре соответствует стадиям создания АС, установленным ГОСТ 34.601-90.

Стадии разработки по ГОСТ 34.601-90 (адаптировано):

1. Формирование требований: Разработка ТЗ (по ГОСТ 34.602-2020), системный анализ AS-IS/TO-BE (см. раздел 2.2).
2. Разработка концепции: Обоснование архитектурных решений, выбор СУБД, определение ЖЦ ИС.
3. Техническое проектирование: Детальное проектирование БД (ER/Физическая модель), разработка макетов интерфейсов.
4. Рабочее проектирование: Создание программного кода, разработка документации пользователя.
5. Ввод в действие: Тестирование (индивидуальное и комплексное), опытную эксплуатация и сдача системы.

Хотя «Водопад» обеспечивает строгий контроль, в реальном мире разработка может включать элементы Итеративного подхода (Agile) на стадии рабочего проектирования, чтобы обеспечить оперативное реагирование на уточнения требований и обратную связь с заказчиком (ООО «Синтез-8»). Таким образом, достигается баланс между строгостью документации и гибкостью разработки.

Заключение

Проектно-аналитическое обоснование и разработка архитектуры Автоматизированной Информационной Системы для товарного учета в ООО «Синтез-8» полностью выполнили поставленные задачи.

В результате системного анализа были формализованы ключевые бизнес-процессы, а модель TO-BE, описанная с использованием нотации BPMN и Исключающих шлюзов, обеспечила четкую логику автоматизированных операций, включая сложный процесс оформления возврата. Была доказана потенциальная экономическая эффективность проекта, выражающаяся в сокращении трудозатрат на 40-70% и снижении числа ошибок.

На основе строгих нефункциональных требований (включая необходимость достижения доступности 99,99%) было технически обосновано ключевое архитектурное решение: выбор СУБД PostgreSQL благодаря ее отказоустойчивости и поддержке механизма MVCC, критически важного для обеспечения высокой производительности при параллельном доступе к учетным данным.

Разработанная ER-модель и физическая схема базы данных, основанные на реляционном принципе, гарантируют соблюдение ACID-свойств транзакций, обеспечивая целостность всех операций товарного учета. Проект соответствует нормативной базе, установленной ГОСТ 34.602-2020 и ГОСТ 34.601-90.

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

Список использованной литературы

1. Барановская, Т. П. Информационные системы и технологии в экономике: Учебник / Т. П. Барановская и др. – 2-е изд., доп. и перераб. – Москва: Финансы и статистика, 2005. – 416 с.
2. Благодатских, В. А. Стандартизация разработки программных средств: Учебное пособие / В. А. Благодатских и др. – Москва: Финансы и статистика, 2005. – 288 с.
3. Бондарева, Г. А. Информатика / Г. А. Бондарева, Е. В. Сахарова, Л. Н. Королькова. – Ставрополь: СТИС, 2006.
4. Вендров, А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. и доп. – Москва: Финансы и статистика, 2005. – 544 с.
5. Габец, А. П. 1С: Предприятие 8.0. Простые примеры разработки / А. П. Габец, Д. И. Гончаров. – Москва: 1С-Паблишинг, 2005. – 420 с.
6. Гетия, И. Г. Безопасность при работе на ПЭВМ. – Москва: НПЦ Профессионал-Ф, 2001. – 140 с.
7. ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению. – Введ. 1978–07–01. – Текст: электронный // Инфостарт. URL: https://infostart.ru/ (дата обращения: 23.10.2025).
8. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения. – Введ. 1992–01–01. – Текст: электронный // Проектно-экспертный центр. URL: https://prj-exp.ru/ (дата обращения: 23.10.2025).
9. ГОСТ 34.602-2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. – Введ. 2020–07–01. – Текст: электронный // Закон.kz. URL: https://zakon.kz/ (дата обращения: 23.10.2025).
10. ГОСТ Р 43.0.11-2014. Информационное обеспечение техники и операторской деятельности. Базы данных в технической деятельности. Общие положения. – Введ. 2015–07–01. – Текст: электронный // ЦНТД. URL: https://cntd.ru/ (дата обращения: 23.10.2025).
11. Каймин, В. А. Информатика: Учебник. – 5-е изд. – Москва: ИНФРА-М, 2007. – 244 с.
12. Кашаев, С. М. 1С:Предприятие 8. Учимся программировать на примерах. – Санкт-Петербург: БХВ-Петербург, 2008. – 336 с.
13. Конеев, И. Информационная безопасность предприятия. – Санкт-Петербург: БХВ-Петербург, 2003. – 733 с.
14. Лугачев, М. И. Экономическая информатика: введение в экономический анализ / М. И. Лугачев и др. – Москва: Инфра-М, 2005. – 569 с.
15. Маклаков, С. В. ВРWin и ERWin. САSЕ-средства разработки информационных систем. – Москва: Диалог-МИФИ, 1999. – 455 с.
16. Мельников, В. В. Безопасность информации в автоматизированных системах. – Москва: Финансы и статистика, 2003. – 368 с.
17. Михайлов, А. В. 1С:Предприятие 7.7/8.0: системное программирование. – Санкт-Петербург: БХВ-Петербург, 2005. – 336 с.
18. Мишенин, А. И. Теория экономических информационных систем. – Москва: Финансы и статистика, 2000. – 240 с.
19. Норенков, И. П. Основы автоматизированного проектирования: Учебник для вузов. – Москва: МГТУ им. Н. Э. Баумана, 2002. – 336 с.
20. Орлов, С. Технологии разработки программного обеспечения: Учебное пособие. – 2-е ��зд. – Санкт-Петербург: Питер, 2003. – 480 с.
21. Партыка, Т. Л. Информационная безопасность. – Москва: ИНФРА-М, 2002. – 367 с.
22. Петров, В. Н. Информационные системы: учебное пособие для вузов. – Санкт-Петербург: Питер, 2002. – 688 с.
23. Радченко, М. Г. 1С: Предприятие 8.0. Практическое пособие разработчика. Примеры и типовые приемы. – Москва: 1С-Паблишинг, 2006. – 656 с.
24. Савицкая, Г. В. Анализ хозяйственной деятельности предприятия: Учебник. – Москва: Инфра-М, 2003. – 400 с.
25. Савицкий, Н. И. Экономическая информатика. – Москва: Экономистъ, 2004. – 429 с.
26. Смирнова, Г. Н. Проектирование экономических информационных систем: Учебник / Под ред. Ю. Ф. Тельнова. – Москва: Финансы и статистика, 2002. – 512 с.
27. Усиков, Т. Н. 1С:Предприятие. Эффективное программирование. – Москва: Новое знание, 2004. – 446 с.
28. Автоматизированная система: обзор главных ГОСТовских понятий. – Текст: электронный // BABOK-School. URL: https://babok-school.ru/ (дата обращения: 23.10.2025).
29. Описание бизнес-процессов Как есть (AS IS) и Как должно быть (TO BE). – Текст: электронный // Trinion. URL: https://trinion.org/ (дата обращения: 23.10.2025).
30. Нотация BPMN — что это такое и как её используют в бизнес-анализе. – Текст: электронный // Skillbox. URL: https://skillbox.ru/ (дата обращения: 23.10.2025).
31. BPMN как инструмент моделирования и анализа бизнес-процессов: кейс построения товарного каталога электронной торговой площадки. – Текст: электронный // E-Postulat. URL: https://e-postulat.ru/ (дата обращения: 23.10.2025).
32. Жизненный цикл информационной системы. – Текст: электронный // Cyberleninka. URL: https://cyberleninka.ru/ (дата обращения: 23.10.2025).
33. Лекция 2. Жизненный цикл информационных систем. – Текст: электронный // StGAU. URL: https://stgau.ru/ (дата обращения: 23.10.2025).
34. Жизненный цикл программного обеспечения. – Текст: электронный // NormDocs. URL: https://normdocs.ru/ (дата обращения: 23.10.2025).
35. Функциональные и нефункциональные требования: ключевые различия. – Текст: электронный // Scand. URL: https://scand.com/ (дата обращения: 23.10.2025).
36. Функциональные и нефункциональные требования (с примерами). – Текст: электронный // Visuresolutions. URL: https://visuresolutions.com/ (дата обращения: 23.10.2025).
37. Критерии выбора СУБД при создании информационных систем. – Текст: электронный // LRED. URL: https://lred.ru/ (дата обращения: 23.10.2025).
38. Как выбрать систему управления базами данных: сравнение лучших СУБД. – Текст: электронный // TimeWeb. URL: https://timeweb.com/ (дата обращения: 23.10.2025).
39. СУБД: что такое системы управления базами данных, виды, где используются, для чего нужны. – Текст: электронный // DIS-Group. URL: https://dis-group.ru/ (дата обращения: 23.10.2025).
40. Реляционные базы данных. – Текст: электронный // REG.Cloud. URL: https://reg.cloud/ (дата обращения: 23.10.2025).
41. Что такое ER-диаграмма и как ее создать? – Текст: электронный // Lucidchart. URL: https://lucidchart.com/ (дата обращения: 23.10.2025).
42. Сравните 1С: Розница и МойСклад — Функции и Цены 2025. – Текст: электронный // A2is. URL: https://a2is.ru/ (дата обращения: 23.10.2025).
43. Обзор программы МойСклад — настройки и интеграции сервиса для складского учета. – Текст: электронный // 1Cbit. URL: https://1cbit.ru/ (дата обращения: 23.10.2025).
44. Учет товаров: как правильно вести товароучет в магазине. – Текст: электронный // Business.ru. URL: https://business.ru/ (дата обращения: 23.10.2025).
45. Товарный учет в магазине | Разные методы и способы учета в розничной торговле. – Текст: электронный // MoySklad. URL: https://moysklad.ru/ (дата обращения: 23.10.2025).
46. Сравнение методологий разработок Waterfall и Agile. – Текст: электронный // Migra. URL: https://migra.ru/ (дата обращения: 23.10.2025).
47. Методология разработки Waterfall: принципы водопадной модели проекта, фазы и этапы, преимущества и недостатки. – Текст: электронный // Endocs. URL: https://endocs.ru/ (дата обращения: 23.10.2025).