18c0693f

Классическое проектирование

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

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

Данная схема имеет свои положительные и отрицательные стороны применения. Положительные стороны применения:

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

СТАДИИ ПРОЕКТА

Организационное

Методическое

Информационное

Программное

Аппаратное

Запуск

+-





Обследование

+-

+-

+-



Концепция ТЗ

+-

+-

+-



Эскизный проект

+-

+-

+-

+-


ТП

+

++

+

+-

+-

РП

++

++

++

++

+

Ввод в действие

++

++

++

++

++


Символами "+", "+-" и "++" показаны примерные оценки доли наличия каждого компонента на каждой стадии


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

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

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

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

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

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

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

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

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

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

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

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

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






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

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

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

Классические методы проектирования ИС

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

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

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

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

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

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

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

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

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

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

Открытая архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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