design - examples - ¿Qué artefactos esenciales de diseño produces?
artifacts gpu (6)
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, con partes de nuestra práctica bien definidas, la fase de diseño se ha pasado por alto en gran medida. Mejores prácticas, ¿alguien?
Código de trabajo ... y dibujos de pizarra.
:PAG
En nuestro modelo (que es bastante específico para las aplicaciones de procesos comerciales), 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 todas las modificaciones y crea desencadenantes en cada entidad, atributos calculados, validadores y otra lógica de negocios
- un conjunto de definiciones de pantalla (ver modelo)
Sin embargo, ¿estos realmente cuentan como artefactos de diseño? Nuestro marco de trabajo es tal que estas definiciones se utilizan para generar el código real del sistema, por lo que tal vez van 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.
Los diseños cambian tanto durante el desarrollo y después que la mayoría de mis documentos cuidadosamente diseñados se pudren en el control de la fuente y se vuelven casi un obstáculo más que 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 su forma de pensar mientras desarrolla algo, pero después de eso se necesita un esfuerzo hercúleo para mantenerlos adecuadamente mantenidos.
Capturo imágenes de pizarras blancas y guardo las imágenes JPEG en el control de fuente. Esos son algunos de mis mejores documentos de diseño!
Después de haber trabajado en muchos proyectos de cascada en el pasado y en muchos proyectos ágiles y ad hoc 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 / escala de tiempo / herramientas, etc.).
Para una ''aplicación empresarial'' genérica basada en servidor, me gustaría que el mínimo sea algo así:
- Un documento de diseño funcional detallado (también conocido como spec). En general, algo parecido a las especificaciones de ejemplo de Joel s '' WhatsTimeIsIt , aunque probablemente con algunos diagramas de caso de uso de UML.
- Un documento de diseño técnico de software. No necesariamente detallado para una cobertura del sistema del 100%, pero 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 a lo largo de las líneas de los diagramas de paquetes, diagramas de componentes, diagramas de clases de características clave y, probablemente, algunos diagramas de secuencia arrojados para una buena medida.
- Un documento de diseño de infraestructura. Probablemente con el diagrama de despliegue UML para la definición conceptual y tal vez 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 usted sabe que el equipo de soporte le dará a la aplicación el mismo cuidado y atención que 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á terminado , lo que plantea todo tipo de problemas interesantes, solo digo que debería ser posible si la administración lo desea.
Este no es un documento de diseño, per se, pero nuestras pruebas unitarias tienen el doble propósito de "describir" cómo se supone que el código que prueban debe funcionar. Lo bueno de esto es que nunca se desactualizan , ya que nuestras pruebas unitarias deben pasar para que nuestra construcción tenga éxito.
No creo que nada pueda reemplazar una buena especificación de diseño pasada de moda por las siguientes razones:
- Sirve como un medio para comunicar cómo creará una aplicación para otros.
- Te permite sacar ideas de la cabeza para que no te preocupes por rastrear un millón de cosas al mismo tiempo.
- Si tiene que pausar un proyecto y volver a él más tarde, no está comenzando nuevamente su proceso de pensamiento.
Me gusta ver varios bits de información en una especificación de diseño:
- Explicación general de su enfoque al desafío en cuestión
- ¿Cómo controlarás tu aplicación?
- ¿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, aunque son un elemento fantástico y posiblemente crítico para incluir en el desarrollo de su aplicación, no cubren todos estos temas.