НОВОЕ СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ: ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ И БИЗНЕС-РЕИНЖЕНИРИНГ

Редакционный совет журнала решил поместить эту статью в рубрику "Руководителю", рассчитывая, что материал статьи будет полезен, в первую очередь, руководителям проектов разработки современных информационных систем (ИС). Наблюдения показывают, что многие из классических методов проектирования ИС на практике забыты, а во многих случаях обнаруживаются как бы заново и считаются вполне современными. В то же время, условия, цели и инструменты проектирования радикально изменились. Недостаточно следить за изменениями инструментов проектирования, о которых много пишут в компьютерных журналах. Прежде всего надо учитывать изменения в целях и других условиях проектирования. Одно из таких изменений получило название BPR - business process reengineering или "реконструкция бизнес-процессов".

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

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

Статья публикуется в трех номерах журнала:

первая часть - о классических методах проектирования и их изменениях,

вторая - о бизнес-реинжиниринге и его связи с ИТ, о возникновении Нового Системного Проектирования,

третья - о новом системном проектировании, соединяющем ИТ и бизнес-реинжиниринг, его методах и организа ции.

Предлагается описание развития технологии проектирования информационных систем (ИС), в котором показывается:

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

В описании неизбежно использование исторического подхода: от 70-х годов настоящего времени к середине 90-х, - с элементами анализа и прогнозов на такое близкое будущее, как 2000-й год. Рассмотрение методов прошлого представляется более чем обоснованным, поскольку эти методы не только продолжают многими применяться, но, во многих случаях, считаются воплощением передовых ИТ.

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

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

Рисунок 1.

1. ВВЕДЕНИЕ: КАКОЕ СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ РАССМАТРИВАЕТСЯ

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

общеуправленческие ИС (MIS - management information system и EIS - executive information system),
специализированные ИС по отраслям производства, например, банковские учетные и управленческие системы, управление дискретным промышленным производством, системы профилактической и режимной деятельности органов МВД и др.,
специализированные ИС по видам деятельности, например, управление работой склада, система маркетинговых исследований, аналитическая система для работы на фондовом рынке и др.,
адаптивные универсальные ИС по применяемым методам обработки информации, например, электронный архив, корпоративная система управления процессом выполнения офисных работ, система статистических расчетов и др.

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

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

2. КЛАССИЧЕСКОЕ ПРОЕКТИРОВАНИЕ ИС

Как классическое рассматривается проектирование ИС для достаточно стабильных условий, что явно или неявно предполагалось в 70-е и в первой половине 80-х годов. Представительность соответствующих технологий, ориентация на наиболее массовую часть ИС, наличие не только теоретических оснований, но и промышленных методик и стандартов, использование этих методик в течение десятилетий - именно это позволяет называть описываемые методы классическими. Методы проектирования таких ИС в80-х годах были хорошо описаны и в зарубежной, и в отечественной литературе разных направлений: методические монографии, стандарты (ГОСТы, ANSI, ISO), учебники. Соответствующая организация работ рекомендовалась официально и во многих отраслях была широко применяема.

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

2.1. "КАСКАДНАЯ" ОРГАНИЗАЦИЯ РАБОТ

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

"запуск": организация основания для деятельности и запуск работ: приказ и/или договор о разработке автоматизированной системы, задание на выполнение работ (proposal for the development, agreement, mobilization),
"обследование": предпроектное обследование, общий анализ ситуации на предприятии, разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning, requirement definition),
"концепция, ТЗ": исследования требований предприятия и пользователей, выработка рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам (strategy planning, analysis, requirement specification, function description),
"эскизный проект": разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level design),
опытный вариант ИС: разработка упрощенного варианта, пилотного проекта будущей ИС (pilot-project, test development),
опытное использование пилот-проекта ИС, разработка исправлений и дополнений к ТЗ (test, corrected requirement specification),
"ТП": разработка технического проекта ИС (detailed analysis and design, test development),
"РП": разработка рабочей документации проекта (development, test, system implementation),
"ввод в действие": по другому - "внедрение" ИС (deployment, put into operation).

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

2.2. ПОЛОЖИТЕЛЬНЫЕ СТОРОНЫ "КАСКАДНОЙ" СХЕМЫ

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

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

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

СТАДИИ ПРОЕКТА	Организа- ционное	Методи- ческое	Информа- ционное	Програм- мное	Аппаратное
Запуск	+-
Обследование	+-	+-	+-
Концепция ТЗ	+-	+-	+-
Эскизный проект	+-	+-	+-	+-
ТП	+	++	+	+-	+-
РП	++	++	++	++	+
Ввод в действие	++	++	++	++	++
Символами "+", "+-" и "++" показаны примерные оценки доли наличия каждого компонента на каждой стадии.

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

2.3. НЕДОСТАТКИ КАСКАДНОЙ СХЕМЫ ПРОЕКТИРОВАНИЯ

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

НЕДОСТАТОК 1:"ОПОЗДАНИЕ"

Чаще всего в качестве основного недостатка называлось существенное запаздывание с получением результатов, которое имело несколько аспектов:

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

В [Мартин84] об этом сказано так: "В конце 1960-х годов появилась идея о создании полностью интегрированной базы данных (БД) организации. Она оказалась практически недостижимой". Правда, Дж. Мартин указывал в качестве причины практического краха идеи сложность и размер задачи. Мы будем далее анализировать еще одну, самую актуальную причину - динамику изменений в требованиях к БД и ИС в целом. Показательно, что в представлении очень многих руководителей и специалистов эта идея продолжает жить до сих пор!

НЕДОСТАТОК 2: "БЕСПОЛЕЗНОСТЬ"

Существовал и явным образом описывался в литературе еще один крупный недостаток разрабатываемых ИС, относящийся, скорее, к практике разработки ИС, чем к теории. И в зарубежной, и в отечественной литературе практики и ведущие аналитики оценивали проектирование ИС как очень часто ведущее к примитивной автоматизации (по сути - "механизации") существующих производственных действий работников. См. об этом также в [Мартин84]: "Анализ должен подвести руководство к вопросу о том, как надо изменить организацию..." и далее: "... легче идти по проторенной дорожке документирования сложившегося бумажного потока, чем определять насущные потребности бизнеса". В отечественной практике возник афоризм, описывающий эффект работы типичной АСУ, механически перемалывающей существующий бумажный поток: "Что на входе, то и на выходе". Ниже мы укажем, что современные аналитики до сих пор указывают на существование этого эффекта.

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

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

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

2.4. БОЛЕЕ РАЗВИТЫЕ ОРГАНИЗАЦИОННЫЕ ПОДХОДЫ

Рассмотрим их на примере совершенствования разработки ИС внутри компаний - разработчиков компьютерных систем. Они развивались в первую очередь - хотя и не только - для уменьшения первого недостатка: "опозданий".

2.3.1. СХЕМА НЕПРЕРЫВНОЙ РАЗРАБОТКИ

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

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

Picture 2.1
Рисунок 2.1

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

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

2.3.2. РАЗВИТИЕ СХЕМЫ ПРОДОЛЖАЮЩЕЙСЯ РАЗРАБОТКИ: СОВЕРШЕНСТВОВАНИЕ ЦИКЛИЧЕСКИХ ФОРМ ПРОЕКТИРОВАНИЯ

В 80-х годах использование принципа продолженной разработки для ускоренного поочередного внедрения отдельных программных комплексов - прикладных или общесистемных - стало развиваться в разных направлениях и получило несколько ходовых жаргонных названий, например - "быстрое прототипирование", rapid protoyping approach или "fast-track". В проектный цикл для этого дополнительно включались такие стадии:

разработка макета-прототипа фрагмента будущей ИС (rapid prototyping) совместно с будущим пользователем,
опробование макета-прототипа фрагмента будущей ИС, доработка прототипа до работающего фрагмента ИС (feedback, improved prototype design and development).

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

НЕДОСТАТКИ 3 и 4: "ЖЕСТКОСТЬ" и "ЗАКРЫТОСТЬ"

Рассмотренные усовершенствованные схемы проектирования претендовали и сейчас часто претендуют на получение и ввод в действие компонентов формально целостной в традиционном смысле ИС и последующей их стыковки в такую ИС.

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

Такая организация проектирования названа проектированием "сверху вниз" (не путать с одноименным стилем программирования). Упоминаемая функциональная иерархия - очень важный признак рассматриваемых подходов. Из-за определяющего влияния на процессы и результаты проектирования ИС иерархических структур для представления функций и данных в ИС применявшиеся подходы получили общее условное название "структурное проектирование". Привычность и доступность иерархических моделей были привлекательным фактором. В [Зиндер и др.83], основываясь на результатах сравнительных исследований, опубликованных к тому времени, и на собственных наблюдениях авторы формулировали: "... в подавляющем числе случаев пользователю естественней и проще представлять модели предметной области в иерархическом виде, а не в виде сетевых структур, что, очевидно, объясняется его постоянными контактами с иерархическими зависимостями реального мира". Однако жесткость иерархических структур ограничивает их пользу, и чем дальше, тем менее эти ограничения допустимы.

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

Одно из популярных в то время представлений архитектуры такой закрытой ИС показано на рис. 2.2, где:

компьютер конкретного типа (конкретной фирмы-производителя),
конкретная операционная система для данного типа компьютера,
СУБД для 1 и 2,
прикладные программы для 2 и 3: пакетные/диалоговые для фиксированных функций или языки нерегламентированных запросов,
пользователь-оператор, обученный именно для 2, 3 и 4
конечный пользователь: обучен и снабжен инструкциями для работы именно с 4 и 5.

Picture 2.2

Рисунок 2.2.
Модель-луковица закрытой ИС

НЕДОСТАТОК 5: "ТИПОВЫЕ ОРГСТРУКТУРЫ"

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

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

3. ДИСЦИПЛИНЫ СОВЕРШЕНСТВОВАНИЯ ПРОИЗВОДСТВА

Подходы к совершенствованию собственно процессов управления производством развивались параллельно и почти независимо от ИТ. Часто в них ИС и автоматизация вообще рассматривались в последнюю очередь.

3.1. ТРАНСФОРМАЦИЯ И НЕПРЕРЫВНОЕ УСОВЕРШЕНСТВОВАНИЕ БИЗНЕС-ПРОЦЕССОВ

В Японии, США и других странах, в различных отраслях пионером такого подхода считается Эдвардс Деминг. Он ввел в практику (см. [Деминг94]) подход "Непрерывное усовершенствование процессов" или CPI - Continious Process Improvement, заключающийся в организации работ, при которой:

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

Деминг начал вводить в практику этот подход в 40-е - 50-е годы в промышленном производстве. Несколько лет его работы консультантом в Японии привели к тому, что он считается одним из отцов "Японского чуда". Ключевой эффект состоял в следующем. Несколько талантливых японских инженеров обнаружили в литературе и подтвердили на практике, что при повышении качества продукции неизбежно происходит и увеличение производительности. (Одним из первоисточников идеи, как писал Деминг, были положения, изложенные ранее в [Шьюарт 31], однако, показательно, что т.н. "цикл Шьюарта" в Японии называют "циклом Деминга".) При этом Деминг указал, что эта трансформация экономики стала возможной после того, как соответствующие идеи превратились в японскую национальную идеологию на производстве.

Впоследствии стало очевидно, что разработанные Э. Демингом "14 принципов управления", подходят для реорганизации бизнес-процессов в любом производстве, включая отрасль услуг и обучения. Эти принципы очень близки принципам BPR. Большое значение имеет анализ отличий подхода Деминга от подхода BPR. Мы вернемся к этому вопросу во второй части статьи. Здесь отметим, что Деминг и во второй половине 80-х годов был очень осторожен в использовании компьютеров. Вполне учитывая возможную пользу от доступных рабочих станций и дешевых (по цене покупки) офисных, статистических и т.п. программ, он специально указывал: использование компьютеров может быть благом, но может быть и злом. Решающими факторами являются цели и подготовленность людей, культура управления вообще и управление движением к качеству в первую очередь.

3.2. ДРУГИЕ ДИСЦИПЛИНЫ. ХАРАКТЕРИСТИКА ПАРАЛЛЕЛЬНОСТИ

Из других дисциплин совершенствования производства упомянем только подход TQM (Total Quality Management), являющийся японским вариантом CPI Деминга, лучшие проявления отечественной школы НОТ и требования к организации такого совершенствования, базирующиеся на серии стандартов ISO 9000.

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

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

4. КЛАССИЧЕСКИЕ МЕТОДЫ ПРОЕКТИРОВАНИЯ ИС

4.1. МАСТЕРСКАЯ КЛАССИЧЕСКИХ МЕТОДОВ ПРОЕКТИРОВАНИЯ ИТ

Конец 70-х - начало 80-х годов - это время становления технологии интегрированных баз данных (БД) как одной из головных технологий в проектировании ИС. Был разработан и вошел в практику большой набор теоретически обоснованных методов: проектирование концептуальных и логических схем БД, организация физической среды хранения данных, планирование путей доступа к данным и др. Развивались методы проектирования функций: от методов формальной спецификации функций до структурного программирования и первых непроцедурных языков программирования четвертого поколения (4GL). Анализ функций (задач) предприятия также служил основой и в проектировании БД. Появились CASE-системы, ориентированные на формализацию информационных и функциональных требований к ИС и предназначенные для формального описания и бригадной разработки больших программных комплексов. Эти методы и инструменты, которые в идеале должны были бы соединяться с методами преобразований управления производством, составляли классическую Мастерскую ИТ. Правда, соединение этих методов в целостные технологии производилось эмпирически и не всегда.

В конце 70-х - середине 80-х годов и в нашей стране большое количество разработчиков успешно применяли методы разработки ИС и БД не только на интуитивно-ремесленном уровне, но и как элементы сложившейся дисциплины. Укажем на наиболее популярные из них, применявшиеся на первых стадиях проектирования и составлявших часть упоминавшейся "Мастерской ИТ".

Обследование, общий анализ ситуации на предприятии и разработка общего обоснования целесообразности создания ИС (feasibility stady, scope analysis, strategy stady and planning):

общий системный и ситуационный анализ текущего состояния и целей предприятия, его масштабов, возможности, стоимости и способов разработки ИС, решающей задачи, способствующие достижению целей предприятия, использование методов [Мартин84], структурного анализа [Росс84], ГОСТов на разработку АСУ и САПР,

"концепция, ТЗ": исследования требований предприятия и пользователей, выработка вариантов и рекомендаций по разработке ИС, разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам (strategy stady, analysis, requirement specification),

анализ критических факторов успеха и риска с использованием системного и ситуационного анализа,
обследование предприятия методами анализа документов, интервью, прямых наблюдений, хронометража и др. (большое количество методик: от SADT Д. Росса до ГОСТа по предпроектным исследованиям при разработке САПР),
определение соответствия существующей оргструктуры, функций, документов и др. целям предприятия,
проектирование более целесообразных и учитывающих создаваемую ИС оргструктуры, набора и иерархии функций ("задач"), видов документов и правил документооборота, вычленение предметных БД, определение взаимосвязей между ними,
разработка предложений по изменениям на предприятии, затрагивающим оргструктуру, документооборот и др.,
построение недетализированных моделей БД и функций ИС (с использованием диаграмм данных Ч. Бахмана, модификаций ER-модели П. Чена, функциональных моделей по стандартам IDEF0, по методике HIPO или др.),
сбор и описание детальных требований к составу данных и алгоритмам реализации функций (см., например, популярную [Атре83], а также [Хаббард84], [Тиори,Фрай85], также требования серий ГОСТ24 и ГОСТ36),

"эскизный проект": разработка архитектуры будущей ИС в рамках эскизного проекта (detailed analysis, high level design),

построение нормализованной реляционной или сетевой модели БД (методы получения нормальных форм Бойса-Кодда, четвертых и пятых нормальных форм, использование предложений комитета CODASYL),
определение принципов организации в ИС интерфейсов конечного пользователя (принципы эргономики, как, впрочем, и влияние компьютерной моды, переход от командного интерфейса к диалоговым режимам "вопрос-ответ", "управление через меню"),
определение модульной иерархии (верхние уровни) программного обеспечения ИС (модульное программирование, метод HIPO),
определение принципов организации аппаратного компьютерного комплекса, на базе которого должна функционировать ИС (расчеты физических параметров ИС: объемов БД, временных характеристик отдельных операций доступа к данным, целых функций и режимов в целом, организации компьютерных сетей, см. также [Тиори,Фрай85]),
определение основных оргмероприятий по созданию и вводу в действие ИС,
определение совокупности требований к приемке будущей ИС,
определение сроков, состава работ и их стоимости для последующих работ по ИС.

Существовал набор методов, которые применялись и на других этапах.

4.3. ОБ ИСПОЛЬЗОВАНИИ КЛАССИЧЕСКИХ МЕТОДОВ ПРОЕКТИРОВАНИЯ ИС В НАСТОЯЩЕЕ ВРЕМЯ

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

Некоторые из усовершенствований в компьютерной поддержке проектирования ИС начиная со второй половины 80-х годов:

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

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

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

5. КАЧЕСТВЕННЫЕ ИЗМЕНЕНИЯ В ИТ

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

5.1. ПОНЯТИЕ ОТКРЫТОЙ АРХИТЕКТУРЫ

Это понятие начало проникать в практику вместе со стандартами на аппаратуру и программным обеспечением компьютерных сетей и переносимым (мобильным) программным обеспечением СУБД и ОС.

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

Понятие переносимости прикладных программ относилось к возможности использовать один и тот же прикладной комплекс на разных компьютерах. Переносимость базировалась первоначально на наличии компилятора с одного языка высокого уровня на разных типах компьютеров: Фортран, затем - Си, Паскаль, при использовании варианта языка, соответствующего стандарту. Затем, с первой половины 80-х годов, предполагалось также наличие тождественных для пользователя и его прикладных программ СУБД на нескольких типах компьютеров. Пионерами в этой области были СУБД ORACLE и INGRES. Одновременно стал решаться вопрос переносимости баз данных.

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

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

5.2. ТРИ КАЧЕСТВЕННЫХ СКАЧКА В ИТ - ТРИ ВЕЛИКИХ ФЕНОМЕНА

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

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

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

5.3. ПОНЯТИЙНАЯ МОДЕЛЬ КАК МИНИМАЛЬНАЯ ИНТЕГРИРУЮЩАЯ МОДЕЛЬ

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

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

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

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

Эти и другие предпосылки (см., например, [Зиндер, Белоконь 89]) являлись основанием того, что единственным достаточно стабильным интегрирующим элементом современной ИС может являться не информационная, и тем более не функциональная модель предприятия, а только понятийная модель предметной области, да и то при условии ее постоянного пересмотра и обновления. Пассивные понятийные модели такого прикладного рода строились и представлялись в виде терминологических словарей и тезаурусов понятий. Такие словари строились как часть обеспечения ИС и содержали описания элементов информационных, функциональных, организационных и других моделей для ИС. Однако практически все использование таких моделей для проектирования и развития ИС приходилось и приходится делать вручную.

Активные понятийные модели разрабатывались не только для хранения описаний используемых понятий и связей между ними. Ставились цели динамически формировать новые суждения, определять тождество или сходство понятий, производить их интерпретацию вычислительного характера. К таким моделям относятся разные представления семантических сетей, некоторые специальные понятийные модели, например, [Zinder90]. Однако создание технологически полных механизмов такого рода оказалось очень сложной задачей. Для непосредственного использования в промышленных разработках ИС активные понятийные модели до последнего времени были непригодны.

В настоящее время слияние средств представления знаний с технологией обобщенных объектов и стандартизацией в области объектно-ориентированных представлений реально ведет на следующий, качественно новый уровень в технологии системного проектирования. В качестве одного из примеров укажем на систему СИНТЕЗ, см. [Калиниченко93].

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

ЗАКЛЮЧЕНИЕ ПЕРВОЙ ЧАСТИ

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

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

СПИСОК ЛИТЕРАТУРЫ К ПЕРВОЙ ЧАСТИ

[Атре 83] Атре Ш. Структурный подход к организации баз данных. - М.: "Финансы и статистика", 1983.

[Деминг94] Деминг В. Э. Выход из кризиса. - Тверь: "Альба", 1994.

[Зиндер и др. 83] Зиндер Е.З., Карапетян К.Г., Новиков А.И. Принципы разработки СОНЗ - унифицированного языка и программного комплекса обслуживания пользователей в интегрированной системе управления. - В кн. "Интегрированные автоматизированные системы управления", - М.: МДНТП, 1983.

[Зиндер, Белоконь 89] Зиндер Е.З., Бело-конь А.К. Персонализация информационных технологий и инструментальной поддержки в проектировании. //Tahkekeha elektroonika elementide projekteerimise ja kat- setamise numbrilised meetodid ja vahendid. Vabar. noup. ettek. teesid. K.II. - Tallinn: TTU, 1989.

[Калиниченко93] Калиниченко Л.А. СИНТЕЗ: язык определения, проектирования и программирования интероперабельных сред неоднородных информационных ресурсов. - М., ИПИ РАН, 1993.

[Мартин84] Мартин Дж. Планирование развития автоматизированных систем. - М.: "Финансы и статистика", 1984.

[Росс84] Росс Д. Структурный анализ (SA): язык для передачи понимания в кн. "Требования и спецификации в разработке программ". - М.: "МИР", 1984.

[Тиори,Фрай85] Тиори Т., Фрай Д. Проектирование структур баз данных. - М.: "МИР", 1985.

[Фокс85] Фокс Дж. Программное обеспечение и его разработка. - М.: "МИР", 1985.

[Хаббард84] Хаббард Дж. Автоматизированное проектирование баз данных. - М.: "МИР", 1984.

[Шьюарт80] Шьюарт У. А. Экономический контроль качества готовой продукции. Издания: Van Nostred, 1931; American Society for Quality Control, 1980.

[Zinder90] Zinder E.Z. PRIMET - The PeRsonal Information MetaTechnologies: from marketing to program implementation. //Общие проблемы информатики. III Международная конф. "Программное обеспечение ЭВМ" (ноябрь, Тверь, 1990) - Тверь: НПО ЦПС,1990

Продолжение в следующем номере