Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Возможности

Одно русское слово "возможности" -- и куча самых разных английских терминов (opportunities, possibilities, capabilities).

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

Всю ночь Ontology Summit 2013 обсуждал capability -- пусть по-русски это пока будет тоже "возможности". Быстро пришли к выводу, что в разных контекстах слово используется абсолютно по-разному ("это функции, процессы -- нет, это ровно наоборот, ни разу не функции и процессы!"). Слово за слово, и речь пошла об архитектуре предпринятия (enterprise architecture). И тут Denise Bedford форулирует то, что мне никак не удавалось выразить точно: "Enterprise Architecture is not configuration management and has never been.  But many people practice configuration management and call it EA".  (http://ontolog.cim3.net/forum/ontology-summit/2013-03/msg00152.html).

Я пытался об этом говорить несколько неуклюже, описывая форму того, что происходит: "якобы архитектор" пристаёт ко всем с расспросами, и делает архитектурные описания -- архитектурой занимаются какие-то другие люди, а наш "якобы архитектор" при этом является только писарем, писцом, владеющим искусством записывать чужие мысли. Но это только форма. Настоящий грех при таком подходе, что этот писец выполняет по факту задачу управления конфигурацией: учётную задачу. Учёт оборудования, учёт программ, учёт людей и их взаимодействий. Архитектурная задача -- это не задача учёта, это задача придумывания. Архитектор придумывает, а дальше уже неважно, кто записывает -- писарь ли, он сам ли на специальных языках, или видеокамера фиксирует его голос и размахивания руками. Но документирование as is и to be с версионированием -- это тут не главное, главное -- придумать, что документировать.

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

Про сами возможности-capability, конечно, важно: это попытка перейти от засилья процессных/поведенческих описаний к описаниям в терминах конечных результатов (ответов на вопрос: для чего нам нужны эти процессы, эти поведения). Ибо процессный подход грешит тем, что весь свисток уходит в то, чтобы иметь быстрые и дешёвые процессы, ведущие из ниоткуда в никуда, иметь функции, которые никому не нужны. Заказ в терминах чисто функциональных описаний оказывается часто не лучшим. Поэтому заказ делается в терминах состояния мира, которое хочется получить после создания целевой системы. Это и есть capabilities системы -- состояния мира, которые она сможет обеспечить своим поведением, своими функциями. Именно поэтому "функциональных требований" не хватает, и постоянно говорят о необходимости отслеживать источник этих требований (ISO 15288), возможностей-opportunity (OMG Essence) фокусирующих требования, и возможностей-capability.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 8 comments