lunes, 29 de septiembre de 2008

4. VENTAJAS Y DESVENTAJAS

4. VENTAJAS Y DESVENTAJAS


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.

2 comentarios:

Thamen dijo...

eso es buenoo!! gracias

Unknown dijo...

Si quería un copia/pega mejor no salía de Wikipedia.