1

Для всех / Re: Практика для джуна, pet

« : 23 Августа 2020, 10:18:04 »

А в чём текущая работа заключается? Классическим советом по переквалификации в БА, является взятие на себя отдельных функций БА (без формальной лычки) на текущем месте. По своему опыту - хорошо заходит написание всевозможных инструкций и прочее техписательство. На это всегда не хватает времени, и препятствовать никто не будет. Сам так в своё время аналитиком стал. Я был единственным программистом кто писал инструкции пользователю Также хорошо вписаться в большой change-проект (внедрение чего-нибудь, реорганизация итп).

С практической точки зрения, решает количество попыток прособеседоваться. Это очень важно - даже при хорошей "конверсии" собеседований процентов в 5%, без большого количества заходов надеяться просто не на что. Лет 10-12 назад, после того как года 3 "с нуля\из программистов" поработал аналитиком в средней не-ИТ также мучительно искал работу. Заняло полгода и несколько десятков собеседований до первого приглашения (я отклонил в итоге) и год до предложения, которое принял. Пришлось заметно просесть в зарплате. В процессе собеседований сам сильно изменился - "конверсия" к концу процесса в разы возросла на всех этапах "воронки".

+ Гипотеза, которая может сработать. Попробовать зайти на компании-аутстафферы типа Аплана, Крок, ЭПАМ итп (это просто примеры компаний такого типа, за рынком сейчас не слежу). Они пылесосят весь рынок и часто не очень требовательны. Часто они могут впихнуть начинающего специалиста заказчику у которого сроки горят.

2

Для всех / Re: Практика для джуна, pet

« : 06 Августа 2020, 22:59:35 »

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

Без опыта в айти и желательно в большой компании быть БА трудно. Про 1с хорошая идея. Другая хорошая идея поработать тестировщиком. Тестировщик главный потребитель трудов аналитика. 

сколько было попыток прособеседоваться? Собеседование наводит порядок с приоритетами в голове. Одна моя знакомая программист очень хотела быть аналитиком. После 1.5 лет попыток её взяли. Но она программистом была все таки.

3

Для всех / Re: Диаграмма деятельности (активности)

« : 17 Мая 2016, 14:57:11 »

1. Зачем вообще понадобилась дорожка "Клиент"?
Активности типа "Ввод данных для регистрации" и "Отображение формы регистрации" я бы объединил во что-то типа "Ввод регистрационных данных в форму регистрации".
Насколько я вижу, все активности на диаграмме сейчас образуют такие пары. Т.е. никакого дополнительного смысла от такого разделения не проявляется. Диаграмма упростилась бы.

Если уж и делать дорожки, то по формам это было бы понятнее. Т.е. будет дорожка "Магазин", "Корзина", "Оформление заказа", "Авторизация", "Регистрация".

2. "Заказ отправлен на исполнение" звучит как состояние, а не как активность. Нужно по другому назвать.

3. В алгоритме пропущено много веток. Что например будет, если клиент не успешно авторизовался?

4

Для всех / Re: UCD для интернет-магазина

« : 12 Мая 2016, 21:05:45 »

Эдуард, спасибо за участие в топике.

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

Если я правильно вас понял- то вы за то чтобы вернуть на диаграмму UC "Добавить товар", "Изменить товар", "Удалить товар".
Здесь, мне кажется, ситуация из разряда "на вкус и цвет".  Думаю, в контексте учебного проекта, эти UC отлично упаковываются в большой UC "Управление каталогом".
Впрочем, если описание задачи из начального поста топика - это и именно та формулировка, которую дал Даниилу преподаватель, то этот преподаватель, возможно, в итоге ожидает увидеть картинку по принципу "по одному UC на каждый глагол из описания". Тогда надо добавлять ещё и другие UC типа "выбрать товар в корзину", "просмотреть каталог товаров" может даже "войти в корзину". И тогда стоит вернуть "Добавить", "Удалить", "Изменить".
Но это только гипотеза и начал я бы всё-таки с самого минимума UC. Мельчить - плохо (насколько я помню Коберна, он примерно то же самое говорил).

- отношение включение говорит мне (а я читаю схему, которая выполнена в определенной нотации и согласно определенному стандарту), что ВИ управления каталогом обязательно включает ВИ авторизации / регистрации, т.е. ВИ УК не будет полон без включения в него и исполнения шагов ВИ А/Р
- т.е. каждый раз когда мне требуется добавить/изменить/удалить какой-то элемент каталога, я должен авторизовать или регистрироваться вновь и вновь - ситуация возможная, но весьма странная
- ровно эти же рассуждения приведут меня и по ВИ оформление заказа, при этом если включение ВИ поиск заказа выглядит разумным, то ВИ А/Р явно нет.

Если я правильно понял, то вы клоните к тому, что <<include>> надо менять на <<extend>>, т.к. включённые UC выполняются всегда, а ту же авторизацию надо выполнять не всегда. 
Здесь я с вами не соглашусь. UC - это не один сценарий, а взаимосвязанная группа сценариев. Да включённые UC всегда выполняются, но только для тех сценариев из группы, в которые они включены. Например: при управлении каталогом текст UC можно сформулировать так, что авторизация будет входить не в базовый сценарий, а в альтернативный (и следовательно не будет выполняться при каждой активизации UC).
Даже погуглил на эту тему: http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html.

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

Соглашусь. Текст объединённого UC для Авторизации и Регистрации будет уродливым. Это была плохая идея с моей стороны.

5

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 22:19:29 »

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

Чтобы корректно дойти до такого уровня детальности ваша диаграмма должна разрастить в объёме раз в 10. В неё тогда придётся включить и другие низкоуровневые подробности клиентского опыта. Не думаю, что это правильно для учебного проекта.

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

6

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 22:11:22 »

Как-то так тогда получается (просто брал удаление, изменение и добавление). Правда у меня теперь "поиск" включается в "управление каталогом" однако, например, для добавления товара в каталог, поиск совершенно не нужен. Криво значит (

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

Надеюсь, не страшно то, что я объединил таки регистрацию и аутентификацию...

Диаграмма -ОК. Если бы был преподом - меня бы устроило.
В "Управлении каталогом" у вас спрятано и "добавление" и "удаление" и "правка". Т.к. удалению и правке поиск нужен, то стрелочка к поиску - ОК.

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

7

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 21:53:30 »

Правильно ли я понимаю, что отношение "расширения" используется тогда, когда один ВИ уже где-то используется, и в то же время при определенных условиях может использоваться еще в одном ВИ ?

Не совсем так.

Расширение, это другая взаимосвязь между кусками текста. Это когда в тексте UC1 даже не упоминается UC2. А UC2 знает\ссылается на UC1 и активизируется при определённых условиях в UC1. Классический пример UC1 "Редактирование текста", UC2 "Проверка правописания". UC1 даже не упоминает UC2. В UC2 написано что-то вроде "активизируется в случае если в UC1 возникла синтаксическая ошибка " и далее в нём описывается в как проверка правописания должна выглядеть для пользователя.
Расширение это не про повторное использование кусков текста. Это скорее про опциональные возможности или про то как описать новую функциональность системы, не пересогласовывая старую спеку.

С отношением расширения, вам пока лучше не связываться. Кажется Коберн, говорил что один раз только в жизни им пользовался на реальном проекте. Оно не сложнее включения, просто ваша задача решается и без него. Если есть очень большое желание - Авторизацию\Регистрацию можно описать как расширение для кейса "Оформить заказ".

8

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 21:41:05 »

Начните  с главного. Какие есть Акторы и какие у них цели относительно системы? Клиент, Администратор, Контент-менеджер?

Чего хочет клиент от системы? "Посмотреть товары в магазине" и "Оформить заказ"?. Чего хочет Администратор - "Управлять каталогом". Чего хочет контент-менеджер? Предположим "Редактировать описание товара".
Нарисуйте эти UC. В принципе, диаграмма готова. С ней всё нормально. Можно писать сами тексты UC.

Если хотите дать понять преподавателю, что освоили связь "включает", то
можно добавить Аутентификацию\Регистрацию как включённый UC для "Оформления заказа", "Управления каталогом", "Редактировать описание товара". "Редактировать описание" можно считать включённым кейсом для "Управление каталогом", а можно не считать - зависит от вашей бизнес-логики.
С этой диаграммой тоже всё ОК.

Вся путаница - от смешения UC разных уровней детальности в одной диаграмме.
Начните писать тексты UC и всё станет на свои места.

9

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 21:07:30 »

1. Последняя версия диаграммы стала несколько захламлённой. Это из-за того, что в ней смешаны UC совершенно разного уровня детальности\абстракции.
Осталось только добавить UC "Закрыть окно браузера" и поставить стрелочки "включает" к нему от остальных UC на диаграмме (это сарказм ).

Я бы для уменьшения "захламлённости" объединил бы UC "Добавление" "Изменение" и "Удаление" товара, а может и вообще бы их убрал с диаграммы. Повторно они никем не используются. В чём был смысл их выделять?

2. Стрелочками "расширить"  вы пользуетесь неправильно. Они пока не нужны на вашей диаграмме. Как вы себе представляете текст UC "Удалить товар" расширяющий UC "управление каталогом"?

10

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 20:54:26 »

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

Нет это не так. Понятий "до" и "после" в UCD не может быть. Овал UC на UCD, с одной стороны это цель Актора относительно Системы, а с другой стороны, простое текстовое описание того как Актор добивается этой цели (его на UCD нет, оно лежит в документе UC Specification).  Куски описаний, которые используются повторно во многих UC иногда выносят в отдельный UC. Чтобы обозначить на UCD что текст UC1 использует\ссылается на текст UC2 используется стрелочка "включает" от UC1 к UC2. Т.е. вся UCD и все эти стрелочки просто наглядно изображают какие есть куски текста (в UC Specification) и связь между этими кусками текста.

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

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

Переделал по-другому все. Правда у меня получается при оформлении заказа аутентификация а не регистрация...регистрацию куда засунуть не знаю..

Можно совместить с аутентификацией для простоты. Т.е. будет юзкейс "Аутентификация или регистрация". Можно и отдельным юз-кейсом.

11

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 19:27:23 »

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

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

Думаю, забыта связь между клиентом и поиском товара. Клиент же может искать товар, не делая заказ?

12

Для всех / Re: UCD для интернет-магазина

« : 11 Мая 2016, 18:43:30 »

1. Стрелочка от "Добавление товара" к "Управление каталогом" идёт в неправильном направлении (как и остальные стрелочки к "Управлению каталогом").
2. Это, конечно, дискуссионный вопрос, но "Аутентификацию" я бы поставил как расширение или включение к "Оформлению заказа" или "Управлению каталогом", как самостоятельный юзкейс она режет глаз. У клиента, обычно, нет самостоятельной цели аутентифицироваться, у него есть цель оформить заказ или поискать товар.

13

Системный Анализ и Требования / Re: Согласование Вариантов использования (Use case): подводные камни и обходные пути

« : 10 Мая 2016, 22:19:56 »

А вы как-то разъясняете клиентам, что такое use case, почему в таком формате пишете требования? Или у них не возникает вопросов и "погружение" не нужно?
Кто-то привык видеть в требованиях описание "фич", а мы хотим как раз от этого отойти.

А вы можете чисто для себя и своей команды разъяснить зачем вам понадобились юз-кейсы? Если объяснение будет убедительным, то и заказчик скорее всего поймёт.
Не пытаетесь ли вы "развести" заказчика ради собственного интереса поэкспериментировать с технологией, ради ограничений вашего нового инструмента управления требованиями и прочих неуважительных причин ?

PS: как вариант, можно разрисовать какую-нибудь небольшую задачу юз-кейсами и "по старому" и на этом примере продемонстрировать преимущества вашего подхода.

14

Работа / Re: Смена профессии. Хочу стать системным аналитиком

« : 03 Апреля 2016, 01:50:19 »

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

Собственно знание АРИСа, насколько я с этим сталкивался, ценится не очень высоко.  Ну если вы не тренером или консультантом по внедрению АРИСа собираетесь стать.
У бизнес-аналитиков ценится знание предметной области. Т.е. правильно рисовать процессы можно научить парой тренингов, а вот рисовать правильные процессы (пусть даже и не очень грамотно с точки зрения АРИСа) - это стоит больших денег. 
Ещё БА ценят, если он хорошо знает как работает компания и уметь что-то в ней менять (будет он что-то при этом рисовать или нет- вторично)
Ещё БА может знать какую-то систему Х, и заниматься её внедрением со стороны заказчика или исполнителя. Здесь также АРИС не всегда нужен.
Хотя, всякое бывает, возможно я излишне категоричен. Организации разные бывают.

Сам работаю системным аналитиком. По вашим вопросам:
1. Дни разные бывают. Проще сказать чем в основном приходится заниматься:
Даёшь предварительную оценку по задаче по кратким бизнес-требованиям. Получаешь более детальные бизнес-требования от бизнес-аналитиков. Общаешься с заинтересованными лицами. Пишешь SRS. Согласовываешь с ЗЛ.
Консультируешь разработчиков и тестировщиков. Консультируешь коллег из других подразделений про систему, которой занимаешься. Собственно моделированием в АРИСе или другой нотации заниматься приходится мало, в основном на эскизном уровне.

2. Оценивают в разных местах по разному.
У меня сейчас есть KPI: по выполнению задач в срок + коллективная ответственность (вместе с разработчиками и тестировщиками) за дефекты в проме.
В других местах бывает, например, KPI по количеству дефектов ПО по вине аналитика.
+ А менее формально, достижение -это сделать что-то большое. Большую систему внедрить. Грубо говоря, доверят тебе проект на Х миллионов евро или нет.

3. Зарплата примерно как у разработчиков ПО соответствующего уровня.

4. С карьерным ростом у аналитиков не очень хорошо. В основном, растём не карьерно, а по грейду - с ростом опыта. Специальность очень узкая, что-то типа юрисконсульта. Если проект достаточно большой, чтобы на нём было хотя бы 3 аналитика, то довольно легко стать лидом, если компетенция позволяет. На статус и деньги это мало влияет. Собственно менеджментом лид заниматся мало. Этим занимаются руководитель проекта или начальник отдела. В больших компаниях бывает должность типа Начальник Всех Аналитиков или Начальник Отдела Анализа. Им может подчиняться сразу человек 50 -100 аналитиков. Занимаются такие люди обеспечением всех проектов компании достаточным количеством аналитиков нужного качества и совершенствованием процессов анализа в целом. Если проект очень большой, то возможно, есть промежуточная ступень между этими 2мя. Но настолько большие проекты нечасто встречаются.
Опять таки, возможно, я сгущаю краски. Бывают организации где на 3-4 аналитиков есть целый Начальник Отдела Анализа.
А в целом, карьерный рост, мне кажется, не от профессии зависит, а от правильного человека в правильном месте в правильное время.

5. В местах где работал я - увольняли как раз за эти варианты - не понравился начальнику и массовые сокращения. В ИТ, мне кажется, довольно высокая толерантность к ошибкам, по сравнению с другими профессиями. Ещё бывает вариант, если аналитик систематически "не тянет", но это быстро перетекает в "не понравился начальству".

6. Раньше работал разработчиком ПО, поэтому сравнить могу только с этой ролью. Нравится то, что понимаешь зачем делается система, чувство ответственности за что-то большое. Не нравится, что обратная связь по принятым решениям приходит очень не скоро. Разработчику проще- закодировал и сразу видишь - работает или нет. Здесь обратной связи можно пару лет ждать. Не нравится, что профессия сравнительно редкая, трудоустроится сложнее чем разработчику, фрилансить также сложно.

15

Работа / Re: Смена профессии. Хочу стать системным аналитиком

« : 01 Апреля 2016, 18:17:14 »

Судя по этому вопросу:

2) Что является оцениваемым достижением в данной отрасли? Сданный отчет, построенный прогноз и т.д. В общем, по каким критериям оценивается деятельность

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

В связи  с этим встречные вопросы:
1) Можно поподробнее описать вашу "смежную область"?
2) Чем занимались те системные аналитики, глядя на которых у вас возникло желание сменить профессию?