UNIVERSIDAD AUTÓNOMA DEL CARMEN

Nombre: Jorge Luis López Hernández

Maestra:

Curso: Herramientas Case

Matricula: 153072
Instrucción:
 
1. Investiga sobre las ventajas y desventajas de las Herramientas CASE, así
como el Bloque de construcción de un CASE.
2. Identifica la ventajas y desventajas de las Herramientas CASE.
3. Elabora un diagrama para representar las ventajas y desventajas de la
Herramienta CASE.
4. Describe a que se refiere cada bloque de construcción de un CASE.
5. En su canal de equipo, analiza los bloques del CASE.
 
Tarea:
 
Elabora un diagrama para representar las ventajas y desventajas de la Herramienta
CASE.
Elabora un documento donde describes cada bloque del grafo “Bloques del CASE”

Ventajas y desventajas de las Herramientas CASE.

VENTAJAS

Entre los beneficios ofrecidos por la tecnología CASE se encuentran los

siguientes:

Facilidad para la revisión de aplicaciones

La experiencia muestra que una vez que las aplicaciones se implementan, se

emplean por mucho tiempo. Las herramientas CASE proporcionan un beneficio
substancial para las organizaciones al facilitar la revisión de las aplicaciones.
Contar con un depósito central agiliza el proceso de revisión ya que éste
proporciona bases para las definiciones y estándares para los datos. Las
capacidades de generación interna, si se encuentran presentes, contribuyen a
modificar el sistema por medio de las especificaciones más que por los ajustes al
código fuente.

Soporte para el desarrollo de prototipos de sistemas

En general, el desarrollo de prototipos de aplicaciones toma varias formas. En

ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de
mostrar la organización y composición de los datos, encabezados y mensajes. Los
ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y
las características de la interface. Sin embargo, no se prepara el código fuente, de
naturaleza orientada hacia procedimientos, como una parte del prototipo.
Como disyuntiva, el desarrollo de prototipos puede producir un sistema que
funcione. Las características de entrada y salida son desarrolladas junto con el
código orientado hacia los procedimientos y archivos de datos.
Muchas herramientas CASE soportan las primeras etapas del desarrollo del
prototipo. Muy pocas brindan apoyo durante todo el proceso de desarrollo del
prototipo. Las que proporcionan la capacidad para generar código soportan de
hecho todo proceso, ya que el código puede ser generado al inducir la actividad de
generación después de cambiar las especificaciones o requerimientos.

Generación de código

Como ya se mencionó, algunas herramientas CASE tienen la capacidad de

producir el código fuente. La ventaja más visible de esta característica es la
disminución del tiempo necesario para preparar un programa. Sin embargo, la
generación del código también asegura una estructura estándar y consistente para
el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la
ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las
características de la generación del código permiten volver a utilizar el software y
las estructuras estándares para generar dicho código, así como el cambio de una
especificación modular, lo que significa volver a generar el código y los enlaces
con otros módulos. Ninguna de las herramientas que existen en el presente es
capaz de generar un código completo en los dominios.

Mejora en la habilidad para satisfacer los requerimientos del usuario

Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya

que esto guarda relación con el éxito del sistema. De manera similar, tener los
requerimientos correctos mejora la calidad de las prácticas de desarrollo. Parece
ser que las herramientas CASE disminuyen el tiempo de desarrollo, una
característica que es importante para los usuarios. Las herramientas afectan la
naturaleza y cantidad de interacción entre los encargados del desarrollo y el
usuario. Las descripciones gráficas y los diagramas, así como los prototipos de
reportes y la composición de las pantallas, contribuyen a un intercambio de ideas
más efectivo.

Soporte interactivo para el proceso de desarrollo

La experiencia ha demostrado que el desarrollo de sistemas es un proceso

interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el tedio
manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de
esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema
con mayor frecuencia y en forma más consistente.

DESVENTAJAS

Las herramientas CASE tienen puntos débiles significativos, que van desde la
confiabilidad en los métodos estructurados hasta su alcance limitado, los cuales
amenazan con minar los beneficios potenciales descritos con anterioridad.

Confiabilidad en los métodos estructurados

Muchas herramientas CASE están construidas teniendo como base las

metodologías del análisis estructurado y del ciclo de vida de desarrollo de
sistemas. Por si sola, esta característica puede convertirse en la principal limitante
ya que no todas las organizaciones emplean métodos de análisis estructurado.
Los métodos estructurados, introducidos en la década de los setenta, fueron muy
elogiados por su habilidad para mejorar la exactitud de los requerimientos
específicos de las aplicaciones. El nivel de conocimiento de los métodos
estructurados es lato entre los profesionales de sistemas de información – de
acuerdo con algunas estimaciones (Yourdon), casi el 90% de todos los analistas
esta familiarizado con estos métodos -. Aproximadamente la mitad de todas las
organizaciones en Estados Unidos han utilizado alguna vez estos métodos. A
pesar de lo anterior, si la organización o el analista no utilizan los métodos propios
del análisis estructurado y tampoco desean considerar su uso, entonces el valor
del CASE disminuye. En algunos casos, los analistas evitan del todo emplear
herramientas CASE.

Falta de niveles estándar para el soporte de la metodología

Aún no aparece un conjunto “estándar” de herramientas CASE. Por tanto, debe

tener precaución al seleccionar una herramienta de este tipo.

Existen dos significados para las palabras “soporte de la metodología”. Una

herramienta puede: 1) dar soporte a los diagramas que emplea una metodología o
2) soportarlos e imponer la metodología, sus reglas y procesos.

Las herramientas CASE que existen en el presente, tienen una de las siguientes
características:

* Son independientes de la metodología.

* Permiten que los usuarios definan sus propias metodologías.

* Soportan una metodología.

* Soportan las metodologías más diseminadas.

En todas ellas existen ciertos compromisos. Las herramientas que son

independientes de la metodología, no pueden fomentar el uso de las reglas y
estándares de la misma. Estas herramientas quizá proporcionen los componentes
de una metodología (por ejemplo: diagramas de flujos de datos, un diccionario de
datos y facilidades para la descripción de procesos), pero no el marco de
referencia, reglas y procedimientos que en realidad constituyen el núcleo de la
metodología. Aunque se puede llevar a cabo acciones básicas para la validación
de diseños y diagramas para detectar componentes faltantes, éstas son sólo
funciones mecánicas. Por otra parte, esta clase de herramientas no puede
proporcionar ayuda metodológica o pedir al usuario que realice tareas necesarias
para la metodología que aún esta sin terminar.

Estas herramientas mejoran la productividad al efectuar tareas tediosas y de

documentación, aunque ellas no puedan asegurar buenos resultados. Desde el
punto de vista funcional, las capacidades que brindan para garantizar la calidad
son mínimas.

Conflictos en el uso de los diagramas

Las herramientas difieren en el uso que hacen los diagramas. Algunas son
herramientas exclusivamente para gráficas, que se abocan al dibujo de diagramas
para el análisis de entrada y salida de datos. Este tipo de herramientas puede
restringir ya sea el proceso de desarrollo normal seguido por una organización o el
estilo particular de trabajo de los analistas.
Otros vendedores de herramientas consideran los diagramas como
documentación y aceptan entradas por medio de formas o lenguajes de
especificación y, en ocasiones, en forma gráfica. Por tanto, se debe tener cuidado
cuando se selecciona una herramienta para apoyar los métodos existentes en una
organización.

Diagramas no utilizados

En general, los productos CASE emplean gráficas para modelar y generar

informes sobre el análisis y desarrollo de sistemas. Una de las afirmaciones de los
vendedores de herramientas es que las presentaciones gráficas y la
documentación mejoran la comunicación entre los miembros del equipo de
desarrollo, propician una calidad mayor de la entrada proporcionada por el cliente
y mejoran la productividad de desarrollo de software. Sin embargo, los
investigadores han encontrado que, en algunos casos, las herramientas gráficas,
automatizadas o manuales, no se emplean del todo. O tal vez no se utilicen en la
forma que deberían emplearse. Por otra parte, algunos analistas prefieren para
algunas tareas un lenguaje estructurado o descriptivo.
Muchos profesionales de los sistemas de información no hacen uso de
herramientas gráficas en el desarrollo de software; más bien las emplean para
automatizar la producción de informes y documentación del sistema, como los
diagramas de flujo utilizados por los programadores para documentar un programa
una vez terminado.

Función limitada

Aunque una herramienta puede apoyar varias fases del ciclo de vida de desarrollo
de sistemas o adaptarse a diferentes metodologías de desarrollo, por lo general su
enfoque primario está dirigido hacia una fase o método especifico. Por ejemplo,
los encargados de desarrollar un nuevo producto pueden afirmar que éste apoya
todo el proceso de análisis y diseño. Sin embargo, las capacidades de
comprobación y verificación de errores del producto quizá sean más rigurosas ya
sea en el área de análisis o en la de diseño, pero no en ambas. Algunos productos
están dirigidos hacia el diseño de bases de datos para la organización y al
desarrollo de aplicaciones que giren en torno a la base de datos, omitiendo el
soporte para pantallas de presentación visual, los informes sobre requerimientos o
las necesidades de seguridad. Algunos productos capaces de generar el código
hacen mayor hincapié en el desarrollo de prototipos como el principal método de
desarrollo de sistemas de información. Muchas herramientas para la fase de
desarrollo recalcan el mantenimiento y la reestructuración del código, pero ofrecen
un soporte débil durante la fase de análisis para la determinación y especificación
de requerimientos.

Alcance limitado

Aunque muchas herramientas basadas en computadoras incluyen la capacidad de

verificar las especificaciones para determinar su complementes o consistencia,
virtualmente no llevan a cabo ningún análisis de los requerimientos de la
aplicación. Por tanto, el alcance de las actividades de desarrollo asociado con las
herramientas existentes es bastante limitado.
La mayor parte de productos CASE describe (documenta) pero no analiza. De
poca ayuda es proporcionar una regla de inclusión en los mejores enfoques y una
regla de exclusión para los que son poco satisfactorios. No ofrecen o evalúan,
soluciones potenciales para los problemas relacionados con sistemas. Y tampoco
existe una garantía clara para que dos analistas que utilicen los mismos métodos
aplicados a información idéntica, formulen recomendaciones igualmente
aceptables.

Bloque de construcción de un CASE.

La ingeniería del software asistida por computadora puede ser tan sencilla como
una única herramienta que preste su apoyo para una única actividad de ingeniería
del software, o tan compleja como todo un entorno que abarque «herramientas»,
una base de datos, personas, hardware, una red, sistemas operativos, estándares,
y otros mil componentes más. Los bloques de construcción de CASE se ilustran
en la Figura 31.1. Cada bloque de construcción forma el fundamento del siguiente,
estando las herramientas situadas en la parte superior del montón. Es interesante
tener en cuenta que el fundamento de los entornos CASE efectivos tiene
relativamente poco que ver con las herramientas de ingeniería del software
en sí. Más bien, los entomos para la ingeniería del software se construyen con
éxito sobre una arquitectura de entornos que abarca un hardware y un software de
sistemas adecuados. Además, la arquitectura del entorno deberá tener en cuenta
los patrones de trabajo humano que se aplicarán durante el proceso de ingeniería
del software.
Las arquitecturas del entorno, que constan de una plataforma hardware y de un
soporte de sistema operativo (incluyendo software de red, gestión de la base de
datos y servicios de gestión de objetos), establece los cimientos para un entorno
CASE. Pero el entorno CASE en sí requiere otros bloques de construcción. Existe
un conjunto de servicios de portabilidad que proporciona un puente entre las
herramientas CASE, su marco de integración y la arquitectura del entorno. El
marco de integración es un grupo de programas especializados que permiten a
cada una de las herramientas comunicarse entre sí, para crear una base de datos
del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero del
software). Los servicios de portabilidad permiten que las herramientas CASE y su
marco de integración migren entre distintas plataformas del hardware y sistemas
operativos sin un mantenimiento adaptativo significativo.

Los bloques de construcción representados en la Figura 3 1.1 representan un

fundamento completo para la integración de herramientas CASE. Sin embargo, la
mayor parte de las herramientas CASE que se utilizan en la actualidad no han sido
construidas empleando todos los bloques de construcción anteriormente descritos.
De hecho, algunas herramientas siguen siendo las «soluciones puntuales». Esto
es, una herramienta se utiliza para prestar apoyo en una actividad de ingeniería
del software concreta (por ejemplo, modelado de análisis), pero esta herramienta
no se comunica directamente con otras, no está unida a una base de datos del
proyecto, y no forma parte de un entorno integrado CASE (1-CASE). Aunque esta
situación no es la ideal, se puede utilizar una herramienta CASE bastante
eficiente, aunque se trate de una solicitud puntual.
Los niveles relativos de integración CASE se muestran en la Figura 3 1.2. En el
extremo inferior del espectro de integración se encuentra la herramienta individual
(solución puntual). Cuando las herramientas individuales proporcionan servicios
para el intercambio de datos (como lo hacen la mayoría), el nivel de integración
mejora ligeramente. Estas herramientas producen su salida en un formato
estándar que deberá ser compatible con otras herramientas que sean capaces de
leer ese formato. En algunos casos, los constructores de herramientas CASE
complementarias trabajan juntos para formar un puente entre herramientas (por
ejemplo, una herramienta de análisis y diseño que se enlaza con un generador de
código). Mediante la utilización de este enfoque, la sinergia entre herramientas
puede producir unos resultados finales que serían difíciles de crear empleando
cada una de las herramientas por separado. La integración de fuente única se
produce cuando un único vendedor de herramientas CASE integra una cierta
cantidad de herramientas distintas y las vende en forma de paquete. Aunque este
enfoque es bastante eficiente, la arquitectura cerrada de la mayoría de los
entornos de fuente Única evita añadir fácilmente herramientas procedentes de
otros fabricantes.

En el extremo superior del espectro de integración se encuentra el entorno de

apoyo integrado a proyectos integrado (EAIP). Se han creado estándares en cada
uno de los bloques de construcción descritos anteriormente. Los fabricantes de
herramientas CASE utilizan los estándares EAIP para construir herramientas que
sean compatibles con el EAIP, y que por tanto sean compatibles entre sí.