Акционерное общество

НАУЧНО-ИССЛЕДОВАТЕЛЬСКИЙ ИНСТИТУТ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКИХ ТЕХНОЛОГИЙ

Конфигурационное Управление Разработкой Систем

Территория ФОРПОСТА
Тетрадь № 143

Здесь рассмотрены общие информационные и интеллектуальные процессы, имеющие место в технологии управления разрабатываемыми конфигурациями весьма сложных систем – Large Scale Systems».
Москва — 1981

Ович-Робзарен Х.А.
КУРС
Конфигурационное управление Разработкой Систем
Введение
УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ ОБРАЗЦА В ПРОЦЕССЕ КОНСТРУИРОВАНИЯ
Конфигурационное управление

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

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

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

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

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

Во-вторых, стал давать о себе знать «принцип историзма», вернее, не он сам, а последствия его нарушения. Как указывают авторы книги [1], после запуска первого американского искусственного спутника Земли возникли трудности с запуском второго.

Дело в том, что окончательное изделие, которое ушло на орбиту и стало недоступно для копирования образца, было сделано с большими отклонениями от первоначального проекта. Эти изменения накопились постепенно и не все они были зарегистрированы в изменениях к документации. В результате для изготовления второго спутника проектировщикам пришлось многое вспоминать, восстанавливать по памяти, а многое изобретать заново.

Изделия ядерной техники, главным образом высокоавтоматизированные и вступившие в режим эксплуатации, подобны такому объекту. Они также не доступны для копирования с имеющегося образца.

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

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

Служба конфигурационного контроля в целом — это сложная организация со многими уровнями подчинения, оснащённая специальной документацией, системой стандартов на процедуры и документы, автоматизированной системой контроля конфигурации на базе ЭВМ.

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

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

Начиная с фазы целеобразования и кончая фазой снятия с производства с данным образцом связаны как бы четыре машины: концептуально-документальная, графическая, программно-алгоритмическая и материальная.

В самом деле, обилие документации даже на простое с виду изделие поражает непосвящённых. Документы выпускают на всех фазах цикла в дополняющих или альтернативных отношениях друг к другу.

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

В ЕСКД с этой целью предусмотрены маркировочные средства для фиксации вариантов или альтернатив графического (конструкционного) исполнения деталей, узлов и блоков образца.

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

Это делается для обеспечения наибольшей полезности образцов, извлечения прибыли от разработки именно в исторически отведённый интервал времени, так как и преждевременное, и запоздалое внедрение образцов, как уже было упомянуто, одинаково приводит к убыткам.

Так или иначе, а с жизнью данного образца связана жизнь трёх других машин, которые определяют все значимые показатели материализованной машины — действующих экземпляров данного образца. Утеря значительной части любой из этих трёх «машин» быстро скажется на парке действующих экземпляров.

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

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

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

Пополнение файла данными о конфигурации

При конфигурационном управлении выполняют, в сущности, три функции:

— обнаружение и учёт предлагаемых изменений,

— контроль базовой конфигурации,

— принятие решений по изменению базовой конфигурации.

При выполнении их порождаются новые данные, которые следует разделить на два класса:

— служебные и паспортные данные, характеризующие время, место, авторов изменения, причину, из-за которой изменение предлагается, обоснование реализуемости;

— конкретные данные о предлагаемой альтернативе (и подчинённым ей имплицитным альтернативам).

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

Но как быть с изменениями остальных трёх машин, которые, естественно, сопряжены с данной?

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

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

В этом смысле последним и несколько запоздалым (что, впрочем, вполне понятно в силу исторически сложившихся обстоятельств) было появление методов так называемого структурного программирования и в особенности метода иерархического программирования и отладки программ — HIPO.

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

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

Под индексом (ключом) 1 зашифровано семейство машин в целом. Если имеется документ, относящийся к семейству машин в целом, то он получает ключ 1D1. Если таких документов много, то опорная часть их ключа всегда есть 1D.

Далее документы перечисляются в любом, например, даже алфавитном порядке последовательным и открытым для любых пополнений множеством ключей: 1D2., 1D17., … 1D9367. Если, например, документ 1D117. имеет подчинённые «шкафы», тома, разделы, книги, то они могут нумероваться как 1D117.1, 1D117.2 и т.д. Если документ 1D117.2. имеет альтернативные варианты (полярный вариант машины, машина для умеренных широт, тропический вариант и т.п.), то они нумеруются как

1D117.2A1., 1D117.2A2. и т.д.

Аналогичным образом нумеруют графические документы с тем только отличием, что применяют для них маркер «G», например, 1.3.G2A5. Таким же образом нумерую программы и составляющие их модули (вызываемые процедуры). Здесь тоже и в ещё большей степени на любом уровне возможны альтернативы. Для нумерации здесь применяют маркер «PR». Таким образом 1PR2.3A2 помечет процедуру, которая вызывается процедурой 1PR2, причём это второй вариант такой процедуры (А2).

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

Легко заметить, что маркеры «D» (doc), «G» (grf) и «PR» (prg) могут появиться на любом уровне разбиения комбинаторного файла. Кроме того, они могут вторгаться в область действия друг друга. Например, может идти речь о графических данных, которые оформлены как программный модуль данных (видеофайл), тогда ключ будет иметь структуру

1.__G__PR…

Или документ (инструкция) каталогизирован в память, так что работа с машиной может идти по методу расспрашивания, тогда ключ будет иметь вид

1__D__PR.

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

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

Здесь эта проблема просто не возникает. Для образования ключей нет никаких ограничений, кроме чисто технического ограничения на длину, но и то лишь в том случае, когда они предназначены для машинной обработки и служат исходным материалом при выработке ключа в индексно-последовательных файлах. Длина ключа здесь не должна превышать 255 символов.

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

Об извлечении уроков из прошлого

Прошлое не обязательно должно быть почтенным историческим прошлым; детальному анализу и обстоятельному обобщению могут быть подвергнуты и действия, скажем, недельной давности. Впрочем, во многих отраслях «разбор полётов» производят почти непосредственно по окончанию ответственных действий.

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

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

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

После конфигурационного учёта изменений данные о них могут поступить на анализ и обобщение. Первые попытки регистрировать все существенные действия и события в ходе разработки образца техники были предприняты в рамках научно-практического проекта «Хиндсайт» [2], который был проведён на примере процессов создания более двадцати образцов в системах вооружений именно с целью научиться понимать прошлое и извлекать из него уроки — уроки прошлого опыта.

Ранг изменения

После того, как комбинаторный файл пополнен данными для конфигурационного учёта и контроля, можно рассмотреть и более точно определить понятие изменения.

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

— набор свойств будущего образца (список характеристик),

— обязательные признаки строения («обязательные качества»), которые образец должен иметь,

— элементы используемых прототипов, в том числе готовые комплектующие блоки и изделия;

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

— стандарты и другие руководящие документы,

— готовые сертифицированные программные продукты, которые должны быть применены в производстве и функционировании образца

— и т.п.

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

Однако так описанный идеальный ход событий никогда на практике не реализуется.

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

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

Если изменяют заказную конфигурацию, то говорят, что это изменение первого ранга, так как его принятие должно быть обязательно согласовано с заказчиком, в противном случае — изменение есть изменение, максимум, второго ранга. Изменения, которые выносит на обсуждение заказчик, всегда принадлежат к первому рангу, даже если они только детализируют заказную конфигурацию.

Уровень изменения

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

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

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

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

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

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

В качестве первичной записи в бланк прохождения документа вносят текст формулировки сущности изменения и ключ, определяющий место «начала» изменения в комбинаторном файле.

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

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

Паспорт изменения

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

Паспорт может состоять из следующих смысловых разделов, или так называемых фасетов:

КТО (конкретное должностное лицо, подразделение, организация) предложил данное изменение;

КОГДА (день, месяц, год) внесено предложение;

ГДЕ территориально возникло данное предложение об изменении;

КОГДА, КЕМ и ГДЕ осуществлено первое рассмотрение документа;

КТО провёл структурный анализ предложенных альтернатив и составил бланк конфигурационного учёта;

КОГДА, ГДЕ, КАКОЙ официальный орган рассмотрел и принял решение о статусе предложенного изменения и т.п.

На основании паспортов всех изменений можно на каждый момент разработки, например, сопоставить предлагавшийся и утверждённый составы базовой конфигурации. На основании сопоставления могут быть затребованы сводки и другого типа, в которых будут затронуты, например, территориальный, кадровый, ресурсный и подобные аспекты разрабатываемого проекта.

Особый интерес представляет смысл паспорта, в котором обосновывается либо отказ, либо отлагание, либо запрет на предлагаемое изменение, так как в нём концентрированы аргументы экономического и организационного характера. Иногда ведь изменение всей проектировочной ситуации приводит и к возврату к ранее отвергнутым предложениям. Следовательно, их надо хранить, хотя бы в назидание.

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

5.3. Основы контроля конфигурации

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

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

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

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

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

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

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

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

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

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

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

Проведя эту автоматизацию, можно затем подкрепить полученным автоматическим процессом «оставшуюся» творческую составляющую, которая при этом сама может измениться как качественно, так и в плане возросшей творческой чисто количественной производительности.

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

Функция, реализующая в конструировании целостность, хотя и кажется чисто интуитивной, также содержит в себе рутинную составляющую и допускает применение принципа расщепление — автоматизация — подкрепление.

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

вариантов вдвойне полезно, оно позволяет конструктору не заботиться о том, «как бы чего не вышло», и направить все свои творческие силы на решении вопросов «как это реализовать?»

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

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

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

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

Таким образом, точка зрения и конструктивно-познавательная задача сильно влияют на «величину» системы, так что понятие большой системы скорее характеризует ситуации в процессе проектирования, чем реальные физические объекты. Однако, практика, как правило, всё-таки заставляет заниматься «сутью дела», а не бесплодным упрощенчеством или усложнительством.

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

В настоящее время всё же всё большее число систем переходит на стадии проектирования в разряд больших систем, меняется точка зрения, возрастают требования к тщательности проектирования.

Инженерная практика настойчиво требует рутинного подкрепления проектировочного процесса на тех этапах, на которых создаётся картина поведения большой системы, когда картину целиком не может воссоздать один конструктор, и она воссоздаётся из картин воображения многих специалистов.

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

Тогда конструктор, имея такое автоматическое подкрепление, сможет сосредоточить свои усилия на составлении новых целостностей, а не на проверке их состоятельности. Расчётный аналог чувства целостности, синхронно подкрепляющий естественную интуицию проектировщика, — так называемый показатель целостности может быть определён на базе понятий «комбинаторный файл», «альтернатива», «комбинанта» и «матрица совместимостей».

Характеристики целого

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

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

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

Этот способ основывается на матрицах совместимости поясов альтернатив. Каждому поясу альтернатив ставится в соответствие блочная матрица совместимости. Между этими матрицами устанавливается естественная иерархия отношения совместимости, которая подробно обсуждается ниже. По содержимому ячеек матриц определяется функционал S — показатель целостности, характеризующий произвольную выборку альтернатив из файла.

Физический смысл этого функционала весьма прост и состоит в том, что область его значений [-1,+1] является своеобразной шкалой состоятельности выборки. Значение этой шкалы охватывает все градации целого, заключённые между следующими тремя случаями:

1) S = -1 — функционально вредная (деструктивная) выборка — совокупность блоков, которые работая как целое или в рамках целого приведут к ущербу, например, аварии, взрыву, загрязнению среды и т.п.

2) S = 0 — функционально неосуществимая выборка, то есть такая структура, которая не может работать как целое или в рамках целого не будет реализовать целевой процесс.

3) S = +1 — функционально полезная выборка, то есть структура, которая сможет работать в рамках целого и давать полезный технологический эффект.

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

S — коэффициент корреляции;

S = -1 — достоверно деструктивная (саморазрушающаяся, катахрезная) комбинация;

S = +1 — достоверно конструктивная комбинация;

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

в интервале (0, +1) лежат значения коэффициентов корреляции конструктивных комбинаций альтернатив.

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

Матрицы совместимости

Во второй главе упомянуты элементарные матрицы совместимости. Эти матрицы дают один из возможных способов символического представления комбинант. Для некоторой

пары альтернативных линеек А = ai и В = bj элементарная матрица совместимости есть прямоугольная таблица А:В с проставленными в её ячейках значениями -1, 0, +1 по следующему правилу:

(ai,bj) = -1, если альтернативы ai и bj сопрягаемы в одной конструкции, но дают деструктивный эффект (взрыв, аварию, быстрый износ узлов конструкции и т.п.)

матрица а = А:В определена невырожденным образом, так как линейки А и В лежат на одном поясе альтернатив и инцидентны через вершину Р;

матрица k = А:С полувырожденная, то есть всегда заполнена только единицами, так как совместимость А и С в целом определилась в матрице а и ещё не уточнялась в матрице y = Т:С и подобных ей матрицах;

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

(ai,bj) = 0, если альтернативы ai и bj функционально несопрягаемы в рамках одной конструкции, хотя и попадают в рамки одной формальной комбинации;

(ai,bj) = +1, если альтернативы ai и bj не только функционально сопрягаемы, но и совместно (взаимно, эмерджентно и т.п.) полезны в рамках одной конструкции.

В частности, матрицы А:А и В:В суть единичные квадратные матрицы в силу определения альтернатив как возможности конструктивного выбора, взаимно исключающие друг друга.

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

Однако элементарные матрицы совместимости имеет смысл составлять лишь для тех пар альтернативных линеек, позиции которых действительно могут выступать в комбинациях в рамках одной конструкции.

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

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

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

Существует взаимно-однозначное соответствие между поясами альтернатив и матрицами из пирамиды совместимости (рис.5.2). Иерархия как своеобразная импликация матриц совместимости состоит ещё и в том, что случаи заведомой несовместимости тех или иных блоков, обнаруживаются на высоких уровнях пирамиды, так что под соответствующими им нулевыми ячейками в нижележащих матрицах совместимости появляются как следствие полностью нулевые блоки. Это сразу существенно снижает объём обрабатываемых данных о совместимости.

Матрицы совместимости поясов альтернатив удобны и для теоретических и чисто умозрительных моделей и выводов.

Показатель целостности

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

Введём треугольное произведение S позиций b, d, e, f, h, то есть произведение множества элементов, стоящих на всех попарных пересечениях выбранных альтернатив, причём знак треугольного произведения будем вычислять, пользуясь следующей таблицей умножения

aj\ai -1 0 +1
-1 -1 0 -1
0 0 0 0
1 -1 0 1

Рассмотрим некоторые весьма естественные свойства такого произведения:

1) S = +1 только тогда, когда произведённая выборка оказывается эмерджентно функционально полезной и состоятельной;

2) S = 0, как только в выборке окажется хотя одна пара функционально несопрягаемых альтернатив;

3) S = -1, если в выборку попадает хоть одна пара несовместимых альтернатив, вызывающих вредные последствия.

Таким образом, знак функционала S и его абсолютное значение сразу же предупреждают конструктора о нежелательном сочетании альтернатив в произведённой им выборке.

Начав с произвольной выборки, можно путём добавления одних альтернатив и исключения других, прийти к ситуации, когда выбор сделан во всех линейках пояса альтернатив и, тем не менее S = 1.

Так как в нашем случае пояс всего один, то это означает, что выбрана некоторая, возможно, осуществимая комбинация — целостная комбинация.

Таким образом, в этом простом случае треугольное произведение играет роль показателя целостности и, возможно, — осуществимости. Обобщим этот показатель на случаи файлов с более чем одним поясом альтернатив.

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

пересекающиеся подмножества в соответствии с принадлежностью линеек поясам альтернатив:

М = mI + mII + mIII + …,

где mI — множество линеек, принадлежащих первому поясу альтернатив;

mII — второму поясу и т.д. Определим значение S(M) следующим образом:

Здесь S(mi) — ранее определённое для файла с одним поясом альтернатив треугольное произведение; множители в фигурных скобках вычисляются по тем же правилам, но из элементов, взятых из полувырожденных, а возможно, вырожденных матриц, составленных для линеек из разных поясов альтернатив, то есть межпоясных матриц совместимости.

Если в каждом поясе комбинация правильная, то все S(mi) = +1 и знак S(m) могут изменить только сомножители s(mi,mj).

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

Лемма: Если PP s (mi,m)j = +1 при всех i,j (i<>j), то правомерно провести данную выборку М в k этапов следующим образом:

— провести частичную выборку mI в первом поясе альтернатив и выделить во втором поясе множество G(mII) тех альтернативных линеек, в которые ведут простые пути от любой одной альтернативы из mI;

— провести частную выборку mII в G(mI) второго пояса альтернатив и выделить в третьем поясе множество G(mII) тех альтернативных линеек, в которые ведут простые пути от любой одной вершины-альтернативы из mII;

И так далее вплоть до последнего k-го пояса альтернатив.

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

Следствие 2. Каким бы способом ни была получена выборка целостной конструкции, всегда можно условно представить, что оно произведена последовательно-связно в направлении от центра комбинаторного файла.

Эти два следствия существенно упрощают все определения, выводы и иллюстрации, касающиеся оптимизации процесса выбора замысла конструкции. В результате введённый показатель целостности S(M) при последовательно-связном способе выборки упрощается, так как всегда этот сомножитель

PP s (mi,m)j = +1,

даже в том случае, когда любой набор из S(mi) обращается в 0 или -1.

Таким образом, при последовательно-связной выборке S(m) удобен в работе и продолжает удовлетворять свойствам 1 — 3.

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

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

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

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

«Опытность любого специалиста… состоит не только в знании ряда типичных ситуаций и их свойств, но в умении переносить этот опыт на новые ситуации, правильно предугадывать их свойства… Здесь человек оказывается сильнее математической статистики…

Там, где нет массовых данных наблюдений конкретного события, интуиция мобилизует массовые данные переноса прошлого опыта на различные единичные события. Человек заменяет статистику событий статистикой актов прогноза, тонко учитывая сходство и различие ситуаций» [3].

Следует особо подчеркнуть, что указанное соотношение между статистическими данными и данными интуиции специалиста имеет принципиально постоянный характер. Это соотношение сохраняется всегда. Его нельзя мотивировать, например, тем, что статистика де недостаточно развита в данной области. Объективность и научность вовсе не означают отказ от интуиции опытных специалистов. Нужен правильный её учёт и использование.

Когда комбинаторный файл построен, мобилизуют опыт специалистов по данному семейству технических систем в целях построения пирамиды матриц совместимости. Естественно, что предварительно в ней должны быть «чисто механически» учтены все достоверные факты машиностроения, составившие историю данного семейства.

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

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

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

— какая часть замысла и кем уже реализована;

— какая часть из нереализованного фигурировала уже в официально высказанных ранее замыслах;

— каков ранг этих замыслов и т.д.

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

Общая схема конфигурационного управления

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

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

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

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

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

Рис. 5.3. Общая схема процесса конфигурационного управления

Таким образом, как и в предыдущих главах, оказалось, что для выполнения всех без исключения функций в ходе конфигурационного управления разработкой образца машины центральным является понятие «работа с альтернативами», хотя и модифицированное с учётом специфики идей конфигурационного управления; символическим и смысловым понятием — «комбинаторный файл», концентрирующим все известные на данный момент альтернативы выполнения элементов строения образца, графической и иной документации, математического обеспечения.

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

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

Список литературы

  1. Бобрышев Д.Н., Рексин В.Э. Управление конфигурацией технических систем. М.: Сов. радио, 1978.
  2. Айзенсон Р.С. Опыт технического прогнозирования при выполнении проекта «Хиндсайт». — В сб.: Научно-техническое прогнозирование для правительственных и промышленных учреждений. М., Прогресс, 1972, с. 21-38.
  3. Хованов Г.М. О практике экспертных оценок в прогнозировании и планировании развития науки и техники. — В кн.: Проблемы организации научных исследований и разработок. Тр. I Московской конференции молодых учёных. М.: Наука, 1967, с. 148 — 152.

 

27 марта 2017 года был проведен III Санкт-Петербургский экономический конгресс (СПЭК -2017) «Форсайт «Россия»: новое индустриальное общество. Перезагрузка».27 марта 2017 года был проведен III Санкт-Петербургский экономический конгресс (СПЭК -2017) «Форсайт «Россия»: новое индустриальное общество. Перезагрузка».

27 марта 2017 года был проведен III Санкт-Петербургский экономический конгресс (СПЭК -2017) «Форсайт «Россия»: новое индустриальное общество. Перезагрузка».

24 октября 2018 г.

Статья поступила в раздел 2 («Научные исследования») сайта, подраздел 2.4. «Методология». В статье рассмотрены общие информационные и интеллектуальные процессы, имеющие место в технологии управления разрабатываемыми конфигурациями весьма сложных систем.