metodologia pbs v10

7/23/2019 Metodologia Pbs v10

http://slidepdf.com/reader/full/metodologia-pbs-v10 1/19

Araoz 749 3º B - C1414DPO(+54 11) 5353 9824Buenos Aires – Argentina

[email protected]

METODOLOGÍA DE GESTION DE PROYECTOS



Página 2 de 19


[email protected]

CONTENIDO

CONTENIDO ........................................................................................................................................................... 2

ALCANCE .............................................................................................................................................................. 4

MARCO METODOLÓGICO ........................................................................................................................................4

ETAPAS DEL PROCESO ..........................................................................................................................................5

1. ETAPA 0: I NICIACIÓN.................................................................................................................................................5 F ASE DE I NICIO ..............................................................................................................................................................5

2. ETAPA 1: PLANEAMIENTO .........................................................................................................................................6 F ASE DE P LANIFICACIÓN DEL PROYECTO.........................................................................................................................6

3. ETAPA 2: EJECUCIÓN.................................................................................................................................................6 F ASE DE D ISEÑO Y D ESARROLLO.....................................................................................................................................6 F ASE DE I NTEGRACIÓN ...................................................................................................................................................6 F ASE DE V ALIDACIÓN Y V ERIFICACIÓN ............................................................................................................................6 F ASE DE I MPLEMENTACIÓN .............................................................................................................................................7

4. MONITOREO Y CONTROL DEL PROYECTO ..................................................................................................................7 5. ETAPA 3: CIERRE.....................................................................................................................................................7

ESTRUCTURA Y EQUIPO, ROLES Y RESPONSABILIDADES......................................................................................... 8

1. R OLES Y R ESPONSABILIDADES ..................................................................................................................................8 1.1. P ROJECT M ANAGER C LIENTE ( O I NTERLOCUTOR FORMAL )....................................... ............................................ 8 1.2. P ROJECT M ANAGER PBS .............................................................................. ...................................................... 9 1.3. BOARD ...............................................................................................................................................................9 1.4. A RQUITECTO S OLUCIÓN ......................................................................................................................................9 1.5. A NALISTA F UNCIONAL.......................................................................................................................................10 1.6. D ESARROLLADOR..............................................................................................................................................10 1.7. A NALISTA T ESTER .............................................................................................................................................10 1.8. A DMINISTRADOR DE LA C ONFIGURACIÓN ..........................................................................................................10

ENTREGABLES..................................................................................................................................................... 11

1. E NTREGABLES POR ETAPA.......................................................................................................................................11 2. DETALLE DE E NTREGABLES POR FASE ....................................................................................................................12 3. DESCRIPCIÓN DE E NTREGABLES..............................................................................................................................12

P ROPUESTA DE S ERVICIO..............................................................................................................................................12 E SPECIFICACIÓN DE R EQUERIMIENTOS .........................................................................................................................13 A RQUITECTURA Y D ISEÑO A LTO N IVEL ..........................................................................................................................13 P LAN G ENERAL DE P ROYECTO ......................................................................................................................................13 C RONOGRAMA ..............................................................................................................................................................13

D ISEÑO D ETALLADO.....................................................................................................................................................14 V ERSIÓN D ESARROLLO (C ARÁCTER I NTERNO PBS) .................................................... .................................................... 14 V ERSIÓN C ANDIDATA (C ARÁCTER I NTERNO PBS)............................................ ........................................................... ...14 V ERSIÓN F INAL.............................................................................................................................................................14 V ERSIÓN P RODUCCIÓN .................................................................................................................................................15 C ASOS DE P RUEBA (C ARÁCTER I NTERNO PBS) .......................................................... .................................................... 15

R EPORTE DE P RUEBA (C ARÁCTER I NTERNO PBS) ...................................................... .................................................... 15 M ANUALES ...................................................................................................................................................................15 I NFORME DE AVANCE ....................................................................................................................................................15



Página 3 de 19


[email protected]

S OLICITUD DE C AMBIO .................................................................................................................................................16 DOCUMENTOS ACTUALIZADOS ......................................................................................................................................16 L ECCIONES A PRENDIDAS (DOCUMENTO DE C ARÁCTER I NTERNO PBS)...................... ..................................................... 16

ANEXO CONTROL DE CALIDAD .............................................................................................................................17

1. EL MODELO V ................................................... ............................................................ .......................................... 17 2. METODOLOGÍA DE VERIFICACIÓN Y VALIDACIÓN...................................................................................................18

ACTIVIDADES DE V ALIDACIÓN Y V ERIFICACIÓN ..............................................................................................................18



Página 4 de 19


[email protected]

ALCANCE

Este documento contiene una descripción resumida de la Metodología de Gestión de Proyectos,PBST RES , utilizada por Pampa Business Solutions SRL (en adelante PBS)

MARCO METODOLÓGICO

PBST RES es el la Metodología de Gestión de Proyectos creada por PBS como marco metodológico a losproyectos que administra.

PBST RES está basada en un estándar mundialmente reconocido en la gestión de proyectos, Metodologíade Project Management del PMI (Project Management Institute). En aspectos relacionados con eldesarrollo de Software PBST RES toma como base el Modelo de calidad CMMI (Capability Maturity ModelIntegration) del SEI (Software Engeenering Institute). Asimismo se encuentra alineada, en aspectosrelacionados con la gestión de la calidad, al Standard ISO 9001:2000.

PBS cuenta en su equipo con skills de Project Manager Professional (Credencial PMP del PMI), consultorCMMI (Curso Oficial del SEI y Experiencia en implementación del Modelo) y Auditor interno ISO 9001:2000quienes trabajaron en la creación este marco.



Página 5 de 19


[email protected]

ETAPAS DEL PROCESO

PBST RES divide al proyecto en las siguientes grandes Etapas: I NICIACIÓN P LANEAMIENTO E JECUCIÓN C IERRE

Y una Etapa cross a todo el proyecto denominada M ONITOREO Y C ONTROL (En el gráfico puede verse bajolos puntos de Control que acompañan a las Fases del Proyecto)

Cada una de las Etapas contiene una o más Fases del ciclo de Vida del Proyecto

Esta metodología representa un modelo/guía a seguir en la gestión de nuestros proyectos, basadaen buenas prácticas del mercado. Su aplicación puede ser adaptada al tipo, tamaño de proyecto y demáscaracterísticas respetando una de nuestras fortalezas que resulta ser la flexibilidad de PBS.

1. ETAPA 0: INICIACIÓN

El objetivo de esta Etapa es dar por comienzo a un nuevo Proyecto ó Fase del mismo. Dentrode esta etapa se incluye la elaboración de la propuesta y su refinamiento hasta aprobación paradar inicio a la siguiente etapa de Planeamiento.

Esta Etapa puede iniciarse por un requerimiento de un cliente o bien por una iniciativa internapara la incorporación de un nuevo producto o servicio al portfolio de PBS. En esta instancia elestudio de factibilidad del proyecto se supone ya ha sido superado.

FASE DE INICIO PBS asigna un Project Manager. Definir los requerimientos del producto. Identificar grandes riesgos y alternativas de respuesta. Identificar alternativas y realizar recomendaciones a ser tenidas en cuenta a lo largo del

proyecto. Generar documento de propuesta para aprobación. Identificar interlocutores por parte del Cliente y de PBS. Generar Plan Preliminar del proyecto (puede ser o no parte de la misma propuesta). Obtener aprobación.



Página 6 de 19


[email protected]

2. ETAPA 1: PLANEAMIENTO

En esta Etapa se refinan las tareas de definición de alcance del proyecto y se elabora endetalle el Plan General del Proyecto

FASE DE PLANIFICACIÓN DEL PROYECTO Asignar el equipo de proyecto. Identificar Stakeholders (partes interesadas) del proyecto. Formación del Board (Ver Estructura y Equipo, Roles y Responsabilidades 1.3BOARD). Refinar alcance del proyecto. Elaboración detallada de Plan General de proyecto que contempla aspectos tales como

recursos, cronograma detallado, gestión de riesgos, plan de comunicación, de monitoreoy control y de transición entre otros aspectos.

Seleccionar la alternativa técnica a implementar. Planificar tareas de Validación y Verificación. Obtener aprobación por parte del Board y generar Línea Base de Requerimientos.

3. ETAPA 2: EJECUCIÓN

En esta Etapa se pone en marcha el Plan de Proyecto de manera de obtener como resultadoel producto ó servicio dado.

A continuación se enumeran las grandes tareas a realizar. De acuerdo al ciclo de vida deDesarrollo utilizado pueden implementarse mediante distintas iteraciones o bien en cascada.

FASE DE DISEÑO Y DESARROLLO Refinar la Arquitectura planteada. Elaborar un diseño detallado. Desarrollar todos los componentes. Realizar pruebas unitarias a los componentes. Comenzar la etapa de administración de control de cambios. Integrar cada uno de los módulos. Generación de prototipos. Preparar los módulos para su testeo de integración.

FASE DE INTEGRACIÓN

Integración de los distintos módulos e interfaces. Integración con productos de terceros. Preparar la aplicación para las pruebas integrales y de sistemas.

FASE DE VALIDACIÓN Y VERIFICACIÓN Esta fase acompaña a toda la construcción e integración mediante las tareas de Verificación y

Validación. (Ver Anexo Control de Calidad).

Verificar la documentación del proyecto (especificación de requerimientos,documentación de diseño) para asegurar consistencia.

Preparación de los casos de prueba de acuerdo a los requerimientos de manera deasegurar que el producto cumple con las especificaciones.

Ejecución de las pruebas integrales y de sistema. Reportar errores y seguimiento hasta su cierre.



Página 7 de 19


[email protected]

FASE DE IMPLEMENTACIÓN Desplegar la solución en el ambiente de producción del cliente de acuerdo al plan de

despliegue conjunto. Asegurar el correcto despliegue que permita realizar las Pruebas de Aceptación del

Cliente. Realizar ajustes finales. Obtener Conformidad y aprobación por parte del Cliente.

4. MONITOREO Y CONTROL DEL PROYECTO

El Monitoreo y Control del proyecto acompaña a todo el Ciclo de Vida del Proyecto.Formalmente se establecen puntos de Control al finalizar cada Fase en los cuales se

solicita aprobación para pasar a la fase siguiente. Típicamente se genera algún reporte oinforme de fin de Fase. De acuerdo a la complejidad, tamaño y características del proyectoel cliente puede participar de la aprobación para pasar a la siguiente fase o bien serinformado de la transición.

Asimismo durante todo el ciclo de Vida del proyecto el Project Manager monitorea ycontrola las distintas restricciones: Alcance, Tiempo, Costos, Riesgos, Calidad ySatisfacción del Cliente. Esto lo hace a través del seguimiento de los planes, feedback querecibe del Equipo de Proyecto en las reuniones y seguimiento con el cliente generando asílos distintos informes.

Esta Etapa también contempla la Gestión de los Cambios del proyecto. Una vezdefinida y aprobada la Línea Base* de Requerimientos por ambas partes (Board), losCambios que se introduzcan serán gestionados mediante Solicitudes de Cambio. Una

Solicitud de Cambio puede ser generada por el cliente o bien por el Equipo de Proyecto alidentificar algún cambio que se considera necesario para el cumplimiento de las distintasrestricciones.

Los Cambios son gestionados a través del Procedimiento de Administración deCambios definido previamente en el Plan General de Proyecto. En líneas generales, seanaliza el impacto, se requiere aprobación por parte del Board (o representantes del clientey PBS) y, en caso de ser aprobado, se actualizan los planes.

*Línea Base de Requerimientos: Conjunto de Requerimientos en un momento dado que definen el alcancedel proyecto

5. ETAPA 3: CIERRE

Esta Etapa comprende la transición que asegure la completa operatividad del productoen el ambiente de producción del cliente así como el cierre del Proyecto.

Traspaso de Información Operativa: Traspaso de información necesaria referida a laGestión de los Requerimientos, de manera tal que el Cliente pueda tomar la misma parala continuidad del servicio: Ej. backlogs de tareas pendientes, cumplidas, etc.

Traspaso de los sistemas mantenidos por PBS: compuesto por tareas de asesoramientosobre los sistemas e infraestructura necesaria para la correcta instalación de los mismosen las instalaciones que disponga el Cliente.

Transferencia de documentación: Actualización de documentación con las últimasmodificaciones.

Obtener aprobación formal por parte del cliente.

Asegurar la Garantía según contrato. Atender requerimientos de cambio (Mantenimiento). Cierre del proyecto: Lecciones Aprendidas.



Página 8 de 19


[email protected]

ESTRUCTURA Y EQUIPO, ROLES Y RESPONSABILIDADES

El Equipo de Proyecto se conforma de acuerdo a la complejidad, tamaño y otras características delproyecto. Típicamente está conformado por los roles que se indican en 1ROLES Y RESPONSABILIDADES. Paraproyectos pequeños, probablemente el mismo miembro del equipo realice más de un rol. Asimismo existenroles tales como Arquitecto de Software, Administración de la Configuración que tiene una asignación parttime, especialmente el primero, que presta mayormente servicios de consultoría inicial. Estos son expresadoscomo Soporte en el diagrama.

Idealmente se piensa en una estructura en la cual se tiene un interlocutor del lado del cliente y uninterlocutor del lado de PBS de manera de efectivizar las comunicaciones y agilizar las decisiones. Estasfiguras conforman el Board que podría o no estar formalmente establecido.

* Dentro de la subestructura Soporte se incluyen Roles tales como Arquitecto Solución, Administrador de la

Configuración, etc. que prestan servicios a distintos proyectos. Esto es porque se considera óptima suagrupación en una subestructura especializada que concentre conocimientos específicos de Arquitectura,Tecnología, etc.

1. ROLES Y RESPONSABILIDADES

1.1. PROJECT MANAGER CLIENTE (O INTERLOCUTOR FORMAL)Con el objetivo de facilitar y efectivizar la comunicación y toma de decisiones PBS solicita que se

nombre una persona que oficie como Representante del Cliente a quien se denomina Project ManagerCliente. Este rol es crucial en el éxito del proyecto. Representa la máxima autoridad por parte del clientepara el proyecto y su interrelación directa es con el Project Manager PBS



Página 9 de 19


[email protected]

El Project Manager Cliente es responsable de:

Monitorear el estado y avance del proyecto. Reflejar las necesidades de los Key Users. Gestionar la resolución de dudas o algún tipo de problema que vaya surgiendo a lo largo del

proyecto sirviendo de nexo ente los Key Users y PBS. Aprobar los documentos relacionados con el proyecto. Establecer las prioridades en cuanto a los requerimientos.

1.2. PROJECT MANAGER PBS El Project Manager PBS es responsable de:

Estimar el esfuerzo necesario para la realización del proyecto. Confeccionar la propuesta de Servicio. Generar el Plan General del Proyecto y planes subsidiarios. Administrar el Proyecto asignado y sus recursos, de manera que cumpla con las múltiples

restricciones que tiene: alcance, costos, tiempos, calidad, manejo de riesgos y satisfacción decliente.

Liderar el Proyecto asignado y conducir los recursos humanos del grupo de Proyecto. Supervisar la gestión integral de los colaboradores propios y del cliente (que participan como

referentes en el proyecto). Revisar y aprobar los documentos presentados por su equipo. Conocer los procesos de negocio en función del área de incumbencia. Comunicar aspectos del proyecto. Mantener informado a los distintos stakeholders del proyecto.

1.3. BOARD

El Board es un Comité formado por un representante por parte del cliente y un representantePBS. Típicamente lo componen los Project Manager de ambos lados. El Board podría estarformalmente establecido o no. De todos modos es responsabilidad de ambos representantes eltrabajo en conjunto en aspectos relacionados con la toma de decisiones, priorización, aprobación,etc. de manera de obtener consenso de ambas partes:

Analizar y aprobar requerimientos, documentos y planes. Gestionar la aprobación de ambaspartes.

Aprobar la Línea Base de Requerimientos. Analizar y aprobar o rechazar las Solicitudes de Cambio. Priorizar las Solicitudes de Cambio o Nuevas iniciativas. Obtener consenso en casos de discrepancia, por ejemplo en estimaciones, análisis de impacto

de algún cambio, etc.

1.4. ARQUITECTO SOLUCIÓN El Arquitecto de la Solución tiene como responsabilidad:

Definir y diseñar la arquitectura para soportar la aplicación. Definir y diseñar la configuración de los componentes de las aplicaciones. Comprender los requerimientos del sistema. Poseer Dominio de Ingeniería del Software. Tomar decisiones técnicas claves en términos de arquitectura. Documentar los aspectos significativos de la arquitectura, incluyendo requerimientos y las vistas

de diseño, implementación y despliegue. Participar en las estimaciones, principalmente en términos de arquitectura



Página 10 de 19


[email protected]

1.5. ANALISTA FUNCIONAL El Analista Funcional es responsable de:

Identificar y comprender las necesidades del cliente de manera de obtener una especificación derequerimientos.

Realizar tareas de Análisis y diseño de una solución que satisfaga las expectativas del cliente.Adicionalmente, supervisión de la programación, documentación, actualización y mantenimientode los sistemas informáticos.

Conocer y aplicar la metodología de desarrollo definida para el proyecto. Generar la Especificación del Sistema que sirva para codificar: Diseñar las entradas, salidas,

archivos y programas de cada sistema. Generar la documentación técnica y de calidad. Participar de las estimaciones de tiempo y esfuerzo así como en la evolución de impacto ante un

cambio.

1.6. DESARROLLADOR El desarrollador es responsable de:

Comprender los requerimientos Detallados, Diseños y Especificaciones realizados por elAnalista.

Realizar tareas de Programación de la aplicación. Realizar el testeo de cada componente desarrollado según la documentación especifica para

asegurar su buen funcionamiento (testeo unitario). Implementación, documentación, actualización y mantenimiento de las aplicaciones. Generar la documentación técnica y de calidad. Documentar programas de acuerdo a los

estándares de instalación. Participar de las estimaciones dando feedback a los analistas de tiempos y esfuerzos.

1.7. ANALISTA TESTER El Analista Tester es responsable de:

Diseñar Plan de Verificación y Validación /Testing (Ambientes de prueba, criterios de aceptación,criterios de suspensión de pruebas, etc.).

Verificar la documentación para asegurar consistencia. Diseñar Condiciones y Casos de Prueba (Test Cases). Crear datos de prueba teniendo en cuenta formatos definidos y especificaciones. Ejecutar las pruebas para comparar resultados con las especificaciones. Analizar resultados de pruebas y documentar y reportar defectos, errores, e inconsistencias en

las funciones de los programas, salidas, pantallas, y su contenido.

1.8. ADMINISTRADOR DE LA CONFIGURACIÓN La Gestión de la Configuración de versiones es un proceso que establece y mantiene la integridad

del los artefactos a través de su ciclo de vida. Contempla aspectos tales como versionado de todos losartefactos (fuentes, documentos, etc.), historial de cambios, gestión de la política de back up, etc.

El Administrador de la Configuración tiene como responsabilidades:

Identificar los recursos requeridos por cada aplicación para ser administrados. Dar soporte a las tareas de desarrollo del proyecto, asegurando la disponibilidad de un ambiente

de trabajo apropiado para el Equipo de Proyecto. Proveer un ambiente apropiado para las actividades de Validación/Testing. Liberar las correctas

versiones de los componentes.

Asegurar la disponibilidad e integridad de los diferentes artefactos para ser incluidos en la Unidadde despliegue cuando fuera necesario. Liberar a producción las correctas versiones de loscomponentes.



Página 11 de 19


[email protected]

ENTREGABLES

1. ENTREGABLES POR ETAPA



Página 12 de 19


[email protected]

2. DETALLE DE ENTREGABLES POR FASE

Como se mencionara anteriormente, la metodología así como los entregables pueden adaptarse altipo y características de proyecto o necesidades particulares del cliente. En proyectos chicos posiblementealgunos entregables puedan ser unificados o simplificados.

Los documentos o artefactos mencionados como de Carácter Interno PBS tienen una propósito degestión del proyecto en fases intermedias y no son necesariamente presentados al cliente como entregablesdel proyecto.

3. DESCRIPCIÓN DE ENTREGABLES

PROPUESTA DE SERVICIO Contiene una descripción del alcance, solución, presupuesto y condiciones de contratación.

Asimismo puede contener un cronograma preliminar, equipo de trabajo preliminar, roles y responsabilidades.El nivel de detalle de la misma puede variar de acuerdo a lo que solicite el cliente o bien el tiempoasignado/urgencia por parte del cliente para obtener la misma, etc. En cuanto al presupuesto y tiempos,puede estar expresado en Orden de Magnitud (donde se acepta cierta variación) o bien ser un presupuestofinal. Esto también depende de lo que el cliente solicite como propuesta, nivel de información disponible, etc.En casos donde el cliente requiera algún tipo de formato especial o información particular (ejemplo: pliegos)la misma puede adaptarse a dichas especificaciones.

Nomenclatura: [PROP_Cliente_Nombre del Proyecto_PBS]



Página 13 de 19


[email protected]

ESPECIFICACIÓN DE REQUERIMIENTOS

Definición inicial del Requerimiento de Software. Este documento reúne la documentación de losrequerimientos (funcionales y no funcionales) de software del proyecto. Asimismo sirve como base delacuerdo común entre todas las partes y formará el contenido de la línea base. Incluye una descripciónGlobal, definición de tipo de usuarios, lista de actores, características de la solución, ambiente de operación,supuestos y restricciones, requerimientos funcionales y no funcionales, interfaces necesarias y criterios deaceptación. Asimismo puede incluir una Visión General de la Arquitectura.

Este documento puede llegar a un nivel de detalle mayor incluyendo casos de uso en términos denegocio u otros diagramas o bien estas cuestiones ser incluidas directamente en los documentos de diseño.

Nomenclatura: [ERS_Cliente_Nombre del Proyecto_Nombre Req_PBS]

ARQUITECTURA Y DISEÑO ALTO NIVEL Contiene una descripción y representación de la arquitectura de la solución, supuestos y

restricciones de la misma, así como características de seguridad. Asimismo incluye aspectos de diseño dealto nivel tales como un análisis para la identificación de actores, definición de casos de uso en términos denegocio, etc.

Este documento puede ser parte de la Especificación de Requerimientos o bien tratarse comodocumento separado.

Nomenclatura: [DAG_Cliente_Nombre del Proyecto_PBS]

PLAN GENERAL DE PROYECTO

Define cómo se va a planificar, ejecutar, medir y controlar el proyecto. El Plan General de Proyectoes un documento madre que reúne distintos aspectos relacionados con la planificación de las distintasvariables que intervienen en el proyecto. Puede ser un único Plan o bien hacer referencia a distintos planes odocumentos subsidiarios tales como alcance, cronograma del proyecto, gestión de riesgos, Plan de Calidad(Validación y Verificación) y Plan de Gestión de la Configuración*. Asimismo incluye la planificación delEquipo de proyecto, skills, roles y responsabilidades, recursos materiales necesarios y aspectos relacionadoscon la comunicación tanto interna como con el Cliente.

El Plan es armado de acuerdo a cada proyecto, es posible que en proyectos chicos o dedeterminadas características algunos ítems sean no aplicables o bien su nivel de detalle sea menor.

* En el Plan de Gestión de la configuración se especifica aquellos artefactos (documentos, fuentes, etc.) queserán controlados, cómo se controlará la integridad de los mismos, políticas de backup, etc.

Nomenclatura: [PGP_Cliente_Nombre del Proyecto_PBS]

CRONOGRAMA Contiene las actividades con su fecha de inicio y fin, duración, secuenciamiento etc. El cronograma

también incluye los hitos del proyecto.

Nomenclatura: [SCH_Cliente_Nombre del Proyecto_PBS]



Página 14 de 19


[email protected]

DISEÑO DETALLADO Contiene una definición de mayor detalle de los requerimientos. Según la metodología de desarrollo

que se aplique y características del proyecto es posible incluir diagramas tales como:o Diagrama de Claseso Diagrama de Objetoso Diagrama de Actividadeso Diagrama de Casos de Uso y descripción de los mismoso Interfaces y diseños de pantalla

Este documento puede considerarse un refinamiento de la Especificación de Requerimientos y/odocumentos de diseño de alto nivel o bien entregarse como documento aparte.

Nomenclatura: [DAD_Cliente_Nombre del Proyecto_PBS]

VERSIÓN DESARROLLO (CARÁCTER INTERNO PBS)

Son las versiones intermedias generadas en el ambiente de desarrollo con los componentesdesarrollados (Build). Según la planificación, durante el desarrollo se generan distintas versiones que sonliberadas al ambiente de testing como versiones de prueba (test).

La nomenclatura de las versiones varía según el proyecto y componentes de versión. Una versiónpodría contener distintos paquetes (ejemplo: librerías, dll’s etc.). La nomenclatura del paquete que los agrupasigue los siguientes lineamientos

Tipos

Build: Versión desarrolloTest: Versión liberada a testing

Nomenclatura: [Numero de Versión]-[Tipo]-[Número de realease + 1]

VERSIÓN CANDIDATA (CARÁCTER INTERNO PBS)

Versión generada en etapa de integración de los distintos módulos. La misma es sujeta a pruebas deintegración por parte del equipo de testing. A lo largo de esta etapa se generan distintas instancias de estaversión producto de las correcciones hasta obtener la versión final.

Tipos

RC: Versión candidata


VERSIÓN FINAL

Corresponde a la versión que recibe el cliente para sus pruebas de aceptación.

Tipos

R: Versión Release




Página 15 de 19


[email protected]

VERSIÓN PRODUCCIÓN

Versión productiva. Posiblemente tenga un número de release diferente a la versión de testing deaceptación debido a los ajustes finales que puedan surgir de estas pruebas.

Tipos

R: Versión Release


CASOS DE PRUEBA (CARÁCTER INTERNO PBS)Preparación estructurada de las pruebas a realizar sobre el software. Los casos de prueba se

construyen de acuerdo a la especificación de requerimientos y son una enunciación de las distintassituaciones a probar. Los mismos contienen una descripción de la prueba, los datos de entrada, pasos aseguir y resultado esperado de la prueba.

Nomenclatura: [TCS_Cliente_Nombre del Proyecto_Req_Nro Caso_PBS]

REPORTE DE PRUEBA (CARÁCTER INTERNO PBS)

Los defectos, mejoras, etc. identificados durante las pruebas son registrados e informados adesarrollo para su corrección través de los reportes de prueba. Los Analistas Tester realizan el seguimientode los distintos defectos hasta la verificación de su cierre.

Nomenclatura: [REP_Cliente_Nombre del Proyecto_Tipo Prueba_PBS]

MANUALES Los manuales o documentación de usuario final constituyen un entregable más al cliente y resultan

clave en el aprendizaje del uso del sistema. Típicamente se manejan los siguientes tipos de manual:

Manual de Usuario (Orientación al usuario final. Enfoque desde la operación del software)Manual del Sistema (Orientación técnica)Manual de Instalación

En general el manual de Usuario y Sistema se presentan de manera unificada.

Nomenclatura: [MAN_Cliente_Nombre del Proyecto_Tipo Manual_PBS]

INFORME DE AVANCE La Etapa de Monitoreo y Control del Proyecto acompaña a todo el ciclo de vida del mismo. Como

producto del seguimiento de las distintas variables que intervienen en el proyecto se generan, segúnfrecuencia predefinida, los Informes de Avance del proyecto. El objetivo es reflejar el status del proyecto,detectar algún desvío e implementar, de manera temprana, acciones correctivas. Estos informes surgen delas reuniones con el Equipo de trabajo, reuniones con el cliente y seguimiento de indicadores y sondistribuidos a las partes involucradas según plan.

Nomenclatura: [INF_Cliente_Nombre del Proyecto_Fecha_PBS]



Página 16 de 19


[email protected]

SOLICITUD DE CAMBIO Este documento se genera con el objeto de documentar un Cambio solicitado. El mismo incluye una

descripción del cambio solicitado, motivo del cambio, quién lo solicita, requerimiento al cuál afecta, análisisde impacto del cambio y circuito de aprobaciones (Board, PBS, Cliente, etc.)

Nomenclatura: [SCA_Cliente_Nombre del Proyecto_Req_Nro Solicitud_PBS]

DOCUMENTOS ACTUALIZADOS Comprende la entrega al cliente de los documentos/entregables actualizados en su última versión

con todos los ajuste que pudieron haberse incorporado en las instancias previas al cierre.

LECCIONES APRENDIDAS (DOCUMENTO DE CARÁCTER INTERNO PBS)

En PBS creemos que una de las claves del crecimiento es la mejora continua de nuestros procesos,productos y servicios. En este sentido cuidamos cada uno de nuestros proyectos incorporando mejoras apartir del aprendizaje.

Al cierre del proyecto o, eventualmente al cierre de una fase en proyectos largos, se lleva a cabo lareunión de Lecciones Aprendidas que involucra a todo el equipo de Proyecto PBS con el objeto de rescatarlos aspectos positivos del proyecto, potenciarlos, explotarlos y mejorarlos, y aquellos aspectos sobre los quese identifican oportunidades de mejora. Estas conclusiones son volcadas en el Documento de LeccionesAprendidas.

Nomenclatura: [LL_Cliente_Nombre del Proyecto _PBS]



Página 17 de 19


[email protected]

ANEXO CONTROL DE CALIDAD

La Metodología de Validación y Verificación utilizada por PBS se encuentra alineada con las Áreas deProcesos VAL y VER del modelo CMMI nivel 3 utilizando el Modelo V como referencia.

1. EL MODELO V

El modelo V considera al testing una actividad importante en lugar de pensarlo como una amenaza alproyecto. Este modelo surge en reacción a ciertos modelos cascada que muestran al testing como una fasesingular posterior al análisis, diseño de alto nivel, diseño detallado y desarrollo.

El Modelo V representa varios niveles de testing e ilustra como cada nivel se encuentra alineado con unaetapa del ciclo de vida de desarrollo. La V muestra, del lado izquierdo, la típica secuencia de actividades dedesarrollo y, del lado derecho, su correspondiente secuencia de actividades de testing.

Del lado del desarrollo, se comienza definiendo los requerimientos de negocio, estos se traducen en alto ybajo niveles de diseño y finalmente se implementan en líneas de código. Del lado de la ejecución del testing,se comienza con las pruebas unitarias, seguidas por las de integración, sistema y aceptación.

Este modelo es valioso porque destaca la existencia de varios niveles de testing y delinea cómo serelaciona cada uno con diferentes fases del desarrollo.

• Las pruebas unitarias focalizan en los tipos de fallas que ocurren mientras se escribe código, tales comolos valores límite en la validación de la entrada de datos del usuario. Las pruebas unitarias sontípicamente realizadas por el mismo desarrollador.

• Las pruebas de integración se focalizan en el diseño de bajo nivel, especialmente chequeando erroresentre interfaces y unidades u otras integraciones.

• Las pruebas de sistema validan si, el sistema como un todo, implementa efectivamente el diseño de altonivel, incluyendo adecuada performance en un ambiente similar a producción.

• Las pruebas de Aceptación son típicamente realizadas por los usuarios (cliente) para confirmar que elproducto reúne los requerimientos de negocio.

En cada etapa de desarrollo, tienden a ocurrir diferentes tipos de fallas, de este modo distintas técnicasse utilizan para identificarlas.



Página 18 de 19


[email protected]

2. METODOLOGÍA DE VERIFICACIÓN Y VALIDACIÓN

VVAALLIIDDAACCIIÓÓNN:: Confirma que el producto, tal como se lo ofrece, cumplirá con el uso que se pretende.Las actividades de Validación en el proceso de desarrollo de Software tienen como principal objetivodeterminar si se está construyendo el producto correcto, según las especificaciones del Cliente. Paraesta finalidad se planifican, preparan, y ejecutan diferentes pruebas sobre el producto de software pararealizar una evaluación objetiva del mismo.

VVEERRIIFFIICCAACCIIÓÓNN:: El objetivo principal de la Verificación en el proceso de desarrollo de Softwareconsiste en determinar si se está construyendo el producto correctamente. Para tal fin es necesarioanalizar los entregables, documentos, etc. en las diferentes etapas del Ciclo de Vida de desarrollo (etapade requerimientos, etapa de diseño, etapa de codificación).

En ambos casos se apunta a la identificación temprana de defectos o inconsistencias de manera deasegurar un producto confiable y minimizar la aparición de defectos en etapas finales. En este sentidonos basamos en un principio que indica que el esfuerzo requerido en la corrección de un defecto, cuantomás temprano sea detectado, menor impacto tendrá en el proyecto.

ACTIVIDADES DE VALIDACIÓN Y VERIFICACIÓN

A. ASIGNACIÓN DE ANALISTAS TESTERS AL PROYECTO

De acuerdo a las necesidades del Proyecto se asignan uno o más Analistas Testers.

B. GENERACIÓN DE PLAN DE CALIDAD

El Analista Tester asignado planifica las actividades de Control de Calidad en el Proyecto e instanciaun Plan de Validación y Verificación (En general, las actividades de Validación y Verificación son incluidasen el mismo Plan).

C. VERIFICACIÓN DE LA DOCUMENTACIÓN

Las actividades de Verificación tienen como objetivo la revisión de la documentación de manera deidentificar tempranamente inconsistencias o cuestiones de lógica en los requerimientos, documentos dediseño, etc. y que las mismas sean comunicadas evitando que sean trasladadas a lo largo de las etapasde desarrollo. Estas inconsistencias de Documentación deben ser resueltas por el Analista oDesarrollador.

D. PREPARACIÓN DE CASOS DE PRUEBA

Los Casos de Prueba se generan tomando como input la documentación de Casos de Uso o ladocumentación de los Requerimientos/Funcionalidad que maneje el Proyecto. Para su confección, sedispone de un template donde se vuelcan las distintas pruebas a realizar, las pre-condiciones, post-condiciones, paso a paso, los resultados esperados, etc. Los Casos de Prueba se agrupan porMódulo, Subsistema, etc. y se almacenan en un repositorio, así como también los diferentes resultados delas ejecuciones.

E. EJECUCIÓN DE LAS PRUEBAS

Para la Ejecución de las pruebas se definen diferentes Fases. Cada Fase comprende un tipo deTesting diferente y se desarrollan diferentes Ciclos de Prueba, antecedidos por un Smoke Test (Prueba deHumo) que permite determinar rápidamente, mediante la validación de distintos aspectos predefinidos, sise sigue adelante o no con el testing.

La Ejecución comienza con las siguientes Fases:




[email protected]

Testing UnitarioTesting de Integración

Testing de Sistema

Cada Ciclo finaliza con una revisión formal de los resultados obtenidos y de los defectosdetectados con el Líder de cada Módulo, Paquete o Subsistema.

F. REPORTE DE PRUEBAS

A medida que se ejecutan las Pruebas, los defectos, mejoras, etc detectados son reportados. Estosson asignados al responsable de cada tema y se realiza un seguimiento de cada uno de los defectos,mejoras, etc. hasta su cierre.

metodologia pbs v10

Documents