El papel del diseno en la metodologia de desarrollo

De Uqbar wiki

El diseño cumple un rol fundamental en todos los desarrollos de software. Es entonces cuando tenemos que tomar decisiones que afectan directamente al producto que vamos a construir. Por supuesto, el qué del análisis vs. el cómo del diseño es una diferencia que aparece en todos los libros. Pero mientras en el qué del análisis las recomendaciones generales apuntan a ordenar, clasificar, separar

o bien, en encontrar los actores e identificar

o

en el diseño necesitamos echar mano a herramientas mucho más cercanas a la tecnología.

Qué es diseñar

Diseñar es encontrar:

Para eso tenemos que tomar decisiones, y aquí es donde empezamos a depender de la tecnología, porque ella nos define:

El diseño y la metodología

Si la metodología de trabajo es secuencial, cada fase del proyecto tiene un comienzo y un fin específico. El diseño debe respetar el orden que le corresponde: después del análisis y antes de la programación / construcción. Si la metodología de trabajo es iterativa, esto implica diseñar en diferentes momentos, sin acotarlo a un período determinado.

De la misma manera,

Diseño anticipado y diseño iterativo

La metodología de desarrollo nos lleva a diseñar de dos formas completamente diferentes:

Las metodologías predictivas proponen el diseño anticipado, donde se asume que

Por el contrario, las metodologías adaptativas proponen el diseño iterativo, donde se asume que

Análisis comparativo

Los defensores del diseño anticipado sostienen que en el diseño iterativo se pierde el orden, que es difícil de coordinar un proyecto (no se sabe exactamente en qué porcentaje está cumplida cada actividad), y que el diseño iterativo confunde diseño y programación, al punto en el que en realidad sólo se programa.

Los defensores del diseño iterativo creen en que todos los proyectos se construyen de esta manera, lo único que hacemos al utilizar esta metodología es reflejar lo que sucede en la realidad: los requerimientos cambian (aparecen nuevos, se modifican los existentes y algunos incluso desaparecen durante el proyecto), los diseñadores se equivocan, también lo hace el usuario y continuamente nos vemos obligados a adaptar nuestra planificación. Separar un proyecto en varias iteraciones facilita aceptar esos cambios, porque no se mantienen fijos los requerimientos ni los diseños, solamente mantenemos el plazo de entrega (lo que vamos a entregar está sujeto a cambios en cada iteración).

Pensar y hacer

Al hacer la comparación entre las metodologías orientadas al producto vs. las orientadas al proceso y al ver la enorme diferencia entre el diseño predictivo y el iterativo, se pone sobre la mesa una larga discusión: ¿es correcto asociar los tiempos de diseño y programación a los tiempos donde se piensa y donde finalmente se hace? ¿es tan taxativa la diferencia? ¿puedo abstraer los detalles técnicos para diseñar una solución? ¿debe ocurrir primero la documentación y después la construcción o son tareas que pueden solaparse? ¿es necesario contar con dos perfiles diferenciados, o sea, un analista funcional y otro programador? ¿no sería más sano tener un desarrollador senior con mayores capacidades de abstracción y otro con menos experiencia, que pueda formarse en la materia?

La metodología define la discusión filosófica de si nos interesan más las personas o los procesos. Asumir que el proceso tiene la prioridad presupone que sólo tengo recursos para asignar, y si divido perfiles en personas que piensan (diseñadores) de las que hacen o ejecutan (programadores) eso permite intercambiar gente sin mayores inconvenientes. Si pienso que las personas son importantes, que su grado de experiencia, la relación entre sí, la motivación personal y grupal, la capacidad de aprendizaje y la respuesta ante problemas que surgen son la clave de éxito de un proyecto, no nos interesa hacer la distinción entre pensar y hacer, porque esto ocurre todo el tiempo en forma simultánea, y mientras menos quiera disociar estos eventos (pensar y hacer) menos complicaciones tengo para encontrar un diseñador que sólo diseñe y un programador que sólo programe. Además el programador se transforma en una persona crítica del diseño, diseño que entonces puede mejorarse (es una metodología menos rígida en este sentido).

Integración de las actividades de diseño en el proceso de desarrollo

¿Qué actividades ocurren al diseñar?

Mientras que las metodologías secuenciales ven que el análisis condiciona el diseño y éste a su vez define las decisiones de implementación, es interesante notar que en los casos que mencionamos arriba es al revés: la arquitectura (o más general, las cuestiones técnicas) impactan sobre el diseño y el diseño puede hacer variar lo relevado en el análisis. De hecho, este es el valor agregado de un buen diseñador: hacer las preguntas que disparen mejoras en lo que el usuario pide.

Latest update on July 17, 2017 by GitHub