plan de desarrollo softwaresvalero/docs/pds3.pdfplan de desarrollo de software (pds) confidencial r...
TRANSCRIPT
Versión: 1.0.0 Autor: XXXXX Fecha de publicación: Agosto 24, 2006 Confidencialidad. 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.
Plan de Desarrollo Software Ventas de Inventario
Plan de Desarrollo de Software (PDS)
Confidencial r Página 2 de 41
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 Objetivo
Miembros del Equipo de Desarrollo 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
Plan de Desarrollo de Software (PDS)
Confidencial r Página 3 de 41
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
Plan de Desarrollo de Software (PDS)
Confidencial r Página 4 de 41
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
Plan de Desarrollo de Software (PDS)
Confidencial r Página 5 de 41
Información del Proyecto
Información del P royecto
Código del Proyecto
Nombre del Proyecto
Negocio
Estatus
Información del C liente
Código del Cliente
Nombre del Cliente
Departamento
Ciudad
Información del S ervicio
Tipo de S ervicio Desarrollo de Software a la Medida
Tipo de C ompromiso Proyecto con Alcance, Tiempo y Costo Fijo
Política de Pago Pagos Parciales por Etapa/ Fase Terminada
Tecnología
Arquitect ura: 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 Esfuer zo
Fecha de I nicio: 03/07/2006
Fecha de F in: 04/05/2007
Esfuerzo (H oras): 15,692 hrs (42 Semanas, 10 Meses)
Número P romedio de Recursos 9
Máximo Número de R ecursos 19
Plan de Desarrollo de Software (PDS)
Confidencial r Página 6 de 41
Stakeholders del Proyecto
Directorio del Proyecto
Nombre Responsabilidad
IS (Id STK)
Teléfono E-mail
Directorio del Proyecto
Nombre Responsabilidad
Empresa Teléfono E-mail
Confidencial r Página 7 de 41
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.
Confidencial r Página 8 de 41
Proceso de Desarrollo del Proyecto
Arquitectura Aplicación Web Multicapas
Metodología Proceso de Desarrollo de Software de Y (PDSS)
Ciclo de Vida 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
Confidencial r Página 9 de 41
Definición Operativa por Servicios
Nomb re 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 Razones de la Desviación
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
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
Nombre Entregable Entregable Equivalente Y Cambio en la Descripción
No Aplica
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 Kinta na Estándares
Nombre Dashboard / Portlets Dashboard (D)/ Portlet (P)
Obligatorio Para (Rol)
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
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
Confidencial r Página 10 de 41
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
Media Complejidad Alta
Servicios/Transacciones en Línea 63 74 24 Servicios/Procesos Fuera de Línea (Lotes)
- - -
Entidades Lógicas de Información - 32 -
Confidencial r Página 11 de 41
Plan de Trabajo del Proyecto
Producto Punto Control #
Esfuerzo Fecha Inicio Fecha Fin Duración
(Días)
Primera Etapa
Inicializar Proyecto de Software (ISP) 1 366 24
Documento de Diseño Funcional del Sistema de Software 2,3 1761.5 58
Documento de Requerimientos No Funcionales del Sistema de Software
4,5 98 9
Documento de Decisiones Técnicas y Tecnológicas 6 282 19.5
Subsistemas de Soporte 7 263 263
Firma Primera Etapa 8 2 263
Diseño Estructural/Técnico del Sistema de Software 9 3360 52.5
Construcción y Prueba Unitaria de Componentes del Sistema de
Software 10 3360 60
Integración de Componentes y Pruebas de Integración
11 1791.5 40
Carga Inicial de Información y Configuración del Sistema de
Software 12 1680 35
Pruebas de Aceptación del Sistema de Software con el Cliente 13 1920 28.5
Elaboración de Manuales de Usuario e Instalación 14 120 2.5
Desarrollo de Material de Entrenamiento y Entrenamiento a
Usuarios 14 192 4
Soporte a Usuarios durante Período Inicial de Operación 15 240 5
Formalización Cierre de Proyecto 16 176 4
Punto de Control Final (Carta de Aceptación Firmada) 16 16 1
TOTAL 15,692 205.5
El Plan de Trabajo está ubicado en el siguiente documento:
Plan de Viajes
Objetivo del Viaje Quien Fecha Duración
No Aplica
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)
Confidencial r Página 12 de 41
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
Confidencial r Página 13 de 41
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 Tipo de Decisión
Cuando un esfuerzo significativo del Proyecto (>10%) será destinado a la Decisión
Técnica
Cuando los problemas se presentan una segunda vez y diferentes alternativas han sido identificadas para resolverlos
Todos
Decisión de Alto Riesgo 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
Baja Alto
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
Media Alto
3
4
5
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.
Confidencial r Página 14 de 41
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
Recurso Responsible de Proveerlo
Licencias y Componentes de Software Cliente
Equipamiento en Sitio Cliente
Facilidades e Sitio como Lugares, Teléfono, Internet, Impresoras Cliente
Facilidades de Acceso como Tarjetas, Oficios, etc Cliente
Acceso a los Sistemas Actuales tales como Cuentas de Usuario, Cuentas de Correo, Conexión. Etc
Cliente
Acceso a las áreas del cliente usuario Cliente
Acceso a las áreas de Soporte del cliente tales como Soporte Técnico, etc Cliente
Acceso a la documentación existente (Especificación del Sistema, Flujos de Proceso, Documentos, etc)
Cliente
Políticas, Reglas y Estándares de Desarrollo utilizados por el Cliente Cliente
Librerías usadas en el Proyecto (Seguridad, Encriptación, o Librerías de Autentificación) Cliente
Gastos de Viajes Cliente
Ambientes de QA Cliente
Casos de Prueba de Aceptación del Cliente y Datos de Prueba Cliente
Notas Ninguna
Confidencial r Página 15 de 41
Ajustes
Diferencias sobre el Proceso Estándar Justificación
Se utilizan procesos en vez de casos de uso 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.
Entregables ajustados de acuerdo a la Propuesta 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.
Confidencial r Página 16 de 41
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)
Confidencial r Página 17 de 41
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
Windows XP Professional, MS Office, Sense, Visio, Project, Internet Explorer.
4
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.
1
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.
2
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.
2
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.
10
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
7
Estacionamiento (Cliente) Lugar de estacionamiento, sin cobro 3
Espacio Físico (GDC) Espacio para equipo de desarrollo y analistas 20
Confidencial r Página 18 de 41
Plan de Entrenamiento
Técnico
Área de E ntrenamiento 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 E ntrenamiento Duración Rol Material Instructor
Inducción a los Macroprocesos de Negocio del Proyecto
5 días Líder Proyecto Analistas
Presentación de los Procesos de Negocio, Premisas Generales y Especificaciones Técnicas
Descripción y explicación detallada de los Scripts generados por cada Proceso de Negocio
10 días Líder Proyecto Analistas
Revisión detallada de los Scripts de Negocio de cada uno de los Procesos a detalle
Proceso
Área de Entrenamient o 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
Confidencial r Página 19 de 41
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
Semanal
Nuevos Requerimientos Líder Change Control Log Traceability Matrix
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 Responsable de la minuta
Minuta una vez terminada la junta
Respaldos Administrador de la configuración
Backups Log Una vez realizado el respaldo
Revisiones
Concepto Responsable Herramienta Frecuencia Objetivo
Avance del proyecto con el cliente
Líder Reporte de Avance Semanal Informar el estado del avance del proyecto al cliente
Avance del proyecto con el OM
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) Líder Responsable de QA
Checklist de Auditoria Al inicio de cada etapa
Revisar si el proceso es usado como se debe
De Administración de la Configuración
Administrador de la configuración Responsable de QA
Cheklist de Auditoria Configuration Management Audit
Semanal Revisar si los procedimientos de control de versiones y la información del repositorio son correctas y confiables
De Análisis y Diseño Funcional
Líder de Proyecto QA de Análisis
Checklist y Alcance Funcional
Los primeros 2 productos del Analista
Revisar que el Análisis Modelado en el SENSE cumpla en forma y fondo con la Metodología y los Requerimientos
De Diseño Técnico Líder Técnico Estándares de Diseño En cada producto de diseño generado
Revisar que el Diseño Técnico cumpla con los Estándares definidos para el Proyecto
De Codificación Supervisor de Desarrollo (Programación)
Estándares de Codificación
En cada programa desarrollado
Revisar que la Codificación
Confidencial r Página 20 de 41
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.
Confidencial r Página 21 de 41
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 Confidencialidad 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
Días festivos
Cliente 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
Confidencial r Página 22 de 41
Plan de Comunicaciones
Tipo Clasificación Reglas de U so
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 Director Operaciones Líder Equipo de Trabajo
Minuta Quincenal y a petición Describir el estado del proyecto e identificar riesgos y problemas
Junta con Sistemas
Líder Cliente de Sistemas
Minuta Semanal Describir el estado del proyecto e identificar riesgos y problemas
Junta con el Cliente
Líder Cliente Funcional
Minuta Semanal Describir el estado del proyecto e identificar riesgos y problemas
Peticiones
Tipo Responsable Herramientas Anticipación Comentarios
Vacaciones Todos Solicitud de vacaciones
Un mes Solicitadas a Capacity Planning con autorización del Líder y Vo.Bo. del Cliente
Permisos Todos Solicitud de vacaciones
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
Líder Formato de solicitud
2 semanas A Capacity planning, requiere autorización del OM
Recursos computacionales
Líder
Formato de solicitud
2 semanas A Help desk, requiere autorización del OM
Recursos de infraestructura
Líder Formato de solicitud
2 semanas A Help desk o a Oficina, requiere autorización del OM
Soporte técnico Líder Formato de solicitud
Cuando sea necesario
A Help desk
Consumibles Líder Formato de solicitud
1 semana A Oficina, requiere autorización del OM
Confidencial r Página 23 de 41
Organización del Proyecto
Organigrama General
Confidencial r Página 24 de 41
Organigrama General
Confidencial r Página 25 de 41
Matriz de Escalamiento Nivel Asunto Y X Tiempo
1 Negociación de Alcance, Duración y Precio del Proyecto
Director de Operaciones
Gerente de Proyecto
1
2 Asignación de Recursos al Proyecto
Líder de Proyecto Líder de Proyecto
10 días
3 Control de Avance del Proyecto Líder de Proyecto Líder de Proyecto
1 día
4 Aprobación de Productos y Resultados del Proyecto
Líder de Proyecto Líder de Proyecto
1 día
5 Levantamiento/ Validación de Requerimientos
Analista(s) Usuario(s) de Negocio
1 día
6 Revisiones Técnicas y Definición de Estándares
Líder Tecnológico Expertos Técnicos
1 día
Roles y Responsabilidades Adicionales
Rol Responsabilidades A dicionales
QA Equipo Funcional Realizar los Peer Review de los Entregables Funcionales de la Primera Etapa (Prototipo, SENSE y Modelo de Datos)
Confidencial r Página 26 de 41
Reglas del Equipo de Trabajo
• Formalidad o Cualquier retraso en la hora de llegada debe ser notificada al Líder de Proyecto antes de la hora de
entrada. El tiempo de retraso debe recuperarse en el día que aconteció. o La retroalimentación del desempeño debe ser puntual, oportuna y constructiva, para cualquier
miembro del Equipo. o La retroalimentación formal de cada integrante del equipo se realizará al transcurrir 6 meses de su
asignación o al término del Proyecto. Esta responsabilidad es del inmediato superior de cada persona y es obligación del Líder de Proyecto asegurarse que se cumpla.
• Trabajo Asignado o Todo plan de trabajo asignado y acordado con una persona implica un compromiso que debe
cumplirse en tiempo y forma. o Todo acuerdo generado en el proyecto y con el cliente debe de ser documentado en minuta, no
importando si el acuerdo se realizó en una reunión formal o informal. o Todo acuerdo realizado debe de ser comunicado a todos los afectados. o Los planes de trabajo deberán de contemplar cargas de trabajo de ocho horas, de lunes a viernes y
no deberán incluir fines de semana ni días festivos. o Si una persona no puede cumplir con su plan de trabajo acordado, es su responsabilidad el trabajar
horas extras, fines de semana y/o días festivos para asegurar el cumplimiento de su plan de trabajo, siempre y cuando la desviación sea imputable a esa persona.
• Permisos y Ausencias o Los permisos por ausencia deben de solicitarse con la anticipación necesaria y se deberá recuperar
el tiempo perdido para cumplir el plan de trabajo. o Para solicitar vacaciones y permisos se debe de estar al corriente en el trabajo acordado.
• Convivencia o El uso del teléfono para fines personales esta permitido pero con moderación, siempre y cuando no
interfiera con el desempeño del proyecto. o El uso de Internet y de mensajeros debe ser moderado, y orientado a cuestiones de trabajo. o El quipo de cómputo asignado debe ser administrado de acuerdo a la responsiva firmada con Help
Desk, y el buen estado y limpieza del mismo es responsabilidad de cada persona o Sólo se permite el uso de equipos de sonido con audífonos.
Confidencial r Página 27 de 41
Plan de Administración de la Calidad
Conceptos de Calidad
Definición de Defecto Un defecto es algo que ocasiona que un producto liberado se comporte de forma inconsistente con los requerimientos de cliente.
Tipificación de Defectos al Diagnosticar Los principales tipos de Defectos son:
Tipo de Defecto Descripción
No Aplica= No es Defecto
La observación recibida no es defecto del producto, pero se debe fundamentar el porque no clasifica como defecto
Claridad =No es Claro
La redacción puede no ser clara para el usuario revisor por dos causas: 1. El analista no lo hizo de forma clara 2. El usuario revisor no lo entiende
Completa= No está completo
Este defecto se deriva de dos causas: 1. El usuario definidor no proporcionó completo la (s) Regla de Negocio/ Transformación que debe cubrir el Mapeo 2. El analista no conceptualizó completo la (s) Regla de Negocio/ Transformación que debe cubrir el Mapeo
Consistencia= No es consistente
La consistencia se debe dar en Entrada-Proceso-Salida de Datos del Mapeo. Esto quiere decir que un dato origen, debe ser procesado (de acuerdo a la (s) Regla (s) de Negocio/ Transformación) y cargado en el campo Destino correcto.
Correcto = No es Correcta la Regla Negocio/ Transformación
Correcto se refiere a el tratamiento a nivel Regla de Negocio / Transformación que se le aplica a un campo
Mapeo= Mapeo de Datos Incorrecto
El mapeo hace referencia a la relación Origen-Destino de un Campo en particular. El Mapeo incorrecto es cuando esta relación Origen-Destino es equivocada.
Método= Método mal Empleado
El Artefacto no cumple con los Lineamientos y Estándares establecidos para la fase correspondiente. Error del Analista/ Técnico Migración
Nivel de Detalle= Falta Nivel de Detalle
La (s) Regla (s) de Negocio tienen que ser detalladas más para lograr el resultado deseado.
Confidencial r Página 28 de 41
Criterios de Clasificación de la Severidad de los D efectos
Tipo Severidad Definición Acción
Alta El defecto es crítico porque afecta el alcance o impide al cliente utilizar el producto.
Este defecto debe ser arreglado. La Aplicación no puede ser liberada sin esta corrección
Media El mismo tipo de defecto ocurre en varias partes del producto, se necesita arreglarlo en todas esas partes, o bien el defecto impide utilizar el producto en la forma normal, pero existen alternativas para operar.
Es recomendable que este defecto sea arreglado
Baja El defecto esta aislado y no impide al cliente operar, pero causa inconveniencias.
Este defecto debe ser arreglado después de arreglar todos los anteriores
Técnicas de Revisión Formal
Técnica Herramienta Criterio de T erminación
Revisión en Grupo Checklists - Todos los checklists han sido aprobados - Todos los defectos han sido registrados y arreglados
Revisión Personal - Todos los defectos han sido registrados y arreglados
Revisión de Código Checklists - Todos los checklists han sido aprobados - Todos los defectos han sido registrados y arreglados
Ver el mapa de procesos para localizar los puntos de revisión formal y el proceso, ver el plan de productos para especificar la técnica utilizada en cada producto.
Objetivos de Calidad
Nombre Descripción Objetivo
Calidad Número de defectos encontrados por el cliente en productos
0 defectos encontrados después de la entrega de productos al cliente
Calidad Número de entregas del mismo producto al cliente 1 entrega
Oportunidad Tiempo de Entrega El producto es entregado en el tiempo acordado
Presupuesto Presupuesto Asignado al Proyecto (en horas) No rebasar el presupuesto asignado (en horas)
Confidencial r Página 29 de 41
Estrategia de Calidad de los Entregables
Criterio de Entrada de los Entregables
• El responsable del Entregable ha finalizado el documento. • El documento cubre los Estándares. • La información está completa y correcta • El responsable ha revisado el documento
Checklists Estándar
Nombre Checklist Ubicación Template
<<Checklist name>>
<<Location>>
Productos de la Estrategia de Calidad
Product o Tipo de Prueba de Calidad
Criterio de Término Alcance de la Prueba de Calidad
Checklist
Project Development Plan
Formal Review All identified defects have been fixed
- Meets project needs - Completeness - Omissions and
ambiguities
Master Work Plan Formal Review All identified defects have been fixed
- Meets project needs - Achievable - Omissions and
ambiguities
Detailed Work Plan
One Person Review
All identified defects have been fixed
- Meet project needs - Achievable - Omissions and
ambiguities
Business Requirements
Formal Review All identified defects have been fixed
- Implements all functional and non-functional requirements in scope
- Omissions and ambiguities
- Verification - Validation
Functional Specification
Formal Review All identified defects have been fixed
- Use Cases Implements all functional requirements in scope
- Omissions and defects in the design
- Verification - Validation
User Interface Design
Formal Review All identified defects have been fixed
- User Views Implements all functional requirements in scope
- Omissions and defects in the design
- Verification - Validation
Prototype Formal Review All identified defects have been fixed
- User Views Implements all functional requirements in scope
- Omissions and defects in the design
- Verification
Confidencial r Página 30 de 41
Product o Tipo de Prueba de Calidad
Criterio de Término Alcance de la Prueba de Calidad
Checklist
- Validation
Architecture Specification
Formal Review All identified defects have been fixed
- The system architecture is achievable
- Omissions and other defects in design
- Verification - Validation
Technical Specification
Formal Review All identified defects have been fixed
- Use Cases Realization Implements all Use Cases
- Omissions and defects in the design
- Verification - Validation
Configuration Guide
Formal Review All identified defects have been fixed
- Completeness - Usability - Omissions and
ambiguities
Deployment Guide Formal Review All identified defects have been fixed
- Meets application deployment needs
- Completeness - Omissions and
ambiguities
Source Code Peer Review All identified defects have been fixed
- Verification - Validation
CTQs del Proyecto Medir nos permite tener una visión más profunda del proceso y brinda un mecanismo para una evaluación objetiva. Las Métricas son usadas en el proyecto para fundamentar su estimación, control de calidad, evaluación de productividad, etc. Nos permiten darle seguimiento y control al proyecto, Las métricas nos ayudan a identificar áreas con problemas, para que podamos tomar acciones para resolverlos y mejorar el proceso. En la lista siguiente se encuentran todos los factores Críticos para la Calidad (CTQ’s) que serán usados para la medición del proyecto:
1. Critical to Quality Factor 1: Calidad de la Aplicación 2. Critical to Quality Factor 2: Tiempo de Entrega
Objetivos de Calidad
Descripción CTQ Métrica Formula Objetivo Min/Med/Max
First Time Right
Número de componentes con defecto reportado por el cliente durante la revisión o aceptación, dividido por el número de componentes desarrollado.
T=(1-Componentes con Defecto / Componentes Entregados)
99% 90%-95%-100%
OTD
Porcentaje del total de Requerimientos cerrado en el periodo de tiempo acordado o antes.
[Total requerimientos cerrados a tiempo o antes en el perídodo / Total de Requerimientos Cerrados en el Período]*100
98% 90%-95%-100%
Confidencial r Página 31 de 41
Descripción CTQ Métrica Formula Objetivo Min/Med/Max
Costo de Calidad Cost of Quality
Porcentaje del Esfuerzo Actual que es gastado en realizar Peer Review (Actual Appraisal) y retrabajado (Actual Rework) en el período actual.
[(Actual Appraisal + Actual Rework) / (Actual Effort + Actual Appraisal Effort + Actual Rework Effort)]*100
8% 5%-10%-15%
SPAN Rango de Variación de Días de Entrega.
Percentile .95 – Percentile .05 of the Delivery Days Variance Distribution
0 0-0-0
Objetivos de Calidad Adicionales
Descripción CTQ Métrica Formula Objetivo Min/Med/Max
No Aplica
Criterios de Aceptación • Criterio Aceptación 1: La prueba de aceptación del sistema de software (validada
previamente por X) arroja los resultados esperados en el ambiente de pruebas • Criterio Aceptación 2: El sistema de software y la documentación relacionada son
entregados (en medio magnético y/o impreso) al responsable del proyecto por parte de X
Prevención de Defectos El propósito de la prevención de defectos es identificar la causa de los defectos y prevenir su recurrencia. La prevención de defectos involucra el analizar los defectos que son encontrados en el pasado y tomar acciones específicas para prevenir la ocurrencia de esos tipos de defecto en el futuro. Para esta práctica, el equipo debe estar regido por monitores de defectos como se describe en las Métricas de Revisiones y en Juntas acordadas para este propósito específico son foros excelentes para la discusión y el análisis. Finalmente, los resultados de esas sesiones deben ser compartidas dentro del equipo para estar alerta y prevenir como se espera.
Confidencial r Página 32 de 41
Plan de Administración de la Configuración Cada producto entregado al usuario y cualquier documento con información relevante del proyecto debe ser mantenido bajo control con Administración de la Configuración. Se hace referencia al Mapa de Procesos para la distribución de las actividades de la Administración de la Configuración y su respectiva técnica en cada producto. Toda vez que un producto etiquetado necesite una modificación derivada de una Petición de Cambio de Software debido al cliente o debido a un problema generado por un defecto no detectado, se debe seguir el proceso Formalize Project Change (FPC).
Tablero de Control de Administración de la Configur ación Tablero de Control de Administración de Cambios de Software
Revisión : Analistas, Líder Técnico
Authorization: Líder de Proyecto
Herramientas de Administración de la Configuración Nombre de la Herramienta Vendedor Usada para
Visual Source Safe 6.0 Microsoft Control de Documentos
Tortoise CVS Open Source (GNU GPL)
Código fuente
Métodos de Identificación
Convenciones de Nombres
Archivos de Código Fuente
Consultar el Documento de Estándares de Diseño y Codificación
Documents Código Documento + Nombre Documento
Donde:
Código del Documento = Código Asociado al Documento Nombre del Documento= Nombre asociado al Documento
Numeración de Versión
Archivos de Código Fuente
La primera versión es la 1.0, los cambios mayores utilizan el segundo dígito 1.1, 1.2, etc. y los cambios menores el tercero 1.1.1, 1.1.2, etc.
Documentos No se utilizará numeración en los documentos ya que se controlará el repositorio en Source Safe. Lo que si es obligatorio es incluir en los comentarios cuando la versión que se va a guardar ya fue revisada o aprobada por el cliente.
Confidencial r Página 33 de 41
Convenciones de Etiquetas Cuando un producto es aprobado y liberado en el repositorio debe aparecer etiquetado como sigue:
Punto de Control 1 [Inicializar Proyecto de Software]
Punto de Control 2 [Documento de Alcance Funcional]
Punto de Control 3 [Documento de Diseño Funcional]
Punto de Cont rol 4,5 [Documento de Requerimientos No Funcionales]
Punto de Control 6 [Documento de Decisiones Técnicas y Tecnológicas]
Punto de Control 7 [Subsistemas de Soporte]
Punto de Control 8 [Firma Primera Etapa]
Punto de Control 9 [Diseño Estructural/Técnico del Sistema de Software]
Punto de Control 10 [Construcción y Prueba Unitaria de Componentes del Sistema de Software]
Punto de Control 11 [Integración de Componentes y Pruebas de Integración]
Punto de Control 12 [Carga Inicial de Información y Configuración del Sistema de Software]
Punto de Control 13 [Pruebas de Aceptación del Sistema de Software con el Cliente]
Punto de Control 14 [Elaboración de Manuales de Usuario e Instalación]
Punto de Control 15 [Desarrollo de Material de Entrenamiento y Entrenamiento a Usuarios]
Punto de Control 16 [Formalización Cierre de Proyecto]
Estructura del Repositorio Visual Source Safe
Perfiles de Usuarios
Perfil de Usuario Permisos de Acceso
Invitado Read
Miembro del Proyecto Read, Write
Líder del Proyecto Read, Write, Delete
Administrador Read, Write, Delete, Destroy
El repositorio del equipo de desarrollo está instalado en un equipo de uno de los integrantes de Proyecto, a reserva que se conceda espacio y acceso en un servidor del cliente para que se mueva el repositorio. El Líder Técnico es el responsable de la Administración y Respaldo del mismo.
Instalación, Conexión y Cuentas de Acceso La ruta para instalar el Software es: La conexión para acceder al Servidor de Source Safe es la siguiente: + Las cuentas de acceso (usuario y contraseña) se tramitan a través del Líder Técnico
Políticas del Repositorio 1. Al generar un documento nuevo, subirlo al servidor antes de retirarse
Confidencial r Página 34 de 41
2. Todos los documentos que existen en el repositorio, son las últimas versiones de los Productos del Proyecto. Para las entregas por Fase y Etapa, el Líder de Proyecto los descarga de SS.
3. Siempre trabajar a través de la descarga (check out) y carga (check in) de los archivos. No deben reemplazarse los archivos ya cargados en el Servidor.
4. Si el archivo es de uso común, o pertenece a otra persona y por motivos de revisión se descarga, al terminar la jornada (o el trabajo sobre el documento) cargarlo de nuevo para que esté disponible para el Equipo
5. La estructura de directorios tal como existe en Source Safe, debe ser replicada localmente en el disco duro de los equipos asignados al Proyecto X. Esta práctica tiene como objetivo, que en caso de requerirse un respaldo de una máquina, se haga sobre la ruta estándar.
Estructura del Directorio La estructura de directorios está generada de acuerdo a la Propuesta entregada al cliente:
Directorio Descripción de Contenido Perfil de Acceso
00 Administración del Proyecto Propuesta, Plan de Trabajo, PDP, Reportes de Avance, Documentación Funcional del Cliente
Todos
01 Definición de Requerimientos y Diseño Funcional
Modelo SENSE, Documento de Requerimientos Funcionales, Documento de Requerimientos No Funcionales
Todos
02 Toma Decisiones Técnicas Desarrollo - Adopción Subsistemas Soporte
Documento de Decisiones Técnicas y Tecnológicas Subsistemas de Soporte
Todos
03 Diseño Estructura – Técnico Modelo SENSE Diseño Técnico Modelo BD Casos Prueba Unitaria Casos Prueba Integración
Todos
04 Construcción y Prueba Unitaria Componentes Desarrollados Casos de Prueba Unitaria Ejecutados
Todos
05 Integración Componentes y Pruebas Integración
Componentes Integrados Casos Prueba Integración Ejecutados
Todos
06 Pruebas de Aceptación Cliente Componentes Probados Casos Prueba Cliente Ejecutados y Aprobados
Todos
07 Elaboración Manuales Instalación y Operación
Manual de Instalación Manual Operación
Todos
08 Carga Inicial de Información y Configuración
Archivos de carga inicial Scripts de carga
Todos
09 Desarrollo de Material de Entrenamiento
Manual de Entrenamiento Todos
10 Soporte a Usuarios Inicio Operación Bitácoras de Soporte Diagnosticadas y Aprobadas
Todos
Estructura del Repositorio Tortoise CVS
Perfiles de Usuarios
Perfil de Usuario Permisos de Acceso
Desarrollador Read, Write, Delete (Solo los archivos que haya creado.)
Supervisor de Desarrollo Read, Write, Delete, Destroy
Líder Técnico Read, Write, Delete, Destroy
Confidencial r Página 35 de 41
El repositorio del equipo de desarrollo está instalado en un equipo de uno de los integrantes de Proyecto, se esta evaluando la posibilidad de conseguir una maquina que funcione como servidor. El Líder Técnico es el responsable de la Administración y Respaldo del mismo.
Instalación, Conexión y Cuentas de Acceso La dirección del cvs es la siguiente: fefl/XDesarrollo fefl/X Las cuentas de acceso (usuario y contraseña) se tramitan a través del Líder Técnico
Políticas del Repositorio 1. El repositorio XDesarrollo se utiliza cuando el programador esta trabajando sobre una WA,
una vez que la termina y concluye con la prueba de integración lo sube al repositorio X. 2. La última versión del código siempre se encuentra en el repositorio X. 3. Los EAR (Enterprise Application Resource) donde va empaquetada la aplicación del X se
toma del repositorio de integración(X).
Confidencial r Página 36 de 41
Plan de Productos
Producto Código Fólder
Plan del Proyecto ISP2 00 Administración del Proyecto
Plan de Trabajo ISP3 00 Administración del Proyecto
Requerimientos de Negocio ASR1 01 Definición de Requerimientos y Diseño Funcional
Especificación Funcional ASR2 01 Definición de Requerimientos y Diseño Funcional
Diseño de Interfaz de Usuario ASR3 01 Definición de Requerimientos y Diseño Funcional
Prototipo WA+Numero+Descripción 01 Definición de Requerimientos y Diseño Funcional
Arquitectura ATD1 02 Toma Decisiones Técnicas Desarrollo - Adopción Subsistemas Soporte
Estándares de Proyecto ATD2 02 Toma Decisiones Técnicas Desarrollo - Adopción Subsistemas Soporte
Subsistemas de Soporte DSS1 02 Toma Decisiones Técnicas Desarrollo - Adopción Subsistemas Soporte
Especificaciones Técnicas ATD3 03 Diseño Estructura – Técnico
Base de Datos ATD4 03 Diseño Estructura – Técnico
Diseño de Pruebas ATD5 03 Diseño Estructura – Técnico
Especificación de Componentes SSW1 03 Diseño Estructura – Técnico
Checklists DTC1 03 Diseño Estructura – Técnico
Casos de Prueba DTC2 03 Diseño Estructura – Técnico
Código Probado Unitariamente CSW1 04 Construcción y Prueba Unitaria
Código Probado Integralmente ISW1 05 Integración Componentes y Pruebas Integración
Código Probado al Nivel de Sistema RAS1 05 Integración Componentes y Pruebas Integración
Documentación de Usuario DSW1 07 Elaboración Manuales Instalación y Operación
Guía de Configuración DSW2 07 Elaboración Manuales Instalación y Operación
Guía de Implementación DSW3 07 Elaboración Manuales Instalación y Operación
Código Aceptado por el Usuario DSW4 06 Pruebas de Aceptación Cliente
Paquete de Software DSW5 06 Pruebas de Aceptación Cliente
Aceptación del Proyecto DSW6 00 Administración del Proyecto
Reporte de Cierre FPT1 00 Administración del Proyecto
Seguimiento del Proyecto PTO1 00 Administración del Proyecto
Reportes de Avance Semanal PSR+año-mes-día 00 Administración del Proyecto
Confidencial r Página 37 de 41
Configuración del Ambiente
Ambiente de Desarrollo
Hardware Software Comentarios
Lap Top o Desk Top WebSphere Application Studio v5, Internet Explorer 6
Por Definir Hardware Servidor WebSphere Application Server v5, Oracle 10 g, Sistema Operativo AIX 5,2 Nivel 6
Ambiente de Pruebas
Hardware Software Comentarios
Lap Top o Desk Top WebSphere Application Studio v5, Internet Explorer 6
Por Definir Hardware Servidor WebSphere Application Server v5, Oracle 10 g, Sistema Operativo AIX 5,2 Nivel 6
Ambiente de Producción
Hardware Software Comentarios
Lap Top o Desk Top WebSphere Application Studio v5, Internet Explorer 6
Por Definir Hardware Servidor WebSphere Application Server v5, Oracle 10 g, Sistema Operativo AIX 5,2 Nivel 6
Configuración del Software
Software Versión Configuración
WebSphere Application Server 5 JDK IBM 1.3.1
WebSphere Application Studio 5 JDK IBM 1.3.1
Oracle 10g
Internet Explorer 6
Microsoft Office 2003
Configuracion de la Conectividad
Conectividad Configuración
Confidencial r Página 38 de 41
Plan de Respaldos
Área de Almacenamiento Completo/ Incremental Medio Frecuencia Responsable
Disco Duro PC Alterna Completo A través de la Red Semanal Líder Técnico
CD Respaldo Completo Local Servidor Mensual Líder Tecnico
CD Respaldo Final Completo Local Servidor Al Cierre del Proyecto Líder Técnico
Proceso de Respaldo
1. Del Servidor se va a replicar a través de la red la BD de Source Safe a un equipo alterno cada semana
2. Del Servidor se respalda a un CD de forma local de la BD de Source Safe cada mes 3. Al cierre del Proyecto se respalda a un CD de forma local de la BD de Source Safe
Proceso de Restauración
1. Del área de almacenamiento definida para la restauración (indicada por el Líder de Proyecto), se copia al disco duro del Servidor a través de la red
2. Se verifican los usuarios y permisos 3. Se verifica la fecha de los documentos
Plan de Recuperación de Desastre <<Por Definir>>
Confidencial r Página 39 de 41
Plan de Pruebas Cada producto de software desarrollado debe ser probado antes de ser entregado al usuario para verificar que cumple con sus requerimientos.
Entradas de las Pruebas Los siguientes elementos han sido identificados como objetivos para probar el software, esta lista incluye lo que será probado:
• Requerimientos funcionales • Requerimientos no funcionales • Procesos
Estrategia de Pruebas La siguiente lista describe como serán probados los requerimientos.
Prueba Tipo Alcance de la Prueba Herramienta Criterio de Aceptación
Pruebas Unitarias
Prueba de Componentes
- Prueba de interfaz de usuario
- Prueba de validación de datos
- Prueba de manejo de errores y mensajes
- Pruebas de impresión - Pruebas de importación y
exportación de datos - Pruebas de funcionalidad de
componentes - Pruebas de código (métodos
y procedures)
Checklists - Todos los checklists han sido aprobados
- Todos los defectos han sido registrados y arreglados
Pruebas Integrales
Pruebas funcionales
- Pruebas de seguridad y control de accesos
- Pruebas de escenarios de negocio
- Pruebas de ciclo de negocio - Revisar documentación
Casos de Prueba
- Todos los checklists han sido aprobados
- Todos los defectos han sido registrados y arreglados
- Todos los requerimientos funcionales han sido satisfechos
Pruebas de sistema
Pruebas de desempeño
- Tiempo de respuesta - Volumen de carga - Estrés
Casos de prueba
- Todos los casos de prueba seleccionados han sido ejecutados
- Todos los defectos han sido registrados y arreglados
- Todos los requerimientos no funcionales han sido satisfechos
Pruebas de sistema
Pruebas de Setup
- Pruebas de instalación - Pruebas de configuración - Pruebas de desinstalación
Casos de prueba
- Todos los pasos en la instalación y configuración han sido ejecutados satisfactoriamente
- Todos los casos de prueba seleccionados han sido ejecutados
- Todos los defectos han sido registrados y arreglados
Las principales consideraciones para la estrategia de prueba son las herramientas y los criterios de aceptación, además de las consideraciones para cada prueba descritas a continuación, es necesario ejecutarlas en un ambiente controlado con Bases de Datos seguras.
Confidencial r Página 40 de 41
Plan de Productos
Producto Revisión Formal / Prueba Herramienta
Statement of Work Revisión personal - Checklist del documento
Plan del Proyecto Revisión personal - Checklist del plan del proyecto
Plan de Trabajo Revisión personal - Checklist del plan del proyecto
Requerimientos del Negocio Revisión de grupo - Checklist del documento
Especificaciones Funcionales Revisión de grupo - Checklist del documento
Diseño de la Interfaz de Usuario Revisión de grupo - Checklist del documento
Arquitectura Revisión de grupo - Checklist del documento
Estándares de Proyecto Revisión de grupo - Checklist del documento
Especificaciones Técnicas Revisión de grupo - Checklist del documento
Base de Datos Revisión de grupo - Modelo de BD
Subsistemas de Soporte Pruebas unitarias Revisión de codigo
- Checklist del código - Checklist de interfaz de usuario
Especificación de Componentes Revisión de grupo - Checklist del documento
Casos de Prueba Revisión de grupo - Checklist del documento
Código de Componentes Pruebas unitarias - Checklist del código - Checklist de interfaz de usuario
Código Probado Unitariamente Revisión de código - Checklist del código - Checklist de interfaz de usuario
Código Integralmente Probado Prueba integral
- Consultar la Matriz de Seguimiento para los casos de prueba específicos para cada requerimiento
Código Probado al Nivel de Sistema Prueba de sistema - Matriz de Seguimiento para los casos de prueba específicos para cada requerimiento
Documentación de Usuario Revisión de grupo - Checklist del documento
Guía de Configuración Revisión de grupo - Checklist del documento
Guía de Implementación Revisión de grupo - Checklist del documento
Código Aceptado por el Usuario Prueba de aceptación del usuario
- Casos de prueba del usuario
Paquete de Software Revisión de grupo - Componentes Probados e Integrados
Aceptación del Proyecto Revisión personal - Checklist del documento
Reporte de Cierre Revisión personal - Checklist del documento
Seguimiento del Proyecto Revisión personal - Plan de Trabajo y Reportes de Avance
Confidencial r Página 41 de 41
Glosario CTQ (Critical To Quality) Requerimientos no Funcionales Defecto El producto no contiene / no se comporta de acuerdo a los requerimientos del
cliente Entregable Cualquier producto comprometido con el cliente y que requiere de su
aprobación. Producto Cualquier producto que necesita ser desarrollado para asegurar la consistencia
del proceso. SLA (Service Level Agreement) Métrica que corresponde a los CTQs del cliente.