¿Se puede justificar la creación de un documento de diseño de software después del desarrollo?

Actualmente estoy trabajando en mi graduación para mis estudios de "Desarrollo de software", en los que tengo que desarrollar software complejo individualmente en una empresa externa. Todo esto debe hacerse de manera estructurada, creando todos los documentos correspondientes.

Para este proyecto, he elegido trabajar con los documentos estándar de IEEE: Documento de requisitos de software (SRS), Documentos de arquitectura de software (SAD) y Documento de diseño de software (SDD). Aunque se enseñó lo contrario en la escuela, para este proyecto elegí crear el SDD después del desarrollo (en lugar de antes). Mi razonamiento es:

La compañía en la que realizo mi pasantía me ha dado instrucciones para crear una pieza compleja de software, satisfaciendo un cierto conjunto de requisitos, de manera experimental. Debido a la cantidad de libertad que me han dado en la definición del proyecto, casi nada es seguro de antemano, y se puede encontrar mejor al experimentar en el proceso de desarrollo. Además, estoy creando el software de manera individual , no tendría ningún beneficio para nadie más en la compañía que yo haga este diseño de software de antemano. Hacerlo de antemano le me acaba de costar mucho tiempo para cambiarlo más adelante, como puedo estar seguro de que con las incertidumbres en el proyecto, el diseño que hago de antemano tendrá que ser cambiado mucho . Esto me parece contraproducente.

¿Es esta una buena justificación para crear el SDD después del desarrollo? Si no, ¿habría alguna buena justificación para eso?

Editar: La razón para crear el SDD después sería que los futuros desarrolladores continúen en el proyecto. No podré terminar todo el proyecto en mi período de graduación, por lo que otros desarrolladores tendrán que continuar en la base de código actual.

En IEEE Std 1016 Sección 3.1 Diseño de software en contexto, puede encontrar este párrafo:

Un SDD se puede preparar y usar en una variedad de situaciones de diseño. Por lo general, un SDD está preparado para respaldar el desarrollo de un elemento de software para resolver un problema, donde este problema se ha expresado en términos de un conjunto de requisitos. El contenido de la SDD se puede rastrear hasta estos requisitos. En otros casos, un SDD está preparado para comprender un sistema existente que carece de documentación de diseño. En tales casos, se prepara un SDD para que la información de interés se capture, organice, presente y difunda a todas las partes interesadas. Esta información de interés puede usarse para la planificación, análisis, implementación y evolución del sistema de software, identificando y abordando preocupaciones de diseño esenciales.

Los autores de IEEE Std 1016 reconocen que un SDD no puede crearse por adelantado. Se puede crear uno después de que exista el sistema de software para capturar información para las partes interesadas.

La Sección 1.1 Alcance también proporciona información interesante:

Este estándar no prescribe metodologías específicas para el diseño, la gestión de la configuración o el aseguramiento de la calidad.

En el contexto de estas preguntas, las palabras clave son "gestión de la configuración". La gestión de la configuración no solo se aplica al sistema de software que se está creando, sino a toda la documentación asociada.

En su situación personal, y en muchas situaciones, crear un SDD por adelantado es un desperdicio. La respuesta de David Arno está cerca de ser lo que yo consideraría la respuesta correcta. El verdadero diseño de su sistema de software es el código. Sin embargo, "crear el SDD antes" o "crear el SDD después" no son sus únicas opciones. Tiene una tercera opción: desarrollar el SDD con el sistema de software.

Si sigue un estándar como IEEE Std 1016, tiene requisitos para un SDD. Específicamente, la Sección 4 de este estándar define el contenido que tiene. A medida que trabaja en las decisiones de diseño, comience a crear los diferentes puntos de vista, vistas y superposiciones. A medida que toma decisiones, capture la lógica del diseño para ellos.

Esto permitirá a las partes interesadas seguir la evolución del diseño del software sin necesidad de profundizar en el código. Por supuesto, las personas pueden tener comentarios o sugerencias. Si está actualizando el SDD, pueden rastrear su progreso y brindar comentarios sobre el enfoque temprano, que luego puede incorporar al producto, así como al SDD. Cuando realiza la transición del proyecto, si el código del software y el SDD están sincronizados, alguien debería poder incorporarse fácilmente y retomar el trabajo.

Si todo lo que busca del SDD es comunicar el diseño con otros, entonces sí, puede crearlo después del desarrollo. Lo único es que se llama documentación.

Sin embargo, me gustaría señalar que un SDD también puede servir para otro propósito. También puede ayudarlo a razonar sobre el diseño y asegurarse de que "falla rápidamente". Esto es algo bueno, especialmente si muchas cosas son inciertas de antemano porque puede descartar enfoques que no funcionarían en toda la implementación desde el principio. También puede evitar que se concentre en los detalles técnicos pronto, al no codificar nada hasta que haya descubierto el diseño.

Te aconsejaría que al menos intentes el SDD de antemano. Si se encuentra con cosas en las que no está seguro de cómo funcionarían, puede hacer pequeños prototipos de los problemas que está tratando de resolver. Esto le dará experiencia para resolver los problemas específicos de su proyecto que beneficiarán la calidad de la solución completa a largo plazo.

El único documento de diseño detallado que creará es el código. Precisamente le dice al compilador cómo construir su aplicación. Como tal, su diseño no puede completarse hasta esa construcción final antes del envío.

Cualquier otro documento de diseño que cree, como un SDD, deberá actualizarse después de completar su diseño (código). Por lo tanto, hay una razón convincente para escribir el SDD después: solo tiene que hacerlo una vez.

El contador obvio de esto es, "¿con qué frecuencia realmente escribe un SDD después del evento"? La aplicación se envía, por lo que no es probable que desee pasar tiempo documentando en esa etapa. Pero esto se aplica igualmente a la actualización de una existente. ¿Qué es peor, no hay SDD o un SDD que está mal y no se puede confiar?

Sin embargo, hay dos razones para escribirlo por adelantado. En primer lugar, puede ser un requisito obligatorio para usted hacerlo (no es agradable; pero sucede). En segundo lugar, crear dicho documento puede ayudarlo a formular una estrategia general para el diseño. Pero eso puede hacerse igualmente bien dibujando, garabateando notas, etc. de manera informal. Y dado que será necesario reescribirlo más adelante, el enfoque "rápido y sucio" de ese proceso inicial de diseño macro ofrece muchos beneficios.

Para mí, no sería una buena argumentación.

Si realmente fuera necesario, argumentaría con un fuerte enfoque en el desarrollo de prototipos para una mejor comprensión de un dominio de problema desconocido. Sin embargo, incluso en esos casos, algunas piezas de diseño serían útiles antes.

Hay un caso para hacerlo por adelantado de todos modos . Porque estás haciendo esto para aprender a escribir documentos como este. Omitir este trabajo porque puede no ser 100% necesario aquí significa que omite su aprendizaje.

Un compromiso podría ser escribirlo durante la implementación. Antes de cada componente / módulo / pantalla u otra subdivisión de su programa, debe pensar cómo lo va a hacer. Luego agrega sus decisiones a su documento de diseño y luego las implementa.

Si algo cambia más tarde, actualice el documento.

Esto tiene varias ventajas en comparación con escribir después del hecho:

• Aprenderá a mantener actualizados los documentos de diseño cuando cambien los requisitos, un hábito útil

• Aprenderá a pensar en el diseño antes de la implementación.

• No es tan aburrido como escribir documentos de diseño después de que

• Si se le acaba el tiempo, tendrá un documento de diseño que describe lo que tiene hasta ahora para que otros puedan continuar su trabajo

• No es mucho trabajo extra de esta manera

• A medida que avanza su proyecto, es posible que no esté muy seguro de por qué usted mismo hizo algo así hace dos meses, y tendrá sus notas para contarle.

Documento de diseño del sistema, un registro de requisitos básicos más actualizaciones (nuevas características) a medida que el proyecto avanza con nuevos atributos de diseño y solución. Mantenido hasta que se entregue el proyecto / solución. Útil, se comunica a todos los interesados.