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

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

Примеры систем отчётности:

· система управленческой отчётности,

· система аналитической отчётности,

· система ключевых показателей эффективности подразделений предприятия,

· система формирования показателей для расчёта скорингового балла по кредитной заявке.

Все это является неотъемлемой частью современного предприятия, которое перешло в новую по отношению к предприятиям XX века. Оно стало электронным, или как говорит Бил Гейтс: «Перешло на электронные рельсы».

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

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

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

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

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

· четко определенные слои

· формальные и явные интерфейсы между слоями

· скрытые и защищенные детали внутри каждого слоя.

Рисунок 2. Архитектура современных систем

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

· выполнение требуемых задач

· принятие решений в соответствующей компетенции

· запуск других задач в слое правил бизнеса и других слоях.

Независимость слоев трехслойной системной архитектуры обеспечивает следующие основные преимущества:

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

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

· разделение усилий коллектива разработчиков.

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

· информационная модель (и база данных) рассматриваются как центральные понятия при анализе и проектировании;

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

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

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

· сама по себе информационная модель является недостаточной (хотя и важной) для решения задач консалтинга;

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

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

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

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

Таблица 1. Системная архитектура

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

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

Реализация. На данном этапе проект преобразуется в систему.

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

Спецификация процесса (СП) используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD (т.е. если он достаточно невелик, и его описание может занимать до одной страницы текста). Фактически СП представляют собой алгоритмы описания задач, выполняемых процессами: множество всех СП является полной спецификацией системы. СП содержат номер и / или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков.

Независимо от используемой нотации спецификация процесса должна начинаться с ключевого слова (например, @СПЕЦПРОЦ). Требуемые входные и выходные данные должны быть специфицированы следующим образом:

@ВХОД = <имя символа данных>

@ВЫХОД = <имя символа данных>

@ВХОДВЫХОД = <имя символа данных>,

где <имя символа данных> - соответствующее имя из словаря данных.

Эти ключевые слова должны использоваться перед определением СП, например,

@ВХОД = СЛОВА ПАМЯТИ

@ВЫХОД = ХРАНИМЫЕ ЗНАЧЕНИЯ

@СПЕЦПРОЦ

Для всех СЛОВ ПАМЯТИ выполнить:

Распечатать ХРАНИМЫЕ ЗНАЧЕНИЯ

@

Ситуация, когда символ данных является одновременно входным и выходным, может быть описана двумя способами: либо символ описывается два раза с помощью @ВХОД и @ВЫХОД, либо один раз с помощью @ВХОДВЫХОД.

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

Спецификации должны удовлетворять следующим требованиям:

· для каждого процесса нижнего уровня должна существовать одна и только одна спецификация;

· спецификация должна определять способ преобразования входных потоков в выходные;

· нет необходимости (на данном этапе) определять метод реализации этого преобразования;

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

· набор конструкций для построения спецификации должен быть простым и стандартным.

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

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

В состав языка входят следующие основные символы:

· глаголы, ориентированные на действие и применяемые к объектам;

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