Проектирование системы управления проектами по разработке компьютерных игр в жанре RPG
Проектное решение организации процесса создания компьютерных игр в жанре RPG небольшими компаниями. Анализ процесса разработки компьютерных игр. Построение диаграмм функций системы управления проектами. Представлена модель системы управления проектами.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 10.09.2020 |
| Размер файла | 3,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Пермский филиал федерального государственного автономного образовательного учреждения высшего образования
"Национальный исследовательский университет
"Высшая школа экономики"
Факультет экономики, менеджмента и бизнес-информатики
Выпускная квалификационная работа
по направлению подготовки 38.03.05 Бизнес-информатика
образовательная программа "Бизнес-информатика"
Проектирование системы управления проектами по разработке компьютерных игр в жанре RPG
Яцков Григорий Александрович
Руководитель
В.О. Кушев
Пермь, 2020 год
Аннотация
Целью данной выпускной квалификационной работы является проектирование системы управления проектами для разработки компьютерных игр в жанре RPG.
Объектом исследования в работе являются системы управления проектами. Предметом исследования является проектное решение организации процесса создания компьютерных игр в жанре RPG небольшими компаниями.
Первая глава посвящена обзору литературы, которая использовалась при написании работы. В список обозреваемой литературы входят работы, посвященные различным этапам процесса разработки компьютерной игры, примеры реальных проектов, а также литература, посвященная моделированию информационных систем. Результатом является выделение общих этапов процесса разработки компьютерной игры в жанре RPG, а также освеженные знания о моделировании систем. Вторая глава содержит в себе детальное описание этапов процесса разработки компьютерной игры в жанре RPG и анализ существующих аналогов проектируемой системы управления проектами. В результаты этой главы включены особенности процесса разработки компьютерной игры, которые накладываются на набор функций системы управления проектами. В третьей главе представлено моделирование и построение диаграмм функций, входящих в проектируемую систему управления проектами. Четвертая глава содержит диаграммы, описывающие систему управления проектами как единое целое. Результаты третьей и четвертой главы имеют практическое применение и могут быть использованы при разработке системы управления проектами для разработки компьютерных игр в жанре RPG.
Оглавление
Введение
Глава 1. Обзор литературных источников
1.1 Обзор источников, связанных с процессом разработки компьютерных игр
1.2 Обзор источников, связанных с моделированием и проектированием информационных систем
Глава 2 Анализ процесса разработки компьютерных игр в жанре RPG
2.1 Особенности разработки игры в жанре RPG
2.2 Процесс разработки компьютерной игры в жанре RPG
2.3 Анализ используемых систем управления проектами
Глава 3. Построение диаграмм функций системы управления проектами
3.1 Построение диаграммы Use-Case
3.2 Построение диаграмм активностей
3.3 Построение диаграмм последовательностей
Глава 4. Построение модели системы управления проектами
4.1 Построение диаграммы классов
4.2 Проектирование базы данных
4.3 Построение диаграммы компонентов
4.4 Проектирование интерфейса
Заключение
Библиографический список
Приложения
Введение
В современном мире индустрия компьютерных игр стремительно развивается. С появлением новых возможностей для создания и продвижения своих творений, таких как новейшие удобные инструменты, многочисленные выставки для маленьких студий и самостоятельных разработчиков, а также платформы цифровой дистрибуции для продажи своих игр, больше и больше людей пробуют себя в данной области. Несмотря на это, далеко не всех разработчиков ждёт успех. Виной этому могут быть следующие причины: нерациональное и неверное планирование работы, выбор неподходящего набора инструментов и программного обеспечения, реализация визуальной составляющей игры в неподходящем для выбранного жанра стиля, проблемы с продвижением игры (маркетинг, продюсирование) и выводом ее на рынок. Помимо этого, для создания востребованной и успешной игры разработчикам зачастую не хватает организованности работы и взаимосвязи между различными процессами разработки, в связи с чем компьютерная игра не оправдывает ожидания как создателей, так и потребителей. Для решения вышеперечисленных сложностей, возникающих при разработке компьютерной игры, существуют некоторые руководства и методики, однако они направлены на большие студии, привязаны к дорогостоящим инструментам или имеют иные ограничения, что делает методику не применимой небольшими студиями или независимыми разработчиками. В случае с разработкой компьютерной игры в жанре RPG, требования к ведению процесса разработки возрастают, в связи с увеличенной степенью взаимодействия разных участников команды разработки между собой, так как для создания успешной игры в жанре RPG необходимо обращать особое внимание на взаимосвязанность каждого элемента, присущего данному жанру, а именно игрового мира, сюжета, неигровых персонажей, роли игрока в этом мире и так далее. Все эти элементы должны находиться в рамках сюжета и не выбиваться из общей картины.
Для достижения наибольшей эффективности в процессе разработки используются различные системы управления проектами. На сегодняшний момент при разработке компьютерных игр не используются системы управления проектами, которые были бы направлены именно на эту область. Более того, пока что не существует системы управления проектами, созданной специально для ведения разработки компьютерной игры в жанре RPG. В связи с этим можно сказать, что проблема, освещенная в данной работе, ещё не разрешена или не решена окончательно.
В связи с этим, возникает необходимость создания специализированной системы управления проектами, которая позволит эффективно вести разработку компьютерной игры силами как крупных и малых студий, так и отдельных независимых разработчиков, способной достигнуть успеха на рынке и принести выгоду её создателям и удовлетворение покупателям.
Объектом исследования работы являются системы управления проектами.
Предметами исследования выступают обоснования проектных решений организации процесса создания компьютерных игр в жанре RPG небольшими компаниями.
В рамках выпускной квалификационной работы достигается следующая цель: проектирование системы управления проектами для разработки игр в жанре RPG. Чтобы достигнуть поставленную цель, необходимо решить следующие задачи:
1. Провести анализ процесса разработки компьютерных игр в жанре RPG;
2. Провести анализ систем управления проектами, которые используются при разработке компьютерных игр;
3. Сформулировать функции, необходимые для улучшения эффективности проектируемой системы управления проектами;
4. Спроектировать выделенные функции системы управления проектами;
5. Спроектировать систему управления проектами с моделями выделенных функций.
В результате выполнения работы будет представлена модель системы управления проектами для разработки компьютерных игр в жанре RPG, которая будет включать в себя весь набор необходимых функций для ведения максимально эффективного процесса разработки, а также поможет разработчикам игры не допускать большую часть организационных ошибок и позволит ускорить процесс создания игры.
Глава 1. Обзор литературных источников
В данной главе представлен обзор литературы, посвященной разработке компьютерных игр, которая использовалась при получении информации о процессе создания компьютерных игр. Также в обзор были включены источники, предоставляющие данные о моделировании информационных систем, которые были использованы для построения диаграмм при проектировании системы управления проектами в работе.
1.1 Обзор источников, связанных с процессом разработки компьютерных игр
На сегодняшний день индустрия компьютерных игр привлекает к себе всё больше и больше внимания. Многие страны рассматривают данную сферу как один из факторов развития экономики, а с ростом популярности киберспорта как спортивной дисциплины, всё больше и больше государств спонсируют разработку компьютерных игр. Поэтому многие разработчики, дабы передать накопленный опыт, пробуют себя в роли писателей, описывая процесс разработки компьютерных игр, рассказывая какие-либо детали и тонкости. проект компьютерный игра
Роберт Нистром в своей книге "Шаблоны программирования игр" (Game Programming Patterns) [2] в деталях рассказывает об одном из этапов разработки компьютерных игр написании кода. Книга указывает на использование различных шаблонов программирования для связывания разных систем в коде игры, а также на способы устранения некоторых возникающих в ходе написания кода проблем. Данный источник полезен для более детального понимания этапа написания кода игры, а также для получения знаний о возникающих на данном этапе проблемах и способах их решений.
В работе Рафа Костера "Theory of Fun for Game Design" [4] описывается психологический аспект игрового дизайна. С этой точки зрения он затем рассматривает каждую часть игрового дизайна в разработке игр с комментариями в ключевых моментах. Эта необычная точка зрения может быть полезна для дополнения представления о роли гейм-дизайнера в процессе разработки компьютерной игры, а также данный источник даёт общую информацию об этапах процесса разработки.
Скотт Роджерс дает отличное представление о деталях игрового дизайна в своей книге "Level Up! The Guide to Great Video Game Design" [5]. Этот источник содержит информацию о различных ролях в разработке игр, какие знания требуются для каждой роли и какую функцию выполняет каждый участник. Более того, Скотт Роджерс тщательно описывает каждый этап разработки с информацией о действиях, которые должен предпринять каждый член команды. Этот источник особенно важен для работы из-за количества предоставленных деталей и идей. С такой информацией моделирование процесса разработки видеоигр потребует меньше усилий, а сама модель будет более детальной и точной.
Написание сценария является одним из самых важных аспектов видеоигры, потому что сюжет и история делают игру захватывающей и захватывающей. Клиент или игрок в нашем случае должен быть погружен в игровой процесс, чтобы обеспечить популярность игры и её успех на рынке. Источником информации о длительности этапа создания сюжета и проработки игрового мира является книга Флинта Дилля и Джона Зуура Платтена "The Ultimate Guide to Video Game Writing and Design". Они собрали важную информацию и основные правила, касающиеся построения персонажей, структуры рассказывания историй и ведения сюжета до конца игры [7]. Этот источник важен для работы из-за необходимости понимания времени и усилий, необходимых для создания хорошего сюжета, и отражения этого этапа при построении модели процесса.
В книге Коллена Маклина и Джона Шарпа "Games, Design and Play. A detailed approach to iterative game design" [8] в деталях описывается процессно-ориентированный подход к разработке игр. Эта книга сосредотачивает внимание на особенностях каждого этапа создания компьютерных игр - от концепции до выпуска. Данный источник также полезен для построения модели процесса разработки компьютерной игры.
Джейсон Шрейер в своей работе "Кровь, пот и пиксели" [9] описывает множество реальных примеров и историй разработки компьютерных игр в самых различных жанрах и разными командами. Для получения более детального представления о реалиях игровой индустрии и, как следствие, лучшего представления о процессе разработки компьютерных игр, этот источник имеет свою важность.
1.2 Обзор источников, связанных с моделированием и проектированием информационных систем
В монографии Остроуха А.В., Сурковой Н.Е. "Проектирование информационных систем" [13] представлена теория проектирования информационных систем. Приведены практические методы использования современных технологий проектирования информационных систем, выбора методов и средств проектирования, основанных на использовании CASE-средств. Приводятся краткие сведения об использовании методов моделирования предметной области в стандарте IDEF0 и IDEF3 и метода построения моделей данных и базы данных в стандарте IDEF1X, объединенных в единую методологию структурного подхода к проектированию информационных систем. Монография полезна для непосредственного проектирования системы управления проектами.
Шпак Ю.А. в своей работе "Введение в системы баз данных" [14] рассматривает и описывает процесс проектирования баз данных, разбирая каждый этап данного процесса и какие инструменты наилучше применимы на каждом из этапов. В книге также присутствуют примеры баз данных, которые имеют реальное практическое применение, а каждый описанный инструмент является используемым в современном мире. Автор излагает материал в понятной для любого читателя форме, избегая излишних сложностей и тонкостей теории баз данных. Данный источник полезен непосредственно для этапа проектирования информационной системы, в частности, проектирования базы данных.
Глава 2 Анализ процесса разработки компьютерных игр в жанре RPG
2.1 Особенности разработки игры в жанре RPG
Данный пункт был рассмотрен в курсовой работе "Создание методики для разработки компьютерных игр в жанре RPG" Яцкова Г.А [15], и для полноты исследования был заимствован в выпускную квалификационную работу.
Компьютерная ролевая игра (Role-Playing Game, RPG) - жанр компьютерных игр, который основан на игровом процессе настольных ролевых игр. В ролевой игре игрок управляет одним или несколькими персонажами, каждый из которых описан набором численных характеристик, способностей и навыков. В ролевую компьютерную игру обычно входят четыре элемента: ролевая система, исследование, сюжет и боевая система [1].
Ролевая система описывает способы создания, изменения и развития персонажей, у которых есть числовые характеристики и навыки, повышающие их эффективность в игре. Необходимыми элементами ролевой системы являются [1]:
- игрок управляет одним или несколькими уникальными персонажами. Это необходимое условие для всех ролевых игр. В отличие от стратегий, его персонажи уникальны и имеют имя;
- игрок постепенно улучшает характеристики и/или навыки (посредством внутриигровых значений, чаще всего очков опыта, получаемых за выполнение заданий, исследование мира, диалоги, сражения и так далее);
- в процессе прохождения происходят проверки характеристик и навыков;
- персонажи могут улучшать свои характеристики и навыки при помощи элементов снаряжения.
Данная особенность накладывает дополнительные требования к разработчикам. Помимо наличия всех обязательных элементов ролевой системы, необходимо предусмотреть, чтобы персонаж или персонажи игрока не стали слишком сильными по сравнению со всем окружающим миром, иначе игрок быстро потеряет интерес к игре.
Исследование описывает способы перемещения персонажа по игровому миру, всё, с чем он может взаимодействовать, например, игровые области, предметы и иные объекты. Для исследования необходимы следующие элементы:
- персонаж игрока может взаимодействовать с игровым миром и находить новые игровые области;
- персонаж игрока может находить предметы и хранить их в инвентаре;
- персонаж игрока может находить источники информации. Компьютерная ролевая игра без поиска информации невозможна в принципе;
- в игре должны присутствовать другие персонажи помимо игрока (неигровые персонажи).
Включение этих необходимых элементов потребует дополнительных усилий от гейм-дизайнера и дизайнера миров, так как необходимо проработать неигровых персонажей, находящихся в мире, а также детально продумать игровой мир, чтобы игрок мог постоянно ставить себе новые цели в нем, искать и исследовать что-то новое.
Сюжет включает в себя все элементы повествования, такие как игровой мир, его историю, персонажей, диалоги, задания, сюжетные линии и способы взаимодействия этих компонентов. Сюжетная составляющая содержит следующие необходимые элементы:
- персонаж игрока может получать информацию из информационных источников (намёки, цели, задания, навыки, заклинания, обучение);
- персонаж игрока может выполнять задания для продвижения по сюжету;
- персонаж игрока продвигается по цепочке связанных событий и играет в них свою роль;
- сюжет зависит от решений игрока, выборы, сделанные игроком, должны иметь последствия.
Для более глубокой проработки сюжета компьютерной игры сценаристу и гейм-дизайнеру необходимо потратить больше сил и времени на создание истории. Большая часть необходимых элементов для жанра RPG направлена на погружение игрока в мир компьютерной игры, а также на повышение количества повторных прохождений игры - реиграбельности.
Боевая система является способом разрешения конфликта в игре, она определяет каким образом персонаж игрока может сражаться с противниками. Боевая система может меняться от игры к игре, однако наиболее часто встречаемыми необходимыми элементами являются:
- эффективность в сражении зависит от характеристик и навыков персонажа;
- в сражениях присутствует элемент случайности. Практически во всех компьютерных ролевых играх присутствуют броски виртуальных кубиков и вероятностные функции;
Включение данных необходимых элементов потребует от разработчиков дополнительных усилий, так как боевая система должна захватывать игроков и награждать за их старания.
Таким образом, в разработке компьютерной игры в жанре RPG необходимо обращать особое внимание и уделять дополнительное время и силы следующим аспектам:
- написание истории и сюжета;
- проработка неигровых персонажей и их индивидуальности;
- разработка боевой системы;
- создание системы улучшения характеристик персонажа игрока;
- разработка системы инвентаря.
Эти особенности должны быть отражены в системе управления проектами, так как для удовлетворения требований жанра RPG, на перечисленные элементы необходимо отводить больше ресурсов, чем при разработке компьютерной игры в ином жанре, что, несомненно, повлияет на модель процесса создания игры.
2.2 Процесс разработки компьютерной игры в жанре RPG
Процесс разработки был подробно рассмотрен в курсовой работе "Создание методики для разработки компьютерных игр в жанре RPG" Яцкова Г.А [15], был заимствован в выпускную квалификационную работу в качестве вспомогательного материала.
Процесс разработки компьютерной игры в жанре RPG был детально рассмотрен в курсовой работе "Разработка и апробация методики создания компьютерной игры в жанре RPG". Данный процесс состоит из пяти главных этапов: концептирование, прототипирование, вертикальный срез, производство контента и тестирование. Список подпроцессов, входящих в каждый этап, представлен в списке ниже:
1. Концептирование;
1.1. Разработка собственного регламента;
1.2. Анализ трендов рынка;
1.3. Создание общей концепции сюжета;
1.4. Определение способов реализации элементов RPG;
1.5. Создание диздока;
2. Прототипирование;
2.1. Определение содержания прототипа;
2.2. Разработка первой версии боевой системы;
2.3. Разработка первой версии системы инвентаря;
2.4. Постановка сеттинга;
2.5. Сборка прототипа;
3. Вертикальный срез;
3.1. Определение содержания вертикального среза;
3.2. Начальная разработка сценария;
3.3. Улучшение боевой системы;
3.4. Создание локации;
3.5. Создание неигрового персонажа;
3.6. Создание начальной системы навыков;
3.7. Сборка вертикального среза;
4. Производство контента;
4.1. Создание сюжета;
4.2. Создание системы навыков;
4.3. Создание неигровых персонажей;
4.4. Создание мира;
4.5. Создание системы инвентаря и внутриигровых предметов;
4.6. Написание кода игры;
5. Тестирование;
5.1. Внутрикомандное тестирование;
5.2. Закрытый бета-тест;
5.3. Открытый бета-тест;
5.4. Исправление ошибок;
Описание этапов и подпроцессов приведено ниже.
Рисунок 2.4.1 - Верхний уровень модели
Входом для процесса является идея компьютерной игры, выходом, соответственно готовый продукт. управление состоит из множества форматов, фреймворков, элементов RPG, описанных выше, правил и ограничений. В качестве управления выступают участники разработки: программисты, гейм-дизайнеры, сценаристы, тестировщики, продюсеры, художники и игроки.
Первый уровень процесса разработки игры в жанре RPG представлен на рисунке 2.4.2.
Рисунок 2.4.2 - Первый уровень модели
Первым процессом является концептирование, входом в который является идея для игры. Этим процессом управляют формат дизайнерского документа, указанного на диаграмме как "Диздок", тренды рынка и элементы RPG, которые были перечислены выше и на диаграмме объединены в один управляющий элемент. Дизайнерский документ является основополагающей для дальнейшей разработки, поэтому он является выходом этого процесса. Механизмами этого процесса являются гейм-дизайнер и продюсер. Гейм-дизайнер оформляет идею игры в понятный для всей команды дизайнерский документ, а продюсер вносит в него коррективы, основываясь на анализе трендов рынка.
Вторым процессом является прототипирование, на вход которого подается дизайнерский документ из предыдущего процесса. Управляющими элементами здесь являются документ содержания, элементы RPG и фреймворк, так как на данном этапе разработка игры уже начинается. Механизмами этого этапа являются гейм-дизайнер, разработчик и художник. В ходе прототипирования появляется самая первая версия игры, в которой пробуются основные механики и особенности разрабатываемой игры. Полученный прототип является выходом процесса прототипирования.
Третьим этапом разработки компьютерной игры является вертикальный срез - процесс, в результате выполнения которого должна появиться следующая итерация разрабатываемой компьютерной игры, пригодной для демонстрации потенциальным спонсорам и покупателям. На вход этого этапа подается прототип, управляющими элементами являются документ содержания, фреймворк и правила магазинов, через которые демо-версия будет поставляться клиентам, а также кураторам магазинов, чтобы в дальнейшем иметь возможность выпустить игру в выбранном магазине. В разработке демо-версии участвуют такие механизмы, как гейм-дизайнер, художник и разработчик, а за взаимодействие с магазинами отвечает продюсер.
Четвертый этап процесса разработки компьютерной игры называется производством контента, который является наиболее продолжительным этапом. Управляющими элементами являются тренды рынка, в связи с тем, что продолжительность данного этапа ставит под угрозу техническую новизну разработки, поэтому при затянутом производстве необходимо следить за движением технологий и желаниями потенциальных покупателей, бюджетные ограничения и фреймворк. Механизмами данного этапа являются все члены команды, кроме продюсера. На выходе из этого этапа появляется уже заполненный, но ещё не готовый к выпуску для широкой аудитории, продукт.
Пятым этапом является тестирование - процесс, который направлен на поиск и исправление ошибок гейм-дизайна, разработки, баланса и прочего. Данный этап посвящен исключительно полированию продукта и подготовке к его выпуску. Управлением этапа тестирования являются чек-лист и формат отчета об ошибках. На вход процессу подается созданный продукт, который обрабатывается механизмами - тестировщиками и игроками, а на выходе появляется готовый к выпуску продукт.
Шестым и заключительным этапом является выпуск разработанной компьютерной игры, на вход которому подается протестированный и готовый к продаже продукт. На данном этапе элементом управления являются правила магазинов, в которые разработанная игра передается, а механизмом выступает продюсер, который налаживает связи с магазинами, собирает статистику и следит за продажами.
Модель этапа концептирования представлена на рисунке 2.4.3.
Рисунок 2.4.3 - Модель этапа концептирования
Первые два процесса этапа - разработка собственного регламента и анализ трендов рынка - являются подготовительными процессами к главному процессу, которым является создание дизайнерского документа. Разработка небольшого и понятного для всей команды регламента устранит недопонимания при создании дизайнерского документа разными участниками команды, анализ трендов рынка в свою очередь поможет при выборе художественного стиля, музыкального оформления и общей тематике разрабатываемой игры. Далее на этапе концептирования необходимо определить базовую идею сюжета и способы реализации элементов RPG, описанных в пункте 1.1. В результате процесса создания дизайнерского документа получается выход этого этапа - дизайнерский документ, описывающий видение разрабатываемой игры всей команде.
Следующим детализированным этапом является прототипирование (рис. 2.4.4).
Рисунок 2.4.4 - Модель этапа прототипирования
Процесс определения содержания прототипа предназначен для обозначения строгих границ при создании прототипа, в целях предотвращения получения прототипа с излишней сложностью. Управляющими элементами являются формат документа содержания и элементы RPG для выявления аспектов жанра RPG, которые будут отражены в прототипе. После этого начинаются этапы разработки первых версий элементов RPG, таких как боевой системы, системы инвентаря и сеттинга игры. Данные этапы могут проходить в разном порядке или параллельно. После их завершения начинается этап сборки прототипа, где все разработанные элементы сводятся воедино.
Следующим этапом является создание вертикального среза, его модель представлена на рисунке 2.4.5.
Рисунок 2.4.5 - Модель этапа создания вертикального среза
Как и в случае с этапом прототипирования, первым подпроцессом этапа создания вертикального среза является определение содержания данного этапа, то есть, какие элементы и в каком объеме будут отражены в конечном результате. На выходе этого подпроцесса получается документ содержания среза, который будет являться входом для каждого последующего подпроцесса, кроме финального. После подготовительной работы в виде определения содержания, начинаются подпроцессы, связанные непосредственно с наполнением вертикального среза со спецификой разработки игры в жанре RPG - начальная разработка сценария, улучшение боевой системы, полученной в результате прототипирования, создание локации и неигрового персонажа для возможной демонстрации потенциальным игрокам, и создание начальной системы навыков. Выходы из каждого подпроцесса отправляются на финальный этап - сборку вертикального среза, результатом которого будет готовый вертикальный срез разрабатываемой игры [5].
Следующим этапом является производство контента, который является наиболее продолжительным и трудозатратным процессом. Модель этого этапа представлена на рисунке 2.4.6.
Рисунок 2.4.6 - Модель этапа производства контента
Этап производства контента можно разбить на несколько подпроцессов, такие как написание сюжета для игры, создание игрового мира и неигровых персонажей, разработка системы улучшения навыков игрового персонажа и системы инвентаря, а также наполнение игры внутриигровыми предметами. Для RPG жанра каждый из элементов должен быть соединен с остальными, например, внутриигровые предметы должны гармонично вписываться в сюжет игры, как и неигровые персонажи. На этапе производства контента происходит активная работа гейм-дизайнера, сценариста, художника и программиста, так как создается множество новых элементов и механик игры. В результате этого этапа появляется разработанная, но пока что не протестированная игра [6].
Предпоследним этапом разработки компьютерной игры является тестирование, которое для игры в жанре RPG является очень трудоемким этапом, в связи с обилием тестируемых объектов. Модель данного этапа представлена на рисунке 2.4.7 (см. рис. 2.4.7).
Рисунок 2.4.7 - Модель этапа тестирования
Для наиболее полного тестирования игры в жанре RPG предпочтительно проводить его в несколько этапов. Первым тестированием является внутрикомандное тестирование или тестирование непосредственно со стороны разработчиков. Данное тестирование направлено на проверку элементов игры без геймплея, например, тестирование функциональности внутриигровых предметов, диалогов с неигровыми персонажами и других механик. После исправления ошибок, найденных при этом тестировании, начинается закрытый бета-тест, который проводится ограниченным числом игроков, которые в ходе игры могут столкнуться с какими-либо ошибками и отправить отчеты об этих ошибках разработчикам. Точно так же работает открытое бета-тестирование, однако количество игроков на открытом этапе значительно возрастает. После каждого этапа тестирования проводится исправление ошибок, в результате на выходе получается протестированная и готовая к выпуску игра [7].
В результате проведенного анализа была построена модель стандартного процесса разработки компьютерных игр в жанре RPG, которая будет использована впоследствии при проектировании системы для управления проектами.
2.3 Анализ используемых систем управления проектами
Перед проектированием системы управления проектами специально для разработки игр в жанре RPG, необходимо узнать, какие системы управления проектами используются сейчас, и какие сложности могут возникать у разработчиков игры при использовании той или иной системы управления.
Одним из используемых инструментов является Trello - простой и универсальный онлайн-инструмент в виде веб-версии, мобильных приложений для Android и IOS, а также расширения для браузера Google Chrome. Сервис реализован по принципу канбан-доски. Канбан-доска является одним из инструментов, который может использоваться при внедрении метода управления разработкой, представляет из себя несколько столбцов, каждый из которых отражает степень готовности задачи-карточки, перемещающиеся между столбцами., на которой находятся списки, внутри карточки с задачами. К преимуществам Trello можно отнести простой и понятный интерфейс, возможность настраивать доски и списки под проект в любой сфере, а также множеством дополнений, подключаемых к доскам. Недостатками являются: отсутствие диаграммы Ганта, в бесплатной версии можно подключить только один плагин к доске, легко запутаться в карточках и досках при ведении большого проекта.
Следующим используемым инструментом является Jira. Это система управления проектами с веб-версией и мобильными приложениями для Android и iOS. Основан на методологии Agile, представляет собой доску с карточками и является самым популярным среди команд разработки. Плюсами Jira является огромное количество подключаемых дополнений, позволяющих добавлять необходимые инструменты в любых количествах, возможность построения диаграммы Ганта и создания отчетов, понятный интерфейс. К недостаткам можно отнести то, что изначально эта система управления проектами рассчитана на специализированные команды разработчиков, включает в себя возможности привязки к программному коду и не всегда необходимые для других проектов опции, что требует дополнительного обучения разработчиков игры.
Ещё одним сервисом, который разработчики используют для организации своей работы, является Wrike. Эта система подходит под требования, которым должна отвечать система управления проектами, и имеет в себе такие функциональные возможности, как диаграммы Ганта, управление ресурсами и загрузкой команды, обновлением задач в реальном времени, настраиваемые статусы и рабочие процессы. В целом, система предлагает множество возможностей для повышения эффективности командной работы над проектом, однако имеет свои недостатки, в частности, долгий период ознакомления с программой и высокая стоимость: от 9.80$ за пользователя в месяц при годовой оплате.
Одна из самых распространенных систем для повышения эффективности ведения разработки это Microsoft Project - инструмент управления проектами, портфелями и ресурсами, предоставляющий интегрированные возможности планирования. Сервис позволяет организовать совместную работу вне зависимости от места расположения сотрудников, а также проконтролировать процесс для достижения необходимых результатов. Данное решение включает в себя такие функции, как пошаговая разработка проекта, наблюдение прогресса задачи на временной шкале, создание задач, распределение ресурсов, построение модели, приближенной к реальности, а также расчет критического пути и возможность добавление макросов и VBA-программ. К недостаткам можно отнести ограниченные возможности подключения к серверу и некоторую ненадежность в работе с сервером.
Третьим примером является система управления проектами под названием Smartsheet. Этот инструмент является платформой для управления и автоматизации работы. Сервис предоставляет возможность совместной работы, поскольку в нём централизованно содержатся все заметки, папки, файлы и командные обсуждения, а получить доступ к этой информации можно с любого браузера и операционной системы. Механизмы для организации процесса включают в себя оболочку электронных таблиц, в которых можно автоматизировать процессы, независимо от их сложности. Smartsheet отвечает всем требованиям, выдвигаемым к системам управления проектами, однако многие пользователи отмечают неудобный и не интуитивный интерфейс и высокую стоимость.
Как было сказано ранее, проектируемая система управления проектами предназначена для небольших команд разработчиков компьютерных игр в жанре RPG, что накладывает некоторые дополнительные требования и ограничения к проектируемой системе. Основным ограничением выступает простота системы управления проектами - интерфейс должен быть интуитивно понятен, а набор функций исчерпывающим и без излишеств. В таком случае команде разработки не придется тратить дополнительные ресурсы на освоение системы или на поиск нового сотрудника специально для организации рабочего процесса. Выбор жанра RPG накладывает дополнительные требования на функции системы управления проектами. Этапы процесса разработки компьютерной игры в жанре RPG были описаны ранее в пункте 1.1, ими являются: концептирование, прототипирование, вертикальный срез, производство контента, тестирование и выпуск. Система управления проектами должна предоставлять возможность вести поэтапную работу над проектом, то есть необходима функция, позволяющая делить проект на этапы.
Накладывая ограничения на рассмотренные системы управления проектами можно выделить несколько критериев, которым должна отвечать удобная, практичная и в то же время функциональная система управления проектами. Проектируемая система управления проектами должна быть сбалансированной между простотой и функциональностью. Для начала необходимо оценить, насколько существующие системы управления проектами подходят для разработчиков компьютерных игр. Необходимыми функциями являются: наличие диаграммы Ганта, наличие канбан-доски, возможность разделения проекта на этапы, создание и обновление задач, распределение ресурсов, настройка статусов задач, расчет критического пути, возможность вести параллельную работу в реальном времени, быстрота и простота освоения инструмента.
Таблица 2.3.1 содержит в себе сравнительный анализ рассмотренных систем управления проектами по выделенным критериям.
Таблица 2.3.1 - Сравнительный анализ систем
|
Wrike |
MS Project |
Smartsheet |
Trello |
Jira |
||
|
Диаграмма Ганта |
+ |
+ |
+ |
- |
+ |
|
|
Деление на этапы |
- |
+ |
- |
- |
- |
|
|
Создание задач |
+ |
+ |
+ |
+ |
+ |
|
|
Распределение ресурсов |
+ |
+ |
+ |
+ |
+ |
|
|
Настройка статусов |
+ |
+ |
+ |
+ |
+ |
|
|
Критический путь |
- |
+ |
- |
- |
+ |
|
|
Параллельность работ |
+ |
+- |
+ |
+ |
+ |
|
|
Канбан-доска |
- |
- |
+ |
+ |
+ |
|
|
Простота освоения |
+- |
+- |
- |
+ |
+- |
Из таблицы 2.3.1 можно заметить, что в каждой используемой системе управления проектами есть недостатки, которые нужно устранить. Эти недостатки подводят к функциональным и нефункциональным требованиям к проектируемой системе управления проектами. Так как проектируемая система направлена на разработчиков компьютерных игр у которых может не быть опыта в ведении командных проектов и использовании систем управления проектами, необходимо иметь наибольшую наглядность в проектируемой системе. Наиболее наглядными из функций систем управления проектами являются канбан-доска и диаграмма Ганта. Канбан-доска позволит участникам процесса разработки наблюдать состояние задач, их количество и ответственных за выполнение задачи, а диаграмма Ганта даст возможность видеть временные рамки и последовательность поставленных задач. Ещё одним шагом для повышения интуитивности пользования системы и ещё большей наглядности будет разделение всей системы на два взаимосвязанных блока - канбан-доску со столбцами и задачами и непосредственно систему управления проектами с диаграммой Ганта, на которой автоматически выстраиваются задачи с канбан-доски в соответствии с указанными дедлайнами и ответственными за задачу. Редактирование задач или ответственных в любом блоке приводило бы к их изменению в другом блоке. Помимо этого, для проектируемой системы необходима функция, позволяющая настраивать процесс разработки компьютерной игры путем разбиения его на этапы разработки компьютерной игры в жанре RPG. Разработчики должны иметь возможность убирать ненужные им этапы по желанию или добавлять собственные. Ещё одним дополнением будет функция глобального таймера, который заводился бы при создании проекта для каждого этапа и отображался на протяжении всей работы во время этого этапа. Такое введение позволило бы повысить наглядность оставшегося времени на работу над каждым этапом и давало бы осознание степени завершенности этапа.
Таким образом, проектируемая система управления проектами состоит из двух блоков: канбан-доска и диаграммы Ганта. Эти блоки являются взаимосвязанными, задачи с канбан доски в автоматическом режиме попадают в блок системы управления проектами и отображаются на диаграмме Ганта, то же самое происходит с назначением ответственных на задачу и их отображением в ресурсах, что делает всю систему понятной и быстрой в освоении.
Таким образом, функциональными требованиями к блоку канбан-доски являются:
· создание задач на доске;
· назначение ответственного за задачу;
· постановка дедлайна для задачи;
· перенос задач с диаграммы Ганта на канбан-доску;
Функциональные требования к блоку диаграммы Ганта:
· настройка этапов процесса разработки компьютерной игры;
· перенос задач с канбан-доски на диаграмму Ганта;
· автоматическое построение диаграммы Ганта;
· добавление задач на диаграмму Ганта;
· построение критического пути;
Функциональными требованиями к системе управления проектами в целом:
· настройка этапов проекта при его создании;
· создание таймера для каждого этапа проекта;
· синхронизация задач с канбан-доски с задачами в блоке диаграммы Ганта и наоборот;
· синхронизация ответственных за задачу с канбан-доски с пулом ресурсов в блоке диаграммы Ганта и наоборот;
· возможность ведения параллельной работы с системой управления проектами несколькими участниками;
Нефункциональными требованиями являются:
· понятность и простота интерфейса;
Таким образом, в первой главе был проведен анализ процесса разработки компьютерных игр в жанре RPG, особенности которого были учтены при выделении функциональных и нефункциональных требований к проектируемой системе управления проектами. Также был проведен анализ систем управления проектами, которые используются при разработке компьютерных игр на данный момент, что также было использовано при формулировании функций в проектируемой системе управления проектами.
Глава 3. Построение диаграмм функций системы управления проектами
3.1 Построение диаграммы Use-Case
Проектирование системы управления проектами началось с построения диаграммы прецедентов (рис. 3.1.1).
Рисунок 3.1.1 - Use-case диаграмма
На построенной диаграмме находится актор - пользователь системы, ответственный за ведение проекта. Ему доступны такие функции, как создание проекта, редактирование канбан-доски и редактирование диаграммы Ганта. Создание проекта включает в себя настройку этапов разработки компьютерной игры и настройку таймеров для каждого этапа. Редактирование канбан-доски состоит из изменения столбцов и изменения задач, в которые включены идентичные прецеденты удаления и добавления столбцов и задач соответственно, в создание задачи, в свою очередь, включены прецеденты постановки дедлайна и назначение ответственного. В прецедент "Редактирование диаграммы Ганта" включены прецеденты создания ресурса и создание задачи, в который включены прецеденты для выделения ресурса и постановки дедлайна.
3.2 Построение диаграмм активностей
Чтобы определить конкретное выполнение каждой функции, которые на диаграмме являются прецедентами, необходимо описать каждую функцию с помощью диаграмм деятельности. Первой диаграммой является диаграмма прецедента "Создание проекта", в которую включены прецеденты "Настройка этапов" и "Настройка таймеров" (рис. 3.2.1).
Рисунок 3.2.1 - Создание проекта
Создание проекта начинается с запроса на создание проекта от пользователя, на который система отвечает открытием формы создания проекта. Пользователь заполняет форму создания проекта и запрашивает следующую форму - создание этапов проекта, после открытия которой пользователь заполняет данную форму. После заполнения формы создания этапов пользователь может выбрать создать таймеры для этапов или нет. Если пользователь выбирает создание таймеров, то система открывает форму создания таймеров для этапов, которую пользователь заполняет, а система сохраняет. Далее пути соединяются на закрытии формы создания проекта, после чего настройки проекта сохраняются, и система открывает окно канбан-доски.
Следующим прецедентом является "Создание ресурса", который включен в прецедент "Редактирование диаграммы Ганта". Диаграмма представлена на рисунке 3.2.2.
Рисунок 3.2.2 - Создание ресурса
Функция создания ресурса начинается с отправления пользователем запроса на создание ресурса, на что система реагирует открытием формы создания ресурса. После этого пользователь заполняет форму создания ресурсов, и система сохраняет созданный ресурс в проекте, после чего форма создания ресурса закрывается.
На рисунке 3.2.3 представлена диаграмма функции создания задач на канбан-доске.
Рисунок 3.2.3 - Удаление задачи
Пользователь отправляет запрос на создания задачи на канбан доске, на что система открывает форму создания задач. После этого пользователь заполняет форму создания задач, затем система проверяет заполненную форму на совпадения в пуле уже созданных задач. При наличии задачи с таким же названием, система выводит сообщение о существовании такой задачи и возвращает форму создания задачи. Если задачи с таким названием не существует, то система добавляет задачу в пул задач, добавляет задачу в выбранный в форме создания пользователем столбец на канбан-доске, включает задачу в диаграмму Ганта и закрывает форму создания задачи.
Следующей функцией является функция добавления столбцов на канбан-доску из блока канбан-доски (рис. 3.2.4).
Рисунок 3.2.4 - Добавление столбцов
Функция начинается с запроса пользователя на создание столбца. После этого система открывает форму создания столбца, которую пользователь заполняет. Далее следует проверка, существует ли уже в системе столбец с таким названием, если существует, то система выводит сообщение о существовании такого столбца и возвращает форму создания столбца. Если столбец с таким названием не существует, система сохраняет его на канбан-доске и закрывает форму создания столбцов.
На рисунке 3.2.5 представлена диаграмма функции удаления столбцов с канбан-доски.
Рисунок 3.2.5 - Удаление столбцов
После поступления запроса от пользователя производится проверка на наличие задач в удаляемом столбце. При наличии задач в столбце система выводит сообщение с вопросом о подтверждении удаления, после чего пользователь может как отменить удаление, так и подтвердить его. Если пользователь решил удалить столбец, то задачи из этого столбца система сохраняет в пуле нераспределенных задач и удаляет столбец. В случае отсутствия задач в удаляемом столбце, система удаляет выбранный пользователем столбец и сохраняет канбан-доску.
Рисунок 3.2.6 содержит диаграмму функции удаление задачи с канбан-доски.
Рисунок 3.2.6 - Удаление задачи
Как и каждая функция, удаление задачи начинается с запроса пользователя на удаление. После этого выбранная пользователем задача сначала удаляется с канбан-доски, так как функция вызывается в блоке канбан-доске, затем выбранная задача удаляется с диаграммы Ганта, затем диаграмма перестраивается, и система сохраняет оба блока.
3.3 Построение диаграмм последовательностей
Для определения в какой момент система отвечает на действия пользователя были построены диаграммы последовательностей для каждой функции. На рисунке 3.3.1 представлена диаграмма, описывающая создание проекта.
Рисунок 3.3.1 - Создание проекта
Пользователь запрашивает создание проекта у системы, после чего система активируется и открывает форму создания проекта, которую пользователь заполняет. В необходимый момент пользователь запрашивает создание таймеров, система открывает форму их создания, в которую пользователь вносит необходимую информацию, после чего пользователь отправляет сообщение сохранить проект, и система сохраняет настройки проекта.
Следующей диаграммой является создание ресурса на диаграмме Ганта (рис 3.3.2).
Рисунок 3.3.2 - Создание ресурса
Эта диаграмма достаточно проста. Пользователь запрашивает создание нового ресурса у системы, на что система отвечает открытием соответствующей формы. После этого пользователь передает данные о ресурсе системе при помощи формы, система сохраняет этот ресурс.
На рисунке 3.3.3 представлена диаграмма функции создания задачи.
Рисунок 3.3.3 - Создание задачи
Функция начинается точно так же, как и предыдущая - с запроса пользователя на создание задачи и открытие системой формы создания задачи. Далее пользователь передает данные о задаче, и система проверяет внесенную информацию. При наличии недоступности ресурса, который пользователь хотел назначить на задачу, ему вернется сообщение от системы, уведомляющее пользователя об ошибке. При устранении корректном внесении информации задача появится на канбан-доске и диаграмме Ганта, которая обновится, подстраиваясь под новую задачу.
На рисунке 3.3.4 представлена диаграмма функции создания столбца на канбан-доске.
Рисунок 3.3.4 - Создание столбца
Так как столбцов на канбан-доске может быть множество, весь процесс не отличается сложностью. После передачи данных о новом столбце системе, она проверяет правильность внесенной информации. При наличии столбца с таким же названием, система отправляет пользователю сообщение об ошибке с соответствующим содержанием. После устранения ошибок, столбец сохраняется системой на канбан-доске.
На рисунке 3.3.5 представлена диаграмма функции удаления столбца с канбан-доски.
Рисунок 3.3.5 - Удаление столбца
После запроса пользователя на удаление столбца, система делает проверку на наличие задач в выбранном столбце. При наличии задач в столбце, система сообщает об этом пользователю и запрашивает дополнительное подтверждение. Если пользователь подтверждает удаление столбца, несмотря на наличие в нем задач, система сохраняет задачи в пуле задач, помечая их находящимися вне столбцов, и удаляет столбец из системы.
Рисунок 3.3.6 содержит диаграмму функции удаления задачи.
Рисунок 3.3.6 - Удаление задачи
Данная функция отличается своей простотой, в связи с отсутствием вложенных элементов, как в случае со столбцом, например. При запросе пользователя на удаление задачи, система удаляет задачу со всех блоков (канбан-доски и диаграммы Ганта), после чего перестраивает диаграмму Ганта, подстраивая её под изменения.
Глава 4. Построение модели системы управления проектами
4.1 Построение диаграммы классов
В качестве начала проектирования системы управления проектами для разработки компьютерных игр в жанре RPG была создана диаграмма классов, из которых состоит проектируемая система управления проектами. Всего было выделено 8 классов, их наименования, атрибуты и относящиеся к ним операции представлены в списке ниже:
1. Проект: атрибуты - идентификатор проекта, наименование проекта, этапы проекта, таймеры этапов; операции - сохранить проект, переключить этап;
2. Канбан-доска: атрибуты - идентификатор проекта, количество столбцов; операции - синхронизировать задачи;
3. Диаграмма Ганта: атрибуты - идентификатор проекта, ось времени, задачи; операции - синхронизировать задачи, обновить диаграмму, построить диаграмму;
4. Пул задач: атрибуты - количество задач, идентификаторы задач; операции - синхронизировать задачи;
5. Пул ресурсов: атрибуты - количество ресурсов, идентификаторы ресурсов, доступность ресурсов; операции - добавить ресурс, удалить ресурс, синхронизировать ресурсы;
6. Задача: атрибуты - идентификатор задачи, название задачи, описание задачи, ответственный, идентификатор ресурса;
7. Ресурс: атрибуты - идентификатор ресурса, количество единиц ресурса, название ресурса;
8. Столбец: атрибуты - название столбца, количество задач, позиция на доске; операции - добавить задачу, удалить задачу.
Некоторые операции необходимо пояснить более детально. Операция "Синхронизировать задачи" присутствует в трех классах, она подразумевает под собой возможность синхронизировать задачи между канбан-доской, диаграммой Ганта и пулом задач, чтобы в каждом блоке системы управления проектами задачи были одинаковыми. То же самое происходит в операции "Синхронизировать ресурсы", только по отношению к ресурсам. Задачи, создаваемые на канбан-доске, должны иметь ответственного за эту задачу, список доступных ответственных синхронизирован с пулом ресурсов. Операция "Переключить этап" в классе "Проект" обозначает смену фазы проекта и его переход на новый этап с соответствующим таймером.
Подобные документы
Сущность управления проектами, этапы его реализации и необходимые для этого знания, порядок составления и назначение Плана управления проектом. Концепция тройственной ограниченности. Использование программы MS Oficce Project в управлении проектами.
реферат [24,9 K], добавлен 16.11.2009Проектирование корпоративных информационных систем. Автоматизация процесса выполнения лабораторных работ по дисциплине "Управление программными проектами". Построение модели ИС учебного процесса: архитектура, формализация пользовательских требований.
дипломная работа [1,1 M], добавлен 20.08.2017Разработка методов сетевого планирования как способа управления проектами. Характеристика компьютерных программ Microsoft Project Server, Time Line and Sure Trak Project Manager, Open Plan, Primavera и Spider Project для автоматизации работы предприятий.
реферат [152,4 K], добавлен 10.02.2012Внедрение системы управления проектами Microsoft Project 2003 в Московский институт экономики, менеджмента и права для автоматизации учета выполнения дипломных проектов. Сравнительная характеристика систем управления проектами в России и за рубежом.
дипломная работа [1,4 M], добавлен 25.10.2013Разработка системы управления проектами для компании ЗАО "Диакон". Экономические параметры разработки и внедрения электронной информационной системы. Технология разработки программного обеспечения. Выбор типа графического интерфейса, его составляющие.
дипломная работа [1,4 M], добавлен 10.06.2014Обзор рынка Информационных технологий. Современные автоматизированные системы управления проектами и их классификация. Open Plan (Welcom Software) - система, предлагающая решение по управлению проектами масштаба корпорации. Основные модули Open Plan.
курсовая работа [630,9 K], добавлен 24.02.2010Принцип работы и задачи информационных систем управления проектами. Методы критического пути, анализа и оценки планов. Сетевые модель и график, виды путей. Информационный обмен между предприятиями, классификация информационных систем и их рынки сбыта.
контрольная работа [17,0 K], добавлен 18.11.2009Изучение возможностей системы YouTrack. Аналитический обзор ее аналогов и их функциональности. Анализ требований к системе управления проектами и надстройке. Визуализация данных. Проектирование интерфейса надстройки. Определение технологий реализации.
курсовая работа [2,3 M], добавлен 13.09.2017Необходимая терминология и основные программные продукты для управления проектами. Краткое ознакомление с системами: Project, Primavera, Spider Protect и Open Plan. Корпоративное управление проектами. Отличительные черты программного обеспечения СКПК.
контрольная работа [1,3 M], добавлен 13.09.2010Общие принципы управления проектами как процесс планирования, организации и контроля за состоянием его задач и ресурсов. Инструменты управления проектами от Microsoft. Описание ресурсов и затрат. Контроль хода выполнения, технология подготовки отчетов.
лекция [1,6 M], добавлен 15.03.2014
