plan de desarrollo softwaresvalero/docs/pds3.pdfplan de desarrollo de software (pds) confidencial r...

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



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



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



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



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


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.


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


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


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 -


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)


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


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.


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


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.


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)


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



1



2



2



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


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


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


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.


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


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


Organización del Proyecto

Organigrama General


Organigrama General


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)


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.


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.


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)


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


- Implements all functional and non-functional requirements in scope

- Omissions and ambiguities

- Verification - Validation

Functional Specification


- Use Cases Implements all functional requirements in scope

- Omissions and defects in the design


User Interface Design


- User Views Implements all functional requirements in scope



Prototype Formal Review All identified defects have been fixed

- User Views Implements all functional requirements in scope


- Verification


Product o Tipo de Prueba de Calidad

Criterio de Término Alcance de la Prueba de Calidad

Checklist

- Validation

Architecture Specification


- The system architecture is achievable

- Omissions and other defects in design


Technical Specification


- Use Cases Realization Implements all Use Cases



Configuration Guide


- 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


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%



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


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.


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.


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


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


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).


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


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




Ambiente de Producción




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


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>>


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 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 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


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.


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


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.