Чтение онлайн

на главную

Жанры

Управление бизнес-процессами. Практическое руководство по успешной реализации проектов
Шрифт:

Можно выделить следующие типы тестирования {57}:

• тест блока выполняется разработчиками в лабораторных условиях и должен показать, что данная работа или шаг автоматизированного решения BPM отвечает требованиям, сформулированным в техническом задании;

• тест интеграции выполняется разработчиками в лабораторных условиях и должен показать, что данная функция или аспект автоматизированного решения BPM отвечает требованиям, сформулированным в техническом задании;

• системный тест выполняется разработчиками в (надлежаще

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

• тест функциональной приемки (FAT) выполняется системным менеджером и группой тестирования в условиях, в максимально возможной степени имитирующих эксплуатационную среду. Он должен показать, что автоматизированное решение BPM отвечает требованиям к функциональности и качеству, сформулированным в функциональных требованиях;

• тест приемки пользователями (UAT) выполняется пользователями системы. В «теневых» эксплуатационных условиях автоматизированное решение BPM будет испытано на предмет соответствия требованиям бизнеса. Это включено в этап реализации;

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

Разумеется, нужно следовать обычному процессу тестирования:

1. Определите показатели теста. Тестирование всегда предполагает баланс между выгодами от тестирования и связанными с ним затратами. 100-процентное тестирование – практически нереальное и чрезвычайно дорогостоящее мероприятие. TMap® – прагматичный подход, описанный в {57}.

2. Определите и опишите стратегию тестирования, которая должна включать тест блоков, приемки пользователями (UAT), интеграции, регрессионный тест и т. д. Необходимо обдумать используемую инфраструктуру. Замечание: обязательно сделайте все возможное в рамках проекта, чтобы на стадии тестирования использовалась точная копия действующей среды инфраструктуры. Многие проекты развалились, если данное условие не было выполнено. Также помните, что не все тесты относятся к системам приложений. В процессной среде бо льшая часть тестирования вращается вокруг «пробных прогонов» процессов в бизнес-подразделении и определения его пригодности для заданной цели.

3. Составьте план тестов. Организация принимает решение о количестве и типах тестовых конфигураций. Не забудьте привлечь все соответствующие заинтересованные стороны и другие подгруппы проекта.

4. Опишите различные конфигурации тестов. Объем их будет зависеть от размера и сложности проекта. Самое важное – охватить все вероятные сценарии.

5. Выполните тестирование. Завершите конфигурации и программы тестов.

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

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

Реализация

ценности

Чтобы добиться согласия, необходимо тщательно определить выигрыши как часть данного этапа. Подробности описаны в главе 21, шаг 5, в связи с реализацией ценности в проекте.

Результаты этапа разработки

* * *

Этап разработки дает значимый вклад в другие этапы общей схемы (рис. 19.7), вот лишь несколько примеров:

• решение может налагать требования на людей, которые будут работать с системой;

• этап разработки дает информацию для обучения на этапе реализации-внедрения;

• предложенная система может обеспечивать функциональность, которая дает бизнесу дополнительные возможности, или же не обеспечить все функции, предусмотренные на этапе инноваций, и в этом случае должны быть привлечены люди, готовившие спецификации после этапа инноваций;

• этап разработки должен обеспечить устойчивое функционирование;

• разработка ПО может повлиять на изменения в архитектуре процессов (особенно соответствующей информации и технологий).

Риски этапа разработки

На данном этапе присутствуют некоторые риски, так что нужно предусмотреть и реализовать стратегии их исключения (или хотя бы снижения). Некоторые риски перечислены в табл. 18.2 (см. выше).

В табл. 19.1 указаны риски и стратегии снижения, которые должны быть рассмотрены на этапе разработки.

Таблица 19.1. Риски и стратегии их снижения на этапе разработки

Глава 20

Этап реализации

Назначение

На этапе реализации (рис. 20.1) все спроектированные и разработанные усовершенствования процессов осуществляются в реальности. Здесь также сходятся вместе многие действия по управлению изменениями персонала. Хотя это одна из последних частей всей общей схемы и цикла проекта, ее следует рассмотреть в самом начале каждого проекта, с этапом стартовой площадки, поскольку именно в начале проекта нужно принять решение относительно его внедрения в бизнес (подробности см. в главе 15). Решение о реализации окажет влияние на такие грани проекта, как проектирование или перестройка процессов, выполнение разработки и тестирования и т. п. К этому решению постоянно возвращаются по ходу проекта, понимая, что метод реализации может измениться.

Кейс: запоздалая реализация в малом масштабе

Нас пригласили проанализировать неудачный BPM-проект. Его спонсор был поражен, что проект не удался: все метрики были определены, технология работала, основные заинтересованные лица получали сведения еженедельно, а пользователи готовились по проекту через масштабную кампанию расклейки постеров, рассылок по электронной почте и по программе интенсивного обучения.

Поделиться:
Популярные книги

На границе империй. Том 3

INDIGO
3. Фортуна дама переменчивая
Фантастика:
космическая фантастика
5.63
рейтинг книги
На границе империй. Том 3

Держать удар

Иванов Дмитрий
11. Девяностые
Фантастика:
попаданцы
альтернативная история
5.00
рейтинг книги
Держать удар

Эффект Фостера

Аллен Селина
Любовные романы:
современные любовные романы
5.00
рейтинг книги
Эффект Фостера

Не грози Дубровскому! Том VIII

Панарин Антон
8. РОС: Не грози Дубровскому!
Фантастика:
фэнтези
попаданцы
аниме
5.00
рейтинг книги
Не грози Дубровскому! Том VIII

СД. Том 17

Клеванский Кирилл Сергеевич
17. Сердце дракона
Фантастика:
боевая фантастика
6.70
рейтинг книги
СД. Том 17

Темный Патриарх Светлого Рода 3

Лисицин Евгений
3. Темный Патриарх Светлого Рода
Фантастика:
юмористическое фэнтези
попаданцы
аниме
5.00
рейтинг книги
Темный Патриарх Светлого Рода 3

Сумеречный Стрелок 3

Карелин Сергей Витальевич
3. Сумеречный стрелок
Фантастика:
городское фэнтези
попаданцы
аниме
5.00
рейтинг книги
Сумеречный Стрелок 3

Пипец Котенку!

Майерс Александр
1. РОС: Пипец Котенку!
Фантастика:
фэнтези
юмористическое фэнтези
аниме
5.00
рейтинг книги
Пипец Котенку!

Неудержимый. Книга IV

Боярский Андрей
4. Неудержимый
Фантастика:
фэнтези
попаданцы
аниме
5.00
рейтинг книги
Неудержимый. Книга IV

Дурная жена неверного дракона

Ганова Алиса
Любовные романы:
любовно-фантастические романы
5.00
рейтинг книги
Дурная жена неверного дракона

Я не князь. Книга XIII

Дрейк Сириус
13. Дорогой барон!
Фантастика:
юмористическое фэнтези
попаданцы
аниме
5.00
рейтинг книги
Я не князь. Книга XIII

Я – Орк. Том 6

Лисицин Евгений
6. Я — Орк
Фантастика:
городское фэнтези
попаданцы
аниме
5.00
рейтинг книги
Я – Орк. Том 6

Отмороженный

Гарцевич Евгений Александрович
1. Отмороженный
Фантастика:
боевая фантастика
рпг
5.00
рейтинг книги
Отмороженный

Безродный

Коган Мстислав Константинович
1. Игра не для слабых
Фантастика:
боевая фантастика
альтернативная история
6.67
рейтинг книги
Безродный