Un documento de control de interfaz ( ICD ) en ingeniería de sistemas [1] e ingeniería de software , proporciona un registro de toda la información de interfaz (como dibujos, diagramas, tablas e información textual) generada para un proyecto. [2] Los documentos de interfaz subyacentes proporcionan los detalles y describen la interfaz o interfaces entre subsistemas o hacia un sistema o subsistema .
Un ICD es el documento general sobre las interfaces del sistema; algunos ejemplos de lo que deberían describir estas especificaciones de interfaz incluyen:
El propósito del ICD es controlar y mantener un registro de la información de la interfaz del sistema para un proyecto determinado. Esto incluye todas las entradas posibles y todas las salidas potenciales de un sistema para algún usuario potencial o real del sistema. Las interfaces internas de un sistema o subsistema se documentan en sus respectivas especificaciones de requisitos de interfaz, mientras que las interfaces hombre-máquina pueden estar en un documento de diseño del sistema (como un documento de diseño de software ) [ cita requerida ] .
Los documentos de control de interfaz son un elemento clave de la ingeniería de sistemas , ya que controlan las interfaces documentadas de un sistema, además de especificar un conjunto de versiones de interfaz que funcionan juntas y, por lo tanto, limitan los requisitos.
Una interfaz de programación de aplicaciones es una forma de interfaz para un sistema de software, en el sentido de que describe cómo acceder a las funciones y servicios que proporciona un sistema a través de una interfaz. Si un productor de sistemas desea que otros puedan utilizar el sistema, una ICD y especificaciones de interfaz (o su equivalente) son una inversión que vale la pena.
Un ICD sólo debe describir la documentación detallada de la interfaz en sí, y no las características de los sistemas que la utilizan para conectarse. La función y la lógica de esos sistemas deben describirse en sus propios requisitos y documentos de diseño según sea necesario. De esta manera, equipos independientes pueden desarrollar los sistemas de conexión que utilizan la interfaz especificada, sin tener en cuenta cómo reaccionarán otros sistemas a los datos y señales que se envían a través de la interfaz. Por ejemplo, el ICD y la documentación de la interfaz asociada deben incluir información sobre el tamaño, el formato y lo que se mide con los datos, pero no el significado último de los datos en su uso previsto por cualquier usuario.
Una interfaz adecuadamente definida permitirá a un equipo probar su implementación simulando el lado opuesto con un simulador de comunicaciones simple. Si no se conoce la lógica empresarial del sistema del otro lado de una interfaz, es más probable que se desarrolle un sistema que no se estropee cuando el otro sistema cambie sus reglas y lógica empresariales. (En una especificación de requisitos de interfaz se debe evitar expresamente incluir límites o comprobaciones de la coherencia). De este modo, se consigue una buena modularidad y abstracción que conducen a un fácil mantenimiento y extensibilidad.
Los críticos de la documentación de requisitos y de la ingeniería de sistemas en general a menudo se quejan del énfasis excesivo en la documentación. [3] [4] Los ICD suelen estar presentes en proyectos basados en documentos , pero también pueden ser útiles en proyectos ágiles (aunque no se los nombra explícitamente como tales). [5] [6] Un ICD no necesita ser un documento textual. Puede ser una tabla (en evolución) de entradas y salidas , una base de datos dinámica que represente cada subsistema como una vista de BD, un conjunto de diagramas de interacción, etc.
Los ICD se utilizan a menudo cuando los subsistemas se desarrollan de forma asincrónica en el tiempo, ya que proporcionan una forma estructurada de comunicar información sobre las interfaces de los subsistemas entre diferentes equipos de diseño de subsistemas. [7] [8] [9]
Existe cierta confusión en torno a la relación entre los Documentos de Requisitos de Interfaz (IRD) y los Documentos de Control de Interfaz (ICD) a la hora de definir requisitos. Los documentos de definición de interfaz, sin importar el nombre, deben contener únicamente definiciones, ¡no declaraciones del tipo “deberá”! Son acuerdos y declaraciones de hechos (que suelen identificarse mediante el uso de “voluntad”). El uso de “voluntad” o “es” depende de en qué parte del proceso de diseño se encuentre. Los requisitos de interfaz pertenecen al conjunto de requisitos del sistema sin importar cómo se llame el documento. Se trata de declaraciones del tipo “deberá” vinculantes contractualmente que impulsan el diseño y deben verificarse. Un requisito de interfaz adecuado apunta a la definición, sin importar dónde se defina. [10]