Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (ПОНЯТИЕ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ И ЕЕ ОСОБЕННОСТЕЙ)

Содержание:

Введение

Информационные технологии позволяют справится с постоянно увеличивающейся организационной сложностью предприятия. Информационные системы всегда связаны с деятельностью человека (организации), будь-то управление движением транспорта, дозировкой лекарств, расчёт заработной платы, поиском веб-ресурсов, реконструкцией археологических объектов и др. Информационная система всегда только обслуживает основную деятельность организации/человека. Как правило, в организации эксплуатируется несколько видов информационных систем. Наличие тесной связи информационной системы и обслуживаемой ею деятельности позволяет говорить о предметной области информационных систем — объектах той деятельности, с которой эта система связана, и отношениях между этими объектами. Для примера, в информационной системе библиотеки объектами предметной области являются издания (книги, журналы, эстампы, музыкальные записи и др.), средства хранения изданий (хранилища и стеллажи), читатели, библиографы и др. А в деятельности кадрово-бухгалтерскогоотдела объектами предметной области информационной системы будут сотрудники, должности, рабочее время, штатное расписание, премии и надбавки, налоги и прочее[1].

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

Таким образом, в данной курсовой работепроисходит анализ и сравнение трех самых популярных методов разработки ЭИС (XP, RUP и DSDM), которые в настоящее время являются самыми обсуждаемыми на рынке инструментов разработки ИС и сравниваются по различным аспектам.

Задачами данной курсовой работы являются:

• рассмотрение понятий экономической информационной системы и ее особенностей;
• изучение объектно-ориентированного подхода (ООП) к анализу и проектированию ЭИС;
• проведение анализа и оценки средств реализации ООП.

ГЛАВА 1. ПОНЯТИЕ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ И ЕЕ ОСОБЕННОСТЕЙ

Система управления предприятием состоит из управляющей части и управляющих процессов. Взаимовлияние и воздействие этих элементов друг на друга осуществляется за счет передачи информации. Информация об объекте управления и управляющих воздействиях, средства сбора, передачи, обработки и хранения информации являются элементами информационной системы предприятия. Таким образом, термин "информационная система" обозначает систему, предназначенную для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию [2].

Информационные системы (ИС) имеют ряд отличий от стандартных прикладных программ и систем.

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

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

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

Таким образом, при разработке ИС решаются две задачи:

- разработка базы данных, которая будет хранить информационные данные;

- разработка графического интерфейса пользователя клиентского приложения [3].

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

Целевое назначение информационной системы сводится к достижению следующих целей:

• обеспечивать для каждого сотрудника предприятия возможность пополнения корпоративных знаний;
• сохранять корпоративные знания как составную часть ИРП;
• обеспечивать совместное использование сотрудниками предприятия текущих и ретроспективных корпоративных знаний.

Для осуществления этих целей информационная система, опираясь на свои подсистемы, должна выполнять следующие функции:

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

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

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

К обработке информации в ЭИС предъявляются следующие требования:

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

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

• системы обработки данных (EDP – electronic data processing);
• информационной системы управления (MIS – management information system);
• системы поддержки принятия решений (DSS – decision support system)[5].

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

ГЛАВА 2. РЕАЛИЗАЦИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА К СОЗДАНИЮ ЭИС

2.1 Подходы к анализу и проектированию ЭИС

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

1. Обеспечения устойчивого функционирования системы и достижения общей цели;
2. Адаптивности к изменениям внешней среды и управляемости посредством воздействия на элементы системы;
3. Обучаемости путем изменения структуры системы в соответствии с изменением целей системы.

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

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

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

С этой точки зрения дизайна ЭИС сводится к согласованной формализации проектных решений на разных этапах жизненного цикла ЭИС:

• планирование и анализ требований,
• технический и детальный дизайн,
• внедрение и функционирование ЭИС.

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

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

Основной недостаток метода: возникновение проблем при объединении существующих систем.

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

Этапы системного проектирования:

1) определение целей и задач управления организацией;

2) создание модели организации, главное требование к которой – системная целостность; каждое изменение элемента модели требует перепроверки и согласования как «cверху-вниз», так и «cнизу-вверх»;

3) создание корпоративной ИС на основе этой модели.

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

2.2. ООП анализ и проектирование

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

Основная идея объектно-ориентированного анализа и проектирования информационных систем состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий или сущностей).

В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области.

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

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

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

Базовыми составляющими объектно-ориентированного подхода являются:

- унифицированный процесс;

- унифицированный язык моделирования;

- шаблоны проектирования.

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

Неотъемлемой частью унифицированного процесса является UML – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода. Следует отметить, что Унифицированный процесс иUMLразрабатывались совместно.

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

Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML(например, диаграммы классов, последовательности и/или коммуникации), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО.

Наиболее популярными методологиями, поддерживающими данный подход, в настоящий момент являются:

-унифицированный процесс(Unified Process, UP);

-экстремальное программирование(eXtreme Programming, XP);

-гибкое моделирование(Agile Modeling, AM).

ООП имеет ряд преимуществ:

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

- сущности реального мира, как правило, обладают определеным поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга;

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

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

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

Типичный процесс объектно-ориентированной разработки выглядит следующим образом (рис.2.1):

Рисунок 2.1.Процесс объектно-ориентированного проектирования

Объектно-ориентированная технология проектирования ИС включает в себя следующие компоненты:

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

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

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

Отличительными чертами предлагаемой методологии являются следующие:

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

2.3 Анализ и оценка средств реализации ООП

Существует два типа объектно-ориентированных моделей системной архитектуры:

- статические модели, описывающие структуру системы как классы объектов и взаимоотношений между ними, которые документируются на данном этапе, являются отношениями обобщения, отношениями "используют - используются" и структурными отношениями;

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

В языке моделирования UML поддерживается ряд возможных статических и динамических моделей:

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

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

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

Модель подсистемы является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов. В UMLпакеты являются структурами инкапсуляции и не отображаются непосредственно в объектах разрабатываемой системы. Существует несколько способов создания, применения и введения новых определений для моделей ООП с использованием диаграмм вариантов использования сценариев, диаграмм действий, диаграмм класс/объект, а также диаграмм сотрудничества, взаимодействия, перехода состояния, контекста данных и словаря данных. Некоторые вводятся сверху-вниз, другие - снизу-вверх, и все они итеративно определяются заново с помощью сотрудничества.

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

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

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

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

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

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

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

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

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

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

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

В некоторых случаях возможно генерировать программы или фрагменты программ на основе информации, представленной в системной модели. Поскольку в моделях не предусмотрена детализация низкого уровня, генератор программного кода не в состоянии сгенерировать законченный комплекс программ. Обычно необходимы программисты для завершения автоматически сгенерированных программ [9,10].

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

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

• • технологический комплекс разработки программного обеспечения RUP (RationalUnifiedProcess) фирмы RationalSoftware;
  • технология разработки программного обеспечения ExtremeProgramming (XP);
  • комплектспециальныхинструментальныхсредствразработки динамических систем – DSDM (DynamicSystemDevelopmentMethod).

Один из способов проектированияэкономической информационной системы - RUP (Rational Unified Process), разработанный Rational Corporation на базе унифицированного языка моделирования UML. Это итеративный метод для объектно-ориентированных систем, который использует сценарии для моделирования требований и построения основы системы.

Жизненный цикл разработки ЭИС по методологии RUP делится на четыре этапа: начало, проектирование, построение и переход (внедрение) (рис.2.2). Затем каждая фаза делится на итерации. Каждая итерация имеет цель создать неотъемлемую часть программного обеспечения. Время, необходимое для каждой итерации, может составлять от двух до 26 недель .

Рисунок 2.2. Жизненный цикл разработки ПО ЭИС RUP

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

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

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

3. Фаза построения (разработки). На этом этапе завершаются все работы по разработке, все части интегрированы. Происходит выпуск предварительных версий ПО ЭИС.

4. Фаза внедрения (перехода). На этом этапе программное обеспечение является полностью работоспособным.Изменения могут вноситься, если пользователи ЭИС дают какую-либо обратную связь, и если все еще существует какая-либо критическая проблема. Проводятся бета-тесты ПО, обучения и тренинги для пользователей, а также подготавливается техническая документация для пользователей [11].

Рассмотрим плюсы и минусы использования такого подхода при проектировании и создании ЭИС (табл.2.1):

Таблица 2.1. Плюсы/минусы методологии RUP:

Плюсы использования RUP	Минусы использования RUP
RUP является итеративным методом разработки; Основан на применении сценариев; Является легко управляемым и отслеживаемым; Создает множество артефактов в процессе разработки; Процесс разработки легко настраивается.	Необходимо большое количество ресурсов для процессной обработки; Пользователь практически не вовлекается в процесс проектирования; Связан с применением дорогостоящих инструментов проектирования и разработки.

В качестве графической нотации в RUP используется Unified Modeling Language (UML), являющийся стандартом для представления объектных моделей. В UML артефакты разработки представляются диаграммами, описывающими структуру программы и ее поведение. В рамках данного средства существует большое количество вариантов нотаций диаграмм, которые позволяют достаточно детально описать компоненты, состав и процессы программ.

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

Жизненный цикл проектирования и разработки ПО ЭИС в рамках экстремального программирования состоит из следующих фаз (рис. 2.3):

Рисунок 2.3. Жизненный цикл проекта в соответствии с методологией Экстремального программирования

Рассмотрим более подробнее данные фазы:

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

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

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

4. Стадия продуцирования.На этом этаперазрабатываемая система готова к первому выпуску, но перед выпуском тестируется.При возникновении новых идей и предложений, происходит их фиксация для позднейшей реализации. Команда разработчиков XP проводит работу с обеих сторон: на стороне поддержки клиентов, а также на стороне разработки и внедрения новых итераций. Это может снизить скорость работы разработчиков и, как следствие, привести к расширению команды и ее реструктурированию.По окончанию этапа происходит документирование всех результатов, завершение всех работ по дизайну, архитектуре и коду ПО ЭИС [12].

Рассмотрим преимущества и недостатки XP методологии разработки ПО ЭИС(табл. 2.2):

Таблица 2.2 . Плюсы/минусы рассматриваемой методологии XP

ПлюсыиспользованияXP	МинусыиспользованияXP
ХР это итерационный метод разработки; Основан на доверии к разработчикам; Клиенты принимают бизнес решения при создании системы; Постоянное совершенствование процесса; Нет привязки с дорогостоящему инструментарию; Разработка основана на технических решениях.	Нет уточнения артефактов; Большая вовлеченность клиентов в процесс разработки; Успех зависит от уровня разработчиков; Из-за недостатка структуры и документации не подходит для крупных проектов; Так как гибкие методологии функционально-ориентированные, нефункциональные требования к качеству продукта сложно описать в виде пользовательских историй.

Dynamic System Development Method (DSDM). В 1995 году сообщество разработчиков программного обеспечения для планирования ресурсов предприятия (ERP) разработало и предложило для использования своё методологическое решение для более быстрой разработки приложений (RAD). Оно называется методом разработки динамических систем (DSDM), и поддерживается всемирным консорциумом,который включает такие достаточно крупные корпорации среди которых можно назвать IBM, Oracle и Hewlett-Packard.

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

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

Рисунок 2.4. Схема создания ПО ЭИС по методологии DSDM

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

Процесс разработки ПО ЭИС по методологии DSDM состоит из нескольких этапов:

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

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

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

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

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

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

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

Рассмотрим преимущества и недостатки DSDM методологии разработки ПО ЭИС(табл. 2.2):

Таблица 2.2 . Плюсы/минусы рассматриваемой методологии DSDM

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

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

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

Заключение

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

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

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

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

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

В настоящее время существует большое разнообразие инструментальных средств проектирования ЭИС, реализующих объектно-ориентированный подход. В данной курсовой работе был проведен анализ и сравнение трех самых популярных средств разработки ЭИС (XP, RUP и DSDM), которые в настоящее время являются самыми обсуждаемыми на рынке инструментов разработки ИС, и проведено их сравнение по различным аспектам.

Список использованной литературы

1. Никитин А., Рачковская И., Савченко И. Управление предприятием (фирмой) с использованием информационных систем. Учебное пособие. – Litres, 2018. – 182с.

2. ISO/IEC 2382:2015 Information technology [Электронный ресурс]. Режим доступа: https://www.iso.org/standard/63598.html

3. Титоренко Г. А. и др. Информационные системы и технологии управления. – Общество с ограниченной ответственностью" Издательство" Юнити-Дана", 2013. – 250с.

4. Зайцев Д. Р. Применение информационных технологий и систем для повышения эффективности управления организацией //Территория науки. – 2015. – №. 2.

5. Арапова А. Е. Проектирование экономических информационных систем // Проблемы и перспективы экономических отношений в постиндустриальном обществе: сборник статей Международной. – 2017. – С. 31.

6. Инюшкина О. Г. Проектирование информационных систем (на примере методов структурного системного анализа): учебное пособие / О.Г. Инюшкина; [науч. ред. Т. А. Матвеева]. — Екатеринбург: «Форт-Диалог Исеть», 2014. — 240 с.

7. Бредихин А. В., Кичигина М. Б. Использование объектно-ориентированных технологий в разработке приложения проектирования бизнес-логики системы // Новые технологии в научных исследованиях, проектировании, управлении, производстве: труды Междунар. науч.-техн. конф. Воронеж: ФГБОУ ВО «Воронежский государственный технический университет», 2017, Т. 1, 404 с. ISBN 978-5-7731-0567-1. – 2017. – С. 34.

8. Гудков К. В., Гудкова Е. А. Объектно-ориентированное моделирование информационной системы сбора, обработки и хранения данных //Труды Международного симпозиума «Надежность и качество». – 2014. – Т. 1.

9. Буч Г., Якобсон И., Рамбо Д. Язык UML. Руководство пользователя. – Litres, 2017.– 496с.

10. Мэтт В. Объектно-ориентированное мышление. – Издательский дом "Питер", 2014.– 304с.

11. RUP methodology documentation [Электронный ресурс]. Режим доступа: https://www.ibm.com/developerworks/rational/library/content /03July/1000/1251/1251_bestpractices_TP026B.pdf

12. ХР methodology documentation [Электронный ресурс]. Режим доступа: http://agilemodeling.com/essays/agileModelingXP.htm

13. DSDM methodology documentation [Электронный ресурс]. Режим доступа: https://www.agilebusiness.org/content/products-0