Я согласен с Арамисом! (c)

Гегель, он самый.

Дык нет в свободном доступе перевода RUP на русский язык.

Ну, на одном сайте видел я на русском очень краткое описание самой сути бизнес моделирования по RUP.
Кстати, если у кого есть желание, могу отослать на почту для просмотра и критики ту модель, которая у меня сейчас получается. Она, конечно, далеко не закончена, однако что-то уже есть (с Вас адрес почты).

galiaskarov злой собака isuct офигенная точка ru

galiaskarov злой собака isuct офигенная точка ru

Какой злой адрес:). Ушло.

Замечательным примером того, как по одним и тем же словам возникают разные диаграммы классов, является вот эта ветка: http://www.uml2.ru/forum/index.php?topic=560
Так о каких единых правилах может идти речь?
Кстати, может и Вашу модель выложить в примеры? Тогда к обсуждению возможно присоединится не только уважаемый Аксакал

ой там моделище, а не моделька, думаю вряд ли у почтенного общества хватит желания усе там проверять и понимать

ой там моделище, а не моделька, думаю вряд ли у почтенного общества хватит желания усе там проверять и понимать

Да нет. Все еще впереди. Над ней работать и работать мне еще.

The Russian Programmers

A group in an American firm that was contracting their programming to a Russian company contacted me. They wanted me to teach them how to write use cases for Russian programmers who knew neither English nor the domain very well.

I said, "You can't hope to teach them the domain inside the requirements document. First teach them the domain, then write a short requirements document that speaks to someone knowledgeable in the domain."

After trying for hours to get me to reveal the secret of communicating across this enormous gap, they finally admitted they had previously (and successfully) worked simply by putting the key people in the same room. They were just hoping that I had a way to communicate the requirements across the ocean perfectly using use cases.

In the end, they improved on my suggestion. They wrote a short requirements document for their local domain experts and then flew one of those experts to Russia to translate, explain, and generally ensure that the programmers were doing the right thing.

The domain expert could jump the large gap presented by the short use case document and then produce, as needed, and only as needed, communication to fill in and reduce the size of the gaps so that the Russian programmers could jump across.

The domain expert did not attempt to communicate perfectly. He managed the continuous incompleteness of the communications by interacting with the programmers in person and watching what they produced. Luke Hohmann (1998) refers to this as "reducing the equivocality" in the communication.

What the domain expert understood was that he did not have to reduce the equivocality to zero. He only had to reduce it to the point that the Russian programmers could take meaningful action.

Given that complete communication is never possible, the task on a project is not to try for complete communication but to manage the incompleteness of our communications.

The target is to reduce equivocality enough for appropriate action to be taken. That means guessing how much is needed, where to stop, when and how to make the gaps smaller, and how to can help the receivers to jump larger gaps.

Software projects are short on time and money, and making the gap smaller costs both. You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there.

Перевод в Промт 8 со стандартными словарями

Российские Программисты

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

Я сказал, "Вы не можете надеяться преподавать им домен в документе требований. Сначала преподавайте им домен, затем напишите короткий документ требований, который говорит с кем-то хорошо осведомленным в домене."

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

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

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

Специалист по проблемной области не пытался общаться отлично. Он управлял непрерывной неполнотой связи, взаимодействуя с программистами лично и смотря, что они произвели. Luke Hohmann (1998) именует это как "сокращение двусмысленности" в коммуникации.

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

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

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

Программные проекты - короткое замыкание вовремя и деньги, и создание промежутка меньшая стоимость оба. Вы должны обнаружить, как большой промежуток, с которым Вы можете пройти в каждый момент, сколько двусмысленности Вы можете терпеть, и остановить там.

Ничего не понял

Ничего не понял

Я всё жду - не дождусь, когда же появятся переводчики на базе нейросистем. ИМХО, технически уже вполне реализуемо.

Ничего не понял

Эд, а ты всегда так читаешь англоязычную лит-ру??

Саш, да нет. Я почему и прибег к помощи переводчика. Прочитал раз, прочитал два. Не фига не понял чего там автор пытается сказать.

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

Идея вроде понятная, но что пытается объяснить автор? Толи что русские нетерпеливые, плохо знают предметную область, либо пытаються все сразу описать, вместо того, чтобы дать краткое содержание, которое постепенно уточнять.

Поясни что ты сам понял?

Эд,

Ну да одна под-глава не даст полного представления о том, что хотел сказать Коберн.
Всю главу можно прочесть здесь: http://alistair.cockburn.us/index.php/ASD_book_extract:_%22Unknowable_and_incommunicable%22
Просто до этого он рассказывает о том, что два человека, имеющих разный бэк-граунд, могут понять одни и то же предложение по разному. Поэтому, прежде чем начать разработку, надо всех участников погрузить в "domain", т.е. объяснить/рассказать предметную область. И чем ближе и дольше люди общаются, тем им меньше надо что-то писать, достаточно только сделать мазки, чтобы не забыть через месяц о чем кто-то хотел сказать.
И как раз мастерство аналитика - это:
"You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there."
"Вам надо понять - на сколько большие разрывы/шаги вы можете сделать в каждый конкретный момент, как много неоднозначности Вы можете допустить, и остановиться здесь"
Тут русские не причём, просто Коберн хотел показать, что для людей с другой культурой и без знания ПрОбл не возможно все описать, все равно будут недопонимания и двусмысленность.

Дык нет в свободном доступе перевода RUP на русский язык. По-моему, за деньги такое делал CMConsult с Новичковым, но результатов я не видела.

Не надо путать Александра Новичкова и Новикова Леонида Борисовича. Это разные люди, с радикально разными экспертизами. Объединяет их только то, что оба работали в Интерфейсе когда-то.
Новчиков и его компания СМ-Консалт предлагает только ТРЕНИНГИ для подготовке к сертификации по инструментарию ClearCase, ClearQuest. А вот Новиков Л. Б. действительно занимался переводом RUP на русский. Официальная позиция в то время компании Rational была в неодобрении локализаций RUP. Лично я не вижу большего смысла в переводе, если честно.

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