ENSAYO USO DE HERRAMIENTAS LUIS ANGEL GALLEGO VILLA

ENSAYO
USO DE HERRAMIENTAS
LUIS ANGEL GALLEGO VILLA
Instructor
ROBINSON VELANDIA RUIZ
Especialista en Gerencia de Proyectos
Tecnología en Análisis y Desarrollo
SENA
Puerto Berrío, Antioquia
Año 2011
HERRAMIENTAS CASE
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de
Software Asistida por Computadora) son diversas aplicaciones informáticas
destinadas a aumentar la productividad en el desarrollo de software reduciendo el
coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos
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 costes,
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.
Sistema de software que intenta proporcionar ayuda automatizada a las
actividades del proceso de software. Los sistemas CASE a menudo se utilizan
como apoyo al método.
Objetivos:









Mejorar la productividad en el desarrollo y mantenimiento del software.
Aumentar la calidad del software.
Reducir el tiempo y coste 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.
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas
CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:
1.
2.
3.
4.
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.
La siguiente clasificación es la más habitual basada en las fases del ciclo de
desarrollo que cubren:



Upper CASE (U-CASE), herramientas que ayudan en las fases de
planificación, análisis de requisitos y estrategia del desarrollo, usando, entre
otros diagramas UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y
diseño de la aplicación.
Lower CASE (L-CASE), herramientas que semiautomatizan la generación de
código, crean programas de detección de errores, soportan la depuración de
programas y pruebas. Además automatizan la documentación completa de la
aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de
aplicaciones.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una
clasificación excluyente entre sí, ni con la anterior:




Integrated CASE (I-CASE), herramientas que engloban todo el proceso de
desarrollo software, desde análisis hasta implementación.
MetaCASE, herramientas que permiten la definición de nuestra propia técnica
de modelado, los elementos permitidos del metamodelo generado se guardan
en un repositorio y pueden ser usados por otros analistas, es decir, es como si
definiéramos nuestro propio UML, con nuestros elementos, restricciones y
relaciones posibles.
CAST (Computer-Aided Software Testing), herramientas de soporte a la
prueba de software.
IPSE (Integrated Programming Support Environment), herramientas que
soportan todo el ciclo de vida, incluyen componentes para la gestión de
proyectos y gestión de la configuración.
Por funcionalidad podríamos diferenciar algunas como:




Herramientas de generación semiautomática de código.
Editores UML: Es un programa de código abierto, gratuito que nos facilita la
creación de diagramas para la planificación de implementación de
aplicaciones.
Herramientas de Refactorización de código: Es una técnica de la ingeniería de
software para reestructurar un código fuente, alterando su estructura interna
sin cambiar su comportamiento externo.La refactorización se realiza a menudo
como parte del proceso de desarrollo del software: los desarrolladores alternan
la inserción de nuevas funcionalidades y casos de prueba con la
refactorización del código para mejorar su consistencia interna y su claridad.
Los tests aseguran que la refactorización no cambia el comportamiento del
código.
Herramientas de mantenimiento como los sistemas de control de versiones.
HERRAMIENTAS UML
El lenguaje de modelado unificado (UML - Unified Modeling Language) facilita
varios tipos de diagramas, los que nos permiten describir los requisitos,
funcionalidad, y otros conceptos relativos a un proyecto de desarrollo de software.
El UML se utiliza para definir un sistema de software y con el 20% de UML se
puede describir el 80% de un proyecto desarrollo.
Efectivamente, como desarrollador se tiene que tener la capacidad para
seleccionar los diagramas adecuados que describan el proyecto.
Estos diagramas se pueden organizar en dos grupos:
1. Los que describen el comportamiento del negocio, del sistema, de un aspecto
en particular:







Diagrama de Actividad: Representa los procesos de negocio o la lógica de un
sistema complejo. Incluye, opcionalmente, el flujo de datos. El nivel de
abstracción suele ser bastante alto, pero pueden realizarse diagramas de
actividad exploratorios cuando la lógica que se trata es compleja.
Diagrama de Estados: Describe los estados de un objeto así como la transición
entre estados. Muy útil para los desarrolladores.
Diagrama de Casos de Uso: Muestra casos de uso individuales, actores y las
relaciones entre ellos. El Proceso Unificado dice está dirigido por los casos de
uso, esto significa que este diagrama (en el nivel de abstracción que sea) es la
base del lenguaje de modelado y representación.
Diagrama de Comunicación: Muestra las relaciones entre instancias de las
clases y el flujo de mensajes entre ellas, antes (UML 1.0) se llamaba Diagrama
de Colaboración. La cuestión tiene que ser realmente complicada para tener
que utilizar estos diagramas.
Diagrama de Interacción: Es una variante del Diagrama de Actividad, muestra
un panorama general del flujo de control dentro del sistema o proceso de
negocio.
Diagrama de Secuencia: Muestra la secuencia de la lógica, el orden en que se
suceden los mensajes. Importante, especialmente cuando se trabaja en
ambientes altamente compartidos.
Diagrama de Tiempo: Muestra el cambio de estado de un objeto a través del
tiempo en respuesta a eventos externos.
Nota: Los últimos cuatro diagramas también se clasifican como Diagramas de
Interacción, dado enfatizan la interacción entre los objetos. Sin embargo no deja
de ser un aspecto del comportamiento.
Los que describen la estructura, la forma, la organización:






Diagrama de Clases: Muestra una colección de clases, sus tipos, sus
contenidos y sus relaciones. Importantísimo representa el modelo de datos, y
en consecuencia su persistencia en alguna forma de almacenamiento.
Diagrama de Estructura: Muestra la estructura interna de una clase,
componente o caso de uso. Especialmente debe indicar los puntos de
interacción con otras partes del sistema.
Diagrama de Componentes: Describe los elementos que componen un
sistema. Debe detallar los elementos o componentes, las interacciones y
relaciones así como las interfaces públicas.
Diagrama de Despliegue: Muestra la arquitectura de ejecución de un sistema.
Incluye nodos, entornos de hardware y software.
Diagrama de Objetos: Describe los objetos y sus relaciones en algún momento.
Generalmente se usa en casos especiales para diagramas de clase o de
comunicaciones.
Diagrama de Paquetes: Describe como los elementos del modelo se organizan
en "paquetes", debe indicar la dependencia entre paquetes.
Ventajas:






Expresar de una forma gráfica un sistema de manera tal que otros lo puedan
entender.
Permite especificar cuáles son las características de un sistema antes de su
construcción.
A partir de estos puntos permite la construcción del diseño del sistema.
Permite que los propios elementos gráficos sirvan como documentación del
sistema desarrollado y que así estos puedan servir para futuras revisión.
Mayor rigor en la especificación.
Permite realizar una verificación y validación del modelo realizado.
Objetivo:


Uml tiene como objetivo primordial ayudar al usuario a desarrollar un buen
sistema.
UML tiene como objetivo final ser tan simple como fuera posible pero
manteniendo la capacidad de modelar toda la gama de sistemas que se
necesita construir.
Un modelo UML está compuesto por tres clases de bloques de construcción:



Elementos: Los elementos son abstracciones de cosas reales o ficticias
(objetos, acciones, etc.)
Relaciones: relacionan los elementos entre sí.
Diagramas: Son colecciones de elementos con sus relaciones.
HERRAMIENTA REM
REM (Requirements Management), es una gran y sencilla herramienta para el
desarrollo del análisis de requisitos de un proyecto de software, al que haya que
aplicarle un proceso de ingeniería de software. Con este programa se pueden
hacer los pasos más importantes del proceso de análisis de requisitos de cualquier
proyecto, en los que se destacan los requisitos funcionales, no funcionales,adición
de sus respectivos actores, casos de uso, entre otros.
Rem permite hacer:








Adición de objetivos
Adición de actores
Adición de requisitos de almacenamiento de información
Casos de uso
Requisitos funcionales
Requisitos no funcionales
Requisitos de restricción
Matriz de rastreabilidad
LA METODOLOGÍA RUP
La metodología RUP, llamada así por sus siglas en inglés Rational Unified
Process, divide en 4 fases el desarrollo del software:




Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.
Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.
Construcción, En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
Transmisión, El objetivo es llegar a obtener el release del proyecto.
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual
consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos
de una iteración se establecen en función de la evaluación de las iteraciones
precedentes.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es
llevada bajo dos disciplinas:
Disciplina de Desarrollo.





Ingeniería de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema
automatizado.
Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de
software.
Implementación: Creando software que se ajuste a la arquitectura y que tenga
el comportamiento deseado.
Pruebas: Asegurándose que el comportamiento requerido es el correcto y que
todo lo solicitado está presente.
Disciplina de Soporte.




Configuración y administración del cambio: Guardando todas las versiones del
proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribución: Hacer todo lo necesario para la salida del proyecto
Es recomendable que a cada una de estas iteraciones se les clasifique y ordene
según su prioridad, y que cada una se convierte luego en un entregable al cliente.
Esto trae como beneficio la retroalimentación que se tendría en cada entregable o
en cada iteración.
Los elementos del RUP son:



Actividades, Son los procesos que se llegan a determinar en cada iteración.
Trabajadores, Vienen hacer las personas o entes involucrados en cada
proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento
de modelo.
Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace
exigente el uso de artefactos, siendo por este motivo, una de las metodologías
más importantes para alcanzar un grado de certificación en el desarrollo del
software.
La Metodología RUP es más adaptable para proyectos de largo plazo.