• Author / Uploaded
• MarceloFloresRojas

Citation preview

INTRODUCCIÓN Como se sabe en la actualidad en los negocios siempre hay una gran necesidad por contar con un sistema o herramienta que les facilite el almacenamiento, uso y procesamiento de datos, sistemas de procesamiento de datos (SPDs), por eso es que cada día se diseñan sistemas y herramientas con un mayor alcance en lo que se refiere a base de datos, con el fin de optimizar el control y procesamiento de la data, por lo que en esta ocasión nos vamos a concentrar en una de las muchas herramientas case que existen en el mercado la cual va a ayudar a los negocios en el control y mantenimiento de la data de posibles aplicaciones, sistemas o herramientas que este desee diseñar como un adecuado control de las versiones que se van diseñando y creando, con el fin de tener un registro total de los éxitos y errores que se tuvo con anteriores versiones y hacer actualizaciones que resuelvan esos problemas, y en caso de no resolverlos volver a la versión anterior y realizar nuevamente el estudio para proceder con otra actualización. Lo que se busca con este trabajo es brindar una alternativa de solución al problema que se da en la creación de aplicaciones, sistemas, software, herramientas, entre otros. En los cuales es primordial tener un buen registro de la data que se va creando en conjunto con las versiones que se van creando de las aplicaciones y otros con el fin de prevenir errores, realizar mejoras continuas, mantenimientos, disminuir tiempos y costos.

Herramientas CASE ¿Qué es una herramienta CASE? Las herramientas CASE 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.

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.

Ventajas y Desventajas Ventajas

Estas herramientas pueden proveer muchos beneficios en todas las etapas del proceso de desarrollo de software, algunas de ellas son:           

Mejora en la productividad Mejora en la eficacia Mejora en la calidad del sistema de información Disminución de tiempo Automatización de tareas tediosas Garantizar la consistencia de los procedimientos Verificar el uso de todos los elementos en el sistema diseñado. Automatizar el dibujo de diagramas. Ayudar en la documentación del sistema. Ayudar en la creación de relaciones en la Base de Datos. Generar estructuras de código.

Desventajas     

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. Costo de adquisición.

Tipos de Herramientas CASE 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.  Herramientas de planificación de sistemas de gestión.  Herramientas de análisis y diseño.  Herramientas de programación.  Herramientas de gestión de prototipos.  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.

Control de Versiones ¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. A pesar de que los ejemplos de este libro muestran código fuente como archivos bajo control de versiones, en realidad cualquier tipo de archivo que encuentres en un ordenador puede ponerse bajo control de versiones. El control de versiones se realiza principalmente en la industria informática para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM (siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a otros ámbitos como documentos, imágenes, sitios web, etc.

Beneficios de un adecuado control de versiones  Tener un control exacto sobre cuál es la última versión del código, y quién y cuándo la ha cargado.  Poder comparar versiones, viendo cuales han sido los cambios realizados.  Regresar atrás (a una versión anterior) cuando lo que hemos desarrollado no nos ha dado los resultados esperados.

 Crear distintas ramas del proyecto. Si llegado a un punto se hace necesario hacer dos aplicaciones con distintas funcionalidades, pero con cosas en común, se pueden separar en dos ramas.

Sistemas de Control de Versiones Es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que se pueda recuperar versiones específicas en un futuro. A pesar de que es mucho más usual hacer un control de versiones sobre el código fuente de algún aplicativo, en realidad cualquier tipo de archivo que se encuentre en la computadora puede ponerse bajo control de versiones. Una ventaja de los sistemas de control de versiones es que permite revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un SCV también significa generalmente que si se comete un error o se pierde archivos, estos pueden ser recuperados fácilmente. Además, se obtiene todos estos beneficios a un coste muy bajo.

Tipos de Sistemas de Control de Versiones Sistemas de control de versiones locales Un método de control de versiones usado por muchas personas es copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo hicieron, si son más listos). Este enfoque es muy común porque es muy simple, pero también tremendamente propenso a errores. Es fácil olvidar en qué directorio te encuentras, y guardar accidentalmente en el archivo equivocado o sobrescribir archivos que no querías. Para hacer frente a este problema, los programadores desarrollaron hace tiempo SCVs locales que contenían una simple base de datos en la que se llevaba registro de todos los cambios realizados sobre los archivos

Figura 1: Diagrama de control de versiones local

Sistemas de control de versiones centralizados El siguiente gran problema con la que se encuentran las personas es que necesitan colaborar con desarrolladores en otros sistemas. Para solventar este problema, se desarrollaron los sistemas de control de versiones centralizados (Centralized Version Control Systems o CVCSs en inglés). Estos sistemas, como CVS, Subversion, y Perforce, tienen un único servidor que contiene todos los archivos versionados, y varios clientes que descargan los archivos desde ese lugar central. Durante muchos años éste ha sido el estándar para el control de versiones

Figura 2: Diagrama de control de versiones centralizadas

Esta configuración ofrece muchas ventajas, especialmente frente a VCSs locales. Por ejemplo, todo el mundo puede saber (hasta cierto punto) en qué están trabajando los otros colaboradores del proyecto. Los administradores tienen control detallado de qué puede hacer cada uno; y es mucho más fácil administrar un CVCS que tener que lidiar con bases de datos locales en cada cliente.

Sin embargo, esta configuración también tiene serias desventajas. La más obvia es el punto único de fallo que representa el servidor centralizado. Si ese servidor se cae durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios versionados de aquello en que están trabajando. Si el disco duro en el que se encuentra la base de datos central se corrompe, y no se han llevado copias de seguridad adecuadamente, se podría perder absolutamente todo; toda la historia del proyecto salvo aquellas instantáneas que las personas relacionadas puedan tener en sus máquinas locales. Los VCSs locales sufren de este mismo problema; cuando tienes toda la historia del proyecto en un único lugar, te arriesgas a perderlo todo.

Sistemas de control de versiones distribuidos Es aquí donde entran los sistemas de control de versiones distribuidos (Distributed Version Control Systems o DVCSs en inglés). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos

Figura 3: Diagrama de control de versiones distribuido

Presentación del Problema Dentro de las empresas o negocios van a existir situaciones en las que es necesario cambiar el código, pero muchas otras en las que se debe cambiar la forma en que se maneja este activo en las diferentes etapas del ciclo de vida del software. Muchas de las razones por las cuales se debe cambiar el código tienen que ver con los requerimientos del cliente, por tanto existe una alta frecuencia de cambio por situaciones en las que los requerimientos no fueron capturados adecuadamente. Esto es conocido como un error funcional, ya que no cumple las necesidades del cliente. Sin embargo también existen otro tipo de errores que tienen que ver con el desarrollo, estos se originan por fallas en la ejecución del código, acceso a los datos o compatibilidad con otro software/hardware. Teniendo en cuenta estas razones de cambio, la siguiente gráfica aproxima la frecuencia de ocurrencia de estos para dar una idea de la distribución que presentan:

Figura 4: Distribución de los hechos que hacen necesario el cambio de código

Por tanto, en una empresa como la nuestra es necesario tener en cuenta el control que se tiene sobre los cambios realizados al software, así como a la documentación generada el este proceso, de otra manera podría afectar el desarrollo de nuestro trabajo y las necesidades de nuestros clientes.

Situaciones de Riesgo Teniendo en cuenta lo anterior, se ha recogido la siguiente problemática que ocurre en la ejecución de nuestras actividades: 

Control de accesos

En la actualidad, el desarrollo de código se da en un ambiente compartido dentro del área de desarrollo, si bien es un área aislada física y electrónicamente, no se controla el acceso a los computadores dentro de la red, por lo que un usuario puede ver y modificar código que otra persona está construyendo, o en el peor de los casos eliminarlo. Es necesaria la implementación de un mecanismo que controle los accesos a los documentos y fuentes de los proyectos en curso, por seguridad de la empresa y las necesidades de los clientes. 

Ambigüedad en las etapas de un proyecto

Si bien el desarrollo de un aplicativo puede estar dividido en etapas de un proyecto, no existe una relación clara entre las versiones de una determinada fuente y la etapa a la que pertenecen. Esto puede inducir al error, provocando demoras o daños irreparables en el desarrollo del plan de un proyecto. Es una mala práctica en la empresa, el no organizar los elementos de software correctamente, por lo que es necesario una herramienta que permite la gestión de los mismos a lo largo de las distintas etapas de un proyecto, sin que el usuario este consciente de ello, ni que interfiera en sus actividades. 

Historial de versiones

Este es un punto crítico en el desarrollo de las actividades, ya que no se puede hacer seguimiento de los cambios que una persona o equipo realiza sobre el código de un aplicativo. En el ambiente compartido las versiones se reconocen por índices (versión x.x.x), sin embargo suele ocurrir que algunas versiones se pierden y, si existiese un error, no se pueden revertir los cambios. Se requiere una herramienta que permita el ingreso de datos de versionamiento según un estándar definido, para que la posterior auditoria o reversión de cambios sea una tarea sencilla. Además este estándar debe estar acorde con cada etapa del proceso (análisis, diseño, desarrollo, pruebas, QA, etc.)



Creación de ramificaciones

Esto es una consecuencia de la falta de control de accesos y el control ligero de versiones. Dos desarrolladores pueden partir de una versión específica y producir distintos resultados sin control de las variaciones que hayan hecho, esto demora la entrega de un proyecto al tener que combinar o evaluar por separado las versiones. La solución debe contemplar este aspecto que sucede con frecuencia en el ambiente de desarrollo, permitiendo un seguimiento constante de las actividades y acciones de los participantes 

Fundición de código

En los casos en los que dos o más ramas de desarrollo se tuvieran que combinar, el proceso se tiene que realizar manualmente, debido a que no existe una herramienta que haga esa tarea, y menos aún que la documente. Como complemento del requerimiento anterior, se requiere una herramienta que tenga funcionalidades de merging para facilitar la tarea de combinar versiones, sin que esto sea una tarea ardua y lenta. Además, que permita documentar las acciones tomadas en las versiones finales. 

Control de aprobaciones

En la actualidad, la aprobación de versiones se da a través de actas dirigidas al encargado del proyecto. Sin embargo es un proceso tedioso y en algunas ocasiones redundante. Además se puede dar el caso de error y provocar una aprobación inadecuada. Este proceso debe ser automático; las notificaciones deben llegar al responsable instantáneamente y permitirle la revisión y aprobación dentro de la herramienta, de tal forma que sus observaciones queden documentadas de manera estandarizada. 

Descentralización de la información

Acceder a una versión de una fuente o documento en un ambiente descentralizado significa encontrarse con diversas versiones y, en caso aquella revisión no esté dentro del ambiente compartido se debe hacer una búsqueda entre los miembros del equipo. Este procedimiento debe ser eliminado principalmente por el tiempo que demanda y la incertidumbre que existe sobre la veracidad de la versión del elemento. La solución

debe considerar un repositorio centralizado, al que los computadores consultan y actualizan.



Auditoria de cambios

En el ambiente de desarrollo de la empresa, si se realiza algún cambio en una fuente no se puede determinar el responsable de este, esto conlleva posibles malentendidos o efectos en la entrega del producto al cliente. Los cambios deben ser documentados en formularios estandarizados y dentro de una herramienta que los organice, para efecto de evitar ambigüedades. 

Responsabilidades dentro de un proyecto

Actualmente no se controla los permisos que tiene cada desarrollador dentro del ambiente de construcción, y junto a la ausencia de documentación de auditoria, pueden generar fallas no previstas. Es necesario una herramienta en la que se pueda asignar perfiles y permisos a los usuarios dentro de un determinado ambiente o etapa. Esto está relacionado con el control de accesos y el control de aprobaciones. 

Control de pruebas

La realización de pruebas solo se realiza en un ambiente local, por lo que la recopilación de datos se ve limitada. Es imposible realizar copias de un ambiente de producción para ejecutar pruebas en el mismo ambiente. Se debe implementar un ambiente controlado en el cual se puedan realizar pruebas, con la seguridad de que no afectará otros activos, y como complemento, que ofrezca la documentación de estos procedimientos.

CA Harvest (Porpuesta de solución) Debido a la problemática existente en la empresa, el equipo encargado propone la implementación de un sistema de control de cambios, que permitirá resolver los distintos aspectos que dificultan el trabajo diario. El sistema propuesto es el CA Harvest Software Change Manager, una herramienta versátil respecto a las necesidades que presentamos actualmente.

Descripción de la herramienta CASE CA Harvest es una herramienta software para el control de revisiones de código fuente y otros archivos relacionados con el desarrollo de software. Está orientado a la gestión de configuración de software a lo largo de todo el ciclo de vida de este, por lo que está preparado para manejar los siguientes elementos de configuración de software:   

Programas de computador (fuente o ejecutable) Documentación (documentación de análisis/diseño, manuales, etc.) Estructuras de datos (diagramas)

Un ECS es un elemento que se crea a partir del proceso de ingeniería de software. Los siguientes ECS son el objeto de las técnicas de gestión de configuraciones y forman un conjunto de líneas base:           



Especificación del sistema Plan del proyecto software Especificación de requerimientos del software o Prototipo ejecutable o en papel Manual de usuario preliminar Especificación de diseño: o Diseño preliminar o Diseño detallado Listados del código fuente Planificación y procedimiento de prueba o Casos de prueba y resultados registrados Manuales de operación y de instalación Programas ejecutables Manual de usuario Documentos de mantenimiento o Informes de problemas del software o Peticiones de mantenimiento o Órdenes de cambios de ingeniería Estándares y procedimientos de ingeniería del software

La herramienta CA Harvest identifica y gestiona las distintas versionas de un ECS de forma que se puedan introducir cambios eficientemente, así mantiene un registro de las modificaciones. Además asegura la correcta asignación de responsabilidades de aprobación o priorización. Justo a un proceso de correcta estandarización, la herramienta facilita la identificación y relación de distintos ECS que comparten un mismo proyecto u objetivo.

Características del producto (CA Harvest) Instalación:   

Se cuenta con manuales de instalación y manuales de usuario. La media se descarga desde el SITE del proveedor, a través de un código. Derecho de descarga, actualizaciones, parches, documentación, soporte 24x7

Requerimientos de hardware REQUERIMIENTOS HARDWARE PARA ENTORNO WINDOWS CLIENTE

SERVIDOR

Procesador Intel (dual-quad)

Procesador Intel (dual-quad)

Al menos 60MB de espacio en disco para los archivos. Al menos 2GB de RAM

Al menos 2GB de RAM 110MB de espacio en disco para uso temporario durante instalación.

Conexión de red con protocolo TCP/IP a un servidor CA SCM (Software

Al menos 2GB de espacio en disco

Change Manager) corriendo Linux,

para los archivos del producto.

UNIX o Windows. 110MB de espacio en disco para uso temporario durante instalación.

Una base de datos local o remota corriendo una versión soportada de ORACLE o SQL Server

Requerimientos de software REQUERIMIENTOS SOFTWARE PARA ENTORNO WINDOWS

SISTEMAS OPERATIVOS

SISTEMAS OPERATIVOS (LINUX)

(WINDOWS) • Windows 200 server

• Red Hat Enterprise Linux AS 3.0/4.0

• Windows 200 Advanced

• SUSE LINUX Enterprise Server 8

Server

and 9 for x86

• Windows 200 Professional

• Z/OS 1.4, 1.5, 1.6

• Windows Server 2003

• ISPF

Standar SERVIDORES DE BD

• RACF, Top Secret, ACF2 SERVIDOR DE APLICACIONES

• Oracle 9.2, 10g, 11g

• Microsoft IIS 5.0 o superior.

• SQL Server 2000 o superior

• Apache Tomcat 4.1.29 o superior.

Interfaz de usuario La interfaz de usuario es muy similar al navegador de carpetas de Windows. Los proyectos y etapas funcionan como contenedores, y dentro de estos existen diversas carpetas donde se ubican los ECS. Se puede hacer una separación por tipo de elementos según las necesidades del proyecto o etapa.

Figura 5: Interfaz gráfica del CA Harvest

Estructura de trabajo CA Harvest es un SCM de tipo centralizado, quiere decir que el repositorio y herramientas de gestión de encuentran desplegadas en un solo servidor al cual se puede acceder remotamente. Harvest posee una estructura básica de trabajo que permite modelar los procesos según las necesidades de la empresa, ofreciendo para cualquier configuración, las mismas características de seguridad y versatilidad. Esta estructura está compuesta por los siguientes elementos:

Para la construcción de la estructura de trabajo en CA Harvest existen diversos objetos que convierten a la herramienta en una muy versátil y capaz de abarcar diversos procesos que se realizan en la empresa. Existen elementos que sirven para construir espacios en Harvest. Son bastante generales y sirven como contenedores de los demás elementos: 

Proyecto

También conocido como ambiente. Estos pueden ser adecuados a diversas categorías como aplicaciones, organizaciones o áreas de trabajo. Estos ofrecen un marco de control que incluye:



o

División de ramas, para desplegar cambios en ambiente aislado y

o

controlado. Definición de procesos y etapas por las que un determinado ECS debe

o

pasar a lo largo del ciclo de vida. Control de accesos para las etapas y ECS.

Usuario

O grupo de usuarios. Son los perfiles de los usuarios que ingresan a la herramienta. Sirven para registrar la actividad que realizan y para asignarles vista a las determinadas etapas de un proyecto. 

Repositorio

Es el espacio donde todos los elementos de configuración de software se guardan. Es un espacio centralizado, además ofrece soporte para acceso remoto y clusterizado. Existen otros objetos de construcción en Harvest, pero estos son utilizados para crear los ciclos de vida dentro de un proyecto. Estos objetos son los siguientes: 

Etapas

Son áreas específicas dentro de un proyecto, en la cual ciertas actividades toman lugar y solo ciertos procesos pueden aplicados a los paquetes que estén dentro. También permiten delimitar espacios a los cuales se quiere que solo determinados usuarios accedan. 

Paquetes

Son la unidad básica de trabajo. Representan solicitudes de cambio, por lo que almacenan diversos tipos de elementos de configuración. Dentro de un paquete existe subespacios para la mejor ubicación de los ECS: espacios para los códigos, documentación y diagramas. Los paquetes permiten que los elementos pasen a través de las distintas etapas de un proyecto como un conjunto, por lo cual la tarea de seguimiento es más sencilla. Los paquetes también se pueden agrupar en caso existan varios requerimientos o la envergadura del proyecto sea mayor. 

Vistas

Una vista dentro de un proyecto permite que los cambios sean aislados y mejor administrados. Las vistas están integradas al ciclo de vida, pues están asociadas a una o más etapas. Varias etapas pueden compartir una misma vista, pero una etapa no puede estar asociada a más de una vista. De esta forma, las vistas determinan que versiones son accesibles a los usuarios.

Ciclo de Vida Están compuestos por diversas etapas configurables, por las que los ECS deben pasar. En cada una se puede controlar el acceso y aprobación. Una vez definido el ciclo, Harvest ofrece herramientas de auditoria para controlar la actividad dentro de cada etapa de los ciclos de vida. Un ciclo de vida describe el camino que los cambios toman mientras se lleva a cabo el desarrollo, en términos de etapas ordenadas. En cada etapa, los procesos definen una serie de actividades que ocurren, esto quiere decir que existe un único flujo de trabajo. La aprobación o rechazo tiene una importancia especial dentro del ciclo de vida ya que estos determinan como están relacionadas las etapas y como los elementos pueden trasladarse. Las distintas opciones de vista permiten definir cuáles versiones estarán disponibles para los usuarios. Un ciclo de vida por ejemplo puede ser el siguiente: Requerimiento, desarrollo, testing, QA y producción. En el diagrama una flecha indica un proceso de promoción de un paquete de una etapa a otra.

Figura 6: Diagrama del ciclo de vida de un software

Funcionalidades del CA Harvest Atributos Internos de la herramienta  Control de versiones -

Almacenar versiones de cualquier elemento o archivo.

-

Permitir un número limitado de versiones.

-

Bloqueo de archivos en el sistema, evitando que otros usuarios la editen.

 Gestión del desarrollo -

Facilitar el desarrollo de versiones por incrementos.

-

Permitir la creación de versiones antiguas del sistema.

 Gestión de procesos -

Definir claramente las etapas de desarrollo.

-

Visualizar gráficamente el modelo de procesos.

 Gestión de datos -

Proporcionar recursos para la recuperación de datos.

-

Clasificar archivos relacionados en grupo de archivos.

 Seguridad -

Solicitar Autenticación del usuario para ingresar al aplicativo.

-

Soportar un sistema de control para la auditoria de cambios a las versiones.

Atributos externos de la herramienta  Interoperabilidad con el equipamiento informático Institucional Las bases de datos de la empresa se encuentran bajo el soporte de equipos informáticos de diferente tecnología informática, el software debe es compatible y puede operar sin restricciones, permitiendo la generación de respaldos y recuperaciones. Asimismo permite la integración con las diferentes herramientas de desarrollo utilizadas en la empresa.

 Administración de Usuarios, Roles y Perfiles Permite fijar roles y responsabilidades para la administración y seguimiento del ciclo de vida, con distintos niveles de autorización a nivel de usuario o de grupo de usuario.  Flexibilidad a los Estándares Informáticos Existentes Si bien el software se basa en estándares propios, permite flexibilidad y versatilidad para la realización de operaciones con el estándar existente en los sistemas de procesamiento de la empresa, así como servir de soporte al estándar existente.

Atributos de uso de la herramienta  Entorno amigable CA Harvest tiene un diseño intuitivo en la interface administrativa como en la interface web beneficiando a usuarios nuevos y avanzados además reduce la cantidad de entrenamiento necesario para aprender cómo navegar a través de la funcionalidad de la herramienta. Por otra parte, esta herramienta CASE permite visualizar gráficamente el histórico de versiones y el ciclo de vida de las aplicaciones; asimismo comparar versiones, invocar procesos y administración de preferencias.  Facilidad de uso Permite la ejecución de procesos definidos por el usuario (UDP), mecanismo por el cual permite ejecutar cualquier tipo de script. Además permite volver atrás los cambios realizados de una manera eficaz y controlada, en forma automática, de acuerdo a como se definan los ambientes de desarrollo, test, producción, etc. Es por estas razones que posee facilidades para la administración de cambios y control de código fuente, permitiendo administrar en forma simple el crecimiento de las aplicaciones. Otra facilidad que ofrece la herramienta es que automatiza la elaboración de informes proporcionando un conjunto predefinido de informe, además de los estandarizados.  Productividad y desempeño Esta herramienta CASE soporta una arquitectura de múltiples capas para lograr un alto nivel de escalabilidad dado que permite la configuración de múltiples servidores de la empresa para una mayor eficiencia. Por otra parte ofrece tiempos cortos de respuesta para las funciones de salida y registro; y tiempos de respuesta aceptable para informes históricos de las migraciones. Asimismo, ofrece buen desempeño incluso cuando aumenta el tamaño y número de las aplicaciones. Otra ventaja es que minimiza tanto

la sobrecarga de almacenamiento para múltiples versiones de archivos, como l sobrecarga necesaria para versiones paralelas de una aplicación y el tráfico en la red a través de la compresión de archivos.  Facilidad de Fusión Una vez que está listo para ser integrado, el código puede ser administrado a través de la fusión integrada de fusión (merge), permitiéndole visualizar y resolver conflictos entre versiones. La facilidad integrada de fusión le permite automatizar la fusión de algunos o todos los cambios de una aplicación dentro de un proceso de desarrollo subsiguiente, eliminando fusiones manuales muy complicadas y conducentes a errores. Los proyectos a corto y a largo plazo pueden ser desarrollados en paralelo sin afectarse entre sí.  Alertas y Notificaciones Permite enviar notificaciones a usuarios o grupos de usuario cuando se cumpla alguna etapa o bien cuando ocurra un problema. Para esto se integra con los servicios de correo electrónico usados en la empresa. Asimismo asocia migraciones a archivos específicos o grupo de archivos de desarrollo y activa auténticamente notificaciones y/o aprobaciones.

Análisis Comparativo Costo-Beneficio Los costos asociados a esta herramienta CASE viene detalla en la siguiente tabla: CA HARVEST SCM

PRECIO UNITARIO (POR CLIENTE)

Licencia del uso del Producto

18,561.40

Servicio Anual del Soporte y Mantenimiento TOTAL COSTO

35,233.00 53,794.40

Los beneficios de adquirir esta herramienta CASE son: 

Controlar el ciclo de vida de las aplicaciones de software de la empresa, la automatización de tareas y procesos de desarrollo, control de accesos y seguridad de repositorio centralizado de fuentes de los diferentes objetos de las aplicaciones.



Mantener el control, resguardo y seguridad en la administración de las versiones programadas, objetos y procedimientos de bases de datos, para



todas las aplicaciones existentes en la empresa. Contribuirá, a través de la integración de gestión de servicios existente, al aumento de la eficiencia del proceso de mantenimiento, la productividad y la



capacidad de respuesta de operaciones de TI. La facilidad integrada de fusión permitirá automatizar la interrelación de los cambios de una aplicación dentro de un proceso de desarrollo subsiguiente, los cuales pueden ser desarrollados en paralelo sin afectarse entre sí.

¿Por qué usar CA Harvest?        

Entorno amigable y Facilidad de uso Soporte amplio para plataformas Productividad y desempeño Facilidad de fusión Alertas y Notificaciones Control del ciclo de vida de las aplicaciones Resguardo y seguridad es la administración de la base de datos. Estandariza procesos

Casos de Aplicación Claro En el año 2010, la empresa de telecomunicaciones Claro comenzaba a implementar una arquitectura orientada a los servicios (SOA), debido a los beneficios que esta significaba. Este tipo de arquitectura le permitiría mantener mejor los sistemas y convertirlos en escalables, un requisito necesario debido a la creciente demanda de servicios de telecomunicación. Esta forma de trabajar requiere que cada necesidad funcional se codifique y convierta en un servicio, de esta forma sería accesible a otros componentes y serviría como pieza para los distintos procesos de negocio de la empresa.

A partir de un inventario de servicios disponible, se forman composiciones de estos para determinados procesos de negocio. La arquitectura orientada a servicios pone a disposición de la institución elementos altamente reutilizables y fáciles de mantener en el tiempo. El desarrollo de los servicios, traía consigo un conjunto de documentos, como son los de análisis y diseño, pruebas, manuales de instalación y operación, entre otros elementos que surgían durante este proceso. La cantidad de documentación demandaba una gestión controlada, de forma que sea de fácil de acceso y consultar en desarrollos posteriores. Los proveedores de Claro exigían acceso a la información para cumplir con los requerimientos de Claro, y este último, requería que el acceso sea controlado y fácil de auditar. En un primer escenario, se dispuso trabajar con un ECM como repositorio de versiones. El sistema elegido fue Alfresco, sin embargo este no cumplía con las exigencias de seguridad que eran requeridas. Luego de varias propuestas, se decidió utilizar la herramienta CA Harvest, porque ofrecía un rápido despliegue y alineación con los procesos y proyectos que se realizaban en la empresa. Además controlaba la seguridad de acceso, necesaria para la información. De esta forma los proveedores podían acceder a la documentación de manera controlada y segura. Por último, ofrecía el adecuado control de versiones para la cantidad de documentación generada durante los desarrollos.

En la actualidad, CA Harvest esta implementado en un clúster, ya que el tráfico interno y externo son altos. CosapiData y Everis, dos de sus proveedores más cercanos acceden a la información de manera controlada, y está se documenta según los estándares de Claro.

BCRP El software CA Harvest se utiliza para mantener actualizadas las versiones de los productos software desarrollados por la Gerencia de Tecnologías de Información (GTI) y para la administración y registro de los programas, lo cual es necesario para la salvaguarda de los Sistemas de Información. Esta herramienta CASE:  Es utilizado en la gestión, administración y almacenamiento de los programas y objetos de los Sistemas del BCRP.  Permite el control del ciclo de vida de aplicaciones de software.  Permite el control de accesos y seguridad del repositorio centralizado de fuentes de los diferentes objetos de las aplicaciones. Este software viene usándose en el Banco desde el año 2002, y por su carácter imprescindible, dicho software se encuentra estandarizado.

Conclusiones y Recomendaciones Entre las conclusiones que obtuvimos están las siguientes:     

Con la herramienta case CA Harvest se lograria un aumento de la eficiencia del proceso de mantenimiento y control del uso y procesamiento de datos. Apoyaria en la automatización de la interrelación de los cambios de una aplicación Reducción de los tiempos del ciclo del proyecto Mnimización de errores dentro del proyecto con el registro y control de versions Reducción de costos a largo plazo

Bibliografía  https://es.wikipedia.org/wiki/Herramienta_CASE  http://es.slideshare.net/guestf131a9/herramientas-case  http://paulchasiluisa.galeon.com/  http://tpsis324.blogspot.com/2008/09/4-ventajas-y-desventajas.html  http://www.reniec.gob.pe/Transparencia/intranet/imagenes/noticias/comunicado /Informe_Tecnico_Change_Manager.pdf  http://www.ca.com/ar/devcenter/ca-harvest-software-change-manager.aspx  http://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones 