¿Es posible el desarrollo de documentación iterativa, y entrega documentación efectiva?

Tengo un proyecto para la universidad que no comenzaré de inmediato, pero he estado pensando durante un período de tiempo razonablemente largo. Entiendo que el desarrollo de proyectos universitarios no es como la industria (actualmente soy un interno), por lo que la situación que señalaré en este momento probablemente parezca algo ridícula para los desarrolladores de software reales. ^^ '

El proyecto en sí mismo requiere que documentemos mucho de nuestro trabajo. Entonces, además de entregar el código, que cuenta para algunas de las marcas, tenemos que entregar documentos que incluyen:

Un documento de análisis de requisitos
Un plan de proyecto
Una lista planificada de casos de uso, objetos y modelos dinámicos y pruebas de aceptación
Documentación del proceso de prueba y el éxito de las pruebas.
Algunas otras discusiones y análisis del uso del tiempo, etc.

Estos entregables se entregarán de la siguiente manera:

RAD primero
Seguido por el plan del proyecto, casos de uso, modelos y pruebas (aproximadamente 3 semanas después)
Por último, la documentación del programa real, el proceso de prueba, etc. + la programación real en sí (aproximadamente 5 semanas después)

Entonces, por lo que entiendo, esto realmente está orientado hacia un enfoque de estilo Cascada para el proyecto. El único problema (en mi opinión) es que este es un proyecto universitario, y los estudiantes ya tienen suficiente presión como para tratar de desarrollar proyectos al final del semestre durante la semana del proyecto. Realmente no quiero estar codificando / desarrollando / probando todo al final del semestre, cuando entraré en pánico con las muchas otras evaluaciones con las que tengo que lidiar.

Al menos me gustaría intentar y hacer algún tipo de ciclo de desarrollo iterativo que significa que podemos comenzar a codificar / crear prototipos temprano, tener un ciclo de desarrollo continuo que no se centre en hacer todo en el último minuto y no tener tanta presión en Al final del semestre para terminar este proyecto. Y ahora viene mi pregunta real:

¿Puedo conciliar de alguna manera tener que entregar toda esa documentación con un ciclo de desarrollo rápido, iterativo / creación de prototipos?
¿Existen estrategias para generar documentación de manera iterativa?
¿Estoy siendo completamente irrazonable preguntando esto y esperando que sea factible en la Universidad?

Además, entiendo que esta pregunta está extremadamente localizada, por lo que me gustaría hacer las mismas preguntas que hice anteriormente en términos de industria, y si muchos de estos problemas que enfrentan los procesos ágiles son diferentes para cada equipo o empresa

De todos modos, perdón por cuánto tiempo es esto, y si has terminado de leer hasta el final, ¡gracias! Si pudieras tomarte el tiempo de responder, te lo agradecería mucho. ¡Gracias!

documentation iterative-development

— blahman
fuente

Esto no responde, así que no lo estoy poniendo como respuesta. Pero no lo hagas . Parte de lo que su instructor quiere es que organice su pensamiento y desarrolle su capacidad para planificar y discutir un sistema que aún no ha escrito. Esas son habilidades muy buenas para tener, y altamente comercializables una vez que haya pasado unos años en el negocio de la programación.

— Ross Patterson

Ah, vale. Sin embargo, si puedo preguntar, parece que algunos métodos de planificación para obtener requisitos y conceptualizar las soluciones del cliente implican la creación de prototipos de un posible producto. ¿Es esta una buena manera de ayudar a evolucionar o ayudar a la etapa de planificación y documentación? ¿O es solo un deseo irracional?

— blahman

Claro, la creación de prototipos es válida. De hecho, en una empresa grande, puede encontrarse construyendo un prototipo para justificar la I + D capitalizada (es una cuestión contable, no técnica), incluso si no tiene intención de utilizar el prototipo como base para el sistema final. De hecho, los mejores prototipos son aquellos que brindan orientación y que luego se descartan. Si tuviera un centavo por cada prototipo "productizado" que necesitara una reescritura total un par de años después, tendría muchos centavos.

— Ross Patterson

La principal preocupación (tengo un problema similar con mi trabajo) es que si "El Proceso" exige que entregues ciertos artefactos en ciertos momentos, y nadie puede desafiar al todopoderoso "El Proceso", entonces si lo intentas, se perderá! No es solo una simple cuestión de que sea una mejor manera (¿Qué es el desarrollo iterativo de documentos?).

Entonces, lo que debe hacer es trabajar dentro del proceso, pero también encontrar la manera de trabajar de la manera que desee. Por ejemplo, ¿su proceso permite la modificación del documento una vez enviado? Si no, entonces no es posible el desarrollo iterativo. Si es así, debe pensar en el costo de la entrega (en términos de su tiempo, su credibilidad, etc.) y administrar ese costo. Si, por ejemplo, es una copia de un archivo y nada más, entonces hazlo. Si (como yo) es una revisión por pares, publicación de revisión, impacta a docenas de personas y cuesta miles de dólares, entonces piense cuidadosamente y asegúrese de que el nuevo documento realmente agregue valor.

Una forma común de trabajar es un documento básico esencial, mínimo, que satisface las necesidades de "El proceso" al principio, seguido más tarde por una actualización final "tal como está construida" que no solo refleja la realidad, sino que tiene los detalles donde sea necesario y está breve donde el código habla por sí mismo.

— Mattnz
fuente

¡Gracias por tu contribución! He pensado un poco más sobre lo que dijiste y cómo puedo aplicarlo a mis propios proyectos. Con mucha de nuestra documentación, se supone que debemos tener un cliente para consultar, a pesar de que tenemos que presentarlo antes de la fecha límite y no hacer modificaciones significativas después de eso. Sin embargo, ¿aún es posible el desarrollo iterativo por consulta del cliente? Quiero decir, ese es el punto de desarrollar en ciclos, ¿verdad?

— blahman