На рис. 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 - длительность одной итерации.