November 5th, 2008

2019

Вторник вечер

Один махонький двухмесячный мыш воняет много сильней, чем были мои худшие ожидания. За что и получил имя Вонючка. Никакого сравнения с теми же морскими свиньями, которых на этом фоне можно считать благоухающими. Одномесячный мыш воняет немногим меньше, но через месячишко наверняка Вонючку догонит. Никакие наполнители не помогают. Зато дитятко полностью счастлив. Он теперь многодетный папа, строгий, но справедливый.
* * *
Вдруг заметил, что все чаще и чаще заинтересовавшие меня вполне англоязычные треки ведут к японским музыкантам. Qypthone, ego wrappin', Tokyo Ska Paradize Orchestra и т.д. (желающие легко найдут их в YouTube). Нужно с этой японской музыкой поближе познакомиться, перейти от охоты и собирательства к какому-нибудь целенаправленному земледелию. Ибо на планете не так много мест, где умеют сочинять и исполнять мажорные мелодии. Кстати, на torrents.ru есть дискография ego wrappin' -- крайне рекомендую.
* * *
Выяснил экспериментально: работать с concept map нельзя даже на экране 1600*1200. Хоть как-то получается только на 2560*1600. Тот же эффект был и с FlyingLogic: на маленьком экране ничего полезного размера создать не удается, все время теряешь на постоянное скроллирование и попытки вспомнить, куда ведут теряющиеся на краях экрана линии.
2019

Процессы, процессные фреймворки, процессные архитектуры

Процессы -- это какие-то содержательные группировки деятельностей (activities) людей, описываемые главным образом в терминах целей этой деятельности и результатов, получаемых в случае успешной реализации в жизни (среди стандартизаторов консенсус, в каких терминах описывать процессы, был достигнут в ходе разработки ISO 15504, а затем зафиксирован в ISO TR 24774). Формализованное описание группы связанных деятельностей часто называют определением процесса (process definition), или моделью процесса (process model). Приняты формулировки типа "люди выполняют различные действия (activity), используя описания процессов -- эти действия обеспечивают прохождение системой ее жизненного цикла", "жизненный цикл -- это изменения (прогресс, эволюция) системы, на которую воздействуют люди, сообразуясь с описаниями процессов жизненного цикла".

Описание процесса по ISO TR 24777 выделяет следующие обязательные атрибуты описания процессов (process atributes): заголовок-название, цели выполнения, tasks, которые группируются в activities, наблюдаемые результаты (outcomes). В обязательные атрибуты включаются из ISO 15504 оцениваемые показатели (assesment indicatiors) -- ресурсы, практики, рабочие продукты (которые делят на хардвер-оборудование, сервисы, софтвер вкупе с данными и документацией, материалы типа воды).

Процессный фреймворк -- это набор моделей (описаний) процессов. Процессные фреймворки отличаются принятой в них процессной архитектурой.

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

На сегодня наиболее авторитетно принятое в середине 90-х IEEE разбиение уровня абстракции процессов на три уровня: референсный, концептуальный, реализационный (http://standards.computer.org/sesc/s2esc_pols/FP-10_Process_Abstraction.htm). Так, ISO 15288 или ISO 12207 это референсные процессные фреймворки системной инженерии (указание набора деятельностей-activity, которые могут выполняться каждая одним агентом -- такой набор однородных и склеенных деятельностей и есть отдельный процесс).

Концептуальный уровень описывает ход (flow по-русски -- это ход, никакой "потоковой метафоры, увы. См. http://ailev.livejournal.com/503568.html, п.1 второго списка) управления и данных между агентами (т.е. описывает протоколы между референсными процессами/агентами). Концептуальные процессы описывают отношения агентов как по управлению, так и по обмену данными.

Модели жизненного цикла -- это концептуальные процессные фреймворки, характерные для тех или иных вариантов жизненных циклов. Именно на этой стадии происходит выбор способа взаимосвязи (последовательное, параллельное, итеративное приложение определяемых описанием 25 поцессов деятельностей к системе и т.д.) предлагаемых референсной процессной моделью. Именно в модели жизненного цикла, как концептуальном уровне абстракции, фиксируется решение следовать путем параллельной инженерии, или выбирать последовательное прохождение стадий, именно тут находится баланс между "водопадными" и agile способами разработки. Именно в модели жизненного цикла вам придется признаться, придерживаетесь ли вы в ваших процессах быстрого прототипирования, или полагаетесь на SCRUM-методологию. Именно тут для эксплуатации вы выбираете между ремонтом по состоянию или ремонтом по нормативам, после чего рисуете диаграммку того, как (последовательность и другие отношения) связаны разные процессы (или, следуя традиции рассмотрений IEEE -- как связаны разные агенты, ответственные за выполнение процессов).

Реализационный (implementation) уровень включает отображение агентов с их процессами на реальные организации и использующиеся в ней инструменты (например, конкретное программное обеспечение, поддерживающее тот или иной способ описания workflow, или краны определенной грузоподъемности, предполагающие какую-то определенную технологию монтажа). "Положения о ..." (policy) и "Инструкции по ..." (procedures) появляются как описания процессов в реализационном процессном фреймворке -- в котором концептуальные описания привязываются к конкретным инструментам и организационным реалиям.

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

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

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

Интересно, как обо всем этом рассказывать, не произнося умных слов "процессный фреймворк" и "процессная архитектура"? Ибо весь мой опыт показывает то, что значение слов "фреймворк" и "архитектура" обычными инженерами не понимается ни сразу, ни потом. Равно как и "референсный", "концептуальный" и "реализационный" в их противопоставлении (и даже без противопоставления). Хотя с "детализацией" обычно никаких проблем, равно как с предметным разбиением на 25 обязательных процессов.