CC BY
1775
2006
НАУЧНЫЙ ВЕСТНИК МГТУ ГА серия Прикладная математика. Информатика
№ 105
УДК 681.518
ИНФОРМАЦИОННЫЕ СИСТЕМЫ:
МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ
А.А. ЕГОРОВА, С.А. КОЗЛОВ
Рассматриваются вопросы классификации существующих методов и средств проектирования информационных систем (ИС), проводится анализ их применимости для создания ИС различной конфигурации и назначения.
Введение
Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы (ИС) стали необходимым инструментом практически во всех сферах деятельности человека.
Под информационной системой, следуя [1], будем понимать комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, информационные ресурсы, а также системный персонал, обеспечивающий поддержку динамической информационной модели.
ИС стала неотъемлемой частью функционирования практически любой организации, поэтому нет необходимости обсуждать вопрос актуальности разработки и внедрения ИС. Однако вопрос системности подходов к их проектированию и качества разработки до сих пор является злободневным.
Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США за 2004 год, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом в срок были выполнены лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.
В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности. Одной из задач, возникающих при разработке, является нахождение общего языка между заказчиком и проектировщиком системы, причем достаточно формального и адекватного проблеме.
Еще одной проблемой является порелизное внедрение систем, а это значит, что разработка обязательно должна быть модульной. Такой подход, может быть, и не позволяет сократить сроки внедрения системы в целом, но, учитывая продолжительные сроки разработки и внедрения ИС, можно говорить о сокращении срока окупаемости системы.
Кроме того, продолжительные сроки разработки и внедрения ИС порождают еще и организационные проблемы (например, изменение команды разработчиков), что при бессистемном подходе может еще увеличивать сроки.
Даже не проводя полный анализ сложности процедуры создания ИС, можно сказать, что правильный выбор методов и средств проектирования, если и не страхует от ошибок, то, по крайней мере, снижает вероятность их «в разы».
1. Классификация информационных систем
Для более полного определения проблемы приведем классификацию ИС, не претендующую на полноту. Информационные системы можно классифицировать по целому ряду различных признаков [2]. В основу классификации положены наиболее существенные признаки, определяющие функциональные возможности и особенности построения современных систем. В
зависимости от объема решаемых задач, используемых технических средств, организации функционирования информационные системы делятся на ряд групп (классов).
По типу хранимых данных ИС можно разделить на фактографические и документальные. Фактографические системы предназначены для хранения и обработки структурированных данных в виде чисел и текстов, являющихся субъектами различных операций. В документальных системах информация представлена в виде неструктурированных документов, состоящих из наименований, описаний, рефератов и текстов. Поиск по неструктурированным данным осуществляется с использованием семантических признаков. Отобранные документы предоставляются пользователю, а обработка данных в таких системах практически не производится.
По уровню управления ИС выделяют 4 уровня.
Информационная система оперативного уровня - поддерживает исполнителей, обрабатывая данные о производственных фактах и событиях. Информационная система оперативного уровня является связующим звеном между фирмой и внешней средой. Задачи, цели, источники информации и алгоритмы обработки на оперативном уровне заранее определены и в высокой степени структурированы.
Информационные системы специалистов - поддерживают работу с данными и знаниями, повышают продуктивность и производительность работы инженеров и проектировщиков. Задача подобных информационных систем - интеграция новых сведений в организацию и организация документооборота.
Информационные системы уровня менеджмента - используются работниками среднего управленческого звена для мониторинга, контроля, принятия решений и администрирования функционирования предприятия. Основные функции этих информационных систем:
- сравнение текущих показателей с аналогичными показателями за предыдущий период;
- составление периодических отчетов за определенный период (выдача отчетов по текущим событиям в ИС данного уровня не входит, являясь атрибутом ИС оперативного уровня);
- обеспечение доступа к архивной информации.
Стратегическая информационная система - ИС, обеспечивающая поддержку принятия решений по реализации стратегических перспективных целей развития организации. ИС стратегического уровня являются инструментом решения неструктурированных задач, осуществления долгосрочного планирования. Они призваны создать общую среду поддержки принятия решений в различных ситуациях. Некоторые стратегические системы обладают ограниченными аналитическими возможностями.
По степени интеграции ИС различают на крупные, средние, малые и локальные системы.
Можно было привести классификацию систем по назначению, однако этот критерий вряд ли можно считать актуальным, а классификацию - полной. Однако стоит заметить, что анализ современного состояния рынка ИС показывает устойчивую тенденцию роста спроса на информационные системы организационного управления. Причем спрос продолжает расти именно на интегрированные системы управления. Автоматизация отдельной функции, например, бухгалтерского учета или сбыта готовой продукции, считается уже пройденным этапом для многих предприятий [3].
2. Этапы проектирования информационных систем
Проектирование ИС охватывает три основные области [4]:
■ проектирование объектов данных, которые будут реализованы в базе данных;
■ проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
■ техническое проектирование с учетом конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных.
Процесс создания ИС состоит из ряда этапов, ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).
Обычно выделяют следующие этапы создания ИС [5]: анализ и формирование требований к системе, проектирование, реализация, тестирование и внедрение.
Целью первого этапа является формирование требований к ИС, корректно и точно отражающих цели и задачи заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выявить и формализовать эти потребности, отобразив их на языке моделей для обеспечения должного уровня соответствия целям и задачам организации [6].
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых, дорогостоящих, ресурсоёмких и тяжелых для исправления в случае допущения ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа, либо использование типового проектирования с неверно выбранной степенью декомпозиции, либо неудовлетворительным результатом выбора базового программного обеспечения.
На этапе проектирования, прежде всего, формируются модели данных. При этом построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных [7].
Разнообразие задач, решаемых с помощью ИС, привело к появлению множества разнотипных систем, отличающихся принципами построения и заложенными в них правилами обработки информации. При этом существует значительное количество методологий проектирования ИС, зависящих от их типа.
3. Каноническое проектирование ИС
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90 [8].
Типовая методология построения информационных систем содержит три основных компонента:
■ набор моделей (типов моделей, если строго) для описания требований к ИС, проектных и программных решений. Каждая модель обычно содержит как определение конструкций (нотацию), так и правила их использования (синтаксис);
■ методика применения набора моделей для построения информационной системы. Методика обычно использует фиксированный набор моделей и определяет последовательность их построения для описания различных аспектов создаваемой системы;
■ процесс организации проектных работ. Включает различные технологии - планирования, управления проектом, контроля качества и т. д.
Можно выделить модели структурного подхода, объектного подхода, саБе-средств.
Структурный подход обычно ассоциируется с раздельным построением модели функций (чаще всего диаграммы потоков данных) и модели данных (чаще всего диаграммы "сущность -связь"). К сожалению, единой нотации и правил построения этих моделей не существует. Поэтому большинство СЛБЕ-систем, обеспечивающих построение моделей структурного подхода, являются закрытыми и несовместимыми с другими аналогичными системами. Не удалось также
сформировать общепринятый стандарт передачи информации между CASE-репозитариями. Невозможность переноса моделей между инструментами разных производителей является препятствием к внедрению технологий повторного использования, созданию библиотек стандартных решений для разных видов деятельности, интеграции средств моделирования со средствами планирования, управления проектами, тестирования и т. д. [2, 9, 10].
В рамках структурного подхода выделяются следующие средства моделирования [11]:
■ диаграмма потоков данных/модель бизнес-процессов (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 и других. При этом следует понимать, что основным направлением объектного подхода является анализ бизнес-операций [12, 13].
Нередко структурный и объектный подходы противопоставляют друг другу. Во многом это результат конкуренции производителей технологий и инструментальных средств. Однако пользователям продуктов и методик такое противопоставление ничего, кроме вреда, не приносит. Сами по себе наборы моделей не определяют принципов построения систем, являясь лишь средством описания объектов автоматизации.
Другая распространенная ошибка - связывание структурного подхода с функциональной декомпозицией программного обеспечения. Диаграмма потоков данных является моделью, использующей декомпозицию функций, но эта декомпозиция является лишь способом разбиения модели на уровни детализации и не влияет на способ структуризации программного обеспечения.
По определению все процессы диаграммы потоков данных выполняются асинхронно и каждый процесс иерархически вложен ровно в один родительский процесс. Для спецификации последовательности выполнения процессов нужно использовать особую разновидность модели
- диаграмму функциональной зависимости.
Диаграмма вариантов использования (Use-case) очень удобна для описания функциональности системы. Каждый вариант использования - определенный сервис, который должна обеспечить система. В этих понятиях удобно описывать функции системы, объекты тестирования, результат для приема у исполнителя. Также обеспечивается трассировка реализации исходных требований к системе. Большим недостатком данной модели является отсутствие изображения
входных и выходных данных, а также информационных связей между вариантами использования. Нет единой картины взаимодействующих функций. Поэтому как средство описания бизнес-процесса модель вариантов использования имеет существенные ограничения. Это скорее структурированный список операций, нежели модель взаимодействующих операций.
Моделирование деловых процессов, как правило, выполняется с помощью Case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др.
Существуют следующие разновидности моделирования ИС:
- функциональное моделирование (IDEF0);
- реляционное моделирование (IDEFI, IDEFIX);
- описание бизнес-процессов (IDEF3);
- диаграммы потоков данных (DFD)[14].
Модель в Case-средствах рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных [15].
Наиболее распространённым языком моделирования бизнес-процессов является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации [16].
Модель IDEF0 используется на начальных этапах создания ИС для высокоуровневого моделирования (построения модели организации, которая адекватна предметной области и содержит в себе знания всех участников бизнес-процессов организации).
IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения (ракурса).
Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).
Обычно сначала строится модель существующей организации работы - AS-IS (как есть). Анализ функциональной модели позволяет выявить наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.
Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход - это тоже бизнес-процесс.
Наличие в диаграммах DFD элементов для обозначения источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, - методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектами, являющимися частью этих процессов.
4. Имитационное моделирование
Метод функционального моделирования позволяет оптимизировать существующие на предприятии бизнес-процессы, однако для оптимизации конкретных технологических операций функциональной модели может быть недостаточно. В этом случае целесообразно использовать имитационное моделирование [17,18].
Имитационное моделирование - это метод, позволяющий строить модели, учитывающие время выполнения операций, и обеспечивающий наиболее полные средства анализа динамики бизнес-процессов. Имитационные модели описывают не только потоки сущностей, информации и управления, но и различные метрики. Полученную модель можно «проиграть» во времени и получить статистику происходящих процессов так, как это было бы в реальности. В имитационной модели изменения процессов и данных ассоциируются с событиями. «Проигрывание» модели заключается в последовательном переходе от одного события к другому [13].
Связь между имитационными моделями и моделями процессов заключается в возможности преобразования модели процессов в имитационную модель. Имитационная модель дает больше информации для анализа системы, в свою очередь результаты такого анализа могут быть причиной модификации модели процессов.
Одним из наиболее эффективных инструментов имитационного моделирования является система ARENA, разработанная фирмой System Modeling Corporation. Система позволяет строить имитационные модели, проигрывать их и анализировать результаты.
5. Типовое проектирование ИС
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т. д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР) - это тиражируемое (пригодное к многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:
■ элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
■ подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
■ объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
Рассмотрим достоинства и недостатки использования ТПР различных классов.
Основным достоинством элементарных ТПР, которые используются, в первую очередь, для реализации библиотек методо-ориентированных программ, является обеспечение применения модульного подхода к проектированию и документированию ИС, а недостатки - большие затраты времени на сопряжение разнородных элементов вследствие информационной, программ-
ной и технической несовместимости, а также большие затраты времени на доработку ТПР отдельных элементов.
Подсистемные ТПР применяются для реализации пакетов прикладных программ. Их несомненными достоинствами является возможность достижения высокой степени интеграции элементов ИС, осуществления модульного проектирования, параметрической настройки компонентов на различные объекты управления, сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации. Тем не менее, адаптивность ТПР недостаточна с позиции непрерывного инжиниринга деловых процессов, возникают проблемы в комплексировании разных функциональных подсистем, особенно в случае использования решений нескольких производителей программного обеспечения.
Для отраслевых проектов ИС используются объектные ТПР. Их достоинства: комплексиро-вание всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости; открытость архитектуры; масштабируемость и конфигурируемость. Однако существует проблема привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необходимость изменения организационно-экономической структуры объекта автоматизации[16].
6. Моделирование данных
Одной из основных частей информационного обеспечения является информационная база. Для её разработки выполняется моделирование данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD - диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).
Существуют два уровня представления модели - логический и физический.
Логический уровень - это абстрактный взгляд на данные, но данные представляются так, как выглядят и могут называться так, как они называются в реальном мире, например, "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например, на основе модели процессов. Отметим, что логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д.
7. Проектирование хранилищ данных
Отдельно следует остановиться на таком виде ИС, как информационные хранилища данных (ИХД). В ИХД помещают данные, которые редко меняются. Хранилища ориентированы на выполнение аналитических запросов, обеспечивающих поддержку принятия решений для руководителей и менеджеров. При проектировании ИХД данных необходимо выполнять следующие требования:
- хранилище должно иметь понятную для интеграции структуру данных;
- должны быть выделены статические данные, которые модифицируются по расписанию (ежедневно, еженедельно, ежеквартально);
- должны быть упрощены требования к запросам для исключения запросов, требующих множественных утверждений БОЬ в традиционных реляционных СУБД;
- должна обеспечиваться поддержка сложных запросов БОЬ, требующих обработки миллионов записей.
Как видно из этих требований, по своей структуре реляционные СУБД существенно отличаются от хранилищ данных. Нормализация данных в реляционных СУБД приводит к созданию множества связанных между собой таблиц. Выполнение сложных запросов неизбежно приводит к объединению многих таблиц, что значительно увеличивает время отклика. Проектирование хранилища данных подразумевает создание денормализованной структуры данных, ориентированных в первую очередь на высокую производительность при выполнении аналитических запросов. Нормализация делает модель хранилища слишком сложной, затрудняет ее понимание и снижает скорость выполнения запроса [19].
8. Заключение
Проведенный краткий обзор состояния вопроса указывает на необходимость развития существующей методологии построения информационных систем. Следует признать, что аналитическая составляющая этого процесса, обеспечивающая непосредственно разработку системы и формирование её облика, в настоящий момент отстает от расширяющегося рынка средств проектирования.
Назначение новой методологии заключается в совершенствовании процесса проектирования ИС и структурирования информационного пространства как объекта автоматизации с целью обеспечения функциональных требований как к самой ИС, так и к характеристикам процесса ее разработки. Основными задачами, решению которых должна способствовать методология проектирования корпоративных ИС, являются следующие:
• обеспечение создания корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;
• создание системы с заданным качеством в заданные сроки и в рамках установленного бюджетирования;
• поддержка удобных механизмов сопровождения, модификации и наращивания системы;
• обеспечение преемственности разработки.
Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, повышения качества постановки задачи, а также применения современных методов и технологий создания ИС на всем жизненном ее цикле.
ЛИТЕРАТУРА
1. Когаловский М.Р. Перспективные технологии информационных систем. - М.: ДМК Пресс; М.: Компания АйТи, 2003.
2. Калянов Г.Н. Структурный системный анализ - М.: Лори, 1997.
3. Данилин А., Слюсаренко А. Архитектура и стратегия. "Инь" и "янь" информационных технологий. Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
4. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. - Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
5. Автоматизированные Системы Стадии создания. ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. - М.: ИПК издательство стандартов, 1997.
6. Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление -М.: ИНФРА-М, 2004.
7. Избачков Ю.С., Петров В.Н. Информационные системы. - СПб.: Питер, 2005.
8. ГОСТ 6.01.1-87 Единая система классификации и кодирования технико-экономической информации. - М.: Изд. стандартов, 1987.
9. Проектирование информационных систем // «КомпьютерПресс», №9, 2001.
10. Йордан Э., Аргила С. Структурные модели в объектно-ориентированом анализе и проектировании. - М. : ЛОРИ, 1999
11. Вендров А.М. Проектирование программного обеспечения экономических информационных систем - М: Финансы и статистика, 2000.
12. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. - М.: СИНТЕГ, 2000.
13. Нейбург Э. Д., Максимчук Р.А. Проектирование баз данных с помощью UML. - М.: Издательский дом «Вильямс», 2002.
14. Черемных С.В., Ручкин В.С., Семенов И.О. Структурный анализ систем. IDEF-технологии. - М.: Финансы и статистика, 2001.
15. Clegg, Dai and Richard Barker. Case Method Fast-track: A RAD Approach - Adison-Wesley, 1994.
16. Кондратьев В.В., Краснова В.Б. Модульная программа для менеджеров. Реструктуризация управления компанией - М.: Инфра-М, 2000.
17. Лоу А.М., Кельтон В.Д. Имитационное моделирование: Пер. с англ. - СПб.: Питер, 2004.
18. Емельянов А.А., Власова Е.А., Дума Р.В. Имитационное моделирование экономических процессов. - М.: Финансы и статистика, 2005.
19. Мейер Б. Объектно-ориентированное конструирование программных систем .-М.: Русская Редакция, Интернет-университет информационных технологий, 2005.
20. ISO/IEC 12207:1995.
21. Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник - М.: Финансы и статистика, 2002.
INFORMATION SYSTEMS: BUILDING METHODS AND TOOS
Egorova A.A., Kozlov S.A.
In the present work we consider the classification modem methods and tools of the information systems (IS). Analysis of applicability and actuality of IS with different configuration and goals is given.
Сведения об авторах
Егорова Алла Альбертовна, окончила МИИГА (1983), доктор технических наук, профессор МГТУ ГА, автор более 60 научных работ, область научных интересов - оптимизация и автоматизация принятия управленческих решений в условиях неполной определённости.
Козлов Сергей Александрович, 1978 г.р., окончил МГТУ ГА (2000), соискатель МГТУ ГА, автор 4 научных работ, область научных интересов - построение автоматизированных систем управления.
