?

Log in

No account? Create an account
Еще раз о планах релиза 2.3 PraxOS - Разработка PraxOS
January 13th, 2010
12:53 am
[ailev]

[Link]

Previous Entry Share Next Entry
Еще раз о планах релиза 2.3 PraxOS
Два дня подряд семинарили с vvagr у нас в офисе по поводу того, что такое PraxOS, и как его получить -- и даже нарисовали какую-то версию 0.1 карты действий и результатов (что, впрочем, никак не поколебало плана, изложенного в первом постинге praxos, http://community.livejournal.com/praxos/455.html -- каковой план продолжает потихоньку выполняться). Итоги этих посиделок:

1. Выделены базовые методы PraxOS:
-- ситуационная инженерия методов (ISO 24744, BPMN 2, STT, DEMO).
-- онтологическая инженерия (ISO 15926-2,7,8). Сюда же -- терминология (SBVR, SKOS).
-- нотационная инженерия (http://ailev.livejournal.com/546301.html, http://ailev.livejournal.com/548756.html, http://ailev.livejournal.com/549681.html, http://ailev.livejournal.com/613067.html -- хотя это только одна из школ, наверняка есть под другими названиями другие школы. Уж графическими языками кто только не занимался, и на тему выразительности графического представления наверняка должны быть работы.)

Эти методы должны быть применены, чтобы получить PraxOS. Проблема та же, что в получении любого "компилятора языка, написанного на самом этом языке": PraxOS нужен, чтобы получить эти методы, а эти методы нужны, чтобы получить PraxOS.

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

2. Определены базовые роли для сценариев использования PraxOS (напомню: use cases являются основным методом получения функциональных требований):
-- создатель ядра PraxOS (методологи-онтологи-логики-языковеды, они же писатели базовых методов; программисты -- в свою очередь писатели компиляторов-редакторов, и писатели веб-сервисов на базе OWL/RDF; а еще комьюнити менеджеры комьюнити всех остальных ролей). Эти люди напишут Софт PraxOS и начальные методы, при помощи которых потом заработает все остальное.
-- писатели методов (методисты-учителя-ученые/инженеры), которые будут пополнять репозитарий методов PraxOS, используя Софт PraxOS как композер методов.
-- ученики методов (которые используют репозитарий методов и привернутые к этому репозитарию справочные, обучающие, экзаменационные/рейтинговые и прочие приложения, не требующие method enactment), которые будут использовать Софт PraxOS как браузер методов.
-- пользователи методов (которым нужен именно method enactment для их конкретного проекта), которые будут использовать Софт PraxOS в целях управления жизненным циклом/процессом/проектом в их ситуации.

Вполне возможно, что прямо сейчас нужно применить метод персонажей.

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

Технология софта пока представляется больше всего похожей на гибрид бульдога, носорога, змеи и ежа:
-- language workbench, в которой вместо AST используется онтологическое представление в терминах ISO 15926-2, а языки определяются в терминах шаблонов из ISO 15926-7,8.
-- не только многонотационность, типичная для language workbench, но и многоязычность, что подразумевает не только разницу национальных языков i18n+l10n, но и разницу в словарных комьюнити (т.е. работу с SBVR, SKOS или чем-то подобным).
-- коллаборативность real-time обеспечивается по алгоритмам, гарантирующим синхронизацию миров (например, движком Cobalt/Croquet/Teleplace).
-- социальный аспект коллаборативности задается всяческими вариантами френдований/командообразований, рейтингований, разделяемых закладок, голосовых и видеочатов и т.д.. Как это происходит с технологической стороны пока непонятно.
-- универсальность и масштабируемость гарантируется использованием какого-нибудь triple store типа AllegroGraph и веб-интерфейсами как у MatrixOne (наряду с посадкой на облако)
-- enactment подразумевает выполнение каких-то вычислений над данными (а не только редактирование, поиски и отображение). Не факт, что все эти вычисления сводятся к логическим вычислениям (хотя первым в голову приходит вычисление критической цепочки и

Смешать, взбить, подавать горячим в вечной альфа-версии.
Абсолютно непонятно, как собрать команду, способную произвести такой технологический коктейль. Зато понятно, почему до сих пор ситуация с софтом PraxOS не сдвигалась с мертвой точки.

4. Репозиторий методов PraxOS будет считаться состоявшимся, ежели он будет примерно в объеме OPFRO (1100 элементов методов) плюс еще примерно столько же. Для начала туда нужно откомпилировать, перевести на русский и отредактировать по содержанию методы OPRFO, а затем добавить заново кодированные методы TOC. Это уже будет работа комьюнити методистов-учителей-ученых/инженеров PraxOS, а не создателей ядра PraxOS.

(9 comments | Leave a comment)

Comments
 
[User Picture]
From:smogendr
Date:January 14th, 2010 12:06 am (UTC)
(Link)
может я не в тему... но все же.
а если бы была задача научить пользоваться наработками Praxos пятилетнего ребенка,
то что бы вы могли предложить в качестве точки входа?
[User Picture]
From:ailev
Date:January 14th, 2010 05:47 am (UTC)
(Link)
это как раз в тему, но пятилетнему ребенку обычно неинтересно заниматься организацией коллективного труда в области системной инженерии, управления фирмой и прочими подобными делами. Кроме того, PraxOS предполагается в основном с текстовым интерфейсом, а пятилетние дети еще и читать-то толком не умеют...
[User Picture]
From:smogendr
Date:January 14th, 2010 09:15 am (UTC)
(Link)
хорошо, поднимаем планку до 10-и ;)
и берем способного ребенка, который хочет что-то сделать в коллективе
[User Picture]
From:ailev
Date:January 14th, 2010 10:53 am (UTC)
(Link)
Речь у ребенка формируется полностью в среднем к 11 годам, поэтому до этих пор бессмысленно.

Я думаю, что нам нужно брать 35-летнего человека с красным дипломом и опытом успешных проектов, и пытаться понять, чем PraxOS может помочь ему. Если удастся ему помочь, то тогда уже задумываться о том, как объяснить этот материал даже детям.

Когда-то даже лучшим физикам теория относительности была непонятна, а сегодня ее "проходят" в школе (да, проходят обычно мимо, но все-таки популярные объяснения наличествуют). Я думаю, что нам нужно пройти такой же путь: сначала сделать вещь, понятную даже не всем профессионалам, и заставить ее работать, а на следующем этапе она безо всякого сомнения будет упрощена, профанирована, популяризирована и придет в негодность от неумелого применения детьми.
[User Picture]
From:smogendr
Date:January 14th, 2010 09:44 pm (UTC)
(Link)
>Я думаю, что нам нужно брать 35-летнего человека с красным дипломом и опытом >успешных проектов, и пытаться понять, чем PraxOS может помочь ему
у вас это еще не проработано? я удивлен. вообще вашими словами удивлен.

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




[User Picture]
From:sergeyvi
Date:January 14th, 2010 11:21 am (UTC)
(Link)
На мой взгляд, набор требований к софту PraxOS однобок. И главная его однобокость - в том, что требования охватывают возможности организации масштабной работы, но совершенно не лезут внутрь процессов ее организации. Именно поэтому Вы и имеете мертвую точку, с которой чтобы слезть, надо быть титантом в первоначальном смысле этого слова.

Предлагаю классический итеративный подход.

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

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

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

Делай X: эпизодически обновляем релиз софта до состояния, до которого дотанцевалось множество ПроСИN, их абстракции и конкретные релизы.

Дальше среда саморазвивается трудом энтузиастов, но каждый конкретный шаг ее саморазвития - несопоставимо меньше и выполнимее, чем задача создать нечто, описанное Вами под пунктом 3.

Как Вам идея? И, кстати, буде заинтересованность с Вашей стороны, с удовольствием готов принимать участие в дальнейшем структурировании вопроса.
[User Picture]
From:ailev
Date:January 16th, 2010 05:55 am (UTC)
(Link)
Во-первых, у нас и так итеративный подход. Так, планирующийся сейчас релиз PraxOS у нас совершенно не случайно отнумерован 2.3 -- мы прошли довольно много итераций до этого момента.

Во-вторых, мы начинаем не с нуля. Например, поглядите на уже неплохо закодированный репозиторий http://opfro.org -- там довольно много элементов методов. Мы хотим на этой стадии прихватить дополнительно только маленький кусочек: планирование процессов по теории ограничений.

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

В-четвертых, мы хорошо представляем, что enactment для процессов будет происходить в CAD-системах (ну, в крайнем случае в каких-нибудь финансовых системах, но это не представляется пока главным). Так что про "все процессы" это преувеличение. Какой-нибудь процесс проектирования отрезка трубопровода в какой-нибудь промышленной установке, или процесс инжиниринга плана производства работ для стройки -- вот первичные "процессы" для enactment (пишу в кавычках, ибо терминология тут должна быть еще уточнена).

Участие, конечно, приветствуется. Возьмите какой-нибудь кусочек -- и вперед! Хоть софт, хоть методы, хоть примеры, хоть методологию...
From:sys_eng
Date:February 6th, 2012 12:18 pm (UTC)
(Link)
Видимо предметом ПраксОС можно обозначить (отъярлычить? то есть не понятие найти, а ярлыком пометить) "набор инструментов (методов, способов) для координации совместной целенаправленной деятельности людей-организаторов". (а самоорганизаторы сюда попадают? Тогда и методы личной продуктивности тоже должны быть: как отвертки разложить на верстаке и пр.).

Целенаправленность очень разная, на разных временных горизонтах (ЖЦ нефтеплатформы - строительный цикл нефтеплатформы - закупочный цикл - отчетный период закупочного цикла - оплата счета в закупочном контракте - ...); на разных количествах людей; на разных типах предмета работы (металл - чертеж - инфомодель - подай-принеси! - а вы риски предотвратили? - ...). И координация очень разная (ЖЦ - Проектная - Процессная - Ситуационная - ...). Значит, и методы в ПраксОСе должны быть разными очень, чтобы ухватывать эти все разнообразия. Плюс внутри должны быть методы рефлексирования. Поэтому народ ждет конечно методов "сверху донизу", до последней гайки и карандаша.

Очевидно, что напрашивается метод наполнения ПраксОС: КраудКукинг (совместное приготовление); как "один из". Авторам виднее, какие требования должны быть к ПраксОСу, чтобы были открытиые АПИ для пополнения методов; как верифицировать метод при добавлении (вики-песочница или бассейн выдержки?); как воздавать витрину методов; как собирать отзывы и "репорты о применении".

Возможно, что каждая отдельная инсталляция ПраксОС (в отдельной группе лиц) могла бы как-то (как? С какими целями? Протоколами? Какими предметами?) обмениваться-общаться с другими (а может, и с МегаПраксОСом!?) для передачи предметов для обработки-координации; а не только координировать людей внутри одной локальной инсталляции ПраксОСа. Ведь для решения задач координации "относительно ЖЦ большого Изделия-Системы" придется координировать очень много различных групп людей, у них явно не будет одной инсталляци ПраксОСа.
[User Picture]
From:ailev
Date:February 6th, 2012 01:48 pm (UTC)
(Link)
Вопрос правильный: как поддерживать разнообразие? Ответ у нас такой: мы должны выдать форму, которая позволяет одинаково выражать самое разное содержание. И должны как-то гарантировать, что самое разное содержание будет выразимо в этой форме. И мы довольно быстро продвигаемся в этом, создавая ОргЛан на базе унифицирующей аккуратное представление мира факт-ориентированной 4D системной онтологии ISO 15926.

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

Что же касается собственно организовывания людей, то у PraxOS тут планируется свой наборчик методов, кроме "общей формы выражения". Ибо тут мы и сами чуть-чуть технологи, про стратегирование можем что-то рассказать современное, про управление кейсами/проектами и т.д.

Насчет совместимости инсталляции PraxOS -- верхние уровни и принципы совместимы, а нижние уровни и конкретное наполнение будут уникальны. Это очевидно, как и с любыми системами такого сорта.
My Website Powered by LiveJournal.com