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

Этапы проектирования ИС

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

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

Подходы "снизу" и "сверху" называют также каузальным и аксиологическим соответственно. На практике обычно эти подходы сочетают.

Каузальное представление системы – описание системы в терминах влияния одних переменных на другие, без употребления понятий цели и средств достижения целей. Этот термин происходит от понятия "cause" – причина, т.е. подразумевает причинно-следственные отношения. При каузальном представлении будущее состояние системы определяется предыдущими состояниями и воздействиями среды. Такое представление является развитием отображения системы в виде "пространства состояний", характерного для большинства математических методов моделирования. Каузальный подход применяется на этапе предварительного описания системы, когда цель еще не сформулирована. Аксиологическое представление системы – отображение системы в терминах целей и целевых функционалов. Этот подход используется на начальном этапе моделирования, когда уже определены цели и средств достижения целей.

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

В 1990-е гг. была разработана методология SADT – (Structured Analysis and Design – структурный анализ и проектирование, которая предложена Дугласом Россом. МетодологияSADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта исследуемой предметной области. На ее основе разработаны и стали широко применяться функционально-ориентированные и объектно-ориентированные технологии. Компьютерная реализация методологии SADT получила название IDEF (Icain Definition). Основными структурными моделями являются модели процессов IDEFO и IDEF3, модель данных IDEF1X. Созданы стандарты IDEF и DFD, ориентированные на анализ процессов, в том числе бизнес-процессов. Для разработки моделей применяются автоматизированные средства – BPWin, ARIS, язык UML (Unified Modeling Language – Унифицированный язык моделирования) и др.

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

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

Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;
• проектирование программ работы системы, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер, клиент-сервер, облачных технологий), параллельной обработки, распределенной обработки данных и т.п.

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

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

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

• предпроектное обследование (формирование требований к системе),
• проектирование,
• реализация,
• тестирование,
• ввод в действие,
• эксплуатация и сопровождение.

Предпроектное обследование (формирование требований к системе)

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

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

Этап предпроектного обследования завершается разработкой технического задания на создание ИС.

Этап проектирования ИС

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

• схема базы данных (на основании ER-модели);
• набор спецификаций модулей системы (строятся на базе моделей функций).

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

• будет ли это архитектура "файл-сервер", "клиент-сервер", сервис-ориентированная архитектура;
• будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
• будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
• будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);
• будут ли для достижения нужной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Этап проектирования завершается разработкой технического проекта ИС.

Этап реализации

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

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

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

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

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

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

Ввод в действие ИС

Ввод в действие ИС включает в себя следующие виды работ:

-подготовка объекта к внедрению проекта - осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта ИС;

-опытное внедрение проекта - осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и "Акт о проведении опытного внедрения";

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

Недостатки каскадной модели

В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится "откатываться" к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к значительному росту затрат, а иногда и к прекращению проекта в той форме, в которой он изначально задумывался. Основным недостатком каскадной модели является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим итерационной (поэтапной) модели с промежуточным контролем. В каскадной модели окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и фактически увеличивает риски. Кроме того, при этом еще и уменьшается ответственность участников проекта, поскольку при формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса. Таким образом, каскадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем. Несмотря на настойчивые рекомендации компаний – вендоров и экспертов в области проектирования и разработки ИС, многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели. К основным причинам, по которым каскадная модель сохраняет свою популярность, можно отнести следующие:

• Определенность в приемке/сдаче работ и финансировании проекта;
• Иллюзия снижения рисков участников проекта (заказчика и исполнителя).

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

Организация разработки ИС

Технический проект

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

На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.

Примерный состав и содержание технического проекта приведены в таблице 3.2.

Таблица 1.3. Содержание технического проекта (ГОСТ 34.602-89)

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

Рабочая документация

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

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

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

Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.

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

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

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

Типовое проектирование ИС

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

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

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

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

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

Основные особенности различных классов ТПР приведены в таблице 1.4

Для реализации типового проектирования используются два подхода:параметрически - ориентированное и модельно-ориентированное проектирование.

Объектная структура

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

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

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

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

Функциональная структура

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

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

На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20.

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

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

Структура управления

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

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

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

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

На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.

Организационная структура

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

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

На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы.

Техническая структура

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

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

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

На внутреннем уровне строится модель "клиент-серверной" архитектуры вычислительной сети.

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

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

Структурным анализомпринято называть метод исследования предметной области, который начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – "разделяй и властвуй" и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых "черных ящиков") и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа.

Операция – элементарное (неделимое в рамках решаемой задачи) действие,.

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

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

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

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

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

Построение диаграммы потоков данных (DFD)

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

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

Внешние сущности

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