lunes, 20 de mayo de 2013

4.1 Estrategias de diseño




4.1 Estrategias de diseño.


El modelo de diseño es un refinamiento y formalización adicional del modelo del análisis, donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo de diseño son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. El modelo de diseño se basa en el diseño por responsabilidades.

  •  Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficiente formal para alcanzar el código fuente. Por tal motivo se refinan los objetos, incluyendo las operaciones y atributos. Además se debe considerar aspectos como, los requisitos del rendimiento, tiempo real, concurrencia, lenguaje de programación, manejo de base de datos, etc. 

  • Otro objetivo del diseño es validar los resultados de los modelos de requisitos y análisis. Durante el diseño, se ve si los resultados anteriores son apropiados para la implementación. Si se descubren aspectos que no están claros en algunos de los modelos anteriores, estos se aclaran, posiblemente regresando a etapas anteriores.

  • El modelo del diseño se considera como una formalización del espacio del análisis extendiéndolo para incluir una dimensión adicional que corresponde al ambiente del implementación.


Esta nueva dimensión, corresponde al ambiente de implementación, se considera al mismo tiempo que se refina el modelo. La meta es refinarlo hasta que sea fácil escribir el código fuente. Como el modelo del análisis define la arquitectura general del sistema, se busca obtener una arquitectura detallada como resultado del modelo de diseño, de manera que haya una continuidad de refinamiento entre los dos modelos.

Un proyecto de diseño para tener un buen desarrollo debe tener una estructura en cuanto a la organización de cómo se va a llevar a cabo. Este desarrollo se va dividiendo en etapas lo que va a constituir la estructura. Entre esas etapas se encuentran:

Briefing, consiste en el primer contacto con el cliente para saber qué es lo que desea del proyecto, cuales son sus expectativas, el ‘cómo’ porqué’ ‘cuanto’. Por lo tanto, se logra conocer al cliente y sus requerimientos y hacia donde va dirigido o donde se quiere enfocar. Esto va a constituir un documento escrito donde se especifique qué es lo que quiere el cliente para saber qué es, específicamente, lo que hay que hacer. Es importante dejar claro todo para que después no haya ninguna confusión de lo que se hizo y lo que no se hizo o lo que se dijo o no se dijo.


Tabla Gantt o diagrama gantt,es más bien una organización de cómo se va a trabajar en el proyecto. Por lo tanto, se van asignando tareas las cuales dependen del tiempo. Además, el tiempo debe ser pagado, así que se definen las horas hombre, lo que dice del costo de la utilidad. 


Benchmark, teniendo en cuenta lo que el cliente quiere, visto en el brief, se van analizando los otros mercados, la competencia y se comparan. ¿Qué falta? Sin embargo, la idea no es copiarle a los otros, sino que dependiendo del cliente, estar a la altura de los demás o sobrepasarlos, pero para eso se debe tomar en cuenta qué recursos tienen que los hacen más populares.


Entrevista a los usuarios, principalmente, el usuario es a quien va dirigido el diseño por lo que es necesario saber lo que él piensa y sus expectativas, críticas, opiniones más que nada.


Modelos mentales y test, además de saber lo que piensa, es necesario saber cómo piensa, cómo estructura la información. Para eso hay varios test, donde se pone en juego distintas cosas como:

  • la facilidad de encontrar las cosas, como links, información
  • que es lo primero que notan los usuarios al entrar en un sitio web

4.2 Diseño de objetos.





4.2 Diseño de objetos.
 
Para los sistemas  es posible definir un diseño en pirámide con las siguientes cuatro capas: 
  • Subsistema. Contiene una representación de cada uno de los subsistemas que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica que los soporta. 
  • Clases y Objetos. Contiene las jerarquías de clases que permiten crear el sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. También contiene representaciones de diseño para cada objeto. 
  • Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus colaboradores. Establece las interfaces externas e internas para el sistema.   
  • Responsabilidades. Contiene las estructuras de datos y el diseño algorítmico para todos los atributos y operaciones de cada objeto.
 Todo el programa está construido en base a diferentes componentes (Objetos), todo objeto del mundo real tiene 2 componentes: características y comportamiento.
Una clase es una plantilla genérica para un conjunto de objetos de similares características.
La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias subclases.

Por ejemplo:
Los mensajes son invocaciones a los métodos de los objetos.
esta es una técnica de diseño, la cual se caracteriza por la determinación y delegación de responsabilidades. 

Análisis orientado a objetos
El modelo del análisis orientado a objetos ilustra información, funcionamiento y comportamiento.
El diseño orientado a objetos transforma el modelo del análisis en un modelo de diseño que sirve como anteproyecto para la construcción de software.

Modelos del diseño
  • Estáticos. Estructura de subsistemas y/o clases y sus relaciones.
  • Dinámicos. Se describen las estructuras que muestran la interacción entre objetos. Ejemplos de UML: diagramas de secuencia, diagramas de estado.
Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.
Tipos: de creación, estructurales, de comportamiento.

4.3 Diseño de Sistemas.


4.3 Diseño de Sistemas.

 Diseño: El diseño es el proceso creativo de transformación del problema en una solución.

La solución será la que satisface  todos los requerimientos planteados en la especificación de requerimientos, en muchos casos son ilimitadas.



Para transformar los requerimientos en un sistema que funcione, los diseñadores deben satisfacer tanto a los clientes como a los constructores de sistemas.

Los clientes deben comprender lo que el sistema debe hacer, y los constructores deben comprender cómo debe operar el sistema.

El diseño es un proceso iterativo que consta de dos partes: Diseño conceptual o del sistema, Diseño técnico.


Diseño Conceptual o del Sistema:

Se realiza primero, y le dice al cliente que es lo que hará realmente el sistema.

Una vez que se aprueba este diseño, se vuelca el trabajo a un trabajo de diseño más detallado.

El diseño conceptual describe el sistema en un lenguaje que el cliente pueda comprender, en lugar de usar términos técnicos o jergas de computación.

Un buen diseño conceptual debería tener las siguientes características:

          Se escribe en el lenguaje del cliente.

          No contiene expresiones de jerga técnica.

          Describe claramente las funciones del sistema.

          Es independiente de la implementación.

Esta vinculado con los documentos del requerimiento.             
 

Diseño Técnico:

Permite que los constructores comprendan el hardware y el software concretos que se necesitan para resolver el problema del cliente.

Es decir este diseño describe:

          La configuración de hardware.

          Las necesidades de software.

          Las interfaces de comunicación.

          Las entradas y salidas del sistema.

          La arquitectura de red.

          Y cualquier otro aspecto que incida en la transformación de los requerimientos en una solución.

          El diseño se describe en un único documento, pero muchas veces se vuelca en dos.


Ejemplo de Diseño Conceptual y Técnico:

4.4 Revisión del diseño.



4.4 Revisión del diseño.

El proceso de revisión se realiza en tres etapas en correspondencia con los pasos del proceso de diseño:

    1. Revisión del diseño preliminar.
    2. Revisión crítica del diseño.
    3. Revisión del diseño de programas.

Revisión del diseño preliminar:

Los clientes y usuarios se reúnen para validar el diseño conceptual.

Se asegura que todos los aspecto relativos a los requerimientos han sido apropiadamente contemplados en el diseño.

Se invita a participar a ciertas personas claves:

          Cliente (s), quien ayuda a definir los req. del sistema.

          Analista (s), quien colabora para definir los req. del sistema

          Usuario (s), potenciales del sistema.

          Diseñador (es) del sistema.

          Un moderador (solo coordina), un secretario (no se involucra).

          Otros desarrolladores (entregan perspectiva externa)

Durante la revisión se presenta a la audiencia el diseño conceptual. Al hacerlo, se demuestra que el sistema tiene la estructura requerida, las funciones y las características especificadas por los documentos de análisis.

Todos los participantes, en conjunto, verifican que el diseño propuesto incluya el hardware necesario, interfaces con otros sistemas, entradas y salidas.

Los clientes aprueban los diálogos y menús, los formatos de los informes y el tratamiento de defectos propuestos.


Revisión crítica del diseño:

Realiza una revisión crítica del diseño, donde se presenta una vista general del diseño técnico.

Integrantes:

           Analista (s), quien colabora para definir los req. del sistema.

           Diseñador (es) del sistema.

           Un moderador (solo coordina), un secretario (no se involucra).

           Diseñador (es) de programas para este proyecto.

           Probador del sistema.

           Analista que escribirá la documentación del sistema.

           Otros desarrolladores (entregan perspectiva externa).

La revisión trata de aspectos técnicos.

El moderador conduce la reunión para que se traten dos puntos: si el diseño implementa todos los requerimientos y si es un diseño de calidad, usando diagramas, datos o ambas cosas, se explican las estrategias de diseño alternativa y como y porque se han tomado las principales decisiones de diseño, Si se identifican problemas mayores el diseño se rehace.


Revisión del diseño de programas:

Cuando el diseño técnico resulta satisfactorio, los diseñadores de programas estarán en posición de interpretarlo como el conjunto  de descripciones de diseño para los componentes reales, que deben ser codificados y probados.

Después de completar los diseños de programas, pero antes de comenzar la codificación, presentan sus planes.

Integrantes:

           Analista (s), que produjeran los req. del sistema.

           Diseñador (es) del sistema.

           Diseñador (es) del programa.

           Un moderador (solo coordina), un secretario (no se involucra).

           Diseñador (es) de programas para este proyecto.

           Probador del sistema.

           Analista que escribirá la documentación del sistema.

           Otros desarrolladores (entregan perspectiva externa).



Este proceso se centra en la detección de defectos más que en su corrección. Además se esta evaluando el diseño no a los diseñadores.

El proceso beneficia a todos al encontrar defectos y problemas cuando aún son fáciles y poco costosos de corregir.