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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 23.09.2018
Размер файла 1,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Этап планирования игры «IT-менеджер» должен содержать назначение работ для разработки внутриигровых модулей. Для этого необходимо составить алгоритм создания архитектуры игрового приложения на основе обнаруженных ранее требований.

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

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

Рисунок 2.2. Диаграмма активностей определения модулей для реализации найденных требований

Данный алгоритм расчета представляет собой установление количества строк кода модуля, исходя из навыков архитектора выбранного пользователем сотрудника. Определяемое количество строк рассчитывается по формуле (1):

, (1)

где РОКС - рассчитываемое ожидаемое количество строк кода модуля от аналитика;

УОКС - установленное ожидаемое количество строк кода модуля в программе;

случайная погрешность (%) - разброс от идеального установленного числа строк кода с учетом навыка архитектора.

Разброс для определения погрешности устанавливается по формуле (2) равным числу нехватки навыка архитектора у выбранного сотрудника до 100 процентов. В свою очередь случайная погрешность высчитывается с помощью определения случайного числа с установленным разбросом от 100 процентов.

, (2)

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

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

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

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

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

Расчет ожидаемой длительности разработки происходит с учетом навыков выбранного разработчика по формуле (3):

, (3)

где ОДР - ожидаемая длительность разработки модулей;

РОКС - рассчитанное ожидаемое количество строк кода модулей от аналитика;

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

Рисунок 2.3. Диаграмма активностей расчета ожидаемого затрачиваемого времени на разработку

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

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

Рисунок 2.4. Диаграмма активностей расчета ожидаемого времени на тестирование

В случае если модуль ранее был разработан, то для расчета длительности используется уже заданное разработчиком количество строк кода. В противном случае, а также если модуль назначен на повторную разработку, используется количество строк кода установленного архитектором при создании архитектуры. После чего выполняется непосредственно сам расчет длительности тестирования по формуле (4):

, (4)

где ОДТ - ожидаемая длительность тестирования модулей;

ОКС - ожидаемое количество строк кода модулей от аналитика или разработчика;

производительность тестировщика - число модулей в день, которые тестировщик может протестировать.

Добавление работы по разработке и тестированию модуля происходит с помощью нажатия на соответствующую кнопку. На рис. 2.5 изображена диаграмма активностей добавления работы в план.

Рисунок 2.5. Диаграмма активностей добавления работы в план

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

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

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

Так под действием уровня навыка разработчика для модуля устанавливается значение количества строк кода по формуле (5):

, (5)

где РКС - реальное количество строк кода модуля от разработчика;

УОКС - установленное ожидаемое количество строк кода модуля в программе;

случайная погрешность (%) - разброс от идеального установленного числа строк кода с учетом навыка разработчика.

Данная формула схожа с определением количества строк кода для модуля с использованием навыка архитектора, однако здесь всю работу выполняет разработчик. Также навык разработчика на данном этапе учитывается в алгоритме генерации ошибок в разрабатываемых модулях. Для этого по формуле (6) выполняется расчет количества создаваемых ошибок, и затем полученное значение округляется до целого.

, (6)

где КО - количество ошибок, допущенных при разработке модуля;

РКС - реальное количество строк кода модуля от разработчика.

Кроме того, для расчета реальной затрачиваемой продолжительности разработки модуля используется аналогичная формула (3) расчета ожидаемой длительности, однако в качестве количества строк кода задается значение, установленное разработчиком по формуле (5), а не архитектором.

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

2.3 Описание статической структуры системы

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

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

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

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

Рисунок 2.6. Диаграмма классов игры «IT-менеджер»

Класс «Module» соединен с классами «Employee» и «Test» с помощью агрегации, которая означает, что время существования коллекции или контейнера содержащихся классов не зависит от времени жизни содержащего их класса. Аналогично «Requirement» содержит ссылку-агрегацию на объекты классов «Employee» и «Stakeholder».

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

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

Проект также имеет несколько сотрудников, которых можно нанимать себе в команду для ведения проекта. За это отвечает класс «Employee», который имеет в составе такие атрибуты, как имя работника, его фотографию, навык и производительность по нескольким профессиям (аналитик, разработчик, тестировщик и архитектор), зарплату и статус занятости. Наем рабочих происходит на этапе анализа, однако на планировании пользователь выбирает среди нанятых сотрудников архитектора, разработчика и тестировщика для назначения соответствующих работ. При этом данные каждого сотрудника о навыках или производительности также участвуют в различных расчетах при составлении плана и его реализации.

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

Как уже было определено ранее, выполненность требования достигается за счет реализации списка модулей. Для создания экземпляра объекта модуля используется класс «Module», где его атрибутами являются название, количество строк кода, которые были заложены в контент игры, определены архитектором и рассчитаны разработчиком, номер дня и итерации реализации этого модуля, степень важности, статус был ли он разработан, связанное главное требование, объект разработчика модуля и тестировщика, а также списки составленных тестов и созданных ошибок при реализации. Модули, разрабатываемые в рамках игры, используются на всех этапах проекта. На стадии планирования их размерность в плане необходимого для реализации количества строк кода рассчитывается в зависимости от навыка архитектора. После чего при добавлении работы в план отображается предварительная длительность разработки и тестирования модуля при назначении соответствующих участников команды. На этапе разработки устанавливается реальное количество строк кода, понадобившееся для его создания, а также генерируется количество ошибок в зависимости от навыка разработчика.

Класс «Test» содержит данные о тесте, проводимом на этапе тестирования. Он включает в себя название и важность теста в рамках игрового проекта. Класс «Stakeholder» характеризует игрового заинтересованного лица, который сообщает о новых требованиях к разрабатываемому продукту. В его составе имеются атрибуты имени и типа. Также существует еще один класс «Error», который отражает тип созданной ошибки и статус ее исправления.

Помимо создания собственных классов в программе были также использованы сторонние библиотеки для организации некоторых процессов в программе. Например, для организации записи действий пользователя во внешний файл была использована библиотека «NLog». Собранная статистика пользовательских действий полезна для дальнейшей обработки данных с целью выявлении неточностей, ошибок и возможностей по улучшению программы. Кроме того, для создания нескольких панелей в рамках одного окна была применена библиотека «AvalonDock». Она позволяет организовать удобный графический интерфейс с возможностью перетаскивания панелей.

2.4 Описание поведения системы

После того как была описана статическая структура системы, необходимо выполнить моделирование динамических аспектов программы. Для этого используется диаграмма последовательностей, которая представляет собой графическую модель динамики взаимодействия объектов во времени для определенного варианта использования.

На рис. 2.7 изображена последовательность действий создания архитектуры модулей для найденных игровых требований. Прежде всего пользователю следует выбрать архитектора среди списка нанятых сотрудников и затем нажать на кнопку «Создать архитектуру модулей». В результате программа выполнит расчет строк кода для внутриигровых модулей в зависимости от навыка выбранного архитектора и отобразит на экране новые добавленные данные.

Рисунок 2.7. Диаграмма последовательностей создания архитектуры модулей

Последовательность добавления работы в план представлена на рис. 2.8, где пользователь должен выбрать модуль, разработчика и тестировщика. Если выбран модуль и разработчик, то программа в автоматическом режиме выполняет расчет ожидаемой длительности разработки модуля. Аналогично при выборе тестировщика для модуля рассчитывается предположительная длительность его тестирования. После осуществления выбора, пользователю необходимо нажать кнопку «Добавить в план», после чего программа добавит выбранные модули в план и отобразит их на экране.

Рисунок 2.8. Диаграмма последовательностей добавления работы в план

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

Рисунок 2.9. Диаграмма последовательностей выполнения разработки модулей

2.5 Описание проектирования графического интерфейса

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

2.5.1 Окно этапа планирования

При переходе на стадию планирования на экране пользователя появляется специальное окно, изображение которого можно проследить на рис. 2.10. С помощью сторонней библиотеки «AvalonDock» на экран были добавлены окна отображения текущих состояний найденных требований, обнаруженных модулей и нанятых сотрудников. Пользователь в режиме реального времени может наблюдать за изменениями в этих окнах и параллельно работать в главном окне.

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

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

В правой части отображаются табличным способом уже добавленные на данную итерацию работы по разработке или тестированию модулей.

Рисунок 2.10. Начальное окно этапа планирования

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

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

Рисунок 2.11. Окно этапа планирования после создания архитектуры модулей

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

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

Рисунок 2.12. Окно этапа планирования с выбранными модулями и сотрудниками

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

В случае если пользователь хочет убрать какой-либо модуль из плана, то ему необходимо выбрать его правой кнопкой мыши, а затем нажать клавишу «Delete» или изображенную кнопку «Удалить». После чего происходит изменение данных о модуле в памяти программы.

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

Рисунок 2.13. Окно этапа планирования с добавленными в план работами

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

2.5.2 Окно этапа разработки

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

Рисунок 2.14. Диаграмма классов игры «IT-менеджер»

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

Глава 3. Реализация и тестирование разрабатываемой программы

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

3.1 Реализация модуля игры

В качестве основной операционной системы для создания программы была выбрана среда Windows, так как она является самой распространенной и установленной на большинстве компьютерах в учебных заведениях. Для построения клиентского приложения под данную платформу выбрана система WPF (Windows Presentation Foundation), которая позволяет с помощью графической (презентационной) подсистемы в составе .NET Framework, использующей язык XAML, создать визуально привлекательный интерфейс взаимодействия системы с пользователем. В качестве основного языка программирования для создания системы был выбран C#, так как он удобен для использования, прост в изучении, имеет полезный синтаксис лямбда_выражений для работы с коллекциями и массивами данных, позволяет организовать работу с WPF.

3.1.1 Описание разработанных классов игровой модели

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

В Приложении D приведено графическое изображение класса «Manager», который содержит заголовки его свойств и методов. Более подробное описание этих данных выглядит следующим образом:

1. Name - имя игрока, введенное в начале игры.

2. Project - экземпляр игрового проекта.

3. GetTreeNodeOfKnownRequirements - свойство, возвращающее список требований для отображения его в виде дерева.

4. GetAnalysts - свойство, возвращающее список нанятых аналитиков.

5. GetArchitects - свойство, возвращающее список нанятых архитекторов.

6. GetDevelopers - свойство, возвращающее список нанятых разработчиков.

7. GetTesters - свойство, возвращающее список нанятых тестировщиков.

8. GetModulesForPlan - свойство, возвращающее список модулей, которые можно добавить в план.

9. GetPlan - свойство, возвращающее список модулей, которые были добавлены в план.

10. GetDevelopmentPlan - свойство, возвращающее список модулей, которые были добавлены в план для разработки.

11. GetStabilizationPlan - свойство, возвращающее список модулей, которые были добавлены в план для тестирования.

12. GetNewDevelopedModules - свойство, возвращающее список модулей, разработанных за текущую итерацию.

13. GetNewTestedModules - свойство, возвращающее список модулей, протестированных за текущую итерацию.

14. GetTreeNodeOfDevelopedRequirements - свойство, возвращающее список реализованных требований для отображения его в виде дерева.

15. GameIsEnd - свойство, возвращающее значение может ли в данный момент времени завершить игру или нет.

16. StartGame - метод создания новой игры.

17. HireEmployee - метод найма сотрудника.

18. FireEmployee - метод увольнения сотрудника.

19. GetCountNewRequirements - метод, возвращающий количество найденных новых требований.

20. SendToStakeholder - метод отправления сотрудников к выбранному стейкхолдеру.

21. FindingKnownRequirements - метод, возвращающий список найденных требований.

22. SearchingRequirements - метод поиска новых требований.

23. ModelingArchitectedModules - метод создания архитектуры модулей.

24. AddModuleToPlan - метод добавления модуля в план работ.

25. RemoveModuleFromPlan -метод удаления модуля из плана работ.

26. CalculateExpectedTime - метод расчета ожидаемой длительности работы.

27. CalculateDevelopedModules - метод расчета длительности разработки.

28. GetAllDevelopedModules - метод, возвращающий список модулей, разработанных за текущую итерацию.

29. CalculateTestedModules - метод расчета длительности тестирования.

30. FindingDevelopedRequirements - метод, возвращающий список реализованных требований.

31. FindingDevelopedModules - метод, возвращающий список разработанных модулей.

32. NonKnownRequirement - метод, возвращающий ненайденное требование.

33. FindingNonKnownRequirement - метод, возвращающий список ненайденных требований.

34. GetErrorModuleByStakeholder - метод, возвращающий список модулей с ошибкой от стейкхолдера.

35. GetNewRequirementByStakeholder - метод, возвращающий новое нереализованное требование от стейкхолдера.

36. GoToNextIteration - метод перехода к следующей итерации.

Класс «Content», показанный на рис. 3.1, содержит следующие свойства и методы:

1. Id - уникальный идентификатор контента.

2. Budget - количество бюджета, выделяемое на виртуальный проект.

3. Time - количество дней, выделяемое на проект.

4. IterationTime - длительность одной итерации.

5. ProjectTitle - название проекта.

6. ProjectDescription - описание проекта.

7. ProjectTask - задача проекта.

8. Stakeholders - список всех стейкхолдеров.

9. Requirements - список всех требований.

10. Employees - список всех сотрудников.

11. Tests - список всех тестов

12. LoadProjectDescription - метод загрузки описания проекта.

13. LoadRequirements - метод загрузки требований.

14. LoadEmployees - метод загрузки сотрудников.

15. LoadTests - метод загрузки тестов.

Рисунок 3.1. Класс «Content» игры «IT-менеджер»

Класс «Project», показанный на рис. 3.2 содержит следующие свойства и методы:

1. Budget - бюджет проекта.

2. Time - длительность проекта.

3. IterationTime - длительность одной итерации.

4. Employees - список всех сотрудников.

5. Requirements - список всех требований.

6. Stakeholders - список всех стейкхолдеров.

7. Tests - список всех тестов.

8. PassedDays - свойство, возвращающее текущий день проекта.

9. PassedIterationDays - свойство, возвращающее текущий день итерации.

10. Iteration - свойство, возвращающее текущий номер итерации.

11. Statisfaction - свойство, возвращающее удовлетворенность заказчика.

12. IncrementSatisfaction - метод, увеличивающий удовлетворенность заказчика.

13. DecrementSatisfaction - метод, уменьшающий удовлетворенность заказчика.

14. AddEmployee - метод добавления нового сотрудника.

15. RemoveEmployee - метод удаления выбранного сотрудника.

16. IncrementDay - метод, увеличивающий количество прошедших дней.

17. PayOut - метод, выплачивающий заработную плату сотрудникам.

18. IncrementIteration - метод, увеличивающий количество прошедших итераций.

Рисунок 3.2. Класс «Project» игры «IT-менеджер»

Класс «Employee», изображенный на рис. 3.3, содержит следующие свойства и методы:

1. Id - уникальный идентификатор сотрудника.

2. Name - имя сотрудника.

3. Image - ссылка на фотографию сотрудника.

4. BitmapImage - фотография сотрудника.

5. AnalystSkill - навык аналитика.

6. AnalystCapacity - производительность аналитика.

7. CurrentAnalystCapacity - текущая производительность аналитика.

8. DeveloperSkill - навык разработчика.

9. DeveloperCapacity - производительность разработчика.

10. CurrentDeveloperCapacity - текущая производительность разработчика.

11. TesterSkill - навык тестировщика.

12. TesterCapacity - производительность тестировщика.

13. CurrentTesterCapacity - текущая производительность тестировщика.

14. ArchitectSkill - навык архитектора.

15. ArchitectCapacity - производительность архитектора.

16. CurrentArchitectCapacity - текущая производительность архитектора.

17. Salary - заработная плата сотрудника.

18. SumSalary - выплаченная заработная плата сотруднику.

19. FoundRequirementsNumber - количество найденных требований.

20. DevelopedCodeLinesNumber - количество строк кода разработанного модуля.

21. FoundErrorsNumber - найденное количество ошибок.

22. IsHired - статус нанятости.

23. ClearCurrentCapacity - метод, очищающий записи текущих производительностей.

24. Hiring - метод найма сотрудника.

25. Unhiring - метод увольнения сотрудника.

Рисунок 3.3. Класс «Employee» игры «IT-менеджер»

Класс «Stakeholder» (рис. 3.4) содержит следующие свойства и методы:

1. Id - уникальный идентификатор стейкхолдера.

2. Name - название стейкхолдера.

3. Type - тип.

Рисунок 3.4. Класс «Stakeholder» игры «IT-менеджер»

Класс «Test», изображенный на рис. 3.5, содержит следующие свойства и методы:

1. Name - название теста.

2. IsImportant - статус важности.

Рисунок 3.5. Класс «Test» игры «IT-менеджер»

Класс «Requirement» (рис. 3.6) содержит следующие свойства и методы:

1. Id - уникальный идентификатор требования.

2. Name - название требования.

3. Stakeholder - стейкхолдер, предъявивший требование.

4. ImportantIndex - показатель важности.

5. MinimumSkill - минимальный уровень навыка для поиска требования.

6. DetectionIterationNumber - минимальный номер итерации для обнаружения.

7. IsFound - статус найдено требование или нет.

8. SubRequirements - список нижестоящих требований.

9. SubModules - список нижестоящих модулей.

10. FoundByEmployee - сотрудник, обнаруживший требование.

11. MainRequirement - главное требование.

12. AllSubRequirements - список всех нижестоящих требований.

13. AllSubModules - список всех нижестоящих модулей.

14. GetArchitectedModules - метод, возвращающий список модулей, добавленных архитектором.

15. GetUnarchitectedModules - метод, возвращающий список модулей, еще не добавленных архитектором.

16. AddSubRequrement - метод добавления нижестоящего требования.

17. AddSubModule - метод добавления нижестоящего модуля.

18. GetSubrequirements - метод, возвращающий список всех нижестоящих требований.

19. GetSubmodules - метод, возвращающий список всех нижестоящих модулей.

Рисунок 3.6. Класс «Requirement» игры «IT-менеджер»

Класс «Module», показанный на рис. 3.7, содержит следующие свойства и методы:

1. Name - название модуля.

2. CalculatedExpectedCodeLinesNumber - рассчитываемое архитектором количество строк кода.

3. ExpectedCodeLinesNumber - ожидаемое количество строк кода, установленное в программе.

4. ActualCodeLinesNumber - реальное затрачиваемое количество строк кода разработчиком.

5. Deadline - номер дня окончания разработки модуля.

6. ImportantIndex - показатель важности.

7. IsDeveloped - статус разработки модуля.

8. Iteration - номер итерации добавления работы в план.

9. Tests - список тестов.

10. Errors - список ошибок.

11. Developer - разработчик.

12. Tester - тестировщик.

13. AcceptedByStakeholder - статус принятия стейкхолдером.

14. Requirement - свойство, возвращающее главное требование.

15. CountFixErrors - свойство, возвращающее количество исправленных ошибок.

16. CountNotFixErrors - свойство, возвращающее количество неисправленных ошибок.

Рисунок 3.7. Класс «Module» игры «IT-менеджер»

Класс «Error», изображенный на рис. 3.8, содержит следующие свойства и методы:

1. Type - тип ошибки.

2. IsFixed - статус исправления ошибки.

3. SetErrorType - метод, задающий тип ошибки.

Рисунок 3.8. Класс «Error» игры «IT-менеджер»

3.1.2 Реализация разработанных алгоритмов

В классе «Manager» содержится метод, реализующий алгоритм определения модулей с использованием выбранного архитектора. В представлении программного кода он выглядит следующим образом:

public List<Module> ModelingArchitectedModules(Employee architect)

{

List<Module> newArchitectedModules = new List<Module>();

if (architect != null)

{

foreach (Requirement req in AllFoundRequirements)

{

if (architect.CurrentArchitectCapacity < architect.ArchitectCapacity)

{

List<Module> unarchitectedModules = req.GetUnarchitectedModules();

if (unarchitectedModules.Count > 0)

{

foreach (Module mod in unarchitectedModules)

{

int inaccuracy = 100 - architect.ArchitectSkill;

int randomInaccuracy = RandomNumber.Shared.GetRandomNumberBetween(100 - inaccuracy, 100 + inaccuracy + 1);

mod.CalculatedExpectedCodeLinesNumber = mod.ExpectedCodeLinesNumber * randomInaccuracy / 100;

newArchitectedModules.Add(mod);

}

architect.CurrentArchitectCapacity++;

}

}

}

architect.ClearCurrentCapacity();

Project.IncrementDay();

Project.PayOut();

}

return newArchitectedModules;

},

где inaccuracy - процент разброса выдачи результата от архитектора,

randomInaccuracy - разброс от идеального установленного числа строк кода модуля.

В качестве входного параметра данный метод принимает объект класса «Employee», который по смыслу является архитектором. Выходными данными является список модулей, которые были составлены сотрудником и установлены значения количества строк кода для разработки этих модулей.

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

public int CalculateExpectedTime(List<Module> modules, int capacity, bool isNewDevelop = true, bool alreadyInPlan = false)

{

int sumCodeLinesInDay = 0;

double days = 0;

foreach (var job in modules)

{

int actualExpectedCodeLinesNumber = job.ActualCodeLinesNumber > 0 && (alreadyInPlan && job.Developer == null || !alreadyInPlan && !isNewDevelop) ? job.ActualCodeLinesNumber : job.CalculatedExpectedCodeLinesNumber;

sumCodeLinesInDay += actualExpectedCodeLinesNumber;

if (sumCodeLinesInDay > capacity)

{

days += sumCodeLinesInDay / capacity;

sumCodeLinesInDay = sumCodeLinesInDay % capacity;

}

}

if (sumCodeLinesInDay > 0)

{

days++;

}

return (int)Math.Ceiling(days);

}

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

Добавление работы в план осуществляется с помощью метода «AddModuleToPlan», выраженного в программном коде следующим видом:

public bool AddModuleToPlan(Module module, Employee developer, Employee tester)

{

if (module != null)

{

if (module.IsDeveloped)

{

if (developer != null)

{

module.Developer = developer;

module.IsDeveloped = false;

module.Tester = (tester != null) ? tester : module.Tester;

module.Iteration = Iteration;

return true;

}

else if (tester != null)

{

module.Tester = tester;

module.Iteration = Iteration;

return true;

}

else return false;

}

else if (developer != null)

{

module.Developer = developer;

module.Tester = (tester != null) ? tester : module.Tester;

module.Iteration = Iteration;

return true;

}

else return false;

}

else return false;

}

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

Для удаления работы из плана используется следующая функция с выбранным модулем на входе и статусом об успешном удалении на выходе:

public bool RemoveModuleFromPlan(Module module)

{

if (module != null)

{

if (module.IsDeveloped)

{

module.Tester = null;

}

else

{

module.Developer = null;

module.Tester = null;

}

return true;

}

else return false;

}

На этапе разработки используется алгоритм расчета количества строк кода в зависимости от навыка разработчика, поэтому метод, реализующий его, выглядит следующим образом:

public List<Module> CalculateDevelopedModules(int passedDays = -1)

{

passedDays = (passedDays == -1) ? PassedDays : passedDays;

var newPassedDays = passedDays;

var developers = GetDevelopmentPlan.Select(x => x.Developer).Distinct();

foreach (var developer in developers)

{

int sumCodeLinesInDay = 0;

double days = passedDays;

foreach (var job in GetDevelopmentPlan.Where(x => x.Developer == developer))

{

int inaccuracy = 100 - developer.DeveloperSkill;

int randomInaccuracy = RandomNumber.Shared.GetRandomNumberBetween(100 - inaccuracy, 100 + inaccuracy + 1);

job.ActualCodeLinesNumber = job.ExpectedCodeLinesNumber * randomInaccuracy / 100;

developer.DevelopedCodeLinesNumber += job.ActualCodeLinesNumber;

sumCodeLinesInDay += job.ActualCodeLinesNumber;

if (sumCodeLinesInDay > developer.DeveloperCapacity)

{

days += sumCodeLinesInDay / developer.DeveloperCapacity;

sumCodeLinesInDay = sumCodeLinesInDay % developer.DeveloperCapacity;

}

job.IsDeveloped = true;

job.Iteration = Iteration;

job.Errors = new List<Error>();

int countErrors = job.ActualCodeLinesNumber * (100 - developer.DeveloperSkill) / 1000;

for (int i = 0; i < countErrors; i++)

{

var error = new Error();

error.SetErrorType();

job.Errors.Add(error);

}

job.Deadline = (int)Math.Ceiling(sumCodeLinesInDay > 0 ? days + 1 : days);

}

if (sumCodeLinesInDay > 0)

{

days++;

}

if ((int)Math.Ceiling(days) > newPassedDays)

newPassedDays = (int)Math.Ceiling(days);

}

Project.IncrementDay(newPassedDays - passedDays);

return GetNewDevelopedModules;

}

В результате работы метод возвращает список модулей, которые были задействованы в разработке на данной итерации, с измененными новыми данными.

3.2 Тестирование и отладка программы

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

В рамках данной работы было проведено тестирование всех функций этапа планирования и разработки игры «IT-менеджер» и результат выполнения подготовленных тестов продемонстрирован в табл. 3.1.

Таблица 3.1. Тестирование функций этапов планирования и разработки

Входные данные

Результат

Выполнение

Выбор архитектора из выпадающего списка сотрудников

Отображение на экране выбранного сотрудника

+

Нажатие кнопки «Создать архитектуру модулей». Архитектор выбран

Отображение на экране информации о новых добавленных модулей и обновление списка всех модулей

+

Нажатие кнопки «Создать архитектуру модулей». Архитектор не выбран

Появление сообщения о необходимости выбора архитектора

+

Выбор модуля из выпадающего списка

Отображение на экране выбранного модуля

+

Выбор нескольких модулей из выпадающего списка

Отображение на экране информации о выбранных модулях

+

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

Отображение на экране выбранного сотрудника и информации об ожидаемой длительности разработки

+

Выбор разработчика из выпадающего списка сотрудников. Модули не выбраны

Отображение на экране выбранного сотрудника, информация об ожидаемой длительности разработки не отображается

+

Выбор тестировщика из выпадающего списка сотрудников. Выбран хотя бы один модуль

Отображение на экране выбранного сотрудника и информации об ожидаемой длительности тестирования

+

Выбор тестировщика из выпадающего списка сотрудников. Модули не выбраны

Отображение на экране выбранного сотрудника, информация об ожидаемой длительности тестирования не отображается

+

Нажатие кнопки «Добавить в план». Выбран хотя бы один модуль, разработчик и тестировщик

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

+

Нажатие кнопки «Добавить в план». Выбран хотя бы один модуль и разработчик. Тестировщик не выбран

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

+

Нажатие кнопки «Добавить в план». Выбран хотя бы один модуль и тестировщик. Разработчик не выбран. Модули уже были ранее разработаны

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

+

Нажатие кнопки «Добавить в план». Выбран хотя бы один модуль и тестировщик. Разработчик не выбран. Модули не были ранее разработаны

Появление сообщения о необходимости разработки модулей перед их тестированием

+

Выбор одной или нескольких строк в таблице плана и нажатие кнопки «Удалить»

Удаление строк из таблицы плана на экране пользователя. Обновление данных о длительности составленного плана

+

Выбор одной или нескольких строк в таблице плана и нажатие клавиши «Delete»

Удаление строк из таблицы плана на экране пользователя. Обновление данных о длительности составленного плана

+

Нажатие кнопки «Следующий этап»

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

+

3.3 Проведение апробации игры

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

Первая апробация была проведена на занятии студентов образовательной программы «Программная инженерия» НИУ ВШЭ - Пермь, которое состоялась 9 ноября 2017 года. В рамках выделенного времени на дисциплине «Обеспечение качества и тестирование» студенты ознакомились с игрой «IT-менеджер» и получили навыки по распределению обязанностей среди участников проекта. После проведения мероприятия были собраны отзывы среди участников. Несколько из них представлены в Приложении G. В основном студенты положительно отозвались о программе, указывая, что действительно получили некоторый опыт в управлении ресурсами, а также указали на некоторые незначительные ошибки в реализации, которые в дальнейшем были исправлены.

12 ноября 2017 года была проведена Осенняя школа по программной инженерии, в рамках которой игра «IT-менеджер» была протестирована более чем 40 школьниками [19]. К сожалению, отзывов от них в письменном виде не было собрано, поскольку игра проводилась как часть большого мероприятия, однако в устном диалоге участники также высказывали положительное мнение об игре. С точки зрения проведения игры, можно сказать, что школьникам сложнее понять используемый в игре учебный материал, поскольку их базовых знаний о программировании недостаточно, чтобы понять принципы командной разработки, приближенной к реальности, которая реализована в игре.

С учетом некоторых внесенных изменений в программу 7 декабря 2017 года была проведена еще одна игра со студентами первого курса на дисциплине «Введение в программную инженерию». Данная целевая аудитория является схожей со школьниками, однако в этом случае можно с уверенностью сказать, что большинство из них знакомы с основами программирования и имеют некоторые знания о жизненном цикле разработки программного обеспечения. Таким образом, проведенная игра позволяла оценить пригодность программы для молодой аудитории, еще плохо разбирающейся в сфере информационных технологий. Во время проведения игры студенты были увлечены игровым процессом и задавали некоторые вопросы, касающиеся управления рабочими и игры в целом. Часть из них были настолько заинтересованы, что предлагали свои варианты решения некоторых обнаруженных ими проблем, большинство из которых касалось ведения игрового процесса, а не существенных ошибок, вызывающих падение программы. Также была собрана рефлексия с 49 участвующих студентов, часть этих отзывов приведена в Приложении H. На ее основе можно сделать вывод, что в целом игра нравится пользователям и вполне подходит для обучения управленческим навыкам командной разработки.


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.