1981), а более "...мягким способом" (Checkland and Scholes, 1990). В соответствии с этим мы определили два основных вопроса, которые необходимо учитывать при проектировании успешных (медицинских) информационных систем:

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

- мы должны уметь ответить на два "основных вопроса" :

Вопрос 1.

какую из множества возможных компьютерных информационных систем (ИС) необходимо спроектировать? и

Вопрос 2.

Как спроектировать выбранный вариант?

Эти два вопроса кажутся вполне разумными и естественными в большинстве ситуаций проектирования ИБ, но на них очень редко дается явный ответ. В тех ситуациях, когда они появляются, они сводятся к форме Какую методологию использовать для проектирования данной ИС? Но, к сожалению, простой выбор "лучшей" методологии проектирования ИС очень труден, если вообще возможен (Kokol, 1993; 1994) (проектирование ИС происходит в двух контекстах: во-первых, в контексте, в котором работает проектировщик, и, во-вторых, в контексте, создаваемом самим проектированием. Не существует однозначно хороших или плохих парадигм проектирования, и существует слишком много различных парадигм проектирования ИБ, чтобы просто выбрать одну из них. Срочно нужны процессы, ориентированные на качество ПО, и способ их проектирования). Мы утверждаем, что для успешного проектирования ИБ необходимо сначала спроектировать (правда, метадизайн в некоторых ситуациях можно свести к выбору, но, тем не менее, этот выбор осуществляется системно) соответствующую парадигму проектирования и называем эту деятельность двухуровневым проектированием (Kokol 1993, 1994).

 

Двухуровневая конструкция

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

 

МЕТАМЕТ

MetaMet (Kokol, 1994) - это конкретная реализация двухуровневого проектирования, основанная на следующих предложенных определениях процесса проектирования ИБ:

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

В соответствии с вышеизложенным использование MetaMet определяется как:

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

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

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

В соответствии с вышеизложенным, метапарадигма должна быть плюралистичной, системной, рекурсивно адаптируемой (рекурсивная адаптивность утверждает, что метапарадигма должна быть итеративной обучающейся системой, накапливающей новые знания о метадизайне, проектировании ИС и смежных областях) и многомерной, а также состоять из фреймворка, теории и методологии. В настоящих приложениях в качестве основы выбрана идея процесса, в качестве методологии - методика "мягких систем" (Checkland and Scholes, 1990), а в качестве теории - формализация процесса (метамоделирование) (Kokol, 1993).

 

COCIDINIS

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

 

Разработка COCIDINIS

В соответствии с конкретной проектной ситуацией, возникшей при проектировании КОСИДИНИС, мы построили новую парадигму проектирования, названную расширенной парадигмой структурированного моделирования на электронных таблицах (РПСМП), которая базируется на следующем определении корня проектирования:

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

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