2.3. Структурный анализ

Анализ является первым этапом создания ИС, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: “Что должна делать будущая система?”. Именно здесь лежит ключ к успеху всего проекта.

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

– внешние условия работы системы;

– функциональная структура системы;

– распределение функций между человеком и системой, интерфейсы;

– требования к техническим, информационным и программным компонентам системы;

– условия эксплуатации.

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

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

Вторая стадия работы, к которой привлекаются заинтересованные представители заказчика, а при необходимости и независимые эксперты, состоит в анализе модели “как есть”, выявлении ее недостатков и узких мест, определении путей совершенствования системы управления на основе выделенных критериев качества.

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

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

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

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

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

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

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

– аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;

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

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

– спецификация системы из-за объема и технических терминов непонятна для заказчика;

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

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

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

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

Выделение двух базовых принципов инженерии информационных систем не означает, что остальные принципы являются второстепенными. Отметим основные из них.

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

2. Принцип полноты - заключается в контроле на присутствие лишних элементов.

3. Принцип непротиворечивости - заключается в обоснованности и согласованности элементов системы.

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

5. Принцип упрятывания - заключается в упрятывании несущественной на конкретном этапе информации: каждая часть “знает” только необходимую ей информацию.

6. Принцип логической независимости - заключается в концентрации внимания на логическом описании системы, обеспечении независимости от ее физической реализации.

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

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

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

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

– функции, которые система должна выполнять;

– процессы, обеспечивающие выполнение указанных функций;

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

Среди всего многообразия средств решения указанных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются:

– FDD (Functional Decomposition Diagrams) – диаграммы функциональной декомпозиции;

– DFD (Data Flow Diagrams) – диаграммы потоков данных;

– ERD (Entity-Relationship Diagrams) – диаграммы “сущность-связь”.

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

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

Источники:

1. Калянов Г. Н. Основы консалтинга при автоматизации предприятий и учреждений. Обзорный курс. Академия АйТи, 1988. Http://academy.it.ru/doc/consult-171.html.

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