
- •Раздел 3.3 посвящен оценке качества бизнес-процесса с общесистемных позиций, позволяющей на основе ряда критериев и метрик оценить, насколько хорош спроектированный вариант и можно мл его улучшить.
- •3.1. Проектирование (планирование) бизнес-процесса
- •3.1.1. Введение в теорию формальных языков и грамматик
- •3.1.2. Грамматика бизнес-процесса и его порождение
- •3.1.5. Организация параллелизма при планировании бизнес-процесса
- •3.2. Тестирование бизнес-процесса
- •3.2.1. Специфика тестирования бизнес-процесса -
- •3.2.2. Модель потоков данных'бизнес-процесса
- •3.2.3. Критерии тестирования бизнес-процессов
- •3.3. Оценка качества бизнес-процесса
- •3.3.1. Критерий сцепления оизнес-процесса
- •3.3.2. Критерий связности бизнес-процесса
- •3.3.3. Порождение вариантов выполнения :к[ бизнес-процесса с учетом типа связности «'?*"
- •3.4. Анализ бизнес-процессов
- •3.4.1. Метод статического анализа потоков данных бизнес-процесса
- •3.4.2. Методы динамического анализа щ
- •Дайте определение грамматики бизнес-процесса.
- •Постройте грамматику бизнес-процесса «Прием на работу нового сотрудника». Выберите и аргументируйте вариант его исполнения.
- •Постройте грамматику бизнес-процесса «Увольнение сотрудника». Выберите вариант его (исполнения и синхронизируйте его с вариантом исполнения процесса «Прием на работу нового сотрудника».
- •4.1. Понятие реорганизации
3.2. Тестирование бизнес-процесса
3.2.1. Специфика тестирования бизнес-процесса -
На практике обнаружение и локализация ошибок в бизнес-процессе осуществляется во время его функционирования в реальных экономических условиях, что может привести и, как правило, приводит к плачевным результатам. Поэтому актуальной является задача выявления ошибок на стадиях планирования (проектирования) и создания бизнес-процесса, т.е. до того, как он начнет реально функционировать.
При решении поставленной задачи целесообразно использовать результаты исследований, лежащие в основе теории тестирования и отладки компьютерных программ как наиболее близких к бизнес-процессам объектов. Подобие бизнес-процессов и программ заключается в следующем:
в основе обеих объектов лежит понятие алгоритма;
обаобъекта имеют одинаковые этапы жизненного цикла;
оба объекта могут выполняться как последовательно, так и параллельно;
оба объекта адекватно моделируются с использованием графовых моделей.
В общем случае тестирование представляет собой набор процедур и действий, предназначенных для демонстрации корректной работы объекта в заданных режимах и внешних условиях. Цель тестирования — выявить наличие ошибок или убедительно продемонстрировать ихотсутствие, что возможно лишь в отдельных тривиальных случаях.
v Важнейшим и наиболее часто применяемым на практике является метод детерминированного тестирования. При этом в качестве эталонов (тестов) используются конкретные исходные данные, состоящие из взаимосвязанных входных и результирующих величин и правильных последовательностей их обработки. В процессе тестирования при заданных исходных величинах необходимо установить соответствие результатов их обработки величинам, используемым как эталонные/Для сложных объектов требуется большое количество тестов и возникает проблема оценки их необходимого количества и использования методов их сокращения. Поэтому тестирование (как и любой другой вид деятельности) целесообразно планировать. План тестирования должен
содержать:
формулировку целей тестирования;
критерии качества тестирования, позволяющие оценить его результаты;
стратегию проведения тестирования, обеспечивающую достижение заданных критериев качества;
потребности в ресурсах для достижения заданного критерия качества при выбранной стратегии.
Для целей тестирования объект удобно представлять в виде ориентированного графа G — (N, £), где N = {Nx, N2, —, Nm) — множество узлов (вершин), соответствующих функционалу объекта; Е - (Еи Е2,..., Е„) - множество ребер (дуг), соответствующих передачам управления между функциями.
Путем (маршрутом) называется последовательность вершин и дуг Р= (Nh EU2, N2, £2 j,..., Ек.и, Nk), где каждая дуга Eii+l выходит из Nt и входит в N't+b причем TV, не обязательно начальный узел. Ветвью называется путь Р, в котором Nx - либо начальный узел, либо узел ветвления, Nk — узел ветвления либо завершающий узел, все остальные JV,- не являются узлами ветвления.
/Очевидно,
что полное тестирование всех возможных
маршру
тов
нереально в связи с огромными затратами
труда и времени.
Поэтому на практике
применяются критерии выбора тестов,
не
гарантирующие
полной проверки объекта. Общим требованием
к
этим
критериям является достижение лишь
определенной степе
ни
полноты покрытия объекта или его
компонентов. Как прави
ло,
эти критерии устанавливают требование,
по крайней мере,
однократной
проверки всех функций (критерий С0),
всех его вет
вей
(критерий Сх)
либо
всех полпутей специального вида.
Самым
распространенным
критерием тестирования является
критерий,
требующий
по крайней мере однократной проверки
каждой из
ветвей объекта (критерий
С,). Например, тестирование при при
емке
программного обеспечения для ВВС США
производится на
основании
этого критерия. По ряду независимых
оценок исполь-
зование критерия С,
обеспечивает обнаружение <я?61%
до
90%
ошибок. ■-.-■■
Однако бизнес-процесс является гораздо более сложным и непредсказуемым объектом, чем обычная компьютерная прог-. дамма, в том числе и параллельная. Если последняя содержит ряд управляющих параллелизмом механизмов, таких, как механизмы с?тхронизации ветвей, то выполнение бизнес-пдоцесса, вообще сребря, непредсказуемо. Например, любое ЛПР^южет приказать своему подчиненному изменить традиционный маршрут испол-аения би?нее-процесса (типичный пример приказа такого рода — «к этот Документ передайте не Ивану Ивановичу, как обычно, а Петру Петровичу»). В то же время даже для последовательных арограмм задача тестирования является трудноразрешимой. Из-эестно, что полное и исчерпывающее ее тестирование практически невозможно, так как требует огромных трудозатрат. Таким образом, перефразировав известное утверждение Дейкстры (касаю-чееся программного обеспечения), можно сказать, что любой 1нзнес-процесс содержит хотя бы одну ошибку - просто пока «ще небыли созданы условия для ее проявления.
В качестве примера можно привести реальный случай, произошедший на одном из молокозаводов Москвы. Схема отгрузки ■олокопродуктов в магазины включала прием денежного залога зпару, принадлежащую молокозаводу. При возврате тары залог возвращался. Поскольку величина залога была незначительной, «однократно возвращалась сломанная тара, нередкими были вучая ее утери, что создавало определенные проблемы при
ежедневной отгрузке молокопродуктов. В связи с этим руководство молокозавода приняло решение о почти двукратном увеличении величины залога. Это привело к тому, что уже на следующий день склад был завален порожней тарой — водители быстро сориентировались и свезли на данный молокозавод тару со всех других заводов Москвы. Другими словами, изменились входные данные бизнес-процесса, и он не просто перестал работать, а начал работать со знаком «минус», принося вместо прибыли
убыток.
Безусловно, подобную ошибку нельзя обнаружить никаким, даже самым тщательным тестированием, поскольку еще никто не научился формализовать"людскую смекалку. Вообще говоря, существует два типа бизнес-процессов — планируемые и спонтанные, приведенный пример относится ко второй категории. Спонтанные процессы не подлежат тестированию и исключаются из рассмотрения.
Наиболее типичными для планируемых бизнес-процессов современного предприятия ошибками являются ошибки, связанные с информационными ресурсами (ошибки в потоках данных). Примерами таких ошибок являются:
создание информационных объектов (ИО) и/или их атрибутов, не используемых в дальнейшей деятельности;
отсутствие и/или неполнота ИО и/или их атрибутов;
дублирование ИО и/или их атрибутов и, как следствие, их не- „ согласованность и противоречивость и др.
Специфика данных ошибок для бизнес-процесса обуславли- , вается наличием регламентов доступа к атрибутам ИО, запрещающих или ограничивающих доступ при выполнении ряда бизнес-операций. Например, такой атрибут сотрудника, как его зарплата, на ряде предприятий доступен только руководству и сотрудникам бухгалтерий.
Основной проблемой при планировании процедуры тестирования является проблема выбора критерия (стратегии) тестирования, т.е. задача выделения тех частей объекта, которые необходимо тестировать. Известные критерии тестирования программ и соответствующие алгоритмы выбора стратегий тестирования, основанные на анализе графовой модели объекта, не обеспечивают обнаружения рассматриваемых ошибок в потоках данных бизнес-процессов. Следовательно, при создании критерия тестирования бизнес-процесса необходимо учитывать не только его структуру управления, но и структуру его потоков данных.
17.1