4. «Типовые оргструктуры»

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

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

На рис. 2.2а показан идеальный вариант каскадной схемы, по которой полагалось планировать проектирование ИС (многие методологии до сих пор продолжают следовать этой линии).

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

Рис.2.2.

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

Был разработан и вошел в практику большой набор теоретически обоснованных методов: проектирование концептуальных и логических схем БД, организация физической среды хранения данных, планирование путей доступа к данным и др. Анализ функций и задач предприятия также служил основой и в проектировании БД. Появились CASE-системы (Computer Aided Soft Engineering), ориентированные на формализацию информационных и функциональных требований к ИС и предназначенные для формального описания и бригадной разработки больших программных комплексов. Эти методы и инструменты, которые в идеале должны были бы соединяться с методами преобразований управления производством, составляли классическую мастерскую ИТ. Укажем на наиболее популярные из них, применявшиеся на первых стадиях проектирования и составлявших часть упоминавшейся «мастерской ИТ».

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

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

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

• анализ критических факторов успеха и риска с использованием системного и ситуационного анализа,

• обследование предприятия методами анализа документов, интервью, прямых наблюдений, хронометража и др. (большое количество методик: от SADT Д.Росса до ГОСТа по предпроектным исследованиям при разработке САПР),

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

• проектирование более целесообразных и учитывающих создаваемую ИС оргструктуры, набора и иерархии функций («задач»), видов документов и правил документооборота, вычленение предметных БД, определение взаимосвязей между ними,

• разработка предложений по изменениям на предприятии, затрагивающим оргструктуру, документооборот и др.,

• построение недетализированных моделей БД и функций ИС (с использованием диаграмм данных Ч.Бахмана, модификаций ER-модели П.Чена, функциональных моделей по стандартам IDEF0 и др.),

• сбор и описание детальных требований к составу данных и алгоритмам реализации функций.

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

• построение нормализованной реляционной или сетевой модели БД (методы получения нормальных форм Бойса-Кодда, четвертых и пятых нормальных форм, использование предложений комитета CODASYL),

• определение принципов организации в ИС интерфейсов конечного пользователя (принципы эргономики, переход от командного интерфейса к диалоговым режимам «вопрос-ответ», «управление через меню»),

• определение модульной иерархии (верхние уровни) программного обеспечения ИС,

• определение принципов организации аппаратного компьютерного комплекса, на базе которого должна функционировать ИС (расчеты физических параметров ИС: объемов БД, временных характеристик отдельных операций доступа к данным, целых функций и режимов в целом, организации компьютерных сетей),

• определение основных оргмероприятий по созданию и вводу в действие ИС,

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

• определение сроков, состава работ и их стоимости для последующих работ по ИС.

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

• широкое применение графических диалоговых интерфейсов (диаграммы структур данных, иерархий функций, потоков данных и др.),

• использование компьютерных сетей и работа с распределенными базами данных для поддержки кооперативной групповой разработки (использование общих словарей-справочников данных, теперь – «репозитариев»),

• постепенное расширение использования понятийных моделей и методов объектного моделирования.

Динамика развития ИТ приводила к существенным изменениям методов проектирования и построения ИС.

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

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

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

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

Понятие открытых систем нельзя трактовать упрощенно. Кроме указанных выше свойств, в открытость систем входит соответствие стандартам (в том числе – стандартам «de facto») и открытость в областях: масштабируемость, расширяемость, интернационализация, переносимость пользователя.

Наконец, к концу 80-х– началу 90-х были достигнуты три существенных прорыва в области информационных технологий:

1. Прорыв в области персональных вычислений, основанный на постоянной доступности работнику возможностей ЭВМ, в первую очередь - на использовании персональных компьютеров.

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

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

Классические методы проектирования ИC, несмотря на известные достоинства, всегда имели отрицательные стороны:

• разработка ИС была слабо связана с реальным повышением эффективности производства;

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

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

• жесткость классических методов стала барьером на пути их дальнейшего применения;

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

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