Professional Documents
Culture Documents
CONTENIDO
CONTENIDO ........................................................................................................................................................... 2
ALCANCE .............................................................................................................................................................. 4
M ARCO METODOLGICO ........................................................................................................................................ 4
ETAPAS DEL PROCESO .......................................................................................................................................... 5
1.
ENTREGABLES..................................................................................................................................................... 11
1.
2.
3.
Pgina 2 de 19
EL MODELO V .........................................................................................................................................................17
METODOLOGA DE VERIFICACIN Y VALIDACIN ...................................................................................................18
ACTIVIDADES DE VALIDACIN Y VERIFICACIN..............................................................................................................18
Pgina 3 de 19
ALCANCE
Este documento contiene una descripcin resumida de la Metodologa de Gestin de Proyectos,
PBSTRES, utilizada por Pampa Business Solutions SRL (en adelante PBS)
MARCO METODOLGICO
PBSTRES es el la Metodologa de Gestin de Proyectos creada por PBS como marco metodolgico a los
proyectos que administra.
PBSTRES est basada en un estndar mundialmente reconocido en la gestin de proyectos, Metodologa
de Project Management del PMI (Project Management Institute). En aspectos relacionados con el
desarrollo de Software PBSTRES toma como base el Modelo de calidad CMMI (Capability Maturity Model
Integration) del SEI (Software Engeenering Institute). Asimismo se encuentra alineada, en aspectos
relacionados con la gestin de la calidad, al Standard ISO 9001:2000.
PBS cuenta en su equipo con skills de Project Manager Professional (Credencial PMP del PMI), consultor
CMMI (Curso Oficial del SEI y Experiencia en implementacin del Modelo) y Auditor interno ISO 9001:2000
quienes trabajaron en la creacin este marco.
Pgina 4 de 19
INICIACIN
PLANEAMIENTO
EJECUCIN
CIERRE
Y una Etapa cross a todo el proyecto denominada MONITOREO Y CONTROL (En el grfico puede verse bajo
los puntos de Control que acompaan a las Fases del Proyecto)
Cada una de las Etapas contiene una o ms Fases del ciclo de Vida del Proyecto
1. ETAPA 0: INICIACIN
El objetivo de esta Etapa es dar por comienzo a un nuevo Proyecto Fase del mismo. Dentro
de esta etapa se incluye la elaboracin de la propuesta y su refinamiento hasta aprobacin para
dar inicio a la siguiente etapa de Planeamiento.
Esta Etapa puede iniciarse por un requerimiento de un cliente o bien por una iniciativa interna
para la incorporacin de un nuevo producto o servicio al portfolio de PBS. En esta instancia el
estudio de factibilidad del proyecto se supone ya ha sido superado.
FASE DE INICIO
Pgina 5 de 19
2. ETAPA 1: PLANEAMIENTO
En esta Etapa se refinan las tareas de definicin de alcance del proyecto y se elabora en
detalle el Plan General del Proyecto
FASE DE PLANIFICACIN DEL PROYECTO
3. ETAPA 2: EJECUCIN
En esta Etapa se pone en marcha el Plan de Proyecto de manera de obtener como resultado
el producto servicio dado.
A continuacin se enumeran las grandes tareas a realizar. De acuerdo al ciclo de vida de
Desarrollo utilizado pueden implementarse mediante distintas iteraciones o bien en cascada.
FASE DE DISEO Y DESARROLLO
FASE DE INTEGRACIN
Pgina 6 de 19
FASE DE IMPLEMENTACIN
5. ETAPA 3: CIERRE
Esta Etapa comprende la transicin que asegure la completa operatividad del producto
en el ambiente de produccin del cliente as como el cierre del Proyecto.
Pgina 7 de 19
* Dentro de la subestructura Soporte se incluyen Roles tales como Arquitecto Solucin, Administrador de la
Configuracin, etc. que prestan servicios a distintos proyectos. Esto es porque se considera ptima su
agrupacin en una subestructura especializada que concentre conocimientos especficos de Arquitectura,
Tecnologa, etc.
1. ROLES Y RESPONSABILIDADES
1.1. PROJECT MANAGER CLIENTE (O INTERLOCUTOR FORMAL)
Con el objetivo de facilitar y efectivizar la comunicacin y toma de decisiones PBS solicita que se
nombre una persona que oficie como Representante del Cliente a quien se denomina Project Manager
Cliente. Este rol es crucial en el xito del proyecto. Representa la mxima autoridad por parte del cliente
para el proyecto y su interrelacin directa es con el Project Manager PBS
Pgina 8 de 19
1.3. BOARD
El Board es un Comit formado por un representante por parte del cliente y un representante
PBS. Tpicamente lo componen los Project Manager de ambos lados. El Board podra estar
formalmente establecido o no. De todos modos es responsabilidad de ambos representantes el
trabajo en conjunto en aspectos relacionados con la toma de decisiones, priorizacin, aprobacin,
etc. de manera de obtener consenso de ambas partes:
Pgina 9 de 19
Identificar y comprender las necesidades del cliente de manera de obtener una especificacin de
requerimientos.
Realizar tareas de Anlisis y diseo de una solucin que satisfaga las expectativas del cliente.
Adicionalmente, supervisin de la programacin, documentacin, actualizacin y mantenimiento
de los sistemas informticos.
Conocer y aplicar la metodologa de desarrollo definida para el proyecto.
Generar la Especificacin del Sistema que sirva para codificar: Disear las entradas, salidas,
archivos y programas de cada sistema.
Generar la documentacin tcnica y de calidad.
Participar de las estimaciones de tiempo y esfuerzo as como en la evolucin de impacto ante un
cambio.
1.6. DESARROLLADOR
El desarrollador es responsable de:
Identificar los recursos requeridos por cada aplicacin 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 Validacin/Testing. Liberar las correctas
versiones de los componentes.
Asegurar la disponibilidad e integridad de los diferentes artefactos para ser incluidos en la Unidad
de despliegue cuando fuera necesario. Liberar a produccin las correctas versiones de los
componentes.
Pgina 10 de 19
ENTREGABLES
1. ENTREGABLES POR ETAPA
Pgina 11 de 19
3. DESCRIPCIN DE ENTREGABLES
PROPUESTA DE SERVICIO
Contiene una descripcin del alcance, solucin, presupuesto y condiciones de contratacin.
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 tiempo
asignado/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 variacin) o bien ser un presupuesto
final. Esto tambin depende de lo que el cliente solicite como propuesta, nivel de informacin disponible, etc.
En casos donde el cliente requiera algn tipo de formato especial o informacin particular (ejemplo: pliegos)
la misma puede adaptarse a dichas especificaciones.
Nomenclatura:
Pgina 12 de 19
ESPECIFICACIN DE REQUERIMIENTOS
Definicin inicial del Requerimiento de Software. Este documento rene la documentacin de los
requerimientos (funcionales y no funcionales) de software del proyecto. Asimismo sirve como base del
acuerdo comn entre todas las partes y formar el contenido de la lnea base. Incluye una descripcin
Global, definicin de tipo de usuarios, lista de actores, caractersticas de la solucin, ambiente de operacin,
supuestos y restricciones, requerimientos funcionales y no funcionales, interfaces necesarias y criterios de
aceptacin. Asimismo puede incluir una Visin General de la Arquitectura.
Este documento puede llegar a un nivel de detalle mayor incluyendo casos de uso en trminos de
negocio u otros diagramas o bien estas cuestiones ser incluidas directamente en los documentos de diseo.
Nomenclatura: [ERS_Cliente_Nombre
del Proyecto_PBS]
CRONOGRAMA
Contiene las actividades con su fecha de inicio y fin, duracin, secuenciamiento etc. El cronograma
tambin incluye los hitos del proyecto.
Nomenclatura: [SCH_Cliente_Nombre
Pgina 13 de 19
del Proyecto_PBS]
DISEO DETALLADO
Contiene una definicin de mayor detalle de los requerimientos. Segn la metodologa de desarrollo
que se aplique y caractersticas del proyecto es posible incluir diagramas tales como:
o Diagrama de Clases
o Diagrama de Objetos
o Diagrama de Actividades
o Diagrama de Casos de Uso y descripcin de los mismos
o Interfaces y diseos de pantalla
Este documento puede considerarse un refinamiento de la Especificacin de Requerimientos y/o
documentos de diseo de alto nivel o bien entregarse como documento aparte.
Nomenclatura:
VERSIN FINAL
Corresponde a la versin que recibe el cliente para sus pruebas de aceptacin.
Tipos
R: Versin Release
Nomenclatura:
Pgina 14 de 19
VERSIN PRODUCCIN
Versin productiva. Posiblemente tenga un nmero de release diferente a la versin de testing de
aceptacin debido a los ajustes finales que puedan surgir de estas pruebas.
Tipos
R: Versin Release
Nomenclatura:
MANUALES
Los manuales o documentacin de usuario final constituyen un entregable ms al cliente y resultan
clave en el aprendizaje del uso del sistema. Tpicamente se manejan los siguientes tipos de manual:
Manual de Usuario (Orientacin al usuario final. Enfoque desde la operacin del software)
Manual del Sistema (Orientacin tcnica)
Manual de Instalacin
En general el manual de Usuario y Sistema se presentan de manera unificada.
Nomenclatura: [MAN_Cliente_Nombre
INFORME DE AVANCE
La Etapa de Monitoreo y Control del Proyecto acompaa a todo el ciclo de vida del mismo. Como
producto del seguimiento de las distintas variables que intervienen en el proyecto se generan, segn
frecuencia predefinida, los Informes de Avance del proyecto. El objetivo es reflejar el status del proyecto,
detectar algn desvo e implementar, de manera temprana, acciones correctivas. Estos informes surgen de
las reuniones con el Equipo de trabajo, reuniones con el cliente y seguimiento de indicadores y son
distribuidos a las partes involucradas segn plan.
Nomenclatura:
Pgina 15 de 19
SOLICITUD DE CAMBIO
Este documento se genera con el objeto de documentar un Cambio solicitado. El mismo incluye una
descripcin del cambio solicitado, motivo del cambio, quin lo solicita, requerimiento al cul afecta, anlisis
de impacto del cambio y circuito de aprobaciones (Board, PBS, Cliente, etc.)
Nomenclatura: [SCA_Cliente_Nombre
DOCUMENTOS ACTUALIZADOS
Comprende la entrega al cliente de los documentos/entregables actualizados en su ltima versin
con todos los ajuste que pudieron haberse incorporado en las instancias previas al cierre.
Pgina 16 de 19
1. EL MODELO V
El modelo V considera al testing una actividad importante en lugar de pensarlo como una amenaza al
proyecto. Este modelo surge en reaccin a ciertos modelos cascada que muestran al testing como una fase
singular posterior al anlisis, diseo de alto nivel, diseo detallado y desarrollo.
El Modelo V representa varios niveles de testing e ilustra como cada nivel se encuentra alineado con una
etapa del ciclo de vida de desarrollo. La V muestra, del lado izquierdo, la tpica secuencia de actividades de
desarrollo 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 y
bajo niveles de diseo y finalmente se implementan en lneas de cdigo. Del lado de la ejecucin del testing,
se comienza con las pruebas unitarias, seguidas por las de integracin, sistema y aceptacin.
Este modelo es valioso porque destaca la existencia de varios niveles de testing y delinea cmo se
relaciona cada uno con diferentes fases del desarrollo.
Las pruebas unitarias focalizan en los tipos de fallas que ocurren mientras se escribe cdigo, tales como
los valores lmite en la validacin de la entrada de datos del usuario. Las pruebas unitarias son
tpicamente realizadas por el mismo desarrollador.
Las pruebas de integracin se focalizan en el diseo de bajo nivel, especialmente chequeando errores
entre interfaces y unidades u otras integraciones.
Las pruebas de sistema validan si, el sistema como un todo, implementa efectivamente el diseo de alto
nivel, incluyendo adecuada performance en un ambiente similar a produccin.
Las pruebas de Aceptacin son tpicamente realizadas por los usuarios (cliente) para confirmar que el
producto rene los requerimientos de negocio.
En cada etapa de desarrollo, tienden a ocurrir diferentes tipos de fallas, de este modo distintas tcnicas
se utilizan para identificarlas.
Pgina 17 de 19
Pgina 18 de 19
Testing Unitario
Testing de Integracin
Testing de Sistema
Cada Ciclo finaliza con una revisin formal de los resultados obtenidos y de los defectos
detectados con el Lder de cada Mdulo, Paquete o Subsistema.
F. REPORTE DE PRUEBAS
A medida que se ejecutan las Pruebas, los defectos, mejoras, etc detectados son reportados. Estos
son asignados al responsable de cada tema y se realiza un seguimiento de cada uno de los defectos,
mejoras, etc. hasta su cierre.
Pgina 19 de 19