Pre Proyecto de Documentación

Question

tengo un problema que me siento muchos programadores pueden relacionarse con ...

He trabajado en muchos proyectos de pequeña escala. Después de mi tormenta cerebral de papel inicial, tiendo a comenzar a codificar. Lo que se me ocurre suele ser un modelo de trabajo aproximado de la aplicación real. Diseño de manera desconectada, así que estoy hablando de bibliotecas de códigos subyacentes, las interfaces de usuario son lo último, ya que la biblioteca suele dictar lo que se necesita en la interfaz de usuario. A medida que mis proyectos crecen, me preocupa que también lo haga mi "especificación" o documento de diseño.

El párrafo anterior, de mis investigaciones, se repite a través de Internet de una manera u otra. Cuando se trata de una UI, hay un poco más de información, pero es específica de la interfaz de usuario y no se relaciona con las bibliotecas de códigos. Lo que estoy empezando a darme cuenta es que tal vez el código es código es código. Según mi amplia investigación, parece que no existe una correspondencia 1: 1 entre un documento de diseño y el código.

Cuando necesito investigar un tema que volcar información en OneNote y desde allí priorizo ​​características en las diferentes versiones y luego en trozos relacionados para que el desarrollo funciona de una manera bastante lineal, mis tareas tienden a verse así:

1. Implementar lector de ficheros binarios
2. Implementar Binary File Writer
3. Crear objeto de encapsular los datos para la expresión de la persona que llama

N Cualquier programador que se precie es consciente de que entre esos tres elementos podría haber un posible muro de código que podría expandirse a varios archivos. He tratado de mapear el proceso completo del código para cada tarea, pero simplemente no creo que se pueda hacer de manera efectiva. En el momento en que uno manipula el pseudo código, es esencialmente código de todos modos, por lo que se niega la inversión de tiempo.

Así que mi pregunta es la siguiente:

Estoy en lo cierto al suponer que la mejor documentación es el propio código. Todos estamos de acuerdo en que se necesita una visión general de alto nivel. ¿Qué tan alto debe ser esto? ¿Diseñas a nivel de declaración, clase o concepto? ¿Qué funciona para ti?

Answer 1

Al final he encontrado que hay algunas maneras de acercarse a este, desde mapas mentales a diagramas de conceptos e incluso UML/Código del Pseudo. Al final, lo que mejor funciona para el individuo parece ser la mejor opción.

Answer 2

Recomiendo leer Code Complete 2 para obtener una idea excelente de este tipo de preguntas.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670

Answer 3

Creo que lo que quiere es una especificación de requisitos de software.

¡Codificar todas las cosas de manera caótica es un modo incorrecto de hacer el trabajo! Lo que necesita es crear una lista de requisitos funcionales/no funcionales para crear una relación vinculada/relacionada/hijo/padre con los requisitos de la interfaz de usuario y para el actor comercial crear un caso de uso.

Después de este paso, es necesario que administre finalmente toda la interfaz de diseño en UML o SPEUDO Code, pero cuando se formalicen los requisitos (para proyectos pequeños) la necesidad de tener UML se ejecutará.

Para la documentación del código puede usar doxygen o javadoc approch donde, en resumen, inserta comentario sobre el código y con un software todo el documento está en HTML/PDF.

Con esta forma se alcanzan en la secuencia de estas cosas:

1 - software de requisito
Ahora usted tiene la visión completa de lo que es su software y tal vez la funcionalidad que el software necesita con qué limitaciones (técnico/no -técnico/tiempo/negocios). Y también el caso del usuario para probar el software en la última etapa del ciclo de vida de desarrollo.

2 - UML o PSEUDO CÓDIGO
Una manera fácil de dividir su trabajo entre colegas y una descripción general simple del código de diseño de la interfaz.

3 - documentación de la biblioteca para otros programadores como usted y todos los beneficios de no desperdiciar coinciden con el tiempo para escribir todo el documento al final del proyecto.

mis 2 centavos.

Palabras clave google: ingeniería de software ciclo de vida de desarrollo de software doxygen, CMMI, IEEE SRS (especificación de requisitos de software).