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

×


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

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


Сообщения - Леонид

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »
451
Задачи студентов / Re: Перевод с UML
« : 04 Марта 2014, 16:47:37 »
если есть возможность, буду очень благодарен, если распишите полностью ответы на все вопросы по сказке.
обещаю, что  использовать буду только для ознакомления и использовать в качестве ответа ее не буду, а сделаю по своему.

спасибо

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

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

452
Задачи студентов / Re: Перевод с UML
« : 04 Марта 2014, 15:36:04 »
уведомления как формы использовать не разрешили, user task в данном случае - запрос начисления? то есть фио, контакты, реквизиты?

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

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

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

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

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

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

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

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

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

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

453
Задачи студентов / Re: Перевод с UML
« : 04 Марта 2014, 15:15:14 »
...уведомление - это тоже user task?

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

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

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

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

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

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

454
Задачи студентов / Re: Перевод с UML
« : 04 Марта 2014, 13:53:41 »
огромное спасибо, за ночь сделал первую часть и вторую кроме XSD

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

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

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

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

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

455
Задачи студентов / Re: Перевод с UML
« : 04 Марта 2014, 11:55:27 »
Добрый день, прошу помощи с тестом на аналитика.

Часть 1.

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

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

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

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

Часть 3.

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

456
Понятно, что раз я на первых парах столкнулся с такими трудностями то пока мне рановато...

Рановато тому, кто так сформулировал задание. На мой взгляд, наилучшим решением будет выбросить его куда подальше и забыть, как страшный сон (вместе с местом, где Вы его взяли).

Найдите что-то более корректное. Для тренировки, например, вполне можно попробовать написать ТЗ и/или спецификацию на маленькую веб-системку ведения личной "поваренной книги" с раздельным учетом ингредиентов, способов приготовления, классификацией по блюдам (первое-второе-компот), поиском рецептов, сортировкой, блэкджеком и т.д.
Берете любой стандарт, гуглите примеры - и вперед. Результаты потом можно будет выложить на растерзание.


457
...требуется разработать общий план проведения системного анализа предметной области разработки Web-проектов.

Давайте-ка подробнее. Какова цель этих работ? Сон чьего разума и в каком контексте породил эту задачу?

Как то в общих словах наверное требуется определить границы проекта, требования к функциональности. Требуется ли на данном этапе Модель предметной области?

Сначала нужно определиться с вопросом "а нафига это всё?". Дальше будет виднее.

...что для этого требуется (из материалов)...

Поглядим.

...что должно стать результатом, какой документ, схемы?

Результатом должен стать "Общий план проведения", разве нет? А план - это работы, сроки (или трудоемкость) и результаты.
Ну, если заказчик (или руководитель) не имеет на этот счет "особого мнения".

458
Вот например компания... 50 лет совокупного опыта в тестировании.

Только не у компании, а у ее сотрудников. :)

459
Для всех / Re: Логическая цепочка
« : 12 Февраля 2014, 18:31:11 »
А почему именно так?

1. Чего-то захотелось (цель).
2. Придумали, как этого достичь (задача).
3. Определили место, время, оповестили участников, подстелили соломку, обеспечили алиби (организация).
4. Сделали! (мероприятие).
5. Сравнили что получилось с тем, чего хотелось (контроль).

460
Для всех / Re: Логическая цепочка
« : 12 Февраля 2014, 16:53:28 »
Цель, задача, организация, мероприятие, контроль.

(для сферической ситуации в вакууме)

461
То есть его интересуют не просто какие-то примеры, а именно правила написания регламентов.
Зная эти правила, человек самостоятельно напишет прекрасный регламент.

Принесите мне попкорн...

А на эти моменты ни одного ответа не последовало...

Правила, правила... Это к глубоким теоретикам. Жизненное правило одно: регламент надо написать так, чтобы среднеглупый исполнитель мог выполнить поставленную задачу и ему за это ничего не было. В первую очередь, из-за действий хитропопых эксплуататоров лазеек.

462
Требования:
• ...женская скрупулезность;
Важно:
...умеющий ладить с "противными" клиентами...

Взаимоисключающие требования?

навык создания 1 ТЗ в день

Сумеет любой. Хоть 7 ТЗ за день. Причем из одной и той же шкурки.

463
Добрый день, совершенно верно: существует бизнес-процесс (если интересно- могу вкратце его описать) и на его основе необходимо разработать, во всем нормам и стандартам, рабочий и простой регламент

Процесс Вам известен (и ссылку на гугль дали), пример грамотного оформления регламента, одобренного Минюстом, я привел в ответе #7.
Смотрите, какие в нем есть разделы и приведены сведения, вносите свои и упрощайте до потребного состояния.

Все просто.

464
Если SLA - это часть регламента, тогда что собой представляют другие части регламента?

На каком основании выполняется работа.
Каков порядок решения спорных вопросов.
"Контактные данные" основных ответственных (как правило, не конкретных людей, а подразделений или должностей).
И т.п.

Я не стал бы называть SLA частью регламента. Это как называть "disclaimer" фразу "сказка ложь, да в ней намек, добрым молодцам урок". Сильно похоже на попытку хоть как-то пристроить пятое колесо к телеге, ибо модно.

Это будет правильно - если изначально этот регламент был составлен правильно.
Однако при его корректировке вряд ли кто-то задумывается о его правильности

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

465
Можешь дать ссылку на такой регламент? Очень интересно.

http://www.fms.gov.ru/documentation/867/details/67089/

Например, п.21.

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

Если под SLA понимать договоренность кому, что, в какие сроки и с каким результатом делается - то это одна из важнейший частей регламента. Сколько при этом процессов в нем прописано, не принципиально.

Я сам работал в госструктуре, как правило такие документы создаются копированием с прошлогодней версии документа и корректировкой двух-трех предложений.

И это правильно. Куда хуже было бы, если бы каждый раз они переписывались "с чистого листа".

А недавно участвовал в составлении ТЗ, источником для которых являлись федеральные законы, под которыми подписываются министры и премьер-министры.
Так там такого понаписано...
Мы в юридическую службу написали запросов на разъяснение объемом равным половине объема этих федеральных законов.
На что нам ответили: однозначного ответа на наши вопросы нет.

Не повезло. На основании федеральных законов ТЗ пишут в исключительных случаях, когда ничего другого [еще] нет.  И дело это неблагодарное.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »