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

×


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

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


Сообщения - leha

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

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

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

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

2
Эдуард, спасибо за участие в топике.
А меня как реального препода эта диаграмма не устраивает по очень многим параметрам.
...
то что представлено на диаграмме - это варианты использования цели пользователя, т.е. пользователь обращается к системе, чтобы решить какую-то важную для него задачу, например по управлению каталогом это означает добавить элемент, изменить имеющийся, удалить элемент
Если я правильно вас понял- то вы за то чтобы вернуть на диаграмму 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 для Авторизации и Регистрации будет уродливым. Это была плохая идея с моей стороны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14
Цитата: Humbert
Цитата: leha
Возможно я ошибаюсь, но вопрос был не совсем про бизнес-анализ и UML, а скорее про инструмент для поддержки процессов предоставления ИТ-услуг.
К бизнес-анализу Вас точно никто не отсылает. Ваши исходные вопросы
Возможно, автору топика стоит конкретизировать свой вопрос. Т.е. мне не до конца понятно, что он всё-таки ищет (и что подразумевается под желанием "описывать сервисы") :
1. Эффективную "рисовалку" ИТ-инфраструктуры?
2. Конкретный пример как рисовать ИТ-инфраструктуру в EA\на UML?
3. Инструмент для автоматизации процессов ITSM (не только "рисовалку")?

Моё предположение в том, что интересовал его 3й вариант.
С тем что в EA  можно нарисовать ИТ-инфраструктуру - не спорю. Но это не делает  EA 3-м вариантом.

15
Возможно я ошибаюсь, но вопрос был не совсем про бизнес-анализ и UML, а скорее про инструмент для поддержки процессов предоставления ИТ-услуг.
В этой области есть куча специализированных инструментов от очень дорогих типа HP OpenView до бесплатных. Можно погуглить что-нибудь типа "ITIL Tool", "ITSM Tool" итп.
На одной из моих прошлых работ мы это делали просто в нескольких таблицах на SharePoint.

Страницы: 1 2 3 4 »