И. А. Кудрявцев аучный (стр. 6 из 9)
Во-вторых, не стоит забывать о том, что в разработке продукта могут принимать участие различные люди, это могут быть тестеровщики, просто наблюдатели или еще кто-то. И у всех у них тоже должен быть определенный набор прав, и, скорее всего, специфический.
Все это наводит на мысль о том, что в создаваемой системе стоит предусмотреть возможность создания новых ролей, причем желательно, чтобы они были настраиваемыми. Поэтому, хотя в текущей реализации мы остановимся на выделенных основных ролях, будем иметь это в виду.
Определим базовую функциональность для каждой из ролей.
Рис.4.1.1.
Рисунок 4.1.1. не требует подробных пояснений, в полной мере отражая функции роли «Разработчик». На рисунке 4.1.2. представлены функции «Владельца продукта», которые в точности совпадают с функциями «Scrum мастера». Поэтому в дальнейшем, в рамках этого абзаца, все, что говорится о «Владельце продукта», применимо и к «Scrum мастеру». «Владелец продукта» наследует все функции роли «Разработчик», расширяя ее и добавляя новые. Он обладает максимальным объемом прав, которых достаточно для использования создаваемой системы в полной мере. Единственное ограничение, которое на него налагается – это то, что он не может менять временную оценку не своих задач, что соответствует методологии Scrum.
Рис. 4.1.2.
Обязанности по созданию проектов и настройке системы возложены на роль «Администратор» (рис. 4.1.3.)
Рис. 4.1.3.
В рамках данной работы подробно рассматриваются лишь архитектурно – значимые варианты использования. Все остальное множество возможных вариантов использования будет использовано без детального описания.
Покажем на диаграммах выделенные архитектурно-значимые варианты использования для большей наглядности (рис.4.1.4.). В этом случае варианты использования также одинаковы как для «Scrum-мастера», так и для «Владельца продукта», и для обеих этих ролей справедливы варианты использования роли «Разработчик».
Рис.4.1.4.
Набор архитектурно – значимых вариантов использования более подробно описан в Приложении А.
1.7 Проектирование схемы базы данных
Реализация любого приложения, связанного с работой с базой данных, начинается с проектирования ее схемы. От того, насколько удачно это будет сделано, во многом зависит удобство работы с хранилищем, эффективность обработки данных, архитектура системы, набор классов и т.д.
В результате проектирования системы управления проектами, основанной на методологии Scrum, была получена диаграмма, представленная на рис.4.1.
Для того, чтобы не пришлось изучать ее самостоятельно, поясним семантику множеств сущностей и множеств связей.
Начнем с очевидных множеств сущностей, таких как Project и Customer. Project – это все проекты компании, у которых определены бюджет и крайний срок сдачи, а Customer – заказчики этих проектов, причем очень часто компания сотрудничает с одним и тем же заказчиком довольно продолжительное время.
Как правило, требования программных продуктов постоянно меняются, и было бы неплохо отслеживать их динамику, чтобы в любой момент можно было посмотреть, кто, что и когда изменил и какие файлы добавил или удалил. За эту функцию отвечает Requirement, а Document-Type определяет, какой тип документа (техническое задание, прототип дизайна сайта и т.п.) описывается.
В компании может существовать несколько команд разработчиков, каждая из которых участвует в каком-то проекте. Очевидно, что за весь свой трудовой путь она принимает участие во многих проектах, а иногда в нескольких одновременно. Сами команды хранятся в Team, а история их разработок в Project-Team. Множество сущностей Project-Member хранит в себе непосредственно людей, хоть каким-то образом относящихся к программным продуктам организации, будь то администратор системы, разработчик, человек от компании-заказчика и т.д.
Множество сущностей Project-Member-Role определяет, что определенный человек в определенной команде играет определенную роль. Все роли, которые возможны, находятся в Project-Role. Учитывая выбранную методологию Scrum, ими могут быть, например, Scrum-мастер, владелец продукта, разработчик, тестеровщик и т.д.
Кроме роли в проекте каждый пользователь системы имеет еще одну роль – User-Role. Она определяет права доступа непосредственно в систему, то есть используется при авторизации и аутентификации.
Если снова вспомнить Scrum, то не придется объяснять, что несут в себе такие множества сущностей, как Product-Task, Sprint и Sprint-Task. Каждый спринт относится к конкретному проекту. На него планируется определенный набор задач, на которые разбиваются все глобальные требования к системе. Декомпозированные задачи могут иметь иерархическую структуру благодаря ParentTask. Кроме того, предусмотрена возможность организации задач таким образом, что нельзя приступить к выполнению какой-либо задачи, пока не выполнена другая, то есть возможность реализации отношения зависимости. Конечно, в идеале каждая задача, запланированная на спринт, должна быть обязательно выполнена в его рамках. Но никто не застрахован от того, что выполнить ее просто не успеют из-за внезапно возникших проблем, и она перейдет на следующую итерацию. Именно поэтому на указанной диаграмме задача может относиться ко многим спринтам.
Рис. 4.1.1.
Каждая задача постоянно находится в динамике, у нее может меняться тип («задача», «улучшение», «дефект» и т.д.) и статус («новая», «завершена», «в разработке» и т.д.). Эти параметры отражены в Task-Type и Status. Чтобы была возможность просмотреть всю историю изменений для конкретной задачи, внесено множество сущностей Task-History, по которой можно отследить, когда и какой член команды изменил параметры задачи и почему, причину позволяют узнать комментарии. Комментарии можно оставлять не только при изменении задачи, но и просто внутри нее, ведя, например, какое-то обсуждение.
Для каждого проекта может быть свой набор приоритетов для выполняемых задач, это может зависеть от заказчика или специфики работ. Кому-то удобнее выставлять приоритеты цифрами, а кто-то предпочитает ограничиться тремя емкими фразами. Учитывая эту возможность, в схеме появляется множество сущностей Priority-Set, которая ее предоставляет. При этом все приоритеты берутся из Priority, которое можно дополнять новыми вариантами.
Очень часто при работе с задачами требуется возможность прикрепления файла, например техническое задание, которое пришло от заказчика, скриншот ошибки и др. Для этого в схеме появилось множество сущностей File, которое служит для хранения файлов Requirement, ProductTask, SprintTask и Comment. Для определения того, к какой сущности относится конкретный файл, в схему было введено Entity, которое и содержит в себе список всех возможных множеств сущностей, для которых актуально наличие файла.
В системе есть несколько видов пользователей, и каждый из них обладает определенным набором прав, который регламентирует, что пользователь может делать, а что – нет. Для того, чтобы сделать эту часть проектируемой системы настраиваемой, появилось множество сущностей Rule, в котором содержатся все возможные действия пользователей, права на выполнение которых могут быть ограничены по каким-либо причинам. (Подробнее об этом говорилось выше, в параграфе 4.1.)
Реляционная схема базы данных представлена в Приложении Б.
Прежде чем приступать к реализации, необходимо не только четко знать, что должна уметь делать система и что могут делать различные пользователи, но и четко представлять себе, как это все должно выглядеть. Иначе очень часто происходят такие неприятные ситуации, когда программист закончил разработку какой-то функциональности, а оказалось, что при таком интерфейсе совершенно неудобно работать или даже полностью нарушена задуманная логика приложения. В этом случае зачастую приходится не только изменять внешний вид страниц, но и переписывать большой объем кода, а иногда даже затрагивать архитектуру программного продукта, что влечет за собой дополнительные немалые затраты времени, сил, а также материальные затраты. Чтобы этого не допустить, необходимо заранее позаботиться о внешнем виде и удобстве интерфейса системы.
Перед началом непосредственной реализации нашего приложения такой прототип был создан.
Хотя было решено, что на данном этапе разработки мы оставили те четыре основные роли, которые были выделены в параграфе 4.1., а также жестко закрепили за ними определенные права доступа в системе, настройка ролей все-таки была включена в прототип. На рисунке 4.3.1. показан список всех ролей с назначенными им правами, которые можно изменять.
Рис. 4.3.1.
Рисунок 4.3.2. показывает, как будет происходить изменение набора прав для выбранной роли.
