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

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

уууу, это порождает другие проблемы. является ли XML базой данных? но не будем.

Предлагаю считать - xml однозначно конвертируется в реляционную СУБД и наоборот. Например bpm, bpmc, основанные на xml,  поддерживает bizagi modeler (хотя bizagi suite работает с  СУБД)

Предлагаю считать - xml однозначно конвертируется в реляционную СУБД и наоборот. Например bpm, bpmc, основанные на xml,  поддерживает bizagi modeler (хотя bizagi suite работает с  СУБД)

ну вооот. а теперь давайте посмотрим, в чём хранит документ Word

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

Если они связаны, значит освоение практик надо дополнять освоением кнопочек. А освоение кнопочек изучением методик. Одно без другого не имеет смысла, а соотношение ингредиентов не так важно.

В чем смысл этого противопоставления?

В чем смысл этого противопоставления?

в том, что я регулярно вижу попытки людей искать там, где светло (инструменты), а не там, где потеряли (методики).

в том, что я регулярно вижу попытки людей искать там, где светло (инструменты), а не там, где потеряли (методики).

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

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

ну вооот. а теперь давайте посмотрим, в чём хранит документ Word

Docx - это упакованный xml.
https://habrahabr.ru/post/138666/

Но свойства этого формата используются только для отражения форматирования текста.
Весь текст размещается в тэгах типа

<w:t>{TEXT}</w:t>

При этом конструкций, отражающие семантические связи, между тэгами нет.

А если брать тот же xpdl или bpel, то они вообще исполняемы с помощью интерпретатора.

Тем не менее в критерий инструмент/не инструмент надо внести уточнение. Речь нужно вести не просто о базе данных как о атрибуте СУТ, а именно о репозитарии.

Нормальный процесс развития.

Для анекдота.

Если не знаешь ни методик, ни инструмента, то неважно с чего начинать.

Обычно перед тем, как приступить к практике, изучают теорию. Как минимум - технику безопасности.
Но если учить некому, опыта обучения вообще чему бы то ни было нет, даже пословицы вроде "не зная броду..." неизвестны - тогда да, начинать можно откуда угодно. Выжившие, возможно, чему-нибудь научатся.

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

А искать проще там, где светло. То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора ("да лан, не подкалывай - это же синонимы!").

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

А искать проще там, где светло. То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора

Я не хочу вступать в защиту аналитиков, которые не знают разницы между справочником и классификатором.  Но я хочу сказать, что это не то,  что приводит к наиболее серьезным и классическим проблемам на проекте.
А вот неумение нормально работать на этапе выявления зл / требований (elicitation по Вигерсу) приводит действительно к серьезным долгоиграющим проблемам на проекте или в продукте. Кажется, что аналитиков с высоким скилом выявления мне встречалось гораздо меньше тех, которые знают «разницу между справочником и классификатором».

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

2 Humbert
Этап выявления в проекте идет всегда вообще самым первым и базируется на большим количестве методик. Именно методики, а не инструменты рулят на этом этапе. 

PS
Предположу (опираясь на то, что я видел и знаю об аналитике в заказной разработке в РФ), что основная проблема у нас в проявлении нигилизма к «выявлению».
С одной стороны, никто не хочет инвестировать в «выявление».
С другой, когда проект завален или «условно успешен», все проблемы объясняются «неадекватным заказчиком», «недостаточным бюджетом», «слабым менеджментом»,  но никто никогда не говорит что «мы мало времени уделили выявлению требований или у нас были проблемы в методиках выявления».

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

Это просто пример про "общую", а не "инструментальную" квалификацию.

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

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

Не "Платон" часом ?

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

Ни как не могу себе представить, как должен  должен выглядеть весь процесс разработки, чтоб «незнание разницы между классификатором и справочником» приводило к падению системы на 2 для + реворк на 2 месяца …  Я не пытаюсь подвергнуть сомнению Ваши слова, но просто пытаюсь представить.

Не "Платон" часом ?

Нет, у гайцов лет 5 назад.

Ни как не могу себе представить, как должен  должен выглядеть весь процесс разработки,

Да как везде. Просто имело место сочетание сразу нескольких факторов: сроки жали, часть проектирования поручили архитектору, а тот перепоручил программистам, квалифицированными кадрами проверить уже не успевали. В смысле, проверить бы еще успели (если бы удалось заставить программистов описать содеянное), а вот переделать - нет.

Ну ничего, как гласит известный афоризм, "Чтобы сделать работу как следует, времени всегда не хватает; но на то, чтобы ее переделать, время находится".

Просто имело место сочетание сразу нескольких факторов: сроки жали, часть проектирования поручили архитектору, а тот перепоручил программистам, квалифицированными кадрами проверить уже не успевали.

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

То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора ("да лан, не подкалывай - это же синонимы!").

А джира какое имеет отношение к инструментарию аналитика? Это багтрекер - инструмент техподдержки. Может даже инструмент управления требованиями, но уж никак не их разработки.

Не годятся примеры совсем. Был бы это пример аналитика, умеющего прекрасно строить IDEF0 в bpWin, но абсолютно не понимающего в анализе... Вот тогда бы я усомнился в том, что хороший уровень владения инструментарием может быть получен без хорошего уровня владения методологией.

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

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

Это как учет на бумажке вести или в ERP. Причем если EA с точки зрения управления требованиями - это что-то типа 1С ранних версий, то тот же Cradle - это SAP.

Думаю в ближайшее время уровень СУТ может выйти вообще на принципиально новый уровень, так как именно СУТ является идеальной площадкой для применения искусственного интеллекта. Мне понравилась идея Юлии Мадорской рассматривать матрицу трассировки как онтологическую модель. Если посмотреть на Loader из состава Cradle, который обеспечивает бесшовную интеграцию между документальным представлением требований и их репозитарием в Cradle, то легко увидеть, что следующим шагом будет семантический разбор нормативной и документальной базы проекта, автоматическое формирование глоссариев и онтологий, автоматическая викификация загружаемых документов.
При таких тенденциях заниматься разработкой требований без серьезного инструментария будет невозможно -  по сути разработка сведется к согласованию онтологий предметной области и разрабатываемой системы.

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

Да, вы расскажите пожалуйста, что именно на вас наваливается.