Лекция 9. Структура бизнес-процессов разработки программного обеспечения: система отслеживания дефектов Rational ClearDDTS
ОСНОВНЫЕ ПРИНЦИПЫ ОРГАНИЗАЦИИ СИСТЕМ КОЛЛЕКТИВНОЙ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ. WORKFLOW СИСТЕМЫ.
Промышленная разработка программных продуктов подразумевает прежде всего их коллективную разработку. В настоящее время имеются специальные концепции технологии программирования, ориентированные на коллективную разработку программ. Суть этих концепций состоит в представлении процесса работы над каждой подзадачей создания продукта в виде жёстко заданной последовательности действий, имеющих чёткие критерии начала и завершения. При этом каждое действие выполняется в общем случае отдельным сотрудником, которые передают таким образом подзадачу друг другу как по конвейеру. Подобная конвейерная технология называется технологией Workflow.
В основе технологии Workflow лежат следующие понятия:
Объект – информационный, материальный или финансовый объект, используемый в бизнес-процессе (в нашем случае это задача, решаемая программистом)
Событие – внешнее действие, произошедшее с объектом (в нашем случае это создание новой задачи или завершение того или иного действия над ней)
Операция – элементарное действие, выполняемое в рамках рассматриваемого бизнес-процесса (например, исправление ошибки в коде или инспектирование рабочего продукта)
Исполнитель - должностное лицо, ответственное за выполнение одной или нескольких операций бизнес-процесса.
Приведенные понятия не исчерпывают множество терминов, определений и особенностей технологии Workflow, тем не менее именно они служат основой программной реализации любой системы класса Workflow. При этом каждая система обеспечивает решение трех следующих задач:
-
разработка описания бизнес-процесса;
-
управление выполнением бизнес-процесса;
-
интеграция используемых в процессе приложений.
В контексте технологии организации коллективной разработки программ перечисленные задачи Workflow системы, обеспечивающей автоматизацию процесса разработки приобретают следующее звучание:
-
разработка последовательности действий и соответствующих им состояний подзадач проекта
-
управление передачей каждой подзадачи от сотрудника к сотруднику по мере изменения состояний подзадачи
-
интеграция используемых в процессе разработки приложений: базы данных хранения рабочих продуктов, приложений, обеспечивающих контроль и интеграцию изменений рабочих продуктов.
ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС КОЛЛЕКТИВНОЙ РАЗРАБОТКИ ПРОГРАММ. ОСНОВНЫЕ СОСТОЯНИЯ ПОДЗАДАЧИ.
При коллективной разработке программных продуктов последовательность действий над каждой подзадачей определяется её жизненным циклом, специфичным для того или иного предприятия. Можно, однако, выделить следующие наиболее общие этапы такого жизненного цикла:
-
Создание новой подзадачи
-
Рассмотрение подзадачи контрольной группой (такая группа называется стандартным термином CCB - Change Control Board - Комитет Контроля Изменений) и назначение её на того или иного сотрудника-разработчика (developer) для разработки
-
Создание разработчиком изменений рабочего продукта в контексте данной подзадачи
-
Инспектирование изменений рабочего продукта другими сотрудниками
-
Интеграция изменений в рабочий продукт
-
Тестирование рабочего продукта сотрудником-тестером (tester)
-
Рассмотрение отчёта о тестировании контрольной группой CCB и принятие решения либо о закрытии подзадачи, либо о возвращении её обратно на доработку.
Имея в виду данную последовательность, подзадача может пребывать в следующих состояниях.
-
New – новая подзадача
-
Approved for analysis – допущено для анализа. В это состояние подзадача переводится после рассмотрения её контрольной группой CCB
-
Assigned for analysis – назначено для анализа. В это состояние подзадача переводится после назначение её на конкретного сотрудника
-
Analysis – в процессе анализа. В это состояние подзадачу переводит сотрудник после того, как начнёт её анализ.
-
Waiting for information – в ожидании информации. В это состояние задача может быть переведена любым участником рабочего процесса в случаях, когда для принятия решения ему необходима дополнительная информация.
-
Analysis completed – анализ завершён. Переводится сотрудником после завершения анализа задачи.
-
Terminated – прерванный. В это состояние задача может быть переведена CCB после рассмотрения и принятия решения о необходимости отмены, прекращения работы над задачей. В это состояние задача может быть переведена, например, сразу после создания новой или по результатам её анализа.
-
Forward – в данном случае имеет значение «переданный на дальнейшую разработку». В это состояние задача переводится CCB после анализа при назначении задачи на разработку конкретному сотруднику
-
Coding – кодирование. В это состояние задача переводится сотрудником-разработчиком, при начале работы по кодированию, связанному с задачей.
-
Inspected – проинспектировано. В это состояние задача переводится сотрудником-разработчиком после завершения кодирования и инспектирования изменений рабочего продукта.
-
Resolved – проверено. Переводится после проверки изменений рабочего продукта по результатам инспектирования специалистом-экспертом (code expert).
-
Integrated – заинтегрировано. Переводится сотрудником, осуществляющим интеграцию изменений в рабочий продукт после успешной интеграции этих изменений.
-
Tested - протестировано. Переводится сотрудником, осуществляющим тестирование изменений в рабочий продукт (tester)
-
Closed – закрыто. В это состояние задача переводится CCB по результатам отчёта о тестировании сделанных изменений.
Собственно, информационная система, автоматизирующая обсуждаемый рабочий процесс, как раз и должна обеспечивать коммуникацию и координацию действий задействованной в нём рабочей группы, поддерживать корректную последовательность состояний процесса и уведомление заинтересованных лиц об изменении состояний конкретной подзадачи.
СИСТЕМА ОТСЛЕЖИВАНИЯ ДЕФЕКТОВ CLEARDDTS
Специальная информационная система ClearDDTS (Distributed Defect Tracking System), разработанная фирмой Rational Software Corporation предназначена для обеспечения распределённой коллективной работы над разработкой программных продуктов. Основным элементом этой системы является база данных, хранящая историю изменений подзадач и сопутствующую им информацию. Доступ к информации, хранимой в системе, осуществляется посредством Web интерфейса, стандартными браузерами. Система построена на базе основных принципов технологии Workflow, т.е. конвейерности.
ClearDDTS служит именно административным целям – работе с запросами на изменения рабочего продукта. Хранилищем данных в этой системе служит DDTS проект, характеризуемый своим названием и классом. Как правило, название и класс проекта идентифицируют рабочую группу, обрабатывающую какой-либо вид подзадач.
Каждый DDTS проект – это множество подзадач. Каждая подзадача имеет свой идентификационный номер и набор полей, куда по мере жизненного цикла подзадачи различные сотрудники заносят новые значения. Класс DDTS проекта определяет набор полей, их типы, их возможные значения, фазы жизненного цикла подзадачи и многое другое. Жизненный цикл подзадачи описывает её переход между различными состояниями. Набор возможных состояний подзадачи может быть задан произвольным образом.
При переходе задачи в то или иное состояние жизненного цикла система автоматически рассылает уведомления заинтересованным лицам. Например, если создана новая задача, система рассылает уведомления об этом группе CCB; когда CCB переводит задачу в состояние Approved for analysis, уведомление рассылается руководителям рабочей группы; когда руководитель назначает задачу на конкретного сотрудника, т.е. переводит её в состояние Assigned for analysis, уведомление приходит этому сотруднику и т.д.
Система DDTS поддерживает также интеграцию с приложениями, используемых для составления отчётов о результатах инспектирования, запросов на интеграцию и тестирования. Кроме того, система позволяет контролировать корректность идентификации версий рабочего продукта, находящихся под управлением системы контроля версий.