Добрый день!
В мозгу потенциального заказчика крепко засела мысль что разрабатывать систему нужно именно посредством продуктов IBM Rational.  Мы начали копаться с RequisitePro, Software Architect.  Написали требования, описали актеров, преценденты использования,  сделали  UML диаграммы, описали классы. Показали программистам - реакция была такова, что для реального проекта вся эта музыка не годится. В лучшем случае Rational нужен только для рисования "картинок", для более наглядного описания системы, но для программистов это имеет мало пользы.
Речь идет о полноценной системе (не web приложение, не интернет магазин). Насколько я понимаю Rational широко используется для создания интернет магазинов.
Мне показалось, что сейчас эти инструментарии любят использовать всяческие консалтинговые организации, чтобы расписать бизнес процессы предприятия клиента, однако они никогда не занимаются разработкой ПО.

В связи с этим возник вопрос: есть ли реальные проекты, реализованные на инструментальных средствах  IBM Rational или это фантастика? Учебные проекты разработанные в институтах в рассчет не идут - это все мулькина грамота, ничего не имеющая с реальными разработками ПО.

Если возможно приведите примеры системы (какие задачи решает) и в каком объеме был использован Rational.  Была ли реальная польза  от этого? 
Спасибо за внимание

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

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

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

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

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

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

Хочется еще добавить, что моделирование ради моделирования - плохая затея. Если Вы не видете плюсы, то рано еще его использовать. А вообще моделирование (хотябы в картинках) решает проблему представления сложного - проще, в виде модели. Мы же еще со школы рисовали задачки по математике, чтобы понять условие...

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

А для начала, просто для себя сделать несколько моделей, чтобы научиться их правильно делать.

В связи с этим возник вопрос: есть ли реальные проекты, реализованные на инструментальных средствах  IBM Rational или это фантастика? Учебные проекты разработанные в институтах в рассчет не идут - это все мулькина грамота, ничего не имеющая с реальными разработками ПО.

Вообще есть и немало. Если кто-то чего-то не умеет, значит ли что это неполезно и бессмысленно?
Однако сами uml инструментальщики с большой любовью используют свои же средства для создания самого себя. Почитайте статьи на Telelogic на других сайтах разработчиков UML
Это принцип не нов.

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

Вообще есть и немало.

Можете в таком случае назвать хотябы десять самых интересных с Вашей точки зрения?

Можете в таком случае назвать хотябы десять самых интересных с Вашей точки зрения?

Да любой большой западный продукт разрабатывается с применением средств моделирования и управления требованиями.
Вот пример компаний:
CitiPower
Daimler TUP
Daimler VSP
Merrill Lynch    

Вот тут мы как раз пытаемся выявить количественные (осязаемые) преимущества от процесса управления требованиями:
http://www.uml2.ru/forum/index.php?topic=779.0

Можете в таком случае назвать хотябы десять самых интересных с Вашей точки зрения?

Примеры именно на IBM Rational назвать не могу, хотя BOLD for Delphi (с использование RR еще не IBMовской правда), я наверное не внимательно читал, Вас по видимому интересовали именно реализации с IBM Rational, а не вообще с применением UML тулов?

Добрый день!
В мозгу потенциального заказчика крепко засела мысль что разрабатывать систему нужно именно посредством продуктов IBM Rational. Мы начали копаться с RequisitePro, Software Architect.

А ВЫ — это кто? Аналитики, директора, заказчики от бизнеса, технические писатели?

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

Ничего не понимаю. Вы зафиксировали требования, создали аналитические модели, сделали проектные модели — выполнили архитектурно-аналитическую работу. Почему «программисты» не участвовали в этих процессах?

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

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

Речь идет о полноценной системе (не web приложение, не интернет магазин).

Очень странная фраза. Системы бывают разного класса и интернет-магазин — вполне так себе система.

Насколько я понимаю Rational широко используется для создания интернет магазинов.

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

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

А мне из моего опыта видится, что консалтинговые компании предпочитают использовать ARIS, PowerPoint, Visio, карты KPI (BSC) и прочие бизнес-диаграммы (типа Ишикавы, Concept Map, Mind Map). Что дальше?

В связи с этим возник вопрос: есть ли реальные проекты, реализованные на инструментальных средствах  IBM Rational или это фантастика?

А каким ещё образом можно создавать аналитическую, проектную и рабочую документацию для современных проектов по разработке промышленных ИС и ПО? Блок-схемами на бумаге?

Если возможно приведите примеры системы (какие задачи решает) и в каком объеме был использован Rational. Была ли реальная польза от этого?

Rational Requisite Pro решает задачу организации хранения, доступа и управления требованиями. В больших софтверных проектах, например таких, какие делает Luxoft, число требований достигает нескольких тысяч. Rational Rose решает задачу фиксации проектных решений и их коммуникации участникам процесса разработки и кодогенерации. Rational SoDa решает задачу генерации проектной документации именно как документов.