Термин «матрица CRUD» в значении «инструмент визуализации и анализа прав доступа пользователей к данным» встречается в документации к сайтам, базам данных и корпоративным порталам. В этой статье разберемся, что под ним понимают: покажем, как выглядит матрица CRUD, поясним, как она связана с ролевой моделью, приведем примеры, как составляют и применяют такие матрицы, а также поделимся опытом: как мы в Uplab работаем с этим инструментом.
Представим типичный сайт компании. Администратор сайта может видеть и загружать все документы. Пользователи — только читать. А руководители подразделений — добавлять, читать и править, но только для своего подразделения... Как правило, все эти роли и доступы известны ещё до разработки и спроектированы уже на на первых этапах создания сайта. Но как разработчики, которые не знают, как устроена компания, могут правильно разработать и настроить все доступы?
Действительно, при проектировании сервиса разработчикам могут быть непонятны многие бизнес-процессы и связи между ними. Это иногда приводит к созданию лишних пользовательских ролей и неправильной настройке доступа. Чтобы такой проблемы не возникло, разрабатывается таблица с подробным описанием ролей и доступов, которая называется «матрица CRUD».
Но прежде, чем мы рассмотрим примеры таких матриц и расскажем о принципах их создания, приведём немного общей теории.
Матрица CRUD представляет собой таблицу, где строки соответствуют различным ролям пользователей (например, сотрудник отдела, директор отдела, финансист, гость), а столбцы — действиям, которые могут быть выполнены с определенными данными или разделами.
Подобную матрицу применяют в разработке программного обеспечения для визуализации и анализа прав доступа пользователей к данным.
CRUD — это аббревиатура, обозначающая четыре основные операции, которые могут быть выполнены с данными:
Матрица CRUD, она же матрица ролей и полномочий, позволяет наглядно представить, какие действия разрешены для каждой роли пользователя в отношении каждого типа данных. Например, администратор может иметь право на все четыре операции (Create, Read, Update, Delete) для всех типов данных, в то время как гость может иметь право только на чтение (Read) некоторых данных.
Этот инструмент используется не только при разработке сайтов, но и в других цифровых продуктах.
Визуальное представление прав доступа в виде матрицы CRUD упрощает разработку и тестирование системы, а ещё облегчает коммуникацию: такая визуализация хорошо понятна для разработчиков, менеджеров и заказчиков при обсуждении прав доступа. Поэтому иметь представление о ней стоит не только разработчикам, но и аналитикам и менеджерам проектов. Также таблица пригодится администраторам системы, потому что она наглядно показывает принципы управления доступом.
CRUD идёт бок о бок с ролевой моделью и с функционалом самой системы. И именно функционал всегда становится отправной точкой для создания матрицы. Чтобы понять, какой именно функционал нужен, представители бизнеса и команда разработки подробно разбирают бизнес-процессы и роли сотрудников в них. Ролевую модель будущего сайта начинают составлять уже на первых этапах проектирования проекта.
Рассмотрим на примере, как могут выглядеть рабочие вводные и готовая матрица CRUD.
Вводные данные:
Исполнительный директор имеет право просмотра всей информации; тимлид видит эффективную загрузку своего подразделения, а также выработку и финансовые данные только по своему подразделению. Сотрудник видит только свои показатели: сколько он отметил рабочего времени, какая у него эффективная загрузка, на каких проектах он работал, какие он сдал документы. Исполнительный директор может добавлять любые данные. Бухгалтерия может видеть всё, при этом у неё есть доступ на редактирование и обновление финансовых данных.
Если всю эту информацию компактно визуализировать в виде матрицы CUD, получится так:
Стандарты заполнения матрицы могут меняться от проекта к проекту и отличаться у разных разработчиков. Но основные данные, которые лежат в её основе, неизменны.
Любой функционал в системе, каждый раздел нужно внести в матрицы CRUD. Чем подробнее и детальнее она составлена, тем проще будет на этапе разработки и тестирования.
Разберём, какое место (а точнее, какое время) занимает составление матрицы CRUD в общей дорожной карте работы над сайтом.
Всё начинается ещё с пресейла, то есть с первичного обсуждения сроков и стоимости работ. Вопросы, которые обязательно зададут разработчики: «Кто пользователи будущего ресурса, какие есть роли?».
В общих чертах матрица доступа расписывается вместе с ролевой моделью на этапе проработки общей архитектуры цифрового продукта. Далее, на этапе аналитики, идёт глубокая проработка всех разделов и ролей пользователей, матрица CRUD детализируется.
На следующих этапах при разработке каждого раздела сразу же указывается, кому он доступен: сразу идёт разграничение прав пользователей. По ходу разработки матрица дополняется, могут меняться детали.
В тестирование готового проекта входит и проверка доступов всех ролей: тестировщик выполняет вход под каждый ролью заходит и проверяет доступность. Поэтому матрица CRUD также важна и при тестировании сайта.
В основе матрицы CRUD лежит идея безопасности через контроль и управление доступом и компактная удобная форма представления важной информации о ролях доступах. Поэтому инструмент удобен и заказчику, и разработчику.
Матрица CRUD — это незаменимый инструмент как для заказчика, так и для разработчика. Она обеспечивает прозрачность, структурированность и эффективность процесса разработки сайта, что в конечном итоге приводит к созданию качественного и функционального продукта, удовлетворяющего требованиям бизнеса и пользователей.
CRUD идёт бок о бок с ролевой моделью и с функционалом самой системы. И хотя функционал — отправная точка для создания матрицы, ролевая модель тоже очень важна для создания матрицы.
Матрица CRUD — это матрица доступа к функционалу; разграничение прав на тот или иной функционал. Она работает не только с процессами и функциями, но и с наборами данных: какие данные какие пользователи видят. Использование этого инструмента помогает оптимизировать разработку и выстроить эффективную коммуникацию между заказчиком разработчиком, а также продуктивно общаться внутри команды разработки.
Комментарии к статье
Комментарии: 0