Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы

Содержание:

Введение

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

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

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

Согласно статистическим данным, неудачными оказывается в среднем порядка 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. Система позволяет строить имитационные модели, проигрывать их и анализировать результаты.

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

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

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

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

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

- объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

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

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

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

Для её разработки выполняется моделирование данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).

Существуют два уровня представления модели - логический и физический.

Логический уровень - это абстрактный взгляд на данные, но данные представляются так, как выглядят и могут называться так, как они называются в реальном мире, например, "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например, на основе модели процессов. Отметим, что логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д.

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

- хранилище должно иметь понятную для интеграции структуру данных;

- должны быть выделены статические данные, которые модифицируются по расписанию (ежедневно, еженедельно, ежеквартально);

- должны быть упрощены требования к запросам для исключения запросов, требующих множественных утверждений SQL в традиционных реляционных СУБД;

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

Как видно из этих требований, по своей структуре реляционные СУБД существенно отличаются от хранилищ данных. Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. Выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что значительно увеличивает время отклика. Проектирование хранилища данных подразумевает создание денормализованной структуры данных, ориентированных в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и снижает скорость выполнения запроса.

2 Основные понятия структурного анализа и структурного проектирования

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

В инженерии ПО (software engineering), Структурный анализ (Structured Analysis, SA) и одноименное с ним Структурное проектирование (Structured Design, SD) – это методы для анализа и преобразования бизнес-требований в спецификации и, в конечном счете, в компьютерные программы, конфигурации аппаратного обеспечения и связанные с ними ручные процедуры.

Структурный анализ, СА (Structured Analysis, SA) и Структурное проектирование, СП (Structured Design, SD) являются фундаментальными инструментами системного анализа и развивались из классического системного анализа 1960-70-х годов.

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

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

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

3) принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;

4) принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы;

5) принцип непротиворечивости – заключается в обоснованности и согласованности элементов.

Структурный анализ – это часть серии структурных методов, представляющих набор методологий анализа, проектирования и программирования, которые были разработаны в ответ на проблемы, с которыми столкнулся мир ПО в период с 1960 по 1980 гг. В этот период большинство программ было создано на Cobol и Fortran, потом на C и BASIC.

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

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

1) анализ – определение того, что система будет делать;

2) проектирование – определение подсистем и их взаимодействие;

3) реализация – разработка подсистем по отдельности;

4) объединение – соединение подсистем в единое целое;

5) тестирование – проверка работы системы;

6) установка – введение системы в действие;

7) функционирование – использование системы.

Эта последовательность всегда выполнялась итерационно, потому что система полностью никогда не удовлетворяла требованиям пользователей, поскольку их требования часто менялись. И, тем не менее, с этой моделью создания системы, ориентированной на управление, постоянно возникали сложности. Эксплуатационные расходы, возникавшие после сдачи системы, стали существенно превышать расходы на ее создание и продолжали расти с огромной скоростью из-за низкого качества исходно созданной системы. Некоторые считали, что рост эксплуатационных расходов обусловлен характером ошибок, допущенных в процессе создания системы. Исследования показали, что большой процент ошибок в системе возник в процессе анализа и проектирования, гораздо меньше их было допущено при реализации и тестировании, а цена (временная и денежная) обнаружения и исправления ошибок становилась выше на более поздних стадиях проекта. Например, исправление ошибки на стадии проектирования стоит в 2 раза, на стадии тестирования – в 10 раз, а на стадии эксплуатации системы – в 100 раз дороже, чем на стадии анализа. На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях. Кроме того, ошибки анализа и проектирования обнаруживались часто самими пользователями, что вызывало их недовольство.

Традиционные подходы к созданию систем приводили к возникновению многих проблем:

1) не было единого подхода;

2) привлечение пользователя к процессу разработки не контролировалось;

3) проверка на согласованность проводилась нерегулярно или вообще отсутствовала, результаты одного этапа не согласовывались с результатами других;

4) процесс с трудом поддавался оценкам, как качественным, так и количественным.

Утверждалось, что когда создатели систем пользуются методологиями типа структурного программирования и проектирования сверху вниз, они решают либо не поставленные задачи, либо плохо поставленные, либо хорошо поставленные, но неправильно понятые задачи. Кроме того, ошибки в создании систем становились все менее доступны выявлению с помощью аппаратных средств или программного обеспечения, а наиболее катастрофические ошибки допускались на ранних этапах создания системы. Часто эти ошибки были следствием неполноты функциональных спецификаций или несогласованности между спецификациями и результатами проектирования. Проектировщики знали, что сложность систем возрастает и что определены они часто весьма слабо. Рост объема и сложности систем является жизненной реалией. Эту предпосылку нужно было принять как неизбежную. Но ошибочное определение системы не является неизбежным: оно – результат неадекватности методов создания систем.

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

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

В 1960-70 появляются следующие концепции:

• примерно 1967 – Структурное программирование (Structured programming) – Edsger Dijkstra,

• примерно 1975 – Структурное программирование Джексона (Jackson Structured Programming) – Michael A. Jackson.

Структурное программирование приводит к Структурному проектированию, что в свою очередь приводит к Структурному системному анализу:

• примерно 1975 – появление на рынке Метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique) – Douglas T. Ross;

• примерно 1975 – Структурное проектирование (Structured Design) – Larry Constantine, Ed. Yourdon и Wayne Stevens;

• примерно 1978 – Структурный анализ (Structured Analysis) – Tom De-Marco, Yourdon, Gane & Sarson, McMenamin & Palmer;

• в 1979 опубликован Структурный анализ и системная спецификация (Structured Analysis and System Specification) – Tom DeMarco.

В течение 1980х начинают появляться инструменты для автоматизации черчения диаграмм:

• 1981 – опубликована (и в 85-93 получает развитие) Методология IDEF0, основанная на SADT и инструментальных средствах создания диаграмм (разработана Дугласом Т. Россом, Douglas T. Ross).

• в 1983 впервые представлен Метод структурного системного анализа и проектирования SSADM (Structured Systems Analysis and Design Method), разработанный в UK Office of Government Commerce.

По аналогии с Computer-Aided design and Computer-Aided Manufacturing (CAD/CAM), использование этих инструментов было названо Computer-Aided Software Engineering (CASE).

Методы СА и СП (в частности, SSADM) сопровождаются нотациями (диаграммами), облегчающими взаимодействие между пользователями и разработчиками. Это были:

• структурные схемы (Structure Charts) – для структурного проектирования;

• диаграммы потоков данных (Data Flow Diagrams, DFD) – для структурного анализа;

• модели данных (Data Model Diagrams).

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

Примерно в 1990 появляется термин «инженерия разработки ПО» (Information Engineering, IE, James Martin), являющаяся логическим расширением структурных методов, появившихся в течение 1970х.

3 Метод структурного анализа и проектирования SADT

SADT (Structured Analysis and Design Technique) – это методология инженерии разработки ПО (software engineering) для описания систем в виде иерархии функций (функциональной структуры).

Структурный анализ возник в конце 60-х годов в ходе революции, вызванной структурным программированием. Метод SADT был предложен Дугласом Т. Россом как способ уменьшить количество дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшения контактов между пользователями и разработчиками и сглаживания перехода от анализа к проектированию. Дуглас Т. Росс часть своих PLEX-теорий относящихся к методологии и языку описания систем, назвал «Методология структурного анализа и проектирования» (SADT). Исходная работа над SADT началась в 1969 г.

Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, когда она была несколько пересмотрена сотрудниками SofTech, Inc. В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний.

Таким образом, к началу 70-х SADT представляет собой четкую формальную процедуру.

Появление SADT на рынке произошло в 1975 г. после годичного оформления в виде продукта.

К 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей и охватывавшими дюжину проблемных областей, в том числе телефонные сети, аэрокосмическое производство, управление и контроль, учет материально-технических ресурсов и обработку данных.

Ее широкое распространение в настоящее время в европейской, дальневосточной и американской аэрокосмической промышленности (под названием IDEF0) позволяет эти цифры существенно увеличить. Таким образом, SADT выделяется среди современных методологий описания систем благодаря своему широкому применению. Почему SADT имеет такое широкое применение?

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

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

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

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

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

SADT использует два типа диаграмм: 1) модели деятельности (activity models); 2) модели данных (data models).

SADT использует стрелки для построения этих диаграмм и имеет следующее графическое представление:

• главный блок (box), где определено названии ее процесса или действия;

• с левой стороны блока – входящие стрелки: входы действия;

• сверху – входящие стрелки: данные, необходимые для действия;

• внизу – входящие стрелки: средства, используемые для действия;

• справа – исходящие стрелки: выход действия.

SADT использует декомпозицию на основе подхода «сверху вниз». Каждый уровень декомпозиции содержит до 6 блоков.

SADT начинается с уровня (level) 0^[1], затем может быть детализирован на более низкие уровни (1, 2, 3, ...). Например, на уровне 1, блок уровня 0 будет детализирован на несколько элементарных блоков и так далее.

На уровне 1 действие «Manufacture computers», может быть разбито (declined), например на 4 блока:

1) получить электронные компоненты («receive electronic components»);

2) сохранить электронные компоненты («store electronic components»);

3) доставить электронные компоненты на сборочную линию («bring electronic components to the assembly line»);

4) собрать компьютеры («Assemble computers»).

Семантика стрелок для действий (activities):

• входы (Inputs) входят слева и представляют данные или предметы потребления (consumables), нужные действию (that are needed by the activity);

• выходы (Outputs) выходят справа и представляют данные или продукты, производимые действием (activity);

• управления (Controls) входят сверху и представляют команды, которые влияют на исполнение действия, но не потребляются. В последней редакции IDEF0 – условия, требуемые для получения корректного выхода. Данные или объекты, моделируемые как управления, могут быть трансформированы функцией, создающей выход;

• механизмы означают средства, компоненты или инструменты, используемые для выполнения действия; представляют размещение (allocation) действий.

Семантика стрелок для данных (data):

• входы (Inputs) – это действия, которые генерируют эти данные (are activities that produce the data);

• выходы (Outputs) потребляют эти данные (consume the data);

• управления (Controls) влияют на внутреннее состояние этих данных (influence the internal state of the data).

Роли SADT-процесса:

• авторы (Authors) – разработчики SADT модели;

• комментаторы (Commenters) – рецензируют (review) работу авторов;

• читатели (Readers) – возможные (the eventual) пользователи SADT диаграмм;

• эксперты (Experts) – те, от кого авторы получают специальную информацию о требованиях и ограничениях;

• технический комитет (Technical committee) – технический персонал, ответственный за рецензирование (reviewing) SADT модели на каждом уровне;

• библиотекарь проекта (Project librarian) – ответственный за все документы проекта;

• менеджер проекта (Project manager) – имеет полную техническую ответственность за системный анализ и проектирование (has overall technical responsibility the system analysis and design);

• аналитик (Monitor) (Chief analyst) – эксперт в области SADT, помогающий и консультирующий персонал проекта по использованию SADT;

• инструктор (Instructor) – обучает авторов и комментаторов SADT.

Этапы моделирования. Одним из важных моментов при проектировании ИС с помощью методологии IDEF0 является точная согласованность типов внутренних связей по их характеру^[2].

В Таблице 2^[3] представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4 – 6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.

Разработка SADT модели представляет собой итеративный процесс и состоит из нижеследующих условных этапов.

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

• что поступает в предметную область на «входе»;

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

• кто является ответственным за выполнение каждой из функций;

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

• что является результатом работы объекта (на выходе)?

На основе полученных результатов опросов создается черновик модели (Model Draft).

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

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

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

4 Метод структурного анализа и проектирования SSADM

SSADM (Structured Systems Analysis and Design Method) – системный подход к анализу и проектированию ИС.

SSADM как комплект стандартов для системного анализа и разработки приложений был разработан в начале 1980-х для Центрального агентства по компьютерам и телекоммуникациям (Central Computer and Telecommunications Agency, сейчас это Office of Government Commerce) – государственного учреждения UK, заинтересованного в использовании технологии в управлении.

Позже SSADM широко использовался для государственных ИТ-проектов в UK, затем нашел широкое применение во всем мире для проектирования ИС.

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

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

1. Логическое моделирование данных (Logical Data Modeling, LDM) – процесс идентификации, моделирования и документирования требований к разрабатываемой системе. Элементы логической модели данных:

• сущности (entities) – то, о чем фирме нужно записать информацию;

• связи (relationships) – ассоциации между сущностями.

2. Моделирование потоков данных (Data Flow Modeling) – процесс идентификации, моделирования и документирования движения данных в ИС. Моделирование потоков данных исследует:

• процессы (processes) – деятельность по преобразованию данных из одной формы в другую;

• накопители данных (data stores) – области (промежуточного) хранения данных (the holding areas for data);

• внешние сущности (external entities) – сущности, которые посылают данные в систему или получают данные из системы;

• потоки данных – маршруты, по которым данные могут двигаться.

3. Моделирование поведения сущностей (Entity Behavior Modeling) – процесс идентификации, моделирования и документирования событий, которые влияют на каждую сущность и последовательности, в которой эти события происходят.

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

Все три методологии во взаимосвязи друг с другом (are cross-referenced against each other) дают гарантию полноты и точности всего приложения.

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

1. Анализ осуществимости проектного решения (Feasibility Study) – анализ предметной области для определения сможет ли проектируемая система удовлетворить бизнес-требованиям.

2. Анализ требований (Requirements Analysis). На этом этапе определяются подлежащие разработке системные требования и моделируется текущая среда предприятия в терминах процессов с включением структур данных.

3. Спецификация требований (Requirements Specification). На этом этапе определяются детальные функциональные и нефункциональные требования и вводятся новые методики для определения необходимых процессов и структур данных.

4. Логическая системная спецификация (Logical System Specification). На этом этапе вырабатываются опции технической системы, логический проект обновлений, обработка запросов и системные диалоги.

5. Физический проект (Physical Design). На этапе физического проектирования создается физический проект базы данных и комплект программных спецификаций с использованием логической и технической системных спецификаций.

В отличие от RAD, который подразумевает параллельное выполнение этапов, SSADM строит каждый этап на основе работы, которая была предписана на предыдущем этапе без отклонений от модели.

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

Стадия 0. Оценивание реализуемости (необязательно).

- Определить рамки и составить план разработки.

- Определить первоначальный вариант требований.

- Выбрать вариант оценивания реализуемости.

- Оформить отчёт о возможности создания.

Стадия 1. Предпроектное исследование.

- Определить рамки предпроектного исследования.

- Определить основные требования.

- Изучить процессы обработки информации в существующей системе.

- Изучить данные, обрабатываемые в существующей системе.

- Разработать логическое описание существующей системы.

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

Стадия 2. Выбор варианта автоматизации.

Стадия 3. Разработка технического задания.

- Разработать общие требования к автоматизируемым функциям.

- Разработать требуемую логическую модель данных.

- Уточнить требования и функциональные задачи.

- Уточнить логическую модель данных.

- Разработать демонстрационный прототип.

- Разработать требования к обработке данных.

- Уточнить цели разработки.

- Оформить техническое задание на создание АС.

Стадия 4. Выбор варианта технической реализации.

- Разработать варианты технической реализации,

- Выбрать вариант технической реализации.

Стадия 5. Разработка логического проекта.

- Определить порядок диалогового взаимодействия.

- Разработать постановки задач модификации баз данных.

- Разработать постановки информационных задач.

- Завершить разработку логического проекта.

Стадия 6. Физическое проектирование.

- Подготовить план физического проектирования.

- Разработать физическую реализацию баз данных.

- Разработать спецификации требований к программным компонентам.

- Оптимизировать физическую структуру баз данных.

- Уточнить спецификации требований к программным компонентам.

- Согласовать интерфейс между задачами и базами данных.

- Оформить физический проект.

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

Заключение

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

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

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

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

SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем. SADT была создана и опробована на практике в период с 1969 по 1973 г. Эта методология возникла под сильным влиянием PLEX, концепции клеточной модели человеко - ориентированных функций Хори, общей теории систем технологии программирования и даже кибернетики. С 1973 г. сфера ее использования существенно расширилась для решения задач, связанных с большими системами, такими, как проектирование телефонных коммуникаций реального времени, автоматизация производства (САМ), создание программного обеспечения для командных и управляющих систем, поддержка боеготовности. Она с успехом применялась для описания большого количества сложных искусственных систем из широкого спектра областей (банковское дело, планирование промышленного производства, системы наведения ракет, методология планирования, технология программирования). Причина такого успеха заключается в том, что SADT является полной методологией для создания описания систем, основанной на концепциях системного моделирования.

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

В SSADM применяется нисходящий подход к построению интегрированных функциональных, информационных и событийных моделей. При моделировании, функций используются классические DFD (включающие только базовые объекты: процесс, поток данных, хранилище данных, внешнюю сущность) с миниспецификациями на структурированном естественном языке. Моделирование данных осуществляется с использованием нотации LDS (Logical Data Structure), являющейся диалектом ER-модели. Для событийного моделирования используются диаграммы истории жизни сущностей ELN (Entity Life History), поддерживающие индикаторы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора.

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

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

- обеспечение создания корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;

- создание системы с заданным качеством в заданные сроки и в рамках установленного бюджетирования;

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

- обеспечение преемственности разработки.

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

Список литературы

1. Инюшкина О.Г., Кормышев В.М. Исследование систем управления при проектировании информационных систем: учебное пособие. / О.Г. Инюшкина, В.М. Кормышев. Екатеринбург: «Форт-Диалог Исеть», 2013. 370 с.

2. Гольдштейн С.Л., Инюшкина О.Г. Практика использования информационных технологий и систем (на примерах управления организацией): учебное пособие / С.Л. Гольдштейн, О.Г. Инюшкина. Екатеринбург: УрФУ, 2010. 185 с.

3. Инюшкина О.Г., Кормышев В.М. Управление знаниями в информационных системах (монография). / О.Г. Инюшкина, В.М. Кормышев, Екатерин-бург: УрФУ, 2012. 212 с.

4. Rob M.A. Issues of Structured vs. Object-Oriented methodology of systems analysis and design. [Электронный ресурс] Режим доступа: PDF.

5. IDEF4 Object-Oriented Design Method. [Электронный ресурс] Режим доступа: http://www.idef.com/IDEF4.htm.

6. Wikipedia: UML [Электронный ресурс] Режим доступа: https://ru.wikipedia.org/wiki/UML.

7. Буч Г., Рамбо Д., Джекобсон А. Язык UML Руководство пользователя. [Электронный ресурс] Режим доступа: PDF.

8. Övergaard G., Selic B., Bock C., Björkander M. Behavioral Modeling. UML Revision Task Force Object Modeling with OMG UML Tutorial Series. [Электронный ресурс] Режим доступа: 01-2_Bock_Behavioral_ModelingTutorial.pdf (http://www.omg.org/).

9. Pefkaros K. Using object-oriented analysis and design over traditional structured analysis and design // International Journal of Business Research Publisher. 03/01/2008 [Электронный ресурс] Режим доступа: http://www.freepatentsonline.com/article/International-Journal-Business-Research/190463129.html.

10. Маклаков С.В. «ERwin и BPwin. CASE-средства разработки информационных систем» / С.В. Маклаков, 2-е изд., испр. и доп., М. : Диалог-Мифи, 2001. – 304 с.М: «Диалг-МИФИ», 2001.

11. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 1998. – 176 с. Программное обеспечение. [Электронный ресурс] Режим доступа: www.interface.ru.

12. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом. PDF, www.complexdoc.ru.

13. Дэвид А. Марка, Клемент МакГоуэн. Предисловие Дугласа Т. Росса. Методология структурного анализа и проектирования SADT Structured Analysis & Design Technique. [Электронный ресурс] Режим доступа: http://www.pqm-online.com/assets/files/lib/books/marka.pdf

Приложение А

Рисунок 1 – Пример уровня 0

Приложение Б

Таблица 1 - Типы и связей и их значимость

Таблица 2 - Типы связностей

1. Пример уровня 0 – см. Приложение А, Рисунок 1 ↑

2. См. Приложение Б, Таблица 1 - Типы и связей и их значимость ↑

3. См. Приложение Б, Таблица 2 - Типы связностей ↑