Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Господа, здравствуйте.
А>>Подскжите пожалуйста кто-нибудь использует для управления требованиями систему Telelogic Doors? Если да, то подскажите а как можно взять какой-нибудь последний триал этой системы, чтобы изучить и ознакомиться?

А>>Спасибо.

А>Используем. И по полугодовым ощущениям (а проектов не один десяток) -- полное убожество. Как по толстому клиенту так и по сервису (совершенно все приходится писать dxl скриптами). Это еще надо учесть, какова стоимость лицензий. Тот же Борландовский CaliberRM по сравнению с DOORS кажется сказкой.


эти doors полное г...о. наша контора купила этот продукт теперь не знаем что делать. для одного проекта еще ничего, а как только несколько проектов жопа.

Здравствуйте, Аноним, Вы писали:

А>Господа, здравствуйте.
А>Подскжите пожалуйста кто-нибудь использует для управления требованиями систему Telelogic Doors? Если да, то подскажите а как можно взять какой-нибудь последний триал этой системы, чтобы изучить и ознакомиться?

А>Спасибо.

Используем. И по полугодовым ощущениям (а проектов не один десяток) -- полное убожество. Как по толстому клиенту так и по сервису (совершенно все приходится писать dxl скриптами). Это еще надо учесть, какова стоимость лицензий. Тот же Борландовский CaliberRM по сравнению с DOORS кажется сказкой.

Здравствуйте, Аноним, Вы писали:

А>эти doors полное г...о. наша контора купила этот продукт теперь не знаем что делать. для одного проекта еще ничего, а как только несколько проектов жопа.

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

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

Господа, здравствуйте.
Подскжите пожалуйста кто-нибудь использует для управления требованиями систему Telelogic Doors? Если да, то подскажите а как можно взять какой-нибудь последний триал этой системы, чтобы изучить и ознакомиться?

Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Господа, здравствуйте.
А>Подскжите пожалуйста кто-нибудь использует для управления требованиями систему Telelogic Doors? Если да, то подскажите а как можно взять какой-нибудь последний триал этой системы, чтобы изучить и ознакомиться?

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

Здравствуйте, <Аноним>, Вы писали:

А>Подскжите пожалуйста кто-нибудь использует для управления требованиями систему Telelogic Doors? Если да, то подскажите а как можно взять какой-нибудь последний триал этой системы, чтобы изучить и ознакомиться?

Согласен с предыдущими ораторами.
а) триал так просто не дадут — только через непосредственный контакт с менеджером, который потом так просто с вас не слезет
б) крайне медленное развитие системы — я не нашел отличий нынешней версии и версии двухлетней давности
в) функицональность ничем не лучше аналогов (реквизит про и калибра), за исключением, может быть, надстройки DOORS Analyst — это интересная задумка, мне понравилась (позволяет полностью интегрировать UML-модель и текст требований), но исполнение было кривое — утечки памяти и дикие тормоза на модели сложнее трех классов.
г) внутренний скриптовый язык dxl — это тихий ужас
д) очень слабый встроенный экспортер в rtf, потенциально мощный, но крайне кривой отдельный продукт DocExpress (здесь могу ошибиться с названием)
е) большое количество проприетарных решений: своя БД, свой тонкий веб-клиент, dxl

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

Ценовой вопрос не рассматриваю

Здравствуйте, Аноним, Вы писали:

А>Господа, здравствуйте.
А>Подскжите пожалуйста кто-нибудь использует для управления требованиями систему Telelogic Doors? Если да, то подскажите а как можно взять какой-нибудь последний триал этой системы, чтобы изучить и ознакомиться?

А>Спасибо.

меня убила цена вопроса
до глумления над триалом так и не дошел

Здравствуйте, Аноним, Вы писали:

А>Используем. И по полугодовым ощущениям (а проектов не один десяток) -- полное убожество. Как по толстому клиенту так и по сервису (совершенно все приходится писать dxl скриптами). Это еще надо учесть, какова стоимость лицензий. Тот же Борландовский CaliberRM по сравнению с DOORS кажется сказкой.

А поконкретней можно, какую варсию используете, какого рода проекты (инхаузеры или аутосорсеры) а то как-то холиварз попахивает? Я сейчас использую DOORS на конкретных проектах у одного заказчика. Имею опыт работы и внедрения ReqPro и CaliberRM. Пока увидел ничего такого, от чего бы я стал плеваться. А проблемы есть у любого инструмента. Да, у CaliberRM более "интуитивно-понятный" интерфейс. Может вы пытаетесь его использовать в таком качестве, для чего он не предназначен?

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

ZD>д) очень слабый встроенный экспортер в rtf, потенциально мощный, но крайне кривой отдельный продукт DocExpress (здесь могу ошибиться с названием)
ZD>е) большое количество проприетарных решений: своя БД, свой тонкий веб-клиент, dxl

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

А вы в реальных проектах используете инструмент у себя в компании (вы вроде как в "большем аутсорсере" работаете)? Интересно было бы узнать, почему именно при низкой квалификации аналитиков рекомендуете использовать? Просто у меня сложилось диаметрально противоположное мнение, о том, что аналитик наоборот должен быть квалифицированным.

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

B>А вы в реальных проектах используете инструмент у себя в компании
DOORS — нет, поскольку для реального проекта его надо купить, а чтобы купить — нужно получить положительные результаты evaluation, а их нет.

B> (вы вроде как в "большем аутсорсере" работаете)?
откуда эта инфа? Вообще, ушел из аутсорсера (большого или нет — отдельный вопрос) полгода назад.

B> Интересно было бы узнать, почему именно при низкой квалификации аналитиков рекомендуете использовать? Просто у меня сложилось диаметрально противоположное мнение, о том, что аналитик наоборот должен быть квалифицированным.
Тут надо сначала определиться, что считать квалификацией. Поясню, что я имел в виду.
В ходе любого проекта возникают задачи по управлению требованиями. По мере роста количества аналитиков, занятых на проекте, проблемы, связанные с управлением требованиями, очевидно, усугубляются. До некоторых пор возможно успешно решать эти задачи, задействовав одного (назовем его ведущим) аналитика на каждую изолированную предметную область, который смог бы в голове держать все неоходимые связи (это я и назвал "квалификацией"), и я считаю, что это эффективнее, чем внедрение инструмента.
Применять инструменты управления требованиями становится целесообразно тогда, когда одного ведущего аналитика на область становится недостаточно либо из-за объема требований, либо из-за отсутствия такого человека. В этом случае инструмент (+детально расписанный процесс) позволяет а) решать текущие проблемы б) наращивать количество аналитиков на проекте более-менее безболезненно.

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

B>> Интересно было бы узнать, почему именно при низкой квалификации аналитиков рекомендуете использовать? Просто у меня сложилось диаметрально противоположное мнение, о том, что аналитик наоборот должен быть квалифицированным.
ZD>Тут надо сначала определиться, что считать квалификацией. Поясню, что я имел в виду.
ZD>В ходе любого проекта возникают задачи по управлению требованиями. По мере роста количества аналитиков, занятых на проекте, проблемы, связанные с управлением требованиями, очевидно, усугубляются. До некоторых пор возможно успешно решать эти задачи, задействовав одного (назовем его ведущим) аналитика на каждую изолированную предметную область, который смог бы в голове держать все неоходимые связи (это я и назвал "квалификацией"), и я считаю, что это эффективнее, чем внедрение инструмента.
ZD>Применять инструменты управления требованиями становится целесообразно тогда, когда одного ведущего аналитика на область становится недостаточно либо из-за объема требований, либо из-за отсутствия такого человека. В этом случае инструмент (+детально расписанный процесс) позволяет а) решать текущие проблемы б) наращивать количество аналитиков на проекте более-менее безболезненно.

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

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

ZD>>В ходе любого проекта возникают задачи по управлению требованиями.

B>Оригинальная точка зрения В принципе это конечно так.
B>Если человек один, все в явном виде хранит в голове и никому
B>это дальше передавать не собирается (ну программистам там всяким),
А я и не предлагал держать требования в голове В голове содержатся связи и зависимости, а сами требования записываются в ворде, вики и т.д.

B>то на управлении требованиями вообще, и на тулах в частности, можно очень хорошо сэкономить
Моё мнение — использоване любого инструмента должно быть в первую очередь экономически оправдано. Если есть аналитик, способный заменить своей головой инструмент — почему бы её не использовать?

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

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

ZD>>>В ходе любого проекта возникают задачи по управлению требованиями.

B>>Оригинальная точка зрения В принципе это конечно так.
B>>Если человек один, все в явном виде хранит в голове и никому
B>>это дальше передавать не собирается (ну программистам там всяким),
ZD>А я и не предлагал держать требования в голове В голове содержатся связи и зависимости, а сами требования записываются в ворде, вики и т.д.

Связи между чем?
Ты предлагаешь аналитику держать в голове связи между разными уровнями требований (user — system)?
И так же между требованиями и дизайном?
Я думаю что это реально либо на совсем уж небольших проектах,
либо там где это вообще не делают.

B>>то на управлении требованиями вообще, и на тулах в частности, можно очень хорошо сэкономить
ZD>Моё мнение — использоване любого инструмента должно быть в первую очередь экономически оправдано. Если есть аналитик, способный заменить своей головой инструмент — почему бы её не использовать?

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

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

B>Связи между чем?
B>Ты предлагаешь аналитику держать в голове связи между разными уровнями требований (user — system)?
B>И так же между требованиями и дизайном?
Да, почему бы и нет, если человек это может делать.

B>Я думаю что это реально либо на совсем уж небольших проектах,
Давай определимся с размерами — что такое небольшой проект?

B>Профи как раз все связи сделает явными и управляемыми, выбрав оптимальный тул,
B>даже если он все это будет иметь в своей голове.
Вот, оптимальный тул! Возможно я просто не знаю такого. Какой можешь предложить тул, кроме реквизита/калибра/доорс?

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

ZD>А я и не предлагал держать требования в голове В голове содержатся связи и зависимости, а сами требования записываются в ворде, вики и т.д.

ZD>Моё мнение — использоване любого инструмента должно быть в первую очередь экономически оправдано. Если есть аналитик, способный заменить своей головой инструмент — почему бы её не использовать?

1. Если все связи и зависимости держаться в голове конкретного аналитика, то по идее упавший ему на голову кирпич лишает компанию возможности восстановить эти связи. Так что связи желательно где-то фиксировать, хоть в Excel, но фиксировать.

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

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

_D>меня убила цена вопроса
_D>до глумления над триалом так и не дошел

Вот и мне хотелось бы увидеть аналог DOORS/CaliberRM/ReqPro стоимостью в 1000 USD за floating лицензию ... при этом желательно имеющим интеграцию с SCCM тулами и средствами проектирования/разработки.

Здравствуйте, Аноним, Вы писали:

А>Господа, здравствуйте.
А>Подскжите пожалуйста кто-нибудь использует для управления требованиями систему Telelogic Doors? Если да, то подскажите а как можно взять какой-нибудь последний триал этой системы, чтобы изучить и ознакомиться?

А>Спасибо.

Добрый день.

Получить триал лицензию DOORS очень просто. Необходимо зайти на сайт www.telelogic.ru и зарегистрироваться там. Далее нужно будет предоставить MAC адрес сетевой карточки компьютера, на котором Вы будете делать триал.
После этого Вам будет выслана лицензия, которая:
1) даст возможность скачать дистрибутив с сайта telelogic
2) позволит этот дистрибутив установить и использовать.

Удачи!

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

B>Вот и мне хотелось бы увидеть аналог DOORS/CaliberRM/ReqPro стоимостью в 1000 USD за floating лицензию ... при этом желательно имеющим интеграцию с SCCM тулами и средствами проектирования/разработки.

Вы, случайно, не на Telelogic работаете?
Моя unsuccessfull story закончилась тогда, когда был получен счет на тулзы для проектной команды из 9 человек в размере около 35 килоевро за год. Такие неоправданные затраты не были одобрены руководством... Осложнило дело еще и то, что я так и не получил возможность оценить триал.
В итоге было принято решение внедрять GForge AS.
Если кого-нибудь заинтересует, вот примеры внедрения:
GForge AS
опенсорцный GForge

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


_D>Вы, случайно, не на Telelogic работаете?

Пока работаю на себя. Просто у меня аллергия на холиварз. Да и насмотрелся я на орущих "ваши use cases/ГОСТы/UML/DOORS/CaliberRM/ReqPro ... полная фигня", а как копнешь, а там элементарная безграмотность. И очень уважительно отношусь к тем, кто вместо эмоций аргументированно излагает позицию.

_D>Моя unsuccessfull story закончилась тогда, когда был получен счет на тулзы для проектной команды из 9 человек в размере около 35 килоевро за год. Такие неоправданные затраты не были одобрены руководством... Осложнило дело еще и то, что я так и не получил возможность оценить триал.

А почему за год??? Разве это не единоразовый платеж? И это счет был только за DOORS или вы еще что-то брали?

P.S. Вопросы я задаю не любопытсва ради. Просто работаю с одним заказчиком на тему оценки возможности/эффективности использования того же DOORS в их условиях. Посему опыт других людей в этой области интересен.

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

B>А почему за год??? Разве это не единоразовый платеж? И это счет был только за DOORS или вы еще что-то брали?

К сожалению, я не сохранил файл, содержащий предложение от Telelogic, поэтому могу быть неточным...
Нам было предложено несколько инструментов Telelogic (DOORS, Synergy, Tau и т.д.).
Поскольку цены на фиксированные и плавающие лицензии были высоки для нас, нам было предложено арендовать продукты по жетонной схеме.
Суть жетонной схемы заключается в том, что каждое приложение при запуске "берет из общей копилки" определенное для этого приложения количество жетонов и возвращает их при выходе. Приложение не запускается, если в копилке недостаточно жетонов. Следовательно, для работы Вам необходимо вычислить требуемое количество жетонов и приобрести их. Причем, срок действия жетона — 1 год, а стоимость 800 евро (могу ошибаться). Дополнительно к жетонам прилагается техподдержка на год (если не ошибаюсь, 10% от стоимости купленных жетонов) и обучение сотрудников (если не ошибаюсь, 1500 евро за занятие). Ну а триал обещали дать только после принципиального согласия высшего руководства на рассмотрение предложения.

B>Подробности можно узнать? Какого рода проекты, как у вас процесс разработки и управления требованиями выстроен? ... и B>что-то у нас "онанимы" (ошибка в правописании допущена не случайно) зачастили ругаться. Ой не спроста это ...

Ну я не "онаним". DOORS изучали, когда выбирали RMS для конторы, где я работал. Мое мнение о нем полностью совпадает с мнением онанимов. Типичное Bloatware за совершенно неадекватные деньги. Кстати, руководство склонялось к его внедрению, это был один из поводов для меня расстаться с этой компанией.

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

dmz>Ну я не "онаним". DOORS изучали, когда выбирали RMS для конторы, где я работал. Мое мнение о нем полностью совпадает с мнением онанимов. Типичное Bloatware за совершенно неадекватные деньги. Кстати, руководство склонялось к его внедрению, это был один из поводов для меня расстаться с этой компанией.

Уже радует что не анонимно ... но тем не менее малоинформативно. На какой позиции вы там работали? Менеджер, аналитик, разработчик? Занимались ли созданием документации требований? Какие использовали стандарты на документацию требований? Какие именно недостатки инструмента вы обнаружили? Какой до этого компания использовала инструментарий? Какова зрелость процессов разработки ПО в компании (или это Люксофт )? Какого рода проекты (инхаузеры или аутсорсеры)? ... Была ли практика одновременной работы нескольких аналитиков над требованиями? Документация требований в печатном виде формально подписывалась у заказчика? Как именно планировали использовать инструмент? Территориально это где Москва, Питер, др. регион?
Ответив на эти вопросы уже можно будет видеть более-менее аргументированную точку зрения. Именно аргументация интересна большинству участникам форума думаю. ... А пока, к сожалению, только эмоции .

B>На какой позиции вы там работали? Менеджер, аналитик, разработчик?
Как это влияет на качество продукта?

B>Занимались ли созданием документации требований?
Да

B>Какие использовали стандарты на документацию требований?
Внутренние. Удовлетворящие SOX. Не ГОСТ. Как это влияет на качество продукта?

B>Какие именно недостатки инструмента вы обнаружили?

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

B>Какой до этого компания использовала инструментарий?
Как это влияет на качество продукта?

B>Какова зрелость процессов разработки ПО в компании (или это Люксофт )?
Как это влияет на качество продукта?

B>Какого рода проекты (инхаузеры или аутсорсеры)? ...
Лично мои были аутсосными, но были и те и другие. И?

B>Была ли практика одновременной работы нескольких аналитиков над требованиями?
Проекты самые различные. Не меньше сотни. Везде по разному.

B>Документация требований в печатном виде формально подписывалась у заказчика?
В печатном это необязательно, заказчик внутренний. Но цикл согласования документов в
электронном виде был.

B>Как именно планировали использовать инструмент?
Для управления требованиями.

B>Территориально это где Москва, Питер, др. регион?
Как это влияет на качество продукта?

B>Ответив на эти вопросы уже можно будет видеть более-менее аргументированную точку зрения. Именно аргументация B>интересна большинству участникам форума думаю. ... А пока, к сожалению, только эмоции

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

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


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

B>>Какой до этого компания использовала инструментарий?
dmz>Как это влияет на качество продукта?

B>>Какова зрелость процессов разработки ПО в компании (или это Люксофт )?
dmz>Как это влияет на качество продукта?

B>>Была ли практика одновременной работы нескольких аналитиков над требованиями?
dmz>Проекты самые различные. Не меньше сотни. Везде по разному.

B>>Как именно планировали использовать инструмент?
dmz>Для управления требованиями.

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

По поводу "Как это влияет на качество продукта?". Поясняю. Качество -- это в первую очередь соответствие определенным тем или иным образом критериям. В данном случае, оценка возможности использования инструмента определяется критериями, которые диктует сложившаяся практика работы с требованиями в организации. Она может быть разной. В частности, вы сказали что планировали использовать инструмент "Для управления требованиями". Только для управления? А для разработки их не планировали использовать ? Несомненно, накладывается еще и один момент, связанный с тем, что подразумевается в данном конкретном случае под "управлением требованиями". Я в своей практике встречал и попытки использования инструментария RDM для целей Issue Management. И люди были искренне уверены что это и есть "Управление требованиями". Так что по такому ответу мне все равно достаточно сложно судить. Но, несомненно, я не в праве требовать от вас большего .
С другой стороны, хотелось бы обратить внимание на тот факт, что коль скоро вы занимались как аналитик разработкой требований, то наверняка имеете предстваление о критериях "хороших требований". Наверняка вы не писали в вашей документации фраз типа "продукт должен иметь дружественный пользовательский интерфейс", ибо это имеет мало шансов на ОБЪЕКТИВНУЮ проверку. В то же время говорите что "Продукт неудобен в использовании". В каком использовании, в каком качестве? Что именно неудобно, увы осталось за кадром.
Лично у меня сложилось впечатление, что основным критерием является именно цена, а точнее соотношение "цена"/"ваше представление о том какой вам нужен продукт". Вот об этих критериях было бы интереснее всего услышать.

B>Лично у меня сложилось впечатление, что основным критерием является именно цена, а точнее соотношение "цена"/"ваше представление о том какой вам нужен продукт". Вот об этих критериях было бы интереснее всего услышать.

Нет, не цена. Цена компании была безразлично.
Что касается остального — понимаете, что бы разработать продукт — нужна долгая и аккуратная работа с требованиями. А что бы его оценить — она вовсе не нужна, достаточно одного короткого слова. Увы.

Заниматься "сбором требований на RMS", что бы потом оценивать данный продукт на соответствие им — совершенно пустое занятие. Так что давайте закончим и останемся при своих.