Este documento describe las herramientas CASE (Computer-Aided Software Engineering), que ayudan en el desarrollo y mantenimiento de software reduciendo los costos. Explica los objetivos, componentes y ejemplos de herramientas CASE, así como los beneficios y desventajas. También cubre temas como la prueba de software, validación y verificación de software orientado a objetos y aplicaciones web, y la evolución de sistemas heredados.

1. HERRAMIENTAS Y ENTORNOS
DE IMPLEMENTACIÓN DE
SOFTWARE
Autor: Miguel Ángel
Sánchez Fernández

2. HERRAMIENTAS CASE
CASE es un acrónimo para Computer-Aided Software Engineering,
que significa Ingeniería de software asistida por computadora.
Es una herramienta que ayuda al ingeniero de software a desarrollar y
mantener software.
Son diversas aplicaciones informáticas destinadas a aumentar la
productividad en el desarrollo de software reduciendo el costo de las
mismas en términos de tiempo y de dinero.
Estas herramientas pueden ayudar en todos los aspectos del ciclo de
vida de desarrollo del software en tareas como el proceso de realizar
un diseño del proyecto, cálculo de costos, implementación de parte
del código automáticamente con el diseño dado, compilación
automática, documentación o detección de errores entre otras.

3. OBJETIVOS DE LAS HERRAMIENTAS
CASE
Mejorar la productividad del software
Aumentar la calidad del software
Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
Mejorar la planificación de un proyecto
Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de
soluciones para los requisitos.
Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas
de errores y la gestión del proyecto.
Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
Gestión global en todas las fases de desarrollo de software con una misma herramienta.
Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

4. COMPONENTES O ELEMENTOS DE
LAS HERRAMIENTAS CASE
Repositorio: Incluye toda la información que se va generando a lo
largo del ciclo de vida del sistema.
Módulos de diagramación y modelización: Algunos de los diagramas
y modelos utilizados con mayor frecuencia son:
Diagrama de flujo de datos.
Modelo entidad - interrelación.
Historia de la vida de las entidades.
Diagrama Estructura de datos.
Diagrama Estructura de cuadros.
Técnicas matriciales.

5. COMPONENTES O ELEMENTOS DE
LAS HERRAMIENTAS CASE
Herramienta de prototipado: Muestra al usuario, desde los
momentos iniciales del diseño, el aspecto que tendrá la aplicación
una vez desarrollada.
Generador de código: Compilar y generar un código usado.
Módulo generador de documentación: Se alimenta del repositorio
para transcribir las especificaciones allí contenidas.

6. BENEFICIOS DE LAS
HERRAMIENTAS CASE
Facilita
La verificación y mantenimiento de la
consistencia de la información del
proyecto.
El establecimiento de estándares en el
procesos de desarrollo y documentación.
El mantenimiento del sistema y las
actualizaciones de su documentación.
La aplicación de las técnicas de una
metodología.
La aplicación de técnicas de reutilización y
reingeniería.
La planificación y gestión del proyecto
informático.

7. DESVENTAJAS DE LAS
HERRAMIENTAS CASEPoca confiabilidad
en los métodos
estructurados.
Falta de niveles
estándar para el
soporte de la
metodología.
Conflictos en el
uso de los
diagramas.
Diagramas no
utilizados.
Función limitada.
Alcance limitado.

8. ESTRUCTURA GENERAL DE UNA
HERRAMIENTA CASE
• CASE de alto nivel son aquellas herramientas que automatizan o
apoyan las fases finales o superiores del ciclo de vida del desarrollo
de sistemas como la planificación de sistemas, el análisis de sistemas
y el diseño de sistemas.
• CASE de bajo nivel son aquellas herramientas que automatizan o
apoyan las fases finales o inferiores del ciclo de vida como el diseño
detallado de sistemas, la implantación de sistemas y el soporte de
sistemas.
• CASE cruzado de ciclo de vida se aplica a aquellas herramientas que
apoyan actividades que tienen lugar a lo largo de todo el ciclo de
vida, se incluyen actividades como la gestión de proyectos y la
estimación.

9. EJEMPLOS DE HERRAMIENTAS
CASE
ERWIN
EasyCASE
Oracle Designer
Power Designer
System Architect
SNAP
Microsoft Visio

10. LA PRUEBA DE SOFTWARE
La prueba de software es un elemento de un tema más amplio que usualmente
se conoce como verificación y validación (V&V). La verificación se refiere al
conjunto de tareas que garantizan que el software implementa correctamente
una función específica. La validación es un conjunto diferente de tareas que
aseguran que el software que se construye sigue los requerimientos del cliente

11. VALIDACIÓN Y VERIFICACIÓN DE
SOFTWARE CONVENCIONALES
Las pruebas requieren que el
desarrollador deseche nociones
preconcebidas sobre lo “correcto” del
software recién desarrollado y luego
trabajen duro para diseñar casos de
prueba a fin de “romper” el software.

12. •Una vez generado el código fuente el software debe probarse para descubrir
tantos errores sea posible
•Pruebas de software:
•Revisan la lógica interna de las interfaces de todo el componente del software.
•Revisan los dominios de entrada y salida para descubrir los errores en el
funcionamiento y rendimiento
¿Qué es?
• Un ingeniero de software
• Pero pueden haber más
especialistas en pruebas.
¿Quién lo
hace?

13. •Cada vez que el programa se ejecuta, ¡el cliente lo
prueba! Por tanto, tiene que ejecutarse el programa antes
de que llegue al cliente, con la intención específica de
encontrar y remover todos los errores.
¿Por qué es
importante?
•la lógica de programa interno se revisa usando técnicas
de diseño de casos de prueba de “caja blanca”
•los requerimientos de software se revisan usando
técnicas de diseño de casos de prueba de “caja negra”
¿Cuáles son
los pasos?

14. PRODUCTO FINAL
Diseño de casos de prueba
Documentación un conjunto de casos de prueba elaborados para revisar la lógica interna
Resultados reales

15. VALIDACIÓN Y VERIFICACIÓN DE
SOFTWARE ORIENTADOS A
OBJETOS
Realizar:
1) ampliar la definición de prueba
para incluir las técnicas de
descubrimiento de error aplicadas
al análisis orientado a objetos y a
modelos de diseño
2) cambiar significativamente la
estrategia para prueba de unidad
e integración
3) explicar las características
únicas del software OO mediante
el diseño de casos de prueba.

16. •La arquitectura del software orientado a objetos (OO) da
como resultado una serie de subsistemas en capas que
encapsulan clases colaboradoras.
•Es necesario probar un sistema OO en varios niveles
diferentes con la intención de descubrir errores que puedan
ocurrir conforme las clases colaboran unas con otras
¿Qué es?
• Un ingeniero de software
• Examinadores
especializados realizan la
prueba orientada a objetos
¿Quién lo
hace?

17. •El programa tiene que ejecutarse antes de
que llegue al cliente con la intención
específica de remover todos los errores, de
modo que el cliente no experimente la
frustración que produce encontrarse con un
producto de calidad pobre.
¿Por qué es
importante?
•Las pruebas OO son estratégicamente análogas a la prueba de sistemas
convencionales, pero tácticamente diferentes.
•las “pruebas” se inician con la revisión de dichos modelos. Una vez
generado el código, la prueba OO comienza “en lo pequeño”, con las
pruebas de clase. Se diseña una serie de pruebas que ejercitan las
operaciones de clase y que examinan si existen errores conforme una
clase colabora con otras clases.
¿Cuáles son
los pasos?

18. PRODUCTO FINAL
Diseño para ejercitar clases, sus colaboraciones y comportamientos
Documenta un conjunto de casos de prueba
Registran resultados reales

19. VALIDACIÓN Y VERIFICACIÓN DE
APLICACIONES WEB
META:
Descubrir errores en el
contenido.
Funcionalidad.
Utilidad
Navegabilidad.
Rendimiento.
Seguridad

20. •Es necesario para comprobar una webapp
se aplica una estrategia de prueba que
abarca tanto revisiones como pruebas
ejecutables.
¿Qué es?
•Un ingeniero web
•Gestores
•Clientes
•Usuarios
¿Quién lo
hace?

21. •Si los usuarios finales encuentran errores
que derrumben su fe en la webapp, irán a
algún otro lado en busca del contenido y de
la función que necesitan, y la aplicación
fracasará.
•Eliminar tantos errores como sea posible
antes de poner en línea la webapp.
¿Por qué es
importante?
•Prueba de contenido.
•Prueba de interfaz.
•Prueba de navegación.
•Prueba de componente.
•Prueba de configuración.
•Prueba de rendimiento
•Prueba de seguridad.
¿Cuáles son
los pasos?

22. PRODUCTO FINAL
Plan de prueba para la webapp
Se desarrolla una suite de casos de prueba para cada paso de prueba
Archivo de Resultados

23. SISTEMAS HEREDADOS

24. EVOLUCIÓN DEL SOFTWARE
Estrategias para la evolución de este sistema
Desechar
completamente
el sistema
Dejar el sistema
sin cambios y
continuar con
un
mantenimiento
regular
Hacer
reingeniería del
sistema para
mejorar su
mantenibilidad.
Reemplazar
todo o parte del
sistema con un
nuevo sistema

25. Para evaluar el valor de negocio de un
sistema, se tiene que identificar a los
stakeholders
•del sistema, tales como usuarios finales
del sistema y sus gestores, y
plantearles una serie de cuestiones
sobre dicho sistema.

26. El uso del
sistema.
Los procesos de
negocio que están
soportados
Contabilidad del
Sistema
Salidas del
Sistema

27. BIBLIOGRAFÍA
http://users.dsic.upv.es/asignaturas/eui/mtp/doc-
practicas/intro_case_SA.pdf
http://www.galeon.com/rcruz0423/docs/case.pdf
I. Sommerville, “Preguntas frecuentes sobre la Ingeniería de Software”.
Ingeniería de Software. Pearson Educacion S.A. : Madrid, 2005.
R. Pressman, “El software y la ingeniería de software". Ingeniería Del
Software. Un Enfoque Práctico. Mcgraw-hill INTERAMERICANA
EDITORES, S.A. : México, 2010.