Дипломная работа: Проектирование модуля планирования и разработки игры

Таким образом, все эти исследовательские группы подтверждают, что основанное на игре обучение дает больше преимуществ, чем использование стандартных методов изучения материала на основе лекций и практик. Главным образом игра привлекает студентов к интересному процессу, в то время как они изучают новый материал. Помимо этого, она позволяет человеку почувствовать себя в реальной ситуации, которая могла бы произойти в определенной изучаемой области, а также в некоторой степени мотивирует своей увлекательностью, если ученику нравится участвовать в ней.

1.2 Сравнение традиционной и гибкой методологий разработки программного продукта

Тема данной работы посвящена обучению студентов навыкам разработки в команде, поэтому были также рассмотрены некоторые исследования, в которых рассказывается об оптимизации жизненного цикла программного обеспечения и преимуществах использования того или иного метода в реальной жизни. Исследователи также проводят сравнение традиционной и гибкой методологии между собой и определяют специфики их использования.

В области разработки программного обеспечения распространенно используется каскадная модель жизненного цикла, по-другому называемая «водопадом». Она реализуется в виде традиционного линейного процесса, начинающегося с разработки требований, затем переходящего в проектирование, реализацию, тестирование и в конечном итоге выпуск продукта для использования. Данная методология была популяризирована в начале 2000-х годов, когда традиционный метод разработки систем был преобладающим. На рис. 1.1 показаны этапы каскадной модели жизненного цикла.

Рисунок 1.1. Графическая интерпретация каскадной модели жизненного цикла

Однако наиболее подходящий пример для изучения разработки программного обеспечения - это использование гибкой методологии. Преимуществами ее применения является достаточно быстрое получение результата, упрощение внесения изменений в проект при изменении требований заказчика за счет итерационной разработки, а также обеспечение гибкости в управлении проектом.

Такая гибкая разработка программного обеспечения характеризуется короткими циклами разработки, называемыми спринтами, в которых периодически выполняется сбор требований, планирование, разработка, проверка и разворачивание. С каждым новым спринтом разработчики итеративно расширяют и улучшают программное приложение. В контексте обучения циклы разработки и рабочие программы заменяются циклами проекта и полезными результатами, соответственно. Другими словами, гибкая методология состоит из множества коротких проектных циклов, в которых пригодный к использованию результат полностью запланирован, спроектирован, разработан, протестирован, проверен и развернут. Одной из определяющих особенностей гибкой разработки программного обеспечения является тот факт, что каждый спринт заканчивается полезной продукцией, которая с каждым циклом все больше расширяется и улучшается. Несмотря на то, что гибкая методология была представлена только в начале 2000-х годов, она в последние годы уже стала широко распространенной. На рисунке 1.2 показан гибкий процесс разработки продукта.

Рисунок 1.2. Модель процесса разработки продукта по гибкой методологии Agile

Проведенное исследование сравнения традиционного и гибкого методов разработки продукта показывает, что из-за коротких циклов студенты терпят больше неудач, по сравнению с традиционным методом. В то же время гибкая разработка занимает больше времени, что может сказаться на отставании студентов. Тем не менее, обучающиеся указали на сильное предпочтение гибкой методологии по сравнению с традиционной, несмотря на то, что их первоначальные предпочтения и показатели эффективности конкретного метода не влияли на их оценку. Тем не менее, гибкая разработка требует значительного объема планирования, а также частого взаимодействия членов команды в рамках проекта [12].

В своей книге Зыков С.В. [13] описывает решение, как предотвратить кризис программного продукта. Многие проблемы возникают из-за неграмотного планирования, отсутствия общего видения проекта и непонимания среди членов команды охвата потребительской сферы продукта. Каждое мнение по конкретному вопросу имеет свои аргументы, направленные на защиту интересов одной из сторон спора. В связи с этим проблемы возникают не только из-за технических ограничений, но и из-за различий человеческих мнений. Это можно преодолеть, используя адаптивный метод разработки программного обеспечения, который помогает оптимизировать производство, чтобы избежать трудностей. Изучая различные методологии, автор объясняет, что типичная методология начинается с верхнего уровня модели жизненного цикла, то есть общего видения проекта, и постепенно декомпозируется на более мелкие детали. Это позволяет участникам анализировать влияние планируемых работ на бюджет и время проекта на каждом этапе. Главным принципом данной методологии является то, что команда должна изначально определить все требования к разрабатываемому программному продукту, корректно детализировать их и просчитать экономическую эффективность и требуемое на реализацию время. Причем запрещено вносить изменения, появляющиеся после установления технического задания. Другая методология включает гибкую разработку программного обеспечения с помощью коротких повторяющихся циклов, где каждый начинается с анализа требований и заканчивается выпуском версии. Такой метод требует соблюдения согласованного плана на протяжении всего процесса разработки и внесение динамических изменений в процесс возможно только в начале новой итерации. Несоблюдение этих правил может привести к тому, что продукт будет не соответствовать заявленным требованиям заказчика.

Очень часто гибкие проекты используют итерации для получения быстрых промежуточных результатов. Авторы, изучающие гибкую методологию, утверждают, что разделение проекта на несколько выпусков позволяет клиентам увидеть прогресс разработки продукта, а разработчикам получить от них отзывы. В начале каждой итерации участники проекта планируют продолжительность и функции, которые будут реализованы в рамках этой итерации. Чтобы оценить продолжительность разработки, авторы советуют разделить пользовательские сценарии на более мелкие задачи, которые можно легче оценить, чем большие [14].

Индустрия разработки программного обеспечения обладает значительными экономическими и технологическими возможностями, которые привлекают многие компании. В этой связи конкуренция между поставщиками программного обеспечения растет, а инновационные циклы снижаются. Schmidt утверждает, что компании должны быть гибкими в таких сложных условиях, потому что для выживания им необходимо быстро адаптироваться к изменяющимся условиям использования новых технологий.

Умение сбалансированно выстроить процесс разработки программного обеспечения - это ключевой фактор успеха компании. Традиционно многие начинают свои проекты, предварительно уточнив спецификации программного обеспечения и точно спланировав ход проекта заранее. Затем руководители проектов и разработчики реализуют эти планы, и программный продукт выпускается только после полной реализации в конце всего проекта. Программа в основном тестируется после фазы реализации на специальной стадии тестирования. Следовательно, проблемы в основном обнаруживаются только в конце процесса разработки. В случае возникновения каких-либо трудностей, многие проекты выходят за рамки установленного времени или бюджета. Кроме того, может быть достаточно трудно гибко реагировать на меняющиеся условия, что в конечном итоге приводит к полному провалу проекта [15].

Использование в игре гибкой методологии позволит пользователю планировать на одну итерацию разработку только нужных модулей программы, а остальные оставлять на следующую. Это необходимо для того, чтобы в самом начале игрок не задавался целью сделать сразу идеальный продукт, так как в современном мире большинство проектов дорабатываются по ходу разработки, а старался достигать совершенства, постепенно добавляя новый функционал, исправляя ошибки и усовершенствуя программу.

В конце итерации частично реализованный функционал программы отправляется заказчику и от него приходит ответ о готовности итогового продукта. Пользователь может самостоятельно знать, что еще остались нереализованные требования и продукт не закончен, следовательно, нужны дополнительные итерации. Однако на поздних сроках, когда весь функционал уже реализован, новый цикл может потребоваться на исправление обнаруженных ошибок или доработку функционала в соответствии новыми требованиями заказчика.

Такие итерации держат пользователя активным на протяжении всего проекта, так как на инициализации и планировании ему требуется изменять детали проекта и составлять план на текущую и будущие итерации, чтобы завершить проект вовремя и удовлетворить заказчика.

Сравнивая между собой традиционную и гибкую методологии, необходимо подчеркнуть, что не существует универсального подхода, который удовлетворял бы всем условиям командного проекта. В зависимости от определенных условий и факторов, таких как сложность проекта, время и бюджет на реализацию, квалификация сотрудников и готовность заинтересованных сторон участвовать в процессе создания продукта, подбирается наиболее подходящий способ ведения проекта. Краткая сравнительная характеристика по критериям этих двух методологий представлена в табл. 1.1. В ней отражены основные аспекты различия двух популярных методологий.

Таблица 1.1. Таблица сравнения традиционной и гибкой методологий

Так, например, в традиционной методологии заказчик участвует только в начале и конце процесса ведения проекта, а его требования формируются только на начальном этапе и их изменения невозможны. В то время как в гибкой методологии, он сильно вовлечен в процесс разработки программного продукта и существует возможность изменения требований на любой итерации проекта, что в некоторой степени затрудняет ведение общей документации.

Кроме того, в традиционной схеме необходимое количество квалифицированных сотрудников может быть заранее рассчитано и распределено по срокам, так как требования к разрабатываемой системе четко определены. В гибкой методологии, как правило, команда должна иметь в штате минимальное число квалифицированных сотрудников, так как продолжительность итерации обычно составляет 2-4 недели и спланировать требуемое количество людей на длительный период достаточно сложно.

Стандартный способ предполагает, что разработчики могут приступить к своей работе только после полной проработки всех требований к будущему программному продукту, а тестирование будет производиться после реализации всей программы, и появление ошибки может повлечь за собой переработку большого количества модулей. В то же время гибкая методология подразумевает быстрый переход к разработке, так как первоначальные требования устанавливаются на первой итерации, а новые узнаются по ходу проекта.

Контроль качества также выполняется после реализации, однако, в отличие от традиционного метода, где тестирование происходит для всего продукта в целом, здесь выполняется поиск ошибок для небольших разработанных модулей на каждой итерации, что снижает риск появления проблем в дальнейшей разработке.

Также в проекте, использующем традиционную методологию, вывести продукт на рынок и получить от пользователей оценку разработанной программы возможно только по истечению всего срока проекта. Проекты по гибкой методологии позволяют команде достаточно быстро презентовать первые релизы продукта в конце каждой итерации, выпуская в дальнейшем обновления для него, а стейкхолдерам проекта, или пользователям, тестировать и оценивать обновленную часть программы.

На основании изученных преимуществ и недостатков двух методологий, а также условиях их применения в командных проектах можно сделать вывод о том, что для обучения студентов навыкам командной разработки больше подходит гибкая методология. Поскольку в последнее время она является наиболее распространенным методом для ведения проектов, а также позволяет динамически управлять проектом на протяжении всего жизненного цикла разрабатываемого продукта. Использовать ее в игровой форме будет значительно интересней, нежели стандартную методологию, подразумевающую выполнение разработки линейным способом.