DISEO Y DESARROLLO DE UN SISTEMA DE PAGOS DE LAS TARJETAS DE CRDITO A LA WEB DE UN BANCO.

JORGE ANDRS BLANCO ESCOBAR

SENA SERVICIO NACIONAL DE APRENDIZAJE. CALIDAD DEL SOFTWARE. FUNDAMENTOS DE LA CALIDAD DEL SOFTWARE-293733 BOGOT 2012

DISEO Y DESARROLLO DE UN SISTEMA DE PAGOS DE LAS TARJETAS DE CRDITO A LA WEB DE UN BANCO.

JORGE ANDRS BLANCO ESCOBAR

MILTON MANUEL ORTIZ.

SENA SERVICIO NACIONAL DE APRENDIZAJE. CALIDAD DEL SOFTWARE. FUNDAMENTOS DE LA CALIDAD DEL SOFTWARE-293733 BOGOT 2012

CONTENIDO

INTRODUCCIN 1. PLANTEAMIENTO DEL PROBLEMA 1.1 DESCRIPCIN DEL PROBLEMA 1.2 FORMULACIN DEL PROBLEMA 1.3 SISTEMATIZACIN DEL PROBLEMA 2. JUSTIFICACIN 3. OBJETIVOS 3.1 OBJETIVO GENERAL 3.2 OBJETIVOS ESPECFICOS 4. METODOLOGA DE DESARROLLO 4.1 MEJORES PRCTICAS DEL PROCESO UNIFICADO RACIONAL RUP 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 Desarrollo iterativo del software. Administracin de requerimientos. Uso de arquitecturas basadas en componentes. Modelamiento visual del software. Verificacin de la calidad del software. Control de cambios.

4.2 CICLOS Y FASES RUP 4.2.1 4.2.2 4.2.3 4.2.4 Inicio. Elaboracin Construccin Transicin

4.3 CRONOGRAMA CONCLUSIONES BIBLIOGRAFA

INTRODUCCIN

En la actualidad el uso de l internet es uno de los factores que han permitido que las personas interacten con sistemas de informacin online, que ha facilitado la calidad de vida. Antes para pagar un servicio, realizar una consignacin, tenamos que ir hasta el banco, soportar una fila incomoda, pero gracias a que los sistemas de informacin han migrado hacia la red, hoy es posible pagar un servicio o realizar una consignacin a travs de internet. El diseo y desarrollo de un sistema que nos permita trasladar la operacin de los pagos de las tarjetas de crdito a internet, permitir a los usuarios del banco facilitar el uso del servicio, sin la necesidad de trasladarse al banco y realizar el pago de forma manual, teniendo una disponibilidad de 24 horas al da, y con toda la seguridad informtica frente a usuarios malintencionados. El sistema de informacin de traslado de operaciones de los pagos de las tarjetas de crdito a la web, ser diseado y desarrollado por los profesionales de nuestra compaa, con ayuda de los usuarios y empleados del banco, aplicando un modelo de calidad y los estndares, para brindarles un producto software de calidad. Para el diseo y desarrollo del software, utilizaremos la metodologa de desarrollo RUP (Rational Unified Process), ya que es una forma disciplinada de asignar tareas y responsabilidades, asegurar la produccin de software de calidad dentro de plazos y presupuestos predecibles. Es dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental.

1. PLANTEAMIENTO DEL PROBLEMA

1.1 DESCRIPCIN DEL PROBLEMA

En la actualidad el pago de los saldos de las tarjetas de crdito se lleva de forma manual, en donde los usuarios deben trasladarse al banco de acuerdo a una fecha determinada para realizar el pago de su tarjeta de crdito, lo cual es una tarea muy tediosa e incmoda, porque tienen que soportar filas muy largas, la disponibilidad del horario no les facilita el pago ya que mucho estn en horas laborales y los usuarios no estn satisfechos con el servicio prestado.

1.2 FORMULACIN DEL PROBLEMA

De qu manera se puede realizar el pago de los saldos de las tarjetas de crdito de los usuarios, sin la necesidad de realizar el pago manual en el banco, mejorando el servicio? 1.3 SISTEMATIZACIN DEL PROBLEMA Cmo es el proceso de los pagos de los saldos de las tarjetas de crdito? Los usuarios tienes otro mtodo distinto, para hacer el pago de los saldos de su tarjeta de crdito, diferente al de ir al banco? Cul es el tiempo de respuesta para un usuario que va realizar su pago, si hay demasiada congestin? Cul es la disponibilidad de tiempo del banco, cuando hay demasiada congestin? Cuntos usuarios estn inconformes con el servicio del banco, en cuanto al pago de los saldos de las tarjetas de crdito de forma manual?

2. JUSTIFICACIN

La falta de un sistema de informacin, que permita a los usuarios realizar sus pagos de saldos de su tarjeta de crdito online, ocasiona largas filas e incomodidad de los usuarios, prdida de clientes por que estn insatisfechos por el servicio y porque les hace perder demasiado de tiempo. Con la implementacin de un sistema de pago de las tarjetas de crdito a internet, se permitir a los usuarios la facilidad de realizar sus pagos online las 24 horas del da, consultar su informacin de saldos, reducir costos, prdida de tiempo por las largas y tediosas filas, automatizar el proceso de pago de saldo de tarjetas crdito.

3. OBJETIVOS

3.1 OBJETIVO GENERAL Disear y Desarrollar un sistema de pago de los saldos de las tarjetas crdito online. 3.2 OBJETIVOS ESPECFICOS Disear una interfaz de fcil uso, para que los usuarios puedan realizar los pagos de saldos de sus tarjetas de crdito online. Mejorar el servicio en el pago de saldos de las tarjetas de crdito por medio de un sistema online. Consultar toda la informacin referente al estado de la cuenta de la tarjeta de crdito. Facilitar a los usuarios el medio de pago de sus tarjetas de crdito online, las 24 horas del da.

4. METODOLOGA DE DESARROLLO El Proceso Unificado Racional RUPes un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational. El proceso describe qu entregables producir, cmo desarrollarlos y tambin provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administracin de cambios y las pruebas. Se enfoca en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de rehus. Las fases del ciclo de vida del software son: inicio, elaboracin, construccin y transicin. El inicio es definir el alcance del proyecto y definir el caso de uso. La elaboracin es proyectar un plan, definir las caractersticas y cimentar la arquitectura. La construccin es crear el producto y la transicin es transferir el producto a sus usuarios [Booch 1998]. Caractersticas Esenciales del Proceso Unificado Racional RUP. Proceso Dirigido por los Casos de Uso. Proceso Iterativo e Incremental. Proceso Centrado en la Arquitectura. 4.1 MEJORES PRCTICAS DEL PROCESO UNIFICADO RACIONAL RUP 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 Desarrollo iterativo del software. Administracin de requerimientos. Uso de arquitecturas basadas en componentes. Modelamiento visual del software. Verificacin de la calidad del software. Control de cambios.

4.1.1 Desarrollo Iterativo del Software El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada. Un proceso iterativo permite una comprensin creciente requerimientos a la vez que se va haciendo crecer el sistema. de los

UP sigue un modelo iterativo que aborda las tareas ms riesgosas primero. Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.

4.1.2 Administracin de Requerimientos RUP describe cmo: Obtener los requerimientos Organizarlos Documentar requerimientos de funcionalidad y restricciones Rastrear y documentar decisiones Captar y comunicar requerimientos del negocio

Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseo, la implementacin y las pruebas. 4.1.3 Arquitectura Basada en Componentes El proceso se basa en disear tempranamente una arquitectura base ejecutable. La arquitectura debe ser: Flexible Fcil de modificar Intuitivamente comprensible Promueve la reutilizacin de componentes UP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

4.1.4 Modelamiento Visual Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes. Bloques de construccin: Ocultan detalles Permiten la comunicacin en el equipo de desarrollo

Permiten analizar la consistencia: entre las componentes entre diseo e implementacin. UML es la base del modelamiento visual de RUP.

4.1.5 Verificacin de la Calidad del Software No slo la funcionalidad es esencial, tambin el rendimiento y la confiabilidad. UP ayuda a planificar, disear, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades. El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.

4.1.6 Control de Cambios Los cambios son inevitables, pero es necesario evaluar si stos son necesarios y rastrear su impacto. RUP indica cmo controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo. 4.2 CICLOS Y FASES DE RUP RUP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada ciclo. Cada ciclo se divide en cuatro Fases:

4.2.5 4.2.6 4.2.7 4.2.8

Inicio. Elaboracin Construccin Transicin

Fig. 1 Fases de RUP

Fuente: El Modelo Proceso Unificado,http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones. 4.2.1 Fase 1 Inicio Se establece la oportunidad y alcance el proyecto. Se identifican todas las entidades externas con las que se trata (actores) y se define la interaccin a un alto nivel de abstraccin: Identificar todos los casos de uso. Describir algunos en detalle. La oportunidad del negocio incluye: Criterios de xito Identificacin de riesgos Estimacin de recursos necesarios Plan de las fases incluyendo hitos

Productos Un documento de visin general: Requerimientos generales del proyecto Caractersticas principales Restricciones Modelo inicial de casos de uso (10% a 20 % listos). Glosario. Caso de negocio: Contexto Criterios de xito Pronstico financiero Identificacin inicial de riesgos. Plan de proyecto. Uno o ms prototipos.

4.2.2 Fase 2 Elaboracin Objetivos: Analizar el dominio del problema. Establecer una arquitectura base slida. Desarrollar un plan de proyecto. Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto. Visin de una milla de amplitud y una pulgada de profundidad porque las decisiones de arquitectura requieren una visin global del sistema. Productos Es la parte ms crtica del proceso: Al final toda la ingeniera dura est hecha Se puede decidir si vale la pena seguir adelante A partir de aqu la arquitectura, los requerimientos y los planes de desarrollo son estables. Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre. Se construye una arquitectura ejecutable que contemple: Los casos de uso crticos Los riesgos identificados Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no funcionales o no asociados a casos de uso.

Descripcin de la Arquitectura del Software. Un prototipo ejecutable de la arquitectura. Lista revisada de riesgos y del caso de negocio. Plan de desarrollo para el resto del proyecto. Un manual de usuario preliminar.

4.2.3 Fase 3 Construccin En esta fase todas las componentes restantes se desarrollan e incorporan al producto. Todo es probado en profundidad. El nfasis est en la produccin eficiente y no ya en la creacin intelectual. Puede hacerse construccin en paralelo, pero esto exige una planificacin detallada y una arquitectura muy estable.

Productos El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario. Una descripcin del relase actual.

4.2.4 Fase 4 Transicin El objetivo es traspasar el software desarrollado a la comunidad de usuarios. Una vez instalado surgirn nuevos elementos que implicarn nuevos desarrollos (ciclos). Incluye: Pruebas Beta para validar el producto con las expectativas del cliente Ejecucin paralela con sistemas antiguos Conversin de datos Entrenamiento de usuarios Distribuir el producto

4.3 CRONOGRAMA
Fase Fase de Inicio Fase de Elaboracin Fase de Construccin Fase de Transicin Nro. Iteraciones 2 2 2 Duracin 4 semanas 4 semanas 12 semanas 4 semanas

CRONOGRAMA FASE 1 DE INICIO

Disciplinas / Artefactos generados o modificados durante la Fase de Inicio Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visin Modelo de Casos de Uso Especificacin de Casos de Uso Especificaciones Adicionales Anlisis / Diseo Modelo de Anlisis / Diseo Modelo de Datos Implementacin Prototipos de Interfaces de Usuario Modelo de Implementacin Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Gestin de Cambios y Configuracin Gestin del proyecto Plan de Desarrollo del Software en su versin 1.0 y planes de las Iteraciones Ambiente Comienzo Aprobacin

Semana 1

Semana 3

Semana 1 Semana 2 Semana 3 Semana 3 Semana 3

Semana 3 Semana 3 siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase

Semana 2 Semana 2

Semana 3 Semana 3

Semana 3

Semana 3

siguiente fase Durante todo el proyecto Semana 1 Semana 4

Durante todo el proyecto

CRONOGRAMA FASE 2 DE ELABORACIN.

Disciplinas / Artefactos generados o modificados durante la Fase de Elaboracin Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visin Modelo de Casos de Uso Especificacin de Casos de Uso Especificaciones Adicionales Anlisis / Diseo Modelo de Anlisis / Diseo Modelo de Datos Implementacin Prototipos de Interfaces de Usuario Modelo de Implementacin Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Gestin de Cambios y Configuracin Gestin del proyecto Plan de Desarrollo del Software en su versin 2.0 y planes de las Iteraciones Ambiente Comienzo Aprobacin

Semana 1

aprobado

Semana 1 Semana 2 Semana 3 Semana 3 Semana 3

aprobado aprobado Semana 5 Semana 5 Semana 5

Semana 2 Semana 2

Revisar en cada iteracin Revisar en cada iteracin Revisar en cada iteracin Revisar en cada iteracin Revisar en cada iteracin

Semana 3 Semana 3

Semana 3

Semana 3

Revisar en cada iteracin Durante todo el proyecto Semana 4 Revisar en cada iteracin Durante todo el proyecto

CRONOGRAMA FASE 3 DE CONSTRUCCIN.

Disciplinas / Artefactos generados o modificados durante la Fase de Construccin Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visin Comienzo Aprobacin

Semana 1

Semana 3

Semana 1 Semana 2 Semana 3 Semana3 Semana 6 Semana 6 Semana 8 Semana 9

Semana 3 Semana 3

Modelo de Casos de Uso

Semana 6

Especificacin de Casos de Uso

Semana 9

Especificaciones Adicionales Anlisis / Diseo Modelo de Anlisis / Diseo

Semana 10

Semana 3 Semana 4 Semana 3Semana 4

siguiente fase siguiente fase

Modelo de Datos

Implementacin Prototipos de Interfaces de Usuario Modelo de Implementacin Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Gestin de Cambios y Configuracin Gestin del proyecto Plan de Desarrollo del Software en su versin 3.0 y planes de las Iteraciones Ambiente

Semana 10 Semana 10

siguiente fase siguiente fase siguiente fase

Semana 11

Semana 11

siguiente fase Durante todo el proyecto Semana 1 Semana 12

Durante todo el proyecto

CRONOGRAMA FASE 4 DE TRANSICIN

Disciplinas / Artefactos generados o modificados durante la Fase de Transicin Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visin Modelo de Casos de Uso Especificacin de Casos de Uso Especificaciones Adicionales Anlisis / Diseo Modelo de Anlisis / Diseo Modelo de Datos Implementacin Prototipos de Interfaces de Usuario Modelo de Implementacin Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Gestin de Cambios y Configuracin Gestin del proyecto Plan de Desarrollo del Software en su versin 1.0 y planes de las Iteraciones Ambiente Comienzo Aprobacin

Semana 1

Semana 3

Semana 1 Semana 2 Semana 3 Semana 3 Semana 3

Semana 3 Semana 3 Semana 4 Semana 4 Semana 4

Semana 2 Semana 2

Semana 4 Semana 4

Semana 3 Semana 3

Semana 4 Semana 4

Semana 3

Semana 4

Semana 3

Semana 4

Durante todo el proyecto Semana 1 Semana 4

Durante todo el proyecto

CONCLUSIONES

La calidad en el diseo y desarrollo de software, es uno de los principales objetivos estratgicos de las organizaciones. La garanta del software es un diseo planificado y sistemtico de acciones que se requieren para asegurar la calidad del software. La ingeniera de software es el proceso mediante el cual se transforman las necesidades de los usuarios en requerimientos, para disear una solucin tecnolgica se software que permita satisfacer los requerimientos, a travs de un proceso de anlisis, diseo y codificacin e integracin-validacin, siempre aplicando los estndares de calidad en cada una de las fases. En el diseo y desarrollo de software debe existir siempre un modelo de calidad conformado por los factores de calidad, los criterios de calidad del producto y las mtricas del producto. Un plan de administracin de riesgos, en el proceso de diseo y desarrollo de software es muy importante, ya que a travs de un anlisis de costos, tiempo, herramientas tcnicas, metodologa y recurso humano, podremos minimizar al mximo los posibles riesgos, identificndolos y creando un plan de contingencia para la calidad de nuestro producto software. RUP es una metodologa de desarrollo que se aplica para grandes proyectos de diseo de software, se divide en 4 fases inicio, elaboracin, construccin y transicin. Entre sus caractersticas principales tenemos que es iterativo e incremental, guiado por los casos de uso. RUP, describe como obtener los requerimientos, documentarlos y captar requerimientos del negocio. organizarlos,

Cada fase en RUP, tiene iteraciones, una iteracin es un ciclo de desarrollo completo dando como resultado una entrega de un producto ejecutable. RUP define roles que se distribuyen entre los miembros del proyecto, definiendo las tareas de cada uno y el resultado (artefactos) que se espera.

 RUP es iterativo porque cada fase se realiza en varias iteraciones cada una con un objetivo definido, es incremental porque cada ciclo se agrega un incremento que es un conjunto de casos de uso. RUP es guiado por los casos de uso, centrado en la arquitectura. El nombre Proceso Unificado UP se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003).

BIBLIOGRAFA

http://www-306.ibm.com/software/awdtools/rup/ http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/ http://es.wikipedia.org/wiki/Proceso_Unificado The Rational Unified Process: An Introduction. Philippe Kruchten. Addison-Wesley Professional; 2 edition (March 14, 2000)