Методические указания по выполнению дипломных работ (стр. 14 из 25)

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

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

3.3. Процессный подход.

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

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

Концепция управления бизнес-процессами в различной степени реализована в следующих подходах: MRP (Manufacturing Resource Planning) – планирование ресурсов производства; TQM (Total Quality Management) - всеобщее управление качеством; BPR (Business Process Reengineering) – реинжиниринг бизнес-процессов.

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

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

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

Рис.3.3. Концептуальная схема управления процессом.

Владелец процесса – это должностное лицо, наделённое правами и полномочиями, а также ресурсами, необходимыми для выполнения процесса, и несущее ответственность за результат процесса.

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

Ресурсы находятся под управлением владельца, и их объём планируется на большое количество циклов, т.е. на длительный период работы.

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

Примерами выходов бизнес – процессов являются такие объекты как: готовая продукция, документация, информация (в частности отчётная), услуги и т.п.

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

Вход бизнес–процесса – продукт, который при выполнении бизнес – процесса преобразуется в выход и должен иметь своего поставщика. К входам бизнес – процесса могут относиться такие составляющие как сырьё и материалы, полуфабрикаты и комплектующие изделия, документация и информация, персонал (в системе «Кадры»), услуги и т.п.

Выходы, входы и ресурсы – являются материальными объектами.

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

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

Если рассматривать деятельность предприятия или организации в целом, то для описания используются укрупненные процессы. Примером процесса верхнего уровня может быть процесс закупок сырья и материалов для производства, который включает такие функции, как: планирование закупок, заключение договоров, оформление заказов, получение товарно-материальных ценностей (ТМЦ), оплату ТМЦ, отпуск ТМЦ в производство. Число уровней декомпозиции процессов определяется задачами проекта, и не должно быть слишком большим - более 7 уровней. При определении бизнес – процессов, существующих на предприятии, целесообразно начинать описание с верхнего уровня. Одним из важнейших вопросов, возникающих при моделировании бизнес – процессов, является определение необходимой глубины описания. При проведении декомпозиции моделей количество объектов на диаграмме растет в геометрической прогрессии. Важно изначально определить практически целесообразную степень детализации описания.

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

3.4. Методологии моделирования проблемных (предметных) областей.

В настоящее время существует большое число методологий моделирования проблемных (предметных) областей, некоторые из которых получили статус официального стандарта, например IDEF (Integrated Definitions), UML (Unified Modeling Language) [3, 6, 8, 9, 10, 11, 13, 14], а другие являются стандартами де-факто, например ARIS (Architecture of Integrated Information Systems) [12, ,13, 14]. Во многом перечисленные стандарты отражают одни и те же абстрактные категории, но делают это на основе различных подходов: структурного (функционально-ориентированного), объектно–ориентированного и комплексного.

В функционально- ориентированных моделях (Data Flow Diagram - DFD-диаграммах потоков данных, Structured Analysis and Design Technique - SADT-диаграммах) главными структурными компонентами являются функции (действия, операции, работы, бизнес-процессы), которые на диаграммах представляются вершинами графа и связываются дугами, которые представляют потоки объектов рис.3.4.

Рис. 3.4. Фрагмент диаграммы потоков данных.

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

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

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

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