CC BY
129
Посилання на статтю_
Чернявская И.М. Модель построения архитектуры информационной системы в проекте/ И.М. Чернявская// Управлшня проектами та розвиток виробництва: Зб.наук.пр. - Луганськ: вид-во СНУ iм. В.Даля, 2005 - №2(14). С. 114-121._
УДК 330.47
И.М. Чернявская
МОДЕЛЬ ПОСТРОЕНИЯ АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ В ПРОЕКТЕ
Исследована функциональная модель, построенная методами структурного моделирования, составлена интегрированная схема архитектуры информационной системы управления проектом. Рис. 2, табл. 3, ист. 11.
Ключевые слова: информационная система управления, архитектура информационной системы, моделирование информационной системы в проекте, интегрированная схема архитектуры информационной системы управления.
1.М. Чернявська
МОДЕЛЬ ПОБУДОВИ АРХ1ТЕКТУРИ 1НФОРМАЦ1ЙНО1 СИСТЕМИ В ПРОЕКТ!
Дослщжено функцюнальну модель, побудовану методами структурного моделювання, складено штегровану схему арх1тектури шформацмно'Т системи управлшня проектом. Рис. 2, табл. 3, дж. 11.
I.M. Chernyavskaya
MODEL FOR SHAPING THE INFORMATION SYSTEM IN PROJECT
Functional model built up by method of structured modeling is searched; the integrated schema of project management information system architecture is formed
Введение. Внедрение информационной системы всегда приводит к реорганизации бизнеса. В значительной степени предмет деятельности остается без изменений, в то время как меняются способы и участники этой деятельности. Модели, используемые для определения потребностей бизнеса, должны позволять делать обоснованные изменения в организационной структуре проекта. Эти модели должны как можно меньше зависеть от известных информационных технологий. Система должна быть открыта в сторону введения новых процедур. Требования должны моделироваться и определяться настолько общим способом, насколько это возможно. Структура данных должна быть рассчитана на изменения в организационной структуре и на текущие и ожидаемые исключения и ограничения. На этом основан подход Р. Баркера к внедрению информационных систем в проекте [1]. Каждая из данных
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
1
моделей реального мира должна соответствовать контексту общего направления бизнеса, которое определяется его задачами, приоритетами и критическими для успеха проекта факторами.
Главная идея такого моделирования - его надо начинать с самых главных характеристик проекта, позволяющих видеть все существенные элементы взаимодействия на его моделях.
В 2003 году Джон Захман опубликовал свою схему развития архитектуры информационной системы [2]. Захмановская схема создает контекстное описание различных представлений архитектуры внедряемой информационной системы. Эти представления соответствуют трем выбранным аспектам: информационное (данные), функциональное (функции) и коммуникационное (сетевая структура). В схеме Захмана строке соответствует точка зрения какого-либо участника проекта. Аспекты представлены в схеме колонками.
Архитектурное представление - это ячейка таблицы, соответствующая пересечению выбранного столбца и выбранной строки. Взгляд какого-либо лица - это совокупность ячеек в пределах одной строки (точки зрения), то есть совокупность архитектурных представлений с выбранной точки зрения, соответствующая выбранным аспектам системы [3].
Итак, рассматриваются два подхода к моделированию бизнес- процессов, необходимых для разработки информационной системы управления проектом. Различия этих подходов заключаются в следующем: в подходе Баркера информационная система управления развивается со временем, в процессе последовательного прохождения этапов жизненного цикла проекта. Каждому этапу приписан набор обязательных или необязательных методик для использования. В подходе Захмана не делается акцент на динамике развития информационной системы управления. При переходе от одной строки таблицы к другой меняется лишь точка зрения, с которой рассматривается система, причем эта точка зрения не обязана быть связана с уровнем детальности рассмотрения.
Постановка и исследование проблемы. Для успешной реализации проекта руководителю проекта необходимо принимать грамотные управленческие решения, что зависит от возможности получения оперативной информации как о состоянии проекта в целом, так и о состоянии его отдельных подразделений. Помимо получения оперативной информации необходимо иметь возможность автоматического выполнения задач, возникающих в ходе проектных работ.
Учитывая стремительный этап развития информационных технологий, перед командой менеджера проекта стоит масштабная задача по реорганизации системы управления на основе внедрения современных управленческих технологий [4].
Наиболее эффективно такую задачу можно решить лишь посредством построения структуры, управляющей самими информационными потоками, используя автоматизированную информационную систему управления, представляющую собой комплекс аппаратно-программных средств, реализующих мультикомпонентную информационную систему, обеспечивающую современное управление процессами принятия решений, проектирования и производства в режиме реального времени при транзакционной обработке данных.
В настоящий момент существует несколько методов моделирования информационной системы в проекте, среди которых можно выделить
2
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
следующие: метод «снизу-вверх», метод «сверху-вниз», а также принцип «дуализма» и многокомпонентности [5].
Метод «снизу-вверх» характеризует систему управления путем разработки модульного программного обеспечения, автоматизирующее отдельные, важные с точки зрения управляющего проектом подразделения. Общая же картина «автоматизированного обмена информацией» просматривается недостаточно хорошо.
Прибегая к методу «сверху-вниз», разработчики выделяют наиболее заметный этап - автоматизацию ведения аналитического учета документооборота и информационных потоков. Такие системы спроектированы «сверху», то есть в предположении, что одна программа должна удовлетворять потребности всех участников проекта. Сама идея использования «одной программы для всех» резко ограничивает круг решаемых задач - автоматизацию повседневной деятельности всех подразделений. Заложенные «сверху» жесткие рамки («общие для всех») ограничивают возможности таких систем по ведению глубокого, часто специфического аналитического и производственно-технологического учета и обмена информационными потоками. При этом интерфейс каждого исполнителя не может быть определен функциями, возложенными на пользователя, и принятой технологией работы. Очевидно, что для успешной реализации задачи оптимизации информационной системы в управлении проектом следует изменить идеологию построения информационной системы управления.
Двойственный подход к формированию планового отчета по вехам положен в основу «принципа дуализма». Реализация принципа дуализма неизбежно требует построения информационной системы управления нового поколения в виде программных модулей, органически связанных между собой, но в то же время способных работать и автономно.
Такая многокомпонентная система обеспечивает соблюдение основополагающего принципа использования автоматизированных информационных систем - отсутствия дублирования ввода исходных данных. Модульность построения информационной системы и принцип одноразового ввода дают возможность гибко варьировать конфигурацией этой системы.
Кроме того, достоинство принципа многокомпонентности состоит в возможности поэтапного внедрения [6].
Целью данной статьи является составление интегрированной схемы архитектуры информационной системы управления.
Изложение основного материала. Развитие структуры проекта предъявляет к информационным системам новые требования. Новый подход к использованию информационной системы управления проектом заключается в сбалансированном сочетании описанных выше.
В этой связи необходимо решить целый комплекс организационно-технических задач, которые позволили бы избежать ошибочных решений:
- система должна охватывать все важнейшие участки бизнес-проекта;
- в системе должна быть заложена достаточная аналитическая глубина, которая обеспечивала бы руководителя проекта информацией в объеме, необходимом для принятия оперативных управленческих решений;
- мультизадачная инфраструктура разработки проекта, корда конкретный модуль информационной системы управления может быть трансформирован в другой и строится на принципах полной взаимозаменяемости, то есть функционирование данного модуля и его развитие не связано с одним конкретным разработчиком;
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
3
- правильный выбор архитектуры построения вычислительно-коммуникационной сети и ориентация на профессиональные СУБД;
- применение эффективных организационно-технических средств по управлению проектом;
- выполнение условия интегрированное, то есть изменение в одной части системы обязательно должно привести к изменениям в другой ее части;
- обеспечение надежности и продолжительности хранения информации, а также защиты от несанкционированных действий;
- простота в эксплуатации и минимальные сроки на переобучение персонала;
- наличие механизмов быстрого поиска ошибок, допущенных исполнителями при вводе данных и т.д.
Основная задача использования такой системы - получить компьютерный инструмент, который зафиксирует текущее положения дел в проекте в виде электронной бизнес-модели, что позволит поставить управленческий диагноз. Модель представляет собой множество своеобразных регистров управленческого учета и отношений между ними. То есть речь идет о некой корпоративной памяти, где сосредоточены в виде непротиворечивой системы все принятые и зафиксированные в особом формате решения по управлению информацией в проекте. Этапы моделирования приведены в табл. 1. Кроме того, эта модель позволяет генерировать разнообразные организационно-распорядительные документы (положения), регламентирующие прохождение проекта [7].
Таблица 1
Этапы моделирования информационной системы управления
Этап Основные характеристики
Моделирование и анализ функционирования системы управления Цель: построение моделей существующих процессов управления проектом, т.е. разработка бизнес-модели «AS-IS». Метод решения: функциональное моделирование. Результат: концептуальная модель описания «исходной» предметной области.
Проектирование функциональной структуры информационной системы Цель: анализ модели «исходной» предметной области, выявление ее недостатков и «узких мест». Построение модели «TO-BE». Метод решения: функциональное моделирование. Результат: диаграммы функциональной декомпозиции, описывающие функциональные возможности внедряемой системы.
Проектирование процессов обработки данных системы Цель: детальное информационное моделирование информационной системы управления, описывающее информационные потребности проекта. Метод решения: моделирование потоков данных. Результат: модель структур первичных и выходных документов, диаграммы потоков данных.
Эксплуатация и контроль версий Особенностью информационной системы управления проектом, созданной по данной архитектуре, является ее многомодульность, поэтому при ее эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых.
Таким образом, главный принцип построения информационных систем управления проектом - это создание единого информационного пространства управленческих действий, а также концентрированность, полнота и оперативность информации, используемой при принятии решений.
4
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
Общий взгляд на организацию как на объект проектирования позволяет сформировать общую архитектуру проектируемой информационной системы управления в масштабе всего проекта (рис. 1).
Рис. 1. Архитектура проектируемой информационной системы управления
Коммуникационные приложения
ш
Подсистема 1п1егпе1-конференций
Подсистема синхронизации данных
с \
Подсистема
управления
у
\х
с \
Подсистема
управления
документооборотом
(отчетность)
\ /
Подсистема защиты информации
Подсистема формирования отчетов
V.
Традиционное хранилище бумажных документов
Подсистема управления хранением документов
7у
И
Стандартные
бизнес-приложения
Документоориентированные специализированные приложения
Ж
Неструктурированная информация(файлы)
Структурированная информация(БД)
Следует отметить, что структурный анализ и бизнес-моделирование можно считать единым неразрывным процессом построения функциональной модели предметной области (рис. 2) [8].
Исследуемая в данной статье методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели информационного потока какой-либо предметной области. Основные элементы этой методологии основываются на концепциях, описанных в работах [9].
Для описания логики взаимодействия информационных потоков применяется технология, называемая также нотацией моделирования, использующая графическое описание информационных потоков и взаимоотношений между процессами в проекте [10].
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
5
Анализ организационных процессов Назначение:
- определение миссии, иерархии цепей;
- оценка эффективности реализации бизнес-процессов;
- спецификация требований к подсистеме информационной поддержки.
Функционально-стоимостной анализ Назначение:
- расчет реальной стоимости;
- определение затратных центров;
- анализ стоимостных факторов.
Информационное моделирование
Функциональное моделирование Назначение: Описание предметной области в виде системы взаимосвязанных функций
Имитационное моделирование
Назначение:
- описание информационной структуры;
- идентификация отношений между объектами.
Назначение:
- моделирование поведения системы;
- анализ динамических характеристик;
- анализ распределения ресурсов.
Рис. 2. Области использования различных методологий в работах по моделированию информационной системы управления
Представляет интерес составление интегрированной схемы, аналогичной схеме Захмана, в которой в качестве аспектов при формировании архитектурных представлений используется хотя бы часть методик, представленных на диаграмме Баркера. Три основные части диаграммы: функциональное, информационное и событийное моделирования. Их пересечения - диаграммы потоков данных, анализ состояний, информационная динамика и функциональная логика. В табл. 2 перечислены известные инструментальные средства (программные продукты или технологические схемы), поддерживающие эти методики [11].
Таблица 2
Инструментальные средства моделирования
Методики Инструменты Комментарии
ФМ SADT- модели Иерархические функциональные модели
ИМ ER- диаграммы Диаграммы «сущность-связь»
СМ Четкого стандарта нет
ФМ&ИМ DF- диаграммы Диаграммы потоков данных
ФМ&СМ Project modeller Моделирование процессов
ИМ&СМ SSADM
ФМ&ИМ&СМ Function Logic, CPN
Примечание: ФМ - функциональное моделирование; ИМ - информационное моделирование; СМ -событийное моделирование.
Построим теперь интегрированную схему архитектуры информационной системы управления (табл.3).
6
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
Таблица 3
Интегрированная схема архитектуры информационной системы управления
Информационное моделирование Функциональное моделирование Событийное моделирование
Цели / предметная область Список важнейших «объектов» Список управляемых процессов Список возможных событий
Бизнес-модель Диаграмма «сущность-связь» Функциональная иерархия Временная схема наступления событий
Модель ИСУ Проект базы данных Функциональная иерархия в терминах ИСУ Схема событий в ИСУ
Технологическая модель Структура базы данных Структурная диаграмма Структура прерываний
Детальное представление Описание структуры данных Описание программы Описание программы обработки событий
Функционирование системы Данные Модули Реакция на событие
Основные выводы и направления дальнейших исследований в данном направлении. Функциональная модель, построенная методами структурного моделирования, представляет «снимок» положения дел на момент «обследования» проекта, описывающий информационное пространство, в котором протекает его реализация. Эта модель позволяет понять, что происходит с позиций системного анализа. Модель является не просто реализацией начальных этапов работы и основанием для формирования технического задания на ее последующие этапы, она представляет собой самостоятельный результат, имеющий большое практическое значение. С ее помощью можно осуществлять предварительное моделирование с целью выявления новых потоков данных, взаимодействующих процессов и структурных элементов.
Использование интегрированной схемы дает возможность формировать информационную систему на всех этапах жизненного цикла проекта. Ее назначение состоит в том, чтобы обеспечить понимание информационной системы на разных стадиях разработки и классифицировать инструментальные средства разработки в реальных проектах.
В следующих статьях исследование будет продолжено с точки зрения оптимизации автоматизированного проектирования информационной системы в управлении проектом.
ЛИТЕРАТУРА
• Barker R. Project-Method. Entity-Relationship Modelling // Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 2002. Vol. 1.
• John A. Zachman. A Framework for Information System Architecture // IBM System Journal, 1987. vol. 26, Sept. P. 138-140.
• Власов А.И., Овчинников Е.М. Корпоративные автоматизированные информационные системы, принципы, средства и системы документооборота. - М.: Учебный центр ОАО Газпром, 1999. - С. 107.
• Лашкевич И. Информационные технологии. - М.: Наука, 1998. - С. 165.
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
7
• Краткое практическое руководство разработчика информационных систем на базе СУБД Oracle: Библиотечка журнала «Информационные технологии». - М: изд-во Машиностроение, 2000. - С. 120.
• Славин Рой. Единственный путь повышения эффективности производства интеграция снизу вверх // Средства и системы автоматизации. - 2001. - № 8. - С. 47.
• Громов А. Управление бизнес-процессами на основе технологии Workflow // Открытые системы. - 1997. - №1. - С. 65-71.
• Marka D.A., McGovan K.L. SADT: Structured Analysis and Design Technique. - N.Y.: McCraw, 2003. - Р. 23-36.
• Маклаков С.В. BPwin и Erwin. CASE-средства разработки информационных систем. -М.: Диалог-мифи, 2003. - С. 256.
• Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.О. - Диалог-мифи, 2004. -С. 224.
• Полукеев О., Коваль Д. Моделирование бизнеса и архитектуры информационной системы // Корпорация ЛВС. - 2000. - №2. - С.27-29.
Стаття надшшла до редакцп 15.06.2005 р.
8
"Управлшня проектами та розвиток виробництва", 2005, № 2(14)
