Файл: "Анализ и оценка средств реализации структурных методов анализа и проектирования информационной системы".pdf

Введение

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

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

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

Согласно статистическим данным, неудачными оказывается в среднем порядка 30% проектов, общая стоимость которых превышает десятки миллиардов долларов. При этом в срок выполняется порядка 16%-20% от общего числа проектов, а перерасход средств составляет до 200% от запланированного бюджета.

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

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

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

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

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

Для достижения цели работы будут решены следующие задачи: рассмотрены методы и средства проектирования информационных систем; основные понятия структурного анализа и структурного проектирования; проанализированы методы структурного анализа и проектирования: SADT и SSADM.

1 Информационные системы: методы и средства проектирования

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

Проектирование ИС охватывает три основные области:

- проектирование объектов данных, которые будут реализованы в базе данных;

- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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

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

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

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

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

Каноническое проектирование ИС. Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

Типовая методология построения информационных систем содержит три основных компонента:

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

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

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

Можно выделить модели структурного подхода, объектного подхода, case-средств.

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

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

- диаграмма потоков данных/модель бизнес-процессов (Data Flow Diagram/Business Process Model) (средство описания процессов обработки информации). Для описания бизнес-процессов организации достойной альтернативы диаграмме потоков данных пока не найдено. Однако эта модель обладает рядом недостатков, самым главным из которых, пожалуй, является невозможность показать последовательность выполнения функций, если они входят в несколько бизнес-процессов;

- диаграмма "сущность - связь" (Entity Relationship Diagram) (описание информационной модели предметной области, не привязанное к инструментам реализации структур хранения данных в компьютерной системе);

- диаграмма переходов состояний (State Transition Diagram) (документирование состояний программных конструкций, экранов, каналов связи);

- структурная карта (Structure Chart) (отображение взаимного вызова функций в процессе выполнения программы);

- блок-схема (Flow Chart) (алгоритмы выполнения процедур).

Объектный подход содержит набор моделей, связанных с понятием класса/объекта, объединяющего данные (состояние) и поведение. В настоящее время наиболее естественным является применение набора моделей, входящих в UML (универсальный язык моделирования), так как этот язык стандартизирован, широко используется и постоянно развивается. Распространенность языка UML можно объяснить тем, что он создан авторами трех самых известных в мире объектных методов (OMT, OOSE и Booch method). Прекращение "войны методов" и объединение ведущих специалистов привело к открытости и стандартной интерпретации моделей.

Стандарт UML открыт для обсуждения и развивается при участии ведущих технологических фирм: Rational Software, Microsoft, Hewlett-Packard, Oracle, IBM, Platinum Technology и других.

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

Моделирование деловых процессов, как правило, выполняется с помощью Case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др.

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

- функциональное моделирование (IDEF0);

- реляционное моделирование (IDEFI, IDEFIX);

- описание бизнес-процессов (IDEF3);

- диаграммы потоков данных (DFD).

Модель в Case-средствах рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных.

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

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

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

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

Одним из наиболее эффективных инструментов имитационного моделирования является система ARENA, разработанная фирмой System Modeling Corporation. Система позволяет строить имитационные модели, проигрывать их и анализировать результаты.

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

Типовое проектное решение (ТПР) - это тиражируемое (пригодное к многократному использованию) проектное решение.

Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

- элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);

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