Электронная версия. Опубликовано в "Руды и металлы", N1, 1994, с. 79 -89.

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

Автором создан программный комплекс GST (Geostatistical Software Tool) моделирования структур изменчивости, управляемой интерполяции и решения связанных задач, вероятно являющийся пока единственной отечественной специализированной программой, уровень тиража которой (на момент написания статьи 69 копий в 28 организациях при максимально возможном тираже 2-3 тысячи копий) позволяет говорить об экономической эффективности. Данная статья является попыткой изложить концептуальные основы, позволившие комплексу GST выйти на этот уровень. Рассматривается предметная область комплекса, но концептуальная основа легко поддается обобщению и на другие предметные области в геологии. Отметим, что не все построения, описанные в данной статье, реализованы, в том числе в комплексе GST. Проект распространяемой сегодня версии GST составлен более года назад, идет проектирование новой (четвертой) версии. Автор не считает, что опубликование ноу-хау может принести ему какой-либо ущерб, так как одним из главных следствий концепции является возможность замены на отечественном рынке на несколько ближайших лет конкуренции кооперацией.

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

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

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

Анализ имеющегося рынка предложения. В настоящее время на рынке имеется большое количество программных средств рассматриваемого назначения. Начнем с импортных программ, имеющих больший тираж, чем отечественные, которые рассмотрим с ними по аналогии с первыми. Полностью отвечают сформулированной предметной области DataMine, BluePACK, GEOPACK, GEOEAS, Geostatistical Toolbox, TechBASE, Rockworks и некоторые менее распространенные. Имеется также большое число средств, отвечающих предметной области только на первый взгляд. Классический примеро - пакет SURFER, который используется отечественными пользователями чрезвычайно широко, несмотря на полное отсутствие управления интерполяцией и механизмов оценивания объектов, отличных от точечных. По сути, пакеты типа SURFER есть средства полностью автоматической интерполяции, не имеющие отношения к рассматриваемому классу задач. Особняком стоят также геофизические системы, обычно имеющие всю атрибутику исследуемой предметной области, но только внешне. Так, у всех них есть средства исследования структур изменчивости, нет средств к их моделированию и реализации построенных моделей в процедурах интерполяции. Для геофизических программ это и не обязательно - потенциальные поля хорошо обрабатываются процедурами детерминированной интерполяции, действующими много быстрее управляемых процедур.

Отечественные разработки в большинстве своем не доведены до состояния коммерческого тиражируемого продукта и обычно существуют в 1-5 копиях, используемых только под авторским надзором. Большинство из них идет строго по следам SURFER-а, реже - по следам Geostatistical Toolbox (иногда, правда, с существенно развитой интерфейсной частью). Достаточно модным является также следование идее DataMine (интегрированные системы полного решения всех задач, возникающих на руднике), но устойчиво работающих отечественных систем этой ориентации пока нет. В качестве примера можно указать разработки Рощина-Тимохина (ВНИИХТ). Отечественные программы геофизического назначения отдельно рассматривать не будем, хотя среди них есть и неплохие - все, сказанное для импортных, относится к ним в полной мере.

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

1. Имеющиеся программные средства достаточно жестко делятся на два класса :

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

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

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

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

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

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

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

-  регулярная сменяемость версий в сочетании с гарантией льготного обновления (у отечественных средств поставлено лучше);

-  открытость для изучения статистики пользователей, статистики выявления и исправления ошибок, перспективных планов разработчика (встречается редко);

-  открытость интерфейсных средств и форматов входных и выходных данных.

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

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

Определяют эффективность системы следующие аспекты, являющиеся sine qua non:

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

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

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

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

Реально существует еще пятый аспект, сознательно выведенный из рассмотрения - сможет ли программное средство существовать без конфликта с системой государственной стандартизации геологоразведочных работ. Особую важность он приобретает именно для задач интерполяции/оценивания с выходом на подсчет запасов, но, к сожалению, он не поддается однозначному моделированию и сильно зависит от экономической политики государства. В разных странах он решается по-разному, а по какому пути пойдет Российская Федерация, пока не ясно. В любом случае стандартизация недетерминированных методик неоднозначна. Даже при полной поддержке ГКЗ РФ (которая сейчас наблюдается) это займет значительное время.

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

Представляется, что при описанных начальных условиях система до некоторых пределов способна к саморегуляции. Разрегуляция ее возможна как по внешним, так и по внутренним причинам. Внешними являются появление конкурирующих разработок или математических аппаратов, а внутренними могут быть потеря темпов развития (особенно часто по направлениям, не фигурирующим в обратной связи с пользователем - например, запоздание с подключением поддержки сетевых средств или интерфейсов к СУБД, выходящих на позиции стандарта de-facto), а также "естественное старение". Под последним понимается тот факт, что программная разработка в некоторый момент времени теряет возможность к эволюционному развитию и должна быть полностью переписана "с нуля". По опыту автора это происходит раз в 3-4 года и примерно соответствует сроку морального старения аппаратных средств. Разрегуляция наступает не мгновенно (исключая катастрофическую разрегуляцию, рассматриваемую ниже), имеет свои симптомы, и при своевременном принятии мер может быть остановлена.

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

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

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

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

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

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

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

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

Особенности, относящиеся к профессиональной среде пользователя:

-  данные дороги и их живучесть может быть обеспечена только применением в качестве среды постоянного хранения форматов баз данных, в поддержке которых в дальнейшем сомневаться не приходится (dBASE, PARADOX, ORACLE);

-  пользователь уже имеет на своем предприятии некоторую технологию хранения и обработки данных. В большинстве случаев это комплект из FOXPRO, SUPERCALC, STATGRAF, SURFER, AutoCAD. Тем самым имеются введенные в технологию функциональные границы, которые следует поддерживать. В нашем случае оптимально проведение функциональных границ средства по внешним границам связки SUPERCALC+STATGRAF+SURFER. При этом следует оставить возможность пользования любым средством из этой связки в его функциональных границах;

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

Не следует исключать возможности появления пользователя, описываемого моделью частично. Практика развитых стран знает многочисленные случаи отсутствия на горнодобывающих предприятиях собственной геологической службы с решением задач разведки силами консалтинговых центров. Легко видеть, тем не менее, что вышеизложенная модель в большой степени, хотя и не полностью, описывает и пользователя в таком центре. Отметим, что подобные центры могут быть и непосредственно при фирме-разработчике средства (как, например, DataMine в Великобритании или ВНИИГЕОСИСТЕМ в России), но пользователи на таких "фирменных" центрах уже хотя бы за счет неформального общения с разработчиками предложенной моделью не описываются.

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

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

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

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

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

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

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

Удачный в этом смысле программный комплекс GST имеет следующие функциональные границы и области перекрытия:

-  переход от общей базы данных, которая может быть либо dBASE-подобной, либо основанной на ASCII-файлах, либо на "Архиве ТОС" (разработка ВНИИГеосистем), к среде моделирования изменчивости и решения интерполяционных задач. Переход осуществляется настраиваемым экспортом-импортом данных с возможностью производить выборки. Возможно описание стандартных выборок, отменяющее необходимость ручного управления экспортом-импортом. Область перекрытия на этом переходе представлена редактором данных, позволяющим кроме собственно редактирования производить сортировки, слияния, алгебраические преобразования, ввод и удаление проб и признаков, перевод массива в другие системы координат. Тем самым, встроенный редактор не обеспечивает всех операций, положенных СУБД, но поддерживает полный процесс подготовки данных с самыми насущными удобствами;

-  переход от среды решения задач к среде САПР, базе данных общего назначения, оптимизаторам стратегии отработки. Осуществляется комплектом настраиваемых программ-экспортеров результирующих данных в форматы ASCII, dBASE (таблицы), AutoCAD (структурированная векторная графика). Область перекрытия здесь очевидна - выборки, настройки масштаба, уровней изолиний, черновая печать на принтере и др.;

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

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

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

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

Отметим, что кроме возможности обмена данными со смежными средствами необходимо предусмотреть прямой обмен данными хотя бы с одной прямо конкурирующей программой. Без этого пользователь, лишенный возможности сравнения, в дальнейшем заведомо будет потерян. Так, комплекс GST имеет предопределенный интерфейс обмена с Geostatistical Toolbox, GEOEAS, SURFER, а также с программами подсчета запасов статистическими и геометрическими методами, разработанными в ВИМСе и ЦНИГРИ.

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

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

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

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

-  размер программного средства на диске должен исходить из реальных параметров компьютеров у типичного пользователя и должен учитывать наличие на том же компьютере двух - трех смежных средств, СУБД, САПР, двух текстовых редакторов и двух - трех пакетов иного назначения. Так, на данный момент разумный предел размеров для рассматриваемых программных средств - около 2 Мбайт.

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

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

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

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

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

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

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

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

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

2. Средний слой составляют близкие единомышленники главного программиста, без которых проект нежизнеспособен (0-3 человека). За пределы этого слоя не могут выпускаться модули, определяющие пользовательские качества разработки, а именно интерфейсы пользователя, связь с базами данных, экспертная система сопровождения, обработчики особых ситуаций и ошибок, а также ключевые математические модули, определяющие методологическую уникальность проекта. Отметим, что попытки обойтись без этого слоя, воспользовавшись готовыми средствами, не катастрофичны, хотя и резко уменьшают шансы проекта на выживание. Долго живут только программы, имеющие собственное лицо, определяемое отнюдь не заставкой на экране, а мелкими особенностями интерфейса, цветовой гаммой, структурой меню, нестандартными операциями во встроенной СУБД и др.

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

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

Выбор языка программирования имеет варианты. Статистика автора показывает, что малопопулярный ныне FORTRAN (компиляторы Microsoft или NDP) все же строит более быстрые программы, чем остальные распространенные компиляторы, что для задач интерполяции и оценивания весьма актуально, но разница с другими профессиональными компиляторами не столь велика, чтобы быть критичной. Собственно технология программирования на нижнем уровне (модули) может быть самой разнообразной, а на верхнем подчиняется основным принципам кинорежиссуры :

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

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

Технология поддержки и развития программного средства рассматриваемого класса также имеет несколько существенных особенностей :

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

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

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

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

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

6. Стратегия взаимодействия со смежными программными средствами должна проектироваться особо по двум направлениям. Взаимодействие со средствами, имеющими перспективы стать стандартом de-facto, должно быть обеспечено с опережением. Взаимодействие со средствами, только входящими в рынок, но интересными с точки зрения разработчиков, более сложно. Если такое взаимодействие видится эффективным, нельзя его коммерциализировать - пользователь примет совет по покупке этого средства только в случае доказуемости отсутствия дилерского соглашения. Выгоду следует искать только в улучшении пользовательских характеристик обоих средств при их совместном использовании. При болеее тесной интеграции с таким средством нужна осторожность. Интеграция программных средств проявляет эмерджентное свойство новой системы, заключающееся в том, что результирующая система подчиняется не армейскому правилу "ход эскадры определяется наиболее тихоходным судном", а этнографическому закону "при смешении нескольких этносов уровень культуры смеси временно отбрасывается на уровень ниже минимального из исходных". Уровень пользовательских характеристик объединения при этом резко падает, и если оба средства не имеют "запаса прочности", может наступить крах.

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

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

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

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

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

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