Plan de Desarrollo Software Ventas de Inventario

Transcripción

1 Plan de Desarrollo Software Ventas de Inventario Versión: Autor: XXXXX Fecha de publicación: Agosto 24, 2006 idad. Todos los derechos reservados. El contenido de este documento es confidencial y está protegido por derechos de autor. Este documento está sujeto a cambios. Comentarios, correcciones o preguntas deben ser dirigidas al autor.

2 Plan de Desarrollo de Software (PDS) Resumen del Documento Propósito El propósito de este documento es establecer planes razonables para la ejecución de la Ingeniería de Software y para el Manejo del Proyecto de Software La audiencia para este documento es: Audiencia Miembros del Equipo de Desarrollo Objetivo Conocer el contenido de este documento y aplicarlo al proceso diario que ejecutan así como brindar retroalimentación para mejorar continuamente el proceso descrito Tabla de Revisiones La siguiente tabla lista las revisiones hechas a este documento. Se utiliza para describir los cambios y adiciones cada vez que el documento se vuelve a publicar. La descripción debe incluir tanto detalle como sea posible, así como, los revisores que solicitaron las modificaciones. Fecha Autor Descripción del cambio Creación Modificación para añadir la Guía de Trabajo Modificación para añadir el Plan de Calidad Modificación para añadir el Plan de Riesgos Modificación para añadir el Plan de Administración de la Configuración Modificación para añadir los datos de los recursos que ingresan al proyecto hasta el 18 de Agosto Modificación para reflejar el resultado de la junta de Especificación de la Arquitectura realizada el 7 de Agosto. Modificación para añadir los datos de los recursos que ingresaron al proyecto hasta el 21 de Agosto Modificación para completar la Administración de la Configuración. Modificación para Incluir el Rol del Diseñador Gráfico r Página 2 de 41

3 Plan de Desarrollo de Software (PDS) Contenido Resumen del Documento 2 Propósito 2 Tabla de Revisiones 2 Contenido 3 Información del Proyecto 5 Stakeholders del Proyecto 6 Estándares 9 Plan de Estrategia del Proyecto 10 Estimación del Proyecto 10 Plan de Trabajo del Proyecto 11 Supuestos 11 Restricciones y Dependencias 12 Proceso de Análisis de Decisiones 13 Riesgos 13 Consideraciones 14 Notas 14 Plan de Recursos 15 Plan de Entrenamiento 18 Plan de Seguimiento del Proyecto 19 Proceso de Cambio de Alcance 20 Guía de Trabajo 21 Horario de Trabajo 21 Días Festivos 21 Herramientas 21 Plan de Comunicaciones 22 Organización del Proyecto 23 Matriz de Escalamiento 25 Roles y Responsabilidades Adicionales 25 Reglas del Equipo de Trabajo 26 Plan de Administración de la Calidad 27 Conceptos de Calidad 27 r Página 3 de 41

4 Plan de Desarrollo de Software (PDS) Objetivos de Calidad 28 Estrategia de Calidad de los Entregables 29 CTQs del Proyecto 30 Criterios de Aceptación 31 Prevención de Defectos 31 Plan de Administración de la Configuración 32 Tablero de Control de Administración de la Configuración 32 Herramientas de Administración de la Configuración 32 Métodos de Identificación 32 Estructura del Repositorio Visual Source Safe 33 Estructura del Repositorio Tortoise CVS 34 Plan de Productos 36 Configuración del Ambiente 37 Configuración del Software 37 Configuracion de la Conectividad 37 Plan de Respaldos 38 Plan de Recuperación de Desastre 38 Plan de Pruebas 39 Entradas de las Pruebas 39 Estrategia de Pruebas 39 Plan de Productos 40 Glosario 41 r Página 4 de 41

5 Plan de Desarrollo de Software (PDS) Información del Proyecto Código del Proyecto Nombre del Proyecto Negocio Estatus Información del Proyecto Código del Cliente Nombre del Cliente Departamento Ciudad Información del Cliente Tipo de Servicio Tipo de Compromiso Política de Pago Información del Servicio Desarrollo de Software a la Medida Proyecto con Alcance, Tiempo y Costo Fijo Pagos Parciales por Etapa/ Fase Terminada Tecnología Arquitectura: Aplicación Web Multicapas Lenguajes de programación Java, SQL, HTML Sistemas operativos: AIX versión 5.2 nivel 6 DBMS: Oracle 10g Otras herramientas: WebSphere MQ 5.3, ERWin, MS Office Tools, Sense, Visio, Kintana, Source Safe Resumen del Esfuerzo Fecha de Inicio: 03/07/2006 Fecha de Fin: 04/05/2007 Esfuerzo (Horas): 15,692 hrs (42 Semanas, 10 Meses) Número Promedio de Recursos 9 Máximo Número de Recursos 19 r Página 5 de 41

6 Plan de Desarrollo de Software (PDS) Stakeholders del Proyecto Directorio del Proyecto Nombre Responsabilidad IS (Id STK) Teléfono Directorio del Proyecto Nombre Responsabilidad Empresa Teléfono r Página 6 de 41

7 Resumen Desarrollar una aplicación integradora de servicios al cliente que permita realizar una venta completa, desde la intención de compra hasta la entrega del producto al cliente, junto con los servicios asociados. El alcance de la aplicación incluye los servicios de Administrar la relación con el cliente (venta y acuerdo de entrega de productos) Administración de la logística interna (surtido y envío de producto hasta el punto de entrega final) Administración de la entrega final (último tramo del envío y entrega al cliente) Administración de las desviaciones (eventos inesperados durante la entrega) El proyecto será desarrollado bajo una plataforma WebSphere presentando como interfaz con el usuario el Browser y conectándose vía MQSeries a los sistemas Legacy. Objetivo Crear el sistema de software Ventas de Inventario para automatizar y soportar las operaciones de: Administrar la relación con el cliente (venta y acuerdo de entrega de productos) Administración de la logística interna (surtido y envío de producto hasta el punto de entrega final) Administración de la entrega final (último tramo del envío y entrega al cliente) Administración de las desviaciones (eventos inesperados durante la entrega como cambio de domicilio, devoluciones, ausencia del cliente, etc.) con la intención de lograr: Otorgar al cliente un servicio formal de calidad en el menor tiempo posible con la información más precisa y oportuna Tener información real y oportuna para establecer compromisos con el cliente Cubrir los procesos logísticos necesarios para cumplir con el servicio pactado con el cliente sin incrementar costos operativos Situación Actual Actualmente X cuenta con una serie de sistemas que permiten la venta y entrega de productos y servicios a sus clientes en los almacenes, de manera que al realizar una venta que requiere una entrega o un servicio adicional se tiene que utilizar diversas aplicaciones para poder completar la tarea. Por otra parte el sistema que actualmente administra el servicio de entrega (SOMS, IBM Z series, interfaz orientada a carácter) está ya rebasado por las prácticas de negocio actuales de X y es necesaria una nueva aplicación que se adapte más al proceso de negocio actual. Situación Deseada X desea una aplicación integradora de servicios al cliente que permita realizar una venta completa, desde la intención de compra hasta la entrega del producto al cliente, junto con los servicios asociados. De esta forma se podrá dar al cliente un mejor servicio que permita, de forma rápida y eficiente, realizar la compra y ofrecer una fecha de entrega precisa que le dé seguridad al cliente. r Página 7 de 41

8 Proceso de Desarrollo del Proyecto Arquitectura Metodología Ciclo de Vida Aplicación Web Multicapas Proceso de Desarrollo de Software de Y (PDSS) Desarrollo de Software Mapa de Procesos del Proyecto Fases PDSS Inicializar Proyecto de Software (ISP) Definición de Requerimientos y Diseño Funcional del Sistema de Software Toma de Decisiones Técnicas y Desarrollo/Adopción de Subsistemas de Soporte Diseño Estructural/Técnico del Sistema de Software Construcción y Prueba Unitaria de Componentes del Sistema de Software Integración de Componentes y Pruebas de Integración Carga Inicial de Información y Configuración del Sistema de Software Pruebas de Aceptación del Sistema de Software con el Cliente Elaboración de Manuales de Usuario e Instalación Desarrollo de Material de Entrenamiento y Entrenamiento a Usuarios Soporte a Usuarios durante Período Inicial de Operación Formalización Cierre de Proyecto r Página 8 de 41

9 Definición Operativa por Servicios Nombre del Servicio Condiciones Prioridades Enhancement and maintenance No Aplica Support No Aplica Quick Fix No Aplica Bug Fix No Aplica Notas del Ajuste de Metodología Se decriben todas las consideraciones y razones utilizadas en el ajuste del proceso estándar de desarrollo de Y, tal como va a ser usado en el Proyecto para adecuarse a la necesidades específicas tales como Metodología del Cliente, distribución de actividades y entregables, puntos de control, métodos no estándares, guías de herramientas, procedimientos y técnicas Desviación del Proceso Estándar No hay desviación del Proceso Estándar. Los Entregables que están comprometidos con base en la Propuesta aparecen en el Mapa de Procesos por cada Fase del PDSS No Aplica Razones de la Desviación Ajuste de Documentación El propósito de esta tabla es serx para relacionar los Entregables de acuerdo al ajuste de Metodología para el Equipo de Desarrollo No Aplica Nombre Entregable Entregable Equivalente Y Cambio en la Descripción Estándares El reporte de actividades es a través de ACTIV. La captura es semanal, y al corte del mes se debe tener lista 3 días hábiles antes del último día del mes. El reporte del avance en el plan de Trabajo es a través de Kintana, y debe ser registrado diario. La Administración de Proyecto en Kintana puede ser consultada en: Project_Management_in_Kintana.pdf La Administración de riesgos se hará a través de Kintana Las revisiones a distancia se harán a través de Interwise Monitores (Dashboards)/ Filtros (Portlets) de Kintana Estándares Nombre Dashboard / Portlets Dashboard (D)/ Portlet (P) X Personal Daily Activity D Todos My Request P Todos My Tasks P Todos Project Gantt P Todos X Meetings D Todos Meetings - Action Items Tracking P Todos Earn Value Analysis P Todos Obligatorio Para (Rol) X Project Daily Activity D Líder de Proyecto My Request P Líder de Proyecto My Tasks P Líder de Proyecto Project Gantt P Líder de Proyecto r Página 9 de 41

10 Nombre Dashboard / Portlets Dashboard (D)/ Portlet (P) Obligatorio Para (Rol) Analize Assignment Load P Líder de Proyecto Request Summary Bar Chart P Líder de Proyecto Deliverable Driven Metrics D Líder de Proyecto Cost of Quality D Líder de Proyecto Risk & Issues Management D Líder de Proyecto Defect Management D Líder de Proyecto Plan de Estrategia del Proyecto Todo el plan de desarrollo del proyecto está planteado a partir de: Inicio de Proyecto Puntos de Control Completos Identificación de desviación de Calendario o Esfuerzo de un 5% del total estimado. Estimación del Proyecto El estimado detallado del tamaño, esfuerzo y calendario del alcance del Proyecto está ubicado en el siguiente documento:. En términos cuantitativos, el alcance funcional del sistema de software es: Tipo de Componente Complejidad Baja Complejidad Complejidad Alta Media Servicios/Transacciones en Línea Servicios/Procesos Fuera de Línea (Lotes) Entidades Lógicas de Información r Página 10 de 41

11 Plan de Trabajo del Proyecto Producto Punto Control # Esfuerzo Primera Etapa Fecha Inicio Fecha Fin Duración (Días) Inicializar Proyecto de Software (ISP) Documento de Diseño Funcional del Sistema de Software Documento de Requerimientos No Funcionales del Sistema de Software Documento de Decisiones Técnicas y Tecnológicas 2, , Subsistemas de Soporte Firma Primera Etapa Diseño Estructural/Técnico del Sistema de Software Construcción y Prueba Unitaria de Componentes del Sistema de Software Integración de Componentes y Pruebas de Integración Carga Inicial de Información y Configuración del Sistema de Software Pruebas de Aceptación del Sistema de Software con el Cliente Elaboración de Manuales de Usuario e Instalación Desarrollo de Material de Entrenamiento y Entrenamiento a Usuarios Soporte a Usuarios durante Período Inicial de Operación Formalización Cierre de Proyecto Punto de Control Final (Carta de Aceptación Firmada) TOTAL 15, El Plan de Trabajo está ubicado en el siguiente documento: Plan de Viajes No Aplica Objetivo del Viaje Quien Fecha Duración Supuestos La información de punto de venta será obtenida y entregada al sistema POS La información de disponibilidad de inventario será obtenida del sistema de inventarios WMS Las interfaces que el sistema de software tendrá con otros sistemas son: a. Mesa de Regalos b. Ventas a distancia c. Kioscos d. Crédito e. Sistema de inventarios SAP R/3 f. Sistema de inventarios WMS (MARC) r Página 11 de 41

12 g. POS h. CRM Restricciones y Dependencias Se consideró que la utilización de módulos de SAP para resolver la solicitud de X no es factible debido al costo de la implementación y a los requerimientos de alta disponibilidad de la aplicación, que SAP no cubre. El desarrollo de servicios en MQSeries necesarios para que la aplicación se conecte a los sistemas de Back-Office será provisto por X. Cualquier desarrollo necesario en los sistemas de Back-Office será provisto por X. El alcance de la aplicación se limita a proveer un flujo de trabajo (workflow) para el proceso de Ventas de Inventario Remoto, ofreciendo los servicios integrados de las diferentes aplicaciones necesarias para llevar a cabo este flujo en un ambiente Web. Todo el desarrollo estará orientado a servicios para asegurar una interfaz común de comunicaciones entre aplicaciones r Página 12 de 41

13 Proceso de Análisis de Decisiones El Proceso de Toma de Decisiones está dirigido al uso de la Matriz de Toma de Decisiones siguiente. Esta herramienta involucra la definición de alternativas, el criterio de selección y el rating final que dirige a la selección de una alternativa. La tabla siguiente muestra las situaciones bajo las cuales la Matriz de Toma de Decisiones es aplicable. Guía de Uso Cuando un esfuerzo significativo del Proyecto (>10%) será destinado a la Decisión Cuando los problemas se presentan una segunda vez y diferentes alternativas han sido identificadas para resolverlos Decisión de Alto Riesgo Tipo de Decisión Técnica Todos Todos Este Proceso está bien documentado en el Entrenamiento de Análisis de Decisiones. Riesgos Las Categorías de Riesgos, probabilidades y niveles de impacto están definidas por Niveles Organizacionales en Kintana ( Risk_Management.pdf), y están explicados en el material de entrenamiento de Identificación de Riesgos e Issues almacenados en Intrasoft. A continuación se listan los Riesgos identificados para el Proyecto que no están dentro de las posibilidades del Equipo de Desarrollo de X mitigar o anular, y que tienen una Probabilidad/ Impacto Bajos: # Riesgo Probabilidad Impacto 1 El Sistema POS no esté disponible para realizar el cobro de las Órdenes de Venta de X 2 Se integre un Workflow para el Tracking del X, que no maneje la concurrencia y volumen necesarios para el sistema, que es de misión crítica Baja Media Alto Alto El Plan de Administración de riesgos a través de Kintana se ejecutará de la siguiente forma: Los riesgos del Proyecto en los cuales se pueden tomar acciones de mitigación, manejo o anulación se registrarán por todos los miembros del equipo en cuanto sean detectados siguiendo el siguiente flujo: 1. En el menú Create elegir la opción Request 2. Elegir del Menú Request Type la opción Risk Management Request 3. Una vez en la pantalla Create New Risk Managment Request: a. Seleccionar el Proyecto donde el riesgo ha sido identificado () b. Describir el riesgo de manera concisa c. Especificar cada uno de los 3 niveles de escalamiento para que el riesgo sea evadido a la brevedad y efectivamente. d. Proporcionar una descripción del riesgo más detallada para que sea entendido e. Registrar la Probabilidad estimada de la amenaza de riesgo. r Página 13 de 41

14 f. Registrar el impacto del riesgo g. Registrar una propuesta de acciones a tomar para disminuir el riesgo 4. Los riesgos llegan al primer nivel de escalamiento (Líder de Proyecto), que analiza el riesgo para poder manejarlo. Puede suceder que después del análisis, el primer nivel de escalamiento no autorice el riesgo registrado. 5. Si el primer nivel de escalamiento no le da solución, Kintana automáticamente le notifica al nivel siguiente (Líder de Operación) para que sea atendido. Consideraciones Licencias y Componentes de Software Equipamiento en Sitio Recurso Facilidades e Sitio como Lugares, Teléfono, Internet, Impresoras Facilidades de Acceso como Tarjetas, Oficios, etc Acceso a los Sistemas Actuales tales como Cuentas de Usuario, Cuentas de Correo, Conexión. Etc Acceso a las áreas del cliente usuario Acceso a las áreas de Soporte del cliente tales como Soporte Técnico, etc Acceso a la documentación existente (Especificación del Sistema, Flujos de Proceso, Documentos, etc) Políticas, Reglas y Estándares de Desarrollo utilizados por el Cliente Librerías usadas en el Proyecto (Seguridad, Encriptación, o Librerías de Autentificación) Gastos de Viajes Ambientes de QA Casos de Prueba de Aceptación del Cliente y Datos de Prueba Cliente Cliente Cliente Cliente Cliente Cliente Cliente Cliente Cliente Cliente Cliente Cliente Cliente Responsible de Proveerlo Notas Ninguna r Página 14 de 41

15 Ajustes Diferencias sobre el Proceso Estándar Se utilizan procesos en vez de casos de uso Entregables ajustados de acuerdo a la Propuesta Justificación El Análisis se desarrolla con la Técnica TISAA y la Herramienta Case SENSE donde se modelan Working Áreas, Procesos, Salidas por cada Módulo del Sistema. Solo se detallan las Fases del PDSS en las que se tienen comprometidos Entregables para el Proyecto Plan de Recursos Plan de Recursos Humanos Rol Responsabilidades Requeridos Fecha Director de Operaciones Tiene como responsabilidad el verificar el buen desempeño del proyecto con respecto a los requerimientos por parte de X, coordinando el desarrollo entre el líder de proyecto y el usuario. Líder de Proyecto Elaborar la planeación de la operación del proyecto. Dar seguimiento puntual al avance del proyecto a través del monitoreo de los indicadores de la operación. Determinar acciones en conjunto con el cliente para solucionar los problemas relacionados con el desempeño del proyecto o cumplimiento de fechas. Renegociar con el cliente cambios en el estimado del esfuerzo. Líder Tecnológico Determinar las soluciones para el proyecto dentro del área técnica, tales como herramientas, estrategias o arquitectura. El diseño de los subsistemas de soporte, la construcción y pruebas de los mismos asegurando la calidad y su documentación para que los programadores los utilicen. Administrar los componentes de software construidos. Establecer un mecanismo para coordinar los cambios/actualizaciones a los componentes del ambiente controlado. Solucionar problemas técnicos a programadores. Analista Detallar el mapa de navegación de los servicios en línea del sistema. Describir procesos de captura que usan pantallas múltiples. Definir procesos de los programas fuera de línea. Generar especificaciones de los programas en línea y fuera de línea (Esqueleto, constante y variables, vistas.). Elaborar especificaciones de rutinas aplicativas reutilizables. Diagramar las dependencias entre procesos incluyendo nombres de programas y rutinas. Probar el diseño. Realizar pruebas de escritorio para el diseño generado. r Página 15 de 41

16 Rol Responsabilidades Requeridos Fecha Diseñar las pruebas funcionales e integrales. Administración de la Función de Diseño. Asegurar el uso de los subsistemas de soporte. Apoyar a los programadores sobre las consideraciones técnicas del sistema. Apoyar a los diseñadores sobre la factibilidad técnica de los sistemas a desarrollar. Supervisor de Programación Supervisión de los programadores verificando el uso de estándares de codificación y calidad de los productos de construcción. Asegurar que los componentes de software construidos son colocados en el ambiente controlado, y que es posible en todo momento, tenerlos identificados y en su versión apropiada. Establecer un mecanismo para asegurar que en todo momento se puede obtener el código ejecutable a partir de un proceso de compilación aplicado sobre el código fuente contenido en el ambiente controlado. Asegurar que los componentes de software construidos y en proceso de construcción son respaldados periódicamente para garantizar su preservación ante contingencias. Revisar, analizar y entender especificaciones de componentes Diseñador Gráfico Desarrollar el Prototipo Funcional de la Aplicación con base en las Especificación de la Metodología CRUDS (WA) Incorporar de acuerdo a estándares o acuerdos la Imagen Corporativa del Cliente Asegurar la Calidad de los Prototipos de los Analistas (estándares y lineamientos para cada TAB de las WA) Desarrollador (Programador) Construir componentes con lógicas ejecutables (procesos, programas, componentes, etc.) Entender la especificación del componente. Diseñar la lógica general y la lógica detallada del componente. Codificar el componente, aplicando estándares y reglas de codificación. Verificar la sintaxis del código generado. Diseñar la prueba unitaria del componente. Elaborar la lista de requisitos funcionales y la lista de condiciones de lógica a verificar. Identificar casos de prueba para comprobar el cumplimiento de todos los requisitos y condiciones de lógica. Elaborar procedimiento de carga inicial de datos de prueba unitaria. Ejecutar todos los casos de prueba unitaria. En caso de encontrar fallas, registrarlas en una bitácora, regresar a la actividad en la que se introdujo el defecto y ejecutar nuevamente dicha actividad y la secuencia de actividades posteriores. Entregar el componente al responsable de integrarlo en el ambiente controlado de componentes terminados y probados unitariamente ( código fuente, diseño de lógica, diseño de prueba unitaria y registro de fallas encontradas) r Página 16 de 41

17 Plan de Recursos de Hardware y Software Hardware Software Requerido Fecha Lap Top s Dell Intel Pentium, 512 Mb RAM, 60 Gb HD, CD, Tarjeta de red Lap Top s Dell Intel Pentium, 512 Mb RAM, 60 Gb HD, CD, Tarjeta de red Lap Top s Dell Intel Pentium, 512 Mb RAM, 60 Gb HD, CD, Tarjeta de red Lap Top s Dell Intel Pentium, 512 Mb RAM, 60 Gb HD, CD, Tarjeta de red Lap Top s Dell Intel Pentium, 512 Mb RAM, 60 Gb HD, CD, Tarjeta de red Windows XP Professional, MS Office, Sense, Visio, Project, Internet Explorer. Windows XP Professional, MS Office, Sense, Visio, Project, Internet Explorer. Windows XP Professional, MS Office, Sense, Visio, Project, Internet Explorer. Windows XP Professional, MS Office, Sense, Visio, Project, Internet Explorer. Windows XP Professional, MS Office, Sense, Visio, Project, Internet Explorer Plan de Recursos de Infraestructura Elemento Descripción Requerido Fecha Espacio físico (Cliente) Espacio para personas con acceso restringido 7 Teléfonos (Cliente) Línea telefónica con acceso a celulares 1 Acceso a Internet (Cliente) Acceso libre a Internet para sitios relacionados con las herramientas de desarrollo y Y Estacionamiento (Cliente) Lugar de estacionamiento, sin cobro 3 Espacio Físico (GDC) Espacio para equipo de desarrollo y analistas 20 7 r Página 17 de 41

18 Plan de Entrenamiento Técnico Área de Entrenamiento Duración Rol Material Instructor Kintana 3 hrs Líder Proyecto Analistas, desarrolladores, testers Material de curso de Kintana y Tutorial de Kintana SENSE 10 hrs Analistas Herramienta CASE Negocio Área de Entrenamiento Duración Rol Material Instructor Inducción a los Macroprocesos de Negocio del Proyecto Descripción y explicación detallada de los Scripts generados por cada Proceso de Negocio 5 días Líder Proyecto Analistas 10 días Líder Proyecto Analistas Presentación de los Procesos de Negocio, Premisas Generales y Especificaciones Técnicas Revisión detallada de los Scripts de Negocio de cada uno de los Procesos a detalle Proceso Área de Entrenamiento Duración Rol Material Instructor Introduction to NSS Todos Y University Y University El seguimiento al Entrenamiento del Equipo de Y puede ser consultado en r Página 18 de 41

19 Plan de Seguimiento del Proyecto Registro Concepto Responsable Herramienta Frecuencia Actividades Todos Kintana Diario Riesgos Todos Kintana Al identificarlo Problemas Todos Kintana Al identificarlo Defectos Todos Kintana Al identificarlo Avance Líder Kintana y Plan de trabajo Nuevos Requerimientos Líder Change Control Log Traceability Matrix Semanal Al solicitarlos Cambio a Requerimientos Líder Change Control Log Al solicitarlos Cambios de Esfuerzo o Calendario Líder Negotiations Log Kinatana Una vez negociado con el cliente Métricas del Proyecto Líder Kintana Quincenal, de acuerdo a las fechas de publicación Acuerdos Respaldos Responsable de la minuta Administrador de la configuración Minuta Backups Log una vez terminada la junta Una vez realizado el respaldo Revisiones Concepto Responsable Herramienta Frecuencia Objetivo Avance del proyecto con el cliente Avance del proyecto con el OM Líder Reporte de Avance Semanal Informar el estado del avance del proyecto al cliente Líder Reporte de Avance Semanal Informar el estado del avance del proyecto al OM y revisar las métricas Auditorias Tipo Participantes Herramienta Frecuencia Objetivo De Proceso (Y) De Administración de la Configuración De Análisis y Diseño Funcional Líder Responsable de QA Administrador de la configuración Responsable de QA Líder de Proyecto QA de Análisis Checklist de Auditoria Cheklist de Auditoria Configuration Management Audit Checklist y Alcance Funcional Al inicio de cada etapa Semanal Los primeros 2 productos del Analista De Diseño Técnico Líder Técnico Estándares de Diseño En cada producto de diseño generado De Codificación Supervisor de Desarrollo (Programación) Estándares de Codificación En cada programa desarrollado Revisar si el proceso es usado como se debe Revisar si los procedimientos de control de versiones y la información del repositorio son correctas y confiables Revisar que el Análisis Modelado en el SENSE cumpla en forma y fondo con la Metodología y los Requerimientos Revisar que el Diseño Técnico cumpla con los Estándares definidos para el Proyecto Revisar que la Codificación r Página 19 de 41

20 Proceso de Cambio de Alcance Cada observación a un producto terminado debe registrarse en la Bitácora de Defectos, para ser diagnósticado. (..\02 Control Proyecto\04 Control Cambios\00 Formatos\ISP2 X BitácoraDefectos_RC.xls) Cada cambio debe seguir el proceso FPC (Formalize Project Change) del PDSS, no importa si fue generado por el cliente o por el equipo de trabajo. (..\02 Control Proyecto\04 Control Cambios\00 Formatos\ISP2 X ControldeCambios.vsd) Cada cambio debe estar documentado utilizando el formato de solicitud de cambio.(..\02 Control Proyecto\04 Control Cambios\00 Formatos\ISP2 X ControldeCambios.vsd) Si un cambio representa más del 5% del esfuerzo total del proyecto es necesario volver a estimar el alcance y el plan del proyecto. r Página 20 de 41

21 Guía de Trabajo Todo el personal asignado al proyecto debe conocer y respetar lo siguiente: Políticas de Operación de Y (GDC México Extendido) Lineamientos de Trabajo Acordados con el Cliente o Horario (especificado más adelante) o Reuniones de avance todos los lunes con el equipo de Y completo o Entrega del Plan de Trabajo actualizado todos los viernes al mediodía Plan de Trabajo acordado con el Cliente. Proceso de Desarrollo Elegido. Acuerdos de Seguridad y idad Hechos con el Cliente. o Consultar Propuesta y Contrato Horario de Trabajo Sitio Entrada Salida Comida Cliente 08:55 18:00 14:00 a 14:30 GDC Mexico 08:55 19:00 14:00 a 15:00 Días Festivos Cliente Días festivos 1º Enero, Primer Lunes de Febrero, Tercer Lunes de Marzo, 1º de Mayo, 16 de Septiembre, Tercer Lunes de Noviembre, 1º de Diciembre de cada 6 años Herramientas Herramienta Version Usada Por Microsoft Word 2003 Todos Microsoft Excel 2003 Todos Microsoft PowerPoint 2003 Todos Microsoft Project 2003 Todos Source Safe 6.0 Todos CASE SENSE V2.6 Analistas y Diseñadores VISIO 2003 Líder de Proyecto r Página 21 de 41

22 Plan de Comunicaciones Tipo Clasificación Reglas de Uso Cara a Cara Primaria Utilizada para la resolución de dudas de los Analistas para los Requerimientos Funcionales y por el Líder Técnico para la Toma de Decisiones Técnicas. Correo Electrónico Primaria Utilizada respetando las reglas de confidencialidad (los correos deben traer la cláusula de confidencialidad) y tamaño máximo (1 MB) Telefónica Secundaria Será utilizada por el Lider de Proyecto y los Analistas cuando comience la Fase de Construcción (se mueven a las instalaciones del GDC), para comunicarse con el cliente (Sistemas y Funcional) Conference Calls Terciaria Utilizada para las juntas de avance. Se pone en conferencia a las personas que sean requeridas pero que no pueden estar en sitio. Juntas Tipo Participantes Herramienta Frecuencia Objetivo Junta de Proyecto Junta con Sistemas Junta con el Cliente Director Operaciones Líder Equipo de Trabajo Líder Cliente de Sistemas Líder Cliente Funcional Minuta Quincenal y a petición Describir el estado del proyecto e identificar riesgos y problemas Minuta Semanal Describir el estado del proyecto e identificar riesgos y problemas Minuta Semanal Describir el estado del proyecto e identificar riesgos y problemas Peticiones Tipo Responsable Herramientas Anticipación Comentarios Vacaciones Todos Solicitud de vacaciones Permisos Todos Solicitud de vacaciones Un mes Solicitadas a Capacity Planning con autorización del Líder y Vo.Bo. del Cliente 2 días Solicitados al Líder Proyecto Revisión Formal Todos Minuta Una semana Los revisores deben ser validados por el Líder de Proyecto Junta Líder Minuta Un día Enviar la minuta por anticipado incluyendo la información a tratar, asistentes y agenda, una vez terminada actualizar los acuerdos y acciones. Recursos humanos Recursos computacionales Recursos de infraestructura Líder Líder Líder Formato de solicitud Formato de solicitud Formato de solicitud Soporte técnico Líder Formato de solicitud Consumibles Líder Formato de solicitud 2 semanas A Capacity planning, requiere autorización del OM 2 semanas A Help desk, requiere autorización del OM 2 semanas A Help desk o a Oficina, requiere autorización del OM Cuando sea necesario A Help desk 1 semana A Oficina, requiere autorización del OM r Página 22 de 41