Часть 1. Устройство экспертиз и экспертирования
Часть 2. Экспертизы СУБД
Заключение

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

Совсем другое дело - СУБД. Когда вы хотите узнать эксплуатационные параметры СУБД ХХХХХ, вы слышите, что эта «машина» может взлетать с любой взлетной полосы не короче 64 Мбайт (но лучше - 512), а за какое именно время она «доставит» вам балансовый отчет или с какими параметрами эффективности будет обслуживать 20 или 200 одновременно «летящих» пассажиров-клиентов - это чаще всего загадка. «Это зависит» - говорят вам, и дальнейший разговор часто сводится к предложениям поставить натурный эксперимент. А ведь вы готовы сообщить все, от чего, казалось бы, «это зависит»: исчерпывающее описание базы данных, частоту обращений «пассажиров» и их запросы, параметры компьютера и ОС.

Конечно, сравнение СУБД с самолетом – ограниченная аналогия. Но в рамках этих ограничений она позволит яснее формулировать цели оценивания СУБД. В конце концов, СУБД вместе с ее платформой и базами данных – это большой, но всего лишь конечный автомат, вычислять поведение которого, казалось бы, можно абсолютно точно. Тем не менее, в «техническом паспорте» этих механизмов нет значений многих характеристик, которые нужны для уверенного планирования работы ИС традиционным для инженерного проектирования расчетным путем. Получается, что кулинария с ее подробными поваренными книгами – гораздо более точное в инженерном смысле дело, чем применение СУБД для создания ИС.

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

И это – если вы всего лишь хотите заранее оценить последствия возможного применения данной СУБД для конкретного проекта. Но мы знаем и более «глобальные» задачи: выбрать для конкретного проекта одну СУБД из нескольких, или произвести выбор СУБД для всей вашей организации, для множества ее известных и еще неизвестных проектов.

Актуальность

Вопрос оценки СУБД время от времени получает дополнительную остроту. Недавно MS SQL Server вышел в сектор средних и более чем средних баз данных и активно конкурирует с «большими» СУБД. С другой стороны, компания Dataquest сообщила (см. Computerworld Россия, №12 за 1999 год) о том, что IBM восстановила лидерство, обогнав Oracle по продажам программных продуктов обеспечения баз данных. Все это происходит на фоне полемики фирм-разработчиков СУБД, в которой они трактуют по разному одни и те же достижения (см. например, www.oracle.com/database/showdown/ c мнениями Oracle о достижениях в MS SQL Server).

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

Решение проектировщика о выборе СУБД и о ее применимости для проекта стало более сложным и ответственным.

Экспертизы: от «бытовой» к профессиональной

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

Очень часто дело пробуют свести к проведению «экспертизы на бытовом уровне».

Эксперта спрашивают: «Скажите, СУБД ХХХХХ потянет билинговую систему в нашей телекоммуникационной компании?» Он отвечает: «Конечно потянет» и страхуется, говоря, что во всемирно известной фирме YYY-Telecom эта СУБД успешно выполняет такие функции на мэйнфрейме. Вы говорите, что это явно неподъемно да и не нужно для вас, и спрашиваете, а не потянет ли на Wintel-сервере. Эксперт сообщает, что вряд ли, но что «это зависит», и вы возвращаетесь к пройденному. Или же он говорит, что рекомендовал бы СУБД ZZZZZ на кластере из двух приличных RISC-серверов, от чего ситуация не облегчается. Существенно, что в любом варианте проведения такой «бытовой экспертизы» эксперт не рискует ничем, произнося самые разные слова (кроме заведомо абсурдных). Ведь всем очевидна невозможность серьезной оценки в таких условиях.

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

Однако, предположим, что этот путь пройден, и экспертизу наконец-то можно планировать и проводить. Что и как делать, чтобы оценки были адекватными и объективными? И как быть, если вам нужно оценивать не СУБД, а ИС в целом?

Предпосылки

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

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

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

Контекст статьи и ее предмета

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

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

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

  1. Самое общее положение: наша деятельность в большинстве случаев осуществляется в контекстах систем «человек-машина», отличительным свойством которых является наличие собственной цели такой системы.
  2. Как только мы должны учитывать не только персонал, обеспечивающий эксплуатацию системы, но и ее пользователей, преследующих с помощью ИС свои профессиональные цели, мы вынужденны говорить уже не об ИС, а об объемлющей ее АС «человек-машина», например:
    • департамент финансового управления с подсистемами бухучета и контроллинга,
    • отдел главного конструктора со справочными системами и САПР,
    • служба управления перевозками с подсистемами составления расписаний, продажи билетов и анализа пассажиропотоков,
    • автоматизированное заводоуправление или предприятие в целом.
  3. Определяющим элементом любой экспертизы является ее цель, которая в нашем случае тесно связана с целью АС – системы, в которую входит или с которой связан оцениваемый компонент (подсистема, ИС, СУБД, процесс проектирования). При одном и том же объекте изменение цели экспертизы может приводить не только к изменению необходимой точности измерений и методов оценивания, но к полному изменению всего устройства экспертизы.
  4. Цели людей в ИС (эксплуатационный персонал) или в проекте разработки ИС (разработчики) никогда не совпадают полностью, а часто очень сильно отклоняются от целей той АС, для которой ИС предназначается.
  5. Даже в случае таких сильно «машинных» систем как СУБД их качества могут быть оценены только в связи с тем, насколько эффективно они помогают конкретным людям достигать своих целей.
  6. Еще одним важнейшим фактором, задающим контекст экспертизы, является конкретная точка и ситуация в цикле проектирования ИС или в ее полном жизненном цикле.

Эти положения отражают принципы, описанные во многих классических источниках. Монографии [Гуд,Макол60], [Мейстер,Рабидо70], [Шнейдерман84], [Инмон,Фридман86] содержат фундаментальные основы для экспертирования систем. Надеюсь, что эти книги еще можно найти в технических библиотеках. Многие излагаемые ниже схемы и рекомендации получены интеграцией рекомендаций этих и ряда других источников, а также более чем 20-тилетнего опыта участия автора в экспертизах самого разного масштаба, опыта их организации и проведения. Некоторые другие рекомендации могут быть почерпнуты из более специальных работ, например, [Martin75], [Тиори,Фрай85], [Fagan86], [Paulk93], [Литвак96]. Придется ссылаться и на публикации, посвященные отдельным, частным вопросам, имеющим отношение к экспертированию ИС, их программного обеспечения, баз данных (БД) и СУБД.

Я поддерживаю известную точку зрения, в соответствии с которой экспертная деятельность должна опираться на сочетание двух положений:

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

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

План изложения

Статья состоит из двух частей.

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

  • Приводятся стартовые определения, таксономия и схема организации экспертиз. Показывается привязка экспертиз к жизненному циклу системы. Достаточно подробно обсуждаются основополагающие вопросы определения цели и вопросов экспертизы. Определяется пространство видов экспертиз и взаимовлияние вида и вопросов экспертизы.
  • Изложение ведется с привлечением двух простых условных примеров, связанных с задачей выбора СУБД для проекта. Разбираются постоянно острые вопросы о влиянии закрытости и независимости экспертизы на ее результаты.
  • Определяются другие компоненты экспертиз и намечается их общий ход.
  • Во второй части разбираются вопросы выполнения экспертиз СУБД.
  • Сначала разбирается проблема выбора СУБД и особенности экспертиз, поддерживающих решение о выборе. Различаются «глобальный» выбор СУБД как единственной для организации и сравнение СУБД для конкретного проекта. Как один из определяющих рассматривается классический вопрос о преодолении конформизма и конъюнктурности экспертов.
  • Рассматриваются четыре группы критериев оценки СУБД и уровни применения этих критериев. Вводится понятие «паспортных» характеристик СУБД. На примере ограничений на структуру базы данных ставится (а далее разбирается) вопрос о необходимости и вариантах ограничений на предмет экспертизы.
  • Далее – как предмет оценки – определяются и разбираются временные характеристики (ВХ) СУБД. Вводится четыре вида таких оценок. Показывается польза и ограниченность каждого вида. На примерах экспертиз ВХ, выполнявшихся для самых разных СУБД за последние более чем 15 лет, показываются возможности и проблемы использования т.н. элементарных ВХ – как паспортных, так и для конкретного проекта.
  • С использованием опыта экспертиз реляционных СУБД разбираются проблемы в определении и использовании ВХ в настоящее время, показываются области применимости элементарных ВХ. Этот разбор заканчивается возвратом к одному из примеров, рассматривавшемуся в первой части статьи.
  • Вторая часть заканчивается сведениями о политических и культурологических факторах и критериях оценки, которые часто играют решающую роль в выборе СУБД, хотя редко подвергаются полноценному разбору.

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

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

Литература

[Гуд,Макол60] Гуд Г. Х., Макол Р.Э., Системотехника. – М.: «Советское радио», 1962.
[Гусаров,Зиндер80] Гусаров А.Е., Зиндер Е.З. Пакет программ ТЕСТЕР для повышения качества физического проектирования баз данных. – В кн. Ускорение внедрения типовых комплексов программ для ЕС ЭВМ и повышение качества рабочего проектирования: Тез. докл. н.-техн. семин. – М.: 1980.
[Зиндер, Ципес83] Зиндер Е.З., Ципес Г.Л. Применение СУБД ОКА для хранения и обработки сильно нагруженных ориентированных графов большой размерности.//УСиМ, N.2, 1983.
[Зиндер84] Зиндер Е.З., Смеси операций для оценки временной эффективности СУБД нереляционного типа. В кн. Обработка данных в автоматизированных системах. – М.: МДНТП, 1984.
[Зиндер95а] Зиндер Е.З. Критерии выбора современной СУБД как объекта инвестиций для развития предприятия. // СУБД, N.1, 1995.
[Зиндер95б] Зиндер Е.З. Тщательная классификация лучше списка значений. // СУБД, N.3, 1995.
[Зиндер96а] Зиндер Е.З. Бизнес-реинжениринг и технологии системного проектирования (учебное пособие). 1-я версия. – М.: МГУ-ЦИТ, 1996.
[Зиндер96б] Зиндер Е.З. Новое системное проектирование: информационные технологии и бизнес-реинжиниринг. // СУБД. 1995, N.4, 1996, No1-2.
[Зиндер97] Зиндер Е.З. Соотнесение и использование стандартов организации жизненных циклов систем. // СУБД, N.3, 1997.
[Зиндер99] Зиндер Е.З. На переломе. //Computerworld Россия, N.8, 1999.
[Инмон,Фридман86] Инмон У., Фридман Л. Методология экспертой оценки проектых решений для систем с базами данных. – М.: «Финансы и статистика», 1986.
[Кузнецов99] Кузнецов С.Д. Гиганты среднего масштаба.//Computerworld Россия, No12, 1999.
[Литвак96] Литвак Б.Г. Экспертные оценки и принятие решений. – М.: «Патент», 1996.
[Мейстер,Рабидо70] Мейстер Д., Рабидо Дж. Инженерно-психологическая оценка при разработке систем управления. – М.: «Советское радио», 1970.
[Пржиялковкий98] Пржиялковский В.В. Критерии, которые мы выбираем: поучительные итоги одного опроса. //Computerworld Россия, N.38, 1998.
[Шнейдерман84] Шнейдерман Б. Психология программирования. – М., «Радио и связь», 1984.
[СЭС89] Советский энциклопедический словарь. – М.: «Советская энциклопедия», 1989.
[Тиори,Фрай85] Тиори Т., Фрай Дж. Проектирование структур баз данных (в двух кн.). Книга 2. – М.: Мир, 1985.
[Fagan86] Fagan M. Advances in Software Inspections.// IEEE Transactions on Software Engineering. v.12, n.7, 1986.
[Martin75] Martin J. Accuracy, security and privacy in computer systems. – NJ.: Prentice-Hall, 1975.
[Paulk93] Paulk M.C., Weber C.V., Garcia S., Chrissis M.B. and Bush M. Key Practices of the Capability Maturity Model, Version 1.1.// Software Engineering Institute, CMU/SEI-93-TR-25, February 1993.

Евгений Захарович Зиндер, аналитическое и конструкторское бюро «Группа 24», тел. (095)155-4949, E-mail: ezinder@osp.ru.