применение RUP ничего не гарантирует, это методология, а не готовое техническое решение.

ну ка, знатоки RUP, давайте-ка попробуйте ответить на пункты автора топика:

1. Закрепощенность: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект ""Снежного комма"", затрагивающие другие компоненты системы.
проектирование только сверху вниз приводит к подобному эффекту быстрее всего

2. Неустойчивость: в результате осуществляемых изменений система разрушается в тех местах, которые не имеют непостредственного отношения к изменяемуму компоненту
это следствие из пред.п.

3. Неподвижность:достаточно трудно разделить систему на компоненты, которые могли бы повторно использоваться в других системах
Для того, чтобы компоненты можно было использовать повторно, они должны быть заранее спроектированы с учетом последующего повторного использования. Обычно это означает дополнительные трудозатраты по реализации дополнительной функциональности сверх предписанной в рамках конкретной системы (иногда плюс 50%-100% работы, что окупается только в случае заведомого нацеливания на повторное применение).
Кстати, мне очень импонирует компонентный подход в разработке. К изолированному компоненту можно применять самостоятельно стоящий RUP, компонент необходимо разрабатывать вне рамок какой-то системы, а именно как самодостаточный имеющий простой интерфейс модуль .

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

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

6. Неоправданные повторения: проект включает повторяющиеся структуры, которые могут унифицироваться с применение простой абстракции
Опять же, речь о том, чтобы не проектировать тупо сверху вниз, а создавать и нарабатывать библиотеки, типовые интерфейсы объектов и реализовать типовые операции в них. Далее при проектировании необходимо не столько разрабатывать каждую сущность с 0-ля и смотреть что получится, сколько смотреть - а что уже есть, и пытаться "подгонять" целевую систему под некоторые наработки. (почти всегда это идет на пользу любой прикладной системе)

7. Неопределенность : проект трудно читать и понимать. Недостаточно четко выражено содержимое проекта."
Это зависит от организации и артефактов. Тут может помочь применение хоть какой-нибудь методологии или же просто здравого смысла.

Не даст ли кто оригинальных рекомендаций, как не сделать вонючий проект, а сделать нечто красивое?
Надо ставить производство ПО на поток. Закладывать в компоненты больше, чем требуется в конкретном бизнесс-приложении, не жалеть времени на то самое среднее звено. Стремиться к максимальной простоте на самом верхнем уровне (т.е. если по смыслу надо сделать A=B+C, то желательно, чтобы в коде именно так и было, а не нечто типа:
- заблокировать А, обработать ошибки
- заблокировать B, опять обработать ошибки
- С...
- провести операцию
- записать в журнал
- снять блокировки
- и т.д. и т.п.)

Мне импонируют языки с возможностью переопределния операторов (С++, С#), ибо читабельность кода и намерения программистов наиболее наглядны в этом случае.

2 funikovyuri

не надо передергивать

в момент работы программиста над компонентом увеличение числа функций на 50% приведет к увеличению потраченного времени дай бог на 10%-20%

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

налицо экономия

опять же, повторюсь, речь идет только о той ситуации, когда производство ПО поставлено на поток и вопрос повторного использования - не праздный


-----------
в принципе, можно привести пример:

в программе используется масса маленьких всплывающих диалогов, состав диалога - надпись и набор радио-кнопок для выбора

было принято вполне разумное решение не плодить эти диалоги а написать нечто типа ф-ии, которая берет параметры (как аргумент или ссылку на структурку-описатель, тут мы используем перегрузку сигнатур), и возвращает результат.

вполне грамотно...
однако, сверх нормы добавили еще пару перезгрузок этой ф-ии, которая позволяет в этих диалогах (в виде baloon) добавлять еще и чек-боксы и иконку.

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

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