Изучение материала

[1], гл. 4, стр. 185 – 262

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

Рис. 3. Обобщенная схема организационного бизнес- моделирования

Определение миссии представлено в нормативном акте, определенном ISO [ISO-15704]. Под миссией понимается как деятельность организации, так и механизмы, использование которых позволяет достичь поставленных целей.

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

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

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

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

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

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

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

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

· базовое Положение об организационно-функциональной структуре компании;

· пакет Положений об отдельных видах деятельности (финансовой, маркетинговой и т.д.);

· пакет Положений о структурных подразделениях (цехах, отделах, секторах, группах и т.п.);

· должностные инструкции.

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

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

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

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

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

Среди основных CASE-средств для разработки можно выделить Rational Rose, ERwin, Designer/2000, Visio и др.

Продукт под названием Visio, приобретенный в январе 2000 года корпорацией Microsoft вместе с его разработчиком – компанией Visio Corporation, позиционировался на рынке как одно из самых популярных средств создания схем и диаграмм. Как и подавляющее большинство средств проектирования данных, Visio Enterprise позволяет производить прямое и обратное проектирование данных, преобразовывать логическую модель в физическую. Этим средством поддерживаются все ODBC- и OLE DB-источники данных. С его помощью можно создавать триггеры для стандартной обработки нарушений ссылочной целостности в случае, если DDL-скрипт создается для Microsoft SQL Server, и серверные ограничения, если скрипт создается для другой СУБД. Отметим, что Visio при генерации скриптов позволяет указывать параметры организации физической памяти Oracle, Informix, Microsoft SQL Server, DB2 и некоторых других СУБД.

Помимо средств проектирования данных Visio включает средства объектно-ориентированного моделирования и генерации кода приложений Visual Basic 6, а также классов C++ и Java. Модели Visio можно сохранять в Microsoft Repository.

Visio, в отличие от специализированных средств проектирования данных, не обладает скриптовым языком, позволяющим создавать серверный код, не связанный с конкретной СУБД. При использовании этого продукта такой код нужно создавать на этапе физического проектирования в уже созданном скрипте. Однако, Visio в целом представляет собой продукт более широкого назначения, нежели другие рассмотренные выше средства проектирования данных. К тому же этот продукт является сервером автоматизации, обладает весьма обширной объектной моделью и встроенным средством разработки — Visual Basic for Applications, что позволяет, в частности, создавать на его базе разнообразные решения, в том числе и автоматизировать разработку моделей данных.

Пример 2. Разработать в среде Microsoft Visio инфологическую модель.

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

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

Пример выполнения

Рассмотрим несколько вариантов инфологической модели.

Вариант 1

Представим всю информацию как характеристики одного объекта – экзаменационной оценки.

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

Предположим, что Сергеев Сергей Петрович сдал экзамен по математике на ВМК на оценку 5. Мы внесли информацию об этом (математика, 15 июля 2003 г., ВМК, Сергеев, Сергей, Петрович, № аттестата – 123123, дата выдачи аттестата – 21 июня 2003 г., оценка 5) в нашу базу данных. Через некоторое время данный абитуриент сдает информатику. Мы вносим информацию (информатика, 21 июля 2003 г., ВМК, Сергеев, Сергей, Петрович, № аттестата – 123123, дата выдачи аттестата – 22 июня 2003 г., оценка 5). При вводе была допущена ошибка – мы неправильно ввели дату выдачи аттестата.

Таким образом, наша база данных дает противоречивую информацию. По одним данным аттестат был получен Сергеевым 21 июня, по другим – 22 июня.

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

Вариант 2

Между двумя сущностями должна существовать связь (абитуриент получает оценки):

АБИТУРИЕНТ <Получает> ОЦЕНКА

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

Попробуем избавиться и от этого недостатка.

Вариант 3

Между тремя сущностями существуют две связи:

· АБИТУРИЕНТ <Получает> ОЦЕНКА;

· АБИТУРИЕНТ <Сдает> ЭКЗАМЕН.

В этой модели данных нет недостатков, отмеченных в предыдущих двух моделях.

Разработка инфологической модели в Microsoft Visio может включать следующие шаги:

1. Запустить редактор MS Visio и выбрать «Новый документ» (рис. 4).

2. В ходе разработки можно использовать достаточно обширную библиотеку фигур. Наиболее часто используемые фигуры можно разместить на левой панели (рис. 5).

3. Разместить на рабочем поле 3 фигуры «Прямоугольник». В данных фигурах разместить надписи, согласно рисунку 6. Чтобы расположить текст на рисунке, необходимо сначала создать текстовое поле. Текстовое поле создается инструментом «Текст» на панели инструментов (рис. 7).

Рис. 4. Шаблоны Microsoft Visio

Рис. 5. Библиотека фигур Microsoft Visio

Рис. 6. Инфологическая модель

Рис. 7. Панель инструментов Microsoft Visio

Пример 3. Выполнить моделирование движения потоков данных по учету материальных ценностей в стандарте DFD на ООО «КГТ». Модель AS-IS.

1. Запустить редактор MS Visio. Выбрать категорию шаблонов «Программы и базы данных», шаблон «Схема модели потоков данных», нажать на кнопку «Создать».

2. Странице нового документа дать название «DFD контекст».

3. Создать новую модель в стандарте DFD. В данной работе допускается рассмотрение DFD-модели не с самого верхнего уровня, а непосредственно с уровня поставленной задачи. Разместить на данной странице элементы DFD-диаграммы в соответствии с обозначениями в табл. 1.

Таблица 1.

Элементы диаграммы потоков данных

№	Название элемента	Обозначение
В стандарте DFD	В редакторе Visio	В стандарте DFD	В редакторе Visio
1.	Функция	Процесс
2.	Внешняя сущность	Интерфейс
3.	Хранилище данных	Хранилище данных
	Стрелка	Поток данных	→

4. Основной недостаток реализации данной нотации в MS Visio в том, что ее основные фигуры («Функция», «Интерфейс» и «Хранилище данных») по умолчанию не имеют точек соединения, поэтому MS Visio при связывании этих фигур с помощью элементов «Поток данных» выстраивает линию соединения не всегда рационально. Но этот недостаток устраняется просто: достаточно добавить на соединяемые фигуры в нужном месте необходимые точки соединения. Тогда концы соединительных стрелок (потоков данных) будут четко «приклеены» к этим точкам, а отрезки ломанной соединительной линии можно подвинуть, так чтобы это выглядело красиво и аккуратно, потянув за зеленый курсор в середине отрезка.

5. На контекстной диаграмме («DFD контекст») разместить только один функциональный блок (Процесс), внешние сущности (Интерфейсы), и потоки данных, их соединяющие. Для элементов «Внешняя сущность» («Интерфейс») рекомендуется задать тень, так как это сильнее будет подчеркивать их визуальное отличие от функциональных блоков, и более будет приближено к стандарту DFD. Для задания тени нужно выделить элемент «Внешняя сущность», нажать клавишу F3 (или выбрать команду меню Формат – Заливка), в появившемся окне «Заливка» в категории «Тень» выбрать стиль «05: Смещение, вверх влево». Причем цвет тени не обязательно делать абсолютно черным, чтобы тень не сливалась со стрелкой. Для корректного отображения стрелок на DFD-диаграмме на соединяемые фигуры нужно добавить точки соединения, а для смещения подписей использовать изменение полей или элемент «Подписи» из шаблона «Фигуры схемы IDEF0». Стрелки подписей в виде молний можно не отображать если задать им цвет белый или прозрачный. В результате проделанных действий контекстная диаграмма будет выглядеть примерно так, как показано на рис. 8.

Рис. 8. Контекстная диаграмма DFD AS-IS

6. Добавить новую страницу, переименовать ее в «DFD AS-IS». Разместить на ней все необходимые для построения DFD-диаграммы элементы.

Общие правила построения DFD-диаграмм:

· на DFD-диаграммах рассматривается движение (циркуляция) потоков данных при выполнении каких-либо процессов. Поэтому в отличие от IDEF0-диаграмм, на DFD-диаграммах нет явного начала и конца, и стрелки не должны приходить «из ниоткуда» и уходить «в никуда»;

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

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

· не должно быть связей между внешними сущностями. Во внешних сущностях не должно быть обработки информации;

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

· нужно избегать пересечений стрелок, для этого можно создавать копии хранилищ данных. Множественные однородные потоки данных можно объединять в один;

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

К названиям элементов DFD-диаграмм предъявляются следующие требования:

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

Функциональные блоки символизируют функции по обработке потоков, направленных в них. Таким образом, в блок должен входить определенный документ или информация (например: «Заказ клиента»), а выходить другой документ, полученный в результате работы функционального блока (например: «Данные заказа»). Название блока должно отражать выполняемую им функцию, например: «Обработать заказы», «Проконтролировать оплату» и т.п. Или возможен иной вариант наименования функций: «Обработка заказов», «Контроль оплаты» и т.п.

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

Хранилища данных представляют собой объекты, собирающие и хранящие информацию. Роль хранилища данных на DFD-диаграмме следующая: в рамках движения информации потоки переходят от одной функции к другой, причем каждая из них совершает определенные преобразования над данной информацией. Часто бывает необходимо сохранить временно или постоянно какую-то информацию на пути ее движения от одной функции к другой (например, зафиксировать в базе данных поступивший заказ, или информацию об оплате счета). Для этого на DFD-диаграммах и используются хранилища данных. Они могут являться аналогами таблиц в схеме базы данных (на DFD-диаграммах AS-IS и TO-BE), а также бумажных хранителей информации (допускается только на DFD-диаграммах AS-IS). Названия хранилищ данных должны быть конкретными, и отражать суть хранимой в них информации. Например: «Клиенты», «Заказы» и др. Не допускаются «глобальные» и расплывчатые названия, такие как: «База данных», «Информационная система», «Архив» и т.п. На одной DFD-диаграмме также допускается отображать одно и то же хранилище данных несколько раз.

Рис. 9. Пример названия хранилищ данных. Фрагмент DFD-диаграммы

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

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

ТЕМА 3. ОБЩАЯ ХАРАКТЕРИСТИКА CASE-СРЕДСТВА IBM RATIONAL ROSE

Поиск по сайту: