Показаны записи 12641 - 12650 из 56266
Стейкхолдеры
Никаких инженерных проектов не происходит, если нет их выполняющих людей. Инженерные проекты затрагиваются самыми разными людьми, и инженерные проекты затрагивают самых разных людей. Эти люди могут быть как "одиночками", так и организованными в группы, в том числе организованные в группы с известным им распределением полномочий (организации). Эти люди, группы и организациии, которые затрагивают проект, или которых затрагивает проект, называются стейхколдерами (stakeholders/заинтересованные стороны. Перевод "заинтересованные лица" не так хорош, ибо этот термин закреплён в законодательстве за юридическими лицами и при общении с менеджерами-юристами и экономистами возможна путаница).
Стейкхолдеры -- это "действующие лица" как в театре) проекта, а исполнители этих ролей -- конкретные люди и организации. Мы назовём это "театральной метафорой", при работе со стейкхолдерами всегда нужно помнить формулировку из театральной программки: "действующие лица и исполнители". Нельзя путать "архитектора" и "Василия Петровича" -- так же нельзя, как нельзя путать "принца Гамлета" и исполняющего его роль "Василия Петровича".
Стейкхолдеры условно делятся на "внешних" и "членов команды". Стейкхолдеры дают возможности (opportunity) для проведения инженерного проекта: если
проект никого не затрагивает (никому не нужен), то его попросту невозможно делать. Если команда может делать проект, но пользователям он не нужен, то такого проекта не будет -- разве что члены команды будут работать бесплатно, и будут исполнителями также и в других ролей (инвесторов, владельцев, пользователей, клиентов и т.д.).
Стейкхолдеры требуют согласовать с ними определение системы (прежде всего требования -- определение системы как "чёрного ящика", ибо как устроена система внутри интересует отнюдь не всех стейкхолдеров) и используют (стейкхолдеры-пользователи) воплощение системы, ради создания которого и затевается инженерный проект.
Простейший рабочий продукт, отражающий альфу "стейкхолдеры" -- это список стейкхолдеров. Из информационных систем со стейкхолдерами работают CRM (customet relationship management).
Специально нет никаких особых дисциплин, которые позволяют работать со стейкхолдерами, но можно выделить:
● Конфликтологию (например, метод "принципиальных переговоров" или "гарвардский метод" -- найдите в Сети литературу по этому вопросу), чтобы снимать противоречия между требованиями различных стейкхолдеров.
● Коммуникации (communications) для налаживания продуктивного диалога со стейкхолдерами
● Особые техники представления стейкхолдеров (например, "метод персонажа" из книжки Алана Купера "Психбольница в руках пациентов" --
http://rutracker.org/forum/viewtopic.php?t=1227489, который обобщается с пользователей на любых других стейкхолдеров --
http://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1
%8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0%
BE%D0%BD%D0%B5%D1%80).
Никаких инженерных проектов не происходит, если нет их выполняющих людей. Инженерные проекты затрагиваются самыми разными людьми, и инженерные проекты затрагивают самых разных людей. Эти люди могут быть как "одиночками", так и организованными в группы, в том числе организованные в группы с известным им распределением полномочий (организации). Эти люди, группы и организациии, которые затрагивают проект, или которых затрагивает проект, называются стейхколдерами (stakeholders/заинтересованные стороны. Перевод "заинтересованные лица" не так хорош, ибо этот термин закреплён в законодательстве за юридическими лицами и при общении с менеджерами-юристами и экономистами возможна путаница).
Стейкхолдеры -- это "действующие лица" как в театре) проекта, а исполнители этих ролей -- конкретные люди и организации. Мы назовём это "театральной метафорой", при работе со стейкхолдерами всегда нужно помнить формулировку из театральной программки: "действующие лица и исполнители". Нельзя путать "архитектора" и "Василия Петровича" -- так же нельзя, как нельзя путать "принца Гамлета" и исполняющего его роль "Василия Петровича".
Стейкхолдеры условно делятся на "внешних" и "членов команды". Стейкхолдеры дают возможности (opportunity) для проведения инженерного проекта: если
проект никого не затрагивает (никому не нужен), то его попросту невозможно делать. Если команда может делать проект, но пользователям он не нужен, то такого проекта не будет -- разве что члены команды будут работать бесплатно, и будут исполнителями также и в других ролей (инвесторов, владельцев, пользователей, клиентов и т.д.).
Стейкхолдеры требуют согласовать с ними определение системы (прежде всего требования -- определение системы как "чёрного ящика", ибо как устроена система внутри интересует отнюдь не всех стейкхолдеров) и используют (стейкхолдеры-пользователи) воплощение системы, ради создания которого и затевается инженерный проект.
Простейший рабочий продукт, отражающий альфу "стейкхолдеры" -- это список стейкхолдеров. Из информационных систем со стейкхолдерами работают CRM (customet relationship management).
Специально нет никаких особых дисциплин, которые позволяют работать со стейкхолдерами, но можно выделить:
● Конфликтологию (например, метод "принципиальных переговоров" или "гарвардский метод" -- найдите в Сети литературу по этому вопросу), чтобы снимать противоречия между требованиями различных стейкхолдеров.
● Коммуникации (communications) для налаживания продуктивного диалога со стейкхолдерами
● Особые техники представления стейкхолдеров (например, "метод персонажа" из книжки Алана Купера "Психбольница в руках пациентов" --
http://rutracker.org/forum/viewtopic.php?t=1227489, который обобщается с пользователей на любых других стейкхолдеров --
http://praxos.ru/index.php/%D0%98%D0%B4%D0%B5%D0%B0%D0%BB%D1
%8C%D0%BD%D1%8B%D0%B9%D0%90%D0%BA%D1%86%D0%B8%D0%
BE%D0%BD%D0%B5%D1%80).
Семь основных альф инженерного проекта
Основы системной инженерии: альфы инженерного проекта
Основы (kernel из OMG Essence) включают в себя семь альф трёх дисциплин. Все эти альфы тесно связаны друг с другом, на диаграмме приведены лишь некоторые основные связи. Нужно чётко понимать, что представление инженерного проекта через эти основные альфы -- это существенное огрубление реальности. Но именно это огрубление реальности позволяет из "цветущей сложности" выделить главное, на чём нужно будет сосредоточить мышление -- какие-то детали при этом неизбежно потеряются, но ситуация "слона-то я и не заметил" будет встречаться реже. В каждом инженерном проекте минимально нужно отслеживать семь альф в трёх дисциплинах, меньше объектов внимания и дисциплин работы с ними иметь нельзя.
Это отслеживание и работа по изменению всех семи основных альф происходит в течение всего проекта. Когда в проекте происходит "пожар", люди работают по ночам и всё внимание уделяется провальной составляющей проекта, знание этого простого факта -- необходимости удержания во внимании всех семи альф на протяжении всего проекта -- позволяет уберечься от "глупых ошибок".
Основы системной инженерии: альфы инженерного проекта
Основы (kernel из OMG Essence) включают в себя семь альф трёх дисциплин. Все эти альфы тесно связаны друг с другом, на диаграмме приведены лишь некоторые основные связи. Нужно чётко понимать, что представление инженерного проекта через эти основные альфы -- это существенное огрубление реальности. Но именно это огрубление реальности позволяет из "цветущей сложности" выделить главное, на чём нужно будет сосредоточить мышление -- какие-то детали при этом неизбежно потеряются, но ситуация "слона-то я и не заметил" будет встречаться реже. В каждом инженерном проекте минимально нужно отслеживать семь альф в трёх дисциплинах, меньше объектов внимания и дисциплин работы с ними иметь нельзя.
Это отслеживание и работа по изменению всех семи основных альф происходит в течение всего проекта. Когда в проекте происходит "пожар", люди работают по ночам и всё внимание уделяется провальной составляющей проекта, знание этого простого факта -- необходимости удержания во внимании всех семи альф на протяжении всего проекта -- позволяет уберечься от "глупых ошибок".
Экономия мышления заключается в том, что часто одна альфа представляет до десятка разных рабочих продуктов. Обсуждение и мышление тем самым ведётся только для одного объекта, и только при разбирательстве с какими-то конкретными деталями вытаскиваются отдельные рабочие продукты.
Например, "воплощение системы готово к проведению пуско-наладочных работ?" -- в то же время доказательство готовности воплощения системы к пуско-наладочным работам может быть разбросано (кроме факта наличия самих рабочих продуктов, представляющих воплощение системы "в металле") по десяткам разных рабочих продуктов: документов типа актов сдачи работ различными подрядчиками, актов предварительных испытаний, писем контрагентов, записей в базах данных систем управления активами предприятия, сообщений о наличии расходных материалов и т.д.
Альфы обозначаются значком, напоминающим альфу (в диаграмме Основ системной инженерии именно эти значки), со вписанным названием альфы.
Например, "воплощение системы готово к проведению пуско-наладочных работ?" -- в то же время доказательство готовности воплощения системы к пуско-наладочным работам может быть разбросано (кроме факта наличия самих рабочих продуктов, представляющих воплощение системы "в металле") по десяткам разных рабочих продуктов: документов типа актов сдачи работ различными подрядчиками, актов предварительных испытаний, писем контрагентов, записей в базах данных систем управления активами предприятия, сообщений о наличии расходных материалов и т.д.
Альфы обозначаются значком, напоминающим альфу (в диаграмме Основ системной инженерии именно эти значки), со вписанным названием альфы.
Альфы -- это функциональные (выполняющие определённую функцию, играющие определённую роль, идеальные) объекты, по которым мы судим о продвижении (progress, "как много мы уже сделали?") и здоровье (health, "в проекте всё идёт хорошо") проекта. Альфы -- это абстракция того же сорта, какого "физическое тело" является абстракцией реальных физических объектов (да, это физическое тело имеет массу, а геометрическая точка имеет координаты.
Но мы связываем физические тела и математические точки как идеальные объекты с реальными объектами, и после надлежащего тренинга "склеиваем" в мышлении идеальные и реальные объекты. Поэтому об экземплярах альф в проекте принято говорить так, как будто они вполне реальны и существуют в мире, несмотря на все абстракции.
Альфы фиксируют компактное описание мира/теорию, удобную для решения каких-то практических проблем. Это нужно, чтобы иметь возможность повторно использовать известные нам способы рассуждений и решения задач для самых разных объектов. Так, мы думаем о "физическом теле" и "математических точках" единообразно, "как в учебниках физики и геометрии", а применимо это мышление к самым разным "реальным объектам вокруг нас" -- от летящей после удара ногой болонки до крутящегося по марсианской орбите космического корабля. В этой экономии мышления (учимся думать один раз, затем похоже думаем в самых разных ситуациях) и заключается смысл разделения альф и рабочих продуктов.
Например, учимся думать о "требованиях" -- а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве "в реале": спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т.д..
Несмотря на всю "идеальность" и "абстрактность", об альфах говорят как о вполне существующих в физическом мире -- поразумевая при этом их тождественность тем рабочим продкутам, по которым мы можем судить об их существовании. Так, можно определить альфу "моя любимая игрушка" -- и, хотя в детстве у меня это был нарисованный на ватмане пульт управления космическим кораблём, а сегодня это мой ноутбук, я могу говорить про прохождение "моей любимой игрушкой" состояний "полюбил", "разлюбил", "поломалась", "играю", "забросил" и т.д. -- независимо от того, какая именно это игрушка прямо сейчас. Если я говорю о "требовании" -- то меня не волнует, пункт ли это протокола совещания с представителями заказчика, или запись в базе данных системы управления требований, или фрагмент диаграммы какой-то модели требований. Для меня это "требование" -- и я после этого знаю, что с ним делать, и как о нём думать, я обсуждаю "требование" как реальный объект, существующий в мире, имеющий своё состояние и меня в этот момент мало волнует, что у этого требования есть ещё и какие-то особенности выражения (как при счёте яблок меня мало волнует, что их ещё и едят).
Формально ALPHA это Abstract-Level Progress Health Attribute, но неформально это просто "идеальный рабочий продукт", названный "альфой" для уменьшения путаницы с "реальными рабочими продуктами" и аббревиатура для него была подобрана задним числом. Альфы -- это то, что изменяется в проекте, и изменения чего мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.
Но мы связываем физические тела и математические точки как идеальные объекты с реальными объектами, и после надлежащего тренинга "склеиваем" в мышлении идеальные и реальные объекты. Поэтому об экземплярах альф в проекте принято говорить так, как будто они вполне реальны и существуют в мире, несмотря на все абстракции.
Альфы фиксируют компактное описание мира/теорию, удобную для решения каких-то практических проблем. Это нужно, чтобы иметь возможность повторно использовать известные нам способы рассуждений и решения задач для самых разных объектов. Так, мы думаем о "физическом теле" и "математических точках" единообразно, "как в учебниках физики и геометрии", а применимо это мышление к самым разным "реальным объектам вокруг нас" -- от летящей после удара ногой болонки до крутящегося по марсианской орбите космического корабля. В этой экономии мышления (учимся думать один раз, затем похоже думаем в самых разных ситуациях) и заключается смысл разделения альф и рабочих продуктов.
Например, учимся думать о "требованиях" -- а применяем потом это мышление к конкретным рабочим продуктам, которые можно найти на производстве "в реале": спецификациям требований, требованиям из текстов стандартов, user stories на карточках, записям в базе данных системы управления требованиями и т.д..
Несмотря на всю "идеальность" и "абстрактность", об альфах говорят как о вполне существующих в физическом мире -- поразумевая при этом их тождественность тем рабочим продкутам, по которым мы можем судить об их существовании. Так, можно определить альфу "моя любимая игрушка" -- и, хотя в детстве у меня это был нарисованный на ватмане пульт управления космическим кораблём, а сегодня это мой ноутбук, я могу говорить про прохождение "моей любимой игрушкой" состояний "полюбил", "разлюбил", "поломалась", "играю", "забросил" и т.д. -- независимо от того, какая именно это игрушка прямо сейчас. Если я говорю о "требовании" -- то меня не волнует, пункт ли это протокола совещания с представителями заказчика, или запись в базе данных системы управления требований, или фрагмент диаграммы какой-то модели требований. Для меня это "требование" -- и я после этого знаю, что с ним делать, и как о нём думать, я обсуждаю "требование" как реальный объект, существующий в мире, имеющий своё состояние и меня в этот момент мало волнует, что у этого требования есть ещё и какие-то особенности выражения (как при счёте яблок меня мало волнует, что их ещё и едят).
Формально ALPHA это Abstract-Level Progress Health Attribute, но неформально это просто "идеальный рабочий продукт", названный "альфой" для уменьшения путаницы с "реальными рабочими продуктами" и аббревиатура для него была подобрана задним числом. Альфы -- это то, что изменяется в проекте, и изменения чего мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.
Это схема инженерного проекта, она же диаграмма альф инженерного проекта, она же диаграмма основ системной инженерии (systems engineering essence, от OMG Essence -- "основа", имени стандарта, где подобная диаграмма была предложена), она же диаграмма инженерной деятельности, она же онтология инженерного проекта.
На этой диаграмме основ отражены основные объекты, за изменением которых следит системный инженер, и которые всегда присутствуют в его мышлении. Это не "реальные предметы", это абстрактные сущности (типа "физическое тело", "химическая связь связь"), но с этими сущностями как раз и проводятся реальные размышления -- точно так же, как механик, вычисляющий траекторию выпущенной из ружья пули или летящей от пинка поручика Ржевского болонки абстрагируется от сущности летящих предметов и размышления свои ведёт в терминах "физического тела", про которое ему известны формулы.
Так и в инженерном проекте: системный инженер размышляет в терминах определения и воплощения системы, а не в терминах конкретных целевых систем (которых у него за долгую инженерную жизнь перед глазами пройдёт множество -- как пациентов перед врачом. Да, каждый пациент конкретен, но учат врача работать с пациентами как абстрактными объектами, а не конкретными людьми -- конкретные люди меняются, но знания о них, как о пациентах, у врача более-менее стабильны).
Что мы обсуждаем по диаграмме альф инженерного проекта:
● О чём в проекте нельзя забывать
● Где границы инженерного проекта, отделяющие его от других проектов
● Кто в проекте за что ответственен
● Какие максимальные риски, которые на себя может взять команда и её отдельные члены
● В каком состоянии сейчас проект, что уже сделано и что нужно ещё сделать для получения успешной системы
● ... многое другое, ибо эта диаграмма отражает основные изменяющиеся в ходе проекта сущности и основные связи этих сущностей.
Рекомендуется эту диаграмму распечатать как плакат и повесить на стенку в том помещении, где работают системные инженеры. Это должно гарантировать, что при размышлениях о "воплощении системы" не будут забыты "стейкхолдеры", при обсуждении "команды" не будут забыты "технологии" и т.д.: схема задаёт некоторую мыслительную конструкцию, которой необходимо следовать в рассуждениях. Это не теория, использование данной схемы должно быть практикой.
</>
Описание метода в настоящем курсе системноинженерног
metanymous в посте Metapractice (оригинал в ЖЖ)
Настоящий курс системноинженерного мышления будет использовать адаптированный (существенно упрощённый, изменённый для работы с системноинженерными, а не софтверными проектами, а также переведённый на русский язык) стандарт OMG Essence. Этот стандарт разработан в рамках
инициативы SEMAT (http://semat.org).
Утверждение его происходит в консорциуме по стандартизации OMG (Object Management Group, http://www.omg.org).
Адаптация для системной инженерии проводилась TechInvestLab (http://techinvestlab.ru).
Обсуждение этой адаптации и перевода на русский язык проходило на заседаниях Русского отделения INCOSE (http://incose_ru.livejournal.com).
инициативы SEMAT (http://semat.org).
Утверждение его происходит в консорциуме по стандартизации OMG (Object Management Group, http://www.omg.org).
Адаптация для системной инженерии проводилась TechInvestLab (http://techinvestlab.ru).
Обсуждение этой адаптации и перевода на русский язык проходило на заседаниях Русского отделения INCOSE (http://incose_ru.livejournal.com).
Ситуационная инженерия методов
Для того, чтобы обсуждать, как устроено мышление системного инженера, нам нужно для начала как-то описать инженерную деятельность, построить её "теорию": ввести основные понятия, которые присутствуют в каждом инженерном проекте и затем разные способы работы обсуждать с использованием этих понятий.
Описанием инженерной деятельности занимаются в рамках дисциплины "ситуационная инженерия методов". Она была основана идеологами объект-ориентированного движения, которые задали два основных структурированных (ибо неструктурированные в форме "просто книжки" никто не отменял) вида описания своих способов работы:
● использование "языков паттернов" (ищутся некоторые "паттерны" -- неформально определяемые способы решения задач, при этом каждый паттерн описывается по заранее известному шаблону, в который обычно входит описание проблемы и типовой способ её решения). Ассорти ссылок про языки паттернов тут:
http://ailev.livejournal.com/487783.html.
Паттерны -- это чистой воды эвристики, никаких попыток выйти на какие-то более-менее формальные "языки паттернов" не делалось. Само слово "язык" в
словосочетании "язык паттернов" используется неформально (просто чтобы указать на то, что в проекте используются разные паттерны в разных сочетаниях, как слова из какого-то языка).
● ситуационную инженерию методов, как дисциплина. Стандарты описания метода в такой дисциплине обычно представляет собой "мета-модель": описание языка, используемого для моделирования способов работы.
Для того, чтобы обсуждать, как устроено мышление системного инженера, нам нужно для начала как-то описать инженерную деятельность, построить её "теорию": ввести основные понятия, которые присутствуют в каждом инженерном проекте и затем разные способы работы обсуждать с использованием этих понятий.
Описанием инженерной деятельности занимаются в рамках дисциплины "ситуационная инженерия методов". Она была основана идеологами объект-ориентированного движения, которые задали два основных структурированных (ибо неструктурированные в форме "просто книжки" никто не отменял) вида описания своих способов работы:
● использование "языков паттернов" (ищутся некоторые "паттерны" -- неформально определяемые способы решения задач, при этом каждый паттерн описывается по заранее известному шаблону, в который обычно входит описание проблемы и типовой способ её решения). Ассорти ссылок про языки паттернов тут:
http://ailev.livejournal.com/487783.html.
Паттерны -- это чистой воды эвристики, никаких попыток выйти на какие-то более-менее формальные "языки паттернов" не делалось. Само слово "язык" в
словосочетании "язык паттернов" используется неформально (просто чтобы указать на то, что в проекте используются разные паттерны в разных сочетаниях, как слова из какого-то языка).
● ситуационную инженерию методов, как дисциплина. Стандарты описания метода в такой дисциплине обычно представляет собой "мета-модель": описание языка, используемого для моделирования способов работы.
Системноинженерное мышление коллективно
Ещё одной особенностью теоретической основы системной инженерии является то, что она должна учитывать коллективный характер человеческой деятельности. То есть понятие "система" каким-то образом должно быть увязано с другими понятиями, имеющимися в инженерном проекте -- это явно не понятие "система" в безлюдном мире типа мира естественных наук. Нет, системноинженерное мышление должно учитывать существование людей, оно должно облегчать согласование многочисленных людских интересов по поводу создания успешных систем, должно облегчать коллективную работу. Это означает, что в основе системноинженерного мышления должно быть целостное представление о человеческой деятельности (т.е. повторяющихся, типовых, присутствующих в культуре способах достижения цели -- отдельное уникальное "действие" ведь "деятельностью" не назовут) по созданию успешных систем. Системноинженерное мышление должно помогать размышлять не только о собственно целевой системе инженерного проекта (подводной лодке, компьютере, атомной электростанции, медицинском приборе), но и о системе деятельности ("проекте", обеспечивающей системе), которая создаёт эту целевую систему. Тем самым в основании системноинженерного мышления лежат:
● Системный подход (как думать о системах)
● Ситуационная инженерия методов (как думать о деятельности)
Ещё одной особенностью теоретической основы системной инженерии является то, что она должна учитывать коллективный характер человеческой деятельности. То есть понятие "система" каким-то образом должно быть увязано с другими понятиями, имеющимися в инженерном проекте -- это явно не понятие "система" в безлюдном мире типа мира естественных наук. Нет, системноинженерное мышление должно учитывать существование людей, оно должно облегчать согласование многочисленных людских интересов по поводу создания успешных систем, должно облегчать коллективную работу. Это означает, что в основе системноинженерного мышления должно быть целостное представление о человеческой деятельности (т.е. повторяющихся, типовых, присутствующих в культуре способах достижения цели -- отдельное уникальное "действие" ведь "деятельностью" не назовут) по созданию успешных систем. Системноинженерное мышление должно помогать размышлять не только о собственно целевой системе инженерного проекта (подводной лодке, компьютере, атомной электростанции, медицинском приборе), но и о системе деятельности ("проекте", обеспечивающей системе), которая создаёт эту целевую систему. Тем самым в основании системноинженерного мышления лежат:
● Системный подход (как думать о системах)
● Ситуационная инженерия методов (как думать о деятельности)
Поэтому появляется третье поколение системной инженерии, моделеориентированная системная инженерия. Она предусматривает использование логических (структурных) и физических (числовых) формальных моделей, которые могут непосредственно быть обработаны (проверены, оптимизированы) компьютером. Это позволяет достигать принципиально другой сложности целевых систем: компьютеры проверяют модели на отсутствие разного рода ошибок в разы более производительно и точно, чем это может сделать человек. Основной особенностью моделеориентированной системной инженерии является то, что используются не только численные физические модели, но и "логические" модели, использующие аппарат дискретной математики, плюс алгоритмические модели на языках программирования.
Четвертое поколение связано с тем, что моделируется уже не только целевая система, но и сами системные инженеры -- их творческие практики. Проводятся гибридные (статистические и логические одновременно) вычисления, характерные для программ искусственного интеллекта, а не нынешних программ физического и логического моделирования, при этом эти все вычисления-моделирования-оптимизации увязаны друг с другом. Особенность четвёртого поколения в том, что не только люди создают модели, а компьютер только проводит вычисления по этим созданным моделям, но и компьютерные программы создают модели: компьютер выполняет творческие функции, которые сегодня выполняет системный инженер. Человек работает в партнёрстве с компьютером, а не программирует компьютер.
Первое поколение -- это алхинженерия ("алхимическая" инженерия), по аналогии с алхимией по сравнению с химией. Помните алхимические неформальные описания химических реакций в те времена, когда не было ещё развитой химической нотации и понимания различий между химическими элементами и сложными веществами? Вот пример ...
(http://gothicsstyle.ru/2011/02/02/srednevekovaya-alximiya-recepty/)
Современное пояснение: "Философская ртуть -- свинец. Прокалив его, получаем массикот (желтую окись свинца). Это зеленый лев, который при дальнейшем прокаливании превращается в красного льва--красный сурик. Затем алхимик нагревает сурик с кислый виноградным спиртом -- винным уксусом, который растворяет окись свинца. После выпаривания остается свинцовый сахар -- нечистый ацетат свинца (чистый Рb (С2Н302) 2 · 3Н20--это бесцветные прозрачные кристаллы). При его постепенном нагревании в растворе сперва перегоняется кристаллизационная вода (флегма), затем горючая вода -- «пригорелоуксусный спирт» (ацетон) и, наконец, красно-бурая маслянистая жидкость. В реторте остается черная масса, или черный дракон. Это мелко раздробленный свинец. При соприкосновении с раскаленным углем он начинает тлеть и превращается в желтую окись свинца: черный дракон пожрал свой хвост и обратился в зеленого льва. Его опять переводят в свинцовый сахар и повторяют все вновь.
Это общий стиль мышления, речь тут не идёт только об алхимии. С любым знанием сначала так: хорошо ещё, что эти неформальные рассуждения вообще можно записать. Искусство создания более сложных объектов (например, каравеллы) было ровно что искусством: передавалась какая-то традиция, чертежей как таковых не было -- обходились эскизами и макетами, пространными текстовыми описаниями, передававшимися зачастую даже не в книгах, а в рассказах -- от мастера-инженера ученикам.
Классическая системная инженерия использует диаграммную технику -- это уже не вольные поэтические метафоры, как в алхинженерии, но много более строгие определения системы: чертежи, диаграммы, таблицы и т.д.. Но это не полностью формальное описание: его нельзя как-то формально проверить, оно предназначено для чтения и интерпретации только людьми. Если уподобить описание системы компьютерной программе по изготовлению системы, то это такая "программа", которую может выполнить только человек, но не станок-компьютер. Можно назвать это "псевдокодом": непосвящённый человек легко спутает псеводокод с компьютерной программой, но программист понимает, что псевдокод пишется для других людей, а не для компьютера. От псевдокода до реальной программы, реального формального текста на каком-то языке программирования примерно столько же работы, как от общего неформального понимания ситуации человеком до написания программы на псевдокоде.
Дочитали до конца.