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 y tomando en cuenta de todas las implicaciones y restricciones técnicas. El propósito del diseño es especificar una solución  que trabaje y pueda ser fácilmente convertida en código fuente y construir  una arquitectura simple y fácilmente  extensible. Las clases definidas en el análisis fueron detalladas, y se añadieron nuevas clases para manejar áreas técnicas como base de datos, interfaz de usuario, comunicación, dispositivos.

 

 

4.1 Estrategias de diseño:

 

 

     A través de la historia de la ingeniería de software ha evolucionado un conjunto de conceptos fundamentales de diseño de software. Cada uno ofrece al ingeniero de software un fundamento sobre el cual pueden aplicarse métodos de diseño más elaborados. Los conceptos fundamentales del diseño de software ofrecen el marco de

       trabajo necesario para hacer las cosas del “modo correcto”.

      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 se proporciona una solución más detallada de la solución. Una abstracción procedimental
se refiere a una secuencia de instrucciones que tiene una función específica y limitada.

 

Una abstracción de datos es una colección nombrada de datos que describe un objeto de datos.  Por ejemplo, se puede decir que la abstracción procedimental abrir
emplearía la información contenida en los atributos de la abstracción de datos puerta.

 

          Arquitectura
La arquitectura del software alude a la estructura general del software y las formas en las 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
El principio de 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.
Independencia funcional
Es la suma de directa de la modularidad y de los conceptos de abstracción y ocultación de información. La independencia funcional se consigue al desarrollar módulos con una función determinante y una aversión a la interacción excesiva con otros módulos. Los módulos independientes son más fáciles de mantener, probar, modificar y se reduce
la propagación de errores.
Refinamiento
El refinamiento es una estrategia de diseño descendente. El desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle procedimentales.  El
refinamiento hace que el diseñador trabaje sobre el enunciado original y que proporcione más y más detalles conforme se realiza cada refinamiento sucesivo. La
abstracción y el refinamiento son conceptos complementarios.
Estrategias de diseño
La meta del diseño es crear un modelo de software que implemente todos los requisitos
del cliente de manera correcta y complazca a aquéllos que lo
usen. El proceso de diseño avanza de una visión general del software a una visión más
estrecha que define el detalle requerido para implementar un sistema.
El proceso de diseño comienza con un enfoque en la arquitectura. Se definen los subsistemas, se establecen mecanismos de comunicación entre los subsistemas; se identifican los componentes y se realiza una descripción detallada de cada componente. Además, se diseñan las interfaces internas, externas y del usuario.

 

 

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.

 

 

 

 

4.3 DISEÑO DE SISTEMAS

Durante el diseño de objetos, se ha desarrollado un diseño detallado con base en la arquitectura especificada. En general, el diseño de sistemas incluye aspectos como los
siguientes:

•Selección del lenguaje de programación a utilizarse.
•Incorporación de bibliotecas (para interfaces gráficas, estructuras de datos, etc.)
•Incorporación de una base de datos.
•Incorporación de archivos en sus diferentes formatos.
•Consideraciones de procesamiento,  como concurrencia, paralelismo, distribución y tiempo real.
Estos aspectos pueden variar entre un sistema y otro. Además, pueden afectar de manera importante la arquitectura final del sistema.
Existen diferentes enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:

•Agregar clases abstractas o interfaces que luego se  especializarán según el ambiente de implementación.
•Instanciar objetos especializados para la administración del ambiente de implementación
•Configurar múltiples versiones del sistema correspondientes a diferentes plataformas.

 Diseño de sistema - Lenguajes de programación
Es importante señalar que un diseño orientado a objetos no necesariamente se tiene que implementar mediante un lenguaje orientado a objetos. Sin embargo, es más natural
hacerlo de esta manera. Esto es debido a que los lenguajes orientados a objetos tienen un apoyo directo a los conceptos del análisis orientado a objetos (encapsulamiento,
generalización, polimorfismo). Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su conveniencia, mantenimiento y protección contra errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y extensión de los programas sea más fácil y segura.
Cabe mencionar que no todos los lenguajes de programación orientados a objetos implementan de la misma forma los conceptos de la metodología orientada a objetos.  Aspectos como manejo de encapsulamiento, referencias, herencia múltiple varían de manera importante entre los lenguajes de programación.
 Diseño de sistema – Interfaces gráficas
Las interfaces gráficas tienen como objetivo principal administrar la interacción entre el usuario mediante elementos gráficos, como son botones, menús y textos. Las aplicaciones interactivas donde el control del ratón y teclado desempeñan un papel importante se conocen como sistemas controlados o dirigidos por eventos. Estos eventos comprenden: mover el ratón, oprimir uno de sus botones, oprimir una tecla, etc.
Desarrollar un sistema dirigido por eventos significa que la aplicación desde un inicio debe considerar un diseño adecuado. Por ejemplo, en Java se escoge alguna de las bibliotecas gráficas (AWT o Swing) para utilizar el manejo apropiado de interfaces mediante sus clases (JFrame, Jpanel, JButton). Más allá de estas bibliotecas o clases también se afecta la lógica del diseño, ya que se debe contemplar el momento de procesar eventos.
Por ejemplo, si se desarrolla un sistema con varias pantallas se puede manejar cada evento mediante una clase para cada pantalla. Otra solución es usar un JFrame para todas las pantallas y declarar una clase que maneje los eventos del JFrame. En el segundo caso, en lugar de que cada pantalla reciba un evento del usuario, se hace que los eventos sean recibidos por parte de la clase y las pantallas se vuelven más pasivas y fáciles de manipular.

 

Diseño de sistema – Bases de datos
Las bases de datos son fundamentales en los sistemas de información. Una decisión estratégica importante en tal contexto es si debe utilizar bases de datos relacionales u
orientadas a objetos.
En general se consideran tres modelos de bases de datos principales:

•Modelo relacional: se define una colección de tablas donde cada una tiene un número específico de columnas y un número arbitrario de filas. Cada objeto se representa como una fila en una tabla y donde cada columna corresponde a un atributo distinto en el objeto.
•Modelo relacional extendido: el modelo relacional se extiende mediante procedimientos, objetos, versiones y otras nuevas capacidades. No hay un solo modelo relacional extendido, más bien hay una variedad de ellos, aunque todos comparten las tablas y consultas básicas del modelo relacional.
•Modelo orientado a objetos: se define un modelo orientado a objetos donde varía el tipo de encapsulamiento de datos y los procedimientos en el objeto. El término
orientado a objetos varía según cada autor.
Las bases de datos son depósitos de datos guardados en uno o más archivos. Existen sistemas de manejo de bases de datos (DBMS) y orientados a objetos (OOBDMS).
Las bases de datos dan apoyo en los siguientes aspectos:

•Múltiples usuarios
•Múltiples aplicaciones
•Seguridad
•Integridad
Distribución de datos
La tarea del diseño se simplifica, creando una tabla correspondiente a cada clase entidad del dominio del problema y manteniendo las asociaciones entre clases.
Obviamente el diseño de tablas puede optimizarse para un acceso más eficiente.
Diseño de sistema – Archivos
Aunque es más efectivo trabajar con bases de datos, es posible utilizar archivos, sobre todo cuando la especificación del sistema así lo requiera. En el caso de usar una base de datos, regularmente una clase se comunica con el DBMS para hacer solicitudes a cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe por lo que el proceso se hace manualmente.

 

4.4. Revisión del diseño.

Según la IEEE 610.12, 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 del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobación.

Las revisiones al diseño de los productos de software se realizan 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. Entre otros, en esta actividad se verifica la arquitectura y utilización de patrones en el diseño.

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

•         Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo

•         Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.

•         Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud  y Completitud principalmente.

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o en un café es una forma de revisión, si se discuten problemas técnicos.

Una presentación formal de un diseño de software a una audiencia de clientes, ejecutivos y personal  técnico es una forma de revisión. Sin embargo en éste trabajo nos concentraremos en una revisión técnica formal, que  llamaremos Inspección de Software.

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 obvio de estas inspecciones es el  descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de Mizuno).

4.5. Diagramas de secuencias del Diseño.

 

 

El Diagrama de Secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Su creación forma parte de la investigación para conocer el sistema; se incluye dentro de la etapa del análisis.

En UML los Diagrama de Secuencia muestran gráficamente los eventos que pasan de los actores al sistema.

Actividades y dependencias

Los Diagramas de 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 lógico de cómo funcionará 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, sin explicar la manera en que lo hace. Una parte de la descripción es un Diagrama de la Secuencia del sistema.

Diagrama de secuencia del sistema

Los casos de uso indican cómo los actores interactúan con el Sistema de Software. Durante esa interacción un actor genera eventos dirigidos al sistema, solicitando alguna operación a cambio.

 

Conviene aislar 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 gráfica de las interacciones del actor y de las operaciones que las mismas originan.

DIAGRAMA DE SECUENCIA => Representación que muestra, en un determinado Caso de Uso, los eventos generados por actores externos, su orden y los eventos internos del sistema.

A todos los sistemas se los trata como una caja negra; los diagramas se centran 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.

4.6. Herramientas CASE para el diseño.

 

Son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

·                     Análisis de datos y procesos integrados mediante un repositorio.

·                     Generación de interfaces entre el análisis y el diseño.

·                     Generación del código a partir del diseño.

·                     Control de mantenimiento.

Actualmente, la tendencia en el desarrollo de software está enfocada hacia las microcomputadoras como plataformas de ingeniería de software, que se interconectan mediante redes para que puedan comunicarse de forma efectiva. La base de datos del proyecto (también denominada biblioteca del proyecto o depósito de software), está disponible a través de un servidor de archivos en red que es accesible desde todas las estaciones de trabajo. Un sistema operativo que gestiona el hardware, la red y las herramientas, mantiene todo el entorno unido.

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 sí mismo, necesita otros componentes. Un conjunto de servicios de portabilidad constituyen un puente entre las herramientas CASE y su marco de integración y la arquitectura de entorno. El marco de integración es un conjunto de programas especializados que permite a cada herramienta CASE comunicarse con las demás, para crear una base de datos de proyectos y mostrar una apariencia homogénea al usuario final (el ingeniero de software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de integración puedan migrar a través de diferentes plataformas hardware y sistemas operativos, sin grandes esfuerzos de adaptación.

La mayoría de las herramientas Case no han sido construidas utilizando todos los bloques componentes. Muchas de éstas son soluciones puntuales, esto es, una herramienta se utiliza como ayuda en una actividad concreta de ingeniería de software (por ejemplo: modelización del análisis), pero no se comunica directamente con otras herramientas, porque no está unida a una base de datos de proyectos. Aunque esta situación no es la ideal, una herramienta Case puede ser utilizada eficientemente, aún siendo una solución puntual.

En el nivel más bajo del espectro de integración está la herramienta individual (solución puntual). Cuando las herramientas proporcionan facilidades para el intercambio de datos (la mayoría lo hace), el nivel de integración aumenta ligeramente. Estas herramientas generan una salida en un formato estándar compatible con otras herramientas que puedan leer ese formato. En algunos casos, los que construyen herramientas CASE complementarias trabajan juntos para establecer un puente entre ellas (p. ej.: una herramienta de análisis y diseño que se une a un generador de código). Utilizando este enfoque, la compatibilidad entre herramientas puede generar productos finales que serían difíciles de desarrollar utilizando cada herramienta por separado. La integración por fuente única se da cuando un constructor de herramientas CASE integra diferentes herramientas y las vende como un único paquete. Aunque este enfoque es bastante efectivo, la mayoría de los entornos provenientes de una misma fuente tienen una arquitectura cerrada que hace difícil añadir nuevas herramientas de otros vendedores.

Al final del espectro de integración está el entorno de soporte de proyectos integrado (del inglés IPSE). Se crean estándares para cada uno de los bloques componentes. Los vendedores de herramientas CASE utilizan estos estándares IPSE para construir herramientas entre sí.

 

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 de calidad se consigue reduciendo sustancialmente muchos de los problemas de análisis y diseño, inherentes a los proyectos de mediano y gran tamaño (lógica del diseño, coherencia, consolidación, etc.).

La mejora de productividad se consigue a través de la automatización de determinadas tareas como la generación de código 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 del ciclo de vida del desarrollo de sistemas que cubren.

·                     La arquitectura de las aplicaciones que producen.

·                     Su funcionalidad.

Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:

·                     Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.

·                     Herramienta(s) que comprende(n) alguna(s) fase(s) del ciclo de vida de desarrollo de software:

·                     Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

·                     Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a las últimas fases del desarrollo: construcción e implantación.

·                     Juegos de herramientas o toolkits, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.

Las herramientas I-CASE se basan en una metodología. Tienen un repositorio y aportan técnicas estructuradas para todas las fases del ciclo de vida. Estas son las características que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilización de lenguajes de alto nivel o técnicas de prototipeo.

Una estrategia posible es utilizar una U-CASE para análisis y diseño, combinada con otras herramientas más modernas para las fases de construcción y pruebas. En este caso, habría que vigilar cuidadosamente la integración entre las distintas herramientas.

Requisitos de aplicación de Case:

·                     Conocimiento y manejo de metodologías.

·                     Capacidad de trabajo en equipo.

·                     Desarrollo conjunto con los usuarios (Prototipos).

·                     Equipamiento apropiado.

 

Otra posible clasificación, utilizando la funcionalidad como criterio principal, es la siguiente:

·Herramientas de planificación de sistemas de gestión. Sirven para modelizar los requisitos de información estratégica de una organización. Proporcionan un "metamodelo" del cual se pueden obtener sistemas de información específicos. Su objetivo principal es ayudar a comprender mejor cómo se mueve la información entre las distintas unidades organizativas. Estas herramientas proporcionan una ayuda importante cuando se diseñan nuevas estrategias para los sistemas de información y cuando los métodos y sistemas actuales no satisfacen las necesidades de la organización.

Herramientas de análisis y diseño. Permiten al desarrollador crear un modelo del sistema que se va a construir y también la evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación. Se tienen:

 Herramientas de análisis y diseño (Modelamiento).

 Herramientas de creación de prototipos y de simulación.

Herramientas para el diseño y desarrollo de interfaces.

Máquinas de análisis y diseño (Modelamiento).

Herramientas de programación. Se engloban aquí los compiladores, los editores y los depuradores de los lenguajes de programación convencionales. Ejemplos de estas herramientas son:

Herramientas de codificación convencionales.

Herramientas de codificación de cuarta generación.

Herramientas de programación orientadas a los objetos.

Herramientas de integración y prueba: Sirven de ayuda a la adquisición, medición, simulación y prueba de los equipos lógicos desarrollados. Entre las más utilizadas están:

  Herramientas de análisis estático.

  Herramientas de codificación de cuarta generación.

Herramientas de programación orientadas a los objetos.

Herramientas de gestión de prototipos. Los prototipos son utilizados ampliamente en el desarrollo de aplicaciones, para la evaluación de especificaciones de un sistema de información, o para un mejor entendimiento de cómo los requisitos de un sistema de información se ajustan a los objetivos perseguidos.

Herramientas de mantenimiento: La categoría de herramientas de mantenimiento se puede subdividir en:

 Herramientas de ingeniería inversa.

 Herramientas de reestructuración y análisis de código.

 Herramientas de reingeniería.

Herramientas de gestión de proyectos. La mayoría de las herramientas CASE de gestión de proyectos, se centran en un elemento específico de la gestión del proyecto, en lugar de proporcionar un soporte global para la actividad de gestión. Utilizando un conjunto seleccionado de las mismas se puede: realizar estimaciones de esfuerzo, coste y duración, hacer un seguimiento continuo del proyecto, estimar la productividad y la calidad, etc. Existen también herramientas que permiten al comprador del desarrollo de un sistema, hacer un seguimiento que va desde los requisitos del pliego de prescripciones técnicas inicial, hasta el trabajo de desarrollo que convierte estos requisitos en un producto final. Se incluyen dentro de las herramientas de control de proyectos las siguientes:

Herramientas de planificación de proyectos.

Herramientas de seguimiento de requisitos.

Herramientas de gestión y medida.

·                                 Herramientas de soporte. Se engloban en esta categoría las herramientas que recogen las actividades aplicables en todo el proceso de desarrollo, como las que se relacionan a continuación:

Herramientas de documentación.

Herramientas para software de sistemas.

Herramientas de control de calidad.

 Herramientas de bases de datos.

Otra clasificación, diferencia las funciones CASE en cinco grupos:

Repositorio. Funcionan en torno a un repositorio central, siendo éste el núcleo fundamental que contiene todas las definiciones de objeto y sus relaciones. Los objetos pueden ser especificaciones del sistema en forma de diagramas de flujo de datos, diagramas entidad-relación, esquemas de bases de datos, diseños de pantallas, etc. El repositorio es un concepto más amplio que el de diccionario de datos y soporta a los demás grupos de funciones. No es fácil encontrar en el mercado productos Case con funcionalidades estrictamente a las de repositorio, ya que, a pesar de su innegable importancia, tienen un carácter auxiliar de los demás grupos de funciones. Cualquier sistema Case poseerá un repositorio propio o bien, trabajará sobre un repositorio suministrado por otro fabricante o vendedor.

Re-ingeniería. Los sistemas Case permiten establecer una relación estrecha y fuertemente formalizable entre los productos generados a lo largo de distintas fases del ciclo de vida, permitiendo actuar en el sentido especificaciones-código (ingeniería "directa") y también en el contrario (ingeniería "inversa"). Ello facilita la realización de modificaciones en la fase más adecuada en cada caso y su traslado a las demás. Al conjunto de facilidades proporcionadas por la ingeniería «directa» e "inversa" se le denomina "re-ingeniería".

Soporte del ciclo de vida. El ciclo de vida de una aplicación o de un sistema de información se compone de varias etapas, que van desde la planificación de su desarrollo hasta su implantación, mantenimiento y actualización. Aunque el número de fases puede ser variable en función del nivel de detalle que se adopte, pueden de modo simplificado, identificarse las siguientes:

Planeamiento.

Análisis y Diseño.

Implantación (programación y pruebas).

Mantenimiento y actualización.

Los sistemas Case pueden cubrir la totalidad de estas fases o bien especializarse en alguna(s) de ellas. En este último caso se pueden distinguir sistemas de "alto nivel" ("Upper Case"), orientados a la autonomía y soporte de las actividades correspondientes a las dos primeras fases y, sistemas de "bajo nivel" ("Lower Case"), dirigidos hacia las dos últimas. Los sistemas de "alto nivel" pueden soportar un número más o menos amplio de metodologías de desarrollo.

Soporte de proyecto. Este tipo de funciones hace referencia al soporte de actividades que se producen durante el desarrollo, derivadas fundamentalmente del trabajo en grupos, tales como facilidades de comunicación, soporte a la creación, modificación e intercambio de documentación, herramientas personales, controles de seguridad, etc. Los sistemas Case pueden conceder a estas cuestiones una importancia variable por lo cual el soporte de proyecto constituye un factor de diferenciación.

Mejora continua de calidad. Aunque frecuentemente se asocia a los sistemas Case con la mejora de la productividad en el desarrollo de aplicaciones, debe tenerse en cuenta que una de las principales ventajas estriba también, en la mejora de la calidad de los desarrollos realizados. Determinados sistemas Case enfatizan más sobre este punto que sobre el anterior, introduciendo herramientas que permiten ejercer un control intenso de garantía de calidad del software desarrollado desde las primeras fases de su ciclo de vida.

 

ELABORADO POR: JUANA HERNANDEZ HERNANDEZ   SEM:IV   MOD:2

BIBLIOGRAFIAS

 

http://fistesvg.blogspot.mx/

http://fistesvg.blogspot.mx/2013/01/41-estrategias-de-diseno.html