?

Log in

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

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

Фрайди найт [28 Mar 2009|12:49am]
Сегодня было много-много организационной работы весь день, и много-много новейших технологий весь вечер.
* * *
Ну вот, термоядерный инерциальный синтез тоже оказался с военным применением. На этих экспериментах получают данные для последующего компьютерного моделирования термоядерного оружия -- http://www.cnews.ru/news/top/index.shtml?2005/05/27/178574.

Гнездо российских инерциальщиков: http://www.vniief.ru/directions/research/synthesis/. По-русски это будет "лазерный термоядерный синтез". Самая передовая установка -- Искра-5 (К сожалению, „скорострельность“ подобной системы очень низка. Это связано с тем, что в йодных лазерах каждый раз после срабатывания требуется замена газовой среды. Цикл перезаполнения газом одного канала занимает как минимум сутки. То есть, грубо говоря, одним каналом удается „стрелять“ один раз в день, а двенадцатью каналами одновременно — только раз в неделю. К тому же после „выстрела“ очень много времени уходит на то, чтобы понять, что же в результате получилось. -- http://wsyachina.narod.ru/physics/lts.html).

Вообще, шапкозакидательных идей на термоядерные темы много. Например, хотят каждые полчаса в спецбункере взрывать дейтериевые 10Ктонн, высвобождая 37Гвт тепла в натриевый теплоноситель -- "взрывная дейтериевая энергетика" (http://wsyachina.narod.ru/technology/explosive_energetics.html). Существенный сдерживающий фактор -- это режим нераспространения. Идею высказывали еще в 40-е годы, и принцип ничем не отличается от идей инерциальщиков-лазерщиков, только вместо "трех микровзрывов в секунду" происходит "один макровзрыв в полчаса". Как я понимаю, вопросы типа "а как будем чинить при поломках" для этого проекта лучше не задавать (впрочем, другие проекты в этом отношении немногим лучше).
* * *
В России сейчас 11 членов INCOSE, 8 из них я знаю (incose_ru).
* * *
К Лебедевским чтениям (http://g-l-memorial.ice.ru/) есть уже пять заявок на доклады.
* * *
Никак не могу привыкнуть к документам, в которых указываются сроки окончания проектов в 2020 и даже в 2050 году.
* * *
Пониманий априорности может быть великое количество -- огромное число философов сражается с кантовским пониманием априорности, а Кант всего лишь популяризировал более ранние понимания. "Аристотелевская априорность" -- это просто различие в "доказательствах от последующего и доказательствах от предшествующего" (http://ru.wikipedia.org/wiki/%D0%90%D0%BF%D1%80%D0%B8%D0%BE%D1%80%D0%B8).

Примеры этих "чтотакоеаприорность"-рассуждений: "К вопросу об «априорности» математического знания" -- http://www.philosophy.ru/library/katr/math_conf2001.html. На эту же тему -- http://credonew.ru/content/view/118/24/.
11 comments|post comment

Movement (Collaboration Networks) System Engineering [28 Mar 2009|01:53pm]
Системная инженерия "движений" (понимаемых как коллаборативные сети), конечно, требует отдельного огромного "программного постинга". Но при текущем бюджете моего времени на такой постинг времени все равно не хватит, поэтому ограничусь краткими тезисами-заметками для самого себя, чтобы когда-нибудь к ним вернуться и расшифровать поподробней.

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

Такого сорта часто называют "движениями", например (и давние, и только организуемые):
-- толкинутые
-- СМД-методология
-- АРИЗ/ТРИЗ
-- политхакинг (http://david-gor.livejournal.com/81528.html)
-- австрийская экономическая школа
-- инвестиционная "неофициальная" сеть (инициатива в Ростове-на-Дону)
-- системная инженерия (которая живет, конечно же, не только в рамках INCOSE, но и как "движение")
-- дворовой/корпоративный спорт (в отличие от спорта профессионального, который организован по-другому)
-- как ни странно, организация реформирования в больших холдингах (меньше "отрасли", но явно больше одной организации-юрлица, чтобы исключить управление прямыми командами и кадровыми заменами, масштабы порядка десятка тысяч человек)
-- огромное количество других подобных структур, которые "организованы" достаточно, чтобы восприниматься как отдельный объект с собственным названием, но не имеют явной "штаб-квартиры", диктующей правила (или имеют множество конкурирующих "штаб-квартир").

Тут я бы временно (ввиду недостатка времени) уклонился от обсуждения самого термина "движение", использования для его описания терминологии сетевых организаций, сравнения "движений" и профессий, "движений" и community of practice.

Речь идет о таком виде организационной инженерии, которую нельзя вот так просто перевести enterprise engineering, ибо "движение" мало напоминает "организацию", у развитого "движения" множество "штабов", а большинство участников никак из этих "штабов" не "управляются". Поэтому прекращаем употреблять этот "административно-военный" сленг даже в кавычках. Будем говорить о collaborative network engineering, инженерии сетевого сотрудничества, не дотягивающего даже до организаций сотрудничества (collaborative networking organizations) ввиду отсутствия явных организационных границ, полномочий и "договоров на присоединение к сети-как-организации" (http://ailev.livejournal.com/652159.html -- тут немного про collaborative networking organizations) .

А теперь несколько дисклеймеров:
-- я, конечно, знаю все возражения против социальной инженерии (не http://ru.wikipedia.org/wiki/Социальная_инженерия как общее название для претекстинга, фишинга, троянского коня, дорожного яблока, кви про кво и прочих методов подлавливания людей для получения несанкционированного доступа к чужим компьютерам, и не социальная инженерия как синоним любого вмешательства в рыночный механизм со стороны государства, профсоюзов или центрального банка, подаваемая Мизесом в качестве прикладного гарнира к социальной физике. Нет речи также о "социальной инженерии" типа той, что у Гастева (http://www.ido.rudn.ru/lectures/201/H9.htm). Никаких "научной организацией труда на основе математики" или "инженерного подхода к распределении труда и ресурсов в обществе". Мы тут про другое.
-- существенно используется представления о системе из людей как кентавр-системе: искусственно-естественной. С одной стороны, люди отлично понимают, что их "строят" и могут выбрать, "построиться" ли им, или сопростивляться их "построению". Тем самым люди не похожи на материал, с которым работают инженеры. Люди также много круче киберфизических систем ("железных" систем, в которые добавлен софт, разработанный таким большим числом людей, что даже создатели не понимают, как работает итоговая смесь железа и программ), ибо люди могут активно сопротивляться их "построению", а киберфизическая система в этом плане абсолютно пассивна. Тем не менее, всегда можно сказать, что в какой-то части система из людей "искусственна" в том смысле, что "рукотворна" (т.е. кто-то пришел и таки смог "построить" -- например, предложил стандарт взаимодействия, который с радостью приняли люди в целевой системе).
-- в отличие от enterprise engineering, нет enterprise, хотя может быть "проект" (несводимый к enterprise). Я тут использую разделение "процессов организации" и "проектных процессов", проводимое в ISO 15288. Проектные процессы в сетевых движениях есть, а организации, имеющей "портфель проектов" -- нет. Нет "глобального максимума", на который работают перераспределяемые ресурсы многих проектов, ибо хозяева проектов -- разные. Инженерия же такой сети вполне возможна, включая отвязанность ее организации-не-как-лица от физической или программной структуры (см. обсуждение связи структуры, организации и архитектуры для интернета как сети в http://www.iso-architecture.org/ieee-1471/ieee-1471-faq.html). Речь тут идет об инфраструктуре, "организованном рынке", хотя слово "рынок" тут только мешает и может легко сбить с толку. Это не "рынок", а организатор сети вряд ли получает прибыль: его роль сводится к предоставлению удобных для реализации личных интересов участников сети стандартов, и только. Правда, легко представить и предпринимательство в области инфраструктуры такой сетевой организации: тут-то и появляются продавцы сетевых стандартов в красивых обложках, устроители семинаров, конференций и прочих доходных бизнесов.

Стандарты в таких сетевых организациях могут называться очень странно. Так, стандарты интернета по исторической традиции называются "request for comments" (http://en.wikipedia.org/wiki/Request_for_Comments).

Стандарты коллаборативной сети ("движения") в идеальном случае (в реальном случае есть только обрывочные тексты разного статуса, а также "неписаные правила") описывают:
-- правила организации-без-лица (как ведется разработка стандартов: кто разрабатывает, как попасть в число разработчиков, кто имеет право вносить изменения в текст, как финализуется и публикуется актуальная версия, где публикуются черновики и окончательный текст версии каждого из стандарта, как осуществляется учет изменений состояния всей системы стандартов)
-- reference process model (до сих пор не понимаю, как перевести это на русский) человекосетецентрической системной инженерии (задание общего для всех участников сети языка описания их деятельности -- представьте себе ISO 15288, полностью переработанный для таких систем), используемая для
-- описания жизненных циклов (т.е. проектов) основных целевых систем, которые создаются участниками, на разных уровнях (опорное, принципиальное, выполняемое, историческое -- см. "Понятийный минимум подходов системной инженерии к управлению жизненным циклом", http://ailev.livejournal.com/638740.html). Это крайне важная штука, для этого, собственно, системная инженерия и нужна -- сделать эти описания в явном виде. Увы, это самая трудная часть, тут можно долго обсуждать, почему так и зачем это нужно. Это главное, что сейчас может привнести системная инженерия в подобные "движения", это главное, что позволяет людям быстро договариваться об их роли в проектах. Если речь идет о целенаправленном создании группой людей чего-то рукотворного в проектном заходе (а не наблюдении за "самоорганизацией движения" или "самостановлением сети"), то нужно обсуждать системы и их жизненный цикл Все эти тезисы написаны для данного пункта. Новизна тут. И все дисклеймеры про "социальную инженерию" тоже нужно относить сюда.
-- специфические онтология и эпистемология: разделяемое участниками "движения" понимание предметной области и принятые правила рассуждений (возьмите, например, "движение" австрийской экономической школы в качестве примера важности как одного так и другого).

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

Иллюстрация (из которой и вырос данный текст): мои комментарии к организации политхакинга -- http://david-gor.livejournal.com/81528.html
2 comments|post comment

Управление требованиями [28 Mar 2009|09:55pm]
Если до сих пор мы в PraxOS рассматривали системную инженерию как набор подходов (системного, процессного, архитектурного и т.д.), то традиционное рассмотрение системной инженерии проходит именно в рамках нескольких предметных дисциплин -- управления требованиями (requirement management, requirement engineering), управления жизненным циклом (подразумевающее следование какой-то определенной refence process model и прохождение доказательств и синхронизаций при переходе от стадии к стадии), архитектурный синтез (означающий обязательное использование высокоуровневых описаний системы, абстрагированных от ее материального воплощения) и т.д.

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

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

Управление требованиями нельзя свести к какому-то одному процессу системной инженерии (например, в ISO 15288 такого процесса нет). Управление требованиями затрагивает все части Vee-диаграммы:
-- требования собираются
-- требования анализируются
-- инженерные решения трассируются к требованиям
-- на этапах проверки и приемки (верификации и валидации) обеспечивается доказательство (evidence) выполнения требований (assurance case)
-- требования передаются между сторонами при приобретении и поставках.

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

Поскольку системная инженерия подразумевает рекурсивное и итеративное использование процессов, то состав и содержание требований непрерывно изменяется. Для требований используется управление конфигурацией (учет изменений состава и содержания требований), обеспечиваемые специальным типом учетных систем -- IT-системами управления требований (DOORS, CaliberRM, IRQA, MKS Integrity, Rational RequisitePro и т.д.). Не нужно обращать внимание на то, что большинство этих IT-систем затрагивает работу с требованиями в программной инженерии. Миры системной инженерии как целого и программной инженерии как частного стремительно сближаются, и в большинстве случаев инструментарий (IT-системы, процессные стандарты, оценка процессов и т.д.) программной инженерии могут быть использованы и для системной инженерии в целом (включая вопросы создания киберфизических систем и человеко-системной интеграции).

Учитывая то, что отдельные (элементарные) требования выступают в самых разных ролях по отношению к другим требованиям, а также другим элементам системы, ее описаниям и моделям, поддерживаемые этими IT-системами онтологии довольно велики. Связь IT-систем управления требований друг с другом (нельзя ожидать, что в крупном проекте системной инженерии управление требованиями проходит в границах одной организации, и ограничится использованием только одной IT-системы управления требованиями) и с другими IT-системами (поддерживающими, например, facility model и project model, системами АСУ ТП и т.д.) происходит классическим образом -- с использованием mapping через общую онтологию. Поэтому изучать дисциплину управления требованиями лучше сразу в терминах такой нейтральной по отношению к используемым IT-системам онтологии.

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

1. Специализированные стандарты управления требованиями (например, Requirement Interchange Format, используемый немецкими автостроителями -- (http://www.automotive-his.de/rif/doku.php?id=welcomeeng, текущая версия RIF 1.2 -- http://www.prostep.org/fileadmin/freie_downloads/Empfehlungen-Standards/ProSTEP_iViP/PSI6_RIF_1.2_Mapping-Table.pdf). Это представляется лучшим вариантом на сегодняшний день -- стандарт отражает текущую лучшую практику, обобщенную по нескольким коммерчески успешным IT-система поддержки требований. Это относительно свежий стандарт, первый его драфт датируется февралем 2005г. Читать его будущим специалистам по управлению требованиями невозможно, ибо этот стандарт сделан программистами для программистов.

2. Cтандарты интеграции данных жизненного цикла (например, ISO 15926 или Gellish). По большому счету, это то же самое, что RIF, но при сегодняшнем состоянии дел по развитию данных стандартов можно априори считать, что качество онтологии управления требованиями в этих стандартах может оказаться ниже, чем приемлемо для специалистов по управлению требований. Однако, переход от "стандартов одной дисциплины" типа RIF к "междисциплинарным" стандартам интеграции данных типа ISO 15926 является магистральной линией. Одна из актуальных на сегодня задач системной инженерии -- это обеспечение в RDL ISO 15926 полного функционального аналога RIF.

3. Онтология требований, встроенная в язык системной инженерии SysML. Увы, этой онтологии совершенно недостаточно, даже если скрестить RIF и SysML, как это предлагается в http://www.omg.org/docs/syseng/08-06-07.pdf. Выражение требований, совмещенное с архитектурными диаграммами, подходит только для тривиальных случаев, и очень плохо масштабируется для больших систем. Несмотря на то, что SysML является чуть ли не обязательным языком системной инженерии по версии INCOSE, использование этого языка для архитектурной работы с очень большими системами, а также выражение на нем требований в PraxOS не рекомендуется.

С управлением требований связаны не только форматы представления самих требований, но и форматы доказательств (decision gates, предполагающие демонстрацию evidence выполнения требований). После длительной дискуссии в качестве метода представления результатов выступает assurance case (подробнее см. http://ailev.livejournal.com/578461.html, основной стандарт ISO 15026). Так что представление assurance case как структурированного набора claims, arguments и evidence таже входит в управление требованиями. Более того, системная инженерия рекомендует сегодня, чтобы assurance case создавался на самых ранних стадиях работы и непрерывно поддерживался в актуальном состоянии, и проверялся при каждом доказательстве при переходе от одной стадии ЖЦ к другой. Современное стояние дел в области доказательства выполнения требований в форме такого предписанного артифакта, как "assurance case": https://buildsecurityin.us-cert.gov/swa/downloads/WG_Outbrief_Croll.pdf -- полным ходом идет становление новой предметной области.

Assurance предлагается считать частью управления требований, а IT-cистема управления требованиями тем самым является одновременно и системой обеспечения assurance (поддержки артифакта assurance case). Дискуссию о том, как отображается assurance на валидацию и верификацию мы тут разворачивать не будем -- но это проблема, требующая своего решения.
38 comments|post comment

navigation
[ viewing | March 28th, 2009 ]
[ go | previous day|next day ]