Повышение эффективности управления и контроля задач
Автор работы: Пользователь скрыл имя, 20 Марта 2013 в 21:08, курсовая работа
Описание работы
В настоящее время, современный рынок программного обеспечения для
решенияописаннойпроблемыпредлагаетнесколько вариантов,к основнымизкоторых
можноотнестиследующиесистемы:
1) Конфигурация «Управление задачами персонала» для «1С: Предприятие
8.1».
2) СистемаэлектронногодокументооборотаDirectum.
3) ОнлайнинструментдляуправленияподчиненнымиМегаплан.
Содержание работы
ВВЕДЕНИЕ............................................................................................................................................2
1 РазработкаIDEF0моделиуправлениязадачами.................................................................4
2 Анализсуществующихрешений...........................................................................................10
3 Требованияксистеме................................................................................................................12
4 Диаграммыпрецедентовсистемы.........................................................................................13
5 Диаграммаклассованализа.....................................................................................................27
6 Диаграммасостояний................................................................................................................30
ЗАКЛЮЧЕНИЕ................................................................................................................................32
СПИСОКИСПОЛЬЗОВАННЫХИСТОЧНИКОВ......
Файлы: 1 файл
1
СОДЕРЖАНИЕ
ВВЕДЕНИЕ............................................................................................................................................2
1 РазработкаIDEF0моделиуправлениязадачами.................................................................4
2 Анализсуществующихрешений...........................................................................................10
3 Требованияксистеме................................................................................................................12
4 Диаграммыпрецедентовсистемы.........................................................................................13
5 Диаграммаклассованализа.....................................................................................................27
6 Диаграммасостояний................................................................................................................30
ЗАКЛЮЧЕНИЕ................................................................................................................................32
СПИСОКИСПОЛЬЗОВАННЫХИСТОЧНИКОВ..........................................................33
ПРИЛОЖЕНИЕ1...............................................................................................................................34
2
ВВЕДЕНИЕ
Проблема контроля задач является актуальной для всех организаций.
Сотрудникам ставятся поручения, которые необходимо выполнять в срок. Задачи могут
различаться по важности и сложности. Сложные задачи могут делиться на множество
подзадач. При критическом количестве задач всегда существует вероятность потери
начальником контроля над задачами, сложно отследить и проверить работу
сотрудников. Сотрудники в свою очередь часто пользуются этим и не соблюдают
правила при исполнении своих служебных обязанностей. Перечисленные причины, а
также по множество других, сказываются на эффективности управления задачами
организации,и,какследствие,наэффективностивсегопредприятиявцелом.
Таким образом, для всех современных предприятий существует острая
необходимость в инструменте, который позволил бы успешно управлять задачами и
обеспечивать контроль над их выполнением, т.е. повысить количество успешно
завершенных задач, а также косвенно повлиять на уменьшение времени, затрачиваемое
наихисполнение.
В настоящее время, современный рынок программного обеспечения для
решенияописаннойпроблемыпредлагаетнесколько вариантов,к основнымизкоторых
можноотнестиследующиесистемы:
1) Конфигурация «Управление задачами персонала» для «1С: Предприятие
8.1».
2) СистемаэлектронногодокументооборотаDirectum.
3) ОнлайнинструментдляуправленияподчиненнымиМегаплан.
Данные инструменты позволяют управлять задачами (создание редактирование),
а так же их контролировать. Но в результате анализа опыта внедрения на предприятиях
было выяснено, что они обладают избыточной функциональностью и сложностью, из-
за которой возникают проблемы с внедрением и использованием. Использование этих
систем является платным. Таким образом организации платят большие суммы за
системы,которыенеиспользуются.
3
В сравнении с указанными выше инструментами в выигрышном положении
могла бы оказаться своя система управления задачами с простым и понятным
пользовательским интерфейсом, функциональность которой могла бы наращиваться
подлюбыетребования.
Целью курсового проекта является повышение эффективности управления и
контролязадач.
Длядостиженияпоставленнойцелинужнорешитьследующиезадачи:
1) Провести анализ предметной области.
2) Разработать требования на проектирование
3) Построить функциональную модель.
4) Разработать структуру БД.
5) Разработать алгоритмы системы.
6) Реализовать систему.
4
1 РазработкаIDEF0моделиуправлениязадачами
Для анализа процесса управления задачами была выбрана методология IDEF0.
Результатоманализаявляетсяфункциональнаямодельпроцессауправлениязадачами.
Целью процесса управления задачами является отслеживание поставленных
задач на всех этапах их жизненного цикла, а также формирование отчетности для
оценкиэффективностивыполнениязадач.ПроцессуправлениязадачейвмоделиIDEF0
декомпозированна5процессов:
подготовка задачи ─ на основании требований, предъявленных заказчиком,
создатьзадачу,нуждающуюся врешении;
выполнениезадачи─ реализациясформулированнойзадачи;
изменение параметров задачи ─ возможность изменения данных задачи под
новыебизнес-требования;
принятиезадачи─проверкавыполненнойзадачинакорректность;
формирование отчетности ─ на основании принятой задачи формируется
отчетовыполнении.
На контекстной диаграмме процесс управления задачей выполнен в общем виде
(рисунок1).
Весь процесс управления задачей осуществляет заказчик. Исполнитель
принимает участие на этапах подготовки и реализации задачи. Входными данными
являютсянекиеисходныеданныедля задачи,предъявленныезаказчиком.Всепроцессы
регламентированы правилами создания задачи. Целью осуществления управления
задачей является получение корректно реализованной задачи и формирование отчета о
еевыполнении.
5
Рисунок 1 — Контекстная диаграммаА-0 модели IDEF0 процесса управления
задачей
На дочерней диаграмме показан более детализированный процесс управления
задачей(рисунок2).
Рисунок 2 — Контекстная диаграммаА0 модели IDEF0 процесса управления задачей
6
Первым процессом является подготовка задачи. На основании исходных данных,
введенных заказчиком, создается задача, нуждающаяся в решении. После того, как
быласозданазадачадляисполнения,начинаетсяпроцессвыполнениязадачи.
Результатами данного процесса являются несколько решений: задача на
принятие, задача на корректировку и отказанная задача. Задача, отправленная на
корректировку или отказанная задача, являются входными данными для процесса
изменения задачи. Результатами данного процесса являются: отмененная задача, задача
с измененными сроками выполнения и задача, переданная другому исполнителю. В
случае отмены задачи, должен быть сформулирован отчет о завершении всяческих
работ в отношении конкретной задачи. Задача с измененными сроками исполнения
перенаправляется на этап выполнения. Переданная другому исполнителю задача
отправляется на этап подготовки задачи для определения новых или уточнения ранее
установленных требований. Задача на принятие служит исходными данными для
следующего процесса ─ принятия задачи. На данном этапе выполняется проверка
выполненной задачи на корректность. В случае выявления ошибок в реализации, она
перенаправляется обратно на этап выполнения задачи на доработку. В случае
корректного выполнения задачи, она приобретает статус принятой. Затем принятая
задача отправляется на этап формирования отчетности. В результате чего должен быть
сформированотчетовыполненииданнойзадачи.
Все процессы управления задачей регламентированы правилами создания
задачи.
НадиаграммеА1показанпроцессподготовкизадачи(рисунок3).
На основании исходных данных, введенных заказчиком, создается задача,
нуждающаяся в решении. Далее сформированная или переданная задача переходит на
этап согласования, на котором заказчик и исполнитель вместе обсуждают задачу и
корректируют ее данные. Затем согласованная заказчиком и исполнителем задача
принимаетсянаисполнение.Результатомявляетсязадачанавыполнение.
Правиласозданиязадачирегламентируютвсетрипроцессаподготовкизадачи.
7
Рисунок3—КонтекстнаядиаграммаА1моделиIDEF0 процессауправлениязадачей
НадиаграммеА2показанпроцессвыполнениязадачи(рисунок4).
Рисунок 4 — Контекстная диаграммаА2 модели IDEF0 процесса управления задачей
Первым процессом является выполнение задачи, где на основании пришедших
данных задачи для выполнения, происходит процесс выполнения задачи. Результатами
данногопроцессаявляются несколькорешений:задачанапринятие,вопросыпозадаче.
Вопросы по задаче передаются следующему процессу на обсуждение задачи. На
8
данном этапе заказчик и исполнитель обсуждают задачу, и на выходе передается
корректировка задачи. Так же первый процесс в качестве результата передает задачу на
выполнение, которая передается в процесс отказа от задачи. В данном процессе
исполнитель отказывается от выполнения задачи и передает ее обратно на подготовку.
Результатом является отказанная задача. Правила создания задачи регламентируют все
процессывыполнениязадачи.
НадиаграммеА3показанпроцессизмененияпараметровзадачи(рисунок5).
Первым процессом является передача задачи, который получает корректировки
задачи или отказанную задачу. Во время этого процесса происходит передача задачи
другому исполнителю. На выход из процесса поступает переданная задача, которая
направляется на дальнейшее согласование. Следующий процесс отмены задачи, так же
получает корректировки задачи и характеризуется как отмена созданной задачи. На
выходе процесса получаем отмененную задачу, направленную для формирования
отчета. Третий процесс изменения сроков так же связан на входе с корректировками
задачи, и является процессом, благодаря которому заказчик может изменить сроки
задачи. Данный процесс на выход выводит задачу с измененными сроками. Эта задача
переходит к процессу выполнения задачи. Правила создания задачи регламентируют
всетрипроцессаизмененияпараметровзадачи.
Рисунок 5 — Контекстная диаграммаА3 модели IDEF0 процесса управления задачей
9
НадиаграммеА4показанпроцесспринятиязадачи(рисунок6).
Выполненная задача, получив статус "задача на принятие" проходит проверку на
корректное исполнение. Результат проверки может выявить недочеты и ошибки, в этом
случаезадачаотправляется надоработкуизатемперенаправляетсянаэтап выполнения.
Если результат проверки не выявляет ошибок, т.е. задача выполнена корректно, она
получаетстатус"принятая".
Всепроцессыпринятиязадачирегламентированыправиламисозданиязадачи.
Рисунок6—КонтекстнаядиаграммаА4модели IDEF0процессауправлениязадачей
10
2 Анализсуществующихрешений
Средипредлагаемыхрешенийможновыделитьследующиесистемы:
1. Конфигурация «Управление задачами персонала» для «1С: Предприятие
8.1».
2. СистемаэлектронногодокументооборотаDirectum.
3. ОнлайнинструментдляуправленияподчиненнымиМегаплан.
В настоящее время данные продукты можно отнести к основным. Далее
рассмотримсистемы подробнее.
Конфигурация «Управление задачами персонала» - программный продукт,
позволяющий вести учет и контроль выполняемых персоналом задач. Также
предоставляетсявозможностьавтоматизироватьбизнес-процессыпредприятия.Данное
решение является оригинальным, но не самостоятельным программным продуктом.
Для его работы необходимо наличие установленной платформы «1С: Предприятие
8.1».
Основныефункциональныевозможностипродукта:
учетзадачсотрудников;
отслеживаниесроковвыполнениязадач;
контрольпросроченныхзадач;
произвольнаямаршрутизациявыполняемыхзадачипоручений;
создание произвольной настройки для карты-маршрута с описанием
обработчиковсобытий;
информированиепользователейопродвижениизадачи.
Directum – система электронного документооборота и управления
взаимодействием в разных областях совместной деятельности. Решение
рассматриваемой проблемы обеспечивает модуль системы «Управление деловыми
процессами». Данный модуль занимается поддержкой процессов согласования и
обработки документов, выдачей заданий и контролем их исполнения, поддержкой
свободных и жестких маршрутов, а также обеспечивает взаимодействия между
11
сотрудниками в ходе бизнес-процессов. Таким образом, модуль повышает
эффективность управления бизнес-процессами, их описания, поддержки и выполнения
засчет:
автоматизацииотдельныхэтаповзадач;
возможностиотслеживаниясостояниякаждойзадачи;
анализазагруженностисотрудниковирезультативностиихработы.
Мегаплан – система автоматизации и управления бизнесом, а также
автоматизация бизнес-процессов. Данный инструмент делиться на несколько сервисов,
позволяющих управлять проектами, задачами и людьми, клиентами, сделками и
продажами, и др. Сервис «Совместная работа» позволяет управлять задачами и
осуществлятьихконтроль.
Таблица1—Своднаятаблицаанализасуществующихрешений.
Управление
задачами
персонала
Directum
Мегаплан
Стоимостьклиентской
лицензии
20000руб.
10200руб.
1824руб.
Самостоятельность
продукта
-
+
+
Мультиплатформенность
-
-
+
Легкостьвовнедрении
-
-
-
12
3 Требованияксистеме
На основании анализа процесса управления задачами и существующих систем
былиразработанытребованиякпроектируемойсистеме.
Системадолжнапозволять:
регистрироватьпользователей;
просматриватьпрофильпользователя;
изменятьданныепользователя;
назначатьроли пользователям;
формироватьотчеты по задачам;
создаватьзадачу:
а) устанавливать трудоемкостьзадачи;
б) добавлятьописаниек задаче;
в) добавлятьфайлы к задаче;
г) устанавливать сроки задачи;
назначатьзадачеразныеметки;
назначатьисполнителя задачи;
начинать,завершать, принимать,отклонять,передавать задачу;
просматриватьзадачуи всю информациюоней;
вести обсуждениепо задаче;
уведомлять пользователя о событиях задачи;
фильтровать задачи по заданнымпараметрам;
сортироватьзадачи;
создаватьсообщества;
приглашатьв сообщества;
управлять сообществами;
просматривать участникови профильсообщества;
изменятьпрофильсообщества;
13
4 Диаграммыпрецедентовсистемы
Диаграмма прецедентов позволяет описать функциональность и поведение
системы через отношения между актерами и прецедентами. Диаграммы представлены
на рисунках 7 и 8. Диаграмма для системы управления задачами (рисунок 7) содержит
трех актеров, двое из которых (Заказчик и Исполнитель) наследуются от другого актера
–Пользователясистемы.
Пользователь системы – это любой зарегистрированный пользователь. Он
может создать задачу или подзадачу, а так же просматривать информацию о задачах и
участвоватьвобсуждениизадач,вкоторыхонявляетсяЗаказчикомилиИсполнителем.
Заказчик– пользователь, создавший задачу. Он может совершать всистеме все
действия как ее пользователь. Также помимо этого, он обладает правом изменять
параметры задачи, проверять задачи, отправленные на проверку, помечая их как
выполненныеилиотправляянадоработку,атакжеотменятьзадачу.
Исполнитель – пользователь, выбранный заказчиком для выполнения задачи.
Он может совершать в системе все действия как ее пользователь. Также помимо этого,
он может принять предложенную задачу или отказаться от нее, и отправить
выполненнуюзадачунапроверкукзаказчику.
Рисунок 7 — Диаграммапрецедентовдля системы управления задачами
14
Диаграмма для системы управления сообществами (рисунок 8) содержит
четырех актеров: Пользователь системы, Участник, Менеджер, Руководитель, каждый
изкоторыхнаследуетвозможностипредыдущего.
Пользователь системы – это любой зарегистрированный пользователь. Он
может создать сообщество или быть приглашенным в сообщество, а так же
просматриватьинформациюосообществах.
Участник – это пользователь, принятый в сообщество с правами участника.
Он может совершать в сообществе все действия как ее пользователь. Также помимо
этого,онможетвыполнятьипросматриватьзадачисообщества.
Менеджер – это пользователь, принятый в сообщество с правами менеджера.
Он может совершать в сообществе все действия как участник. Также помимо этого, он
можетизменятьпрофильсообщества.
Руководитель – это пользователь, создавший сообщество или принятый в
сообщество с правами руководителя. Он может совершать в сообществе все действия
как ее менеджер. Также помимо этого, он может просматривать отчет по задачам
сообщества,приглашатьиудалятьчленовсообщества.
Рисунок 8 —Диаграммапрецедентовдля системы управления сообществами
15
Таблица2 —Прецедент: СозданиеЗадачи
Прецедент: СозданиеЗадачи
ID: 1
Краткое описание:
Создание новой задачи в системе
Главные актеры:
Пользователь системы
Основной поток:
1. Пользователь создает новую задачу.
2. Система выводит форму создания новой задачи.
3. Пользователь вводит название задачи.
4. Пользователь выбирает Сообщество.
5. Система формирует список участников в сообществе.
6. Пользователь выбирает исполнителя из списка участников сообщества.
7. Пользователь добавляет описание к задаче.
8. Пользователь ставит метки задаче.
9. Пользователь добавляет файлы к задаче.
10. Пользователь устанавливает трудоемкость задачи.
11. Пользователь отправляет данные системе.
12. Система устанавливает заказчиком задачи, пользователя создавшего
данную задачу.
13. Система устанавливает статус задачи как «Новая».
14. Система посылает уведомление о новой задаче исполнителю.
15. Пользователь видит созданную задачу в списке задач.
Таблица 3 —Прецедент: СозданиеПодзадачи
Прецедент: СозданиеПодзадачи
ID: 2
Краткое описание:
Создание подзадачи для выбранной задачи.
Главные актеры:
Пользователь системы
Основной поток:
1. Пользователь создает новую подзадачу.
2. Система выводит форму создания новой подзадачи.
3. Пользователь выбирает родительскую задачу.
4. Пользователь вводит название подзадачи.
5. Пользователь выбирает сообщество.
6. Система формирует список участников сообщества.
7. Пользователь выбирает исполнителя из списка участников сообщества.
8. Пользователь добавляет описание к подзадаче.
9. Пользователь ставит метки подзадаче.
10. Пользователь добавляет файлы к подзадаче.
16
11. Пользователь устанавливает трудоемкость подзадачи.
12. Пользователь отправляет данные системе.
13. Система устанавливает заказчиком подзадачи, пользователя создавшего
данную подзадачу.
14. Система устанавливает статус подзадачи как «Новая».
15. Система посылает уведомление о новой задаче исполнителю.
16. Пользователь видит созданную подзадачу в списке задач.
Прецедент СозданиеЗадачи можно представить в виде диаграммы действия
(рисунок 9). Данная диаграмма показывает, какие действия должен совершить
пользовательсистемыдлядобавлениявнеезадачи.
Рисунок 9 —Диаграммадействия для создания новой задачи
17
Прецедент СозданиеПодзадачи также представлен в виде диаграммы действия
(рисунок 10). На данной диаграмме изображена последовательность действия,
которые должен пользователь, для создания подзадачи. После совершения всех
шагов, система создает новую подзадачу и устанавливает выбранную задачу
как родительскую.
Рисунок 10 —Диаграммадействия для создания подзадачи
18
Таблица4 —Прецедент: ПросмотрЗадачи
Прецедент: ПросмотрЗадачи
ID: 3
Краткое описание:
Просмотр данных о задаче.
Главные актеры:
Пользователь системы
Основной поток:
1. Пользователь открывает задачу.
2. Система выводит окно с данными задачи.
Таблица5 —Прецедент: ОбсуждениеЗадачи
Прецедент: ОбсуждениеЗадачи
ID: 4
Краткое описание:
Позволяет пользователям вести обсуждение задачи.
Главные актеры:
Пользователь системы
Основной поток:
1. Пользователь открывает задачу.
2. Система выводит окно с данными задачи и обсуждением.
3. Пользователь вписывает текст сообщения.
4. Пользователь отправляет сообщение.
5. Система добавляет сообщение к обсуждению.
6. Система посылает уведомления о новом сообщении в обсуждении всем
участникам обсуждения, кроме автора сообщения.
Данный прецедент представлен на диаграмме действия (рисунок 11), на которой
изображен процесс обсуждения задачи. Процесс обсуждения задачи
заключается в обмене сообщениями по задаче.
19
Рисунок 11—Диаграммадействия для обсуждения задачи
Таблица 6 —Прецедент: ПринятиеНаИсполнение
Прецедент: ПринятиеНаИсполнение
ID: 5
Краткое описание:
Позволяет исполнителю согласиться или отказаться выполнять
предложенную задачу.
Главные актеры:
Исполнитель
Основной поток:
1. Исполнитель открывает задачу.
2. Система выводит окно с данными задачи и возможностью выбора принять
ему задачи, либо отказаться.
3.1 Если исполнитель соглашается выполнять задачу, тогда система
установит задаче статут «В работе».
3.2 Если исполнитель не соглашается выполнять задачу, тогда система
установит задаче статут «Отказано».
4. Система отсылает уведомление заказчику, о принятом решении
исполнителя.
Прецедент «ПринятиеНаИсполнение» представлен на диаграмме действия
(рисунок 12), на которой изображен процесс принятие исполнителем задачи. Как
видно по диаграмме, пользователь может согласиться выполнять задачу, так и
отказать от нее.
20
Рисунок 12—Диаграммадействия для принятия наисполнение
Таблица7 —Прецедент: ОтказОтЗадачи
Прецедент: ОтказОтЗадачи
ID: 6
Краткое описание:
Дает возможность исполнителю отказаться от уже выполняемой задачи.
Главные актеры:
Исполнитель
Основной поток:
1. Исполнитель открывает задачу, от которой хочет отказаться.
2. Система выводит окно с данными задачи.
3. Исполнитель отказывается от выполнения задачи.
4. Система изменяет статус задачи на «Отказано».
5. Система отсылает уведомление заказчику.
Таблица 8 —Прецедент: ОтправкаНаПроверку
Прецедент: ОтправкаНаПроверку
ID: 7
Краткое описание:
Дает возможность исполнителю уведомить заказчика об выполнении задачи.
Главные актеры:
Исполнитель
21
Основной поток:
1. Исполнитель открывает задачу.
2. Система выводит окно с данными задачи.
3. Исполнитель завершает выполнение задачи.
4. Система изменяет статус задачи на «Ждет проверки».
5. Система отсылает уведомление заказчику.
Таблица9 —Прецедент: ИзменениеПараметровЗадачи
Прецедент: ИзменениеПараметровЗадачи
ID: 8
Краткое описание:
Позволяет заказчику изменять данные задачи введенные при ее создании.
Главные актеры:
Заказчик
Основной поток:
1. Заказчик открывает настройки задачи.
2. Система выводит страницу настроек задачи, где есть поля ввода новых
данных.
3. Заказчик вводит в эти поля новые данные.
4. Заказчик отправляет введенные данные.
5. Система сохраняет введенные изменения.
Таблица10 —Прецедент: ПринятиеВыполненойЗадачи
Прецедент: ПринятиеВыполненойЗадачи
ID: 9
Краткое описание:
Позволяет заказчику принять выполненную задачу.
Главные актеры:
Заказчик
Основной поток:
1. Заказчик открывает страницу с задачей на проверку.
2. Система выводит окно с данными задачи.
3. Заказчик принимает выполнение задачи.
4. Система изменяет статус задачи на «Выполнена».
5. Система отсылает уведомление исполнителю.
Таблица11 —Прецедент: ОтправкаНаДоработку
Прецедент: ОтправкаНаДоработку
ID: 10
Краткое описание:
Позволяет заказчику отправить задачу на доработку.
Главные актеры:
22
Заказчик
Основной поток:
1. Заказчик открывает страницу с задачей на проверку.
2. Система выводит окно с данными задачи.
3. Заказчик отправляет задачу на доработку.
4. Система изменяет статус задачи на «В работе».
5. Система отсылает уведомление исполнителю.
Таблица12 —Прецедент: ОтменаЗадачи
Прецедент: ОтменаЗадачи
ID: 11
Краткое описание:
Позволяет заказчику отменить задачу.
Главные актеры:
Заказчик
Основной поток:
1. Заказчик отменяет задачу.
2. Система переводит задачу в состояние «Отменена».
3. Система высылает уведомление исполнителю.
Таблица13 —Прецедент: СозданиеСообщества
Прецедент: СозданиеСообщества
ID: 12
Краткое описание:
Создание нового сообщества в системе.
Главные актеры:
Пользователь системы
Основной поток:
1. Пользователь создает новое сообщество.
2. Система выводит форму для создания нового сообщества.
3. Пользователь вводит название сообщества.
4. Пользователь отправляет данные системе.
5. Система добавляет в сообщество создающего с ролью «Руководитель».
Таблица14 —Прецедент: ПринятиеПриглашения
Прецедент: ПринятиеПриглашения
ID: 13
Краткое описание:
Позволяет пользователю согласиться или отказаться вступить в сообщество,
в которое его приглашают.
Главные актеры:
Пользователь системы
23
Основной поток:
1. Пользователь заходит на страницу сообщества.
2. Система отображает страницу с данными сообщества и возможностью
выбора вступить в сообщество или отказаться.
3.1 Если пользователь соглашается вступить, тогда система добавляет его в
сообщество с предложенной ролью.
3.2 Если пользователь не соглашается вступить, тогда система удаляет
предложение о вступлении в сообщество.
4. Система отсылает уведомление пригласившему пользователю.
Прецедент «ПринятиеПриглашения» представлен на диаграмме действия
(рисунок 13), на которой изображен процесс соглашения на вступление в
сообщество. Как видно по диаграмме, пользователь может согласиться
вступить в сообщество, или отказаться от вступления.
Рисунок 13 —Диаграммадействия для принятия приглашения
Таблица15 —Прецедент: ПросматриватьПрофильСообщества
Прецедент: ПросматриватьПрофильСообщества
ID: 14
Краткое описание:
Позволяет пользователю просматривать страницу с данными сообщества.
Главные актеры:
24
Пользователь системы
Основной поток:
1. Пользователь заходит на страницу сообщества.
2. Система отображает страницу с данными сообщества.
Таблица16 —Прецедент: ПросмотрЗадачСообщества
Прецедент: ПросмотрЗадачСообщества
ID: 15
Краткое описание:
Позволяет участнику просматривать задачи в сообществе.
Главные актеры:
Участник
Основной поток:
1. Участник открывает страницу задач сообщества.
2. Система выводит страницу с задачами сообщества.
Таблица17 — Прецедент: ИзменениеПрофиляСообщества
Прецедент: ИзменениеПрофиляСообщества
ID: 16
Краткое описание:
Позволяет менеджеру изменять профиль сообщества.
Главные актеры:
Менеджер
Основной поток:
1. Менеджер открывает окно изменения профиля сообщества.
2. Система выводит форму настроек профиля, где есть поля ввода новых
данных.
3. Менеджер вводит в эти поля новые данные.
4. Менеджер отправляет введенные данные.
5. Система сохраняет введенные изменения.
Таблица18 —Прецедент: ПросмотрОтчета
Прецедент: ПросмотрОтчета
ID: 17
Краткое описание:
Позволяет руководителю просматривать отчет о выполнении задач за
определенный период.
Главные актеры:
Руководитель
Основной поток:
1. Руководитель формирует отчет.
2. Система выводит форму ввода данных для отчета.
25
3. Руководитель вводит сообщество.
4. Руководитель вводит отчетный период.
5. Руководитель отправляет данные системе.
6. Система формирует и выводит отчет.
Данный прецедент также представлен в виде диаграммы действия
(рисунок 14). На этой диаграмме представлена последовательность действий, которые
должен совершить руководитель для того чтобы сформировать отчет по заданному
периоду.
Рисунок 14 —Диаграммадействия для принятия приглашения
Таблица19 —Прецедент: ПриглашениеУчастника
Прецедент: ПриглашениеУчастника
ID: 18
Краткое описание:
Позволяет руководителю приглашать новых участников в сообщество.
Главные актеры:
Руководитель
Основной поток:
1. Руководитель приглашает участника.
2. Система выводит форму для приглашения нового участника.
26
3. Руководитель выбирает пользователя, и роль с которой тот вступит в
сообщество.
4. Руководитель отправляет данные.
5. Система высылает уведомление о приглашении пользователю.
Таблица 20 —Прецедент: УдалениеУчастника
Прецедент: УдалениеУчастника
ID: 19
Краткое описание:
Позволяет руководителю удалять участников из сообщества.
Главные актеры:
Руководитель
Основной поток:
1. Руководитель удаляет участника.
2. Система выводит список всех участников.
3. Руководитель выбирает пользователя, которого хочет удалить.
4. Руководитель отправляет данные.
5. Система удаляет пользователя из сообщества.
6. Система высылает уведомление об удалении пользователю.
27
5 Диаграммаклассованализа
На рисунке 15 представлена диаграмма классов, которая описывает
структуру системы. Данная диаграмма показывает классы, их атрибуты и
методы, а также взаимосвязи этих классов. Данная диаграмма содержит 9
классов. Ниже приведено описание каждого класса.
Класс Задача. Каждая такая задача имеет свое название, описание,
трудоемкость, заказчика, исполнителя, время создания, время окончания,
статус, сообщество, родительская задача. Все эти атрибуты позволяют наиболее
полно описать задачу. Также над объектом данного класса можно совершать
следующие действия: создатьЗадачу, получитьИнформацию, изменитьЗадачу,
изменитьСтатус. Поле сообщество необходимо, для указания сообщества, в
рамках которого создана задача.
Класс Задача, так же имеет взаимосвязь сам с собой, т.е при наличии
родительской задачи, задача считается подзадачей для родительской.
Класс Задача связан с классом Метка. Каждый объект Задача может
обладать метками, позволяющие более гибко искать необходимые задачи.
Класс Метка содержит в себе два поля: название, задача с которой она связана,
а так же методы создатьМетку, просмотретьМетку, удалитьМетку,
изменитьМетку.
Класс Обсуждение имеет связь с классом Задача. У каждой задачи есть
обсуждение. При этом среди полей у обсуждения указана только задача, с
которым оно связано. Единственный метод класса просмотОбсуждения.
Класс Обсуждение так же связан с классом Сообщение. У каждого
обсуждения может быть большое кол-во сообщений. Данный класс содержит 4
поля: текст, автор, обсуждение и время создания. Поле «обсуждение» указывает
на принадлежность к конкретному обсуждению, а значит и к конкретной
задаче.
Класс Файл имеет связи с задачей и сообщением. Но при этом эти связи
имеют отличие. Так например сообщение может содержать только один файл,
28
тогда как к задаче может быть приложено большое кол-во файлов. Тип, путь к
файлу и объект файла, являются полями класса. Объектом файла могут
являться как Сообщение, так и Задача. Методы класса: создатьСообщение,
просмотретьСообщение и удалитьСообщение.
Класс Сообщество, также имеет связь с классом Задача. Так сообщество
может иметь множество задач. Имеет единственное поле: название, и четыре
метода: создатьСообщество, получитьИнформацию, изменитьСообщество и
сформироватьОтчет.
Класс Уведомление имеет связь с классами Задача и Сообщества. Эта
взаимосвязь охарактеризована тем, что уведомление указывает на конкретный
уведомляемый объект, будь то сообщество или задача. В данном классе
присутствует пять полей: объект уведомления, отправитель, получатель, тип,
время создания. Методы: сгенерироватьУведомление, показатьУведомление.
Одним из основных классов является класс Пользователь. Он
характеризует пользователя системы. При этом имеет связь со следующими
классами: Задача, Сообщество, Сообщение, Уведомление. Так поля «заказчик»
и «исполнитель» в Задаче являются ссылками на пользователей в системе. То
же самое и для полей «отправитель» и «получатель» класса Уведомление. Поле
«автор» в классе Сообщение, так же является ссылкой на пользователя. Каждый
пользователь может иметь множество сообщества, а в сообщество может
входить множество пользователей – так охарактеризована связь с классом
Сообщество. Пользователь содержит в себе поля: имя, фамилия, отчество,
email, дата рождения. И методы: создатьПользователя, получитьИнформацию,
принятьПриглашение и изменитьПользователя.
Связь классов Сообщество и Пользователь обеспечивает класс
Сотрудничество, которая содержит в себе поля: роль, участник и сообщество.
Методы:
создатьСотрудничество,
удалитьСотрудничество
и
просмотретьИнформацию.
29
Рисунок 15 — Диаграмма классов системы управления задачами
30
6 Диаграммасостояний
На рисунке 16 представлена диаграмма состояний, которая описывает
состояния задачи. Данная диаграмма показывает состояния и события, а также
переходы между состояниями. Данная диаграмма содержит 6 состояний.
Состояние Новая является начальным состоянием каждой задачи. Каждая
задача по умолчанию создается с данным состоянием. Задача с данным
состоянием может переходить в 2 состояния, в зависимости от действия
исполнителя задачи. Так событие принятиеНаИсполнение переводит задачу в
состояние В работе, а отказОтИсполнения в состояние Отказано.
Состояние В работе характеризуется как время потраченное с момента
принятия задачи, до момента отправки на проверку. Отсюда же и выходит
событие отправкаНаПроверку, которое обновляет состояние до Ждет прверки.
Так же как и в состоянии Новая, данное состояние может переходить в
состояние Отказано, с помощью события отказОтЗадачи.
Состояние Отказано – это состояние, когда у задачи отсутствует
исполнитель. Так при помощи события передачаЗадачи, заказчик может
передать ее другому исполнителю и вернуть в состояние Новая.
Каждое из вышеописанных состояний может перейти в состояние
Отменена. Для этого заказчик может вызвать событие отменаЗадачи. Данное
состояние является конечным.
Состояние Ждет проверки является промежуточным состоянием и может
перейти в 2 других: В работе и Завершена. Для этого есть 2 события:
отправкаНаДоработку и принятиеВыполненойЗадачи.
Состояние Завершена является конечным состоянием.
31
Рисунок 16 — Диаграмма состояний системы управления задачами
32
ЗАКЛЮЧЕНИЕ
На этапе анализа были проведены следующие работы: анализ предметной
области, где были выявлены необходимые требования к системе; описание основных
процессов управления задачами; выявлены роли пользователей и основные функции,
которые они могут выполнять в системе; выявлены классы системы; выявлены
состоянияисобытиязадачивсистеме.
Результатом проведенных работ являются диаграммы IDEF0, диаграмма
прецедентовиихспецификация,диаграммаклассовидиаграммасостояний.
На основании проведенного анализа было разработано техническое задание на
создание системы управления задачами. Техническое задание приведено в приложении
1.
33
СПИСОКИСПОЛЬЗОВАННЫХИСТОЧНИКОВ
1) Джим Арлоуи АйлаНейштадт— UML2иУнифицированныйпроцесс.
Практическийобъектно-ориентированныйанализипроектирование,2-еиздание.—
СПб:Изд.СимволПлюс,2007. —624с.
2) ЛеоненковА.В.— СамоучительUML2.— СПб.:Изд.БХВ-Петербург,2007. —
576с.
3) ВольфсонБорис— Гибкиеметодологииразработки —2010.—126с.
34
ПРИЛОЖЕНИЕ 1
Техническое задание
1 Общиесведения
1.1 Полноенаименованиесистемы
Системауправлениязадачами.
2 Назначениеицелисозданиясистемы
2.1 Назначениесистемы
Основным назначением системы является автоматизация деятельности по
управлению и контролю задач. В рамках проекта автоматизируется деятельность в
следующихпроцессах:
Формирование задачи;
Инструменты,помогающиепри обсуждении задач;
Разбиениезадачи наподзадачи;
Контрольжизненного циклазадачи;
Формированиеотчетов.
2.2 Целисозданиясистемы
Система управления задачами создается с целью повышения эффективности
процессауправления задачами.
3 Характеристика объектовавтоматизации
Заказчиком формируется задача, которая предлагается исполнителю.
Исполнитель с заказчиком согласовывают условия задачи до тех пор, пока заказчик не
отменит задачу, либо исполнитель не примет ее к исполнению. Задачи могут
разбиватьсянаподзадачи.
35
Следующим этапом является – выполнение задачи. Здесь исполнитель
выполняет принятую задачу. Принятая задача выполняется до тех пор пока не будет
принятазаказчиком,либонеотменена.
Далее заказчик проверяет отправленную исполнителем на проверку задачу, и
делаетвывод:завершеназадачаилинуждаетсявдоработке.
Последним этапом является анализ проделанной работы. Здесь подводятся итоги
того,чтобылосделано.Итогомявляетсяотчеторезультатеанализа.
4 Требованияк системе
4.1 Требованиякфункциям,выполняемымсистемой
Оперативноеуведомлениео состоянии задачи;
Формирования отчетов;
Возможностьзакрепления задачи законкретнымисполнителем;
Возможность установления трудоемкости задаче;
Возможность установления сроковзадаче;
Возможностьобсуждения задачи;
Возможностьпередачи задачи.
Возможностьизменения статуса задачи.
4.2 Требованияквидамобеспечения
При реализации системы должна применяться web-ориентированная среда
разработкиRubyOnRails.
Информация о работе Повышение эффективности управления и контроля задач