CMMI-SVC-ESP - ORIGINAL

CMMI para Servicios, Versión 1.3

existentes, consúltese el área de proceso Prestación de Servicios.

Estos requisitos deberían estar formulados en un lenguaje que puedan
entender las partes interesadas relevantes, y que aun así tenga la
precisión que requieren los que desarrollan el servicio o el sistema de
servicio.

Algunos ejemplos de requisitos de las partes interesadas son:
 Requisitos de operaciones.
 Requisitos de entrega al cliente.
 Requisitos de monitorización.
 Requisitos de instrumentación.
 Requisitos de documentación.
 Requisitos de acuerdo de nivel de operaciones.
 Estándares organizativos para líneas de producto y servicios estándar.
 Requisitos de acuerdos con otras partes interesadas relevantes.

Ejemplos de productos de trabajo

1. Requisitos de clientes.

2. Requisitos de usuarios finales.

3. Restricciones de clientes y usuarios finales sobre la realización de
la verificación y validación.

4. Restricciones de niveles de personal.

Subprácticas

1. Implicar a las partes interesadas relevantes utilizando métodos de
recabar necesidades, expectativas, restricciones, e interfaces
externas.
Recabar requisitos va más allá de recogerlos porque implica identificar
proactivamente requisitos adicionales no provistos explícitamente por los clientes
utilizando métodos tales como encuestas, análisis de datos de satisfacción de
clientes, prototipos, simulaciones, o talleres para recabar atributos de calidad.

2. Transformar las necesidades, expectativas, restricciones, e
interfaces de las partes interesadas en requisitos priorizados de
las partes interesadas.
Al documentar el conjunto de requisitos reconocidos de las partes interesadas se
deberían consolidar y priorizar las diferentes aportaciones de las partes
interesadas relevantes, obtener la información faltante, y resolver los conflictos.

3. Definir restricciones para la verificación y validación.

SP 1.2 Desarrollar requisitos de sistema de servicio

Refinar y elaborar los requisitos de las partes interesadas para

Desarrollo del Sistema de Servicio (SSD) 403

CMMI para Servicios, Versión 1.3

desarrollar requisitos de sistema de servicio.

Los requisitos de las partes interesadas se analizan conjuntamente con
el desarrollo del modelo operativo con objeto de derivar conjuntos de
requisitos más detallados y precisos llamados “requisitos derivados”.
Estos requisitos abordan todos los aspectos del sistema de servicio
asociados con la prestación de servicios, incluyendo los productos de
trabajo, los servicios, los procesos, los consumibles, y los clientes y
otros recursos; así como las funcionalidades y atributos de calidad que
necesitan las partes interesadas relevantes.

Los requisitos derivados surgen de las restricciones, de las
consideraciones de problemas tácitos no explícitamente establecidos
en la línea base de los requisitos de las partes interesadas, y de los
factores que introduce la arquitectura del sistema de servicio
seleccionada, su diseño, las consideraciones que son exclusivas del
trabajo del desarrollador, y las prioridades estratégicas, incluyendo las
tendencias de mercado de la industria. La extensión y profundidad de
los requisitos derivados varía con la complejidad del sistema de
servicio que se necesita para cumplir los requisitos de las partes
interesadas.

Para más información sobre establecer servicios estándar, consúltese
el área de proceso Gestión Estratégica de Servicios.

En algunos contextos de servicios, los requisitos derivados pueden ser
tan simples como identificar y cuantificar los recursos necesarios. Para
sistemas de servicio complejos que tengan muchos tipos de
componentes e interfaces, los requisitos iniciales se refinan de forma
iterativa en conjuntos de requisitos más detallados, que pueden ser
asignados a componentes de sistema de servicio según se va
refinando la solución preferida.

Por medio de tales actividades de análisis, refinamiento, derivación, y
asignación se establecen la funcionalidad y los atributos de calidad
requeridos por el sistema de servicio.

Ejemplos de productos de trabajo

1. Requisitos derivados con relaciones y prioridades.

2. Requisitos de servicio.

3. Requisitos de sistema de servicio.

4. Asignaciones de requisitos.

5. Requisitos de arquitectura, que especifiquen o restrinjan las
relaciones entre los componentes de sistema de servicio.

6. Requisitos de interfaz.

7. Requisitos de nivel de cualificación.

Subprácticas

1. Desarrollar los requisitos y expresarlos en los términos que se

404 Desarrollo del Sistema de Servicio (SSD)

CMMI para Servicios, Versión 1.3

SP 1.3 necesitan para diseñar el servicio y el sistema de servicio.

En particular, estos requisitos incluyen requisitos de arquitectura que especifican
atributos de calidad que son críticos.

2. Derivar los requisitos que resulten de la selección de soluciones y
de las decisiones de diseño.

3. Establecer y mantener las relaciones entre requisitos que hay que
tener en cuenta para gestionar los cambios y asignar los
requisitos.

Las relaciones incluyen dependencias en las que un cambio en un requisito
puede afectar a otros requisitos.

Las relaciones entre requisitos pueden ayudar a diseñar y evaluar el impacto de
los cambios.

4. Priorizar los requisitos derivados.

La priorización de requisitos puede ayudar a definir los ciclos de desarrollo
iterativos.

5. Asignar los requisitos a entidades lógicas, a componentes de
sistema de servicio, y a otras entidades según sea apropiado.

Según evoluciona el modelo operativo, los requisitos se asignan a entidades
lógicas (p. ej. funciones, procesos) las cuales ayudan a establecer relaciones
entre los requisitos y el modelo operativo. Estas entidades lógicas también sirven
para organizar los requisitos y para ayudar a sintetizar la solución técnica. A
medida que la solución técnica se selecciona o va surgiendo, los requisitos se
asignan a componentes de sistema de servicio (o a la arquitectura, en el caso de
muchos requisitos no funcionales) según sea apropiado.

En el caso de utilizar un enfoque iterativo o incremental para el desarrollo del
sistema de servicio, los requisitos también se asignan a iteraciones o a
incrementos.

6. Identificar interfaces tanto externas como internas al sistema de
servicio.

7. Desarrollar requisitos para las interfaces identificadas.

Analizar y validar requisitos

Analizar y validar los requisitos, y definir la funcionalidad y los
atributos de calidad requeridos para el sistema de servicio.

Se realizan análisis de requisitos para determinar qué impacto tendrá el
entorno de prestación de servicios proyectado sobre la capacidad para
satisfacer las necesidades, expectativas, restricciones, e interfaces de
las partes interesadas relevantes. Dependiendo del contexto de la
prestación de servicios, se deberían considerar factores tales como la
viabilidad, las necesidades de la misión, las restricciones de los costes,
la heterogeneidad de los usuarios finales, el tamaño del mercado
potencial, y la estrategia de compras. También se establece una
definición de la funcionalidad y los atributos de calidad requeridos. Los

Desarrollo del Sistema de Servicio (SSD) 405

CMMI para Servicios, Versión 1.3

objetivos de los análisis son determinar cuáles los requisitos candidatos
de los modelos del sistema de servicio que satisfarán las necesidades,
expectativas, y restricciones de las partes interesadas, y después
traducir estos modelos en requisitos exhaustivos del sistema de
servicio. En paralelo con esta actividad, se determinan los parámetros
que se utilizan para evaluar la eficacia de la prestación de servicios en
base a las entradas de los clientes y usuarios finales y al modelo de
prestación de servicios preliminar.

Los requisitos se validan trabajando con las partes interesadas
relevantes para asegurar que, en el entorno de prestación de servicios,
el sistema de servicio prestará los servicios como se proyectó.

Ejemplos de productos de trabajo

1. Modelos y escenarios operativos, casos de uso, y diagramas de
actividad e historias de usuario.

2. Modelos de la instalación, la capacitación, la operación, el
mantenimiento, el soporte, y la retirada del sistema de servicio y
los componentes de sistema de servicio.

3. Definición de la funcionalidad y los atributos de calidad requeridos.

4. Requisitos de calidad significativos para la arquitectura.

5. Nuevos requisitos.

6. Informes de defectos en requisitos y cambios propuestos para
resolverlos.

7. Evaluación de riesgos relacionados con los requisitos.

8. Registro de los métodos y los resultados de los análisis.

Subprácticas

1. Desarrollar modelos y escenarios operativos que incluyan las
operaciones, la instalación, el desarrollo, el mantenimiento, el
soporte, y la retirada según sea apropiado.
Identificar y desarrollar escenarios que sean consistentes con el nivel de detalle
de las partes interesadas sobre las necesidades, expectativas, y restricciones en
las cuales se espera que opere el sistema de servicio propuesto.

2. Desarrollar un modelo operativo detallado que defina la interacción
entre el sistema de servicio, los usuarios finales, y el entorno, y
que satisfaga las necesidades operativas, de mantenimiento, de
soporte, y de retirada.
Los modelos y escenarios operativos se refinan de forma iterativa para incluir
mayor nivel de detalle a medida que se toman decisiones y se desarrollan
requisitos de más bajo nivel (p. ej. para describir más a fondo las interacciones
entre el sistema de servicio, los usuarios finales, y el entorno). Los modelos y
escenarios operativos se revisan periódicamente para asegurar que abordan las
necesidades de funcionalidad y de atributos de calidad de las partes interesadas
relevantes, las distintas fases del ciclo de vida, y los modos de uso del sistema de

406 Desarrollo del Sistema de Servicio (SSD)

SG 2 CMMI para Servicios, Versión 1.3

servicio. Las revisiones pueden tomar la forma de recorridos.

3. Establecer y mantener una definición de la funcionalidad y los
atributos de calidad requeridos.

Esta definición de la funcionalidad y los atributos de calidad requeridos describe
qué tiene que hacer el producto (consúltese la definición de “definición de
funcionalidad y atributos de calidad requeridos” en el glosario). Esta definición
puede incluir descripciones, descomposiciones, y reparto de las funciones del
producto.

Adicionalmente, la definición especifica consideraciones o restricciones de diseño
acerca del modo en que la funcionalidad requerida se va a materializar en el
sistema de servicio. Los atributos de calidad abordan factores del sistema de
servicio tales como la disponibilidad, la mantenibilidad; la modificabilidad; la
puntualidad, la capacidad productiva, y el tiempo de respuesta; la fiabilidad; la
seguridad; y la escalabilidad. Algunos atributos de calidad surgirán como
atributos significativos para la arquitectura, dirigiendo así las actividades
subsiguientes de diseño del sistema de servicio de alto nivel. Comprender
claramente los atributos de calidad y su importancia en función de las
necesidades de la misión o del negocio es una entrada esencial al proceso de
diseño.

4. Analizar los requisitos para asegurar que son necesarios,
suficientes, y que equilibran las necesidades y las restricciones de
las partes interesadas.

A medida que se definen los requisitos, se deberían entender qué relaciones
tienen con los requisitos de mayor nivel y con la funcionalidad definida de mayor
nivel. Se determinan los requisitos clave que se utilizarán para realizar el
seguimiento del progreso. Se puede realizar un análisis de coste/beneficio para
evaluar el impacto sobre los costes, los plazos, el rendimiento, y los riesgos del
servicio o el sistema de servicio que tienen los requisitos de atributos de calidad
que son significativos para la arquitectura. Puede que sea necesario renegociar
los requisitos de mayor nivel cuyos costes o riesgos resulten ser inaceptables.

5. Validar los requisitos para asegurar que el sistema de servicio
resultante actuará como se proyectó en el entorno del usuario
final.

Desarrollar el sistema de servicio

Los componentes de sistema de servicio se seleccionan, diseñan,
implementan, e integran.

Un sistema de servicio puede incluir productos de trabajo, procesos,
personas, consumibles, y clientes y otros recursos.

Una parte importante de los componentes de sistema de servicio que a
menudo no se tiene en cuenta es el factor humano. Las personas que
realizan las tareas formando parte de un sistema de servicio posibilitan
que los sistemas operen, y este rol lo pueden desempeñar tanto el
personal del proveedor como los usuarios finales. Por ejemplo, un
sistema de servicio que procese las llamadas entrantes de un servicio

Desarrollo del Sistema de Servicio (SSD) 407

CMMI para Servicios, Versión 1.3

debería disponer de personal capacitado para recibir las llamadas y
procesarlas de forma apropiada utilizando otros componentes del
sistema de servicio. En otro ejemplo, los usuarios finales de un servicio
de seguros pueden necesitar seguir un proceso de reclamaciones
preestablecido para recibir del sistema de servicio los beneficios del
servicio.

Un consumible es cualquier cosa utilizable por el proveedor de
servicios que deje de estar disponible o que cambie permanentemente
al ser utilizada en la prestación de servicios. Un ejemplo es la gasolina
de un sistema de servicio de transportes que utilizan los vehículos que
funcionen con gasolina. Incluso los sistemas de servicio que se
componen fundamentalmente de personas y procesos manuales a
menudo utilizan consumibles tales como el material de oficina. El papel
que desempeñan los consumibles del sistema de servicio siempre se
debería tener en cuenta.

Esta meta se centra en las siguientes actividades:

 Evaluar y seleccionar soluciones que potencialmente satisfagan un
conjunto apropiado de requisitos.

 Desarrollar diseños detallados para las soluciones seleccionadas
(lo suficientemente detallados como para poder implementar el
sistema de servicio a partir del diseño).

 Implementar los diseños de los componentes de sistema de
servicio según se necesite.

 Integrar el sistema de servicio de forma que se puedan verificar y
validar sus funciones y atributos de calidad.

Habitualmente, estas actividades se solapan, son recurrentes, y se
soportan mutuamente. Puede que sea necesario algún nivel de diseño,
a veces bastante detallado, para seleccionar soluciones. Se pueden
utilizar prototipos, pilotos, y pruebas independientes como medio para
adquirir conocimientos suficientes para desarrollar un conjunto
completo de requisitos o seleccionar de entre las alternativas
disponibles.

Desde la perspectiva de las personas, los diseños pueden consistir en
especificaciones de niveles de cualificación y planes de personal, y los
distintos planes de personal se pueden probar con prototipos o pilotos
para determinar cuáles funcionan mejor bajo ciertas condiciones.
Desde la perspectiva de los consumibles, los diseños pueden consistir
en especificaciones de las características y cantidades de consumibles
que son necesarios. Puede que incluso algunos consumibles requieran
ser implementados. Por ejemplo, puede que sea necesario diseñar e
imprimir formularios específicos en papel para probarlos más adelante
como parte del sistema de servicio.

Los procesos de desarrollo se implementan de forma repetida en el
sistema de servicio según se necesite para dar respuesta a cambios en
los requisitos, o a problemas que no se descubrieron durante la
verificación, validación, transición, o entrega. Por ejemplo, algunas

408 Desarrollo del Sistema de Servicio (SSD)

CMMI para Servicios, Versión 1.3

SP 2.1 cuestiones que se revelaron en los procesos de verificación y
validación se pueden resolver en los proceso de desarrollo de
requisitos. La recurrencia e iteración en estos procesos permite al
grupo de trabajo asegurar la calidad de todos los componentes de
sistema de servicio antes de que éste empiece a prestar servicios a los
usuarios.

Seleccionar soluciones para el sistema de servicio

Seleccionar soluciones para el sistema de servicio de entre las
soluciones alternativas.

Las soluciones alternativas y sus virtudes relativas son tenidas en
cuenta de antemano para seleccionar una solución. Se establecen los
requisitos clave (incluyendo los requisitos de atributos de calidad), los
problemas de diseño, y las restricciones con el fin de utilizarlos en los
análisis de soluciones alternativas. Se tienen en cuenta las
características de la arquitectura que proporcionan la base para
mejorar y evolucionar el sistema de servicio.

Para más información sobre analizar posibles decisiones utilizando un
proceso de evaluación formal que evalúe las alternativas identificadas
con respecto a criterios establecidos, consúltese el área de proceso
Análisis de Decisiones y Resolución.

Una estrategia que potencialmente es ineficaz para implementar esta
práctica consiste en generar únicamente soluciones basadas en la
forma en que se prestaban los servicios en el pasado. Es importante
considerar alternativas que representen formas distintas de asignar y
llevar a cabo las funciones necesarias (p. ej. procesos manuales frente
a automáticos, responsabilidades de los usuarios finales frente a las del
personal de prestación de servicios, gestión de peticiones de servicio
planificadas con anterioridad frente a peticiones sobre la marcha).

Se pueden asignar componentes de sistema de servicio, incluyendo
funciones de prestación de servicios y de soporte, a los
suministradores externos. Como resultado, se investigan acuerdos de
suministro prospectivos. Para utilizar componentes suministrados
externamente se tienen en cuenta sus costes, sus plazos, sus
prestaciones, y sus riesgos. Se pueden utilizar alternativas
suministradas externamente con o sin modificaciones. A veces, para
cumplir mejor los requisitos del servicio o del sistema de servicio, estos
elementos requieren modificaciones en aspectos tales como las
interfaces o adaptaciones de alguna de sus características.

Para más información sobre gestionar la adquisición de productos y
servicios a los suministradores, consúltese el área de proceso Gestión
de Acuerdos de Suministro.

Ejemplos de productos de trabajo

1. Criterios para filtrar soluciones alternativas.

Desarrollo del Sistema de Servicio (SSD) 409

CMMI para Servicios, Versión 1.3

SP 2.2 2. Criterios de selección.

3. Decisiones y justificaciones de la selección de un componente de
sistema de servicio.

4. Documentación de las relaciones entre requisitos y componentes
de sistema de servicio.

5. Soluciones, evaluaciones, y justificaciones documentadas.

Subprácticas

1. Establecer criterios definidos de selección.

2. Desarrollar soluciones alternativas.

El desarrollo de soluciones alternativas puede requerir utilizar patrones de
arquitectura, reutilizar componentes, investigar soluciones comerciales (COTS),
externalizar servicios, y tener en cuenta la madurez y obsolescencia tecnológicas.

3. Seleccionar el sistema de servicio que mejor satisfaga los criterios
establecidos.

La selección se basa en evaluar las alternativas utilizando los criterios definidos.
En situaciones de alto riesgo, para ayudar en la evaluación se pueden utilizar
simulaciones, prototipos, o pilotos.

Seleccionar las soluciones para el sistema de servicio que satisfacen mejor los
criterios es la base para poder asignar los requisitos a los diferentes aspectos del
sistema de servicio. Los requisitos de menor nivel se generan a partir de las
alternativas seleccionadas y se utilizan para desarrollar el diseño de los
componentes de sistema de servicio. Los requisitos de interfaz entre los
componentes de sistema de servicio se describen.

Desarrollar el diseño

Desarrollar diseños para el sistema de servicio y para los
componentes de sistema de servicio.

El término “diseño” en esta práctica se refiere a definir los componentes
de sistema de servicio y el conjunto de sus relaciones previstas; estos
componentes interactuarán colectivamente en los modos previstos para
lograr la prestación real de los servicios.

Los diseños de sistema de servicio deberían proporcionar el contenido
apropiado no sólo para la implementación, sino también para otros
aspectos del ciclo de vida del sistema de servicio, tales como la
modificación, la transición y puesta en producción, el mantenimiento, el
sostenimiento, y la prestación de servicios. La documentación de
diseño proporciona una referencia para dar soporte al entendimiento
mutuo del diseño por parte de las partes interesadas relevantes, y
facilita que se realicen futuros cambios en el diseño tanto durante el
desarrollo como en las fases subsiguientes del ciclo de vida.

Una descripción completa del diseño se documenta por medio de un
“paquete de diseño” que incluye el rango completo de características y
parámetros, incluyendo las funciones, las interfaces, los umbrales de

410 Desarrollo del Sistema de Servicio (SSD)

CMMI para Servicios, Versión 1.3

operación, las características de los procesos de fabricación y servicio
(p. ej. qué funciones se automatizan frente a cuáles se realizan
manualmente), y otros parámetros. Los estándares de diseño
establecidos (p. ej. listas de comprobación, plantillas, marcos de
procesos) son la base para lograr que la documentación de diseño
tenga un alto nivel de definición y completitud.

Algunos ejemplos de otros productos de trabajo relacionados con el diseño del
sistema de servicio son:
 Descripciones de los roles, las responsabilidades, las autoridades, las

rendiciones de cuentas, y las habilidades de las personas que se necesitan
para prestar el servicio.
 Casos de uso funcionales describiendo los roles y actividades de las personas
que participan en el servicio.
 Diseños o plantillas de manuales, formularios en papel, material de
capacitación, y guías para los usuarios finales, los operadores, y los
administradores.

“Diseñar las personas” en este contexto quiere decir especificar las
habilidades y niveles de cualificación que se necesitan para acometer
las tareas requeridas, y puede incluir indicar qué niveles de personal
son apropiados así como cuáles son las necesidades de capacitación
(si se necesita capacitación para lograr los niveles de cualificación
necesarios). “Diseñar consumibles” en este contexto significa
especificar las propiedades y características de los consumibles que se
requieren para dar soporte a la prestación de servicios así como las
estimaciones de uso de recursos para que opere el sistema de servicio.

Ejemplos de productos de trabajo

1. Arquitectura del sistema de servicio.

2. Diseños de componentes y consumibles del sistema de servicio.

3. Descripción de habilidades y detalles de la solución de personal (p.
ej. asignar utilizando personal disponible, contratar personal
permanente o temporal).

4. Diseño de especificaciones de interfaz y documentos de control.

5. Criterios de reutilización de diseños y componentes de sistema de
servicio.

6. Resultados de decisiones de hacer-o-comprar.

Subprácticas

1. Desarrollar un diseño para el sistema de servicio.

El diseño del sistema de servicio habitualmente consta de dos grandes fases que
se solapan en la ejecución: diseño preliminar y diseño detallado. El diseño
preliminar establece las capacidades y la arquitectura del sistema de servicio. El
diseño detallado define completamente la estructura y las capacidades de los
componentes de sistema de servicio.

Desarrollo del Sistema de Servicio (SSD) 411

CMMI para Servicios, Versión 1.3

SP 2.3 2. Asegurar que el diseño cumple con los requisitos de funcionalidad
y de atributos de calidad que tiene asignados.

3. Documentar el diseño.

4. Diseñar las interfaces de los componentes de sistema de servicio
utilizando para ello los criterios establecidos.

Los criterios para las interfaces frecuentemente reflejan los parámetros críticos
que se deberían definir, o al menos investigar, para determinar su aplicabilidad.
Estos parámetros son a menudo característicos de un tipo de sistema de servicio
determinado, y frecuentemente se asocian con requisitos de atributos de calidad
(p. ej. seguridad, protección, durabilidad, características de misión crítica).
Determinar minuciosamente qué procesos se deberían automatizar o automatizar
parcialmente, y qué procesos se deberían realizar manualmente.

5. Evaluar si los componentes de sistema de servicio deberían
desarrollarse, comprarse, o reutilizarse en base a los criterios
establecidos.

Asegurar la compatibilidad entre interfaces

Gestionar las definiciones, los diseños, y los cambios de las
interfaces del sistema de servicio internas y externas.

Muchos problemas de integración surgen de aspectos de las interfaces
tanto internas como externas que no se conocen o controlan. La
gestión eficaz de los requisitos de interfaces, de sus especificaciones, y
de sus diseños ayuda a asegurar que las interfaces implementadas
serán completas y compatibles.

En el contexto de los sistemas de servicio, las interfaces pueden
caracterizarse de manera amplia de acuerdo a uno de estos cuatro
grandes grupos:

 Las interfaces persona-a-persona, que son interfaces que
representan una comunicación directa o indirecta entre dos o más
personas, pudiendo ser cualquiera de ellas personal del proveedor
de servicios o usuarios finales. Por ejemplo, un guion de llamadas,
el cual indica el modo en que un operador de atención a usuarios
interactúa con un usuario final, define una interfaz de comunicación
directa persona-a-persona. Los libros de registro y los letreros
instructivos son ejemplos de interfaces indirectos persona-a-
persona.

 Los interfaces persona-a-componente, que son interfaces que
engloban las interacciones entre una persona y uno o más
componentes de sistema de servicio. Estas interfaces pueden
incluir tanto interfaces gráficas de usuario para componentes
automatizados (p. ej. aplicaciones software), como mecanismos de
control para el operador de componentes automatizados,
parcialmente automatizados, y no automatizados (p. ej.
equipamiento, vehículos).

412 Desarrollo del Sistema de Servicio (SSD)

CMMI para Servicios, Versión 1.3

 Las interfaces componente-a-componente, que son interfaces que
no incluyen interacción directa con personas. Las interfaces de
muchas de las interacciones entre componentes automatizados
pertenecen a este grupo, aunque existen otras posibilidades, tales
como las especificaciones que restringen la unión física de dos
componentes (p. ej. un camión de reparto, un muelle de carga).

 Interfaces compuestas, que son interfaces que mezclan o conectan
en niveles interfaces de más de uno de los otros tres grupos. Por
ejemplo, un sistema de ayuda en-línea que permita conversar
puede tener una interfaz compuesta, construida sobre una
combinación integrada de interfaces persona-a-persona, persona-
a-componente, y componente-a-componente.

Las interfaces también se pueden caracterizar como interfaces
externas o internas. Las “interfaces externas” son interacciones entre
los componentes de sistema de servicio y otras entidades externas al
sistema de servicio, incluyendo las personas, las organizaciones, y los
sistemas. Las interfaces internas pueden incluir las interacciones entre
el personal, los equipos, y las funciones de la organización proveedora
de servicios. Las “interfaces internas” también pueden incluir las
interacciones entre el personal o los usuarios finales y los componentes
de sistema de servicio.

Algunos ejemplos de productos de trabajo de interfaz de usuario son:
 Guiones de interacción con el cliente.
 Tipos y frecuencias de los informes.
 Interfaces de programas de aplicación.

Ejemplos de productos de trabajo

1. Categorías de interfaces con listas de interfaces por categoría.

2. Tabla o correspondencia de relaciones de interfaz entre los
componentes de sistema de servicio y el entorno externo.

3. Lista de las interfaces definidas que se han acordado para cada
par de componentes de servicio cuando sea aplicable. 4.
Informes de las reuniones del grupo de control de interfaces.

5. Acciones para actualizar las interfaces.

6. Actualización de una descripción o un acuerdo de interfaz.

Subprácticas

1. Revisar la cobertura y completitud de las descripciones de interfaz.

Las descripciones de interfaz se deberían revisar con las partes interesadas
relevantes para evitar que se malinterpreten, reducir retrasos, y prevenir el
desarrollo de interfaces que no funcionen correctamente.

2. Gestionar las definiciones de interfaz del sistema de servicio
internas y externas, sus diseños, y sus cambios.

La gestión de interfaces incluye mantener la consistencia de las interfaces

Desarrollo del Sistema de Servicio (SSD) 413