35
хранение, управление и целостность данных, а также обеспечивает
возможность одновременного доступа нескольких пользователей. Клиентская
часть представлена так называемым “толстым” клиентом, то есть приложением
(АРМ) на котором сконцентрированы основные правила работы системы и
расположен пользовательский интерфейс программы. При всей простоте
построения такой архитектуры, она обладает множеством недостатков,
наиболее существенные из которых - это высокие требования к сетевым
ресурсам и пропускной способности сети компании, а также сложность
обновления программного обеспечения из-за “размазанной” бизнес-логики
между АРМом и сервером БД. Кроме того, при большом количестве АРМов
возрастают требования к аппаратному обеспечению сервера БД, а это, как
известно, самый дорогостоящий узел в любой информационной системе.
Как видим, минусов у такой архитектуры достаточно, а решение
тривиально - нужно отделить бизнес-логику от клиентской части и СУБД,
выделив ее в отдельный слой. Так и поступили разработчики и следующим
шагом развития клиент-серверной архитектуры стало внедрение среднего
уровня, реализующего задачи бизнес-логики и управления механизмами
доступа к БД (рисунок 1.5).
Рис. 1.5. Трехуровневая клиент-серверная архитектура
Плюсы данной архитектуры очевидны. Благодаря концентрации бизнес-
логики на сервере приложений, стало возможно подключать различные БД.
36
Теперь, сервер базы данных освобожден от задач распараллеливания работы
между различными пользователями, что существенно снижает его аппаратные
требования. Также снизились требования к клиентским машинам за счет
выполнения ресурсоемких операций сервером приложений и решающих теперь
только задачи визуализации данных. Именно поэтому такую схему построения
информационных систем часто называют архитектурой “тонкого” клиента.
Но, тем не менее, узким местом, как и в двухуровневой клиент-серверной
архитектуре, остаются повышенные требования к пропускной способности
сети, что в свою очередь накладывает жесткие ограничения на использование
таких систем в сетях с неустойчивой связью и малой пропускной способностью
(Internet, GPRS, мобильная связь).
Существует еще один важный момент использования систем,
построенных на такой архитектуре. Самый верхний уровень (АРМы), в целом
обладающий огромной вычислительной мощностью, на самом деле
простаивает, занимаясь лишь выводом информации на экран пользователя. Так
почему бы не использовать этот потенциал в работе всей системы? Рассмотрим
следующую архитектуру (рисунок 1.6) которая позволяет решить эту задачу.
Рис. 1.6 Распределенная архитектура системы
Еще два-три года назад реализация такой архитектуры системы для
среднего и малого бизнеса была бы не возможна из-за отсутствия
соответствующих недорогих аппаратных средств. Сегодня хороший ноутбук
37
обладает мощностью, которой несколько лет назад обладал сервер крупной
корпорации, и позволял рассчитывать множество важных и судьбоносных
отчетов для всех сотрудников этой корпорации.
Более 95 % данных, используемых в управлении предприятием, могут
быть размещены на одном персональном компьютере, обеспечив возможность
его независимой работы. Поток исправлений и дополнений, создаваемый на
этом компьютере, ничтожен по сравнению с объемом данных, используемых
при этом. Поэтому если хранить непрерывно используемые данные на самих
компьютерах, и организовать обмен между ними исправлениями и
дополнениями к хранящимся данным, то суммарный передаваемый трафик
резко снизиться. Это позволяет понизить требования к каналам связи между
компьютерами и чаще использовать асинхронную связь, и благодаря этому
создавать надежно функционирующие распределенные информационные
системы, использующие для связи отдельных элементов неустойчивую связь
типа Интернета, мобильную связь, коммерческие спутниковые каналы. А
минимизация трафика между элементами сделает вполне доступной стоимость
эксплуатации такой связи. Конечно, реализация такой системы не элементарна,
и требует решения ряда проблем, одна из которых своевременная
синхронизация данных.
Каждый АРМ независим, содержит только ту информацию, с которой
должен работать, а актуальность данных во всей системе обеспечивается
благодаря непрерывному обмену сообщениями с другими АРМами. Обмен
сообщениями между АРМами может быть реализован различными способами,
от отправки данных по электронной почте до передачи данных по сетям.
Еще одним из преимуществ такой схемы эксплуатации и архитектуры
системы, является обеспечение возможности персональной ответственности за
сохранность данных. Так как данные, доступные на конкретном рабочем месте,
находятся только на этом компьютере, при использовании средств шифрования
и личных аппаратных ключей исключается доступ к данным посторонних, в
том числе и IT администраторов.
38
Такая архитектура системы также позволяет организовать
распределенные вычисления между клиентскими машинами. Например, расчет
какой-либо задачи, требующей больших вычислений, можно распределить
между соседними АРМами благодаря тому, что они, как правило, обладают
одной информацией в своих БД и, таким образом, добиться максимальной
производительности системы.
Таким образом, предложенная модель построения распределенных
систем вполне способна решить и реализовать функции современного
программного обеспечения для предприятий среднего и малого бизнеса.
Построенные на основе данной архитектуры системы будут обладать
надежностью, безопасностью информации и высокой скоростью вычислений,
что от них в первую очередь и требуется.
Обратимся к этапам проектирования корпоративных информационных
систем.
1.Анализ
Обследование и создание моделей деятельности организации, анализ
(моделей) существующих КИС, анализ моделей и формирование требований к
КИС, разработка плана создания КИС.
2.Проектирование
Концептуальное проектирование, разработка архитектуры КИС,
проектирование общей модели данных, формирование требований к
приложениям.
3.Разработка
Разработка, прототипирование и тестирование приложений, разработка
интеграционных тестов, разработка пользовательской документации.
4.Интеграция и тестирование
Интеграция и тестирование приложений в составе системы, оптимизация
приложений и баз данных, подготовка эксплуатационной документации,
тестирование системы.
5.Внедрение
39
Обучение пользователей, развертывание системы на месте эксплуатации,
инсталляция баз данных, эксплуатация.
6. Сопровождение
Регистрация, диагностика и локализация ошибок, внесение изменений и
тестирование, управление режимами работы ИС.
Анализ начинается с определения требований и назначения
подмножества этих требований программному элементу.
На этом этапе начинается решение задачи планирования проекта ПО.
В ходе планирования проекта определяются:
- объем проектных работ;
- риск проектных работ;
- необходимые трудозатраты;
- формируются рабочие задачи;
- формируется план-график работ.
Анализ требований, относящийся к программному элементу, т.е. к ПО,
уточняет и детализирует:
- функции ПО;
- характеристики ПО;
- интерфейс ПО.
Все определения документируются в спецификации анализа.
Проектирование создает представления:
- архитектуры ПО;
- модульной структуры ПО;
- алгоритмической структуры ПО;
- входного и выходного интерфейса (входных и выходных форм данных).
Кодирование (реализация)состоит в переводе результатов
проектирования в текст на языке программирования.
Тестирование – это выполнение программы для выявления дефектов в
функциях, логике и форме реализации программного продукта.
40
Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели
изменений:
- исправление ошибок;
- адаптация к изменениям внешней для ПО среды;
- усовершенствование ПО по требованию заказчика.
Сопровождение ПО состоит в повторном применении каждого из
предшествующих шагов (этапов) жизненного цикла, т.е. системного анализа,
анализа требований, проектирования и т. д., к существующей программе, но не
разработке новой программы (таблица 1.3)
Таблица 1.3
Жизненный цикл корпоративных информационных систем
Процессы организации и управления проектом: планирование, управление, контроль
Анализ
Проектирован
ие
Разработка
Интеграция и
тестирование
Внедрение
Сопровожде
ние
*Обследова
ние и
создание
моделей
деятельност
и
организаци
и
*Анализ
(моделей)
существую
щих ИС
*Анализ
моделей и
формирован
ие
требований
к ИС
*разработка
плана
создания
ИС
*Концептуаль
ное
проектирован
ие
*Разработка
архитектуры
ИС
*Проектирова
ние общей
модели
данных
*Формирован
ие требований
к
приложениям
*Разработка,
прототипирова
ние и
тестирование
приложений
*Разработка
интеграционн
ых тестов
*Разработка
пользовательс
кой
документации
*Интеграция и
тестирование
приложений в
составе
системы
*Оптимизация
приложений и
баз данных
*Подготовка
эксплуатацион
ной
документации
*Тестирование
системы
*Обучение
пользовател
ей
*Развертыва
ние системы
на месте
эксплуатаци
и
*Инсталляц
ия баз
данных
*Эксплуатац
ия
*Проведени
е ПСИ
*Регистраци
я,
диагностика
и
локализация
ошибок
*Внесение
изменений и
тестировани
е
*Управлени
е режимами
работы ИС
Интегральные процессы: управление конфигурацией, документирование, проверки,
интеграция
41
Каждая стадия (этап) завершается выпуском полного комплекта
документации, достаточной для того, чтобы разработка могла быть продолжена
другой командой разработчиков.
Достоинствами классического жизненного цикла являются:
- получение плана и временного графика по всем этапам проекта;
- упорядочение хода разработки.
К недостаткам классического жизненного цикла относятся:
- частое отклонение реальных проектов от стандартной
последовательности шагов;
- основанность цикла на точной формулировке исходных требований к
ПО, тогда как реально в начале проекта требования заказчика определены лишь
частично;
- доступность результатов проекта заказчику лишь в конце работы.
Поскольку данные составляют основу деятельности любой организации и
являются наиболее стабильной ее составляющей (функции и структура
организации меняются гораздо чаще), то при построении корпоративной
информационной системы наиболее адекватным решаемым задачам является
подход к проектированию, основанный на данных. Такой подход обеспечивает
наилучшее архитектурное решение при разбиении системы на приложения, а
также простоту и согласованность при интеграции приложений. В основу
процессов проектирования и разработки ПО и ИО положены методология
проектирования от данных DATARUN, которая была разработана в компании
CSA (США) для проектирования и быстрой разработки программного и
информационного обеспечения переносимых распределенных ИС в
архитектуре клиент-сервер. Эти возможности основаны на использовании
современных инструментальных средств моделирования, быстрого
прототипирования и разработки. Методология DATARUN основана на моделях.
Она поддерживает принципы формирования и развития моделей, заложенные в
КРССМ. Модель требований к ПО и ИО базируется на бизнес- процессах и
формируется на основе системы моделей требований к ИС. Процесс
42
проектирования основан на извлечении всех данных из моделей бизнес-
процессов, построении и развитии моделей данных (концептуальной модели
данных, модели архитектуры ИС, полной реляционной модели данных и т.д.,
вплоть до моделей, определяющих приложения). Эти модели взаимоувязаны и
интегрированы друг с другом и определяют множество уровней спецификаций
для каждого этапа разработки. В процессе проектирования модели данных
развиваются от простой начальной версии в законченную спецификацию
приложения, используемую для генерации. При этом полная реляционная
модель данных может быть разделена на подмодели (подсхемы),
представляющие разные части системы, которые могут быть распределены по
сети в окружении клиент-сервер в соответствии с архитектурой ИС.
Методология DATARUN объединяет лучшие черты реляционного
проектирования, объектно-ориентированной технологии и подхода RAD
(быстрого создания приложений). В общем ЖЦ ИС методология DATARUN
охватывает этапы ЖЦ формирования требований к ПО и ИО и все этапы стадий
проектирования, разработки, интеграции и тестирования и внедрения системы
(в части ПО и ИО). Дальнейшие шаги по созданию ИС, выполняемые на
стадиях сопровождения и развития ИС, не раскрываются в данном докладе.
Методология их выполнения базируется на тех же основных принципах, что и
описанные методологии.
Для создания корпоративной информационной системы, отвечающей
целям и задачам организации нужна специальная методология, которая бы во-
первых, помогла сформировать требования к ИС, отвечающие целям и задачам
организации, и во-вторых, спроектировать и разработать систему, отвечающую
этим требованиям, с учетом их изменений в процессе разработки. Наличие
такой методологии является решающим фактором успеха при создании КИС. В
статье предложена методология, обеспечивающая создание корпоративных
информационных систем, отвечающих целям и задачам организации,
предъявляемым к ним требованиям по автоматизации деловых процессов, и
43
обеспечивающая выполнение основных требований к процессу разработки (по
срокам, качеству и т.д).
При создании корпоративных информационных систем необходимым
слагаемым успеха помимо методологии, является также и комплекс
согласованных инструментальных средств, поддерживающий эту методологию
и обеспечивающий автоматизацию процессов, выполняемых на всех этапах ЖЦ
создания ИС. Эти средства должны поддерживать быстрое построение
корпоративных ИС, отвечающих целям и задачам организации и
удовлетворяющих основным требованиям (открытости, переносимости и
масштабируемости и т.д.), а также обеспечивать поддержку процессов
управления проектом.
1.5 Обоснование проектных решений по видам обеспечения
В проектах по внедрению КИС инструментальные средства
моделирования используются главным образом на этапах работ, связанных с
информационным обследованием организаций и проектированием систем.
Основным результатом информационного обследования является модель
деятельности организации, созданная с помощью используемого
инструментария. На этапе проектирования системы создаются техническое
задание и технический проект на внедрение, при разработке которых
используется модель деятельности, созданная на этапе информационного
обследования (это касается в первую очередь таких компонентов технического
задания и технического проекта, как требования к системе, описание ее общих
настроек, процедуры выполнения автоматизируемых процессов, концепция
полномочий, сопроводительная документация по системе). Также на этапе
проектирования с использованием модели деятельности предприятия
разрабатывается эксплуатационная документация на КИС или ее части.
Как правило, внедрение КИС требует изменения ряда бизнес-процессов
организации – как с целью совершенствования, так и для их адаптации к
44
архитектуре и функционалу выбранной для внедрения системы. Поэтому на
практике информационное обследование организации часто совмещается с
работами по созданию моделей «как должно быть», отражающих целевое
состояние организации, в рамках проекта по подготовке организации к
внедрению КИС. Типовой проект такого рода может включать следующие
этапы:
-подготовка проекта (определение организационной структуры и
планирование проекта, создание инфраструктуры проекта, разработка «грубой»
архитектуры процессов и определение процессов для автоматизации);
-анализ «как есть» (детальное описание выбранных процессов «как есть»,
изучение разработанных моделей процессов на соответствие функционалу и
сценариям использования внедряемой системы, определение процессов для
изменения);
-разработка концепции «как должно быть» (детальное описание
автоматизируемых процессов «как должно быть», определение
организационной структуры «как должно быть», разработка новых
должностных инструкций и формулирование требований к квалификации
персонала;
-подготовка к реализации изменений (разработка плана перехода,
временных решений, тренинг-курсов);
-реализация изменений (поэтапная реализация плана перехода,
перестройка организационной структуры, обучение персонала).
Результатами проекта являются модель «как должно быть» и
соответствующим образом организованная деятельность компании, полностью
подготовленной к внедрению выбранной КИС.
В отдельных случаях средства моделирования деятельности применяются
и на этапе настройки функционала КИС. Например, средства ARIS широко
используются при внедрении и сопровождении продуктов и решений SAP,
главным образом благодаря их тесной интеграции. Так, возможны
синхронизация и автоматизированный перенос результатов описания