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

Отметим, что все содержание табл. 4.2.1 дает представление о том, что собой представляет «системная инженерия», и лишь этап 6.2 в чистом виде представляет «программную инженерию».

4.2.2. Структура процесса проектирования информационной системы по ISO/IEC 15288

Стандарт на процессы жизненного цикла систем ISO/IEC 152888

«Системная инженерия — процессы жизненного цикла систем (Standard for

Systems Engineering — System life cycle processes)» применим для широкого класса систем в правительственных, коммерческих, военных и академических организациях, его основное предназначение — поддержка создания компьютеризированных систем. Для контрактов с государственными ведомствами развитых стран применение этого стандарта обязательно. Он начал разрабатываться с 1996 г., то есть позднее ГОСТ 34.601-90, действующая версия опубликована в 2008 г.

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288,

несколько отличаются от предусмотренных ГОСТ 34.601-90, но не принципиально. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 4.2.2.

8 ISO/IEC 15288:2008 «Systems and software engineering — System life cycle processes»

(Системотехника. Процессы жизненного цикла системы).

22

архивирование системы

ISO/IEC 15288 предлагает рассматривать ЖЦ ИС в виде набора процессов.

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

при помощи различных видов деятельности. Всего выделено 25 процессов,

объединяемых в 4 группы. Помимо процессов, определено 123 различных

результата и 208 видов деятельности, нацеленных на их достижение.

Рассматривая структуру процесса проектирования АС по ГОСТ 34.601-90 или ISO/IEC 15288, уместно отметить тот факт, что большинство выпускных квалификационных работ (дипломных проектов) по специальности 220301, так или иначе, связаны с проектированием автоматизированных систем. Поэтому рекомендуем студентам самостоятельно ознакомиться с полными текстами упомянутых стандартов.

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

4.3.CASE – системы

Впервых попытках автоматизации процессов проектирования информационных объектов использовалось прямое заимствование идей и методов из других областей инженерной деятельности. Однако скоро выявился целый ряд проблем, связанных с низкой продуктивностью проектирования систем. Была осознана необходимость и предприняты интенсивные усилия в создании специализированных инженерных методов и средств, получивших названия «программная инженерия» (software engineering) и «системная инженерия» (system engineering)9. Результатом этих усилий явились так называемые CASE-системы, которые сегодня занимают такое же прочное место

впрактике инженерного проектирования, как и САПР.

CASE (Computer-Aided Software/System Engineering) — дословно переводится как разработка ПО/систем с помощью компьютера.

9 Для обозначения этого направления используются также термины «системная интеграция» и «консалтинг».

23

Современная CASE-система — это аналог САПР, одна из разновидностей информационных систем, среда проектирования прикладной функциональности ИС и программного обеспечения.

Принципиальное отличие среды проектирования систем (Computer-Aided System Engineering) от соответствующей среды проектирования программного обеспечения (Computer-Aided Software Engineering) заключается в результатах проектирования. В первом случае — это описания производственных процессов, процессов управления, бизнес-процессов, организационных структур и т.п., предназначенные для людей, которые проектируют, создают и эксплуатируют систему; во втором — прежде всего, программный код для компьютеров, а в дополнение к нему — документация для людей, работающих с этим ПО. Аббревиатура CASE охватывает оба эти случая.

Большинство CASE-систем основано на парадигме

методология/метод/нотация/средство.

Методология определяет руководящие указания для проектирования,

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

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

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

Средства (инструментарий) — любые программные средства, автоматизирующие ту или иную совокупность процессов проектирования ИС. CASE-средства удается применить на всех стадиях и этапах ЖЦ ИС.

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

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

4.3.1. CASE-методологиия

24

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

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

Если теперь посмотреть на содержание стандартов ГОСТ 34.601-90, ГОСТ

12207-99, ISO/IEC 15288, то мы увидим, что это есть не что иное, как применение методологии системного анализа к проблемам определенной предметной области — области проектирования ИС.

Основу CASE-методологии проектирования ИС составляет моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей системы. При этом под моделью предметной области понимается некоторая другая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию — быть адекватной этой области.

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

25

Допустим, мы хотим заняться проектированием ИС для предприятий. О каких объектах структуризации может идти речь?

Об одном из объектов структуризации мы уже говорили — это процесс проектирования ИС. Здесь CASE-методология говорит нам, что если структуру этого процесса мы выстроим в соответствии со стандартами ГОСТ 34.601-90, ГОСТ 12207-99 или ISO/IEC 15288, то это должно помочь нам решить проблему создания ИС.

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

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

принципом иерархичности.

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

Что это за системы?

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

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

26

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

В-третьих, информационные и другие процессы фирмы не замыкаются внутри неѐ. Организационная система является подсистемой систем более высокого порядка, например, системы под названием «экономика».

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

На рисунках, приведенных ниже, показаны примеры некоторых структур, о которых шла речь. На рис. 4.3.1.1 показана структура внутренней среды фирмы, еѐ основные службы, на рис. 4.3.1.2 — структура внешней среды фирмы, на рис. 4.3.1.3 — структура бизнеса фирмы, на рис. 4.3.1.4 — структура процессов управления фирмой.

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

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

27

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

4.3.3. Подходы к проектированию ИС

28

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

Вширокой трактовке10 сущность структурного подхода при проектировании ИС заключается в ее декомпозиции (разбиении) в соответствии

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

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

Вузкой трактовке объектом структуризации также является функциональность, но не всей организации, а только еѐ структуры управления. Структура ИС привязывается к существующей структуре управления организацией, которая, как правило, является функционально-ориентированной, иерархической, образующей так называемую «вертикаль управления». Это представляется вполне логичным и понятным — поскольку автоматизация управленческих процессов есть одна из главных задач ИС, особенно если она называется АСУ. Но в этом заключается и главный недостаток такого подхода.

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

Вкачестве альтернативы структурному подходу в его узкой трактовке рассматривается процессный подход, который сформировался в середине 80-х годов ХХ века, и сегодня применяется не только к проектированию ИС, но и к

10 А.М. Вендров. CASE-технологии. Современные методы и средства проектирования информационных систем. http://www.citforum.ru/database/case/index.shtml

29

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

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

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

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

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

Именно функциональность бизнес-процессов является главным предметом структуризации в этом подходе. И, исходя из неѐ, определяется функциональность ИС.

Структурный подход в его узкой трактовке привязывает нас к «вертикальному» описанию организации (как структуры распределения ответственности, полномочий и взаимоотношений). Процессный подход ориентирует нас на еѐ «горизонтальное» описание, как системы процессов.

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

4.3.4.Основные элементы процессного подхода

Основные понятия процессного подхода формулируются следующим образом11:

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

11 Международный стандарт ISO 9000:2000 Основные положения и словарь, п. 2. 4 «Процессный подход».

30