4.1_ESTRATEGIA DE DISEÑO

 

ESTRATEGIA DE DISEÑO:
Los principales pasos del proceso de desarrollo son los siguientes:
• Análisis del problema: da como resultado un modelo de objeto y una lista de operaciones.
• Diseño: da como resultado un modelo de objeto de código, un diagrama de dependencia de módulos y especificaciones de módulos.
• Implementación: da como resultado un código ejecutable.

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

Arquitectura de la información: es una estudio bastante intenso de la disposición de la información. La manera en que la información se ordena es un paso fundamental para lo que es la producción. No es fácil pasar de muchas variables a una unidad que contenga todo, por eso, es importante saber de qué manera se dispone de todo lo que se tiene.

Wireframes: el wireframes ya constituye un prototipo de cómo se va a ver y la disposición de las cosas.

Diseño visual: está ligado con las imágenes, video, tipografía, recursos gráficos que se quiere utilizar en el sitio.

Diseño font: pasa a ser los códigos de programación que transcribe toda la información para ser usado en los sitios web, ya que la web usa otro lenguaje entonces, de esta manera, todo lo diseñado se logra ver en un sitio web.

Cita bibliográfica: 

http://magdalenanovoa.wordpress.com/2008/08/02/estrategia-de-diseno/

https://www.google.com.mx/search?q=temario+unidad+1+fundamentos+de+software&hl=es&tbo=d&ei=_oAiUcyjEoWG0QHa9IHwBg&start=20&sa=N&biw=1366&bih=704&cad=cbv&sei=-YwiUe3EIZLv0QHA7oHgCg 

http://es.scribd.com/doc/27182020/Ingenieria-de-Software-Un-Enfoque-Practico-6th-edicion-Roger-pressman-1

ALUMNO: ZEFERINO GUERRERO HERNANDEZ

SEMESTRE Y GRUPO: 4TO MOD_1

CARRERA: INGENIERÌA EN SISTEMAS COMPUTACIONALES

DOCENTE: M.C. MARIA GUADALUPE RIVERA GARCIA

4.2_DISEÑO DE OBJETOS

¿Qué es?
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.

Diseño orientado a objetos:
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.

Patrones del diseño:

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.

Métodos:

•El método de Booch: este método abarca un micro proceso de desarrollo y un macro proceso de desarrollo tanto para el análisis como para el diseño. El nivel micro define un conjunto de tareas de análisis que se reaplican en cada etapa en el macro proceso.
•El método de Rumbaugh: Este método mejor conocido como OMT, se utiliza para el análisis, diseño del sistema y diseño a nivel de objetos.
•El método de Jacobson: también llamado OOSE (que en español significa ingeniería del Software Orientada a Objetos este método, en el análisis, se diferencia de los otros por la importancia que da al caso de uso.

4.3_DISEÑO DE SISTEMA

Los Modelos del Diseño

El objetivo del diseñador es producir un modelo de una entidad que se construirá más

adelante. El proceso por el cual se desarrolla el modelo combina:

· la intuición y los criterios en base a la experiencia de construir entidades similares

· un conjunto de principios y/o heurísticas que guían la forma en la que se desarrolla el modelo

· un conjunto de criterios que permiten discernir sobre calidad

· un proceso de iteración que conduce finalmente a una representación del diseño final

Frecuentemente analista y diseñador son la misma persona, sin embargo es necesario

que se realice un cambio de enfoque mental al pasar de una etapa a la otra. Al abordar

la etapa de diseño, la persona debe quitarse el sombrero de analista y colocarse el

sombrero de diseñador.

“El diseño estructurado, tiende a transformar el desarrollo de software de una práctica

artesanal a una disciplina de ingeniería”.

· Eficiencia

· Mantenibilidad

· Modificabilidad

· Flexibilidad

· Generalidad

· Utilidad

¿Qué es el diseño?

El diseño es el proceso creativo de transformación del problema en una solución; la descripción de una solución también se denomina diseño.

La solución será la que satisface  todos los requerimientos planteados en la especificación de requerimientos.

Las soluciones en muchos casos son ilimitadas.

Existen dos tipos de diseño:

-Diseño Conceptual 

-Diseño del Sistema

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.

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.

Diseño Conceptual y Técnico

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

Cuando el diseño se completa se mantienen reuniones con los clientes para revisarlo antes de avanzar al desarrollo.

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.

Revisiones del diseño

Revisión del diseño preliminar

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

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)

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).

Revisión del diseño de programas

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).

4.5_DIAGRAMAS DE SENTENCIA DE DISEÑO

Diagramas  de sentencia de Diseño

Antes de entrar con los diagramas de diseño, hemos de efectuar algunas aclaraciones. 

En primer lugar, se omitirán los atributos y métodos de las clases derivadas de Form, ya que dichas 

clases se forman a partir de numerosísimos componentes del .NET Framework, y su presencia en estos 

diagramas los convertiría en inmanejables. 

En segundo lugar, las clases de la carpeta Librerías (StringTokenizer, Conversiones y Tiempo) se han 

omitido. Por ser utilizadas en casi todos los escenarios, su presencia entorpecería la finalidad de estos 

diagramas. Dichas clases serán descritas posteriormente en esta misma documentación. 

Por último, otras clases, que como en el caso de la carpeta Librerías, son utilizadas pero no son 

fundamentales para la comprensión del diseño, serán omitidas. Por ejemplo, todos las clases dedicadas a 

la interacción con la base de datos instancian un objeto Base, encargado de conectarse con la base de 

datos. Esta clase y otras, como se ya se ha dicho, serán omitidas en los diagramas.

Diagrama de Secuencia

 muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

4.6_HERRAMIENTAS CASE PARA EL DISEÑO

HERRAMIENTAS CASE

Concepto de las herramientas CASE

La herramienta CASE (Computer-Aided Systems Engineering ) cuyo significado en español es ingeniería de sistemas asistida por ordenador, es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo de sistemas y al igual que las herramientas CAD (Diseño Asistido por Computadora) o CAM (Manufactura  Asistida por Computadora) su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas. La primera herramienta CASE como hoy la conocemos fue Excelerator en 1984, era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT.

Tecnología de las herramientas CASE

 La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información. Para mejorar la calidad y la productividad de los sistemas de información a la hora de construir software se plantean los siguientes objetivos : 

• Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta conseguimos agilizar el trabajo.
• Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
• Simplificar el mantenimiento de los programas.
• Mejorar y estandarizar la documentación.
• Aumentar la portabilidad de las aplicaciones.
• Facilitar la reutilización de componentes software.
• Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos. 

Componentes de una herramienta CASE

De una forma esquemática podemos decir que una herramienta CASE se compone de los siguientes elementos:

• Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.
• Metamodelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta.
• Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas.
• Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.