Часть 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 лет назад, слишком часто игнорируются на практике.
Однако, эти попытки стали приводить к такому разрастанию материала, которое рушило все объемные и временные рамки подготовки статьи. После ╚экспресс-экспертизы╩ ситуации я принял совет коллег ограничиться изложением лишь основных фактов и рекомендаций.
Все же, даже при таком упрощенном изложении стартовать с нуля нельзя. Вот основные положения, которые задают верный подход к проблеме.
Эти положения отражают принципы, описанные во многих классических источниках. Монографии [Гуд,Макол60], [Мейстер,Рабидо70], [Шнейдерман84], [Инмон,Фридман86] содержат фундаментальные основы для экспертирования систем. Надеюсь, что эти книги еще можно найти в технических библиотеках. Многие излагаемые ниже схемы и рекомендации получены интеграцией рекомендаций этих и ряда других источников, а также более чем 20-тилетнего опыта участия автора в экспертизах самого разного масштаба, опыта их организации и проведения. Некоторые другие рекомендации могут быть почерпнуты из более специальных работ, например, [Martin75], [Тиори,Фрай85], [Fagan86], [Paulk93], [Литвак96]. Придется ссылаться и на публикации, посвященные отдельным, частным вопросам, имеющим отношение к экспертированию ИС, их программного обеспечения, баз данных (БД) и СУБД.
Я поддерживаю известную точку зрения, в соответствии с которой экспертная деятельность должна опираться на сочетание двух положений:
В связи с этим подчеркну, что ниже излагается достаточно общая и ╚правильная╩, к тому же √ неоднократно проверенная на практике, но всего лишь одна, причем упрощенная для публикации схема действий.
Статья состоит из двух частей.
В первой части разбираются общие вопросы устройства экспертиз сложных систем.
Активно используются понятия и примеры, введенные в первой части, так что начинать чтение рекомендуется именно с нее.
Заключение содержит перечень вопросов, оставшихся за рамками статьи, и краткую характеристику ключевых вопросов, которые автор не мог не выделить особо.
[Гуд,Макол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.