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

×


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

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


Сообщения - pshony

Страницы: 1
1
Бегло просмотрел варианты перевода, вот несколько альтернативных вариантов / корректировок в формулировках для вашего рассмотрения, которые успел записать:
Impact Analysis – анализ последствий
Baseline – базовый/исходный срез/перечень (требований)
A business policy is a non-actionable directive that supports a business goal - Бизнес политика - это неоспоримое (неподлежащее обсуждению) руководство к действию, призванное поддержать определенную бизнес цель.
A higher level business rationale that, when addressed, will permit the organization to increase revenue, avoid costs, improve service, or meet regulatory requirements - Высокоуровневое бизнес обоснование, которое, в случае принятия соответствующих мер, позволит организации увеличить доходы, избежать затрат, улучшить обслуживание, или удовлетворять нормативных требований
Work Product – результат работы

2
Ну, потому что интуиция человеку дается скорее от природы. Можно исходить из того, что определенный уровень интуиции у посетителей сайта / членов сообщества  в наличии имеется. Предполагаю, что умение ею пользоваться закладывается, наверно, где-то в самом начале.

Вряд ли сайт будет претендовать на повышение уровня интуиции своих посетителей :).

При наличии одной лишь "способности чувствовать" логические цепочки еще отсутствуют ...
Т.е. как и в любой другой области, одной лишь способности не достаточно.

По мере наработки опыта и профессионализма количество цепочек увеличивается.
Хотелось бы верить, что также сайт / сообщество uml2.ru способно помочь заполнить недостающие цепочки :).
В этом смысл слогана и, как мне кажется, цель сайта/сообщества.

А почему не наоборот? Это только половина одного витка спирали. :)
Цитировать
Интуиция — способность чувствовать уже имеющиеся логические цепочки связанной информации, касающиеся нужного вопроса, и таким образом моментально находить ответ на любой вопрос.
От интуиции к компетентности!

3
От интуиции к компетентности!

По-моему, вполне отражает цели сообщества:http://www.uml2.ru/index.php?option=com_content&task=view&id=13&Itemid=72
и то, зачем большинство, как мне кажется, приходит на сайт:
одни: узнать компетентное мнение коллег,
другие: такое мнение предоставить (и тем самым поднять свой авторитет в глазах коллег).

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

4
Обсуждение статей / Re: Отношение extend
« : 17 Июля 2009, 15:12:40 »
Эдуард, Сергей,

Спасибо за развернутые ответы. Конечно, все это в том или ином виде я читал. Для меня же важно услышать авторитетные мнения, основывающиеся на успешной практике. Также, думаю, что это будет полезным дополнением к статье.

В связи с моим вопросом «Значит ли из ответа на второй вопрос, что Include нельзя использовать в альтернативных потоках?» просто напишу следующее.

1.   Когда-то ход мыслей у меня был примерно следующий:

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

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

Утверждения типа «В отношении «extend» любопытно то, что базовый ВИ ничего не знает о расширяющих ВИ, он просто предоставляет для них точки входа.» не имели для меня никакого практического смысла, т.к. какая разница, «знает» или «не знает», если мне все равно в базовом ВИ нужно прописать эти точки расширения, без которых ничего не произойдет (т.е. мне все равно нужно знать наперед, что тем или иным способом мне нужно вызвать такую-то функциональность и в таком-то месте. Не зная, какую функциональность я хочу вызвать, как я могу сказать, где заранее расставить точки расширения? Иначе, чтобы впоследствии не редактировать документ с базовым ВИ, придется наставить столько точек расширения, что потом вообще никому не объяснишь, кому это надо, зачем, и что с этим делать :-) Вот если бы можно было действительно как-то так написать расширяющий ВИ, чтобы документ с расширяемым ВИ редактировать не приходилось... :-)

Чтобы никого не сбивать с толку, процитирую еще раз «правильное» понимание:


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


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


2.   Правда, я так и не нашел ответа на следующую проблему:

ВИ пишутся, для:
- клиентов – чтобы они могли понять, как ПО поможет им выполнять их работу, и чтобы они могли внести корректировки, если им нужна чуть-чуть другая «помощь», нежели предлагается.
- разработчиков – чтобы они могли понять, что должно делать ПО, на сколько это сложно и сколько будет стоить.
- тестировщиков – чтобы они могли написать тест-кейсы и проверить, что ПО работает так, как предполагалось.

По факту, никому из них не интересно вникать в правила и особенности написания ВИ.

Очевидно, ВИ не пишутся для самовыражения бизнес-/системных аналитиков :-)

Чем же наличие двух разных возможностей запустить определенную функциональность (в тексте ВИ) может помочь в достижении целей первых 3х? Что же эти возможности дают такого, что оправдывало бы дополнительную сложность простых вещей?

С одной стороны, можно было бы подумать, что предварительное разделение на Include и Extend может подсказать что-то архитектору, но, с другой стороны, нужна ли ему такая «помощь»?

5
Обсуждение статей / Re: Отношение \
« : 16 Июля 2009, 22:01:19 »


1. Может ли точка расширения быть помещена в Альтернативный поток?
2. Если может, то чем это будет отличаться от Include в одном из альтернативных потоков?

...
2. а причем тут инклюд? инклюд - это то что включается всегда, без чего основной ВИ неполон и завершится не может. А расширяющий - это то без чего можно спокойно обойтись. По-моему все предельно ясно в статьях написано - перечитайте их внимательно

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

  • Значит ли из ответа на второй вопрос, что Include нельзя использовать в альтернативных потоках?

Пример (чтобы мне лучше разобраться):

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

Вопрос к примеру: На каких шагах такого ВИ можно/нужно включить ВИ для выбора адресатов из адресной книги (если предположить, что другого способа указать адресата, типа просто ввести его имя с клавиатуры, не существует)? Т.е. какая здесь ДВИ получается?

6
Обсуждение статей / Re: Отношение \
« : 16 Июля 2009, 19:37:53 »
1. Может ли точка расширения быть помещена в Альтернативный поток?
2. Если может, то чем это будет отличаться от Include в одном из альтернативных потоков?

7
Может быть, можно сойтись на некой компромисной позиции?
Процесс разработки предполагает, что документация должна корректироваться и обновляться по ходу проекта.

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

От заказчика получено одобрение.

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

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

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

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

Что Вы думаете?

8
Прочитал комментарий по поводу того, что ВИ не являются функциональными требованиями.
Цитировать
Варианты использования сами по себе, строго говоря, не являются функциональными требованиями ... это (по Вигерсу) пользовательские требования. Функциональное требование будет выглядеть в данном случае как некая возможность системы/модуля по сохранению/использованию настроек, и "подтребованием" -- возможность обновлять настройки через обновление файлов настроек
Прочитал комментарии в теме: Как Вы описываете требования к ПО?

На сколько я понимаю, имелось в виду, что просто не все требования возможно описать в ВИ и какие-то нужно будет задокументировать в Supplementary Specification.

Это Ок. А то сначала подумал, что параллельно с юзкейсами предлагается вести отдельный документ, где функциональные требования, описанные в ВИ, необходимо было бы прописать явно.

9
1) Хотел бы добавить, что мы, по крайней мере, заявляем :-), что работаем в соответствии с RUP. А там все же основным артефактом, который фиксирует фунциональные требования, является юзкейс(ы). Получается, у меня выбора нет. Исправьте меня, если считаете, что я что-то не правильно понимаю.

2) Есть такая книжка: Use Cases Patterns and Blueprints, By Gunnar Övergaard, Karin Palmkvist, ISBN : 0-13-145134-0
Так вот там тоже упоминается этот CRUD pattern. Но там (в этой же книжке) упоминается такой Common Mistake, как "Modeling a business process as a system use case". Там есть пример:
"An example of a business use case that will be supported to a high degree by a software system is Manage Order in a warehouse business. The flow comprises among other things the registration of an order, the generation of a pick-list for the assembly of the shipment, the generation of an invoice when the order has been shipped, and finally the registration of the payment from the customer. It should also comprise the possibility to change or to delete a registered order.

Why not capture this as a single use case in the system use-case model? The problem is that this use case does not model one usage of the software; it models one usage of the business. The flow consists of several subflows that will be performed at different points in time, at irregular time intervals, and possibly initiated by different persons. Furthermore, each of these subflows provides a value to someone inside the warehouse. Hence, every subflow constitutes a use case in the software; that is, they are complete usages of the software. If we change focus and study the entire warehouse, however, none of them constitutes a use case on its own; they are only fragments in the usage of the warehouse business. The key here is the subject of the model: Is it the software system or is it the business?"

Еще там пишется про "Pauses in Use Cases
A somewhat related situation is when the performance of a use case includes a scheduled pause. A typical example is the telephone exchange system supporting a hotel, where one important service to the customers is to offer automatic wake-up calls. From the business perspective, the complete flow starts when a customer requests a wake-up call at some future point in time and ends when the wake-up call has been performed the next morning.

It is tempting to model this flow as one use case, but this is not the best way to do it. First, there is a long period of time during this process when nothing happens, and it is generally considered bad practice to model use cases whose execution largely consists of doing nothing. Second, it may be the case that the wake-up call is never performed at all (for example, if the customer cancels the request or decides to check out before the wake-up time). In this case, the use case has been waiting for a long time for nothing (see also Chapter 28, "Future Task")."

Отсюда и возникли мои сомнения, а не повторю ли я эту ошибку у себя в юзкейсе, если сделаю его единым, как описывал. И, соответственно, для меня не понятно, почему CRUD не подпадает под эту ошибку?

3) Что вы думаете про Pluggable use cases http://alistair.cockburn.us/index.php/Pluggable_use_cases

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

Будет ли корректным описывать задачу выше в виде одного варианта использования (например "Модифицировать конфигурационные настройки системы"), который будет сначала описывать шаги того, как пользователь скачивает файл, потом просто уточнить, что перед тем, как загружать новую конфигурацию, ему её следует отредактировать и внести необходимые изменения вне системы, а затем описать шаги по загрузке фала обратно в систему и того, как система его валидирует?

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

Написанные варианты использования (не только этот :) будут являться функциональными требованиями к системе.


Страницы: 1