Шпаргалка по "Менеджменту"

ее представлении.

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

в следующем:

• на каждой стадии формировался законченный, отвечающий

критериям полноты и  согласованности набор проектной, а 

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

предусмотренные стандартами  виды обеспечения ИС: организационное,

методическое, информационное, программное,

аппаратное и др.;

• выполняемые в логичной последовательности этапы работ 

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

завершения всех работ  и соответствующие затраты.

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

такой схемой табл. 5.2.

Таблиц а 5.2

Эти стадии работ стали  также называть частями «проектного 

цикла» системы. Такое  название возникло потому, что в  этапы 

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

к системе и вариантов  проектных решений. Жизненный цикл

самой системы существенно  сложнее и больше. Он может включать

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

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

В этих циклах происходило  и развитие ИС, и модернизация

ее компонентов.

Отрицательные факторы  применения описанной схемы проектирования

также наблюдались постоянно, были описаны в литературе

и хорошо известны практикам.

Недостаток 1 (опоздание). Чаще всего в качестве основного

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

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

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

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

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

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

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

затем — программисты;

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

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

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

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

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

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

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

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

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

превышать сроки и  смету разработки, или делать и  то и другое.

Недостаток 2 (бесполезность). Существовал и явным образом 

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

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

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

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

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

механизации) существующих производственных действий работников.

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

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

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

и далее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Схема непрерывной  разработки. Примером может служить 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

improved prototype design and development).

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

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

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

Недостаток 3 и 4 {жесткость  и закрытость). Рассмотренные

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

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

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

их стыковки в такую  ИС.

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

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

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

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

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

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

«сверху вниз» (не путать с одноименным стилем программирования).

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

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

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

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

подходы получили общее  условное название — «структурное

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

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

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

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

... в подавляющем числе  случаев пользователю естественней 

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

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

объясняется его постоянными  контактами с иерархическими

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

Однако жесткость иерархических  структур ограничивает их

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

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

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

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

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

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

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

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

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

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

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

1) компьютер конкретного  типа (конкретной фирмы-производителя);

2) конкретная операционная  система для данного типа компьютера;

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

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

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

запросов;

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

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

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

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

Недостаток 5 (типовые оргструктуры). Потенциальная возможность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

комплексов.

В конце 70-х — середине 80-х годов XX в. и в нашей стране

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

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

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

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

Обследование, общий анализ ситуации на предприятии и разработка

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

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

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

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

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

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

«Концепция, ТЗ»: исследования требований предприятия и пользователей,

выработка вариантов  и рекомендаций по разработке ИС,

разработка ТЗ на проектирование ИС в целом и ЧТЗ по подсистемам

(strategy stady, analysis, requirement specification):

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

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

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

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