Построение информационной системы поддержки

Информационные технологии являются основой реинжиниринга бизнес-процессов. Информационная система (ИС) решающим образом влияет на функционирование процессов и при правильном использовании приводит к многократному повышению их результативности [3].

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

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

Поскольку информационная система является достаточно сложной системой, для ее создания необходима мощная технология разработки. Рассмотрим этапы разработки программного обеспечения [3] (см. рис. 4.8):

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

2. Анализ требований. Цель этого этапа состоит в проверке полноты и непротиворечивости спецификаций требований и построении Прецедент-модели информационной системы. П-модель отражает функциональные требования к системе. При ее построении должны быть определены субъекты системы (пользователи), основные прецеденты, их взаимосвязи (интерфейсы). Должно быть составлено высокоуровневое описание прецедентов.

3. Идеальное проектирование (логическое проектирование). Этот этап предназначен для построения логической структуры информационной системы. Результатом является объектная модель, в которой отражены основные объекты системы – функциональные (процедуры), информационные (данные), интерфейсные (экранные формы) – а также их связи и связи с конечными пользователями системы.

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

5. Реализация. Цель данного этапа – создание программного кода и баз данных информационной системы.

6. Тестирование. Здесь проверяется соответствие информационной системы предъявляемым к ней требованиям. Программный продукт не может считаться готовым до тех пор, пока «настоящий» пользователь не признает его работу удовлетворительной. Тестирование - длительный и дорогостоящий этап (на него приходится 25 – 50% стоимости разработки). Раньше тестирование относили на конец процесса разработки и сводили только к проверке программного кода. Сейчас большинство специалистов считают, что о тестировании следует позаботиться с самого начала разработки. При этом специально выбранные пользователи проверяют не только макеты и готовые версии продукта, но и документацию. Результатом этого этапа должны быть корректные результаты прогона системы на тестовых задачах.

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

Описание потока событий прецедента «Разработка ИС» представляет собой подробное описание хода работ на каждом из этапов разработки – от сбора требований до тестирования системы.

Построение объектной модели прецедента «Разработка ИС» включает в себя:

· определение участников разработки (интерфейсных и управляющих объектов),

· определение для каждого этапа исходных данных и результатов (объектов-сущностей);

· определение взаимодействий между объектами.

На рис. 4.9 приведена схема взаимосвязи основных объектов, участвующих в прецеденте «Разработка ИС».

Приведем описание потока событий прецедента разработки информационной системы в терминах участвующих объектов:

1. Сбор требований. Интерфейсный объект Интервьюер опрашивает потенциальных Пользователей ИС и Заказчиков с целью выявления их пожеланий и требований к системе. Собранная информация обрабатывается и формируется Список требований. Элементы списка упорядочены по приоритетам и содержат приблизительные оценки сроков разработки.

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

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

4. Реальное проектирование. После того, как О-модель ИС создана, Разработчик принимает ее в качестве отправной точки для создания модели реализации (эта модель не показана на рис. 4.9). Разработчик начинает с адаптации модели к условиям реального окружения с учетом выбранных средств реализации (языка программирования, СУБД и т.д.) и возможностей стыковки ИС с существующим программным обеспечением. Затем формируется физическая структура баз данных, составляются подробные спецификации функциональных блоков, создаются макеты экранных форм.

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

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

Рассмотрим подробнее процесс формирования П-модели и О-модели информационной системы.

П-модель информационной системы формируется Аналитиком требований на основании Спецификации требований и О-модели нового бизнеса. Построение П-модели начинается с выделения прецедентов и субъектов системы. В [3] описан алгоритм выделения прецедентов и субъектов информационной системы из модели бизнеса. Рассмотрим основные идеи этого алгоритма. Для каждого субъекта, а также управляющего или интерфейсного объекта модели бизнеса выполняются следующие действия:

1. Определяется, использует ли данный объект в своей деятельности информационную систему. Если да, то в модели ИС ему сопоставляется субъект – пользователь информационной системы.

2. Проверяются все обязательства объекта. Если некоторое обязательство осуществляется с помощью информационной системы, то либо в модели ИС идентифицируется новый прецедент ИС и в его описание вносится соответствующее обязательство, либо обязательство вносится в уже выделенный ранее прецедент информационной системы.

Поясним изложенное выше на конкретном примере – выделении субъектов и прецедентов информационной системы на основании О-модели бизнес-процесса «Продажа заказного продукта» (см. п. 3.2). На рис. 3.4 приведена схема взаимодействия объектов данного прецедента, на рис. 3.6 – диаграмма взаимодействия объектов.

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

Например, Продавец при приеме заказа от Клиента заносит Заказ в информационную систему. В этом случае объекту Продавец модели бизнеса сопоставляется субъект Продавец в модели ИС. Продавец в прецеденте «Продажа заказного продукта» имеет следующие обязательства:

· «Получить заказ клиента»;

· «Передать заказ проектировщику»;

· «Передать отправителю адрес клиента»;

· «Принять оплату клиента».

Первые 3 обязательства могут быть выполнены с помощью одного прецедента ИС «Обработка заказа» (см. рис. 4.10). В описание этого прецедента вносятся функции ввода, хранения и использования информации о заказе и адресе клиента. Для обязательства «Принять оплату клиента» выделяется новый прецедент ИС «Оплата заказа», и в его описание вносится соответствующая функция (см. рис. 4.10).

Если субъект Клиент бизнес-модели тоже может использовать информационную систему (например, вносить заказ в ИС через Интернет), то ему в модели ИС сопоставляется субъект Клиент. Обязательство Клиента «Заказ продукта» может выполняться с помощью уже выделенного прецедента «Обработка заказа» (соответствующая функция добавляется в его описание). Обязательство «Оплата продукта» не может выполняться без участия Продавца.

Аналогичным образом объекту Проектировщик модели бизнеса сопоставляется субъект Проектировщик модели ИС. С помощью информационной системы он может выполнять обязательство «получить информацию о заказанном продукте». При этом он может использовать ранее выделенный прецедент ИС «Обработка заказа».

Объекту Отправитель модели бизнеса сопоставляется субъект Отправитель модели ИС. Его обязательство «получить адрес клиента» может быть выполнено с помощью прецедента ИС «Обработка заказа», а обязательство «получить информацию об оплате» - с помощью прецедента «Оплата заказа».

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

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

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

Управляющие объекты – активные модули системы (процедуры), выполняющие некоторые операции, например, запись, удаление, поиск сортировка данных в базах данных, вычисления, преобразования данных.

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

Рассмотрим пример формирования О-модели прецедента ИС «Обработка заказа». Фрагмент данной модели приведен на рис. 4.11. Основные функции данного прецедента:

1. Ввод заказа (информации о заказываемом продукте и адресе клиента) либо Продавцом, либо непосредственно Клиентом.

2. Выдача информации о заказанном продукте Проектировщику продукта

3. Выдача информации об адресе клиента и о продукте Отправителю.

В качестве объекта-сущности здесь выступает информационный объект «заказ», содержащий информацию о заказанном продукте и об адресе клиента (см. рис. 4.11). Этот объект соответствует объекту «заказ» в модели бизнеса (в прецеденте «Продажа заказного продукта»).

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

Управляющими объектами являются: блок «Запись заказа», который вносит введенный заказ в базу данных; блок «Поиск заказа», который извлекает данные из БД и передает их блоку выдачи заказа.

Контрольные вопросы

1. Какова роль мотивации к проведению реинжиниринга для различных групп сотрудников компании?

2. Что должна содержать директива на проведение реинжиниринга?

3. Перечислите основных участников проекта по реинжинирингу, их роли и обязанности.

4. Каковы особенности каскадной, спиральной и макетной схемы разработки? Какая схема наиболее пригодна для реинжиниринга и почему?

5. Какие виды обсуждений Вы знаете? В чем состоят их отличительные особенности?

6. Что включает в себя анализ положения дел, проводимый на этапе визуализации?

7. Каким образом осуществляется работа по спецификации целей?

8. Каково основное содержание этапа обратного инжиниринга?

9. Каково основное содержание этапа прямого инжиниринга?

10. Каковы основные характеристики «хорошего» прецедента модели нового бизнеса?

11. Что включает в себя разработка новой оргструктуры?