Добрый вечер всем.
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 в том, что он автоматически следит за версиями каждого элемента в отдельности (в автоматическом режиме). За счет чего - значительно сокращается объем БД.
Сравнение средств управления требованиями (Requirements Management Tools)