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

_O_>>4. Есть достаточно много крупных компаний успешно применяющих UML для проектирования и разработки. Собственно, мы делаем продукт как раз на базе UML 2.0, который вполне успешно используется этими самыми компаниями.
M> Но есть не меньшее количество таких же крупных компаний, которые не менее успешно не применяют UML и что?

Без анализа какие компании применяют UML, в каких проектах и для чего — кроме беспредметного религиозного спора ничего не выйдет.
Например в каких секторах рынка (если это вообще рыночные сектора) работают компании, применяющие и не применяющие UML? В каких проектах он применяется и для чего? Что ставится на первое место в подобных проектах — код или модель?
Если вы потратите время, что бы честно и спокойно ответить на эти вопросы — спорить станет не о чём.
Во-первых выясниться, что упомянутые ранее крупные компании UML сам по себе никогда не применяют. Как вы никогда не услышите от них про применение C++ — даже если они им очень широко пользуются. Они могут применять или не применять процесс разработки, в котором UML используется или не используется как язык описания моделей определённого уровня и не более того. Да и то в разных проектах может быть разный процесс. Что, впрочем, совершенно не мешает специалистам компании широко применять тот же UML для общения друг с другом — рисования диаграмм на доске. Насколько мне известно — в том же Микрософт такое происходит достаточно часто.
Теперь по поводу Микрософт. То, что Микрософт не применяет RUP — совершенно естественно. Это тяжеловесная методология, а MS всю дорогу демонстировала, что скорость разработки новых технологий для них гораздо важнее качества (не верите — посмотрите список патчей к виндам за прошедший год). Что, с моей точки зрения, совершенно оправдано. Кроме того, MS ведёт свои разработки для себя самой. То есть выступает и как заказчик и как производитель. Потому лишний документооборот, который возникает между заказчиком и производителем им не нужен. Вспомните так же, что MS имеет уникальное по объёму и концентрации количество высококвалифецированных профи — для которых тот же UML не нужен — так как они вполне могут общаться на более высоком уровне, пропуская многие элементарные шаги. В общем MS — уникум — и нельзя ожидать от других компаний того же уровня и подхода к разработке, что и от MS.
Если брать компании, производители софта для софта (Sun, Borland, Intel, IBM (те их подразделения, что производят компиляторы, например)), то там картина та же. Она обусловлена простой вещью — на верхнем уровне компилятор, к примеру, как UML модель — элементарен, а на подробном — пока вы будете разрисовывать среднининький компилятор или JVM — вас на рынке просто похоронят. Да и пользы от такой модели будет не много. Часто будет проще посмотреть в код. Ведь для рисования алгоритмов UML как раз не очень то и подходит. Кроме того, компилятор или JVM или DB — абы кого делать не допустят. А те специалисты, которые этим занимаются в разжёвывании элементарных вещей просто не нуждаются. Потому ни экономического ни технологического смысла применения UML в подобных проектах — просто нет.
Совсем другая картина в компаниях, которые занимаются автоматизацией — внутренней или внешней. В таких проектах предсказуемость сроков и качества работ выходят на первое место (клиенту то специфику IT обяснять никому не охота или собственному начальсту). Кроме того, привлекать к подобным проектам спецов такого уровня как в MS или Sun — просто не выгодно экономически. Требуется процесс разработки, который позволяет вести проекты при, в среднем, довольно средней квалификации программистов. Причём делать это прогнозируемым образом. А такой процесс неизбежно требует средств описания тех же моделей — в первую очередь для самих разработчиков. Вот там то UML и процветает — для этого то он (де факто) и был придуман.