1) El documento presenta un estándar metodológico para el desarrollo de software que incluye elementos como procesos, artefactos, roles y actividades. 2) Se describen estrategias para mejorar el proceso de desarrollo de software en la empresa como definir procesos basados en metodologías estandarizadas y asegurar la calidad. 3) Finalmente, se presenta un caso práctico para desarrollar un sistema de control de asistencia siguiendo la metodología propuesta.

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. Para formalizar y definir el proceso de desarrollo de software : Qué se debe hacer, Quién debe hacerlo Cuándo debe hacerlo y Cómo debe hacerlo No existe una metodología de software universal . Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable. ¿Por qué es importante una Metodología?

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. Estrategias de Mejora del Proceso de Desarrollo de Software en CNP Procesos de software definidos , Basado en UP, requisitos de SW-CMM y el PMI Definición del Modelo de atención Estandarización del Proceso de desarrollo de SW Aseguramiento de la Calidad Que respeten estándares y métricas definidos Aplicación de la Metodología de Desarrollo de SW Aprovechando la integración de nuestras herramientas Nivel técnico y profesional de nuestros recursos Staff de profesionales calificados Capacitación constante Mejoría continua basada en la mejores prácticas

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. Nuestra metodología de desarrollo Inicial Elaboración Construcción Transición CONSTRUC. Y PRUEBAS Desarrollo de componentes Pruebas unitarias Integración de componentes Pruebas funcionales y de estrés SOPORTE Y MEJORAMIENTO. Mejoras y corrección de defectos Acciones correctivas IMPLANTAC. CAPACITACION Manejo de versiones Medición de la performance GESTIÓN DE REQUISITOS Identificación de requisitos Identificación de actores del negocio Identificación riesgos Control de requisitos PROPUESTA DE SOLUCION Definición conceptual de la solución Plan y recursos del proyecto Control de calidad Negociación DISEÑO FISICO Diagrama de componentes Diagrama de despliegue Modelo físico de datos Diccionario de datos PLAN DE SOLUCION Definición conceptual Alcance de los servicios Planificación y ampliaciones Planificación de la ejecución del servicio ANALISIS DE SIT. ACTUAL Análisis de la organización Modelamiento del negocio Problemas y limitaciones Proceso propuesto DISEÑO LOGICO Casos de uso Objetos del dominio Diagramas de Clases y comportamto. Diseño lógico de la BD Prototipos Gestión del Proyecto Aseguramiento de la Calidad Configuración del Software Soporte Técnico Disponibilidad de Herramientas Desarrollo Iterativo de Componentes Iteracción 3 Iteracción 4 Iteracción 1 Iteracción 2

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. Los múltiples roles que debemos controlar en el ciclo de vida del desarrollo de SW Gerente de proyecto Administrar el Proyecto Seguimiento de requisitos Asegurar la integración y colaboración Promover la calidad, y Re-uso Asegurar la documentación de los sistemas y proceso de desarrollo Expertos del Negocio Conocer el Negocio Compartir su conocimiento Apoyar en el análisis Validar las especificaciones de diseño Administrador de BD Modelar las entidades de información Implementar procedimientos en la BD Tratamiento de datos Ing. De proyecto Modelamiento UML Desarrollar Documentar Probar Trabajo Iterativo Control de calidad El sponsor del proyecto Arquitecto

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

14. Alcance del Proyecto “ COMPONENTE 01: Definición y Automatización de los procesos de Control de Asistencia en las planillas. ” Recopilación y Análisis de procesos. Desarrollo y construcción del Sistema de Control de Asistencia. COMPONENTE 02: Implantación Piloto del Sistema La Implantación Piloto del Sistema en ambiente de pre-producción, Los talleres de capacitación respecto al uso de la aplicación La preparación del equipo de humano técnico que llevará a cabo las labores de seguimiento y soporte Alcance de la solución

15. Plataforma tecnológica

16. Extractos de la metodología

17. Inicio del Proyecto Formalización de la fecha de inicio del proyecto Reunión de Kick off. Necesidades a cubrir. Exposición de la Propuesta de solución. Objetivo de la Solución Visión de la solución Enfoque Funcional Beneficios para el cliente Alcances de la propuesta (Alcance de los procesos y ámbito de operación) Definición del Proyecto. Estructura funcional Cronograma del Proyecto. Recursos del Proyecto. Entregables del Proyecto. Acuerdos y Compromisos iniciales (responsabilidades, seguimiento y control del proyecto, próximos pasos).

18. Fuentes de Información para Casos de Uso Especificaciones del alcance de la propuesta Literatura relevante del dominio Entrevistas con expertos del dominio Conocimiento personal del dominio Sistemas y datos existentes Fuentes de Información

19. Documento de Visión y Alcance Indice del documento

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

22. Análisis de procesos

23. Análisis de procesos

24. Análisis de procesos

25. Análisis de procesos

26. ¿Qué es el comportamiento del sistema? El comportamiento de un sistema describe cómo un sistema actúa y reacciona. La actividad exterior visible y verificable de un sistema El comportamiento del sistema es capturado en los casos de uso. Ellos describen la funcionalidad del sistema, su ambiente, y la relación entre ellos Definición de la funcionalidad del sistema

27. Inventario de la funcionalidad necesaria para atender los requisitos del sistema

28. Documento de Análisis y Diseño

29. Descripción del análisis de la aplicación En esta etapa se presenta en forma clara para el cliente, por medio de diagramas, como los casos de uso y los actores interactúan , enviándose estímulos entre ellos Pedidos Vendedor Colocar Pedido Supervisor Autorizar Créditos Solicitar Listado De Pedidos Atendidos Sistema de Inventarios

30. Ejemplo de Diagrama de Actores

31. Distribución de casos de uso en paquetes

32. Ejemplo de diagrama de casos de uso 02 – Información de la empresa

33. Documentación de un Caso de Uso Documentar los casos de uso mostrando: Una breve descripción El propósito del caso de uso en unas pocas líneas Flujo de eventos detallados Descripción del flujo de eventos primario y alternativos que ocurren cuando el caso de uso es iniciado La descripción del flujo de eventos debe leerse como un diálogo entre el actor y el caso de uso Precondiciones y post condiciones Requerimientos especiales Opcionalmente, prototipos de interfaz usuaria y otros diagramas (diagramas de actividad o diagramas de estado) El caso de uso estará escrito en términos que el cliente entienda Detalle del caso de uso

34. Ejemplo de descripción del caso de uso Se ha realizado la consulta de los datos de un miembro del personal en modo sólo lectura. Postcondiciones El usuario de la Oficina de Tiempos es admitido en el sistema luego de ser validados su cuenta de usuario y clave. Precondiciones: RQ001 La información del personal debe estar sincronizada con las 9 planillas del cliente Requerimientos: El caso de uso comienza cuando un usuario de la Oficina de Tiempos consulta los datos de un miembro del personal en modo sólo lectura. El caso de uso termina cuando el Sistema muestra la información del personal seleccionado. Resumen: CU-02-07 Filtrar Personal Casos de uso asociados: Principal Tipo: Acceder a la información del del personal que labora. El acceso será restringido en modo sólo lectura. Propósito: Oficina de Tiempos Actor(es): CU-02-03 Consultar Personal Caso de uso:

35. Ejemplo de descripción del caso de uso 6.- El sistema muestra la página principal y el caso de uso termina. 5.- El usuario de la Oficina de Tiempos vuelve a la página principal del sistema. 4.- El sistema muestra en modo sólo lectura los datos correspondientes al personal seleccionado. Los datos son: SIP Nº de Fotocheck Ficha Anterior Estado Apellido Paterno Apellido Materno Nombre 1 .. 3.- El usuario de la Oficina de Tiempos elige el personal que desea consultar al detalle. El usuario puede utilizar el Filtro de Personal para hallar a la persona que busca (CU-02-07 Filtrar Personal). 2.- El sistema muestra en pantalla el listado del personal que supervisa tal como lo indica su jerarquía de control. 1.- El caso de uso comienza cuando el usuario de la Oficina de Tiempos ingresa a la opción de consultar personal. Respuesta del Sistema Acción del Actor FLUJO BASICO

36. Ejemplo de descripción del caso de uso Nombre del cliente PANTALLAS DEL CASO DE USO – CU-02-03

37. Descripción del Diseño de la aplicación INPUT: Documento de Visión y Alcance e información generada en el análisis. Como Resultado esta fase se deberán obtener los componentes del sistema y sus relaciones así como las entidades de información necesarias. Los resultados son: Diseño lógico, que incluye la información generada en la fase de análisis. Modelo de datos de la aplicación.

38. Ejemplo de Modelo Conceptual

39. Ejemplo de Diagrama de Clases

40. Ejemplo de Diagrama de secuencia

41. Ejemplo de Modelo conceptual de datos

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

44. Documento de Arquitectura

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. Ejemplo de Decisiones de la arquitectura Servidor Web: Tomcat 5.0 Plataforma Java: Java 2 (jdk 1.4) Framework Base: Framework Sybase Perú (Struts 1.1, Spring 2.1, Ajax 1.0, JSP 2.0) JSP 2.0 Servlet API 2.4. Driver de comunicación con MS SQL Server: jTDS (OpenSource) Modo de Comunicación con el Reloj Digital: Sockets y RMI Reporteador: Chart Director Exportar Reportes a PDF: Jasper Reports

47. Documentación técnica de la Arquitectura Ejecución por línea de comando a través de la web conectándose al dispositivo a través de TELNET, respecto al mapeo del archivo sería el mismo procedimiento. Alternativas consideradas Construcción de un aplicativo Java con soporte RMI, que recibe invocaciones del servidor de aplicaciones web, el usuario podrá desde una interfaz web enviar comandos al reloj, el aplicativo contará con una interfaz a través de sockets con los relojes de asistencia, estos se encontrarán conectados a la red a través de un convertidor ethernet y las IP’s respectivas registradas en la base de datos de la aplicación. Solución La invocación debe ser desde el aplicativo web hacia los relojes. La comunicación con los relojes de asistencia se realiza a través de sockets con el módulo de comunicación. Se deben utilizar los comandos propios del reloj para la descarga de archivos texto. Condiciones Los relojes de asistencias se conectarán a un módulo de comunicación a través de sockets, este módulo se encontrará separado del servidor web y se ejecutará como un servicio socket de tipo servidor. Resumen de la solución CU-04-06 Enviar Comando al Reloj CU-04-02 Asignar Personal al Reloj Factor

48. Ejemplo de Requerimientos técnicos Servidor Memoria : 1GB Sistema Operativo : Windows 2000 o superior Linux(RedHat Linux, SuSe Linux) Procesador : Pentium IV o superior Cliente Memoria : 256MB Sistema Operativo : Windows 2000 o superior Navegador : Internet Explorer 6.0. ó Netscape Navigator 8.0.

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