Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Nastya от 15 Декабря 2015, 17:00:55
-
Всем добрый день!
Возможно, кто-то подскажет, есть такой вопрос.
В данный момент занимаюсь написанием документации по функционалу ролевого доступа в админке: есть менеджеры, их можно объединить в группы, создаются роли с установкой вручную галочек к чему будет доступ, а к чему нет. Возможен вариант установки "может если является членом группы".
Главный вопрос в том, как нарисовать диаграмму high-level flow для всего этого процесса, что она будет в себя включать. С диаграммами я на вы. Буду благодарна любой помощи. :)
-
Это ?
-
Всем добрый день!
Возможно, кто-то подскажет, есть такой вопрос.
В данный момент занимаюсь написанием документации по функционалу ролевого доступа в админке: есть менеджеры, их можно объединить в группы, создаются роли с установкой вручную галочек к чему будет доступ, а к чему нет. Возможен вариант установки "может если является членом группы".
Главный вопрос в том, как нарисовать диаграмму high-level flow для всего этого процесса, что она будет в себя включать. С диаграммами я на вы. Буду благодарна любой помощи. :)
Это пользовательская документация или внутренняя?
Почему рисование диаграммы - это "главный вопрос"? И какой смысл вы вкладываете в слово "flow" (это слово обычно подразумевает описание какой-то последовательности действий)?
-
Это пользовательская документация или внутренняя?
Почему рисование диаграммы - это "главный вопрос"? И какой смысл вы вкладываете в слово "flow" (это слово обычно подразумевает описание какой-то последовательности действий)?
Спасибо за ответ в теме!
Документация для разработчиков: Functional Specification Document
Делаю по образцу компании, в которую недавно пришла. Самым первым пунктом во всех спеках у них идет схема под насванием High-level flow, которая в общем описывает функцию, для которой создана спека: создание какой-то сущности, к примеру или предоставление.
И вот как это отобразить для создания ролей и групп и навешивания на менеджера не представляю, т.е. получается какой-то примитив, непонятно зачем он вообще нужен.
-
Это ?
В этом и проблема, что будет делать Роль я не могу описать. Т.к. сами по себе роли не определены, все они будут создаваться по усмотрению менеджеров и админа (он будет просто хардкодом забит). Т.е:
Есть менеджер без группы и роли - ничего не видит.
Добавим его в группу (предварительно создав) - это ничего ему не даст без роли.
Создаем роль, которая представляет собой: название и выставление чекбоксами разрешений ("может", "не может", "может, если менеджер этой сущности", "может, если состоит в группе с менеджером сущности") к определенной активности для определенного раздела админки. Один из чекбоксов - "может , если состоит в группе с менеджером данной сущности". Т.е. тут роль и будет иметь смысл.
Флоу - как я поняла по примерам - это высокоуровневая диаграмма действий. Как она будет выглядеть для моей фичи не пойму. И нужна ли она. Может ее вообще для моего варианта не нарисовать, а нужно что-то другое?
-
В данный момент занимаюсь написанием документации по функционалу ролевого доступа в админке: есть менеджеры, их можно объединить в группы, создаются роли с установкой вручную галочек к чему будет доступ, а к чему нет. Возможен вариант установки "может если является членом группы".
Главный вопрос в том, как нарисовать диаграмму high-level flow для всего этого процесса, что она будет в себя включать. С диаграммами я на вы. Буду благодарна любой помощи. :)
Если оставить пока за скобками flow, а говорить об упомянутой здесь диаграмме вариантов использования, то в этом случае, на первый взгляд, видны варианты использования вроде таких: Создать роль, Настроить доступ для роли, Назначить роль пользователю (менеджеру?).
Не совсем понятно, чем роли отличаются от групп, но если отличаются, то для групп появляется свой набор вариантов использования (ВИ).
Кто будет выполнять все эти настройки? Если только админ, то у вас на диаграмме появляется единственный человечек - Администратор. Если в процессе настройки участвует кто-то ещё, то, как минимум, у них с администратором будет разный набор доступных ВИ (иначе нет смысла их разделять).
Документация для разработчиков: Functional Specification Document
Делаю по образцу компании, в которую недавно пришла. Самым первым пунктом во всех спеках у них идет схема под насванием High-level flow, которая в общем описывает функцию, для которой создана спека: создание какой-то сущности, к примеру или предоставление.
А от вас требуют делать только по такому образцу? Или вы сами решили, что это необходимо? В таких случаях лучше спросить у руководителя.
-
Ай, все-то вы (автор, ваша организация) усложняете... Диаграмма, сдается мне, будет состоять из одного человечка, подписанного "админ" и одного огурца, надписанного "расставить галки".
А если серьезнее, в данном случае нужен не flow (которого по сути нет), а некий регламент наделения полномочиями. Кому можно, что можно, где можно, в течение какого времени можно. А также, кто вносит изменения и кто контролирует. Под "кто" могут пониматься как роли в системе, так и должности в организации.
Если очень нужно описать именно процесс наделения полномочиями - ну так его и опишите. Мол, в начале не было ничего. И пришел админ, и сказал он "да будет пользователь". Увидел админ, что пользователь гол и одинок. И выдал он ему права, и включил его в группы. И увидел дело рук админа офицер СБ, и изрёк "это хорошо".