?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Мой доклад на АПСПИ-2015 в секции "системная инженерия" [22 May 2015|10:05am]
Мой доклад "Essence в варианте для системной инженерии" 21 мая 2015 на четвёртой научно-практической конференции «Актуальные проблемы системной и программной инженерии» (АПСПИ - 2015)</h1>

Слайды (http://www.slideshare.net/ailev/syseng-apspi-may15):


Опубликованные тезисы (в сборнике трудов конференции ISBN 978-5-94768-073-7):

УДК 004.436.4 + 65.012
Анатолий Левенчук, ailev@asmp.msk.su
TechInvestLab, г.Москва

Подход к Essence в варианте для системной инженерии Что нужно для Essence в варианте для системной инженерии по сравнению с содержащим Язык и Основы (kernel) Essence в варианте для программной инженерии из стандарта OMG Essence [1]?

В работе сформулирован ряд требований, которым должен удовлетворять Essence в варианте для системной инженерии. Эти требования ведут к необходимости изменить как Язык, так и Основы. Эти требования сформулированы с учётом удовлетворения потребностей разных стейкхолдеров инженерного проекта – системного инженера, инженера моделеориентированной системной инженерии и моделеориентированного концептуального проектирования, системноинженерного менеджера, менеджера, модельера данных.

Для ряда требований сделаны предложения по минимальному изменению Основ (kernel): замене альф области интересов инженерного решения в варианте для программной инженерии (Требования и Программная система) на альфы в варианте для системной инженерии (Определение системы и Воплощение системы).

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

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

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

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

На основе предложенных изменений был выпущен продукт Русского отделения INCOSE [2].

Литература
1. OMG Essence (2014) – Kernel and Language for Software Engineering Methods, specification (http://www.omg.org/spec/Essence/Current)
2. Anatoly Levenchuk, Towards a Systems Engineering Essence – INCOSE Russian chapter product, 2015 (http://arxiv.org/abs/1502.00121)

УДК 004.436.4 + 65.012
Anatoly Levenchuk, ailev@asmp.msk.su
TechInvestLab, Moscow

An approach to a Systems Engineering Essence

What may be a Systems Engineering Essence in comparison with Software Engineering Essence (Language and Kernel provided by OMG Essence [1])?

The work suggested requirements for Systems Engineering Essence. These requirements drive changes in Essence Language as well as in Kernel. In addition, the requirements address concerns of various stakeholders of a systems engineering project, such as systems engineer, model-based systems engineer and model-based conceptual engineer, systems engineering manager, general manager, data modeler.

To fit the requirements, minimal changes of a Software engineering Kernel in solution area of concerns (Requirements and Software systems alphas) needed. These alphas should be changed to Systems Engineering Essence solution area of concerns alphas (System definition and System realization alphas).

Suggested Kernel changes supports expression traditional systems engineering notions (stakeholder needs, requirements, architecture) in Essence Language. Also these changes convenient for expressing verification and validation alpha associations.

Suggested Kernel changes also harmonized with several systems engineering standards.

Also there is need for different enterprise activities viewpoints that reflect particular endeavor area of concerns alphas.

All these changes tested for the enterprise engineering. In this case we need simultaneously diagramming two projects. One of them is project of interest (e.g. systems engineering project), another is change management project (e.g. introducing some kind of systems engineering methodology and tools in an enterprise). In this enterprise engineering case Language and Kernel are used for description of both project of interest and change management project and we need Language elements that permit expression links between two projects.
On a base of these suggestions there was published INCOSE Russian chapter product [2].

References
1. OMG Essence (2014) – Kernel and Language for Software Engineering Methods, specification (http://www.omg.org/spec/Essence/Current)
2. Anatoly Levenchuk, Towards a Systems Engineering Essence – INCOSE Russian chapter product, 2015 (http://arxiv.org/abs/1502.00121)
post comment

Мой доклад на АПСПИ-2015 в секции "SEMAT методология" [22 May 2015|10:17am]
Мой доклад "Essence для управления технологиями" 21 мая 2015 на четвёртой научно-практической конференции «Актуальные проблемы системной и программной инженерии» (АПСПИ - 2015).

Слайды (http://www.slideshare.net/ailev/sysmgmt-apspi-may15):


Опубликованные тезисы (в сборнике трудов конференции ISBN 978-5-94768-073-7):

УДК 004.436.4 + 65.012
Анатолий Левенчук, ailev@asmp.msk.su
TechInvestLab, г.Москва

Essence для управления технологиями

Известен Essence [1] в варианте для системной инженерии [2]. В настоящей работе делается попытка использовать этот вариант Essence не столько для описания практик системной инженерии, основывающихся главным образом на альфах Определения и Воплощения системы, сколько для практик управления технологиями – менеджерских практик.

Под термином «управление технологиями» (technology management) скрываются довольно много разных вариантов понимания содержания дисциплины (area of concern). Можно выделить несколько основных вариантов:
-- предпринимательство, стратегирование и маркетинг (основные альфы Возможности и Стейкхолдеры),
-- использование современных технологий (основная альфа Технология), предмет заботы CTO и CIO.
-- инженерный менеджмент (основные альфы – Работа и Команда), при этом нужно учитывать, что классический инженерный менеджмент тяготеет к операционному управлению в ситуации, когда «организация делает что-то в миллионный раз», а управление технологиями занимается этим когда «организация делает что-то в первый раз» [3]

Предложены расширения Основ (kernel extension) для учёта специфики управления технологиями.

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

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

В работе ставятся вопросы о развитии Языка Essence для облегчения обсуждения вопросов технологического управления.

Литература
1. OMG Essence (2014) – Kernel and Language for Software Engineering Methods, specification (http://www.omg.org/spec/Essence/Current)
2. Anatoly Levenchuk (2015), Towards a Systems Engineering Essence – INCOSE Russian chapter product, (http://arxiv.org/abs/1502.00121)
3. Galbraith, J.R. (1982) – Designing the Innovating Organization, Organizational Dynamics, 10, 3:5-25


УДК 004.436.4 + 65.012
Anatoly Levenchuk, ailev@asmp.msk.su
TechInvestLab, Moscow

Technology Management Essence

Based on the OMG Essence [1] there known Systems Engineering Essence [2]. This work is using Systems Engineering Essence not to based primarily on the System Definition and System realization alphas practice of systems engineering descriptions, but for technology management practices descriptions.

The term «technology management» is used for different disciplines (areas of concern). We can distinguish several basic variants:
-- Entrepreneurship, strategy development and marketing (based on Opportunities and Stakeholders alphas).
-- The use of modern technology (based on Technology), the concern of CTO and CIO.
-- Engineering Management (based on Work and Team). You will need to take into account that the classical engineering management tends to operational management in a situation where "the organization is doing something for the millionth time," and technology management when "organization does something for the first time "[2].

In our work, we suggest Essence kernel extension for a technology management. There are three kind of systems that should be mentioned by technology management, possibly in a separate but linked Essence projects:
-- The system of interest for which you want an engineering solution, is the subject of the primary project.
-- Using system is subject of strategizing and marketing projects. Needs alpha is about using system characteristics.
-- enabling system is subject for technology management work with Way of Working and Team alphas and Enterprise Owners sub-alpha of Stakeholders alpha.

Technology management practices should link all these projects and their conflicting requirements. Opportunity window should be bidirectional and synchronous opening in time towards the team and external stakeholders. Design decisions should be consistent with not only the team and customers concerns, but investors’ concerns too. There should not be confused project-endeavour and venture-endeavour: project portfolio decisions should be made "on margin", depending on the resource loads in the enterprise as a whole.

The paper also raises questions about the Essence Language development for a technology management modeling.

References
1. OMG Essence (2014) – Kernel and Language for Software Engineering Methods, specification (http://www.omg.org/spec/Essence/Current)
2. Anatoly Levenchuk (2015), Towards a Systems Engineering Essence – INCOSE Russian chapter product, (http://arxiv.org/abs/1502.00121)
3. Galbraith, J.R. (1982) – Designing the Innovating Organization, Organizational Dynamics, 10, 3:5-25
post comment

Заметки с SEMAT track на АПСПИ-2015: проблематизируем Essence [22 May 2015|12:36pm]
От русского отделения INCOSE было 8 докладов про разные приложения Essence, плюс были доклады от русского отделения SEMAT -- эдакий фестиваль. Вот пара моих заметок:

1. Практически все замечали, что с помощью Essence много быстрее учить студентов. Хорошая явно задаваемая онтология позволяет заменить "опыт" на быстро передаваемое знание. Почему? Мой ответ: основное знание кодируется в альфах. Оно:
-- компрессирует знание про рабочие продукты в 6-10 раз, задаёт уровень абстрации
-- позволяет обсудить как инженерные, так и менеджерские аспекты проекта. Системный инженер обсуждает содержание альфы, CTO обсуждает практики (дисциплины и технологии) работы с альфой, а операционный менеджер ресурсы и время работы с альфой.

2. Альфа четырёхмерна (оставим пока в сторону очевидные онтологические непонятки). Это позволяет легко понимать альфу в том числе как activity по изменению участвующих (отношение participation) в ней рабочих продуктов. Скажем, альфа Team -- это activity с командой (изменения, процессы, происходящие с командой во всё время её существования). В любой момент я могу говорить не про activity аспект (аспект изменений), а просто обозначать альфой участвующие предметы. Тем самым альфа это product-based способ описания, в котором изменяющиеся и имеющие разные состояния products (artifacts). Трекинг (как в issue tracking) идёт именно альф. Case management -- альф. Четырёхмерие тут даёт смотреть на альфу и как на (изменяющуюся) вещь, и как на сам процесс изменения (вещи).

3. Моя страшная гипотеза в том, что состояния альфы -- это тоже альфы (подальфы), равно как чекпойнты это тоже альфы (подальфы). То есть "иерархия трёх типов" это традиционный случай введения первоначально жёсткой по типам и числу уровней иерархии, а затем признания факта, что никаких особых там отдельных типов нет, а число уровней N. Это очень консистентно с тем, что происходит в проектном управлении: жизненный цикл бьют сначала на гейты, затем вводят контрольные точки посередь стадий, затем вводят контрольные точки по отдельным частностям -- и получают порядка 1000 контрольных точек (для выпуска Боинга) или 15000 контрольных точек (для проведения Олимпийских игр). Это по факту уже case management, issue tracking -- это не процессное, не проектное управление. И это же проясняет, почему в классической литературе по case management сами кейсы именуются по основной вещи, которая изменяется в ходе кейса (кандидаты, менеджеры), а иногда и мероприятия (интервью) -- http://ailev.livejournal.com/946134.html.

Такой онтологический взгляд даёт ответ на некоторые "трудные вопросы":
-- почему никакой особой стадийности/гейтовости не наблюдается в состоянии альф? Потому как можно очень по-разному нарезать входящие в activity объекты на темпоральные части (сами по себе activity).
-- почему отдельные чекпойнты так и хочется ставить в разные состояния разных альф? Потому как они сами подальфы (темпоральные части) этих подальф (состояний альф). И да, с чекпойнтами тоже идёт большая работа по изменению участвующих в чекпойнтах темпоральных частей.

4. Если мы принимаем этот продуктно-работный дуализм альф, то сразу понятно становится связь не только с case management/issue tracking, но и всем lean. Например, small batch size -- это про измельчение альф (набора участвующих в работах объектов), что эквивалентно измельчению связанных с этими объектами работ. И этот же дуализм и четырёхмерие объясняет все трудности объяснения альф, case, issue -- это очень хитрые объекты из чуждой пока обыденному восприятию 4D экстенсиональной онтологии. В таком подходе сам проект -- это case/issue/topalpha, а семь альф -- это его "канонические подальфы", то есть иерархия не со срезанной верхушкой. Более того, в этом случае понятно, как включать проект в проект/кейс/issue более высокого уровня. Там можно придумать какой-нибудь вариант IEC 81346, позволяющий именовать структуру не только статичной целевой системы, но и связанных с ней работ (то есть включать именование и обеспечивающей системы тоже, а также задумываться о включении в рассмотрение используемой системы).

5. Вообще, отсутствие в явном рассмотрении в Essence используемой системы меня напрягает сильно. Ибо пока там в виде подальфы возможностей есть только Needs. Обеспечивающая система рассматривается наряду с целевой системой, и даже более детально (аж три альфы endeavour).

5. Похоже, что текущий вариант показа проектов технологического развития -- это не столько удвоение ядра (две диаграммы Essence для целевой системы и обеспечивающей системы соответственно), сколько порождение новых area of concerns в рамках того же ядра. То есть Team общая для команды развития и команды проекта, а они сами подальфы Team, хотя и разведённые в разные area of concern (а не две топовые альфы).

6. Все эти соображения пока крайне мутны, но все мои мысли больше и больше ведут к желанию сделать Essence 2. Но не в варианте именно как Essence 2, а в варианте ArchiEssence -- case management/issue tracking ready, с диаграммами как в ArchiMate и простыми карточками как в Essence.

Конечно, я помню и про SysMoLan, но там размышления у меня больше про другие аспекты (мультимоделирование, теоркатегорный формализм и т.д. -- меньше управления жизненным циклом, больше собственно системной инженерии).
13 comments|post comment

Летние планшетные математические игры для школьников [22 May 2015|02:39pm]
Сезонные продажи математических игр (Android и iOS) рекомендуются как идеальное средство освежить школьные знания по математике во время летних каникул. Ибо забывается всё быстро (и далее в рекламках идут цифры, свидетельствующие, что "ну очень быстро"). Я купил отроку сразу три игры:
-- геометрия DragonBox Elements (https://play.google.com/store/apps/details?id=com.wewanttoknow.Euclid)
-- алгебра DragonBox Algebra 12+ (https://play.google.com/store/apps/details?id=com.wewanttoknow.DragonBox2)
-- математика разных классов Math Planet -- For Grades 1-8 (https://play.google.com/store/apps/details?id=air.com.playpowerlabs.mathplanetapp, и там внутри pack для middle school -- это 6-8 класс американской школы).

Отрок за сутки справился с Elements (хвалёные 100+ заданий). И сказал, что остальные игры ему не нравятся и вряд ли он в них будет играть. Чуйка его не подводит, выполнение упражнений по школьной программе detected, какие же это игры?! Ничего, в транспорте и очередях всё одно делать нечего -- потихоньку все перерешает. Но что-то мне подсказывает (судя по прохождению Elements за день), что две других игры могут сыграться неожиданно быстро, дело даже до лета не дойдёт. Это при всём его нежелании в них играть.

А в какие игры он хочет играть? Всё своё свободное время он тратит сейчас на Civilization: Beyond Earth. Но там никакой алгебры и геометрии.

После алгебры и геометрии начинаем физику. Там три опции:
-- классическая (с ручкой и бумажкой и старым задачником физматшколы)
-- интерактивная (например, вольфрамовская физика для школы -- https://play.google.com/store/apps/details?id=com.wolfram.android.physicsi). Более игровые формы и работу с моделерами (http://www.algodoo.com/, http://physion.net/) я отнёс бы сюда же -- но тут важны не сами моделеры, а именно curriculum. Так что нужно ещё разобраться.
-- лабораторная с физическими объектами (например, с роботами -- http://shop.robotslab.com/products/robotslab-box). Тут есть несколько вопросов: а) почему это так дорого и б) насколько это круче для учебных целей, чем компьютерное моделирование (те же роботы, но на экране дисплея).

Ну, и алгоритмика -- чтобы скриптовать всю эту физику. Математика, геометрия (это совсем другая часть мозга, нежели алгебра-вычисления), физика в ассортименте, алгоритмика. Пока без инженерии. Привет, лето.
14 comments|post comment

Теплокровная рыба-луна [22 May 2015|02:57pm]
Не могу выбросить из головы новость про теплокровную рыбу-луну (она машет плавниками, разогревая мышцы, а потом хитрый теплообменник в жабрах разгоняет это тепло по всему телу -- и температура тела становится больше температуры окружающей воды на 5°C, что даёт огромное преимущество в подвижности этому хищнику) -- https://swfsc.noaa.gov/news.aspx?ParentMenuId=39&id=20466 (статья тут. Обращу внимание, что теплокровный мозг у рыб был найден довольно давно, например, тут -- фишка открытия была в том, что тепло у рыбы-луны распространяется на всё тело, а не только держится под черепушкой).

Основная моя мысль тут про то, как же мы ещё мало знаем про окружающий нас мир. Теплокровные рыбы открыты в 2015 году! Более того, теплокровной оказалась всем знакомая рыба-луна (которую я сам неоднократно видел в аквариумах, но даже в голову не приходило, что она может быть теплокровной).
2 comments|post comment

navigation
[ viewing | May 22nd, 2015 ]
[ go | previous day|next day ]