Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы(Теоретические аспекты структурного анализа).pdf
Добавлен: 17.05.2023
Просмотров: 60
Скачиваний: 4
ВВЕДЕНИЕ
Теория систем впервые была применена в точных науках и технике как вклад школы науки управления. Как самостоятельная дисциплина теория систем оформилась в 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) – для структурного анализа;