Описание постановки инженерии схемы данных жизненного цикла
Попробуем написать отрывок потенциального "Стандарта инженерии схемы данных жизненного цикла" как стандарта, задающего описание метода [можно дополнительно протипизировать и "данные жизненного цикла" -- "Стандарт инженерии сжемы данных жизненного цикла целевой системы", что укажет на использование методов системной инженерии, поелику помянут тип "целевая система" из онтолета 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 (считаем, что пруверы входят в состав сервера)
-- хранилище данных для тестовых загрузок данных (считаем, что адаптер входит в состав хранилища данных, равно как и интерфейсы загрузки и просмотра данных)
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 (считаем, что пруверы входят в состав сервера)
-- хранилище данных для тестовых загрузок данных (считаем, что адаптер входит в состав хранилища данных, равно как и интерфейсы загрузки и просмотра данных)