Для начала пользователю следует определить модули, которые будут добавляться в план, выбрать сотрудников на разработку и тестирование. Также предполагается предварительно добавлению работы в план отображать ожидаемое затрачиваемое время, необходимое на разработку или тестирование выбранных модулей с учетом характеристик назначенных работников. Диаграмма активностей алгоритма расчета ожидаемой длительности разработки модулей в зависимости от навыка разработчика назначенного сотрудника представлена на рис. 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 Описание поведения системы
После того как была описана статическая структура системы, необходимо выполнить моделирование динамических аспектов программы. Для этого используется диаграмма последовательностей, которая представляет собой графическую модель динамики взаимодействия объектов во времени для определенного варианта использования.