Diferencia entre revisiones de «Diseño De Software»
(→Ver también) |
|||
| (No se muestran 4 ediciones intermedias de 4 usuarios) | |||
| Línea 25: | Línea 25: | ||
Esto último me parece importante destacar para no confudir: el rol del diseñador y desarrollador son distintos, y tienen responsabilidades distintas. Muchas veces tenemos la suerte de poder cumplir ambos roles (es decir, quienes diseñan algunas de las soluciones muchas veces participan luego directamente en la programación). Pero esta "dualidad" de roles no debe confundir las responsabilidades distintas que tienen. Al momento de diseño se deberá pensar que es otra persona quien deba entender nuestras ideas. Y como desarrolladores, debemos pedir (exigir!) diseños claros que nos ayuden y faciliten la tarea. | Esto último me parece importante destacar para no confudir: el rol del diseñador y desarrollador son distintos, y tienen responsabilidades distintas. Muchas veces tenemos la suerte de poder cumplir ambos roles (es decir, quienes diseñan algunas de las soluciones muchas veces participan luego directamente en la programación). Pero esta "dualidad" de roles no debe confundir las responsabilidades distintas que tienen. Al momento de diseño se deberá pensar que es otra persona quien deba entender nuestras ideas. Y como desarrolladores, debemos pedir (exigir!) diseños claros que nos ayuden y faciliten la tarea. | ||
| − | == | + | ==Por qué diseñamos== |
El objetivo del diseño es doble: construir aplicaciones en menor tiempo y con mayor calidad. | El objetivo del diseño es doble: construir aplicaciones en menor tiempo y con mayor calidad. | ||
| Línea 42: | Línea 42: | ||
== Ver también == | == Ver también == | ||
| + | * [[Diseño Por Contrato]] | ||
* [[Patrones De Diseño]] | * [[Patrones De Diseño]] | ||
| − | * [[ | + | * [[Interfaces De Usuario]] |
* [[UML]] | * [[UML]] | ||
| + | * [[DSL]] | ||
| + | |||
| + | [[Category: Diseño De Software]] | ||
Revisión actual del 15:10 26 abr 2011
El diseño de software es la tarea de representar en un lenguaje gráfico (usualmente UML) la solución de una problemática.
Contenido
¿Qué es el diseño?
Supongo que todos, de una manera u otra, tenemos una idea de qué es diseñar: incluso quien menos cerca se encuentre de esta tarea sabe que, mínimamente, consiste en crear "cajitas con texto y muchas lineas" en alguna herramienta (electrónica o papel... muchos, me incluyo, empezamos sintiéndonos más cómodos con esta segunda opción; y es que a veces hasta resulta más facil pensar con un lapiz que con un mouse).
Pero más allá de las ideas y sensaciones que puedan tener internamente, el diseño es una actividad básicamente creativa: es pensar de cero cómo se resolverá un problema. Es crear, de manera aún más abstracta que en la programación, una solución intangible a un problema.
Y el diseñador es...
El diseñador será entonces, obviamente, la persona de comprender el problema e idear la mejor solución al mismo para que pueda ser resuelto por otras personas. El diseñador no resuelve el problema directamente, es decir, no se encarga de programarlo: le brinda a los desarrolladores la visión que tiene para una mejor solución de la situación.
Para poder comunicar su visión deberá, entonces, utilizar alguna herramienta para plasmar sus ideas (en la mente) en algo visible por personas que no posean poderes psíquicos. Actualmente, dicha herramienta se llama UML, y es un lenguaje visual que, con diagramas y notas, permite mostrar cómo un problema debe ser resuelto.
Pero el diseñador no es...
El diseñador no es el analista del problema: no puede suponer situaciones que no están explícitas en el caso de uso, ni es el experto en el área que tiene que resolver. Todas las dudas que tenga sobre el problema las deberá aclarar con el correspondiente analista, ya que él por si mismo no cuenta con los elementos necesarios para presuponer (adivinar) situaciones que le resulten confusas.
El diseñador tampoco es desarrollador... y esto, en nuestro ámbito, suele "doler" un poco. El diseñador se encuentra muy cerca del código y debe conocer la plataforma y arquitectura donde se implementará su solución (puede construir los castillos de arena que considere necesario... pero siempre dentro de un arenero que él mismo no construyó). Pero si bien conoce del código y lenguaje de implementación, insisto, el diseñador no es quien programará la solución.
Un buen diseñador debe conocer íntegramente la solución que quiere, y saber cómo quiere que se implemente en el lenguaje de turno. Por eso, personalmente pienso que un buen diseñador es, ante todo, un buen programador.
Yo diseño, tu programas; yo programo, tu diseñas
Esto último me parece importante destacar para no confudir: el rol del diseñador y desarrollador son distintos, y tienen responsabilidades distintas. Muchas veces tenemos la suerte de poder cumplir ambos roles (es decir, quienes diseñan algunas de las soluciones muchas veces participan luego directamente en la programación). Pero esta "dualidad" de roles no debe confundir las responsabilidades distintas que tienen. Al momento de diseño se deberá pensar que es otra persona quien deba entender nuestras ideas. Y como desarrolladores, debemos pedir (exigir!) diseños claros que nos ayuden y faciliten la tarea.
Por qué diseñamos
El objetivo del diseño es doble: construir aplicaciones en menor tiempo y con mayor calidad.
Pensar que se pierde tiempo diseñando es tener una visión muy pobre sobre la realidad: no se pierde tiempo en diseño, sino que se gana en construcción.
Un buen diseño permite crear sistemas de mayor calidad, mantenibles y escalables: nos permitirá programar aplicaciones más fáciles de entender por personas no involucradas, que sean flexibles para que puedan adaptarse a los cambios del negocio rápidamente. Esto permitirá que la aplicación pueda evolucionar junto al negocio con el menor esfuerzo posible.
Los problemas que aparecen al evitar (o escatimar) con la etapa de diseño son ampliamente conocidos y pueden leerse en varios libros, foros y notas. Y, obviamente como suele siempre pasar, a veces preferimos la "experiencia de primera mano"... cosa que también tenemos para contar. Tuvimos ya experiencias con proyectos donde la etapa de diseño fue, por diversos motivos, "relegada"... y sufrimos, a continuación, los problemas que todo librito avisa que siguen.
Aprendamos entonces de experiencias pasadas, evitando pegarnos repetidas veces contra la misma pared. Recordemos que el tiempo por si mismo no brinda experiencia, sino tan solo situaciones. Es nuestra capacidad de aprender de estas situaciones lo que lleva a la experiencia y nos enriquece como profesionales.
El resultado de nuestro trabajo
Evidentemente, los sistemas que creamos son la cara visible de nuestro equipo y el resultado de nuestro trabajo; es la manera y el producto por el cual nos conocen. Crear soluciones de calidad habla bien de nosotros como equipo; debemos apuntar constantemente a mejorarnos, utilizando las herramientas existentes para ayudarnos en este proceso de aprendizaje y superación constante.
