November 30th, 2010

2021 год
  • ailev

К созданию методологии использования ISO 15926

В настоящий момент мне известны следующие обрывки методологии использования ISO 15926 (кроме разных наборов слайдов, или зачастую одиночных слайдов, которые предполагают устное комментирование авторами):

1. Часть 1 стандарта, описывающая "пирамиду справочных данных" и прочие важные сведения (важность которых трудно понять, пока не приступишь к какому-то конкретному проекту).
2. Раздел 4 Части 2 "Fundamental concepts and assumptions" -- как "кодировать на ассемблере", т.е. в языке Части 2.
3. Часть 7, описывающая способ подъема уровня языка шаблонами, и раздел про полное определение шаблона в части 8.
4. Проект части 6 про то, как оформлять записи (reference data items) в RDL -- как формулировать "определения" и т.д.
5. Полуготовое руководство "Beginners's guide to 15926 modeling", пока всего 15 страниц крупным шрифтом с комментариями -- https://www.posccaesar.org/svn/pub/SIG/MMT/MMT2010_revisedBasedOnComments.pdf
6. Template characterization methodology -- https://www.posccaesar.org/wiki/TemplateCharacterization (старый документы, еще в старинной терминологии short-hand и long-hand templates).
7. ISO15926 Primer -- https://www.posccaesar.org/wiki/ISO15926Primer (больше о том, что такое ISO 15926, чем как с ним работать).
8. ISO 15926 HOWTO -- https://www.posccaesar.org/wiki/ISO15926HowTo_Introduction, но не нужно ждать многого от этих недоделанных страниц
9. Руководство по соответствию -- https://www.posccaesar.org/wiki/IdsAdiComplianceSpecification
10. Ряд демонстрирующихся на разных семинарах слайдов Магне, в которых он приводит почти сотню примеров кодирования шаблонов (на самом деле -- графов поднятия-опускания, а то и вообще "паттернов" в виде куска семантической сетки в языке Части 2).
11. Наша инициатива -- .15926M, но эту методику только предстоит разработать (чему и посвящен этот постинг).

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

Тем самым, никакой особой "методологии" на сегодня не существует -- она заключается главным образом в комментариях, которые дают "модельеры с черным поясом". Более того, существую серьезные расхождения во мнениях этих "модельеров с черным поясом" по поводу методологии моделирования -- взять хотя бы дискуссию вокруг FunctionalPhysicalObject, развернувшуюся в группе "ISO 15926" в LinkedIn. Есть различия и в экспертизе самих "чернопоясников", например использование логики (аксиом шаблонов) или упор на "инженерность-без-этой-вашей-FOL".

Возможные роли для методологии:
1. Разъяснять, "с какой стороны подойти к корове". В данном случае -- к слону (любимое сравнение авторов стандарта, подчеркивающее огромность стандарта и неохватность его содержания одним человеком). Проблема в том, что сам многочастный стандарт не является "учебным текстом".
2. Обращать внимание на важные моменты, которые мало кто вычитывает из стандарта с первого раза (например, зачем в стандарте есть не только class, но и class_of_class, и почему столько споров вокруг FunctionalPhysicalObject). Ну, или разъяснять накопившиеся за много лет разночтения (типа невыразимости различения классификации, членства и специализации Части 2 в EXPRESS, но выразимости их в OWL -- "классофклассика" https://www.posccaesar.org/wiki/ISO15926inOWLPart2EntityMembership).
3. Дополнять стандарт тем, что в нем не написано:
-- руководство по локализации. Вообще, "в стандарте есть всё необходимое для создания словарей" -- но никто не знает, как нужно делать многоязычность в RDL.
-- IT-инфраструктура в типичных производственных конфигурациях САПР/PLM/ERP/EAM -- все эти data stores и data warehouse, трехсхемная архитектура, мэппинги, хранилища RDL и т.д.. Тут нужно учесть, что речь даже не идет о будущей Части 9 (которую пока никто не видел, и в которой ожидается стандартизация SPARQL-запросов к федерации RDL, которая предполагается соответствующей Части 8 -- глядите http://www.infowebml.ws/ и http://15926.org для информации двухлетней давности, а для свежей скудной информации http://iringug.org), а о растолковывании невнятного текста Части 1.
-- технология мэппинга и использования адаптеров (IRING, XMpLant и разные другие).
-- технология data handover,
-- как организовать модульность (онтолеты)
-- как организовать и администрировать RDL
-- как воткнуться в федерацию RDL,
4. Разъяснять не только то, что задумывалось в Части 2, но и "что получилось в Части 4", и "что получилось в WIP/RDS" (ибо хотели, как лучше -- а получилось, как всегда). Сейчас это -- устное предание.
5. Разъяснять template characterization в разных "особых случаях", типа "шаблоны для кодировки по KKS" или "выражение закупаемого по каталогу оборудования для тэга в составе функциональной системы".
6. Излагать технологию ISO 15926 для конкретной конфигурации софта какого-то поставщика (или набора софта разных поставщиков).

Трудность тут в том, что методология не должна просто "переписывать стандарт" -- она не замена стандарта, а дополнение к стандарту. В методологии, например, может говориться, почему в стандарте выбрано то или иное решение -- чтобы следующий методологии человек случайно не пошел "поперек стандарта", не поняв его "духа".

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

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

В случае (б) нормативные высказывания вкраплены в объясняющий и растолковывающий их текст -- и тем самым существенно снижается "нормативный градус" в пользу дидактичности.

Опять же, остается тонкая граница между уточнением и дополнением стандарта новыми нормами, и дидактичной обработкой текста стандарта плюс нормативного текста методологии.

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

Еще один вопрос -- это предмет методологии (scope). Понятно, что Ontology Handbook (в котором ISO 15926 занимает весьма немного места) -- это книжка на много сотен страниц. Можно начинать с того, "что такое EXPRESS" (что довольно актуально, ибо описания этого языка на дороге не валяются, а Часть вторая написана в нём -- или наоборот, неактуально, ибо реализаций в EXPRESS на сегодня по факту нет). Но тогда можно просто не дойти до сути дела. Можно приступить сразу к сути дела: "как моделировать промышленные кодировки, используя встроенный в Часть 2 парсинг текстовых строк на правую-левую части -- и оформлять это шаблонами", но это явно "дело нижнего уровня" -- и такие дела нужно объединять в мероприятия, мероприятия в практики, практики -- в дисциплины.

Учитывая, что "справочные данные" в ISO 15926 включают в том числе любые часто используемые классы (например, данные каталога оборудования), а RDL определяется просто как "набор/collection справочных данных", мы тут отходим от терминологии с RDL и переходим к терминологии "схема данных" и "НСИ" (считая, что в RDL хранится и схема данных, и НСИ).

Практики дисциплины "Инженерия схемы данных жизненного цикла":
1. Моделирование, с мероприятиями/паттернами кодирования:
-- общие принципы моделирования ("это не объект-ориентированное программирование, а онтологическое моделирование данных", разъяснение 4D)
-- типовые паттерны (архитектура "функциональный тэг, спецификация, объект в каталоге, железка", заводские кодировки типа KKS или RDS-PP, стандарты с типоразмерами и т.д.), таксономия этих паттернов/шаблонов моделирования должна оговариваться отдельно.
-- оформление шаблонами (как "порезать огромную семантическую сетку на шаблоны")
2. Мэппинг ("ISO 15926 outside") и работа с адаптерами для конкретного хранилища/склада данных.
3. Управление схемой данных (разворачивание/организация и ведение схемы данных в форме RDL), в том числе Handover схемы данных.
4. Локализация схемы данных.
5. Управление данными (экземплярами, а не схемой) с использованием схемы данных - handover.
6. Постановка метода инженерии схемы данных жизненного цикла

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

Дисциплина "Управление данными инжинирингового проекта"
1. Практика Plant Design and Project Data handover

Дисциплина "Инженерия IT-инфраструктуры для ISO 15926"
1. Практики разворачивания систем конкретных поставщиков софта в варианте использования ISO 15926

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

Комментируйте.
2021 год
  • ailev

Закон ОМа: описание [практики] постановки [метода] инженерии схемы данных жизненного цикла

Поскольку объекты мира задаются главным образом через набор операций с ними ("вот это стул -- на нём сидят, вот это стол -- за ним едят"), то каждый онтолет подразумевает какое-то "руководство по эксплуатации", то есть методы действий (каталог компонентов методов) в данной предметной области. СМДМ-методологи обсуждают этот момент как обязательное наличие "двух досок" -- одна объектно-онтологическая (предметная), другая -- оргдеятельностная. На деятельностной доске задаются функциональные свойства объектов, на онтологической доске -- "что такое" эти объекты. Единство Онтолетного и Методологического я бы назвал законом OMа. Развитие предметной области -- это когда онтология и деятельность вдруг расходятся: обнаруживается, что действия производятся (дела идут) не с обозначенными в онтолете продуктами, или (что то же самое) оказывается, что обозначенные в онтолете продукты никем не используются, и происходит что-то другое.

Связь онтолета (как онтологического описания -- и дальше я традиционно не буду различать онтологию и онтологическое описание, метод и описание метода) и описания метода проявляется очень просто: каждый объект, помянутый в методе, должен быть типизирован. Под "типизацией" я имею ввиду не только классификацию его к понятиям Части 2, но и к понятиям расширенной онтолетом Части 4.

Тут есть свои:

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

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

В ISO 15288 декларирование типа вылезает в заголовки. Так, все 25 processes этого стандарта имеют намеренное решение тип (process) включить в заголовок с именем конкретной практики, но в оглавлении это выглядит совершенно избыточным (так, я снял эту типизацию в переводе -- а сейчас вновь задумался, не вернуть ли её). Другой пример из стандартов ISO 15288 -- это рекомендация добавлять тип "система", когда подчеркивается использование системного подхода, например, вместо "самолёт" говорить "система самолёт". Я с этой рекомендацией не соглашаюсь обычно ("всё есть системы, так зачем это каждый раз говорить?"), но сегодня в очередной раз задумался над пользой принудительной типизации.

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

Компромиссным вариантом является "декларирование типа" -- как в языках программирования, типизация показывается явно при первом употреблении объекта. В моём вчерашнем постинге я использовал такой подход к типизации, указывая "практики дисциплины" (заодно указав и отношение композиции дисцилины из практик, и тип "практики" для списка индивидуальных практик дисциплин, и указав тип "дисциплина" для индивидуальных методов типа "Инженерия схемы данных жизненного цикла"). Ежели идти дальше, то для типов нужно указать, из какого онтолета они пришли -- "практика" пришла в явном виде из ISO 24744 (там это process), а "дисциплина" -- путем обобщения разных наборов практик (что отражалось в различных "дисциплинах системной инженерии" -- "дисциплина инженерии требований", "дисциплина инженерии системной архитектуры"). Тут я просто обобщил "практику" вверх до "дисциплины" (а не только вниз до уровня "мероприятия" и "дела", как это делается в онтолете ISO 24774).

Пример с дисциплиной (вновь введенное понятие), практикой (использующейся как в ISO 24744, так и в ISO 24744), мероприятием (использующимся только в 24774 для более мелких практик) и делом (использующимся опять таки как мельчайшая единица как в ISO 24744 и ISO 24774) показывает, что нам не обойтись для моделирования метода собственным онтолетом, который должен входить в .15926O.

Но это не даёт ответа на вопрос, как рэндерить эту типизацию. В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию/рендерингу/представлению практики постановки метода инженерии схемы данных жизненного цикла (которая, по идее, должна быть "специализацией" практики "постановка метода" в дисциплине "ситуационная инженерия методов" -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов").

В качестве упражнения: опустим типы из ISO 24744/24774 в предыдущем предложении -- смысл ведь не изменится! "В отдельном постинге (http://community.livejournal.com/dot15926/16745.html) я выполню упражнение по описанию постановки инженерии схемы данных жизненного цикла (которая, по идее, должна быть специализацией постановки в ситуационной инженерии методов -- примерно в том же смысле, в котором мы говорим о "специализации шаблонов")". Интересно, сколько людей сочтет "более понятным" типизированный вариант, а сколько нетипизированный?

Этот пример также даст понимание, как может выглядеть описание (рендеринг) методологии в части описания практик (я, правда, не понимаю, правильно ли публиковать это в dot15926, ибо речь идет явно об организационной практике -- а тогда это должно идти в praxos. Типичный пример двойной классификации). Обратите внимание, что многие формулировки и типы в этом примере предписаны ISO 24774 (практики, мероприятия, способ нумерации и т.д.), но существенно также используется типизация по ISO 24744 (даже слово "метод" -- это тоже тип к "инженерии схемы данных", наряду с "продуктами работ") -- но не думаю, что требуется как-то специально обозначать эти пространства имён. Всякие объяснения выбранной терминологии тоже опущены (так, "инженерия схема данных" подразумевает прохождение целевой системы схемы данных по полному жизненному циклу -- от замысла и определения пользовательских потребностей до валидации и эксплуатации. "Разработка" же обычно ассоциируется с более коротким жизненным циклом проекта, заканчивающимся на проектировании -- невзирая на совпадение "проектирования" и "изготовления" для информационных продуктов). "Многоуровневые типизации" и "буквальные типизации" (типа "шаблон практики постановки..." -- чтобы показать, что тип "постановки метода инженерии" в ISO 24744 будет не "process", а "ProcessKind", или использование "метод" как обозначение того целого из практик-продуктов-организации, что подлежит постановке) я старался не использовать. Интересно было бы получить замечания, где дополнительная типизация была бы полезна и уместна (а где, наоброт, осталась лишняя). В целом, "остаточная типизация" следует ISO 24774, как ее можно обнаружить в ISO 15288, взятом за образец предлагаемого описания/рендеринга. Заодно в качестве побочного эффекта мы получаем текст "процессного стандарта", выполнение которого можно проверять по ISO 15504 (SPICE), ибо такой текст читается как "описание типового процесса" (reference process model) в смысле этого стандарта оценки соответствия.
2021 год
  • ailev

Описание постановки инженерии схемы данных жизненного цикла

Попробуем написать отрывок потенциального "Стандарта инженерии схемы данных жизненного цикла" как стандарта, задающего описание метода [можно дополнительно протипизировать и "данные жизненного цикла" -- "Стандарт инженерии сжемы данных жизненного цикла целевой системы", что укажет на использование методов системной инженерии, поелику помянут тип "целевая система" из онтолета ISO 15288, ну да ладно. Подробнее про типизацию см. в http://community.livejournal.com/dot15926/16526.html). Немного разъяснений, вопросов и обоснований в квадратных скобках -- и крайне интересно, насколько эти комментарии полезны для читающих, а насколько они лишни и поэтому безжалостно должны вычищаться из текста перед его боевым применением.

0. Практика "Постановка инженерии схемы данных жизненного цикла".

Назначение практики постановки инженерии схемы данных – предоставить обеспечивающую инфраструктуру и услуги для выполнения остальных практик инженерии схемы данных. Данная практика определяет, обеспечивает и обслуживает оборудование, здания и сооружение, инструменты и программно-аппаратные комплексы, наряду с персоналом.

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

В результате успешного выполнения практики постановки инженерии схемы данных:
А) на роли модельеров данных и предметных экспертов назначены конкретные физические лица ["бестиповой" вариант: модельерами данных и предметными экспертами назначены...]
Б) модельеры данных и предметные эксперты обучены (т.е. имеют необходмые компетенции)
В) модельеры данных и предметные эксперты организованы (т.е. определены их полномочия и ответственность)
Г) модельеры данных и предметные эксперты обеспечены рабочими местами и необходимыми IT-сервисами, для чего закуплены и настроены программно-аппаратные средства для инженерии схемы данных и целевой работы с данными [ибо одной схемой не обойдёшься, ее ведь нужно отлаживать на реальных данных -- справочных и данных проекта]
Д) стабильная и надёжная инфраструктура обслуживается и совершенствуется.

Сотрудники организации [избежим слова "акторы", 24744:producers] ДОЛЖНЫ выполнить при постановке инженерии схемы данных следующие мероприятия и дела:
a) организовать людей
Должны быть определены организации (отдельные юрлица, если речь идет о расширенной организации, и подразделения, если речь идет о какой-то отдельной организации), предоставляющие физических лиц для заполнения ролей модельеров данных и предметных экспертов [айтишников для настройки-поддержки софта тут не определяем, их деятельность будет описана отдельной практикой -- хотя в таком различении и есть сомнения]. Инженерия схемы данных, как и любая другая работа по моделированию выполняется небольшим числом хорошо коммуницирующих квалифицированных людей, а не "организациями". Поэтому невозможно "заключить контракты с юрлицами", а потом просто собрать результат работы в виде готового продукта. Должны быть выполнены следующие дела:

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

В контрактах явно определяется, какие именно роли из настоящего стандарта будут исполняться подрядчиком, какая IT-инфраструктура и инструменты будут использоваться.

В контракте явно оговаривается раскрытие Заказчику информации о делегировании конкретных людей и компонент IT-сервисов в число участников проекта инженерии схемы данных жизненного цикла, проектный менеджер [эта роль не определена в данном отрывке стандарта, и нужно еще подумать, вводить ли сразу проектную действительность] ведет справочник назначений (заполнения ролей модельеров данных и предметных экспертов) и справочник IT-сервисов и инструментов.

2) физические назначения
Менеджмент организаций, заключивших контракт на участие в инженерии схеме данных жизненного цикла, обязан выполнить требования контракта и назначить конкретных физических лиц (раскрыв их назначение проектному менеджеру для заполнения справочника назначений), а также выделив оговоренные сервисы IT-инфраструктуры и раскрыв их в справочнике IT-сервисов и инструментов проектного менеджера.

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

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

Необходимо довести до них цели проекта, описать конструкцию контрактов [в том числе неявных, между подразделениями или даже внутри подразделения]

Необходимо представить людям методологию работы (текст настоящего Стандарта и сопутствующие справочные материалы).

2) провести установочное заседание проектной команды
На этом заседании проектная команда знакомится друг с другом, получает ответы на вопросы, связанные с их назначением (полномочия, ответственности, доступная инфраструктура и инструменты, расписание и место работы, обязательность следования описанному в данном Стандарте методу работы и т.д.).

Рекомендуется использование методов проведения kick-off meetings из проектного управления.

3) проводить регулярные планирующие и контрольные мероприятия в порядке управления проектом
Использовать сценарные техники ролевого проведения планирующих и контрольных мероприятий (планирование итераций в духе Agile методов, планирование в духе LastPlanner и т.д.).

Рекомендуется использование техник планирования и мониторинга проектов, адаптированные из методов управления программными проектами. [специфика инженерии схемы данных жизненного цикла более похоже на программирование, нежели на другие типы работ]

c) Обучить участников проекта
Для того, чтобы участники проекта инженерии схемы данных жизненного цикла могли выполнить свою задачу, нужно их обучить. В описании каждого вида актора приведены минимальные компетенции и знания, которыми они должны обладать, чтобы выполнять свою работу.

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

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

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

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

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

Полезно участие в таких семинарах не только "целевых" участников проекта (модельеров данных и проектных экспертов), но и других специалистов (администраторов данных, проектных менеджеров, разработчиков, программистов и т.д.).

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

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

Необходимо участие модельеров данных в онлайн-сообществах (dot15926, форумы Iring, комьюнити "ISO 15926" в LinkedIn и т.д.).

Практикуется также личная переписка между экспертами (для чего полезно личное знакомство на международных и отечественных конференциях.

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

1) настройка инструментов (IT-сервисов) на совместную работу
Приобретение всех необходимых инструментов (и разворачивание их в виде IT-сервисов) предполагается на предпроектной стадии, на стадии собственно проекта инженерии схемы данных жизненного цикла должна быть проведена только настройка всех потребных IT-сервисов для совместного применения в ходе конкретного инженерного проекта:
Предусловие:к моменту начала настройки существуют:
-- необходимые программные средства и лицензии
-- рабочие места для коллективной работы над моделями (требование: монитор 2560*1600 плюс возможность работы 3-4 человек за одним монитором). Такими рабочими местами должны обладать как модельер данных, так и предметный эксперт.

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

Компоненты должны быть настроены на использование принятой на предприятии сервис-ориентированной архитектуры [если предприятию свезло такую архитектуру иметь]. Настроенная конфигурация компонент должна быть поставлена под контроль конфигурации и обслуживаться (например, согласно набору практик жизненного цикла IT-инфраструктуры ITIL) [этот вопрос не рассматривается в рамках данного Стандарта. Это к Стандарту методов поддержки IT-инфраструктуры. Поэтому-то я и не стал включать в число исполнителей проекта роль айтишника или программиста].

2) закрепление исполнителей за рабочими местами
Участвующим в проекте модельерам данных и предметным экспертам [более корректная формулировка: людям, замещающим роли модельеров данных и предметных экспертов] должны быть предоставлены на их рабочих местах необходимые пароли к программам, а также права доступа к тем данным, которые им необходимы для работы. Должен быть проведен инструктаж (в том числе -- обучение) по работе с этими программными средствами в части администрирования [предполагается, что вряд ли работник IT-службы, установивший какой-то Редактор схемы или RDL sandbox проведет инструктаж по собственно моделированию. Скорее, он покажет, как вызывать программу, и куда на сервере можно/нужно выкладывать результаты работы, и как потом схема данных будет попадать в целевое хранилище данных для НСИ и/или инжинирингового проекта]. Всем участникам проекта должен быть известен телефон службы IT-поддержки.

Наставление по постановке метода [я думаю, что текст этого наставления может быть сохранен для "неспециализированного" описания метода]

Театральная метафора
Основная метафора постановки методологии [метод и методология, как объяснено в ISO 24744 -- синонимы]– театральная. Методология – это сценарий для прописанных ролей, который необходимо исполнить имеющейся труппой реальных людей, назначенных на роли. В ходе постановки пьесы проводится кастинг людей-актеров на роли, эти роли затем разучиваются, закупается реквизит, спектакль репетируется для осуществления правильного взаимодействия актеров друг с другом и реквизитом, а затем осуществляется игра актеров в спектакле соответственно их ролям.

Два уровня: организация и физические назначения
Основная проблема в том, что существует два уровня выполнения данной работы:

А) в наложенной организации проекта («организации, наложенной на существующие юридические лица, http://ailev.livejournal.com/652159.html) находятся формально ответственные (чаще всего – в силу договора) юридические лица, которые должны выполнять те или иные акторские роли и предоставлять те или иные IT-сервисы. Так что нужно заключить правильную систему контрактов, определить полномочия (в том числе по использованию ресурсов -- например, инструментов) и ответственности.[опять же, эти "организации" могут оказаться подразделениями внутри предприятия, а "договора" -- устными соглашениями]

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

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

Необходимость наличия инфраструктуры перед началом моделирования
Тем не менее, согласно правилам Lean management (восьмой тип muda – «making-do», описанный Lauri Koskela в http://www.iglc2004.dk/_root/media/13091%5F088%2Dkoskela%2Dfinal.pdf) нельзя приступать к работе, пока не наличествуют все необходимые ресурсы, это ведет к бесполезной трате времени и наличных ресурсов. Нельзя разрабатывать схему данных жизненного цикла, пока нет квалифицированного модельера данных, или пока нет софта для создания схем данных.

Поэтому постановку метода необходимо вставлять в [рабочий продукт] «План-график стадии создания схемы данных», строго контролировать ее обеспечение ресурсами, проверять фактическое выполнение.

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

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

Продукты работы
[продукты должны бы быть специфицированы как "продуктный пул" для всей совокупности практик метода, но уж приведу тут без подробностей и не претендуя на полноту списка -- только для примера. Более того, сама терминология тоже еще не устоялась и требует отдельного разбирательства]

Основные:
-- целевая схема данных (шаблоны и классы), как набор онтолетов (часть местной RDL), возможно в вариантах "нейтральной схемы" и "схемы в формате конкретного хранилища данных" (можно назвать "физической схемой", но тут цепочка явно больше, чем в "трехсхемной модели", и до "физической схемы" может быть еще несколько уровней -- объектная схема, затем реляционная схема, затем b-деревья и т.д.). Схема состоит из отдельных ссылающихся друг на друга онтолетов.
-- схема мэппинга, если он требуется для хранения целевой схемы [а если речь идет о практике интеграции данных с использованием мэппинга/адаптеров, то это отдельная практика]
-- уже наличествующие "доверенные" [то есть те, которым мы доверяем] онтолеты из федерации RDL (как для использования в моделировании, так и для пополнения по итогам моделирования)
-- материалы для моделирования (проектная документация, учебники, словари, стандарты, справочные базы данных и т.д.. Часто еще и "живые эксперты", ибо речь идет о knowledge acquisition, т.е. превращении implicit knowledge в explicit. Тут же -- доступ к поисковым системам, например, Google или Яндекс).
-- отладочные данные

Вспомогательные:
-- Справочник назначений -- ведется Проектным менеджером
-- Справочник IT-сервисов -- ведется Проектным менеджером
-- набор литературы и учебных схем данных для образования модельера данных
-- настоящий Стандарт инженерии схемы данных жизненного цикла [помним, что пул продуктов определяется не для отдельной практики, а для всей дисциплины]

Роли
-- модельер данных
ISO 15926 предусматривает минимально два уровня: "желтый пояс", который способен выполнить какое-то моделирование самостоятельно для использования получившейся схемы в рамках предприятия, и "черный пояс", чьи схемы достойны помещения в публичный (отраслевой, национальный, глобальный) RDL.
Объем знаний: владение методами, описанными настоящим Стандартом [см. также набор практик в http://community.livejournal.com/dot15926/16360.html].

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

Инструменты (IT-сервисы)
-- редактор схемы данных
-- сервер для поддержки местного RDL и участия в федерации RDL (считаем, что пруверы входят в состав сервера)
-- хранилище данных для тестовых загрузок данных (считаем, что адаптер входит в состав хранилища данных, равно как и интерфейсы загрузки и просмотра данных)