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

**Как написать ВКР МУИВ на тему Разработка информационной системы управления задачами сотрудников организации**

Нужна ВКР по этой теме? Ответим за 10 минут!
Telegram: @Diplomit
Телефон/WhatsApp: +7 (987) 915-99-32, Email: admin@diplom-it.ru

Оформите заказ онлайн: Заказать ВКР МУИВ

Написание выпускной квалификационной работы (ВКР) в Московском университете имени С.Ю. Витте (МУИВ) по направлению подготовки 09.03.02 «Информационные системы и технологии» — это финальный этап, требующий решения практических задач, актуальных для современного бизнеса. Тема «Разработка информационной системы управления задачами сотрудников организации» особенно востребована в условиях роста численности компаний и повышения требований к прозрачности и эффективности внутренних процессов. Во многих организациях, включая условную компанию ООО «Корпоративные Решения», управление задачами всё ещё осуществляется через разрозненные инструменты: email, мессенджеры, Excel и бумажные планеры. Это приводит к критическим проблемам: потере задач, дублированию, отсутствию контроля за сроками исполнения и невозможности объективно оценить вклад каждого сотрудника.

Стандартная структура ВКР МУИВ требует не просто создания списка задач, а разработки комплексной системы, включающей планирование, делегирование, контроль, отчётность и интеграцию с корпоративными процессами. Этот проект объёмом 150–200 часов сочетает в себе глубокий анализ организационной структуры, проектирование сложной ИТ-системы и всестороннее экономическое обоснование. Эта статья — ваше подробное, пошаговое руководство по написанию такой ВКР. В ней вы найдёте конкретные инструкции и примеры для каждого раздела, что поможет вам понять масштаб задачи и принять взвешенное решение.

Нужна ВКР по этой теме? Ответим за 10 минут!
Telegram: @Diplomit
Телефон/WhatsApp: +7 (987) 915-99-32, Email: admin@diplom-it.ru

Оформите заказ онлайн: Заказать ВКР МУИВ

ВВЕДЕНИЕ

Назначение:

Обосновать выбор темы, сформулировать цель и задачи работы, определить объект и предмет исследования.

Содержание:

• Актуальность темы в современных условиях: В условиях высокой конкуренции на рынке труда и роста требований к операционной эффективности, прозрачное управление задачами становится ключевым фактором успеха компании. В ООО «Корпоративные Решения» отсутствие централизованной системы приводит к тому, что до 25% задач теряются или выполняются с нарушением сроков. Сотрудники тратят до 2 часов в день на поиск и уточнение задач в email и мессенджерах, что снижает общую продуктивность на 15%. Внедрение систем класса Jira или Asana экономически нецелесообразно для компании среднего размера из-за высокой стоимости лицензий и сложности внедрения.
• Объект и предмет исследования: Объектом исследования выступает управленческая деятельность в ООО «Корпоративные Решения». Предметом исследования является процесс постановки, контроля и исполнения задач сотрудниками.
• Цель и задачи работы (4-6 конкретных задач):
  1. Провести анализ существующих методик управления задачами (Agile, Scrum, Kanban, OKR) и готовых систем (Jira, Trello, Asana).
  2. Изучить текущий процесс управления задачами в ООО «Корпорнативные Решения» и выявить ключевые недостатки (фрагментация, отсутствие контроля, дублирование).
  3. Разработать архитектуру автоматизированной информационной системы управления задачами (АИСУЗ).
  4. Спроектировать и реализовать АИСУЗ с модулями: доски задач (Kanban), календаря, отчётности по KPI сотрудников, уведомлений.
  5. Обеспечить интеграцию системы с корпоративной почтой и календарём (например, Microsoft 365).
  6. Рассчитать экономическую эффективность от внедрения АИСУЗ.
• Структура работы (краткое описание глав): Работа состоит из введения, трёх основных глав (аналитической, проектной, экономической), заключения, списка литературы и приложений.

Частые ошибки и сложности:

Расплывчатая актуальность без привязки к конкретной компании и цифрам. Смешение задач по анализу бизнес-процессов и разработке ПО.

Практические рекомендации:

Начните актуальность с цифры: «В ООО «Корпоративные Решения» из-за отсутствия системы управления задачами теряется до 25% задач и снижается продуктивность на 15%...».

Примеры/шаблоны:

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

АНАЛИТИЧЕСКАЯ ЧАСТЬ

1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Анализ подразделения «Управление проектами» организации ООО «Корпоративные Решения»

1.1.1 Дерево бизнес-направлений организации

Назначение:

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

Содержание:

Дерево бизнес-направлений строится как иерархическая схема, отражающая основные линии бизнеса и их подчинённость. Для ООО «Корпоративные Решения» такая схема выглядит следующим образом. На вершине иерархии находится Генеральный директор. Ему непосредственно подчиняются два ключевых блока: 1) Операционный блок (Руководители департаментов: Маркетинг, Продажи, IT, Финансы), 2) Блок стратегического развития (Управление проектами, Планирование). Именно Управление проектами в лице Руководителя проектов и его команды является основным инициатором и координатором задач в компании, хотя задачи ставят и руководители департаментов.

Частые ошибки и сложности:

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

Практические рекомендации:

Используйте типовую, логически обоснованную структуру для компании, занимающейся консалтингом или ИТ-услугами, с 50-100 сотрудниками. Чётко укажите в пояснительном тексте, что структура является условной, но репрезентативной для данного сегмента бизнеса и соответствует общепринятым практикам в области корпоративного управления.

Примеры/шаблоны:

[Здесь приведите схему: ООО «Корпоративные Решения» → Генеральный директор → Операционный блок → Департаменты (Маркетинг, Продажи, IT, Финансы); Блок стратегического развития → Управление проектами].

1.1.2 Сопоставление бизнес-процессов и критических факторов успеха организации

Назначение:

Этот подраздел призван на научной основе доказать, что именно процесс управления задачами является приоритетным направлением для автоматизации. Для этого используется методика CSF (Critical Success Factors — Критические факторы успеха).

Содержание:

Работа строится в два этапа. На первом этапе необходимо определить ключевые критические факторы успеха (КФУ) для ООО «Корпоративные Решения». Для компании, чья деятельность напрямую связана с выполнением проектов и служебных поручений, такими факторами являются: 1) Своевременность исполнения задач, 2) Прозрачность процессов для руководства, 3) Эффективность работы сотрудников, 4) Минимизация дублирования усилий. На втором этапе составляется матрица, в которой по вертикали перечисляются ключевые бизнес-процессы, связанные с управлением: «Постановка задачи», «Делегирование задачи», «Исполнение задачи», «Контроль исполнения», «Формирование отчётности». В ячейках матрицы проставляются оценки по 5-балльной шкале, насколько каждый процесс влияет на достижение каждого КФУ. Затем подсчитывается суммарный балл для каждого процесса. Процесс «Контроль исполнения» набирает наивысший балл (18 из 20), что делает его приоритетным для автоматизации.

Частые ошибки и сложности:

Распространённая ошибка — подмена КФУ общими целями бизнеса, такими как «получение прибыли» или «рост компании». КФУ должны быть измеримыми и напрямую влиять на способность компании достигать этих целей. Другая ошибка — анализ функций отделов вместо сквозных бизнес-процессов.

Практические рекомендации:

Чётко разделяйте понятия «процесс» и «функция». Процесс — это последовательность действий, создающая ценность для бизнеса (например, «от постановки задачи до её закрытия»). Используйте методику CSF строго по её канону, чтобы ваш анализ выглядел профессионально и убедительно.

Примеры/шаблоны:

Бизнес-процесс	Своевременность	Прозрачность	Эффективность	Сумма
Контроль исполнения	5	5	4	14
Постановка задачи	4	3	5	12

1.1.3 Анализ структуры и нормативной документации подразделения

Назначение:

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

Содержание:

В рамках этого подраздела следует описать организационную структуру непосредственно Управления проектами, включая штатное расписание (Руководитель проектов, Менеджеры проектов, Аналитики). Далее необходимо проанализировать существующую нормативную базу: 1) Должностные инструкции для менеджеров проектов, которые, как правило, содержат общие фразы вроде «обеспечивает выполнение задач в срок», но не регламентируют конкретные шаги и инструменты; 2) Внутренние регламенты по постановке задач (часто это просто корпоративная инструкция по email-этикету); 3) Шаблоны отчётов для руководства, которые носят описательный и субъективный характер. Ключевой вывод должен быть следующим: существующая документация носит фрагментарный, несистемный и устаревший характер, не обеспечивает единообразия в работе и не позволяет эффективно контролировать процесс в условиях роста компании.

Частые ошибки и сложности:

Главная трудность — полное отсутствие доступа к внутренней документации реальной коммерческой компании. Это приводит к тому, что студенты либо пишут абстрактные общие фразы, либо полностью опускают этот подраздел.

Практические рекомендации:

Чётко укажите, что анализ проводится на основе типовых корпоративных регламентов и общепринятых методик управления проектами (например, PMBOK Guide). Это придаст вашему анализу достоверность и профессионализм, так как вы опираетесь на отраслевые стандарты, а не на вымышленные внутренние документы.

1.2 Моделирование бизнес-процесса

1.2.1 Моделирование "КАК ЕСТЬ"

Назначение:

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

Содержание:

Этот подраздел является одним из самых объёмных и важных в аналитической главе. Необходимо создать комплекс из четырёх взаимодополняющих моделей:

1. IDEF0 (функциональная модель): Начинаем с контекстной диаграммы (A0), которая показывает процесс «Управление задачами сотрудников» как чёрный ящик. Входами являются «Поручение от руководителя», выходами — «Исполненная задача, Отчёт». Механизмами выступают «Сотрудник, Менеджер», а управлением — «Внутренние регламенты ООО «Корпоративные Решения». Обязательна декомпозиция на диаграмму A1, которая должна содержать как минимум 4 функциональных блока: A1.1 «Формулирование и постановка задачи», A1.2 «Делегирование и уточнение задачи», A1.3 «Исполнение задачи», A1.4 «Контроль и закрытие задачи».
2. DFD (диаграмма потоков данных): Эта модель показывает, как данные (текст задачи, статус, комментарии) перемещаются между внешними сущностями (Руководитель, Сотрудник) и процессами («Поставить задачу», «Исполнить задачу»), а также где эти данные хранятся (например, в «Email-переписке», «Чатах в мессенджере»). Важно показать, что данные фрагментированы по разным хранилищам и не интегрированы в единую систему.
3. Диаграмма активностей (BPMN): Эта модель описывает последовательность действий конкретного сотрудника. Например, менеджер сначала пишет задачу в email, затем дублирует её в чат, потом ждёт выполнения, периодически уточняя статус в мессенджере, и только потом, возможно, получает отчёт. На диаграмме должны быть отражены ворота (решения: «Задача уточнена?»), параллельные потоки и таймеры (ежедневные напоминания).
4. Матрица распределения ответственности (RACI): Таблица, где по вертикали перечислены все действия процесса, а по горизонтали — роли (Руководитель департамента, Менеджер проекта, Исполнитель, Руководитель проекта). В ячейках указано: Responsible (R — кто выполняет), Accountable (A — кто утверждает), Consulted (C — кого консультируют) и Informed (I — кого информируют).

Частые ошибки и сложности:

Самые частые ошибки — это грубое нарушение синтаксиса нотаций. Например, в IDEF0 стрелки управления и входа путают местами, или в DFD процессы подключаются напрямую к другим процессам без потока данных. Критическая ошибка — отсутствие обязательной декомпозиции (A1) в IDEF0.

Практические рекомендации:

Не допускайте, чтобы диаграмма существовала сама по себе. Каждую из них необходимо сопровождать подробным текстовым описанием, поясняющим её элементы и логику взаимодействия. Например: «На диаграмме IDEF0 функция A1.2 «Делегирование и уточнение задачи» включает отправку email, дублирование в мессенджер и устные уточнения, что занимает в среднем 30 минут и приводит к путанице».

Примеры/шаблоны:

[Ссылка на рисунок 1.2 — IDEF0 диаграмма «Управление задачами (модель "КАК ЕСТЬ")»].

1.2.2 Моделирование процесса "КАК ДОЛЖНО БЫТЬ"

Назначение:

Предложить и визуализировать целевую, оптимизированную модель бизнес-процесса, которая лишена выявленных в модели «КАК ЕСТЬ» недостатков.

Содержание:

Работа в этом подразделе строится по следующему алгоритму:

1. Оценка проблемности процесса: Создаётся таблица, где для каждого выявленного недостатка (например, «Потеря задач из-за фрагментации коммуникаций») указываются три критерия: частота возникновения (в баллах от 1 до 5), влияние на бизнес (от 1 до 5), трудоёмкость устранения (от 1 до 5). Общий балл проблемности рассчитывается как сумма произведений.
2. Формулировка целей и ключевых показателей эффективности (KPI): На основе оценки формулируются измеримые цели. Например: «Сократить время на поиск и уточнение задач с 2 часов до 15 минут в день», «Обеспечить 100% учёт всех поставленных задач», «Снизить количество просроченных задач до 0%», «Повысить удовлетворённость сотрудников процессом управления задачами до 90%».
3. Создание оптимизированной модели: Строится новый комплекс диаграмм в тех же нотациях (IDEF0, DFD, BPMN, RACI), что и в модели «КАК ЕСТЬ». Ключевые изменения: все задачи ставятся и отслеживаются в единой АИС, система автоматически отправляет уведомления, предоставляет аналитику по KPI, а интеграция с почтой позволяет создавать задачи из email одним кликом.

Частые ошибки и сложности:

Часто студенты предлагают «оптимизацию» общими фразами: «сделать всё быстрее и лучше», но не поясняют, за счёт каких конкретных, измеримых изменений это будет достигнуто. Отсутствие конкретных финансовых метрик (KPI) делает модель абстрактной.

Практические рекомендации:

Используйте конкретные, признанные в индустрии методы оптимизации: 1) Централизация данных в единой АИС, 2) Автоматизация рутинных операций (уведомления, напоминания), 3) Интеграция с существующими корпоративными инструментами (почта, календарь), 4) Внедрение прозрачной системы KPI для оценки эффективности.

Примеры/шаблоны:

KPI примеры:

• Время на поиск и уточнение задач (цель: ≤ 15 минут/день)
• Процент учтённых задач (цель: 100%)
• Процент просроченных задач (цель: 0%)
• Удовлетворённость сотрудников (цель: ≥ 90%)

1.3 Анализ рынка программного обеспечения для автоматизации бизнес-процесса

Назначение:

Провести объективный обзор существующих на рынке готовых систем для управления задачами, чтобы аргументированно обосновать, почему для ООО «Корпоративные Решения» целесообразнее разработать собственное решение.

Содержание:

Необходимо проанализировать от 3 до 5 систем-аналогов. Для каждой системы следует привести:

• Производителя:
• Основной функционал:
• Стоимость:
• Сильные и слабые стороны: Оценка в контексте конкретной задачи ООО «Корпоративные Решения» (управление задачами в среднем бизнесе).

Примеры систем для анализа:

1. Jira: Мощнейшая система для IT-команд. Сильные стороны: гибкость, мощная аналитика. Слабые стороны: очень высокая стоимость (от $7.5/пользователь/месяц), сложность для нетехнических команд, избыточность функционала для общего управления задачами.
2. Asana: Универсальная платформа. Сильные стороны: удобный интерфейс, хорошая интеграция. Слабые стороны: стоимость для больших команд (от $10.99/пользователь/месяц), закрытый API, ограничения в бесплатной версии.
3. Trello: Простая доска Kanban. Сильные стороны: бесплатная базовая версия, простота. Слабые стороны: отсутствие продвинутой аналитики, слабый контроль за сроками, сложность масштабирования на большие команды.
4. Microsoft Planner (в составе Microsoft 365): Интеграция с экосистемой Microsoft. Сильные стороны: удобство для компаний на M365. Слабые стороны: упрощённый функционал, отсутствие гибких отчётов и KPI.

Частые ошибки и сложности:

Главная и самая грубая ошибка — путаница между готовыми программными продуктами (CRM, ERP, специализированные платформы) и средствами разработки (языки программирования, фреймворки). Это абсолютно разные вещи, которые рассматриваются в разных разделах (1.3 и 1.5 соответственно).

Практические рекомендации:

Сфокусируйтесь на том, чтобы чётко объяснить, почему каждая из рассмотренных систем не подходит «из коробки» для решения специфической задачи ООО «Корпоративные Решения» — управления задачами в среднем бизнесе с ограниченным бюджетом. Обязательно делайте вывод о том, что настройка готовой системы под эти нужды может обойтись дороже и быть менее гибкой, чем разработка собственного решения.

Примеры/шаблоны:

Система	Производитель	Стоимость (год, 50 пользователей)	Подходит?
Jira	Atlassian	~4 500 $	Избыточно/дорого
Asana	Asana Inc.	~6 600 $	Дорого
Собственная АИСУЗ	—	220 000 руб. (единоразово)	Да

1.4 Анализ стейкхолдеров и их требований к разрабатываемой системе

Назначение:

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

Содержание:

Список стейкхолдеров должен включать как внутренних, так и внешних участников:

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

Частые ошибки и сложности:

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

Практические рекомендации:

Используйте матрицу заинтересованных сторон, где по осям X и Y отложены «Уровень влияния на проект» и «Уровень заинтересованности в результате». Это поможет вам расставить приоритеты при сборе и реализации требований, уделяя основное внимание группам с высоким влиянием и заинтересованностью (Менеджеры, Руководитель проекта).

1.5 Выбор средств разработки

Назначение:

Обосновать выбор технологического стека, который будет использован для разработки АИСУЗ, на основе анализа требований и сравнительной оценки альтернатив.

Содержание:

Работа в этом подразделе включает три ключевых этапа:

1. Анализ существующего ПО в организации: В ООО «Корпоративные Решения» используется Microsoft 365 (почта, календарь, Teams) и Windows-серверы. Это накладывает определённые ограничения и преимущества на выбор технологий для обеспечения простой интеграции.
2. Сравнительный анализ альтернатив: Для каждого компонента стека проводится сравнительный анализ.
   • Frontend: React vs Angular vs Vue.js. React выбран за его огромную экосистему библиотек (например, для Kanban-досок — react-beautiful-dnd) и компонентную архитектуру, идеально подходящую для построения сложных интерфейсов управления задачами.
   • Backend: Python/Django vs Node.js/Express vs .NET Core. Python/Django выбран за встроенную админку, высокий уровень безопасности «из коробки» и богатую экосистему для быстрой разработки.
   • СУБД: PostgreSQL vs MySQL vs MS SQL Server. PostgreSQL выбран за надёжность, поддержку JSON-полей (для гибкого хранения метаданных задач) и отличную производительность.
3. Обоснование интеграций: Для интеграции с Microsoft 365 будет использован Graph API, который позволяет синхронизировать задачи с Outlook и календарём, а также отправлять уведомления через Teams.

Частые ошибки и сложности:

Основная ошибка — смешение этого раздела с разделом 1.3 (анализ готовых систем). Здесь речь идёт не о готовых продуктах, а о «кирпичиках» для строительства собственного решения.

Практические рекомендации:

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

1.6 Техническое задание на разработку корпоративной информационной системы

Назначение:

Формализовать все собранные в ходе анализа требования к будущей системе в виде официального документа, который будет служить основой для разработки.

Содержание:

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

• Введение (цель создания системы, основание для разработки).
• Назначение системы (цели, решаемые задачи: централизованное управление задачами, контроль сроков, аналитика по KPI).
• Требования к системе:
  • Требования к функциональным характеристикам (модули: Kanban-доска, Календарь, Отчётность по KPI, Уведомления, Интеграция с M365).
  • Требования к надёжности (доступность 99.9%, резервное копирование).
  • Требования к интерфейсу (интуитивно понятный интерфейс для нетехнических пользователей).
  • Требования к информационной и программной совместимости (интеграция с Microsoft Graph API, Windows-серверами).
• Требования к документации.
• Стадии и этапы разработки.
• Порядок контроля и приёмки системы.

Полный текст технического задания выносится в Приложение 1 к ВКР.

Частые ошибки и сложности:

Самая частая ошибка — несоблюдение структуры и формулировок, предписанных ГОСТом. Студенты часто пишут ТЗ в свободной форме, превращая его в список желаний, что является грубым нарушением требований.

Практические рекомендации:

Используйте официальный текст ГОСТ 34.602-2020 как подробный чек-лист. Каждый его подраздел должен найти своё отражение в вашем документе. Это гарантирует, что ТЗ будет принято научным руководителем.

1.7 Выводы по разделу

Назначение:

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

Содержание:

В этом подразделе необходимо кратко, но ёмко резюмировать выводы по каждому предыдущему пункту (1.1–1.6) и сделать общий, обобщающий вывод. Например: «По результатам анализа организационной структуры (п. 1.1) установлено, что в ООО «Корпоративные Решения» отсутствует единый инструмент для управления задачами. Моделирование текущего состояния "КАК ЕСТЬ" (п. 1.2.1) выявило критические проблемы: фрагментация коммуникаций приводит к потере до 25% задач. Анализ рынка готовых решений (п. 1.3) показал, что существующие системы либо слишком дороги (Jira, Asana), либо не охватывают весь необходимый функционал для управления в среднем бизнесе. Таким образом, разработка собственной автоматизированной информационной системы управления задачами является единственно верным и обоснованным решением для повышения операционной эффективности ООО «Корпоративные Решения»».

Частые ошибки и сложности:

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

Практические рекомендации:

Начинайте каждый тезис с фразы «По результатам анализа (п. 1.X)...». Это создаёт чёткую логическую связь и показывает, что выводы делаются на основе проделанной работы, а не на пустом месте.

Примеры/шаблоны:

«Анализ подтвердил неэффективность существующего фрагментированного процесса управления задачами в ООО «Корпоративные Решения». Готовые программные решения на рынке не отвечают специфике задачи управления в условиях ограниченного бюджета. Обоснована необходимость и разработана архитектура собственной АИСУЗ.»

ПРОЕКТНАЯ ЧАСТЬ

2 ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ПРОЕКТА

2.1 Структурирование требований к разрабатываемой системе

2.1.1 Логическое моделирование данных

Назначение:

Цель этого подраздела — перейти от общих требований к визуальному описанию динамического поведения будущей системы через диаграммы UML.

Содержание:

Используются следующие нотации UML:

• UseCase-диаграмма: На диаграмме отображаются акторы (роли пользователей: Исполнитель, Менеджер, Руководитель проекта, Администратор) и прецеденты (сценарии использования системы: «Поставить задачу», «Изменить статус задачи», «Сформировать отчёт по KPI», «Настроить интеграцию с почтой»). Диаграмма показывает, кто и что может делать в системе.
• Диаграмма последовательности: Описывает взаимодействие объектов системы в рамках одного конкретного прецедента. Например, на диаграмме «Поставить задачу» показано, как объект «Форма постановки задачи» передаёт данные объекту «Сервис задач», который в свою очередь сохраняет задачу в БД и отправляет уведомление через «Сервис интеграции с M365».
• Диаграмма функций: Представляет собой иерархическое дерево всех функций системы, разбитое по логическим модулям: «Модуль управления задачами», «Модуль календаря», «Модуль отчётности», «Модуль интеграций», «Модуль управления пользователями».

Частые ошибки и сложности:

Неправильное выделение акторов и прецедентов. Распространённая ошибка — описание шагов вместо целей. Например, «Нажать кнопку отправить» — это шаг, а не прецедент. Правильный прецедент: «Отправить запрос на формирование маршрута».

Практические рекомендации:

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

2.1.2 Конструирование модели данных

Назначение:

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

Содержание:

• ER-диаграмма (сущность-связь): Графическое представление сущностей (таблиц базы данных) и связей между ними. Основные сущности для данной задачи: «Пользователь», «Проект», «Задача», «Комментарий», «Файл», «Статус задачи». Важно правильно отобразить связи: например, у одного «Пользователя» может быть много «Задач» (связь один-ко-многим), а у одной «Задачи» — один «Статус» (связь многие-к-одному).
• Диаграмма классов (UML): Более детальное представление, включающее не только атрибуты сущностей, но и их методы (операции). Например, для класса «Задача» атрибуты: заголовок, описание, дедлайн, приоритет; методы: изменитьСтатус(), добавитьКомментарий(), отправитьУведомление().

Для каждой сущности необходимо дать подробное текстовое описание: перечислить все атрибуты, их типы данных (VARCHAR, DATE, INT, JSON), указать первичные и внешние ключи.

Частые ошибки и сложности:

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

Практические рекомендации:

Следуйте правилам нормализации реляционных баз данных до третьей нормальной формы (3NF). Подробно опишите каждую сущность и связь в тексте, не надейтесь, что диаграмма всё объяснит сама. Укажите, какие атрибуты являются обязательными, а какие — опциональными.

2.2 Разработка программного обеспечения

2.2.1 План разработки ПО

Назначение:

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

Содержание:

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

1. Анализ требований и проектирование архитектуры (1 неделя).
<