Гринберг А.С., Король И.А. Информационный менеджмент

Подождите немного. Документ загружается.

130 Часть II. Функционирование компонентов информационного общества

Недостаток

(опоздание).

Чаще всего в качестве основного

недостатка называлось существенное запаздьшание с получением

результатов, имевшее несколько аспектов:

• согласование результатов с пользователем производилось

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

этапа работ; это приводило к тому, что разработчики делали

не ту ИС, которую хотели заказчик или тем более пользова-

тели, а ту, которую представили себе проектировщики-ана-

литики, затем

—

программисты;

• модели автоматизируемого объекта, отвечающие критериям

внутренней согласованности и полноты, для мало-мальски

крупного проекта ИС устаревали (т.е. переставали отвечать

реальным внешним требованиям) вскоре после их утверж-

дения, а иногда и одновременно с ним; это относится и к

функциональной модели, и к информационной, и к проек-

там интерфейса пользователя, и к инструкциям персоналу;

• попытки довести до внедрения проект, выполняющийся в

такой манере, заставляли или искажать требования к ИС, или

превышать сроки и смету

разработки,

или делать

и то и

другое.

Недостаток

(бесполезность).

Существовал и явным образом

описывался в литературе еще один крупный недостаток разраба-

тываемых ИС, относящийся скорее к практике разработки ИС,

чем к

теории.

И в зарубежной, и в отечественной литературе прак-

тики и ведущие аналитики оценивали проектирование ИС как

очень часто ведущее к примитивной автоматизации (по сути —

механизации)

существующих производственных действий работ-

ников. См. об этом также в [45]:

Анализ должен подвести руководство к вопросу о том,

как надо изменить организацию...

и далее:

...легче идти по проторенной дорожке документирова-

ния сложившегося бумажного потока, чем определять на-

сущные потребности бизнеса.

В отечественной практике возник афоризм, описывающий

эффект работы типичной АСУ, механически перемалывающей

существующий бумажный поток: «Что на входе, то и на выходе».

Ниже укажем, что современные аналитики до сих пор указывают

на существование этого эффекта.

Глава 5. Проектирование корпоративных информационных систем 131

Как альтернатива такому подходу требовалось получение с

помощью ИС качественно новых результатов, позволяющих осу-

ществлять оптимальное управление производством в целом, ди-

намически менять управление производственными процессами на

предприятии, принимать лучшие управленческие решения, встра-

ивать контроль качества и рациональное управление внутрь про-

изводственных

процессов,

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

ными коллективами.

Такой подход рекомендовалось осуществлять всегда, но он

встречал скрытое и явное сопротивление работников на предпри-

ятиях. Это было и является в настоящее время проблемой во всех

странах. Такой подход полностью отвечал бы определениям ки-

бернетики по Н. Винеру, но был очень редко достижим.

Вместе с тем в начале 80-х годов XX в. большинству проекти-

ровщиков ИС казалось, что имеющиеся модельные и организаци-

онные методы проектирования, а также поддерживающие их про-

граммные средства составляют законченную дисциплину, которая

может совершенствоваться, но уже позволяет, в общем, успешно

планировать и осуществлять разработки больших ИС.

Более развитые организационные подходы. Они развивались, в

первую очередь, хотя и не только, для уменьшения первого недо-

стс.

ка: «опозданий».

Схема непрерывной

разработки.

Примером может служить

подход, который руководители больших проектов IBM в 70-х

—

80-х годах прошлого столетия называли «Продолжающейся разра-

боткой». Характеризующей особенностью такого подхода стал не-

прерывный процесс разработки и развития большой ИС с плани-

руемыми точками передачи в эксплуатацию новых версий и но-

вых функциональных блоков (подсистем, задач) и встроенными в

процесс постоянно осуществляемыми процедурами экспертизы

качества, работоспособности и др.

Содержательно этот подход описан в [60]. Схема проектного

цикла при продолжающемся проектировании, совпадающая

цик-

лом жизни системы, приведена на рис. 5.1. В верхней части того

же рисунка представлена более распространенная схема, состав-

ленная также на основе [60].

Большое внимание уделялось организации процесса проекти-

рования. Выделим положение, в соответствии с которым встроен-

ные в процесс экспертизы должны были, в частности, служить

тем средством обратной связи, основываясь на котором можно

132 Часть II, Функционирование компонентов информационного общества

было бы и получать подтверждение пользователя и совершенство-

вать сам процесс разработки,

Разработка Ввод

действие Использование

?!(разрав в ^Ч-

управлении) ^ч» Сощюаояиеяне

Раапаботкя

Ввоя в

Продолжение Ввод в Продолжение

действие разработки действие разработки

V V

^^Использование ^W

Использование

Рис.

5,1. Схема непрерывной разработки

Существенно, что процесс системного проектирования начал по-

лучать спиральный характер, при котором каждый следующий виток

служил развитию спроектированной на предыдущих витках и уже

функционирующей системы. Один виток спирали при этом представ-

лял собой законченный проектный цикл по типу каскадной схемы.

Схема циклической разработки. В 80-х годах использование

принципа продолженной разработки для ускоренного поочеред-

ного внедрения отдельных программных комплексов — приклад-

ных или общесистемных — стало развиваться в разных направле-

ниях и получило несколько ходовых жаргонных названий, напри-

мер «быстрое прототипирование» (rapid prototyping approach или

fast-track). В проектный цикл для этого дополнительно включа-

лись такие стадии:

• разработка макета-прототипа фрагмента будущей ИС (rapid

prototyping) совместно с будущим пользователем;

• опробование макета-прототипа фрагмента будущей ИС, до-

работка прототипа до работающего фрагмента ИС (feedback,

improved prototype design and development).

Однако применение таких методов наряду с быстрым эффек-

том давало снижение управляемости проектом в целом и стыкуе-

мости различных фрагментов ИС.

Недостаток 3 и 4

{жесткость

и закрытость). Рассмотренные

усовершенствованные схемы проектирования претендовали и сей-

Глава 5, Проектирование корпоративных информационных систем 133

час часто претендуют на получение и ввод в действие компонен-

тов формально целостной в традиционном смысле ИС и после-

дующей их стыковки в такую ИС.

Для планирования формально целостной ИС рекомендовалось

на стадии обследования вначале определять укрупненные функ-

ции системы, затем детализировать их. По мере реализации фраг-

ментов ИС предполагалось использовать детальные описания функ-

ций соответствующего фрагмента.

Такая организация проектирования названа проектированием

«сверху вниз»

(не путать с одноименным стилем программирова-

ния).

Упоминаемая функциональная иерархия — очень важный

признак рассматриваемых подходов. Из-за определяющего влия-

ния на процессы и результаты проектирования ИС иерархических

структур для представления функций и данных в ИС применяв-

шиеся подходы получили общее условное название

—

«структур-

ное

проектирование».

Привычность и доступность иерархических

моделей были привлекательным фактором. В [34], основываясь на

результатах сравнительных исследований, опубликованных к тому

времени, и на собственных наблюдениях, авторы формулировали:

... в

подавляющем

числе случаев

пользователю естествен-

ней и проще представлять модели предметной области в

иерархическом виде, а не в виде сетевых структур, что, оче-

видно, объясняется его постоянными контактами с иерар-

хическими зависимостями реального мира.

Однако

жесткость

иерархических структур ограничивает их

пользу, и чем дальше, тем менее эти ограничения допустимы.

Не только жесткость моделей, но и использование фирменных

(«патентованных») архитектур используемых компьютеров, опе-

рационных систем и систем управления базами данных приводи-

ло к отрицательным результатам при возникновении неизбежной

необходимости развития ИС. Эти недостатки получили оценку

как недостатки

закрытых

систем: закрытые ИС было трудно или

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

но стыковать с другими системами.

Одно из популярных в то время представлений архитектуры

такой закрытой ИС показано на рис. 5.2, где:

компьютер конкретного типа (конкретной фирмы-произво-

дителя);

конкретная операционная система для данного типа компь-

ютера;

134 Часть II. Функционирование компонентов информационного общества

3) СУБД для 1 и 2;

прикладные программы для 2 и 3: пакетные (диалоговые)

для фиксированных функций или языки нерегламентированных

запросов;

пользователь-оператор, обученный именно для 2, 3 и 4;

конечный пользователь: обучен и снабжен инструкциями для

работы именно с 4 и 5.

6. Конечный пользователь

Рис.

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

Недостаток

(типовые

оргструктуры).

Потенциальная возмож-

ность и необходимость применения оргмероприятий для построе-

ния ИС (или АСУ), меняющих оргструктуры повышения эффек-

тивности работы предприятия в отечественных условиях, практи-

чески не использовалась. Для каждого предприятия, его отделе-

ния или отдела существовали так называемые типовые оргштат-

ные структуры, расписания и положения. Для того чтобы произ-

вести изменение в этой области, чаще всего нужно было решение

соответствующего министерства, поэтому в большинстве случаев

оргструктура оставалась неизменной, а ИС повторяла те функ-

ции, которые ранее выполнялись вручную.

Глава 5. Проектирование корпоративных информационных систем 135

Прежде чем перейти к характеристикам методов, соответству-

ющих тем или иным стадиям классического системного проекти-

рования, опишем наблюдавшуюся в тот же период ситуацию с

организацией совершенствования управления производством, ко-

торая по большому счету всегда должна была быть целью проек-

тирования ИС.

Классические методы проектирования. Конец 70-х — начало

80-х годов — это время становления технологии интегрирован-

ных баз данных как одной из головных технологий в проектиро-

вании ИС. Был разработан и вошел в практику большой набор

теоретически обоснованных методов: проектирование концепту-

альных и логических схем БД, организация физической среды

хранения данных, планирование путей доступа к данным и др.

Развивались методы проектирования функций: от методов фор-

мальной спецификации функций до структурного программиро-

вания и первых непроцедурных языков программирования чет-

вертого поколения (4GL). Анализ функций (задач) предприятия

также служил основой и в проектировании БД. Появились CASE-

системы, ориентированные на формализацию информационных

и функциональных требований к ИС и предназначенные для

формального описания и бригадной разработки больших про-

граммных комплексов.

В конце 70-х

—

середине 80-х годов XX в. и в нашей стране

большое количество разработчиков успешно применяли методы

разработки ИС и БД не только на интуитивно-ремесленном уров-

не,

но и как элементы сложившейся дисциплины. Укажем на наи-

более популярные из них, применявшиеся на первых стадиях про-

ектирования.

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

общий анализ ситуации

на

предприятии

разра-

ботка общего обоснования целесообразности создания

ИС (feasibility

stady, scope analysis, strategy stady and planning):

общий системный и ситуационный анализ текущего состоя-

ния и целей предприятия, его масштабов, возможности, стоимос-

ти и способов разработки ИС, решающей задачи, способствую-

щие достижению целей предприятия; использование методов [45],

структурного анализа [53], ГОСТов на разработку АСУ и САПР.

«Концепция,

ТЗ»:

исследования требований предприятия и

пользо-

вателей,

выработка вариантов

рекомендаций по разработке

ИС,

разработка

ТЗ на

проектирование

ИС в

целом

ЧТЗ

по

подсисте-

мам (strategy stady, analysis, requirement specification):

136 Часть II. Функционирование компонентов информационного общества

анализ критических факторов успеха и риска с использова-

нием системного и ситуационного анализа;

обследование предприятия методами анализа документов,

интервью, прямых наблюдений, хронометража и др. (большое ко-

личество методик: от SADT

Д.

Росса до ГОСТа по предпроектным

исследованиям при разработке САПР);

определение соответствия существующей оргструктуры,

функций, документов и других целям предприятия;

проектирование более целесообразных и учитывающих со-

здаваемую ИС оргструктуры, набора и иерархии функций («за-

дач»),

видов документов и правил документооборота, вычленение

предметных БД, определение взаимосвязей между ними;

разработка предложений по изменениям на предприятии,

затрагивающим оргструктуру, документооборот и др.;

построение недетализированных моделей БД и функций ИС

(с использованием диаграмм данных Ч. Бахмана, модификаций

ER-модели П. Чена, функциональных моделей по стандартам

IDEF0, по методике ШРО или др.);

сбор и описание детальных требований к составу данных и

алгоритмам реализации функций (см., например, популярную [16],

а также [58], [61] и требования серий ГОСТ24 и ГОСТ36).

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

разработка архитектуры будущей

ИС в

рамках эскизного проекта

(detailed analysis, high level design):

1) построение нормализованной реляционной или сетевой

модели БД (методы получения нормальных форм Бойса

—

Кодда,

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

ний комитета CODASYL);

2) определение принципов организации в ИС интерфейсов

конечного пользователя (принципы эргономики, как, впрочем,

и влияние компьютерной моды, переход от командного интер-

фейса к диалоговым режимам «вопрос

—

ответ»,

«управление через

меню»);

определение модульной иерархии (верхние уровни) программ-

ного обеспечения ИС (модульное программирование, метод ШРО);

4) определение принципов организации аппаратного компью-

терного комплекса, на базе которого должна функционировать ИС

(расчеты физических параметров ИС: объемов БД, временных ха-

рактеристик отдельных операций доступа к данным, целых функ-

ций и режимов в целом, организации компьютерных сетей, см.

также [58]);

Глава 5. Проектирование корпоративных информационных систем 137

5) определение основных оргмероприятий по созданию и вво-

ду в действие ИС;

определение совокупности требований к

приемке

будущей ИС;

7) определение сроков, состава работ и их стоимости для по-

следующих работ по ИС.

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

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

ня.

Все эти методы остались в арсенале разработчиков и в настоя-

щее время. Однако они и соответствующие инструменты начина-

ют совсем по иному применяться в условиях BPR и открытой ар-

хитектуры ИС. Кроме того, теперь они сочетаются с новыми ме-

тодами, позволяющими достичь большей гибкости и процесса

разработки, и самой ИС, причем за меньшее время. В отношении

собственно классических методов изменения в первую очередь

касаются качества их компьютерной поддержки, т.е. применения

новых ИТ для поддержки классических методов.

Некоторые из усовершенствований в компьютерной поддерж-

ке проектирования ИС начиная со второй половины 80-х годов:

широкое применение графических диалоговых интерфейсов

(диаграммы структур данных, иерархий функций, потоков дан-

ных и др.);

использование компьютерных сетей и работа с распределен-

ными базами данных для поддержки кооперативной групповой

разработки (использование общих словарей-справочников данных,

теперь

—

«репозитариев»);

постепенное расширение использования понятийных моде-

лей и методов объектного моделирования.

Конечно, новые ИТ заставили включать в классические мето-

дики соответствующие новые функции. Как пример это относит-

ся к средствам динамического моделирования архитектур клиент-

сервер и систем с распределенными базами данных. Однако вклю-

чение отдельных новых функций не меняло подхода в целом и не

устраняло описанных выше недостатков.

Тем не менее, несмотря на то что у большинства отечествен-

ных разработчиков возможности использовать, например, распре-

деленные БД отсутствовали из-за плохих линий связи и низкой

надежности компьютеров, изменения в ИТ происходили во всем

мире, влияли на методы проектирования и стандарты и проника-

ли в отечественные разработки.

138 Часть И. Функционирование компонентов информационного общества

5.4. Качественные изменения

в информационных технологиях

В 80-х годах прошлого столетия произошел целый ряд каче-

ственных изменений в ИТ. Некоторые из них осознавались посте-

пенно (например, развитие архитектуры и стандартов открытых

систем — см. части II и III), другие, как феномен персональных

вычислений, входили в жизнь гораздо более революционным пу-

тем. Кратко рассмотрим, как эти изменения все более ограничива-

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

требуя новых подходов в разработке чисто компьютерных компо-

нентов ИС, а также как эти изменения помогали появлению BPR.

Три качественных скачка в информационных технологиях. На-

конец, к концу 80-х

—

началу 90-х годов XX в. во всем мире не

только разработчиками, но и пользователями были осознаны три

действительно революционных феномена. Они стали все шире

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

ность компьютеризованных предприятий:

феномен персональных

вычислений,

основанный на постоянной

доступности работнику возможностей ЭВМ, в первую очередь —

на использовании персональных компьютеров. Феномен состоит

в том, что во многих видах информационных, проектных и управ-

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

лях (машинистках, чертежниках, делопроизводителях и др.), явля-

ющихся посредниками между постановкой задачи и ее решением;

феномен кооперативных

технологий,

состоящий в компью-

терной поддержке совместной согласованной работы группы ра-

ботников над одним проектом. Этот феномен возник на основе

суммы методов, обеспечивающих управление доступом членов

группы к разным частям проекта, управление версиями и редак-

циями проектной документации и согласованным выполнением

работ в последовательной процедуре работ, управление параллель-

ным конструированием и др.;

феномен компьютерных

коммуникаций,

заключающийся

рез-

ком увеличении возможностей обмена любой информацией. Он

возник, в частности, на основе стандартизованных протоколов

обмена данными прикладного уровня в локальных и глобальных

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

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

мечаний, ненужные переезды для проведения совещаний, обеспе-

Глава 5, Проектирование корпоративных информационных систем 139

чить постоянную готовность работника получить и отослать сооб-

щение или информативные записи данных вне зависимости от

места его географического расположения и др.

Оценка их влияния на производственную деятельность и орг-

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

только за рубежом, но и отечественными специалистами, хотя тог-

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

Понятийная модель предметной области. Открытые архитекту-

ры стимулируют использование готовых покупных компонентов

ИС разных разработчиков. Современный лозунг

—

«Не разраба-

тывать, а покупать!». (Конечно, это, как всякий лозунг, сильное

упрощение ситуации.)

Необходимость строить ИС на основе набора «покупных» при-

ложений разных поставщиков, причем набора, состав которого

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

невозможности использовать классические структурные техноло-

гии проектирования интегрированных систем. Например, замена

программного комплекса бухгалтерской или складской подсисте-

мы на более развитый, но других разработчиков, приводит к тому,

что меняется структура БД и набор действий с данными. Даже

если по большому счету в новом приложении будут выполняться

те же функции, но, например, быстрее и в более удачной компо-

новке, а информация хранится всего лишь в виде более детальных

сведений и т.п., то информационные и функциональные модели

могут отличаться друг от друга практически во всех

деталях!

Из-за

этого старые способы построения интегрированных моделей ста-

ли отказывать все чаще и чаще.

В силу этого проектирование ИС из покупных компонентов

на формальном уровне может оказаться близким к хаотичной са-

модеятельной разработке полностью несогласованных программ

для решения частных задач предприятия, т.е. к так называемому

позадачному подходу, с попытками последующего соединения та-

ких задач в целостную систему.

С другой стороны, постепенно осуществлялись попытки пре-

одолеть разрыв между формальными требованиями к проектиро-

ванию целостных больших ИС с интегрированными базами дан-

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

то одного, то другого программного комплекса. (Часто такие по-

пытки помещались критиками в одну графу с позадачным подхо-

дом и отвергались.) Постепенно и практикам, и теоретикам, и