811

UML SysML и пр. / Re: Опять Бизнес Модель Вариантов Использования (БМВИ)

« : 24 Декабря 2006, 23:41:20 »

2Юрий Булуй, смотря что из этого System Under Construction или рассматриваемая система. Если система - это коммутатор и телефонная сеть, то основной актер - это звонящий он инициирует действия и имеет ЦЕЛЬ, дополнительнгый актер - вызываемый - он ыне системы и имеет свой ИНТЕРЕС, в соответствии с которым будет развиваться сценарий и система должна учитывать не только ЦЕЛЬ, но и ИНТЕРЕСЫ всех актеров.

1. Каков интерес secondary actor и как этот интерес влияет на сценарий? (думаю имеет смысл это озвучить в рамках обсуждения)
2. Отображение на диаграмме в этом примере (secondary actor), и в оригинальном (с Клерком как бизнес-вокером) ... просто есть один подход, со стереотипами ... интересно узнать ваши предположения на эту тему, т.к. эту идею пока никто не стал развивать.

812

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 24 Декабря 2006, 14:39:21 »

Для описания БП можно использовать как подход декларируемый RUP -- BUC/BA models, так и модификации, которые предложены различными авторами, вплоть до введения ими собственных стереотипов. В любом случае, описание бизнеса тоже сводится к описанию статической и диниамической составляющей. Статика - это те же BUC диаграммы и различные вариции на тему диаграмм классов. Динамика это activity/sequence/collaboration.

Тут есть один момент -- он связан в частности с тем, что нужно четко понимать какую цель мы преследуем, когда хотим заняться описанием бизнес-процессов, и подбирвать соответстующие средства для этого. Например, если цель сделать автоматизацию БП, в сфере где БП нам известны, то не факт, что имеет смысл делать полномасштабное описание бизнеса, а может только некоторые общие вещи или наоборот -- отдельные детали. Если цель -- анализ эффективности БП и реинжениринг, который частично связан с автоматизацией, но это не квинтэссенция, то не факт что UML будет the best для этих целей. Цель определяет средства ее достижения.

813

UML SysML и пр. / Re: Опять Бизнес Модель Вариантов Использования (БМВИ)

« : 23 Декабря 2006, 22:55:10 »

Подолью масла в огонь :-) ... нужно помнить про seconary actor, если про Коберна речь ведем ... вот и пример (не помню у него в книге возможно он есть), когда есть коммуникационная система, есть звонящий и есть вызываемый ... они беседуют по телефону. Что будем делать с экторами в этом случае ;-)?

814

UML SysML и пр. / Re: Опять Бизнес Модель Вариантов Использования (БМВИ)

« : 23 Декабря 2006, 14:08:42 »

Юра, при всем к тебе уважении, ну прочитай еще раз свой текст.

Тьфу, блин ... совсем сдурел ... это чистая оговорка (точнее опечатка?) ... Клерк, Клиент ... оба на букву "К", да и время было 2 ночи .... виноват ... что-то я переутомился похоже :-), ну скоро отдохну :-).
Конечно же я имел ввиду КЛИЕНТА!!!! ... сорри ...

815

UML SysML и пр. / Re: Опять Бизнес Модель Вариантов Использования (БМВИ)

« : 23 Декабря 2006, 02:08:39 »

Что я хотел сказать ...
1. Мы можем отобразить Клерка как эктора на диаграмме, в том случае, если он является secondary actor, т.е. при условии, что Клиент и Клерк взаимодействуют через scope. Такая ситуация возможна при условии существования, например, системы где в одном или нескольких шагах юзкейса "мяч" оказывается на стороне Клерка (т.е. долежен сделать какие-то телодвижения в рамках сценария(ев)), чтобы Клиент мог продолжить выполнение сценария. В общем виде -- когда происходит взаимодействие двух (или более) разных сущностей, посредством того что в scope, в рамках конкретной цели.
2. У Коберна есть такая вещь как идентификация internal actor ... но он эту тему у себя не развивает сильно, просто декларирует, что да ... есть. В тексте юзкейса он их явно выделяет (именует). Это IMHO некий аналог бизнес-вокера в RUP. На диаграмме он этого не показывает ... известно как он относится к UC диаграммам :-). Но это не secondary actor! Можно ли в таком случае показывать его на диаграмме. По-умолчанию -- нет, но допускаю возможность если показать сего с определенным стереотипом :-), это не запрещено, но IMHO изврат.
3. Если выбросить из головы Коберна с его white и black boxes, и бизнес доменом и системным доменом ..., то на диаграмме BUC, будет только Клерк, и все. Разницу в б/п можно показать только на activity диаграммах, либо на реализации юзкейса

816

ПО Аналитика / Re: подскажите новичку по матрице трассируемости

« : 21 Декабря 2006, 12:11:32 »

Здравствуйте, уважаемые аналитики!

просветите меня пож-та вот по такой ситуации:

 - в Rational Rose есть use-case_диаграмма, на которой 2 прецедента: "Получить наличные" и "Идентифицироваться" (это для банкомата), причем
   "Получить наличные" (более высокий уровень) -- <<включает (include)>> --> "Идентифицироваться" (уровнем ниже);

 - создаю требования в RequisitePro из модели прецедентов Rational Rose (импортирую: associate model to RequisitePro);

Вот теперь в чем вопрос:

 в RequisitePro трассировочная матрица (функциональные требования-use-case_ы) должна быть такой (вар. 1):

   FUNC1: Реализовать прецедент "Получить наличные"            (трассируется на USC2: Получить наличные)
      FUNC1.1: реализовать процедуру идентификации владельца карты      (трассируется на USC1: Идентифицироватся)
      FUNC1.2: реализовать процедуру запроса суммы наличных
      ..
   FUNC2: Реализовать прецедент "Идентифицироваться"            (трассируется на USC1: Идентифицироватся)
      FUNC2.1: ..A..
      FUNC2.2: ..B..
   ..


На мой взгляд, если реализовывать вар. 1, будут проблемы в случае, когда  use-case "Идентифицироваться" включается в другие use-case_ы
(придется дублировать функц. требования в трассировочной матрице несколько раз).
Если можно, нельзя ли аргументы в пользу выбранного Вами варианта (может быть есть 3-й вариант).

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

817

Примеры / Re: Micro-CRM

« : 20 Декабря 2006, 22:54:30 »

Если только поупражняться в написании user stories ... как раз думаю эти аспекты и вообще requirements in agile в курс включить :-).
А реально, если и присоединюсь, то на рождественских каникулах ... времени сейчас не так много. Много встреч и заврешение дел года уходящего. Хотя может и сам подкину пару бизнес-кейсов для описания :-). Я лучше свои комментарии буду добавлять в опубликованне решения :-).

818

Примеры / Re: Micro-CRM

« : 20 Декабря 2006, 15:57:46 »

Зачем так сильно заморачиваться с этой задачей -- бизнес-моделировать, еще давайте юзкейсы распишем ... ее бюджет 150 баксов! А вы хотите столько усилий? Пишем несколько user stories, ваяаем эволюционирующие прототипы ... это адекватная технология разработки такой системки ... и все. XP рулит в данном случае.

819

UML SysML и пр. / Re: Кому, зачем и когда нужен UML

« : 20 Декабря 2006, 02:04:08 »

Вопрос того, что UML обременителен, и нужно тратить время на поддержание моделей происходит от использования UML не с той стороны :-). Если мы начинаем с того, что выделяем в системе три слоя -- GUI, Бизнес-логики и слой работы с данными, то использование UML очень даже оправдано при проектировании последних двух. Естественно при наличии Domain model. А если КИС или другое ПО сделано в стиле "спагетти", когда бизнес-логика рзамазана по GUI и хранимым процедурам в БД ... то UML тут НИКАК не поможет ... тут уже ничего не поможет :-).
Процесс внесения изменений начинается с изменения модели, и анализа влияния изменений. Можно оперировать на уровне интерфесов классов добавляя методы например, или вводя новые классы при изменении бизнес-сущностей.  Более того, можно использовать UML только для ядра системы или для поддержки фреймворка, заложенного в систесму, почему нет? Для больших систем -- управлять на уровне пакетов. Другой вопрос, что приходится проектировать пакеты так, чтобы они не пересекались по данным ... а это уже вопрос в т.ч. и квалификации проектировщика (вне зависимости от того знает от UML или нет).

820

Теория моделирования и нотации / Re: Что такое декомпозиция

« : 18 Декабря 2006, 01:53:54 »

Юрий, спасибо. Не можешь (можете? как лучше:-)) напомнить ссылку, старый форум скорее всего почил в бозе

Ссылку уже кинули :-), можно на "ты" ... :-).

Интересно. Однако в чем ортогональность описания множеством функция и множеством UC? Насколько я помню, есть ортогональность структурного подхода и объектного подхода. Но UC - к ООП никакого вроде отношения не имеет?
Далее: цель - стратегия,
           функция - тактика?
Так стоит понимать?
...
Книгу Коберна держу как настольную, но все равно до конца не могу ее понять. Что занчит ВИ уровня неба, уровня горизонта, уровня моря? Это что декомпозиция? Декомпозиция контекста, декомпозиция цели, декомпозиция функции, декомпозиция объекта? В чем различия?
Объектную декомпозицию понимаю, декомпозицию функций понимаю, декомпозиция цели - мне кажется то же что и декомпозиция функций, а что понимать под декомпозицией контекста, Смещение точек зрения? Перемещение точки зрения, фокусного расстояния? С перспективы птичьего полета, до более близкого расстояния. Тогда вероятно понятно, разный уровень наблюдения. Высоко - много, но не детально, низко - узко, но детально?

...Да мысль понятна, действительно, по UC не выстроешь. Можно ли выдвинуть такую мысль: ВИ это потребности пользователей, это разные точки зрения на роль системы (в отличии от необходимости единой точки зрения в SADT)....?

Что касается уровней UC у Коберна. Это взгляд с разных точек зрения, уровень неба это обощение. У юзкейсов уровня неба и экотры могут быть разные, и цели у них разные. Коберн говорит про то, что UC summary (небо), объединяют в себе цели разных экторов (уровня user goal - "море"). Второй аспект это время выполнения этого UC -- дни, недели ... А уровень моря, это выполнил -- пошел покурил, потом такой же другой взял (например открытие счетов), то что проходит "одной транзакцией".
Когда говорим о соотношении summary и user goal UC, то, как я говорил, это не обязательно будет "строгое" включение UC уровня user goal в summary. Если бы каждый шаг summary был бы строго одним UC уровня user goal, то это можно было бы считать декомпозицией, а так этого может и не быть ...
Справедливости ради следует отметить, что часто происходит и "функциональная" декомпозиция, особенно если переходим от уровня summary, к user goal, т.к. например в UC "Получить кредит" (эктор Клиент) уровня Summary, может быть цель пользователя-клерка "Оценить кредитный риск Клиента". Это будет несколько похоже на функциональную декомпозицию, но как сказал Александр во-первых кол-во уровней ограничено (мы уже не можем декомпозировать до элементарных оперций, которые делает клерк для оценки риска, ибо это уже не юзкейсы а его целостный сценарий ... а при функциональной декомпозиции это все ФУНКЦИИ только разного уровня детализации), во-вторых мы рассуждаем в терминах целей, а в третьих смотрим, как вы справделиво заметили, с другой стороны ... с внешней стороны (Эктор -- всегда будет outside of scope).

821

Сообщество Аналитиков / Re: Создание сообщества IT-консультантов, аналитиков и архитекторов

« : 17 Декабря 2006, 17:12:13 »

К сожалению, я не могу принять участие во встрече, хотя инетерсно было бы познакомиться с коллегами "вживую" :-). Да и выходные не всегда лучшее время для встреч, может как-ниь вечером, после работы ... хотя конечно у кого когда заканчивается ... но при желании можно прийти на работу на 1 час раньше и 1 час раньше уйти, если конечно есть такая возможность.

822

RUP EUP AUP OpenUP / Re: Покрытие RUP инструментами от Borland и проч.

« : 17 Декабря 2006, 17:07:51 »

Коллега подкинул ссылку на описание того, как инструментами от Borland покрыть весь спектр дисциплин по RUP - http://bdn.borland.com/article/33319 Ценным моментом является приведение альтернатив от других коммерческих производителей и OpenSource-команд.

Следует учесть то, что статья уже старая ... и у Борланда есть уже инструментарий для тестирования (в этом году Борландом была куплена компания Segue -- #3 на рынке тулов для тестирования) и для портфолио менеджемента. Второй момент, что статья не содержит действительно серьезного анализа альтернатив, и следует помнить, что цель статьи в большей степени маркетинговая :-).

823

RUP EUP AUP OpenUP / Re: Покрытие RUP инструментами от Borland и проч.

« : 17 Декабря 2006, 17:03:57 »

Безусловно интересная статья.

Проблема лишь в том, что поработать со всеми этими инструментами большая иногда проблема.
Скажем CaliberRM. Нашел дистрибутив, пытался установить: клиент ставится,а сервер ни в какую.
Поставил сервер на другую машину. Проблемы соединения, проблемы использования. Все очень непонятно и сложно. Хотя читал анонсы, как о самой лучшей системе управления требованиями.

Пробывал использовать розовскую систему управления требованиями. Не хочет работать с office 2003, только office 2000.

Я не испытывал трудности при работе с CaliberRM, мне он даже больше нраавился чем RequisitePro. Да и инсталляция его достаточно простая. Не знаю чем конкретно вызвана у вас проблема инсталляции серевера, но даже в бытность работы в Борланд, я с проблемами инсталляции у заказчиков на сталкивался. Посмотрите внимательно на ReadMe, может просто с .NET проблемы? И кстати какая у вас версия CaliberRM?
ReqPro нужно ставить более свежий, чтобы он работал с Word2003, не ниже 15 релиза. В 13 был дефект работы с офисом отличным от английского. Сейчас уже есть версия 7 ReqPro, но я ее еще не ставил. Как поставлю -- поделюсь впечатлениями, если они возникнут, учитывая что функциональность его не растет в последнее время, и GUI у него конечно не очень приятный, по сравнению с CaliberRM.

824

Теория моделирования и нотации / Re: Что такое декомпозиция

« : 17 Декабря 2006, 16:53:24 »

1. В старом форуме я приводил ссылку на статью "Why Usa cases are not functions", там можно и посмотреть более детально.
2. В общем виде можно сказать, что UC это в первую очередь ЦЕЛЬ ... а не действие. И именно функция может быть декомпозирована до элементарных операций. Причем, говоря о декомпозиции, подразумеваем, что функция строго состоит из последовательности операций. UC тоже могут быть декомпозированы, но в терминах декомпозиции ЦЕЛЕЙ пользователя по отношению к системе. Хотя более корректно говорить не о декомпозиции целей, а о контексте, который задает например outmost UC для других UC ... это очень хорошо показано у Коберна, когда он вводит понятие уровней юзкейсов. Близко к этому -- RUPовское Business UC - System UC. BUC -- по сути контекст для SysUC. Эта грань -- она с одной стороны достаточно четкая, с другой стороны (особенно с позиций функционального анализа) может показаться не вполне четкой. Но она еть :-). Например, можно выстроить функциональную декомпозицию по ЦЕЛЯМ, но сложно (или невозможно) будет выстроить "иерархию" UC по функциям, ввиду ортогоноальности природы UC и функций. Да, у них может быть пересечение (если описывать функционально предметную оласть и ее же потом описать на UC), но повторюсь, что в одном UC может присутствовать множество функций и наоборот.

825

UML SysML и пр. / Re: Методика количественной оценки диаграмм UML

« : 09 Декабря 2006, 00:52:36 »

1. Метриками можно описать не диаграмму, а собственно качество, например, дизайна.
2. Как вариант можно посмотреть эту книгу "С. Орлов. Технологии разработки программного обеспечения".
3. Можно посмотреть еще тут http://www.sdmetrics.com/CustomMetrics.html
4 ... и тут http://javaboutique.internet.com/tutorials/codemetrics/

и просто погуглить на тему метрик дизайна