Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Общая теория систем и системный анализ

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 7 8 910 / 1310 11 12 13 > Следующая >>>

 предметы деятельности (ПД) - сырье, материалы, информация;

Параметры КП

Параметры процесса

Параметры СД

Параметры К

Параметры ПД

КПС

Рис. 4.13. Структура содержательного описания процесса

 конечные продукты (КП) - товары, услуги, информация;

 средства деятельности (СД) - здания, оборудование, инструменты;

 субъекты деятельности или кадры (К) - работники, исполнители.

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

Каждый из элементов предлагается описывать множеством семантических параметров (характеристик, свойств). Весь процесс в целом также описывается множеством параметров, называемых параметрами процесса.

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

Модели вариантного выбора позволяют на основе иерархической содержательной модели формировать дерево вариантов системы и дерево оптимальных вариантов. Имеется несколько стратегий формирования альтернативных вариантов и выбора оптимальных решений. Наиболее распространенная стратегия - когда решения принимаются на всех уровнях иерархии «сверху – вниз». Сначала на верхнем уровне иерархии формируются «обобщенные» варианты реализации всей системы в целом и выбирается оптимальный вариант. Этот вариант является ограничением для нижестоящих уровней. Затем аналогичным образом принимаются решения на более низких уровнях. Тем самым выбранный на верхнем уровне вариант как бы уточняется, детализируется на уровне подсистем. Иногда используется более жесткая процедура, когда сама декомпозиция системы (подсистемы) осуществляется только после того, как для нее

был выбран оптимальный вариант. На рис. 4.14 приведен пример дерева вари-

Варианты системы

Варианты подсистемы

Оптимальные варианты

Рис. 4.14. Дерево вариантов системы

антов.

4.5 Прикладные технологии, использующие

системный анализ

4.5.1 Методология IDEF0

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

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

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

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

Стандарт IDEF0 предназначен для функционального моделирования. В ос-

Функция Выходы

Управление

Механизм

Входы

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

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

IDEF0 методология построена на следующих принципах:

– Графическое описание моделируемых процессов. Графический язык блоков и дуг IDEF0 диаграмм отображает операции или функции в виде блоков, а взаимодействие между входами/выходами операций, входящими в блок или выходящими из него, дугами (рис. 4.15). Функциональный блок преобразует входную информацию (данные, материалы, средства, задачи, цели и др.) в выходную (что требуется получить в результате выполнения данной функции). Управление определяет, когда и как это преобразование может или должно произойти. Механизм (или исполнители) непосредственно осуществляют это преобразование.

– Лаконичность. За счет использования графического языка описания процессов достигается с одной стороны точность описания, а с другой – краткость. Описание объектов и процессов в IDEF0 выполняется в виде совокупности взаимосвязанных блоков, называемых блоками ICOM (Input - Control - Output Mechanism), где I - вход, С - управление, О – выход, М – механизм.

Рис. 4.15. Структура модели

Необходимо соблюдение правил и точность передачи информации. При IDEF0 моделировании необходимо придерживаться следующих правил:

 на диаграмме должно быть не менее 3-х и не более 6-и функциональ-

ных блоков;

 диаграммы должны отображать информацию, не выходящую за рамки

контекста, определенного целью и точкой зрения;

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

дуги и ICOM коды имеют единую структуру;

 уникальность имен функций блоков и наименований дуг;

Название

Определение

Иллюстрация

Взаимосвязь по управлению

выход одного Блока влияет (является управляющей) на выполнение функции в другом Блоке

Взаимосвязь по входу

выход одного Блока является входом для другого

 четкое определение роли данных и разделение входов и управлений;

 замечания для дуг и имена функций блоков должны быть краткими и

лаконичными;

 для каждого функционального блока необходима как минимум одна

управляющая дуга;

 модель всегда строится с определенной целью и с позиций конкретной

точки зрения.

В процессе моделирования очень важным является четко определить направление разработки модели – ее контекст, точку зрения и цель. Контекст модели очерчивает границы моделируемой системы и описывает ее взаимосвязи с внешней средой. Цель отражает причину создания модели и определяет ее назначение. При этом, все взаимодействия в модели рассматриваются именно с точки зрения достижения поставленной цели. Точка зрения определяет позицию автора, т.е. что будет рассматриваться и под каким углом зрения.

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

Диаграммы более высокого уровня (А-0, А0) – являются наиболее общим описанием системы, представленным в виде отдельных Блоков. Декомпозиция этих блоков позволяет достигать требуемого уровня детализации описания системы. При IDEF0 моделировании для описания отношений между блоками используются пять типов взаимосвязей (табл. 4.2).,

Табл. 4.2. Типы связей в методологии IDEF0

Название

Определение

Иллюстрация

Обратная связь по управлению

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

Обратная связь по входу

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

Взаимосвязь «выходмеханизм»

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

Описание IDEF0 модели построено в виде иерархической пирамиды, в вершине которой представляется самое общее описание системы, а основание представляет собой множество более детальных описаний. Разработка IDEF0 диаграмм начинается с построения самого верхнего уровня иерархии (А-0) – одного блока и интерфейсных дуг, описывающих внешние связи рассматриваемой системы. Имя функции, записываемое в блоке 0, является целевой функци- ей системы с принятой точки зрения и цели построения модели (рис. 4.16).

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

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

Рис. 4.16. Контекстная диаграмма

Рис. 4.17. Детализированная диаграмма

4.5.2 Технология реинжиниринга бизнес-процессов

Понятие «реинжиниринг бизнес-процессов» (BPR - Business process reengineering) возникло примерно в 1990 г. и с тех пор вызывает активный интерес специалистов в области менеджмента и ИТ.

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

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

Последовательность стадий проведения реинжиниринга бизнеспроцессов представлена на рис. 4.18.

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

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

Решение о проведении

реинжиниринга

Этап 1

Визуализация

Разработка образа будущей компании Спецификация целей компании

Этап 2

Обратный реинжиниринг

Создание модели существующего предприятия

Идентификация процессов на предприятии Документирование потоков работ

Определение стоимости существующих процессов

Этап 3.1

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

ние бизнес-

процессов

Реорганизация процедур для использования ЭВМ,

повышения эффективности ручного труда

Идентификация необходимых изменений в работе персонала и ЭВМ

Проектирование работ, системы мотивации

Организация командной работы Управление качеством и т.д.

Приобретение ЭВМ, Разработка программного обеспечения

Этап 3.2

Разработка

организационной

структуры

Этап 3.3

Разработка

информационной

системы

Этап 3

Прямой

инжинир

инг

Новая компания

Этап 4

Внедрение

Подготовка персонала Внедрение перепроектированных процессов

Интеграция и тестирование

сонала и поэтапный ввод в действие перепроектированных бизнес-процессов.

Рис. 4.18. Последовательность проведения реинжиниринга

Анализ этапов проведения РБП показывает большие трудовые и стоимостные затраты, связанные с последовательным характером выполняемых работ, необходимостью существенных затрат на обратный инжиниринг, ручную раз-

работку моделей новой организации бизнес-процессов и последующую реализацию проекта.

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

Во многом успех конкретного проекта по реинжинирингу определяет использование инструментальных средств. Все используемые в BPR инструментальные средства можно разделить на следующие группы:

1) Средства создания диаграмм и инструментарии низкого уровня, пред-

назначенные для автоматизации первых этапов (описания целей и перспектив компании).

2) Средства описания потоков работ, позволяющие проектировать планы

работ над проектами.

3) Средства имитационного моделирования/анимации, применяемые для

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

4) CASE-средства, объектно-ориентированные инструментарии и средст-

ва быстрой разработки приложений (RAD-средства), используемые в основном для разработки информационных систем в составе новых бизнес-процессов.

5) Интегрированные многофункциональные средства, автоматизирую-

щие все основные этапы BPR. Как правило, эти средства поддерживают многопользовательский доступ к инструментарию, стыковку с RAD-средствами, возможности имитационного моделирования.

4.5.3 RAD-технология прототипного создания приложений

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

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

100

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

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

Rapid Application Development (RAD, быстрая разработка приложений) – это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

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

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

Применение технологии RAD целесообразно, когда:

 требуется выполнение проекта в сжатые сроки (90 дней). Быстрое

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

 нечетко определены требования к ПО. В большинстве случаев за-

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

<<< < Предыдущая 1 2 3 4 5 6 7 8 910 / 1310 11 12 13 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]