• Save
Pb11 002 1 Metodologia
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Pb11 002 1 Metodologia

on

  • 6,444 views

 

Statistics

Views

Total Views
6,444
Views on SlideShare
6,375
Embed Views
69

Actions

Likes
8
Downloads
0
Comments
2

3 Embeds 69

http://www.slideshare.net 49
http://aulavirtual.ingenieriausp.com 18
http://webcache.googleusercontent.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • es mi correo
    Are you sure you want to
    Your message goes here
    Processing…
  • solicito la copia de tu trabajo es muy bueno porfavor te tomare omo referencia bibliografica....renba.blue
    @gmail.com
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Pb11 002 1 Metodologia Presentation Transcript

  • 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