Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

ISO 15288 и OMG Essence

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

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

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

Как я советовал бы использовать OMG Essence в проектах системной инженерии? Очень просто: выкидывать слово software из словосочетания software system -- и использовать "из коробки", даже без расширения начального набора сущностей. Это сразу будет очень и очень полезно, я это пробовал делать на нескольких проектах.

Дальше правильно было бы специализировать (расширить) начальный набор сущностей до традиционного, находящегося во внимании системных инженеров. Для этого я бы рекомендовал брать ISO 15288 как краткое хоть как-то структурированное описание деятельностей системной инженерии (сравните, например, абсолютно бесструткруное описание вида "чего бывает в цирке" из BKCASE/SEBoK), и перекладывать его в формат Основ. Какие при этом возникают проблемы? Вот очень краткий списочек (и нужно понимать, что аналогичные проблемы будут возникать при перекладывании в этот универсальный язык описания методов многих других подобных стандартов -- всех этих CMMI, PMBoK, ITIL и т.д. и т.п.):

1. Основная структура описания деятельности системных инженеров в ISO 15288 структурирована по требованиям ISO 24774 (не путать с ISO 24744) -- process-activities-tasks. Выше -- группы, выделенные по принципу перехода от рассмотрения целевой системы к рассмотрению обеспечивающей системы. Она принципиально не совпадает с принятой структурой описания деятельностей и дел (activity spaces, activities, activities approaches и т.д.) в Основах. Я предлагаю не зацикливаться на собственно деятельностях-глаголах, ибо их сложнее всего распознавать, отделять друг от друга, описывать и обсуждать. Нет проблем иметь хоть два, хоть три, хоть пять классификаций видов деятельности. Пусть будут обе классификации, нет проблемы.

2. ISO 15288 не отделяет важное от неважного. Конечно, там говорится что-то типа "работайте с требованиями" и "договорись о методе разработки" (звучит это в нём как требование выбрать вид жизненного цикла"). Но внимание читателя сконцентрировано главным образом на видах необходимых работ, а не на альфах и рабочих продуктах. Так что первым делом нужно вытащить из ISO 15288 альфы и подальфы. Вот, например (http://ailev.livejournal.com/706776.html):
а) источники потребности заинтересованных сторон (sources of stakeholder need). Говорится, что время жизненного цикла системы идет -- и потребности заинтересованных сторон могут поменяться. Поэтому нужно поддерживать отнесение требований заинтересованных сторон к источникам их потребностей, чтобы не прозевать момент изменений этих потребностей и соответствующий пересмотр записанных требований.

б) требования заинтересованных сторон (stakeholder requirements) -- включая все вопросы их формулирования, полноты выявления, устранения в них противоречий, выкидывания нереализуемых или непрактичных требований.

Это все практика определения требований заинтересованных сторон (Stakeholder Requirements Definition Process). Один из пяти результатов выполнения этой практики -- "выявлены требования заинтересованных сторон для валидации".

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

Это уже практика анализа требований (Requirements Analysis Process). Один из четырех результатов выполнения этой практики -- "определена основа для верификации соблюдения требований к системе".

Поддержка и регулярная демонстрация соотнесения (tracability) всех элементов слоев этого блинчатого пирога: заинтересованные лица <--> их потребности <--> их требования <--> системные требования <--> проект-design <--> система. Для этого используется правильное хранилище данных (data repository).
Обратите внимание, что высказываемые в ISO 15288 соображения по требованиям по-другому рассортировываются -- ибо речь идёт о разных областях интересов (клиентской, решения, предпринятия). Но самое интересное наступает потом:

3. Оформить найденные альфы: отличить "настоящие альфы" (которые присутствуют во всех проектах системной инженерии) как сущности, которые проходят свои состояния, от несущностных конкретных/практических повышающих свою детализацию рабочих продуктов , через которые эти альфы проявляются. А затем определить наборы состояний для этих альф. Тут эвристика: поскольку изменения состояний альф будут определять границы стадий жизненного цикла, то изменения состояний альф -- это часто будет изменение "cognitive framework" (помним, что ISO 24744 определял стадии жизненного цикла как то, что различается своим cognitive framework -- чем забита голова у работников на этой стадии). То есть поменяли предмет размышлений -- поменялось состояние альфы. А затем нужно создать список контрольных вопросов, подтверждающий состояние этих альф.

4. Явно выделить отсутствующие в ISO 15288 компетенции системного инженера и системноинженерного менеджера (systems engineering management), отсортировав их от общих инженерных компетенций -- помним, что OMG Essence говорит о всей работе по созданию системы, как системно-инженерной части "удержания целого", так и всей работе инженерных специальностей, плюс всей работе менеджеров.

Конечно, это только основные вопросы. Я даже не касаюсь, например, вопроса об использовании паттернов OMG Essence для выражения всех понятий из ISO 15288 -- до этого момента нужно ещё провести огромное количество работы.

Я бы сейчас предложил после разбирательства с этими основными проблемами не столько выполнить проект по конвертированию полного содержания ISO 15288 в формат OMG Essence (получив "суженный расширенный" его вариант -- суженный за счёт ограничения только сущностями и абстрагируясь от упоминания конкретных практик, а расширенный за счёт явного доформулирования состояний и списков контрольных вопросов к этим состояниям), сколько озаботиться о том, как эти описания потом будут использованы в ходе реальных крупных инженерных проектов. Ибо все примеры использования OMG Essence пока игрушечны, и авторы не скрывают, что они сами хотели бы работать с отдельными небольшими командами проектов. Для системной инженерии тренд резкого снижения числа непосредственных участников одного проекта также есть, но всё-таки он не так выражен пока, как в софтовых проектах. Так что для системноинженерного использования ISO 15288 в формате OMG Essence нужно:
-- предложить корпоративные процедуры method enactment
-- внимательно подумать над тем, как (в каком виде, по каким процедурам, когда и почему) эти описания того, что должны делать системные инженеры попадут к разным другим людям, связанным с организацией работы и управлением технологиями работы (это я рассматриваю в посте http://ailev.livejournal.com/1067676.html).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 9 comments