Разработка информационной системы и разработка бизнеса

из "Реинжиниринг бизнеса - Реинжиниринг организаций и информационные технологии "

Объект может участвовать в нескольких прецедентах, играя некоторую роль в каждом из них. Полная совокупность обязательств объекта в системе представляется множеством его ролей. Один экземпляр объекта может принимать участие в нескольких экземплярах прецедентов. Таким образом, один прецедент может влиять на другой. Однако подобное влияние может приводить и к конфликтам, которых хотелось бы избежать. [c.225]
Чтобы избавиться от возможных конфликтов, необходимо отслеживать использование ресурсов. Для этого необходимо рассмотреть бизнес-систему на двух уровнях бизнес-уровень, содержащий модель бизнеса, и уровень ресурсов, описывающий, как ресурсы используются бизнес-моделью. [c.225]
В объектной модели бизнеса используются объекты трех типов интерфейсные, управляющие и объекты-сущности. Каждому из этих типов объектов соответствуют свои сущности в бизнесе. [c.225]
Управляющие объекты представляют действия, которые должны выполняться сотрудниками (человеческие ресурсы), использующими те или иные инструменты. [c.225]
Объекты-сущности представляют предметы и явления в бизнесе автомобили, документы или нечто более абстрактное, например знания о чем-либо. [c.225]
Модель бизнес-системы выполняется ресурсами компании. Ресурсы могут быть одушевленными (человеческими) или неодушевленными (компьютеры и информационные системы). Иными словами, модель бизнес-системы включает два уровня уровень бизнеса и уровень ресурсов. На уровне ресурсов модель описывает, как взаимодействуют между собой сотрудники компаний и как они используют информационные системы для выполнения прецедентов, представленных в П-модели бизнеса. На этом уровне можно обнаружить большое разнообразие типов человеческих ресурсов сотрудники отдела продаж, проектировщики и разработчики. К неодушевленным ресурсам относятся средства технической поддержки деятельности сотрудников, в первую очередь - информационные системы. [c.225]
Объекту-сущности бизнес-уровня обычно соответствует объект-сущность в идеальной О-модели информационной системы. Однако иногда удобно сопоставить атрибутам в модели бизнес-системы объекты-сущности в модели ИСП. Объекты-сущности бизнес-уровня не имеют непосредственного соответствия в П-модели ИСП. К объекту-сущности в модели бизнеса могут иметь доступ различные активные объекты бизнес-системы. Следовательно, соответствующий объект-сущность (или объекты-сущности) в информационной модели может участвовать в нескольких прецедентах ИСП. [c.227]
Поясним изложенное выше на конкретном примере, в котором в модели бизнеса активный объект X имеет обязательства, обозначенные как А, Б и В. Следовательно, в П-модели информационной системы можно выделить субъект с именем X и прецеденты с именами А, Б и В. Реализуя обязательство В, активный объект X в модели бизнеса обращается к объекту-сущности Y. В идеальной объектной модели информационной системы это соответствует тому, что объект-сущность Y участвует в прецеденте В (см. рис. 8.14). [c.227]
Предложенный алгоритм не отвечает на вопрос, как следует интерпретировать отношение коммуникации между активными объектами в модели бизнеса Объекты взаимодействуют друг с другом, и следует выяснить, как это взаимодействие может быть поддержано средствами информационной системы. В частности, если информационная система обеспечивает автоматическую поддержку коммуникации между объектами бизнес-системы, то следует освободить эти объекты от обязательства инициировать коммуникацию. Однако, как правило, это не так, и обычно задача информационной системы состоит в передаче информации между объектами бизнес-системы. [c.228]
Приведенный выше алгоритм позволяет построить основу модели информационной системы по объектной модели бизнеса. К сожалению, модель бизнеса дает слишком абстрактное представление о том, как сотрудники корпорации намерены использовать информационную систему, и не существует такого алгоритма, который помог бы построить более детальное описание способов взаимодействия пользователей с этой системой. [c.228]
Построение хороших интерфейсов пользователей ИСП - это целая наука. Моделированию прецедентов должна предшествовать работа, к которой привлекаются пользователи по определению прецедентов ИСП и используемого в них пользовательского интерфейса. Для этого можно организовать серию рабочих встреч, в ходе которых разработчики интерфейсов изучают то, как будущие пользователи выполняют свои обычные обязанности на своих рабочих местах. Разработчики интервьюируют их и просят описать всевозможные сценарии использования создаваемой информационной системы, т.е. описать экземпляры прецедентов информационной системы. Чтобы добиться лучшего взаимопонимания на данном этапе, разработчики представляют пользователям наброски интерфейсов и по достижении более или менее устойчивых решений относительно интерфейсов приступают к созданию прототипов. Более подробные сведения об этом можно найти в [7] и [2]. [c.228]
В упрощенной бизнес-модели банка выделим двух субъектов Клиент и Информационное Бюро Банка. Клиент может инициировать один из следующих прецедентов Получение Кредита (Кредитование), Управление Счетом (Управление) и Инвестирование (рис. 8.15). [c.228]
Обратите внимание, что объект-сущность Клиент отличается от субъекта Клиент. Первый необходим для представления информации обо всех клиентах, зарегистрированных в банке, а второй - для представления клиента, обращающегося в банк для выполнения некоторой операции. Чтобы избежать недоразумений, будем явно указывать, о каком Клиенте идет речь -объекте-сущности или субъекте. [c.229]
Рассуждая подобным образом, выделяем интерфейсный объект Обработчик Инвестиций для прецедента Инвестирование. Объектами-сущностями здесь являются Инвестиционный План, Клиент, Счет и Знания-о-Рынке. Можно выделить управляющий объект Аналитик-Рынка для сбора долговременных Знаний-о-Рынке. Для прецедента Управление Счетом можно выделить интерфейсный объект Обработчик Счета и объекты-сущности План Сбережений, Клиент и Счет. [c.229]
Многие банки предпочитают использовать один и тот же тип ресурса для Обработчика Кредитов, Обработчика Инвестирования и Обработчика Счета. Поэтому в окончательном варианте модели будем работать с одним интерфейсным объектом под названием Обслуживающий Клерк, позволяющим выполнять три различные задания (рис. 8.16). [c.229]
Рассмотрим теперь вопрос о том, какая требуется ИСП для поддержания описанного выше бизнеса. [c.229]
Интерфейсный объект Обслуживающий Клерк принимает участие в трех прецедентах (см. рис. 8.16), т.е. он имеет по крайней мере три обязательства (ответственности). Для того чтобы кредитовать или инвестировать, банк должен проанализировать различные альтернативы, оценить безопасность, риск и т.п. Следовательно, в ИСП целесообразно ввести субъект Обслуживающий Клерк и два прецедента Приложение кредитования и План инвестиций. Управляющий объект бизнес-системы Аналитик Рынка приводит к введению в ИСП субъекта Аналитик Рынка и прецедента Анализ-Знаний-о-Рынке. [c.230]
Заметим, что это далеко не полный перечень участвующих объектов. Другие объекты будут обнаружены через прецеденты ИСП. Таким образом, между объектами бизнес-системы и объектами ИСП существует некоторое соответствие. [c.230]
Для Обслуживающего Клерка необходима следующая поддержка интерфейсный объект должен контролировать количество денег на счетах клиента, т.е. снимать деньги со счетов, переводить их с одного счета на другой, запрашивать баланс счета, класть деньги на счет, а также запрашивать информацию о состоянии рынка. [c.231]

Вернуться к основной статье