Основы теории систем и системного анализа

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

В табл. 3.4 приведены данные для расчета глобальных приоритетов сценариев развития технопарка и результаты расчетов.

Таблица 3.4

189

Окончание табл. 3.4

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

0,1066 · 0,0865 + 0,1333 · 0,1629 + 0,2332 · 0,0306 +

+0.1212 · 0,0383 + 0,1177 · 0,096 + 0,1469 · 0,0222 +

+0,2009 · 0,0099 + + 0,2224 · 0,3599 + 0,5136 · 0,0887 +

+0,1093 · 0,0364 + 0,5261 · 0,0566 + 0,5806 · 0,0113 = 0,2253.

Как видно из табл. 3.4, наилучшим сценарием, получив-

шим наибольший глобальный приоритет, стал «Рост без существенных расходов».

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

1.Каково назначение системного анализа, его основная цель?

2.Как определяется системный анализ с практической, методической и методологической сторон?

3.Каковы основные принципы системного анализа?

4.Перечислите и охарактеризуйте основные этапы системной последовательности принятия решений.

5.Чем отличаются различные варианты системной последовательности?

6.Какие виды анализа выполняются на этапе анализа ситуа-

ции?

190

4. ТЕХНОЛОГИИ СИСТЕМНОГО АНАЛИЗА

4.1.Понятие технологии системного анализа

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

Несмотря на общепризнанную целесообразность применения системного анализа для разрешения сложных проблем, масштабы реального, а не просто декларируемого использования аппарата системного подхода невелики [62]. Основной причиной является сложность самого процесса системного анализа. Выделяют три группы факторов сложности, связанные с тремя составляющими — объектом системного анализа, средой и субъектом. Объектом в данном случае является исходная проблематика, средой — условия возникновения проблем и их разрешения, субъектом — разработчик, осуществляющий анализ и поиск средств разрешения проблем (рис. 4.1).

СРЕДА

Анализ проблем Проблематика

Разрешение проблем

Рис. 4.1. Факторы сложности процесса системного анализа

192

Факторы, связанные с объектом. Это, прежде всего, ком-

плексность, сложность проблем. Большинство проблем, разрешаемых с помощью системного анализа, затрагивают различные аспекты деятельности — технический, экономический, социальный, экологический и т. д. Заметной тенденцией последнего времени является усложнение проблем, перерастание их в проблематику, т. е. в сплетение, клубок неразрывно связанных проблем [2].

Факторы, связанные со средой. Это уникальность, не-

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

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

Факторы, связанные с субъектом. Это сложность при-

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

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

193

Термин «технология» (от греч. techne — «искусство, мастерство, умение» и logos — «понятие, учение») широко используется в производственной сфере. При этом под технологией понимается последовательность согласованных технологических операций в процессе производства продукции. Системная технология является информационной технологией, т. е. организованной совокупностью методов обработки информации. В отличие от теории, она основана на четко организованных процессах и предполагает наличие конкретных рекомендаций относительно последовательности этапов разработки, состава работ и используемых процедур, методов и моделей [62]. Особую роль при этом играет автоматизация. Использование компьютерных инструментальных систем поддержки может значительно повысить эффективность разработки за счет автоматизации рутинных операций, контроля ошибок, использования типовых фрагментов моделей, систематизации накапливаемой в процессе разработки информации, возможности проведения экспериментов на моделях и т. д.

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

И хотя, по признанию многих авторов, универсальная общесистемная технология для проектирования сложных систем любой природы, еще не создана, основы такой технологии, несомненно, фактически уже существуют [62]. Кроме того, создаются и находят широкое применение специализированные системные технологии, ориентированные на конкретные виды систем. В настоящее время наиболее развиты автоматизированные технологии разработки информационных систем (CASE-технологии), бизнес-систем (технологии реинжиниринга бизнес-процессов) и технических систем (САПР-техноло- гии). Идеи и принципы, заложенные в эти технологии, а также конкретные методы и модели, несомненно, могут быть использованы при создании общесистемной информационной технологии.

194

4.2.Специализированные технологии системного анализа

4.2.1.CASE-технологии разработки информационных систем

CASE-технологии представляют собой совокупность методологий проектирования и сопровождения информационных систем (ИС) на всем их жизненном цикле, поддержанную комплексом взаимоувязанных CASE-средств. В основе регламента различных технологий разработки ИС лежит понятие жизненного цикла системы, отражающее укрупненные этапы ее создания и эксплуатации. Традиционно выделяются следующие основные этапы жизненного цикла: анализ требований; проектирование; реализация (программирование); тестирование и отладка; эксплуатация и сопровождение. В разное время и в разных «школах» разрабатывались более детальные технологии. При этом разбиение работ на этапы и их названия менялись. Соответствующие технологии организации работ рекомендовались официально, фиксировались в стандартах (ГОСТы, ANSI, ISO) и во многих отраслях широко использовались. Несмотря на все различия технологий можно выделить этапы, общие для большинства методик [63]: формирование требований; разработка концепции; техническое задание; эскизный проект; технический проект; рабочая документация; ввод в действие; сопровождение.

Если состав этапов и их назначение в течение последних десятилетий менялись незначительно, то схема их применения, порядок следования этапов и организация работ менялись кардинально. Традиционная схема, используемая в 1970-е и вна-

чале 1980-х гг., называемая каскадной (водопадной) моделью,

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

195

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

Существенно сглаживает недостатки каскадной модели спиральная схема, получившая распространение в 1980-х гг. [63, 64]. Характерной особенностью данной модели является непрерывный процесс разработки и развития ИС с планируемыми точками передачи в эксплуатацию новых версий и новых функциональных блоков. Разработка проекта ведется как бы по спирали, на каждом витке которой создается очередная версия. Виток спирали представляет собой законченный проектный цикл по типу каскадной схемы, т. к. предполагает последовательное выполнение всех этапов от анализа до внедрения (рис. 4.2, б). Такой подход обеспечивает на каждом витке уточнение требований к системе, однако сроки разработки готового продукта по сравнению с каскадной схемой удлиняются, а затраты существенно возрастают.

В конце 1980-х гг. сложился новый подход, названный

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

(rapid prototyping) [63, 64]. Последовательность этапов в данной модели внешне выглядит как каскадная, однако содержание технологических этапов таково, что многие проектные решения в процессе разработки ИС подвергаются многократным уточнениям и корректировкам, как это предусмотрено спиральной моделью. Такой компромисс достигается за счет создания на различных этапах разработки системы вместо законченных прототипов макетов, представленных хотя бы и на бумаге, оперативно проверяемых и обсуждаемых со всеми заинтересованными сторонами (будущими пользователями, заказчиками и т. д.). По результатам обсуждений макетов при необходимости принимается решение о возврате на любой из предыдущих этапов с целью корректировки принятых решений (рис. 4.2, в). Макеты, представленные на ранних этапах в виде грубых концептуальных моделей, постепенно уточняются, детализируются.

196

Рис. 4.2. Схемы разработки информационных систем: а — каскадная; б — спиральная; в — макетная

197

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

дующие методы: SADT (Structured Analysis and Design Technique), DFD (Data Flow Diagrams), ERD (Entity-Relationship Diagrams), STD (State Transition Diagrams) [65]. Наиболее су-

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

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

Самым замечательным свойством классов является возможность на основе одних классов создавать другие (наследовать) путем добавления новых атрибутов и методов, а также переопределения методов. В определении класса-потомка приводятся только новые атрибуты/методы и переопределен-

198