![]() Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву ![]() Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Стадия «Разработка аванпроекта»Содержание книги
Поиск на нашем сайте
Стадия «Разработка аванпроекта» содержит два этапа: «Формирование требований к ИС» и «Разработка концепций ИС». Основным содержанием этапа «Формирование требований к ИС» является разработка модели «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) источники разработки.
|
||||||||||||
Последнее изменение этой страницы: 2016-08-26; просмотров: 646; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.15.186.178 (0.013 с.) |