МИСПИСИТ_КП. Курсовой проект по дисциплине методы и средства проектирования информационных систем и технологий Разработка информационной системы независимой игровой студии
 Скачать 1.13 Mb.
|
|
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ им. проф. М. А. Бонч-Бруевича (СПбГУТ) Институт Непрерывного Образования (ИНО) КУРСОВОЙ ПРОЕКТ по дисциплине МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ «Разработка информационной системы независимой игровой студии» Фамилия: Царькова Имя: Анна Отчество: Александровна № зачётной книжки: 1710122 Группа №: ИБ-72з Проверил: ______________ Санкт-Петербург 2021 2 Содержание Введение. ........................................................................................................................ 3 1. Диаграмма вариантов использования. .................................................................... 4 2. Диаграмма последовательности .............................................................................. 6 3. Диаграмма состояний ............................................................................................. 12 4. Диаграмма деятельности ........................................................................................ 14 5. Диаграмма классов .................................................................................................. 17 Заключение .................................................................................................................. 21 Список литературы ..................................................................................................... 22 3 Введение. Исследуемая область в данном курсовом проекте – независимая игровая студия, в частности, координация деятельности и контроль работы отдельных разработчиков с целью оптимизации процесса разработки. Оптимизация критически важна для данной отрасли, поскольку любые задержки и ошибки могут привести к существенным убыткам, что может привести к финансовому провалу проекта и закрытию компании. Создание информационной системы необходимо, чтобы руководитель мог своевременно получать и предоставлять разработчикам необходимую информацию. Благодаря информационной системе разработчики смогут быстрее получать задания, а руководитель – своевременно принимать необходимые управленческие решения. Грамотный менеджмент играет критически важную роль в любой разработке. 4 1. Диаграмма вариантов использования. Построим диаграмму вариантов использования. Диаграмма вариантов использования является отправной точкой в процессе моделирования. Цель построения диаграммы – наглядно отобразить общий механизм работы и взаимодействия внутри студии, что призвано повысить эффективность деятельности разработчиков, и, как следствие, минимизировать время и затраты на разработку. В данной работе для удобства будет рассмотрена работа небольшой независимой студии, поэтому в её иерархии будет только 3 уровня – руководитель, руководители отделов и отдельные разработчики (их подчинённые). Руководитель управляет разработкой в целом, контролирует деятельность начальников отделов и ставит перед ними задачи для выполнения. Начальники отделов (арт директор, технический директор, геймдизайнер) контролируют деятельность разработчиков и ставят перед ними конкретные задачи для выполнения, а также отчитываются о проделанной работе перед руководителем. Разработчики получают задания от своих начальников, а также могут обмениваться данными между собой. Рисунок 1. Классификационное дерево студии 5 Рисунок 3. Подробная диаграмма вариантов использования Общая диаграмма использования представлена на рисунке 2. Рисунок 2. Общая диаграмма вариантов использования Также на рисунке 3 представлена подробная диаграмма вариантов использования, описывающая действия не только для групп «актёров», но и для отдельных начальников и разработчиков: 6 2. Диаграмма последовательности Диаграмма последовательности – это UML-диаграмма, на которой отражается жизненный цикл объекта (создание, деятельность, уничтожение) и взаимодействие «актёров» информационной системы в рамках определённого инцидента. Диаграммы последовательности хорошо отражают точные действия в пределах одного инцидента – например, обмен сигнала Составим диаграммы деятельности для основных вариантов использования. Необходимо составить следующие диаграммы: диаграмма «Принятие управленческих решений», описывающая механизм принятия решений руководителем; диаграмма «Постановка задач», описывающая механизм передачи заданий от руководителя начальникам отдела; диаграмма «Согласование ТЗ», описывающая механизм передачи ТЗ от начальника отдела к разработчику и согласование выполненного задания; диаграмма «Отчёт о работе», описывающая механизм формирования начальником отдела отчёта о выполненных заданиях и отправки руководителю; диаграмма «Выполнение полученного задания», описывающая механизм получения и выполнения разработчиком задания, а также обмена данными между отдельными разработчиками, например, передача референсов для работы от художника к 3D-художнику. 7 1. Диаграмма «Принятие управленческих решений». Данная диаграмма отражает последовательность действий руководителем во время принятия управленческих решений. В первую очередь руководитель составляет план. Он принимает решения и даёт задания в соответствии с этим планом. Также руководитель получает отчёт о выполненной работе от начальников отдела. Сравнивая данные из отчётов с планом, руководитель может оценить эффективность разработки, а также скорректировать план и дать новые указания (например, к поощрению отдельных сотрудников). Рисунок 4. Диаграмма «Принятие управленческих решений». 8 2. Диаграмма «Постановка задач». Данная диаграмма отображает процесс постановки задач от руководителя к начальникам отдела. Руководитель составляет план, согласно которому он будет выдавать задания и следить за успехом разработки. В результате трудовой деятельности руководитель получает отчёты от начальников отделов, в котором отражён прогресс выполнения заданий. Получив информацию о проделанной работе, руководитель может определить следующий этап разработки. Он формирует новые задания и отправляет их начальникам отделов. Рисунок 5. Диаграмма «Постановка задач» 9 3. Диаграмма «Согласование ТЗ». На данной диаграмме отражён процесс выдачи и утверждения технического задания начальником отдела. После получения задания от руководителя начальник отдела формирует чёткое ТЗ для разработчика. Затем он выдаёт ТЗ, после получения выполненного задания проверяет его. Если всё в порядке, то начальник утверждает работу, в противном случае он отправляет задание на доработку. Этот цикл повторяется до утверждения работы. Рисунок 6. Диаграмма «Согласование ТЗ» 10 4. Диаграмма «Отчёт о работе». Данная диаграмма отражает процесс формирования отчёта о работе, который каждый начальник отдела формирует отдельно и отправляет руководителю. Формирование отчётов необходимо для отслеживания темпов работы, соответствия планам и своевременного принятия необходимых управленческих решений. Когда начальник отдела утверждает выполненные задания, он заносит эту информацию в отчёт. Сформированный отчёт отправляется руководителю. Рисунок 7. Диаграмма «Отчёт о работе» 11 5. Диаграмма «Выполнение полученного задания». Данная диаграмма отображает процесс получения, выполнения и согласования технического задания, а также процесс обмена данными между отдельными разработчиками. Разработчик получает от начальника отдела техническое задание и опционально материалы выполненного задания от другого разработчика (например, 3D-художник получает от художника концепт арты, по которым он должен моделировать). Передача материалов от разработчика к разработчику напрямую быстрее, чем включение материалов исключительно в ТЗ, потому что многие задания выполняются параллельно и подвергаются многочисленным правкам). Затем разработчик выполняет задание и отправляет его на утверждение начальнику. Также у него есть возможность отправить материалы задания другим разработчикам до утверждения (например, тестировщику для выявления ошибок). После проверки и получения комментариев разработчик корректирует свою работу до тех, пока она не будет окончательно утверждена. Рисунок 8. Диаграмма «Выполнение полученного задания» 12 3. Диаграмма состояний Диаграмма состояний строится для наглядной демонстрации основных состояний системы и переходов между этими состояниями. Преимуществом данной диаграммы является то, что на ней более наглядно и понятно отображён процесс работы системы в целом. На диаграмме состояний присутствуют начальное и конечное состояние, а также связанные с ними данные. Это могут быть деятельность, входное действие, выходное действие, событие и история состояния. Так как лучше всего диаграммы состояния подходят для описания одного объекта системы, то составим диаграмму состояний, описывающую процесс формирования и выполнения отдельного задания внутри разработки. На ней будут отражены все необходимые этапы: 1. Поиск задания. 2. Выполнение задания. 3. Проверка задания. 4. Утверждение задания. Также включим в схему несколько проверок (выполнено ли задание, нужны ли исправления, нужны ли дополнительные материалы). 13 Рисунок 9. Диаграмма состояний 14 4. Диаграмма деятельности Диаграмма деятельности – это UML-диаграмма, на которой отображаются действия, состояния которых описаны на диаграмме состояний. Диаграммы деятельности строятся для того, чтобы точно описать алгоритмы реализации выполняемых операций в системе. Составим несколько диаграмм деятельности для разных активностей. 1. Диаграмма «Выдача задания». На данной диаграмме подробно описывается процесс выдачи заданий начальником, в том числе с учётом составленного плана и степени его выполнения. Рисунок 10. Диаграмма «Выдача задания » 15 2. Диаграмма «Согласование ТЗ». На данной диаграмме описывается процесс согласования ТЗ между начальником и разработчиком. 3. Диаграмма «Выполнение задания». На данной диаграмме подробно описан процесс выполнения задания. Рисунок 11. Диаграмма «Согласование ТЗ» Рисунок 12. Диаграмма «Выполнение задания» 16 4. Диаграмма «Анализ отчёта о проделанной работе». На данной диаграмме описан процесс формирования отчёта о работе и его анализа, а также процесс принятия управленческих решений в соответствии со степенью соответствия плану. Рисунок 13. Диаграмма «Анализ отчёта о проделанной работе» 17 5. Диаграмма классов Диаграмма классов – это диаграмма, на которой отображены типы классов и их связи внутри системы. Построим диаграмму классов для сценария «Создание начальником отдела технического задания для разработчика» прецедента «Согласование ТЗ». Техническое задание не всегда выдаётся в электронном виде, однако при удалённой работе и при использовании аутсорса могут возникнуть ситуации, когда начальник и разработчик работают в разное время (например, находятся в разных часовых поясах). В этом случае выдача ТЗ в электронном виде предпочтительнее. В рассматриваемой ситуации начальник даёт разработчику конкретное техническое задание. Определим классы-сущности для диаграммы классов: начальник отдела, выдающий ТЗ – Boss; техническое задание – Task; ассеты, нужные для выполнения ТЗ – Asset; содержание ТЗ – TaskContent. Отдельный класс для содержания ТЗ создаётся по причине того, что в одно задание может включаться несколько разных ассетов, при этом один ассет может включаться в несколько разных ТЗ, например: задание «разработать анимацию стрельбы» требует использовать модель персонажа и модель оружия, те же модели используются в задании «создать текстуры для моделей». Опишем каждый класс более подробно: 18 - Boss (начальник): Таблица 1. Описание класса Boss - Task (задание): Параметр Значение Атрибуты (private) taskNumber (int) – номер ТЗ taskDate (date) – дата выдачи ТЗ taskDeadline (date) – дата необходимой сдачи работы (дедлайн) taskComplete (date) – дата сдачи работы Операции (public) Create() – создание нового задания SetInfo() – внести информацию о задании GetInfo() – получить информацию о задании Таблица 2. Описание класса Task Параметр Значение Атрибуты (private) Name (string) – имя начальника Department (string) - отдел Contact (string) – информация о способе связи с боссом Операции (public) AddBoss() – добавляет начальника, который может добавлять ТЗ RemoveBoss() – удаление начальника GetInfo() – получение информации о начальнике 19 - TaskContent (содержание задания): Параметр Значение Атрибуты (private) contentNumber (int) – номер содержания Операции (public) Create() – создать строку SetInfo() – внести информацию о строке GetInfo() – получить информацию о строке Таблица 3. Описание класса TaskContent - Asset (ассет): Параметр Значение Атрибуты (private) name (string) – название ассета type (string) – тип ассета Операции (public) AddAsset() – добавить ассет RemoveAsset() – удалить ассет GetInfo() – получить информацию об ассете Таблица 4. Описание класса Asset Опишем отношения между классами: 1. Boss – Task Отношение ассоциации, так как между данными классами обычная связь. Один босс может создавать несколько заданий, при этом задание может быть создано только одним боссом, поэтому это связь 1 (Boss) ко многим (Task). 20 2. Task – TaskContent Отношение композиции, так как строка задания – это часть задания. Каждое задание может включать несколько строк, при этом строка требования соответствует только одному заданию, поэтому это связь 1 (Task) ко многим (TaskContent). 3. TaskContent – Asset Отношение агрегации, так как ассеты – это части строки требования. Строка требования может включать в себя только один ассет, один ассет может включаться в разные строки требования, поэтому это связь 1(Asset) ко многим(TaskContent). Итоговая схема классов-сущностей и отношений между ними: Рисунок 14. Диаграмма классов 21 Заключение В данной работе были построены различные UML-диаграммы, предназначенные для упрощения создания потенциальной информационной системы. Приобретён опыт работы с UML-диаграммами. Для конкретного примера построены следующие диаграммы: диаграмма вариантов использования; диаграмма последовательности; диаграмма состояний; диаграмма деятельности; диаграмма классов. Для дальнейшего использования следует доработать систему, сделав её более полной и добавив в неё необходимые функции, которые могут потребоваться уже в ходе эксплуатации готовой системы. Список литературы 1. Бабич А. В. Введение UML [Электронный ресурс]. URL:https://intuit.ru/studies/courses/1007/229/info 2. Смирнов М. Е. UML – быстрый старт [Электронный ресурс]. URL: http://www.msmirnov.ru/public/UML_quick_start.pdf 3. Швецов, В. И. Базы данных [Электронный ресурс] : учебное пособие / В. И. Швецов .– М. : Интернет-Университет Информационных Технологий (ИНТУИТ), 2009. - 155 с. |