miércoles, 29 de mayo de 2013

3.6 HERRAMIENTA CASE PARA EL ANALISIS

3.6 HERRAMIENTA CASE PARA EL ANALISIS


1.            Borland Caliber Analyst

Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía Borland.

Por un lado está el Caliber DefineIT (la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como capturar los diferentes escenarios de negocio a través de diferentes herramientas visuales; es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.

Por el otro está Caliber RM que nos permite gestionar dichos requisitos durante el ciclo de vida del producto, si bien no ayudaba al usuario a visualizar los requerimientos y por lo tanto no resultaba tan efectiva como ellos demandaban.

El paquete que incluye ambas aplicaciones nos permitirá realizar las siguientes tareas: representar y especificar los escenarios de manera visual, permitiendo el uso de un lenguaje común; generar diagramas de casos de pruebas y UML, mejorando tanto la velocidad como la exactitud de la definición de los requisitos; rastrear los requisitos software durante el ciclo de vida del proyecto, respondiendo de manera rápida a cualquier cambio que se produzca.

La compañía Seilevel Inc., una de las más fuertes en cuanto a los servicios relacionados con los requisitos del software, ha seleccionado esta herramienta como la mejor de este tipo. Según palabras de un directivo de la compañía ven características únicas en esta herramienta así como una experiencia de usuario excelente y una oportunidad para mejorar el trabajo de sus clientes en cuanto al análisis y gestión de requisitos se refiere.

2.            CASE Spec

Esta herramienta está desarrollada por la empresa Goda Software, siendo esta una aplicación comercial de uso exclusivo para el sistema operativo Windows. Las principales características que avalan a esta herramienta son las siguientes:

Especificación: posibilidad de realizar las especificaciones tanto con las técnicas tradicionales como con los diagramas de casos de uso. Además, nos permite crear diagramas UML y de flujo de datos.

Seguimiento de los requisitos: a través del uso combinado de un procesador de textos y una hoja de cálculo, el usuario será capaz de realizar el seguimiento de los requisitos así como hacer un informe acerca de los mismos.

Capacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el proyecto.

Capacidad de importar y exportar archivos.

Generación automática de la documentación del proyecto así como posibilidad de realizar amplios informes.

3.            IRQA 4

Herramienta desarrollada por Visure y que tiene la meta de servir como aplicación para proporcionar un soporte integral en la ingeniería de requisitos de un proyecto de informática.

A parte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado, organización y seguimiento), esta aplicación dispones de las siguientes características:

Reutilización de requisitos: permite que los requisitos definidos en un proyecto puedan ser utilizados en otros proyectos realizados por la organización, a través del uso de librerías. De esta manera se consigue ofertar una pequeña ventaja a la hora de realizar líneas de productos.

Vista documental: esta nueva opción ofrece un agrupamiento de los requisitos que permite al usuario observar una diferenciación clara entre los mismos así como facilitar toda labor relacionada con estos.

Ingeniería de requisitos: además de la gestión de los requisitos, esta aplicación proporciona funcionalidades relacionadas con la ingeniería de requisitos, lo que permite centralizar en una sola herramienta todas las actividades relacionadas con los requisitos (incluyendo las pruebas de validación y aceptación).

Al ser esta una herramienta integrada, se ofrece al usuario la libertad de seleccionar aquellas otras aplicaciones más adecuadas para la realización de otras tareas relacionadas con el ciclo de vida de un proyecto, lo que hace que no se dependa de un solo proveedor de aplicaciones.

4.            Tiger Pro

Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que aparecen a la hora de definir los requisitos de un programa. También ayuda al usuario a aclarar algunos de los requerimientos desde el punto de vista de las pruebas a realizar, señalando aquellos requerimientos cuya verificación pueda resultar complicada.
La herramienta, que se va actualizando con el paso del tiempo, permite exportar el trabajo realizado en archivos bajo el formato CSV. Los usuarios que utilicen esta herramienta podrán trabajar en los requisitos tomando como referencia los siguientes conceptos: palabras claves relacionadas con el mismo (hasta 3 palabras para cada requisito), criterio de aceptación del requisito, seguimiento del mismo (tanto hacia la fuente como hacia otros lugares), prioridad del requerimiento, riesgo que trae consigo el requisito y coste del mismo. Además, a la hora de realizar los informes correspondientes, la herramienta nos proporcionará la opción de redactar los mismos en forma textual o bien nos presentará la información de forma gráfica.

5.            GatherSpace

A la hora de realizar la definición de los requisitos para un proyecto de informática, el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta herramienta de definición y gestión de requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar ningún programa para utilizarla: bastará con crear una cuenta en el sitio web de la misma y comenzar a definir el proyecto que se quiere desarrollar. De esta manera, la aplicación consigue que la colaboración de todos los miembros del grupo de desarrollo sea posible de una manera mucho más eficaz.

Las características más representativas de esta herramienta son las siguientes:

Creación de una jerarquía de requerimientos: permite crear paquetes funcionales para después relacionarlos con componentes de más alto nivel para después permitir asociar casos de uso más detallados y requisitos del software a dichos componentes.

Manipular varios proyectos al mismo tiempo, controlando el acceso de los usuarios para que estos puedan ver solo alguno de los proyectos.

Posibilidad de visualizar la documentación generada a partir de los requisitos en tres formatos diferentes: HTML, PDF y Microsoft Word.
Además de contar con todas estas opciones, la compañía ha dispuesto un buen sistema de seguridad que protegerá los datos introducidos en la herramienta. Para asegurar la integridad del trabajo realizado se realizan copias de seguridad diaria de la información introducida en la herramienta y además existe la posibilidad de encriptar los datos introducidos en la misma. También es necesario señalar que el usuario podrá descargarse la información desde el servidor de la empresa tantas veces como le sea necesario.

6.            IBM Rational RequisitePro

Esta herramienta, desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramientas más completas y potentes dentro del análisis y la gestión de los requisitos.

Una de las grandes ventajas que aporta este producto es la compatibilidad existente entre su software y algunos de los programas más utilizados. Por ejemplo, esta herramienta es capaz de comunicarse de manera muy eficiente con el Microsoft Word, de manera que la realización de los informes es más sencilla al tiempo que se ofrece al usuario una interfaz conocida para el desarrollo de su labor. Además de esta compatibilidad, el programa también se comunica con gran eficiencia con algunos de los sistemas de bases de datos más utilizados en el mundo de la informática (DB2 de IBM, Microsoft SQL Server, Microsoft Access y Oracle) de manera tal que se controla el acceso a los datos existentes en el sistema al tiempo que se tiene un repositorio central de datos.

Por si esto no fuera suficiente, la comunicación entre la base de datos utilizada y el Microsoft Word permite al usuario gestionar los requisitos desde la base de datos seleccionada al tiempo que estos se mantienen dentro de su contexto en el procesador de textos.

Al igual que la herramienta estudiada anteriormente, Racional RequisitePro ofrece la posibilidad de trabajar mediante acceso Web. De esta manera se logra tener tanto un acceso remoto como un acceso distribuido y además no se necesita que el software esté instalado en el cliente. También es necesario mencionar que la herramienta dispone de una matriz de seguimiento de los requisitos (al igual que la herramienta CASE Spec); en este caso, dicha matriz puede representarse tanto de forma gráfica como de forma textual. Además, en este caso se incorpora al seguimiento de los requisitos la existencia de un árbol de seguimiento global.

7.            RaQuest
Se trata de la herramienta de gestión de requisitos desarrollada por la empresa Sparx Systems, desarrolladora también de la herramienta de análisis y modelado Enterprise Architect, utilizada en la Escuela.

Las características principales de esta herramienta son las siguientes:

Definición y gestión de los elementos relacionados con los requisitos, entre los que se encuentran el tipo, el estado, la dificultad del requisito, las relaciones existentes entre diferentes requisitos, etc.

Creación de paquetes para gestionar de manera más sencilla y completa los requisitos.
Generación de documentación del proyecto (tanto parcial como total) en los siguientes formatos: HTML, CSV, Word, Excel, RTF
Además de estas características, la herramienta nos ofrece una serie de vistas diferentes, dependiendo de la vista que queramos obtener del proyecto. Estas vistas son: vista del tipo lista (permite ordenar los requisitos, mostrar diferentes listas, filtrar las listas en relación a diferentes palabras y buscar en el proyecto) y vista del tipo árbol (se pueden mostrar los árboles de proyecto y miembro así como mostrar los árboles por el tipo y por el estado).
Elección de la Herramienta a Utilizar
Debido a la gran compatibilidad existente con el Enterprise Architect, a la variedad de formatos para generar la documentación y a las numerosas opciones existentes en cuanto al tipo de vistas y la definición de los elementos relacionados con los requisitos, me he decantado por utilizar la herramienta RaQuest. 



3.5 DICCIONARIO DE CLASES SEGUN MODULOS

3.5 DICCIONARIO DE CLASES SEGUN MODULOS

Esta es la ultima estapa del modelo de analisis, en esta etapa se actualiza el diccionario de clases segun modulos, originalmente descrito en el dominio del problema, aunque no es necesario ordenarlos por relevancia, a cada clase y caso de uso se le pueden asignar modulos adicionales, que estos a su vez pueden tener otros modulos  o paquetes principales de importancia, estos ayudan a analisar de una mejor manera.

Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qué datos representan a la factura y al cheque. Los dos son términos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripción de flujos de datos, almacenes de datos o procesos.

fuente:
http://books.google.com.mx/books?id=MOviEp0ApQcC&pg=PA327&lpg=PA327&dq=diccionario+de+clases+segun+modulos&source=bl&ots=OWzNkgPuiy&sig=d2U43tOGBuuYN0VYW9_spn7xrG0&hl=es&sa=X&ei=T5V0UfjuEM-k2gWi9oC4Bg&ved=0CDUQ6AEwAQ 


3.4 DIAGRAMAS DE SECUENCIAS

3.4 DIAGRAMAS DE SECUENCIAS



El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso 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 pasados entre los objetos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "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 vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.


 Diagrama de Secuencia para un escenario
Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la case instanciada por el objeto en la recepción final del mensaje.

3.3 CLASES

3.3 CLASES


Los objetos se representan y agrupan en clases que son óptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la sección de un curso almacenan información similar para cada estudiante. Se podría decir que los estudiantes constituyen una clase. Los valores podrían ser diferentes para cada estudiante, pero el tipo
de información es el mismo. Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la clase establecida. El término instanciar se usa cuando un objeto se crea a partir de una clase. Por ejemplo, un programa podría instanciar a un estudiante llamado Peter Wellington como un objeto de la clase denominada estudiante.
Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y diseño orientado a objetos, diferente de la programación clásica, es la técnica de poner todos los atributos y métodos de un objeto en una estructura independiente, la propia clase. Ésta es una situación común en el mundo físico. Por ejemplo, un paquete con harina para pastel empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel. Un suéter de lana es similar a una clase porque incluye una etiqueta con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a
secar extendido. Cada clase debe tener un nombre que la distinga de todas las demás. Los nombres declase normalmente son sustantivos o frases cortas y empiezan con una letra mayúscula. En la figura 18.1 la clase se llama RentaAuto. En el UML, una clase se representa como un rectángulo. El rectángulo contiene otras dos características importantes: una lista de atributos y una serie de métodos. Estos elementos describen una clase, la unidad de análisis que es una parte principal de lo que llamamos análisis y diseño orientado a objetos. 

Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la clase RentaAuto posee los atributos tamaño, color, marca y modelo. Todos los automóviles poseen estos atributos, pero los atributos de cada automóvil tendrán diferentes valores. Por ejemplo, un automóvil puede ser azul, blanco o de algún otro color. Más adelante demostraremos que es posible serrnás específico acerca del rango de valores para estas propiedades. Al especificar atributos, normalmente la primera letra es minúscula. 

Un método es una acción que se puede solicitar a cualquier objeto de la clase. Losmétodos son los procesos que una clase sabe cómo realizar. Los métodos también se llaman operaciones. La clase RentaAuto podría tener los siguientes métodos: inicioRenta( ), entregaAutof ) y servicio( ). Al especificar métodos, normalmente la primera letra es minúscula.




Fuente: analisis de diseño y diseño de sistemas – kendall & kendall, pag 258- 259.

3.2 IDENTIFICACION DE CLASES SEGUN ESTEREOTIPOS

3.2 IDENTIFICACION DE CLASES SEGUN ESTEREOTIPOS


Para llevar a cabo la transicion del modelo de requisitos al modelo de analisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.
En general, los cambios mas comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo  a los objetos borde.
Los cambios a la funcionalidad son más dificiles de administrar, ya que ésta puede abarcar todos los tipos de objetos.
 bordes
Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a traves de ellso se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentacion comperensible para el actor.
Las clases borde en otras palabras , describen la comunicación bidireccional entre el sistema y los actores.
Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:
1.       Se pueden identificar con base a los actores.
2.       Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.
3.       Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.

·         Estrategia correspondiente a los actores.
Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.
 Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que  se hace en la clase entidad RegistroUsuario, utiliza también por el caso de uso RegistroUsuario.
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.
Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.
Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.
Hacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.
Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.
 Control
En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.




unidad 3.1 : MODELO DE ANÁLISIS

MODELO DE ANÁLISIS
El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.
Análisis de requisitos
El análisis de requisitos le proporciona al diseñador de software una representación de datos, función y comportamiento que puede trasladar a diseños arquitectónicos de interfaz. Este, junto al modelo de análisis, ofrece al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software.
Objetivos generales del modelo de análisis
El modelo de análisis debe cumplir tres objetivos primarios:
1.      Describir los que requiere el cliente
2.      Establecer una base para la creación de un diseño de software
3.      Definir un conjunto de requisitos que pueda validarse una vez construido el software.
http://mundokramer.wordpress.com/2011/05/20/modelo-de-analisis-software/

4.6 Herramientas para el diseño

4.6 Herramientas para el diseño
Son un conjunto de métodos, utilidades y técnicas que facilita la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguno de sus fases. El empleo de las HERMIENTAS CASE permite integrar el proceso de ciclo de vida.
v  Análisis de datos  y procesos integrados mediante un repositorio
v  Generación de interfaces entre el análisis y el diseño
v  Generación de código a partir del diseño
v  Control de mantenimiento
Actualmente, la tendencia en el desarrollo de software está enfocada hacia las microcomputadoras como plataforma de ingeniería de software, que se interconectan mediante redes para que puedan comunicarse de forma efectiva. La base de datos del proyecto, la arquitectura de entorno, compuesta por la plataforma hardware y el soporte del sistema operativo (incluida la red y la gestión de  la base de datos). Constituye la base del CASE, pero el entorno CASE en si mismo necesito otros componentes. Un conjunto de servicios de portabilidad constituye un puente entre las herramientas CASE y su marco de investigación en un conjunto de programas especializados que permite cada herramienta CASE comunicarse con las demás para crear una base de datos de proyectos y muestra una apariencia homogénea al usuario final (el ingeniero de software).
La principal ventaja de la utilización de una herramienta CASE es la mejora de la calidad de los desarrollos realizados y en segundo término, el aumento de la productividad. Para conseguir estos dos objetivos es conveniente contar con una organización y una metodología de trabajo además de la propia herramienta.
La mejora calidad se consigue reduciendo sustancialmente muchos de los problemas de análisis, inherentes a los proyectos de mediano y gran tamaño (lógica del coherente, consolidación).
La mejora productividad se consigue a través de la automatización de determinadas tareas como la generación de códigos y la reutilización de objetos o módulos.
Tipos de CASE
No existe una única clasificación de herramientas CASE  y en ocasiones, es difícil incluirlas en una clase determinada podrían clasificarse atendiendo a:
·         Las plataformas que soportan
·         Las fases de ciclo de vida del desarrollo de sistemas que cubren

·         La arquitectura de las aplicaciones que producen su funcionalidad. 
4.5 Diagramas de secuencia de diseño
El diagrama de secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores de sistema. Su creación forma parte de la investigación para conocer el sistema, se fluye dentro de la etapa del análisis.
En UML los diagramas de secuencia muestran gráficamente los eventos que pasan de los actores al sistema.
Actividades y dependencia
Los diagramas e secuencia de un sistema se preparan durante la fase del análisis, para su creación debemos formular antes los casos de uso.
Comportamiento del sistema
Antes de iniciar el diseño de cómo funcionara una aplicación de software, es necesario investigar y definir su comportamiento como “una caja negra”. El comportamiento del sistema es una descripción de lo que hace. Una parte de la descripción es un diagrama de secuencia del sistema
Diagrama de secuencia del sistema
Los casos de unos indican los actores interactúan con el sistema del software. Durante esa interacción un actor genera eventos dirigidos al sistema solicitando alguna operación a cambio conviene aísla, y explicar gráficamente las operaciones que un actor solicita al sistema, porque ello contribuye a entender el comportamiento del sistema.
En UML los diagramas de secuencia dan una descripción grafica de las integraciones del actor, y de las operaciones que los mismos originan. A todos los sistemas se los trata como “caja negra”, los diagramas se encuentran en los eventos que trascienden las fronteras del sistema y que fluyen desde los actores hacia los sistemas.
El diagrama de secuencia debe prepararse para el curso normal de los eventos de un caso de uso y los cursos opcionales más interesantes. DIAGRAMA DE SECUENCIA = Representación que muestra en un determinado caso de uso, los eventos generados por actores extremos, su orden y los eventos internos del sistema.




4.4 Revisión del diseño

4.4 Revisión del diseño
Según la IEEE 61012 una revisión es un proceso o reunión durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de un proceso se presenta al equipo de proyecto, a los administradores, usuarios, clientes u otra parte interesada para su comentario o aprobación.
La revisión del diseño de los productos de software se realiza por demanda con el objetivo de detectar e identificar no conformidades en el diseño antes de pasar a la codificación, así como también identificar aspectos de mejoramiento. Una recisión es una forma de aprovechar la diversidad de un grupo de personas.
ü  Señalar las necesidades de mejoras en el producto de una sola persona o equipo
ü  Confirmar las partes del producto en las que no es necesario o no es deseable una mejora
ü  Conseguir un trabajo de mayor calidad maximizando los criterios de correctitud y completitud.
El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar que se conviertan en defectos después de la entrega del software. El beneficio de estas inspecciones el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software.


4.3 Diseño de sistema

4.3 Diseño de sistema
El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones).
El proceso de diseño de un sistema complejo se suele de forma descendente:
*      Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos).
*      Diseño e implementación de cada uno de los subsistemas o Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis. O desarrollo según la especificación. O prueba.
*      Integración de todos los subsistemas
*      Validación del diseño
Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las características del mismo.

En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva y eficiente.

De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento).

Así, con respecto al diseño de herramientas software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de informaciones en pantalla, profundidad de menús, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo de errores, estructuras de datos, utilización de lenguaje natural.

4.2 Diseño de objetos

4.2 Diseño de objetos
Un sistema orientado a objetos está compuesto de objetos que interactúan, los cuales mantienen ellos mismos su estado local y proveen operaciones sobre su estado. La representación del estado es privada y no se puede acceder a ella directamente desde fuera del objeto. El proceso de diseño de objetos comprende el diseño de clases de objetos y las relaciones entre estas clases. El diseño orientado a objetos comprende el desarrollo de un modelo orientado a objetos de un sistema de software para implementar los requerimientos
identificados. Los objetos en un diseño orientado a objetos están relacionados con el problema a resolver.
Un proceso general para el diseño orientado a objetos puede contener las siguientes etapas:
ü  Comprender y definir el contexto y los modos de utilización del sistema
ü  Diseñar la arquitectura del sistema
ü  Identificar los objetos principales del sistema
ü  Desarrollar los modelos de diseño

ü  Especificar las interfaces de los objetos
Todas estas actividades se pueden ver como actividades entrelazadas que influyen entre sí. Los objetos se identifican y las interfaces se especifican completa o parcialmente en el momento de definir la arquitectura del sistema.

unidad 4

Unidad 4: Modelo de diseño

La fase de diseño (y los modelos de UML resultantes) expande y detalla los modelos de análisis tomando en cuenta todas las implicaciones y restricciones. El propósito del diseño es especificar una solución que trabaje y pueda fácilmente se convierta en código fuente y construir una arquitectura simple y fácilmente entendibles. Las clases definidas en el análisis fueron detalladas y se añaden nuevas clases para manejar áreas técnicas como base de datos, interfaces del usuario.


4.1 Estrategia de diseño
Abstracción: Para un problema determinado se pueden considerar muchos grados de abstracción. En un alto grado de abstracción una solución se establece en términos generales con el lenguaje de entorno del problema en los grados de menor abstracción. En un alto grado de abstracción una solución se establece en términos generales con el lenguaje de entorno del problema.
Arquitectura: La arquitectura del software alude a la estructura general del software y las formas en la que la estructura proporciona una integridad conceptual para un sistema. La arquitectura es la estructura u organización de los componentes del programa (módulos), la manera en que estos componentes interactúan, y la estructura de datos que utilizan los componentes.

Patrones: Un patrón de diseño describe una estructura de diseño que resuelve un problema recurrente de diseño particular dentro de un contexto específico y en medio de fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el patrón.

Modularidad: Los patrones de arquitectura y diseño de software materializan la modularidad; es decir, el software se divide en componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos del problema. La modularidad se basa en la estrategia divide y vencerás (es más fácil resolver un problema complejo cuando éste se divide en piezas más manejables).

Ocultación de información: Sugiere que los módulos se caracterizan por las decisiones de diseño que cada uno oculta a los otros. Los módulos deben especificarse y diseñarse de manera que la información (procedimientos y datos) que está dentro del módulo sea inaccesible para otros módulos que no necesiten esta información.