Especificaciones de desarrollo por encargo: ¿es correcto dejarlas en Excel? — Cómo elegir el formato como entregable

«Recibí la versión corregida de las especificaciones, pero terminé aprobando la recepción sin saber qué había cambiado.»

«Cuando quisimos encargar una modificación, las especificaciones en Excel que nos habían entregado no se parecían en nada a las pantallas actuales.»

«La empresa de desarrollo nos envió unas especificaciones en Excel con formato de cuadrícula, ¿es esto normal?»

Cuando se externaliza el desarrollo de un sistema, junto con el programa se entregan las especificaciones y los documentos de diseño. En el desarrollo por encargo en Japón, estos documentos se elaboran muy a menudo en Excel, con un estilo frecuentemente llamado «cuadrícula Excel», en el que las celdas se dividen en unidades muy pequeñas y se usan como si fueran papel cuadriculado de manuscrito.

En internet abundan las críticas a la cuadrícula Excel, pero la mayoría se centra en lo poco práctica que resulta como documento interno del equipo de desarrollo. Este artículo cambia de enfoque: se centra exclusivamente en las especificaciones que se entregan al cliente en un desarrollo por encargo, y organiza qué es lo problemático y qué formato conviene elegir con el vocabulario de la práctica contractual: recepción, cambios de especificaciones y mantenimiento. El objetivo es que resulte útil tanto para quien encarga el desarrollo como para la empresa que lo entrega.

1. Conclusión, en primer lugar

Antes de entrar en detalle, resumimos los puntos clave.

• El formato de las especificaciones que se entregan no debe elegirse por «si es fácil de escribir durante el desarrollo», sino por si el cliente puede revisarlo, si resiste la recepción, si permite compartir las diferencias de los cambios de especificaciones y si sigue siendo utilizable en el mantenimiento años después
• La conclusión no es «abandonar Excel», sino «abandonar la cuadrícula y volver a usar la herramienta adecuada para cada cosa»: el texto en Word, las tablas en el formato de tabla propio de Excel, los diagramas con una herramienta de dibujo y el registro de los acuerdos en PDF
• Antes de discutir el formato, hay que definir en el contrato (en la especificación de los entregables del contrato individual) qué documentos son entregables y si se recibirá el original editable

Si convertimos en una tabla de decisión el formato recomendado según la naturaleza de cada documento, queda así.

A continuación explicamos, en orden, por qué se llega a esta conclusión.

2. ¿Qué problema tienen las especificaciones en cuadrícula Excel como entregable?

Antes que nada, aclaremos algo: el problema no es el propio software Excel. Como herramienta de cálculo y de listas, Excel es excelente, y como se explica más adelante, para documentos como las definiciones de elementos, Excel es la elección correcta. El problema es meter en la «cuadrícula» textos, diagramas y tablas —cosas de naturaleza distinta— todo junto.

Si se tratara de un documento interno de la empresa, sería un problema que solo afecta a quienes lo escribieron. Pero cuando se trata de un entregable, la cosa cambia. Las especificaciones son un producto que el cliente recibe a cambio de un pago, son objeto de recepción y son un activo que se usará durante años después. Desde el punto de vista del entregable, la cuadrícula Excel presenta los siguientes problemas.

2.1 No se puede revisar a fondo en la recepción

La cuadrícula Excel no cuenta con un mecanismo práctico de visualización de diferencias como el control de cambios de Word. Para ser precisos, el entorno de coedición de Microsoft 365 sí tiene un historial de cambios de celdas («Mostrar cambios» o el historial de versiones), y existen herramientas como Spreadsheet Compare para comparar libros entre sí. Sin embargo, lo que se puede rastrear se centra en los valores y fórmulas de las celdas; el texto dentro de las formas y los cuadros de texto, que se usa mucho en los documentos con cuadrícula, queda fuera, y en la práctica habitual de entregar archivos por correo electrónico, el historial de coedición simplemente no funciona.

Al final, cuando el cliente recibe la versión corregida que refleja las observaciones de la revisión, tiene que buscar visualmente «qué ha cambiado». Releer por completo un documento de decenas de hojas cada vez no es realista, así que en la práctica se termina aprobando la recepción con un «probablemente ya esté corregido».

Esto es la degradación de la recepción a mero trámite. La recepción es el procedimiento de «confirmar que el entregable se ajusta a lo acordado y aceptarlo»; cuando este proceso se vacía de contenido, si más tarde aparece un problema, se termina en una discusión estéril del tipo «pero si ya pasó la recepción» frente a «no, es que no se entregó en una forma que se pudiera verificar».

2.2 No queda registro del acuerdo sobre los cambios de especificaciones

Durante el desarrollo, las especificaciones siempre cambian. Cuando el documento es una cuadrícula Excel, el intercambio de cambios tiende a convertirse en «una montaña de copias de archivos». Muchos reconocerán nombres de archivo como especificaciones_v2_final_corregido(2).xlsx.

El problema es que después no se puede identificar cuál versión es «la que ambas partes acordaron». Cuando surgen discrepancias sobre costos adicionales o plazos de entrega, lo que sirve de base es el documento acordado. Si no se sabe cuál es ese documento, la discusión se convierte en un intercambio de acusaciones sin salida.

2.3 Se desvía de la implementación en la fase de mantenimiento

Como el documento en cuadrícula tiene un costo de actualización alto, deja de actualizarse con las modificaciones posteriores a la entrega. Nadie lo toca por miedo a que se rompa el diseño, el texto dentro de las formas no aparece en las búsquedas y por eso quedan correcciones sin hacer; la acumulación de estos factores lleva, años después, a una situación en la que «las especificaciones existen, pero nadie sabe si coinciden con la realidad».

La factura de esta situación se paga en la siguiente modificación. Si no se puede confiar en el documento, hay que volver a empezar investigando el sistema real (el sistema en funcionamiento y el código fuente), y ese esfuerzo se suma al presupuesto. El hecho de que el documento no se mantenga repercute en el costo de las futuras modificaciones.

2.4 No se puede aprovechar del lado del cliente

Un diseño pensado para imprimirse es difícil de leer en pantalla. Además, como el contenido está disperso en numerosas hojas y formas, la búsqueda de texto completo funciona mal, y localizar «dónde estaba escrita aquella especificación» toma tiempo. Tampoco es fácil el reaprovechamiento por parte del cliente, como añadir notas de operación o reutilizarlo en material de explicación interna, así que un documento por el que se pagó termina, con frecuencia, «solo guardado».

3. La perspectiva contractual — las especificaciones son un «entregable»

Antes de entrar en el tema del formato, subamos un nivel. Las especificaciones y los documentos de diseño se convierten en un entregable contractual, igual que el programa, cuando el contrato los define como productos a entregar. Dicho de otro modo, un documento que no está especificado en el contrato no necesariamente se entregará. El Modelo de Transacción y Contrato de Sistemas de Información de la IPA también sigue esta estructura: en el contrato individual se especifican los productos a entregar y se definen el método y el plazo de la recepción. La visión general del contrato modelo se explica en otro artículo, «Cómo estructurar los contratos de desarrollo por encargo y mantenimiento operativo — el uso diferenciado de cuasi-mandato y contrato de obra según el “Modelo de Transacción y Contrato” de la IPA».

Es decir, la discusión sobre el formato —Excel o Word— solo tiene sentido una vez que se ha decidido la siguiente base.

• Qué documentos son el entregable: hacer una lista al nivel del nombre de cada documento, no un genérico «conjunto de documentos»
• En qué formato se recibirán: si se incluye el original editable (archivos de Word o Excel). Recibir solo PDF genera problemas en el mantenimiento
• El método de recepción: qué se debe verificar para aceptarlo. Cómo se mostrarán las diferencias de la versión corregida
• El tratamiento de los derechos de autor y el reaprovechamiento: si el cliente puede reproducir y modificar el documento internamente. Si podrá entregarlo a otra empresa cuando, en el futuro, encargue el mantenimiento a un tercero

Si esto no está decidido en el contrato, por muy buen formato que se elija, surgirán conflictos sobre si ese documento era o no objeto de entrega. Para organizar lo que hay que definir antes de encargar el desarrollo, consulte también «Qué conviene organizar antes de encargar el desarrollo externo de una aplicación de Windows».

4. Las opciones de formato de entrega — comparadas según si funcionan como entregable

Una vez decidida la base, se elige el formato. Como se mencionó al principio, los criterios de evaluación son cuatro: facilidad de lectura para el cliente / facilidad de revisión y recepción / gestión de diferencias en los cambios de especificaciones / sostenibilidad en la fase de mantenimiento.

El significado de los símbolos de evaluación es el siguiente. Se juzga si el formato cuenta con el mecanismo de forma nativa, sin incluir si se podría cubrir con algún ajuste operativo.

Antes de continuar, explicamos los motivos de los tres casos marcados con △.

• La gestión de diferencias de Excel es △: porque no existe un mecanismo equivalente al control de cambios de Word que muestre las diferencias en rojo. Existen el historial de versiones de los valores de celda y Spreadsheet Compare, pero presuponen un entorno de coedición o dejan fuera el texto dentro de formas y cuadros de texto (sección 2.1). Al final hay que compensarlo con la regla operativa de «añadir por separado una lista de cambios».
• La sostenibilidad de PDF en el mantenimiento es △: para leerlo no hay problema, pero como no se puede seguir actualizando manteniendo la estructura, se necesita un original editable aparte (sección 4.3).
• La sostenibilidad del Wiki en el mantenimiento es △: la facilidad de actualización es, de hecho, la mejor de todas, pero si el documento sobrevive después de terminar el contrato depende del contrato y la configuración de la herramienta. Si no se decide de antemano si se puede exportar, quién es dueño del espacio y cómo se gestionan las cuentas, se pierde el acceso al documento en el mismo momento en que termina el contrato (sección 4.5).

A continuación, ampliamos cada uno.

4.1 Word — la primera opción para especificaciones basadas en texto

Los documentos que «se explican con texto», como un documento de diseño general o la descripción de un flujo de trabajo, deberían escribirse originalmente en un procesador de texto. Word ya incluye desde el principio las herramientas necesarias para un documento de entrega.

• Estilos de encabezado e índice automático: la estructura del documento queda clara y se puede saltar desde el índice a la sección deseada
• Control de cambios (función de revisión): se ve en rojo qué ha cambiado en la versión corregida. La eficacia real de la revisión y la recepción mejora notablemente
• Función de comentarios: las observaciones del cliente y sus respuestas quedan registradas en el propio documento
• Comparación de documentos: se pueden mostrar las diferencias entre dos versiones incluso después

El cliente no necesita ninguna herramienta especial ni aprendizaje, y el hecho de que se acepte tal cual como formato de entrega es, en la práctica, una gran ventaja.

El punto a tener en cuenta es que si se crea un documento que solo tiene una apariencia ordenada sin usar los estilos, se cae en el mismo agujero que podríamos llamar «cuadrícula Word». Los encabezados deben usar el estilo de encabezado, y el diseño debe lograrse con formato, no a base de espacios repetidos. Además, el «problema de cuál es la versión más reciente» también puede ocurrir en Word, así que debe usarse junto con la gestión de versiones que se explica más adelante.

4.2 Excel: volver a usarlo como una «tabla auténtica»

Documentos como la definición de elementos de pantalla, la lista de códigos o la matriz de permisos son, en esencia, tablas. Escribirlos en Word resulta, por el contrario, incómodo, y Excel es la elección correcta. Sin embargo, se usa no como cuadrícula, sino como una tabla simple que se puede tratar como datos.

• Una fila = un registro, una columna = un atributo. En cada hoja se coloca una sola tabla
• No crear el diseño combinando celdas. Los encabezados van en una sola fila al principio
• No romper la estructura de datos por el aspecto de impresión (el formato para imprimir se resuelve por otro medio)

Si se crea de esta manera, el documento se puede tratar de forma mecánica durante el mantenimiento. Se hace posible el reaprovechamiento, como cotejar la definición de elementos con la definición real de la base de datos o usar la lista directamente como base de los elementos de prueba, y así se facilita incluso la propia verificación de si el documento se ha desviado de la implementación.

4.3 PDF — el formato para congelar la «versión acordada»

Que el PDF no se pueda editar fácilmente es tanto un defecto como una ventaja. Como original de las especificaciones queda descalificado, pero es adecuado como instantánea de la versión que pasó la recepción o de la versión acordada tras un cambio de especificaciones. Como no se reescribe por descuido, funciona como registro de «en este momento se acordó esto».

Sin embargo, en rigor, un PDF también se puede rehacer. El valor como registro no proviene del formato PDF en sí, sino de que ambas partes conserven el mismo archivo, así que combínelo con prácticas como enviarlo por correo electrónico conservando también el registro del envío, o guardarlo en el entorno de ambas partes. Si se busca además valor probatorio en caso de disputa, la firma electrónica o el sellado de tiempo también son opciones.

Hay otro principio, que es simple: el PDF siempre debe ir acompañado del original editable. Entregar solo el PDF reduce las opciones futuras del cliente (el aprovechamiento interno, encargar el mantenimiento a otra empresa).

4.4 Usar Markdown + Git como original y generar Word/PDF para la entrega

Como gestión del lado de la empresa de desarrollo, en los últimos años se ha extendido el método de escribir las especificaciones en Markdown y gestionar las versiones en el mismo repositorio Git que el código fuente. Se pueden obtener diferencias a nivel de línea, se puede revisar el documento con el mismo mecanismo que la revisión de código, y el motivo de cada cambio queda registrado en el historial (esto es suficiente como registro de la práctica de desarrollo, pero si se busca además valor probatorio para auditorías o disputas, hace falta además una práctica que prohíba reescribir el historial, entre otras medidas).

En este caso no hace falta pedirle Git al cliente. Si se organiza de forma que el original se gestione en Markdown y el entregable se genere en Word o PDF con una herramienta de conversión como Pandoc, el cliente simplemente recibe Word o PDF como siempre. Así se pueden conciliar la eficiencia de gestión del lado del desarrollo y la facilidad de lectura del lado del cliente.

Pandoc es una herramienta gratuita que convierte formatos de documento entre sí (de código abierto, se ejecuta por línea de comandos). Puede convertir Markdown a Word (.docx), PDF, HTML y muchos otros formatos, y si se especifica como «plantilla» un archivo de Word con el logotipo y los estilos de encabezado propios de la empresa, el Word generado se ajusta al formato estándar interno. Solo la empresa de desarrollo necesita instalarla; el lado que encarga el trabajo no necesita ninguna herramienta nueva. Como este punto se malinterpreta con facilidad, conviene explicarlo claramente al hacer la propuesta.

El flujo, representado en un diagrama, queda así.

［Lado de la empresa de desarrollo］
  Escribir las especificaciones en Markdown
        ↓
  Gestionarlas en el mismo repositorio Git que el código fuente
    ・Se ven las diferencias a nivel de línea
    ・Se puede revisar el documento con el mismo mecanismo que la revisión de código
    ・Queda en el historial cuándo, quién y por qué lo cambió
        ↓
  Convertir con Pandoc (especificando como formato un archivo Word de plantilla propia)
        ↓
  Se genera Word / PDF
        ↓
─────────── Entrega ───────────
        ↓
［Lado que encarga el trabajo］
  Recibir Word / PDF como siempre, leerlo y revisarlo
        ↓
  Devolver las solicitudes de corrección como "comentarios" (no reescribir directamente el resultado generado)
        ↓
  La empresa de desarrollo lo refleja en el Markdown original, lo vuelve a generar y lo entrega de nuevo

El punto a cuidar es dejar claro en el contrato «cuál es el original». Si el cliente modifica directamente el archivo Word generado, este se separa del original, así que, como se ve al final del diagrama, hace falta un acuerdo operativo para que las solicitudes de corrección se reciban como comentarios y se reflejen en el lado del original.

4.5 Wiki y herramientas en línea — «especificaciones vivas» cuando hay mantenimiento continuo

En sistemas con un contrato de mantenimiento vigente y modificaciones frecuentes, también es una opción sólida mantener las especificaciones actualizadas de forma constante en una herramienta en línea como Notion o Confluence. Es un formato con alta capacidad de búsqueda, en el que el historial de cambios queda registrado automáticamente, y que facilita mantener un «documento vivo» en lugar de terminar en el momento de la entrega.

Sin embargo, visto como entregable, hay que decidir de antemano qué queda cuando termina el contrato: el formato de exportación (si se puede exportar a Word o PDF), la propiedad del espacio y quién asume el costo, y el tratamiento de las cuentas de acceso. Si esto se deja ambiguo, se produce un bloqueo (lock-in) a una herramienta específica, con el riesgo de perder el acceso al documento en el mismo momento en que termina el contrato.

5. Cómo gestionar el intercambio de cambios de especificaciones

Aunque se ordene el formato, si no hay una práctica operativa, el «problema de cuál es la versión más reciente» reaparece. Porque las especificaciones no dejan de cambiar ni siquiera después de la entrega: siguen cambiando tanto durante el desarrollo como en la fase de mantenimiento. El esquema básico recomendado es el siguiente.

1. Preparar un único libro de gestión de cambios: una tabla en la que cada fila registra el número de cambio, la fecha, el contenido, el impacto (costo/plazo) y quién lo acordó. Para esto basta una tabla simple de Excel. Hágalo corresponder con el procedimiento de gestión de cambios del contrato modelo de la IPA (véase el artículo mencionado antes)
2. Intercambiar las correcciones del documento en una forma en la que se vean las diferencias: en Word, active el control de cambios y envíe la versión corregida; el cliente la revisa centrándose en el texto en rojo. Si preocupa que se olvide activar el control de cambios, quien lo recibe puede detectar los olvidos cotejándolo con la versión acordada anterior mediante la función «Comparar» de Word. Una vez acordado, se aplica el historial y se fija la versión
3. Definir una regla de numeración de versiones: la versión de recepción es v1.0, y cada acuerdo de cambio la sube a v1.1, v1.2, etc. No usar en el nombre del archivo palabras como «final», «corregido» o «(2)»
4. Congelar en PDF la versión acordada y que ambas partes la conserven: para que cualquiera pueda identificar después con qué versión se llegó al acuerdo

Sea cual sea la herramienta, si estos cuatro puntos funcionan, se evitan casi por completo los dos grandes problemas: «no se sabe qué cambió» y «no se sabe cuál es la versión acordada». Dicho de otro modo, lo esencial no es elegir la herramienta, sino acordar las reglas operativas.

6. Lo que el lado que encarga el trabajo debería confirmar antes de contratar

Para quienes encargan el trabajo, resumimos en una lista de verificación lo que conviene confirmar en la etapa de presupuesto y contrato.

• ¿La lista de entregables incluye las especificaciones y los documentos de diseño al nivel del nombre del documento (y no como un genérico «conjunto de documentos»)?
• ¿Se puede recibir el original editable (archivos de Word/Excel, etc.)? ¿No se limita solo al PDF?
• Al recibir la versión corregida, ¿se presenta en una forma que permite saber qué ha cambiado (control de cambios, lista de cambios)?
• ¿El alcance del contrato de mantenimiento incluye la actualización del documento en cada modificación? Si no la incluye, ¿es aceptable dar por hecho que se irá desviando de la realidad?
• El tratamiento de los derechos de autor y el reaprovechamiento del documento. ¿Se podrá entregar el documento cuando, en el futuro, se encargue el mantenimiento a otra empresa?
• ¿Está definido el procedimiento para los cambios de especificaciones (libro de gestión de cambios, forma de dejar constancia del acuerdo)?

También desde el punto de vista de quien recibe el encargo, esta lista sirve tal cual para organizar el presupuesto. Qué documento se escribe y con qué nivel de detalle es esfuerzo, y por tanto es dinero. Si se acepta el pedido dejando ambiguo el alcance de los entregables, cerca de la entrega surgen malentendidos del tipo «yo daba por hecho que este documento también estaba incluido». Acordar desde el principio la lista de documentos y su formato protege a ambas partes.

Resumen

Resumimos los puntos clave de este artículo sobre las especificaciones que se entregan en un desarrollo por encargo.

• El formato de las especificaciones que se entregan debe elegirse desde la perspectiva de la recepción, los cambios de especificaciones y el mantenimiento; no basta con elegirlo solo por si es fácil de escribir durante el desarrollo
• El problema esencial de la cuadrícula Excel es la degradación de la recepción a mero trámite por no poder ver las diferencias, la pérdida del registro del acuerdo, y la desviación respecto a la implementación por el alto costo de actualización
• La conclusión no es «eliminar Excel por completo», sino volver a usar la herramienta adecuada para cada cosa: el texto en Word (estilos + control de cambios), las tablas en el formato de tabla simple de Excel, y el registro del acuerdo congelado en PDF
• Gestionar el original del lado del desarrollo en Markdown + Git y generar Word/PDF como entregable permite conciliar las ventajas de ambas partes
• Antes que el formato, hay que decidir en el contrato la lista de entregables, la entrega del original editable y el tratamiento de los derechos de autor. Lo esencial es el acuerdo sobre las reglas operativas, más que la herramienta

Por otro lado, el tema de leer y escribir Excel desde un programa (generación de informes) se trata en «Cómo generar informes en Excel: COM/Open XML/plantillas», y la estructuración del contrato se trata en el artículo que explica el Modelo de Transacción y Contrato de la IPA. Le recomendamos leer también estos artículos.

Referencias

• Modelo de Transacción y Contrato de Sistemas de Información de la IPA ─ la plantilla de contrato mencionada en el capítulo 3, que define la especificación de los entregables, el método y el plazo de recepción, y el procedimiento de gestión de cambios. Tanto el lado que encarga como el que recibe el trabajo pueden obtenerla gratuitamente
• IPA, «Modelo de Transacción y Contrato de Sistemas de Información», segunda edición (revisión conforme a la reforma del Código Civil) ─ la segunda edición vigente y su explicación
• Pandoc ─ el sitio oficial de la herramienta de conversión de documentos mencionada en la sección 4.4. Incluye la lista de formatos compatibles y el modo de uso, incluida la especificación de una plantilla de Word
• Grado de Requisitos No Funcionales de la IPA ─ útil para organizar los requisitos no funcionales que se suelen olvidar en las especificaciones. La explicación está en otro artículo

Para quienes estén considerando encargar desarrollo o mantenimiento

En KomuraSoft LLC, al aceptar encargos de desarrollo de aplicaciones empresariales para Windows, acordamos desde el principio con el cliente el alcance, el formato y la práctica de actualización de la documentación de los entregables, siguiendo el criterio expuesto en este artículo. Además, en las modificaciones de software existente, también aceptamos la investigación que parte de una situación en la que «las especificaciones existen, pero no se sabe si coinciden con la realidad actual». No dude en consultarnos, incluida la revisión de las especificaciones o del formato de entrega.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

El cliente nos ha indicado una plantilla de cuadrícula Excel. ¿Debemos seguirla sí o sí?

Seguir el formato de entrega indicado forma parte de las obligaciones de quien recibe el encargo, pero vale la pena confirmar cuál es el objetivo de esa indicación. Si el objetivo es cumplir un estándar documental interno o una auditoría, puede que haya margen para proponer cubrir el mismo contenido con un formato de Word; y en no pocos casos, la plantilla simplemente se mantiene por costumbre histórica. Incluso cuando no se puede cambiar la indicación, muchos de los problemas de «no se ven las diferencias» se pueden mitigar con ajustes operativos, como adjuntar una «lista de cambios» a la versión corregida o congelar en PDF la versión acordada.

Las especificaciones se entregaron solo en PDF. ¿Hay algún problema?

En ese momento no parece un problema, porque se puede leer, pero surgen dificultades en la fase de mantenimiento y modificación. Editar un PDF no es imposible con herramientas especializadas, pero no es realista seguir actualizándolo manteniendo la estructura como se haría con un original de Word o Excel, y con cada cambio de especificaciones la desviación respecto a la implementación va aumentando. Además, si en el futuro se encarga el mantenimiento a otra empresa, sin un original editable resulta difícil transferir el documento. Lo más seguro es dejar explícito en el contrato, como condición del entregable, que se entregará «incluyendo un formato editable (el original de Word o Excel)». Si ya se ha recibido solo el PDF, conviene consultar a la empresa de desarrollo sobre la entrega del original.

¿Hasta qué nivel de detalle deberían pedirse las especificaciones?

No es cierto que «cuanto más detallado, mejor». Cuanto más detallado es un documento, mayor es el costo de actualizarlo, y más fácil que se desvíe de la implementación en la fase de mantenimiento. El criterio orientativo es que el comportamiento esté especificado lo suficiente como para servir de base en la recepción, y que se conserve la información que se consultará en el mantenimiento y las modificaciones (elementos de pantalla, estructura de datos, integraciones externas, reglas de negocio). Por el contrario, una explicación línea por línea de la implementación que ya se entiende leyendo el código se desvía menos si se deja en el código y los comentarios, en lugar de en el documento. Qué documentos hacer y con qué nivel de detalle está directamente ligado al esfuerzo, es decir, al importe del presupuesto, así que es un punto que debe acordarse antes de firmar el contrato.

¿De quién es la responsabilidad de actualizar las especificaciones después de la entrega?

Depende del contrato. Si el alcance del contrato de mantenimiento incluye «la actualización de los documentos de diseño en cada modificación», es tarea de quien recibió el encargo; si no lo incluye, hay que encargar la actualización del documento por separado en cada modificación, o asumir que se irá desviando de la realidad. Lo que suele generar conflictos es que este punto no se decida y ambas partes den por hecho, sin más, que «claro que se habrá actualizado». Se recomienda, al firmar el contrato de mantenimiento, dejar por escrito, al nivel del nombre de cada documento, cuáles quedan bajo el alcance del mantenimiento.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.