Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы(Теоретические аспекты структурного анализа).pdf

ВВЕДЕНИЕ

Теория систем впервые была применена в точных науках и технике как вклад школы науки управления. Как самостоятельная дисциплина теория систем оформилась в 40-50-х годах XX века.

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

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

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

Широкое признание теории, осознание системности мира началось в 1948 году после публикации американским математиком Н.Винером книги «Кибернетика». Первоначально он определяет кибернетику как «науку об управлении и связи в животных и машинах» (аналогии процессов в живых организмах и машинах), позже анализирует с позиций кибернетики процессы, происходящие в обществе.

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

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

---

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

Развитием системного анализа занимались ученые самых различных специальностей (физики, философы, геологи, медики, биологи). Это указывает на то, что положение ОТС находится в центре человеческих знаний. По степени общности ОТС ставят на один уровень с математикой и философией (Дж.ван Гиг).

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

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

Предмет исследования – экономическая информационная система.

Глава 1. Теоретические аспекты структурного анализа

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

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

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

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

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

---

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

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

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

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

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

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

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

В этот период большинство программ было создано на Cobol и Fortran, потом на C и BASIC. Это было новым положительным сдвигом в направлении проектирования и программирования, но при этом не было стандартных методологий для документирования требований и самих проектов.

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

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

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

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

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

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

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

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

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

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

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

---

И, тем не менее, с этой моделью создания системы, ориентированной на управление, постоянно возникали сложности. Эксплуатационные расходы, возникавшие после сдачи системы, стали существенно превышать расходы на ее создание и продолжали расти с огромной скоростью из-за низкого качества исходно созданной системы. [7, c.151]

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

Например, исправление ошибки на стадии проектирования стоит в 2 раза, на стадии тестирования – в 10 раз, а на стадии эксплуатации системы – в 100 раз дороже, чем на стадии анализа.

На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях.

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

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

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

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

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

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

Кроме того, ошибки в создании систем становились все менее доступны выявлению с помощью аппаратных средств или программного обеспечения, а наиболее катастрофические ошибки допускались на ранних этапах создания системы. [2, c.187]

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

---

Эту предпосылку нужно было принять как неизбежную. Но ошибочное определение системы не является неизбежным: оно – результат неадекватности методов создания систем.

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

Для помощи в управлении большим и сложным ПО с конца 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 DeMarco, 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) сопровождаются нотациями (диаграммами), облегчающими взаимодействие между пользователями и разработчиками. [3, c.19]

Это были:

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

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

---