#систематика /// Потребности, требования, ограничения
У надсистемы (по отношению в ЦС), а точнее у её, надсистемы, проектных ролей, есть какие-то потребности.
Эти потребности проявляются / преобразуются / выражаются как требования к ЦС.
И здесь важна их трассировка — связывание потребностей надистемы с требованиями к ЦС.
Когда формулируются требования, то они формулируются к ЦС без рассмотрения её, целевой системы, свойств и устройства. В таком случае ЦС рассматривается как чёрный ящик. Это предпочтительный вариант.
Требования обязательно должны быть увязаны с главной функцией системы.
Но если вместе с потребностями транслируются также требования к внутреннему устройству ЦС или принципам её работы, то тогда ЦС рассматривается как прозрачный ящик, и тогда требования, выдвигаемые к внутреннему устройству ЦС есть ограничения. Если такая ситуация случилась, то стоит торговаться насчёт ограничений, потому что это ограничения конструкторской свободы команды проекта, реализующей ЦС.
Все эти потребности, требования и ограничения являются описанием системы:
потрбености для над-системы и систем в окружении;
требования и ограничения для целевой системы.
Сначала рассматривают окружение и надсистему (главное действие) и лишь затем ЦС и цепочки обеспечения!
Потребности и требования обязательно трассируются, то есть сводятся "концы с концами".
Не должно оставаться потребностей, не переведенных в требования — потребности не будут удовлетворены, система не будет успешной.
Не должно быть требований, не относящихся к потребностям — это будет лишняя работа, которая может помешать другим требованиям и воплощению системы.
___
#потребности #требования #ограничения #чёрный_ящик #прозрачный_ящик #описание
У надсистемы (по отношению в ЦС), а точнее у её, надсистемы, проектных ролей, есть какие-то потребности.
Эти потребности проявляются / преобразуются / выражаются как требования к ЦС.
И здесь важна их трассировка — связывание потребностей надистемы с требованиями к ЦС.
Когда формулируются требования, то они формулируются к ЦС без рассмотрения её, целевой системы, свойств и устройства. В таком случае ЦС рассматривается как чёрный ящик. Это предпочтительный вариант.
Требования обязательно должны быть увязаны с главной функцией системы.
Но если вместе с потребностями транслируются также требования к внутреннему устройству ЦС или принципам её работы, то тогда ЦС рассматривается как прозрачный ящик, и тогда требования, выдвигаемые к внутреннему устройству ЦС есть ограничения. Если такая ситуация случилась, то стоит торговаться насчёт ограничений, потому что это ограничения конструкторской свободы команды проекта, реализующей ЦС.
Все эти потребности, требования и ограничения являются описанием системы:
потрбености для над-системы и систем в окружении;
требования и ограничения для целевой системы.
Сначала рассматривают окружение и надсистему (главное действие) и лишь затем ЦС и цепочки обеспечения!
Потребности и требования обязательно трассируются, то есть сводятся "концы с концами".
Не должно оставаться потребностей, не переведенных в требования — потребности не будут удовлетворены, система не будет успешной.
Не должно быть требований, не относящихся к потребностям — это будет лишняя работа, которая может помешать другим требованиям и воплощению системы.
___
#потребности #требования #ограничения #чёрный_ящик #прозрачный_ящик #описание
#систематика /// Альфы и подальфы
Альфа — это обязательная характеристика состояния системы. Этих альф несколько, как минимум, выделяются 7 альф:
- Возможность для системы
- Внешние проектные роли
- Описание системы
- Воплощение системы – целевая альфа
- Команда
- Технологии
- Метод
На альфах фокусируют внимание при воплощении системы, этот фокус позволяет не забыть о важных вещах.
Подальфы — это составные части каждой из альф. "Продвигая" подальфы в сторону воплощения, двигаются и основные альфы.
Пример: функциональное описание, модульное и конструктивное — это три подальфы для альфы "Описание системы". Даже если прогресс наблюдается только в отдельном модульном описании, то можно говорить, что основная альфа Описания всё же продвигается вперёд. Тут важно следить за равномерным процессом продвижения всех подальф в альфах и альф в системе / проекте системы.
____
#альфа #подальфа #описание
Альфа — это обязательная характеристика состояния системы. Этих альф несколько, как минимум, выделяются 7 альф:
- Возможность для системы
- Внешние проектные роли
- Описание системы
- Воплощение системы – целевая альфа
- Команда
- Технологии
- Метод
На альфах фокусируют внимание при воплощении системы, этот фокус позволяет не забыть о важных вещах.
Подальфы — это составные части каждой из альф. "Продвигая" подальфы в сторону воплощения, двигаются и основные альфы.
Пример: функциональное описание, модульное и конструктивное — это три подальфы для альфы "Описание системы". Даже если прогресс наблюдается только в отдельном модульном описании, то можно говорить, что основная альфа Описания всё же продвигается вперёд. Тут важно следить за равномерным процессом продвижения всех подальф в альфах и альф в системе / проекте системы.
____
#альфа #подальфа #описание
#систематика /// Коммуникация и описание
Описание всегда есть коммуникация. Даже если мы делаем описание для самих себя, то коммуницируем сами с собой из одной точки времени в другую.
___
#коммуникация #описание
Описание всегда есть коммуникация. Даже если мы делаем описание для самих себя, то коммуницируем сами с собой из одной точки времени в другую.
___
#коммуникация #описание
#систематика /// Коммуникация: нарратив и объяснение
Коммуникация / описание может быть в виде нарратива и в виде объяснения.
Нарратив — это последовательный рассказ о чём-то, часто в виде истории (storytelling). То есть когда для сообщения выбираются / придумываются герои в каком-то контексте и рассказывается их история. И это действительно лучше запоминается.
Нарратив звучит убедительно, совпадает с картиной мира потребителя сообщения. И чем больше совпадение с картиной мира, тем убедительнее нарратив.
Нарратив позволяет запомнить историю — она логична и (при хорошем нарративе) создается впечатление, что так и должно быть.
При этом в нарративе:
- Нет требований к заземлению, системные уровни и уровни абстракции описываются в свободной форме.
- Нет требований к предсказанию, то есть не строятся модели и прогнозы.
Нарратив не передает вместе с историей новые знания об обработке картин мира, он не объясняет, а лишь сообщает наблюдение. Для коммуникации в совместной работе, когда целью является создание чего-то, нарратив работает хуже, чем объяснение, так как объяснение позволяет рассказать как есть / как устроено, вместо того, чтобы придумывать истории о том, как это выглядит в виде рассказа.
Объяснение позволяет компактно
- уложить в голове картину интересующей части мира; картина будет описывать часть мира и давать представление о подобных частях мира в последствии, следовательно, можно:
- вывести из этой картины предстказательную модель;
- передать это понимание устройства части мира из своей головы в другие головы.
Одному наблюдению может соответствовать насколько разных объяснений. Пример:
Наблюдение — на холоде вода превращается в лёд.
Объяснение 1 — там где холод, там духи льда, и они превращают воду в лёд.
Объяснение 2 — при 0ºC вода меняет агрегатное состояние на твёрдое, кристаллы воды меняют своё подведение.
Объяснение 3 — когда холодно, вода не течет, чтобы не тратить энергию, а замерзает в лёд и сохраняет энергию для поддержания внутреннего тепла.
Объяснение можно оценить без экспериментальной проверки — эпистемически. Проверка будет полу-формальной, но с такой проверкой можно работать.
Объяснение позволяет строить причинно-следственную связи и генерировать предсказания.
У объяснения есть требования к заземлению, то есть к понижению уровня абстракции.
___
#описание #нарратив #объяснение #заземление
Коммуникация / описание может быть в виде нарратива и в виде объяснения.
Нарратив — это последовательный рассказ о чём-то, часто в виде истории (storytelling). То есть когда для сообщения выбираются / придумываются герои в каком-то контексте и рассказывается их история. И это действительно лучше запоминается.
Нарратив звучит убедительно, совпадает с картиной мира потребителя сообщения. И чем больше совпадение с картиной мира, тем убедительнее нарратив.
Нарратив позволяет запомнить историю — она логична и (при хорошем нарративе) создается впечатление, что так и должно быть.
При этом в нарративе:
- Нет требований к заземлению, системные уровни и уровни абстракции описываются в свободной форме.
- Нет требований к предсказанию, то есть не строятся модели и прогнозы.
Нарратив не передает вместе с историей новые знания об обработке картин мира, он не объясняет, а лишь сообщает наблюдение. Для коммуникации в совместной работе, когда целью является создание чего-то, нарратив работает хуже, чем объяснение, так как объяснение позволяет рассказать как есть / как устроено, вместо того, чтобы придумывать истории о том, как это выглядит в виде рассказа.
Объяснение позволяет компактно
- уложить в голове картину интересующей части мира; картина будет описывать часть мира и давать представление о подобных частях мира в последствии, следовательно, можно:
- вывести из этой картины предстказательную модель;
- передать это понимание устройства части мира из своей головы в другие головы.
Одному наблюдению может соответствовать насколько разных объяснений. Пример:
Наблюдение — на холоде вода превращается в лёд.
Объяснение 1 — там где холод, там духи льда, и они превращают воду в лёд.
Объяснение 2 — при 0ºC вода меняет агрегатное состояние на твёрдое, кристаллы воды меняют своё подведение.
Объяснение 3 — когда холодно, вода не течет, чтобы не тратить энергию, а замерзает в лёд и сохраняет энергию для поддержания внутреннего тепла.
Объяснение можно оценить без экспериментальной проверки — эпистемически. Проверка будет полу-формальной, но с такой проверкой можно работать.
Объяснение позволяет строить причинно-следственную связи и генерировать предсказания.
У объяснения есть требования к заземлению, то есть к понижению уровня абстракции.
___
#описание #нарратив #объяснение #заземление
#систематика /// Опровержение объяснения
Объяснения могут подвергаться опровержениям. И чем больше путей для опровержения объяснения, тем объяснение сильнее (при условии, что объяснение выдержало все эти опровержения, не было ими опровергнуто).
При рассмотрении опровержений удобно пользоваться моделью возможных и невозможных миров:
- возможные — которые не соответствуют объяснению
- невозможнные — которые противоречат объяснению
И чем больше невозможных миров отсекается объяснением, тем оно сильнее.
___
#описание #объяснение
Объяснения могут подвергаться опровержениям. И чем больше путей для опровержения объяснения, тем объяснение сильнее (при условии, что объяснение выдержало все эти опровержения, не было ими опровергнуто).
При рассмотрении опровержений удобно пользоваться моделью возможных и невозможных миров:
- возможные — которые не соответствуют объяснению
- невозможнные — которые противоречат объяснению
И чем больше невозможных миров отсекается объяснением, тем оно сильнее.
___
#описание #объяснение
#систематика /// Описание системы, разбиения
Описание — это то, как мы говорим о системе. Описание необходимо для обсуждения будущей системы, чтобы обсуждать модели-описания и договариваться для достижения непротиворечий.
Описание делается через рассмотрения, а их три основных:
- функциональное — по роли/функции: что части делают для реализации эмержентности / сервиса – это описание чёрного ящика – аналитиеская работа.
- модульное / конструктивное — по частям: из каких частей состоит система – это описание прозрачного ящика! – синтетическая работа.
- пространственное — по размещению в пространстве-времени: где-когда части физически находятся – тоже описание прозрачного ящика.
(вот эти три первых — это костяк архитектуры системы)
и множество дополнительных:
- финансы
- право
- этика
- етс
Важно: функциональное разбиения принято считать самым важным, и его можно назвать системным разбиением. Возникающий парадокс между системным разбиением по функциям и системным разбиением по часть-целое убирается с помощью трассировки функций к частям. Сделав такую трассировку вявляются уровни разбиения функционального и модульного, которые скорее всего не будут совпадать, и это нормально. Разбиения, как физические, так и функциональные, делаются вниманием.
Системы описываются частично в будущем — когда они воплощены / run-time. То есть описываются воплощения систем, всё остальное по сути и есть описание / design-time: от идеи - через описание - к воплощению. Поэтому в описаниях часто что-то отсутствует, так как это ещё не случилось, это в будущем, это ещё не выявлено.
Описываются требования и архитектура; они всегда есть, но могут быть еще не описаны и/или не выявлены.
Описание проявляется только в виде документации, то есть записанное, задокументированное на каком-то физическом носителе.
Каждая проектная роль делает своё описание системы — ролевое описание системы (viewpoint).
Система, пока она не воплощена, имеет лишь описание. Как только система выделена вниманием, то есть кто-то о ней думает, то эта система (она может ещё только появиться в будущем) имеет описание, то есть образ того, как она работает в виде воплощения. То есть описание системы возникает до воплощения. Чтобы работать над системаой, воплощать её, необходимо задокументировать описание. Исключение — когда система создаётся НЕ коллективно, и описание системы достаточно для одного человека, который мыслит и воплощает систему.
____
#описание #функция #модуль #размещение #трассировка #эмерджентность
Описание — это то, как мы говорим о системе. Описание необходимо для обсуждения будущей системы, чтобы обсуждать модели-описания и договариваться для достижения непротиворечий.
Описание делается через рассмотрения, а их три основных:
- функциональное — по роли/функции: что части делают для реализации эмержентности / сервиса – это описание чёрного ящика – аналитиеская работа.
- модульное / конструктивное — по частям: из каких частей состоит система – это описание прозрачного ящика! – синтетическая работа.
- пространственное — по размещению в пространстве-времени: где-когда части физически находятся – тоже описание прозрачного ящика.
(вот эти три первых — это костяк архитектуры системы)
и множество дополнительных:
- финансы
- право
- этика
- етс
Важно: функциональное разбиения принято считать самым важным, и его можно назвать системным разбиением. Возникающий парадокс между системным разбиением по функциям и системным разбиением по часть-целое убирается с помощью трассировки функций к частям. Сделав такую трассировку вявляются уровни разбиения функционального и модульного, которые скорее всего не будут совпадать, и это нормально. Разбиения, как физические, так и функциональные, делаются вниманием.
Системы описываются частично в будущем — когда они воплощены / run-time. То есть описываются воплощения систем, всё остальное по сути и есть описание / design-time: от идеи - через описание - к воплощению. Поэтому в описаниях часто что-то отсутствует, так как это ещё не случилось, это в будущем, это ещё не выявлено.
Описываются требования и архитектура; они всегда есть, но могут быть еще не описаны и/или не выявлены.
Описание проявляется только в виде документации, то есть записанное, задокументированное на каком-то физическом носителе.
Каждая проектная роль делает своё описание системы — ролевое описание системы (viewpoint).
Система, пока она не воплощена, имеет лишь описание. Как только система выделена вниманием, то есть кто-то о ней думает, то эта система (она может ещё только появиться в будущем) имеет описание, то есть образ того, как она работает в виде воплощения. То есть описание системы возникает до воплощения. Чтобы работать над системаой, воплощать её, необходимо задокументировать описание. Исключение — когда система создаётся НЕ коллективно, и описание системы достаточно для одного человека, который мыслит и воплощает систему.
____
#описание #функция #модуль #размещение #трассировка #эмерджентность
#систематика /// Описание и требования к нему
К описанию бывают требования двух видов
- Требования к формату описания
- содержанию — запрос на описание части физического мира, ограниченного чем-то
- языку — как выделяются объекты из фона и какими словами обозначаются
- нотации
- Требования к цели — запрос на описание, чтобы агент А по описанию сделал действие N
в этом случае надо догадываться:
- сколько на самом деле нужно описаний, так как "чтобы агент А сделал действие N" может наступить только при участии других агентов, для которых тоже потребуется описание.
- на каком языке и нотации требуется описание
- что должно являться содержанием описания, то есть к какой части мира описание реферирует
Эти виды требований могут и комбинироваться, а также скорее всего каждый из нас тяготеет к одному из видов как более комфортным и понятным или привычным требованиям.
Важно уметь выявлять одно из другого — на основе запроса по формату надо уметь выявить или предположить цель применения этого описания, а на основе запрос по цели надо уметь выявить требования по формату: содержание-язык-нотация.
Часто требования к описанию на бытовом уровне выдвигаются только как требования к содержанию.
И тогда надо догадаться:
- на каком языке описывать? — язык уже где-то закреплен или его надо выявить / снять с речи и применить?
- насколько детально описывать — насколько мелкий самый мелкий наш объект внимания в этом описнаии? Это системные уровни в системном разбиении часть-целое — здесь речь про масштаб рассмотрения, позиция в спектер zoom in - zoom out рассмотрения.
- насколько конкретно описывать — вот тут надо предполагать, что получаетнль описания будет с описанием делать — выявлять общие законы или рассматривать конкретную описываемую часть мира; это про выбор предмета описания — класс или экземпляр.
Раз к описанию есть требования, то есть и потребности, из которых эти требования проистекают, а значит у описания обязательно должна быть цель — соответствующая цели того, кто запрашивает описание. Запрашиваемое описание — это про предпочтение в интересе той роли, которая запрашивает это описание.
___
#описание #часть_целое #системное_разбиение #требования #нотация #роли #интерес
К описанию бывают требования двух видов
- Требования к формату описания
- содержанию — запрос на описание части физического мира, ограниченного чем-то
- языку — как выделяются объекты из фона и какими словами обозначаются
- нотации
- Требования к цели — запрос на описание, чтобы агент А по описанию сделал действие N
в этом случае надо догадываться:
- сколько на самом деле нужно описаний, так как "чтобы агент А сделал действие N" может наступить только при участии других агентов, для которых тоже потребуется описание.
- на каком языке и нотации требуется описание
- что должно являться содержанием описания, то есть к какой части мира описание реферирует
Эти виды требований могут и комбинироваться, а также скорее всего каждый из нас тяготеет к одному из видов как более комфортным и понятным или привычным требованиям.
Важно уметь выявлять одно из другого — на основе запроса по формату надо уметь выявить или предположить цель применения этого описания, а на основе запрос по цели надо уметь выявить требования по формату: содержание-язык-нотация.
Часто требования к описанию на бытовом уровне выдвигаются только как требования к содержанию.
И тогда надо догадаться:
- на каком языке описывать? — язык уже где-то закреплен или его надо выявить / снять с речи и применить?
- насколько детально описывать — насколько мелкий самый мелкий наш объект внимания в этом описнаии? Это системные уровни в системном разбиении часть-целое — здесь речь про масштаб рассмотрения, позиция в спектер zoom in - zoom out рассмотрения.
- насколько конкретно описывать — вот тут надо предполагать, что получаетнль описания будет с описанием делать — выявлять общие законы или рассматривать конкретную описываемую часть мира; это про выбор предмета описания — класс или экземпляр.
Раз к описанию есть требования, то есть и потребности, из которых эти требования проистекают, а значит у описания обязательно должна быть цель — соответствующая цели того, кто запрашивает описание. Запрашиваемое описание — это про предпочтение в интересе той роли, которая запрашивает это описание.
___
#описание #часть_целое #системное_разбиение #требования #нотация #роли #интерес
#инфоарх /// Таблица
Таблица это текст со связями объектов.
Если простой линейный текст это одномерная структура, то таблица двумерная, что позволяет просматривать связи между описываемыми объектами.
Таблица — нотация для передачи связей объектов.
Связи также можно представить в виде схемоидов, схем, диаграмм, майнд-карт, etc, но такие представления могут не передавать полностью модель отношений, вырывая из контекста только те отношения и только те объекты, которые показаны на схеме.
___
#описание #таблица #нотация #схема #диаграмма
Таблица это текст со связями объектов.
Если простой линейный текст это одномерная структура, то таблица двумерная, что позволяет просматривать связи между описываемыми объектами.
Таблица — нотация для передачи связей объектов.
Связи также можно представить в виде схемоидов, схем, диаграмм, майнд-карт, etc, но такие представления могут не передавать полностью модель отношений, вырывая из контекста только те отношения и только те объекты, которые показаны на схеме.
___
#описание #таблица #нотация #схема #диаграмма
#систематика /// Системная инженерия
Системная инженерия есть трансдисциплинарный подход и метод создания успешных систем. Успешная система есть функционирующая система, в которой удовлетворены интересы всех проектных ролей.
Системная инженерия рассматривается только как гибрид анализа и последующего синтеза, понимания-для-созидания, где конечной целью является воплощение успешной системы, то есть результат в физическом мире
© "По карте не ходят, меню не едят, на чертежах не летают, код не хранит значения переменных"
Компьютерная программа — описание системы, воплощением же будет состояние программы в ходе её выполнения на компьютере.
UI — описание того, что видит пользователь, воплощение — состояние системы в момент когда пользователь видит UI и работает с ним.
UX — описание действий пользователя и их последствий, воплощение — массив всех конкретных действий каждого пользователя и последствия действий для него.
В случае разработки софта можно представить весь процесс цепочки: все программы, связанные друг с другом (и часто взвимодействующие также с людьми в оргпроцесссах) меняют описание в их базах данных, и все для того, чтобы в конце, как итоговое изменение физического мира, пользователю доставили материальную коробку с товаром из интернет магазина или пустили в зал кинотеатра или на борт самолёта.
Также полезно при проектировании и разработке системы держать в уме само воплощение, то есть представлять систему как будето она уже существует. И если что-то мешает это представить, то там и надо работать, туда направлять фокус.
___
#воплощение #описание
Системная инженерия есть трансдисциплинарный подход и метод создания успешных систем. Успешная система есть функционирующая система, в которой удовлетворены интересы всех проектных ролей.
Системная инженерия рассматривается только как гибрид анализа и последующего синтеза, понимания-для-созидания, где конечной целью является воплощение успешной системы, то есть результат в физическом мире
© "По карте не ходят, меню не едят, на чертежах не летают, код не хранит значения переменных"
Компьютерная программа — описание системы, воплощением же будет состояние программы в ходе её выполнения на компьютере.
UI — описание того, что видит пользователь, воплощение — состояние системы в момент когда пользователь видит UI и работает с ним.
UX — описание действий пользователя и их последствий, воплощение — массив всех конкретных действий каждого пользователя и последствия действий для него.
В случае разработки софта можно представить весь процесс цепочки: все программы, связанные друг с другом (и часто взвимодействующие также с людьми в оргпроцесссах) меняют описание в их базах данных, и все для того, чтобы в конце, как итоговое изменение физического мира, пользователю доставили материальную коробку с товаром из интернет магазина или пустили в зал кинотеатра или на борт самолёта.
Также полезно при проектировании и разработке системы держать в уме само воплощение, то есть представлять систему как будето она уже существует. И если что-то мешает это представить, то там и надо работать, туда направлять фокус.
___
#воплощение #описание
#систематика /// Конфигурация
Конфигурация есть текущее воплощение системы, её части на данный момент плюс их описание.
Конфигурация должна быть обязательно описана и задокументирована; обычно это выражается в описании релизов, версий, состояний milestone, етс.
Несоответствия реальности и описаний конфигурации — конфигурационные коллизии; это плохо, это много лишней работы.
Поэтому необходимо отслеживать соответствие воплощения системы и её описания, осуществлять управление конфигурацией.
____
#конфигурация #воплощение #описание
Конфигурация есть текущее воплощение системы, её части на данный момент плюс их описание.
Конфигурация должна быть обязательно описана и задокументирована; обычно это выражается в описании релизов, версий, состояний milestone, етс.
Несоответствия реальности и описаний конфигурации — конфигурационные коллизии; это плохо, это много лишней работы.
Поэтому необходимо отслеживать соответствие воплощения системы и её описания, осуществлять управление конфигурацией.
____
#конфигурация #воплощение #описание