Здравствуйте, Щербатов Евгений,
прочитал — хоть и с опозданием — о ваших проблемах для работы с требованиями.
Вас спасет только один инструмент — лучший в мире — для работы с требованиями — Doors от от компании Telelogic (www.telelogic.com)

Анатолий
(avolokhov@rambler.ru)

Добрый день.

Хочу для управления требований использовать CaliberRM (6.5). В проекте на вскидку порядка 2000 требований, 3 приложения, около 20 крупных объектов. У кого есть опыт, подскажите как лучше оформить базу в Caliber. И вообще впечатления о работе с ним.

Спасибо

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

M>Добрый день.

M>Хочу для управления требований использовать CaliberRM (6.5). В проекте на вскидку порядка 2000 требований, 3 приложения, около 20 крупных объектов. У кого есть опыт, подскажите как лучше оформить базу в Caliber. И вообще впечатления о работе с ним.

M>Спасибо

Re: Управление требованиями

Автор: cvoronin
Дата: 12.02.04

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

M>Хочу для управления требований использовать CaliberRM (6.5). В проекте на вскидку порядка 2000 требований, 3 приложения, около 20 крупных объектов. У кого есть опыт, подскажите как лучше оформить базу в Caliber.

так как структурирование категорий требований и custom-атрибутов в большой степени зависит от (как минимум):
1. используемых методологий и подходов
2. сложившейся (или желаемой культуры анализа и разработки
3. внутренних регламентов органзации (как документарных, так и должностных)

этот вопрос стоит обсуждать будучи в контексте Ваших задач/потребностей.

С удовольствием отвечу на Ваши вопросы:

телефон: +7(095)238-3611
Если Вы в Москве — готов встретиться.

С уважением,
Сергей Орлик
менеджер по продуктам
Borland
Россия, СНГ
http://www.borland.com
http://info.borland.ru
http://www.jbuilder.ru

Здравствуйте, Сергей Орлик, Вы писали:

СО>этот вопрос стоит обсуждать будучи в контексте Ваших задач/потребностей.

СО>С удовольствием отвечу на Ваши вопросы:

Вот такой вопрос. Есть программист — я, у него есть пара человек на подхвате. И есть куча пользователей — которые пользуются программами которые разработаны в компании (мной +...). Все сделано на 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

Здравствуйте, Сергей Орлик, Вы писали:

СО>т.е., как я понял, речь идет о продвинутом баг-трекинге.
СО>Для такой задачи стоит смотреть в первую очередь в направлении 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мо версию я не нашел — может онлайн на него взглянуть можно?

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

СО>>Если пользователей системы достаточно много (например, Вы создаете тиражируемую/коробочную систему) — можно смотреть в сторону StarTeam Enterprise + StarTeam WebEdition ChangeRequest Only (работа с CR из броузера).

A>А где на него можно посмотреть? Дeмо версию я не нашел — может онлайн на него взглянуть можно?

Я так понял вопрос — про Web Edition.
Пробной версии его действительно нет (там используется технология ASP, что само по себе = исходные тексты )
На www.opendotnet.ru развернут StarTeam вместсе с WebEdition.

В принципе, есть мысль развернуть демо-конфигурацию StarTeam WebEdition на www.jbuilder.ru. Если считаете, что это будет "познавательно" — буду признателен за любые комментарии на этот счет

С уважением,
Сергей

Здравствуйте, Сергей Орлик, Вы писали:

СО>С удовольствием отвечу на Ваши вопросы:

Есть вопросы..

Сразу оговорюсь, что я посмотрел Калибер, многое в нем понравилось, но также и кое-чего нет.
Сейчас попытаюсь описать идеальную систему управления требованиями, как я себе её вижу, для своего проекта. И хотелось бы получить затем коментарии двух видов.

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. + все то, что есть в Калибере сейчас.


Господа, буду признателен за коментарии
и советы касательно того, где я могу найти систему, которая позволит сделать все то , что я хочу?

+ очень хотелось бы (но это непринципиально), чтобы система содержала в себе сразу управление рисками, багтрекинкг, планировщик работ (аля МС-Прожект) и чтобы все это было интегрировано в одно приложение. Чтобы это все было под рукой. Чтобы не надо было для каждой задачи запускать отдельную апликацию. И чтобы эта интерграция позволяла бы связывать какими — то связями те же ошибки, требования, планы и получать нужные отчеты. Т.е. главная идея — чтобы производить как можно меньше движений для осуществления операции, чтобы это все было просто и быстро. Но это все не принципиально, хотя в идеале так хотелось бы. Сейчас главная задача хотя бы систему управления требованиями найти подходящую.

Спасибо

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Здравствуйте, Сергей Орлик, Вы писали:

СО>>С удовольствием отвечу на Ваши вопросы:

ЩЕ>Есть вопросы..

Ни х... себе у тебя задачки..... Я просто в шоке.

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Есть вопросы..

ЩЕ>Сразу оговорюсь, что я посмотрел Калибер, многое в нем понравилось, но также и кое-чего нет.
ЩЕ>Сейчас попытаюсь описать идеальную систему управления требованиями, как я себе её вижу, для своего проекта. И хотелось бы получить затем коментарии двух видов.

ЩЕ>Итак, пусть у нас есть проект
ЩЕ>АВТОМОБИЛЬНЫЙ ЗАВОД.

ЩЕ>Этот проект состоит из бизнес объектов и приложений, которые собираются из этих бизнес объектов.
ЩЕ>Мы имеем объект КРЕСЛО
ЩЕ>и приложения ЛЕГКОВОЕ АВТО и МАРШРУТКА :
[........]

На самом деле я увидел в Вашем письме два направления мыслей:
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

Здравствуйте, Сергей Орлик, Вы писали:

СО>Здравствуйте, 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 больше "заточен" под Вашу задачу.
Спасибо, попробуем

Здравствуйте, 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.

С уважением,
Сергей

Здравствуйте, Сергей Орлик, Вы писали:



СО>если что-то упустил, прошу извинить — еще раз перечитаю на свежую голову и попытаюсь, если необходимо, детализировать

Что-то прочитал сейчас Ваш ответ и не въехал вообще. Такое ощущение, что Вы меня не поняли. Или я вас. Голова уже плохо соображает. Я в выходные ещё раз перечитаю внимательно ваш ответ и подумаю посижу.

Но скажите мне плиз такую вещь. Не привязываясь к Калиберу и его возможностям. Если Вы поняли саму идею проектирования требований, какую я предлагаю — она верна или неверна в корне?

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

Спасибо.

Здравствуйте, Сергей Орлик, Вы писали:

В догонку пока не ушел...

Вот у меня на диаграмме изображено, что объект КРЕСЛО имеет два подъобекта СПИНКА, СИДАЛИЩЕ.
У всех их трех имеется группировка требований(которая в Калибере изображается в виде книжечки) : Функциональное, Дизайн. Т.е. требования сгруппированы по своему назначению.

Вот в Калибере я не могу внутри этой книжечки завести ещё одну такую книжечку — он этого не позволяет. Как быть?

А к тому, что
На самом деле я увидел в Вашем письме два направления мыслей:
1. структурную организацию требований без привязки к ИТ.
2. анализ проблемы создания конкретной прикладной системы с точки зрения ее архитектора/разработчика

Это да — тут все верно.

Здравствуйте, Евгений,


ЩЕ>Вот у меня на диаграмме изображено, что объект КРЕСЛО имеет два подъобекта СПИНКА, СИДАЛИЩЕ.

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

"СПИНКА и СИДАЛИЩЕ", с моей точки зрения, должны быть custom-"закладками" (по аналогии с закладкой "Дизайн" на моей копии экрана) со своими атрибутами (так как и спинка и сидалище у кресла есть всегда — а то как-то неудобно ездить, если чего нет . Эти закладки будут всегда у КРЕСЛА, а параметры требований на закладках будут/могут быть специфичны для конкретной модели кресла, причем при их первичном определении можно задать что они будут "наследуемыми" с точки зрения значения по-умолчанию.

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

С уважением,
Сергей

P.S. Все, о чем я писал, применимо к пути "1. структурная организация требований без привязки к ИТ".

P.S.S. Если же плясать от "2. анализ проблемы создания конкретной прикладной системы с точки зрения ее архитектора/разработчика", т.е. Вы хотите сами создать собственную прикладную "систему управления комплектующими", тогда у Вас _потенциально_ есть существенно бОльший выбор возможностей по организации структур данных и их визуального представления. Но это уже, imho, другая тема — "готовое ПО vs. собственная разработка"

Здравствуйте, Евгений,


ЩЕ>Не привязываясь к Калиберу и его возможностям. Если Вы поняли саму идею проектирования требований, какую я предлагаю — она верна или неверна в корне?

мне кажется держать линки в визуальной составляющей дерева требований — не верно.
Если на тоже дерево посмотреть. как на набор объектов — экземпляров классов со своими ссылками на другие объекты — это логично.

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

Imho, скорость будет принципиально зависеть от того, как все это хозяйство будет отображаться на БД.

С уважением,
Сергей

P.S. похоже пора сплитить эту ветку как минимум на четыре :
1. StarTeam
2. Caliber
3. Как создать систему управления требованиями
4. Как структурировать требования

Здравствуйте, Сергей Орлик, Вы писали:

СО>С другой стороны — есть StarTeam SDK и Вы можете сделать своего упрощенного Web-клиента к StarTeam.

Спасибо

Здравствуйте, Сергей Орлик, Вы писали:


ЩЕ>>Вот у меня на диаграмме изображено, что объект КРЕСЛО имеет два подъобекта СПИНКА, СИДАЛИЩЕ.

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

СО>"СПИНКА и СИДАЛИЩЕ", с моей точки зрения, должны быть custom-"закладками" (по аналогии с закладкой "Дизайн" на моей копии экрана) со своими атрибутами (так как и спинка и сидалище у кресла есть всегда — а то как-то неудобно ездить, если чего нет . Эти закладки будут всегда у КРЕСЛА, а параметры требований на закладках будут/могут быть специфичны для конкретной модели кресла, причем при их первичном определении можно задать что они будут "наследуемыми" с точки зрения значения по-умолчанию.

ОК. пусть будут закладки.. НО ведь этих закладок может быть очень много.. Это же будет как минимум неудобно ими пользоваться. Хотя бы если их количество зашкалит за 20. Или я не прав?

Далее.. Если это закладка, а требования это атрибуты, то атрибутов может быть ещё больше, скажем 50-100 , например. Они же в дерево не выстроятся , а будут лежать на форме закладки и получится мешанина, да?
(у меня сейчас под рукой нет Калибера — проверить не могу, поэтому вспоминаю его ГУИ на память, насколько успел попользовать — чуть-чуть).

И если таким образом распределять требования, т.е. часть в проекте (в раскрытых книжечках), часть в виде атрибутов на закладках, то это же каша получится? Ведь Калибер, требованиями считает ноды TreeView, так ведь? А значит закладка — это уже не объект, а её атрибуты, это уже не требования, так ведь? (блин проверить не могу до понедельника). И соответственно это я не смогу полноценно получить отчеты, посмотреть матрицу взаимосвязей, т.к. матрица будет показывать связи между требованиями, а не атрибутами закладок. Т.е. это будет уродливое приспособление данной задачи под конкретные возможности используемой программы управления требованиями.
Где я не прав?

PS
Я потихоньку начинаю въезжать какие части Колибера для чего можно и нужно использовать. Поэтому спасибо за ответы на вопросы. Если я узнаю все что меня интересует возможно я пойму где я неправильно представляю себе реализацию задачи. (или убедюсь , что задача сформулирована верно и её можно решить средствами, а я просто не умею ими пользоваться).

PPS
Господа, не один же Сергей занимается управлением требованиями и рисками — присоединяйтесь к обсуждению, расскажите, как и кого такие вещи сделаны, что используете! Не стесняйтесь!
Не могу же я быть один, которого волнуют такие проблемы и тем более не могу я быть первым кто пытается разложить систему требований в ту структуру с линками, что я обрисовывал выше. Может кто-то уже проходил по такому пути и нашел выход — поделитесь, сделайте человечество грамотнее на ещё одного человека!

Здравствуйте, Евгений,

СО>>"СПИНКА и СИДАЛИЩЕ", с моей точки зрения, должны быть custom-"закладками" (по аналогии с закладкой "Дизайн" на моей копии экрана) со своими атрибутами (так как и спинка и сидалище у кресла есть всегда — а то как-то неудобно ездить, если чего нет . Эти закладки будут всегда у КРЕСЛА, а параметры требований на закладках будут/могут быть специфичны для конкретной модели кресла, причем при их первичном определении можно задать что они будут "наследуемыми" с точки зрения значения по-умолчанию.

ЩЕ>ОК. пусть будут закладки.. НО ведь этих закладок может быть очень много.. Это же будет как минимум неудобно ими пользоваться. Хотя бы если их количество зашкалит за 20. Или я не прав?

Я привел этот пример как альтернативу иерархическому представлению _в_данном_конкретном_кресловом_случае .
Никто не мешает детализировать:
Кресло
-спинка
-сидалище

Аналогия (попробуйте представить как на функц. требования будет раскладываться соотв. use case):
продажа
-обработка заказа
-выставление счета

(для приведенного примера use case это не 100% ответ, а всего-лишь один из вариантов детализации)

ЩЕ>Далее.. Если это закладка, а требования это атрибуты, то атрибутов может быть ещё больше, скажем 50-100 , например. Они же в дерево не выстроятся , а будут лежать на форме закладки и получится мешанина, да?
см. выше — все зависит от контекста
если поставщик спинки — один на заводе. а сидалища — другой, я бы однозначно выбирал вариант с стрибутами, сгруппированными на закладках.

Все зависит от степени детализации — что есть "комплектующее" — кресло или, например, его спинка.

ЩЕ>И если таким образом распределять требования, т.е. часть в проекте (в раскрытых книжечках), часть в виде атрибутов на закладках, то это же каша получится? Ведь Калибер, требованиями считает ноды TreeView, так ведь? А значит закладка — это уже не объект, а её атрибуты, это уже не требования, так ведь? (блин проверить не могу до понедельника).
все правильно, поэтому я и заговорил о степени детализации ("атомарности" комплектующих).

ЩЕ>И, соответственно, это я не смогу полноценно получить отчеты, посмотреть матрицу взаимосвязей, т.к. матрица будет показывать связи между требованиями, а не атрибутами закладок.

верно.

ЩЕ>Т.е. это будет уродливое приспособление данной задачи под конкретные возможности используемой программы управления требованиями.

может быть (а может и нет, если Вы видели как консультанты настраивают SAP или какуюлибо другую ERP

ЩЕ>Где я не прав?
в том то и дело что Вы правы и универсальных ответов — нет. есть обсуждение возможных путей решения задачи. Я для выбора более эффективного пути необходимо больше информации:
1. эту систему будет использовать производитель автомобилей для определения конкретных моделей?
2. эту систему будет использовать автодилер для заказа комплектации?
и т.п.
выбор даже из этих двух вариантов (кто будет пользователем системы) будет накладывать различные ограничения и приоритеты на возможный путь решения задачи.


С уважением,
Сергей

P.S. ЩЕ>PS
ЩЕ>Я потихоньку начинаю въезжать какие части Колибера для чего можно и нужно использовать.

Я Вам искренне завидую , потому как при каждом новом обсуждении открываю возможные способы его применения и больше узнаю о том, как отличается даже в похожих проектах ответ на вопрос "чего хочет пользователь" (поверьте, это другое кино )

Здравствуйте, Щербатов Евгений, Вы писали:


ЩЕ>Этот проект состоит из бизнес объектов и приложений, которые собираются из этих бизнес объектов.
ЩЕ>Мы имеем объект КРЕСЛО
ЩЕ>и приложения ЛЕГКОВОЕ АВТО и МАРШРУТКА :
К вопросу о визуальном представлении трейсов (в Вашем прототипе UI [link]) в Caliber.

Вот как выглядит трейс из моего примера на другой закладке:


С уважением,
Сергей

В целом интересная идея по поводу организации требований/свойств, но возникли у меня такие вот соображения.

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

Теперь две замеченные мною проблемы данного подхода.

1. Мы не можем допускать сужение списка требований/свойств в зависимости от контекста использования. Мы должны использовать все ранее определённые требования/свойства, а также добавлять новые. Удалять же «лишние» — это путь к анафеме!
Пример.
1. Самолёт должен:
1.1. Взлетать
1.2. Лететь
1.3. Производить посадку
1.4. Перевозить пассажиров
1.5. Иметь салон первого класса на 100 пассажиров и салон бизнес-класса на 400 пассажиров.
1.6. Обладать возможностью обнаружения целей по полученным координатам или путём самостоятельного поиска, определения государственной принадлежности обнаруженной цели, одновременного сопровождения до 14 целей и одновременного обстрела трех целей двумя ракетами средней дальности в условиях радиоэлектронного противодействия противника.
1.7. Величина максимально допустимых перегрузок составляет 10g.

2. Пассажирский самолёт должен:
2.1. Взлетать
2.2. Лететь
2.3. Производить посадку
2.4. Перевозить пассажиров
2.5. Иметь салон первого класса на 100 пассажиров и салон бизнес-класса на 400 пассажиров.

3. Истребитель должен:
3.1. Взлетать
3.2. Лететь
3.3. Производить посадку
3.4. Обладать возможностью обнаружения целей по полученным координатам или путём самостоятельного поиска, определения государственной принадлежности обнаруженной цели, одновременного сопровождения до 14 целей и одновременного обстрела трех целей двумя ракетами средней дальности в условиях радиоэлектронного противодействия противника.
3.5. Величина максимально допустимых перегрузок составляет 10g.

Вопрос: должен ли пассажирский самолёт реализовывать обстрел вражеского самолёта ракетами средней дальности? Сколько пассажиров должно размещаться в салоне первого класса истребителя?
В нашем случае, чтобы корректно определить истребитель, прийдется указать, что требования 1.4 и 1.5 не являются требованиям в контексте истребителя.
При определении новых терминов на основании базовых должно производиться уточнение, но не снижение точности. В этом отношении возникает ассоциация с принципом подстановки Лискоу. Да и изменение значений уже определённых свойств приведёт к нарушению принципа открытия-закрытия.

Еще пример
1. Объект «Бутылка пива»
1.1. Свойства
1.1.1. Уталяет жажду
1.1.2. Не приводит к немедленной гибели

2. Приложение «Купить пива»
2.1. Объект «Бутылка пива»
2.1.1. Свойства
2.1.1.1. Уталяет жажду
Вот я и говорю, что удаление требования/свойства может привести к фатальным последствиям

2. Похоже, что в линках смысла нет.

1. Кресло
1.1. Кресло должно быть.
1.2. Кресло должно быть красивым.
1.3. Кресло должно быть мягким.
1.4. Кресло должно быть сделанным из натуральной кожи.
1.5. Кресло должно быть синим.

2. Луноход
2.1. Кресло должно быть
2.2. Кресло должно быть удобным.
2.3. Кресло должно быть зелёным.

3. Офисное кресло.
3.1. Кресло должно быть
3.2. Кресло должно быть мягким
3.3. Кресло должно быть сделанным из натуральной кожи
3.4. Кресло должно быть тёмно-серым.

Пусть и Луноход, и ОфисноеКресло ссылаются на Кресло. Но в чем смысл такой ссылки? Единственно корректная трактовка, приходящая мне в голову, такова: «Оба этих кресла обладают набором свойств и атрибутов, определённых для Кресла. При этом могут появляться новые атрибуты».
Поэтому хранение линков, пожалуй, пользы нам не принесёт. Точнее, мы можем при создании понятия сказать: кресло в контексте лунохода является представителем понятия Кресло. Пусть система тогда скопирует в луноходное кресло все определённые для Кресла требования/свойства. Но! Удаление этих требований/свойств недопустимо (см. выше). Тогда какой смысл хранить ссылку? Пожалуй, что никакого. Отсюда вывод: ссылки не нужны.

Т.о.мы можем говорить о следующих свойствах системы:
1. Система обеспечивает ведение списка понятий
2. Система обеспечивает ведение списка требований/свойств для понятия.
3. Понятия могут включать в себя другие понятия.
4. Агрегирующее понятие может уточнять включаемое путём добавления новых требований/свойств к включаемомоу. Удаление уже определённых требований/свойств не допускается.