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

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

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

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

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


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

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

Спасибо