Здравствуйте, nvb, Вы писали:

nvb>Здравствуйте, Saddo, Вы писали:

>Вообще-то подобная проблема решается словарем — грубо говоря, текстовыми заметками, прикрепляемыми к блокам модели и однозначно интерпретирующими короткое название блока в понятном для всех виде. Можно иметь несколько интерпретаций, понятных для заказчика и исполнителей, но писать эти интерепретации должен один человек — аналитик. Это хуже, но если иначе нельзя...
>>Разработчики должны будут иметь список соответствия (вида Б = B) терминов и объектов модели.
Я примерно о том же и говорил.

>>Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области.
>Это как??? Хочется спросить "тогда зачем нужна такая модель?", но вероятно, все сложнее. Приведите пример такого несоответствия.
Прямой пример я навскидку не смогу привести. Но наверное есть термины специфичные исключительно для русского языка (язык предметной области) и не имеющие аналогов в английском (язык модели). Хотя в популярных предметных облостях это не бывает.

nvb>Стоп! В последнем предложении две фразы:
nvb>"Модель сильно отличается от реальности" — так приблизьте до необходимого уровня, что мешает? Все модели не идеальны.
nvb>"Зачастую требуется корректировка модели с учетом возможности разработки этой модели, представлении в виде кода" — коректировка или дальнейшая декомпозиция?
Аналитик, который занимается анализом предметной области, может не всегда идеально представить свое знание ввиде модели. И не всегда его модель будет хорошей, если не будет учитываться мнение тех кто будет разрабатывать эту модель.

nvb>Вообще, похоже, есть проблемы с аналитиком, раз сказана такая фраза. У него времени не хватает или он просто не в состоянии это сделать?

"In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback. The analysts have full responsibility for creating the model, based only on input from the business experts. They have no opportunity to learn from the programmers or gain experience with early versions of software. Knowledge trickles in one direction, but does not accumulate." (c) Evans

nvb>Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили?
nvb>И почему разработчики не участвуют в проектировании? Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили?
Просто подобный слой приносит сильные задержки по времени. Эксперт <-> Аналитик(и) <-> ТимЛид/Проектировщики. К тому же, как и любая прослойка вносит свой уровень шума и сломанного телефона.

nvb>А вообще-то я немного не понимаю, в чем проблема. Если в работе над моделью принимают участие лишь несколько аналитиков, то именно они и будут являться носителями ключевых знаний. Если Вас не устраивает такое состояние дел, то можно организовать регулярные семинары для разработчиков, на которых будет объясняться модель — что там есть и зачем. Но, по опыту, большинству разработчиков это настолько по барабану, что такой семинар — пустая трата времени и денег. Лучше уделять время на объяснение модели на проектных совещаниях — по 10-15 минут, хотя бы на верхних уровнях.

В том-то и проблема, что у нас это единственное похоже решение.