Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Реализация проекта реинжиниринга бизнес-процессов





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

Для изменения структуры организационно-экономической системы осуществляются:

• разработка организационно-штатной структуры предприятия;

• разработка должностных инструкций;

• разработка системы стимулирования работников;

• обучение персонала;

• подготовка рабочей документации.

Для создания новой информационной системы осуществля­ются:

• генерация, настройка, программирование и отладка про­граммных модулей;

• разработка и наполнение базы данных;

• установка вычислительного оборудования и системы телеком­муникации.

Для быстрой разработки информационной системы широко используются CASE-средства автоматизации проектирования (см. гл. 13) или средства конфигурации комплексных систем уп­равления ресурсами предприятия (ERP-системы), например R/3, BAAN IV, Oracle Application, «Галактика», БОСС и др. (см. гл. 14). В том и другом случае для разработки оригинального программного обеспечения могут потребоваться средства бы­строй разработки приложений (RAD-технология) и языки про­граммирования 4-го поколения (4GL), например АВАР4, JAM и др. (см.п. 13.4).

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

Внедрение проекта реинжиниринга бизнес-процессов

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

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

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

 

Основные понятия и особенности проектирования клиент-серверных экономических информационных систем (КЭИС)

 

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

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

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

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

Рис. 12.1. Структура локальной вычислительной сети

 

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

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

удаленных подразделений предприятия, требованиями эксплуа­тационной надежности, быстродействием, простотой обслужи­вания. Рассмотрим различные схемы клиент-серверной архитек­туры (рис. 12.2).

 

Архитектура "Клиент-сервер"

Рис. 12.2. Варианты клиент-серверной архитектуры КЭИС

 

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

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

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

Двухуровневая клиент-серверная архитектура основана на использовании только сервера базы данных (DB-сервера), когда клиентская часть содержит уровень представления данных, а на сервере находится база данных вместе с СУБД и прикладными программами.

DB-сервер отличается от файл-сервера тем, что в его опера­тивной памяти, помимо сетевой операционной системы, функ­ционирует централизованная СУБД, которая обеспечивает совме­стное использование рабочими станциями базы данных, разме­щенной во внешней памяти этого DB-сервера.

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

Обращение к базе данных осуществляется на языке SQL, ко­торый фактически стал стандартом для реляционных баз данных Отсюда сервер баз данных часто называют SQL-сервером, кото­рый поддерживается всеми реляционными СУБД: Oracle Informix, MS SQL, ADABAS D, InterBase, SyBase и др. Клиентс­кое приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.). При этом вза­имодействие клиентского приложения с SQL-сервером осуществ­ляется через ODBC-драйвер (Open Data Base Connectivity), кото­рый обеспечивает возможность пересылки и преобразования данных из глобальной базы данных в структуру базы данных клиентского приложения. Применение этой технологии позволи­ло разработчикам не заботиться о специфике работы с той или иной СУБД и делать свои системы переносимыми между базами данных. За время своего существования ODBC стал стандартом де-факто на алгоритм доступа к разнородным базам данных, и на сегодняшний день насчитывается более 160 прикладных сис­тем, которые работают с источниками информации через драй­веры ODBC.

Трехуровневая клиент-серверная архитектура позволяет по­мещать прикладные программы на отдельные серверы приложе­ний, с которыми через API-интерфейс (Application Program Interface) устанавливается связь клиентских рабочих станций. Работа клиентской части приложения сводится к вызову необхо­димых функций сервера приложения, которые называются «сер­висами». Прикладные программы в свою очередь обращаются к серверу базы данных с помощью SQL запросов. Такая организа­ция позволяет еще более повысить производительность и эффек­тивность КЭИС за счет:

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

• параллельности в работе сервера приложений и сервера базы данных, причем сервер приложений может быть менее мощным по сравнению с сервером базы данных;

• оптимизации доступа к базе данных через сервер приложений из клиентских мест путем диспетчеризации выполнения зап­росов в вычислительной сети;

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

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

Многоуровневая архитектура «Клиент-сервер» создается для территориально-распределенных предприятий. Для нее в общем случае характерны отношения «многие ко многим» между клиент­скими рабочими станциями и серверами приложений, между сер­верами приложений и серверами баз данных. Такая организация позволяет более рационально организовать информационные по­токи между структурными подразделениями в процессе выполне­ния общих деловых процессов. Так, каждый сервер приложений, как правило, обслуживает потребности какой-либо одной функ­циональной подсистемы и сосредоточивается в головном для под­системы структурном подразделении, например, сервер приложе­ния по управлению сбытом - в отделе сбыта, сервер приложения по управлению снабжением - в отделе закупок и т.д. Естественно, что локальная сеть каждого из подразделений обеспечивает более быструю реакцию на запросы основного контингента пользовате­лей из соответствующего подразделения. Интегрированная база данных находится на отдельном сервере, на котором обеспечива­ются централизованное ведение и администрирование общих дан­ных для всех приложений.

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

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

• синхронный режим, когда тиражируемые данные обновляют­ся по мере возникновения необходимости одновременно на серверах баз данных во всех копиях. Требуемое быстродей­ствие каналов для синхронного режима - единицы Мбит в секунду;

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

Направление тиражирования между серверами баз данных может быть:

• равноправным, т.е. в обоих направлениях;

• сверху-вниз типа «ведущий/ведомый», когда на серверах фи­лиалов содержатся только некоторые подмножества данных центральной базы данных;

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

Рассмотрим технологическую сеть техно-рабочего проекти­рования трехуровневой клиент-серверной КЭИС (рис. 12.3).

 

Основные понятия и классификация CASE-технологий

 

Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное зна­чение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоя­щее время приобрело новый смысл, охватывающий процесс раз-

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

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

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

• подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

• широкое внедрение и постоянный рост производительности персональных ЭВМ, позволяющих использовать эффективные графические средства и автоматизировать большинство эта­пов проектирования;

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

Преимущества CASE-технологии по сравнению с традицион­ной технологией оригинального проектирования сводятся к сле­дующему:

• улучшение качества разрабатываемого программного при­ложения за счет средств автоматического контроля и гене­рации;

• возможность повторного использования компонентов разра­ботки;

• поддержание адаптивности и сопровождения ЭИС;

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

• освобождение разработчиков от рутинной работы по доку­ментированию проекта, так как при этом используется встро­енный документатор;

• возможность коллективной разработки ЭИС в режиме реаль­ного времени.

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

Методология определяет шаги и этапность реализации про­екта, а также правила использования методов, с помощью кото­рых разрабатывается проект.

Метод - это процедура или техника генерации описаний ком­понентов ЭИС (например, проектирование потоков и структур данных).

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

Инструментальные средства CASE - специальные програм­мы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.

Рис. 13.1. Архитектура CASE-средства

 

Рассмотрим архитектуру CASE-средства, которая представ­лена на рис. 13.1.

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

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

• проектировщиков и их прав доступа к различным компонен­там системы;

• организационных структур;

• диаграмм;

• компонентов диаграмм;

• связей между диаграммами;

• структур данных;

• программных модулей;

• процедур;

• библиотеки модулей и т.д.

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

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

• создавать элементы диаграмм и взаимосвязи между ними;

• задавать описания элементов диаграмм;

• задавать описания связей между элементами диаграмм;

• редактировать элементы диаграмм, их взаимосвязи и описа­ния.

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

• мониторинг правильности построения диаграмм;

• диагностику и выдачу сообщений об ошибках;

• выделение на диаграмме ошибочных элементов.

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

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

• инициализации проекта;

• задания начальных параметров проекта;

• назначения и изменения прав доступа к элементам проекта;

• мониторинга выполнения проекта.

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

Современные CASE-системы классифицируются по следую­щим признакам:

1) по поддерживаемым методологиям проектирования: функ­ционально (структурно)-ориентированные, объектно-ориентиро­ванные и комплексно-ориентированные (набор методологий про­ектирования);

2) по поддерживаемым графическим нотациям построения ди­аграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватыва­ющих большинство этапов разработки ЭИС) и workbench (пол­ностью интегрированные средства, связанные общей базой про­ектных данных - репозиторием);

4) по типу и архитектуре вычислительной техники: ориенти­рованные на ПЭВМ, ориентированные на локальную вычисли­тельную сеть (ЛВС), ориентированные на глобальную вычисли­тельную сеть (ГВС) и смешанного типа;

5) по режиму коллективной разработки проекта: не поддер­живающие коллективную разработку, ориентированные на ре­жим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

6) по типу операционной системы (ОС): работающие под уп­равлением WINDOWS 3.11 и выше; работающие под управле­нием UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными воз­можностями (такие, как редакторы диаграмм), так и дорогостоя­щие системы для больших ЭВМ.

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

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

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

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

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

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

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

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

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

Многопользовательский режим. Развитые CASE-системы дол­жны обладать возможностями разделения полномочий пер­сонала разработчиков и объединения отдельных работ в об­щий проект.

Открытая архитектура. Открытая к доступу проектировщи­ков информация об используемых форматах файлов и интер­фейсах должна позволять безболезненно переходить от одной CASE-системы к другой.

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

Наличие графических средств поддержки методологий проектирования. Большинство CASE-систем базируется на графи­ческом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детали­зировать изображения с той степенью, с какой это необходи­мо для понимания проектных решений.

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

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

Генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД.

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

 

Основные понятия и классификация методов типового проектирования

 

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

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

В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового про­ектирования (рис. 14.1).

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

Рис. 14.1. Классификация типовых методов проектирования

 

 

Рис. 14.2. ТПР уровня Задача

 

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

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

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

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

Типовые проектные решения для функциональных подсистем реализуются в виде пакетов прикладных программ (ППП), кото­рые позволяют осуществлять:

• модульное проектирование;

• параметрическую настройку программных компонентов на различные объекты управления;

• сокращение затрат на проектирование и программирование взаимосвязанных компонентов;

• хорошее документирование отображаемых процессов обра­ботки информации.

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

В качестве примеров широко распространенных функциональных ППП можно назвать: 1C «Предприятие» (автоматизация бухгалтерского учета, расчета заработной платы, складского учета), «Фолио - Склад» (автоматизация складских операций), Project Expert (бизнес-планирование), ИНЭК (финансовый ана­лиз) и др.

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

• открытостью архитектуры, позволяющей устанавливать про­екты на разных программно-технических платформах;

• масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест;

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

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

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

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

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

 







Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычис­лить, когда этот...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2023 zdamsam.ru Размещенные материалы защищены законодательством РФ.