Добрый день, прошу помощи с тестом на аналитика.

Не могу понять как в первой части должно выглядеть описание процесса, в гугле не могу найти ни одного примера, как это делается?
Есть ли те, кто знает как сделать эти задания?



_______________________________________________________________

Часть 1

Предлагается диаграмма последовательности UML. Нужно кратко (в пределах одной страницы А4) описать суть

процесса. Описание должно быть аккуратно сформулировано и оформлено, а также понятно нетехническим людям.

Часть 2

По факту проведения платежа пользователю отправляется сообщение вида:

ШТРАФ ПО АДМИНИСТРАТИВНОМУ ПРАВОНАРУШЕНИЮ ПОСТАНОВЛЕНИЕ №77ФА2090776 на сумму

300 руб. успешно оплачен. Платежный документ в отделение № 1 Московского ГТУ Банка России г. Москва 705.

УИН:188108В77ФА209077622. Служба поддержки: emp@mos.ru

Необходимо:

1. Выделить переменные;

2. Записать в чистом виде шаблон сообщения;

3. Спроектировать XSD-схему запроса от платежного агента к Системе.

Часть 3

На диаграмме из части 1 выбрать три любых User Task и предложить для них экранные формы.
________________________________________________________________________________________
Перед Вами система — сказка “Золотая рыбка”.

Требуется:

1. Описать назначение системы;

2. Указать участников системы, объекты системы;

3. Проставить взаимосвязи между участниками системы и объектами;

4. Перечислить возможные функции каждого из участников системы;

5. Описать все возможные сценарии системы;

6. Визуально изобразить один из сценариев;

7. Сделать общее описание дальнейшего развития системы;

8. Выборочно описать один из сценариев возможного развития системы.

Здесь много о такой системе: http://www.roskazna.ru/gis-gmp/
Раньше проект назывался УНИФО, теперь ГИС ГМП.

Немного из опыта: при асинхронном взаимодействии систем важно подумать и аккуратно описать варианты повторных обращений к системе и обработку зависших сообщений в очередях.

Добрый день, прошу помощи с тестом на аналитика.

Часть 1.

Общее описание процесса для "нетехнических людей":

Система посредством Сервиса предоставляет Пользователю возможность совершить платеж по имеющемуся начислению через наиболее подходящего Пользователю Платежного агента. По факту проведения платежа Система уведомит Пользователя о результате посредством Сервиса.

Вопросы к схеме:
1. Почему Система определяет перечень доступных для оплаты ПА, не опрашивая их? Какова сравнительная ценность такого перечня?
2. Зачем Система определяет ПА с наименьшим размером комиссии, если окончательное решение принимает пользователь (который может руководствоваться любыми критериями, включая иррациональные)?
3. Какова вероятность того, что платеж не пройдет из-за того, что Система применила исторические данные о условиях его осуществления Платежным агентом?

Часть 2.
1. Это легко.
2. Непонятно. Какой шаблон будет считаться достаточно чистым?
3. В норме ПА незачем запрашивать какие-то "Системы", коих может быть миллион. В норме ПА должен таким системам отвечать. Так что постановка вопроса сомнительна. Если вести речь про ответ, то спектр его возможного содержания достаточно широк в зависимости от того, какие реквизиты запроса предпочитает хранить у себя Система, и какими реквизитами может себе позволить отвечать Платежный агент.
(с примерами XSD пас, не хочу возиться).

Часть 3.

Что это за помесь сказки и диаграммы? Ну а если начинать читать со слов "Перед Вами..." - простор для творчества весьма велик. Например, так:
1. Назначение системы: Добрым молодцам урок.
2. Участники системы: Читающий(1..n), Добрый молодец(1..n). Объект системы - носитель со сказкой (опционально: носитель может быть неотторгаемо интегрирован в читающего).
3. Читающий последовательно получает информацию с Носителя и озвучивает ее Добрым Молодцам.
4+ - самостоятельно.

огромное спасибо, за ночь сделал первую часть и вторую кроме XSD

сказка и usertask это разные задания.


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

огромное спасибо, за ночь сделал первую часть и вторую кроме XSD

Подсказка к третьей задаче: экранная форма уведомления о чем-нибудь - это тоже экранная форма (зато с минимумом элементов).

а как должны выглядеть ответы на вопросы про систему и объект если подходить не творчески, а по сути самой сказки?

Сказка по сути своей - не система. Это некое линейное повествование, поэтому нетворчески к такому "творческому" заданию не подойти. Разработчики "теста на аналитика" упражняются в креативности на Ваших нервных клетках? Отвечайте симметрично.

Варианты рассмотрения могут быть разными, например:

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

Под "ядром" я понимаю здесь некий системообразующий элемент, идею, вокруг котой "все вертится".
Можно также рассмотреть децентрализованные схемы.

сказкой сейчас займусь, а уведомление - это тоже user task?

и по поводу xsd - эта запрос на получение информации о платеже, правильно ли выглядит данная схема? или я в корне сделал что-то не так?

уведомления как формы использовать не разрешили, user task в данном случае - запрос начисления? то есть фио, контакты, реквизиты?


и со сказкой что-то совсем туго, не могу с точки зрения сути сказки определить назначение, а так же по всем остальным пунктам...

есть ли какие-то примеры? и как расписать взаимодействия объектов? если пишу    Рыбка – дед: принимать и исполнять желания, то получается "желание" надо записывать в объекты системы?

...уведомление - это тоже user task?

Я не знаю, что составители теста имели ввиду под термином "user task", я не силен в басурманщине. Но догадываюсь, что это что-то, что Пользователь делает с Системой. Так вот если он там уведомляется - это тоже вполне себе действие.

и по поводу xsd - эта запрос на получение информации о платеже, правильно ли выглядит данная схема? или я в корне сделал что-то не так?

Не совсем. Плясать надо от того, какой смысл вкладывается в слова "информации о платеже". Если речь об одном платеже, о котором мы точно знаем (то есть, знаем его идентификатор), то достаточно только PaymentID.

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

Если о всех платежах, которые числятся за данным плательщиком, то в принципе, можно и по такой большой совокупности считать. Но чаще обходятся меньшим количеством реквизитов-фильтров. И здесь PaymentID тоже не нужен.

Можно, конечно, сказать, что это у нас универсальный запрос на все случаи жизни. Но это не очень хорошая практика, и на создание интеллектуальных обработчиков запросов идут немногие.

уведомления как формы использовать не разрешили, user task в данном случае - запрос начисления? то есть фио, контакты, реквизиты?

Да, например. То есть, "форма вода данных для запроса начислений". Туда же "форма выбора начисления", "форма выбора Платежного агента", "форма ввода реквизитов платежа".

и со сказкой что-то совсем туго, не могу с точки зрения сути сказки определить назначение, а так же по всем остальным пунктам...

Назначение сказок определили до нас. В моем первом сообщении часть цитаты.
Все остальное - исключительно полет фантазии.

есть ли какие-то примеры?

Примеры назначения? Ну, для третьего буллета в предпоследнем ответе: "Преобразование разбитого корыта в объекты, удовлетворяющие потребности агента. Циклическое."

и как расписать взаимодействия объектов? если пишу    Рыбка – дед: принимать и исполнять желания

Рыбка - дед:
1. Принимать желания.
2. Информировать о принятии желания в обработку.

то получается "желание" надо записывать в объекты системы?

Нужно определиться, что мы понимаем под "объектом". В зависимости от контекста, объектами могут выступать дед, бабка, рыбка. Или корыто, невод, дворец. Или желания. Или море (которое меняет состояние в зависимости от сложности запроса).

Желание вполне можно считать объектом информационного обмена между 1) бабкой и дедом 2) дедом и рыбкой.

если есть возможность, буду очень благодарен, если распишите полностью ответы на все вопросы по сказке.
обещаю, что  использовать буду только для ознакомления и использовать в качестве ответа ее не буду, а сделаю по своему.

спасибо

если есть возможность, буду очень благодарен, если распишите полностью ответы на все вопросы по сказке.
обещаю, что  использовать буду только для ознакомления и использовать в качестве ответа ее не буду, а сделаю по своему.

спасибо

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

Результаты этого обсуждения можете использовать как угодно, в том числе, с целью трудоустройства или иного извлечения прибыли. Мне не жалко, у меня таких результатов много.

осилил 5 пунктов не считая 5, все ли верно?

1.   Выполнение участником рыбка желаний пользователя бабка, посредством передачи информации о желаниях агентом дед.
2.   Участники: рыбка, бабка, дед. Объекты – невод, желание, корыто, изба, статус столбовая дворянка, статус вольная царица, статус владычица морская.
3.   Рыбка – дед:
Принимать желания.
Информировать о принятии желания в обработку.
Бабка – дед:
Передача информации о желании.
Дед – бабка:
Получение информации о желании.
Дед – рыбка:
Передача информации о желании.
Дед – невод:
Закидывать.
Невод – рыбка:
Ловить.
Рыбка - невод:
Попадаться в объект невод.
Бабка – желание:
Придумывание и передача агенту дед.
Дед - желание:
Получение информации от пользователя бабка и передача участнику рыбка.
Рыбка – желание:
Получение от агента дед и исполнение.

4.   Рыбка:
Принимать желания.
Информировать о принятии желания в обработку.
Исполнять желания.
Дед:
Закидывать невод.
Получать информацию о желании от пользователя бабка.
Передавать информацию о желании участнику рыбка.
Бабка:
Придумывание желаний.
Передача информации о желании агенту дед.
Приобретение статуса столбовая дворянка, статуса вольная царица.
Недовольство текущим статусом, положением и статусом объектов во владении.

осилил 5 пунктов не считая 5, все ли верно?

В такой ситуации не может быть деления на верно/неверно. Это своего рода вопрос личного вкуса, эстетики и привычек. Так что дальше - моя вкусовщина.

1.   Выполнение участником рыбка желаний пользователя бабка, посредством передачи информации о желаниях агентом дед.

Я бы не сказал. Рыбке до Бабки вообще дела не было. Скорее, "Возврат участником Рыбка спонтанно образовавшейся задолженности участнику Дед посредством разрешения его запросов". Шутка, разумеется. С некоторой долей шутки.

3.   Рыбка – дед:

Вот тут было бы уместно нарисовать участников и соединить их подписанными дугами отношений.

Бабка – дед:
Передача информации о желании.

А "подготовка агента к приему и передаче следующего желания"? (начинается со слов "Дурачина ты, простофиля!")

Дед – невод:
Закидывать.
Невод – рыбка:
Ловить.
Рыбка - невод:
Попадаться в объект невод.
Бабка – желание:
Придумывание и передача агенту дед.
Дед - желание:
Получение информации от пользователя бабка и передача участнику рыбка.
Рыбка – желание:
Получение от агента дед и исполнение.

Я бы отделил отношения участников от манипуляции объектами.
На упомянутой выше картинке, например, можно изобразить так:
"Дед" +  "->" + "Рыбка".
Стрелку подписать (например, сверху): "Передача информации о желании"
И подрисовать (например, внизу) объект "Желание".

Кстати, отношения Деда с Рыбкой я бы разделил и отрисовал двумя стрелками. Первая - "Установление доверительных отношений" - однократное, с применением объекта "Невод". Вторая - собственно, "Передача информации о желании", многократное, с применением объекта "Желание".

Бабка:
...
Приобретение статуса столбовая дворянка, статуса вольная царица.

Я бы сказал, "потребление результатов исполнения желаний". Будет более универсально.

Недовольство текущим статусом, положением и статусом объектов во владении.

Неплохой пример дуги, начинающейся и оканчивающейся на одном и том же участнике. Кольца, то есть.

---

Ну и подправить картинку. Объекты оттуда убрать, причинно-следственность починить (например, дед закидывал невод в море не потому, что бабка послала его за новым корытом).