Здравствуйте!
В своей организации мы планируем пилот-проект по внедрению RUP (начать хотим с управления требованиями). В настоящее время мы активно используем MS Source Safe. Rational предлагает для управления версиями Clear Case. Т.к. с этим продуктом (Clear Case) плотно не работали, то возникает желание использовать MS Source Safe вместо Clear Case. Поделитесь пожайлуста, есть ли такая возможность и возможные негативные последствия такого выбора (например, потеря в функциональности при работе с Requisite Pro и т.п.)

Не обладая существенным опытом работы с MSSS тем не менее возьму на себя смелость поделиться мнением о RUP и соответствующих продуктах от Rational, поскольку практически вся их линейка у нас ипользуется.

1. Насколько мне известно (по крайней мере в средних проектах из 20-30 человек) упомянутые продукты вполне можно использовать без какой либо интеграции и таким образом используемая система контроля версий не оказывает влияния на остальные подсистемы

2. Вообще говоря RUP отнюдь не подразумевает обязательного использования продуктов Rational, которые вообще говоря дороги и требуют качественного администрирования. Имеются существенны основания быть осторожными в переходе под RUP, поскольку его серьезное внедрение в масштабах целой компании обходться дорого в терминах и денег и усилий, и иногда себя не окупает.

3 Стоит иметь в виду текущий интерес индустрии к Agile методологиям и определенные сомнения в будущей судьбе монстров калибра RUP (см например http://www.sdmagazine.com)

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

ND>3 Стоит иметь в виду текущий интерес индустрии к Agile методологиям и определенные сомнения в будущей судьбе монстров калибра RUP (см например http://www.sdmagazine.com)

Это что за зверь такой Agile?
Есть реальная альтернатива RUP?

Здравствуйте Александр,

Agile методологиями последнее время называют разного рода методологии (наиболее известная пожалуй XP) направленные на (существенное) упрощение процедур разработки по контрасту с тем же RUP. Собственно замечание касалось того что не стоит СЛИШКОМ досконально внедрять RUP, предпочтительно выбрать некий промежуточный вариант как оно часто в реальности и получается.

Скажем минимальный набор документов типа Vision, Glossary,Software Requirement Specifications, Use cases +UML диаграммы по необходимости вполне покрывает основные запросы по документированию. Фактически RUP есть опорная модель на которую хорошо ориентироваться в случае спорных моментов, но вообще говоря последнее время гуру методологий говорят больше о том что полное внедрение RUP настолько тяжело и дорого что для небольших команд не рационально и вообще все это (очень сложные CASE и методологии) выходит из моды.

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

ND>Скажем минимальный набор документов типа Vision, Glossary,Software Requirement Specifications, Use cases +UML диаграммы по необходимости вполне покрывает основные запросы по документированию. Фактически RUP есть опорная модель на которую хорошо ориентироваться в случае спорных моментов, но вообще говоря последнее время гуру методологий говорят больше о том что полное внедрение RUP настолько тяжело и дорого что для небольших команд не рационально и вообще все это (очень сложные CASE и методологии) выходит из моды.

"Полное внедрение RUP" это что такое?
Мне кажется, что можно говорить только об адаптации RUP (как общего подхода к разработке ПО) к нуждам конкретной организации. Например, можно ограничиться только бизнес-моделированием.

Насчет дороговизны и по деньгам и по ресурсам — согласен. Но весь вопрос в том какую систему мы хотим на выходе — дешевую или работающую?

Здравствуйте Александр,

Имелась в виду ситуация, когда весь процесс разработки упорядычевается в соответствии с RUP. Это влечет за собой определенное изменение бизнес-процессов, а зачастую и существенный сдвиг в мировосприятии даже программеров: Use-Case driven разработка и упор на анализ/проектирование даются не легко, не говоря о том что влекут за собой отказ от понятия "должно быть сделано вчера". Software engineering вообще имеет много манагерских аспектов и соответственно требует достаточно серьезного сдвига их мировоззрения — в общем все уходит далеко от тривиального кодерства со всеми вытекающими.

Дешевая и работающая не всегда ортогональны, тем более что эти категории не имеют смысла без численной оценки, а обстоятельства редко позволяют выбирать.
В общем следует отметить что профессионалам RUP знать следует (ИМХО RUP/UML/Design patterns это библия) а вот вопрос официального внедерения в компании менее очевиден и подпадает под юрисдикцию CTO/манагеров.

Здравствуйте Ув. Nikita,

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

Здравствуйте

Рискуя разочаровать Вас скажу что я не являюсь ни аналитиком ни архитектором. Я просто девелопер уделяющий достаточное внимание вопросам проектирования и имею удовольствие работать в компании где могу наблюдать все это в реальности.

Коротким ответом на вопрос является: RUP. Будучи результатом объединения усилий группы ведущих методологов и их методологий он несет в себе большое количество концентрированной мудрости (притом качественно оформленной) и само знакомство с документацией по нему очень способствовует пониманию современного состояния software engineering'а.

Для контраста можно посмотреть на XP(см напр http://www.extremeprogramming.org/). Оно сильно альтернативно к RUP но за ним стоят тоже отнюдь не последние в нашем бизнесе люди.

Как-то я видел такую статистику: 37% разработчиков используют Clear Case, 18% PVCS и всего 8% VSS. На счёт PVCS сказать могу очень мало — я с ней почти не работал. А вот две остальных сравнить (точнее, найти различия) попытаюсь.

1. CC продвигается не просто как средство для совместного хранения исходников, но как средство управления версиями. Наряду с RUP есть методолгия UCM (Unified Change Management), которую и поддерживает CC. Причина или следствие, но средства контроля версий в CC гораздо более развиты, чем в VSS. Например, можно разветвить текущую версию проекта на две, работа над которыми ведётся параллельно (известная схема: фирма выпустила готовый продукт, и начала штамповать патчи к нему; тем временем ведётся работа и над следующей "более продвинутой" версией продукта, включаются новые фичи и т.п.). При необходимости версии можно соединять воедино (если нарисовать, то получим ромбик, в кадой вершине которого по версии). В отличие от VSS, можно наплодить много разных версий и запутаться... Чтобы не запутаться, есть удобная программка для просмотра иерархии всего генеалогического дерева проекта (в форме графа).

2. В CC используется модель VOB/View, которая, по моему мнению, вовсе не является очевидной, но надуманной. Можно было бы и упростить.

3. Как-то был такой случай: в VSS выложили большое число (1000) маленьких файлов (по 1000 байт) в одну папку, и VSS выдал предупреждение что-то типа "Windows может заглючить от такого количества маленьких файлов". (Проверять это мы тогда не стали.) За CC такого замечено не было.

4. При использовании VSS на файл-сервере требуется вего-навсего завести папку, расшаренную по сети на чтение/запись, создать там базу можно с любого другого компа. В CC же всё придётся поставить на файл-сервер ClearCase-server (он ещё и Windows NT захочет). Вообще администрировать CC обойдётся дороже, чем VSS, а времени на обучение всем возможностям CC потребуется значительно больше. Вообще за использование продуктов Rational придётся платить много и дважды: первый раз — сразу и в магазине, второй раз — каждый месяц и администриратору:(

5. CC можно управлять с помощью контекстных меню прямо из Windows Explorer!

6. У нас в конторе стоит VSS, и я считаю, что он вполне нам подходит.