?

Log in

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

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

Инженерия справочных данных ISO 15926. Описание метода. [25 Feb 2011|01:59pm]
TechInvestLab опубликовал вторую версию описания метода "Инженерия справочных данных ISO 15926" -- http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc. Насколько я понимаю, это первое в мире внятное и более-менее соответствующее самым свежим версиям Стандарта описание того, что же нужно делать для реализации слогана "ISO 15926 outside". Забавно, что такой текст впервые появился на русском языке, а не на английском или норвежском.

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

Первая версия этого текста растеклась по 70 страницам и пыталась объять необъятное: подробно расписывала практики самых разных жизненных циклов -- от обеспечивающей системы (практики оргразвития для освоения метода) до жизненного цикла шаблона с перечислением всяких хитростей плетения аналитических диаграмм с учётом 4D-онтологии. Попытка в этом первом тексте разделить метод ISO 15926 на ontology science, ontology engineering и mapping engineering оказалась негодной: потерялась целевая система и её жизненный цикл, а число практик перевалило за тридцать и стало неуправляемым. Рассортированный по нескольким группам описаний набор рабочих продуктов удручал: поскольку части рабочих продуктов рассматривались как независимые рабочие продукты, список был огромен и отношения между продуктами оказались плохо определенными. Пяти уровней оглавления не хватало. К тому же целевой системой была неудачно выбрана "схема данных" -- тяжёлое наследие парадигмы "баз данных". Поэтому вторая часть писалась заново с чистого листа.

Разработка началась с трехчасовой дискуссии и исписанных пары листов флип-чарта. Далее был подготовлен десяток схем в PowerPoint (из которых четыре существенно переработанных попали в окончательную версию документа). По итогам разбирательства с этими схемами во второй версии было решено убрать весь материал ontology science (про 4D extensionalism, как именно разрабатывать аналитические диаграммы и т.д. -- про это достаточно рассказано в самом стандарте), а также практики подготовки организации (ибо текст предназначался инженерам, а не менеджерам). Осталась только часть ontology engineering, неразрывно склеенная с mapping engineering.

После моделирования на схемах в PowerPoint убрали классификацию групп описаний рабочих продуктов: правильный вопрос был "онтологический" (какие есть рабочие продукты), а не "какие есть описания рабочих продуктов". Изо всех вариантов жизненного цикла самых разных рабочих продуктов остался только инкрементальный жизненный цикл главного, самого времязатратного продукта: справочных данных одного инженерного проекта (а понятие "схема данных" упоминается только в связи с legacy хранилищами данных). Применяемые в этом жизненном цикле практики были текстуально размещены внутри описания стадий жизненного цикла. Уровней заголовков оставили один. Каждый из нас (писали я и vvagr) сделал по три редакторских прохода по тексту, итого получилось 19 страниц с четырьмя картинками -- мы намеренно не хотели делать текст подробным, чтобы сохранить его "обзорность".

Первая часть текста содержит ответы на часто встречающиеся вопросы (для чего применяется ISO 15926? что такое "единое информационное пространство", которое неизменно встречается во всех русскоязычных презентациях и отсутствует в презентациях англоязычных? почему не помогают стандарты STEP? чем отличается интеграция данных от обмена данными? почему "ISO 15926 outside" не похож на традиционный MDM -- master data management? и т.д.). Удивительно, но ответы на большинство этих вопросов представлены сейчас только в устной традиции, или разбросаны по слайдам разных авторов и репликам в нескольких форумах.

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

Мы также следовали принципам и терминологии системной инженерии (в версии ISO 15288 и сопутствующих ему стандартов). Это легко: сам ISO 15926 использует терминологию типа "данные жизненного цикла установки" (plant life cycle data), наши "часто встречающиеся вопросы об ISO 15926" по факту являются (функциональными) требованиями к методу, а изложение компонент метода -- описание конструкции (морфологии) метода, включая пояснения по связи функции и конструкции, т.е. архитектуры метода инженерии справочных данных.

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

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

Для меня самым трудным в работе было:

1. Как организовать модульность в описании метода.
Все практики глубоко иерархичны, все рабочие продукты имеют много уровней детализации, на одном наборе практик может быть множество видов жизненных циклов (да и каждая деталь рабочего продукта имеет собственный жизненный цикл). Как структурировать это разноуровневое месиво? Мы некоторое время назад выкинули OMG SPEM за то, что этот стандарт не поддерживал много уровней описания. Сейчас у меня закралось подозрение: может быть, это неплохо? Ассоциативное связывание как метод доступа к компонентам метода не лучше и не хуже, чем глубокая таксономия. Пока что очевидно, что короткий текст на одну тему явно лучше длинного текста на все темы.

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

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

Но додумывать в плане модульности описания метода нужно еще много чего.

2. Разбиение описаний системы в стиле ISO 42010 -- не по объектам, а по группам их описаний.
Я заметил провальность любых попыток организовать знание о рабочих продуктах "по группам описаний", как они даны в архитектурных фреймворках (т.е. используя диаграммы метамодели ISO 42010). Все эти DoDAFы и MoDAFы замечены в том, что заставляют произвести много лишних описаний, но не позволяют сформулировать необходимые. Гарольд "Бад" Лоусон предлагает lightweight architectural framework, основывающийся на ISO 15288, как выход из ситуации, но мне беда представляется другой: неонтологичность выявления всех этих групп описаний. Нужно структурировать текст не по разным описаниям одних и тех же объектов, а по самим объектам. Описания-модели же и их группы использовать по потребности, не выводя их на уровень основного разбиения. То есть в основе изложения лежат PBS и WBS, а не архитектурный фреймворк!

Похоже, что ISO 42010 инструмент более аналитический, нежели синтетический: его можно использовать для объяснений и проверок, но не в качестве деятельностного ориентира -- то есть задающего какое-то "разбиение". Как только "группы описаний рабочих продуктов" попадают в заголовки -- так всё пропало, и вместо холистичного синтеза и продвижения вперед в работе начинается останавливающий работу analysis paralysis прямо из учебников.

Это хорошая тема для обсуждения на Рабочей встрече по проблемам системной инженерии в Бекасово (7-11 апреля 2011г.), ибо там как раз будет акцент на тему инженерных разбиений.
2 comments|post comment

navigation
[ viewing | February 25th, 2011 ]
[ go | previous day|next day ]