Проектирование системы рабочего взаимодействия сотрудников разно уровневых структурных подразделений (на примере конкретной организации).

1.1. Технико-экономическая характеристика предметной области и предприятия

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

Пример: В АО "Корпоративные системы" функционируют 5 структурных подразделений: отдел разработки, отдел сопровождения, отдел продаж, бухгалтерия и HR. Коммуникация между уровнями (от рядовых сотрудников до топ-менеджмента) осуществляется преимущественно через электронную почту и корпоративный чат, что приводит к задержкам и потере информации.

Сложности:

• Отсутствие открытых данных по предприятию — требуется моделирование реалистичного кейса.
• Необходимость связать предметную область с конкретной организацией.

Время: 10–12 часов.

1.2. Характеристика комплекса задач и обоснование необходимости автоматизации

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

Пример: Задачи включают согласование задач между отделами, контроль исполнения поручений, учёт рабочего времени. В текущих условиях отсутствует единая система отслеживания, что снижает производительность на 15–20%.

Сложности:

• Требуется чёткая формулировка проблем, подтверждённая анализом.
• Необходимо обосновать, почему именно ИС, а не другие инструменты.

Время: 8–10 часов.

1.3. Анализ существующих разработок и выбор стратегии автоматизации

Проводится обзор аналогов (например, Jira, Trello, Microsoft Teams, внутренние ERP-системы) с акцентом на их применимость в условиях АО "Корпоративные системы". Обосновывается выбор подхода: разработка с нуля, адаптация open-source или внедрение коммерческого решения.

Пример: Система Trello не подходит для иерархического контроля, а Jira слишком техническая. Решено создать собственную веб-систему на базе Django с модулями для задач, уведомлений и отчётности.

Сложности:

• Нужно найти актуальные аналоги с описанием функционала.
• Обоснование выбора требует знания архитектурных решений.

Время: 10–12 часов.

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

Определяются архитектура системы, технологии (например, Python/Django + PostgreSQL), принципы взаимодействия модулей, требования к безопасности и масштабируемости. Подчёркивается, как выбранные решения решают поставленные задачи.

Пример: Архитектура клиент-сервер, REST API, ролевой доступ. Это обеспечит гибкость при расширении функционала и защиту конфиденциальных данных.

Сложности:

• Требуется понимание современных ИТ-подходов.
• Нужно увязать технические решения с бизнес-целями.

Время: 8–10 часов.

2.1. Разработка проекта автоматизации

Создаются диаграммы (DFD, ERD, Use Case), описывается логика работы системы, сценарии взаимодействия пользователей. Учитываются роли: сотрудник, руководитель подразделения, администратор.

Пример: Диаграмма Use Case включает «Создать задачу», «Назначить исполнителя», «Получить уведомление», «Сформировать отчёт».

Сложности:

• Необходимы навыки моделирования в нотациях UML/BPMN.
• Сложно учесть все сценарии взаимодействия между уровнями.

Время: 12–15 часов.

2.2. Информационное обеспечение задачи

Описывается структура базы данных: таблицы (сотрудники, задачи, подразделения, статусы), связи, нормализация. Приводятся физическая и логическая модели.

Пример: Таблица «tasks» содержит поля: id, title, description, assignee_id, department_id, status, deadline.

Сложности:

• Требуется знание проектирования БД.
• Нужно обеспечить целостность и безопасность данных.

Время: 8–10 часов.

2.3. Программное обеспечение задачи

Приводятся фрагменты кода, описывается архитектура ПО, выбор фреймворков, реализация модулей (аутентификация, управление задачами, уведомления).

Пример: Модуль уведомлений реализован через Celery и Redis, отправка email через SMTP-сервер.

Сложности:

• Нужно писать корректный и документированный код.
• Сложно интегрировать разные компоненты системы.

Время: 15–20 часов.

2.4. Контрольный пример реализации проекта и его описание

Демонстрируется работа системы на примере реального сценария: например, руководитель отдела разработки создаёт задачу для программиста, назначает срок, система отправляет уведомление, отслеживает выполнение.

Пример: Скриншоты интерфейса, лог выполнения, результат — снижение времени согласования на 30%.

Сложности:

• Требуется прототип или работающая демо-версия.
• Нужно чётко связать пример с целями проекта.

Время: 10–12 часов.

3.1. Выбор и обоснование методики расчёта экономической эффективности

Выбирается метод (например, по ГОСТ 34.601-90 или методика Синергии), обосновывается выбор показателей: трудоёмкость, затраты на разработку, годовой экономический эффект.

Пример: Используется метод расчёта по формуле: Э = (Тб – Тн) × Сч × N – З, где Т — время на задачу, Сч — часовая ставка, N — количество задач, З — затраты на разработку.

Сложности:

• Нужно знать методики расчёта, принятые в вузе.
• Сложно подобрать реалистичные цифры.

Время: 6–8 часов.

3.2. Расчёт показателей экономической эффективности проекта

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

Пример: Затраты на разработку — 250 тыс. руб., годовая экономия — 420 тыс. руб., срок окупаемости — 7 месяцев.

Сложности:

• Требуется точность в расчётах.
• Нужно обосновать все цифры.

Время: 8–10 часов.

Если после прочтения вы осознали, что самостоятельное написание отнимет слишком много сил, или вы просто хотите перестраховаться — обращение к нам является взвешенным и профессиональным решением. Мы возьмём на себя все технические сложности, а вы получите готовую, качественную работу и уверенность перед защитой.