Convenciones de nomenclatura para objetos de seguimiento de elementos de trabajo

Todos los objetos de seguimiento de elementos de trabajo están asociados a uno o más nombres.La mayoría tiene nombres para mostrar descriptivos y todos, salvo los tipos de elemento de trabajo y las listas globales, están asociados a nombres de referencia.Un nombre descriptivo es un identificador único y visible por el usuario para un campo que se utiliza para asegurar la coherencia en todos los proyectos de equipo y tipos de elemento de trabajo de una colección de proyectos.El nombre de referencia lo utiliza internamente Team Foundation Server y no se puede cambiar una vez definido.

En la siguiente tabla se resumen los requisitos de denominación que se deben cumplir para cada objeto de seguimiento de elementos de trabajo.

Objeto de seguimiento de elementos de trabajo	Nombre de referencia	Nombre descriptivo
Tipo de elemento de trabajo	No es aplicable	El nombre de cada tipo de elemento de trabajo puede tener hasta 255 caracteres Unicode y debe ser único en un proyecto de equipo.
Campo de elemento de trabajo	Requerido.Vea Requisitos del nombre de referencia.	Los nombres de campos pueden tener hasta 128 caracteres Unicode y deben ser únicos en una colección de proyectos de equipo.
Tipo de vínculo	Requerido.Vea Requisitos del nombre de referencia.	Debe definir dos nombres descriptivos para cada tipo de vínculo: nombre de vínculo hacia delante y nombre de vínculo inverso.Estos nombres pueden tener hasta 128 caracteres Unicode y deben ser únicos para todos los tipos de vínculos definidos para una colección de proyectos de equipo.
Categoría	Requerido.Vea Requisitos del nombre de referencia.	Los nombres descriptivos de categorías pueden tener hasta 128 caracteres Unicode y deben ser únicos en un proyecto de equipo.
Lista global	No es aplicable	El nombre de cada lista global puede tener hasta 254 caracteres Unicode y debe ser único en una colección de proyectos de equipo.

Contenido del tema

• Requisitos del nombre descriptivo

• Requisitos del nombre de referencia

• Nombres de referencia de campos y requisitos de portabilidad

• Ejemplos de nombres de referencia de campos

Requisitos del nombre descriptivo

Además de los requisitos resumidos en la tabla expuesta previamente en este tema, los nombres descriptivos que se definan deben cumplir los siguientes requisitos:

• Los nombres no deben estar vacíos.

• Los nombres no pueden tener espacios en blanco iniciales ni finales.

• Los nombres no pueden contener caracteres de barra diagonal inversa (\).

• Los nombres de campos no pueden contener los siguientes caracteres: barra diagonal inversa (\), punto (.) y corchetes de apertura y cierre ([]).

• Los nombres no pueden contener dos o más espacios en blanco consecutivos.

Requisitos del nombre de referencia

Debe definir un nombre de referencia cada vez que agregue o cree un campo de elemento de trabajo, un tipo de vínculo o una categoría.Todos los nombres de referencia pueden tener hasta 70 caracteres Unicode.

Puede definir un nombre de referencia utilizando caracteres alfanuméricos, caracteres de subrayado y guiones.Cada nombre de referencia debe contener al menos un punto,., pero no puede aparecer ninguno al principio o al final de un nombre.Un nombre de referencia no puede comenzar por un número o un carácter de subrayado, ni tampoco puede tener varios guiones consecutivos, como (--).

Nombres de referencia de campos y portabilidad

El lenguaje de definición de tipos de elemento de trabajo incluye el concepto de nombre de referencia de campo.Los nombres de referencia de campos pueden ayudar a trasladar definiciones entre colecciones de proyectos de Team Foundation así como permitir integraciones de otros fabricantes para buscar y hacer referencia a campos concretos.Estos nombres son globalmente únicos, lo mismo que los espacios de nombres en aplicaciones .NET Framework.

No se puede cambiar el nombre de los nombres de referencia de campos.Si, por ejemplo, cambia el nombre de campo "Título" por "Encabezado", el nombre de referencia de ese campo no cambiará.Las integraciones y las representaciones internas de los campos deben utilizar el nombre de referencia de campo en lugar de depender del propio nombre de campo.

El espacio de nombres System se utiliza solamente para definir todos los campos de sistema básicos que son obligatorios para las funciones del sistema de Team Foundation.Team Foundation Server evita que el usuario cree su propio campo System.X porque podría impedir la funcionalidad de Team Foundation Server.

El espacio de nombres Microsoft se utiliza para definir campos que están definidos en una definición de tipos de elemento de trabajo de una plantilla de procesos de Microsoft Solutions Framework (MSF).Team Foundation Server no le impide que cree su propio campo Microsoft.X.Sin embargo, esta práctica no es recomendable porque podría impedir la funcionalidad de Team Foundation Server.

Los clientes y socios pueden crear sus propios espacios de nombres de campos para tipos de elemento de trabajo personalizados.

Para obtener descripciones de campos y campos de sistema definidos por MSF for Agile Software Development v5.0, vea Referencia de campos de elementos de trabajo para Visual Studio ALM.

Ejemplos de nombres de referencia de campos

Los ejemplos siguientes muestran nombres de referencia de campo válidos en varios espacios de nombres.

Ejemplos de espacio de nombres System

System.Id

System.Title

System.CreatedBy

System.CreationDate

System.ChangedBy

System.ChangedDate

System.State

System.Reason

Ejemplos de espacio de nombres Microsoft

Microsoft.Common.Status

Microsoft.Common.Priority

Microsoft.Scheduling.Duration

Microsoft.Scheduling.PercentComplete

Microsoft.Testing.TestCaseName

Ejemplos de otros espacios de nombres

Los clientes y socios también pueden definir sus propios espacios de nombres para admitir sus tipos de elemento de trabajo personalizados.Por ejemplo, la compañía ficticia Trey Research podría definir los tipos de elemento de trabajo personalizados siguientes:

TreyResearch.Common.Severity

TreyResearch.Common.Phase

TreyResearch.RiskManagement.RiskType

TreyResearch.RiskManagement.Resolution

La compañía ficticia de software A.Datum Corporation podría definir los siguientes tipos de elemento de trabajo:

A_Datum.Common.BusinessPriority

A_Datum.Bug.FoundInPhase

A_Datum.Bug.FixInPhase

Vea también

Referencia

FIELD (Definición) (Elemento)

Conceptos

Personalizar datos de seguimiento, formularios, flujos de trabajo y otros objetos de proyecto