Моделирование бизнес-процессов на примере компании-разработчика программного обеспечения (стр. 5 из 12)

2.Анализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

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

Разработка

Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

- постановка задачи;

- разработка;

- тестирование;

- документирование.

Рисунок 3. Виды деятельности при разработке новых систем и роли

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

Диаграмма деятельности для стадии постановки задачи приведена на Рисунке 4.

Рисунок 4. Диаграмма деятельности для стадии постановки задачи

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

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

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

Контроль над процессом является эпизодическим, осуществляется в основном уже непосредственно перед сдачей проекта. Официальная оценка результатов разработки продукта отсутствует.

Внедрение и сопровождение

Процесс внедрения, а также последующего сопровождения прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 5):

- установка ПО;

- обучение пользователей;

- сбор замечаний;

- устранение замечаний;

- модернизация ПО.

Рисунок 5. Виды деятельности при внедрении и сопровождении

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

В таблице 7 приведены сводные данные по ролям и функциям.

Таблица 7.Сводная таблица ролей и функций

Функция	Роль					Итого
	разработчик	специалист по внедрению	документатор	сотрудник тех. поддержки	пользователь
постановка задачи	+	+	+	+	4
разработка	+	+	2
тестирование	+	+	+	+	4
документирование	+	+	+	3
сбор замечаний	+	+	+	+	4
устранение замечаний	+	+	2
модернизация ПО	+	+	2
обучение	+	+	+	3
установка ПО	+	+	+	3
Всего	8	9	3	2	5

2.2 Проблемы и задачи

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

Существующие проекты, находящиеся на сопровождении, дорабатываются также хаотично, по мере поступления требований, отсутствует системность внесения исправлений, практически всегда документация является неактуальной.

Основными задачами в части реорганизации бизнес-процессов является:

- определение наиболее удобного типа процесса разработки для новых проектов;

- определение типа процесса для сопровождения существующих проектов;

- выработка стандарта планирования новых проектов и сопровождения существующих проектов;

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

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

2.3 Анализ типовых вариантов процессов разработки

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

На рисунке 6 приведен водопадный процесс разработки с указанием результатов на каждом этапе.

Рисунок 6. Водопадный процесс разработки

Спиральный процесс

В случае спирального процесса последовательность «анализ – проектирование – реализация – тестирование» выполняется несколько раз. Основные причины использования спирального процесса обычно следующие:

- необходимость предупреждения рисков;

- необходимость предоставить заказчику частичную версию проекта до его завершения.

Основной трудностью использования спирального процесса является поддержка актуальности документации.

На рисунке 7 приведен спиральный процесс разработки.

Рисунок 7. Спиральный процесс разработки

Инкрементальный процесс

Инкрементальный процесс разработки представляет собой постоянное продвижение проекта понемногу вперед при практически непрерывном процессе. Это аналог спирального процесса с небольшим временным интервалом полного цикла (например, неделя). Данный процесс очень удобен на стадии сопровождения проекта. Однако использование данного процесса предполагает очень четкое управление документацией в силу постоянного обновления.

Унифицированный процесс

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

На рисунке 8 приведен унифицированный процесс разработки.

Рисунок 8. Унифицированный процесс разработки

Исходя из всего вышесказанного, наиболее удобным и оправданным является использование:

- для разработки новых проектов – унифицированного процесса разработки;

- для сопровождения – использование инкрементального процесса.

2.4 Оптимизация процессов разработки и сопровождения

При переходе к проектному управлению необходима реорганизация бизнес-процессов в соответствии с жизненным циклом реализации проектов. Жизненный цикл проекта – это комбинация процессов и подпроцессов, необходимых для создания (реализации) объекта или решения. Так, жизненный цикл проекта в стандарте PMI (ProjectManagementInstitute, США) состоит из следующих фаз: