1

ПО Аналитика / Re: прототипирование GUI и Pencil Project

« : 31 Марта 2011, 00:24:08 »

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

Однозначно удобное и практичное средство (GUI Design Studio).
Подтверждаю, что если подробненько описать элементы - то на прототипе можно и испытания пройти. Не все пользователи сразу подвох понимают.
Плюсы
 - простота и надежность в установке и работе;
 - интегрировано c SVN (командная разработка);
 - никакой зависимости от серверов и репозитариев. Папку скопировал - и работай дома.
 - неплохая генерилка документации, только перевод придется править (особенно поразила фраза "Используется мимо").
 - достаточный набор базовых элементов, возможность определение типовых элементов и их повторного использования;
 - возможность вносить изменения в конкретное использование типового компонента без модификации первоисточника.
 - наличие просмотрщика (это для заказчика, пусть радуется).
и еще много.

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

Короче. Используем.
Одна из последних претензий заказчика (на испытаниях)  было то,  реальный софт несколько отличался от прототипа (он в его разработке участвовал).
Вот в этом то и недостаток. Пользователь слишком рано поймет, что ему нужно, и туфту сдать будет очень сложно. Требования становятся конкретными, даже черезчур.

PS. Примеры приложить не могу, ввиду специфики проекта.

2

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 21:38:53 »

... Предусмотрена ли в UML вообще, в CASE-системах в частности, и в EA в частности частности, нотация для явного отображения таких связей? Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?
......

В PowerDesigner данное отношение поддерживается явно. Даже по умолчанию у прецедента есть вкладка, предназначенная для ведения связей с реализационными классами и интерфейсами (см. приложенный рисунок).

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

В последующем, при анализе зависимостей (через матрицы или как показано на рисунке), всегда видно, сколько будет стоить. изменение.

В дополнение к связи с классами, у нас используется и связи с объектами БД и некоторыми другими элементами (собственное расширение).

3

Консалтинг и Внедрение / Re: Документы при приемке ПО

« : 07 Октября 2009, 00:59:02 »

Совершенно нормальная ситуация.
Когда есть возможность, то в договорах стараемся полностью вычищать все ссылки на ГОСТ (это мы как разработчики).
Выше было правильно сказано, что ссылаемся на "(super-extra-UMgile-concurrent-extreme-development)".
Всякая документация, которую нужно отдать заказчику -  затраты.

Теперь по сути.

Смотрим ТЗ и договор.

В договоре. Нужно уточнить, кто является правообладателем (т.е. собственником исходного кода). Если разработчик - то выбить можно только эксплуатационную документацию. Ни о каких структурах БД и т.д. и т.п. речи быть не может.

Если в ТЗ документации нет, то возможны варианты:
1) Дозаказать документацию за отдельные деньги (надо понимать, что разработчик зафиксировал свою прибыль и в минус идти не будет ни при каких условиях). Если сумма вменяемая - это лучший вариант.
2) Если идет этап сопровождения, по отдельным ежегодным договорам, то в очередной договор можно включить и поставку доки. Суть - шантаж - нет доки, нет сопровождения. Шансы есть, но все зависит от ситуации (у кого нервы крепче).

Если удалость договориться о доработке доки, то не забудьте определить критерии качества затребованных документов. Просто перечень документов  и ссылка на ГОСТ – МАЛО, нужно раскрыть, что и в каком виде должно быть в каждом пункте.


Просто для справки.
Во вложении некоторая сводная таблица по составу ГОСТовых документов, которые передаются заказчику по окончанию разработки(минимум и максимум).

Кратенько состав документов на этапе разработки излагается в РД 50-34.698-90.

4

Варианты Использования (Use Case) / Re: Многозвенная архитектура - как рисовать много Use-cases?

« : 01 Октября 2009, 09:25:18 »

На счет символов ГИС и тп....
Андо, я когда-то вам говорил, что ВИ там совсем не много, но меня никто не слушал ...

И правильно сделали. ...
Если говорить про Word, то в нем тоже мало ВИ, создать документ да распечатать документ. Все заморочки со шрифтами, стилями, шаблонами и еще черте знает с чем - все ограничения, отображение и логика. Интересно было бы посмотреть постановку задачи на разработку конкурента Word.

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

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

Действительно, архитектурные проблемы есть. Сменили архитектуру - их стало еще больше. Почему сменили - отдельный разговор.
520 страниц - это " настольная книжка" заказчика. Это не результат работы аналитиков. Мы ее наследуем, т.к. переучивать тысячи специалистов под наши идеи заказчик не будет. Требования заказчика - закон.
Зачем заказчику нужна карта и что на ней отображать - ясно. Какое место ГИС занимает в структуре системы - яcно. Остается маленький вопросик - нужно чуть чуть кода написать, для чего написать дискретные спецификации и передать их в отдел разработки. С моей точки зрения, такой точкой дискретизации и является прецедент. Конечно же, в большей степени он ориентирован на точку зрения пользователя, но эту точку зрения надо сделать «осязаемой», «понятной», «выровненной».

Теперь по теме.

Структурировать по пакетам – однозначно.
Кроме того, естественным способом группировки является диаграмма. Если следовать рекомендациям, что на одно диаграмме – от 5 до 9 элементов, то на 300 ВИ получится около 50 диаграмм, что все одно много и они так же должны быть разнесены по пакетам. Составить хорошую диаграмму  - это, к сожалению, искусство.

Для описания системы нами используется «структурно-объектный» (SADT+ООА) подход.
Сначала контекст, основные бизнес-области, основные БП, их декомпозиция. 1-3 ВИ подкладываются под листовую функцию (шаг БП). Таким образом получается достаточно естественная структура «пакетов».
Данный подход в наибольшей степени подходит для класса т.н. корпоративных систем. Для описания функциональности маршрутизатора или игрушки для мобильного телефона он подходит в меньшей степени.

5

Варианты Использования (Use Case) / Re: Многозвенная архитектура - как рисовать много Use-cases?

« : 30 Сентября 2009, 00:27:41 »

что такого необычного и уникального в вашей системе, что ей понадобилось более 300 (!) кнопок (как вы пишете), за каждой из которых "следует" уникальный во всём use case? это система управления ядерным реактором?

Странное у Вас представление о сложной системе.

На днях пришлось воспользоваться лет 5 назад разработанным редактором символов для ГИС.

Время прошло много, все уже забылось, и когда я туда заглянул, то мое настроение резко ухудшилось (работа была срочная и критическая).  Боюсь обмануть в количестве, но 200 вариантов использования есть только в редакторе символов, а сколькое еще реализовано собственно в клиентской части ГИС (автономная работа) + при отображении реальной информации из базы + взаимодействие с сервером приложений.

Для пояснения. Книжка с кратким перечнем символов и описанием основных правил их отображения занимает 520стр (в новой редакции). Почти половина символов имеет особенности в отображении, формировании подписи, при наложениях, при групповом и одиночном применении, изменение масштаба, полилинии, сплайны и тд. и т.п. Вариант использования с названием "создание символа для отображения объекта на картфоне" явная профанация.

Разрабатывали 2 человека 2 года (не только редактор, его они из-за лени написали). А. Шемис - передай им привет, их систему вчера Медведеву показывали.

6

Обсуждение статей / Re: Как я согласовываю документы

« : 23 Сентября 2009, 00:14:01 »

Личный опыт.
Наплевательское отношение к согласованию документов проявляется в основном в 2 случаях:
- 1. документ маловажный или все решено уже заранее. Тогда возникает вопрос - зачем нужно было тратить уйму времени на его разработку? Рвать себе ... и потом расстраиваться???. Ошибочка.
- 2. Тебе безусловно доверяют. Соответственно никто и ничем не озабочен. "Он все сделает...". Тогда надо выкладываться на все 100. Делать как надо. А когда дойдет до согласования, то надо понимать, что многие будут читать документ впервые, время на его прочнение они себе заплапнировать не удосужились. Т.е. как и написано, напоминать. предоставлять текст заранее,  составить очередность, сделать выписки и т.д. и все это для того, чтоб дело не затягивать.
Вывод - расстраиваться не надо, это просто жизнь такая.

7

ПО Аналитика / Re: Матрица реквизитов в разных системах

« : 17 Сентября 2009, 23:56:09 »

На трех объектах с тремя атрибутами иллюстрация понятна. Как будет выглядеть картинка, когда атрибутов 1000 и по 700 из них встречаются в 15 системах.

ХА!!!. Будет матрица строк на 1000 и столбцов на 15 (в минимуме, если не делить на подсистемы,  компоненты).На то она и матрица.

PD, в данном случае, на мой взгляд целесообразнее использовать по прямому назначению - рисовать объектную модель. Т.е. 1000 атрибутов разойдется по объектам, а не по системам. При этом нужно учесть, что в каждой системе модель данных все-таки своя и отличается кардинально.

Про PD – в нем ОЧЕНЬ много моделей и возможностей.  Ваш случай – частный

Из личного опыта. Не говорю, что идеально.
Нужно иметь логическую модель, из которой генерится (изменяется)  базовая физическая модель, на основе которой сгенерированы модели конкретных объектов (эталоны, по нашему).
Изменения (особенности) учитываются на всех уровнях .Логика - новые требования и изменения, базовая физическая - как должно быть, частные модели - учитывают особенности каждого объекта (имеется ввиду ОА, или системы).
Для исключения дублирования в части атрибутов используется механизм ReplicatedObject.
Если короче - то "Тыкая" в системе на 1 элемент (например, бизнес функцию), можно выйти и на колонку и на атрибут и на систему и на класс и на форму и на изначальное требование.
При необходимости, создается любая матрица зависимостей (я еще раз подчеркиваю – практически любая, между ЛЮБЫМИ элементами, в том числе и вычисляемым транзитивным путем). Матриц можно сделать сколько угодно, и они все будут актуальными.
  Очень важно понимать, на какой вопрос нужен ответ. Соответственно, в ходе разработки, сопровождения, тестирования, т.е. постоянно, нужно поддерживать актуальность данных.
У нас 26 «объектов», 3 типа СУБД, 2 унаследованные системы, реквизитов (по вчерашним селектам, с учетом суррогатов)– 7876 (это только в базе, без учета особенностей в GUI, Hibernate и т.д.) Есть эталоны каждого объекта, всегда знаем, где, что отличается, что надо свести, что оставить.
Если честно – не успеваем все отслеживать. Частный бизнес на людях экономит, но снежный ком уже нарастает.
 

Из подобных тому, что на скриншоте с некоторыми натяжками подойдут:
- IBM Rational RequisitePro (как раз работа с матрицей)
- Sparx Systems Enterprise Architect (инструмент, подобный PD) и RaQuest (работа с матрицей, анализ влияния)
А так из подручных средств для обработки более удобен MS Access, но для ввода - не фонтан.

Именно с натяжкой.
Из личного опыта использования связки requsite+ WebSphere Business modeler + RSA.
Лучше сразу повеситься. По указанию начальства внедрял полгода. Всех заставлял использовать. Потом плюнул и выбрал с нуля PD.
Ранее для ООМ использовал Rose +requsitе. Для маленьких задачек в маленьком (8 чел) коллективе. Кое-как жили. С Soda – геморрой был страшный.

Что такое мапирование?

Про маппинг.  На рисунке простой пример из документации.
Т.е. сопоставление одно объекта другому. Если есть возможность определения и правил трансформации – то вообще замечательно.

Кстати, достаточно хорошие матрицы были в Oracle Designer. Я его долго использовал. Но, по моему,  это уже мертвый продукт.

8

Идеи и мозговой штурм / Re: Специфика работы с госзаказчиком. Неужели, у всех так?

« : 17 Сентября 2009, 02:28:08 »

По опыту происходит так.
 Госструктуры - безмерно богатые. Денег у них - ГОРЫ. Кому они достаются? Правильно, своим теще-зяте-офшорам.

НО. Приходит время что-то показать. Тогда ОФШОРЫ находят ПОДРЯДЧИКА (за как можно меньшие деньги, но с максимальными по времени и объемам результатами).

Так вот.
1. Если взялись за такое дело - то ВАША проблема решить проблемы Заказчика (в т.ч. и ОФШОРА). Если есть сомнения, нет опыта - не беритесь, обдерут как липку. НО если уж взялись - решайте проблемы. Если У вас маленькая компания и вы собираетесь оставаться на этом рынке и присосаться к рекам денег - делать нужно КАЧЕСТВЕННО. Исключение - только для приближенных ОФШОРОВ.
2. Терминология, документация - это святое. И не только в Госструктурах.
3. Обтекаемость формулировок - это очень опасная штука. Если вы новичок, и у Вас в ТЗ сферический конь - то есть очень большой шанс не получить оплату по контракту. Если при сдаче допускается "Смягчение формулировок" - то значит, все схвачено.
4. Про поиски "заинтересованного человека" - так это всеобщая проблема. Контракт заключается менеджментом, а обследовать и внедрять приходится на складе. Найти такого человек в любом проекте - 50% успеха.
5. Бумажка (протокол встречи, совещания и т.д.) - это не тяжкая обязанность, а правило хорошего тона, показатель профессионализма. Именно задача аналитика этим и заниматься. Заказчики и пользователи должны чувствовать обратную связь (оформленную красиво, грамотно, понятно для читателя, именно в его терминологии). Кроме того  - такие бумажки (с подписями), это ваша ИНДУЛЬГЕНЦИЯ.
Вывод. Вне зависимости от ситуации, с кем и на кого работаете, делайте свою работу качественно. Повышайте свою квалификацию. Вы же наемный работник и вам придется себя еще не раз продавать.

9

ПО Аналитика / Re: Матрица реквизитов в разных системах

« : 17 Сентября 2009, 01:22:55 »

Прилагается пример из картинок. Результат - автоматическая матрица трассировкки.
В принципе, можно строить любые зависисмости (матрицы) между любыми типами элементов.
Средство - PD 15.1.

10

Для всех / Re: Вопрос из теста. Интересно, как бы вы на него ответили.

« : 11 Сентября 2009, 22:36:54 »

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

Вопрос значительно усложнится, если уточнить, кто является общим предком ящерицы и птицы (либо птицы и дракона, либо дракона и ящерицы, либо сразу всех троих), а так же в какой последовательности они эволюционировали и получали те или иные свойства.

У кого какие мысли???

11

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 04 Сентября 2009, 01:23:45 »

Виталий, так Jira интегрируется с тонким клиентом?
С толстым клиентом проджекта кто только не интегрируется.
Лично пробовал с Requisite, Sybase и Jira (но тогда только в триале).
А вот с тонким клиентом - не слышал и не видел (чтоб через web access).

Еще раз проблема и критерий выбора средства управления требованиями.
План проекта опубликован на Project Server. Задачу в план можно включить только подав предложение через web интерфейс (кто пробовал это глюкавище - тот поймет).
Средство управления требованиями должно формировать предложение в план проекта и отслеживать состояние его рассмотрения (т.е. после утверждения предложения в плане проекта устанавливать у требования признак «Утверждено к исполнению»).

Средству управления требованиями, которое может проделывать такой фокус, смело можно ставить повышающий  коэфф. не менее 1.5.

По поводу собственно Jira.
Connector позволяет в MS Project импортировать записи из Jira.
Но у нас: -  руководителю проекта запрещено смотреть в Jira, нам нельзя напрямую использовать файл Project. Т.е. интеграции нет.

Если требования описаны просто - т.е. в виде набора дискретных утверждений «Система должна …»/ «не должна», то да, Jira подходит. Только интерфейс корявый, лично я не перевариваю. Уже долго пользуемся как багописалкой, но никак не могу привыкнуть
Для более формализованных требований – не подходит.
CleaQuest +Requiste - тогда уж намного лучше .

12

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 01 Сентября 2009, 01:18:15 »

Простите, совсем забыл про планирование.
Есть плагин для проджекта. Работает.
Но вопрос заключается в том, что он работает только с "Толстым клиентом проджекта". Т.е. может интегрировать требования в локальный или сетевой mpp файл.

У нас же ситуация следующая.
Развернут project server. Проектом "рулит" руководитель проекта.
Начльники отделов разработки и проектирования могут только "подавать предложения" в план проекта.
Угадайте как? Правильно, через project web access.

А вот с этой штукой (project web access) Powerdesigner отказывается интегрироваться.

Может у кого есть опыт того, как и какое средство управления требованиями интегрировать с тонким клиентом MS Project с учетом того, что сформированные требования это только предложения, которые будут включаться в план, превращаться в групповую задачу и т.д.

13

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 01 Сентября 2009, 01:05:32 »

Добрый вечер всем.

1. Сначала ответ Виталию.
Виталий: "Ну не люблю я повер дезигнер   - он более для программистов, имхо."

Действительно так.
Однако самое забавное заключаетсяв том, что в большинстве компаний аналитики работают именно на программистов.
Именно программисты основные "клиенты" и "работодатели" для программистов.
Соответственно, их задачей и является перевод текстовых выражений "хотелок" в формальные спецификации, на формальном языке, который легко усвояется программистами, котрые могут работать по очреди на 4-5 проектах.
Если даже аналитик находится на стороне заказчика, то чем точнее и формальнее он выразит свои требования, тем меньше у него риск быть явно обманутым или получить "несколько другой" продукт.

Вывод - чем ближе средство управления требованими к народу, тем лучше. Идеал - кодогенерация + автотестирование. Надиктовал требование, а на выходе идеальный код.

2. Теперь по сути вопросов.
"1. Есть ли возможность связи с инструментами планирования и тестирования?"

2.1 - Тестированием пока сам не пользовался, но чуть интересовался:
 - хорошо тестируется БД. Этим PD отличается сильно в лучшую сторону. Генераторы, профили, автозаполнение, проверка правил  и т.д. и т.п.
 - есть и связь со средствами UnitTesting, в частности под платформу .net20, тестирования web-services и прочее по мелочи. Но такое ощущение, что это один из недостатков, который я забыл перечислить. Не складывается впечатления комплексного подхода. Что может, то и тестирует.

"2. Как организована совместная работа?"
2.2 Через репозитарий, который находится в базе.

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

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

Для пользователей, которым нужно только смотреть или получать отчеты, оформлять подписку на изменение элементов присутствует Repository web Browser (правда нам его удалось запустить только под postgres, под оракл - не запускается зараза.
Очень полезно именно подписка - программист отвечает за модуль, на который есть спецификации и требования (по трассировке). Подписывается на их изменения. Ему сообщается, о наличии в них изменений. К выходу очередных версий спецификации - он уже морально готов.
Недостаток – нельзя в on-line править в базе. Может это и теоретически неправильно, но такую возможность крайне уважаю (Oracle Designer помер – а жаль). В процессе работы над итерацией – версии не сильно нужны, все нестабильно, быстро меняется. Вот в Oracle Designer была такая фича, что если есть общий  элемент модели на диаграмме, то если мой коллега изменил чтой-то в общем элементе, он у меня в момент отметился как измененный и всегда спрашивал, что дальше будем делать. Очень, очень полезная штука.  В PD в online изменяется только статусы проекта и модели. Маловато.

"3. Как работает версионность? Я имею в виду закомитить все требования для версии ПО 1.0, потом что-то менять, закомитить для версии 1.1 и сравнить требования для 1 и 1.1."
То, что описывается в данном вопросе есть.
Введены понятия как версии, так и ветки, baseline и т.д. (правда определение baseline специфичное).
Чтоб долго не писать, попробую приложить картинку из доки.

Лично пользуемся только версионностью (у пока еще 3 года будет только линейная разработка по набору функционала).
Сравнение можно делать любой версии с любой.  Прецедент был - разбор полетов, спор и ругань. Пришлось сравнить версию 12 с версией 96 (это версии спецификаций, благо  не софта). Разница во времени - 14 месяцев. Заняло 5 минут.
По отдельному элементу доступны все его свойства во всех версиях.
Отличительная особенность PD в том, что он автоматически следит за версиями каждого элемента в отдельности (в автоматическом режиме). За счет чего - значительно сокращается объем БД.

14

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 28 Августа 2009, 00:41:47 »

Ответ на вопрос 1 – недостатки.

Собственно по требованиям

- формальноотсутствует syspect (по моему - так называется в requisite pro признак возможных изменений). Но может это и к лучшему, т.к. после того, как impact and Lineage Analysis выдает более 4000 зависимостей на одно требование, то только ручное снятие такого признака может занять целый день. Но несомненно, в некоторых ситуациях пригодился бы. В остальном нормально. Лучше задайте каверзный вопрос, желательно не теоретический, а сравнительный, т.е. относительно возможностей другого средства.

Общие недостатки.
- НЕ РУСИФИЦИРОВАН. Для использования предметными аналитиками требуется обучение.
- НЕТ КНИГ и учебных пособий на РУССКОМ, нигде. Уже устал лекции читать.
- Не удается под Oracle 9i запустить Repository web Browser. Точнее, типовой аналитик не может разрешить проблему с установкой (там джавийная ошибка по преобразованию типов данных оракловым JDBC драйвером). А т.к. фирма жмотится и у нас фактически нет ни админа, ни конфигуратора (точнее - они в наших интересах не работают), ни лицензии, то всем приходится иметь толстого клиента. Не критично, но жаль.
- ввиду того, что файлы моделей хранятся в XML, то при больших объемах одной модели
(более 60000 элементов, наличие встроенных рисунков /bmp скриншоты/, итоговом размере файла модели более 70 мегабайт, наличие более 142 версий в репозитарии)

 бывает (раз в месяц), что при синхронизации (создании новой версии с одновременным обновлением локальной модели), зависает минут на 10-20. Ест ресурсы локально машины 100%. Указано для локальной машины - пень 4, 1 гигабайт оперативки.
- капризничает при построении диаграмм последовательностей (когда есть более 4-5 вложенных вызовов).
- отвратитьный сайт Sybase.ru и com.


Ответ на вопрос 2 – нотации по моделированию БП.

Analysis (наиболее обощенный тип модели БП);
BPMN 1.0;
DFD;
Service Oriented Architecture;
BPEL4WS 1.1;
WS-BPEL 2.0;
Sybase WorkSpace Business Process (собственная нотация, заточенная под для использования в Sybase WorkSpace);
ebXML 1.01;
ebXML 1.04.
Последние 5 поддерживают кодогенерацию.

15

ПО Аналитика / Re: Сравнение средств управления требованиями (Requirements Management Tools)

« : 27 Августа 2009, 00:31:26 »

Привет Виталий! Волей случая - Yandex - завел меня на форум.

Только личное мнение - Sybase PD 15.

Преимущества:
- трассировка на любой элемент любого типа модели (на шаг БП, поток, сущность, таблицу, атрибут, класс, объект, метод, парамент, элемент XML схемы и многое другое). Кроме того, умение быстро вычислять транзитивные зависимости. Т.е. если требование трассировано на бизнес процесс, а бизнес процесс декомпозирован, его шаг описан вариантом использования, который описан диаграммой взаимодействия ... то можно получить взаимосвязь между требованием и папрметром метода.
- простой в использовании генератор отчетов с возможностью расширения (надеюсь Виталий помнит, как пытался получить отчет из IBM-овских продуктов - Web Sphere Business Modeller - мучался почти 3 недели и ноль).
- возможность как декларативного расширения (новые атрибуты, списки выбора, формы, вкладки, новые типы трассировок и т.д.), так и процедурного расширения. Кто зает VB - может целые приложения писать. Лично уже наваял 4 дополнительные формы.
- отрытое описание метамодели - дополняй, программируй сколько влезет.
- совместная работа, версии, простота.....

Рекомендую.