ANALISIS Y DISEÑO A TRAVES DEL ESTANDAR IEEE830

MATERIA: INGENIERIA DE SOFTWARE

DOCENTE: JHON FREDY ZABALA

Básicamente el Análisis se Baso en los siguientes Puntos:

• Definir el Cliente, Proveedor y Usuarios.•Definir la Naturaleza.•Definir el Ambiente.•Características del Ambiente.•Definición de Tbds.•Definir Importancia y Estabilidad.•Prototipos•Diseño del Sistema.

•El Sistema a Definir es el Aplicativo para la Radicación de Reclamos de Tarjeta Crédito de una Entidad Financiera, con el fin de crear una Interfaz practica y efectiva en el momento de la Radicar el Reclamos con respecto a las tipologías de Cuota de Manejo y Fraudes, donde se validen al iniciar el reclamo el cumplimiento de las Políticas que el Proveedor a establecido para la Radicación de los mismos.

•Definición de Usuarios:

•Usuario Administrativo: 2 Usuarios Administradores: Que se encargaran de Buscar, Eliminar, Modificar, Ingresar, Borrar, Crear y Consultar la Base de Datos.

•Usuario Cliente: 1 Usuario: El que se encarga de Crear, Borrar, Ingresar y Consultar la base datos.Cargos: Tecnólogos o Técnicos en Sistemas. •Usuario final: 9 Que se encargaran de Consultar e Ingresar a la base de datos.Cargos: Profesionales en Áreas Administrativas o Niveles Tecnólogos con conocimientos en Sistemas. •Interfaces:2.1.2. Las interfaces Externas:Este Sistema interactúa con la Base de Datos de el Cliente y otra Base de Datos de los Productos con los que Cuenta éste. Estas Bases de datos estarán hechas en Oracle y tendrán una Interfaz de usuario hecha en HTML y JAVA. Además se deberá implementar el Middleware. 

  

Las Restricciones del diseño que impusieron en una Aplicación. Requerimiento para el manejo de imágenes en cada interfaz del usuario: deberá validar que cada reclamo contenga las cartas y documentación requeridas para la creación del reclamo, ya que esta inconsistencia no dejaría grabar el reclamo. El sistema deberá ser flexible en cuanto a su interfaz de botones en todas las ventanas de navegación, el idioma utilizado será el español, que deberá tener conceptos y palabras conocidas al ambiente donde se va trabajar el sistema. La base de datos que almacenara la información de los reclamos deberá contener llaves de acceso únicas, para acceder a los datos directamente, además la interfaz deberá validar datos en el momento de ingresarlos ya que informara cuando el usuario digite o ingrese un dato errado en algún campo.

•Representación hecha con herramientas Esta representación corresponde a todas las ventanas de la aplicación que en este caso se manejaran con los siguientes botones:   DocumentaciónAnálisisRespuestaCambio de etapa

 

  

•Modelo Diagrama de Flujo del Sistema Actual: 

 

  

•Prototipos del Sistema Actual: Ingreso al Sistema

 

 

  

•Prototipos del Sistema Actual: Radicación de Reclamos

 

 

  

•Prototipos del Sistema Actual: Datos de el Cliente:

 

 

  

•De acuerdo al Estándar IEEE 830: se Deben manejar los Siguientes:•Propósito•Ámbito del Sistema•Tiempos de Entrega•Matriz de Costos•Perspectiva del Producto•Funciones del producto•Suposiciones y Dependencias•Requisitos Futuros•Modelo Propuesto•Requisitos de Rendimiento.•Apéndices: Pantallazos propuestos, Actas de Servicio, Cronograma de Trabajo.

 

 

  

•Matriz de Costos:

 

 

  

•Tiempos de Entrega:

 

 

  

•Diagrama Propuesto:

 

 

  

•Requisitos del Sistema: Se requiere un Servidor con estas Características:Servidor RACK Supermicro de alta densidad 2 CPU INTEL XEON 5420 QUAD CORE 2,33Ghz (8 cores) Memoria 8GB FB DDR2 667Mhz ECC Registrada Discos duros SATA150 10.000 RPM Sistema Operativo 2003 ServerSoftware Manejador de Bases de Datos en Oracle 10GSoftware Macromedia Dream Weaver, JDK SOFTWARE DE JAVA 1.6,Se Requiere un Middleware JSP que es el Lenguaje que hace la Consulta entre la Pagina Web y la Base de Datos.Se requiere una Red LAN Tipo Cliente Servidor.

           

 

 

  

 

Apéndices :Nuevas Pantallas Propuestas en la Radicación de Reclamos:

          

 

 

  

 

Apéndices :Nuevas Pantallas Propuestas en la Radicación de Reclamos con validación de Documentos:

          

 

 

  

 

Apéndices :Nuevas Pantallas Propuestas en la Radicación de Reclamos con validación de Documentos:

          

 

 

  

 

El Estándar IEEE830 nos recomienda la Utilización de el Lenguaje UML para el Diseño de los procesos que maneja el Sistema, entre estos los Diagramas a utilizar son:•Diagramas de Casos de Uso•Diagramas de Secuencia de Procesos

          

 

 

  

 

•Diagramas de Casos de Uso de Ingreso al Sistema por el Usuario Administrador:

          

 

 

  

 

•Diagramas de Casos de Uso de Ingreso al Sistema por el Usuario Final:

          

 

 

  

 

•Diagramas de Casos de Uso de Documentación de Reclamos por el Usuario Final:

          

 

 

  

 

•Diagrama de Secuencia para la Eliminación de Información de el Usuario Administrador y Final:

          

 

 

  

 

Este es un Software para la Radicación de Reclamos del Área de Tarjeta de Crédito de una Entidad Financiera, en éste se realizo la Modificación de las Interfaces de las Tipologías de Cuota de Manejo y Fraudes, esto con el fin de realizar un Filtro antes de la Radicación de los Reclamos y evitar así el gran Volumen de Radicaciones que realiza la Oficina y el Vencimiento de los mismos por la Falta de Documentos e Información. En la Tipología de Cuota de Manejo se realizo una Modificación al Modelo que actualmente maneja el Sistema, ya que no estaba enlazando la Información de el Producto y por ésta razón se radicaban reclamos sin ningún fundamento ya que no se había realizado la Validación de las Políticas para esta Tipología de Reclamos. En la Tipología de Fraudes se realizo una Validación de Documentos que anexan las Oficinas cuando realizan la Reclamo, allí el Sistema le exigirá al Usuario el Anexo de los Documentos correspondientes de lo Contrario no lo deja Radicar. Así con la Modificación Propuesta se mejoraría el volumen de Reclamos que hacen las Oficinas y por ende la Carga Laboral que generaba a los Analistas que realizaban el proceso.

          

 

 

  

 De acuerdo al estándar IEEE830 las Pruebas a Realizar en un Sistema deberán ser de Dos Clases:

•Pruebas de Caja Negra: Referentes a las que se realizan mediante el Código de la Aplicación.

•Pruebas de Caja Blanca: Referentes a las que se realizan con la Interfaz y su Validación de los Datos.

          

 

 

  

 Pruebas de Caja Negra: INGRESO AL SISTEMA CON EL USUARIO Y CONTRASEÑA

  DESCRIPCIÒN: En ésta pantalla se muestra el Ingreso a la Aplicación digitando el Usuario y la Clave.

El código de éste acceso es éste:

   

          

 

 

  

Pruebas de Caja Negra:Si realizamos la Modificación de éste Código en el comando donde se valida la contraseña: If txtPassword = "456" Then por If txtPassword = "456 Then Nos arrojara el Siguiente Pantallazo de Error:

 

          

 

 

  

Pruebas de Caja Blanca: PRUEBA DE INGRESO AL SISTEMA CON CONTRASEÑA INVALIDA:

 

       En este pantallazo se muestra cuando el Usuario digita el Número de su Contraseña Invalido y su respectivo error: