¿Qué significa la palabra artefactos en ingeniería de software?

La palabra artefacto es de la frase latina arte factum, skill + to make. Aunque la palabra artefacto tiene orígenes nobles , la palabra “artefacto” puede tener una connotación positiva o negativa en la ingeniería de software y el desarrollo de productos.

Una respuesta en StackExchange (¿Qué significa artefacto?) Incluye “Ejemplos serían documentos de diseño, modelos de datos, diagramas de flujo de trabajo, matrices y planes de prueba, guiones de configuración, …”

Durante el desarrollo del producto, a veces implica que ciertos tipos de artefactos tienen menos valor que el producto entregado al cliente. Incluso el Manifiesto Ágil incluye la frase “software de trabajo sobre documentación exhaustiva”.

Un artefacto puede tener una amplia gama de valores. En el contexto del desarrollo de nuevos productos, los entregables son un subconjunto de artefactos.

A menudo, el valor relativo de un solo producto no se conoce durante el desarrollo. La contribución relativa de cualquier entregable al proyecto puede estimarse en retrospectiva, pero el valor de cualquier entregable está sujeto a la perspectiva del evaluador. Los codificadores tienden a valorar el código de trabajo. Otro individuo puede enfatizar la importancia de los prototipos que crearon. Los redactores valoran los mensajes persuasivos.

El producto disponible para los clientes puede caracterizarse como un conjunto de productos externos . Los otros elementos pueden caracterizarse como entregables internos . Estos no están disponibles para el cliente.

Para un desarrollo exitoso, una multitud de contribuyentes se esfuerzan por actuar de manera coherente y armoniosa para producir un conjunto diverso de productos que se unen para formar un producto de gran valor. Finalmente, los clientes y usuarios evalúan el valor por la capacidad de un producto para resolver su problema actual o hacer un trabajo importante.

El término “artefacto” cubre todo el material recolectado o creado durante la vida del proyecto. Cubre notas tomadas con los interesados ​​durante la recopilación de requisitos, fotos de garabatos de pizarra tomadas después de sesiones de lluvia de ideas, así como documentos más detallados, como casos de uso, maquetas y prototipos.

En mi opinión, estos artefactos representan más una “instantánea” de dónde el equipo pensó que el proyecto iba en un momento determinado. Algunas organizaciones catalogan y almacenan meticulosamente estas cosas, pero creo que su vida útil es bastante corta. Ciertamente, algunos (es decir, casos de uso) tienen una vida más larga, pero es una buena práctica considerarlos a todos como efímeros.

Depende del contexto.

Durante la recopilación de requisitos, un artefacto es cualquier cosa que alguien del equipo haya recibido del cliente. Normalmente se etiquetaría o identificaría para garantizar la unicidad, y otros artefactos pueden hacer referencia a ella. Por ejemplo, un borrador de conjunto de requisitos puede ser referenciado por un documento de requisitos más formal que el equipo puede haber preparado. El documento de requisitos formales (que ahora es otro artefacto) puede hacer referencia al artefacto recibido del cliente.

Por otro lado, durante el modelado de requisitos (por ejemplo, si sigue RUP o cualquier otra metodología similar), puede desarrollar artefactos como un subproducto de “ingeniería de software”. Por lo tanto, puede modelar un conjunto de casos de uso, actores, etc.

Más adelante, durante la fase arquitectónica, los artefactos solo aumentan: el modelo operativo (lógico o físico) es otro ejemplo de un artefacto grande y complejo. El Diagrama de clase, o un diagrama de secuencia específico que representa la interacción para un proceso específico, es otro artefacto.

Puede generalizar los artefactos como las entidades individuales que componen la documentación para el sistema de software que se está creando.