Стадия «Разработка аванпроекта»

Стадия «Разработка аванпроекта» содержит два этапа: «Формирование требований к ИС» и «Разработка концепций ИС».

Основным содержанием этапа «Формирование требований к ИС» является разработка модели «AS IS» и документа «Технико-экономическое обоснование». Модель «AS IS» рекомендуется разработать в составе трех типов диаграмм: организационная структура предприятия, схема внешнего документооборота и диаграммы Swim Lane (плавательные дорожки).

Рисунок 3.2 - Организационная диаграмма поликлиники

 

Эти диаграммы строятся в среде пакета All Fusion Process Modeler (BPwin) соответственно в методологиях Organization Charts, Data Flow Diagram (DFD) и Swim Lane Diagram [Коваленко]. Возможно применение для этих целей и другие программные инструментарии, например, Oracle Designer 10g, Rational Rose, MS Visio, Business Studio и т.п.

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

Рисунок 3.3 - Схема документооборота АРМ врача-офтальмолога с внешними объектами

 

Разработка подобной схемы позволит в интегрированном виде понять информационные процессы, происходящие на предприятии и перейти к реализации наиболее сложной части построения модели «AS IS»: выявлению бизнес-процессов и построению для каждого из них диаграммы плавательных дорожек (рис. 3.4-3.5).

Рисунок 3.4 - Диаграмма «Регистрация и размещение»

Рисунок 3.5 - Диаграмма «Расчет с клиентами»

 

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

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

Каждый бизнес-процесс характеризуется:

· четко определенным во времени началом и концом;

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

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

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

· Диаграммы Swim Lane идеально подходят для графического отображения в нотации IDEF3 бизнес-процессов:

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

· с помощью пяти перекрестков легко реализуются любые логические условия;

· на ней удобно размещать все документы (внешние и внутренние);

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

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

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

После построения модели «AS IS» на основе этих трех типов диаграмм (рис. 3.2-3.5) раз-работчик (системный аналитик) должен получить четкое представление о существующей системе управления предприятиям, выявить существующие недостатки, определить пути их устранения и сформулировать ожидаемый технико-экономический эффект от внедрения информационной системы. На основании этой информации формируется результирующий для этапа «Формирование требований к ИС» документе «Технико-экономическое обоснование» (ГОСТ 24.202-80, РД 50-34.698-90), который рекомендуется разместить в Приложении к дипломному проекту.

Документ ТЭО ИС должен состоять [A4] из введения и следующих разделов (сокращенный вариант):

Раздел «Характеристика объекта и существующей системы управления» должен содержать:

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

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

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

Раздел «Цели, критерии и ограничения создания ИС» должен содержать:

· формулировку производственно-хозяйственных, научно-технических и экономических целей и критериев создания ИС;

· характеристику ограничений по созданию ИС.

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

Документ ТЭО разрабатывается в основном для Заказчика, чтобы убедить его в необходимости использования ИС в управлении предприятием.

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

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

Основой для построения функциональной диаграммы является модель «AS IS», но подвергнутая существенной модернизации.

Во-первых, в ней должны быть устранены недостатки, указанные в ТЭО.

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

В-третьих, следует рассмотреть возможные варианты глобального изменения управленческих процессов. В качестве примера рассмотрим построение функциональной модели «ТО ВЕ» для управления городом, используя для этого стилизованные диаграммы потоков данных «объектного» типа (рис. 3.6).

Рисунок 3.6 - Модель управления городом «AS IS»

 

 

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

Модель управления «ТО ВЕ» финансовыми и материальными потоками муниципального образования построена по принципу корпорации, в которой централизован ряд финансово-хозяйственных процедур и создана служба муниципальных закупок (рис. 3.7).

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

Рисунок 3.7 - Модель управления городом «TO BE»

 

Данный пример является типичной задачей бизнес-анализа, для которой широко применяются методологии IDEF0, IDEF3 и DFD.

В-четвертых, необходимо использовать принципы Business process reengineering (BPR), основного инструмента при построении модели «TO BE», который предполагает радикальное переосмысление и модификацию бизнес-процессов для достижения резких, скачкообразных улучше-ний главных показателей деятельности предприятия, таких, как стоимость, качество, сервис и тем-пы.

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

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

Каждый из девяти принципов BPR необходимо «сфокусировать» на диаграммы модели «AS IS» и попытаться применить их для оптимизации бизнес-процессов при построении функциональной модели «ТО ВЕ» [Коваленко].

Построение функциональной модели «ТО ВЕ» начинается с создания контекстной диаграммы (рис. 3.8) с учетом всех перечисленных выше приемов по оптимизации модели «AS IS». Контекстная диаграмма содержит полную информацию о входной и выходной информации, пользователях системы и нормативной документации, в соответствии с которой выполняются бизнес-процессы.

Состав функциональных блоков 1-го уровня декомпозиции обычно определяется количеством заместителей руководителя. В том случае, когда разработчик использует процессный подход к управлению, возможно использование модифицированных диаграмм модели «AS IS» в качестве функциональных блоков первого уровня декомпозиции.

Первые 2-3 уровня декомпозиции рекомендуется выполнять в IDEF0-методологии, поскольку имеющиеся в ней ICOM-коды обеспечивают связанность диаграмм различных уровней. По мере приближения к моделированию процессов на рабочих местах следует использовать методологи IDEF3 и DFD, так как они более удобны для описания логики процессов и документооборота [Коваленко, Маклаков].

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

Результат построения функциональной модели может быть представлен одной диаграммой – «деревом узлов» (рис. 3.9). Все блоки нижнего уровня иерархии определяют функциональный состав проектируемой ИС и затем на этапе «Рабочее проектирование» они будут реализованы в виде программных модулей.

Полностью функциональную модель рекомендуется разместить в Приложении к дипломному проекту, а в тексте пояснительной записки к дипломному проекту полезно оставить только контекстную диаграмму, первый уровень декомпозиции и диаграмму «Дерево узлов».

На базе функциональной модели можно выполнить расчет стоимости эксплуатации ИС в среде пакета BPwin помощью инструмента стоимостного анализа, основанного на работах – Activity Based Costing (ABC) [Коваленко, Маклаков]. Итоговая стоимость эксплуатации заносится в функциональный блок контекстной диаграммы. Например, стоимость ежемесячной эксплуатации ИС транспортного предприятия составит 21230 руб., АРМ врача - 24101 рублей (рис. 3.8, 3.9).

Рисунок 3.8 - Контекстная диаграмма функциональной модели «ТО ВЕ» ИС транспортного предприятия

Рисунок 3.9 - Диаграмма «Дерево узлов» АРМ врача-офтальмолога

 

Функциональная модель является основой для построения базы данных, поскольку она однозначно определяет состав входных и выходных документов. Поэтому БД должна быть построена исходя из следующих двух соображений: все входные документы необходимо разместить в БД, а данные, необходимые для формирования выходных документов, также должны находиться в БД. Построение БД рекомендуется начать с базы данных логического уровня в среде пакета All Fusion Erwin Data Modeler (или Oracle Designer 10g) с помощью методологии IDEF1X [Коваленко]. БД логического уровня (ER-диаграмма) должна иметь 3-ю нормальную форму Кодда и не иметь отношений типа M:M (рис. 3.10). При этом в БД необходимо максимально использовать справочники («Номерной фонд», «Услуги» на рис. 3.10), чтобы заменить ввод с клавиатуры справочные данные вызовом их в виде всплывающих меню.

Пакет ALL Fusion Modeling Suite обеспечивает интеграцию IDEF- и IDEF1X-моделей в среде пакета BPwin для связывания объектов БД (сущностей и атрибутов) с дугами и работами функциональной модели [Коваленко]. Связывание моделей гарантирует завершенность анализа и полную информационную поддержку для всех функциональных модулей системы. Другими словами, при выполнении программных модулей не возникнет ситуация, когда не удастся занести информацию в БД или не будет найдены необходимые данные в БД.

Результаты связывания функциональной и информационной моделей могут быть отражены в пяти видах отчетов, настройка которых производится в окне Data Usage Report (Tools/Report/ Data Usage Report). Анализ отчетов позволяет выявить атрибуты, которые не используются при работе программных модулей и являются лишними, если только в них не планируется хранение вычисляемых в процессе работы данных. Также определятся отсутствие необходимых сущностей или атрибутов для информационной поддержки функциональных модулей. В обоих случаях коррекция БД выполняется непосредственно в среде BPwin, а затем экспортируется в пакет ERwin [Коваленко, Маклаков]. Затем средствами пакета ERwin может быть выполнена генерация схемы базы данных в среде практически любого современного СУБД. В дипломном проекте рекомендуется сгенерировать схему БД в СУБД Access (рис. 3.11) [Коваленко, Маклаков].

Рисунок 3.10 - БД логического уровня для ИС санатория

Рисунок 3.11 - Физическая структура БД для ИС санатория

 

Рисунок 3.12 - Дерево меню АРМ врача-офтальмолога

 

 

Рисунок 3.13 - Дерево меню ИС транспортного мероприятия

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

· запустить в работу все программные модули, полученные на нижнем уровне иерархии диаграммы «Дерево узлов» (рис. 3.9);

· обеспечить доступ к каждому полю таблиц БД, чтобы выполнить с ним операции ввода, изменения или удаления данных (рис. 3.11).

В самом простом случае «Дерево меню» может повторить диаграмму «Дерево узлов» (рис. 3.12). Такой вид меню удобен, например, для систем типа АРМ. В информационных системах с большим количеством пользователей можно в главном меню выделить вкладки (кнопки) для конкретных групп пользователей: руководитель, бухгалтерия, отдел кадров и т.п. (рис. 3.13). Выбор структуры «Дерева меню» определяется функциональностью системы, требованиями к правам доступа пользователей, желаниями Заказчика и т.п.

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

3.2.1.2 Стадия «Разработка технического задания»

 

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

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

При разработке технического задания необходимо решить следующие задачи:

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

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

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

· установить общие требования к проектируемой системе;

· определить перечень задач создания системы и исполнителей;

· определить этапы создания системы и сроки их выполнения;

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

ТЗ на ИС содержит следующие разделы, которые могут быть разделены на подразделы:

· 1) общие сведения;

· 2) назначение и цели создания (развития) системы;

· 3) характеристика объектов автоматизации;

· 4) требования к системе;

· 5) состав и содержание работ по созданию системы;

· 6) порядок контроля и приемки системы;

· 7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

· 8) требования к документированию;

· 9) источники разработки.