¿Qué es el diseño detallado? ¿Cuáles son las ventajas desventajas al usarlo?

7

Realmente no entiendo la idea:

  1. ¿Qué es el diseño detallado?
  2. Por qué usar diseño detallado.
  3. Ventajas / Desventajas de usar el Diseño Detallado.
  4. Cualquier método alternativo que no sea el uso del Diseño Detallado.

¿Podría alguien por favor guiarme / explicarme?

    
pregunta Mafahir Fairoze 17.11.2010 - 14:06

3 respuestas

19

1) Cuando la mayoría de las personas hablan sobre el diseño detallado, se refieren a un proceso conocido como diseño de arriba hacia abajo. En resumen, cuando piensas en el problema que estás tratando de resolver, comienzas en el nivel más alto y luego trabajas en los detalles. Este enfoque funciona muy bien cuando tiene una estructura general en la que desea que viva su aplicación. En el nivel macro, está considerando cuántas máquinas serán necesarias para alojar su aplicación, qué servicios existentes necesitará usar, etc. A medida que profundice, verá casos de uso (o historias de usuarios si prefiere esa terminología) y manejo de errores (los casos de uso tienen tanto una ruta de condición normal como de error de la que preocuparse). A medida que avanza en los detalles, observa su algoritmo, las transiciones de estado, la secuencia lógica y cómo funcionan juntas las partes internas del código.

2) El enfoque clásico de arriba hacia abajo para el diseño detallado es lo que se enseña con la metodología de "cascada", guías de proceso IEEE, proveedores de UML, universidades y CMMI, entre otros. En muchos de estos procesos pesados te hacen escribir dos documentos de diseño. Uno es el diagrama arquitectónico general (el diseño de nivel superior). El otro es el diseño detallado donde vas más abajo en el agujero Rabit. En muchos casos, es el único enfoque para el diseño que mucha gente conoce. Es un enfoque muy lógico y metódico para resolver un problema de software.

3) La principal ventaja es que ha identificado cuáles serán las secciones críticas que probablemente serán. Si necesita comenzar a trabajar sobre cómo su software utilizará otro servicio existente, ha compilado su lista de puntos de integración. Podrías iniciar conversaciones con los propietarios de esos servicios para planificar tu integración y cómo manejar eventos inesperados.

La principal desventaja es que muchas veces la gente va demasiado lejos por el agujero de Rabit, y el documento de diseño cobra vida propia. Si bien es ventajoso tener una visión general y una arquitectura de cómo funcionará una aplicación, invariablemente encontrará que sus pensamientos iniciales sobre los detalles centrales fueron totalmente erróneos. Cuando eso sucede, se descuida el documento de diseño o hay equipos enteros que mantienen el trabajo y retrasan el progreso en el trabajo.

4) Ya he mencionado el diseño de arriba hacia abajo, así que sigue que debe haber un enfoque "de abajo hacia arriba", ¿verdad? Como resultado, hay. Esencialmente, el enfoque "de abajo hacia arriba" es el proceso de pensamiento central detrás de las metodologías de desarrollo impulsado por prueba y diseño continuo. Esencialmente, los detalles del código de trabajo comienzan a impulsar el diseño de cómo los trozos más grandes de código de trabajo cooperan e interactúan entre sí. Con TDD, tiene pruebas unitarias para asegurarse de que los detalles se comporten correctamente y seguir validando su diseño. El diseño continuo nos enseña que nunca conoceremos verdaderamente los detalles hasta que el software esté listo. Por lo tanto, ¿por qué tratar de combatir el hecho? En lugar de una gran etapa de diseño frontal, el diseño se construye en incrementos en varias iteraciones de diseño / código y pruebas. En realidad, es un concepto muy liberador que te permite concentrarte en resolver problemas.

En pocas palabras, no hay una respuesta perfecta. Para mí, encuentro que un buen equilibrio entre diseño de arriba hacia abajo y de abajo hacia arriba funciona bien. Esencialmente, todavía me tomo el tiempo para pensar en el panorama general. Incluso planeo un plan para los idiomas de la interfaz de usuario y mis mejores ideas para su diseño. Sin embargo, no entro en gran detalle porque sé que los detalles cambiarán. Básicamente, debe detener el proceso de arriba a abajo cuando llega a áreas de las que no está seguro. Una vez que llegue a esas áreas, comience con el enfoque de abajo hacia arriba. Esto le permite probar cosas diferentes, verificar con el cliente si tiene sentido para ellos y continuar mejorando con el tiempo.

    
respondido por el Berin Loritsch 17.11.2010 - 14:42
3

Un diseño detallado le permite evaluar las opciones de diseño antes de implementarlas . Puede potencialmente ahorrarle una tonelada de trabajo innecesario que de lo contrario habría gastado en una implementación que fue profundamente defectuosa debido a una opción de diseño de alto nivel y tuvo que ser reescrita extensamente.

    
respondido por el Kris 17.11.2010 - 14:30
-3

Cuando la mayoría de las personas hablan de diseño detallado, se refieren a un proceso conocido como diseño de arriba hacia abajo. En resumen, cuando piensas en el problema que estás tratando de resolver, comienzas en el nivel más alto y luego trabajas en los detalles. Este enfoque funciona muy bien cuando tiene una estructura general en la que desea que viva su aplicación. En el nivel macro, está considerando cuántas máquinas serán necesarias para alojar su aplicación, qué servicios existentes necesitará usar, etc. A medida que profundice, verá casos de uso (o historias de usuarios si prefiere esa terminología) y manejo de errores (los casos de uso tienen tanto una ruta de condición normal como de error de la que preocuparse). A medida que avanza en los detalles, observa su algoritmo, las transiciones de estado, la secuencia lógica y cómo las partes internas del código trabajan juntas

    
respondido por el vikash sharma 07.03.2013 - 08:30

Lea otras preguntas en las etiquetas