¿Qué artefactos de diseño esenciales produce?[cerrado]

Question

En el transcurso de su ciclo de vida de desarrollo de software, ¿qué artefactos de diseño esenciales produce?¿Qué los hace esenciales para su práctica?

El proyecto en el que estoy actualmente ha estado en producción durante más de 8 años.Esta aplicación web se ha mejorado y mantenido activamente durante ese tiempo.Si bien contamos con políticas y procesos basados ​​en CMMI y partes de nuestra práctica están bien definidas, la fase de diseño se ha pasado por alto en gran medida.Mejores prácticas, ¿alguien?

Answer 1

Habiendo trabajado en muchos proyectos en cascada en el pasado y en muchos proyectos ad hoc y ágiles más recientemente, hay una serie de artefactos de diseño que me gusta crear, aunque no puedo decir lo suficiente que realmente depende de los detalles del proyecto ( metodología/estructura del equipo/plazo/herramientas, etc.).

Para una 'aplicación empresarial' genérica basada en servidor, me gustaría que lo mínimo fuera algo así:

• Un documento de diseño funcional detallado (también conocido como especificación).Generalmente algo parecido a lo de Joel Especificación de ejemplo de WhatsTimeIsIt, aunque probablemente con algunos diagramas de casos de uso UML.
• Un documento de diseño técnico de software.No necesariamente detallado para una cobertura del 100% del sistema, pero sí detallado en todas las áreas clave y que contiene todas las decisiones de diseño.Siendo un poco fanático de UML, sería bueno ver muchas imágenes como diagramas de paquetes, diagramas de componentes, diagramas de clases de características clave y probablemente algunos diagramas de secuencia incluidos, por si acaso.
• Un documento de diseño de infraestructura.Probablemente con un diagrama de implementación UML para el diseño conceptual y quizás un diagrama de red para algo más físico.

Cuando digo documento, cualquiera de los anteriores puede dividirse en varios documentos o tal vez almacenarse en una wiki/alguna otra herramienta.

En cuanto a su utilidad, mi filosofía siempre ha sido que un equipo de desarrollo siempre debería poder entregar una aplicación a un equipo de soporte sin tener que entregar sus números de teléfono.Si los artefactos de diseño no indican claramente qué hace la aplicación, cómo lo hace y dónde lo hace, entonces sabrá que el equipo de soporte le brindará a la aplicación el mismo cuidado y atención que le darían a un perro rabioso.

Debo mencionar que no estoy reivindicando la práctica de entregar software de un equipo de desarrollo a un equipo de soporte una vez que está finalizado, que plantea todo tipo de cuestiones interesantes, sólo digo que debería ser posible si la dirección así lo deseara.

Answer 2

Código de trabajo... y dibujos de pizarra.

:PAG

Answer 3

Los diseños cambian tanto durante el desarrollo y después que la mayoría de mis documentos cuidadosamente elaborados se pudren en el control de fuente y se convierten casi más en un obstáculo que en una ayuda, una vez que el código está en producción.Considero que los documentos de diseño son necesarios para una buena comunicación y para aclarar tu pensamiento mientras desarrollas algo, pero después de eso se necesita un esfuerzo hercúleo para mantenerlos en buen estado.

Tomo fotografías de pizarras y guardo los archivos JPEG en el control de fuente.¡Esos son algunos de mis mejores documentos de diseño!

Answer 4

En nuestro modelo (que es bastante específico para aplicaciones de procesos de negocio), los artefactos de diseño incluyen:

• un modelo de datos de dominio, con comentarios sobre cada entidad y atributo
• un archivo de propiedades que enumera todos los activadores de modificación y creación de cada entidad, atributos calculados, validadores y otra lógica empresarial
• un conjunto de definiciones de pantalla (ver modelo)

Sin embargo, ¿estos realmente cuentan como artefactos de diseño?Nuestro marco es tal que estas definiciones se utilizan para generar el código real del sistema, por lo que tal vez vayan más allá del diseño.

Pero el hecho de que cumplan una doble función es poderoso porque, por definición, están actualizados y sincronizados con el código en todo momento.

Answer 5

Este no es un documento de diseño per se, sino nuestro pruebas unitarias Tienen el doble propósito de "describir" cómo se supone que funciona el código que prueban.Lo bueno de esto es que ellos nunca te quedes desactualizado, ya que nuestras pruebas unitarias deben pasar para que nuestra compilación tenga éxito.

Answer 6

No creo que nada pueda reemplazar una buena especificación de diseño antigua por las siguientes razones:

• Sirve como un medio para comunicar a otros cómo creará una aplicación.
• Te permite sacar ideas de tu cabeza para que no te preocupes por rastrear un millón de cosas al mismo tiempo.
• Si tienes que pausar un proyecto y volver a él más tarde, no volverás a empezar tu proceso de pensamiento.

Me gusta ver varios fragmentos de información en una especificación de diseño:

• Explicación general de su enfoque ante el desafío en cuestión.
• ¿Cómo monitoreará su solicitud?
• ¿Cuáles son las preocupaciones de seguridad y cómo se abordan?
• Diagramas de flujo/diagramas de secuencia
• Problemas abiertos
• Limitaciones conocidas

Las pruebas unitarias, si bien son un elemento fantástico y posiblemente crítico para incluir en el desarrollo de su aplicación, no cubren todos estos temas.