Курсовая работа - Ant0nRudenk0/rudenko.github.io GitHub Wiki
Курсовой проект по дисциплине "Проектирование информационных систем"
Руденко А.О., ИДБ-17-07
1. Определение требований к модели ✋
Тема ВКР: Разработка автоматизированной информационной системы для формирования документов для корпоративной печати на промышленном предприятии
Объект исследований: процессы документооборота организации.
Предмет исследований: средства информационной поддержки процессов документооборота и корпоративной печати промышленного предприятия.
Процессы верхнего уровня: ✋
- А1 Управление конфигурацией
- А2 Подготовка информации для документа
- А3 Составить документ
- А4 Контроль исполнения документа
Точка зрения: Руководитель отдела делопроизводства
Цель моделирования: Формирование документов
2. Функциональное моделирование процессов (IDEF0) ✋
Диаграмма A0

Диаграмма A1-A4

Диаграмма A11-A13

Диаграмма A21-A23

Диаграмма A31-A33

Диаграмма A41-A43

3. Функциональное моделирование программных и информационных средств (DFD) ✋
Конфигурация технических средств: ПК и 1С.
Конфигурация программных средств: Многоуровневые.
Допустимые виды хранилищ и их размещение: ПО и файлы форматов .docx и .pdf.
Автоматизация процесса А33

4. Описание выбранного процесса ✋ в формате прецедента (Use Case) ✋
Диаграмма UML Use Case
4.1 Идентификатор прецедента: А3
4.2 Название прецедента: Составить документ
4.3 Контекст: Составление документа на предприятии
4.4 Участники (actors) и цели (goals):
| Участник | Категория | Цель (goal) |
|---|---|---|
| Сотрудник | Основной | Просмотреть и ввести данные |
| Администратор | Основной | Проконтролировать и настроить ИС, управлять данными |
| Руководитель отдела делопроизводства | Внешний | Сформировать параметры обработки данных |
| Информационная система | Инструмент | Предоставить средства обработки данных |
4.5 Предусловия (pre-conditions):
-
Условие наличия потока управления: Входные данные для обработки
-
Условие наличия входного потока: Минимальный набор данных о сотруднике
-
Условие наличия потока исполнителя: Сформированные руководителем отдела параметры обработки
-
Условие наличия потока механизма: Информационная система
4.6 Постусловия (post-conditions):
- Выходной поток: Обработанные данных, документы
4.7 Основной поток выполнения (main flow):
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| Сотрудник | Авторизируется | Наделение пользователя правами |
| Сотрудник | Вводит данные, вводит параметры | Поступление данных в систему |
4.8 Исключения (exceptions):
| Условие (риск) | Последствия | Реакция |
|---|---|---|
| Ввод некорректных данных | Сбой в работе системы | Уведомить сотрудника о неправильности введенных данных |
| Отсутствие минимального набора данных сотрудника | Невыполнимость обработки данных | Обратиться к администратору для получения данных |
| Сбой в работе оборудования | Потеря данных сотрудников | Выяснение причины сбоя и восстановление данных |
4.9 Альтернативы (alternates):
| Участник | Действие (activity) | Ожидаемый результат |
|---|---|---|
| Администратор | Ввод дополнительных вычислительных мощностей | Стабильная работа системы |
4.10 Временные параметры:
-
Триггер (событие, стартующее прецедент): Обращение пользователя
-
Номинальная частота повторения прецедента: 25 раз в сутки
-
Продолжительность прецедента: 10 минут
5. Описание структуры объекта ✋ в формате ERD (Class) ✋
-
Описываемый объект: описание потоков, ролей, модулей
-
Диаграмма UML Class:
ER-диаграмма потоков
ER-диаграмма ролей
ER-диаграмма модулей
6. Описание алгоритма ✋ в формате UML (Sequence) ✋
-
Описываемые процессы и потоки данных: А33 Сформировать документ
-
Диаграмма UML Sequence:
7. Описание состава ✋ в формате UML (Component) ✋
-
Описываемый объект: структура программных средств системы
-
Диаграмма UML Component:
8. Демонстрация реализации (личная страница)
Личная страница на Github
9. Подготовка к интерпретации построенных моделей
9.1 Используемые паттерны проектирования и разработки ✋:
- Процессная модель для сравнения:
Задача: необходимо повысить эффективность работы систем документооборота и делопроизводства
Решение задачи при помощи методологии PDCA:
- Этап Plan(Планирование):
Выявленные проблемы: чрезмерные затраты времени на обработку данных
Цель: оптимизировать временные затраты на обработку данных
Требования: повысить эффективность без увеличения количества сотрудников
Ожидаемый результат: повышение эффективности на обработку данных
Ресурсы, необходимые для достижения ожидаемого результата: 1С
Процессы (запланированные действия):
-
анализ существующих систем
-
разработка системы
-
Этап Do(Выполнение): Команда программистов выполняет запланированные действия.
-
Этап Check(Проверка): Оценка эффективности новой программы обработки и поиск ошибок.
-
Этап Act(Улучшение): Доработка программы на основе оценки. Исправление ошибок.
- Используемые в разработке паттерны и фреймворки:
Паттерн: "Цепочка обязанностей"
9.2 Используемые паттерны выявления проблем ✋:
- Муда: огромный поток документов к одному сотруднику, который приводит к увеличению длительности обработки
- Мура: выполнение мелких поручений, откладываю важные напоследок
- Мури: переработка сотрудника для выполнения всех обязанностей
9.3 Возможные антипаттерны ✋:
| Категория | Антипаттерн (риск) | Действие по избежанию |
|---|---|---|
| Разработка | Ненужная сложность | Не усложнять проект тогда, когда этого не требуется, придерживаться принципа "проще - лучше" |
| Архитектура | Квадратное колесо | Перед выполнением задачи провести поиск и анализ существующих аналогичных систем и их решений |
| Организация | Расползание рамок | Держать под контролем масштабы проекта |
| Среда | Автономный коллектив | Усилить влияние руководства |
10. Интерпретация построенных моделей
10.1 Определение числовых показателей для поставленной цели моделирования:
Стандарт цели: определение процессов требующих повышения качества.
Способ получения: извлечение из диаграмм IDEF0 и DFD.
10.2 Определение числовых показателей для цели потенциального проекта автоматизации: ✋
Сотрудник на составление документа тратит, в среднем, 30 минут. За 8-ми часовой рабочий день, в среднем, сотрудник выполняет 25 обращений. Это занимает 12,5 часов, что подразумевает, что сотруднику не хватит рабочего времени для обработки всех обращений. Поэтому стоит оптимизировать работу при помощи внедрения информационной системы.
10.3 Расчет потенциального эффекта от автоматизации:
Проведем расчет долгосрочной экономии времени от реализации проекта: при наличии 5 сотрудников и при работе в одну смену продолжительностью 8 часов, ежемесячная экономия времени составит 4,17/8 * 5 = 2,6 чел/мес.
Расчет найденных ресурсов за счет экономии времени: после автоматизации затрачиваемое время сократилось в 3 раза, т.к. смена равна 8 часам, делаем вывод, что появилось 5 «свободных» часов. За эти 5 часов один сотрудник может составить еще 30 документов. Для всех сотрудников получается следующий результат: 5 * 30 = 150 дополнительно составленных документов в день за счет экономии времени.
Расчет возможности сокращения штата за счет экономии времени: Возникает возможность сократить штат сотрудников с учетом сохранения трудоемкости до 3 человек.
Таким образом, внедрение данной системы позволяет снизить время, затрачиваемое при работе с данными, уменьшить количество персонала, необходимое для успешной работы предприятия.
10.4 Определение числовых показателей и расчет трудозатрат на разработку программных средств:
Расчет сложности разработки методом FPA IFPUG:
Расчет трудозатрат на разработку «с нуля» методом COCOMO II:
ВЫВОДЫ
Исходя из значений, полученных методом COCOMO II, можно сделать вывод что при средних навыках программистов данная система является экономически выгодной и может быть реализована с помощью 2 человек за 4 месяца. Однако, эти значения необходимо интерпретировать с учетом реальной деятельности, поскольку указанные расчеты включают не только саму разработку, но и документирование + тестирование, причем, разработка подразумевалась строго с нуля (без использования CASE-средств, фреймворков, готовых библиотек и открытого программного обеспечения).
Так как при разработке использовалось CASE-средство (1С) и нет необходимости в затратах ресурсов на разработку документации, то реализация может быть выполнена за более сжатые сроки и при меньшем количестве людей (1 месяц и 1 человек).
Стоит отметить, что на данных момент готовность проекта составляет 40 процентов, поэтому выполнение ВКР в срок осуществимо.