Обсуждение

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

Фишка как раз в том, что практики инженерии требований и инженерии системной архитектуры имеют специфические артефакты, для которых "модели, чертежи, документация" лишь форма. А вот "конфигурация" и "изменения" -- это отдельные сущности. Я-то сортирую по дисциплинам (знаниевым областям). В определении дисциплин важны в том числе и наличие профессиональных организаций, и существование профильных подразделений на предприятиях, и профильных образовательных предметов. А твоя "матрица" сведется к наличию той или иной безродной семантической сетки, над которыми разве что заумные поисковые запросы нужно будет строить, чтобы вытащить консистентный кусок для использования в реальной ситуации. А вот когда перейдём от практик к процессам, тогда да, аспектные описания придётся сливать (aspect weaving), и там будет какой-то граф из работ, объектов работ, ролей и назначенных на них людей. Над упорядочиванием этого материала еще некоторое время придётся думать. Я хочу пока хотя бы устаканить терминологию и вытащить суть дела (scope).

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

Сущности -- требования, системная архитектура (которые даны нам не непосредственно, а в форме моделей и текстовых описаний. Требования и архитектура со всеми их моделями -- они как данные, могут быть многократно в разных форматах выражены). Конфигурация и изменения в Multi-D проекте, вестимо. Меня в этом постинге сейчас не это интересует, а тот консенсус, который намечается в разных профессиональных ассоциациях и реальных предпринятиях по поводу названий их знаниевых практик и претензии на scope этих практик. А с составом объектов этих практик и составом работ, а также способами их реализации в процессах мы разберемся на следующем такте. У меня в блоге ещё страницы не кончились :-)

"Требования и архитектура со всеми их моделями -- они как данные, могут быть многократно в разных форматах выражены)." Просто "требования" - это взгляд на артефакты, а не сущность. Архитектура - это требования для стадии проект. Сущность "предархитектурные требования" или "требования стейкхолдеров" действительно нужно вводить, без неё ряд сущностей неполный. Архитектура, проект, рабочка - это сущности, они действительно выражаются в формах моделей, документов, чертежей. "Конфигурация и изменения в Multi-D проекте, вестимо." Я спросил "чего", а не "где"! Консенсус в названиях - это вообще не про что, это про бирки. Не интересно, маркетинг. Но я не про состав, а про способы структуризации практик.

Да, я имел ввиду требования стейкхолдеров и требования к системе как набор сущностей из GORE (motivational), предмет инженерии требований (архитектура не является предметом инженерии требований, хотя и так можно подходить). Консенсус в названиях -- это тебе неинтересно, но есть и другие стейкхолдеры. Они без названий вообще не поймут, о чём речь. Кроме того, есть языковая семантическая линия рассуждений (по Витгенштейну), а есть чисто онтологическая "без названий с номерами". Чисто онтологическая не работоспособна без языковой работы. Люди в номерах не рассуждают. Перед любой работой с кодированием номерами нужно разбираться с названиями и сутью понятий. Multi-D проект -- это мегамодель по форме, проект по содержанию. Так понятней? :-) Из многочисленных способов структуризации практик меня в данном постинге интересует -- по дисциплинам (т.е. имеющих свои профессии в ВУЗах, профессиональные ассоциации, софтверные платформы, конференции). С другими способами структуризации я буду разбираться в других постингах. Структуризаций таких (таксономий) может быть множество, для разных целей.

С инженерией требований есть явное противоречие. С одной стороны, практики применяются итерационно, на всех уровнях и на протяжении всего ЖЦ. А описываемое тобой анкетирование стейкхолдеров и пр. явно применимо только на верхнем уровне и в начале ЖЦ, а потом ни для компонент, ни для перехода к проекту и рабочке - не используется. Не надо меня обвинять в онтологиях с номерами. Из того что я умею с ними работать вовсе не следует, что я предлагаю работать с ними во всех случаях. В данном случае я о том, что нужен гармонизированный человекочитаемый подход. Но никакая языковая работа не достигнет тут консенсуса в названиях, да ты его и не ищешь. тут можно победить только шагом в сторону - введя гармоничную терминологию для новой структуры разбиения. Я как раз предлагаю тебе задуматься над многомерным разбиением, вместо перечисления кучи древовидных альтернатив. Перейти к нескольким таксономиям дисциплин с множественным наследованием, если так понятнее. А про то, что именно находится под управлением конфигурацией и изменениями - по-прежнему непонятно.

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

Нет, работа со стейкхолдерами делается в ходе всего жизненного цикла. Во многих "методологиях разработки" (вариантах вида жизненного цикла) даже необходимо иметь "голос заказчика/пользователя" в команде разработчиков постоянно доступным от начала до самой приёмки-сдачи. Анкетирование и интервьюирование, включая такие форматы, как разговор с "голосом заказчика/пользователя" в ходе проектных сессий и производственных совещаний -- нормальная часть работы. К тому же есть огромное число разных других стейкхолдеров, и все изменения нужно заново проговаривать с ними всеми, улаживая неизбежные конфликты. Другое дело, что это системноинженерная практика, в рабочке её нетути, ибо рабочка -- это уже specialty engineering. При декомпозиции и переходе к системной инженерии компоненты системы "пользователем" по факту является системный архитектор надсистемы вкупе с этой надсистемы испытателем. Я считаю существенным сейчас выбор имён и терминологии. Я не возражаю, что у меня на данной стадии работы (замысел) не столько онтология, сколько терминология в смысле Совы. А то и вовсе набор прототипов :-) Разбиениями я как раз и хочу заняться, и очевидно, что там их множество (как и всегда). Но я не уверен, что там просто "множественное наследование". У меня есть некоторые мысли (типа взять картинки процессов формального выпуска из книжки Ватта и вставить в них содержательные процессы системной инженерии -- уж насколько это можно шаблонизировать в условиях кейс менеджмента), я попробую разные варианты. "Находится под управлением конфигурацией и изменениями" -- лучше бы игнорировать слово "управление", тогда и "под управлением" не нужно ничего искать. Но нужно выделить основные объекты работы, несомненно. Я как раз над этим думаю и пишу очередной более подробный текст.

Следует. Ибо онтология -- это про разделяемую нарезку реальности, а не просто про нарезку реальности. Недаром определения рекомендуют брать из словарей и стандартов, а не просто выдумывать их из головы. Ну, и я не хочу изобрести новый вариант управления конфигурацией пока, я хочу пока отмоделировать то, что уже изобретено и описано. Меня интересует нарезка на области знаний: для удобства преподавания, для удобства сбора нужной квалификации в каких-то подразделениях предприятия. Меня не только "просто моделирование" интересует, но и использование этих моделей. Я стараюсь сейчас больше заниматься функциональной стороной, а не конструкционной. Что там внутре -- это следующий шаг работы. А сейчас -- требования, выделение из мирового континуума инженерных знаний объекта (дисциплины) для проработки, функциональное определение и границы с другими предметами. Потом -- итерации (в выделенном куске ищутся основные виды объектов и виды операций, основные роли. Затем -- уточняются границы дисциплины, варианты её организационного оформления и способы обучения, компактного описания в guides и шаблонах практик для моделирования, затем по итогам корректируются объекты-работы-роли, сравнивается с тем, что обнаруживается в жизни и литературе, и т.д.). Нельзя объять необъятное. Нужно делать работу маленькими осмысленными частями. "Замысел" к тому же -- самая слабоформализуемая часть разработки, сейчас в этом "дисциплиностроении" у меня как раз "замысел" заканчивается.