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

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

Методология DATARUN опирается на две модели или на два представления:

модель организации; модель ИС.

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

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

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

Модель ИС

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

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

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

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

[pic]

Последовательность шагов проектирования системы

[pic]

Модели, создаваемые с помощью подхода DATARUN

BPM (Business Process Model) - модель бизнес-процессов.
PDS (Primary Data Structure) - структура первичных данных.
CDM (Conceptual Data Model) - концептуальная модель данных.
SPM (System Process Model) - модель процессов системы.
ISA (Information System Architecture) - архитектура информационной системы.
ADM (Application Data Model) - модель данных приложения.
IPM (Interface Presentation Model) - модель представления интерфейса.
ISM (Interface Specification Model) - модель спецификации интерфейса.

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

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

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

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

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

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

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

Модель представления интерфейса - это описание внешнего вида интерфейса, как его видит конечный пользователь системы. Это может быть как документ, показывающий внешний вид экрана или структуру отчета, так и сам экран (отчет), созданный с помощью одного из средств визуальной разработки приложений - так называемых языков четвертого поколения (4GL - Fourth
Generation Languages). Так как большинство языков 4GL позволяют быстро создавать работающие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ранних стадиях проектирования.

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

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

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

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

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

Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями: мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности; интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС; использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный
ЖЦ ПО) содержит следующие компоненты; репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость; графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС; средства разработки приложений, включая языки 4GL и генераторы кодов; средства конфигурационного управления; средства документирования; средства тестирования; средства управления проектом; средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи
(tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого,
CASE-средства можно классифицировать по следующим признакам: применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

Классификация по типам в основном совпадает с компонентным составом
CASE-средств и включает следующие основные типы: средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic
Works)); средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000
(ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик
(МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных; средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor
(SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000,
Silverrun и PRO-IV; средства разработки приложений. К ним относятся средства 4GL (Uniface
(Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE),
New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично
- в Silverrun; средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав
Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor.
В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team
(Cayenne)).

Вспомогательные типы включают: средства планирования и управления проектом (SE Companion, Microsoft
Project и др.); средства конфигурационного управления (PVCS (Intersolv)); средства тестирования (Quality Works (Segue Software)); средства документирования (SoDA (Rational Software)).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Vantage Team Builder (Westmount I-CASE);
Designer/2000;
Silverrun;
ERwin+BPwin;
S-Designor;
CASE.Аналитик.

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect,
Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

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

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

Анализ предметной области

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

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

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

Охарактеризуем коротко каждый из них.

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

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9