Системный сдвиг

Я вообще редко пишу сюда про образование (а может, нужно чаще?..), но тут просто не смог пройти мимо. Замечательные результаты тестов! Приходите учиться в университет, у вас разовьются способности анализа и следования правилам, вырастет тревожность и упадут ориентация на результат, способность к сотрудничеству, стрессоустойчивость, уверенность в себе и в будущем! Это не какой-то конкретный университет, это среднее по стране и по всем специальностям. Говорят, только у медиков партнерство не падает, т.к. другой способ подготовки - интересно, ничего не знаю про медицинское образование! А у остальных - вот так.

Руководство по написанию требований от INCOSE, которое я считаю одним из лучших и компактных описаний процесса работы с текстами требований, было обновлено в 2023 году до версии 4, и, видимо, по случайности, его финальный драфт (на английском) можно свободно скачать вот тут: https://www.incose.org/docs/default-source/working-groups/requirements-wg/gtwr/incose_rwg_gtwr_v4_040423_final_drafts.pdf Так что, если вы хотели ознакомиться — скачивайте, пока доступно! Обычно драфт не очень сильно отличается от финальной версии. В чем его отличие от предыдущей версии, я пока не понял, но вроде бы документ стал длиннее страниц на 20.

По сети, говорят, ходит флешмоб про 20 книг, которые до сих пор с вами или сильно повлияли на вас: без объяснения, только обложки. Вот мои 20 (это те, что "по специальности"). Удивительно тут, конечно, что по системному анализу и управлению требованиями книг тут не так много — даже не понятно, откуда я этого всего нахватался.

Мы всё неправильно понимаем про HTTP метод PATCH. Иногда читать стандарты очень увлекательно — становится понятно, что люди имели в виду на самом деле. Читать книги и статьи опаснее — там уже личные интерпретации, кто как понял. Почти во всех примерах, что мне встречались, тело запроса PATCH описано, как набор новых значений полей в JSON — с оговоркой, что в случае PUT мы должны были бы передать все поля, а не только изменившиеся, а в случае PATCH — только изменившиеся. Но в стандарте — RFC 5789 — написано совсем другое! В запросе PATCH должен передаваться набор изменений, применяемых к ресурсу, в формате "патч-документа". Что это за формат — зависит от медиа-типа ресурса. В реестре медиа-типов IANA есть, например, типы патч-документов для json: application/json-patch+json и application/merge-patch+json; и тип для XML: xml-patch+xml (ну ещё несколько специфических). Документ JSON-patch [RFC 6902] выглядит именно как набор операций, вносящих изменения в JSON: [ { "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "replace", "path": "/a/b/c", "value": 42 }, { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } ] op — это, понятно, название операции, вот какие операции могут быть: add — добавить элемент в массив или свойство в объект; remove — удалить свойство объекта или элемент массива; replace — соответственно, заменить (как последовательное применения remove и add); move — переместить значение из одного места (пути) в другой (тоже как remove и add, но у add будет другой путь); copy — скопировать значение и вставить в другое место; test — проверить значение по указанному адресу на соответствие (без масок или регулярных выражений, просто на совпадение). Понятно, что неидемпотентным PATCH делает именно операция add — если будем применять её несколько раз к массиву, добавится много элементов вместо одного. То, как обычно описывают формат применения PATCH — больше похоже на merge-patch+json: там мы действительно передаем только изменившиеся свойства, и null для тех свойств, которые хотим удалить. В любом случае, тип медиа не должен быть просто application/json — по стандарту (а точнее — по errata к стандарту, списку исправлений), сервер вообще должен возвращать ошибку 415, если в запросе PATCH приходит тот же медиа тип, что у ресурса — то есть, не json-patch, просто json. Это чтобы избежать неоднозначности интерпретации. А в каких форматах сервер готов принимать патч-документ — он должен сам сказать в ответе на запрос OPTIONS: Accept-Patch: application/prs.example.patch+json, application/json-patch+json, application/merge-patch+json. Вот так PATCH должен работать на самом деле. Ясно, что он так практически никогда не работает, так что можете этими знаниями блеснуть на собеседовании, разве что. И то — будьте осторожны, а то интервьюер примет вас за зануду-теоретика, выучившего стандарты, но далекого от практики. А на практике ни один фронтендер не будет вам конструировать сложный патч-документ, когда можно передать просто набор изменившихся полей. Ну, или пока дело не дойдет до какого-то очень сложного по структуре, со многими уровнями вложенности объекта.

Иногда интересные общеприменимые идеи встречаются в стандартах и фреймворках, принятых в отдельных отраслях. Так ISO 15926 начался в нефтегазовой индустрии, а сейчас считается общим стандартом для семантического представления 4D-модели (с учетом времени) любой сложной инженерной конструкции и её жизненного цикла в любой отрасли. Медицинский стандарт HL7 содержит самую подробную структуру для хранения личных имен, что мне только встречалась (из 11 полей и 13 типов). А в образовании есть модель интеграции технологий в обучение (считай — уровень или глубина цифровизации) SAMR: S — Substitution, простая замена старой технологии на цифровой эквивалент без изменения функции. A — Augmentation, расширение — технология выполняет ту же функцию, но с небольшим расширением. M — Modification, изменение — технология значимо меняет способ выполнения функции. R — Redefinition, переопределение — применение технологии позволяет выполнить совсем другую задачу, ранее непредставимую. На примере такси: S — раньше такси вызывали по телефону в конкретной компании-перевозчике, теперь можно вызвать через мессенджер/чат-бот/форму на сайте (таксисту вызов передает оператор по рации); A — На сайте можно посмотреть историю своих заказов и текущий заказ; M — Можно вызвать такси в мобильном приложении перевозчика, адрес определяется автоматически, у таксиста тоже есть приложение, где он видит вызов, оператор не нужен; R — Каждый может стать таксистом, если есть своя машина и немного свободного времени. Не нужно знать контакты конкретного перевозчика — пользователь вообще не думает, кто и из какой конкретно компании приедет. У всех пассажиров и всех таксистов приложение одного координатора. Кто бы мог такое придумать! У нас уровень трансформации обычно измеряют другими ступенями: компьютеризация, информатизация, цифровая трансформация (поставили компьютеры и начали на них решать какие-то задачи; создали интегрированную систему для поддержки бизнес-процессов; перестроили бизнес-процессы, и каждый новый сразу проектируем в цифре). Иногда говорят про перестройку бизнес-модели на последнем шаге. это уже ближе к SAMR. В другом подходе последний уровень почему-то "мышление на основе данных", что бы это ни значило. Redefinition мне больше нравится! Вы тоже, когда автоматизируете процессы, задумайтесь — чем вы занимаетесь? Заменой, расширением, изменением или переопределением? Аналитик, особенно бизнес-аналитик, по моему убеждению занимается именно цифровизацией предприятия — может быть, не всего, а отдельных процессов, но в пределе — может и всего, как CDTO (директор по цифровой трансформации). Это к вопросу о возможном карьерном треке и кем может быть опытный аналитик, если не архитектором и не менеджером проектов.

Продолжение истории про Mothers of All Demos — оператором видеокамеры на этом мероприятии был некий Стюарт Бранд — издатель журнала The Whole Earth Catalog, биолог, эколог и активист. Стюарт был далек от компьютеров, но зато, например, убедил NASA сделать и опубликовать один из первых снимков Земли из космоса — чтобы показать людям, насколько она маленькая и хрупкая. Он же придумал ежегодно отмечаемый "День Земли" На демонстрации Энгельбарта Бранд был не просто оператором — он помогал готовить сценарий и драматургию презентации, да и саму идею связи информации из многих источников и совместной работы людей над одним объектом скорее всего они совместно обсуждали — она лежит в русле экологического подхода. А знаем мы его по одной очень известной фразе, популяризированной Стивом Джобсом: Оставайтесь голодными, оставайтесь безрассудными! Эта фраза была напечатана на последней странице The Whole Earth Catalog выпуска 1974 года, и именно её процитировал Джобс в речи перед выпускниками Стэнфорда, упомянув, что зачитывался этим журналом, и вообще это было "что-то типа Гугла на бумажном носителе, и задолго до Гугла". Вот так всё связано хитрыми способами!

Вам хотелось когда-нибудь озвучить ТЗ? Причем чтобы не просто диктор его зачитывал, а это звучало как-то более интересно? Теперь при помощи AI можно превратить документ в подкаст. Я взял для примера техническое задание, которое мы показываем на курсе "Системный анализ и разработка требований в ИТ-проектах" в школе Systems.Education, и вот что получилось. (Разговор идёт на английском, так что можете включить субтитры или переозвучить на русском в Яндекс.Браузере — правда, Яндекс немного потерял интонации и кое-где неправильно перевел фактуру) — Хорошо, так, посмотрим, что тут у нас, эм, вы дали нам эту спецификацию требований к программному обеспечению еще аж 2010 года — О, вау! — Да, это система для управления регистрацией лекарственных средств в России. Интересно. Я знаю, о чем ты думаешь. — Звучит захватывающе. — Да, но оставайтесь со мной здесь, это не просто какой-то скучный старый документ. — Ладно, это настоящий портал в прошлое. — Да, мы должны были поиграть в детектива и собрать воедино то, каким был российский фармацевтический мир, знаете ли более десяти лет назад, — Как маленькая капсула времени. — Да, полная подсказок о том, как всё раньше работало. — Ладно, название: "Требования к программному обеспечению для системы управления регистрацией лекарственных средств" — Ок — Нет, точно будет бестселлером с таким названием. — Что внутри. О, вот где становится интересно. В основном это описывает программное обеспечение, которым они хотели заменить свою существующую систему для управления регистрацией лекарств. Из того, что мы можем сказать, их старая система, вероятно, была кучей электронных таблиц, и ручных процессов. — О, я могу только представить себе эту головную боль! — Да, эта новая система должна была упростить, все объединить в цифровом виде, так что представьте это, вы знаете, вы зарегистрировались в 2010 году, вы просто тонете в бумажной работе, пытаясь отслеживать каждую мелочь для каждого препарата в процессе разработки, и тут появляется эта система, и берет на себя тонны данных: про каждый препарат, категорию, дозирование, упаковку, научные данные. — Там куча данных! и т.д. в таком же духе на 19 минут :) Вот ссылка, извините, что Youtube: https://www.youtube.com/watch?v=vOFn6p9qx6o Это сделано в NotebookLM от Google, ну это больше шутка, конечно (хотя можно проверить — что AI вычитывает в вашем документе и где есть пробелы — например, тут они гадают, что за роль такая "гость", и кто бы это мог быть). А вообще в него можно загрузить несколько документов и ссылок, и задавать разные вопросы к этим документам — удобная вещь для аналитика при анализе нормативки, например, или старой документации.

Я смотрю, вам понравился пост про философию :) Тогда держите ещё один. Стэнфорд поддерживает ресурс "Стэнфордская философская энциклопедия", в частности, там есть раздел "Философия компьютерных наук". В нем, например, предпринимается попытка разъяснить, что такое computer science — наука или инженерия? Интересно, что тут опять возникает рационалистский оптимизм: сначала (с 1940-х до 1970-х) computer science рассматривалась, как подраздел математики: программа написана на формальном языке, значит, каждый оператор и их последовательность можно рассматривать как математическое выражение, в, конечном итоге, формально доказать правильность работы программы. Этим активно занимались Дейкстра и Хоар; и Дейкстра так протестовал против оператора GOTO в том числе потому, что тот мешал формальной верификации. Кроме того, Дональд Кнут поддерживал рассуждение, что компьютерная система — это творение человеческих рук, а значит её поведение может быть в точности предсказано. В 1970-е, однако, системы стали действительно большими и получили развитые пользовательские интерфейсы, так что и свести все варианты входов системы к некоторому ограниченному множеству, и формально проанализировать все программы со всеми библиотеками стало нереальной задачей. Хотя теоретически это осуществимо (хотя бы и с некоторыми ограничениями), на практике сложность такой верификации на порядки превышала бы сложность создания системы. Поэтому методы computer science стали развиваться в сторону тестирования и оценки надежности или скорее достоверности (reliability), в чем-то походя на методы проверки качества физических изделий. Хоть мы и не можем проверить работоспособность программы (а тем более комплекса программ) на всём объеме возможных входных данных и внутренних состояний, мы можем проверить некую выборку таких данных и состояний, наиболее статистически вероятных, и считать, что с некоторой вероятностью проверенная программа работает. В каком-то смысле, computer science — это инженерия математики — проверка математических выражений инженерными методами. Наконец, computer science может рассматриваться как отрасль эмпирической науки — изучающей реально существующие вычислительные системы. Ну и что, что они созданы человеком и не найдено пока природных вычислительных систем — это такой специальный предмет исследования, который всегда создается человеком, но далеко не всегда человеком познаваем. Наверное, можно даже рискнуть назвать это эмпирической математикой — и рассматривать каждую новую систему, алгоритм или язык как своего рода эксперимент. Ну, будем честными — почти всегда это эксперимент и есть — то ли система будет решать задачи, для которых она предназначена, то ли мы узнаем что-то новое о задачах, желаниях пользователя, вычислительных возможностях и о себе :) А в следующий раз я расскажу о философских основаниях требований — там тоже интересно, не переключайтесь!

В этот день 56 лет назад, 9 декабря 1968, прошло событие, которое потом назвали "Мать всех презентаций" — 'Mother of All Demos'. Дуглас Энгельбарт продемонстрировал возможности своей системы NLS, oN-Line System. Впервые в одной системе были показаны следующие идеи: - растровый графический монитор - графический интерфейс - окна в интерфейсе - мышь - гипертекст, ссылки - динамическое связывание (когда программа "на лету", без перекомпиляции определяет, какую библиотеку загрузить для обработки файла) - текстовый редактор - совместное редактирование документов - электронные письма с ссылками и документами - видеоконференции с шэрингом экрана - управление версиями - вывод экрана на проектор Ещё раз: 56 лет назад, 1968 год. Компании ещё не все перешли на электронные терминалы, многие до сих пор для ввода и вывода используют перфоленты, люди считают на логарифмических линейках. Презентация просто взрывала мозг! Да, это была экспериментальная система, но она оказала влияние на всё дальнейшее развитие технологий, появление и возможности персонального компьютера. Часть команды Энгельбарта потом перешла в Xerox, которая в 1973 выпустила персональный компьютер Xerox Alto — с мышью и оконным интерфейсом. Он вдохновил Стива Джобса на создание Macintosh, ну и так далее. Алан Кей, тогда ещё студент магистратуры, был на презентации, проникся, потом в Xerox PARC придумал объектно-ориентированное программирование и язык Smalltalk. Дэна Бриклина это демо вдохновило на создание VisiCalc — первого табличного процессора, дедушки Excel. На презентации были и другие люди, о многих из которых теперь написано в Википедии. Но главная идея, из которой все эти инструменты у Энгельбарта родились — расширение ментальных возможностей человека, ни много ни мало. Она опирается на статью ещё 40-х годов "Как мы можем мыслить" Вэнивара Буша. В этом смысле интересно посмотреть на свои системы — исходим ли мы из того, что помогаем человеку мыслить?

Учат ли системному анализу в школе? Оказывается, да! В 10-11 классах. Есть вот целый учебник. Системный анализ, в изложении авторов, представляет собой введение в системную инженерию (даже начинается с типового примера от системных инженеров — морской буровой платформы) + несколько расчетных упражнений по многокритериальному анализу. Как думаете, поможет это в становлении системного аналитика? Оцените, кстати — на какую профессию там ориентируют школьников — генеральный конструктор, ни много ни мало! Не знаю, правда, есть ли школы, в которых такой предмет реально преподают.