1621

Книги, статьи и ресурсы / Re: К Вигерс, Разработка требований к программному обеспечению--пропущенные страницы

« : 27 Августа 2011, 23:53:40 »

Вы просто молодец!

1622

О Сайте и Форуме / Re: [ИДЕЯ] Тематические блоги на сайте

« : 25 Августа 2011, 12:28:58 »

Вообще голосование значимо. 4 голоса за. Ну собственно почти столько же и используют. Проблема данного блога: там намучаешься вставить картинки.

1623

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 25 Августа 2011, 12:26:10 »

Александр, назначайте мне букву и указывайте сроки. Да и дайте первоисточник:)

1624

Работа / Re: Кто где работает территориально?

« : 24 Августа 2011, 22:47:49 »

Иваново, Палехская, 10 ЗАО "НПО Консультант"
и
Иваново, Ф.Энгельса, 10 ФБГОУ ВПО "Ивановский государственный химико технологический университет"

1625

О Сайте и Форуме / Re: [ИДЕЯ] Тематические блоги на сайте

« : 24 Августа 2011, 22:43:30 »

У меня вот, например, 2 блога: личный (подседневная жизнь), профессиональный - события и высказывания, ссылки относительно профдеятельности.

Сейчас вот думаю над вопросом агрегации блогов аналитиков.

Павел, посмотрите как все реализовано у software-testing.ru. Мне кажется, можно что-то в подобном же ключе.

Мы долго шли к коллективному блогу, но так и не используем его активно. Почему? Трудно сказать, но это факт.

Что с ним делать? Оставить? Убрать? Оставить и интегрировать ленту анонсов блога на первой страницы с индивидуальными блогами? Последний вариант мне нравится больше (правда, там другой стоит движок drupal)

1626

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 24 Августа 2011, 22:38:45 »

Не совсем понял технологию работы с глоссарием. Напишите, пожалуйста, сценарии использования:
1. добавить термин
2. добавить перевод
3. добавить альтернативу перевода (2 и 3 видимо одно и тоже)
4. что-то еще?

Спасибо

1627

Системный Анализ и Требования / Re: Логично ли так формировать ТЗ?

« : 22 Августа 2011, 20:41:50 »

Эд, а не получается ли при этом уже функциональная декомпозиция?
Описав все СВИ относительно всех Пользователей вы и получите набор всех необходимых ФТ. Зачем еще дальше дробить на функции?

Саша, не в данном случае. Здесь не декомпозиция, здесь группировка по определенным (например, по архитектурным признакам). Я согласен, может это не должно сразу появится в ТЗ, хотя а почему нет? В этом случае просто меняются углы зрения и высвечиваются некоторые темные местечки. Если ВИ считать не просто констатацией требований, но и синтетическими штучками, то почему нет?

Мой вопрос в Use Cases Professionals: Could a subsystem be of an actor? Could one subsystem initiate (communicate) an use case of another one?

Ответы:
James Shields • 

Any user or system or subsystem that interacts with your system is an actor.
 And your system is an actor when it interacts with another system or subsystem.
 That other system or subsystem you interact with is often termed a secondary actor.
 Personally I don't like this secondary actor terminology as it leads to confusion.
 It's just a system or subsystem you interact with to use it's functionality via it's use cases.

Putcha Narasimham

If a subsystem SubX-SD becomes an Actor, the system boundary has to be redefined and the new SD NSD will be different. The SubX-SD must be truly independent of the NSD. As said earlier "initiation" use case is not crucial. It can be taken up and resolved later, that is after Naming the Use Case and its Goal.

 I wish to restate what you wrote: "in some cases SubX-SD can initiate some UC of the NSD ON BEHALF OF a previous Actor (PA) of the original SD. PA is NOT directly connected to the New SD and is NOT an Actor of NSD". I hope this is consistent with what you wrote & intended.

 If the SubX-SD is truly a subsystem with some independent processing power / storage etc (NOT A mere TRANSMITTER OF INFRORMATION with or without amplification) then the connection between SubX-SD and the PA (now Actor of SubX- SD) is irrelevant to the context of the new SD. SubX-SD must deal with the PA as its Current Actor CA separately in a suitable way. The SubX-SD must have its own GOAL (it may be related to what CA asks SubX-SD) with ref to the new SD. This is the principle of system boundary and specific context for each subsystem of any system.

 Within a SYSTEM BOOUNDARY of an SD, NO SubSystems of itself should be recognized and represented in the USE CASE DIAGRAM of SD. Accordingly it cannot be an actor of another External System ES which may be connected with SD . If a USE CASE DIAGRAM of the ES is drawn, then SD as a whole will be an Actor of ES which will now be THE SD.

 If an Actor A is a mere TRANSMITTER he or she or it is NOT an Actor. The entity on the other end is the true Actor of the System Under Development.

John Watson 

Hello Edward,
 I think that if Ivar Jacobson had English as his first language that Actors would have been called Interactors. An Actor (or Interactor)symbol on a Use Case diagram represents a role filled by anything outside the boundary of a system that interacts with that system.

 Consider an Automatic Check-in Kiosk at an airport. A traveller (Actor) interacts with the Check-in Kiosk (System) in order to obtain their boarding pass and bagggage tags. To complete the process, The Check-in Kiosk System requests the Reservation System (Actor from the viewpoint of the Check-in Kiosk) to validate the Traveller's reservation details. In this context, Get Boarding Pass is a Use Case of the Check-in Kiosk initiated by the Traveller Actor. From the viewpoint of the Traveller the Check-in Kiosk is a system and the Reservation System is "invisible". From the viewpoint of the Check-in Kiosk, the Reservation System is an Actor. From the viewpoint of the Reservation System the Check-in System is an Actor.

 If you would like a diagram and Use Case descriptions to illustrate the above, e-mail me.

 For scope control purposes we choose to treat the Check-in System and Reservation Systems as separate entities. From the viewpoint of each system (or sub-system?) the other system is an Actor

Мнения пока разделились

1628

Варианты Использования (Use Case) / Re: Кто нибудь встречал адекватный пример описания сценариев при обобщении ВИ?

« : 22 Августа 2011, 20:32:37 »

Почитай вот наш FAQ

1629

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 22 Августа 2011, 20:22:38 »

На то воля топикстартера была. Не виноватые мы - он сам к нам пришел

1630

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 22 Августа 2011, 19:50:06 »

Иначе будет бардак - кто в лес кто по дрова... Что уже и получилось в этой теме.

А где ты увидел бардак? 

1. Идет привлечение внимания
2. Выясняется интересно ли это кому-то
3. Предложен пример переводов и обозначены некоторые проблемы (как иллюстрация)
4. Ожидается сбор кворума

Способы будут, как можно прочитать у Александра. Возможно и твой вариант.

1631

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 22 Августа 2011, 15:13:45 »

Вообще, я очень советую каждому аналитику иметь на рабочем столе ссылку на RUP,

А ссылку ?!

1632

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 22 Августа 2011, 15:12:30 »

Добрый день, Александр

На данном этапе мне важно понять, будет ли это кому-то еще интересно. Если да, то выложим на wiki, организуем обсуждение, возможно - голосовалку, поскольку абсолютного консенсуса по некоторым терминам может и не быть.

Ждем реакции других заинтересованных лиц. Сколько будем ждать?

1633

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 22 Августа 2011, 15:11:12 »

Бизнес ограничения – есть ограничения, налагаемые на дизайнерскоепроектное решение по организации, которая нуждается в решениив нем нуждается?. Бизнес ограничения описывают ограничения на доступные решения, или аспект текущего состояния, которое не может быть изменено путем развертывания нового решения. См. также технических ограничений.

Но все равно звучит явно не по-русски. Надо думать над формулировкой.

1634

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 22 Августа 2011, 15:04:11 »

Осуществлять и редактировать перевод в таком виде крайне затруднительно.

Вместе с тем у нас есть wiki http://lib.uml2.ru/BABOK, где просто имеет смысл создать допстраницу Глоссарий и работать над ней совместно в режиме редактирования.

Другой способ - пригласить желающих участвовать. Вам, Александр, (или кому-либо еще (мне, например) сделать на GoogleDocs расшаренный для участников документ (Вы владелец остальные могут редактировать). Желающие обратятся к владельцы, чтобы он мог внести его в списки редакторов. На документом можно работать совместно.

1635

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 20 Августа 2011, 21:45:10 »

Ну, нужно было автору показаться умным! Только практического значения это не имеет!

Автор не только кажется умным, но и строит на этом свою полемику с оппонентами. Записывайтесь в Use Case Professionals.

Автор некто Brain C.

его ответ на вопрос

How to properly reflect sequence of use cases in UML?

Hello to everyone.
 My question is basically the following:

 Use Case diagrams typically do not reflect sequential order of use cases in native UML. In my work I often need to provide development team with the high-level order of use cases reflected in the main set of use case diagrams.

 Example: let's imagine that we have 5 CRUD Use Cases - 'View List Of Objects', 'View Object's Details', 'Delete Object', 'Create Object', 'Edit Object'. From the standpoint of sequence (and thus from the standpoint of navigation within the application) first comes 'View List Of'; after the list is displayed User is able to 'Create New', 'View Details' and 'Delete'; after performing 'View Details' User is able to 'Edit'.

 There are some ways to do it which I'm aware of however I do not consider them as proper options:
 1. Create a 'Sequencer Use Case' which includes all these Use Cases (e.g. 'Manage Objects'). But this will flood the diagram with UC's of different level of abstraction.
 2. Use additional relationships such as ''Precedes' or 'Invokes'. But this will also flood the diagram heavily.
 3. Use sequence and activities diagrams. However these diagrams are ususally used to reflect flow of a single use case and not the flow between use cases.
 How do you solve this issue?

I think part of the answer is in how we frame the question. Rather than use the CRUD use case example that rarely has direct value to a user, let's consider a business suite like Microsoft Office with use cases Manage Document, Manage Spreadsheet, etc. These use cases each has a goal that matter to a user to use an artifact with paths to view, create, edit and delete it along with other connected use cases. Some, like delete, could be used by all manage use cases; others can only be used by a few because they are more narrow.

 In real world usage, users create Word documents, then copy part to a PowerPoint and then change the wording, and then copy it back to the Word document, and then ... There are innumerable scenarios.

 If you view use cases to be services, you do not have to worry about documenting them all. Sufficient sample scenarios that cover the services would be sufficient.

 Sometimes there truly are overriding business reasons for specific order that are *always* true. In that case, I suggest that the whole scenario that delivers the business goal should be its own use case that describes all the steps in order - including other use cases, that can provide value outside this scenario, as appropriate.

 Unfortunately, all too often, today's "always" is tomorrow's "what if we?" Preconditions then become a documentation, coding and testing problem. I have found it better for project sanity to treat use cases as services whenever possible.

 In spite of common usage, use cases cannot have preconditions and be UML compliant. Please see http://www.building-requirements-consensus.com/preconditions.html for a detailed discussion.