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

×


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

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


Сообщения - Сергей Евтухович

Страницы: 1 2 3 4 5 6 7 8 9 »
1
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 12 Сентября 2016, 22:16:45 »
Всем доброго дня ..

Использую ЕА 12.

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

__________________________
| FIELD_1 | FIELD_2  | FIELD_3 |
         1               2                 3

Как это сделать ?

Как временное решение собрал из Boundary таблицу но это долго и не удобно
Добрый день! Что такое "предписание"? Почему нужна именно таблица. Может добавить объект с заполненными атрибутами? Если хочется именно таблицу можно добавить к элементу linked document.

2
Это к вопросу отличия СА от БА.
Это картинка не даёт ответ на вопрос, обозначенный в теме, поэтому если вы хотели что-то сказать, опубликовав её, то лучше прокомментировать.

4
Нет. Гораздо важнее власть, реальные активы, рынки сбыта, инфраструктура. А деньги - просто резаная бумага, в лучшем случае. Приложение.

Дык. Дураков в руководстве, как правило, нет.
Есть же такая расхожая фраза: "деньги это не цель, а средство". Возникает вопрос, средство для чего? Для получения власти, активов, ...? Если так, то вопросы остаются. Зачем это всё нужно, власть, активы? И тут видимо мы приближаемся к разговору о таких вещах как пирамида Маслоу :)

5
Ну правильно вот и приходит народ ни за что не отвечающий. А накосячат - можно и уволиться, все равно другие возьмут. Типа " к пуговицам претензии есть? Нет, ну хорошо." А хороший спец получается только тогда, когда он осознает все в комплексе, а не только свои требования. Иначе, это не аналитик, а простой постановщик.
А чем, по Вашему, аналитик отличается от простого постановщика?

6
В жизни все просто на самом деле...
Бизнес аналитик в первую очередь отвечает за бизнес процесс.
Поэтому для него важно выбрать БИЗНЕС.
От него и отталкиваться. Если этот бизнес  финансовый, то надо изучать их, а не получать сертификаты.
В чьей жизни всё просто?
За бизнес-процесс обычно отвечает владелец бизнес-процесса, а не бизнес-аналитик.
И по поводу важности выбора бизнеса и неважности сертификатов... Если человек знает бизнес, то он не бизнес-аналитик, а эксперт предметной области. Даже если он называется бизнес-аналитиком, он часто не обладает компетенциями бизнес-аналитика. Таких полно. Им обычно гораздо легче сменить бизнес, чем стать хорошим бизнес-аналитиком. И сертификация как раз многое говорит о человеке как о бизнес-аналитике.
Системный аналитик отвечает за СИСТЕМУ. Значит надо изучать систему на фоне бизнеса, в которой она работает.  А так как системы в одной предметной области очень похожи, то СА еще могут прыгать из анализа одной системы в другую. Но на практике, как я убедилась, крайне редко.
В каком смысле СА отвечает за систему? Вы видимо понимаете под системой программный комплекс? Это распространённая ошибка. СА прежде всего отвечает за формирование требований к системе. К организационно-технической системе. А знание внутренностей и особенностей конкретного программного комплекса не делает человека хорошим СА.

7
Похоже это вы пытаетесь решить за счет Ваших заказчиков личностные проблемы:)

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

8
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 19 Ноября 2015, 16:09:20 »
Подскажите пожалуйста,
каким образом в EA сделать наследование классов чтобы автоматически наследовались операции?
Начать нужно с того, что операции не наследуются, а реализуются (абстрактные) или переопределяются. И о каком контроле вы ведёте речь по отношению к скриншоту 1? В EA можно повторить всё о чём вы рассказываете (см. прилагаемые скриншоты).

9
Для всех / Re: Выбор UML диаграммы
« : 13 Ноября 2015, 07:39:30 »
Изобретение собственных нотаций - это вообще вполне нормальная практика на мой взгляд. Просто потому что универсальной нотации нет, а сколько людей- столько и остального.
Согласен. Вполне нормальная практика. Но нужно понимать, что у нотации собственного сочинения могут быть как плюсы, так и минусы. Григорий предлагает использовать все те же элементы, что и на activity-диаграмме, за исключением дорожек от sequence-диаграммы. На мой взгляд, ничего принципиально нового и замечательного, в данном конкретном случае мы не получаем. С другой стороны мы заранее ограничиваем круг потенциальных потребителей таких диаграм, если всё же будем использовать элементы ветвлений диаграммы последовательности. Это уже более экзотично и менее понятно.

10
Для всех / Re: Выбор UML диаграммы
« : 12 Ноября 2015, 19:15:40 »
Ну или вот ещё пример (скрепка).

Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).

Какой тут бест-практис то ? :))))
Андрей, на диаграмме последовательности да ветвления может использоваться элемент типа fragment, но от этого диаграмма, на мой взгляд, не становится более применимой для отображения потоков действий. Если бы я не знал Григория, то взглянув на диаграмму без дополнительных пояснений в первую очередь заподозрил бы незнание UML. А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.

11
Для всех / Re: Выбор UML диаграммы
« : 11 Ноября 2015, 17:45:43 »
Хотя её тоже можно нарезать на столбцы, как на приведенном рисунке, но в этом случае получается примерно то же самое, что я предлагаю. При этом столбцы  содержат больше визуального мусора.
По-моему весь этот "визуальный мусор" наоборот акцентирует внимание на сути процесса, а также более привычен как тем, кто знает UML, так и тем, кто не знает UML, но знаком с блок-схемами алгоритмов. Сейчас мы можем скатиться к спору о вкусах:)

Что значит "стандартизованные"? Если речь об UML, то в нём слишком много элементов, причём назначение некоторых трудно понять, специально не изучая язык. Если нельзя исходить из того, что все, кто будет пользоваться диаграммой, знакомы с UML, то нужно использовать самые простые и интуитивно понятные элементы. "Дорожки" imho являются как раз таким элементом.
Если говорить о тех, кто ни разу не видел UML и блок-схемы алгоритмов, тогда я, возможно, согласился бы. Но таких, по моему опыту, мало. Всем остальным привычнее будет Activity диаграмма. Тем более что видов элементов Activity диаграмм очень немного. "Дорожки", как Вы сказали, также могут применяться с Activity диаграммой.

12
Для всех / Re: Выбор UML диаграммы
« : 10 Ноября 2015, 13:53:05 »
В данном случае стрелочки просто показывают последовательность действий во времени. Это не операции, не сообщения, не методы.

Вообще imho чем меньше текста на диаграмме, тем лучше.
 
Кстати, в учебниках по банковскому делу для таких описаний используют подобие Collaboration Diagram - на мой взгляд, худшей из всех диаграмм в истории UML. Примерно как на картинке. Очень жалко бедных студентов, которые по таким картинкам пытаются разобраться.
И всё же для меня остаётся непонятным, зачем использовать для целей указания последовательности действий Sequence вместо Activity diagram. Тем более что Activity больше похожа на обычую схему алгоритма и ветвления на Activity изображаются более лаконично и наглядно. Это более знакомо и привычно. Как студентам/выпускникам тех. вузов, так и тем, кто уже "вырос".  А в случае применения sequence мы изобретаем новую нестандартную диаграмму, хотя есть стандартизованные аналоги.

13
Для всех / Re: Выбор UML диаграммы
« : 06 Ноября 2015, 14:06:45 »
Ничем не лучше. Это одно и то же.
По моему это нецелевое использование диаграммы. Не путать со статьёй УК:). Зачем изобретать свою нотацию, если есть uml activity diagram? Вы не боитесь запутать неокрепшие умы? И ещё... Смотря на такую диаграмму сразу хочется прочитать надписи на стрелках.

14
1. Ищите позиции стажер системного аналитика или младший аналитик в интеграторах или "внедренцах" (возможно не крупных)
Интеграторы и внедренецы нацелены на типовые внедрения типового софта для решения типовых задач. Насколько я себе представляю, часто в таких проектах очень мало общения с заказчиком для выявления бизнес- и системных требований, при этом ограничена кастомизация софта. Аналитик в основном занимается описанием интерфейсов API и изменением бизнес-процессов под внедряемый софт. Исходя из этого я бы начал с заказной разработки, а не интеграторов. Может я сталкивался не с теми интеграторами?

15
Да нет никакой новой реализации )) Документирование системы нужно для сохранения знания, типа.
Ещё такой вариант... Как уже писали выше сделать два юзкейса + include третьего с общим поведением. А далее если текущие реализации общего поведения сделаны по разному, тогда для общего юзкейса не нужно делать use case realization. А сделать разные use case realization для двух других юзкейсов.

Страницы: 1 2 3 4 5 6 7 8 9 »