• conjure

Китайцы отжигают

Китай меня не перестаёт удивлять. Смотрите, как китайские ребята отожгли - по-другому не назовёшь. Семейная пара (67-летний мужчина и 65-летняя женщина), которой принадлежит дом на фото ниже, - сопротивлялась, как могла. Они отказались покинуть свою собственность, хотя там подвинулась для скоростной дороги вся деревня - почти 500 домов! Причина сопротивления: государство предложило такую мелкую компенсацию, что на неё нового дома старикам уж не построить. Получилось в итоге вот так:

1840

Меня удивило, что со стариками не расправились как-нибудь особенно зверски. К примеру, в той же России я запросто могу представить, что этих пенсионеров просто объявили бы умалишёнными, отправили в дом престарелых, подкинули стрихнинчику или подстроили нечаянный разрыв сердца. В их-то годы... А китайцы вон как справились: отожгли на полную катушку практически без рукоприкладства. Хотя как знать, может это и был вариант:"Устроить гнусным старикашкам разрыв сердца".
1842

Collapse )

Здесь оригинал статьи на немецком, фотографии тоже оттуда: Knallharte Verkehrsplanung in China

Upd. Говорят, дом вчера снесли. Но всё равно отожгли китайцы, да.

В Германии, кстати, есть закон, что владельцы земель или недвижимости должны в случае чего поступиться своей собственностью на благо человечества. Например, если нужно будет проложить новую дорогу. Потому что интересы общественности, как ни странно, стоят над индивидуальными потребностями. Происходит это тоже только в обмен на компенсацию. А что, если мне, к примеру, эта компенсация не подойдёт, как и китайской паре? Ужос.
стандарт

Схема московского метро: продолжаем думать

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

А теперь давайте немного обсудим идеи, которые были высказаны. Я не стал комментировать активно прошлый пост, потому что многие мысли повторяются несколько раз. Решил написать более подробный анализ всего, что было предложено. Плюс я хотел бы начать делиться некоторыми мыслями, которые есть у "Городских проектов" и опытом, который мы подсмотрели в других городах.
Collapse )

Корпус знаний по системной инженерии, первая версия

Оригинал взят у ailev в Корпус знаний по системной инженерии, первая версия
Вчера была выпущена первая версия Guide to the Systems Engineering Body of Knowlede (SEBoK), version 1.0 -- http://www.sebokwiki.org (.pdf версия -- http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0_Final.pdf).

В этом тексте написан кратенький (на 852 страницы мелкого шрифта в .pdf) обзор системной инженерии, с обширнейшей литературой, а также снабженный глоссарием (в .pdf не поместился, он тут: http://www.sebokwiki.org/1.0/index.php/Glossary_of_Terms).

Это работа аж 70 авторов, и отнюдь не все из этих авторов разбираются в современной моделеориентированной системной инженерии (так, управление моделями при помощи PLM систем даже не обсуждается -- хотя слово PLM поминается на страницах 500 и 507, из аж 800 страниц, слово generative не было обнаружено, и т.д.). Так что не ждите откровений про далёкое, или даже ближайшее будущее, в тексте фиксируется канон для по большей части усреднённого вплоть до "средней температуры по больнице" ближайшего прошлого. Считается, что американцы продавили по многим спорным вопросам свою точку зрения (в том числе излишний учёт стандартов Пентагона вместо твёрдой опоры на ISO 15288), европейцы не очень этим довольны, но поделать с этим уже ничего не могут.

Тем не менее, для мирового сообщества системных инженеров выход такого справочника -- большое событие, ибо это теперь и есть каноническая версия системной инженерии, на которую нужно ориентироваться создателям учебных курсов, сертификаций, стандартов, справочников профессий и прочих формальных рассмотрений дисциплины системной инженерии. По факту, авторская группа была договорной площадкой, чтобы создать некоторое общее понимание по самым важным вопросам, например, "что такое системная инженерия". В SEBoK v.1.0 появилось очередное новое определение системной инженерии (http://www.sebokwiki.org/1.0/index.php/Systems_Engineering_%28glossary%29):
Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.


Исправления ошибок для этого текста планируется выпускать раз в полгода, пересмотр (revision) делать раз в три года, всё под чутким руководством консорциума из INCOSE, IEEE-CS, и SERC.

Так что не слишком надейтесь на то, что найдёте в этом стандарте (ага, это стандарт -- как по способу коллегиального написания, так и по способам предполагаемого использования) какие-то откровения или советы повышенной разумности, но в качестве справочника он вполне может пригодиться.

Архимейт по-русски: дополнения второй версии

Оригинал взят у ailev в Архимейт по-русски: дополнения второй версии
31 января 2012 года вышла спецификация ArchiMate 2.0, существенно расширяющая возможности этого архитектурного языка.

1. В ядро (core) Архимейта добавлено два новых типа:
-- место (location), чтобы моделировать "концептуальное" или физическое (протяженность в пространстве) место, назначенное структурным элементам и (косвенно) элементам поведения. Формально место введено на уровне деятельности.
-- функционал оборудования (infrastructure function), чтобы моделировать внутреннее поведение узла на уровне оборудования (для подобия моделирования на всех трех уровнях). Помним, что к оборудованию относятся не только железки, но и связь и системный софт (прикладной софт моделируется на уровне обработки данных).

2. Новое расширение целеполагания (Motivation) позволяет архитектору (и инженеру по требованиям) воспользоваться подходом GORE (целе-ориентированной инженерии требований). Для предприятия, как и для любой другой системы, обсуждаются заинтересованные стороны, и их интересы, а потом (после некоторого анализа) формулируются требования и ограничения. Затем разрабатываемая архитектура трассируется к этим требованиям и ограничения (в Архимейте это будет "требование реализуется элементом архитектуры"). Тут нужно заметить, что кроме требований и ограничений, новые элементы не могут связываться с любыми типами элементов, разве что с "пользой" (value) и "смыслом" (meaning).

В тексте вперемешку встречаются motivation и intention (и совсем не встречается goal-oriented -- то есть традиция идет от моделей типа OMG BMM), но я перевел в данном случае привычным для российского оргконсалтера языком: "целеполагание". Вот что добавлено:

Целеполагающие (motivational) типы:
-- цель (goal) -- конечное состояние, которое намеревается достичь заинтересованная сторона. "Цели" из "цели-средства".
-- требование (requirements) -- высказывание (statement) о необходимости того, какая функция должна быть реализована архитектурой данной конкретной организации.
-- принцип (principle) -- культурная норма для архитектур всех организаций в данном контексте, или указание на нормативный способ реализации таких архитектур любой организации.
-- ограничение (constraint) -- ограничение того способа, которым реализована система. Обычно это ограничение на конструкцию (т.е. не на функцию, т.е. не требование по определению!). Интересно, что Архимейт заранее смирился с тем, что стейкхолдеры будут накладывать ограничения в виде требований: этот тип введен как подтип требований, но я рекомендовал бы этим не злоупотреблять.
Требования, ограничения, принципы -- это задание "средств" из "цели-средства".

Источники намерений (intentions) типы:
-- заинтересованная сторона (stakeholder) -- это роль человека, команды или организации (чаще --культурно-обусловленных классов, например, "акционер"), которая представляет их интересы (concerns, interests in) относительно результатов (outcome) архитектуры.
-- факторы влияния (driver) -- что-то, что создаёт, обосновывает и подпитывает изменения в организации (Drivers represent internal or external factors which influence the plans and aims of an enterprise). Внутренние факторы обычно связывают с заинтересованными сторонами, но бывают и внешние (всякие "кризисы" и "регулирования"). Это не требования, это лишь источники для формулировок требований.
-- оценка (assessment) -- результат некоторого анализа некоторого фактора влияния (driver).

Мета-модель задаёт и иную классификацию: все типы объявляются мотивационными элементами, кроме заинтересованной стороны -- это структурный элемент (активной структуры).

Новое отношение в расширении целеполагания -- влияние (influence), повторяющее нотацию для отношения хода информации, и указывающее "позитивность" или "негативность" такого влияния.

Добавлено также 6 новых групп описаний:
-- заинтересованных сторон
-- воплощения целей
-- вклада целей
-- принципов
-- воплощения требований
-- целеполагания (все элементы вместе взятые)

3. Еще одно добавленное расширение -- реализации и перехода к новой архитектуре (implementation and migration) -- добавляет типы:
-- пакет работ (work package) -- серия действий, спроектированных (designed) для того, чтобы достигнуть уникальной цели за определенное время (обратите внимание, как аккуратно Архимейтовцы уходят от указания терминологии какого-то конкретного подхода проектного управления! Они так и говорят: моделировать пакетом работ можно проекты, под-проекты, а также отдельные задания (tasks) в проекте, программе или портфеле проектов.
-- комплектующее (deliverable) -- точно определенный результат (outcome) пакета работ (These may be results of any kind; e.g., reports, papers, services, software, physical products, etc., or intangible results such as organizational change. A deliverable may also be the implementation of (a part of) an architecture).
-- базис (plateau) -- относительно стабильное состояние (baseline) архитектуры, которое верно для какого-то периода времени. По факту вводит управление конфигурацией для архитектуры. В тексте обсуждаются не столько plateau, сколько именно конфигурационные базисы (baseline), почему я и оставил это в переводе (для экономии понятий -- ибо не будем же мы ориентироваться на TOGAF, с которым пытались совместиться в текущей версии -- уж как смогли).
-- расхождение (gap) -- результат (outcome) анализа расхождений (gap analysis) , который существует между двумя конфигурационными базисами архитектуры (что исчезает из одного и добавляется в другой базис. Это по сути держатель diff для базисов, где ассоциации с другими элементами помечены "убирается" и "добавляется").

Сюда же -- три новые группы описаний:
-- проектное (project) -- кто, что, зачем делает
-- перехода к новой архитектуре (migration) -- расхождения между архитектурными базисами в ходе проекта: что меняется в ходе смены базисов
-- реализации и перехода к новой архитектуре (implementation and migration) -- моделируется всё проектное, включая связи с элементами архитектуры)

4. Для того, чтобы бесплатно скачать с сайта OpenGroup кучу .pdf книжков по ArchiMate 2.0 (опубликован там три дня назад), нужно:
а) не обращать внимания на настоятельные пожелания приобрести какие-то evaluation license для этого стандарта;
б) получить регистрацию на сайте OpenGroup (и не путать с регистрацией в издательском магазине!), для чего постучаться в какой-то из форумов (например, в ArchiMate Forum -- и выскочит заветная кнопочка "зарегистрироваться". После заполнения анкетки вас пустят залогиниться на opengroup.org, а после подтверждения почты -- дадут скачивать бесплатные .pdf (их вышло много -- https://www2.opengroup.org/ogsys/jsp/publications/PublicationsByLatest.jsp).
в) на сам форум, впрочем, прорваться не дадут: это только для членов OpenGroup. Но вам должно хватить скачанных материалов.

5. Archi версии 2.2 с поддержкой этих понятий выйдет в конце февраля или начале марта. А пока можете насладиться третьей бетой версии 2.1 (http://archi.cetis.ac.uk/) -- там теперь можно делать "холсты" (canvas) типа используемых в http://businessmodelgeneration.com/canvas, причем со вставкой картинок. Восхитительно! Плюс много чего поправленного (так, теперь возможны cut/paste внутри текста метки элемента -- раньше копировался/вставлялся только весь элемент).

6. Другие постинги серии "Архимейт по-русски": http://ailev.livejournal.com/964544.html, http://ailev.livejournal.com/963548.html, http://ailev.livejournal.com/963190.html, http://ailev.livejournal.com/956829.html -- глоссарий, http://ailev.livejournal.com/956191.html, http://ailev.livejournal.com/955954.html.

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

E-xecutive
Как заставить регламенты работать
Как заставить регламенты работать

В вашей компании хаос, и вы думаете, что регламенты помогут вам упорядочить его? Решение верное, но вот достигают нужного результата единицы, а большинство выкидывает деньги и время на ветер. Какие ошибки совершают компании при разработке и внедрении регламентов, и как их избежать? Ответы и советы - в статье Сергея Ковалева.Далее

Мои твиты

Collapse )

Мои твиты

Мои твиты

Collapse )