Файл: 1 разработка сценария внедрения.pdf

23
Этап
Мероприятия
Разработка организационной модели в соче- тании с новым процессом
Определение технологических требований; выбор платформы для новых процессов
Выделение краткосрочных и долгосрочных мер
Утверждение
Анализ затрат и преимуществ; расчет прибы- ли на капитал
Оценка влияния на клиентов и служащих; оценка влияния на конкурентоспособность
Подготовка официального документа для высшего руководства
Проведение обзорных совещаний для озна- комления и утверждения деталей проекта орг- комитетом и высшим руководством
Внедрение
Завершение подробной разработки процессов и организационных моделей; определение но- вых рабочих обязанностей
Разработка систем поддержки
Реализация предварительных вариантов и первичные испытания
Ознакомление работников с новым вариан- том; разработка и осуществление плана ре- формы
Разработка поэтапного плана; внедрение как таковое
Разработка плана обучения; обучение работ- ников новым процессам и системам
Последующие мероприятия
Разработка мероприятий по периодической оценке; определение итогов нового процесса; внедрение программы непрерывного совер- шенствования нового процесса
Предоставление окончательного отчета орг- комитету и администрации
1.2.3 Отображение и моделирование процессов
На сегодняшний день получили распространение три основ- ные методологии функционального моделирования (и сопутст- вующий им инструментарий): IDEF (Integrated DEFinition), UML
(Unified Modeling Language) и ARIS (Architecture of Integrated

24
Information Systems). Для каждой из них существуют определен- ные программные продукты, которые помимо разработки позво- ляют проводить преобразования и операции для последующей работы с полученными моделями. Наибольшее распространение сегодня получили методологии IDEF и программный продукт
BPWin, содержащий методологии IDEF0, IDEF3, DFD (Data Flow
Diagrams) и ERWin (IDEF1x) от компании Computer Associates.
История методологии IDEF начинается с 70-х годов ХХ века с методологии SADT (Structured Analysis and Design Technique), разработанной Дугласом Россом (Softtech INC). Изначально
SADT применялось Министерством Обороны США для практи- ческого моделирования процессов в рамках программы ICAM
(Integrated Computer Aided Manufacturing). Принципиальным тре- бованием при разработке рассматриваемого семейства методоло- гий была возможность эффективного обмена информацией меж- ду всеми специалистами – участниками программы ICAM (Icam
DEFinition). В последующем эта методология была трансформи- рована в стандарт IDEF0 (Function Modeling, FIPS № 183). Семей- ство IDEF включает уже упомянутые IDEF3 (Process Description
Capture) и IDEF1x (Data Modeling, FIPS № 184).
После опубликования стандартов они были успешно приме- нены в самых различных областях бизнеса, показав себя эффек- тивным средством анализа, конструирования и отображения биз- нес-процессов (к слову сказать, он активно применяется и в оте- чественных госструктурах, например в Государственной налого- вой инспекции). Более того, собственно с широким применением
IDEF (и предшествующей методологии SADT) и связано возник- новение основных идей популярного ныне понятия «реинжини- ринг бизнес-процессов» (Business Process Reengineering – BPR).
Информационный процесс – это устойчивый процесс (по- следовательность работ и действий с данными и информацией), относящийся к сопровождению производственно-хозяйственной деятельности компании и обычно ориентированный на информа- ционное обслуживание создания новой стоимости. Бизнес- процесс включает в себя иерархию взаимосвязанных функцио- нальных действий, реализующих одну (или несколько) бизнес- целей компании и отражающий результаты в информационной системе, например, информационное обеспечение управления и

25 анализа выпуска продукции или ресурсное обеспечение выпуска продукции (под продукцией здесь понимают товары, услуги, ре- шения, документы).
Работа с использованием метода IDEF начинается с поста- новки цели моделирования. Мировой опыт свидетельствует, что ошибки при постановке цели приводят в среднем к 50 % неудач в процессе моделирования. Формулирование цели изначально на- правляет работу в заданном направлении, а значит, ограничивает круг вопросов для анализа. Практическая работа начинается с оп- ределения контекста (Context, Context Diagram), то есть верхнего уровня системы, в нашем случае – предприятия. После формули- ровки цели необходимо очертить область моделирования (Scope), которая в последующем будет определять общие направления движения и глубину детализации (Decomposition). Собственно, сама методология IDEF определяет стандартизированные объек- ты для работы и отображения. Например, к таковым относятся функция (Activity), интерфейсная дуга (Arrow), заметка (Note) а также способ их расположения и трактования (Semantics).
В последнее время на российском рынке появился про- граммный продукт Business Studio, который специально создан для работы с методами IDEF и обладает интуитивным и дружест- венным интерфейсом (User-friendly Interface).
В основе нотации и методологии IDEF0 лежит понятие
«блока», то есть прямоугольника, который выражает некоторую функцию бизнеса (рисунок 1.10). В соответствии со стандартом функция должна быть выражена глагольным оборотом В IDEF0 роли сторон прямоугольника (функциональные значения) раз- личны: верхняя сторона имеет значение «управление», левая –
«вход», правая – «выход», нижняя – «механизм исполнения».

26
Рисунок 1.10 – Базовый блок методологии IDEF0
Вторым элементом методологии и нотации является «по- ток», называемый в стандарте «интерфейсная дуга». Это элемент, описывающий данные, неформальное управление, или что-либо другое, оказывающее влияние на функцию, изображенную бло- ком. Потоки обозначаются оборотом существительного.
В зависимости от того, к какой стороне блока направлен по- ток, он, соответственно, носит название «входной», «выходной»,
«управляющий». Изобразительным элементом, представляющим поток, является стрелка. Поток можно интерпретировать как представление объекта, под которым понимается как информа- ционный объект, так и реальный физический объект.
Важным фактором является то, что «источником» и «при- емником» потоков (то есть, началом и концом стрелки) могут быть, как правило, только блоки. При этом источником может являться только выходная сторона блока, приемником – любая из трех оставшихся. Если же необходимо подчеркнуть внешний ха- рактер потока, то может быть применен метод «туннелирования»
– скрытие или появление интерфейсной дуги из «туннеля».
И, наконец, «третьим китом» методологии IDEF0 является принцип функциональной декомпозиции блоков, который пред- ставляет собой модельную интерпретацию той практической си- туации, что любое действие (тем более такое сложное, как биз- нес-процесс) может быть разбито (декомпозировано) на более простые операции (действия, бизнес-функции). Или, другими словами, действие может быть представлено как совокупность элементарных функций.

27
Пример функциональной модели процесса отгрузки и дос- тавки продукции показан на рисунок 1.11.
Степень формализации описания бизнес-процессов может быть различной в зависимости от решаемых при этом задач. Для описания информационных процессов разработан специализиро- ванный язык BPEL (Business Process Execution Language). BPEL создан на основе XML для формального описания бизнес- процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия Web-служб и включает в эту модель поддержку транзакций.
В настоящее время активно развивается методология BPMS
(Business Process Management System) – класс программного обеспечения для управления бизнес-процессами и администра- тивными регламентами. (Употребляются также термины BPM- система и просто BPM). Использование BPMS позволяет органи- зовать эффективное взаимодействие между управленцами и ИТ- специалистами, лучше использовать существующие подсистемы и ускорить разработку новых.
Рисунок 1.11 – Пример функциональной модели процесса отгрузки и доставки
Основные функции BPMS – моделирование, исполнение и мониторинг бизнес-процессов. Основываясь на данных монито- ринга, предприятия выявляют узкие места и усовершенствуют

28 свои бизнес-процессы. Цикл управления замыкается, когда при помощи BPMS измененные бизнес-процессы оперативно вне- дряются в эксплуатацию.
Современные методы разработки и развития программного обеспечения ИС в полной мере стараются ориентироваться на возможности автоматизированного оперативного внесения изме- нений. Наиболее сложным оказался процесс стандартизации язы- ка BPEL для унификации использования одних и тех же конст- рукций программным обеспечением разных производителей.
Фирмы IBM и Microsoft определили два довольно-таки схожих языка: WSFL (Web Services Flow Language) и Xlang, соответст- венно.
Рост популярности BPML и открытое движение BPMS к пользователям привело корпорации Intalio Inc., IBM и Microsoft к решению объединить эти языки в новый язык BPEL4WS. В апре- ле 2003 года корпорации BEA Systems, IBM, Microsoft, SAP и
Siebel Systems передали BPEL4WS версии 1.1 в OASIS для стан- дартизирования в Web Services BPEL Technical Committee. Хотя
BPEL4WS появился в версиях 1.0 и 1.1, технический комитет
WS-BPEL OASIS проголосовал 14 сентября 2004 за то, чтобы на- звать спецификацию WS-BPEL 2.0. Это изменение было сделано, чтобы согласовать BPEL с другими стандартами Web-сервисов, которые на основании «Соглашения об именовании» начинаются сочетаниями букв «WS-».
Корпорации Active Endpoints, Adobe, BEA, IBM, Oracle и
SAP опубликовали согласованные спецификации BPEL4 People и
WS-HumanTask, в которых описывалось, как может быть реали- зовано в системе и нотациях BPEL взаимодействие процессов с людьми. Предполагается добавление в BPEL семантики в форме
WS-HumanTask и других разнообразных дополнений.
1.2.4 Обеспечение процесса анализа и проектирования
ИС возможностями CASE-технологий
Термин CASE (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Пер- воначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспече-

29 ния (ПО), в настоящее время приобрело новый смысл, охваты- вающий процесс разработки сложных ИС в целом.
Теперь под термином CASE-средства понимаются про- граммные средства, поддерживающие процессы создания и со- провождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (при- ложений) и баз данных, генерацию кода, тестирование, докумен- тирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Таким образом, современные CASE-средства вместе с системным программным обеспечением и техническими средствами поддержки образуют полную среду разработки ИС.
Появлению CASE-технологии и CASE-средств предшество- вали исследования в области методологии программирования.
Программирование обрело черты системного подхода с разра- боткой и внедрением языков высокого уровня, методов структур- ного и модульного программирования, средств визуального мо- делирования и проектирования на базе языка UML (Unified
Modeling Language), средств их поддержки, формальных и не- формальных языков описаний системных требований и специфи- каций и т. д. Кроме того, появлению CASE-технологии способст- вовали и такие факторы, как:
– подготовка аналитиков и программистов, восприимчи- вых к концепциям модульного и структурного программирова- ния;
– широкое внедрение и постоянный рост производительно- сти компьютеров, позволившие использовать эффективные гра- фические средства и автоматизировать большинство этапов про- ектирования;
– внедрение сетевой технологии, предоставившей возмож- ность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
CASE-технология представляет собой методологию проек- тирования ИС, а также набор инструментальных средств, позво- ляющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровож- дения ИС и разрабатывать приложения в соответствии с инфор-

30 мационными потребностями пользователей. Большинство суще- ствующих CASE-средств основано на методологиях структурно- го (в основном) или объектно-ориентированного анализа и про- ектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моде- лями системы, динамики поведения системы и архитектуры про- граммных средств.
CASE-средства позволяют создавать не только продукт, практически готовый к использованию, но и обеспечить «пра- вильный» процесс его разработки. Основная цель технологии – отделить проектирование программного обеспечения от его ко- дирования, сборки, тестирования и максимально «скрыть» от бу- дущих пользователей все детали разработки и функционирования
ПО. При этом значительно повышается эффективность работы проектировщика: сокращается время разработки, уменьшается число программных ошибок, программные модули можно ис- пользовать при следующих разработках.
Большинство CASE-средств основано на парадигме «мето- дология/метод/нотация/структура/средство».
Методология задает руководящие указания для оценки и выбора проекта разработки ПО, этапы и последовательность ра- бот, правила применения тех или иных методов.
Метод – систематическая процедура или технология генера- ции описаний компонент ПО (например, описание потоков и структур данных).
Нотации предназначены для описания системы в целом, ее элементов: графы, диаграммы, таблица, блок схемы, алгоритмы, формальные языки и языки программирования.
Структуры являются средством для реализации структурно- го анализа и построения структуры конкретной системы.
Средства – технологические и программные инструменты для поддержки и усиления методов.
CASE-технологии обладают следующими основными дос- тоинствами, которые позволяют широко использовать их при разработке информационных систем:
– ускоряют процесс коллективного проектирования и раз- работки;

31
– позволяют за короткий срок создать прототип заказанной системы с заданными свойствами;
– освобождают разработчика от рутинной работы, оставляя время для творчества;
– обеспечивают эффективность и качество разрабатывае- мого ПО за счет автоматизации контроля всего процесса разра- ботки;
– поддерживают сопровождение и развитие системы на высоком уровне.
Следует отметить, что, несмотря на все потенциальные воз- можности CASE-средств, существует достаточно много примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (Shelfware).
В связи с этим необходимо учитывать следующее:
– CASE-средства не обязательно дают немедленный эф- фект, он может быть получен только спустя какое-то время;
– реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
– CASE-средства обеспечивают возможности для получе- ния существенной выгоды только после успешного завершения процесса их внедрения, эффективного обучения пользователей и регулярного применения.
Можно также перечислить следующие факторы, услож- няющие определение возможного эффекта от использования
CASE-средств:
– широкое разнообразие качества и возможностей CASE- средств;
– относительно небольшое время использования CASE- средств в различных организациях и недостаток опыта их приме- нения;
– широкое разнообразие в практике внедрения различных организаций;
– отсутствие детальных метрик и данных для уже выпол- ненных и текущих проектов;
– широкий диапазон предметных областей проектов;
– различная степень интеграции CASE-средств в различ- ных проектах.

32
Некоторые аналитики считают, что реальная выгода от ис- пользования некоторых типов CASE-средств может быть получе- на только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.
Ниже перечислены основные виды и последовательность работ, рекомендуемые при построении логических моделей предметной области в рамках CASE-технологии анализа системы управления предприятием.
Проведение функционального и информационного обследо- вания системы управления (административно-управленческой деятельности) предприятия:
– определение организационно-штатной структуры пред- приятия;
– определение функциональной структуры предприятия;
– определение перечня целевых функций структурных элементов (подразделений и должностных лиц);
– определение круга и очередности обследования струк- турных элементов системы управления согласно сформулирован- ным целевым функциям;
– обследование деятельности выделенных структурных элементов;
– построение FD-диаграммы системы управления с указа- нием структурных элементов и функций, реализация которых бу- дет моделироваться на DFD-уровне.
Разработка моделей деятельности структурных элементов и системы управления в целом:
– выделение множества внешних объектов, оказывающих существенное влияние на деятельность структурного элемента;
– спецификация входных и выходных информационных потоков;
– выявление основных процессов, определяющих деятель- ность структурного элемента и обеспечивающих реализацию его целевых функций;
– спецификация информационных потоков между основ- ными процессами деятельности, уточнение связей между процес- сами и внешними объектами;