Retomando el caso identificado en la actividad 2 realiza lo siguiente: Analiza el caso e identifica el uso de los forma
Views 26 Downloads 0 File size 327KB
Retomando el caso identificado en la actividad 2 realiza lo siguiente:
Analiza el caso e identifica el uso de los formatos PSP0 Identifica el tipo de información que se proporciona y su aplicación. Explica la importancia del uso de las herramientas PSP0 para el desarrollo de programas. Al finalizar, integra tu actividad en un documento con datos de identificación completos, posteriormente guárdala con la nomenclatura DMS_U1_EA_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. Consulta La rúbrica de la actividad para que consideres los aspectos a evaluar. Envía tu Evidencia de aprendizaje al docente en línea mediante el Portafolio de evidencias. Espera y atiende la retroalimentación correspondiente.
En la actividad anterior me adelanté un poco e implementé varios de los formatos que se utilizan para PSP, por lo cual en esta actividad retomo varios de los formatos que exhibí en la actividad anterior para efectos de la evidencia de aprendizaje. En la empresa en la que trabajo nos dedicamos a la validación de ficheros médicos a través de nuestro Call Center, esto quiere decir que contamos con un equipo de operadores que se dedican a llamar a los médicos para validar sus datos (nombre, especialidad, domicilio, horario de consulta, costo de consulta, principales laboratorios que lo visitan, etc.) Actualmente ésta validación se llevaba a cabo a través de una hoja de Excel por lo que se me solicitó desarrollar un sistema en visual basic que automatice los procedimientos y que se guarde la información en una base de datos central en la que pueda estar protegida la información. Planeación: El sistema que se va a implementar es una copia de un sistema actual que existe en web, sin embargo dadas las circunstancias del desorden en el que los operadores incurren para la captura de datos se les restringió el acceso al sistema y se les cambió por hojas de Excel. El plan: Consiste en estructurar un sistema réplica del sistema web, pero este debe ser local con una base de datos réplica también que haga las veces del sistema original. La idea es que en este sistema si pueden cometer errores en captura de información. El sistema debe ser capaz de proveer una interfaz gráfica que permita al operador un manejo de una sola vista con los campos que conoce de su sistema actual. Desarrollo. El tiempo de elaboración se lleva 2 meses
Si no es posible apegarse perfectamente al plan de la gráfica de Gantt, se tendrá que corregir conforme a la experiencia del método. Originalmente me apegué a los tiempos de entrega del sistema, pero dada la renuencia del equipo del Call Center en donde pretendían continuar con la sub-cultura de Excel, el tiempo se extendió a 3 meses. Diseño Se trata de una interfaz gráfica que cuenta con todos los campos de las bases de datos para su llenado, ésta debe estar separada en 6 secciones y debe ser una sola vista que se recorra de arriba hacia abajo solamente con scrollbar.
Secciones: La primera sección estará deshabilitada para el operador pero será visible y solo informativa, es decir que podrá ver el estatus anterior del fichero médico y el número consecutivo. Contendrá la navegación de botones. La segunda sección estará disponible para su captura y pertenecerá exclusivamente a los datos del médico. La tercera sección contendrá los datos del domicilio del médico. Las secciones 4 a la 6 son los domicilios alternos que tenga el médico.
Requisitos del Software El Software debe ser capaz de manejar estructuras de clases, herencia, polimorfismo y debe ser capaz de seguir ejecutándose al atrapar los errores que puedan resultar dentro del código. Para este requerimiento se obtienen los siguientes módulos: Funciones:
Introducir Ficheros Médicos Grabar o Guardar Ficheros Médicos No eliminar ficheros Médicos
Consultas:
Consulta de códigos postales de los domicilios Consulta de estatus de la validación (óptimo, confiable y por confirmar. Este estatus es resultado de la marcación del Call Center y es motivo de consulta en SQL) Consulta de las bases de datos que alimentan los combos
Base de datos necesaria: Tabla1: (el lay out es muy extenso, solo dejo una imagen)
Sepomex: estado, municipio, ciudad, código_postal, colonia Opciones-si-no: SI, NO Catálogo laboratorios: id_laboratorio Catálogo-enfermedades: enfermedad Catálogo abreviatura calles: descripción Estimación del Software
Compilación: Luego se procede a la compilación del código, se registra cada defecto en el cuaderno de defectos y en la tabla de análisis de errores y el tiempo dedicado también en el cuaderno de registro de tiempos.
Post-Mortem. Hasta aquí habría completado el software. Lo único que falta es la fase de PostMorten, que corresponde al completado del Resumen del plan del proyecto con los valores reales. Debemos registrar un tiempo de postmorten estimado en el cuaderno de registro de tiempos
El proceso de llenado podemos verlo en las instrucciones del Plan del Proyecto.
RESUMEN SEMANAL DE ACTIVIDADES A partir del cuaderno de registro de tiempos de las últimas semanas, se puede obtener un Resumen Semanal de Actividades que le permitirá conocer el tiempo que necesita en una semana para llevar a cabo actividades de programación. En caso de tener otras actividades, como por ejemplo pasar clases de actualización por las mañanas, el Ing. deberá registrarlo en esta tabla. Así se irá obteniendo distintos resúmenes semanales, tendrá uno cuando programa y pasa clases, otro cuando solo programa, etc. De esta manera, antes de obtener un nuevo compromiso, analizaremos el tipo de semanas que vienen, y en base a criterio aceptar o rechazar. A continuación veamos como se obtiene un resumen semanal a partir del cuaderno de registro de tiempos.
Este proceso normalmente lo hacía en un bloc de notas y en hojas de papel, pero, lo que he plasmado arriba es lo que se debe hacer.
Fuentes: Humphrey, W. (1995) A discipline for software engineering (The complete PSP Book) United States of America: Addison Wesley. Humphrey, W. (2005) PSP a Self-improvement process for software engineers. United States of America: Addison Wesley. Humphrey, W. (2006). TSP (SM) Leading a Development Team. United States of America: Addison-Wesley. Zapata, J., García, J., Cerrada, J. (2001) Introducción al proceso software personalSM. Madrid, España: Addison Wesley. Universidad de Pamplona. (24 de agosto de 2009). Introduciendo PSP (Procesos Personal De Software) en el Aula. Recuperado de: http://www.unipamplona.edu.co/unipamplona/portalIG/home_40/recursos/03_v13_18/revis ta_16/27102011/01.pdf Conacyt. (S/F). Casos de éxito. Recuperado de: http://www.cimat.mx/es/casos_de_exito