Курсовая работа «Подсистема контроля исполнения поручений» – образец полного проекта для студента

Актуальность задачи контроля исполнения поручений в современных организациях неоспорима. Внедрение специализированных автоматизированных систем способно повысить операционную эффективность, по разным оценкам, на 20-30% за счет снижения времени на координацию, устранения потерь информации и обеспечения прозрачности процессов. Несмотря на это, существует проблема нехватки гибких и легко интегрируемых программных решений, которые можно было бы адаптировать под уникальные бизнес-процессы конкретной компании. Большинство существующих на рынке продуктов либо избыточно сложны, либо не обладают достаточной функциональностью.

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

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

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

Определив цели и задачи, мы можем перейти к первому логическому этапу исследования — глубокому анализу предметной области.

Глава 1. Теоретические основы и анализ предметной области

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

Современный рынок программного обеспечения предлагает множество решений для управления задачами. Системы вроде Trello (вышедший в 2011 году и задавший тренды в UI/UX таск-менеджеров) и Jira завоевали огромную популярность благодаря гибкости и удобству. Сильные стороны таких систем — визуализация процессов (Kanban-доски), простота совместной работы и богатые возможности по интеграции. Однако их слабыми сторонами часто являются высокая стоимость для больших команд, избыточная сложность для простых задач контроля и необходимость в длительной настройке под специфические нужды предприятия.

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

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

Глава 2. Формирование требований и обоснование выбора технологического стека

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

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

1. Управление пользователями: Система должна поддерживать регистрацию пользователей и ролевую модель (Администратор, Руководитель, Исполнитель).
2. Управление задачами: Пользователи с соответствующими правами должны иметь возможность создавать задачи, назначать ответственных, устанавливать сроки исполнения и изменять статусы.
3. Коммуникация по задаче: Должна быть реализована возможность оставлять комментарии и прикреплять файлы к каждой задаче.
4. Система уведомлений: Пользователи должны получать уведомления о ключевых событиях (новая задача, новый комментарий, изменение статуса, приближение срока).

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

• Безопасность: Система должна обеспечивать надежное разграничение прав доступа, чтобы исполнитель не мог видеть чужие задачи, если они ему не назначены.
• Производительность: Интерфейс системы должен быть отзывчивым, а операции с базой данных — быстрыми.
• Надежность: Система должна стабильно работать в режиме 24/7 и обеспечивать сохранность данных.

Для реализации этих требований был проведен выбор технологического стека. В качестве архитектурного паттерна был выбран MVC (Model-View-Controller). Это решение обусловлено тем, что MVC идеально подходит для веб-приложений, так как строго разделяет логику обработки данных (Model), их отображение (View) и обработку пользовательского ввода (Controller), что упрощает разработку, тестирование и дальнейшую поддержку проекта.

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

Для серверной части (backend) был выбран язык программирования Python в связке с фреймворком Django. Django предоставляет мощные встроенные инструменты для быстрой разработки, включая ORM для работы с базой данных, систему аутентификации, панель администратора и шаблонизатор, что значительно ускоряет процесс создания надежного веб-приложения.

Глава 3. Проектирование архитектуры и ключевых модулей системы

3.1. Как устроена общая архитектура и модель данных

Общая архитектура системы построена в соответствии с выбранным паттерном Model-View-Controller (MVC). Это разделение логики позволяет сделать систему гибкой и масштабируемой.

• Model (Модель): Этот компонент отвечает за всю бизнес-логику и взаимодействие с базой данных. Он включает в себя описание сущностей системы (пользователи, задачи, комментарии) и правила работы с ними. В контексте Django, модели определяются как Python-классы, которые фреймворк автоматически транслирует в таблицы базы данных.
• View (Представление): Это то, что видит пользователь. Компонент отвечает за генерацию HTML-страниц и отображение данных, полученных от контроллера. В Django эту роль выполняют шаблоны, которые наполняются динамическими данными.
• Controller (Контроллер): Этот компоент является связующим звеном. Он принимает HTTP-запросы от пользователя, обращается к Модели для получения или изменения данных, а затем передает эти данные в Представление для отображения. В Django роль контроллера выполняют функции или классы-обработчики (views.py).

Фундаментом системы является ее база данных. Логическая схема (ER-диаграмма) описывает ключевые сущности и связи между ними. Для нашего проекта она включает следующие основные таблицы:

Ключевые таблицы БД:
1. Users (Пользователи): Хранит информацию о пользователях системы (ID, логин, хеш пароля, email, роль).
2. Tasks (Задачи): Основная таблица, содержащая данные о поручениях (ID, заголовок, описание, статус, срок исполнения, ID автора, ID исполнителя).
3. Comments (Комментарии): Связана с задачами и хранит историю обсуждения (ID, текст комментария, ID автора, ID задачи, дата создания).
4. Files (Файлы): Хранит информацию о прикрепленных к задачам файлах (ID, имя файла, путь на сервере, ID задачи).

Таблица Tasks связана с таблицей Users отношениями «один ко многим» через поля автора и исполнителя, а с таблицами Comments и Files — отношением «один ко многим». Такая структура обеспечивает целостность данных и позволяет эффективно выполнять запросы.

3.2. Проектирование модуля управления задачами

Модуль управления задачами является ядром всей системы. Его работа строится вокруг жизненного цикла задачи, который можно наглядно представить с помощью диаграммы бизнес-процессов (например, в нотации BPMN). Этот процесс включает несколько ключевых этапов.

Жизненный цикл задачи описывается последовательной сменой ее статусов:

1. Новая: Задача создана руководителем и назначена исполнителю, но работа над ней еще не началась.
2. В работе: Исполнитель принял задачу и приступил к ее выполнению.
3. На проверке: Исполнитель завершил работу и передал результат на проверку руководителю.
4. Завершена: Руководитель проверил и утвердил результат.
5. (Опционально) Возвращена на доработку: Руководитель нашел недостатки и вернул задачу исполнителю с комментариями.

Этот подход идеологически близок к методологии Kanban, где каждая задача проходит через определенные стадии на пути к завершению. Алгоритмически это реализовано через набор функций. Функция создания задачи принимает от пользователя заголовок, описание, срок и исполнителя, после чего создает новую запись в таблице Tasks со статусом «Новая». Функция изменения статуса проверяет права текущего пользователя и корректность перехода (например, нельзя перевести задачу из «Новой» сразу в «Завершенную»).

Механика прикрепления файлов и добавления комментариев тесно интегрирована с задачей. При добавлении комментария создается запись в таблице Comments, которая жестко связана с ID конкретной задачи. Аналогично, при загрузке файла он сохраняется на сервере, а в таблице Files создается запись с путем к нему и привязкой к ID задачи.

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

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

Ролевая модель определяет права и возможности каждого пользователя. В системе предусмотрены три основные роли:

• Администратор: Обладает полными правами. Может управлять пользователями (добавлять, удалять, изменять роли), видеть все задачи в системе и настраивать глобальные параметры.
• Руководитель: Может создавать задачи и назначать их своим подчиненным (исполнителям), просматривать и комментировать задачи внутри своего отдела, изменять их статусы и принимать выполненную работу.
• Исполнитель: Имеет наиболее ограниченные права. Может просматривать и комментировать только назначенные ему задачи, изменять их статус (например, с «Новая» на «В работе») и прикреплять файлы.

Такое четкое разграничение прав доступа является фундаментальным требованием безопасности.

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

• Создание новой задачи (уведомление получает исполнитель).
• Добавление нового комментария (уведомление получают все участники задачи).
• Изменение статуса задачи (уведомление получают автор и исполнитель).
• Приближение срока исполнения (дедлайна) за 24 часа (уведомление получает исполнитель).

Каналы доставки уведомлений могут быть двух типов: внутрисистемные (в виде иконки с колокольчиком в интерфейсе) и внешние, через отправку писем на email, указанный пользователем при регистрации.

3.4. Каким будет пользовательский интерфейс и как мы будем его тестировать

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

• Простота и интуитивность: Интерфейс не должен быть перегружен элементами. Все основные действия (создание задачи, просмотр списка) должны быть доступны в 1-2 клика.
• Консистентность: Элементы управления, цвета и шрифты должны быть единообразны на всех страницах приложения.
• Информативность: Пользователь должен всегда понимать, на какой стадии находится задача, и легко находить нужную информацию.

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

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

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

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

[Смысловой блок: Заключение]

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

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

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

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

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

• Интеграцию с внешними системами, такими как корпоративные календари (Google Calendar, Outlook).
• Разработку полноценного мобильного приложения для платформ iOS и Android.
• Внедрение элементов искусственного интеллекта для аналитики и прогнозирования рисков срыва сроков.

Список источников информации

1. Братищенко В.В. Проектирование информационных систем. — Иркутск: Изд-во БГУЭП, 2004. 84 с.
2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. — М.: Финансы и статистика, 2004. 202с.
3. Горелик О.М. Управленческий учет и анализ: [учеб. пособие для вузов по специальности «Прикладная информатика (по обл.)» и др. экон. специальностям]. — М.: КноРус, 2007. 252 с.
4. Граничин О.Н. Информационные технологии в управлении: учеб. пособие для студентов вузов, обучающихся по специальностям «Прикладная информатика (по областям) и «Менеджмент организации (по специализации «Информационный менеджмент»)». — М.: Интернет-Ун-т Информ. Технологий, 2010. 335 с.
5. Громов Ю.Ю. Информационная безопасность и защита информации: Учебное пособие. — Ст. Оскол: ТНТ, 2010. 384 c.
6. Дармилова Ж.Д. Инновационный менеджмент: Учебное пособие для бакалавров. — М.: Дашков и К, 2013. — 168 c.
7. Диго С.М. Базы данных: проектирование и использование: [Учеб. для вузов по специальности «Прикладная информатика (по обл.)»] . — М.: Финансы и статистика, 2010. 591 с.
8. Завгородний В.И. Комплексная защита в компьютерных системах. — М.: Логос; ПБОЮЛ Н.А.Егоров, 2011. 264 с.
9. Ивасенко А.Г. Информационные технологии в экономике и управлении: [учеб. пособие для вузов по специальностям «Прикладная информатика (по обл.)», «Менеджмент орг.», «Гос. и муницип. упр.»]. — М.: КноРус, 2011. 153 с.
10. Ивасенко А.Г. Информационные технологии в экономике и управлении: учеб. пособие для студентов вузов, обучающихся по специальностям «Прикладная информатика (по областям)», «Менеджмент орг.», «Гос. и муницип. упр.». — М.: КноРус, 2009. 153 с.
11. Информатика: [учеб. для вузов по специальности «Прикладная информатика (по обл.)» и др. экон. специальностям] /А. Н. Гуда [и др.] ; под общ. ред. В. И. Колесникова. — М.: Дашков и К°, 2010. 399 с.
12. Информатика: учебник для студентов вузов, обучающихся по специальности 080801 «Прикладная информатика» и другим экономическим специальностям /[В. В. Трофимов и др.] ; под ред. проф. В. В. Трофимова.-М.: Юрайт, 2010.-910 с.
13. Информационные системы и технологии в экономике и управлении: [учеб. для вузов по специальности «Прикладная информатика (по обл.)» и др. экон. специальностям] /[В. В. Трофимов и др.] ; под ред. В. В. Трофимова.-М.: Высш. образование, 2010.-480 с.
14. Информационные технологии: [учеб. для студентов вузов, обучающихся по специальности 080801 «Прикладная информатика» и др. экон. специальностям /В. В. Трофимов и др.] ; под ред. проф. В. В. Трофимова. — М.: Юрайт, 2009.-624 с.