1. Estándar de Metodología de Desarrollo de Software MIGUEL RODRIGUEZ CABELLOS JEFE DE DESARROLLO Y MEJORAMIENTO DE SISTEMAS CAJA NOR PERU. Miembro de la Fundación BBVA para las Micro Finanzas
2. El proceso de desarrollo de SW Negociación Iniciador/ Sponsor del Proyecto Requeri-mientos Productos entregables del proyecto Usuarios finales Activos del proceso Almacén d’activos del proceso Límites del proyecto Procesos de Planificación Procesos de seguimiento y control Procesos De ejecución Procesos de inicio Procesos de cierre Espectativas Cronogramas Costos Cambios RQ
3. Factores de éxito para mejorar Herramientas Metodología Notación RRHH
4.
5. Elementos que necesitan ser definidos por la Metodología Proceso SW Artefactos Roles Actividades - Conocimientos - Habilidades - Actitudes - Plantilla - Guía de elaboración - Lista de control - Procedimientos - Seguimiento y control realiza responsable produce Personas Herramientas Notación
6.
7. Definición del Modelo del Proceso de Atención en CNP Gerencia Proyectos Metodología Soporte Herramientas Procesos Estándares / Métricas ATENCION DE REQUISITOS Planificación y Control Aseguramiento de la Calidad Web Cliente Servidor CLIENTE Móviles OPERACIONES Recursos Consultorías
8. 8 Pruebas funcionales Cliente 1 Análisis de Requisitos Aseguramiento de la Calidad Atención de Requisitos INICIO GESTION DEL PROYECTO 10 Asegurar Calidad 6 Generar Data para Pruebas 11 Concluir Entregables 13 Dar aceptación FIN Operaciones Planificación y Control 3 Planear atención 4 Análisis y Diseño 12 Entregar solución Estandarización del proceso de desarrollo 2 Negociación Propuesta y Plan de Solución 7 Desarrollo 9 Pruebas de estrés Producto Terminado Conformidad Pruebas Plan de implementación Conformidad de Calidad Requisitos Conformidad del SW Entregables Requermiento Codificado 5 Planificar Pruebas
9.
10. Artefactos de nuestra metodología Manual de operación Cronograma del proyecto Matriz de trazabilidad Plan de pruebas Plan de implantación Plan de Administración riesgos Matriz de riesgos Kick off Manual de usuario Manual de instalación Manual Técnico Visión del Proyecto Planificación de la solución Requerimientos Informe semanal Informe mensual Evaluación post-mortem Criterios de aceptación Material de capacitación Plan de capacitación Documento Análisis y Diseño Documento Arquitectura Especificación de casos de uso Casos de prueba Modelo de procesos del negocio Modelos UML Modelo de datos Prototipo del sistema Resultados de pruebas Análisis del negocio
11.
12. La máxima eficiencia en el proceso de desarrollo “ Sistema de control de asistencia” CASO PRACTICO
13. Sistema de Control de Asistencia “ Desarrollar una herramienta WEB con la funcionalidad necesaria para un eficiente control de la asistencia, permitiendo la generación automática de conceptos Hacia las 9 planillas existentes, con el máximo aprovechamiento de sus recursos y una total integración de información segura, auditable y con los niveles de calidad requeridos para hacer mas eficiente la emisión de boletas de pago ” VISION
20. Requisitos funcionales Reportes de Gestión de indicadores para la gestión de recursos. RQ8 Generación de reportes operativos RQ7 Generación automática de conceptos para el sistema de planillas RQ6 Manejo de las excepciones de labor diaria RQ5 Automatización del sistema de registro de horarios de ingreso y salida – Operación diaria RQ4 Administración de los marcadores electrónicos RQ3 Configuración de horarios flexibles RQ2 Información del personal de las 9 planillas del cliente RQ1
21. Requisitos no funcionales Arquitectura Web intuitiva y amigable RQ16 Sistema paramétrico RQ15 Flexibilidad para el registro, corrección y reproceso de los datos de la asistencia RQ14 Despliegue del sistema hacia las supervisiones y jefaturas que controlan el trabajo del personal RQ13 Seguridad de la información que administran los tareadores, jefes y supervisores respecto a las excepciones de la asistencia RQ12 Auditabilidad de la información registrada RQ11 Seguridad de la información registrada RQ10 Asegurar la calidad de la información que se ingresa al sistema. RQ9
42. Ejemplo de la Lista de tablas Otros usuarios que escalan las alarmas Usuarios_escalados Configuración de parametros Parametro_x_Planilla Configuración de parametros Parametro_x_Area Configuración de parametros Parametro_sistema Tablas generales de los sistemas Tabla_Tablas Sistemas que estarán bajo el modelo de seguridcadad Sistema Usuarios del sistema Usuario_Sistema Perfiles registrados para los actores del sistema Perfil módulos u opciones del sistema Modulo Rastro de auditoria para acceso a opciones Log_Opciones Rastro de auditoria de la actualización de datos Log_Auditoria Tabla de empresas del sistema Empresa 01 - Seguridad Descripción Nombre
43. Ejemplo del Diccionario de datos Lista de campos de la tabla Empresa usuario VA15 Usuario que actualiza cod_usuario_actualizacion fecha DT Fecha de actualización fec_actualizacion flag A1 estado flg_estado VA30 Representante de la empresa des_representante VA40 Dirección des_direccion VA20 Teléfono des_telefono A11 Número de ruc des_ruc VA30 Nombre de la empresa des_empresa X empresa A3 Código de empresa cod_empresa Mandatory Domain Data Type Comment Name
45. Ejemplo de Factores que impactan en la Arquitectura A A El sistema deber á diseñar la interfaz necesaria para el envío de información de la base de datos de control de asistencia hacia las 9 base de datos de planillas. El sistema deberá interactuar con las 9 bases de datos de planillas del cliente para realizar el proceso de transferencia de información por cada período (CU-07-02 - Tranferir Datos a Planillas) M A El formato en el que envía el reloj los registros de marcas es inalterable, por tanto el sistema se ajustará a ello. El sistema deberá procesar el archivo de marcas que el reloj digital genera cuando se le solicita que realice la descarga de marcaciones. CU-04-03 - Leer Marcaciones del Reloj. M A El envío de órdenes al reloj se ajusta a la especificación de comandos que el instrumento soporta. El sistema conversará, a través de comandos, con el reloj digital que controla la asistencia del personal. CU-04-06 Enviar Comando al Reloj CU-04-02 - Asignar Personal al Reloj M A El sistema debe estar implementado en un ambiente web. Funcionalidad – Interfaces con otros subsistemas B M Se mantendrá una única tabla de auditoría, sobre la cual se registrarán todas las ocurrencias diferenciadas por el tipo de situación. El sistema guardará los usuarios y lo realizado en los registros referidos a los temas mencionados. El sistema deberá poseer capacidades de auditoria para identificar a la persona que realizó un cambio en alguna de las siguientes situaciones: M M Se tendrá un personal especializado para el manejo de perfiles y asignación de permisos a los usuarios, así como la creación de los mismos. La estructura de las tablas y el módulo de seguridad debe ser totalmente flexible a fin de soportar futuros cambios o implementaciones. El sistema contará con un módulo por separado y con una estructura especial para el manejo de los accesos y seguridad dentro del sistema. Se tomará en cuenta la encriptación de clave en la base de datos. El sistema deberá contar con un módulo de seguridad que solicite, en forma obligatoria, una cuenta de usuario (user_id o login) y clave (contraseña o password). Almacenada en la base de datos con un algoritmo de encriptación. Seguridad – Acceso y reglas de seguridad Dificultad Prioridad Impacto en las personas involucradas, arquitectura u otros. Flexibilidad (actual y futura evolución) Medidas y escenarios de Calidad Factor
46.
47.
48.
49. La arquitectura desde diferentes vistas Vista lógica Vista del proceso Vista de casos de uso Vista de lmplementación Vista de despliegue Vista de datos
