Создание прототипов важный элемент в последовательности разработки концепции новой информационной системы. Прототип системы – это частичная или возможная реализация предполагаемого нового продукта. Прототипы позволяют решать три основные задачи:
- Пояснение и завершение процесса формирования требований. В этом случае прототип используется как инструмент уточнения требований, позволяет указать на ошибки в формулировке требований, которые можно исправить без больших затрат до создания реального продукта.
- Исследование альтернативных решений. В данном случае прототип используется как инструмент конструирования, который позволяет исследовать различные варианты реализации требований и оценить возможные технические приемы.
- Создание конечного продукта. В данном случае прототип используется как инструмент эволюционной или инкрементной модели построения системы.
Основная цель построения прототипа – устранение неясностей на ранних стадиях процесса разработки.
К прототипам, проясняющим и завершающим процесс формулировки требований, относятся модели TO – BE. Создание этих моделей является важнейшим этапом в создании системного проекта. На этом этапе моделируются новые бизнес-процессы и новые потоки данных, которые появятся на предприятии в результате внедрения новой информационной системы. Эти модели строятся на основании утвержденных в спецификации требований к новой ИС и являются графическим изображением однозначного понимания проблем заказчиком и исполнителем проекта.
Начнем построение моделей с модели бизнес-процесса. Безусловно, что эта модель будет отличаться от модели AS-IS, поскольку в результате формирования требований появились предложения по реорганизации бизнес-процессов.
Контекстная модель:
Название: Заказ и отпуск готовой продукции «Метиз – М».
Цель: Увеличение числа продаж. Увеличение числа продаж на 50%, уменьшение среднего рабочего времени каждого сотрудника на обслуживание заказчика до 20 минут, уменьшение времени заказчика для оформления заказа не более 1 часа с учетом двух возможностей: сетевого обслуживания и непосредственного контакта в течение 3 месяцев после первого выпуска информационной системы.
Точка зрения: начальник отдела продаж.
Входные данные: данные системы склад, данные о заказчике, заказ.
Выходные данные: заказ, отказ (отказ от выполнения заказа), требование, счет, закрытие (информация о закрытии договора), отчеты (аналитические отчеты), изменение склада (данные для системы «Склад» после продажи), изменение плана (корректировка производственного задания для выполнения заказа). Поскольку выходных данных много и изображение их на контекстной модели будет затруднено, то их нужно сгруппировать, например, следующим образом:
- обработанный заказ (заказ со статусом «принят» или отказ от выполнения заказа);
- документы на оплату и получение (счет, требование);
- отчеты;
- закрытие договора;
- данные для систем «Склад» и «Производство».
Управление: номенклатура (номенклатура крепежных изделий) и цена (текущая цена крепежных изделий), устав (устав предприятия), положение (положение об отделе продаж), документы системы (нормативные документы предприятия для сопровождения системы продаж).
Механизмы: сотрудник отдела продаж, система продаж.
Рис.32 Контекстная диаграмма модели TO-BE
При декомпозиции контекстной диаграммы, необходимо учитывать новые функции системы, поскольку в процессе формирования требований к новой информационной системе произошло изменение бизнес-процесса (реинжинеринг) в рассматриваемой предметной области. Действительно, в модели AS-IS бизнес-процесс реализации товара состоял из следующих основных функций: проверка готовности заказа, организация оплаты, организация выдачи, подготовка отчетов. В новой системе большое значение уделяется приему и размещению заказа (в случае отсутствия готовой продукции на складе). Кроме того, система должна быть интегрирована в общую систему управления предприятием. Новые функции системы описаны в документе бизнес-требования. Поскольку все они не могут быть отображены на диаграмме декомпозиции (ограничения инструментария), сгруппируем их следующим образом: прием и размещение заказа, организация оплаты, организация отгрузки, закрытие договора, создание и выдача отчетов.
Рис.33 Декомпозиция контекстной диаграммы
Декомпозицию основных функций в данном разделе рассматривать не будем. Это задание для самостоятельной работы. Приступим к созданию модели DFD – диаграмм потоков данных.
При создании этой модели необходимо учесть взаимодействие с системами «Производство», «Склад». Обратить внимание на оформление заказа и на возможность различных форм оплаты заказа.
Рис.34. Контекстная диаграмма информационных потоков
Декомпозиция контекстной диаграммы производится следующим образом. Функции обработки информации те же, что и при декомпозиции модели бизнес-процесса. Однако на ней появляются хранилища данных: склад, производство, заказы, отчеты. При этом система оплаты пока не декомпозируется.
Рис.35. Декомпозиция контекстной диаграммы DFD
Рис.36. Декомпозиция диаграммы прием и размещение заказа
Для того чтобы понять структуру базы данных и создать логическую информационную модель будущей системы необходимо продолжить декомпозицию диаграмм до уровня, который определит не только основные сущности и связи между ними, но и свойства (атрибуты) сущностей. В самом сложном случае – это уровень операций обработки записей.
Задания для самостоятельной работы:
1. Разработать и описать бизнес-требования для задачи самостоятельного решения. Выбрать модель управления бизнес-процесса.
2. Разработать и описать требование одного пользователя для задачи самостоятельного решения.
3. Разработать и описать спецификации требований для выбранной в пункте 2.1. задачи самостоятельного решения.
4. Создать прототипы для выбранной задачи.
