Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - chicago2018

Страницы: 1
1
хм, IEEE 830-1998 есть в переводе на русском, а IEEE 29148:2011 еще не перевели?

2
Объясните пожалуйста разницу в этих двух терминах на пальцах (без отсылки на эти ваши интернеты).

3
Спасибо. Будем изучать  ;)

4
Если я правильно понимаю, то можно классифицировать ВИ по таким признакам как:
- тип ВИ: бизнесовый/системный
- уровень ВИ: обобщенный/пользовательский/подфункции - раз, два
- прозрачность ВИ: черный ящик/прозрачный ящик

Например, все ВИ на диаграмме по этой ссылке, я бы классифицировал как:
- тип ВИ: бизнесовый
- уровень ВИ: пользовательский
- прозрачность ВИ: черный ящик

Направьте меня на путь истинный, если ошибаюсь :)


5
Пример ДВИ 1:


Пример ДВИ 2:


1. Насколько корректно использовать отношение обобщения, как в примере на ДВИ 2, для того чтобы:
- показать задействуемые бизнес-подразделения
- показать, что 1 сотрудник может выполнять несколько ролей
- избежать большого количества связей на диаграмме (только не в моём случае ;D)

2. Правильно ли я понимаю, что в ВИ уровня "Пользовательский" (по Коберну) описываются только Бизнес ДЛ? Т.е. Системные ДЛ не описываются?

6
Главное в ВИ – это сценарии, основной и альтернативные. В приведенном примере основной сценарий невнятный, альтернативным нет места
Делать разбивку на основной и альтернативные сценарии пока не стал, чтобы не усложнять описание, т.к. это пока черновик..


совершенно непонятно, зачем переделывать плохую user story в плохой use case.
А чем именно плох приведенный user story?


Но, может быть, у вас есть примеры попроще?
Подготовлю примеры к выходным

7
Доброго дня!

Проект на этапе анализа требований.
Что имеем: ~100 бизнес-требований описанных в формате User Story
Что хочется сделать: для каждого User Story описать 1 или несколько Use Case, для того чтобы:
- детализировать существующие требования
- выделить функциональные требования
- описать интерфейсы максимально абстрактно, чтобы не ограничивать команду разработки

Пример User Story:


Пример Use Case:


Диаграмма ВИ тоже есть, но еще не доведена до ума.

Дайте пожалуйста свои замечания к описанию моего Use Case:
- насколько корректно использовать такой шаблон Use Case, который у меня получился?  :o
- насколько корректно само описание?  ???

8
Ничем.

Вам надо было посетить семинары по проектированию продуктового ландшафта, проходившие 3 и 4 января сего года. Повторять буду, но не знаю, когда.

PS. Если что, архитектором я тоже работал. мой документ аналитиками признан хорошим. Пока не публиковал его, т.к. не истек срок давности.
Хотелось бы ссылку на инф. с этим семинаром в интернете. Где проходил семинар? Есть какие-то материалы с него?

9
Интересует тема проектирования веб-сервисов.
Есть небольшой опыт в проектах на SOA архитектуре.
Увидел как выглядит реализация сервисов на SOAP протоколе (c REST сервисами знаком только в теории).
Немного принимал участие в доработке существующих SOAP API (добавление вх/вых параметров - в основном все сводилось к расширению атрибутного состава таблицы/сущности).

Но, не было опыта проектирования сервиса и API с нуля.
Поэтому хочется понимать, как подходить к решению следующих задач:
1. Проектирование нового SOAP сервиса и SOAP API
2. Проектирование нового REST сервиса и REST API
В чем будут отличаться подходы к решению 1 и 2 задач (на уровне системного анализа)?

Например, компания хочет разработать какой-либо веб-сервис, подключает для этого штатного аналитика - с чего он должен начать? Хочется понять последовательно весь процесс.

Все статьи которые я находил в основном касались больше технической части (т.е. конкретно реализации - аналитику это не очень понятно)
Собственно, подскажите литературу, которая поможет начинающему системного аналитику разобраться в этих вопросах.

Страницы: 1