Проектирование модуля планирования и разработки игры
Анализ исследований, изучающих использование игр в образовательных целях, и описание создания модуля планирования и разработки игры "IT-менеджер" для обучения студентов навыкам командной разработки. Построены диаграммы UML для описания бизнес-процессов.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 23.09.2018 |
| Размер файла | 1,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Аннотация
Данная работа содержит анализ исследований, изучающих использование игр в образовательных целях, и описание создания модуля планирования и разработки игры «IT-менеджер» для обучения студентов навыкам командной разработки. Построены диаграммы UML для описания бизнес-процессов и взаимодействия системы. Создание приложения производилось в Microsoft Visual Studio 2015 с использованием языка программирования C# и технологии WPF для построения клиентского приложения.
Работа включает: 66 страниц формата А4 основного текста (3 главы), 31 иллюстрацию, 3 таблицы, 6 формул и 9 приложений.
Библиографический список содержит 22 источника.
Оглавление
- Введение
- Глава 1. Анализ и формализация требований к разрабатываемому модулю
- 1.1. Обзор исследований, изучающих использование игр в обучении
- 1.2. Сравнение традиционной и гибкой методологий разработки программного продукта
- 1.3. Описание требований к модулю планирования и разработки игры
- 1.4. Анализ существующих решений
- 1.4.1. Game Dev Tycoon
- 1.4.2. Game Corp DX
- 1.4.3. SimulTrain
- 1.5. Сравнение игровых симуляторов
- Глава 2. Проектирование модуля планирования и разработки
- 2.1. Построение архитектуры игры
- 2.2. Моделирование алгоритмов, реализуемых в программе
- 2.3. Описание статической структуры системы
- 2.4. Описание поведения системы
- 2.5. Описание проектирования графического интерфейса
- 2.5.1. Окно этапа планирования
- 2.5.2. Окно этапа разработки
- Глава 3. Реализация и тестирование разрабатываемой программы
- 3.1. Реализация модуля игры
- 3.1.1. Описание разработанных классов игровой модели
- 3.1.2. Реализация разработанных алгоритмов
- 3.2. Тестирование и отладка программы
- 3.3. Проведение апробации игры
- Заключение
- Библиографический список
- Приложение
Введение
Современное образование в области IT_технологий предоставляет для студентов и школьников теоретические знания, которые они получают из различных учебников и накопленных знаний преподавателей, а также практические уроки, целью которых является разработка программ, реализующих различные задачи, поставленные преподавателями. Существуют научные доказательства, что лекционные материалы гораздо меньше усваиваются обучающимися, в отличии от выполнения практических заданий [1]. Однако изучаемый материал еще лучше усваивается, если проводить занятия по принципу игры, так как игровая форма обучения соединяет в себе сознательную и чувственную форму восприятия информации и активное взаимодействие между учениками [2].
Игровые формы обучения позволяют активизировать умственную деятельность на решение сложных задач, и в связи с этим необходимо как можно больше добавлять в процесс обучения игровую составляющую.
В данной работе рассматривается сфера обучения студентов навыкам программной инженерии, где они должны разбираться как правильно вести IT-проекты в командной разработке.
Существует проблема, что игровой процесс обучения достаточно сильно зависит от знаний преподавателя и способности привлечь аудиторию к взаимодействию друг с другом. К тому же для проведения обучающей игры для большой аудитории, как правило, требуется увеличение количества времени на игру, либо добавление новых ведущих и ресурсов на тот же промежуток времени.
Частично решить данную проблему может внедрение в процесс обучения программы, которая представляет собой игру, построенную на базе ряда тем учебных дисциплин программной инженерии. В этой игре будет представлена гибкая методология командной разработки программного обеспечения, где на этапах планирования и разработки в зависимости от навыков работников и случайно происходящих событий будут меняться условия.
Объект исследования - обучение студентов навыкам командной разработки при помощи деловой игры.
Предмет исследования - программное средство, используемое для обучения управления программными проектами на этапах планирования и разработки.
Целью данной работы является создание модуля планирования и разработки игры «IT_менеджер» для обучения студентов навыкам программной инженерии и разработки программного продукта в команде.
Исходя из указанной цели, можно выделить следующие задачи:
1. Выполнить анализ исследований современных средств обучения с помощью игр, определить требования к разрабатываемой системе и изучить существующие аналоги, отражающие процесс разработки программного продукта.
1.1. Выполнить анализ исследований, изучающих использование обучающих игр, определить преимущества и главные аспекты, которые влияют на качество игр такого типа при их создании.
1.2. С учетом выявленных ограничений определить требования к разрабатываемому модулю планирования и разработки и составить техническое задание на его разработку.
1.3. Проанализировать и сравнить наиболее значимые обучающие игровые симуляторы, связанные с разработкой программных продуктов, выявить их достоинства и недостатки.
1.4. Выполнить анализ наиболее значимых и популярных методологий разработки программного обеспечения, сравнить их по ключевым параметрам и выбрать наиболее подходящую для использования в игре.
2. Выполнить проектирование модуля планирования и разработки.
2.1. Разработать алгоритмы для расчета ожидаемого и реального количества строк кода для разработки модуля и затрачиваемой длительности разработки и тестирования в зависимости от персональных характеристик выбранных работников.
2.2. Описать логику взаимодействия пользователя с программой и статическую структуру системы на этапах планирования и разработки.
3. Создать модуль игры «IT_менеджер» с использованием графического интерфейса и выполнить его тестирование.
3.1. Создать программный модуль, отвечающий за этап планирования и разработки.
3.2. Построить несколько сценариев использования программы, и проверить работоспособность разработанного модуля.
Для решения поставленных задач необходимо применить различные методы исследования. Теоретический анализ литературных источников позволит определить проблемы, которые были обнаружены ранее другими исследователями по данной тематике, и выделить преимущества, которые могут быть достигнуты при реализации рассматриваемой системы. Сравнение существующих решений даст понятие об их достоинствах и недостатках для будущего разрабатываемого приложения. А с помощью объектно-ориентированного языка программирования будет создан модуль для игры «IT_менеджер».
Практическая значимость результатов заключается в том, что разработанный модуль планирования и разработки будет использоваться в игре «IT_менеджер», которая будет обучать пользователей навыкам командной разработки по гибкой методологии.
Глава 1. Анализ и формализация требований
к разрабатываемому модулю
Тема данной работы направлена на создание игры для обучения пользователей командной разработке программных продуктов. Существуют стандартные способы обучения, где на занятиях преподаватель в начале рассказывает лекционный материал учащимся, а затем на практике они отрабатывают эти знания. В конечном итоге происходит проверка знаний при помощи прохождения обучающимися определенного теста, составленного преподавателем. Правильность его выполнения затем проверяется преподавателем и выставляется оценка для каждого обучающегося соответственно.
Заменить эту длинную цепочку событий может позволить внедрение в процесс обучения специализированной программы, которая способствовала бы получению новых знаний людьми и в конце выполняла бы проверку, насколько хорошо усвоен материал.
1.1 Обзор исследований, изучающих использование игр в обучении
Для привлечения людей к изучению нового материала используются специальные техники, которые представляют обучение в игровой форме, чтобы им было легче потреблять большой объем новой информации. Также при помощи этой игры можно сразу показать, как новый материал может быть применен на практике.
В последнее время распространенным способом для получения практических навыков используются деловые игры. Они являются своеобразным моделированием процессов и механизмов принятия решений, используя математическую и организационную модели. Применение таких игр в обучении способствует развитию профессиональных навыков обучаемых. Они учат защищать свою точку зрения, используя обоснованные аргументы, перефразировать и применять получаемую информацию и работать сообща. Также деловая игра способствует развитию социальных навыков в людях и воспитанию правильной самооценки.
В своем рассуждении А. А. Вербицкий говорит о деловой игре, как о симуляторе, создающем социальное и предметное содержание имитируемой профессии. Такая игра позволяет человеку столкнуться с теми процессами деятельности, которые могут проявиться в реальности. И, обнаружив проблему один раз, не допустить ее появление во второй [3].
Исследование ряда иностранных деятелей (Chang, Liang, Chou, Lin) [4] на наборе нескольких групп студентов общей численностью 103 человека, где 50 учеников использовали учебные материалы, основанные на игре, а другие 53 ученика использовали стандартные учебники для изучения материала, показало, что обучающаяся с использованием игры группа значительно больше получила опыта в изучаемой профессиональной деятельности, чем другая группа, не связанная с игрой. Группа, обучающаяся на основе игры, была более заинтересована, сконцентрирована и способна контролировать свое обучение, чем не участвующая в игре группа. Использование игры может быть эффективно для помощи обучающимся и мотивировать их изучать новый материал.
Этот вывод согласуется с некоторыми результатами других исследований, изучающих обучение на основе игры и получения профессионального опыта. Admiraal, Huizenga, Akkerman и Dam [5] обнаружили, что обучение на основе игры может улучшить опыт в рассматриваемой деятельности и взаимодействие учащихся средних школ. Choi и Baek [6] обнаружили, что мультимедийная виртуальная учебная среда может улучшить такой опыт среди старшеклассников в начальных школах. Kiili, Freitas, Arnab и Lainema [7] указали на тоже самое только среди студентов колледжа, а Liu, Liao и Pratt [8] предположили, что применение такого метода обучения может повысить стремление студентов к дистанционному обучению. Однако ранее эти исследования не сравнивали между собой обучение на основе игры и стандартное обучение по книгам.
Основная идея предыдущих исследований в области образования была также подтверждена другими авторами: Sung, Hwang, Lin и Hong. В своем исследовании [9] они разработали и внедрили экспериментальную игру для детей в начальной школе. Затем они проанализировали разницу обучения с использованием игры и без, и полученные результаты показали, что игровые сценарии, встроенные в образование, могут стимулировать мотивацию для изучения новых и глубоких знаний. Достичь этого можно постоянно улучшая игру, где лучшим способом сделать это является учет предпочтений каждого ученика. Также с каждым новым проведенным занятием с использованием этой игры можно накапливать статистику игры и отзывы пользователей о ней для исправления недочетов и внесения новых желаемых функций в программу.
В другой работе [10] исследователи анализируют влияние использования игры в обучении для внедрения ее в математические курсы. Они выдвигают утверждение, что для положительного влияния программы на мотивацию учащихся к обучению необходимо использовать специальные стратегии и методы. Одним из таких инструментов является добавление игровых подсказок для пользователя, которые могут помочь ученику в трудной и непонятной ситуации. Их целью является направить ученика на правильный выбор, когда он не может справиться самостоятельно. Самое главное - не сообщать ответ напрямую, а только давать подсказку, как достичь желаемого результата. Таким образом, даже если студенты не могут решить проблему самостоятельно, у них все еще есть энтузиазм после намека на правильное действие и вероятность успешного решения возрастет.
Учителя также могут играть важную роль в игре. По словам Becker [11], в качестве экспертных руководителей, они могут помочь ориентироваться в аспектах игры, а также наполнять игровой контент учебными материалами. Сочетание увлекательного геймплея и образовательной информации делает учеников удовлетворенными и их удовольствие зависит от успеха решения возникающих проблем в игре. Поэтому игра должна иметь трудности, которые преднамеренно препятствуют прогрессу или ухудшают условия игры, однако они должны быть в меру решаемыми, чтобы игрок не застрял на одном месте. Таким образом, студент постоянно будет стремиться улучшить условия в игровой среде, и он будет все больше радоваться, выполняя эту задачу.
Игры предоставляют хорошую возможность для людей воплощать свои идеи и мысли. Используя симулятор, они могут делать то, что невозможно в реальной жизни, и получать ответы на ранее неисследованные вопросы. Это дает свободу экспериментировать над некоторыми вещами, которые в реальности могли бы иметь за собой последствия, а также предоставляет широкие возможности для исследований, где можно четко контролировать и записывать каждое выполняемое действие над объектом исследования, а также собирать статистику для дальнейшего сравнения результатов, получения выводов, подтверждения или опровержения выдвинутых ранее гипотез.
Таким образом, все эти исследовательские группы подтверждают, что основанное на игре обучение дает больше преимуществ, чем использование стандартных методов изучения материала на основе лекций и практик. Главным образом игра привлекает студентов к интересному процессу, в то время как они изучают новый материал. Помимо этого, она позволяет человеку почувствовать себя в реальной ситуации, которая могла бы произойти в определенной изучаемой области, а также в некоторой степени мотивирует своей увлекательностью, если ученику нравится участвовать в ней.
1.2 Сравнение традиционной и гибкой методологий разработки программного продукта
Тема данной работы посвящена обучению студентов навыкам разработки в команде, поэтому были также рассмотрены некоторые исследования, в которых рассказывается об оптимизации жизненного цикла программного обеспечения и преимуществах использования того или иного метода в реальной жизни. Исследователи также проводят сравнение традиционной и гибкой методологии между собой и определяют специфики их использования.
В области разработки программного обеспечения распространенно используется каскадная модель жизненного цикла, по-другому называемая «водопадом». Она реализуется в виде традиционного линейного процесса, начинающегося с разработки требований, затем переходящего в проектирование, реализацию, тестирование и в конечном итоге выпуск продукта для использования. Данная методология была популяризирована в начале 2000-х годов, когда традиционный метод разработки систем был преобладающим. На рис. 1.1 показаны этапы каскадной модели жизненного цикла.
Рисунок 1.1. Графическая интерпретация каскадной модели жизненного цикла
Однако наиболее подходящий пример для изучения разработки программного обеспечения - это использование гибкой методологии. Преимуществами ее применения является достаточно быстрое получение результата, упрощение внесения изменений в проект при изменении требований заказчика за счет итерационной разработки, а также обеспечение гибкости в управлении проектом.
Такая гибкая разработка программного обеспечения характеризуется короткими циклами разработки, называемыми спринтами, в которых периодически выполняется сбор требований, планирование, разработка, проверка и разворачивание. С каждым новым спринтом разработчики итеративно расширяют и улучшают программное приложение. В контексте обучения циклы разработки и рабочие программы заменяются циклами проекта и полезными результатами, соответственно. Другими словами, гибкая методология состоит из множества коротких проектных циклов, в которых пригодный к использованию результат полностью запланирован, спроектирован, разработан, протестирован, проверен и развернут. Одной из определяющих особенностей гибкой разработки программного обеспечения является тот факт, что каждый спринт заканчивается полезной продукцией, которая с каждым циклом все больше расширяется и улучшается. Несмотря на то, что гибкая методология была представлена только в начале 2000-х годов, она в последние годы уже стала широко распространенной. На рисунке 1.2 показан гибкий процесс разработки продукта.
Рисунок 1.2. Модель процесса разработки продукта по гибкой методологии Agile
Проведенное исследование сравнения традиционного и гибкого методов разработки продукта показывает, что из-за коротких циклов студенты терпят больше неудач, по сравнению с традиционным методом. В то же время гибкая разработка занимает больше времени, что может сказаться на отставании студентов. Тем не менее, обучающиеся указали на сильное предпочтение гибкой методологии по сравнению с традиционной, несмотря на то, что их первоначальные предпочтения и показатели эффективности конкретного метода не влияли на их оценку. Тем не менее, гибкая разработка требует значительного объема планирования, а также частого взаимодействия членов команды в рамках проекта [12].
В своей книге Зыков С.В. [13] описывает решение, как предотвратить кризис программного продукта. Многие проблемы возникают из-за неграмотного планирования, отсутствия общего видения проекта и непонимания среди членов команды охвата потребительской сферы продукта. Каждое мнение по конкретному вопросу имеет свои аргументы, направленные на защиту интересов одной из сторон спора. В связи с этим проблемы возникают не только из-за технических ограничений, но и из-за различий человеческих мнений. Это можно преодолеть, используя адаптивный метод разработки программного обеспечения, который помогает оптимизировать производство, чтобы избежать трудностей. Изучая различные методологии, автор объясняет, что типичная методология начинается с верхнего уровня модели жизненного цикла, то есть общего видения проекта, и постепенно декомпозируется на более мелкие детали. Это позволяет участникам анализировать влияние планируемых работ на бюджет и время проекта на каждом этапе. Главным принципом данной методологии является то, что команда должна изначально определить все требования к разрабатываемому программному продукту, корректно детализировать их и просчитать экономическую эффективность и требуемое на реализацию время. Причем запрещено вносить изменения, появляющиеся после установления технического задания. Другая методология включает гибкую разработку программного обеспечения с помощью коротких повторяющихся циклов, где каждый начинается с анализа требований и заканчивается выпуском версии. Такой метод требует соблюдения согласованного плана на протяжении всего процесса разработки и внесение динамических изменений в процесс возможно только в начале новой итерации. Несоблюдение этих правил может привести к тому, что продукт будет не соответствовать заявленным требованиям заказчика.
Очень часто гибкие проекты используют итерации для получения быстрых промежуточных результатов. Авторы, изучающие гибкую методологию, утверждают, что разделение проекта на несколько выпусков позволяет клиентам увидеть прогресс разработки продукта, а разработчикам получить от них отзывы. В начале каждой итерации участники проекта планируют продолжительность и функции, которые будут реализованы в рамках этой итерации. Чтобы оценить продолжительность разработки, авторы советуют разделить пользовательские сценарии на более мелкие задачи, которые можно легче оценить, чем большие [14].
Индустрия разработки программного обеспечения обладает значительными экономическими и технологическими возможностями, которые привлекают многие компании. В этой связи конкуренция между поставщиками программного обеспечения растет, а инновационные циклы снижаются. Schmidt утверждает, что компании должны быть гибкими в таких сложных условиях, потому что для выживания им необходимо быстро адаптироваться к изменяющимся условиям использования новых технологий.
Умение сбалансированно выстроить процесс разработки программного обеспечения - это ключевой фактор успеха компании. Традиционно многие начинают свои проекты, предварительно уточнив спецификации программного обеспечения и точно спланировав ход проекта заранее. Затем руководители проектов и разработчики реализуют эти планы, и программный продукт выпускается только после полной реализации в конце всего проекта. Программа в основном тестируется после фазы реализации на специальной стадии тестирования. Следовательно, проблемы в основном обнаруживаются только в конце процесса разработки. В случае возникновения каких-либо трудностей, многие проекты выходят за рамки установленного времени или бюджета. Кроме того, может быть достаточно трудно гибко реагировать на меняющиеся условия, что в конечном итоге приводит к полному провалу проекта [15].
Использование в игре гибкой методологии позволит пользователю планировать на одну итерацию разработку только нужных модулей программы, а остальные оставлять на следующую. Это необходимо для того, чтобы в самом начале игрок не задавался целью сделать сразу идеальный продукт, так как в современном мире большинство проектов дорабатываются по ходу разработки, а старался достигать совершенства, постепенно добавляя новый функционал, исправляя ошибки и усовершенствуя программу.
В конце итерации частично реализованный функционал программы отправляется заказчику и от него приходит ответ о готовности итогового продукта. Пользователь может самостоятельно знать, что еще остались нереализованные требования и продукт не закончен, следовательно, нужны дополнительные итерации. Однако на поздних сроках, когда весь функционал уже реализован, новый цикл может потребоваться на исправление обнаруженных ошибок или доработку функционала в соответствии новыми требованиями заказчика.
Такие итерации держат пользователя активным на протяжении всего проекта, так как на инициализации и планировании ему требуется изменять детали проекта и составлять план на текущую и будущие итерации, чтобы завершить проект вовремя и удовлетворить заказчика.
Сравнивая между собой традиционную и гибкую методологии, необходимо подчеркнуть, что не существует универсального подхода, который удовлетворял бы всем условиям командного проекта. В зависимости от определенных условий и факторов, таких как сложность проекта, время и бюджет на реализацию, квалификация сотрудников и готовность заинтересованных сторон участвовать в процессе создания продукта, подбирается наиболее подходящий способ ведения проекта. Краткая сравнительная характеристика по критериям этих двух методологий представлена в табл. 1.1. В ней отражены основные аспекты различия двух популярных методологий.
Таблица 1.1. Таблица сравнения традиционной и гибкой методологий
|
Условие |
Традиционная методология |
Гибкая методология |
|
|
Формирование требований заказчика |
Только на этапе формирования проекта, изменения невозможны |
На любой итерации проекта |
|
|
Возможность изменения требований |
Отсутствует |
Присутствует |
|
|
Участие заказчика в процессе ведения проекта |
Только в начале и конце |
Сильно вовлечен в процесс разработки программного продукта на всех этапах |
|
|
Ведение документации |
Формулируются четко на начальной стадии ведения проекта |
Осуществляется по ходу проекта |
|
|
Количество квалифицированных сотрудников |
Рассчитывается и распределяется по срокам |
Необходимо минимальное число квалифицированных сотрудников, так как планирование обычно осуществляется на одну ближайшую итерацию |
|
|
Условие начала разработки программы |
Только после полной проработки всех требований к будущему программному продукту |
Почти сразу, после получения первоначальных требований |
|
|
Тестирование продукта |
После реализации всей программы, появление ошибки может повлечь за собой переработку большого количества модулей программы |
На каждой итерации, что снижает риск появления проблем в дальнейшей разработке |
|
|
Оценка программы стейкхолдерами проекта |
После полной реализации |
По окончании каждой итерации |
|
|
Выведение продукта на рынок |
По истечению всего срока проекта |
Быстрый выпуск в конце каждой итерации |
Так, например, в традиционной методологии заказчик участвует только в начале и конце процесса ведения проекта, а его требования формируются только на начальном этапе и их изменения невозможны. В то время как в гибкой методологии, он сильно вовлечен в процесс разработки программного продукта и существует возможность изменения требований на любой итерации проекта, что в некоторой степени затрудняет ведение общей документации.
Кроме того, в традиционной схеме необходимое количество квалифицированных сотрудников может быть заранее рассчитано и распределено по срокам, так как требования к разрабатываемой системе четко определены. В гибкой методологии, как правило, команда должна иметь в штате минимальное число квалифицированных сотрудников, так как продолжительность итерации обычно составляет 2-4 недели и спланировать требуемое количество людей на длительный период достаточно сложно.
Стандартный способ предполагает, что разработчики могут приступить к своей работе только после полной проработки всех требований к будущему программному продукту, а тестирование будет производиться после реализации всей программы, и появление ошибки может повлечь за собой переработку большого количества модулей. В то же время гибкая методология подразумевает быстрый переход к разработке, так как первоначальные требования устанавливаются на первой итерации, а новые узнаются по ходу проекта.
Контроль качества также выполняется после реализации, однако, в отличие от традиционного метода, где тестирование происходит для всего продукта в целом, здесь выполняется поиск ошибок для небольших разработанных модулей на каждой итерации, что снижает риск появления проблем в дальнейшей разработке.
Также в проекте, использующем традиционную методологию, вывести продукт на рынок и получить от пользователей оценку разработанной программы возможно только по истечению всего срока проекта. Проекты по гибкой методологии позволяют команде достаточно быстро презентовать первые релизы продукта в конце каждой итерации, выпуская в дальнейшем обновления для него, а стейкхолдерам проекта, или пользователям, тестировать и оценивать обновленную часть программы.
На основании изученных преимуществ и недостатков двух методологий, а также условиях их применения в командных проектах можно сделать вывод о том, что для обучения студентов навыкам командной разработки больше подходит гибкая методология. Поскольку в последнее время она является наиболее распространенным методом для ведения проектов, а также позволяет динамически управлять проектом на протяжении всего жизненного цикла разрабатываемого продукта. Использовать ее в игровой форме будет значительно интересней, нежели стандартную методологию, подразумевающую выполнение разработки линейным способом.
1.3 Описание требований к модулю планирования и разработки игры
Данная работа направлена на создание модуля планирования и разработки игры «IT-менеджер», целью которого является реализация двух соответствующих этапов разработки. Главным образом программа должна реализовывать функции, отражающие действия во время командной разработки программного продукта, и содержать этапы анализа, планирования, разработки, тестирования и внедрения. Кроме того, в игре должны быть определены сроки проекта, чтобы студент мог составить план согласно установленной длительности. Несоблюдение установленных правил влияет на игровой процесс и удовлетворенность заказчика. Для завершения проекта обязательным условием является показ продукта всем участвующим стейкхолдерам для получения от них оценки. В случае если имеются ошибки в разработанной программе или появляются новые требования со стороны стейкхолдеров, то следует доработать программу.
Функциональным назначением всего программного продукта является представление одной из методологий разработки программного обеспечения в игровой форме, а также осуществление ведения разработки виртуального проекта. В узком плане данная работа направлена на проектирование и реализацию программного модуля планирования и разработки внутриигрового проекта. Система должна иметь удобный интерфейс взаимодействия с пользователем и выполнять необходимые для данных этапов расчеты, которые будут влиять на игровой процесс.
Предполагается, что данные об имеющихся требованиях к игровому продукту, количестве и характеристиках сотрудников для разрабатываемого модуля будут поступать из другого модуля анализа требований. Выходным результатом работы модуля планирования и разработки является составленный пользователем план работ, а также выполненная реализация модулей по составленному ранее плану с генерацией ошибок в разработанных игровых модулях.
Для наглядного отображения основной работы разрабатываемого модуля было проведено описание системы на концептуальном уровне с помощью диаграммы прецедентов, изображенной на рис. 1.3.
Рисунок 1.3. Диаграмма прецедентов модуля планирования и разработки
Предполагается, что в системе будет участвовать только один актор, он же пользователь системы, контролирующий все процессы, происходящие в игре на этапах планирования и разработки. При переходе на этап составления плана разработки пользователь должен выполнить функцию создания архитектуры внутриигровой программы, где на основе найденных на предыдущем этапе требований, составляется набор модулей, реализующих их. За это действие отвечает прецедент «Формирование модулей для реализации найденных требований». Также перед составлением модулей необходимо выбрать архитектора из списка сотрудников, нанятых ранее на этапе анализа. Характеристики выбранного человека будут влиять на полученные в игре данные. Так если навык архитектора окажется низким, то полученные данные о необходимом количестве строк разработки модуля будет сильно варьироваться от идеального значения, установленного в программе для данного модуля. За определение количества строк кода необходимого для реализации определенного требования отвечает прецедент «Расчет количества строк кода модуля с использованием навыка архитектора». В данном случае назначенный пользователем сотрудник задает предположительную размерность выбранного модуля, которая в дальнейшем будет использоваться при составлении плана работ.
Следующий прецедент «Добавление работ в план» содержит в себе выбор модуля для разработки и двух сотрудников, выполняющих роль разработчика и тестировщика. Пользователю предоставляется для выбора только список тех модулей, которые были определены архитектором на продолжительности всего проекта. Дополнить этот список можно, повторно запустив процесс определения модулей на основе найденных требований, предварительно выбрав архитектора. Назначение разработчика и тестировщика определяется самим пользователем с помощью специальных выпадающих списков, располагаемых на экране. Допускается назначение одного сотрудника сразу на две роли и выбор нескольких модулей для одновременного назначения разработки и тестирования сразу для всех.
«Удаление работы из плана» предполагает то, что модуль, ранее добавленный в план работ, не будет задействован в разработке или тестировании. При добавлении или удалении модуля происходит перерасчет ожидаемой длительности разработки и тестирвоания, отображаемой на экране для того, чтобы пользователь мог ориентироваться по запланированным временным затратам.
После выбора модуля и участника разработки выполняется прецедент «Расчет длительности разработки выбранного модуля с использованием навыка разработчика», в результате которого пользователь получает информацию о предположительном затрачиваемом времени, необходимом на разработку выбранного модуля. Аналогичным образом выглядит прецедент расчета длительности тестирования, где результатом является ожидаемое время выполнения тестов назначенным тестировщиком.
После определения запланированных работ пользователь выполняет «Переход на этап разработки» посредством нажатия на соответствующую кнопку интерфейса.
Этап разработки начинается автоматически при переходе на соответствующий экран. Прецедент «Запуск виртуальной разработки по составленному плану» подразумевает начало разработки модулей согласно установленному на предыдущем этапе плану. Связанный с ним другой прецедент подразумевает выполнение специальных алгоритмов, которые рассчитывают продолжительность разработки и тестирования добавленных в план модулей и количество строк кода для них в зависимости от характеристик разработчика. С течением времени на экране отображается прогресс разработки, где количество прошедших дней увеличивается на единицу, а разработанные за этот период модули добавляются в список на экране.
Во время процесса разработки для модулей, участвующих в данном процессе, рассчитывается количество допущенных при их создании ошибок в зависимости от навыка назначенного на эту работу разработчика. За это отвечает прецедент «Расчет количества ошибок во время создания модуля».
Рассмотренные прецеденты отражают основное взаимодействие пользователя с системой и описывают его действия на этапах планирования и разработки. При этом можно выделить основные возможности, предоставляемые разрабатываемым модулем:
1. Определение модулей, реализующих требования игрового проекта, в зависимости от навыков архитектора.
2. Выбор модулей для добавления в план работ.
3. Выбор разработчика и тестировщика на реализацию работы.
4. Добавление и удаление работы на разработку и тестирование выбранных модулей.
5. Расчет ожидаемого количества строк кода разработки для определяемого нового модуля в зависимости от характеристик аналитика.
6. Расчет прогнозируемой длительности разработки модуля в зависимости от характеристик назначенного разработчика и установленного архитектором количества строк разработки этого модуля.
7. Расчет реальной длительности разработки модуля в зависимости от характеристик назначенного разработчика и установленного архитектором количества строк разработки этого модуля.
8. Расчет прогнозируемой длительности тестирования модуля в зависимости от характеристик назначенного тестировщика и количества строк кода разработки этого модуля.
9. Расчет реальной длительности тестирования модуля в зависимости от характеристик назначенного тестировщика и количества строк кода разработки этого модуля.
10. Расчет прогнозируемой длительности итерации в зависимости от добавленных в план работ и индикация превышения установленной для проекта максимальной длительности итерации для пользователя.
11. Генерация ошибок в разработанном модуле в зависимости от характеристик разработчика.
Более подробные требования к разрабатываемой системе приведены в техническом задании, которое расположено в прил. А.
1.4 Анализ существующих решений
Рассмотренная тема обучения навыкам командной разработки проявляется в некоторых уже существующих обучающих игровых симуляторах. Был проведен анализ наиболее популярных решений и составлена сравнительная таблица по различным оценочным критериям. Главным образом разрабатываемая игра должна быть ориентирована на молодую аудиторию и иметь образовательную составляющую, так как планируется использовать ее в учебных заведениях. Также симулятор должен иметь понятный интерфейс и краткую инструкцию правил для того, чтобы пользователь с легкостью мог самостоятельно начать прохождение и играть в подходящем для него темпе. В рамках обучения виртуальный проект должен иметь завершение, чтобы игрок мог увидеть конечный результат и оценить последствия своих действий.
1.4.1 Game Dev Tycoon
Game Dev Tycoon [16] - это игра, где пользователю предстоит взять на себя роль начинающего разработчика и своими усилиями создать IT-компанию. Игрок начинает создавать игры на заре игровой индустрии в гараже с достаточным для проживания на пару месяцев денег. Создавая качественные игры, нравящиеся внутриигровым пользователям, игрок получает большую прибыль, которую он должен тратить на развитие собственной компании. Параллельно можно отправить игрового персонажа где_то подрабатывать для получения дополнительных денег.
В начале пользователю случайным образом присваиваются 4 тематики, которые нужно использовать для создания игры. Данный фактор значительно вносит дисбаланс между несколькими участниками, так как программно в игре заложено, что для некоторых тем проще создать популярную игру, чем для других, тем самым одному пользователю может повезти больше, чем другому. Каждую тематику можно изучать, чтобы делать более качественные игры. Также на качество влияют технологии и дизайн, постоянно улучшая которые можно сделать хорошую игру. В начале предоставляется только эти три фактора, влияющие на игру, но в дальнейшем при развитии собственной компании их количество увеличится и добавятся маркетинг, виды игр (такие как средние, большие и высокобюджетные) и много другое.
Во время создания игры пользователь должен распределить отведенное на разработку время между тремя показателями (рис. 1.4), проработанность которых будет влиять на итоговую оценку разработанной программы. Это распределение поначалу невозможно верно составить, поскольку только после проб и ошибок пользователь должен самостоятельно подобрать верное соотношение, в результате которого будет получена максимальная оценка продукта.
Рисунок 1.4. Окно распределения ресурсов между тремя показателями игры
После выпуска игры для нее появляются обзоры из различных журналов и отзывы пользователей, которые влияют на продажи игры и, соответственно, на прибыль компании издателя. Чем больше игрок производит игры, тем больше он развивается и накапливает свой капитал.
Спустя какое-то время появляется возможность открыть свой собственный офис (рис. 1.5) и нанять людей на работу. Существует несколько типов сотрудников для найма: дизайнер, технолог и разработчик. Каждый из них имеет свой навык, который отражается на качестве создаваемой им игры, а также появляется необходимость выплачивать зарплату, что в свою очередь также влияет на игровой бюджет.
Рисунок 1.5. Окно игры, отображающее прогресс работы в офисе
Нет каких-то четких границ сроков создания игры, пользователь самостоятельно решает сколько нужно потратить время на изучение технологий, разработку и исправление ошибок. Игра продолжается до тех пор, пока у него не закончатся деньги, или не пройдет 35 игровых лет, когда программно останавливается развитие игровой индустрии. Игроку предоставляется выбор продолжить свободную игру самостоятельно, либо завершить ее.
В целом игра подходит для увлекательного времяпровождения для любого типа людей, как знакомых с реальным выпуском программных продуктов, так и нет. Однако ее нельзя назвать обучающей, так как кроме правильного распределения денег и трудовых ресурсов компании она ничему не учит. Кроме того, в своем контенте она не содержит образовательных целей, а только направлена на развлечение игрока.
1.4.2 Game Corp DX
Еще один симулятор игровой студии носит название Game Corp DX [17]. Он содержит в себе стандартные для подобного жанра элементы свободного управления миром и построения успешного бизнеса. Отличительными особенностями данной игры являются простой дизайн, легкость освоения правил и отсутствие каких-либо ограничений на выпуск игр.
Game Corp DX построена полностью на 2D графике, что может оттолкнуть современное поколение людей и наоборот привлечь более взрослое. На протяжении всей игры пользователю помогает виртуальный персонаж, изображенный на рис. 1.6. В начале игры он кратко объясняет, что нужно делать и куда нажимать, чтобы создать свою первую игру, а в дальнейшем участвует при возникновении различных игровых событий в качестве диалогового лица.
Рисунок 1.6. Окно начала игры Game Corp DX
Игроку предстоит с начальным бюджетом нанять нескольких сотрудников и назначить им создание новой игры. Существует игровое время, которое длится 8 рабочих часов, после которых все сотрудники компании идут домой и на следующий день приходят обратно на работу. У нанятого работника имеется несколько показателей влияющих на продуктивность его работы, можно накормить его различной едой и его эффективность повысится в несколько раз. Также при назначении работы пользователь должен обращать внимание на навыки сотрудника. Всего в игре существует 4 вида специальности: кодинг, арт, звук и сценарий. Каждый такой навык можно развивать у конкретного человека до четвертого уровня мастерства, однако для одного человека разрешается выбрать только один вид постоянной занятости. На рис. 1.7 изображено окно создания игры, где пользователь должен ввести название будущей игры, выбрать ее размер и тип.
Рисунок 1.7. Окно создания нового проекта игры
Также внутри игры существуют некоторые события, которые вносят разнообразие в скучный процесс менеджмента. Например, участие в ежегодной церемонии награждения лучшей игровой студии. Несколько внутриигровых компаний и собственно созданная пользователем оцениваются автоматически игрой в различных номинациях. Победителям присуждают такие полезные пассивные бонусы, как увеличение скорости работы игровых подчиненных или рост продаж выпущенных игр.
Данная игра не имеет определенной конечной цели, и она сводится к тому, чтобы заработать как можно больше денег. Через несколько часов игры созданная компания начинает на потоке производить хорошо продающиеся игры и сложность для игрока значительно понижается. Действия пользователя превращаются в однообразный алгоритм создания игр. Сложно назвать Game Corp DX обучающей игрой, так как в целом она не содержит каких-либо поучающих советов для начинающих разработчиков или менеджеров, а скорее направлена на увлекательную трату времени.
1.4.3 SimulTrain
Тренинговый бизнес-симулятор SimulTrain [18] - это компьютерный симулятор, используемый для обучения управлению проектами. Моделирование ведения проекта позволяет обучающимся получить знания о различных нюансах менеджмента, научиться следить за сроками и стоимостью проекта, качеством его ведения и влиянием человеческого фактора. В режиме реального времени пользователь видит последствия принимаемых им решений в компании и может проследить их влияние на различные затраты по времени или стоимости проекта. Главное окно симулятора представлено на рис. 1.8, на котором отображается виртуальный офис компании игрока. Здесь в процессе игры будут появляться различные сообщения о произошедших событиях, а также о необходимости выбора решения, которое будет влиять на процесс игры.
Рисунок 1.8. Главное окно бизнес-симулятора SimulTrain
Игра подразумевает ведение достаточно сложного проекта и для этого требуется командная работа от трех до четырех человек. Рассчитанное времяпровождение в ней равно примерно шести часам и разделено на три или четыре перерыва, во время которых происходит обсуждение между членами команды принятых решений и их последствий.
Игровой симулятор показывает этапы ведения проекта от планирования до завершения, а также сценарий игры содержит более шестидесяти ситуаций, которые требуют от игрока быстрой реакции и правильного решения. Пользователи получают различные телефонные звонки, письма по электронной почте, голосовые сообщения для погружения в атмосферу реального проекта.
Игрок должен в роли руководителя проекта назначить выполнение задач существующим в компании сотрудникам, при этом руководствуясь соответствием навыков конкретного человека и требуемых в задании. Также необходимо следить за мотивацией внутриигровой команды, стоимостью, сроками и качеством текущего проекта.
В игре предусмотрено отслеживание статуса проекта и выполняемости плана с помощью различных диаграмм. Так, например, на рис. 1.9 показана диаграмма Ганта, которая содержит задания разработки проекта и их назначение конкретным сотрудникам. По горизонтали откладывается время, необходимое на выполнение данных заданий. Согласно данной диаграмме можно отслеживать завершенность конкретных задач, а также всего проекта в целом.
Рисунок 1.9. Диаграмма Ганта, отображающая процесс составленного плана в игре
Данный бизнес-симулятор ориентирован на взрослую аудиторию, которая возможно уже имеет свои проекты и хочет улучшить или проверить свои навыки руководителя. В результате, по заверению авторов игры, участники смогут научиться эффективно планировать ресурсы и управлять проектом, принимать правильные групповые решения, а также успешно завершать проекты.
Для получения отзыва о всех принятых решений подразумевается привлечение тренера, который не должен часто вмешиваться в рабочий процесс групп, а только участвовать в обсуждении результатов игры. Он суммирует все действия по ходу игры и обсуждает с участниками то, как можно было бы рационально решить появляющиеся проблемы в игре. Это позволяет пользователю получить некоторые навыки, руководствуясь которыми в дальнейшем он не будет допускать подобных ошибок.
1.5 Сравнение игровых симуляторов
Все рассмотренные симуляторы содержат в себе командную разработку каких-либо программных продуктов. Однако часть из них носит сугубо развлекательный характер, который не подходит для обучения людей соответствующим навыкам, а другая часть наоборот сосредоточена в основном на проведении тренинга людей с целью обучения определенным компетенциям в ущерб развлечению. У тех и других игр есть своя аудитория, и в большинстве случаев она не пересекается. Развлекательные игры в основном ориентированы на молодое поколение, а образовательные игры - на взрослое. Однако в учебных заведениях последнюю категорию игр будет достаточно сложно применить для использования в образовательных целях, так как для мотивации молодым людям будет не хватать развлекательной составляющей игры. Для удовлетворения их потребностей необходимо находить компромиссное решение, сочетающее в себе образовательную и развлекательную части, либо делать процесс обучения более простым и понятным. В табл. 1.2 представлено краткое сравнение трех игровых симуляторов по оценочным критериям, выдвинутым перед анализом существующих решений.
Таблица 1.2. Таблица сравнения игровых симуляторов, реализующих командную разработку
|
Критерий |
Game Dev Tycoon |
Game Corp DX |
SimulTrain |
|
|
Ориентирован на молодую аудиторию |
+ |
+ |
- |
|
|
Пользователь может самостоятельно начать игру |
+ |
+ |
- |
|
|
Требует выполнение действий согласно установленным правилам |
+ |
- |
+ |
|
|
Содержит краткую инструкцию для начала игры |
+ |
+ |
- |
|
|
Содержит образовательные элементы |
- |
- |
+ |
|
|
Доступность игры для всех желающих |
+ |
+ |
- |
|
|
Имеет окончание игры |
- |
- |
+ |
В связи с выявленными недочетами существующих на рынке решений возникает потребность в их совершенствовании и смены ориентира целевой аудитории на студентов учебных заведений. Основной целью такой игры будет служить обучение навыкам командной разработки, где материал будет подаваться в упрощенном варианте, чем для более опытных пользователей. Так игрок сможет самостоятельно разобраться в игре, и сделать для себя соответствующие выводы без привлечения третьего лица, объясняющего недостатки принятых им решений.
Глава 2. Проектирование модуля планирования и разработки
На основании выявленных требований к разрабатываемой программе выполняется проектирование архитектуры игры «IT-менеджер». Для модуля планирования и разработки описываются алгоритмы, реализующие функциональность соответствующих этапов, с помощью нотаций диаграмм UML. Затем определяется статическая структура системы, выраженная в виде диаграммы классов, и выполняется описание поведения системы. После чего создается пользовательский интерфейс программы с учетом специфики описанных алгоритмов.
2.1 Построение архитектуры игры
Игра «IT-менеджер» представляет собой однопользовательское приложение с графическим интерфейсом пользователя, построенное с использованием объектно-ориентированной методологии программирования. В ней отражается взаимодействие основных модулей, реализуемых для осуществления логики игры, и компонентов системы, выполняющих дополнительные функции с использованием сторонних библиотек.
На рис. 2.1 показана схема взаимодействия компонентов внутри программы. С помощью изображенных связей передается управление между двумя модулями, таким образом, что они образуют цикл этапов гибкой методологии.
Рисунок 2.1. Архитектура игры «IT-менеджер»
Начальным модулем является авторизация, во время которой пользователь должен идентифицировать себя как игрока для входа. Затем идет модуль выбора проекта, где ему предоставляется возможность выбрать желаемый среди доступных проектов игры. После определения игрового контента управление программой переходит к модулю анализа, который является первым из пяти, осуществляющих этапы жизненного цикла разработки программного продукта. По ходу игры на этапе анализа пользователь может изменить состав сотрудников его игровой компании, для этого управление передается соответствующему модулю, в котором происходят действия по найму и увольнению рабочих.
Также любое действие пользователя в программе должно записываться в текстовый файл, для того чтобы в дальнейшем можно было анализировать собранную статистику для улучшения игры и обнаружения ошибок. Данное действие логирования осуществляется с помощью компонента «NLog», предоставляющего методы для быстрой и удобной записи данных в текстовый файл. А для добавления нескольких панелей в рамках одного окна, отображающих различные данные о текущих найденных требованиях, добавленных модулях и нанятых сотрудниках проекта, используется компонент «AvalonDock».
2.2 Моделирование алгоритмов, реализуемых в программе
Подобные документы
Анализ моделей и методов реализации интеллектуальных игр в системе человек-робот. Среда разработки Choreographe. Алгоритмы модуля распознавания, обработки данных, функций модуля игры. Тестирование программного комплекса, исправление и редакция ошибок.
дипломная работа [1,7 M], добавлен 12.08.2017Основные стадии разработки, принципы тестирования и отладка программного модуля "VFS". Особенности проектирования на языке UML. Методы "грубой силы" и их применение при отладке программы. Вредные факторы, присутствующие на рабочем месте программиста.
дипломная работа [827,0 K], добавлен 07.03.2012Автоматизация рутинных бизнес-процессов технической поддержки организации с помощью встраиваемого модуля технологии системы IP-телефонии. Особенности проектирования, разработки и реализации модуля. Описание информационной системы, ее тестирование.
дипломная работа [2,3 M], добавлен 10.12.2016Анализ программного обеспечения Skype: оценка возможностей, сферы применения. Проектирование компонента: средства разработки, формирование пользовательского интерфейса и концептуальной модели данных. Реализация модулей. Диаграммы компонентов и классов.
курсовая работа [1,4 M], добавлен 27.04.2012Описания систем планирования ресурсов предприятия. Документирование и стандартизация процесса разработки корпоративной информационной системы. Создание основных объектов конфигурации, документов, регистров, отчетов, ролей и интерфейсов пользователей.
курсовая работа [3,0 M], добавлен 18.05.2016Разработка структурной диаграммы программного модуля. Представление схемы для основных расчетов выбранного приложения для создания прямоугольной матрицы. Особенности создания пользовательского интерфейса. Тестирование и отладка спроектированного модуля.
курсовая работа [648,4 K], добавлен 27.05.2015Обзор средств программирования. Описание и свойства языка Delphi. Основания для разработки, ее назначение, предъявляемые требования, стадии разработки. Описание схемы основного модуля, процедур, программы. Используемые технические и программные средства.
курсовая работа [42,8 K], добавлен 25.02.2012Анализ правил выбора хода на шахматной доске К. Шеннона. Характеристика программного модуля искусственного интеллекта для игры в шахматы. Контроль времени, поиск лучшего хода в шахматных алгоритмах. Разработка программы для игры с компьютерным оппонентом.
дипломная работа [3,7 M], добавлен 07.07.2012Методика разработки программного модуля для нахождения методом хорд корня уравнения x3-x-0,3=0 с точностью до 0,001 на языке программирования Visual Basic for Application. Схема программного модуля и описание процедуры обработки кнопки "Найти корни".
курсовая работа [394,0 K], добавлен 08.09.2010Анализ наиболее популярных систем планирования, представленных на российском рынке. Специфика разработки основных принципов финансового управления на малом предприятии. Особенности разработки и применения информационной системы финансового планирования.
дипломная работа [2,1 M], добавлен 25.11.2009
