Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: panov.st от 11 Июня 2016, 16:22:26
-
Добрый день!
Вопрос касается области управления доступом (access control, rbac)
Кто-нибудь может порекомендовать материалы — статьи, книжки — , в которых описываются методологии, подходы к сбору и анализу требований по управлению доступом в процессе разработки функционала системы? В частности, меня интересует какие артефакты — формы, отчеты, диаграммы — имеются для формализации и фиксации правил доступа в контексте некоторой бизнес функции.
Например, если через Модель Предметной Области можно управлять изменениями предметной области, которые должны быть учтены в системе, то в области упраления доступом существуют модели (диаграммы, отчеты, схемы) через которые разработчик может управлять изменениями в правилах доступа?
-
Могу по другому сформулировать вопрос.
Наш проект начинался с небольшого набора функционала для которого достаточно было 5-6 ролей.
С течением времени проект разрастался и новый функционал требовал более тонкой настройки прав доступа.
У команды, на данный момент, нет опыта работы с такими методологиями, как, например, Role engineering (top-down, bottom-up, Hybrid), как описано в статье https://blogs.oracle.com/OracleIDM/entry/enterprise_role_definition_best_practices (https://blogs.oracle.com/OracleIDM/entry/enterprise_role_definition_best_practices)
Какие бы вы дали советы команде
- с чего начать (к каким материалам стоит обратиться),
- понять нужен или не нужен нам Role engineering
чтобы в конце-концов выстроить грамотный процесс проектирования и поддержки подсистемы управления доступом?
-
Я думаю, что можно начать отсюда:
https://en.wikipedia.org/wiki/Role-based_access_control
Хотя, наверное вы уже это прочитали...
Вообще, нужно идти ИМХО на форумы по ERP системам, и там искать ответ - как это устроено у них, н-р, в 1С, МС и САП. Здесь вряд ли кто-то даст ответ...
-
Я думаю, что можно начать отсюда:
https://en.wikipedia.org/wiki/Role-based_access_control
Хотя, наверное вы уже это прочитали...
Вообще, нужно идти ИМХО на форумы по ERP системам, и там искать ответ - как это устроено у них, н-р, в 1С, МС и САП. Здесь вряд ли кто-то даст ответ...
Спасибо за ответ, bas!
Почему я здесь вопрос задал?
Я думал про оформление бизнес требований некоторой фичи F в виде, скажем, User Story (из scum), или просто текстом.
И одним из пунктов я предполагал будет "Правила доступа". Ведь это тоже часть бизнес-логики фичи F.
Именно на данном шаге я задумался об оформлении этих требований.
Под сложностью описания требований я понимаю не столько перечисление ролей, которые могут иметь доступ к операции над объектом, сколько описание ограничений (особенно динамических)
- только мои пациенты
- пациенты в моей организации
- доступ по вертикальной иерархии подчинения
- доступ по территориальному признаку (федеральный, региональный, местный)
- и т.п.
Если, скажем, написать, что правила доступа фичи F, такие же, как у фичи N, то эта формулировка пораждает ряд вопросов:
- какие правила у фичи N?
- действительно ли правила повторяются?
- может быть, тут можно выполнить объединение правил?
Т.е. я подвожу к вопросу, должен ли системный аналитик формально описывать правила доступа, максимально полно, как, к примеру, матрицу (или другую форму представления правил)?
Для того, чтобы программисту только осталось внести изменения в код.
В итоге, если это действительно верно - полностью расписывать в требованиях правила доступа к фичи F - получается, что на этапе проектирования фичи F нужно выполнить некоторое подобие аудита правил доступа, т.е. некоторый процесс "пересмотра" существующих правил доступа, но уже с учетом новой фичи F.
Именно поэтому я вышел на процесс role engineering, правда, пока не смог определится с тем, поможет он в данном вопросе или нет
Если мой ход рассуждения неверен, Вы тоже, пожалуйста, скажите об этом.
Попробую спросить на форумах erp систем.
Еще раз сасибо за подсказку!
-
Я писал варианты такого документа. А еще посмотрите http://www.trackstudio.ru/ В системе очень неплохо реализована возможность настройки прав доступа. На сайте есть несколько статей и пример ТЗ на настройку.
-
Я писал варианты такого документа. А еще посмотрите http://www.trackstudio.ru/ В системе очень неплохо реализована возможность настройки прав доступа. На сайте есть несколько статей и пример ТЗ на настройку.
SALar, а Вы могли бы раскрыть состав и структуру этого документа? Я правильно понял, что у вас была форма документа, разработанная полностью внутри вашего проекта/компании?
Пример ТЗ, о котором вы говорили, не могу найти
-
С сайта трекстудии
-
SALar, огромное спасибо!
Думаю, именно такой документ я и искал. По крайней мере его можно брать за основу для развития своего решения: матрица + немного текстового описания + диаграммы.
Плюс появилось желание регламентировать состав и структуру ТЗ для бизнес функций - сейчас у нас описание требований происходит в произвольной форме: тоже есть картинки, диаграммы, текстовое описание, но они не так структурированы, и не всегда можно уследить за их полнотой.
SALar, а вы не подскажете, что за нотация использовалась для диаграмм из Приложения?