Хочу для управления требований использовать CaliberRM (6.5). В проекте на вскидку порядка 2000 требований, 3 приложения, около 20 крупных объектов. У кого есть опыт, подскажите как лучше оформить базу в Caliber. И вообще впечатления о работе с ним.
Здравствуйте, Maxim2030, Вы писали:
M>Добрый день.
M>Хочу для управления требований использовать CaliberRM (6.5). В проекте на вскидку порядка 2000 требований, 3 приложения, около 20 крупных объектов. У кого есть опыт, подскажите как лучше оформить базу в Caliber. И вообще впечатления о работе с ним.
M>Спасибо
Здравствуйте, Максим, Вы писали:
M>Хочу для управления требований использовать CaliberRM (6.5). В проекте на вскидку порядка 2000 требований, 3 приложения, около 20 крупных объектов. У кого есть опыт, подскажите как лучше оформить базу в Caliber.
так как структурирование категорий требований и custom-атрибутов в большой степени зависит от (как минимум):
1. используемых методологий и подходов
2. сложившейся (или желаемой культуры анализа и разработки
3. внутренних регламентов органзации (как документарных, так и должностных)
этот вопрос стоит обсуждать будучи в контексте Ваших задач/потребностей.
С удовольствием отвечу на Ваши вопросы:
телефон: +7(095)238-3611
Если Вы в Москве — готов встретиться.
Здравствуйте, Сергей Орлик, Вы писали:
СО>этот вопрос стоит обсуждать будучи в контексте Ваших задач/потребностей.
СО>С удовольствием отвечу на Ваши вопросы:
Вот такой вопрос. Есть программист — я, у него есть пара человек на подхвате. И есть куча пользователей — которые пользуются программами которые разработаны в компании (мной +...). Все сделано на Delphi, в основном, но есть и кое что по мелочи постороннее.
Хотелось бы иметь возможность вести список ошибок с возможностью вноса в список ошибок всеми пользователями, иметь возможность выдавать отчеты типа — за прошедшую неделю в программе 1 исправлено 5 ошибок (список), добавлено 8 фич (список)..., в программе 2 — ..., Ну и прикрутить сюда систему контроля версий желательно. Есть ли что нибудь из борландовских продуктов для этого?
Пока все, по мере возникновения возможностей будут рости и желания
Здравствуйте, ironwit, Вы писали:
I>Есть программист — я, у него есть пара человек на подхвате. И есть куча пользователей — которые пользуются программами которые разработаны в компании (мной +...). I>Хотелось бы иметь возможность вести список ошибок с возможностью вноса в список ошибок всеми пользователями, иметь возможность выдавать отчеты типа — за прошедшую неделю в программе 1 исправлено 5 ошибок (список), добавлено 8 фич (список)..., в программе 2 — ..., Ну и прикрутить сюда систему контроля версий желательно. Есть ли что нибудь из борландовских продуктов для этого?
---
т.е., как я понял, речь идет о продвинутом баг-трекинге.
Для такой задачи стоит смотреть в первую очередь в направлении StarTeam, а не Caliber.
Для решения этой задачи вполне достаточно StarTeam Standard (по 1 клиентской лицензии уже лежит в коробках Delphi 8 Enterprise и Architect). Он включает поддержку контроля версий фалов и работу с Change Request (CR) — запросами на изменения, бывающие в этой редакции двух типов — Suggestion ("ну очень хочется...") и Defect ("ааа....ошибка!").
Если пользователей системы достаточно много (например, Вы создаете тиражируемую/коробочную систему) — можно смотреть в сторону StarTeam Enterprise + StarTeam WebEdition ChangeRequest Only (работа с CR из броузера).
Безусловно, Caliber можно использовать вместо StarTeam и для управления CR (похожим образом, например, его использует Siemens ICN — см. http://www.borland.com/products/case_studies/pdf/crm_siemens.pdf ). Однако, концептуально, StarTeam больше "заточен" под Вашу задачу.
С уважением,
Сергей Орлик
Borland
Re[4]: CaliberRM. Как организовать базу требований
Здравствуйте, Сергей Орлик, Вы писали:
СО>т.е., как я понял, речь идет о продвинутом баг-трекинге. СО>Для такой задачи стоит смотреть в первую очередь в направлении StarTeam, а не Caliber.
СО>Для решения этой задачи вполне достаточно StarTeam Standard (по 1 клиентской лицензии уже лежит в коробках Delphi 8 Enterprise и Architect). Он включает поддержку контроля версий фалов и работу с Change Request (CR) — запросами на изменения, бывающие в этой редакции двух типов — Suggestion ("ну очень хочется...") и Defect ("ааа....ошибка!").
Угу. Согласен. Более того могу добавить что у StarTeam есть такая штука как свойство Addressed In в котором указывается Build Label. Build Label это метка на репозитарии которую ты ставишь когда создаешь версию. В случае фикса этот самый Build Label автоматом ставится в "Next Build" и когда ты создаешь следующую метку все метки "Next build" заменяются на нее.
Т.е. по факту делать ничего не нужно, просто поддерживаешь актуальный список багов и когда делаешь releas-ы ставишь метки. Список что в какойм релизе произошло получается сам.
СО>Если пользователей системы достаточно много (например, Вы создаете тиражируемую/коробочную систему) — можно смотреть в сторону StarTeam Enterprise + StarTeam WebEdition ChangeRequest Only (работа с CR из броузера).
А где на него можно посмотреть? Дeмо версию я не нашел — может онлайн на него взглянуть можно?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[5]: CaliberRM. Как организовать базу требований
Здравствуйте, Anatolix, Вы писали:
СО>>Если пользователей системы достаточно много (например, Вы создаете тиражируемую/коробочную систему) — можно смотреть в сторону StarTeam Enterprise + StarTeam WebEdition ChangeRequest Only (работа с CR из броузера).
A>А где на него можно посмотреть? Дeмо версию я не нашел — может онлайн на него взглянуть можно?
Я так понял вопрос — про Web Edition.
Пробной версии его действительно нет (там используется технология ASP, что само по себе = исходные тексты )
На www.opendotnet.ru развернут StarTeam вместсе с WebEdition.
В принципе, есть мысль развернуть демо-конфигурацию StarTeam WebEdition на www.jbuilder.ru. Если считаете, что это будет "познавательно" — буду признателен за любые комментарии на этот счет
С уважением,
Сергей
Re[2]: CaliberRM. Как организовать базу требований
Здравствуйте, Сергей Орлик, Вы писали:
СО>С удовольствием отвечу на Ваши вопросы:
Есть вопросы..
Сразу оговорюсь, что я посмотрел Калибер, многое в нем понравилось, но также и кое-чего нет.
Сейчас попытаюсь описать идеальную систему управления требованиями, как я себе её вижу, для своего проекта. И хотелось бы получить затем коментарии двух видов.
1. Действительно ли я верно рассуждаю, создавая описываемую модель или изначально заблуждаюсь где-то в идеологии? и именно поэтому долгое время уже не могу найти продукт, который бы сполна удовлетворил мои потребности. (так получается, что в одном продукте есть что-то одно, в другом другое, а нужно бы слепить их все вместе)
2. Если моя идея проектирования требований верна, то как её наиболее полно реализовать в Калибере? Я средств к этому не нашел...
Итак, пусть у нас есть проект
АВТОМОБИЛЬНЫЙ ЗАВОД.
Этот проект состоит из бизнес объектов и приложений, которые собираются из этих бизнес объектов.
Мы имеем объект КРЕСЛО
и приложения ЛЕГКОВОЕ АВТО и МАРШРУТКА :
Рисунок 1.
Как видно на рисунке 1, объект КРЕСЛО(как и все остальные объекты и приложения) имеет набор Функциональных и Дизайн требований, а также сам состоит из набора других объектов.
Приложение ЛЕГКОВОЕ АВТО (например) имеет свой набор Функциональных и Дизайн требований, а также включает в себя объект КРЕСЛО (а если быть точным, то не включает, а ссылается. там слово link стоит — это означает ссылку).
Рассмотрим более подробную структуру объекта КРЕСЛО:
Рисунок 2.
Как видно на рисунке 2. У кресла и объектов из которых оно состоит есть масса свойств (требований). Какие-то из этих требований может быть нужны только ЛЕГКОВОМУ АВТО, а какиет-то только МАРШРУТКЕ. А какие-то обоим сразу.
Вот развернутая диаграмма приложения ЛЕГКОВОЕ АВТО:
Рисунок 3.
Обратите внимание, что
— приложение ЛЕГКОВОЕ АВТО не дублирует объект КРЕСЛО, а ссылается на него (link)
— в приложении ЛЕГКОВОЕ АВТО используется не весь набор требований объекта КРЕСЛО, а только те, что нужны именно ему.
Тоже самое для приложения МАРШРУТКА:
Рисунок 4.
Здесь приложение МАРШРУТКА также использует (link) объект КРЕСЛО и опять же только те его требования, что нужны именно ему.
Что я хочу показать в подобной схеме?
1. Что существует толпа объектов, которые используются другими такими же объектами и приложениями.
Причем возможно используется не весь их набор требований, а только тот, что необходим в данном объекте.
2. В данном случае требования объекта КРЕСЛО не раздроблены между приложениями, которые его используют, а сгруппированы в одном месте. А те кто их используют, вставляют линки.
Этот подход позволяет
1. В дереве требований повысить скорость нахождения информации. Т.е. предположим, что один программист работает над объектом КРЕСЛО, поэтому он знает его структуру, где он лежит в дереве и сразу его находит. Другой программист работает над приложением МАРШРУТКА. И по долгу службы тоже соответственно работает над объектом КРЕСЛО. Однако ему вовсе не надо знать где эти требования физически лежат — он работает с ними оттуда, откуда ему удобно.
В общем хочу, сказать, что объекты могут характеризоваться одновременно с разных сторон. Программисты работающие с объектами используют разные характеристики в совей голове для этого объекта и все они верные. Таковая структура позволит этим разным людям эффективно построить свою работу.
2. Понятие link, изображаемое на рисунках шире , чем просто линк. Это означает следующее. Что это не простой маппинг, а если я например работаю в приложении МАРШРУТКА с объектом КРЕСЛО и мне начинает нехватать какой-либо функциональности, то я могу добавить это новое требование прямо по месту — оно автоматом создастся, как линк, а физически поместится в объект КРЕСЛО.
3. Кроме того, при создании нового требования, система должна предложить мне выбрать места куда возможно ещё стоит добавить это требование , как линк. Предположим, я работаю с объектом КРЕСЛО и создаю новое требование. Я знаю, что оно будет нужно в приложениях ЛЕГКОВОЕ АВТО и МАРШРУТКА и я указываю, что нужно линки на это требование добавить и туда тоже.
4. Если я создал набор требований, например штук 1000 и потом обнаружил, что линки на них нужно было добавить в 20 приложений, то мне необходима возможность выбрать эти 20 приложений и одной пачкой добавить туда сразу все 1000 требований, а не заниматься этим 1000 раз. Это особенно актуально, если требования переносятся в систему из какой-либо другой системы, где автоматический импорт невозможен.
5. Описываемый подход позволяет не только эффективно организовать поиск требований разным людям, у которых разная классификация в голове, но и одновременно отображает в узле , скажем ЛЕГКОВОЕ АВТО структуру приложения , как таковую. Т.е. сразу видно, из каковых логических блоков оно состоит, где что используется.
6. Также не надо забывать , что существуют бизнес объекты, реализация которых физически размазана по нескольким приложениям. Т.е. в одном сделан один кусок, в другом другой. В таком случае, я имею возможность создать этот объект со всеми его требованиями, как абстракнтую сущность (например объект КРЕСЛО) отдельно, а там где он реально физически реализован — просто сослаться на этот объект.
7. Необходима возможность для каждого пользователя системы настраивать его область видимости (depot). Т.е. если Вася работает только с приложением МАРШРУТКА, то ему и не надо видеть все это огромное дерево требований, которое содержит 10-20 тысяч требований. Он настраивает свой depot на приложение МАРШРУТКА и при старте системы его дерево автоматически отфильтровывает все, что ему ненужно.
8. Замечу сразу, что уровень вложенности объектов/функцинальных требований/требований на моей диаграмме гораздо глубже, чем вообще позволяет создать Клибер. А нужно теоретически это не ограничивать вовсе.
8. + все то, что есть в Калибере сейчас.
Господа, буду признателен за коментарии
и советы касательно того, где я могу найти систему, которая позволит сделать все то , что я хочу?
+ очень хотелось бы (но это непринципиально), чтобы система содержала в себе сразу управление рисками, багтрекинкг, планировщик работ (аля МС-Прожект) и чтобы все это было интегрировано в одно приложение. Чтобы это все было под рукой. Чтобы не надо было для каждой задачи запускать отдельную апликацию. И чтобы эта интерграция позволяла бы связывать какими — то связями те же ошибки, требования, планы и получать нужные отчеты. Т.е. главная идея — чтобы производить как можно меньше движений для осуществления операции, чтобы это все было просто и быстро. Но это все не принципиально, хотя в идеале так хотелось бы. Сейчас главная задача хотя бы систему управления требованиями найти подходящую.
Спасибо
Re[3]: CaliberRM. Как организовать базу требований
Здравствуйте, Щербатов Евгений, Вы писали:
ЩЕ>Есть вопросы..
ЩЕ>Сразу оговорюсь, что я посмотрел Калибер, многое в нем понравилось, но также и кое-чего нет. ЩЕ>Сейчас попытаюсь описать идеальную систему управления требованиями, как я себе её вижу, для своего проекта. И хотелось бы получить затем коментарии двух видов.
ЩЕ>Итак, пусть у нас есть проект ЩЕ>АВТОМОБИЛЬНЫЙ ЗАВОД.
ЩЕ>Этот проект состоит из бизнес объектов и приложений, которые собираются из этих бизнес объектов. ЩЕ>Мы имеем объект КРЕСЛО ЩЕ>и приложения ЛЕГКОВОЕ АВТО и МАРШРУТКА :
[........]
На самом деле я увидел в Вашем письме два направления мыслей:
1. структурную организацию требований без привязки к ИТ.
2. анализ проблемы создания конкретной прикладной системы с точки зрения ее архитектора/разработчика
Однако, с моей точки зрения, Вы пытаетесь решить вопрос (1) с точки зрения (2), т.е. если "переврать" описанные идеи — есть взгляд на организацию иерархии и атрибутики требований с точки зрения ОО-проектировщика (набор классов с атрибутами, изменямыми в run-time и т.п.) Первая аналогия, пришедшая в голову — обсуждение плюсов и минусов можественного наследования, применения интерфейсов и ссылок и т.п.
Я попытался набросать утрированный пример в CaliberRM: (к вопросу о четкости — изображение 1024x768, так что IE его уменьшает автоматически — используйте кнопку IE "Expand to regular size")
Идея состоит в том, что вместо явного присутствия ссылки в дереве требований (как у Васм представлено в tree view [link]), я вынес это на уровень трейсов. В этом плане сама концепция Traceability в requirement Management является одним из ключей к превращению процесса работы над требованиями в нечто управляемое и версионируемое. Соответственно при генерации отчетов они могут присутствовать (все зависит от Вашего шаблона) в спецификации "изделия".
Таким образом сразу дерево требований по количеству вхождений в него уменьшается в разы (если не на порядок).
Я не стал строить N-е кол-во моделей автомобилей и комплектующих, но надеюсь что моя идея понятна
Да, безусловно для разных типов требований (например Вы можете завести отдельные категории комплектующихз или даже разные проекты, связанные через трейсы...) Вы моежет задасть разные custom-атрибуты и их группы, видимые в зависи мости от прав конкретных групп пользователей.
Что касается количественных ограничений — если не ошибаюсь (не сверялся с документацией) в одном проекте м.б. до 256 типов требований. Когда к нам пришел запрос по использованию Caliber для поддержки управления изменениями в одной достаточно крупной ИТ-службе — попытался залить (тестовый "залив" делал из маленького приложения, обращавшегося к Caliber 5.1 через его SDK) в один проект около 15 тысяч требований по 5 категориям — проблем не встретил.
Ряд европейских производителей автомобилей использует Caliber именно для описания требований к моделям.
Кстати, для управления требованиями именно к ПО по отношению ко всем пользователям Caliber отношение, думаю, будет не больше чем 2:3 (если не 50:50). Потому как очень многие компании используют его для определения функциональности промышленных изделий (автомобили, телефоны и т.п.), кто-то — для описания внутрикорпоративных бизнес-процедур, ..... — чего только не слышал от коллег из Европы и Штатов.
Поэтому очень рекомендовал бы взглянуть на задчу структурирования требований вместе с кем-то из коллег, кто в большее степени является вовлеченным непосредственно в производственные вопросы на Вашем предприятии и изначально не является разработчиком ПО — это позволит найти компромисс между "программистским" и "менеджмент" взглядами.
ЩЕ>+ очень хотелось бы (но это непринципиально), чтобы система содержала в себе сразу управление рисками, багтрекинкг, планировщик работ (аля МС-Прожект) и чтобы все это было интегрировано в одно приложение.
Это уже специализированный модуль ERP получается (например, SAP)
ЩЕ>Чтобы это все было под рукой. Чтобы не надо было для каждой задачи запускать отдельную апликацию. И чтобы эта интерграция позволяла бы связывать какими — то связями те же ошибки, требования, планы и получать нужные отчеты. Т.е. главная идея — чтобы производить как можно меньше движений для осуществления операции, чтобы это все было просто и быстро. Но это все не принципиально, хотя в идеале так хотелось бы. Сейчас главная задача хотя бы систему управления требованиями найти подходящую.
---
Трейсы могут вести в систему управления проектами (MSProject), SCCM (для StarTeam можно делать трейсы на файлы, CR и в частности дефекты, задачи и т.п.), средства оценки рисков (напримре, Estimate Pro).
Кроме того — есть SDK, позволяющий создавать хоть своего клиента (например, простейший пример клиента на ASP есть на Borland CodeCentral).
если что-то упустил, прошу извинить — еще раз перечитаю на свежую голову и попытаюсь, если необходимо, детализировать
С уважением,
Сергей Орлик
Borland
Re[4]: CaliberRM. Как организовать базу требований
Здравствуйте, Сергей Орлик, Вы писали:
СО>Здравствуйте, ironwit, Вы писали:
I>>Есть программист — я, у него есть пара человек на подхвате. И есть куча пользователей — которые пользуются программами которые разработаны в компании (мной +...). I>>Хотелось бы иметь возможность вести список ошибок с возможностью вноса в список ошибок всеми пользователями, иметь возможность выдавать отчеты типа — за прошедшую неделю в программе 1 исправлено 5 ошибок (список), добавлено 8 фич (список)..., в программе 2 — ..., Ну и прикрутить сюда систему контроля версий желательно. Есть ли что нибудь из борландовских продуктов для этого? СО>--- СО>т.е., как я понял, речь идет о продвинутом баг-трекинге.
угу СО>Для такой задачи стоит смотреть в первую очередь в направлении StarTeam, а не Caliber.
СО>Для решения этой задачи вполне достаточно StarTeam Standard (по 1 клиентской лицензии уже лежит в коробках Delphi 8 Enterprise и Architect). Он включает поддержку контроля версий фалов и работу с Change Request (CR) — запросами на изменения, бывающие в этой редакции двух типов — Suggestion ("ну очень хочется...") и Defect ("ааа....ошибка!").
ок СО>Если пользователей системы достаточно много (например, Вы создаете тиражируемую/коробочную систему) — можно смотреть в сторону StarTeam Enterprise + StarTeam WebEdition ChangeRequest Only (работа с CR из броузера).
можно ли к StarTeam Standard прикрутить "(работа с CR из броузера)"? СО>Безусловно, Caliber можно использовать вместо StarTeam и для управления CR (похожим образом, например, его использует Siemens ICN — см. http://www.borland.com/products/case_studies/pdf/crm_siemens.pdf ). Однако, концептуально, StarTeam больше "заточен" под Вашу задачу.
Спасибо, попробуем
... << RSDN@Home 1.1.4 beta 2
Я не умею быть злым, и не хочу быть добрым.
Re[5]: CaliberRM. Как организовать базу требований
Здравствуйте, ironwit, Вы писали:
IСО>>Если пользователей системы достаточно много (например, Вы создаете тиражируемую/коробочную систему) — можно смотреть в сторону StarTeam Enterprise + StarTeam WebEdition ChangeRequest Only (работа с CR из броузера).
I>можно ли к StarTeam Standard прикрутить "(работа с CR из броузера)"?
Web Edition и Web Edition Change request only доступны как дополнительные опции Starteam Enterprise. Web Edition является частью поставки StarTeam Enterprise Advantage, а Web Edition Change request only для Enterprise Advatage — доп. опция (). Для StarTeam Standard они, к сожалению, не поставляются.
С другой стороны — есть StarTeam SDK и Вы можете сделать своего упрощенного Web-клиента к StarTeam.
С уважением,
Сергей
Re[4]: CaliberRM. Как организовать базу требований
СО>если что-то упустил, прошу извинить — еще раз перечитаю на свежую голову и попытаюсь, если необходимо, детализировать
Что-то прочитал сейчас Ваш ответ и не въехал вообще. Такое ощущение, что Вы меня не поняли. Или я вас. Голова уже плохо соображает. Я в выходные ещё раз перечитаю внимательно ваш ответ и подумаю посижу.
Но скажите мне плиз такую вещь. Не привязываясь к Калиберу и его возможностям. Если Вы поняли саму идею проектирования требований, какую я предлагаю — она верна или неверна в корне?
Мне просто сейчас кажется, что эта модель очень эффективна с точки зрения скорости работы, поиска информации, юзабилити, да и вообще организации требований.
Может я чего-то принципиально не понимаю?
Спасибо.
Re[4]: CaliberRM. Как организовать базу требований
Вот у меня на диаграмме изображено, что объект КРЕСЛО имеет два подъобекта СПИНКА, СИДАЛИЩЕ.
У всех их трех имеется группировка требований(которая в Калибере изображается в виде книжечки) : Функциональное, Дизайн. Т.е. требования сгруппированы по своему назначению.
Вот в Калибере я не могу внутри этой книжечки завести ещё одну такую книжечку — он этого не позволяет. Как быть?
А к тому, что На самом деле я увидел в Вашем письме два направления мыслей:
1. структурную организацию требований без привязки к ИТ.
2. анализ проблемы создания конкретной прикладной системы с точки зрения ее архитектора/разработчика
Это да — тут все верно.
Re[5]: CaliberRM. Как организовать базу требований
ЩЕ>Вот у меня на диаграмме изображено, что объект КРЕСЛО имеет два подъобекта СПИНКА, СИДАЛИЩЕ.
ЩЕ>Вот в Калибере я не могу внутри этой книжечки завести ещё одну такую книжечку — он этого не позволяет. Как быть?
"СПИНКА и СИДАЛИЩЕ", с моей точки зрения, должны быть custom-"закладками" (по аналогии с закладкой "Дизайн" на моей копии экрана) со своими атрибутами (так как и спинка и сидалище у кресла есть всегда — а то как-то неудобно ездить, если чего нет . Эти закладки будут всегда у КРЕСЛА, а параметры требований на закладках будут/могут быть специфичны для конкретной модели кресла, причем при их первичном определении можно задать что они будут "наследуемыми" с точки зрения значения по-умолчанию.
Как раз определение "книжечек", т.е. типизация категорий и является одним из первичных этапов структурирования требований, к которому необходимо привлекать людей от бизнеса. Именно исходя из их образа мыслей. сформированного реальным процессом разработки и модификации новых комплектующих, будет зависеть и удобство использования полученной структуры описаний.
С уважением,
Сергей
P.S. Все, о чем я писал, применимо к пути "1. структурная организация требований без привязки к ИТ".
P.S.S. Если же плясать от "2. анализ проблемы создания конкретной прикладной системы с точки зрения ее архитектора/разработчика", т.е. Вы хотите сами создать собственную прикладную "систему управления комплектующими", тогда у Вас _потенциально_ есть существенно бОльший выбор возможностей по организации структур данных и их визуального представления. Но это уже, imho, другая тема — "готовое ПО vs. собственная разработка"
Re[5]: CaliberRM. Как организовать базу требований
ЩЕ>Не привязываясь к Калиберу и его возможностям. Если Вы поняли саму идею проектирования требований, какую я предлагаю — она верна или неверна в корне?
мне кажется держать линки в визуальной составляющей дерева требований — не верно.
Если на тоже дерево посмотреть. как на набор объектов — экземпляров классов со своими ссылками на другие объекты — это логично.
ЩЕ>Мне просто сейчас кажется, что эта модель очень эффективна с точки зрения скорости работы, поиска информации, юзабилити, да и вообще организации требований.
Imho, скорость будет принципиально зависеть от того, как все это хозяйство будет отображаться на БД.
С уважением,
Сергей
P.S. похоже пора сплитить эту ветку как минимум на четыре :
1. StarTeam
2. Caliber
3. Как создать систему управления требованиями
4. Как структурировать требования
Re[6]: CaliberRM. Как организовать базу требований
ЩЕ>>Вот у меня на диаграмме изображено, что объект КРЕСЛО имеет два подъобекта СПИНКА, СИДАЛИЩЕ.
ЩЕ>>Вот в Калибере я не могу внутри этой книжечки завести ещё одну такую книжечку — он этого не позволяет. Как быть?
СО>"СПИНКА и СИДАЛИЩЕ", с моей точки зрения, должны быть custom-"закладками" (по аналогии с закладкой "Дизайн" на моей копии экрана) со своими атрибутами (так как и спинка и сидалище у кресла есть всегда — а то как-то неудобно ездить, если чего нет . Эти закладки будут всегда у КРЕСЛА, а параметры требований на закладках будут/могут быть специфичны для конкретной модели кресла, причем при их первичном определении можно задать что они будут "наследуемыми" с точки зрения значения по-умолчанию.
ОК. пусть будут закладки.. НО ведь этих закладок может быть очень много.. Это же будет как минимум неудобно ими пользоваться. Хотя бы если их количество зашкалит за 20. Или я не прав?
Далее.. Если это закладка, а требования это атрибуты, то атрибутов может быть ещё больше, скажем 50-100 , например. Они же в дерево не выстроятся , а будут лежать на форме закладки и получится мешанина, да?
(у меня сейчас под рукой нет Калибера — проверить не могу, поэтому вспоминаю его ГУИ на память, насколько успел попользовать — чуть-чуть).
И если таким образом распределять требования, т.е. часть в проекте (в раскрытых книжечках), часть в виде атрибутов на закладках, то это же каша получится? Ведь Калибер, требованиями считает ноды TreeView, так ведь? А значит закладка — это уже не объект, а её атрибуты, это уже не требования, так ведь? (блин проверить не могу до понедельника). И соответственно это я не смогу полноценно получить отчеты, посмотреть матрицу взаимосвязей, т.к. матрица будет показывать связи между требованиями, а не атрибутами закладок. Т.е. это будет уродливое приспособление данной задачи под конкретные возможности используемой программы управления требованиями.
Где я не прав?
PS
Я потихоньку начинаю въезжать какие части Колибера для чего можно и нужно использовать. Поэтому спасибо за ответы на вопросы. Если я узнаю все что меня интересует возможно я пойму где я неправильно представляю себе реализацию задачи. (или убедюсь , что задача сформулирована верно и её можно решить средствами, а я просто не умею ими пользоваться).
PPS
Господа, не один же Сергей занимается управлением требованиями и рисками — присоединяйтесь к обсуждению, расскажите, как и кого такие вещи сделаны, что используете! Не стесняйтесь!
Не могу же я быть один, которого волнуют такие проблемы и тем более не могу я быть первым кто пытается разложить систему требований в ту структуру с линками, что я обрисовывал выше. Может кто-то уже проходил по такому пути и нашел выход — поделитесь, сделайте человечество грамотнее на ещё одного человека!
Re[7]: CaliberRM. Как организовать базу требований
Здравствуйте, Евгений,
СО>>"СПИНКА и СИДАЛИЩЕ", с моей точки зрения, должны быть custom-"закладками" (по аналогии с закладкой "Дизайн" на моей копии экрана) со своими атрибутами (так как и спинка и сидалище у кресла есть всегда — а то как-то неудобно ездить, если чего нет . Эти закладки будут всегда у КРЕСЛА, а параметры требований на закладках будут/могут быть специфичны для конкретной модели кресла, причем при их первичном определении можно задать что они будут "наследуемыми" с точки зрения значения по-умолчанию.
ЩЕ>ОК. пусть будут закладки.. НО ведь этих закладок может быть очень много.. Это же будет как минимум неудобно ими пользоваться. Хотя бы если их количество зашкалит за 20. Или я не прав?
Я привел этот пример как альтернативу иерархическому представлению _в_данном_конкретном_кресловом_случае .
Никто не мешает детализировать:
Кресло
-спинка
-сидалище
Аналогия (попробуйте представить как на функц. требования будет раскладываться соотв. use case):
продажа
-обработка заказа
-выставление счета
(для приведенного примера use case это не 100% ответ, а всего-лишь один из вариантов детализации)
ЩЕ>Далее.. Если это закладка, а требования это атрибуты, то атрибутов может быть ещё больше, скажем 50-100 , например. Они же в дерево не выстроятся , а будут лежать на форме закладки и получится мешанина, да?
см. выше — все зависит от контекста
если поставщик спинки — один на заводе. а сидалища — другой, я бы однозначно выбирал вариант с стрибутами, сгруппированными на закладках.
Все зависит от степени детализации — что есть "комплектующее" — кресло или, например, его спинка.
ЩЕ>И если таким образом распределять требования, т.е. часть в проекте (в раскрытых книжечках), часть в виде атрибутов на закладках, то это же каша получится? Ведь Калибер, требованиями считает ноды TreeView, так ведь? А значит закладка — это уже не объект, а её атрибуты, это уже не требования, так ведь? (блин проверить не могу до понедельника).
все правильно, поэтому я и заговорил о степени детализации ("атомарности" комплектующих).
ЩЕ>И, соответственно, это я не смогу полноценно получить отчеты, посмотреть матрицу взаимосвязей, т.к. матрица будет показывать связи между требованиями, а не атрибутами закладок.
верно.
ЩЕ>Т.е. это будет уродливое приспособление данной задачи под конкретные возможности используемой программы управления требованиями.
может быть (а может и нет, если Вы видели как консультанты настраивают SAP или какуюлибо другую ERP
ЩЕ>Где я не прав?
в том то и дело что Вы правы и универсальных ответов — нет. есть обсуждение возможных путей решения задачи. Я для выбора более эффективного пути необходимо больше информации:
1. эту систему будет использовать производитель автомобилей для определения конкретных моделей?
2. эту систему будет использовать автодилер для заказа комплектации?
и т.п.
выбор даже из этих двух вариантов (кто будет пользователем системы) будет накладывать различные ограничения и приоритеты на возможный путь решения задачи.
С уважением,
Сергей
P.S. ЩЕ>PS ЩЕ>Я потихоньку начинаю въезжать какие части Колибера для чего можно и нужно использовать.
Я Вам искренне завидую , потому как при каждом новом обсуждении открываю возможные способы его применения и больше узнаю о том, как отличается даже в похожих проектах ответ на вопрос "чего хочет пользователь" (поверьте, это другое кино )
Re[3]: CaliberRM. Как организовать базу требований
ЩЕ>Этот проект состоит из бизнес объектов и приложений, которые собираются из этих бизнес объектов. ЩЕ>Мы имеем объект КРЕСЛО ЩЕ>и приложения ЛЕГКОВОЕ АВТО и МАРШРУТКА :
К вопросу о визуальном представлении трейсов (в Вашем прототипе UI [link]) в Caliber.
Вот как выглядит трейс из моего примера на другой закладке:
культуры анализа и разработки
(к вопросу о четкости — изображение 1024x768, так что IE его уменьшает автоматически — используйте кнопку IE "Expand to regular size")
до понедельника). И соответственно это я не смогу полноценно получить отчеты, посмотреть матрицу взаимосвязей, т.к. матрица будет показывать связи между требованиями, а не атрибутами закладок. Т.е. это будет уродливое приспособление данной задачи под конкретные возможности используемой программы управления требованиями. 
