?

Log in

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

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

Функции, capabilities, services, требования в разных подходах к архитектурным описаниям [12 Jul 2011|12:13am]
1. Архитектура (ISO 42010 --architecture (of a system): fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution) у системы всегда есть, это архитектурных описаний (ISO 42010 --architecture description: work product used to express an architecture) иногда нет, а иногда есть и несколько разных для одной и той же системы.

2. Архитектура -- это архитектура системы. Систему нужно как-то выделить из окружающего мира и назвать. В системном подходе система определяется/задаётся её функцией в надсистеме. Задание системы через её конструкцию, внутреннюю организацию, механизм, материал, структуру и т.д. (т.е. задание системы через перечисление элементов и их взаимодействие, "вовнутрь системы", "белый ящик") является ошибкой и ложным пониманием системного подхода -- система всегда задается "снаружи", как "чёрный ящик". Тем самым в каждый подход к архитектурному описанию (ISO 42010 -- architecture framework: conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders) так или иначе включает в себя:
а) описание функций системы как отдельную тематическую группу описаний (ISO 42010 -- architecture view: work product expressing the architecture of a system from the perspective of specific system concerns), отражающую необходимость целевой системы для объемлющей надсистемы
б) если подход к архитектурному описанию содержит какие-то указания на метод архитектурной работы (из ISO 42010: architecting -- process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle), то описание функций системы обычно становится первым же разрабатываемым артефактом.

3. В разных подходах к архитектурному описанию (architecture framworks) системозадающая функциональная группа описаний называется по-разному:
-- DoDAF 2.02 (http://cio-nii.defense.gov/sites/dodaf20/capability.html): capability (с отдельными моделями Vision, Capability Taxonomy, Capability Phasing, Capability Dependencies, Capability to Organizational Development Mapping, Capability to Operational Activities Mapping, Capability to Services Mapping) --
-- TOGAF (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html): business functional decomposition diagram, data entity/business function matrix, business service/function catalog, application system/function matrix
-- RM-ODP (http://rcurinf01.uco.es/rmodpwiki/index.php/Resources): computational viewpoint (which enables distribution through functional decomposition on the system into objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition).
-- традиционный диаграммные техники системной инженерии: фукнциональная группа описаний и функциональная архитектура (например, в главе 6 тут -- https://sites.google.com/site/themanagersguide/system-engineering, фукнциональная архитектура -- это FFBD, functional flow block diagram и отнесённые/allocated требования)
-- ARIS (http://www.google.com/search?q=ARIS+function+tree): function tree
-- DEMO (http://www.demo.nl/publications): organization construction model (хотя тут не всё так просто, и чистых "функций" или "capabilities" нет, но акторы называются по их функциям, включая представление всей организации как актора, а трансакции -- это интерфейсы между функциями). Более точно функции тут связаны с production -- продукты или сервисы, которые оргсистема поставляет окружению. Еще более точто -- это business, слово в DEMO почти синонимично function (в то время как organization, information и IT -- это construction в DEMO, противопоставляемое function во всех архитектурных диаграммах).
-- ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/chap4.html): business function.
-- UML/SysML -- впрямую функциональное описание выразить нельзя! Но UML/SysML не подход к архитектурному описанию, это только лишь язык, причём убогий (пардон май френч).

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

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

Работа по созданию онтологии Gellish показала, что у слова "функция" есть минимально пять разных значений: 1. подтипа активности -- процесса или события, 2. какой-то сущности в определенной роли или сделанной для определенной роли, 3. самой роли сущности, обычно в физической вещи, которую эта вещь играет в активности, 4. указания на связь, например корреляция между какими-то аспектами -- ежели высота растёт, то давление падает, 5. математическое отношение между числовыми объектами, определяющее их соотнесение/mapping. Конечно, путаница неизбежна.

Ключевой ход -- это рассмотрение функций в связи с модуляризацией системы. Целевая система -- это модуль (заменяемый!) в надсистеме, а ее функциональные определения подсистем связаны также с их модульностью (заменяемостью). Так что ключевым является рассмотрение "функциональности" в строгом соответствии с системным подходом: если есть какая-то "функция", то можно выделить какую-то систему, выполняющую эту функцию, и надсистему, в которой эта функция определена/осмыслена. Тем самым получается не произвольно дробное выделение функций, а хоть как-то соотнесенное с дробностью самой системы в её физическом (или программотехническом, информационном) воплощении. Подробнее про "гамбургер-диаграмму", выражающую такой мыслительный ход на совмещение уровней модульности системы и уровней определения функций, см. в http://ailev.livejournal.com/920248.html

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

Диаграмма "гамбургера", в том числе в заимствованном в онтологии ISO 15926 виде (см. http://ailev.livejournal.com/920248.html), критика "несистемноподходности" TOGAF со стороны DEMO (http://www.sapio.nl/sapio2010/pdf/jd236_togaf.pdf), а также множество других работ сводятся к одному: в большинстве подходов к архитектурному описанию нет системноподходности (двойственного рассмотрения каждой системы как задаваемой снаружи модуля-функции, поддерживаемой изнутри модульной же конструкцией-механизмом-материалом-организацией-и-т.д.), и тем самым эти подходы не являются в полной мере архитектурными подходами к описанию систем. Они (включая даже TOGAF) описывают что-то, не являющееся системами.

5. Современные архитектуры рассматриваются как сервис-ориентированные (SOA). Это просто отражение того факта, что любая функция системы может быть представлена как интерфейс, а взаимодействие систем (определяемое как взаимодействие функций через их интерфейсы) представлено через протокол, описываемый сервис-контрактом. Это прямое отражение замечания по связи функциональности (возможности выполнения функции, capabilities) и модульности (т.е. привязки capabilities/function к физической нарезке мира, "приложениям" или "оборудованию"). Вместо прямой трассировки функций к (под)организации, бетону, железу или софту мы получаем еще один уровень косвенности: функции привязываются к сервисам, а уже сервисы реализуются железом или софтом. Если теперь подменить реализацию сервиса, система не изменится. Функция -- это спрос на систему, сервис --"черный ящик" отвечающего на этот спрос предложения, поддержанного системой.

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

В последнее время появился новый тренд: рассмотрение сервиса не как "чёрного ящика", а "белого ящика", который позволяет связать функцию с поведением обеспечивающей её системы. Онтологически сервис сервис определяется как событие, существующее в течение интервала времени t, напротяжении которого поставщик сервиса явно обязуется выполнять работы в соответствии с зафиксированным описанием и в интересах клиента (http://www.loa-cnr.it/Papers/FerrarioGuarinoFIS08Proceedings.pdf). Выделение сервиса как особого онтологического объекта, позволяет подробно описать это сложное отношение между требуемой функцией и поведением системы, реализующей эту функцию. Сервисы позволяют перейти к языку акторов, ответственных за рабочие трансакции, в том числе задав ход на работу с правами по использованию сервисов (legal perspective -- http://www.loa-cnr.it/Papers/FerrGuarFern.pdf). Самая свежая статья этой серии, описывающей подобный подход к онтологическому описанию сервисов -- http://www.loa-cnr.it/Papers/WI_2011_service_ontology_final.pdf

6. "Требования" в моделе-ориентированном подходе перестают быть как отдельным артефактом, а определяются как указание на деонтическую модальность каких-то определяющих систему артефактов (http://ailev.livejournal.com/900086.html), например, указание "должны быть реализованы" для архитектурных описаний (т.е. для функций, capabilities, сервисов и т.д.). Особо отметим, что в таком подходе нет "нефункциональных требований", ибо все требования так или иначе сводятся к функциям/capabilities/удовлетворению сервисных контрактов и т.д.

Нужно особо оговорить, что практики инженерии требований и инженерии системной архитектуры, тем не менее, остаются разными практиками, ибо требуют разного тренинга. Инженер по требованиям работает с заинтересованными сторонами и обеспечивает их выявление, и их переговоры, а инженер-архитектор предлагает системную архитектуру (http://ailev.livejournal.com/805721.html, и боле раннее описание работы инженера по требованиям в http://ailev.livejournal.com/810548.html).

В любом случае, использование понятия "требования" весьма запутанно (см., например, http://ailev.livejournal.com/901202.html -- требования как программа, метод, модель, интеракция) и связывается всё более со старинным немоделеориентированным и недатацентрическим документарным подходом с полнотекстовыми бумажными документами. Современная моделеориентированная и датацентрическая системная инженерия предусматривает фиксацию всей необходимой информации о нуждах заинтересованных сторон в инженерных информационных системах с моделеориентированной и датацентричной архитектурой (http://ailev.livejournal.com/934700.html). Дальше каждый предыдущий базис (baseline) информационной модели становится требованиями для разработки следующего -- см., например, ряд: 1. user needs, 2. ConOp, 3. architecture, 4. design, 5. as built.

Тем не менее, наиболее близко к "требованиям" стоит функциональная группа описаний (или группа описаний "возможностей", capabilities). Более того, в некоторых учебниках деонтический статус, придаваемый описаниям из других групп предлагают называть не "требования", а "ограничения" (constraints), и часто отмечают при этом их как "нефункциональные требования". С другой стороны, есть традиция считать любые требования функциональными (например, Donald Firesmith выступает против термина "нефункциональные требования" -- любые требования функциональны, они описывают функцию системы для какой-то заинтересованной стороны, вписывают целевую систему в важную для этой заинтересованной стороны надсистему). Постоянная дискуссия о разнице между "требованиями" и "ограничениями" приводит к тому, что "чистые требования" в конце концов становятся функциональной группой описаний системной архитектуры, а "ограничения" входят в другие описания. Jan Dietz продолжает эту линию в противоположную от "требований" сторону и определяет уже всю архитектуру как "ограничение" (а не "требование" -- чисто уже лингвистическая разница) для принимаемых проектных (design) решений.

В любом случае, в GORE (goal-oriented requirement engineering) видно, что "цели" (требования) в моделях связаны с какими-то архитектурными идеями -- т.е. не существуют сами по себе. Вместо традиционного языка полнотекстовых требований используется язык "цели -- средства", или "функции/capabilities -- конструкция (в том числе механизм, материал, структура, организация, технология и т.д.)".

7. Разработка функционального описания может вестись самыми разными методами. Чаще всего предлагается определить сценарии (use cases), по факту являющиеся процессами (развертками во времени) надсистемы, и использовать их для формулирования функций/capabilities. Эти процессы-use cases нельзя путать с внутренними процессами (механизмом работы системы), ибо эти механизмы-процессы формулируются уже как реализационные, т.е. архитектурные/проектные решения -- и они дальше определяют сервисы, а уже сервисы определяют потребных акторов (человечьих и нечеловечьих). Хотя этот пункт сформулирован исходя из "сервиса как черного ящика", подход "белого ящика" может потребовать и других рассмотрений.

8. Итого:
-- требования и архитектурное описание сегодня уже не так хорошо различимы, как еще десяток лет назад
-- под любыми словами (функции, capabilities, services, требования и т.д.) разные подходы имеют ввиду совершенно разные вещи (часто эти разные вещи имеются ввиду и в рамках одного и того же подхода, ибо для них не выполняется онтологическое моделирование).
-- архитектурные описания могут быть разработаны в рамках системного подхода и учитывать необходимость модульности в конструкции системы, а могут быть разработаны не в рамках системного подхода. Громкие трейдмарки типа TOGAF или ARIS тут не являются гарантами, скорее уж наоборот.
-- переход от функций к capabilities, и разбирательство с обязанностями одних частей системы выполнять процессы для других частей системы (т.е. разбирательство с сервисами и организацией-по-DEMO) приводят к существенным изменениям в методах архитектурного описания. Этот переход активно идёт последние пять лет. Поэтому книжки по архитектурным описаниям, выпущенные ранее 2006 года я бы вообще не рекомендовал читать, и древними подходами к архитектурным описаниям я бы тоже не рекомендовал пользоваться.
-- существующие подходы к архитектурным описаниям следуют современным трендам в самой разной степени и чаще всего представляют собой эклектику, проштампованную бюрократией организаций по стандартизации. Из наиболее перспективных для описания enterprise architecture нужно выделить подходы DEMO и ArchiMate (кстати, в ArhiMate пытались учитывать в том числе и DEMO), а в части разбирательства с сервисами -- general service model на базе онтологии DOLCE.
-- в области методов архитектурных описаний нужно выполнять практику управления технологией (http://ailev.livejournal.com/936356.html): со старых, двадцатилетней давности методов архитектурной работы нужно вовремя соскакивать, и осваивать новые. Для моделеориентированной системной инженерии подойдёт отнюдь не любой подход к архитектурному описанию -- и, скорее всего, такой подход (например, praxos) только предстоит создать.
24 comments|post comment

Переход к системной инженерии в инжиниринговой компании [12 Jul 2011|11:40pm]
Предположим, что случилось чудо, и какая-то российская инжиниринговая компания захотела последовать опыту всяких разных Boeing Commercial Airplane Co., Rollce-Royce, Mitsubishi Electric Corporation и прочих мирных и военных инжиниринговых компаний со странички http://incose.org/about/organization/cab.cfm -- то есть заменить свою бессистемную инженерию системной инженерией.

1. Нужно четко понимать, что речь идет об управлении технологией -- замены одного метода инженерной работы на другую в масштабах предприятия. Это подразумевает выполнение минимально следующих практик (обычно поначалу этим занимается "служба развития", http://praxos.livejournal.com/11299.html и минимально требующийся для выполнения этих практик персонал включает Предпринимателя/заказчика, методолога/стратега/технолога, онтолога/модельера данных и программиста/айтишника плюс Организатора):
-- выбор метода системной инженерии
-- освоение дисциплины данного метода (получение людей, которые следуют дисциплине мышления и действия)
-- разворачивание технологии данного метода (закупка и настройка софта, постановка практик с использованием данной технологии, подготовка форм документов, наполнение баз данных и т.д.)
-- организация работы (разделение труда, определение полномочий и обязанностей, "расстановка по местам", организация взаимодействия и сотрудничества, правила дележки ресурсов)
-- запуск механизма непрерывного совершенствования ("уровни зрелости")

2. Прежде всего, нужно понять, какое поколение системной инженерии интересует (http://ailev.livejournal.com/936356.html -- я выделяю четыре поколения). Ибо можно запросто ошибиться, пригласив стареньких и знаменитых иностранных консультантов, которые заменят бессистемное шило на системное мыло двадцатилетней давности. Или попытаться внедрить маленький сверхсовременный кусочек супер-пупер-системной инженерии, который не будет иметь никаких шансов выжить в окружающей бессистемной грязи.

3. Системная инженерия (рассматриваемая в части технических практик -- инженерия требований, инженерия системной архитектуры, системная интеграция и т.д.) не может быть освоена организацией без сопутствующих изменений в используемых методах инженерного менеджмента. Хорошим примером тут является ISO 15288, в котором освоение системной инженерии связывается с освоением не только группы технических практик, но и еще трёх других групп практик (а именно, проектных, организационных/программных, а также организационных/трансакционных -- обзовём их пока таким способом, чтобы показать суть дела, а не просто формальное "следование стандарту и его терминологии"). Так что "перехода к системной инженерии" будет маловато, нужен также переход от ad hoc менеджмента к какому-то конкретному варианту инженерного менеджмента (например, моделе-ориентированному -- http://ailev.livejournal.com/928876.html, если мы уж взялись тут говорить об управлении технологией, в данном случае технологией инженерного менеджмента).

4. Для того, чтобы получить нужных людей, требуется их либо нанять уже обученных (что считаю невероятным -- в лучшем случае будут наняты люди, обученные несовместимым между собой методам работы), либо обучить. Проблема в том, что переход к системной инженерии требует существенной перестройки в мышлении (т.е. перехода к использованию системного подхода на деле, а не "оформления обычной работы в терминологии системной инженерии". Иначе можно получить систеноинженерные аналоги высказываний типа "парламент -- не место для дебатов!"). Увы, краткосрочных (недельных, или двухнедельных) курсов системной инженерии достаточно, чтобы познакомить с основными идеями и даже терминологией, но недостаточно, чтобы из "просто инженера" получить системного инженера. Не нужно забывать, что системная инженерия -- это магистерская специальность, ей учат пять лет. Даже если рассматривать вариант дополнительного высшего образования (прикидки по образовательным объемам: http://ailev.livejournal.com/871079.html), то это освоение материала 30 не слишком толстых учебников и стандартов (ага, счет страниц стандартов в этой предметной области легко выходит на сотни), а также руководств к программному обеспечению и организационных регламентов. (ибо мало "знать предмет", нужно еще и "знать технологию").

Ежели эти слова не убедили, то вот анализ "образования" и "тренинга" в развитии системного мышления (там очень убедительная табличка, тренинг в развитии системного мышления является наименее действенным средством изо всех -- а ведь без системного мышления никакой системной инженерии не будет): http://www.aero.org/publications/crosslink/spring2007/04.html

Поэтому образовательные программы западных инжиниринговых фирм устроены "многоуровнево": обычно для инженерного корпуса корпорации руководством задаётся требуемый процент Ph.D., магистров, бакалавров, повысивших квалификацию на краткосрочных курсах (таких обычно 100%), и далее разворачивается многолетняя и дорогая программа по достижению этих показателей -- в партнерстве с большим числом учебных заведений (например, поглядите, как выглядят цены для курсов, если вы работаете на Boeing -- http://dce.mst.edu/admissions/fee_schedule.html, это из-за довольно типового корпоративного соглашения с университетом, в котором Boeing employees and its suppliers worldwide have the opportunity to earn a Master of Science degree, Graduate Certificate, or Ph.D. in Systems Engineering -- http://emse.mst.edu/boeing/index.html). Вот еще опыт MITRE (7тыс.человек) -- http://www.mitre.org/work/tech_papers/2010/10_0678/10_0678.pdf, вот подход NASA -- http://www.worldscinet.com/srf/03/0302/free-access/S1793966609000080.pdf (и, кстати, моя критика этого подхода: http://ailev.livejournal.com/803770.html).

5. Нужно быть готовым заплатить $много за софт и его настройку. Нужны разные САПРы, нужны системы моделирования, нужны PLM. Нет шансов купить всё это в коробочном варианте. Чтобы всё это заработало, нужны исследования и суперусилия. И нужны люди, которые понимают, зачем им этот софт и готовы с ним работать -- то есть для работы нужны обученные люди. Отдельно скажу, что никакое "внедрение софта" или "переход к 3D-проектированию" при этом не является переходом к системной инженерии. Этот переход совершается прежде всего в головах людей, а системноинженерный софт в руках инженеров дикарей является "файлами на диске", так же как ружьё в руках дикаря -- не более чем кусок железа. Но без софта и его настройки не будет никакой системной инженерии, будут только разговоры о ней.

6. Нужны экстраординарные усилия по организации работы по-новому -- определить жизненный цикл, назначить людей на акторские роли, определить полномочия этих людей в выделении людских и денежных ресурсов, обеспечивать адекватное выбранным методам (а не поперек и мимо них) планирование ежедневной работы. Это требует искусного организатора, ибо речь тут идёт о масштабной реорганизации. Если у вас были ГИПы, которые главным образом представляли из себя проектных менеджеров, то появление системных архитекторов и инженеров по требованиям может вызвать чисто человеческие конфликты между старыми привычками работы и вновь предлагаемыми методами моделе-ориентированной работы. А уж если на первых порах что-нибудь не будет получаться (а ведь на первых, и часто даже на вторых порах не будет получаться -- сразу без ошибок-то ведь никакая организация не проходит!), то есть риск провала проекта из-за "отсутствия политической воли", "недостатка leadership" (то есть недостатка умения убалтывать других людей следовать целям организации, а не своим личным хотелкам) и других абсолютно нетехнических причин.

7. После того, как работа хоть как-то пошла по новому, нужно идти по циклу непрерывного совершенствования, "процессной зрелости". Эту работу нужно обязательно предусматривать (иногда ее рассматривают как "текущую организационную" в противовес "реорганизационной" -- и этот переход нужно планировать). Например, использовать сочетание голдратовской техники обнаружения ограничений и lean & 6 sigma методов подстройки под ограничения и снятия ограничений. Опять же, этот цикл подъема по ступенькам процессной зрелости в новом методе работы нужно "запускать" сознательно, что требует дополнительных усилий в ходе реорганизации -- и об этих усилиях нельзя забывать.

8. Каждый из предыдущих пунктов -- "самый критический". Нет поддержки Предпринимателя/Заказчика -- данного оргпроекта не будет вообще. Не найдётся организатора, который сможет всё это вытянуть, будет грандиозная неудача. Выбрано неверное содержание образования -- овчинка окажется не стоящей выделки, а конкуренты будут радоваться. Недостаточно времени и усилий ушло на обучение -- не видать вам следования дисциплине системной инженерии, в работе будут только использовать новомодные слова, а работать и думать будут по-старинке. Не будет развернута технология -- никакого толку от обученных людей не будет (ибо не только экскаваторщик без экскаватора не копает, но даже и землекоп без лопаты. Что уж говорить о моделе-ориентированной системной инженерии без настроенного софта, который поддерживает те самые модели!). Ну, и так далее по всему списку.

9. С чего начать? С организации хоть какой-то команды озабоченных технологическим менеджментом людей, и прикидок силами этой команды имеющегося задора и поддерживающего этот задор административных, знаниевых, людских, финансовых и прочих ресурсов по каждому пункту из списка. А дальше всё зависит от задора и полномочий людей, оказавшихся в команде -- и от наличия ресурсов и длинной многолетней воли, чтобы дождаться таки успеха, а не бросить дело на полпути.
8 comments|post comment

navigation
[ viewing | July 12th, 2011 ]
[ go | previous day|next day ]