http://blog.shumoos.com/archives/308

Материал готовился для аналитического онлайн-марафона «Проектные истории» http://school.system-analysis.ru/project-stories/, но не вписался по времени. В итоге после доклада все равно возник вопрос о трассировке требований разного уровня.

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

Сергей, в статье представлен результат применения модели. Какова модель трассировки?

Да и матрица обычно выглядит как-то иначе, а у тебя скорее граф, причем ориентированный.

Какова модель трассировки?

Вероятно, я не понимаю вопроса. Попробую ответить как понял. Это модель перехода от требования бизнеса (государства, ...) к требованиям конкретного Конструкторского Бюро. Ну, или к проектной команде.

Да и матрица обычно выглядит как-то иначе, а у тебя скорее граф, причем ориентированный.

Точно. Матрица устаревшее, но к сожалению устоявшееся понятие. Трассировка требований - это очевидно граф. Причем неориентированный. В представленной модели нет петель положительной обратной связи, но  в реальных проектах они вполне могут встречаться.

То что предыдущие исследователи использовали термин "матрица" - это их проблемы.
Точно также устаревшая модель управления по риск оптимумам является частным случаем "особой причины вариаций" карт Шухарта.
RUP предложил термин матрица. Но это не соответствует практике. Давайте двигаться дальше.
"Матрица трассировки"  такая же неполная модель, как диаграмма Исикавы (Дерево Текущей Реальности гораздо полнее).

Был этот мир глубокой тьмой окутан.
Да будет свет! И вот явился Ньютон.

Но сатана недолго ждал реванша.
Пришел Эйнштейн - и стало все, как раньше.

Вероятно, я не понимаю вопроса.

Модель трассировки - это основные сущности или элементы такой модели и типы связей (направления и их смысл).

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

Вот, что я имел в виду.

сообщение устарело

Например, дерево целей типично задает модель выражаемую строгим иерархическим деревом.

Голдратт полагает, что все таки двунаправленный граф. Или я его неправильно понял.

Модель трассировки - это основные сущности или элементы такой модели и типы связей (направления и их смысл).

Предложенная схема "читается" следующим образом:

"Танк должен иметь возможность сопровождения мотопехоты на марше, так как он должен соответствовать теории глубокой операции."
"Танк должен иметь скорость по шоссе 40-50 км/ч, так как он должен иметь возможность сопровождения мотопехоты на марше [и скорость передвижения мотопехоты по большинству современных дорог - 40-50 км/ч]"
Замечу, что при изменении дорожной инфраструктуры более низкоуровневое требование о скорости подлежит изменению, а более высокоуровневое о сопровождении на марше не изменится.

Связей, наверное, должно быть больше.

Например, между удельной мощностью двигателя и дешевизной производства/обслуживания (ибо экстремально высокие значения для текущего уровня производства явно не удешевят изделия).

Или связь между калибром орудия и массой.

Ну а в целом - нормальная такая трассировка. В таком (графическом) виде применима при очень небольшом количестве требований и взаимосвязей, оптимально - на уровне презентации. При детализации превращается в нечитаемую паутину.

Связей, наверное, должно быть больше.

Например, между удельной мощностью двигателя и дешевизной производства/обслуживания (ибо экстремально высокие значения для текущего уровня производства явно не удешевят изделия).

И связей больше и квадратиков больше.
1. Для иллюстрации подхода "правильная схема" была не нужна.
2. Для иллюстрации подхода "правильная схема" была вредна. То,  что Леонид нашел ошибку в схеме как раз и показывает, зачем она нужна. Вот если бы никто не нашел ошибки, то это означало бы, что она не нужна.

Ну а в целом - нормальная такая трассировка. В таком (графическом) виде применима при очень небольшом количестве требований и взаимосвязей, оптимально - на уровне презентации. При детализации превращается в нечитаемую паутину.

На уровне слайда такую схему хорошо делать, если вы собираетесь кому-то что-то втюхать. Ибо для "улучшения" восприятия, вы уберете все неприятные моменты.

Для анализа нужно работать с полной схемой. И проблема тут не в том, что она нечитаема. Читаема, просто времени нужно несколько больше.
Проблема в отрицательной обратной связи в нашей индустрии. За нахождение ошибок в таких схемах "тестировщику" создавали неприемлемые условия и он уходил. Теперь никто такие схемы не анализирует.
Итог: "Даже если вам повезет, и среди тысячи сотрудников вашей фирмы найдется кто-то, способный такую схему нарисовать, то прочитать ее будет некому. Второго сотрудника такой квалификации ваша фирма себе позволить не может." Если нужен пример, он есть у меня. Фирма 5000+ сотрудников.

сообщение устарело

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

Кто писал про соответствующий инструмент, коллеги? Я не вижу что-то.

И да, рисовать ориентированный граф и писать, что он неориентированный, как-то не очень хорошо :-)

Сергей этого не говорил.
У него было 2 утверждения:
1.  "Я нарисовал матрицу трассировок."
2.  "Трассировка требований - это очевидно граф. Причем неориентированный."
"Я нарисовал неориентированный граф" — он не говорил.
Граф у него получился ориентированный граф лишь потому, что Flying Logic не даёт создавать других. Так что стрелками можно пренебречь.

И я скажу еще больше: те, кто грамотно используют IDEF0 имеют даже лучшую трассировку, чем та, что нарисована на Вашей схеме и как-то проблем с чтением IDEF0 чаще всего не возникает у людей самой разной специализации.

А по сведениям организационных консультантов, которые работают с собственниками и руководителями малого и среднего бизнеса — вполне так себе возникают: http://www.mrybakov.ru/order/business/business_processes/more_info/index.php?sphrase_id=81681

Собственники и руководители — не самая последняя аудитория, на которую стоит ориентироваться, не правда ли?

У организационных консультантов, которые работают с собственниками и руководителями малого и среднего бизнеса основная проблема в том, что собственники и руководители малого и среднего бизнеса не особо то с ними и работают.

В принципе. А не потому, что они пользуются или не пользуются какой-то там нотацией

А при чём тут проблемы консультантов?

Речь была о применимости IDEF0 моделей.

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

Если брать мое мнение, то IDEF0 вполне может вернуться. Сейчас его практически вытеснил BPMN.  BPMN  отличная нотация и для as is, и для to be, и прототипирование на BPMS возможно, но в качестве нотации для выявления и фиксации функциональных и нефункциональных требований не подходит так, как IDEF0.

С другой стороны вклинивание  IDEF0 между описанием БП as is в BPMN и моделированием поведения системы в UML - это серьезное усложнение технологии.