 |
Часть I. Роль системного анализа в проектировании информационных систем
|
|
|
|
Козьма Прутков
1.1. Системный анализ как метод
Системный анализ представляет собой совокупность методов и средств, позволяющих исследовать свойства, структуру и функции объектов, явлений или процессов в целом, представив их в качестве систем со всеми сложными межэлементными связями[1]. Нетрудно увидеть, что приведенное определение является, по существу, кругом: системный анализ = анализ систем.
Исследователями приложены значительные усилия (и затрачено ещё большее количество бумаги) в попытках дать ясные конструктивные определения понятиям системного подхода, системного анализа, большой системы, системы, но содержательных определений, понятных инженеру, найдено не было.
Не вдаваясь в философские основания такой ситуации, ограничимся имеющимися «рабочими» определениями. Недаром в классификации специальностей, по которым присваиваются ученые степени, Высшая Аттестационная Комиссия не включила в классификатор чистый «Системный анализ», а сопроводила этот термин указанием, в какой области исследований проводился системный анализ. Поэтому системный анализ следует рассматривать как деятельность по исследованию систем в некоторой определенной области, подчиняющейся ряду принципов [1–5]:
1. Выделение некоторого объекта/явления как системы: целостность представления объекта/явления; определение целенаправленности/назначения объекта; определение интегративных свойств объекта; выявление структуры и функций объекта.
2. Формирование модели системы.
3. Исследование модели системы с целью оценки ее свойств и прогнозирования ее поведения в будущем.
Обычно системный анализ применяется к объекту/явлению, выделенному аналитиком из окружающего мира как система.
|
|
|
Особенность применения методов системного анализа к объекту «Информационная система» (ИС) заключается в том, что информационная система при этом может выступать как реально существующий объект или проектируемый объект
В первом случае методы и средства системного анализа обычно применяются при решении задач аудита информационных систем. Во втором случае методы и средства системного анализа применяются как основные принципы процесса проектирования, определяющие его содержание.
В настоящем материале рассматривается применение системного подхода к деятельности «Проектирование информационной системы». Для этого необходимо рассмотреть информационную систему как «систему с точки зрения системного анализа».
1.2. Информационная система как «система» с точки зрения системного анализа
1.2.1. Целостность представления ИС
Анализ неудач проектов разработки и внедрения информационных систем показывает, что эти неудачи часто связаны с отсутствием целостного понимания информационных систем и процесса их разработки и внедрения. Обычно инженеры – участники процесса проектирования бывают удивлены, когда услышат, что их представление об информационной системе не соответствует целостному представлению о ней. Эта ситуация связана с тем, что в проектирование и внедрение ИС вовлечены специалисты разных специальностей. Даже обладая высокой квалификацией в своей области (программное обеспечение, информационное обеспечение, технические средства и сети передачи данных), они уделяют недостаточно внимания целостному представлению об ИС. Что часто приводит к появлению системных ошибок, которые проявляются только на этапе опытной эксплуатации ИС. Целостное представление об ИС может быть сформировано только там, где специалисты по продажам, проектировщики и разработчики работают как одна команда и регулярно обмениваются информацией о ходе проекта. Такие команды формируются только в тех организациях, в которых процессы продаж, проектирования и внедрения управляются наличием и неукоснительным исполнением Порядков/Регламентов этих процессов.
|
|
|
1.2.2. Определение целенаправленности/назначения проектирования информационной системы С определением целей в проектировании информационных систем вообще дело обстоит неважно. Часто при анализе технических заданий можно обнаружить утверждения, что целью создания информационной системы является «создание информационной системы».
Как правило, понятие цели используется для указания результата развития системы за определенный промежуток времени. Определение цели ИС связано с назначением ИС. В настоящее время принято считать, что назначение ИС заключается в информационно-функциональной поддержке деятельности, для которой разрабатывается ИС. Цели ИС фиксируют количественные и качественные характеристики ИС, ориентированные на требования поддерживаемого вида деятельности. Эти требования фиксируются в Техническом задании (ТЗ) на разработку и внедрение ИС.
Следует отметить, что не всегда в ТЗ ясно и недвусмысленно определяются цели разработки и внедрения ИС. Часто они замещаются указанием назначения или формулируются общими словами. В этом случае Исполнитель, чтобы не испытывать трудности со сдачей ИС Заказчику, либо самостоятельно принимает решение о значении параметров ИС, либо пользуется неясностью формулировок ТЗ для разработки по принципу «как придется». И в первом и во втором случае трудности, возникающие при сдаче ИС (по ТЗ) являются следствием системной ошибки, допущенной при определении целенаправленности/назначения ИС.
1.2.3. Определение интегративных свойств информационной системы
Под интегративными свойствами в системном анализе понимаются свойства, присущие системе в целом, но не присущие ее элементам в отдельности [1,2]. Обычно функциональные требования, содержащиеся в ТЗ (Раздел «Общие требования к системе») определяют интегративные свойства информационной системы.
1.2.4. Выявление структуры и функций информационной системы
|
|
|
Поверхностное понимание структуры объекта/явления сводит понятие структуры к совокупности элементов объекта/явления и указанию связей между ними. Такое понимание структуры информационной системы в целом правильно, но не исчерпывает содержания структуры ИС (в рамках системного анализа), знание которой необходимо для проектирования ИС.
Накопленный опыт создания ИС отразился в структуре нормативных документов по проектированию ИС. Наиболее полезным является ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы». Несмотря на то, что с момента его выхода прошло более 20 лет, этот документ актуален и сегодня. ГОСТ четко сформулировал структуру ИС. Однако с точки зрения системного анализа, необходимо более широкое понимание структуры ИС.
Проблема заключается в нахождении компромисса между простотой описания, что является одной из предпосылок понимания, и необходимостью учета разнообразных характеристик системы. В этих целях в рамках системного анализа используется концептуализация описания структуры системы [3], позволяющая выделить некоторые уровни описания (страты). Страта представляет собой некоторый абстрактный уровень описания, использующий определенные принципы и понятия, свойственные данной страте. Обычно страты организуются в иерархию.
Требования, предъявляемые к функционированию системы на любой страте, выступают как условия или ограничения функционирования системы на нижестоящих стратах. Ход реального процесса определяется требованиями к поведению системы на верхней страте. Для надлежащего функционирования системы на данной страте все нижние страты должны работать правильно. Это также определяет наличие обратной связи между нижестоящими стратами и вышестоящей стратой. Стратифицированное описание системы задается семейством моделей, каждая из которых описывает поведение системы на определенной страте. Стратифицированное представление информационной системы представлено на рис. 1.
Экономическая страта включает описание ИС с точки зрения роли и влияния ИС на экономические характеристики организации, деятельность которой предполагается поддерживать. Основными показателями на этой страте являются Совокупная стоимость владения (ССВ) ИС (за отчетный период) и общий функционал системы. Требования со стороны экономической страты включают общие требования к обеспечению функционирования ИС в рамках бизнес-процессов организации.
|
|
|
К сожалению, в настоящее время в практике проектирования часто в ТЗ Заказчик указывает требования к функционирования ИС в слишком общей форме. Тем более, не принято указывать в ТЗ требования к ССВ, а в Техническом/рабочем проекте — оценки ССВ. Хотя с увеличением степени информатизации коммерческих и государственных структур наблюдается повышение интереса Заказчиков к Совокупной стоимости владения, как функционирующих ИС, так и проектируемых ИС.
Рис. 1. Стратифицированное представление ИС
Функциональная страта включает описание функциональных требований к ИС. Основным показателем на этой страте является степень покрытия множества процессов деятельности организации Заказчика ИТ-сервисами и эффективность процессов деятельности (в сравнении с эффективностью этих процессов при отсутствии поддержки ИС). Эта страта также включает принятую в настоящее время процедуру выделения функциональных подсистем ИС. Требования со стороны функциональной страты включают содержательные (с указанием значений показателей) требования к ИТ-сервисам.
Страта обработки информации и управления включает принятые в практике проектирования виды обеспечения ИС и их структуру и характеристики: информационное обеспечение; лингвистическое обеспечение; программное обеспечение; организационное обеспечение; обеспечение информационной безопасности.
Требования со стороны Страты обработки информации и управления включают требования к техническому обеспечению ИС.
Техническая страта включает техническое обеспечение, средства передачи данных, а также средства и организацию технического сопровождения. Основными показателями, формируемыми на этой страте, являются показатели, характеризующие качество ИС: время реакции системы; объемы хранимой информации; коэффициент готовности системы; отказоустойчивость.
Требования со стороны экономической страты предъявляются в форме требований к ИТ-сервисам, которые должны поддерживать различные функции бизнес-процессов.
Как следует из изложенного, ИС является системой с точки зрения системного анализа. Критически настроенный читатель скажет, что в приведённом обосновании системности ИС для него нет ничего нового. Следует заметить, что для систем, относительно которых накоплен значительный опыт создания и эксплуатации системный анализ редко дает что-либо новое.
|
|
|
Однако выполнение требований системного анализа в процессе проектирования гарантирует от системных ошибок, устранение которых дорого обходится на этапе промышленной эксплуатации системы. Опасность системных ошибок заключается в том, что часто обнаруживается, что система не подлежит исправлению и единственным методом модернизации системы является полный ее снос.
Процесс проектирования ИС (как и других технических систем) систем можно рассматривать во времени как управление «движением» проекта по некоторой «траектории». В зарубежной технической литературе моден термин «road map», который описывает такую траекторию для проектирования и внедрения ИС. Процесс проектирования ИС есть управление «объектом» ИС на этой траектории. При этом ИС как объект управления проходит стадии «материализации» от идеи (на стадии постановки задачи через стадии проектирования и внедрения) до полной материализации на этапе сдачи в промышленную эксплуатацию. С точки зрения теории управления в описании объекта всегда выделяются «управляемые параметры» (параметры, которые изменяются в целях управления) и «наблюдаемые параметры» (параметры, которые получаются в результате управляющих воздействий на объект).
Если в процессе проектирования не учитывается некоторая страта или её составляющая, то ее показатели неявно переходят из множества управляемых показателей в множество наблюдаемых показателей, значения которых могут быть оценены только после создания ИС. Так пренебрежение экономической стратой часто приводит к созданию ИС с недопустимо высокой для Заказчика общей стоимостью владения.
Следует заметить, что применение методов системного анализа позволило получить существенные количественные результаты, только в тех случаях, когда использование этих методов основано на выборе соответствующей математической модели. К сожалению, попытки применения методов системного анализа в областях, в которых отсутствуют разработанные математические модели, приводят только к призывам: «Ребята, надо думать системно!».
Последнее утверждение не означает, что в настоящее время найдены адекватные математические модели ИС. Хотя и получены количественные результаты для ИС на основе применения теории очередей, в области описания моделей данных, однако трудно себе представить, возможность написания единой математической модели ИС.
1.2.5. Модели, применяемые для систем, которые не описываются математическими моделями
В соответствии с положениями системного анализа необходимы модели, позволяющие описывать: структуру системы; механизмы функционирования системы; поведение системы (проявление механизмов функционирования в изменяющихся окружающих условиях).
При разработке таких моделей пришлось согласиться с рядом ограничений:
1. В настоящее время не представляется возможным описать ИС единой математической моделью.
2. В отличие от математических моделей моделирование ИС должно использовать некоторые элементы описания ИС на естественном языке. Такие модели принято называть семантическими моделями, в связи с тем, что смысл элементов модели определяется их именами.
3. Если и возможно моделирование ИС, то только совокупностью связанных моделей.
В связи приведенными ограничениями возникла необходимость общего определения понятия модели. Выяснилось, что под моделью M целесообразно понимать непустую совокупность некоторого множества элементов S (базовое множество модели) и заданных на этих элементах свойств A (множество атрибутов) и заданных на этих объектах отношений R (множество отношений). Здесь Aij –некоторое i-ое свойство элемента sj. Значения свойства Aij элемента sj задаются на множествах, именуемых доменами (Dij)
В соответствии с поставленной задачей моделирования были разработаны среды моделирования, обеспечивающие разработку и поддержку взаимосвязанных моделей (Integration Definition — IDEF, BPWIN, Oracle BPA, ARIS Sheer). Наиболее современными средами являются BPA, ARIS [11,12]. Далее приводятся примеры моделей, выполненные в средах Oracle BPA, или ARIS Sheer.
В качестве основной формы представления модели приняты помеченные графы (графы, элементы которых помечены их именами). В случаях, когда необходимо представить только структуру объекта, нет необходимости указывать атрибуты элементов. И на элементы базового множества не накладываются никаких дополнительных ограничений.В этом случае модель имеет простой вид, например:
Пример некой структуры
Связь 1–2, связь 1–3, связь 1–4
Здесь:
S={Элемент 1, Элемент 2, Элемент 3, Элемент 4}
R={Связь 1–2, Связь 1–3, Связь 3–4}
|
|
|
