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

NS>И ГЛАВНОЕ. Почему-то никто об этом не говорил.
NS>Очень хорошая интеграция с программами разработки ПО и с системами поддержки разработки ПО.
NS>Естественно каждая со своими. Т.е. StartTeam с CaliberRM и JBuilder, а ClearCase с requisitePro, ClearQuest и Visual Studio NET (с последним интеграция очень хороша, попробуйте сразу поймете, что хоть это и не главное но очень важное преимущество).

Вы немного напутали в плане интеграции.

Было сказано что интеграция инструментов — это очень важно. Я это полностью поддерживаю и считаю это большим приемуществом компании Rational.
Коротко об интеграции инструментов:
1. ClearQuest — RequisitePro
Если применять ClearQuest в качестве "корзины" запросов, то в дальнейшем данные запросы можно связать с требованиями в RequisitePro.

2. RequisitePro — ClearQuest
Проработанные требования могут быть связаны с заданиями в ClearQuest. При помощи ClearQuest произходит непосредственное управление процессом внесения изменений в проект, т.е. реализацией требований.

3. ClearQuest — ClearCase
Здесь все просто. Если вы решите использовать данный вид интеграции, вы сможете связать изменения, производимые в исходниках (версии элементов) с заданиями, которые назначены вам в ClearQuest.

4. ClearCase — Visual Studio
Здесь все понятно. ClearCase интегрируется со средством разработки. Кстати существует также интеграция и для борландовских инструментов. Проверено, вирусов нет . Просто автор предыдущего поста немного перепутал ClearCase с ClearQuest-ом, и я решил исправить эту ошибку.

5. ClearQuest — TestManager
В двух словах: тестскрипт выявил ошибку — в ClearQuest автоматически создается запись об ошибке с подробнейшим ее описанием.

Я могу еще много рассказать о всех существующих видах интеграции, но лучше просто перечислю
ClearQuest — MS Project
RequisitePro — MS Project
TestManager — RequisitePro
Средства тестирования — MSDEV
А сколько своих интеграций можно написать
А еще ни слова не было сказано об инструменте генерации документов и отчетов
А это Crystal Reports и SoDA, которая проинтегрирована практически со всеми средствами Rational.

Конечно же это не означает, что использовать нужно все инструменты и все виды интеграции. Это сродни точке зрения о внедрении некоторого процесса разработки. Зачем это делать, если можно взять нужную часть, изменить ее под собственные нужны и использовать.
Наша компания конечно же не использует ВСЕ эти способы. По мере необходимости мы применяем те или иные. Бывает даже, что некоторую интеграцию мы используем в фиксированный рпомежуток времени для решения определенных организационных проблем.
Тоже самое с инструментами. При помощи инструментов можно упростить, улучшить качество процесса разработки. Думать что инструмент и процесс — одно и тоже — заблуждение.

Могу немного рассказать о нашей компании. Изначально в качестве средства управления версиями мы использовали .... зашаренную папку .
Потом перешли на SourceSafe. Долгое время мы работали с этим замечательным инструментом. Но в определенный момент нам понадобилась возможность "параллельной разработки". По рекомендации был выбран ClearCase. Так до сих пор на нем и живем. К сожалению у меня нет опыта использования других инструментов, и я не могу чтолибо добавить по этому поводу. ClearCase нас полностью удовлетворяет. Возможно мы перейдем на другой инструментарий. Если это случится, то по причине высокой цены Rational.

А сейчас я буду злиться по поводу всего прочитанного о "параллельной разработке"
Во первых не соглашусь с meridian. Необходимость в параллельной разработке возникает не по причине большого количества разработчиков. На мой взгляд причины могут быть следующие:
1. Несколько разработчиков знакомо с одним участком кода, и способны работать с ним. Этот принцип широко используется в концепции Экстремального Программирования.
2. Разработчику необходимо проделать некоторую исследовательскую работу, которая не зависит от изменений, которые будут параллельно происходит в основном потоке проекта. Это скорее даже будет мешать (постоянно мерджить текущие наработки, хотя они никак не влияют на суть собственной работы).
3. Время между стабильными версиями проекта существенное. Возможность отбренчится от некоторого бейзлайна — очень удобна.

Во вторых я в принципе не согласен с человеком, утверждающем, что параллельная разработки — это зло и бить нужно архитекторов. Просто бред. Причины смотрите выше. Архитектура и параллельная разработки. В упор не вижу связи. Без условно, архитектура вполне может быть НЕГАТИВНОЙ ПРИЧИНОЙ необходимости одновременной работы нескольких РАЗРАБОТЧИКОВ с одним ФАЙЛОМ исходного текста. Но это не есть параллельная разработки!