Карта гипотез - вышла книга

Я уже писал несколько раз про методику "Карта гипотез" от Александра Бындю. Методика несложная, но, на мой взгляд очень полезная:

1. Предлагает удобный инструмент для планирования/стратегирования в связке цели-субъекты-гипотезы-задачи.
2. Подчеркивает многовариантность и гипотетичность стратегирования.

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

Продается здесь - https://www.litres.ru/book/aleksandr-vasilevich-byndu/karta-gipotez-70019446/

#бындю #картагипотез #стратегирование

Как разрабатывать стратегии для малого и среднего бизнеса

Посмотрел вебинар Дмитрия Торшина о разработке стратегии для МСБ. Хороший ликбез. Рассматривает вопросы:
- как определять цели;
- как формулировать гипотезы;
- как оценивать гипотезы (шаблон RICE);
- как оценивать риски;
- как разрабатывать стратегический и тактический планы;
- авторский шаблон стратегии для МСБ.

Запись вебинара: https://www.youtube.com/watch?v=sUxVIv5ipFk

Презентация: https://drive.google.com/file/d/1H4RWtN5SmXZKHANHnBKapOpDE1l_ph1p/view?usp=sharing

Ссылка на шаблон стратегии - https://drive.google.com/drive/folders/16aPQES61x4PUd4vdeuDEQW1F-TMySprZ

#стратегирование #торшин

Дискретность мышления: язык, обучаемость-внушаемость, принятие решений – сложно о простом

Последнее время появляется всё больше научных работ, показывающих, что человеческая психология неплохо описывается при помощи математических моделей квантовой механики. Оказывается, что квантовоподобные (quantum-like) логика и теория принятия решений позволяет строить модели мышления людей.

«Квантовоподобные» значит:

1. Человеческий мозг производит вычисления пользуясь инструментами «дискретизации» и «ренормализации»: если все возможные мысли, идеи, понятия, слова, буквы представить в виде системы векторов, то для обработки всего этого богатства нужны огромные вычислительные мощности. Чтобы с ними справиться мозг выполняет квантование (дискретизацию). Обработка информации происходит по дискретным точкам в сложных многомерных многоуровневых «решетках» - события, понятия, объекты сохраняются в узлах этих решеток – в мышлении нет непрерывности – вычисления выполняются не над непрерывными функциями, а только над точками дискретизации. Это дает при сложных вычислениях экспоненциальный рост производительности при росте сложности вычислений. Точность мышления определяется точностью дискретизации.

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

3. Принятие решений нарушает классическую теорию вероятностей, но может быть смоделировано через квантовую вероятность – например, внимание человека по «внутренней когнитивной карте окружающей реальности» моделируется по законам квантовой вероятности в связи с силой эмоции, связанной с «объектом на карте».

4. И другое ☺

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

1. Мышление и выбор человека «иррациональны» – зависят от сложности мышления: частоты дискретизации и сложности «решетки», а также от текущего состояния (значений) – поэтому порядок заданных вопросов влияет на содержание ответов.

2. Сложность (вычислительная сила) мышления связаны со сложностью языка, которым владеет человек – это не столько про сравнение, например, французского языка и языков народов банту, сколько про количество понятий и связей между ними, которыми владеет каждый конкретный носитель языка. Обычно это коррелирует с уровнем образования и жизненным опытом человека.

3. Дееспособность/агентность, т.е. сложность и вариативность сценариев поведения также связаны со сложностью мышления и жизненным опытом.

4. Кроме сложности мышления на принятие решений влияет история обучения нейросетки каждого человека: чему учили, как учили, в какой последовательности, какими эмоциями это сопровождалось и т.д.

Резюме: способность к сложному мышлению повышает вашу дееспособность и адаптивность. Короче, учиться надо непрерывно.

#банальное #логика #теориярешений

Что такое мышление письмом (зачем мне этот канал)

«Никто не может мыслить без ручки в руке» (Н.Луман).

Наиболее убедительно и популярно преимущества мышления письмом рассмотрены в книге Зонке Аренс «Как делать полезные заметки. Эффективная система организации идей по методу Zettelkasten». Если обобщить сказанное в книге и дополнить некоторыми соображениями получается следующее:

1. «Мышление происходит по мере формирования и уточнения отчужденной от тебя мысли». Думать «в голове» - малопродуктивно, чревато ошибками и неточностями.

2. Чтение не продуктивно, если не записывать идеи прочитанного и собственные мысли по поводу.

3. Не пишешь – значит не думаешь.

4. Необходимо записывать свои мысли по любому поводу и вести картотеку этих записей. Записывать нужно: а) конспект прочитанного (пересказ, а не копипаста) с библиографическими ссылками; б) собственные мысли, с отсылками на ранее записанное; в) черновики текстов для дальнейшей публикации (если появится необходимость в публикации).

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

6. Для качества заметок полезно чтобы у написанного было хотя бы несколько читателей. Это помогает: а) придерживаться определенного уровня качества записей относительно связности текста; б) обмениваться идеями с людьми, которым интересны темы заметок.

Таким образом, этот канал – черновики по поводу прочитанного, просмотренного, собственные мысли, черновики для статей. Канал нужен в первую очередь самому автору, но, если есть люди, которым заметки по какой-то причине интересны, а тем более кому-то интересно обсудить написанное – это очень хорошо, я благодарен. Канал в телеграм, потому что мне это сейчас наиболее удобно. На случай если телеграм сломается все (почти) заметки я дублирую в ФБ и ВК.

Аналогичный мой канал на темы не связанные с IT теперь здесь - https://t.iss.one/thinkingbyletter3

Более подробно о мышлении письмом можно почитать здесь:

• Зонке Аренс. «Как делать полезные заметки» - https://tocit.ru/static/files/48010866be98762e75980ec68e6a64f4e2d02004d168a35682cb0b0a2fadc109.pdf
• Zettelkasten: как один немецкий учёный стал невероятно продуктивным - https://habr.com/ru/articles/508672/
• Анатолий Левенчук «Мышление письмом/моделированием» - https://ailev.livejournal.com/1513051.html
• Курс «Практики саморазвития». Глава 4 Практика мышления письмом. - https://aisystant.system-school.ru/lk/#/course/selfdev/2023-11-23T1211/17689

#мышлениеписьмом #аренс #луман #левенчук #zettelkasten

Примеры разработки стратегии компании на 2024 год

Дмитрий Торшин провел семинар по стратегированию на реальных кейсах своих учеников. В роликах представлены фрагменты семинара:

Рассмотрено 3 примера стратегий IT-компаний, на основе шаблона, заранее предоставленного автором вебинара.

Первые 2 примера подготовлены новичками, и демонстрируют типовые ошибки:
- слишком обобщённые цели;
- отсутствие привязки целевых показателей к реалиям функционирования компании (в некоторых случаях непонятно чем заявленные достижения помогут компании, в других случаях заявлены слишком заниженные или слишком завышенные критерии);
- недостаточная проработка маркетинговых аспектов (выхода на рынок, расширения доли рынка, завоевания нового сегмента рынка).

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

Ссылка на ролики - https://drive.google.com/drive/folders/1tHguJgBXJbdQUNvSR75D1Hmp83e4g572?usp=sharing

#стратегирование #торшин

Творчество: человек и ИИ

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

Так ли это? Не знаю. Но есть повод попытаться разобраться что такое творчество.

1. Творчество – это придумывание чего-то качественно нового, доселе неизвестного (не важно всем или только творцу).

2. Творчество может быть мыслительным (моделирование себя или окружающего мира), инженерным (изменение окружающего мира – создание новых физических объектов) и фантазийным (искусство).

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

4. Творчество – это не любое изменение, а изменение, имеющее ценность (не важно только для самого творца или для всего человечества). В связи с этим придумали понятие «умной мутации» (smart mutation) – творческая мутация идеи ведет к улучшению эволюционной приспособленности к среде, в которой эта идея будет использоваться.

5. Творческое озарение, догадка возникает из хаоса (шума, случайности) ассоциаций, идей, эмоций.

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

Разработчики ИИ сейчас пытаются научить его творчеству. Например, Карелов описывает как это работает в системе FanSearch:
«
1. Сначала предварительно обученная LLM генерирует первоначальные творческие решения в виде компьютерного кода.
2. Потом вступает в дела «автоматический оценщик», задача которого отсеять из множества первоначальных решений любые подозрения на конфабуляции модели (кстати, использование применительно к LLM термина «галлюцинация» - это сильное огрубление смысла, ведущее к его ограниченной трактовке; верный термин – именно конфабуляция), т.е. возникновение ложного опыта из-за появления фрагментов памяти с описанием того, чего, на самом деле, не было в реальных данных обучения).
3. В результате объединения 1 и 2, первоначальные решения эволюционным путем «превращаются» в новые знания, т.е., по сути, происходит «автоматизация открытий», о которой вот уже несколько десятков лет мечтают разработчики ИИ - вычисления превращаются в оригинальные инсайты.
».

Этот подход позволил системе FanSearch от Google DeepMind сделать математическое открытие, которое сейчас широко обсуждается в сети (решение центральной задачи экстремальной комбинаторики – о наборе предельных значений).

Таким образом, ИИ в настоящее время способен генерировать умные мутации и на основе их цепочек даже делать научные открытие. Однако, что касается серендипности – это свойство в современных теориях интеллекта считается недоступным для ИИ. Хотя, LLM вроде как способны уже усматривать признаки провидческих (серендипных) идей в человеческих текстах. И кто знает, что будет уже через несколько лет…

Литература:
1. Об открытии FanSearch - https://deepmind.google/discover/blog/funsearch-making-new-discoveries-in-mathematical-sciences-using-large-language-models/?utm_source=twitter&utm_medium=social
2. Лекция Карелова о Теории интеллекта Роли-Йегера-Кауффмана - https://www.youtube.com/watch?v=hADqkxkQF2o&ab_channel=%D0%9C%D0%B0%D0%BB%D0%BE%D0%B8%D0%B7%D0%B2%D0%B5%D1%81%D1%82%D0%BD%D0%BE%D0%B5%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B5%D1%81%D0%BD%D0%BE%D0%B5
3. Об умных мутациях - https://arxiv.org/abs/2206.08896

#сознание #карелов #ИИ

Об уличную эпистемологию

Приходит ко мне товарищ и говорит: «Свинину есть грех». С товарищем в свое время не одним килограммом свиного шашлыка был заеден не один литр вина. Что сказать товарищу? «Ты, друг, тронулся на старости лет?»

Можно так, а можно по-другому. Например:

1. Хочешь мы обсудим твоё духовное прозрение?
2. Что такое грех в твоей системе мировоззренческих координат?
3. Какова она теперь – твоя новая система координат?
4. Причем здесь свинина?
5. Каким теперь блюдом ты будешь сопровождать свои алко-духовные опыты вместо свинины? Почему?
6. Насколько ты убежден в твоем новом духовном прозрении относительно связи свинины с греховностью?
7. Ты сам до этого дошел или тебе кто-то об этом сказал?
8. Действительно ли твои новые источники знаний (люди или книги) настолько надежны что имеет смысл менять свои убеждения и жизнь в соответствии с ними?
9. И т.д.

Приведенные вопросы – это широко известная в узких кругах «уличная эпистемология» – способ ведения диалога, который заключается в том, чтобы не спорить с услышанным тезисом, а попытаться:

1. Понять его содержимое.
2. Понять насколько человек убежден в тезисе.
3. Понять как человек к этому пришел.

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

Зачем уметь вести такие диалоги?
Во-первых, может быть человек со странным тезисом прав, а я нет – нужно его услышать.
Во-вторых, может быть он не прав, но для того чтобы ему помочь (если оно надо), человека для начала нужно понять.
В-третьих, может быть с моей точки зрения человек глубоко неправ, но переубедить его невозможно (или не нужно), тогда хорошо бы просто его понять, чтобы научиться мирно сосуществовать.

Умное слово «эпистемология» обозначает философскую дисциплину о природе, структуре, происхождении и т.д. знания. Честно говоря, уличная эпистемология – это банальное умение выслушать и понять человека, с которым ты, возможно, не согласен. Для этого нужен, как мне кажется, всего лишь базовый уровень общей культуры, доброжелательность и любопытства. Но американцы не были бы американцами, если бы не умели общеизвестные вещи красиво обернуть и дорого продать. Так, Питер Богоссян и Энтони Маньябоско, придумали название «уличная эпистемология» для маскировки своего желания вести умную пропаганду атеизма, но так, чтобы это не выглядело примитивной пропагандой, а работало через открытие неискушенным собеседникам мало кем осознаваемой "тайны": убеждения большинства людей как правило случайны и малообоснованны. Да-да. И если умело людям это показывать, то можно деликатно разубеждать в чем угодно, а потом опять убеждать в чем угодно. А по ходу процесса писать об этом книги и снимать ролики для ютуба.

Когда я впервые услышал термин «уличная эпистемология», то подумал: вот, наверное, хороший способ понять мировоззрение человека и его источники. Но, увы, нет. Мировоззрение (даже если, как у большинства людей, его в системном стройном виде нет) – это сложная и объемная совокупность взглядов, идей, понятий, которую, чтобы понять у одного человека, нужно затратить много времени. Кто проводил глубинные интервью даже по узким вопросам может представить – насколько это долго, сложно и дорого. Поэтому уличная эпистемология – это лишь способ относительно быстро понять крошечный фрагмент мировоззрения. Что само по себе неплохо и замечательно – можно не спорить и ругаться на чувствительные темы, а узнавать, понимать и учиться терпеть друг друга.

Есть, конечно, кроме уличной и «лабораторная» эпистемология. Например, психиатры глубоко изучают своих пациентов: их взгляды, сны, отношения и т.д. Или следователи-психологи по вопросам идейного экстремизма… Но об этом в другой раз.

Дисклеймер: любые совпадения по поводу свинины, алкоголя, греха и товарища считать случайными и выдуманными!

#уличнаяэпистемология #мышление #богоссян #маньябоско

Несколько книг о государственном стратегировании

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

1. Форсайт-сессия от 10-13 сентября 2009 г. под началом С.Переслегина на тему развития новосибирского региона. Мне были наиболее интересны первые 20 страниц на тему культуры форсайтов в разных странах (США, Европа, Япония, Россия, Китай, Индия и другие страны). Также интересны раскиданные по книги общетеоретические вещи по стратегированию, типа «сценирование», «дикие карты» и т.д. В целом книга интересна как пример игрового стратегирования по региону в контексте стратегий более высокого порядка.

2. Summa strategia – С.Переслегин и др. (2013) Как справедливо замечает автор в предыдущей книге – с онтологией часто в стратегировании плохо (например, в США и Европе). Видимо, в связи с этим Переслегин сотоварищи решили собрать воедино различные аспекты государственного военного и мирного стратегирования и сделать какую-никакую целостную онтологию для данной предметной области. Этой попыткой обобщить всё книга и интересна, и тем, что ее можно использовать как справочник для задачи освоения науки управления вселенной без привлечения внимания санитаров.

3. Стратегия: логика войны и мира (2001) – Эдвард Люттвак. Автор интересен тем, что кроме теории и исторических штудий имел отношение к практической политической деятельности – был советником в Госдепартаменте США, в Совете по национальной безопасности, у президента США Рональда Рейгана. Книга, якобы, изучается в военных училищах по всему миру.

4. Большая стратегия Византийской Империи – Эдвард Люттвак. Очень интересное историческое политологическое исследование в попытке ответить на вопрос почему восточная часть римской империи, не обладая географическими или военными преимуществами перед западной, просуществовала тысячу лет – в два раза дольше чем западная.

5. Большая стратегия Российской Империи (1650-1831) – Джон Ледонн. Гарвардский историк явно под влиянием Люттвака анализирует российскую стратегия в 17-19 вв. Официального русского перевода нет, пару лет назад я сделал неофициальный, но он так и остался несвёрстанным.

6. Российская Империя и мир (1700-1917): геополитика экспансии и сдерживания – Джон Ледонн. Более ранняя книга примерно на ту же тему, что и предыдущая. С переводом такая же история.

#стратегирование #политология #переслегин #люттвак #ледонн

Какие бывают модели данных

Всех (многих) системных аналитиков когда-то учили, что модели данных бывают:

1. Концептуальные.
2. Логические.
3. Физические.

Но при внимательном рассмотрении (Matthew West - Developing high quality data models, глава 3) можно увидеть, что модели данных бывают:

1. Физические.
2. Логические.
3. Концептуальные.
4. Канонические.
5. Модели данных приложения.
6. Модели данных бизнес-требований.
7. Интеграционные.
8. Модели данных предприятия.
9. Бизнес-информационные.
10. Использования данных.

На рисунке ниже показано как они между собой соотносятся с точки зрения Уэста.

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

И вообще есть у меня гипотеза: если заставить проектировщиков освоить две книги: Криса Партриджа «BORO…» и Мэтью Уэста «Разработка высококачественных моделей данных», - то проектировщики стали бы умнее не только в профессиональной деятельности.

#уэст #партридж #boro #моделированиеданных

Итерации, гипотезы и адаптивность при разработке государственных ИС

Если чиновников, ответственных за цифровизацию, заставить освоить, сдать экзамен и реализовать хотя бы один проект в соответствии с методическими рекомендациями по ссылке в конце поста – страна начнет стремительно прогрессировать в области цифровизации.

Я неоднократно писал о причинах неизбежного отставания государственных цифровых проектов от частных:

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

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

Однако, как оказывается, государственные организации не оставляют попыток угнаться за техническим прогрессом в цифровизации. Мне прислали замечательный документ Минцифры России под названием «Методические рекомендации по организации производственного процесса разработки государственных информационных систем с учетом применения итерационного подхода к разработке». И там, фантастика (!), они пишут (стр.19-20):

«Независимо от того, насколько хорошо Система изначально определена и спроектирована, реальные потребности клиентов и выбор технологический решений являются неопределенными и, соответственно, развивающимися. Поэтому понимание того, как Система должна быть реализована, должно адаптироваться с течением времени. Исходя из этого при разработке Технического проекта рекомендуется придерживаться следующих правил:

1. Проектирование осуществляется на основе требований к Системе, исходящих от заинтересованных сторон, в том числе – клиентов, эксплуатирующего систему персонала, должностных лиц Ведомства.

2. В ходе проектирования рекомендуется использование практик, сохраняющих как можно дольше рассмотрение возможных вариантов реализации Системы (гипотез) в процессе её создания и принятие обоснованных (например, с точки зрения лучших экономических результатов) технических решений только после проверки гипотез.
3. И т.д.».

Рекомендуется системы внедрять итерациями, причем на каждой итерации проводить работы по проектированию, реализации, оценке и корректировке требований (гипотез) для следующей итерации. В рамках одной итерации разработка может вестись ежеквартальными инкрементами. Бюджет может быть независимый для каждой отдельной итерации. И много еще чего из современного ИТ-менеджмента, что является тайным знанием для многих госслужащих, предлагается использовать для успешного создания ИС ГО.

Сложно сходу глубоко оценить ценность и адекватность конкретных рекомендаций – нужно глубоко анализировать документ, а лучше испытать предлагаемые методики в реальном проекте. Но в любом случае есть что нам перенять для усовершенствования нашего законодательства в сфере создания ИС ГО.

Ссылка на документ: МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ОРГАНИЗАЦИИ ПРОИЗВОДСТВЕННОГО
ПРОЦЕССА РАЗРАБОТКИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ С УЧЕТОМ
ПРИМЕНЕНИЯ ИТЕРАЦИОННОГО ПОДХОДА К
РАЗРАБОТКЕ

#егов #менеджмент #мцриап #минцифры

Вот мы тут капаем желчью, глядя на системы егов, а между прочим на днях правительство опубликовало концепцию развития ИИ до 2029 года. Которая в числе прочих задач поедусматривает использование ИИ в госуслугах. И уже в текущем году на реализацию заложили 2 млрд. тг.
Идея стартапа: напишите кто-нибудь на нейросетке и натренируйте бота по госуслугам - можно назвать его "Нить Ариадны". Слоган: "Получи услугу - убей Минотавра".

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

УПД2. Кстати, хорошая идея для пополнения бюджета: покупать скины и вооружение для ускоренного прохождения уровней. можно еще интеллектуальную песочницу сделать: смоделируй деятельность ГО и получи годовой абонемент на егов без глюков...

УПД3. Чувствую наведут на меня порчу сотрудники ГО без чувства юмора...

Ссылка - https://www.gov.kz/memleket/entities/mdai/documents/details/606493?lang=ru

#егов #ИИ

Еще о моделировании данных и мышлении

Читаю Matthew West - Developing High Quality Data Models.

Коротко об авторе:
По образованию химик, работал в Shell, с 1987 года стал айтишником со специализацией в управлении данными. Внес ключевой вклад в разработку стандартов ISO 15926 и ISO 1887. Эти стандарты (кто не знает) разрабатывались для задач обмена информацией между промышленными предприятиями – там, где предприятий сотни и тысячи, номенклатура объектов – много-много миллионов и надо как-то интегрироваться, обмениваться данными в длинных производственных цепочках.

Чем хороша книга:

1. По ходу раскрывает не только приемы моделирования данных, но и поневоле показывает принципы человеческого мышления относительно выделения понятий, отношений между понятиями.
2. Дает много практических советов относительно разработки моделей данных. В частности, много рассказывает о типовых проблемах моделирования исторических данных, четырехмерных объектов, событий и состояний и т.д. и т.п.
3. В приложении дает обширный набор шаблонов данных из ISO 15926.
4. Возникает соблазн использовать книгу как хрестоматию для обучения а) мышления, б) моделирования данных (наряду с книгой Партриджа).

Недостатки:
1. Для совсем незнакомых с принципами реляционных БД многое будет непонятно.
2. Для тех, у кого сложности с понятийным мышлением, желательно для начала прочитать учебник логики.

Ссылку на английский текст книги я давал пару постов выше (можно найти поиском либо по тэгам). На русский перевожу по ходу чтения – так проще читать не торопясь – готово уже 9 глав (всего теоретических глав – 16, полкниги занимают шаблоны данных).

Ссылка на русский перевод – https://docs.google.com/document/d/1kvqJ4aI6Hr2gcNbNB96QFNCJWuDIW-Ri5JTDHn6X_ek/edit?usp=sharing

#уэст #моделированиеданных #перевод

Об архитектуре требований, viewpoint’ах, view (1/2)

Сегодня Денис Гобов рассказывал для Казахстанского чаптера IIBA про Анализ требований и определение дизайна, и вкратце среди прочего про архитектуру требований, viewpoint’ы и view.

Судя по вопросам про архитектуру тема для слушателей непростая. Есть повод повторить и сравнить подходы к определению архитектуры из BABOK Guide и ISO 42010 (Systems and software engineering. Architecture description).

BABOK Guide:
• Архитектура требований — это структура всех требований изменения.
• Точка зрения (viewpoint) — это набор соглашений, определяющих как представляются требования, как эти представления организуются, и как они будут связаны. Точки зрения дают шаблоны для учета интересов конкретных групп заинтересованных сторон.
• Представление (view) - фактические требования и дизайны для конкретного решения с выбранной точки зрения. Набор представлений образует архитектуру требований конкретного решения.

Обратите внимание, что определение архитектуры требований в BABOK Guide противоречиво: с одной стороны, это «структура требований», в другом месте это «набор представлений», т.е. архитектура включает в себя содержание требований. Возникает неизбежный вопрос, всё-таки «архитектура требований» - это «набор представлений (описаний, view)» или «структура всех требований»?

ISO 42010:
• Архитектура – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
• Описание архитектуры (architecture description) – рабочий продукт, используемый для выражения архитектуры.
• Точка зрения (viewpoint) – рабочий продукт, устанавливающий условности конструирования, интерпретации и использования архитектурного представления для структуризации определенных системных интересов.
• Представление (view) – рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.

Для сравнения терминологии BABOK Guide и ISO 42010 необходимо учитывать, что ISO 42010 рассматривает архитектуру «системы», а BABOK Guide рассматривает архитектуру «требований», которые по сути являются описанием «системы», т.е. «архитектуру описания системы». Если толкователи BABOK Guide будут держать в голове подход, выраженный ISO 42010, то они будут считать, что архитектура требований - это основные свойства набора требований, выраженные во представлениях (view), но а) это не простая сумма всех view, б) это не просто «структура» требований. Dixi.

Однако, на самом деле, начиная пост, я просто хотел привлечь внимание к двум важным понятиям:

• Viewpoint.
• View.

Для системной инженерии и бизнес-анализа это очень важные понятия. Viewpoint переводят на русский по-разному: аспект, точка зрения, способ описания. View – представление, описание.

#системнаяинженерия #бизнесанализ

Об архитектуре требований, viewpoint’ах, view (2/2)

Viewpoint – это о том, что у разных сторон есть различные интересы (concern) относительно системы, и им не нужны все возможные описания системы. Собственника бизнеса интересуют одни аспекты, и он хочет видеть описания своего бизнеса и своей инфраструктуры со стороны своих интересов – под его интересы формируется один или несколько viewpoint, а под каждый viewpoint формируются свои view. В физическом мире мы видим как аналитики, архитекторы и разработчики для владельца делают специальные документы: концепцию, business requirement specification и т.д.

У финансового директора, соответственно свои интересы, свои viewpoint и ему нужны свои view. У технического директора – третье. У архитектора – четвертое. У руководителя службы безопасности – пятое. И так далее.

Концепция viewpoint-view позволяет очень детально и очень гибко описывать даже очень сложные системы, при этом сохранять различные уровни абстрактности для описания архитектуры. Инструментально это реализовано, например, в стандарте описания архитектуры archimate и редакторах поддерживающих стандарт: вы можете для каждой диаграммы устанавливать небходимые viewpoint’ы.

Если усвоить в работе с системами, архитектурой, требованиями этот подход деления на viewpoint’ы-view, то работать становится проще: при взаимодействии с различными стейкхолдерами вы сразу анализируете их интересы (concerns) относительно системы, выясняете их viewpoint’ы и планируете какие view вы для них должно готовить.

Диаграмма связи этих архитектурных понятий на картинке ниже.

Ссылки:
1. Стандарт ISO 42010 – https://docs.cntd.ru/document/1200139542
2. Стандарт Archimate – https://pubs.opengroup.org/architecture/archimate3-doc/ch-Stakeholders-Architecture-Views-and-Viewpoints.html
3. Вебинар по анализу требований и определению дизайна –
https://youtu.be/3HMgHd_N_7o?si=bSY-n65YOBXJUwnz

#системнаяинженерия #бизнесанализ

Диаграмма из ISO 42010

Принципы технического экспресс-перевода

Есть важные книги, для которых нет русского перевода, и которые нужно читать медленно, перечитывая несколько раз. Читать не за 1-2 дня, но, минимум, 1-2 недели. Перечитывая не потому что слабо владеешь языком оригинала, а потому что темы сложные и за одно прочтение не разберешься. Очевидно, что если делаешь заметки по прочитанному, то понимаешь и запоминаешь лучше. Но можно не просто делать заметки, но сразу делать и перевод на русский – при этом а) ты и внимательно прочитываешь каждое слово, б) пишешь, формулируешь мысли автора на родном языке, в) на выходе после чтения остается русский текст, которым можно поделиться с теми, кто не может читать свободно по-английски.

Вчера закончил перевод для такой книги – Matthew West «Developing High Quality Data Models». Понял для себя несколько особенностей такого перевода в процессе чтения:

1. Невозможно книгу из 400 страниц перевести качественно за неделю. Для качественного перевода нужны не 1-2 недели, но 1-2 месяца полной занятости минимум.

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

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

4. Много времени занимает перевод диаграмм и рисунков – поэтому я их не перевожу.

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

6. Если машинный перевод предложения звучит по-русски непонятно, то начинаем разбираться почему: непонятно по причине плохого машинного перевода или по причине сложности темы или по причине туманности авторской мысли? При любом варианте приходится переводить предложение «вручную»: если причиной непонятности была слабость машинного перевода то предложение становится понятным, если сложность темы или авторский стиль – тут уж извините…

7. Копипаста через систему машинного перевода, форматирование текста и вставка иллюстраций занимает по времени 1-2 дня работы. Внимательное чтение и редактирование текста – 5-6 дней работы.

Мэтью Уэст хорош, большой молодец, я много открыл для себя в моделировании данных – но об этом в другой раз…

#перевод #мышлениеписьмом #уэст

Развитие и модернизация ИС

Задали вопрос чем отличается развитие от модернизации в контексте разработки ПО – для использования в официальной документации. Спрашивали – отвечаем:

1. В обыденном русском языке развитие и модернизация – синонимы. Тексты по социологии выделяют оттенки этих понятий: развитие – органичный рост системы (в данном случае социальной), реализация присущего системе потенциала изменений; модернизация – изменения в строго заданном направлении, перенимание и внедрение уже существующих в других местах образцов.

2. В казахстанском законе «Об информатизации» модернизация – часть развития, не касающаяся изменений в функциональности: «Ст.1 п. 6-1) развитие объекта информатизации - этап жизненного цикла объекта информатизации, на протяжении которого осуществляется комплекс мероприятий по реализации дополнительных функциональных требований, а также модернизации объекта информатизации».

3. В международных стандартах термин развитие для ПО, кажется, не используется. Вероятно, потому что за термином «development» закреплено понятие, которое в русском языке передается термином «разработка». Вместо этого используются термины «адаптивная модернизация» и «полная модернизация». Причем, разделение между ними проходит не по основанию «добавляем или нет новую функциональность», а по основанию цели изменений. Адаптивная модернизация выполняется в рамках адаптивного сопровождения программного средства для обеспечения работоспособности в изменяющейся операционной среде. Полная модернизация выполняется в рамках полного сопровождения в интересах пользователя. Т.е. и адаптивная и полная модернизация может затрагивать функциональность ПО, различие между ними – в объеме и цели изменений (См. ИСО/МЭК 14764-2002).

4. Российская нормативная практика, если смотреть на официальные комментарии Минцифры, ориентируется на ИСО/МЭК 14764-2002.

5. Можно также посмотреть эти термины в ШСМ А.Левенчука – там есть понятие метода работы/практики. Метод работы включает в себя а) технологии/инструменты; б) дисциплину/методику. Если меняются только технологии – то это модернизация, т.е. меняются только инструменты: писали тексты в одном приложении, потом поставили более современное, но задачи и способы написания текстов не изменились. Если изменили методы работы, дисциплину (например, тексты перестали писать копирайтеры, а стал генерировать ИИ на основе спецификаций требований, ну или вообще перешли на видео вместо текстов) – то это развитие.

Резюме: Если вы пишете спецификацию или договор, то лучше в тексте полностью раскрывать понятия, давать четкие определения. Иначе вы можете понимать под модернизацией обновление версий ОС, а заказчик – разработку дополнительной функциональности любого объема. Или наоборот.

Ссылки:
• ИСО/МЭК 14764-2002 "Информационная технология. Сопровождение программных средств" – https://files.stroyinf.ru/Data2/1/4294817/4294817040.pdf
• «Об информатизации» Закон Республики Казахстан от 24 ноября 2015 года № 418-V ЗРК – https://adilet.zan.kz/rus/docs/Z1500000418

#развитие #модернизация

Кто такой аналитик бизнес-данных

Закончил перевод стандарта от IIBA Руководство по аналитике бизнес-данных. Стандарт выстроен примерно по той же схеме что и другие стандарты:

• Введение
• Области знаний (домены).
• Типовые задачи, которые решают аналитики.
• Техники (методы работы), которые используются для решения задач.

Кроме того, в отличие от BABOK Guide, здесь присутствуют в количестве практические примеры из реальной жизни – как та или иная компания решали свои проблемы с помощью аналитики данных, а также по каждому домену приводится разбор учебного кейса – в этом Руководство по аналитике бизнес-данных легче использовать как учебник, чем BABOK Guide.

Роль аналитика бизнес-данных в данном стандарте занимает примерно такое же место как роль бизнес-аналитика в BABOK Guide.

В BABOK Guide цепочка ролей от бизнес к технологиям выглядит примерно так: Эксперт предметной области – Бизнес-аналитик – Технический специалист. На реальном рынке это может быть даже Эксперт предметной области – Бизнес-аналитик – Системный аналитик – Технический специалист (разработчик). Понятно, что на практике иногда сотрудник может в одном лице исполнять некоторые смежные роли.

В руководстве по аналитике бизнес-данных цепочка ролей получается примерно следующая: Эксперт предметной области – Аналитик бизнес-данных – Специалист по обработке данных (data scientist) – Технический специалист (data engineer, разработчик).

Аналитик бизнес-данных – это не просто специалист по данным, которые умеет работать с данными знает технические инструменты и статистические методы (за этим лучше идти к дата-сайентистам), но это тот кто:

1. Может понять проблемы бизнеса и поставить правильные вопросы для решения с помощью данных: сформулировать гипотезы и спланировать исследование.
2. Может найти, изучить источники данных, получить из них релевантные данные.
3. Может выполнить анализ полученных данных.
4. Может выполнить правильную интерпретацию данных и подготовить отчеты по данным.
5. Может выполнить задачи по использованию результатов исследования для влияния на принятие бизнес-решений.
6. Может участвовать в управлении стратегией организации в области аналитики бизнес-данных.

О задачах, которые необходимо решать, чтобы всё это делать, в общих чертах и рассказывает стандарт на 200 страницах.

Ссылка на страницу IIBA с официальной информацией о стандарте и сертификации - https://www.iiba.org/business-analysis-certifications/business-data-analytics-certification/

#бизнесанализ #датаналитика #iiba #babok #cdba

Моделирование данных: нормализация vs. онтология (1/2)

Нормализация – это подход к моделированию данных, при котором проектировщики стремятся устранить избыточность данных. Если вы ведете учет товаров на складе, то вам не важно вы храните насосы или хрустальную посуду – вам нужны только название, маркировка, размер. Поэтому, скорее всего вы будете хранить данные по товарам в одной таблице – вся нужная информация по объектам хранения вполне может быть описана несколькими полями реляционной таблицы. При проектировании с точки зрения нормализации борьба идет за форму хранения – чтобы данные хранились компактно, а что там за объекты реального мира кроются за данными – не важно. Правда, у нормального подхода есть недостаток: как только возникает необходимость по хрустальной посуде хранить дополнительную информацию, то нормальную модель нужно переделывать, и, соответственно, информационную систему.

Онтологический подход – это подход, при котором проектировщики стремятся к тому, чтобы их модель по возможности адекватно отражала реальный мир. Если вы проектируете модель данных для процессов производства, использования и обслуживания насосного оборудования, то вам неудобно будет использовать одинаковое описание для насосов и для хрустальной посуды – вы проектируете различные типы насосов (их сотни), которые имеют различное устройство, изготавливаются из различных материалов и по-разному используются. У каждого насоса может быть собственный жизненный цикл, от момента начала проектирования до утилизации. Каждый насос может фигурировать в большом количестве информационных систем, в которых его проектируют, производят, хранят, используют, и эти информационные системы могут обмениваться между собой данными о конструкциях насосов и о конкретных изделиях, их состоянии. Для того чтобы такой обмен данным был возможен, информационная модель насоса должна как можно точнее отображать реальный мир, «жизнь» насоса – тогда с большой вероятностью этой моделью смогут пользоваться и проектировщики, и производственники, и пользователи оборудования.

Все проектировщики моделей данных знают интересное свойство сего занятия: попроси двух проектировщиков построить модель одной и той же предметной области – получится две совершенно разных и, часто, несовместимых модели. Причем несовместимых не из-за разных названий, но и по существу. Отсюда рождается предположение: если мир проектировать исходя не из удобства и компактности хранения данных, а из его физических свойств, то модели у разных проектировщиков должны получаться более-менее одинаковые. Правда, о способах «правильного» онтологического описания реального мира тоже нужно договориться – а то на примере истории философии мы можем увидеть, что философские онтологии могут быть абсолютно несовместимыми. Технические онтологии должны быть универсальными, упрощать взаимопонимание насколько это возможно и в то же время точно отражать физические свойства моделируемых объектов.

К чему привели попытки договориться о правилах онтологического моделирования?

#моделирование #моделированиеданных #boro #hqdm #gellish

Моделирование данных: нормализация vs. онтология (2/2)

1. Крис Партридж популярно объяснил о сложностях разработки правильных онтологий, выделил базовые сущности моделирования, обосновал необходимость думать о физических объектах, как о 4D – пространственно-временных протяженностях.

2. Группа специалистов разработала набор стандартов ISO 15926, как лингва франка обмена данными между независимыми информационными системами. По некоторым сведениям использование подхода, описанного в данном стандарте позволяет многократно сократить затраты на интеграционные проекты.

3. Некоторые соавторы ISO 15926 продолжили работу над улучшением решений, предложенных в стандарте. Мэтью Вест предложил свой вариант – HQDM (High Quality Data Modelling), Андрис ван Ренссен – Gellish (он с середины 90-х годов начал разрабатывать свой «Общий инженерный язык», как универсальный язык инженерного проектирования, который в итоги превратился в язык концептуального моделирования данных).

4. Параллельно с подачи Э.Эванса возникла идеология DDD – domain-driven design, которая не про интеграции, а про адаптивность в рамках одной системы: если мы спроектируем программные объекты системы по возможности отражающими реальный мир, то систему будет легче развивать.

В чем проблема онтологического подхода к данным?

1. Мышление людей сильно привязано к объект-атрибутной парадигме, корни которой уходят еще к Аристотелю (об этом много пишет Партридж).

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

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

4. Другое)

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

О базовых объектах онтологий и прочих приятных вещах – в следующих постах.

#моделирование #моделированиеданных #boro #hqdm #gellish