1

Системный Анализ и Требования / Re: Как разложить требования по 2м Use Case

« : 01 Апреля 2015, 13:53:36 »

Пока жду ответа, описал альтернативный поток юзкейса "работа с картой"



1)   Запускается функция, которая открывает консоль. В консоли выводится строка: {команда ping и логический адрес устройства} (если актив имеет более одного логического адреса, то выводится первый адрес, который можно отредактировать вручную).
2)   Пользователь проверяет строку консоли, если необходимо, вручную редактирует её и инициирует запуск.
3)   Команда передается в Агент доступности
4)   Результат выполнения команды выводится в консоли.

2

Системный Анализ и Требования / Re: Как разложить требования по 2м Use Case

« : 01 Апреля 2015, 12:11:43 »

Если основное назначение UC1 — добавлять на карту новые объекты и добавление всегда или в большинстве случаев должно сопровождаться проверкой доступности, то проверка доступности должна быть не в альтернативных потоках, а в основных.

Спасибо Денис.
Назначение UC1 - просмотр состояния активов на карте.
Актив может быть в следующих состояниях:
Доступен
Недоступен
Доступность не контролируется

кроме того, с активом  может произойти инцидент, это отслеживается сторонней SIEM системой.
Инцидент на активе также отображается на карте рядом с иконкой актива (условно молния)

Проверка доступности описана основным потоком в UC2, в агенте доступности.
Актив начинает проверяться на доступность тогда, когда пользователь в UC2 добавит актив в одну из групп Агента.
сущность группа - контейнер настроек, какие проверки должны осуществляться.
Функционалом предполагаются 2 варианта проверок -
1. цикличная - агент опрашивает устройства по очереди
2. по требованию. Это как раз случай, когда пользователь выбирает актив на карте и жмет кнопку на инфопанели "ICMP проверка (пинговать) Актива"

Проверка актива на доступность не связана с картой непосредственно.
Если он добавлен в Агент доступности (АД), то он опрашивается вне зависимости от того, есть он на карте или нет.

Upd: Сейчас мы поставляем Систему Заказчику включая АД, но вообще он оплачивается отдельно и заказчик может купить пакет, в который АД не входит.
Соответственно на карте будут отображаться только Активы и их инциденты, без функций опроса доступности.

3

Системный Анализ и Требования / Как разложить требования по 2м Use Case

« : 01 Апреля 2015, 10:26:09 »

Уважаемые форумчане, обращаюсь с вопросом, как разложить требования по 2м Use Case.

Описание:

Система предоставляет функционал работы с картой, на которую пользователь добавляет активы своего предприятия.
UC1 - Работа с картой .
Некоторые активы физически представляет собой сетевые устройства, узлы сети.
По таким устройствам есть дополнительный функционал - определить их доступность, утрированно отправить сетевой пакет на узел проверить что он пришел. Функционал осуществляет Агент доступности.
UC2 - Работа с агентом
Агент осуществляет периодический опрос активов, которые внесены в его список. Также на карте есть кнопки осуществления запроса по требованию
Соответственно когда пользователь заходит на карту и выбирает актив, у него появляются кнопки - осуществить запрос выбранного актива. Т.е. функция инициируется с карты, а выполняет её агент доступности.

Вопрос
Как в этом случае оформить это в юзкейсах?
Начал писать альтернативные потоки в UC1
"Осуществить запрос выбранного актива"
есть вариант описать в UC1 что инициируется функция, потом управление передается в UC2 где осуществляется определение доступности, а данные доступности возвращаются в UC1.

Вопрос: Корректно ли это, или лучше всё описать в агенте доступности (UC2)?
Предложите решение которое на ваш взгляд будет правильным.