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

×


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

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


Сообщения - Gevorg

Страницы: « 1 2 3 4 5 6 7 8
106
каким образом можно проверить правильно ли написал аналитик требовния со слов заказчика, ведь именно тут происходит наибольшая потеря.
возможна ещё ситуация, когда аналитик записал требования правильно, но сам заказчик ошибается и выдал противоречивые или, как минимум, плохо согласованные требования.
И в первом и во втором случае меня в работе аналитика всегда сильно выручал метод построения  ЮМЛ-моделей для себя - и текстовых экскурсий по ним - для Заказчика.
Обычно это диаграмма классов для бизнес-сущностей и диаграммы состояний для них же.
Иногда сильно помогает активити со свим-лайнами в двух вариантах:
- детальный, с отображением передаваемых между активностями объектов[в состояниях].
- и упрощённый, где поток объектов скрыт полностью или почти полностью.


В модели для себя пытаюсь увязать всё, что записано со слов Заказчика,
а затем - по модели излагаю своё понимание и задаю вопросы в текстовом виде.

Самое мучительное - именно качественная модель.
Если она получилась - текстовое описание рождается как речевой поток у спортивного комментатора :-)

Дальше - уже всё просто: Заказчику отсылается текст с 1-м (главным) вопросом:
правильно ли я, аналитик, понял суть происходящего в предметной области?
И если ДА, то как быть с проблемами, изложенными далее в пачке остальных вопросов?


Всё это пространное описание я привожу с одной целью - 
указать, что вот оно, место для безмолвного моделирования:

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

Даже если аналитик один, и в одном лице объединяет роли и автора и инспектора требований,
и даже, если Заказчик за такое моделирование не платит и падает в обморок при словах ЮМЛ и Диаграмма -
всё равно стОит таким заниматься, чтобы уменьшить эту злобную "наибольшую потерю".

107
Если вспомнить начало топика, то надо признать, что мы отклонились от темы.
Разговор был о том, что структуру самого ВИ можно нарисовать в виде Class Diagram.

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

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

Обсуждение ушло в другом направлении, и у меня, по ходу его развития, возникли "крамольные" вопросы:
а может просто диаграмма ВИ сама по себе слабый инструмент?
а если её доработать, то и получится дать любителям визуальных представлений приличный инструмент для создания ЮзКейсов?

108
Вообще, жалко, что народ не был на вчерашнем семинаре
а конспект семинара где-то есть?

109
Вот посмотрим на диаграмму 2, она наиболее простая:
Основоной Актер имеет какие-то цели, каждая цель представляется одним или несколькими ВИ, каждый ВИ имеет некую ответсвенность. Что такое SuD - я не понял.
В оригинале у Коберна написано:
This model fragment expresses that use case is the primary actor's goal, calling upon the responsibility of the system under design (SuD).
Я не силён в английском, но мне кажется, что описание Коберна намного более примитивное по сравнению с тем, что привёл BAS.
у меня здесь вопросы:
- как всё-таки, трактуется стрелочка с закрашенным треугольником на конце в общем случае.
- что ближе к современному пониманию ЮзКейса?
  -- примитивное Коберновское ЮзКейс - это цель основного Актёра или
  -- Юз-Кейс (или их набор) не есть цель, а есть некое представление цели (одной или нескольких?),
                   (если я правильно понял BASa)
- что же тогда такое по Коберну Ответственность? другое название для ЮзКейса?

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


111
1. Представление Коберна о возможной структуре понятия действующее лицо
там ещё есть Цель, Интерес, Действие...
получается уже целая модель поведения.
меня живо интересует,
кто ещё строил подобные модели, свои независимые, или на основе этих, Коберновских.

112
Вот, перенабранные из книжки диаграммы, про которые спрашивал.
Снимаю предыдущие свои вопросы и заменяю на детские:
- что это такое?
- как оно правильно называется?
- кому это было интересно и кто брался развивать\дорабатывать\править?
(и если были таковые, то где посмотреть их результаты?)

113
На опыт и идеи никто платок не накинет, никто и не требует делится деталями реальных проектов:-)
Вот здесь и кроется трудность:
ну не платят аналитику за систематизацию своего опыта и идей,
ни деньгами, ни даже времени сделать это за свой счёт - и того не дают.
Фаза стабилизации результатов проекта до сих пор у многих аналитиков только в розовых мечтах и существует.
А выделить идею или наработку и подать её на подходящем примере - оказывается не таким простым делом.
Вот и стоит такой специалист перед выбором: или кидать в форум полуфабрикт и краснеть за его ущербность - или прикладывать труд в этом направлении за счёт отставания в непрестанной гонке на работе.

114
UML UC диаграмма ... ну разве что запудрить мозги заказчику, типа "умеем картинки на UML малевать".
В-четвертых, использоание визуальных диаграмм оправдано тогда, когда они действительно улучшают понимание.
так здесь 2 направления для визуализации:
- собственно, функциональных требований (UML UC диаграмма)
- модели понятий вокруг- и для- понимания инструмента под названием Use Case (в каком-то смысле - метамодель).

с мнением по первому направлению - полностью согласен.
Но мои вопросы были относительно второго.

115
В-третьих, существуют как сторонники визуализации, так и потивники.
ага, меня интересуют результаты сторонников визуализации :-)
и критика этих результатов

116
ссылки на подход Коберна и RUP.
Ага, про Коберна... Кого ни спрошу - отмахиваются:
У Коберна, в его Writing Effective Use Cases есть UML-диаграммки,
эдакая модель понятий - контекст для  Use Case.
Там Goal, Responsibility, Actor, Action и т.д.
Насколько я понял из книжки, сам Коберн признаётся, что это суровый драфт, который ещё править и править...
У меня по этому поводу 2 вопроса:
- Что уважаемые форумчане лично думают про эти самые диаграммы?
- и что знают про мнения и работы других в этом направлении?.

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

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