Ретро культ карго

Впечатления от семинара сегодня на инжеке. Специально не пишу название и не упоминаю тему.

Я рад, что на факультете начали вести семинары (отдельное фе отсутствию рассылок и сайта поддержки, но будем рады и объявлению на стене). 

Опечалило, две вещи: 1) что на семинаре рассказывали про метод по состоянию на начало 1970-х годов; 2) в качестве инструмента рекомендовали ручками заполнить матрицу смежности в Excel и вести расчеты в нем

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

Не притязая на системность и не обосновывая необходимость, считаю, что минимум нужно формировать навыки работы:
1. с данными, минимум в объеме http://libraries.mit.edu/guides/subjects/data-management/
Правда к этому курсу нужны библиотеки данных типа такойhttp://libraries.mit.edu/guides/subjects/data/index.html
А учитывая, что лаборатория баз данных на инжеке есть, а библиотеки данных нет можем активно инсинуировать :)

2. с солверами, например с солверами линейного программирования и аналогами. Важно уметь ставить вычислительные эксперименты. Времена когда все выводы можно было сделать по формуле из пяти элементов кончились :)

Кстати солверы без п 1 бесполезны.

По работе с с пакетами статистики надеюсь, что студентов учат в них работать. Интересно в каких пакетах учат работать, надеюсь не только в Excel?

3. с геоинформационными системами (ГИС). Думаю пояснять зачем ГИС нужны не нужно :) Правда где у нас банк картографических подложек унифицированный с п 1 :)

4. с ментальными моделями. Минимум с mindmap, желательно с concept map, идеально с диаграммами системной динамики.
Умение выражать гипотезу это базовый навык аналитика, лучше если выражение будет не в форме лингвистической модели.

5. с информацией. Курс базовый, как искать и спрятать информацию поближе, чтобы найти когда надо :) Минимум работа с источниками, сбор библиографии и тд. Дополнительно хорошо проводить семинары где студенты докладывают, что они прочли из списка выданного руководителем семинара. Важно это не один список который выдан всем, каждый получает по своей статье и статья должна быть из последнего выпуска топового журнала и не нужно перед выдачей студентам читать текст статьи

Введение в системную инженерию

Дисциплина: «Введение в системную инженерию» (поток техников СП-649)

Осень 2012 г.

Один семестр:

3 семестр

36 часов (16 часов лек, 20 лаб), реферат, зачет 3 ЗЕТ

Преподаватель: Акоев Марк Анатольевич

Телефон кафедры ПСС: 375-97-18

Информация по предмету в блоге: http://akoev.blogspot.com/search/label/SysEng

Литература

1. А.И. Левенчук Курс "Введение в системную инженерию" в МФТИ (http://ailev.livejournal.com/980403.html).

2. Материалы заседаний Русского отделения INCOSE (http://incose-ru.livejournal.com/).

3. В.К.Батоврин, Системная и программная инженерия. Словарь-справочник. ДМК-Пресс, 2010.

Отдельно к каждой теме

7 семестр

Занятия	Тема
1-2	Тема 1. Дисциплина системной инженерии и роль системного инженера.
3-4	Тема 2. Понятие системы.
5-6	Тема 3. Понятие жизненного цикла.
7-8	Тема 4. Стандарты системной инженерии.
9-12	Тема 5. Моделеориентированная системная инженерия.
13-14	Тема 6. Практики определения системы.
15-16	Тема 7. Практики воплощения системы.
17-18	Тема 8. Системы систем. Организационная инженерия. Организация производства

Введение в системную динамику для экономистов

И426 УрФУ в 16:00 14 мая 2012 г

Презентация тут http://www.slideshare.net/Marcus.Akoev/ss-12920819 для скачивания зарегистрируйтесь (регистрация бесплатна).

Звук будет тут (если не забуду записать :)

Дополнительное чтение: "Гарри Поттер и Методы Рационального Мышления"

Семинар: Архитектурное описание для корпоративных и инженерных информационных систем. Подход ArchiMate

Семинар Архитектурное описание для корпоративных и инженерных
информационных систем. Подход ArchiMate
Докладывает: Марк Акоев (40 мин представление стандарта и демонстрация
примеров, плюс обсуждение).
Семинар состоится 02 марта 2012 года в 18:00 по адресу:
главный корпус УрФУ, ауд. И-426*. Контактный телефон: 375-97-18.
Приглашаются все желающие.

На семинаре будет дан обзор языка ArchiMate (стандарт Open Group).
Язык предназначен для описания архитектуры информационных систем (как
связи бизнес-слоя), использующихся программных систем и оборудования,
на котором информационные системы функционируют.

Обзорная информация о языке http://ailev.livejournal.com/940819.html

Бесплатный инструмент создания диаграмм редактора (Archi):
http://archi.cetis.ac.uk/

Презентация, примеры и звук будут выложены тут.

* ул. Мира 19, главный корпус УрФУ, в главном корпусе направо, на
второй этаж по лестнице, по коридору прямо, дойти до лестницы и на 4
этаж налево. Для прохода через охрану необходимо иметь при себе
документы государственного образца с фотографией, удостоверяющие
личность (паспорт, студенческий, водительское удостоверение).

==========
Зачем нужен еще один язык описания архитектуры?
Те компании которые примеряют архимейт, выигрываю в следующем:

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

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

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

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

Доводы за и против использования смотрим тут:
http://ailev.livejournal.com/940819.html

update
Слайды http://www.slideshare.net/Marcus.Akoev/ss-11830985

Мечта о системе управления показателями

решил зафиксить мысль, тк в конторе мысль не нужна.

Цель снизить затраты на механическую обработку данных в аналитике.

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

Потребители: аналитики и работники служб отчетности в организации.

Почему нужен новый продух и нет радости от существующего, например от SQL баз? Проблема в том, что SQL не проходит по двум причинам: 1) данные между рядами из разных источников могут быть противоречивы, в РМД можно противоречивы данные хранить, но хочется упростить затраты на создание схемы данных учитывающей неконсистентность данных с точки зрения полноты и точности; 2) заранее не известно какие данные может потребоваться хранить в системе и выделять из данных ключи и поддерживать ссылочную целостность.

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

Требования для системы управления показателями:

1. нужно уметь формировать систему показателей: для каждого показателя указать что это, как собирается, кто источник данных, когда порождены, единицы измерений, как связаны с другими показателями (связь по ссылочной целостности, вычисляются, проверяются и пр). то есть система показателей образует онтологию   (в смысле машиночитаемое описание представлений о мире, проще не парится и брать в качестве основы промышленный стандарт ISO 15926). С онтологией системы показателей нужно уметь работать: изменять, трансформировать и версионировать (тут засада, проблема не обсуждалась на уровне теории, типа мне про это не известно :( ). Задача решаемая, топовые онтологии есть (ISO 15926, Gellish), ПО для работы есть (triple store), будет проблема с версионированием, но можно найти решения для работы.

Работа архитектора над такой системе будет сводится к продумыванию изменений онтологии при появлении новых параметров.

2. значения показателей чаще всего образуют временные ряды: те что наблюдались в реальности (взяты из КИС), вбиты из текстовых справок, взяты с потолка и отданы наружу. Значения должны версионироваться и для них должны хранится срезы в какой документ конкретное значение с конкретным источником было выдано.

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

Результат отдали наружу, и зачем где и как соврали, можем даже написать почему соврали.

3. Для сбора данных из КИС пишем конекторы, которые сосут данные, для людей модуль опросы. Важно значения живут в моделе Bunge-Wand-Weber (то есть тройками значение-отношение-значение), но хранятся в РБД, схема которой изменяется с изменением данных без потерь значений и информации автоматом по онтологии. Очень напоминает то что делается в платформе (речь идет о внутреннем фреймворке используемом на фирме), только на более высоком уровне. Плюс работа с данными строится в терминах привычного языка выборок который работает напрямую с РБД, проблему с модификациями запросов нужно думать. Технологии тоже уже есть, некоторые в экспериментальном виде.

4. Работа с данными скорее будет производится в табличном редакторе, то есть для создания среза для анализа данных отбираем объекты про которые хотим построить набор данных, смотрим каие параметры есть, анализируем полноту покрытия параметров за интересующий период времени и заполняем срез данными из системы. Дальше анализируем средствами табличного процессора или внешней аналитической системы.

То что написано выше напоминает то как работают финансовые и прочие аналитики, но у них нет явной задачи работать с противоречивыми значениями и темпоральной логикой над ними я пытался найти в мире статистики похожую систему, но не нашел возможно системы пока в зачаточном состоянии.
Ближайшее что нашел это  http://wikiposit.org/w , но немного не то нет возможности связать данные из разных наборов, например вытащить все что есть по перечню вузов.

То что описано выше это страшная смесь системы управления записями поверх кусков реляционной модели склеенной онтологией и все вместе живет в машине вывода :(.

много буков, и счастья нет :)