Читайте также:
|
Обзор. Вернемся к элементам работ VSTS – ключевым дискретным характеристикам проекта, таким как задача (task), ошибка (bug), риск (risk) и т.д. Эти характеристики выделены в VSTS с целью конкретизировать объекты управления в проекте, сделать это управление сквозным в следующих смыслах:
Благодаря единой среде, включающей в себя средства поддержки различных видов элементов работы, в VSTS гораздо проще строить связи между элементами работы различного вида, отслеживать их изменения, чем при использовании отдельных продуктов поддержания процесса. Например, не нужно ждать момента, пока информация об ошибке или задаче будет перенесена из одной системы в другую. Ведь традиционно программные средства планирования (там, где определяются задачи), управления ошибками (там, где происходит учет ошибок), средства версионного контроля – это разные средства. Кроме того, в силу наличия единого информационного репозитория в VSTS возможны строгие ссылки на такие объекты, определенная сборка или тест, и получение, по соответствующему запросу, подробной информации по разным фильтрам, на разную глубину детализации. Возможно также настроить автоматическую генерацию элементов работы, например, ошибок при неудачной автоматической сборке или при автоматическом прогоне тестов.
Рис. 13.1.
Элементы работы можно связывать с другими артефактами проекта - файлами с исходным кодом, сборками (как настройками, так и результатами), документами (по процессу, проектными, пользовательскими и др.), отчетами, которые могут также храниться в VSTS. Все это показано на рис. 13.1. Важно отличать элементы работы от этих артефактов – последние являются рабочими продуктами (точнее, из них рабочие продукты сформируются), а элементы работы являются управляющей информацией в проекте. Правда, и по ним также можно создавать рабочие продукты – генерировать отчеты, документы и планы в продуктах Office и т.д. Но сами по себе элементы работы являются средством оперативной работы над проектом, а не результатами (в том или ином смысле).
Реквизиты. Каждый элемент работы принадлежит определенному типу. Тип элемента работы определяет набор реквизитов, для каждого из которых можно задать:
Бывают также системные реквизиты, имена, типы и обработка которых "прошита" в TFS. Это, например, такие реквизиты как состояние (state), причины (reasons), связи (links).
Отдельного внимания заслуживают имена для ссылок. Они позволяют идентифицировать данный реквизит не только в пределах одного типа элементов работы, но и в пределах всего TFS-проекта, а также при переносе элементов работы из проекта в проект. Для поддержания уникальности этих имен рекомендуется использовать концепцию пространств имен (namespaces). Кроме того, имена для ссылок служат для организации своего рода пула реквизитов – одинаковое имя для ссылок, использованное в разных типах элементов работы, подразумевает одинаковый смысл соответствующих реквизитов, а также одинаковую их роль с точки зрения формирования отчетов. Существует набор предопределенных имен для ссылок, соответствующих системным реквизитам. Реквизиты с соответствующими именами для ссылок могут подвергаться особой обработке со стороны TFS.
Каждый реквизит может либо не участвовать в отчетах вообще, либо участвовать в следующих режимах:
Жизненный цикл элемента работы определяется двумя системными реквизитами: состоянием и причиной.
Первый описывает текущее состояние элемента работы и определяет его текущую роль в процессе. Каждый тип элементов работы описывает допустимый набор состояний, например, "активный", "завершенный", "проверенный" и т.д.
Кроме того, каждый тип элемента работы имеет описание переходов между своими состояниями состояний, причины, вызывающие эти переходы и действия, выполняемые в них. Причинами могут являться, например, "выполнен", "устарел", "отложен" и т.д. Переходы может осуществлять сама система TFS, автоматически, но в большинстве случае разработчик сам инициирует переход, внося в систему информацию о том, что выполнил задачу, исправил ошибку и так далее.
Таким образом, жизненный цикл элемента работы представляется ориентированным графом, нагруженным как по узлам, так и по дугам. Использование такого графа вместо нагруженного только по узлам, как например, часто можно встретить в системах управления ошибками, позволило резко сократить размер описания и повысить информативность.
Для настройки типов рабочих элементов используется продукт Team Foundation Power Tools 1). Он является свободно распространяемым продуктом и содержит, в частности, визуальный редактор, позволяющий просматривать и редактировать жизненный цикл элемента работы в визуальном виде – см. рис. 13.2. На этом рисунке показан граф жизненного цикла для типа рабочего элемента "ошибка". Мы можем видеть три состояния – Active (обнаружена ошибка), Resolved (ошибка исправлена), Closed (ошибка закрыта), – и переходы между этими состояниями. В каждом переходе имеется прямоугольник Transition, в котором содержатся параметры перехода – причина, действия, которые нужно выполнить, список реквизитов, который должен быть изменен при переходе и некоторую другую информацию.
увеличить изображение
Рис. 13.2. Жизненный цикл элемента работы типа "Ошибка".
Еще одной важной составляющей описания жизненного цикла реквизита являются правила, которые описывают различные ограничения на значения реквизитов элемента работы, в том числе:
При описании каждого правила можно указать имя пользователя или группы, для которых это правило будет применяться. Исключением является только правило "позволить сохранить текущее значение", применяемое всегда для всех пользователей.
Кроме того, можно описать правила, применяемые в разные моменты времени, в том числе:
Система правил предоставляет обширные возможности для спецификации различных тонкостей бизнес-процесса, однако платить за эту гибкость приходится сложностью настройки. Именно описание корректных правил потребовало от нас наибольших усилий при разработке собственного шаблона и его использовании в реальном промышленном проекте.
Еще один важный механизм настройки реквизитов в VSTS – это задания способа представления реквизита в экранных формах редактирования, просмотра в отчетах. Для этой цели в TFS существует достаточно гибкий диалект XML, включающий предопределенный набор элементов пользовательского интерфейса, а также позволяющий группировать их, разбивать по колонкам или размещать на закладках. Используя вложенность элементов и групп, можно описать строгий, удобный и красивый пользовательский интерфейс, но иногда для этого требуется много времени. Некоторые типы элементов пользовательского интерфейса можно связывать с реквизитами элемента работы, используя соответствующее имя для ссылок.
Дата добавления: 2015-12-08; просмотров: 56 | Нарушение авторских прав