¿Diseña/dibuja/dibuja primero una solución de desarrollo y luego la desarrolla? ¿Si es así, cómo?

Question

Trabajo mucho con personas que toman decisiones que buscan utilizar mejor la tecnología en sus negocios. He encontrado que una imagen vale más que mil palabras y la creación de prototipos de un sistema en un diagrama de algún tipo siempre presta mucho al debate. He utilizado Visio, UML (algo), Mapas mentales, Diagramas de flujo y Moered Up WinForms para comenzar la visión de estos patrocinadores para garantizar que todos estén en sintonía. Siempre busco que ese proceso común se pueda utilizar para unir la visión empresarial al proceso de desarrollo de modo que todos terminemos en el mismo extremo, "Algo funcional que resuelve un problema".

Estoy buscando sugerencias o notas de Cliff sobre cómo abordar el proceso de diseño de modo que funcione para aplicaciones que solo pueden tardar una semana en desarrollarse, pero que también pueden usarse para abarcar proyectos más grandes.

Sé que esto se adentra en el área de UML, pero he descubierto que me resulta difícil encontrar una guía para utilizar adecuadamente los distintos tipos de diagramas, y mucho menos ayudar a los usuarios comerciales a comprender los diagramas y relacionarlos.

¿Qué usa para capturar una visión de un sistema/aplicación para luego presentarla a los patrocinadores de un proyecto? (todo antes de escribir una sola línea de código) ...

Answer 1

¡Papel o pizarra blanca!

Para el deveoper solitario, recomendaría el papel. Al menos al principio, eventualmente querrás formalizarlo con UML, pero no creo que sea necesario.

Para un grupo de desarrolladores que trabajan juntos (físicamente), recomendaría una pizarra blanca. De esa manera, es visible para todos y todos pueden mejorar y contribuir. De nuevo, es posible que desee formalizar en este punto, pero aún no creo que sea necesario

Cuando comencé a hacer OOP por primera vez (o diseñando un algoritmo), lo hacía todo en mi mente mientras codificaba. Pero después de hacer algunos proyectos complejos razonables, definitivamente veo el beneficio en extraer las interacciones entre diferentes objetos en un sistema.

Realizo proyectos por mí mismo, así que utilizo muchas tarjetas de índice para diseñar clases y papel para sus interacciones. El punto es que debe ser fácil de cambiar. He jugado con Dia, un editor de diagramas, para hacer UML, pero hacer cambios es muy difícil. Quiero ser capaz de hacer cambios rápidos, para poder descubrir qué funciona mejor.

Vale la pena mencionar que TDD y los proyectos "spike" [1] también pueden ayudar al diseñar un sistema.

[1] De Programación Extrema aventuras en C#, página 8: "experiement"

"Spike" es un término de la programación extrema significado Usamos la palabra porque pensamos en un pico como experimento rápido, casi de fuerza bruta con el objetivo de aprender una sola cosa. Piense en deslizar una uña grande a través de una placa .

Answer 2

De Conceptual Blockbusting: A Guide To Better Ideas por James L.Adams:

bloques intelectual como resultado un ineficiente elección de tácticas mentales o una escasez de municiones intelectual. . . . 1. Resolver el problema usando un idioma incorrecto (verbal, matemática, visual) -. como para tratar de resolver un problema matemáticamente cuando puede más fácilmente llevarse a cabo visualmente

(pg 71, 3ª edición)

No hace falta decir que si eliges utilizar diagramas para capturar ideas que puedan captarse mejor con las matemáticas, es igualmente malo. El truco, por supuesto, es encontrar el lenguaje adecuado para expresar tanto el problema como la solución. Y, por supuesto, puede ser apropiado usar más de un idioma para expresar tanto el problema como la solución.

Mi punto es que usted está asumiendo que los diagramas son la mejor manera de hacerlo. No estoy seguro de que estaría dispuesto a hacer esa suposición. Puede obtener una mejor respuesta (y el cliente puede estar más contento con el resultado) a través de algún otro método de enmarcar requisitos y diseños propuestos.

Por cierto, Conceptual Blockbusting es una lectura muy recomendable.

Answer 3

Lectura en Kruchten's 4+1 Views.

Aquí hay una manera de proceder.

1. Recopile casos de uso en un diagrama de casos de uso. Esto mostrará actores y casos de uso. El diagrama no comienza con muchos detalles.

2. Priorice los casos de uso para centrarse en casos de uso de alto valor.

3. Escribir narrativas. Si lo desea, puede dibujar diagramas de actividades.

Lo anterior es completamente no técnico. UML impone algunas reglas sobre las formas que se utilizarán, pero aparte de eso, puede representar las cosas en la terminología del usuario final.

1. Puede hacer análisis de nombres, dibujando diagramas de clase para ilustrar las entidades y las relaciones. Al principio, estos estarán en la terminología del usuario. Sin contenido técnico geek.

2. Puede ampliar los diagramas de actividades o agregar diagramas de secuencia para mostrar el modelo de procesamiento. Esto comenzará con descripciones del procesamiento por parte del usuario final y no técnicas.

3. Puede recorrer los diagramas de clase y actividad para pasar del análisis al diseño. En algún momento, se habrá movido del análisis al modo de ingeniería. Los usuarios pueden no querer ver todas estas imágenes.

4. Puede dibujar diagramas de componentes para la vista de desarrollo y los diagramas de despliegue para la vista física. Estos también se repetirán a medida que su concepción del sistema se expanda y refine.

Answer 4

Al diseñar una aplicación (creo principalmente aplicaciones web, pero esto se aplica a otros), que suelen crear historias de usuario para determinar exactamente lo que realmente necesita el usuario final. Estos forman los típicos "requisitos comerciales".

Después de que las historias de los usuarios se definan, creo diagramas de flujo para diseñar las rutas que las personas tomarán al usar la aplicación.

Después de ese paso (que a veces recibe un proceso de aprobación) creo bocetos de interfaz (lápiz/lápiz & papel milimetrado) y comienzo el diseño de las bases de datos. Esto y el siguiente paso son, por lo general, el proceso que consume más tiempo.

El siguiente paso es tomar los bocetos y convertirlos en wireframes limpios. Yo uso OmniGraffle para este paso, está a años luz de Visio.

Después de esto, es posible que desee hacer diagramas UML típicos, u otros diseños de objetos/organización funcionalidad, pero los empresarios no van a cuidar mucho acerca de ese tipo de detalles :)

Answer 5

cuando estoy Al armar un diseño, me interesa transmitir las ideas de manera limpia y fácil a la audiencia. Esa audiencia está compuesta por (típicamente) personas diferentes con diferentes antecedentes. Lo que no quiero hacer es ingresar al "modo de enseñanza" para un modelo de diseño en particular. Si tengo que pasar un tiempo considerable para decirle a mi cliente qué significa la flecha con la cabeza sólida y cómo es diferente de la que es hueca o lo que significa un cuadrado versus un círculo, no estoy progresando, al menos no el progreso. Quiero.

Si es razonablemente informal, lo esbozaré en una pizarra o en un bloque de papel y flechas simples como máximo. El punto del diseño aproximado en este punto es asegurarse de que estamos en la misma página. Sin embargo, variará según el cliente.

Si es más formal, podría sacar una herramienta UML y armar algunos diagramas, pero la mayoría de mis clientes no escriben software y probablemente solo son marginalmente interesantes en las entrañas. Lo mantenemos en el nivel de "burbuja y línea" y podríamos armar algunas listas con viñetas donde se necesita una aclaración. Mi cliente no quiere ver diagramas de clase ni nada de eso, típicamente.

Si tenemos que mostrar alguna interacción de la GUI, voy a lanzar algunos prototipos de ventanas simples en Visual Studio, es rápido y fácil. Descubrí que el cliente puede relacionarse con eso con bastante facilidad.

En pocas palabras, produzco dibujos simples (en algún formato) que pueden comunicar el diseño a las partes interesadas y a los interesados. Me aseguro de saber lo que quiero que haga y, lo que es más importante, lo que ELLOS NECESITAN que haga, y hablar con eso. Por lo general, no se mete en las malas hierbas porque la gente se pierde allí y no creo que sea un buen momento para diagramar todo hasta el enésimo grado. En última instancia, si el cliente y yo (y todas las demás partes interesadas) estamos en la misma página después de hablar sobre el diseño, soy un tipo feliz.

Answer 6

Para tareas pequeñas o muy limitadas, creo que los desarrolladores casi universalmente están de acuerdo en que cualquier tipo de diagrama es un paso innecesario.

Sin embargo, cuando se trata de un sistema más grande y complicado, especialmente cuando dos o más procesos tienen que interactuar o se necesita lógica empresarial compleja, Process Activity Diagrams puede ser extremadamente útil. Usamos métodos ágiles bastante puros en el desarrollo y descubrimos que estos son casi el único tipo de diagramas que usamos. Es increíble lo mucho que puede optimizar un diseño de alto nivel con solo tener todas las piezas grandes frente a usted y conectarlas con líneas de flujo.No puedo dejar de insistir en lo importante que es adaptar el diagrama a su problema, y ​​no al revés, de modo que, aunque el enlace proporciona un buen punto de partida, simplemente agregue lo que tiene sentido para representar su sistema/problema.

En cuanto al almacenamiento, la pizarra puede ser ideal para una lluvia de ideas y cuando la idea todavía se está refinando, pero yo diría que una vez que la idea toma una forma bastante final, electrónica y wiki son mejores (OmniGraffle es el rey de diagramación si tienes la suerte de poder usar una Mac en el trabajo :). Tener un área en la que volcar todos estos diagramas puede ser extremadamente útil para que alguien nuevo obtenga una comprensión rápida de una pieza global del sistema sin tener que buscar el código. Además, dado que los diagramas de actividad representan bloques lógicos más grandes, no existe el problema de tener que mantenerlos siempre actualizados. Cuando realiza un gran cambio en un sistema, entonces sí, pero es probable que use el diagrama existente para planificar el cambio de todos modos.

Answer 7

El asesoramiento UML funciona bien si está trabajando en un gran proyecto de aversión al riesgo & con un montón de interesados ​​y con muchos contribuyentes. Incluso en esos proyectos, realmente ayuda desarrollar un prototipo para mostrar a los que toman las decisiones. Por lo general, recorrerlos a través de la interfaz de usuario y una historia de usuario típica es suficiente. Dicho esto, debe tener en cuenta que concentrarse en la IU para los responsables de la toma de decisiones tenderá a hacer que descuiden algunos aspectos importantes de los programas de fondo, como las validaciones, las reglas comerciales y la integridad de los datos. Tienden a escribir estos problemas como cuestiones "técnicas" en lugar de decisiones comerciales.

Si, por otro lado, está trabajando en un proyecto Agile donde es posible hacer cambios de código rápidamente (y deshacer errores rápidamente), puede hacer un prototipo evolutivo con todos los trabajos. La arquitectura de su aplicación debe ser flexible y lo suficientemente flexible como para soportar cambios rápidos (por ejemplo, patrón de diseño de objetos desnudos o MVC estilo Rails). Ayuda a tener una cultura de desarrollo que fomente la experimentación, y reconoce que BDUF no es un predictor de funcionamiento de software exitoso.

Answer 8

Soy un chico ágil, así que tiendo a no dedicar mucho tiempo a la diagramación. Ciertamente hay momentos en que dibujar algo en un tablero blanco o una servilleta ayudará a garantizar que usted comprenda un problema o requisito en particular, pero realmente nada es mejor que poner el software en funcionamiento frente a un cliente para que puedan ver cómo funciona. Si se encuentra en una situación en la que sus clientes aceptasen iteraciones frecuentes y demostraciones sobre el diseño inicial, digo que lo haga. Es incluso mejor si están bien para obtener retroalimentación temprana en forma de pruebas de unidad de paso o de integración (algo como Fit funciona bien aquí).

En general, no me gustan los prototipos, porque con demasiada frecuencia el prototipo se convierte en el producto final. Tuve la desgracia de trabajar en un proyecto que básicamente consistía en extender una oferta comercial que resultó ser una "prueba de concepto" que se empaquetó y vendió. El proyecto se canceló después de que se registraran más de 1000 defectos en la aplicación principal (sin contar las mejoras o personalizaciones en las que estábamos trabajando actualmente).

He intentado usar UML, y he descubierto que a menos que la persona que mira los diagramas comprenda UML, son de poca ayuda. Por lo general, las maquetas de pantalla no son una mala idea, pero solo muestran el lado de la aplicación que afecta directamente al usuario, por lo que no obtendrá mucho kilometraje por nada que no sea una presentación. Curiosamente, herramientas como el diseñador de Workflow en Visual Studio producen diagramas bastante claros que son fáciles de entender para los no desarrolladores, por lo que son una buena herramienta para generar flujo de trabajo de la aplicación principal, si su aplicación es lo suficientemente compleja como para beneficiarse de ella.

Aún así, de todos los enfoques que he usado a lo largo de los años, nada supera a un usuario que tiene algo en sus manos que le permite saber qué tan bien entiende el problema.

Answer 9

Sugiero leer los artículos de Joel sobre "Especificaciones funcionales sin dolor". La parte 1 se titula "Why Bother?".

Utilizamos Mockup Screens en el trabajo ("Prototipos de pantalla rápidos y fáciles"). Es fácil alterar las pantallas y las vistas dejan en claro que esto es solo un diseño.

Las maquetas se incluyen en un documento de Word que contiene la especificación.

Answer 10

4 + 1 vistas son buenas solo para técnicos. Y solo si están lo suficientemente interesados. ¿Recuerdas esas últimas doce veces que te costó discutir los diagramas de caso de uso con el cliente?

Lo único que encontré que funciona con todo el mundo es, de hecho, mostrarles las pantallas de su aplicación. Usted mismo dijo: una imagen vale más que mil palabras.

Curiosamente, hay dos enfoques que han trabajado para mí:

1. Presentar a los usuarios un completo manual del usuario (antes de que se inicie un desarrollo uniforme), O
2. Use maquetas que no se parece en nada a aplicación terminada: primero analiza las pantallas principales de tu aplicación. Cuando esté satisfecho, continúe discutiendo las maquetas, pero un escenario a la vez.

Para la opción (1) puede usar lo que quiera, en realidad no importa.

Para la opción (2), es completamente correcto comenzar con lápiz y papel. Pero pronto es mejor usar una herramienta maqueta especializada (tan pronto como sea necesario para editar, mantener o organizar sus maquetas)

terminé de escribir mi propia herramienta maqueta en 2005, se hizo muy popular: MockupScreens

Y aquí está la lista más completa de herramientas de maqueta que conozco. Muchos de ellos son gratuitos: http://c2.com/cgi/wiki?GuiPrototypingTools