UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

PROPUESTA DE METODOLOGA Y ESTNDARES PARA LA ADMINISTRACIN DE PROYECTOS EN LAS PEQUEAS Y MEDIANAS EMPRESAS DE SOFTWARE CON BASE EN LOS ESTANDARES DEL PMI

KAREN ROCO JIMENEZ MURILLO

PROYECTO FINAL DE GRADUACIN PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TTULO DE MSTER EN ADMINISTRACIN DE PROYECTOS

San Jos, Costa Rica Mayo, 2012

UNIVERSIDAD PARA LA COOPERACIN INTERNACIONAL (UCI) Este Proyecto Final de Graduacin fue aprobado por la Universidad como Requisito parcial para optar al grado de Mster en Administracin de Proyectos

__________________________ Se debe anotar el nombre ERIKA GTJENS SOTO

__________________________ EDGAR UGALDE SABORO LECTOR No.1

________________________ KAREN ROCO JIMENEZ MURILLO SUSTENTANTE

ii

DEDICATORIA

A mi familia y amigos, que creyeron en mis capacidades y me sostuvieron con su nimo, pues gracias a su estmulo, ideas, cario y paciencia logr terminar este proyecto.

iii

AGRADECIMIENTOS

Dios: creador de todo lo existente y gua de mi vida, que me da la oportunidad de seguir creciendo profesionalmente, me apoyaste para lograr este triunfo cuando me sent sin fuerza, sin nimo y voluntad de seguir adelante, poniendo a las personas indicadas en mi camino.

iv

INDICE HOJA DE APROBACION ii DEDICATORIA iii AGRADECIMIENTO iv INDICE v INDICE ILUSTRACIONES vii INDICE CUADROS viii RESUMEN EJECUTIVO ix 1 INTRODUCCIN ................................................................................................... 12 1.1 Antecedentes ................................................................................................ 12 1.2 Problemtica. ................................................................................................ 12 1.3 Justificacin del problema ............................................................................ 13 1.4 Objetivo general ........................................................................................... 17 1.5 Objetivos especficos. ................................................................................... 17 2 MARCO TERICO ................................................................................................ 18 2.1 Marco Referencial ........................................................................................ 18 2.2 Teora de la Temtica a Estudiar ................................................................... 21 2.2.1 Metodologa RUP ......................................................................................... 21 2.2.1.1 Ciclo de Vida del Software ....................................................................... 24 2.2.1.2 Disciplinas de Desarrollo .......................................................................... 25 2.2.2 Mejores Prcticas para El Desarrollo de Software ......................................... 28 2.2.3 Ciclo de Vida de Proyecto ............................................................................ 30 2.2.3.1 Fase Concepcin ....................................................................................... 30 2.2.3.2 Fase Elaboracin....................................................................................... 31 2.2.3.3 Fase Construccin ..................................................................................... 31 2.2.3.4 Fase Transferencia .................................................................................... 32 2.3 Teora de Administracin de Proyectos ......................................................... 33 2.3.1 Qu es un Proyecto?.................................................................................... 33 2.3.2 Qu es la Administracin de Proyectos? ...................................................... 34 2.3.3 Qu son los Grupos de Procesos de Administracin de Proyectos? .............. 35 3 MARCO METODOLGICO ................................................................................. 39 3.1 Fuentes de informacin ................................................................................. 39 3.2 Mtodos de Investigacin ............................................................................. 41 3.3 Herramientas. ............................................................................................... 42 3.3.1 Primer objetivo especfico: ........................................................................... 43 3.3.1.1 Tcnica descomposicin ........................................................................... 43 3.3.1.2 Juicio de Expertos ..................................................................................... 44 3.3.1.3 Herramientas............................................................................................. 44 3.3.1.4 Tcnica Documental o Bibliogrfica ......................................................... 44 3.3.2 Segundo objetivo especfico: ........................................................................ 45 3.3.2.1 Plantillas ................................................................................................... 45 3.3.2.2 Identificacin de involucrados .................................................................. 45 3.3.3 Tercer objetivo especfico: ............................................................................ 46 3.3.4 Cuarto objetivo especfico: ........................................................................... 46 3.3.4.1 Investigacin Aplicada .............................................................................. 47 v

3.4 Supuestos y Restricciones. ............................................................................ 47 3.5 Entregables. .................................................................................................. 49 DESARROLLO ...................................................................................................... 50 4.1 Justificacin del proyecto.............................................................................. 53 4.2 Primer Objetivo Especfico ........................................................................... 53 4.2.1 Concepcin ................................................................................................... 55 4.2.1.1 Modelado del Negocio .............................................................................. 57 4.2.1.2 Requisitos ................................................................................................. 59 4.2.1.3 Configuracin y administracin del cambio .............................................. 62 4.2.1.4 Gestin del proyecto ................................................................................. 64 4.2.1.5 Ambiente .................................................................................................. 72 4.2.2 Elaboracin .................................................................................................. 75 4.2.2.1 Anlisis / Diseo ....................................................................................... 77 4.2.2.2 Implementacin ........................................................................................ 80 4.2.3 Construccin................................................................................................. 82 4.2.3.1 Pruebas ..................................................................................................... 84 4.2.4 Transicin..................................................................................................... 86 4.2.4.1 Despliegue ................................................................................................ 87 4.3 Segundo Objetivo Especfico ........................................................................ 89 4.3.1 Administrador del Proyecto (PM) ................................................................. 89 4.3.2 Gerente de Oficina de Proyectos (PMO) ....................................................... 93 4.3.3 Vendedor ...................................................................................................... 94 4.3.4 Analista de Sistemas ..................................................................................... 95 4.3.5 Arquitecto..................................................................................................... 97 4.3.6 Coordinador de proyectos y mtricas ............................................................ 98 4.3.7 Lder de Diseo ............................................................................................ 99 4.3.8 Diseador ..................................................................................................... 99 4.3.9 Desarrollador ...............................................................................................100 4.3.10 Auditor Aseguramiento Calidad ...............................................................103 4.3.11 Comit arquitectura..................................................................................103 4.3.12 Coordinador de pruebas ...........................................................................103 4.3.13 Analista de Pruebas ..................................................................................104 4.3.14 Encargado del Despliegue ........................................................................105 4.3.15 Revisor de Requerimientos ......................................................................105 4.4 Tercer Objetivo Especfico ..........................................................................106 4.4.1 Repositorio de Carpetas para las Herramientas .............................................106 4.4.2 Herramientas Automatizadas para la Administracin de Proyectos ..............108 4.5 Cuarto Objetivo Especfico ..........................................................................110 4.5.1 Gua para la Gestin del Proyecto ................................................................110 4.5.1.1 Gua Gestin de la Oficina de Proyectos ..................................................111 4.5.1.2 Gua Inicio de la Gestin del Proyecto .....................................................113 4.5.1.3 Gua Planificacin de la Gestin del Proyecto ..........................................115 4.5.1.4 Gua Ejecucin de la Gestin del Proyecto ...............................................117 4.5.1.5 Gua Control de la Gestin del Proyecto...................................................119 4.5.1.6 Gua Cierre de la Gestin del Proyecto.....................................................121 4.5.2 Guas para el Desarrollo del Software ..........................................................123 4.5.2.1 Gua Requisitos del Desarrollo del Software ............................................123 vi

5 6 7 8

4.5.2.2 Gua Anlisis y Diseo del Desarrollo del Software .................................126 4.5.2.3 Gua Implementacin del Desarrollo del Software ...................................129 4.5.2.4 Gua Pruebas del Desarrollo del Software ................................................132 4.5.2.5 Despliegue del Desarrollo del Software....................................................134 CONCLUSIONES .................................................................................................136 RECOMENDACIONES ........................................................................................139 BIBLIOGRAFIA .....................................................................................................140 ANEXOS ................................................................................................................141 8.1 Anexo 1: ACTA DEL PROYECTO .............................................................141 8.2 Anexo 2: EDT .............................................................................................143 8.3 Anexo 3: CRONOGRAMA .........................................................................144 8.4 Anexo 4: Otros ............................................................................................147 8.4.1 Plantilla Modelo de Casos de Uso del Negocio ............................................148 8.4.2 Plantilla Glosario .........................................................................................152 8.4.3 Plantilla Visin ............................................................................................158 8.4.4 Plantilla Especificacin de Requerimientos de Software ..............................167 8.4.5 Plantilla de Anlisis Preliminar ....................................................................179 8.4.6 Plantilla Solicitud de Requerimientos...........................................................184 8.4.7 Plantilla Check List del Ambiente ................................................................188 8.4.8 Plantilla Plan de Especificacin del Ambiente .............................................195 8.4.9 Plantilla Plan del Desarrollo de Software .....................................................199 8.4.10 Plantilla Plan de Aseguramiento de la Calidad (SQA) ..............................219 8.4.11 Plantilla Plan de Administracin de Configuracin ..................................225 8.4.12 Plantilla Plan de Pruebas ..........................................................................232 8.4.13 Plantilla Lista de Riesgos .........................................................................266 8.4.14 Plantilla Minuta de la Reunin .................................................................273 8.4.15 Plantilla Asignacin de Roles ...................................................................275 8.4.16 Plantilla Plan de Despliegue del Proyecto ................................................282 8.4.17 Plantilla Lista de Revisin del Ciclo de Vida del Proyecto .......................288 8.4.18 Plantilla Documento Arquitectura del Software........................................291 8.4.19 Plantilla Solicitud de Cambio de Requerimientos .....................................299 8.4.20 Plantilla Acta de Inicio del Proyecto ........................................................300 8.4.21 Plantilla Estructura de Desglose del Trabajo ............................................303 8.4.22 Plantilla Cronograma del Proyecto ...........................................................304 8.4.23 Plantilla Prototipos de Interfaces de Usuario ............................................308 8.4.24 Plantilla Documento de Lecciones Aprendidas .........................................314 8.4.25 Plantilla Plan de Gestin de los Costos.....................................................319

vii

NDICE DE FIGURAS

Figura 1. Rational Unified Process [Adaptado de RUP- Rational IBM, 2002] .... 23 Figura 2. Las fases del RUP y sus Hitos (Hernndez, 2005) . 24 Figura 3. Proceso de Disciplinas de Desarrollo .. 26 Figura 4. Ciclo de Vida del Proyecto (RUP, 2002) . 30 Figura 5. Mapa de relacin entre RUP y PMBOK (2008) .. 51 Figura 6. Mapa de flujos y disciplinas del RUP .. 52 Figura 7. Flujo de entregables durante la Concepcin del Proyecto... 55 Figura 8. Disciplina de Modelado del Negocio (IBM, 2008)..... 58 Figura 9. Ejemplo de proceso de Requerimientos (IBM, 2008). 60 Figura 10. Proceso de Configuracin y Administracin del Cambio (IBM, 2008) 62 Figura 11. Procesos de Administracin de Proyectos (IBM, 2008)... 65 Figura 12. Esquema de Administracin del Ambiente (IBM, 2008).. 73 Figura 13. Flujo de entregables durante la Elaboracin del Proyecto75 Figura 14. Disciplina de Anlisis y Diseo (IBM, 2008)79 Figura 15 Ejemplo de proceso de implementacin (IBM, 2008)... 81 Figura 16. Flujo de entregables durante la Construccin del Proyecto 83 Figura 17. Ejemplo de proceso de Pruebas (IBM, 2008).. 85 Figura 18. Ejemplo de Proceso de Despliegue (IBM, 2008) 88 Figura 19. Fases de la Administracin de Proyectos. 111

viii

NDICE DE CUADROS Cuadro 1 Fuentes de Informacin Utilizadas .................................................................... 40 Cuadro 2 Herramientas Utilizadas .................................................................................... 42 Cuadro 3 Supuestos y Restricciones ................................................................................. 48 Cuadro 4 Entregables ....................................................................................................... 49 Cuadro 5 Caractersticas del PMBOK y RUP ..80

ix

RESUMEN EJECUTIVO El presente trabajo de investigacin no se desarrolla en una organizacin en particular dado que los lineamientos y recomendaciones resultantes sern de utilidad y aplicacin para pequeas y medianas empresas del rea de software. Las tecnologas de Informacin juegan un papel clave en esta evolucin y presentan nuevas herramientas e iniciativas de apoyo a la administracin de proyectos, las cuales deben adoptarse considerando las caractersticas y objetivos propios de la organizacin. Dado el creciente aumento de pequeas y medianas empresas de software que se constituyen y no cuentan con una oficina de proyectos y una metodologa que les ayude a desarrollar con orden y planificacin las diferentes etapas y procesos que involucra la direccin general de la empresa (planificacin, organizacin, seleccin de personal, ejecucin y control de las operaciones) y el ciclo de vida de los proyectos que administran, aunado con la influencia de nuevas tecnologas; surge la necesidad de implementar nuevas formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administracin de proyectos, sin dejar de lado la colaboracin a distancia, el outsourcing, la mejora de calidad, generacin y distribucin de conocimiento y coordinacin de varios proyectos, entre otras. El objetivo general de este proyecto de graduacin es definir una propuesta de Plantillas y Herramientas que se puedan aplicar como estndar para el ciclo de vida del desarrollo de software adaptable para pequeas y medianas empresas con base en el marco estndar del RUP (Rational Unified Process) y del PMI (Project Management Institute), para el mes de marzo del 2012. El primer objetivo especfico definido es el disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento. El segundo objetivo especfico es el identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin. El tercer objetivo especfico es definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de las organizaciones que implementen esta metodologa. x

El cuarto objetivo especifico es crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas. Para el desarrollo de este trabajo se utiliz un mtodo cientfico el cual involucra investigacin documental y un proceso analtico sinttico, con el cual se logra cumplir con los objetivos planteados. La metodologa de desarrollo de software, est ligada al Cuerpo de Conocimientos del PMI (PMBOK, 2008), pues este ltimo da los lineamientos para gestionar un proyecto, sea este cual fuere. EL RUP es una metodologa que apoya en la parte del desarrollo del ciclo de vida del software, es decir la parte aplicativa de la Ingeniera propiamente dicha. El PMBOK (2008) es gestin del proyecto. RUP (2002) es la metodologa del desarrollo del software. Ambos estn estrechamente amarrados, ya que el producto o servicio a desarrollar (software) requiere de una mejor prctica de desarrollo de su ciclo de vida y adems que este se haga eficientemente, para ello est la Gestin de Proyectos (PMI). En resumen, con esta propuesta metodolgica se busca brindar a pequeas y medianas empresas del rea de software una metodologa que sea una opcin aplicable para el desarrollo de sus operaciones y administracin de proyectos. El mayor beneficio de la implantacin de estas Plantillas y Herramientas es hacer las cosas ms fciles. Administrar proyectos de software es una tarea compleja, por medio de la adecuada utilizacin de la metodologa se puede crear una atmsfera positiva y de respaldo a los administradores de proyectos y lograr un entorno donde sea posible realizar proyectos con xito.

xi

12

INTRODUCCIN

1.1

Antecedentes

Esta investigacin va orientada para las pequeas y medianas empresas del rea de software basadas en proyectos. Dichas empresas son aquellas cuyas operaciones se componen principalmente de proyectos. Estas empresas son las que obtienen sus ingresos principalmente de la ejecucin de proyectos de software para otros en virtud de un contrato.

1.2

Problemtica.

En la ltima dcada se ha dado un creciente aumento de pequeas y medianas empresas de software que se constituyen y no cuentan con una oficina de proyectos y una metodologa que les ayude a desarrollar con orden y planificacin las diferentes etapas y procesos que involucra la direccin general de la empresa (planificacin, organizacin, seleccin de personal, ejecucin y control de las operaciones) y el ciclo de vida de los proyectos que administran, aunado con la influencia de nuevas tecnologas; surge la necesidad de implementar nuevas

formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administracin de proyectos, sin dejar de lado la colaboracin a distancia, el outsourcing, la mejora de calidad, generacin y distribucin de conocimiento y coordinacin de varios proyectos, entre otras. problemas que enfrentan dichas empresas se encuentran que: No existen formas ni estilos definidos para administrar los proyectos internos y externos. En otras palabras, no utilizan ningn tipo de metodologa. Los encargados y participantes de los proyectos no tienen claramente definidos sus roles y funciones formalmente y por escrito, se realizan por costumbre y segn la necesidad del momento. Los principales

13 Los proyectos no tienen una metodologa estndar para el control y seguimiento en cuanto a su alcance, costos, tiempo, comunicaciones y calidad Generalmente no existe plantillas adecuadas para llevar un control de cambios formal en el alcance, ni para la planificacin en el seguimiento de la calidad del producto del proyecto. La gestin del tiempo del proyecto se limita a un cronograma de trabajo inicial y posiblemente uno final, no utilizndose herramientas adecuadas de control de cambios del mismo. No hay plantillas ni herramientas para documentar las lecciones aprendidas. Generalmente no se trabaja enfocado en la rentabilidad del proyecto. Sin base objetiva para evaluar la calidad o para resolver problemas. Inexistencia o reduccin de las actividades de mejora de la calidad.

1.3

Justificacin del problema

En el siglo pasado innumerables reas de Tecnologa han tenido progresos considerables, pero una destaca sobre las dems no porque haya dejado de existir o por que se haya convertido en una innovacin radical, sino porque ha cambiado tanto que apenas es reconocible a la situacin en la que se encontraba hace 10 aos: la Administracin de Proyectos (Rapoza, 2005). An cuando el profesionalismo en la administracin de proyectos se ha desarrollado considerablemente, la necesidad de administrar un nmero cada vez ms grande de proyectos con caractersticas variables, que adems se encuentran en diferentes fases dentro de su ciclo de vida, presenta nuevos y difciles retos en las empresas (Dooley et al., 2005). Las tendencias de competencia global, cambios tecnolgicos y reingenieras cada vez ms rpidas incrementan la importancia de los procesos de administracin de proyectos, si se considera al administrador de proyectos y a su equipo como un agente de cambio, debido a la esencia temporal del proyecto.

14 Hablando del desarrollo de software es posible mencionar que los proyectos de software se encuentran pobremente administrados. Frecuentemente se retrasan o sobrepasan lo presupuestado inicialmente (se estima un factor del 50 al 100%), adems de que los clientes o usuarios de la misma manera se muestran insatisfechos con la calidad de los sistemas de software. Es por esto que no es de sorprender que las organizaciones de desarrollo de software busquen activamente nuevas maneras de mejorar su desempeo (Boyd, 2001; Mathiassen & Pourkomeylian, 2003). Ante estas deficiencias, algunos de los esfuerzos para mitigar fallas en los proyectos de desarrollo que las empresas generalmente tratan de implementar es la mejora de la Administracin de Proyectos mediante esquemas y metodologas que les ayuden a agilizar y obtener un mejor control y seguimiento de los proyectos y clientes que administran (Boyd, 2001). El desarrollo de software es un proceso de negocios estratgico que integra y automatiza otros procesos de negocio, siendo en la actualidad, una fuente de ventajas competitivas para las compaas. El proceso de desarrollo de software requiere, por un lado, un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin (anlisis de requerimientos), elaboracin (diseo), construccin (implementacin) y transicin (pruebas e implantacin). Para responder a las exigencias particulares de este modelo de servicios, las principales consultoras coinciden en que la adopcin de metodologas de desarrollo y la administracin de proyectos comprobadas es clave para garantizar el xito de los proyectos. Se utilizar la disciplina de Administracin de Proyectos (Project Management), difundida en la actualidad por el Project Management Institute (PMI), y segn el PMBOK, 2008 (Gua del Conjunto de Conocimientos de la Administracin de

15 Proyectos, difundida por dicho instituto), esta disciplina es la aplicacin de conocimientos, habilidades, herramientas y tcnicas en un amplio rango de actividades para cumplir con los requerimientos de un proyecto en particular. Asimismo, esta disciplina busca estandarizar el lenguaje y el mtodo de trabajo del equipo que ejecutar el proyecto, estableciendo los pasos a seguir y documentacin a utilizar en cada fase, de forma tal de no omitir acciones importantes, tomar todos los recaudos necesarios en los momentos propicios y tener todo el proyecto debidamente documentado permanentemente. Durante ms de 40 aos las tcnicas de desarrollo de software han ido evolucionando, en pro de mejorar la calidad de los productos obtenidos, y de disminuir el esfuerzo, los tiempos y los costos de los proyectos que las utilizan. As han surgido y se han documentado y puesto en prctica diversos paradigmas y metodologas, como lo es el Proceso Unificado de Desarrollo (RUP). El proceso de desarrollo RUP (Rational Unified Process) aplica varias de las mejores prcticas en el desarrollo moderno de software en una forma que se adapta a un amplio rango de proyectos y de organizaciones. Esta metodologa permite que todos los integrantes de un equipo de trabajo, conozcan y compartan el proceso de desarrollo, una base de conocimientos y los distintos modelos de cmo desarrollar el software. Provee un enfoque estructurado para realizar tareas y responsabilidades en una empresa de desarrollo. Su principal objetivo es asegurar la produccin de software de alta calidad, que cumpla las necesidades de sus usuarios finales, que sea realizado en las fechas acordadas y con el presupuesto disponible. La idea es adoptar en gran medida los conceptos de esta metodologa, adaptndola a las necesidades del ciclo de vida de los desarrollos, y as crear una carpeta de plantillas y herramientas adecuadas con el objetivo de lograr productos de software de calidad. Se espera que el mayor beneficio de la implantacin de la Carpeta de Plantillas y Herramientas sea hacer las cosas ms fciles. Administrar proyectos es una tarea

16 compleja, que por medio de la adecuada utilizacin de la metodologa se puede crear una atmsfera positiva y de respaldo a los administradores de proyectos de las empresas desarrolladoras, y lograr un entorno donde sea posible realizar proyectos con xito. Esta carpeta tiene como fin sembrar en las empresas de software el uso de las mejores prcticas para las fases de iniciacin, planificacin, ejecucin, control y cierre de los proyectos mediante la utilizacin de plantillas. Los gerentes de proyecto necesitan de una disciplina que los auxilie a tomar todas las medidas para atender responsablemente cada uno de los aspectos que hacen a un proyecto, sin dejar detalles librados al azar que puedan atentar contra el xito del proyecto. A raz de lo comentado anteriormente, el poseer plantillas de documentacin y herramientas estandarizadas para el uso general de los proyectos de la empresa basadas en la metodologa de direccin de proyectos y de las mejores prcticas y de las normas. Se logra: Tener un ordenamiento en la documentacin que debe ser utilizada en cada una de las etapas que involucra los proyectos internos y externos de la empresa. Confiabilidad en la informacin para la toma de decisiones dentro del proyecto o de la alta gerencia. Optimizacin de los niveles de comunicacin entre proyectos y racionalizacin del uso de recursos compartidos. Favorecer la adecuada administracin de la configuracin de los proyectos y contar con un repositorio central donde se administre el conocimiento generado en los diferentes proyectos. Establecer una terminologa estndar, que mejora la comunicacin tanto externa como interna.

17 1.4 Objetivo general

El objetivo general de este proyecto es definir una propuesta de Plantillas y Herramientas que se puedan aplicar como estndar para el ciclo de vida del desarrollo de software adaptable para pequeas y medianas empresas con base en el marco estndar del RUP (Rational Unified Process) y del PMI (Project Management Institute), para el mes de marzo del 2012, realizado como proyecto final de graduacin para ser presentado como requisito parcial para optar por el ttulo de Mster Administracin de Proyectos.

1.5

Objetivos especficos.

Los objetivos especficos de este proyecto son: Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento. Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin. Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, para que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa. Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas.

18

MARCO TERICO

2.1

Marco Referencial

El presente trabajo de investigacin no se desarrolla en una organizacin en particular dado que los lineamientos y recomendaciones resultantes sern de utilidad y aplicacin especficamente para pequeas y medianas empresas del rea de software. Este tipo de empresas estn buscando controlar mejor el ambiente de administracin de proyectos de software y relacionados, ya sean de utilizacin interna o para sus clientes. Entre las preocupaciones principales que las envuelve es que los proyectos sean terminados a tiempo, con el menor costo para la empresa para obtener mayor rentabilidad, pero llevando durante el proceso un control y seguimiento ordenado de las actividades desarrolladas y del personal involucrado. Existen diferentes metodologas de administracin de proyectos propuestas por diferentes organizaciones; metodologas formales como PMI (Project Management Institute), SEI (Software Engineering Institute), y metodologas giles como lo son RUP (Rational Unified Process) y MSF (Microsoft Solutions Framework), entre otras que ofrecen herramientas de planificacin, anlisis y control de proyectos, necesarios para una buena administracin. Estos mtodos son indispensables en las organizaciones, ya que para conseguir un proyecto fructfero se debe comprender el mbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las actividades a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir. La gestin formal de proyectos se asienta sobre la administracin del proyecto y sobre un plan general con claridad y mbito de certidumbre hasta el final del proyecto, aunque siempre persista algn grado de incertidumbre.

19 La gestin formal hace hincapi en la necesidad de conocer con el mayor detalle los requerimientos desde el principio para dar rigor al plan del proyecto. Las

principales referencias de la gestin formal de administracin de proyectos son las asociaciones: PMI (Project Management Institute), IPMA (International Project Management Association) y la metodologa PRINCE2 (Projects in Controlled Environments). PMI e IPMA son organizaciones que han ido desarrollando

estndares, mtodos y modelos de certificacin profesional. Sin considerar el tamao del proyecto, su alcance o duracin existen 5 mximas de satisfaccin en su desarrollo (Boyd, 2001): 1. Entregar el producto que el cliente desea o necesita. 2. Entregar la calidad de manera acorde con el precio. 3. Entregar el producto en el espacio de tiempo que el cliente desea o necesita. 4. Entregar el nivel de retroalimentacin que el cliente desea. 5. Contar con un sistema de resolucin de conflictos justo para el cliente y el equipo de desarrollo. Los que se consideran como pasos bsicos esenciales para lograr una administracin eficiente de proyectos se enumeran a continuacin (Toledo, 2002): 1. Nunca iniciar sin un objetivo bien definido. 2. Fragmentar el proyecto. 3. Invertir tiempo en la planeacin. 4. Involucrar al equipo de trabajo en la planeacin y el control. 5. Fomentar la cohesin del equipo de trabajo. 6. Prevenir problemas. 7. Antes de ejecutar, establecer lneas de Base. 8. Mantener claro el objetivo principal del proyecto. 9. Establecer un proceso para monitorear y controlar. 10. Atender los puntos crticos primordialmente. 11. Tomarse el tiempo necesario para cerrar el proyecto. 12. Utilizar una metodologa para todos los proyectos.

20 Por otro lado los aspectos crticos que contribuyen al fracaso de proyectos de software incluyen: Falta de visin clara y establecimiento adecuado de requerimientos. Expectativas irreales. Falta de descomposicin del proyecto. Polticas inadecuadas de seleccin de personal y conflictos en el equipo de desarrollo. Falta de involucramiento y enfoque hacia el cliente. Falta de enfoque estratgico y apoyo administrativo.

Tanto los pasos bsicos para realizar una administracin proyecto como los aspectos crticos que provocan fracasos en este proceso de desarrollo deben de ser contemplados y corregidos, de acuerdo a la forma de trabajar de la empresa. De esta manera se busca mejorar el proceso de desarrollo de los proyectos de software y tomar en cuenta aquellas fallas comunes.

21 2.2 Teora de la Temtica a Estudiar

2.2.1 Metodologa RUP Segn IBM Rational Unified Process for System RUP (2002) es la metodologa estndar de la industria para la construccin completa del ciclo de ingeniera de software, tanto para sistemas tradicionales como para sistemas web, llamada as por sus siglas en ingls Rational Unified Process. Es un proceso de ingeniera de software, bien definido y estructurado; a la vez que es un producto que provee un marco de proceso adaptable a las necesidades y caractersticas de cada proyecto especfico. Esta metodologa le permite mayor productividad en equipo y la realizacin de mejores prcticas de software a travs de plantillas y herramientas que lo guan en todas las actividades de desarrollo crtico del software. El proceso de desarrollo de software requiere, por un lado, un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software. Segn Booch et al.(2002), creadores de este proceso unificado de desarrollo de software, su definicin viene dada por tres caractersticas fundamentales: Esta dirigido por casos de uso. Es un proceso centrado en la arquitectura. Es iterativo e incremental

Que el RUP (2002) est dirigido por casos de uso significa que el proceso de desarrollo sigue una trayectoria que avanza a travs de los flujos de trabajo generados por los casos de uso. Los casos de uso se especifican y disean en el principio de cada iteracin, y son la fuente a partir de la cual los encargados de las pruebas construyen sus casos de prueba. Los casos de uso describen la

funcionalidad total del sistema, pensada en trminos de la importancia de la misma para el usuario (no slo de la funcionalidad en s).

22 Pero esto no significa que se desarrollen aisladamente respecto de la arquitectura, sino que se desarrollan a la vez, madurando ambos segn avanza el ciclo de desarrollo. Lo casos de uso guan la arquitectura del sistema (como parte del proceso) y sta influye en la seleccin de los casos de uso. La arquitectura

involucra los elementos ms significativos y est influenciada entre otros por las plataformas de software, los sistemas operativos, los sistemas de gestin de base de datos, adems de otros como sistemas heredados y requerimientos no funcionales. Por esta razn eso dice que el RUP est centrado en la arquitectura, lo que invoca ms la relacin con los principios de la usabilidad. Segn lo que establece el RUP (De Carlo et al., 2004) los elementos del RUP son: Actividades, son los procesos que se llegan a determinar en cada iteracin. En concreto es una unidad de trabajo que una persona que desempee un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en trminos de crear o actualizar algn producto. Roles, definen el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempear diversos roles, as como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueo de un conjunto de artefactos. Artefactos, son un producto, es un trozo de informacin que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final. Un artefacto puede ser cualquiera de los siguientes (RUP, 2002): un documento, un modelo, y un elemento del modelo. El RUP (2002) divide los proyectos en pequeos ciclos o iteraciones a travs de cada una de las fases por las que pasa el proyecto, las cuales son establecidas claramente, cada una desarrollada en una o ms iteraciones que ejecutan actividades definidas para cada flujo de trabajo de los conocidos en cualquier proceso de desarrollo. Concretamente el RUP divide el proceso en cuatro fases,

23 como se muestra en la Figura 1, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y las cuales se definen de acuerdo al nivel de madurez que alcanzan los productos que se van obteniendo en cada actividad ejecutada. La terminacin de cada fase ocurre en el hito correspondiente a cada una, donde se evala que se hayan cumplido los objetivos de la fase en cuestin. Y desde la terminacin de la fase de inicio se puede ya determinar la factibilidad tanto operativa como econmica del proyecto, la cual nos lleva a tomar la decisin de continuarlo o no realizarlo.

Figura 1. Rational Unified Process Fuente: [Adaptado de RUP- Rational IBM, 2002]

El proceso del desarrollo del software segn RUP puede ser descripto en dos dimensiones: El eje horizontal representa el tiempo y muestra los aspectos dinmicos del proceso siendo expresados en trminos de ciclos, fases, iteraciones e hitos El eje vertical representa los aspectos estticos del proceso, cmo se describe en trminos de actividades, artefactos, empleados y flujos de trabajo Es recomendable que a cada una de estas iteraciones se les clasifique y ordene segn su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentacin que se tendra en cada entregable o en cada iteracin. (De Carlo et al., 2004)

24 Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un grado de certificacin en el desarrollo del software.

2.2.1.1 Ciclo de Vida del Software El ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final, tal como se muestra en la Figura 2.

Figura 2. Las fases del RUP y sus Hitos (Hernndez, 2005)

El RUP divide en cuatro fases el desarrollo del software: Concepcin (o inicio), el objetivo es determinar la visin del proyecto. Elaboracin, el objetivo es determinar la arquitectura ptima. Construccin, el objetivo es llevar a obtener la capacidad operacional inicial. Transicin, el objetivo es llegar a obtener las mejoras del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones o flujos de trabajo, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes. (De Carlo et al., 2004) El ciclo de vida que se desarrolla por cada iteracin, es llevado bajo dos disciplinas: desarrollo y soporte.

25

Disciplina de Desarrollo (De Carlo et al., 2004) Modelado del Negocio: Entendiendo las necesidades del negocio. Anlisis de Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software. Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo el solicitado est presente. Distribucin/Instalacin (Despliegue: Hacer todo lo necesario para la salida del proyecto

Disciplina de Soporte (De Carlo et al., 2004) Administracin de la Configuracin y Cambios: Guardando todas las versiones del proyecto. Administracin del Proyecto: toda la gestin del proyecto y recursos. Ambiente: Administrando el ambiente de desarrollo.

2.2.1.2 Disciplinas de Desarrollo Las disciplinas de desarrollo RUP representan ms de cerca los roles individuales de sus miembros o subgrupos dentro del equipo de desarrollo integral del proyecto. Estas disciplinas son las siguientes, tal como se muestra en la Figura 3 y se detallan a continuacin:

26

Figura 3. Proceso de Disciplinas de Desarrollo

2.2.1.2.1 Modelar el Proceso de Negocio Uno de los principales problemas en el desarrollo de software reside en los problemas de comunicacin entre la comunidad de ingeniera de software y la comunidad de ingeniera de negocios. (De Carlo et al., 2004) Esto genera que la salida de las reas de negocio no sean interpretadas correctamente por las reas de desarrollo de software y vice-versa. RUP resuelve estas diferencias proponiendo un lenguaje y un proceso comn para ambas comunidades, as como herramientas que permiten crear y mantener la equivalencia entre modelos de negocio y modelos de software. En el modelado de negocios se documentan los procesos de negocio utilizando los llamados casos de negocio. Esto asegura el entendimiento comn entre todos los "involucrados" sobre qu procesos de negocio necesitan ser soportados en la organizacin. Los casos de negocio son analizados para comprender cmo el software debera soportar los procesos de negocio. Esto es documentado en un

27 modelo de objetos de negocio. Es posible que algunos proyectos decidan no encarar el modelado de negocios.

2.2.1.2.2 Analizar Requerimientos El objetivo de esta actividad es describir qu debera hacer el sistema y permitir que los desarrolladores y el cliente se pongan de acuerdo en esa descripcin. Para lograrlo obtenemos, organizamos y documentamos la funcionalidad requerida y sus restricciones, se rastrean y se documentan decisiones. (De Carlo et al., 2004). Se crea el documento con la Visin y se obtienen las necesidades de los "involucrados" (partes interesadas).

2.2.1.2.3 Analizar Y Disear El objetivo del Anlisis y Diseo es definir la arquitectura del sistema proveyendo bases slidas para el proceso de diseo e implementacin. (De Carlo et al., 2004) Ejecute - en un entorno de implementacin especfico - las tareas y funciones definidas en las descripciones de los casos de uso Complete todos los requerimientos Sea estructurado de manera robusta (fcil de modificar si los requerimientos funcionales cambian)

2.2.1.2.4 Probar e Implementar El propsito de la implementacin es el desarrollo del sistema, en el cual se deben obtener finalmente las herramientas necesarias para resolver los requerimientos definidos en las etapas previas (De Carlo et al., 2004). Los objetivos a cumplir en esta etapa: Definir la organizacin del cdigo, en trminos de subsistemas organizados en capas

28 Implementar clases y objetos en trminos de componentes (archivos fuente, binarios, ejecutables y otros) Probar los componentes desarrollados como unidades. Integrar los resultados producidos por los desarrolladores individuales en un sistema ejecutable Probar los componentes desarrollados como unidades. Integrar los resultados producidos por los desarrolladores individuales en un sistema ejecutable El sistema se desarrolla a travs de la implementacin de componentes. RUP describe cmo reutilizar los componentes existentes o implementar definidas, alcanzando un

nuevos componentes con responsabilidades bien

sistema fcil de mantener e incrementando las posibilidades de reutilizacin.

2.2.1.2.5 Soporte y Monitoreo Las organizaciones exitosas no slo automatizan sus procesos de negocio, sino que tambin controlan su ejecucin y la ajustan dinmicamente en respuesta a los resultados en tiempo real. (De Carlo et al., 2004)

2.2.2 Mejores Prcticas para El Desarrollo de Software RUP, que incluye una serie de herramientas y la definicin de mejores prcticas para el desarrollo de software, fue adquirida por IBM y avalada como un estndar en el mbito internacional. RUP es un Proceso de Ingeniera de Software que ofrece una metodologa disciplinada para la asignacin de tareas y responsabilidades en una organizacin de desarrollo de software.

29 Su objetivo es asegurar la produccin de software de alta calidad que logre responder a las necesidades de sus usuarios finales en un cronograma y presupuesto predecibles. RUP describe la manera de implementar efectivamente "mejores prcticas" comercialmente probadas para el desarrollo de software. RUP ofrece a cada miembro del equipo las guas, plantillas y herramientas necesarias para aprovechar al mximo las siguientes mejores prcticas: 1. Desarrolle software iterativamente: RUP sugiere el desarrollo iterativo que aborda los riesgos ms altos en cada paso del ciclo de vida, reduciendo en forma significativa los riesgos del proyecto. 2. Administre requerimientos: RUP describe como obtener, organizar y

documentar la funcionalidad requerida y sus restricciones; rastrear y documentar especificaciones y decisiones, capturar y comunicar fcilmente requerimientos de negocio. 3. Utilice arquitecturas basadas en componentes: RUP soporta el desarrollo de software basado en componentes, mdulos o subsistemas que cumplen una funcin clara. (De Carlo et al., 2004) 4. Modele el software visualmente: La base para el modelado visual es el Unified Modeling Language (UML), creado por Rational software y que se ha convertido en un estndar del mercado. (De Carlo et al., 2004) 5. Verifique la calidad del software: RUP describe como obtener, organizar y documentar la funcionalidad requerida y sus restricciones; rastrear y documentar especificaciones y decisiones, capturar y comunicar fcilmente requerimientos de negocio. 6. Controle los cambios al software: El proceso describe cmo controlar, seguir y monitorear cambios para permitir el desarrollo iterativo.

30 2.2.3 Ciclo de Vida de Proyecto El ciclo de vida RUP es iterativo, y su dimensin de ciclo de vida se divide en cuatro fases, tal como se muestra en la Figura 4:

Figura 4. Ciclo de Vida del Proyecto (RUP, 2002)

2.2.3.1 Fase Concepcin Es la primera fase del sistema y consiste en adquirir los requerimientos por parte de los distintos usuarios y consolidar una visin nica de los objetivos y alcances del sistema. Durante esta fase se establece el caso de negocios del sistema y se delimita el alcance del proyecto. Para ello se identifican todas las entidades

externas con las cuales interacta el sistema (actores) y se define la naturaleza de esta interaccin a alto nivel. Esto involucra la identificacin de todos los

casos de uso y la descripcin de los ms significativos. El caso de negocios incluye el criterio de aceptacin, la evaluacin de riesgos, una estimacin de los recursos necesarios y un plan de fases mostrando fechas de los principales hitos del proyecto. (De Carlo et al., 2004)

31 2.2.3.2 Fase Elaboracin El propsito de esta fase es analizar el mbito del problema, establecer la base de la arquitectura, desarrollar el plan de proyecto y eliminar los

elementos de mayor riesgo del proyecto. (De Carlo et al., 2004) Para lograr estos objetivos se debe tener una visin completa del sistema. Las decisiones de arquitectura deben ser tomadas con un entendimiento completo del sistema: su alcance, funcionalidades principales y requerimientos no funcionales como ser requerimientos de ejecucin. Al finalizar esta fase en forma exitosa, se asegura que la arquitectura, requerimientos y planes son lo suficientemente estables y que los riesgos han sido mitigados a fin de que sea posible predecir el costo y cronograma del desarrollo completo. Durante esta fase se construye un prototipo de la arquitectura ejecutable en una o ms iteraciones dependiendo del alcance, tamao, riesgo y lo novedoso del proyecto. Este esfuerzo debera dar respuesta a los casos de uso crtico planteando en la fase Concepcin que exponen los mayores riesgos tcnicos del proyecto.

2.2.3.3 Fase Construccin El propsito de la implementacin es el desarrollo del sistema, en el cual se deben obtener finalmente las herramientas necesarias para resolver los requerimientos definidos en las etapas previas. (De Carlo et al., 2004) Durante esta fase se construyen todos los componentes y funcionalidades de la aplicacin restantes y son integrados al producto. Asimismo toda la funcionalidad es probada. La fase construccin es, fundamentalmente, un

proceso de manufactura donde el nfasis est puesto en administrar recursos y controlar las operaciones para optimizar costos, cronogramas y calidad. Se vive

32 una transicin conceptual que va del desarrollo de propiedad intelectual durante las dos primeras fases, al desarrollo de productos implementables durante las dos ltimas fases.

2.2.3.4 Fase Transferencia El propsito de esta fase es lograr la transicin del producto de software a la comunidad de usuarios. Una vez que el producto ha sido entregado al usuario final, surgen temas que requieren del desarrollo de nuevas versiones, corregir algunos problemas, o finalizar las funcionalidades que fueron pospuestas. (De Carlo et al., 2004) Se ingresa a esta fase cuando el producto est lo suficientemente maduro para ser implementado en el entorno del usuario final. Tpicamente requiere que un subconjunto utilizable del sistema haya sido completo a un nivel de calidad aceptable y que la documentacin de usuario est disponible a fin de que la transicin al usuario final de resultados positivos. Adems otro propsito de esta fase es producir versiones finales del producto y es el momento en que el sistema debe ser entregado a sus usuarios finales. Esta fase puede contar con varias iteraciones pero involucra al usuario final y al equipo o empresa de desarrollo. Al finalizar esta etapa el sistema debe quedar en manos de los usuarios, para esto se debe lograr la confianza en el nuevo sistema.

33 2.3 Teora de Administracin de Proyectos

2.3.1 Qu es un Proyecto? Segn el PMI (PMBOK, 2008): un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado nico. Segn Gido y Clements (2003): un proyecto es un esfuerzo por lograr un objetivo especfico mediante un serie especial de actividades interrelacionadas y la utilizacin eficiente de los recursos. Segn Chamoun (2002): un proyecto es un conjunto de esfuerzos temporales, dirigidos a generar un producto o servicio nico. De las definiciones anteriores se rescatan las siguientes caractersticas de lo que realmente define a un proyecto: Es temporal, significa que tiene un comienzo y un final definido. As el final del proyecto se alcanza cuando se han cumplido con los objetivos establecidos, cuando queda claro que estos no sern realizados, cuando la necesidad que dio origen al proyecto deja de existir o cuando ste sea cancelado (PMBOK, 2008). Tiene un objetivo bien definido que se espera de l, determinados a partir de un alcance, planificacin y presupuesto. Se lleva a cabo con actividades

interdependientes que utilizan una serie de recursos (humanos, materiales, econmicos. Los proyectos siempre tienen un cliente, quien es el que asigna o determina los recursos, adems los proyectos siempre tendrn un grado de incertidumbre. Crean un producto, un servicio o un resultado nico, algo que no ha sido hecho antes, an cuando la categora a la que pertenezca el proyecto sea amplia. Es decir, que cada proyecto posee caractersticas y funciones especficas y en donde las circunstancias en las cuales se lleva a cabo varan (Chamoun, 2002). Aunque existan elementos que se repitan con otros proyectos, no

34 quiere decir que ste no sea nico, ya que siempre hay elementos que son diferentes con respecto a los otros proyectos. Lleva a cabo una serie de actividades interdependientes, no repetitivas para lograr el objetivo, que son elaboradas progresivamente. Lo cual significa desarrollar en pasos e ir aumentando mediante incrementos. Para lograr esto es de suma importancia controlar adecuadamente la definicin del alcance del proyecto y los cambios que puedan originarse durante la ejecucin del mismo (PMBOK, 2008). Los proyectos son una forma de organizar actividades que no pueden ser tratada dentro de los lmites operativos normales de la organizacin. Se usan a menudo como un medio para lograr el plan estratgico de la organizacin y son autorizados ya sea por una demanda del mercado, una necesidad de la organizacin, una solicitud de un cliente, un avance tecnolgico o un requisito legal (PMBOK, 2008).

2.3.2 Qu es la Administracin de Proyectos? Segn PMI (PMBOK, 2008): La direccin de proyectos es la aplicacin de conocimientos, habilidades, herramientas, tcnicas a las actividades de un proyecto para cumplir con los requisitos del mismo. Segn Dixon (2000): La administracin de proyectos es la disciplina de gestionar proyectos exitosamente, la cual puede y debe aplicarse durante el ciclo de vida de cualquier proyecto Segn Rodrguez (2002): La administracin de proyectos es la forma de planear, organizar, dirigir y controlar una serie de actividades realizadas por un grupo de personas que tienen un objetivo especfico; el cual puede ser (crear, disear, elaborar, mejorar, analizar entre otros) un problema o cosa. La administracin de proyectos consiste en aplicar e integrar los grupos de procesos de direccin de proyectos de inicio, planificacin, ejecucin, seguimiento

35 y control, y cierre (ciclo de vida del proyecto). El director de proyecto es el

responsable de lograr los objetivos del proyecto. La administracin de proyectos incluye: Identificacin de los requisitos. Identificacin de objetivos claros y posibles de alcanzar. Lograr el equilibrio entre la calidad, el alcance, el tiempo y los costos. Lograr la adaptacin entre las especificaciones, los planes, y el enfoque de acuerdo a las inquietudes y expectativas de las diferentes clases de interesados. En una organizacin pueden realizarse uno o varios proyectos a la vez, en los cuales se deben cumplir una serie de requerimientos establecidos para su ejecucin. Los beneficios obtenidos mediante la aplicacin de la administracin de proyectos son numerosos para la organizacin y para las personas involucradas, ya que generan una mayor confianza en el resultado a obtener, menos tensin en el equipo de trabajo, mayores tasas de productividad, menos desperdicio de recursos valiosos, llevando a un menor costo el gasto del proyecto.

2.3.3 Qu son los Grupos de Procesos de Administracin de Proyectos? Un proceso se define como el conjunto de acciones y actividades

interrelacionadas que se llevan a cabo para alcanzar un conjunto previamente especificado de productos, resultados o servicios. Existen dos categoras de

procesos: los que estn orientados al producto y los que tienen que ver con la administracin del proyecto. Los procesos orientados al producto especifican y

crean el producto del proyecto, mientras que los de la administracin de proyectos describen, organizan y completan el trabajo del proyecto (PMBOK, 2008). Un grupo de procesos incluye los procesos constitutivos de la direccin de proyectos que estn vinculados por las entradas y salidas respectivas; de este

36 modo el resultado de un proceso se convierte en la entrada de otro. Basndose en esta definicin el PMBOK (2008) establece cinco grupos de procesos: 1. Iniciacin: este grupo de procesos se refiere a la autorizacin inicial del proyecto o de alguna de las fases del mismo, establecer la visin de qu, del proyecto. 2. Planificacin: este grupo de procesos conciernen a la definicin del plan de accin, el refinamiento de los objetivos y la seleccin de la estrategia para lograr los objetivos del proyecto definiendo as el cmo del proyecto. 3. Ejecucin: este grupo de procesos implica la coordinacin de los involucrados en el proyecto y otros recursos necesarios para llevar a cabo el plan del proyecto. 4. Seguimiento y Control: grupo de procesos que aseguran el cumplimiento de los objetivos del proyecto a travs de la supervisin y la medicin continua del avance, la identificacin de las variantes con respecto al plan original y la toma de acciones correctivas y preventivas de forma oportuna. 5. Cierre: grupo de procesos de aceptacin formal del proyecto o una de sus fases y termina ordenadamente el proyecto o una de sus fases.

El conjunto de los 5 grupos de procesos es lo que se conoce como el ciclo de vida del proyecto (PMBOK, 2008), siendo cada uno una fase, al dividir un proyecto en fases se facilita la gestin del mismo. La transicin de una fase a otra se hace mediante el establecimiento de puntos de control que sirven para verificar que los objetivos de una fase particular han sido alcanzados. Las fases son

secuenciales. El nivel de coste y de personal es bajo al comienzo, alcanza su mximo nivel en las fases intermedias y cae rpidamente cuando se aproxima su conclusin. El nivel de incertidumbre es ms elevado al inicio. La certeza de terminar con xito aumenta gradualmente a medida que avanza el proyecto o la

37 etapa del mismo. El poder que tienen los interesados para influir en el resultado y coste del proyecto es ms alto al comienzo y decrece mediante va avanzando el proyecto. Debido a la complejidad que representa la administracin de proyectos de forma eficiente y profesional, el PMBOK (2008) ha establecido 9 reas de conocimiento conformadas por 44 procesos, que contienen los conocimientos y las mejores prcticas generalmente aceptadas, donde cada rea es descrita en funcin de los procesos que la componen, las cuales se aplican en forma iterativa con los grupos de procesos de la administracin de proyectos. Las 9 reas de conocimiento son: 1. Alcance: corresponde a la definicin de lo que se incluye y lo que no se incluye en el proyecto. 2. Tiempo: procesos necesarios para asegurar que el proyecto se termine en el tiempo establecido. 3. Costo: procesos requeridos para que el proyecto se complete dentro del presupuesto aprobado. 4. Calidad: actividades a que la determinan de las polticas, que el objetivos y

responsabilidades

calidad,

modo

proyecto

cubra

satisfactoriamente las necesidades por las cuales se emprendi. 5. Recursos Humanos: procesos que organizan y dirigen el equipo del proyecto a quienes se les asignan roles y responsabilidades para concluir el proyecto. 6. Comunicacin: procesos para asegurar la generacin, recoleccin,

distribucin, almacenamiento, recuperacin y destino final de la informacin del proyecto en tiempo y forma. 7. Riesgos: procesos relacionados con la planificacin de la gestin de riesgos, la identificacin y el anlisis de riesgos, las respuestas a los riesgos, y el seguimiento y control a los riesgos de un proyecto.

38 8. Adquisiciones: procesos para comprar o adquirir los productos o servicios o resultados necesarios fuera del equipo del proyecto para realizar el trabajo. 9. Integracin: procesos y actividades necesarias para identificar, definir, combinar, unificar y coordinar los distintos procesos y actividades de administracin de proyectos dentro de los grupos de procesos de administracin de proyectos.

Es importante resaltar que los procesos incluidos en las reas de conocimiento de la administracin de proyectos son repetitivos debido a la existencia o a la necesidad de elaborar gradualmente el proyecto durante el ciclo de vida del mismo. Conforme el director conoce ms en profundidad el proyecto, puede

dirigirlo con mayor nivel de detalle (PMBOK, 2008).

39

3 3.1

MARCO METODOLGICO

Fuentes de informacin

La metodologa propuesta ser desarrollada utilizando como base la metodologa formal de administracin de proyectos desarrollada por el PMBOK (2008) y la metodologa gil de ingeniera de software RUP (Rational Unified Process). El presente proyecto se desarrollar un tipo de investigacin documental, donde se apoya la recopilacin de antecedentes mediante documentos que fundamentan y complementan la informacin. Para ello se utilizaran fuentes de carcter

secundario, mediante la revisin de material bibliogrfico referente al tema en cuestin, tales como libros, artculos, revistas, publicaciones, entre otros. actividades a realizar como parte de la investigacin documental son: Abordar el tema (relacionado con las metodologas indicadas). Buscar fuentes de informacin por medio de una sistemtica y amplia consulta bibliogrfica. Recolectar documentos. Se archivaran para que puedan ser utilizados cuando se conveniente. Recopilar la informacin. Tratar la informacin. Documentar las fuentes utilizadas. Las

El presente trabajo mostrar los resultados obtenidos a travs de la sntesis, anlisis e interpretacin del material obtenido a partir de una bsqueda intensa.

40 Fuentes Primeras Las fuentes primarias son toda aquella informacin oral o escrita que es recopilada directamente por el investigador a travs de relatos escritos o transmitidos por los participantes en un suceso o acontecimiento. (Mndez, 1995). Con el fin de obtener la informacin se aplicara la herramienta de Juicio de Expertos, por lo que se utilizara el mtodo de la Entrevista y la Observacin. Fuentes Secundarias Las fuentes secundarias estn constituidas por informacin escrita que ha sido recopilada y transcrita por personas que han recibido tal informacin a travs de otras fuentes escritas o por un participante en un suceso o acontecimiento. (Mndez, 1995). El resumen de las fuentes de informacin que se utilizaran en este proyecto se presenta en el Cuadro 1:
Cuadro 1 Fuentes de Informacin Utilizadas

Objetivos Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento. Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin. Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa.

Fuentes de informacin Primarias Secundarias

Entrevista Observacin

Investigacin mixta

41
Objetivos Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas. Fuentes de informacin

3.2

Mtodos de Investigacin

Para lograr los objetivos de este PFG, se utilizara un proceso cientfico que contempla el mtodo de investigacin analtico-sinttico.

Donde la investigacin documental ser la principal fuente de informacin para el desarrollo de este proyecto. Como se ha indicado, el PMI (PMBOK, 2008) y el RUP (2002), son la base principal para la elaboracin. Aunado a la informacin suministrada por profesionales en el tema (juicio de expertos) y complementada por la aplicacin de herramientas de software para el desarrollo (Hojas de Excel, Microsoft Project).

Otras fuentes consultadas para el desarrollo del proyecto sern libros, manuales de desarrollo y pginas en internet de empresas dedicadas al tema.

La investigacin ser basada en el mtodo analtico sinttico. De acuerdo con lo sealado por Mndez (1995), anlisis y sntesis son procesos que permiten al investigador conocer el entorno. Donde el anlisis inicia su proceso de

conocimiento por la identificacin de cada una de las partes que caracterizan el problema: de este modo podr establecer las relaciones causa-efecto entre los elementos que componen su objeto de investigacin. La sntesis implica que a partir de la interrelacin de los elementos que identifican su objeto, cada uno de ellos pueda relacionarse con el conjunto en la funcin que desempean con referencia al problema de investigacin.

42 En consecuencia, anlisis y sntesis son dos procesos que se complementan en uno en el cual al anlisis debe seguir la sntesis. En conclusin, el anlisis descompone el todo en sus partes y las identifica, mientras que la sntesis

relaciona los elementos componentes del problema y crea explicaciones a partir de su estudio.

3.3

Herramientas.

El cuadro 3 presenta las herramientas que se utilizaran para cada uno de los objetivos especficos:
Cuadro 2 Herramientas Utilizadas
Objetivos Herramientas

Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento. Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin. Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa. Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas.

Tcnica descomposicin Juicio de Expertos Herramientas Tcnica Documental o Bibliogrfica

- Plantillas - Identificacin de involucrados

- Establecimiento de la secuencia de actividades para la definicin de la estructura que debe llevar el repositorio donde se almacenaran las herramientas. - Investigacin aplicada, se utilizaran los conocimientos producidos en la investigacin para hacer, actuar y construir.

43 3.3.1 Primer objetivo especfico: Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos,

comunicaciones, riesgo y abastecimiento.

Para disear la metodologa de plantillas planteada, se utilizarn algunas de las herramientas y tcnicas sugeridas por el PMBOK (2008), las cuales se detallan a continuacin:

3.3.1.1 Tcnica descomposicin Consiste en la subdivisin de los productos entregables de un proyecto en componentes ms pequeos y fciles de manipular, hasta que el trabajo y los productos entregables se definan al nivel de paquete de trabajo. El nivel de

paquete de trabajo es el nivel ms bajo del EDT y es el punto en que el costo y el plan de trabajo pueden estimarse de forma fiable. El nivel de detalle para los paquetes de trabajo pueden variar segn el tamao y la complejidad del proyecto (PMBOK, 2008).

Diferentes

productos

entregables

pueden

tener

diferentes

niveles

de

descomposicin. Para llegar a un esfuerzo de trabajo fcil de manejar, o paquete de trabajo, para algunos productos entregables el trabajo slo puede dividirse hasta el nivel siguiente, mientras que otros pueden requerir mayor nivel de descomposicin. Este trabajo regularmente cubre las siguientes actividades: Identificar los productos entregables y el trabajo correspondiente. Estructurar y organizar el EDT. Dividir los niveles superiores de la EDT en componentes ms detallados de nivel inferior.

44 Verificar que el grado de descomposicin del trabajo es el necesario y el suficiente para identificar los paquetes de trabajo

3.3.1.2 Juicio de Expertos El juicio de expertos significa realizar consultas a una persona que conoce ampliamente de un tema muy especfico de un rea del trabajo que estamos realizando. Se recurrir a la experiencia de personas que tengan pequeas y medianas empresas de software para consultarles sobre la informacin que les sea til para el diseo de las nuevas plantillas, basado en los estndares establecidos por las metodologas utilizadas como base, el PMBOK (2008) y el RUP (2002). Para validar la informacin que se vaya recolectando se utilizar el sistema de Entrevistas verbales con dichos profesionales. 3.3.1.3 Herramientas Se utilizarn herramientas de software tales como Microsoft Word, Microsoft Excel para el diseo de las plantillas, adems para definir la lista de actividades, los atributos de las actividades, los recursos necesarios para cada actividad, la cantidad de horas de esfuerzo necesarios y los hitos del cronograma.

Se utilizar el software de Administracin de Proyectos Microsoft Project como herramienta para el desarrollo del cronograma del proyecto, el cual permite visualizar grficamente las actividades, las fechas de inicio y finalizacin, as como las duraciones esperadas. Adems, permite realizar automticamente los clculos del anlisis matemtico de la ruta crtica hacia delante y hacia atrs y la nivelacin de recursos para permitir la consideracin rpida de muchas alternativas del cronograma (PMBOK, 2008).

3.3.1.4 Tcnica Documental o Bibliogrfica Es la que se realiza a travs de la consulta de documentos (de todo tipo) con el fin de unificarlos, analizarlos, utilizarlos, perfeccionarlos y sistematizarlos. Se

45 buscar recopilar informacin de las herramientas, plantillas y estndares planteados por el PMBOK (2008) y el RUP (2002), para los grupos de procesos de planificacin de proyectos y utilizarlos como base para disear el portafolio de plantillas en las diferentes reas que cubre el ciclo de vida de la administracin de proyectos y el ciclo de vida del desarrollo de software.

3.3.2 Segundo objetivo especfico: Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin.

3.3.2.1 Plantillas El uso de plantillas es importante para poder estandarizar la documentacin de los proyectos, de esta forma la informacin que se genere en las plantillas ser de uso y entendimiento comn entre los integrantes del equipo de trabajo.

Tanto la metodologa del PMBOK (2008) y el RUP (2002), ya ofrecen una serie de plantillas para su aplicacin, una de las ideas, es tomarlas, identificar aquellas que sean realmente funcionales para lograr el objetivo de la metodologa planteada y adaptarlas para la utilizacin de las pequeas y medianas empresas de desarrollo de software.

3.3.2.2 Identificacin de involucrados Incluye la lluvia de ideas de parte de los involucrados dentro de los procesos estudiados, para identificar alternativas posibles de caminos a tomar, y as ayudar a establecer las metodologas de forma correcta.

46 3.3.3 Tercer objetivo especfico: Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa

Para lograr este objetivo, se toma la informacin recolectada en el primer objetivo, adems de las plantillas que han sido diseadas, para organizarlas en un repositorio, y por medio de la investigacin documental, desarrollar los procedimientos de utilizacin y adaptacin de las mismas en las empresas de software.

El repositorio ser un lugar electrnico, en la red o una unidad de almacenamiento de datos, donde se guardaran las plantillas que integran el portafolio de herramientas, organizado de manera que sean accesibles para la consulta y utilizacin de los involucrados en los distintos proyectos.

Una de las tcnicas que se espera utilizar ser la de establecimiento de la secuencia de actividades, que consiste en identificar y documentar las relaciones lgicas entre las actividades del plan de trabajo de un proyecto de software, y con esto establecer la organizacin y ordenamiento de las plantillas.

3.3.4 Cuarto objetivo especfico: Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas

Para lograr este objetivo se har uso de la siguiente tcnica:

47 3.3.4.1 Investigacin Aplicada Se caracteriza por su inters en aplicar y utilizar los conocimientos producidos, para saber hacer, actuar, construir y modificar. Aplicando dicha tcnica: Se definir los procedimientos para el desarrollo e implementacin de proyectos de software mediante la utilizacin del portafolio de plantillas y herramientas planteados en los objetivos anteriores. Definicin de instructivos de trabajo que apoyen los procedimientos de desarrollo e implementacin de proyectos de software. Creacin de diagramas de flujo que especifiquen grficamente el

procedimiento a seguir y las plantillas y herramientas a utilizar en el desarrollo e implementacin de proyectos de software.

3.4

Supuestos y Restricciones.

Segn el PMBOK (2008) las restricciones del proyecto se definen como la enumeracin y descripcin de las restricciones especficas asociadas con el alcance del proyecto que limitan las opciones del equipo. Y los supuestos del proyecto se definen como la enumeracin y descripcin de supuestos que se realizan especficamente para el proyecto, asociados con el alcance y el impacto potencial de tales supuestos en el caso que fueran falsos.

Los supuestos que se tienen para el desarrollo de este proyecto son: El proyecto va orientado para ser aplicable a pequeas y medianas empresas del rea de software dedicadas a la venta, implantacin y desarrollo a la medida de aplicaciones de sistemas de informacin cuya operacin normal es de forma proyectizada. Se definirn y establecer una metodologa que genere herramientas y plantillas de documentacin para la administracin del ciclo de vida de los proyectos de software, tanto internos y externos de la empresa basados en las 9 reas del conocimiento establecidas como mejores prcticas del PMBOK (2008).

48 Se consideran proyectos internos los que involucran el desarrollo de una aplicacin, mejoramiento y correccin de versiones de los productos de software actuales, control y atencin de soporte a clientes de la empresa, control de la asignacin y tareas desarrolladas por los funcionarios de las reas de consultora, atencin al cliente y soporte tcnico. Se consideran proyectos externos aquellos que son implementados y desarrollados para un cliente que adquiri el software que desarrolla y promueve la empresa.

Las restricciones que se tienen para este proyecto: Se tiene como fecha lmite de finalizacin del proyecto el mes de Marzo del 2012. El director del proyecto cuenta con una disponibilidad de un 25% para la implementacin del proyecto

Los Supuestos y Restricciones y su relacin con los objetivos del proyecto se ilustran en el cuadro 4, a continuacin.
Cuadro 3 Supuestos y Restricciones

Objetivos Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento. Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin. Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa.

Supuestos

Restricciones

Se cuenta con la experiencia del director de proyectos en el campo del desarrollo del Software.

No se establecern polticas y/o especificaciones de cmo debe funcionar las empresas en referencia.

49
Objetivos Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas. Supuestos Restricciones

3.5

Entregables.

Los entregables y su relacin con los objetivos del proyecto se ilustran en el cuadro 5, a continuacin.
Cuadro 4 Entregables
Objetivos Entregables

Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento. Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin. Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa. Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas.

Documento introductorio de establecimiento de la metodologa propuesta para la empresa.

Documento con la identificacin de los roles y responsabilidades que deben ser tomados en cuenta en el diseo de las plantillas.

Estructura de carpetas organizada donde se guarda la Carpeta de Herramientas por rea del conocimiento del PMI y ciclo de vida del desarrollo del software segn RUP. Instructivo con la gua para la utilizacin de la carpeta de herramientas diseadas.

50

DESARROLLO

El desarrollo de software es un proceso de negocios estratgico que integra y automatiza otros procesos de la organizacin, siendo en la actualidad, una fuente de ventajas competitivas para las empresas, donde se debe de tomar en cuenta que no existe un proceso de software universal. Las caractersticas de cada proyecto (equipo de desarrollo, recursos, costos, etc.) exigen que el proceso sea configurable y se tomen en cuenta todos los factores que se involucran.

El desarrollo de software es un trabajo con humanos (ejecutivos, clientes, usuarios, analistas, desarrolladores, arquitectos, entre otros), por lo cual debe de existir una muy buena comunicacin, organizacin, resolucin de conflictos para lograr el xito del proyecto.

Al desarrollar un producto de software, se debe buscar soluciones elegantes para problemas complejos, determinando el alcance del sistema, descomponindolo en sus funciones bsicas, donde se deben de cumplir con los plazos y el cronograma definido para el desarrollo luego de un estudio preliminar.

El desarrollo de software debe ser configurado y adecuado a la situacin y solicitudes del cliente. Para lo cual se deben de realizar preguntas que conduzca a una definicin de las caractersticas claves del proyecto y proporcionen excelentes lineamientos para la planificacin y el desarrollo del mismo.

Se debe facilitar la comunicacin, asegurar la calidad del producto final, aumentar la productividad, instrumentalizar el mantenimiento, mejorar la prediccin sobre los planes y presupuestos, pues nos trae como resultado el incremento en la satisfaccin de los clientes.

51 Durante este captulo se desarrolla el trabajo propuesto, en el cual se utilizarn las tcnicas y herramientas, descritas previamente segn lo establecen los objetivos generales y especficos definidos. Para lo cual, se utilizara la combinacin de las metodologas RUP para el desarrollo de software y PMBOK (2008) para la administracin de proyectos. El PMBOK es definido como el conjunto de

conocimientos que se utiliza para administrar cualquier tipo de proyecto y el RUP es definido como el conjunto de conocimientos para el desarrollo de proyectos de software y que se adapta al contexto y necesidades particulares de cada empresa.

El PMBOK (2008) entra en las reas que el RUP no considera, tal como es la gestin de la integracin, gestin de recursos humanos, gestin de la comunicacin y gestin de costos, tal como se muestra en la Figura No. 5.

Figura No.5 Mapa de relacin entre RUP y PMBOK (2008)

El RUP ofrece una perspectiva apropiada para la estandarizacin de las mejores prcticas en el desarrollo de Software y el PMBOK (2008) ofrece una descripcin apropiada para la estandarizacin de las mejores prcticas en la Administracin de Proyectos. Con ambos acercamientos disponibles para las empresas, la pregunta llega a ser: Son ellos compatibles? La respuesta es simple: Si.

52

PMBOK Cualquier tipo de proyecto Solamente Prcticas de manejo de proyectos Cubre todos los aspectos del manejo de proyectos Descriptivo fases son dependientes del dominio de uso

RUP Proyecto especifico de Software Manejo de Proyecto y otras prcticas de desarrollo de software Cubre algunos aspectos de la Gerencia de Proyectos Prescriptivo Las fases e iteraciones estn especificando el desarrollo del software

Cuadro 5 Caractersticas PMBOK y RUP

Tanto el RUP y PMBOK, dividen las actividades de trabajo en grupos estructurales y grupos temporales. El RUP tiene grupos estructurales de actividades llamadas disciplinas y grupos temporales de actividades denominado flujos de trabajo, tal como se muestra en la Figura XXX. El PMBOK tiene grupos estructurales de los procesos llamadas reas de conocimiento y grupos temporales de procesos llamados grupos de procesos, tal como se muestra en la Figura XX.

Figura 6 Mapa de flujos y disciplinas del RUP

53

4.1

Justificacin del proyecto

Dado el creciente aumento de pequeas y medianas empresas de software que se constituyen y no cuentan con una oficina de proyectos y una metodologa que les ayude a desarrollar con orden y planificacin las diferentes etapas y procesos que involucra la direccin general de la empresa y el ciclo de vida de los proyectos que administran, aunado con la influencia de nuevas tecnologas; surge la necesidad de implementar nuevas formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administracin de proyectos, sin dejar de lado la colaboracin a distancia, el outsourcing, la mejora de calidad, generacin y distribucin de conocimiento y coordinacin de varios proyectos, entre otras.

4.2

Primer Objetivo Especfico

Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento.

El Rational Unified Process (RUP), es un proceso de desarrollo de software utilizado para el anlisis, implementacin y documentacin de sistemas y cuyo propsito principal es el de productor de software de alta calidad, buscando satisfacer las necesidades de los usuarios finales, ajustndose al presupuesto y a los tiempos estimados. Esta metodologa describe a gran detalle todas las

actividades, roles, responsabilidades, productos de trabajo y herramientas para definir quin hace qu y en qu momento en un proyecto de desarrollo de software, tal como se muestra en la Figura 6.

54 RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades. Las fases que dividen el ciclo de vida son Concepcin, Elaboracin, Construccin y Transicin.

La descripcin de la carpeta de plantillas y herramientas que fueron creadas para cumplir con el primer objetivo especfico de este proyecto ha sido organizada en las 4 fases definidas por la metodologa RUP, segn lo presentado y analizado en los apartados anteriores de este documento. En cada fase se incorporan las

reas del conocimiento del PMBOK (2008) que se involucran y que complementaran la metodologa del RUP.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones. Cada una de estas iteraciones debe de tomar en cuenta estas las disciplinas de desarrollo del RUP, las cuales se indican a continuacin:

Disciplina de Desarrollo: o Modelado del Negocio. o Administracin de Requerimientos. o Anlisis y Diseo. o Implementacin. o Pruebas. o Despliegue.

Disciplina de Soporte: o Configuracin y administracin del cambio. o Administracin del proyecto. o Ambiente.

55 4.2.1 Concepcin Es la fase de la idea, de la visin inicial de producto, su alcance, las primeras estimaciones. Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones. Concluye con el hito de objetivo del ciclo de vida. En lo que corresponde a la Administracin de Proyectos, segn se muestra en la Figura 7 los principales entregables que deben ser generados en esta fase del proyecto.

Figura 7. Flujo de entregables durante la Concepcin del Proyecto

Durante esta fase se realiza el:

Establecimiento de las actividades que definen el modelo, alcance del proyecto, la visin, se identifican los actores y se disean los casos de uso.

A partir del modelo de casos de uso y de la lista de riesgos, se determina qu casos de uso deben implementarse primero para atacar los riesgos de mayor exposicin. Con base en la informacin previa se realiza el proceso de planificacin general y un plan de trabajo detallado para la siguiente fase, as como el plan para la siguiente iteracin.

56 Desarrollar el Plan del Proyecto para determinar los recursos que deben ser asignados y se establecen las pautas que se deben de seguir. La integracin de las reas del conocimiento necesarias para complementar las reas que no tiene el RUP en la Administracin de Proyecto, como lo es la gestin de la integracin, gestin del alcance, gestin del tiempo, gestin de las comunicaciones y gestin de los recursos humanos.

Esta fase responde las siguientes preguntas:

Cules son las principales funciones del sistema para los usuarios ms importantes?

Cmo podra ser la mejor arquitectura del sistema? Cul es el plan del proyecto y cuanto costar desarrollar el producto?

Los objetivos son: Poner en marcha el proyecto Desarrollar el anlisis del negocio hasta justificar la puesta en marcha plan de proyecto

Para ello Esbozar una arquitectura Mitigar los riesgos Anlisis inicial del negocio (coste, agenda, recuperacin de la inversin)

Los principales entregables son: Un documento de visin del proyecto o Requerimientos generales del proyecto o Caractersticas principales o Restricciones Modelo inicial de casos de uso (10% a 20 % listos). Glosario.

57 Caso de negocio: o Contexto o Criterios de xito o Pronstico financiero Identificacin inicial de riesgos. Plan de proyecto. Uno o ms prototipos.

Las partes interesadas deben acordar el alcance y la estimacin de tiempo y costo. Debe quedar una completa comprensin de los requerimientos plasmados en casos de uso.

4.2.1.1 Modelado del Negocio Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin, comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio. Los objetivos de esta disciplina son: Entender la estructura y la dinmica del cliente para la cual el software va a ser desarrollado. Entender el problema actual en el cliente e identificar potenciales mejoras. Asegurar que usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin de la empresa cliente. Derivar los requerimientos del necesidades del cliente. software necesarios para apoyar las

Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visin de la nueva organizacin a crear, basado en esta visin se definen procesos, roles y responsabilidades de la organizacin por medio un modelo de casos de uso del negocio y un modelo de objetos del negocio. Complementario a estos modelos, se desarrollan otras especificaciones tales como el glosario. Como se muestra en la Figura 8 el flujo de informacin en esta disciplina.

58

Figura 8. Disciplina de Modelado del Negocio (IBM, 2008)

A continuacin se describen las plantillas a utilizar para esta disciplina:

Modelo de Casos de Uso del Negocio Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). Tambin describe la realizacin de cada caso de uso del negocio, estableciendo los actores internos, la informacin que en trminos generales manipulan y los flujos de trabajo asociados al caso de uso del negocio. Permite situar al sistema en el contexto organizacional haciendo nfasis en los

59 objetivos en este mbito. Se representa con un Diagrama de Casos de Uso usando estereotipos especficos para este modelo. Plantilla Relacionada: Ver [GDS-001 - Modelo de Casos de Uso del Negocio] en Anexo 8.4.1. en la pgina 148.

4.2.1.2 Requisitos Esta disciplina tiene como objetivos establecer lo que el software debe hacer, definir los lmites del mismo, una interfaz de usuario, para realizar una estimacin del costo y tiempo de desarrollo. El establecimiento y mantenimiento de un acuerdo entre el cliente y el equipo del proyecto sobre la evolucin de las necesidades del sistema, siendo los objetivos de esta disciplina:

Definir el mbito del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.

Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo que el sistema debera hacer.

Proveer a los desarrolladores un mejor entendimiento de los requerimientos del sistema.

Proveer una base para estimar recursos y tiempo de desarrollo del sistema. Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones.

Los requerimientos pueden ser divididos en dos grupos: Los requisitos funcionales son las cosas que el sistema puede hacer, su funcionalidad. Se modelan mediante diagramas de casos de uso. Describen las funciones que el software va a ejecutar; por ejemplo, ajustarse a un formato de texto o modular una seal. Los requisitos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad especfica. Especifican criterios

60 que pueden usarse para juzgar la operacin de un sistema en lugar de sus funciones especficas. Por ejemplo requisitos de usabilidad, fiabilidad, eficiencia, portabilidad, entre otros.

En otras palabras, en este flujo de trabajo se debe analizar el problema, comprender las necesidades de los interesados y expresarlas en forma de requisitos; construir diagramas de casos de uso para los requisitos funcionales, los no funcionales describirlos textualmente en especificaciones suplementarias. Adems hay que gestionar los cambios en los requisitos a lo largo de todo el proceso.

Figura 9. Ejemplo de proceso de Requerimientos (IBM, 2008)

A continuacin se describen las plantillas a utilizar para esta disciplina:

61

Glosario Es un documento que define los principales trminos usados en el proyecto. Permite establecer una terminologa consensuada. Plantilla Relacionada: Ver [GDS-003 - Glosario] en Anexo 8.4.2 en la pgina 152.

Visin Este documento define la visin del producto desde la perspectiva del cliente, especificando las necesidades y caractersticas del producto. Constituye una base de acuerdo en cuanto a los requisitos del sistema. Plantilla Relacionada: Ver [GDS-004 - Visin del Producto] en Anexo 8.4.3 en la pgina 158.

Solicitud de Requerimiento Son aquellas solicitudes que realiza el cliente funcional para la solucin de software que han solicitado, en la cual se detalla una necesidad en el contenido, forma o funcionalidad de ella. Plantilla Relacionada: Ver [GDS-002 - Solicitud de Requerimientos] en Anexo 8.4.6 en la pgina 184.

Especificacin de Requerimientos de Software Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripcin narrativa) se realiza una descripcin detallada, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. Tambin, para casos de uso cuyo flujo de eventos sea complejo podr adjuntarse una representacin grfica mediante un Diagrama de Actividad. Plantilla Relacionada: Ver [GDS-005 - Especificacin de Requerimientos de

Software] en Anexo 8.4.4 en la pgina 167.

62 4.2.1.3 Configuracin y administracin del cambio La finalidad de esta disciplina de trabajo es mantener la integridad de todos los artefactos que se crean en el proceso, as como de mantener informacin del proceso evolutivo que han seguido. El cambio es un factor de riesgo crtico en los proyectos de software. Los artefactos software cambian no slo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo, especialmente importante por su posible impacto son los cambios en los requisitos, tal como se muestra en la Figura 10.

Figura 10. Proceso de Configuracin y Administracin del Cambio (IBM, 2008)

Siendo sus principales componentes:

Administracin

de

la

solicitud

de

cambio:

Seala

la

infraestructura

organizacional requerida para estimar el costo, cronograma e impacto de de

63 una solicitud de cambio a un producto existente. Involucrando al personal responsable del control de la calidad. Medicin del estado real del producto: Es utilizado para describir el "estado" del producto, basado en el tipo, nmero, frecuencia y severidad de los defectos encontrados y corregidos durante el curso del desarrollo del producto. Las mtricas derivadas en este aspecto son tiles para determinar el estado de completitud del proyecto. Administracin de la configuracin: Describe la estructura del producto e identifica sus componentes que pueden ser tratados como entidades que pueden tener una versin por separado. El proceso consiste en la correcta identificacin de cada uno de los componentes. Seguimiento del cambio: Describe lo que se ha realizado a cada uno de los elementos indicando la causa y el momento del cambio. Seleccin de versiones: El propsito de esta seleccin es asegurar que las versiones correctas son seleccionadas para cambios o implementacin. La seleccin de versiones se apoya en una correcta identificacin de la configuracin. Manufactura de software: Cubre lo necesario para automatizar los pasos de compilar, probar y empacar el software para su distribucin.

A continuacin se describen las plantillas a utilizar para esta disciplina:

Plan de Administracin de Configuracin (CM) El propsito de este documento es controlar las polticas de Manejo de Configuraciones (CM) que se utilizaran para monitorear y proteger los activos del proyecto y reforzar las prcticas de desarrollo. Estas polticas pueden

mejorar la comunicacin entre los miembros del equipo de desarrollo y minimizar los problemas encontrados cuando se integra en sus trabajos. Plantilla Relacionada: Ver [GDS-012 - Plan de Administracin de

Configuracin Software] en Anexo 8.4.11 en la pgina 225.

64 Solicitud de Cambio de Requerimientos Los cambios propuestos para los artefactos se formalizan mediante este documento. Mediante este documento se hace un seguimiento de los defectos detectados, solicitud de mejoras o cambios en los requisitos del producto. As se provee un registro de decisiones de cambios, de su evaluacin e impacto, y se asegura que stos sean conocidos por el equipo de desarrollo. Los cambios se establecen respecto de la ltima lnea base (el estado del conjunto de los artefactos en un momento determinado del proyecto) establecida. En nuestro caso al final de cada iteracin se establecer una lnea base. Plantilla Relacionada: Ver [GDS-007 Solicitud de Cambio de

Requerimientos] en Anexo 8.4.19 en la pgina 299.

4.2.1.4 Gestin del proyecto El objetivo de esta disciplina es equilibrar los objetivos competitivos, gestin de la integracin, alcance, tiempo, comunicaciones, riesgos, calidad, adquisiciones y los recursos humanos, y superar restricciones para entregar un producto que satisface las necesidades de ambos clientes con xito (los que pagan el dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el manejo de una entrega exitoso de software. En resumen su propsito consiste en proveer pautas para: Administrar proyectos de software intensivos. Planear, dirigir personal, ejecutar acciones y supervisar proyectos. Administrar el riesgo.

65

Figura 11. Procesos de Administracin de Proyectos (IBM, 2008)

Donde se involucra la metodologa del PMBOK (2008) agregando a esta disciplina las pautas para: Administracin de personal: contratando, entrenando, enseando. Administracin del presupuesto: definiendo, asignando. Administracin de los contratos con proveedores y clientes.

66 4.2.1.4.1 Gestin de la Integracin La Gestin de la Integracin permite considerar el proyecto como un todo, donde se establece la relacin de todos los componentes, se unifica, consolida y articula el proyecto para lograr su conclusin de forma satisfactoria. En esta rea es

donde se formaliza el inicio del proyecto, se definen los roles, se comprende la razn y el porqu del proyecto, los riesgos y en que va consistir su desarrollo. Los procesos involucrados son: Desarrollar el Plan de Gestin del Proyecto. Dirigir y Gestionar la ejecucin del Proyecto. Supervisar y Controlar el desarrollo del Proyecto. Control Integrado de cambios al Proyecto. Cerrar el Proyecto.

A continuacin se describen las plantillas a utilizar para esta rea:

Acta de Inicio del Proyecto Documento emitido por el iniciador o patrocinador del proyecto que autoriza formalmente la existencia de un nuevo proyecto, y le confiere al director de proyectos la autoridad para aplicar los recursos de la organizacin a las actividades del proyecto de desarrollo de software. Plantilla Relacionada: Ver [GPS-001 - Acta de Inicio del Proyecto] en Anexo

8.4.20 en la pgina 300.

Plan de Gestin del Proyecto Documento formalmente aprobado que define cmo se ejecuta, supervisa y controla un proyecto. Plantilla Relacionada: Ver [GPS-005 - Plan del Desarrollo de Software] en

Anexo 8.4.9 en la pgina 199.

67 Lista de Revisin Ciclo Vida Software Este documento contiene una lista de todos los aspectos que deben ser tomados durante el desarrollo del software por cada una de sus etapas, se utiliza como un CheckList por el Administrador del Proyecto, para validar que los artefactos y las etapas van siendo completados de acuerdo al Plan del Desarrollo del Software. Plantilla Relacionada: Ver [GGP15 - Lista de Revisin Ciclo Vida Software]

en Anexo 8.4.17 en la pgina 288.

Lecciones Aprendidas Las lecciones aprendidas no solo se capitalizan al final de los proyectos; tambin las podemos generar y usar durante las reuniones del equipo o con los involucrados clave, pues es posible utilizar los acontecimientos recientes que causaron una desviacin del rumbo inicialmente planeado o las decisiones tomadas durante el planeamiento que no consideraron las variables claves, cuyos resultados salieron a la luz durante la ejecucin del proyecto. As es que siempre tenemos que estar dispuestos a aprender de nuestros errores, tanto como de las buenas decisiones. Este aprendizaje lo convertimos en activos cuando lo documentamos, transmitimos y utilizamos en otros proyectos. Plantilla Relacionada: Ver [GPS-007 - Lecciones Aprendidas] en Anexo 8.4.24 en la pgina 314.

4.2.1.4.2 Gestin del Alcance La gestin del alcance es el proceso en el que se define el trabajo que se debe realizar para completar los objetivos de forma exitosa. Se dice que lo que no est en el alcance no es parte del proyecto.

A continuacin se describen las plantillas a utilizar para esta rea:

68 Estructura de Desglose del Trabajo (EDT): Descomposicin jerrquica con orientacin hacia el producto entregable relativa al trabajo que ser ejecutado por el equipo del proyecto para lograr los objetivos del proyecto y crear los productos entregables requeridos. Organiza y define el alcance total del proyecto (Duncan, 2008). Plantilla Relacionada: Ver [GPS-002 EDT Cronograma del Proyecto] en

Anexo 8.4.21 en la pgina 303.

Plan del Desarrollo de Software El propsito de este documento es permitir organizar, controlar y administrar la documentacin referente al proyecto. En este documento se encuentra la referencia a todos los planes y documentos generados durante el desarrollo del proyecto los cuales se irn agregando a lo largo del proyecto. responsable de esta actividad el Lder de Analistas. Plantilla Relacionada: Ver [GPS-005 - Plan del Desarrollo de Software] en Siendo el

Anexo 0 en la pgina 199.

4.2.1.4.3 Gestin del Tiempo Con la gestin del tiempo se asegura que el proyecto se lleve a cabo en los plazos previstos, nos da la informacin necesaria para desarrollar el proyecto en el plazo aprobado, de acuerdo con las duraciones y secuencias determinadas segn los requisitos y recursos asignados a las distintas actividades.

A continuacin se describen las plantillas a utilizar para esta rea: Cronograma: Documento que establece los tiempos para las actividades involucradas en el proyecto. El desarrollo del cronograma contina a lo largo del proyecto en funcin a la gestin y a los riesgos que se presenten. Plantilla Relacionada: 8.4.22 en la pgina 304. Ver [GPS-002 - Cronograma del Proyecto] en Anexo

69

4.2.1.4.4 Gestin de Riesgos Esta rea permite al equipo del proyecto, prever y actuar con oportunidad para evitar los problemas potenciales, aumentando la posibilidad de tener un menor impacto en eventos negativos y un mayor impacto en eventos positivos. Incluye los procesos de identificacin, anlisis y planificacin de las actividades a desarrollar ante nuevos riesgos que aparezcan a lo largo del proyecto, reanalizar los riesgos existentes, monitorear los planes de contingencia y revisar la ejecucin de las respuestas a cada uno de los riesgos mientras se evala su efectividad.

Un riesgo puede tener una o ms causas y si estos ocurren puede producir cierto impacto en el proyecto. Usualmente los riesgos ms importantes se identifican en base a la probabilidad de su ocurrencia y a la severidad de su impacto si se presenta.

Los procesos involucrados en esta rea son: Planificacin de la Gestin de Riesgos. Identificacin de los Riesgos. Anlisis Cualitativo de los Riesgos. Anlisis Cuantitativo de los Riesgos. Planificacin de las respuestas a los riesgos. Seguimiento y Control de Riesgos.

A continuacin se describen las plantillas a utilizar para esta rea:

Lista de Riesgos Un precepto esencial de RUP es identificar y atacar los ms altos riesgos lo ms pronto posible. La lista de riesgos identifica los eventos, en orden decreciente de prioridad, que podran afectar el xito del proyecto. Esta

plantilla incluye tambin el Plan de Gestin de los Riesgos que se debe de seguir segn lo establecido.

70 Plantilla Relacionada: la pgina 266. Ver [GDS-014 - Lista de Riesgos] en Anexo 8.4.13 en

4.2.1.4.5 Gestin de Comunicaciones La gestin de las comunicaciones soporta los procesos que aseguran la generacin, manejo y transmisin oportuna y apropiada de la informacin del proyecto.

A continuacin se describen las plantillas a utilizar para esta rea:

Minuta de Reunin El uso es almacenar las ideas expuestas en las reuniones que se lleven a cabo en el seno del proyecto. Recoge todo lo que acontece en las reuniones de revisiones del proyecto, donde se registran una serie de informaciones a raz de la revisin, permitiendo al equipo de desarrollo la bsqueda de los temas tratados en una fecha determinada una vez que las actas hayan sido almacenadas en el repositorio de documentacin. Se realiza durante las diferentes etapas del proceso de desarrollo, como parte de las actividades del equipo de documentacin. Plantilla Relacionada: en la pgina 273. Ver [GDS-010 - Minuta de Reunin] en Anexo 8.4.14

4.2.1.4.6 Gestin de Recursos Humanos La gestin de los recursos humanos organiza, administra y lidera el equipo de proyecto con el fin de lograr un manejo integral, efectivo y eficiente de las diferentes tareas y resultados. Se definen las responsabilidades de los miembros del equipo de proyecto, as como el plan de gestin del personal a seguirse durante el proyecto.

71 A continuacin se describen las plantillas a utilizar para esta rea:

Asignacin de Roles Este documento tiene como propsito describir el equipo del proyecto y establecer sus responsabilidades dentro del proyecto. En el caso de proyectos pequeos esta informacin se puede definir dentro del Plan del Proyecto del Software. Plantilla Relacionada: en la pgina 275. Ver [GGP05 - Asignacin de Roles] en Anexo 8.4.15

4.2.1.4.7 Gestin de los Costos La gestin del costo incluye los procesos de estimacin, presupuesto y control de los costos, para que el proyecto sea completado dentro del presupuesto aprobado. Considera tambin el flujo de efectivo requerido en funcin de su tiempo de duracin.

A continuacin se describen las plantillas a utilizar para esta rea:

Plan de Gestin de los Costos Este documento establece la gestin de los costes en los que el proyecto va a incurrir. Para ello se identifican los costes asociados a cada recurso en funcin de las tareas asignadas. Plantilla Relacionada: Ver [GPS-008 - Plan de Gestin de los Costos] en

Anexo 8.4.25 en la pgina 319.

4.2.1.4.8 Gestin de la Calidad La gestin de la calidad es el proceso de verificacin de que los estndares sean aplicados correctamente. En proyectos pequeos esto se puede realizar por el equipo de desarrollo, pero en proyectos grandes, un grupo especfico se debe dedicar a este rol. Busca de satisfacer las necesidades por las que fue creado el

72 proyecto a travs de diferentes polticas, procedimientos y objetivos de calidad. Adems promueve actividades que buscan lograr la mejora continua de los procesos. Siendo un conjunto de actividades que sern ejecutadas para generar confianza en que el producto cumplir con los requerimientos y el proceso es efectivo.

Una de las principales fases dentro de la elaboracin de un proyecto de software es el Aseguramiento de la Calidad del Software (SQA), es decir, un modelo sistemtico y planeado de todas las acciones necesarias para proveer la confianza adecuada, segn los requerimientos tcnicos establecidos, de cada producto e tem del proyecto. Un sinnimo del aseguramiento de la calidad del software es aseguramiento del producto de software.

A continuacin se describen las plantillas a utilizar para esta rea:

Plan de Aseguramiento de la Calidad (SQA) El plan de aseguramiento de la calidad del software (SQAP) define las actividades especficas a llevar a cabo en un proyecto especfico. El SQAP contiene una lista de comprobacin para las actividades que se deben llevar a cabo para asegurar la calidad del producto. Para cada fase del proyecto, se debe crear un plan para su monitoreo. Plantilla Relacionada: Ver [GPS-006 - Plan de Aseguramiento de la Calidad]

en Anexo 0 en la pgina 219.

4.2.1.5 Ambiente Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que apoyan un proyecto. Su propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual

73 basarse, el cual provee procesos y herramientas para poder desarrollar el software. En concreto, las responsabilidades de esta disciplina incluyen: Seleccin y adquisicin de herramientas. Establecer, instalar y configurar las herramientas para que se ajusten a los planes del proyecto que se desarrolla. Configuracin del proceso. Mejorar el proceso. Servicios tcnicos

Figura 12. Esquema de Administracin del Ambiente (IBM, 2008)

A continuacin se describen las plantillas a utilizar para esta disciplina:

Plan de Especificacin del Ambiente El propsito es detallar las inversiones y usos de las tecnologas de integracin en la organizacin, que sern requeridas para el desarrollo e implementacin del software que ser desarrollado. Aqu se define los tipos de tecnologas que

74 sern utilizados, para as determinar si es necesario realizar nuevas adquisiciones o mejorar las que se tienen. Plantilla Relacionada: Ver [GDS-016 - Plan de Especificacin del Ambiente]

en Anexo 8.4.8 en la pgina 195. Checklist de Ambiente El propsito de este documento es verificar los ambientes de Desarrollo y Pruebas contra el Plan de Especificacin de Ambiente. Adems identifica las personas responsables y las caractersticas de Hardware y Software que poseen los diversos ambientes requeridos. Plantilla Relacionada: Ver [GDS-017 - Checklist de Ambiente] en Anexo 8.4.7 en la pgina 188.

75 4.2.2 Elaboracin Comprende la planificacin de las actividades y del equipo necesario. La especificacin de las necesidades y el diseo de la arquitectura. Termina con el hito de Arquitectura. En esta fase los procesos se enfocan hacia la comprensin del problema y la tecnologa, se definen los lmites del proyecto, se abarcan ms los procesos que tienen que ver con los requerimientos, anlisis y diseo del proyecto que se va a desarrollar. En lo que corresponde a la Administracin del proyecto, como se muestra en la Figura 13, se muestra el flujo de procesos y entregables principales que se deben generar.
Del Inicio del proyecto
Acta de Constitucin del Proyecto (F0)

Replanificacin
Solicitud de Cambio aprobada (Formato F4)

Planificacin de los Recursos Humanos Desarrollo del Cronograma de Trabajo Planificacin de las Compras y Adquisiciones
Lneas Base Primarias: Alcance Tiempo Costo

Definicin del Alcance del Proyecto

[ CP, ET ]

EDT (WBS)

Desarrollo del Presupuesto

[ CP, ET ]

Planificacin de los Riesgos Planificacin de las Comunicaciones

[ CP, ET ]

Aprobaci n del Plan del Proyecto

[ EP ] Plan de Gestin del Proyecto

Si Aprobado

Plan Plande de Gestin Gestindel del Proyecto Proyecto

Formato: Formato:F1 F1

No

Roles: CP : Coordinador del Proyecto EP : Ejecutivo del Proyecto ET : Equipo de Trabajo

Figura 13. Flujo de entregables durante la Elaboracin del Proyecto

Al final de la fase se determina la viabilidad de continuar el proyecto y si se decide proseguir, dado que la mayor parte de los riesgos han sido mitigados, se escriben los planes de trabajo de las etapas de construccin y transicin y se detalla el plan de trabajo.

Las iteraciones en la fase de elaboracin: Establecen una firme comprensin del problema a solucionar.

76 Establece un plan detallado para las siguientes iteraciones. Elimina los mayores riesgos.

El resultado de esta fase es la lnea base de la arquitectura del ciclo de vida.

Los objetivos de esta fase son: Establecer una arquitectura slida para guiar las fases posteriores. Asegurar que los requerimientos y definiciones obtenidos en la etapa de concepcin sean slidos y se hayan contemplado y mitigado todos los riesgos que podran afectar el desarrollo del sistema. Definir los posibles escenarios de instalacin y trabajo, verificando las necesidades de equipamiento de hardware e infraestructura. Analizar y profundizar en cada uno de los casos de uso obtenidos en la etapa de concepcin para elaborar un prototipo funcional que permita verificar el alcance del desarrollo de software. Revisar que los requerimientos de software se correspondan con la estructura actual de trabajo y documentar las propuestas de reorganizacin. Afinar el diseo de las arquitecturas a fin de verificar que sea slida y cumpla con los requerimientos del sistema. Analizar el posible re-uso de componentes dentro de la arquitectura seleccionada. Refinar el esquema de desarrollo seleccionando herramientas y metodologas particulares para la etapa siguiente (construccin). Completar el plan de proyecto.

Para ello Se toman decisiones considerando la comprensin global del sistema: mbito, requisitos funcionales y no funcionales

Los entregables principales son: Modelo de casos de uso (80% completo) con descripciones detalladas. Otros requerimientos no funcionales o no asociados a casos de uso.

77 Descripcin de la Arquitectura del Software. Un prototipo ejecutable de la arquitectura. Lista revisada de riesgos y del caso de negocio. Plan de desarrollo para el resto del proyecto. Un manual de usuario preliminar.

Condiciones de xito de la fase de elaboracin: Es estable la visin del producto? Es estable la arquitectura? Las pruebas de ejecucin demuestran que los riesgos han sido abordados y resueltos? Estn de acuerdo con el plan todas las personas involucradas?

4.2.2.1 Anlisis / Diseo Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requerimientos en especificaciones de implementacin. disciplina son: Los objetivos de esta

Transformar los requerimientos al diseo del futuro sistema. Desarrollar una arquitectura para el sistema Adaptar el diseo para que sea consistente con el entorno de implementacin, diseando para el rendimiento, teniendo en cuenta las siguientes actividades:

a) Analizar Casos de Uso: Esta actividad consiste en tomar los casos de uso y generar el modelo conceptual. Adems se debe hacer la realizacin de cada uno de los casos de uso, que comprende el VOPC, diagrama de secuencia, diagrama de colaboracin y diagrama de estados.

b) Realizar Anlisis de Arquitectura: Esta actividad consiste en tomar las realizaciones de casos de uso y buscar la mejor arquitectura posible, dadas

78 las restricciones de diseo que se encuentran en el documento de especificaciones suplementarias.

c) Disear Esquema de Solucin: Esta actividad consiste en generar los diagramas de clases participantes (VOPC) y los diagramas de secuencia, para los casos de uso ms representativos.

d) Probar Solucin Propuesta: Esta actividad consiste en tomar un caso de uso y programar el producto, luego probar el correcto funcionamiento de la solucin. Se deben hacer tanto pruebas funcionales como de desempeo.

e) Describir Ambiente de Produccin: Esta actividad consiste en generar los diagramas de implantacin y de procesos, en donde se muestra cmo quedar la aplicacin cuando ya se encuentre en el ambiente de produccin

f) Disear Casos de Uso: Esta actividad consiste en tomar todos los diagramas de secuencia y de clases participantes y refinarlos, se deben especificar los tipos de dato de los parmetros, y los tipos de dato de los retornos de las operaciones.

g) Disear Base de Datos: Esta actividad consiste en tomar los diagramas de clases participantes y mapear las clases de entidad, en clases persistentes de bases de datos, y adems generar procedimientos almacenados para las operaciones de bases de datos.

h) Disear Componentes: Esta actividad consiste en agrupar las diferentes clases en componentes, tomando consideraciones como tipo y

funcionalidad.

79

Figura 14. Disciplina de Anlisis y Diseo (IBM, 2008)

A continuacin se describen las plantillas a utilizar para esta disciplina:

Anlisis Preliminar Con este modelo se establece la realizacin de los casos de uso en clases y pasando desde una representacin en trminos de anlisis (sin incluir aspectos de implementacin) hacia una de diseo (incluyendo una orientacin hacia el entorno de implementacin), de acuerdo al avance del proyecto. Plantilla Relacionada: Ver [GDS-006 - Anlisis Preliminar del Sistema] en

Anexo 8.4.5 en la pgina 179.

Documento Arquitectura del Software Uno de los desarrollos ms importantes dentro de la construccin del software es el desarrollo de la arquitectura de software, que permite representar la estructura del software, sirviendo de comunicacin entre las personas

80 involucradas en el desarrollo y ayudando a realizar diversos anlisis que orienten el proceso de toma de decisiones. Plantilla Relacionada: Ver [GDS-022 - Documento Arquitectura del Software]

en Anexo 8.4.18 en la pgina 291.

4.2.2.2 Implementacin Esta disciplina tiene como objetivos implementar las clases de diseo como componentes (ej. fichero fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los componentes en un sistema ejecutable. El resultado final de esta disciplina es un sistema ejecutable. Por cada iteracin se debe de hacer lo siguiente:

Planificar los submdulos que deben ser implementados y en qu orden deben ser integrados.

Cada desarrollador decide en qu orden implementa los elementos del submdulo.

Si se encuentran errores de diseo, se notifican. Se prueban los submdulos individualmente. Se integra el sistema siguiendo el plan.

81

Figura 15 Ejemplo de proceso de implementacin (IBM, 2008)

A continuacin se describen las plantillas a utilizar para esta disciplina:

Prototipos de Interfaces de Usuario Se trata de prototipos que permiten al usuario hacerse una idea ms o menos precisa de las interfaces que proveer el sistema y as, conseguir retroalimentacin de su parte respecto a los requisitos del sistema. Estos prototipos se realizarn como: dibujos a mano en papel, dibujos con alguna herramienta grfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Slo los de este ltimo tipo sern entregados al final de la fase de Elaboracin, los otros sern desechados. Asimismo, este artefacto, ser desechado en la fase de Construccin en la

82 medida que el resultado de las iteraciones vayan desarrollando el producto final. Plantilla Relacionada: Ver [GDS-008 - Prototipos de Interfaces de Usuario] en Anexo 8.4.23 en la pgina 308.

Modelo de Implementacin Este modelo es una coleccin de componentes y los subsistemas que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de cdigo fuente, y todo otro tipo de ficheros necesarios para la implantacin y despliegue del sistema. (Este modelo es slo una versin preliminar al final de la fase de Elaboracin, posteriormente tiene bastante refinamiento). Plantilla Relacionada: Ver [GDS-018 - Plan de Despliegue del Proyecto] en

Anexo 8.4.16 en la pgina 282.

4.2.3 Construccin El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar el cambio de los artefactos construidos, ejecutar el plan de administracin de recursos y mejoras en el proceso de desarrollo para el proyecto. Se desarrolla el producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el hito del inicio de la capacidad operativa.

Adems que se incluye el control y las pruebas del producto desarrollado. Durante esta fase se construyen todos los componentes y funcionalidades de la aplicacin restantes y son integrados al producto. Todo es probado en profundidad. El nfasis est en la produccin eficiente y no ya en la creacin intelectual. Puede hacerse construccin en paralelo, pero esto exige una planificacin detallada y una arquitectura muy estable. Como se muestra en la Figura 16, se presentan las acciones que se deben de seguir en lo que a la

83 Administracin de proyectos, se debe de ir realizando, donde la mayora de la documentacin fue iniciada en las fases anteriores, pero en esta debe de irse completando.
Durante la Ejecucin del proyecto
Registro de Informacin de Avance del Proyecto
[ CP ]

Elaboracin del Informe de Estado del Proyecto

[ CP ]

Elaboracin del Informe de Estado

Infor Informe mede de Estado Estadodel del Proyecto Proyecto

Formato: Formato:F6 F6

Anlisis de Variaciones
[ CP ]

Se necesitan ca mbio s
Si Si

No

Fin

Control Integrado de Cambios

Requiere Solicitud Cambio

No

Aprobacin: Acc. Correctivas Acc. Preventivas Evaluacin del Requerimiento de Cambio

[ CG ]

Acc. Acc.Correctivas Correctivas Acc. Acc. Preventivas Preventivas

Fin

Dirigir y gestionar la ejecucin del proyecto Cambios Aprobados Solicitud Solicitudde de Cambio Cambio Rechazada Rechazada
Formato: Formato:F4 F4
Fin

[ IP ]

Elaboracin del Requerimiento de Cambio

Solicitud Solicitudde de Cambio Cambio

Formato: Formato:F4 F4

Roles: IP : Interesado en el Proyecto (Stakeho lders) CG : Comit de Gestin del Proyecto CP : Coordinador del Proyecto

Solicitud Solicitudde de Cambio Cambio Aprobada Aprobada

Fin

Formato: Formato:F4 F4

Replanificacin del Plan de Gestin de l Proyecto

Figura 16. Flujo de entregables durante la Construccin del Proyecto

Los objetivos de esta fase son: Lnea base de la arquitectura crece hasta convertirse en el sistema completo Riesgos reducidos o rutinarios Obtener un sistema de calidad en un tiempo acotado. Completar para cada mdulo a desarrollar las etapas de anlisis, diseo, desarrollo y pruebas. Trabajar en paralelo en el desarrollo de subsistemas y mdulos que pueden ser elaborados de forma independiente. Trabajar de forma iterativa e incremental en el desarrollo, documentando y completando las definiciones de los casos de uso, diseo y pruebas. Probar los ambientes de instalacin y realizar instalaciones beta de los productos en entornos similares a los definitivos.

84 Instalar y probar las redes y software de base necesarios para la futura instalacin del sistema.

Para ello A travs de sucesivas iteraciones e incrementos se desarrolla un producto software, listo para operar, ste es frecuentemente llamado versin beta

Los entregables principales son: El producto de software integrado y corriendo en la plataforma adecuada. Manuales de usuario. Una descripcin de la versin actual del software.

Se obtiene un producto preliminar que debe decidirse si puede ponerse en ejecucin sin mayores riesgos.

Condiciones de xito: El producto est maduro y estable para instalarlo en el ambiente del cliente? Estn los interesados listos para recibirlo?

4.2.3.1 Pruebas Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin), verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los defectos detectados han sido resueltos antes de la distribucin. Se debe establecer una relacin clara y directa entre los casos de uso y los casos de prueba para facilitar que el proceso de aseguramiento de la calidad del software se ejecute adecuadamente. Los objetivos de esta disciplina son: Verificar la interaccin entre los objetos Verificar la integracin apropiada de componentes Verificar que se satisfacen los requerimientos

85 Identificar los defectos y corregirlos antes de la instalacin

Figura 17. Ejemplo de proceso de Pruebas (IBM, 2008)

A continuacin se describen las plantillas a utilizar para esta disciplina:

Plan de Pruebas El plan de pruebas debe planearse en esta fase, ejecutarse desde la primera iteracin de la fase de elaboracin y refinarse sucesivamente durante el ciclo de vida del proyecto. Cada prueba es especificada en este documento que establece las condiciones de ejecucin, las entradas de la prueba, y los resultados esperados. Plantilla Relacionada: la pgina 232. Ver [GDS-015 - Plan de Pruebas] en Anexo 8.4.12 en

86

4.2.4 Transicin El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto al inicio del mismo. Se realiza el traspaso del producto a los usuarios. Incluye: manufactura, envo, formacin, asistencia y el mantenimiento hasta lograr la satisfaccin de los usuarios. Termina con el hito de entrega del producto. Al finalizar esta etapa el sistema debe quedar en manos de los usuarios.

Los objetivos de esta fase son: Gestionar todos los aspectos de implantacin Pruebas de aceptacin Instalacin del software en el entorno final de trabajo, realizando instalaciones progresivas y pruebas. Capacitacin de los usuarios con la nueva herramienta. Conversin e importacin de datos anteriores al nuevo sistema. Ajuste del software y la organizacin. Medicin de performance de la herramienta y del esquema organizacional. Pruebas de estrs sobre las redes y equipamiento, verificacin de los planes de contingencia.

Para ello Las iteraciones en esta fase continan agregando caractersticas al software. El equipo se encuentra ocupado en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior.

Los entregables principales son: Traspasar el software desarrollado a la comunidad de usuarios.

87 Una vez instalado surgirn nuevos elementos que implicarn nuevos desarrollos (ciclos). Incluye: Pruebas preliminares para validar el producto con las expectativas del cliente. Ejecucin paralela con sistemas antiguos. Conversin de datos. Entrenamiento de usuarios. Distribuir el producto.

Condiciones de xito: Se han alcanzado los objetivos fijados en la fase de Inicio? El usuario est satisfecho?

4.2.4.1 Despliegue Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a su entrega y recepcin por el cliente. En esta disciplina se realizan las actividades de probar el software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la tarea de ensear al usuario. El objetivo es producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:

Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin. Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos

88

Figura 18. Ejemplo de Proceso de Despliegue (IBM, 2008)

A continuacin se describen las plantillas a utilizar para esta disciplina: Plan de Despliegue Este modelo muestra el despliegue la configuracin de tipos de nodos del sistema, en los cuales se har el despliegue de los componentes. Plantilla Relacionada: Ver [GDS-018 - Plan de Despliegue del Proyecto] en

Anexo 8.4.16 en la pgina 282.

89

4.3

Segundo Objetivo Especfico

Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin.

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempear diversos roles, as como un mismo rol puede se desempeado por varias personas.

Los roles los ejecutan las personas encargados de la realizacin de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, se dividen en varias categoras: Analistas, Desarrolladores, Probadores, Encargados, Otros actores. A continuacin se describen los actores involucrados en el desarrollo de software y por cada uno las tareas y responsabilidades asignadas:

4.3.1 Administrador del Proyecto (PM) Aprobar el anlisis y diseo Hacer entrega formal del anlisis y diseo al cliente y evaluar los criterios de aceptacin de la etapa Elaborar todos los documentos necesarios para planear el proyecto entre ellos: plan de desarrollo de software, plan de administracin de requerimientos, plan de administracin de configuracin, plan de pruebas, plan de riesgos. Elaborar la lista de chequeo de proyectos donde se define cules son los tems que se van a desarrollar y que aplican segn el tipo de proyecto. Solicitar aprobacin del cliente.

90 Si el cliente suministra informacin para la elaboracin del proyecto se considera producto suministrado por el cliente. Ver procedimiento propiedad del cliente. Si el proyecto requiere que se hagan compras o adquisiciones y estn dentro del alcance, aplicar lo definido en el proceso Gestin Compras y Logstica. Evaluar riesgos que puedan presentarse en el proyecto, cuantificarlos y establecer un mtodo de control y mitigacin. Solicitar creacin de estructura en repositorios. Definir WBS o lista de entregables y actividades que deben ejecutarse en el proyecto. Definir cules son los entregables que se generarn en el proyecto y que aplican segn el alcance definido con el cliente. Establecer la secuencia de actividades segn el plan de iteraciones y entregables definidos con el cliente. Identificar cules actividades se pueden realizar en paralelo y cules tienen dependencia. Estimar la duracin para cada una de las actividades, teniendo en cuenta los modelos de estimacin puntos de caso de uso, lneas de cdigo y experiencia El PM se reunir con el equipo de trabajo para validar las actividades, el secuenciamiento y la duracin asignada a cada actividad, con el fin de determinar si son adecuados para el proyecto. En caso de ser necesario

realizar ajustes, se aplicarn directamente sobre el cronograma. Definir criterios de aceptacin con el cliente para cada una de las iteraciones o fases del proyecto Planear la siguiente iteracin Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Reportar tiempos invertidos en cada una de las actividades del cronograma. Ajustar tiempos de actividades de acuerdo con el desarrollo que se va presentando segn el comportamiento del proyecto

91 Aprobar o rechazar reporte de tiempos invertidos por personas involucradas en el proyecto. Realizar seguimiento y control a los riesgos identificados en el proyecto, en el caso de que surjan nuevos riesgos, reportarlos y gestionarlos. Ver procedimiento Gestin de riesgos Llevar control de indicadores de progreso del proyecto Peridicamente realizar reuniones de seguimiento con el equipo de trabajo con el fin de identificar el estado del proyecto, dificultades presentadas, acciones tomadas, riesgos materializados, necesidades de formacin, estado de la lista de revisin de ciclo de vida de proyectos (generacin de tems definidos en la planeacin), etc. Realizar seguimiento y control a los riesgos identificados en el proyecto, en el caso de que surjan nuevos riesgos, reportarlos y gestionarlos. Ver procedimiento Gestin de Riesgos Semanalmente generar el informe de estado del proyecto que contempla: avance, variacin esfuerzo, variacin duracin, pendientes, recursos y controles de cambio. Segn la periodicidad definida con el cliente, presentar informes de avance del proyecto el cual contiene un detalle de actividades realizadas durante el perodo, avance al cronograma, riesgos materializados, control de cambios, pendientes y plan de trabajo siguiente perodo. Reuniones de seguimiento entre el cliente y el PM, evaluar el informe de avance presentado. Verificar el estado del proyecto y los avances obtenidos. Programar y formalizar la entrega de la solucin al cliente. Si el cliente lo solicita, entregar los casos de prueba diseados en el proceso de pruebas. Validar los criterios de aceptacin Actualizar cronograma con el avance al 100% de actividades completadas. Entregar todos los productos suministrados por el cliente para el desarrollo del proyecto. Ver procedimiento manejar propiedad del cliente. Reunin de entrega con el cliente.

92 Hacer entrega de los medios fsicos que contienen la solucin y la documentacin exigida. Generar acta de entrega al cliente, estableciendo el perodo de garanta, que debe corresponder con la misma definida en el contrato Registrar las fechas de inicio y finalizacin de garanta con el objetivo de aplicar nicamente la garanta a aquellos proyectos que an la tienen vigente. El analista encargado deber atender la garanta en los plazos establecidos en el formato garanta de proyectos. Realizar control de versiones al software. Ver procedimiento CM Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas

durante la aplicacin proceso. En la fase de Inicio y Planeacin se identifican los riesgos del proyecto, en primera instancia se busca en el plan de riesgos los posibles riesgos, si no se encuentra en el listado se ingresa como un riesgo genrico del proyecto Asignar a cada riesgo la probabilidad de ocurrencia que debe estar entre 0 y 50% segn la priorizacin y el anlisis Formular estrategias, acciones y planes de mitigacin para los riesgos identificados Supervisar los planes de accin, verificar que los planes de mitigacin han sido implementados, en caso de que no funcionen, reportar el riesgo materializado, fecha, nmero de ocurrencias, magnitud de prdida en horas, solucin y accin correctiva y preventiva formulada Registrar en lecciones aprendidas aquellos riesgos que se materializaron en el proyecto y que deban formar parte del conocimiento organizacional para que sirvan de fuente de consulta para otros proyectos Llevar a cabo el cierre del contrato, entregar todos los elementos que fueron contemplados en el contrato, informes, manuales, fuentes, etc. Verificar que todo lo pactado se haya cumplido Gestionar el cumplimiento del alcance definido en la negociacin comercial con el cliente.

93 Cuando se presenten variaciones por solicitud interna implica aprobacin del PM. Cuando se presenten variaciones por solicitud del cliente implica control de cambios, registrarlos y realizar la gestin con el Vendedor para su negociacin.

4.3.2 Gerente de Oficina de Proyectos (PMO) Realizar un kickoff interno para entregar al PMO y al PM la orden de inicio, propuesta tcnica y comercial, riesgos y todos los elementos necesarios que apoyen el desarrollo de la planeacin. Informar al Coordinador de proyectos el inicio del proyecto para que este sea creado en herramienta. Realizar kickoff interno con el objetivo de conocer el alcance del proyecto, canales de comunicacin, competencias necesarias, revisar las lecciones aprendidas en otros proyectos, presentar el plan de desarrollo, plan de riesgos, metodologa de trabajo, fecha de inicio y finalizacin y otro tema que sea necesario desarrollar. Realizar kickoff externo con el objetivo de conocer: alcance del proyecto, canales de comunicacin, plan de desarrollo, plan de riesgos, equipo de trabajo, metodologa de trabajo, fecha de inicio y finalizacin y otro tema que sea necesario desarrollar. Realizar entrega formal de todos los elementos de la planeacin al cliente. Gestionar la generacin de facturas correspondientes al proyecto, en los puntos de corte o segn lo convenido en la negociacin con el cliente. Administrar el talento humano asignado al proyecto, gestionar incapacidades (informar a talento humano para liquidacin), vacaciones (solicitud al PM, PM evala viabilidad, PMO aprueba, PMO enva a talento humano la aprobacin para liquidacin), necesidades de formacin (se identifican en reuniones de seguimiento del proyecto, o el personal hace la solicitud por correo y el PMO se encarga de gestionar con el rea de capacitaciones la formacin, ya sea interna o externa).

94

4.3.3 Vendedor Analizar la viabilidad del proyecto Si se decide participar de una oferta

comercial, se contina con el siguiente paso, en caso contrario declinar participacin Elaborar propuesta comercial para el cliente, si se requiere apoyo para su elaboracin solicitar al PMO los recursos necesarios. Si el cliente suministra informacin para la elaboracin de la propuesta se considera producto suministrado por el cliente. Estimar el tiempo y costo que se requiere para el desarrollo. estimacin se basa en la experiencia de los desarrolladores expertos. En la estimacin de un proyecto se puede utilizar cualquier o se puede hacer una combinacin de varias, queda a criterio de los Vendedor. Para estimar costo tener en cuenta el nmero de recursos, cargos y disponibilidad requerida durante el tiempo de vida del proyecto. Identificar riesgos iniciales del proyecto y tenerlos en cuenta en la estimacin de tiempo y costo del proyecto. Si despus del anlisis se identifica que el proyecto es riesgoso, se enva carta al cliente declinando participacin. Solicitar aprobacin interna al Gerente de Desarrollo y al PMO de la propuesta tcnica y comercial que se va a enviar al cliente. El Gerente de Desarrollo y el PMO se renen validan la propuesta tcnica y comercial, en caso de que existan observaciones se las comunican va email al Vendedor, en caso contrario envan un email de aprobacin. El Gerente de Desarrollo y el PMO pueden detectar que no es viable la realizacin del proyecto, le comunican al Vendedor y se enva carta al cliente declinando su participacin. Presentar y sustentar la propuesta tcnica y comercial al cliente. Esta actividad slo se hace, cuando el proceso de contratacin con el cliente as lo solicite. Para la

95 En caso de que la propuesta haya sido adjudicada, gestionar con el cliente uno de los siguientes documentos que formalicen la aceptacin: contrato, oferta mercantil u orden de servicio. Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas

durante la aplicacin proceso.

4.3.4 Analista de Sistemas Entender el alcance y la definicin del problema que se va a resolver con el sistema. Determinar los stakeholders relevantes. Obtener el contexto suficiente del negocio para entender el problema. Describir el problema que se est tratando de resolver con el sistema. Definir un vocabulario comn que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los casos de uso Obtener la lista de los usuarios potenciales, tomadores de decisiones y dems interesados en el proyecto. Determinar qu debe hacer el sistema. Definir los lmites del sistema. Identificar las necesidades y caractersticas del sistema. Identificar los requerimientos funcionales y no funcionales del sistema. Trazabilidad entre necesidades, caractersticas y requerimientos. Establecer los requerimientos de alto nivel del sistema . Definir quin y/o qu interactuar con el Sistema. Esbozar la funcionalidad del Sistema, lo que el Sistema deber hacer . Tener una idea y generar un primer acuerdo del comportamiento esperado del sistema en relacin al requerimiento. Completar los requerimientos con aquellos no evidentes desde el punto de vista funcional. Manejar las dependencias entre los requerimientos.

96 Priorizan los requerimientos funcionales de acuerdo con la relevancia para la arquitectura y el negocio. Identificar el conjunto de escenarios y requerimientos que representan aspectos importantes en la definicin de la arquitectura, para luego priorizar su orden de implementacin de acuerdo con su complejidad tcnica y el impacto en las dems actividades del proyecto. Visualizar en la arquitectura los casos de uso ms importantes para la arquitectura. Identificar riesgos asociados a la definicin de los requerimientos encontrados, identificar acciones para mitigarlos. Recolectar los requerimientos de los stakeholders de lo que el sistema debe hacer. Obtener detalle adicional del requerimiento como insumo para la

especificacin. Identificacin de las fuentes adecuadas de informacin para el requerimiento o el conjunto de requerimientos en cuestin. Formular qu preguntas deben ser resueltas a travs de la recopilacin de informacin. Identificar las necesidades, priorizar la informacin y clarificar dudas directamente de los stakeholders. Los requerimientos son especificados a un nivel de detalle necesario para que los diseadores, personal de pruebas, documentadores y dems miembros del equipo del proyecto puedan continuar con el desarrollo del mismo. Detallar la informacin del requerimiento. Detallar la informacin no funcional que debe ser incluida en el desarrollo de la solucin. Describir el flujo de sucesos en detalle incluyendo cmo comienza, termina e interactan los actores Identificacin de la pertinencia de la revisin de los requerimientos. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de la documentacin.

97 Dar respuesta a los incidentes encontrados Dejar la constancia de las revisiones Aprobar el requerimiento funcional especificado Convertir la documentacin del requerimiento segn los estndares del cliente, en caso de ser requerido. Hacer entrega formal del requerimiento al cliente. Ajustar la especificacin del requerimiento. Dejar la constancia de las revisiones. Dar contexto del requerimiento al resto de los integrantes del equipo como Arquitecto, Diseador de Solucin, Ingeniero de Desarrollo, Ingeniero de Pruebas y Documentador. Elaborar la presentacin y dems elementos que ayuden al entendimiento del requerimiento. Suministrar los artefactos de anlisis a los interesados del equipo de desarrollo Elaborar documento que especifique los requerimientos para el uso de interfaces propias y con otros sistemas Disear la Interfaz de Usuario: segn los lineamientos grficos y de usabilidad dados por el cliente o si no fueron determinados realizar una propuesta. Construir el prototipo de interfaz de usuario que le permita al usuario llevar a cabo los casos de uso de manera eficiente. Definir flujo de navegacin del proyecto, teniendo en cuenta el modelo de casos de uso y los requerimientos definidos por el cliente Elaborar documento que especifique que parmetros se deben tener en cuenta en el diseo para que la interfaz sea usable Disear las realizaciones de los casos de uso

4.3.5 Arquitecto Definir la arquitectura y sus restricciones del sistema. Establecer un conjunto de medidas, objetivos y restricciones que definen directrices para el diseo y construccin de la solucin.

98 Determinar la manera en que la aplicacin debe ser construida, basndose en modelos de diseo que soporten cumplir con las metas y restricciones propuestas. Establecer la estructura de implementacin de la solucin, identificando los subsistemas, las relaciones y dependencias de los elementos fsicos Describir cmo la funcionalidad del sistema es distribuida a travs de los nodos fsicos. Documentar la arquitectura propuesta, como documento de apoyo para el diseo y construccin de la solucin. Plantear varias alternativas de posibles arquitecturas a usar en el proyecto, indicar cundo comprar o reusar. Organizar la presentacin de la arquitectura propuesta, junto con informacin adicional del proyecto; para que el documento se valide en el comit de arquitectura. Identificacin de la pertinencia de la revisin de la arquitectura. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de la documentacin. Dar respuesta a los incidentes encontrados. Implementar cambios en la arquitectura actual, que permitan mejorar en algn aspecto la definicin del sistema bajo una perspectiva arquitectnica. Identificar los artefactos de referencia, para la implementacin de un requerimiento. Orientar al desarrollador en el proceso de contextualizacin y anlisis de informacin, antes de implementar los artefactos.

4.3.6 Coordinador de proyectos y mtricas Dar seguimiento al proyecto por medio de reuniones entre el PM y el PMO para validar los indicadores del proyecto y tomar acciones sobre el desempeo y avance del proyecto. Analizar los resultados de garantas reportadas por los clientes. Pasar toda la informacin del proyecto para el repositorio histrico del controlador de versiones.

99 4.3.7 Lder de Diseo Entregar Diseo para Implementacin, dar contexto del diseo al resto de los integrantes del equipo como Analistas, Arquitecto, Diseador, Desarrollador, Analista de Pruebas y Documentador. Preparacin de la presentacin del Diseo. Elaborar la presentacin y dems elementos que ayuden al entendimiento del diseo. Presentacin del diseo y su documentacin. Suministrar los artefactos de diseo a los interesados del equipo de desarrollo. Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas

durante la aplicacin proceso.

4.3.8 Diseador Inspeccionar la especificacin del requerimiento funcional por parte de un par, con el fin de encontrar posibles inconsistencias, ambigedades y temas incompletos. El objetivo es identificar las clases de diseo que satisfacen el comportamiento requerido. Adicionalmente, se debe determinar cules de esas clases de diseo se ajustan a la arquitectura lgica del sistema. Esta actividad se realiza en cada iteracin en la que hay nuevos requerimientos que deben ser analizados y diseados. Transformar los requerimientos en el diseo de lo que el sistema debe hacer. Adaptar el diseo segn el ambiente de implementacin y las restricciones de diseo y arquitectura definidas para el sistema. Evolucionar a una arquitectura ms robusta y detallada del sistema. Refinar las definiciones de los elementos de diseo. Refinar y actualizar las realizaciones de casos de uso basados en los nuevos elementos de diseo identificados. Disear las clases del sistema. Disear los subsistemas que componen el sistema.

100 Identificar y definir las responsabilidades, operaciones, atributos, y relaciones de los elementos del diseo. Identificar las clases persistentes en el diseo. Disear las estructuras apropiadas de bases de datos para almacenar las clases persistentes. Definir mecanismos y estrategias para almacenar y recuperar datos persistentes de manera que se cumplan los criterios de desempeo

establecidos para la aplicacin. Generar la estrategia de pruebas unitarias que permita cubrir la funcionalidad crtica de la aplicacin que se est diseando. Identificar componentes. Buscar agrupaciones y patrones. Inspeccionar el anlisis y diseo por parte de un par, con el fin de encontrar posibles inconsistencias, ambigedades y temas incompletos. Identificacin de la pertinencia de la revisin del anlisis y diseo. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de la documentacin. Dar respuesta a los incidentes encontrados. Identificar los artefactos de referencia, para la implementacin de un requerimiento. Orientar al desarrollador en el proceso de contextualizacin y anlisis de informacin, antes de implementar los artefactos definidos para el sistema.

4.3.9 Desarrollador Identificar qu libreras, componentes de trabajo que se pueden usar para la implementacin del proyecto. Identificar los artefactos de referencia, para la implementacin de un requerimiento. Orientar al desarrollador en el proceso de contextualizacin y anlisis de informacin, antes de implementar los artefactos definidos para el sistema

101 Entender la arquitectura del sistema, sus lineamientos, restricciones, sus componentes transversales y dems elementos que deben regir la

implementacin del sistema para su adecuado funcionamiento e integracin. Entender de manera global el comportamiento del subsistema, analizando el papel que los componentes a implementar juegan en el sistema y cmo interactan con los dems elementos analizados. Comprender el comportamiento del requerimiento a ser implementado, sus precondiciones, post condiciones, ruta bsica y las alternas definidas. Entender el modelado esttico y dinmico del caso de uso. Comprender los principales componentes de la solucin, sus estructuras y la interaccin entre los mismos. Implementar la solucin modelada en la fase de diseo, cumpliendo los lineamientos establecidos por la arquitectura y los requerimientos establecidos en la fase de anlisis del sistema Codificar el diseo del requerimiento, verificando que el comportamiento sea adecuado a la luz de las especificaciones; que se hayan seguido los lineamientos establecidos y los contratos definidos se cumplan a cabalidad. Ofrecer documentacin en el cdigo fuente para facilitar su lectura, comprensin y mantenimiento. Asegurar que un nico componente de la solucin produce una salida correcta para una entrada de datos especificada. Minimizar la aparicin de incidentes en etapas posteriores (aseguramiento de calidad) que pueden ser detectados desde una etapa temprana del ciclo de vida (construccin). Evaluar las condiciones bajo las cuales el requerimiento que se desea probar es completamente satisfactorio Inspeccionar las pruebas unitarias diseadas con base en los casos de prueba. Elaborar los artefactos que estarn encargados de realizar las pruebas unitarias sobre los componentes funcionales. Evaluar el correcto comportamiento de los componentes funcionales con base en la entrada de datos suministrada por la prueba.

102 Realizar los ajustes requeridos a los componentes funcionales con base en los resultados fallidos generados por la ejecucin de la prueba. Ejecutar pruebas funcionales. Inspeccionar la implementacin funcional por parte de un par, con el fin de encontrar posibles inconsistencias, ambigedades y temas incompletos. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de componentes o tems a evaluar. Dar respuesta a los incidentes encontrados. Describir los lineamientos para planear y ejecutar la integracin de elementos fsicos de la aplicacin, asegurando la estabilidad de la comunicacin de los subsistemas y un correcto control de versin del producto integrado. Identificar los elementos a integrar y el orden de sus dependencias en la implementacin. Detectar excepciones que puedan producirse en la integracin del subsistema, para asegurar estabilidad de la integracin. Generar los artefactos de software que componen el subsistema. Los errores detectados en la integracin se deben reportar para ser corregidos. Identificar los elementos a integrar y el orden de sus dependencias en la implementacin. Generar los artefactos de software que componen el sistema. Producir los artefactos requeridos para instalar y desinstalar el producto de una manera segura y simple, sin afectar otras aplicaciones o caractersticas del sistema. Revisar la arquitectura del sistema para referenciar los elementos fsicos y de estructuracin de la solucin, que deben regir la implementacin y despliegue del sistema integrado. Obtener todos los artefactos que sern incluidos en el producto para despliegue. Analizar los escenarios soportados para la instalacin de la aplicacin y determinar las condiciones para la generacin de los artefactos. Construir los artefactos de software que sern usados para instalar el producto

103 Documentar el proceso para instalar y desinstalar el producto, de una manera segura y simple. Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas

durante la aplicacin proceso.

4.3.10 Auditor Aseguramiento Calidad Programar aseguramiento de calidad segn lo definido en el plan de aseguramiento de calidad.

4.3.11 Comit arquitectura Verificar la arquitectura funcional y tcnica. Permite verificar las propuestas de arquitectura tcnica y funcional y su viabilidad, tomar la decisin de cul de las arquitecturas propuestas se ajusta adecuadamente al proyecto y cliente.

4.3.12 Coordinador de pruebas Definir alcance para la verificacin y validacin. prueba y los factores crticos a verificar y validar. Identificar Factores Crticos. Identificar la lista especfica de tareas, eventos y artefactos que sirven como motivadores durante la presente iteracin, examinar elementos claves como: matriz de riesgos, solicitudes de cambio, casos de uso, modelado UML, etc. Analizar resultados. Analizar los resultados de todas las actividades de Identificar los objetos de

validacin e identificar incidentes Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso.

104 Transferencia. Realizar transferencia al cliente de la solucin, a travs de

capacitaciones formales donde se explique el funcionamiento del sistema. Esto aplica siempre y cuando as se haya definido en el contrato.

4.3.13 Analista de Pruebas Adquirir un entendimiento inicial a los objetivos y el alcance de la presente iteracin. Adquirir informacin y retroalimentacin de los interesados en el proyecto acerca de los objetivos y el alcance de la prueba. Identificar claramente el foco de la prueba en la presente iteracin. Dejar claro los documentos que sern el resultado de las pruebas. Considerar la completitud de la estrategia en trmino de profundidad y contenido. Identificar los mecanismos potenciales para cubrir la estrategia de pruebas. Comunicar las decisiones realizadas acerca de los mecanismos de prueba. Identificar los requerimientos y la estrategia a seguir con respecto a los datos de pruebas. En caso de ser necesario solicitar datos al cliente para llevar a cabo las pruebas, ver procedimiento producto suministrado por el cliente. Definir los requerimientos de los ambientes de pruebas necesarios para soportar el esfuerzo de pruebas. Utilizar los artefactos de despliegue y el manual de administracin para instalar y configurar el producto y dejarlo apto para pruebas internas. Identificar incidentes en el manual y la configuracin por defecto de la solucin. Identificar si la construccin est estable y puede ser objeto de prueba. Validar que el producto ha sido implementado apropiadamente y que cumple con su tarea dentro del ambiente definido. Determinar la tcnica apropiada de implementacin de casos de prueba. Configurar las precondiciones del ambiente de pruebas. Para tener listo el ambiente en el estado correcto para iniciar Implementar uno o ms casos de prueba reutilizables

105 Validar la implementacin. Los errores detectados reportarlos. Instruir a los futuros usuarios de la aplicacin.

4.3.14 Encargado del Despliegue Planear logstica de despliegue. Planear el despliegue del producto al cliente. Revisar artefactos de despliegue. Revisar que la solucin est completa para despliegue. Planear despliegue. Generar estrategia para el despliegue. Ejecutar despliegue. Desplegar la solucin al cliente. Revisar despliegue. Asegurar la calidad del despliegue, pruebas funcionales.

4.3.15 Revisor de Requerimientos Preparacin de la revisin. ejecutar la revisin. Reunin de Revisin. Adquirir informacin y retroalimentacin del equipo de revisin. revisiones. Revisin par de la implementacin. Verificar con un revisor Par, la adecuada implementacin de los elementos de diseo. Reportar los incidentes detectados. Aprobacin. Dejar la constancia de las revisiones. Reportar los incidentes detectados. Dejar la constancia de las Recopilacin de la informacin necesaria para

106

4.4

Tercer Objetivo Especfico

Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa.

4.4.1 Repositorio de Carpetas para las Herramientas Se definir un directorio con una estructura estndar establecida para cada uno de los proyectos, dentro de un repositorio de administracin de la configuracin. Si es un proyecto o mdulo nuevo se crear un nuevo directorio en el repositorio. Si se trata de mantenimiento se utilizar el que ya exista para el proyecto en proceso.

Con el diseo y construccin del repositorio de informacin se obtiene una estructura global del mismo a partir de identificar las necesidades de cada una de las partes implicadas, permitiendo almacenar, recuperar y mantener la documentacin de las distintas reas involucradas en el proyecto y tener accesible y organizada la ltima versin de todos los documentos generados durante el proceso de desarrollo.

Se deben de establecer y controlar los permisos necesarios para el acceso y mantenimiento de dicha informacin para el equipo de trabajo y la gente involucrada en su elaboracin.

Este repositorio puede estar en el servidor central de proyectos y lo debe de crear el administrador de la configuracin al comenzar un nuevo proyecto en la fase de concepcin, a solicitud del administrador del proyecto, como parte de las actividades de arranque y puede refinarse en etapas posteriores segn las necesidades que surjan dentro del propio proceso de desarrollo.

107 El administrador del proyecto debe asegurarse que los miembros del equipo mantengan actualizados sus respectivos productos/documentos del proyecto en el repositorio de administracin de la configuracin del proyecto, dentro del subdirectorio que les corresponda y utilizando los estndares para la identificacin de los archivos y sus versiones.

El repositorio de trabajo debe ser creado por soporte bajo solicitud expresa del administrador de proyectos, y los documentos y archivos del proyecto se manejarn de forma centralizada en dicha librera, incluyendo el cdigo y libreras ejecutables.

La estructura del repositorio define la estructura de carpetas y archivos que van a contener toda la informacin relacionada al proyecto. Establecer la organizacin que tendr la documentacin en el repositorio a partir de la estructura de los diferentes niveles de carpetas que identifican cada una de las reas del proyecto, detallando los criterios que se siguen para agrupar la documentacin. Un ejemplo de estructura de carpetas que se puede utilizar es como la siguiente:

108

4.4.2 Herramientas Automatizadas para la Administracin de Proyectos El uso de herramientas automatizadas surge como una respuesta a las necesidades de las organizaciones por establecer en su funcionamiento las mejores prcticas generalmente aceptadas, pues proporcionan el beneficio de la experiencia de los procesos que soportan y el uso de software probado.

Un entorno de trabajo basado en la colaboracin y comunicacin ayuda a mejorar la productividad individual, grupal y organizacional, de tal manera que se reducen los tiempos de ciclo, se da una mayor accesibilidad a la informacin para la toma de decisiones.

Dentro de un contexto de administracin de proyectos, es necesario tener presente que una herramienta automatizada no solamente es software (para el registro de la informacin de los proyectos en materia del portafolio de proyectos, el pool de recursos y reporte del tiempo laborado), sino que tambin se hace imprescindible para la definicin de procedimientos y/o un modelo de operacin, que ayuda a planear, programar, controlar a las personas, recursos y costos necesarios para la oportuna conclusin de cada proyecto.

El mercado de la administracin de proyectos acoge muchas herramientas automatizadas hoy en da. Si bien es cierto esta proliferacin es positiva para poder tener una amplia gama de opciones, se deben de utilizar criterios para la eleccin de la ms apropiada para la organizacin segn el uso y funcin que ofrezcan y las necesidades que se requieran cubrir.

Se sugiere la utilizacin de una herramienta automatizada de anlisis de negocio y UML orientada a objetos para el desarrollo completo del ciclo de vida, que provea el lmite competitivo para el desarrollo de software, administracin de proyecto, administracin de requerimientos y anlisis de negocio.

109 Con respecto a las herramientas automatizadas de Administracin de Proyectos en lnea, se debe tomar en cuenta que, en los tiempos de hoy que se habla cada vez ms de Cloud Computing o Software as Services (SAS), podemos encontrar que el uso de sistemas de administracin de proyectos no se encuentra ajeno a esta nueva modalidad. Hay en el mercado numerosas soluciones bajo estas caractersticas y que al igual que sus antecesoras cumplen y superan las expectativas en cuanto a funcionalidad e informacin para la toma de decisiones.

Si ya se est identificado con el concepto de Cloud Computing es fcil comprender las ventajas en usar una herramienta de administracin de proyectos local (instaladas en equipos propios o individuales) versus una colgada en la nube que habilitan el software como un servicio.

Algunas de las ventajas ms importantes que se encuentran en este tipo de herramientas son: Mayor acceso: la posibilidad de acceder al software desde cualquier lugar

donde disponga de acceso a Internet. Centralizado: mayor visibilidad y oportunidad de colaboracin para todos los miembros del proyecto. De fcil instalacin: no tener la necesidad de instalar algo en su computador (no copias de seguridad, no volver a instalar y compatibilidad con la mayora de los sistemas operativo (Windows, Linux, Mac OS, etc.) Mejor soporte: mejor servicio de atencin al cliente (mediante chats en lnea o emails). Ms amigable: la tecnologa web nos brinda mejores interfaces, amigables y sencillas de utilizar.

110

4.5

Cuarto Objetivo Especfico

Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas.

Los instructivos o guas creadas para la utilizacin de la carpeta de plantillas planteadas fusionando las metodologas RUP y PMBOK (2008), se dividirn en dos reas, Gestin del Proyecto Desarrollo del Software

4.5.1 Gua para la Gestin del Proyecto Para la gestin del proyecto se ha elaborado una gua para cada una de las fases del ciclo de vida del proyecto desde el momento que la Oficina de Proyectos entra para la asignacin del personal al proyecto, tal cual se muestra en la Figura XX, que presenta como se mueve el flujo de informacin ntrelos diferentes procesos. Para lo cual tenemos:

Figura 19. Fases de la Administracin de Proyectos

111 4.5.1.1 Gua Gestin de la Oficina de Proyectos

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Salida Administrador del Proyecto (PM) Planificar, organizar, supervisar y controlar la ejecucin de los Proyectos de la compaa Este proceso aplica para todos los proyectos de desarrollo. Nuevos proyectos Asignacin de personal

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico
GESTIN OFICINA PROYECTOS

1. Asignar PM

2. Asignar personal

3. Reasignar recursos

5. Planear compras o adquisiciones

Planear
10. Gestionar personal

4. Contratar recursos

7. Consolidar informacin

Hacer
11. Informar estado proyectos

6. Seguimiento proyectos

8. Seguimiento compromisos

9. Controlar presupuesto

Verificar

12. Generar acciones

Actuar

Caracterizacin Planear
#
1

Actividad Asignar PM

Asignar Personal

Reasignar recursos

Descripcin Consultar hoja de recursos disponibles y asignar PM Project Manager para el proyecto, segn las competencias requeridas para el proyecto, verificar tabla de competencias. Asignacin de personal para la ejecucin del proyecto. El PMO revisa su tabla de manejo de recursos y procede con la asignacin, se deben verificar las competencias requeridas para el proyecto, verificar la tabla de competencias. El PMO tiene la potestad de acuerdo con la tabla de recursos que maneja, reasignar recursos entre proyectos que tengan los siguientes criterios: Fecha de finalizacin de proyecto prximo a concluir Competencias de los recursos Si el perfil necesario est en cabeza de unos pocos recursos, se hace necesaria una capacitacin para no depender del conocimiento de estos pocos recursos. Gestionar las compras de software, hardware necesario para la ejecucin del proyecto cuando as lo amerite.

Responsable PMO

Salida Email notificacin asignacin PM Tabla de Competencias Tabla de recursos actualizada Tabla de Competencias

PMO

PMO

Tabla de recursos actualizada

Planificar compras o adquisiciones

PMO

112

Hacer
# Actividad Descripcin El PMO tiene la potestad de contratar nuevos recursos, con la aprobacin de la Gerencia General, para que cumpla con las fechas y los perfiles necesarios del proyecto. Recursos Humanos apoya con la consecucin de hojas de vida y el PMO se encarga de realizar la entrevista y seleccionar el candidato que ms se ajuste al perfil. Consolidar toda la informacin recopilada en el seguimiento a los proyectos, fechas de inicio, finalizacin, avance, riesgos, entre otros Administrar el recurso humano asignado al proyecto, gestionar incapacidades (informar a Recursos Humanos para liquidacin), vacaciones (solicitud al PM, PM evala viabilidad, PMO aprueba, PMO enva a Recursos Humanos la aprobacin para liquidacin), necesidades de formacin (se identifican en reuniones de seguimiento del proyecto, o el personal hace la solicitud por correo y el PMO se encarga de gestionar con el rea de capacitaciones la formacin, ya sea interna o externa). Responsable Salida

Contratar recursos

PMO

Tabla de recursos actualizada

Consolidar informacin

Coordinador proyectos mtricas

Seguimiento general proyectos

10

Gestionar personal

PM PMO

Verificar
6

Seguimiento proyectos

Planeacin y ejecucin de reuniones peridicas con los Gerentes de proyectos para conocer el estado de todos los proyectos de la compaa, riesgos generales, necesidades de personal, necesidades de formacin u otro elemento. Realizar seguimiento a los compromisos establecidos en las reuniones de seguimiento

Seguimiento compromisos Controlar presupuesto Informar estado proyectos

PMO PM Coordinador proyectos mtricas PMO Coordinador proyectos mtricas PMO

Seguimiento proyectos

Seguimiento general proyectos Control presupuesto proyectos Informe proyectos estado

Controlar el presupuesto de costos del proyecto Generar el informe de estado de todos los proyectos, escalar situaciones que requieren solucin o decisiones por parte del Director de Servicios de Ingeniera, si no es posible solucionarlas, escalarlas al comit de Gerencia para solucin.

11

PMO

Actuar
Generar acciones Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Lecciones aprendidas Acciones Correctivas, Preventivas y de mejora

12

PMO

113

4.5.1.2 Gua Inicio de la Gestin del Proyecto

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Salida Vendedor, Oficina de Administracin de Proyectos (PMO) Autorizar formalmente el inicio del proyecto Este proceso aplica para todos los procesos de desarrollo Solicitud de Cotizacin Propuesta tcnica y comercial Contrato Carta de declinacin del proyecto

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# 1 Actividad Analizar Viabilidad Descripcin Si se decide participar de una oferta comercial, se debe continuar con el siguiente paso, en caso contrario se declina participacin. Responsable Vendedor Salida Carta declinando participacin

Hacer
# Actividad Descripcin Elaborar propuesta comercial para el cliente, si se requiere apoyo para su elaboracin solicitar al PMO los recursos necesarios. Identificar los requerimientos y necesidades del cliente. Delimitar el alcance del proyecto. Para ello se identifican todas las entidades externas con las cuales interacta el sistema. Identifican los casos de uso crticos y su descripcin. Responsable Salida

Elaborar Propuesta

PMO, Vendedor

Propuesta tcnica comercial

114
Adquirir los requerimientos por parte de los distintos usuarios y consolidar una visin nica de los objetivos y alcances. Estimar el tiempo y costo que se requiere para el desarrollo del proyecto. Para la estimacin se utiliza la tcnica de estimacin basada en la experiencia de los desarrolladores expertos. Para estimar costo tener en cuenta el nmero de recursos, cargos y disponibilidad requerida durante el tiempo de vida del proyecto. Identificar riesgos iniciales del proyecto y tenerlos en cuenta en la estimacin de tiempo y costo del proyecto. Ver procedimiento Gestin de riesgos. Si despus del anlisis se identifica que el proyecto es riesgoso, se enva carta al cliente declinando participacin. Presentar y sustentar la propuesta tcnica y comercial al cliente. Incluyendo el criterio de aceptacin, evaluacin de riesgos, estimacin de los recursos necesarios y un plan de fases mostrando fechas de los principales hitos del proyecto. Esta actividad slo se hace, cuando el proceso de contratacin con el cliente as lo solicite. En caso de que la propuesta haya sido adjudicada, se debe gestionar con el cliente uno de los siguientes documentos que formalicen la aceptacin: Contrato, Oferta mercantil u Orden de servicio.

Estimar duracin

PMO, Vendedor

Estimacin de tiempo de cada uno de los puntos de la propuesta

Identificar Riesgos

PMO, Vendedor

Plan de Riesgos Carta declinando participacin

Presentar propuesta

Vendedor

Adjudicar propuesta

Vendedor

Contrato u Oferta mercantil u Orden de servicio

Verificar
Email solicitud aprobacin propuesta tcnica y comercial Email observaciones propuesta tcnica y comercial Email aprobacin propuesta tcnica y comercial Carta declinando participacin Orden de inicio Propuesta tcnica y comercial Plan de riesgos Presentacin kickoff interno (opcional)

Aprobacin interna

Solicitar aprobacin interna al Gerente de Consultora y al PMO de la propuesta tcnica y comercial que se va a enviar al cliente. El Gerente de Consultora y el PMO se renen validan la propuesta tcnica y comercial, en caso de que existan observaciones se las comunican va email al Vendedor, en caso contrario envan un email de aprobacin. El Gerente de Consultora y el PMO pueden detectar que no es viable la realizacin del proyecto, le comunican al Vendedor y se enva carta al cliente declinando su participacin.

Vendedor

Ordenar inicio

Realizar un kickoff interno para entregar al PMO y al PM la orden de inicio, propuesta tcnica y comercial, riesgos y todos los elementos necesarios que apoyen el desarrollo de la elaboracin.

Vendedor PMO PM Coordinador de proyectos

Actuar
Generar acciones Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Lecciones aprendidas. Acciones Correctivas, preventivas y de mejora.

Vendedor

115 4.5.1.3 Gua Planificacin de la Gestin del Proyecto

DATOS GENERALES DEL PROYECTO Responsable Objetivo Administrador Proyecto (PM), Oficina de Administracin de Proyectos (PMO) Planear y gestionar con xito un proyecto de software, a travs de la gestin de alcance. Describir qu debera hacer el sistema y permitir que los desarrolladores y el cliente se pongan de acuerdo en esa descripcin. Este proceso aplica para todos los proyectos de desarrollo. Propuesta tcnica y comercial Orden de Inicio Contrato u Oferta mercantil u Orden de servicio Plan de riesgos Plan de Desarrollo de Software Plan de Iteraciones Plan de Administracin de Requisitos Plan de Administracin de Configuracin Plan de Pruebas Plan de Riesgos WBS Proyecto Acta de Entrega

Alcance Entradas

Salida

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico
PLANIFICACIN

1. Planear proyecto

7. Planear siguiente iteracin

Planear

2. Evaluar riesgos

3. Solicitar creacin ambiente

4. Definir WBS

5. Definir criterios de aceptacin

Hacer

6. Kickoff interno/externo

Verificar

8. Generar acciones

Actuar

Caracterizacin Planear
# 1 Actividad Descripcin Responsable Elaborar todos los documentos necesarios para planear el Planear proyecto proyecto entre ellos: plan de desarrollo de software, plan PM de administracin de requisitos, plan de administracin de Salida Plan de Desarrollo de Software

116
configuracin, plan de pruebas, plan de riesgos. Elaborar la lista de chequeo de proyectos donde se define cules son los tems que se van a desarrollar y que aplican segn el tipo de proyecto. Solicitar aprobacin del cliente. Si el cliente suministra informacin para la elaboracin del proyecto se considera producto suministrado por el cliente. Si el proyecto requiere que se hagan compras o adquisiciones y estn dentro del alcance, aplicar lo definido en el proceso Gestin Compras y Logstica. 7 Planear siguiente iteracin Planear la siguiente iteracin PM Plan de Administracin de requisitos. Plan CM Plan de riesgos Check list ciclo vida proyectos

Hacer
#
2

Actividad Evaluar riesgos Solicitar creacin ambiente

Definir WBS

4.1

Secuenciamient o actividades

4.2

Estimar duracin

4.3

Revisin interna

Definir criterios de aceptacin

Descripcin Evaluar riesgos que puedan presentarse en el proyecto, cuantificarlos y establecer un mtodo de control y mitigacin. Ver procedimiento Gestin de riesgos Solicitar creacin de estructura en repositorios: utilizando la herramienta que utilice la empresa para tal razn. Definir WBS o lista de entregables y actividades que deben ejecutarse en el proyecto. Definir cules son los entregables que se generarn en el proyecto y que aplican segn el alcance definido con el cliente. Establecer la secuencia de actividades segn el plan de iteraciones y entregables definidos con el cliente. Identificar cules actividades se pueden realizar en paralelo y cules tienen dependencia. Estimar la duracin para cada una de las actividades, teniendo en cuenta los modelos de estimacin puntos de caso de uso, lneas de cdigo y experiencia. El PM se reunir con el equipo de trabajo para validar las actividades, el secuenciamiento y la duracin asignada a cada actividad, con el fin de determinar si son adecuados para el proyecto. En caso de ser necesario realizar ajustes, se aplicarn directamente sobre el cronograma. Definir criterios de aceptacin con el cliente para cada una de las iteraciones o fases del proyecto

Responsable PM PM

Salida Plan de Riesgos

PM

Cronograma Proyecto Lista de Revisin Ciclo Vida Proyecto Cronograma del Proyecto Cronograma del Proyecto

PM

PM

PM

Cronograma del Proyecto Criterios de aceptacin

PM

Verificar
Realizar kickoff interno con el objetivo de conocer el alcance del proyecto, canales de comunicacin, competencias necesarias, revisar las lecciones aprendidas en otros proyectos, presentar el plan de desarrollo, plan de riesgos, metodologa de trabajo, fecha de inicio y finalizacin y otro tema que sea necesario desarrollar. Realizar kickoff externo con el objetivo de conocer: alcance del proyecto, canales de comunicacin, plan de desarrollo, plan de riesgos, equipo de trabajo, metodologa de trabajo, fecha de inicio y finalizacin y otro tema que sea necesario desarrollar. Realizar entrega formal de todos los elementos de la planeacin al cliente. Vendedor PMO Presentacin PM kickoff interno Diseador/Analista/ (opcional) Probador/Diseador Vendedor PMO PM Diseador/Analista/ Probador/Diseador

Kickoff interno

6.1

Kickoff externo

Presentacin kickoff externo (opcional) Acta de entrega

Actuar
Generar acciones Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. PM Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Lecciones aprendidas Acciones Correctivas, preventivas y de mejora

117 4.5.1.4 Gua Ejecucin de la Gestin del Proyecto

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Salida Administrador Proyecto (PM), Oficina de Administracin de Proyectos (PMO) Gestionar el cumplimiento de todas las actividades definidas en la planeacin de proyectos Este proceso aplica para todos los proyectos de desarrollo. Proyecto elaborado Ejecucin del proyecto

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# Actividad Gestionar cronograma Descripcin Reportar tiempos invertidos en cada una de las actividades del cronograma. Ajustar tiempos de actividades de acuerdo con el desarrollo que se va presentando segn el comportamiento del proyecto Responsable PM Analistas Diseador/Probador/ Desarrollador Salida Cronograma del Proyecto

Hacer
#
2

Actividad

Descripcin Aprobar o rechazar reporte de tiempos invertidos por personas involucradas en el proyecto. Realizar seguimiento y control a los riesgos identificados en el proyecto, en el caso de que surjan nuevos riesgos, Gestionar riesgos reportarlos y gestionarlos. Ver procedimiento Gestin de riesgos Gestionar Gestionar la generacin de facturas correspondientes al facturacin proyecto, en los puntos de corte o segn lo convenido en Gestionar avance

Responsable PM

Salida Cronograma Proyecto Plan de riesgos

PM

PMO

Factura

118
la negociacin con el cliente.

Verificar
5 Asegurar calidad Programar aseguramiento de calidad segn lo definido Auditor Aseguramiento en el plan de aseguramiento de calidad. Ver proceso Calidad Aseguramiento de Calidad

Actuar
Generar acciones correctivas, preventivas y de mejora PM como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante Generar acciones la aplicacin proceso. Lecciones aprendidas Acciones Correctivas, preventivas y de mejora.

119

4.5.1.5 Gua Control de la Gestin del Proyecto

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Administrador Proyecto (PM), Oficina de Administracin de Proyectos (PMO) Monitorear y controlar el proyecto con el objeto de identificar problemas oportunamente y adoptar las acciones necesarias en el momento indicado. Este proceso aplica para todos los proyectos de desarrollo. Cronograma del proyecto Contrato u Oferta mercantil u Orden de servicio Plan de Desarrollo de Software Plan de iteraciones Plan de administracin de requisitos Plan de administracin de configuracin Plan de aseguramiento de calidad Plan de pruebas Plan de riesgos Control proyecto interno y externo

Salida

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
#
1

Actividad Gestionar alcance

Descripcin Responsable Gestionar el cumplimiento del alcance definido en la negociacin comercial con el cliente. PM Cuando se presenten variaciones por solicitud interna Vendedor implica aprobacin del PM.

Salida Cronograma Proyecto Solicitud cambio anlisis interno

120
Cuando se presenten variaciones por solicitud del cliente implica control de cambios, registrarlos y realizar la gestin con el GDN para su negociacin. Ver procedimiento administracin de cambios Solicitud cambio cliente

Hacer
# 2 Actividad Controlar cronograma Descripcin Llevar control de indicadores de progreso del proyecto Responsable PM Salida Cronograma Proyecto

Administrar el talento humano asignado al proyecto, gestionar incapacidades (informar a talento humano para liquidacin), vacaciones (solicitud al PM, PM evala viabilidad, PMO aprueba, PMO enva a talento humano la Gestionar aprobacin para liquidacin), necesidades de formacin (se personal identifican en reuniones de seguimiento del proyecto, o el personal hace la solicitud por correo y el PMO se encarga de gestionar con el rea de capacitaciones la formacin, ya sea interna o externa). Realizar seguimiento y control a los riesgos identificados en Gestionar el proyecto, en el caso de que surjan nuevos riesgos, riesgos reportarlos y gestionarlos. Ver procedimiento Gestin de Riesgos. Semanalmente generar el informe de estado del proyecto Informar estado que contempla: avance, variacin esfuerzo, variacin proyecto duracin, pendientes, recursos y controles de cambio. Segn la periodicidad definida con el cliente, presentar informes de avance del proyecto el cual contiene un detalle Informar avance de actividades realizadas durante el perodo, avance al cliente cronograma, riesgos materializados, control de cambios, pendientes y plan de trabajo siguiente perodo.

PM PMO

Solicitud de vacaciones Necesidad de capacitacin

PM

Plan de riesgos Seguimiento proyectos Mtricas

PM

PM

Informe de avance

Verificar
# Actividad Descripcin Responsable Salida Cronograma Proyecto Lecciones aprendidas Plan de riesgos Necesidades de capacitacin Check list Ciclo de vida proyectos Cronograma Project Seguimiento proyectos Acta de reunin

Seguimiento interno

Peridicamente realizar reuniones de seguimiento con el equipo de trabajo con el fin de identificar el estado del PM proyecto, dificultades presentadas, acciones tomadas, Equipo de riesgos materializados, necesidades de formacin, estado proyecto del check list de ciclo de vida de proyectos (generacin de tems definidos en la planeacin), etc. PMO Reuniones entre el PM y el PMO para validar los PM indicadores del proyecto y tomar acciones sobre el Coordinador desempeo y avance del proyecto proyectos Reuniones de seguimiento entre el cliente y el PM, evaluar el informe de avance presentado. Verificar el estado del PM proyecto y los avances obtenidos.

Seguimiento proyecto Seguimiento cliente

Actuar
# Actividad Descripcin Responsable Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. PM Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Salida Lecciones aprendidas Acciones Correctivas, preventivas y de mejora

10

Generar acciones

121

4.5.1.6 Gua Cierre de la Gestin del Proyecto

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Administrador Proyecto (PM) Finalizar formalmente todas las actividades contempladas en el alcance del proyecto y entregar el producto terminado al cliente. Este proceso aplica para todos los proyectos de desarrollo. Control proyecto interno / externo Contrato u Oferta mercantil u Orden de servicio Acta de entrega y cierre del proyecto Criterios de aceptacin Instalador Formato ejecucin casos de prueba Manual instalacin Manual usuario

Salida

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# Actividad Descripcin Responsable Programar y formalizar la entrega de la solucin al cliente. Si el cliente lo solicita, entregar los casos de prueba diseados en el proceso de pruebas. Validar los criterios de aceptacin. Actualizar cronograma con el avance al 100% de PM actividades completadas. Entregar todos los productos suministrados por el cliente para el desarrollo del proyecto. Ver procedimiento manejar propiedad del cliente. Salida

Entregar producto al cliente

Criterios de aceptacin Casos de prueba

122
Realizar transferencia al cliente de la solucin, a travs de capacitaciones formales donde se explique el Analista de pruebas funcionamiento del sistema. Esto aplica siempre y cuando as se haya definido en el contrato. Reunin de entrega con el cliente. Hacer entrega de los medios fsicos que contienen la PM solucin y la documentacin exigida. Control de asistencia a entrenamiento personal Instalador Manual instalacin Manual usuario

1.1

Transferencia

1.2

Reunin de entrega

Hacer
# 2 Actividad Cierre proyecto Repositorio histrico Descripcin Llevar a cabo el cierre del contrato, entregar todos los elementos que fueron contemplados en el contrato, informes, manuales, fuentes, etc. Verificar que todo lo pactado se haya cumplido Pasar toda la informacin del proyecto para el repositorio histrico del controlador de versiones Responsable PM Cliente CM Salida

Verificar
# 3 Actividad Descripcin Generar acta de entrega al cliente, estableciendo el perodo Garanta de garanta, que debe corresponder con la misma definida proyecto en el contrato Registrar las fechas de inicio y finalizacin de garanta con Control garanta el objetivo de aplicar nicamente la garanta a aquellos proyectos que an la tienen vigente. El analista encargado deber atender la garanta en los plazos establecidos en el formato garanta de proyectos. Atender garanta Realizar control de versiones al software. Ver procedimiento CM Analizar los resultados de garantas reportadas por los Estadsticas clientes Responsable PM Salida Acta de entrega Formato control garanta

3.1

PM

3.2

PM Coordinador de proyectos

Estadsticas

Actuar
# Actividad Descripcin Responsable Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la PM aplicacin proceso. Salida Lecciones aprendidas Acciones Correctivas, preventivas y de mejora

Generar acciones

123

4.5.2 Guas para el Desarrollo del Software Para la gestin del desarrollo del software se ha elaborado una gua para cada una de las fases del ciclo de vida del desarrollo del proyecto. Para lo cual tenemos:

4.5.2.1 Gua Requisitos del Desarrollo del Software

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Salida Administrador del Proyecto Desarrollar el modelo de sistema que se va a construir a partir de la correcta extraccin de requerimientos del nuevo desarrollo de software Este proceso aplica para todos los proyectos de desarrollo Lista de necesidades del cliente Especificacin de Requerimientos

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# Actividad Descripcin Entender el alcance y la definicin del problema que se va a resolver con el sistema. Determinar los stakeholders relevantes. Responsable Salida Modelo del negocio Modelo de Sistema Documento Visin Glosario

Entender el problema

Analista Sistemas

124
Modelo del negocio Modelo de Sistema Documento Visin

1.1.

Entender el dominio (Negocio) Formular el problema Capturar un vocabulario comn Identificar los Stakeholders

Obtener el contexto suficiente del negocio para entender el problema Describir el problema que se est tratando de resolver con el sistema Definir un vocabulario comn que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los casos de uso Obtener la lista de los usuarios potenciales, tomadores de decisiones y dems interesados en el proyecto. Determinar qu debe hacer el sistema. Definir los lmites del sistema. Identificar las necesidades y caractersticas del sistema. Identificar los requerimientos funcionales y no funcionales del sistema. Trazabilidad entre necesidades, caractersticas y requerimientos. Establecer los requerimientos de alto nivel del sistema Definir quin y/o qu interactuar con el Sistema Esbozar la funcionalidad del Sistema, lo que el Sistema deber hacer Tener una idea y generar un primer acuerdo del comportamiento esperado del sistema en relacin al requerimientos Completar los requerimientos con aquellos no evidentes desde el punto de vista funcional Manejar las dependencias entre los requerimientos Priorizan los requerimientos funcionales de acuerdo con la relevancia para la arquitectura y el negocio. Identificar el conjunto de escenarios y requerimientos que representan aspectos importantes en la definicin de la arquitectura, para luego priorizar su orden de implementacin de acuerdo con su complejidad tcnica y el impacto en las dems actividades del proyecto. Visualizar en la arquitectura los casos de uso ms importantes para la arquitectura Identificar riesgos asociados a la definicin de requerimientos, identificar acciones para mitigarlos

Analista Sistemas

1.2.

Analista Sistemas

1.3.

Analista Sistemas

Glosario

1.4.

Analista Sistemas

Documento Visin Documento Visin Atributos de los requerimientos Glosario Especificacin de Requerimientos de Software Lista de requerimientos de alto nivel Lista de actores Lista de requerimientos

Definir y delimitar el sistema

Analista Sistemas

2.1. 2.2. 2.3. 2.4.

Acordar las Caractersticas de la solucin Encontrar actores Encontrar Requerimientos Describir el flujo de eventos Reunir requerimientos adicionales Manejar Dependencias de Requerimientos Priorizar los Requerimientos Priorizar requerimientos arquitectnicos Documentar la vista de casos de uso Identificar riesgos

Analista Sistemas Analista Sistemas Analista Sistemas Analista Sistemas

2.5.

Analista Sistemas

Lista de requerimientos Lista de requerimientos

2.6. 3

Analista Sistemas Analista Sistemas

3.1.

Analista Sistemas

3.2. 3.3

Analista Sistemas Analista Sistemas

Diagrama de casos de uso Plan de riesgos

Hacer
# 4 Actividad Definicin de requerimientos Determinar las fuentes de los requerimientos Recopilar la Informacin Reunin de extraccin datos Especificar Requerimientos Descripcin Recolectar los requerimientos de los stakeholders de lo que el sistema debe hacer. Obtener detalle adicional de los requerimientos como insumo para la especificacin. Identificacin de las fuentes adecuadas de informacin para los requerimientos o el conjunto de requerimientos en cuestin. Formular qu preguntas deben ser resueltas a travs de la recopilacin de informacin. Identificar las necesidades, priorizar la informacin y clarificar dudas directamente de los stakeholders. Los requerimientos son especificados a un nivel de detalle necesario para que los diseadores, personal de pruebas, documentadores y dems miembros del equipo del proyecto puedan continuar con el desarrollo del mismo. Responsable Analista Sistemas Salida Acta reunin de extraccin de requerimientos

4.1 4.2 4.3

Analista Sistemas Analista Sistemas Analista Sistemas Acta de reunin

Analista Sistemas

125
Especificar requerimientos funcionales Especificar requerimientos suplementarios Detallar caso de uso y/o sentencia Requerimiento funcional especificado Requerimientos no funcionales(opcion al) Especificacin Casos Uso

5.1

Detallar la informacin del requerimientos Detallar la informacin no funcional que debe ser incluida en el desarrollo de la solucin. Describir el flujo de sucesos en detalle incluyendo cmo comienza, termina e interactan los actores

Analista Sistemas

5.2 5.3

Analista Sistemas Analista Sistemas

Verificar
# Actividad Verificar Requerimiento Descripcin Inspeccionar la especificacin del requerimiento funcional por parte de un par, con el fin de encontrar posibles inconsistencias, ambigedades y temas incompletos Identificacin de la pertinencia de la revisin de los requerimientos. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de la documentacin. Recopilacin de la informacin necesaria para ejecutar la revisin Adquirir informacin y retroalimentacin del equipo de revisin. Reportar los incidentes detectados Dar respuesta a los incidentes encontrados Responsable Analista Diseador Salida Lista de chequeo requerimiento Matriz Trazabilidad Requerimientos Email solicitud revisin par

6.1

Informar el inters en la revisin Preparacin de la revisin Reunin de Revisin Ajustar especificacin segn revisin par Aprobacin Aprobar Requerimientos por Parte del Cliente Preparacin de la documentacin del requerimiento Entrega del requerimiento Ajustar especificacin segn revisin cliente. Aprobacin

Analista Sistemas

6.2 6.3

Revisor Par Revisor Par

6.4

Analista Sistemas Email retroalimentacin revisin par Observaciones a la especificacin de requerimiento Acta de entrega

6.5

Dejar la constancia de las revisiones

Analista Sistemas

Aprobar el requerimiento funcional especificado

Analista Sistemas

7.1 7.2

Convertir la documentacin del requerimiento segn los estndares del cliente, en caso de ser requerido. Hacer entrega formal del requerimiento al cliente

Analista Sistemas Analista Sistemas Acta de entrega

7.3 7.4

Ajustar la especificacin del requerimiento Dejar la constancia de las revisiones

Analista Sistemas Analista Sistemas Acta de reunin

Actuar
# Actividad Descripcin Responsable Salida Control de asistencia a entrenamiento personal Evaluacin de entrenamiento personal Evaluacin de instructores Presentacin requerimiento

Entregar Requerimiento

Dar contexto del requerimiento al resto de los integrantes del equipo como Arquitecto, Diseador de Solucin, Ingeniero de Desarrollo, Ingeniero de Pruebas y Documentador.

Analista Sistemas

8.1

8.2

Preparacin de la presentacin del requerimiento Presentacin del requerimiento y su documentacin.

Elaborar la presentacin y dems elementos que ayuden al entendimiento del requerimiento Suministrar los artefactos de anlisis a los interesados del equipo de desarrollo Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso.

Analista Sistemas

Analista Sistemas Lecciones aprendidas Acciones Correctivas, preventivas .

Generar acciones

PM Analista Diseador

126

4.5.2.2 Gua Anlisis y Diseo del Desarrollo del Software

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Salida Administrador del Proyecto Definir una arquitectura funcional y tcnica apropiada para el proyecto, al igual que el anlisis y el diseo del software a desarrollar. Este proceso aplica para todos los proyectos de desarrollo. Modelo de casos de uso Diseo

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# 1 1.1 Actividad Especificar la arquitectura candidata Establecer las metas y restricciones tcnicas del proyecto Identificar mecanismos de diseo Estructurar el modelo de implementacin Describir la distribucin de la solucin Elaborar el Descripcin Definir la arquitectura y sus restricciones del sistema. Establecer un conjunto de medidas, objetivos y restricciones que definen directrices para el diseo y construccin de la solucin. Determinar la manera en que la aplicacin debe ser construida, basndose en modelos de diseo que soporten cumplir con las metas y restricciones propuestas. Establecer la estructura de implementacin de la solucin, identificando los subsistemas, las relaciones y dependencias de los elementos fsicos Describir cmo la funcionalidad del distribuida a travs de los nodos fsicos. sistema es Responsable Arquitecto Arquitecto Salida Arquitectura de Software

1.2

Arquitecto

1.3

Arquitecto

1.4 1.5

Arquitecto Arquitecto Arquitectura de

Documentar la arquitectura propuesta, como documento

127
documento de arquitectura Planear presentacin de la arquitectura de apoyo para el diseo y construccin de la solucin. Plantear varias alternativas de posibles arquitecturas a usar en el proyecto, indicar cundo comprar o reusar. Organizar la presentacin de la arquitectura propuesta, junto con informacin adicional del proyecto; para que el documento se valide en el comit de arquitectura. Software

1.6

Arquitecto

Hacer
# Actividad Descripcin Responsable Salida Paquete de diseo Diagrama de secuencia Diagrama de clases Diagrama de actividades Diagrama de estados

Anlisis y diseo

El objetivo es identificar las clases de diseo que satisfacen el comportamiento requerido. Adicionalmente, se debe determinar cules de esas clases de diseo se ajustan a la arquitectura lgica del sistema. Esta actividad se realiza en cada iteracin en la que hay nuevos requisitos que deben ser analizados y diseados

Diseador

3.1

Afinar arquitectura del sistema

3.1

Analizar requisito y disear solucin

3.2

Requerimientos de interfaces Disear las interfaces de usuario Flujo de navegacin

3.3

3.4

3.5

Usabilidad

Disear componentes Refinar caso de uso y/o sentencia Diseo de clases Diseo de subsistemas

Implementar cambios en la arquitectura actual, que permitan mejorar en algn aspecto la definicin del sistema bajo una perspectiva arquitectnica Transformar los requisitos en el diseo de lo que el sistema debe hacer. Adaptar el diseo segn el ambiente de implementacin y las restricciones de diseo y arquitectura definidas para el sistema. Evolucionar a una arquitectura ms robusta y detallada del sistema Elaborar documento que especifique los requerimientos para el uso de interfaces propias y con otros sistemas Disear la Interfaz de Usuario: segn los lineamientos grficos y de usabilidad dados por el cliente o si no fueron determinados realizar una propuesta. Construir el prototipo de interfaz de usuario que le permita al usuario llevar a cabo los casos de uso de manera eficiente. Definir flujo de navegacin del proyecto, teniendo en cuenta el modelo de casos de uso y los requisitos definidos por el cliente Elaborar documento que especifique que parmetros se deben tener en cuenta en el diseo para que la interfaz sea usable Refinar las definiciones de los elementos de diseo. Refinar y actualizar las realizaciones de casos de uso basados en los nuevos elementos de diseo identificados Disear las realizaciones de los casos de uso Disear las clases del sistema Disear los subsistemas que componen el sistema Identificar y definir las responsabilidades, operaciones, atributos, y relaciones de los elementos del diseo Identificar las clases persistentes en el diseo. Disear las estructuras apropiadas de bases de datos para almacenar las clases persistentes. Definir mecanismos y estrategias para almacenar y recuperar datos persistentes de manera que se cumplan los criterios de desempeo establecidos para la aplicacin, Generar la estrategia de pruebas unitarias que permita cubrir la funcionalidad crtica de la aplicacin que se est diseando. Identificar componentes. Buscar agrupaciones y patrones

Arquitecto

Diseador

Diseo de subsistemas

Analista

Documento requerimiento de interfaces Prototipo (opcional) Flujo de navegacin Lista de chequeo usabilidad Paquete de diseo (refinado) Especificacin Casos Uso (refinados) Paquete de diseo Diagrama de clases Vista de componentes

Analista

Analista

Analista

Diseador

4.1 4.2

Analista Diseador

4.3

Diseador

4.4

Disear base de datos

Diseador

Paquete de diseo (refinado) Modelo de datos

4.5

Disear pruebas unitarias

Diseador

Diseo de pruebas unitarias

128
Verificar
# 2 Actividad Verificar la arquitectura funcional y tcnica. Descripcin Permite verificar las propuestas de arquitectura tcnica y funcional y su viabilidad, tomar la decisin de cul de las arquitecturas propuestas se ajusta adecuadamente al proyecto y cliente. Identificacin de la pertinencia de la revisin de la arquitectura. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de la documentacin. Recopilacin de la informacin necesaria para ejecutar la revisin Adquirir informacin y retroalimentacin del equipo de revisin. Reportar los incidentes detectados. Dar respuesta a los incidentes encontrados Responsable Comit arquitectura Salida Acta del comit de arquitectura

2.1

Informar el inters en la revisin Preparacin de la revisin Reunin de Revisin Ajustar a la arquitectura tcnica y funcional Aprobacin

Arquitecto

Email solicitud revisin par

2.2 2.3 2.4

Revisor par Revisor par Arquitecto Email retroalimentaci n revisin par Lista de chequeo diseo Matriz Trazabilidad Requisitos Email solicitud revisin par Lista de chequeo diseo

2.5

Dejar la constancia de las revisiones

Revisor par

Verificar Anlisis y Diseo

Inspeccionar el anlisis y diseo por parte de un par, con el fin de encontrar posibles inconsistencias, ambigedades y temas incompletos Identificacin de la pertinencia de la revisin del anlisis y diseo. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de la documentacin. Recopilacin de la informacin necesaria para ejecutar la revisin Adquirir informacin y retroalimentacin del equipo de revisin. Reportar los incidentes detectados. Dar respuesta a los incidentes encontrados

Diseador

5.1

Informar el inters en la revisin Preparacin de la revisin Reunin de Revisin Ajustar especificacin segn revisin par Aprobacin Aprobar anlisis y diseo por Parte del Cliente

Diseador

5.2 5.3

Revisor par Revisor par

5.4

Diseador Email retroalimentaci n revisin par Acta de entrega

5.5

Dejar la constancia de las revisiones

Revisor par

Aprobar el anlisis y diseo

PM

Actuar
# 7 Actividad Entrega del anlisis y diseo Descripcin Hacer entrega formal del anlisis y diseo al cliente y evaluar los criterios de aceptacin de la etapa Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Responsable PM PM Diseador Analista Sistemas Arquitecto Salida Acta de entrega Criterios aceptacin Lecciones aprendidas Acciones Correctivas, preventivas y de mejora

Generar acciones

129

4.5.2.3 Gua Implementacin del Desarrollo del Software

DATOS GENERALES DEL PROYECTO Responsable Objetivo Administrador de Proyectos Implementar el producto de acuerdo con los elementos de anlisis y diseo elaborados. Integrar los diferentes componentes para obtener un producto final. Asegurar que el producto integrado funcione correctamente. Este proceso aplica para todos los proyectos de desarrollo. Modelo de anlisis Modelo de diseo Solucin implementada

Alcance Entradas Salida

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# 1 Actividad Entregar Diseo para Implementacin Preparacin de la presentacin del Diseo. Presentacin del diseo y su documentacin. Estructurar modelo de Descripcin Dar contexto del diseo al resto de los integrantes del equipo como Analistas, Arquitecto, Ingeniero de Desarrollo, Ingeniero de Pruebas y Documentador. Elaborar la presentacin y dems elementos que ayuden al entendimiento del diseo. Responsable PM Arquitecto Diseador (responsable) PM Arquitecto Diseador (responsable) PM Arquitecto Diseador (responsable) Desarrollador Salida Acta de entrega

1.1

Presentacin diseo

1.2

Suministrar los artefactos de diseo a los interesados del equipo de desarrollo. Identificar qu libreras, componentes de trabajo se pueden usar para la implementacin del proyecto.

Inventario de componentes

130
implementacin Analizar artefactos para implementacin Identificar los artefactos de referencia, para la implementacin de un requisito. Orientar al desarrollador en el proceso de contextualizacin y anlisis de informacin, antes de implementar los artefactos definidos para el sistema Entender la arquitectura del sistema, sus lineamientos, restricciones, sus componentes transversales y dems elementos que deben regir la implementacin del sistema para su adecuado funcionamiento e integracin. Entender de manera global el comportamiento del subsistema, analizando el papel que los componentes a implementar juegan en el sistema y cmo interactan con los dems elementos analizados. Comprender el comportamiento del requisito a ser implementado, sus precondiciones, post condiciones, ruta bsica y las alternas definidas. Entender el modelado esttico y dinmico del caso de uso. Comprender los principales componentes de la solucin, sus estructuras y la interaccin entre los mismos. Arquitecto Diseador Desarrollador (responsable)

3.1

Revisin general de la arquitectura.

Desarrollador

3.2

Revisin general de los requisitos del subsistema. Estudio del caso de uso o requisito especfico. Estudio del diseo del requisito para implementacin.

Desarrollador

3.3

Desarrollador

3.4

Desarrollador

Hacer
# 4 Actividad Implementar Elementos de Diseo. Descripcin Implementar la solucin modelada en la fase de diseo, cumpliendo los lineamientos establecidos por la arquitectura y los requisitos establecidos en la fase de anlisis del sistema Codificar el diseo del requisito, verificando que el comportamiento sea adecuado a la luz de las especificaciones; que se hayan seguido los lineamientos establecidos y los contratos definidos se cumplan a cabalidad. Ofrecer documentacin en el cdigo fuente para facilitar su lectura, comprensin y mantenimiento. Asegurar que un nico componente de la solucin produce una salida correcta para una entrada de datos especificada. Minimizar la aparicin de incidentes en etapas posteriores (aseguramiento de calidad) que pueden ser detectados desde una etapa temprana del ciclo de vida (construccin). Evaluar las condiciones bajo las cuales el requisito que se desea probar es completamente satisfactorio Inspeccionar las pruebas unitarias diseadas con base en los casos de prueba. Elaborar los artefactos que estarn encargados de realizar las pruebas unitarias sobre los componentes funcionales. Evaluar el correcto comportamiento de los componentes funcionales con base en la entrada de datos suministrada por la prueba. Realizar los ajustes requeridos a los componentes funcionales con base en los resultados fallidos generados por la ejecucin de la prueba. Ejecutar pruebas funcionales Describir los lineamientos para planear y ejecutar la integracin de elementos fsicos de la aplicacin, asegurando la estabilidad de la comunicacin de los subsistemas y un correcto control de versin del producto integrado. Identificar los elementos a integrar y el orden de sus dependencias en la implementacin. Responsable Desarrollador Salida

4.1

Implementacin del diseo. Documentacin de la implementacin. Implementar pruebas de desarrollador Revisin general de los casos de prueba diseados Revisin general del diseo de las pruebas unitarias (opcional) Construir los artefactos de pruebas Ejecutar las pruebas unitarias Ajustar resultados Pruebas funcionales

Desarrollador

Clases jsp Libreras

4.2

Desarrollador

Desarrollador

5.1

Desarrollador

5.2

Desarrollador

Prueba unitaria

5.3

Desarrollador

5.4

Desarrollador Clases Libreras Clases jsp Libreras

5.5

Desarrollador

5.6

Desarrollador

Integrar el producto Planear la integracin de los

Desarrollador

7.1

Desarrollador

Diagrama de secuencia

131
subsistemas Ejecutar pruebas de desarrollador a la integracin del subsistema Integrar los subsistemas Planear la integracin del sistema general Integrar el sistema

7.2

Detectar excepciones que puedan producirse en la integracin del subsistema, para asegurar estabilidad de la integracin. Generar los artefactos de software que componen el subsistema. Los errores detectados en la integracin se deben reportar. Identificar los elementos a integrar y el orden de sus dependencias en la implementacin. Generar los artefactos de software que componen el sistema

Desarrollador

Pruebas integracin

7.3

Desarrollador

7.4 7.5

Desarrollador Desarrollador

Integracin de componentes

Verificar
# 6 Actividad Verificar Implementacin Informar el inters en la revisin Preparacin de la revisin Revisin par de la implementacin. Ajustar especificacin segn revisin par Aprobacin Descripcin Inspeccionar la implementacin funcional por parte de un par, con el fin de encontrar posibles inconsistencias, ambigedades y temas incompletos. Solicitar la revisin al par, enviar un email informando qu se va a revisar, en qu fecha y ruta de componentes o tems a evaluar. Recopilacin de la informacin necesaria para ejecutar la revisin Verificar con un revisor Par, la adecuada implementacin de los elementos de diseo. Reportar los incidentes detectados. Dar respuesta a los incidentes encontrados. Reportar la solucin dada. Dejar la constancia de las revisiones Responsable Desarrollador Email solicitud revisin par Salida

6.1 6.2 6.3

Desarrollador Revisor par Revisor par

6.4

Desarrollador Email retroalimentacin revisin par

6.5

Revisor par

Actuar
# 8 Actividad Crear artefactos para despliegue Descripcin Producir los artefactos requeridos para instalar y desinstalar el producto de una manera segura y simple, sin afectar otras aplicaciones o caractersticas del sistema. Revisar la arquitectura del sistema para referenciar los elementos fsicos y de estructuracin de la solucin, que deben regir la implementacin y despliegue del sistema integrado. Obtener todos los artefactos que sern incluidos en el producto para despliegue Analizar los escenarios soportados para la instalacin de la aplicacin y determinar las condiciones para la generacin de los artefactos. Construir los artefactos de software que sern usados para instalar el producto Documentar el proceso para instalar y desinstalar el producto, de una manera segura y simple. Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Responsable Desarrollador Salida Instalador

8.1

Revisin general de la arquitectura Obtener la lnea base del producto integrado Planear la generacin de los artefactos de despliegue Generar los artefactos de despliegue Construir el manual de instalacin

Desarrollador

8.2

Desarrollador

8.3

Desarrollador

8.4

Desarrollador

Instalador Manual instalacin plan de despliegue Lecciones aprendidas Acciones Correctivas, preventivas y de mejora

8.5

Desarrollador

Generar acciones

PM Desarrollador

132 4.5.2.4 Gua Pruebas del Desarrollo del Software

DATOS GENERALES DEL PROYECTO Responsable Objetivo Coordinador de Pruebas Los propsitos del proceso de Pruebas son: Confirmar que cada producto de trabajo y/o servicio de software de un proceso o proyecto, refleje adecuadamente los requisitos especificados. Confirmar que un producto o uno de sus componentes cumplen con su tarea dentro de un ambiente especfico. Este proceso aplica para todos los proyectos de desarrollo Producto Producto Verificado

Alcance Entradas Salida

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# Actividad Definir alcance para la verificacin y validacin Descripcin Identificar los objetos de prueba y los factores crticos a verificar y validar. Identificar la lista especfica de tareas, eventos y artefactos que sirven como motivadores durante la presente iteracin, examinar elementos claves como: matriz de riesgos, solicitudes de cambio, casos de uso, modelado UML, etc. Adquirir un entendimiento inicial a los objetivos y el alcance de la presente iteracin. Adquirir informacin y retroalimentacin de los interesados en el proyecto acerca de los objetivos y el alcance de la prueba Responsable Analista de pruebas Salida Plan de pruebas. Lista de ideas de prueba. Check list de pruebas

1.1

Identificar Factores Crticos Entendiendo los objetivos de la Iteracin Presentar opciones a los interesados

Analista de pruebas

1.2

Analista de pruebas Analista de pruebas

1.3

133
1.4 1.5 Formular una misin Identificar los entregables de la prueba Considerar la profundidad apropiada para la estrategia Identifique los posibles mecanismos de prueba Defina los mecanismos de prueba que se van a usar Identificar claramente el foco de la prueba en la presente iteracin. Dejar claro los documentos que sern el resultado de las pruebas. Considerar la completitud de la estrategia en trmino de profundidad y contenido. Analista de pruebas Analista de pruebas Analista de pruebas

1.6

1.7

Identificar los mecanismos potenciales para cubrir la estrategia de pruebas

Analista de pruebas

1.8

Comunicar las decisiones realizadas acerca de los mecanismos de prueba. Identificar los requerimientos y la estrategia a seguir con respecto a los datos de pruebas. En caso de ser necesario solicitar datos al cliente para llevar a cabo las pruebas, ver procedimiento producto suministrado por el cliente Definir los requerimientos de los ambientes de pruebas necesarios para soportar el esfuerzo de pruebas

Analista de pruebas

1.9

Datos de Prueba

Analista de pruebas

Definir configuraciones ambiente de pruebas

Analista de pruebas

Hacer
# 3 3.1 3.2 4 Actividad Desplegar producto para pruebas internas Instalacin de la solucin Validar estabilidad de la solucin Validar Implementacin Seleccionar la tcnica apropiada de diseo de casos de prueba Configurar las precondiciones del ambiente de pruebas. Implementar el caso de prueba Ejecucin de las Pruebas Descripcin Utilizar los artefactos de despliegue y el manual de administracin para instalar y configurar el producto y dejarlo apto para pruebas internas. Identificar incidentes en el manual y la configuracin por defecto de la solucin Identificar si la construccin est estable y puede ser objeto de prueba Validar que el producto ha sido implementado apropiadamente y que cumple con su tarea dentro del ambiente definido. Determinar la tcnica apropiada de implementacin Responsable Analista de pruebas Analista de pruebas Analista de pruebas Analista de pruebas Analista de pruebas Formato ejecucin casos de prueba Salida

4.1

4.2

Para tener listo el ambiente en el estado correcto para iniciar Implementar uno o ms casos de prueba reutilizables Validar la implementacin. Los errores detectados reportarlos.

Analista de pruebas Analista de pruebas Analista de pruebas Formato ejecucin casos de prueba

4.3 4.4

Verificar
# 5 Actividad Analizar resultados Descripcin Analizar los resultados de todas las actividades de validacin e identificar incidentes Responsable Coordinador de pruebas Analista de pruebas Salida Estadsticas Carta certificacin

Actuar
# Actividad Descripcin Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Responsable Coordinador de pruebas Analista de pruebas Salida Lecciones aprendidas Acciones Correctivas, preventivas y de mejora

Generar acciones

134

4.5.2.5 Despliegue del Desarrollo del Software

DATOS GENERALES DEL PROYECTO Responsable Objetivo Alcance Entradas Salida Administrador de Proyectos Definir el proceso que se debe llevar a cabo cuando se va a desplegar el producto donde un cliente. Este proceso aplica para todos los proyectos de software. Producto verificado Producto instalado

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Proceso en Grfico

Caracterizacin Planear
# 1 Actividad Planear logstica de despliegue Revisar artefactos de despliegue Planear despliegue Descripcin Planear el despliegue del producto al cliente Responsable PM Arquitecto Lder desarrollo PM Arquitecto Lder desarrollo PM Arquitecto Lder desarrollo Salida

1.1

Revisar que la solucin est completa para despliegue

1.2

Generar estrategia para el despliegue

Inventario de componentes de despliegue Lista de chequeo de despliegue

Hacer
# 2 Actividad Ejecutar despliegue Descripcin Desplegar la solucin al cliente Responsable PM Arquitecto Lder desarrollo Salida

135
Control de asistencia a entrenamiento personal

Ejecutar capacitacin

Instruir a los futuros usuarios de la aplicacin (si aplica)

Analista de pruebas

Verificar
# 3 Actividad Revisar despliegue Descripcin Asegurar la calidad del despliegue, pruebas funcionales Responsable PM Arquitecto Lder desarrollo Salida

Actuar
# Actividad Descripcin Generar acciones correctivas, preventivas y de mejora como resultado de la aplicacin del proceso. Adicionalmente registrar las lecciones aprendidas durante la aplicacin proceso. Responsable PM Arquitecto Lder desarrollo Analista de pruebas Salida Lecciones aprendidas Acciones Correctivas, preventivas y de mejora

Generar acciones

136 5 CONCLUSIONES

Objetivo #1: Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento.

La metodologa RUP tiene una fuerte base de herramientas que permiten una mejor administracin de los proyectos de software, la cual permite seleccionar exclusivamente las herramientas que sean aplicables a la realidad de la empresa, sin afectar el enfoque global de la metodologa.

La aplicacin formal del RUP supone algunas desventajas tales como grandes esfuerzos en la construccin de modelos, no cubre por completo los procesos de gerenciamiento de proyectos, y la necesidad de soporte de herramientas informticas, pero tiene como grandes ventajas que disminuye el riesgo del error de anlisis / diseo acumulado, aligera el esfuerzo de implementacin y proporciona la documentacin del ciclo de vida en el mismo proceso.

La metodologa planteada, basada en la metodologa RUP interrelacionada con la Gua del PMBOK (2008) ayudara a finalizar de una manera eficiente, rpida y funcional la implementacin de un sistema de software, ya que esta metodologa dirige todo el progreso del desarrollo de un sistema de software y la administracin que se debe de llevar en cada uno de los pasos.

Aun cuando, a pesar de que en el desarrollo de software se encuentre gran cantidad de cambios en el momento de realizar el desarrollo de los proyectos, es posible realizar una metodologa para administrar los proyectos de forma

137 que se logre reducir el impacto de los imprevistos y los riesgos que puedan resultar negativos para los diferentes procesos.

Objetivo #2: Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin.

La cantidad de personas o roles que se definan que van a intervenir en un proyecto, va a depender mucho del tamao del proyecto y el trabajo que se va a realizar, ya que en muchos casos, una misma persona podr ejecutar varios roles a la vez, lo cual, no hace que sea obligatorio tener un equipo de trabajo muy grande para que el uso de la metodologa resulte exitosa.

Objetivo #3: Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, para que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa.

El administrador del proyecto debe asegurarse que los miembros del equipo mantengan actualizados sus respectivos productos/documentos del proyecto en el repositorio de administracin de la configuracin del proyecto, dentro del subdirectorio que les corresponda y utilizando los estndares para la identificacin de los archivos y sus versiones, para llevar un control ordenado del desarrollo del proyecto, y que la informacin este accesible a todos los involucrados en el mismo.

La utilizacin de una herramienta automatizada de anlisis de negocio para el desarrollo completo del ciclo de vida, es necesaria, que provea el lmite competitivo para el desarrollo de software, administracin de proyecto, administracin de requerimientos y anlisis de negocio.

138 Objetivo #4: Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas.

Al implementar un desarrollo de software particular para un cliente, es importante la utilizacin de patrones o guas, los cuales ya tienen una funcionalidad general y han sido predefinidas, y as contar con una base consistente y previamente elaborada, como la presentada en el desarrollo de este proyecto.

Hasta donde se ha investigado, no se ha creado una metodologa universal para hacer frente con xito a un proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto particular (recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.).

Histricamente, las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones del contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y con requisitos muy cambiantes. Las metodologas como el RUP y la gua del

PMBOK (2008) ofrecen una solucin casi a la medida para una gran cantidad de proyectos que tienen estas caractersticas.

139 6 RECOMENDACIONES

Esta propuesta metodolgica no ha sido probada en un ambiente real, por lo cual, es recomendable darle seguimiento a la implementacin de la misma, para refinar el modelo, tanto en los procedimientos como en las plantillas que fueron confeccionadas.

Se recomienda, realizar revisiones peridicas sobre la funcionalidad y resultados obtenidos con la aplicacin de esta metodologa propuesta, con el propsito de fortalecer, realizar mejoras y refinarla a travs del tiempo, manteniendo estos documentos en un ciclo de mejora continua, incluyendo las mejoras y variaciones que presenten en las nuevas versiones de las metodologas RUP y la gua del PMBOK.

Contar con un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una empresa de desarrollo de software, es necesario para finalizar de una manera eficiente, rpida y funcional la implementacin de un Sistema de Software. El establecer la aplicacin de una metodologa con la cual se puede mantener una fcil administracin, como la metodologa RUP combinada con el PMBOOK (2008), es de gran utilidad y facilitara el desarrollo de todas las etapas del ciclo de vida del software.

En este trabajo, se ha tratado de cubrir las ms importantes plantillas en la utilizacin de la metodologas RUP y la gua del PMBOK (2008), pero a raz que las empresas de desarrollo de software son tan complejas y diferentes, se pretende que funcionen como base, y las cuales puedan ser adaptadas de acuerdo a las necesidades propias de cada empresa.

Este documento no incluye detalle de herramientas automatizadas que ayuden a agilizar el proceso de la implementacin de la metodologa propuesta, pero se recomienda investigarlas y utilizarlas, ya que las mismas proporcionan el beneficio de la experiencia de los procesos que soportan. Contemplar que se deben de utilizar criterios para la eleccin de la ms apropiada.

140

BIBLIOGRAFIA

Boyd, Andrew (2001). The five maxims of project satisfaction. Aslib Proceedings, 53(10), 423. Emerald Group Publishing Limited. Chamoun, Yamal (2003). Administracin Profesional de Proyectos La Gua. Mxico. Edamsa Imprensiones, S.A. de C.V. Dixon, Miles. (2000). Project management body http://www.apm.org.uk Consultado el 20 Setiembre 2011. of knowledge.

Dooley, L., Lupton, G., & O'sullivan, D. (2005). Multiple project management: A modern competitive necessity. Journal of Manufacturing Technology Management, 16(5), 466. Joe DeCarlo, Enrico Mancin, Cecile Peraire, Angelo Fernandes, Mike Edwards and Kathy Carroll. IBM Rational Unified Process for System. 2004. Ibm.com/redbooks. Disponible en: http://www.redbooks.ibm.com/redbooks/SG247362/wwhelp/wwhimpl/js/html/wwhel p.htm. Consultado el 01 Octubre del 2011. Gido, Jack, Clements, James (2003). Administracin Exitosa de Proyectos. Segunda Edicin. Mxico, DF. International Thompson Editores, SA. Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, 2000 Addison Wesley Mendez, C (1995). Metodologa. Gua para elaborar diseos de investigacin en Ciencias econmicas contables y administrativas. Editorial: Mc Graw Hill Interamericana S.A. Segunda edicin. Project Management Institute. Gua de los Fundamentos de la Direccin de Proyectos. PMBOK (2008). Newtown Square, Pennsylvania: Project Management Institute, 4 Edicin. 2008. Rational Software Corporation, Rational Unified Process. Best Practices for Software Development Teams (2011). A Rational Software Corporation White Paper. Disponible en: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251 _bestpractices_TP026B.pdf Rapoza, J. Good ol' project days. EWeek, 22(36), 48-48. 2005. Disponible en http://www.eweek.com/c/a/Enterprise-Applications/Good-Ol-Project-Days/ Consultado el 05 Octubre 2011.

141

8 8.1

ANEXOS

Anexo 1: ACTA DEL PROYECTO

ACTA DEL PROYECTO Fecha de elaboracin del Acta del proyecto 20/09/2011 INFORMACIN GENERAL DEL PROYECTO Nombre del proyecto Propuesta de metodologa y estndares para la administracin de proyectos en las pequeas y medianas empresas de software con base en los estndares del PMI. reas de conocimiento / procesos: rea de aplicacin (sector / actividad): Alcance, Tiempo, Costo, Calidad, Recursos Empresas de Desarrollo de Software Humanos, Comunicacin y Riesgos Fecha de inicio del proyecto: Fecha tentativa de finalizacin del proyecto: 01/01/2012 23/03/2012 OBJETIVOS DEL PROYECTO Objetivo General Definir una propuesta de Plantillas y Herramientas que se puedan aplicar como estndar para el ciclo de vida del desarrollo de software adaptable para pequeas y medianas empresas con base en el marco estndar del RUP (Rational Unified Process) y del PMI (Project Management Institute), para el mes de marzo del 2012, realizado como proyecto final de graduacin para ser presentado como requisito parcial para optar por el ttulo de Mster Administracin de Proyectos. Objetivos Especficos Disear las plantillas para la propuesta de la administracin del proyecto que sern aplicables para cada etapa que involucra el ciclo de vida de los proyectos de software de pequeas y medianas empresas, para ordenar y administrar correctamente cada proyecto. Las reas de conocimiento que dichas plantillas apoyarn sern: alcance, tiempo, costo, calidad, recursos humanos, comunicaciones, riesgo y abastecimiento. Identificar los roles y responsabilidades para el uso de las plantillas, para que los funcionarios involucrados asuman el papel y la responsabilidad que les corresponde en el contexto del proyecto y de la organizacin. Definir una estructura adecuada para almacenar las plantillas y herramientas identificadas y diseadas en los objetivos anteriores, de forma que se lleve con facilidad el control de los archivos de los proyectos de la organizacin que implemente esta metodologa. Crear un instructivo para la administracin de proyectos de software que sea nico, entendible e indique los procesos y fases que debe seguir los proyectos para la utilizacin de las plantillas propuestas. JUSTIFICACION DE IMPACTO (aporte y resultados esperados) El mayor beneficio de la implantacin de la Carpeta de Plantillas y Herramientas es hacer las cosas ms fciles. Administrar proyectos es una tarea compleja, que por medio de la adecuada utilizacin de la metodologa se puede crear una atmsfera positiva y de respaldo a los administradores de proyectos de las empresas desarrolladoras, y lograr un entorno donde sea posible realizar proyectos con xito. Esta carpeta tiene como fin sembrar en las empresas de software el uso de las mejores prcticas para las fases de iniciacin, planificacin, ejecucin, control y cierre de los proyectos mediante la utilizacin de plantillas. Los gerentes de proyecto necesitan de una disciplina que los auxilie a tomar todas las medidas para atender responsablemente cada uno de los aspectos que hacen a un proyecto, sin dejar detalles librados al azar que puedan atentar contra todo el proyecto. Tener plantillas de documentacin y herramientas estandarizadas en el uso general de los proyectos de la empresa basadas en la metodologa de direccin de proyectos, de las mejores prcticas y de las

142
normas. Logrando: o Tener un ordenamiento en la documentacin que debe ser utilizada en cada una de las etapas que involucra los proyectos internos y externos de la empresa. o Confiabilidad en la informacin para la toma de decisiones dentro del proyecto o de la alta gerencia. o Optimizacin de los niveles de comunicacin entre proyectos y racionalizacin del uso de recursos compartidos. o Favorecer la adecuada administracin de la configuracin de los proyectos y contar con un repositorio central donde se administre el conocimiento generado en los diferentes proyectos. o Establecer una terminologa estndar, que mejora la comunicacin tanto externa como interna. DESCRIPCION DEL PRODUCTO Descripcin del Producto Carpeta de plantillas y herramientas estndares donde las empresas de Software encuentren el respaldo necesario para administrar sus proyectos dentro del tiempo, costo y calidad definidos, por medio de la utilizacin de metodologas estandarizadas para el desarrollo de software y la administracin de proyectos especficamente en los temas de gestin Integracin, Alcance, Tiempo, Recursos Humanos y Comunicaciones. NECESIDAD DEL PROYECTO (lo que da origen) Dado el creciente aumento de pequeas y medianas empresas de software que se constituyen y no cuentan con una oficina de proyectos y una metodologa que les ayude a desarrollar con orden y planificacin las diferentes etapas y procesos que involucra la direccin general de la empresa (planificacin, organizacin, seleccin de personal, ejecucin y control de las operaciones) y el ciclo de vida de los proyectos que administran, aunado con la influencia de nuevas tecnologas; surge la necesidad de implementar nuevas formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administracin de proyectos, sin dejar de lado la colaboracin a distancia, el outsourcing, la mejora de calidad, generacin y distribucin de conocimiento y coordinacin de varios proyectos, entre otras. Entre los principales problemas que enfrentan dichas empresas se encuentran que: No existen formas ni estilos definidos para administrar los proyectos internos y externos. Los encargados y participantes de los proyectos no tienen claramente definidos sus roles y funciones formalmente y por escrito, se realizan por costumbre y segn la necesidad del momento. Los proyectos no tienen una metodologa estndar para el control y seguimiento en cuanto a su alcance, costos, tiempo, comunicaciones y calidad Generalmente no existe plantillas adecuadas para llevar un control de cambios formal en el alcance, ni para la planificacin en el seguimiento de la calidad del producto del proyecto. La gestin del tiempo del proyecto se limita a un cronograma de trabajo inicial y posiblemente uno final, no utilizndose herramientas adecuadas de control de cambios del mismo. No hay plantillas ni herramientas para documentar las lecciones aprendidas. Generalmente no se trabaja enfocado en la rentabilidad del proyecto. RESTRICCIONES / LIMITANTES / FACTORES CRITICOS DE EXITO 1. Se tiene como fecha lmite de finalizacin del proyecto el mes de Marzo del 2012. 2. El director del proyecto cuenta con una disponibilidad de un 25% para la implementacin del proyecto. IDENTIFICACION DE GRUPOS DE INTERES Cliente(s) directo(s): Departamento o rea de implementacin de proyectos de software. Clientes indirectos: Clientes de las pequeas y medianas empresas dedicadas al desarrollo e implantacin de software. AUTORIZACIN PARA EL PROYECTO Hecho por: Firma: Karen Roco Jimnez Murillo Aprobado por: Firma: Erika Gatjens Soto Tutor

143

8.2

Anexo 2: EDT

144

8.3

Anexo 3: CRONOGRAMA

145

146

147

8.4

Anexo 4: Otros

148

8.4.1 Plantilla Modelo de Casos de Uso del Negocio

[Nombre del proyecto] Modelo de Casos de Uso del Negocio Versin [1.0]
[Este documento es la plantilla base para elaborar el documento Modelo de Casos de Uso. Los textos que aparecen entre parntesis rectos son explicaciones de que debe contener cada seccin. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. Para actualizar la tabla de Contenido, haga clic con el botn derecho del ratn sobre cualquier lnea del contenido de la misma y seleccione Actualizar campos, en el cuadro que aparece seleccione Actualizar toda la tabla y haga clic en el botn Aceptar.] [Este documento se realiza en forma previa al Modelo de Casos de Uso del Sistema y constituye una entrada fundamental para realizar el mismo. El propsito principal de modelar actores y CU del Negocio es describir como se utiliza el negocio por parte de sus clientes y socios. Estos Casos de Uso del Negocio constituyen los procesos del Negocio que dan valor a los actores involucrados. Estos procesos son el vehculo con el que el Negocio hace cosas. Las estrategias del Negocio se traducen en Objetivos del Negocio que guan las actividades realizadas en los procesos del Negocio, por lo que cada CU del Negocio debe soportar por lo menos un objetivo del Negocio, y esta es una gua para identificar la granularidad correcta para la definicin de los CU del Negocio. Cuando se est realizando el modelado del Negocio solo para tener una visin primaria para un proyecto de Ingeniera de Software, se debe delimitar con cuidado el esfuerzo de modelado del Negocio. En este caso en general no vale la pena hacer el modelado del Negocio entero, y es conveniente considerar la parte del Negocio con la que se est tratando, como si fuera el Negocio entero, la parte considerada ser la que utilice directamente el sistema en desarrollo. Las partes de la Organizacin que se dejen fuera de los lmites del Negocio tomado en cuenta, pueden ser modeladas como actores del Negocio.]

Historia de revisiones
Fecha [dd/mm/aaaa] Versin [x.x] Descripcin [detalles] Autor [nombre]

149

Contenido
1. Actores ............................................................................................................... 150 1.1. [Actor 1] ...................................................................................................... 150 1.2. [Actor 2] ...................................................................................................... 150 2. Casos de Uso ...................................................................................................... 150 2.1. Diagramas de Casos De Uso ........................................................................ 150 2.2. [Caso de Uso 1]............................................................................................ 150 2.2.1. Descripcin ........................................................................................... 150 2.2.2. Pre-condiciones ................................... Error! Marcador no definido.148 2.2.3. Flujo de eventos principal ...................................................................... 150 2.2.4. Flujos de eventos alternativos ................................................................ 150 2.2.5. Post-condiciones .................................................................................... 148 2.2.6. Requerimientos especiales ..................................................................... 151 2.3. [Caso de Uso 2]............................................................................................ 151

150
1. Actores del Negocio
[En esta seccin se debe describir a cada uno de los actores del Negocio que participan en los Casos de Uso del Negocio, un actor del Negocio es un usuario del Negocio o cualquier entidad que interacta con el Negocio.] 1.1. [Actor del Negocio 1] [Descripcin del Actor 1 del Negocio] 1.2. [Actor del Negocio 2] [Descripcin del Actor 2 del Negocio]

2.
2.1.

Casos de Uso del Negocio

Diagramas de Casos De Uso [Aqu se presentan los Diagramas de Casos de Uso del Negocio, para mostrar la interaccin entre los Actores y los Casos de Uso del Negocio.]

2.2. 2.2.1.

[Caso de Uso del Negocio 1] Descripcin

[Explicar brevemente el propsito del caso de uso del Negocio] 2.2.2. Flujo de eventos principal

[En esta seccin se realiza una descripcin textual del flujo del Negocio que representa el Caso de Uso. El flujo debe describir que hace el Negocio para proveer de valor a un actor del Negocio, pero no como hace el Negocio para resolver sus problemas. Las alternativas simples se pueden presentar dentro del texto del Caso de Uso. Si el flujo alternativo es ms complejo, use una seccin separada para describirlo.] 2.2.3. 1.1.1.1. Flujos de eventos alternativos [Flujo alternativo 1]

[En esta seccin se describen las alternativas ms complejas a las cuales se haca referencia en el Flujo de eventos principal. Estos flujos alternativos representan la conducta alternativa normalmente debida a excepciones que ocurren en el flujo principal. Ellos pueden ser necesarios para describir los eventos asociados con la conducta alternativa. Cuando finaliza el flujo alternativo, se retoman los eventos del flujo de eventos principal a menos que se establezca otra cosa.] [Sub-flujo alternativo 1] [Los flujos alternativos pueden dividirse en subsecciones si esto aporta claridad] [Sub-flujo alternativo 2] ... 1.1.1.2. ... 2.2.4. Diagrama de Actividad [Flujo alternativo 2]

[En esta seccin incluye un Diagrama de Actividad que modele en forma grfica los flujos del Caso de Uso del Negocio descritos previamente. Es importante que se muestren los distintos condicionales que existen en el proceso que determinan que se siga un camino u otro en la ejecucin del proceso, y cuales son todas las opciones de terminacin para los flujos modelados.]

151
2.2.5. Requerimientos especiales

[En esta seccin se especifican los requerimientos especiales que son especficos a un caso de uso del Negocio, que son las caractersticas del caso de uso del Negocio no cubiertas por los flujos descritos.] 2.3. [Requerimiento especial 1] ...

[Caso de Uso del Negocio 2] ...

3.

Reglas del Negocio

[En esta seccin se especifican las Reglas del Negocio que se deben tener en cuenta en la ejecucin de los distintos procesos definidos. Las Reglas del Negocio son tipos de requerimientos sobre como el Negocio, incluyendo sus herramientas, debe funcionar. Pueden ser leyes y regulaciones impuestas al Negocio entre otras, y pueden ser clasificadas de distinta forma segn el Negocio, por ejemplo pueden estar agrupadas por dominio, usuario o grupo de productos, aunque una clasificacin ms formal las define como Restricciones y Derivaciones. Las Reglas del Negocio deben ser expresadas con un nivel de formalismo que permita su automatizacin, una forma puede ser utilizando el Object Constraint Language (OCL) especificado en UML. De todas formas es til mostrar las Reglas de Negocio como notas de texto en los elementos de los distintos diagramas y modelos, por ejemplo en los Diagramas de Actividad.]

3.1.

[Regla del Negocio 1] ...

152

8.4.2 Plantilla Glosario

<Nombre del Proyecto> Glosario Versin <1.1.0>

[Nota: Este Plantilla tiene por finalidad servir de base para la confeccin del documento Glosario. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]

153

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

154

ndice
1 Introduccin 1.1 Propsito 1.2 mbito 1.3 Referencias 1.4 Resumen Ejecutivo 2 Definiciones 2.1 Trminos 2.2 <Grupo de Trminos> 2.3 <Un segundo Grupo de Trminos> 155 155 155 155 155 155 155 156 157

155

Glosario
Introduccin
[La introduccin del Glosario provee un resumen del documento completo. Presente cualquier informacin que el lector pueda necesitar para entender el documento en esta seccin. El documento Glosario es usado para definir la terminologa especfica para el dominio del problema, explicando los trminos que puedan no ser familiares al lector acerca de la descripcin de los casos de uso o de otros documentos del proyecto. Este documento puede ser un diccionario informal, capturando la definicin de los datos en los que se pueda enfocar los casos de uso u otros documentos del proyecto que necesiten hacer algo con esta informacin. Este documento debe ser guardado con el nombre de Glosario..] Propsito [Especifique el propsito del Glosario.] mbito [Una breve descripcin del mbito de este Glosario; que proyecto(s) estn asociados a l, o cualquier cosa que pueda versen afectada o influenciada por este documento.] Referencias [Esta subseccin provee una lista completa de todos los documentos referenciados en cualquier parte de este Glosario. Identifique cada documento por ttulo, nmero de edicin (si es aplicable), y editorial. Especifique las fuentes de donde pueden obtenerse estas referencias. Esta informacin puede ser entregada a modo de referencia a un apndice o a otro documento.] Resumen Ejecutivo [Esta subseccin describe el contenido del resto del Glosario, est organizado el documento.] y explica cmo

Definiciones
[Los trminos definidos en este punto forman la esencia del documento. Estos pueden ser definidos en el orden deseado, pero generalmente se usa el orden alfabtico para proveer mayor accesibilidad.] Trminos

Termino

Descripcin
[La definicin para <Un trmino> se realiza aqu. Se debe presentar cuanta informacin sea necesaria para que el lector comprenda los conceptos.]

Estereotipos de UML
[Esta seccin contiene o referencia las especificaciones del Unified Modeling Language(UML) estereotipos y sus implicaciones semnticasuna descripcin textual del significado y uso del estereotipo, adems describe cualquier limitacin en su uso- para estereotipos ya conocidos o desarrollados (y que son importantes para el sistema), El uso de estos

156
estereotipos puede ser recomendado o imprescindible; Por ejemplo, cuando su uso es requerido por un estndar impuesto o cuando su uso hace a los modelos significativamente ms fciles de entender. Esta seccin puede estar vaca si no existen estereotipos adicionales, o si se usan los predefinidos por UML.]

<Grupo de Trminos> [A veces es til organizar los trminos por grupos para facilitar la lectura. Por ejemplo si el dominio del problema contiene trminos iguales relacionados con cuentas y con crear una construccin (si este fuera el caso en el que estamos desarrollando un sistema que maneje los proyectos de construccin), presentar los trminos de los dos subdominios diferentes puede confundir al lector. La solucin a este problema es agrupar los trminos. En la presentacin de grupos de trminos, proporcione una descripcin corta que ayude al lector a entender qu representa <un grupo de trminos>. Los trminos presentados con el grupo deben estar organizados alfabticamente para facilitar el acceso.]

Grupo de trminos

Descripcin
[La definicin para <un grupo de trminos> se presenta aqu. Incluya tanta informacin como sea necesaria para que el lector pueda entender el concepto.]

Estereotipos de UML
[Esta seccin contiene o referencia las especificaciones del Unified Modeling Language(UML) estereotipos y sus implicaciones semnticasuna descripcin textual del significado y uso del estereotipo, adems describe cualquier limitacin en su uso- para estereotipos ya conocidos o desarrollados (y que son importantes para el sistema), El uso de estos estereotipos puede ser recomendado o imprescindible; Por ejemplo, cuando su uso es requerido por un estndar

157
impuesto o cuando su uso hace a los modelos significativamente ms fciles de entender. Esta seccin puede estar vaca si no existen estereotipos adicionales, o si se usan los predefinidos por UML.]

<Un segundo Grupo de Trminos>

Grupo de trminos

Descripcin
[La definicin para <un grupo de trminos> se presenta aqu. Incluya tanta informacin como sea necesaria para que el lector pueda entender el concepto.]

Estereotipos de UML
[Esta seccin contiene o referencia las especificaciones del Unified Modeling Language(UML) estereotipos y sus implicaciones semnticasuna descripcin textual del significado y uso del estereotipo, adems describe cualquier limitacin en su usopara estereotipos ya conocidos o desarrollados (y que son importantes para el sistema), El uso de estos estereotipos puede ser recomendado o imprescindible; Por ejemplo, cuando su uso es requerido por un estndar impuesto o cuando su uso hace a los modelos significativamente ms fciles de entender. Esta seccin puede estar vaca si no existen estereotipos adicionales, o si se usan los predefinidos por UML.]

158

8.4.3 Plantilla Visin

<Nombre del Proyecto> Visin Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de Base para la confeccin del documento Visin. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]

159

Historia de Revisiones
Fecha Versin Descripcin Autor

<aaaa-mm-dd>

<1.1.0>

Documento Inicial

<Nombre>

160 ndice 1. Introduccin 1.1. Propsito 1.2. mbito 1.3. Definiciones, Siglas, y Abreviaciones 1.4. Referencias 1.5. Resumen Ejecutivo 2. Posicionamiento 2.1. Declaracin del Problema (OBLIGATORIO) 2.2. Declaracin de Posicionamiento del Producto 3. Descripcin de Clientes, Stakeholders y Usuarios 3.1. Demografa del Mercado 3.2. Resumen de Stakeholders (OBLIGATORIO) 3.3. Resumen de usuarios (OBLIGATORIO) 3.4. Alternativas y Competencia 4. Descripcin Global de la Solucin 4.1. Modelo de Negocios 4.2. Perspectiva del Producto de software 4.3. Resumen de capacidades 4.4. Supuestos y Dependencias 5. Caractersticas del Producto 5.1 <Caracterstica> 5.2 <Siguiente Caracterstica> 6. Restricciones 7. Rangos de Calidad 8. Precedencia y prioridad 9. Otros Requerimientos del producto 9.1. Estndares Aplicables 9.2. Requerimientos de sistema 9.3. Requerimientos de Performance 9.4. Requerimientos de Entorno 10. Requerimientos de Documentacin 10.1. Manual de Usuario 10.2. Gua de Instalacin, Configuracin, y archivo Read Me

161 161 161 161 161 161 162 162 162 162 163 163 163 163 163 164 164 164 164 164 165 165 165 165 165 165 165 165 165 165 166 166 166

161

Visin
1. Introduccin
[El propsito de este documento es recolectar, analizar y definir una vista global de las necesidades de los usuarios y caractersticas del producto. Entendemos por producto al conjunto de la solucin, incluyendo los procesos administrativos como el sistema. Este es el documento inicial del proyecto, y resume la visin macro de todas las reas afectadas: 1) el rea que da origen al proyecto, responsable de la definicin del producto (usualmente el rea comercial); 2) el rea responsable de la solucin global para satisfacer la definicin del producto (usualmente Ingeniera de Procesos); 3) el rea responsable del desarrollo o modificacin del (los) sistema(s) computacional(es) requeridos. Enfquese en determinar las capacidades necesitadas por los stakeholders y por qu existen estas necesidades y como el producto va a solucionarlas. Los detalles de cmo la sern resueltas estas necesidades 1) por los procesos administrativos estarn en los respectivos Diagramas de Actividad; 2) por el sistema computacional se describen en las especificaciones de los casos de uso. ] 1.1.Propsito [Especifique el propsito de este documento de Visin.] 1.2.mbito [Breve descripcin sobre el mbito del documento de Visin, que reas organizacionales y sistemas computacionales (nuevos o a modificar) estn asociados y qu o quienes estarn afectados o influenciados por este proyecto] 1.3.Definiciones, Siglas, y Abreviaciones [Definicin de todos los trminos, siglas y abreviaciones requeridas para interpretar el documento de Visin. Esta informacin debe irse incorporando al Glosario del proyecto. Por ejemplo: Stakeholder: Ejecutivos de la empresa que se ven principalmente afectados por el proyecto. Un resultado exitoso del mismo redundar positivamente en su gestin. Pueden o no ser participantes del proceso o usuarios del sistema computacin. Participantes del proceso: Personas o dispositivos que forman parte de los procesos administrativos involucrados en la solucin. Pueden o no ser usuarios del sistema computacional. Usuarios: Personas que interactan directamente con el sistema computacional.] 1.4.Referencias [Este punto deber: Proveer una completa lista de todos los documentos referenciados en cualquier lugar del documento de Visin. Identificar cada documento por un ttulo, nmero de reporte (si aplica), fecha y organizacin que la pblica. Especificar las fuentes desde las cuales las referencias pueden ser obtenidas. Esta informacin puede estar referida a un apndice u otro documento.] 1.5.Resumen Ejecutivo [Breve resumen del contenido del resto del documento de Visin, y como este est organizado].

162 2. Posicionamiento
2.1.Declaracin del Problema (OBLIGATORIO) [Obtener una declaracin del o los problemas que ser resuelto por el proyecto. Se debe usar el siguiente formato:

El problema de Afecta a El impacto del cual es Una solucin exitosa sera

[describa el problema] [principales involucrados por el problema] [cual es el impacto del problema] [describa algunos beneficios claves que debe contener una solucin para ser calificada de exitosa]

2.2.Declaracin de Posicionamiento del Producto [Esta seccin aplica en proyectos que implican el desarrollo de un nuevo producto o servicio, que se intentar posicionar en el mercado. Si el origen del proyecto es un requerimiento interno, o uno especfico de un cliente que no ser comercializado a otros clientes, esta seccin no aplica. El objetivo es proveer una declaracin a alto nivel, dando la posicin que intenta el producto tomar en el mercado. Normalmente se obtendr de definiciones generadas por la Gerencia Comercial. Se sugiere el siguiente formato:

Para Quin El (nombre del producto) Que

[cliente objetivo] [declaracin de la necesidad u oportunidad] es un [categora del producto] [declaracin del beneficio clave, esto es razn de conveniencia de la compra) [primera alternativa de competencia] [declaracin de la diferencia esencial]

A diferencia de Nuestro producto

3. Descripcin de Clientes, Stakeholders y Usuarios

[Para obtener productos y servicios que satisfagan las verdaderas necesidades de los clientes, stakeholders y usuarios, es necesario identificar e involucrar a todos aquellos que se vean afectados por el proyecto (stakeholders) en el proceso de Modelamiento del Negocios. Es importante identificar tambin a todos los usuarios del (los) sistemas computacionales, y asegurarse que estn adecuadamente representados por algn Stakeholder. Esta seccin debe establecer un perfil de los stakeholders y usuarios de la aplicacin y los problemas claves que ellos perciben que deben ser resueltos por la solucin propuesta. El objetivo es proveer el background y la justificacin de por qu los requerimientos son necesarios.]

163
3.1.Demografa del Mercado [Esta seccin aplica en proyectos que implican el desarrollo de un nuevo producto o servicio, que se intentar posicionar en el mercado. Si el origen del proyecto es un requerimiento interno, o uno especfico de un cliente que no ser comercializado a otros clientes, esta seccin no aplica. [Esta seccin resume la demografa del mercado que motiva la decisin de existencia del producto. Describe y posiciona los segmentos del mercado objetivo. Estima el tamao y crecimiento del mercado segn el nmero de potenciales usuarios, o la cantidad de dinero que sus clientes estn dispuestos a pagar tratando de encontrar las necesidades que su producto podr satisfacer. Analice las principales tendencias y tecnologa de la industria. Responda estas preguntas estratgicas: Cual es la reputacin de la organizacin en ese mercado? Cmo quisieran Uds. que fuesen? Cmo este producto o servicio apoya sus objetivos? 3.2.Resumen de Stakeholders (OBLIGATORIO) [Detalle a todos los stakeholders identificados.]

Nombre
[Nombre del tipo de Stakeholder.]

Representa
[Describa brevemente que representa para el proyecto]

Rol
[Describa brevemente el rol que jugar en el desarrollo del proyecto, cual ser su nivel de involucramiento]

Criterios de xito
[Describa brevemente cuales son los criterios bajo los cuales el Stakeholder considerar que el proyecto es exitoso].

3.3.Resumen de usuarios (OBLIGATORIO) [Detalle a todos los usuarios identificados.]

Nombre
[Nombre del perfil de usuario, esto es conjunto de personas que cumplen el mismo rol para el sistema]

Descripcin
[Describa brevemente que representan para el sistema, cuantas personas hacen esa tarea, cantidad de operaciones, si es una tarea nueva, si no lo es como la ejecutan actualmente.]

Stakeholder
[Indique que Stakeholder representa a este perfil de usuarios].

3.4.Alternativas y Competencia [Identifique alternativas que sean percibidas como disponibles. Ello puede considerar comprar un producto de la competencia, construir una nueva solucin, hacer mejoras a una solucin existente o no hacer nada. Indique las principales fortalezas y debilidades de cada opcin, y porque fueron desechadas.]

4. Descripcin Global de la Solucin

[Esta seccin contiene una visin de alto nivel sobre la solucin, sus capacidades, interfaces a otras aplicaciones y configuraciones de sistemas]

164
4.1.Modelo de Negocios [El Objetivo de esta subseccin es dar un entendimiento del modelo de negocios al que la solucin a construir responde. Para ello se recomienda incluir un Diagrama de Casos de Uso de Negocio, y para cada caso de uso un Diagrama de Actividad Global, identificando cuales funciones sern ejecutadas manualmente, cuales usando sistemas computacionales existentes y cuales usando sistemas computacionales a construir o modificar. Esta subseccin no es aplicable si la totalidad de la solucin es un sistema computacional, por ejemplo un sistema de consulta de clientes por la WEB].

4.2.Perspectiva del Producto de software [Esta subseccin pone el producto de software a construir o modificar en perspectiva de otros productos relacionados y del ambiente de los usuarios. Si el producto es independiente y totalmente autocontenido, indquelo aqu. Si es una parte de un sistema mayor, debe identificar las interfaces entre los sistemas, Se recomienda incluir un Diagrama de Casos de Uso de Software, distinguiendo que Casos de Uso son nuevos y cuales son adecuaciones a Casos de Uso ya existentes. Se debe incluir una breve descripcin de cada Caso de Uso, hasta el nivel que sea necesario para poder dimensionar el esfuerzo de su construccin]. 4.3.Resumen de capacidades [Resuma los principales beneficios y caractersticas que la solucin cumplir. Organice las funciones de manera fcil de entender, por ejemplo en una tabla como la siguiente:

Beneficios
[corresponden a los tems identificados en la Formulacin del problema como una solucin exitosa sera]

Caractersticas que lo permiten

[A travs de que caractersticas de que procedimientos y casos de uso se obtendr el beneficio respectivo]

4.4.Supuestos y Dependencias [Identifique los factores que afectan las caractersticas establecidas en el documento de Visin, especialmente aquellas que si cambian provocaran un cambio en este documento. Por ejemplo, un supuesto podra establecer que un sistema operativo especfico estar disponible para un Hardware especfico. Separe los supuestos tcnicos de los no tcnicos.]

5. Caractersticas del Producto

[Liste y describa las caractersticas de los productos, Las caractersticas son las capacidades de alto nivel del sistema, son los que entregan beneficios a los usuarios. Cada caracterstica es un servicio esperado externamente que requiera tpicamente una serie de entradas para alcanzar el resultado deseado. Por ejemplo, una caracterstica de un problema de ajuste de sistema puede ser la habilidad de entregar reportes de tendencias. Como el modelo de casos de uso toma una forma, actualice esta descripcin para referirse a los casos de uso. Debido a que el documento Visin es revisado por un gran nmero de personal, el nivel de detalle necesita ser lo suficientemente general como para ser entendido por cualquier persona. De todas formas, debe tener el suficiente detalle para entregar al equipo la informacin suficiente para crear los casos de uso.

165
Para manejar la complejidad de la aplicacin efectivamente, se recomienda para cualquier sistema Nuevo, o incremento de un sistema ya existente, que la capacidad sea abstrada a un alto nivel de caractersticas, un buen nmero de caractersticas son entre 25-99. Estas caractersticas proveen la base fundamental para la definicin del producto, manejo del mbito y del proyecto. Cada caracterstica debe explicarse con gran detalle en el modelo de casos de uso. A travs de esta seccin, cada caracterstica debe ser externamente percibida por los usuarios, operadores u otros sistemas externos. Estas caractersticas deben incluir una descripcin de su funcionalidad y cualquier uso relevante. Se pueden aplicar los siguientes principios: Abstenerse de disear. Mantener la descripcin de las caractersticas en un nivel general. Enfocarse en las capacidades necesarias y porque (no como) deben ser implementadas <Caracterstica> <Siguiente Caracterstica>

5.1.5.1 5.2.5.2

6. Restricciones
[Indique cualquier restriccin externa al proyecto, por ejemplo fecha de trmino, mxima, presupuesto mximo, plataformas de Hardware y Software Bsico,]

7. Rangos de Calidad
[Defina los rangos de calidad exigidos para performance, robustez, tolerancia a fallas, usabilidad y otros atributos no funcionales.]

8. Precedencia y prioridad
[Defina la prioridad de las diferentes caractersticas del sistema.]

9. Otros Requerimientos del producto

[A un alto nivel, listar los estndares aplicables, los requerimientos de hardware o de plataforma, requerimientos de performance, y los requerimientos de entorno] 9.1.Estndares Aplicables [Listar todos los estndares con los cuales debe cumplir el producto. Estos pueden incluir estndares legales y reguladores (FDA, UCC), de comunicacin (TCP/IP, ISDN), estndar de la plataforma (Windows, UNIX, etc.), y estndares de calidad y seguridad (UL, ISO, CMM).] 9.2.Requerimientos de sistema [Defina cualquier requerimiento de sistema que sea necesario para soportar la aplicacin. Este puede incluir soporte de operador de host y plataformas de network, configuraciones, memoria, perifricos, y software] 9.3.Requerimientos de Performance [Use esta seccin para detallar los requerimientos de performance. Incluya estos tems como factores de carga de usuario, ancho de banda o capacidad de la comunicacin, rendimiento, exactitud, y confiabilidad o tiempo de respuesta bajo variadas condiciones de carga.] 9.4.Requerimientos de Entorno [Detalle los requerimientos de entorno necesarios. Para sistemas basados en

166
hardware, los requerimientos de entorno pueden incluir temperatura, golpes elctricos, humedad, radiacin, etc. Para aplicaciones software pueden incluir las condiciones de uso, entorno de usuario, disponibilidad de recursos, mantenimiento, y manejo y recuperacin de errores.]

10.

Requerimientos de Documentacin
[Esta seccin describe la documentacin que debe ser desarrollada para dar soporte al despliegue exitoso de la aplicacin.]

10.1. Manual de Usuario [Describa el propsito y contenido del Manual de Usuario. Discuta sobre el tamao deseado, nivel de detalle, necesidad de ndice, glosario, tutorial versus la estrategia del manual de referencia, etc. Dando formato e imprimiendo las constantes que tambin deben ser identificadas.] 10.2. Gua de Instalacin, Configuracin, y archivo Read Me [Consiste en un documento que incluye las pautas de instrucciones de instalacin y configuracin, es importante que entregue una solucin completa. Tambin se incluye tpicamente como un componente estndar El archivo Read Me puede incluir una seccin de Lo Nuevo de esa versin, y un capitulo de compatibilidad con versiones antiguas. La mayora de los usuarios tambin aprecian la documentacin de bugs conocidos y sus soluciones.]

167

8.4.4 Plantilla Especificacin de Requerimientos de Software

<Nombre del Proyecto> Especificacin de Requerimientos de Software (SRS) Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de Base para la confeccin del documento de Especificacin de Requerimientos de Software. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. El formato del texto debe tener tipo de letra verdana. ] [NOTA: Para proyectos pequeos, de duracin menor a un mes y un equipo de menos de 3 personas, este documento se puede reemplazar con una referencia al documento Anlisis Preliminar. En este caso el jefe del proyecto necesita mantener el documento Anlisis Preliminar durante el ciclo de vida del proyecto como lnea base de requerimientos.]

168

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

169

ndice
1. Introduccin............................................................................................................ 170 1.1. Propsito ......................................................................................................... 170 1.2. mbito ............................................................................................................ 170 1.3. Definiciones, Acrnimos y Abreviaciones........................................................ 170 1.4. Referencias ...................................................................................................... 170 1.5. Resumen Ejecutivo .......................................................................................... 170 2. Descripcin General................................................................................................ 171 2.1. Especificacin de Funcionalidades ................................................................... 171 2.2. Supuestos y Dependencias ............................................................................... 171 2.3. Acuerdos con el Cliente para la Administracin de Requerimientos ................. 171 3. Especificacin de Requerimientos ........................................................................... 171 3.1. Reportes de Casos de Uso ................................................................................ 171 3.2. Requerimientos Funcionales ............................................................................ 172 3.3. Requerimientos Adicionales............................................................................. 173 3.4. Requerimientos no Funcionales........................................................................ 173 3.5. Requerimientos Tcnicos ................................................................................. 174 3.6. Requerimientos de Proceso .............................................................................. 174 4. Administracin de Requerimientos ......................................................................... 174 4.1. Conjunto de Requisitos .................................................................................... 175 4.2. Requisitos Individuales .................................................................................... 175 4.3. Criterios de Revisin de Requerimientos.......................................................... 176

170

Especificacin de Requerimientos de Software

1. Introduccin
[La introduccin de la Especificacin de Requerimientos de Software debe ser un resumen del documento completo. Debe incluir el propsito, mbito, definiciones, acrnimos, abreviaciones, referencias, y resumen ejecutivo de este documento]

1.1. Propsito El propsito de este documento es capturar todos los requerimientos de software del sistema, o un subconjunto del sistema.
[Nota: Los Requerimientos que se realizarn utilizando algn framework transaccional deben ser especificados en el documento apropiado para eso]

1.2.

mbito

[Prrafo obligatorio.] [Una descripcin del entorno afectado; que proyectos se ven afectados o influenciados por esta Especificacin de Requerimientos de Software.]

1.3.

Definiciones, Acrnimos y Abreviaciones

[Prrafo obligatorio si existen trminos, definiciones acrnimos o abreviaciones.] [Esta subseccin debe proporcionar las definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente la Especificacin de Requerimientos de Software. Esta informacin puede ser entregada a modo de referencia al Glosario del proyecto.] [Recomendacin: Se sugiere mantener solo un glosario para el proyecto.]

1.4.

Referencias

[Prrafo obligatorio si existen referencias.] [Esta subseccin debe entregar una lista de todos los documentos referenciados en cualquier lugar de esta Especificacin de Requerimientos de Software. Cada documento debe ser identificado por ttulo, edicin (si es aplicable), fecha, y editorial. Especificar las fuentes de donde se pueden obtener estas referencias, esta informacin puede ser entregada como referencia a un apndice o a otro documento.]

1.5.

Resumen Ejecutivo

[Prrafo NO obligatorio.] [Esta subseccin debe describir el resto del documento conteniendo y explicando cmo est organizado.]

171 2. Descripcin General

[Se considera en esta parte la descripcin de los factores principales que afectan al espacio de la solucin. Incluya aquellos tems como perspectiva del producto, funciones del producto, caractersticas de usuario, limitaciones, supuestos y dependencias. No se incluye en esta seccin la descripcin de los requerimientos.]

2.1.

Especificacin de Funcionalidades

[Prrafo obligatorio.] [Si usa el modelado de casos de uso, esta seccin debe contener la referencia de ste, y una descripcin o resumen del modelo o del subconjunto ms representativo del mismo. Esto incluye una lista de nombres y breves descripciones de los casos de uso, actores, diagramas aplicables y relaciones... En caso de no existir modelo de caso de uso se deben referenciar todas las descripciones existentes de las funcionalidades, ya sean minutas de reunin, correos electrnicos, etc. Es necesario agregar esas descripciones en esta seccin y en el seccin 1.4 Referencias del documento se necesitan mencionar todos los fuentes de los requerimientos.] [Este punto se puede reemplazar con la plantilla Excel de Administracin de Requerimientos haciendo referencia.]

2.2.

Supuestos y Dependencias

[Prrafo obligatorio.] [Esta seccin describe cualquier factibilidad tcnica clave, disponibilidad de componentes o subsistemas, u otros supuestos realizados en los cuales la viabilidad del software descrito en esta Especificacin de Requerimientos de Software se base.]

2.3. Acuerdos con el Cliente para la Administracin de Requerimientos

[Prrafo obligatorio.] [En esta seccin se define como se tratarn los cambios de los requerimientos. Normalmente en la Orden de Servicio se define un porcentaje como cota para realizar posibles cambios en los requerimientos. Este impacto se mide en la cantidad de horas/hombre que requiera esta modificacin.]

3. Especificacin de Requerimientos
[Esta seccin debe describir detalladamente todos los requerimientos de software, de forma de permitir a los diseadores, disear el sistema para satisfacer los requerimientos como tambin a los probadores disear un plan de test adecuado para poder verificar el cumplimiento de los mismos. Cuando se usa el modelado de casos de uso, estos requerimientos se capturan en los casos de uso, y en las especificaciones adicionales aplicables, Si no se usa el modelado de casos de uso, la definicin de especificaciones adicionales debe insertarse directamente aqu.]

3.1.

Reportes de Casos de Uso

[Prrafo obligatorio.] [En modelado de casos de uso, ellos definen la mayora de los requerimientos funcionales del sistema, y algunos requerimientos no funcionales. Para cada caso de uso en el modelo superior, o subconjunto del mismo, refirase o cierre, el

172
reporte de caso de uso en esta seccin. Asegrese de que cada requerimiento est claramente etiquetado.] [Para proyectos pequeos, de duracin menor a un mes y un equipo de menos de 3 personas, este prrafo se puede reemplazar con una referencia a documento Anlisis Preliminar.]

3.2.

Requerimientos Funcionales

[Prrafo obligatorio.] [En esta seccin se deben describir todos los requerimientos funcionales en forma detallada, esta seccin debe ser usada cuando las funcionalidades no son transacciones de algn framework transaccional. La descripcin debe ser suficientemente clara para permitir a los diseadores hacer un diseo apropiado, los programadores entender funcionalidad y a los probadores elaborar un plan de pruebas apropiado.] [Datos a Definir por cada requerimiento no Funcional] Campo En qu Consiste Los dgitos deben ir separados por "comas". El primer dgito indica la fase en que se ingres el requerimiento. El segundo dgito indica la iteracin. El tercer digito indica el ID del requerimiento, el cual no se puede repetir en ninguna fase ni iteracin anterior (ES UNICO). El cuarto indica la versin para un mismo requerimiento, en caso de que un requerimiento sea modificado. Fecha en que se solicita el requerimiento o cambio. Corresponde al requerimiento listado en la planilla TEC Puede tener tres valores: I : Requerimiento Inicial N : Nuevo Requerimiento M: Modificacin del Requerimiento Referencia a artefacto donde esta requerimiento escrito. La referencia tiene siguiente formato: <direccin relativa>\<nombre de artefacto> Quien pide el requerimiento Quien es asignado para administrar y resolver requerimiento Prioridad asignada segn: A: Alto M: Medio B: Bajo Corresponde al estado actual del requerimiento reportado, segn: PROPUESTO ACEPTADO ASIGNADO CONSTRUIDO VALIDADO REVISADO CANCELADO TERMINADO Tipo de Modificacin del requerimiento, se aplica solo para cambios. Segn: FUNCIONAL NO FUNCIONAL

Nmero (F,I,ID,V)

Fecha Funcionalidad Tipo

Origen Pedido por Asignado a Prioridad

Estado

Categora

173
DE PROCESO TCNICO Artefactos que se necesitan cambiar. Incluido componentes, cdigo, pginas, (no solo documentos). Por defecto: UNKNOWN ALTO MEDIO BAJO Breve descripcin del requerimiento - texto de requerimiento Fecha inicio de la implementacin Fecha final de la implementacin Estimacin de duracin de requerimiento en horas. Tiempo en minutas que se gasto para cambiar la planilla (ingresar, borrar o cambiar requerimientos).

Impacto del Requerimiento

Descripcin Fecha de Inicio Fecha de Trmino Duracin (horas) Tiempo de Cambios (*)

3.3.

Requerimientos Adicionales

[Prrafo obligatorio.] [Las especificaciones adicionales capturan requerimientos que no estn incluidos en los casos de uso. Los requerimientos especficos de las Especificaciones adicionales, que son aplicables a este subsistema o caracterstica. Estos pueden ser capturados directamente en este documento o referenciarse en Especificaciones Adicionales por separado. Asegrese de que cada requerimiento est claramente etiquetado.] [Requerimientos adicionales son tambin requerimientos funcionales.]

3.4.

Requerimientos no Funcionales

[Prrafo obligatorio.] [En esta seccin se describen los aspectos no funcionales, tales como tiempo de respuesta, esttica de la aplicacin, facilidad de navegacin, etc.] [Datos a Definir por cada requerimiento no Funcional.] Campo En qu Consiste Los dgitos deben ir separados por "comas". El primer dgito indica la fase en que se ingres el requerimiento. El segundo dgito indica la iteracin. El tercer digito indica el ID del requerimiento, el cual no se puede repetir en ninguna fase ni iteracin anterior (ES UNICO). El cuarto indica la versin para un mismo requerimiento, en caso de que un requerimiento sea modificado. Fecha en que se solicita el requerimiento o cambio. Corresponde al requerimiento listado en la planilla TEC Puede tener tres valores: I : Requerimiento Inicial N : Nuevo Requerimiento M: Modificacin del Requerimiento Referencia a artefacto donde esta requerimiento escrito. La referencia tiene siguiente formato: <direccin relativa>\<nombre de artefacto> Quien pide el requerimiento Quien es asignado para administrar y resolver requerimiento

Nmero (F,I,ID,V)

Fecha Funcionalidad Tipo

Origen Pedido por Asignado a

174
Prioridad asignada segn: A: Alto M: Medio B: Bajo Corresponde al estado actual del requerimiento reportado, segn: PROPUESTO ACEPTADO ASIGNADO CONSTRUIDO VALIDADO REVISADO CANCELADO TERMINADO Tipo de Modificacin del requerimiento, se aplica solo para cambios. Segn: FUNCIONAL NO FUNCIONAL DE PROCESO TCNICO Artefactos que se necesitan cambiar. Incluido componentes, cdigo, paginas, (no solo documentos). Por defecto: UNKNOWN ALTO MEDIO BAJO Breve descripcin del requerimiento - texto de requerimiento Fecha inicio de la implementacin Fecha final de la implementacin Estimacin de duracin de requerimiento en horas. Tiempo en minutas que se gasto para cambiar la planilla (ingresar, borrar o cambiar requerimientos).

Prioridad

Estado

Categora

Impacto del Requerimiento

Descripcin Fecha de Inicio Fecha de Trmino Duracin (horas) Tiempo de Cambios (*)

3.5.

Requerimientos Tcnicos

[Prrafo obligatorio.] [En esta seccin se describen los requerimientos tcnicos, tales como sistema operativo, plataforma de arquitectura, por ejemplo WebSphere, .NET, etc.] [Este punto se puede reemplazar referenciando a Administracin de Requerimientos.] la plantilla Excel de

3.6.

Requerimientos de Proceso

[Prrafo obligatorio.] [En esta seccin se describen los requerimientos de proceso. Por ejemplo, para desarrollo se necesita usar proceso de desarrollo en cascadas, RUP, XP, ITDA-KP, Este prrafo se puede relacionar con artefacto Configuracin del Proceso o con el Plan del Proyecto.] [Este punto se puede reemplazar haciendo referencia a Administracin de Requerimientos.] la plantilla Excel de

4. Administracin de Requerimientos
[Prrafo obligatorio.]

175
[En esta seccin se especifica cmo se realizara el seguimiento de los requerimientos, y los documentos asociados a este seguimiento, as mismo, en esta seccin se describen como se realizaran los posibles cambios o nuevas modificaciones existentes durante el proyecto. Esto normalmente se puede seguir con la plantilla de Administracin de Requerimientos al cual se debe referenciar en esta seccin.] Normalmente estos controles se llevan mediante una Excel para mayor facilidad en el control y la administracin

4.1.

Conjunto de Requisitos Resultado Caracterstica R1 R2 R3 Completos Consistentes Correctos Priorizados Comprensibles Organizados Requisitos Individuales
Completo Trazabilidad hacia Sin ambigedad Verificable

Observaciones

4.2.

Comprensible Independiente del Diseo e Implementar R1 R2 R3 R1 R2 R3

Caso de uso / Requisito (1)

Adelante

Atrs

R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3 R1 R2 R3

(1) Requisito hace referencia a los No-Funcionales y a los Funcionales cuando son expresados en sentencias y no en C

176

4.3.

Criterios de Revisin de Requerimientos

Aplica a especificacin en Caso de Sentencia Uso Accin a seguir si NO cumple

APLICAN AL CONJUNTO DE REQUISITOS Se toman todos los requisitos de software del sistema. Estos pueden estar dados en casos de uso o sentencias. El conjunto de requisitos de software esta completo si: a). Incluye requisitos orientados a: funcionalidad, desempeo, confiabilidad, usabilidad, disponibilidad, manejo x de errores, configuracin, mantenimiento, carga de datos, respaldo, depuracin e interfaces externas. b). Todos y cada uno de los requisitos de software estn asociados al menos a una necesidad del negocio, caracterstica del producto o requisito de usuario. Debido a x que la trazabilidad es bi-direccional tambin debe verificarse que cada necesidad tenga asociados al menos una caracterstica y requisito de software. c). En los casos de uso estn claramente descritos los x actores que participan en ellos. El conjunto de requisitos de software es consistente si: a). El diagrama de casos de uso es consistente con las convenciones de UML, u otro lenguaje de modelado bien definido, dnde son bien empleados los elementos grficos x que representan las relaciones, los actores y los casos de uso b). No hay comportamiento comn especificado en dos x requisitos diferentes c). No hay conflicto entre los rasgos de un comportamiento. Por ejemplo, una precondicin del caso de uso 'X' implica que el comportamiento del caso de uso 'Y' debe haber ocurrido, y una precondicin del caso de uso 'Y' implica que se haya dado algn comportamiento del caso de uso 'X'. x Otro ejemplo: un requisito define que siempre debe darse el comportamiento 'A' antes que el comportamiento 'B', pero otro requisito indica que el comportamiento 'B' siempre debe ocurrir antes que el 'A'. d). No hay ms de un requisitos que enuncia el mismo comportamiento u objetivo pero utilizando diferentes x trminos. e). Los requisitos de un paquete dado son consistentes con x el tema o idea capturada en el nombre del paquete f). Todos los casos de uso estn asociados por lo menos con un actor. Si no es as, el caso de uso debe estar x asociado con otros casos de uso va relaciones de extensin, inclusin, generalizacin. El conjunto de requisitos de software es correcto si: Correcto a). Cada requisito representa una parte necesaria para el x sistema a construir. b). Los requisitos han sido revisados y aprobados por el x cliente / usuario El conjunto de requisitos de software esta priorizado si: Priorizados a). Est definida la importancia relativa de cada requisito. Por ejemplo, puede ser priorizado por importancia para el x negocio, complejidad para implantar, riesgo arquitectnico, costo de desarrollar, estabilidad del requisito, entre otros. x x ALERTAR DETENER x

ALERTAR

Completos

DETENER

ALERTAR

ALERTAR

ALERTAR

Consistente

DETENER

ALERTAR

ALERTAR

ALERTAR

ALERTAR

177

El conjunto de requisitos de software es comprensible si: a). Presenta claramente el comportamiento del sistema. Es decir, es fcil de entender lo que el sistema hace al revisar x el modelo. b). En los diagramas de casos de uso no hay largas x cadenas de relaciones de inclusin y extensin. c). No es presentado un requisito por cada pantallas de x interfaz grfica. Comprensible d). En los diagramas de casos de uso no hay descomposicin funcional o flujo de trabajo, cuyos sntomas son: casos de uso demasiado pequeos; muchos casos de uso; dificultad para entender el modelo; nombres de casos x de uso como: operacin + objeto o funcin + dato (por ejemplo Insertar tarjeta); asociaciones con punta de flecha (o sin ella) entre casos de uso semejando un flujo de actividades e). El modelo y/o diagrama tiene una seccin donde describe el contenido del mismo, por ejemplo la secuencia x ms comn de los casos de uso. El conjunto de requisitos de software es organizado si: a). Son organizados usando mltiples diagramas o paquetes para dividir y organizar la funcionalidad del sistema hacindolos comprensibles para los interesados. Cuando el modelo es grande y/o las responsabilidades son distribuidas en diversas partes del modelo, deben utilizarse paquetes de x requisitos de forma que sean intuitivos y hagan que el modelo sea fcil de entender. Ejemplos de paquetes son aquellos organizados por rea funcional, por actor, por dependencia, por relacin entre los actores y el sistema, por iteracin, entre otros. x x ALERTAR

ALERTAR ALERTAR

ALERTAR

ALERTAR

Organizados

DETENER, si no hay al menos un (1) diagrama de CU

APLICAN A REQUISITOS INDIVIDUALES Aplica a especificacin en Caso de Sentencia Uso Accin a seguir si NO cumple

Los requisitos de software pueden estar dados en casos de uso o sentencias. Un requisito de software esta completo si:

a). El caso de uso proporciona las interacciones y comportamiento x necesarios para satisfacer las metas u objetivos de los actores b). El requisito contiene nicamente la funcionalidad que ser x realizada por el sistema. c). El caso de uso tiene claramente enunciado: Propsito, x Precondicin, Pos condicin, Flujos alternos y de excepciones Completo d). Para cada caso de uso estn definidas las respuestas del software a todas las entradas del actor tanto para flujos vlidos como no x vlidos. e). El requisito expresado como sentencia breve (tradicional) tiene definidas las respuestas del software tanto para comportamiento vlidos como no vlidos. f). El requisito expresado como sentencia breve (tradicional) tiene en el enunciado el tipo de usuario, resultado deseado, objeto y calificador medible. x

DETENER

DETENER

DETENER

DETENER

DETENER

DETENER

178

Un requisito de software es rastreable hacia adelante si: Trazabilidad hacia adelante a). El tiene un nico nombre o nmero de referencia as como los componentes de diseo, mdulos de implementacin y todos los elementos dnde este es referenciado. Un requisito de software es rastreable hacia atrs si: a). Tiene referencia explcita a su origen o fuente. Un requisito de software no es ambiguo si: a). Tiene una sola interpretacin por usuarios e implementadores. Para ello no deben existir palabras o frases que favorezcan la mltiple interpretacin, tales como: Conjuncin (y, con, tambin), ya que posiblemente representa varios requisitos; Disyuncin (o), ya que posiblemente no representa un comportamiento concreto; y palabras como usualmente, con frecuencia, normalmente, flexible, verstil, eficiente, amigable al usuario y que signifiquen posibilidad (puede, tal vez, probablemente). b). No es excesivamente detallado con mltiple y profundo anidamiento, sea por inclusiones en los casos de uso o por jerarqua en las sentencias. Un requisito de software es verificable si: a). No existen palabras o frases no verificables tales como: funciona bien, rpido, buen desempeo, usualmente ocurre, entre otras. Verificable b). El requisito est enunciado en trminos cuantificables y verificables c). En los casos de uso las precondiciones y pos-condiciones estn declaradas de forma que pueden ser probadas. x x DETENER

ALERTA

Trazabilidad hacia atrs

ALERTA

Sin ambigedad

ALERTA

ALERTA

DETENER

DETENER

Un requisito de software es independiente del diseo e implementacin si: Independiente a). En el requisito NO son empleadas palabras o frases tcnicas, tales Diseo e implementacin como: nombre de componentes, campos de bases de datos, objetos de software, restriccin de diseo, entre otros. Un requisito de software es comprensible si: a). El caso de uso es auto-explicados. Esto es, las anotaciones, modelos y formato de los casos de uso deben permitir que el interesado revise, entienda y valide los casos de uso con una mnima cantidad de esfuerzo. b). El requisito est escrito en el 'lenguaje' de los clientes y usuarios, utilizando trminos que son usados en el dominio del negocio (Glosario).

ALERTA

ALERTA

Comprensible

ALERTA

179

8.4.5 Plantilla de Anlisis Preliminar

<Nombre del Proyecto> Anlisis Preliminar Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de base para la confeccin del documento Anlisis Preliminar. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. El formato del texto debe tener tipo de letra verdana.]

180

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

181

ndice
1 Introduccin 1.1 Propsito 1.2 mbito 1.3 Referencias 1.4 Resumen Ejecutivo 2 Requerimientos 2.1 Casos de Uso de la funcionalidad <Nombre de Funcionalidad> 2.1.1 Actores 2.1.2 Casos de Uso 2.2 Casos de Uso de la funcionalidad <Nombre de Funcionalidad> 2.2.1 Actores 2.2.2 Casos de Uso 3 Anlisis Preliminar 3.1 Modelo de Anlisis de Arquitectura Actual 3.2 Modelo de Anlisis de Arquitectura Propuesta 3.3 Diagrama de secuencia de Escenario Tpico para la funcionalidad <Nombre de Funcionalidad> 3.4 Diagrama de Despliegue (Deployment) 4 Descripcin de la Solucin Propuesta 182 182 182 182 182 182 182 182 182 182 182 182 183 183 183 183 183 183

182

Anlisis Preliminar
1. Introduccin
[La introduccin del Anlisis Preliminar provee un resumen del documento completo. Presente cualquier informacin que el lector pueda necesitar para entender el documento en esta seccin.] 1.1. 1.2. Propsito [Especifique el propsito del Anlisis Preliminar.] mbito [Una breve descripcin del mbito de este Anlisis Preliminar; que proyecto(s) estn asociados a l, o cualquier cosa que pueda versen afectada o influenciada por este documento.] 1.3. Referencias [Esta subseccin provee una lista completa de todos los documentos referenciados en cualquier parte de este Anlisis Preliminar. Identifique cada documento por ttulo, nmero de edicin (si es aplicable), y editorial. Especifique las fuentes de donde pueden obtenerse estas referencias. Esta informacin puede ser entregada a modo de referencia a un apndice o a otro documento.] Resumen Ejecutivo [Esta subseccin describe el contenido del resto del Anlisis Preliminar, explica cmo est organizado el documento.] y

1.4.

2. Requerimientos
[Desarrolle en esta seccin los anlisis bsicos de casos de uso, puede aadir o eliminar subsecciones segn sea necesario] 2.1. Casos de Uso de la funcionalidad <Nombre de Funcionalidad> [Inserte el diagrama del Modelo de Casos de Uso correspondiente a la funcionalidad <Nombre de funcionalidad>. Puede usar el siguiente texto como punto de partida: El modelo de los casos de uso (<Numero de la Figura>) representa la primera abstraccin de los requerimientos del sistema de alto nivel, con sus descripciones.]

Actores
[Nombre los actores que interactan con el sistema y una describa brevemente la funcin de cada actor]

Casos de Uso
[Nombre y describa los distintos correspondiente a esta subseccin] 2.2. casos de uso mostrados en la figura

Casos de Uso de la funcionalidad <Nombre de Funcionalidad> [Para la explicacin de estos puntos, refirase al punto 2.1]

Actores Casos de Uso

183 3. Anlisis Preliminar

3.1. Modelo de Anlisis de Arquitectura Actual [Incluya un diagrama del modelo de Anlisis de la arquitectura actual del sistema (si corresponde), describa brevemente la generalidad del modelo.] 3.2. Modelo de Anlisis de Arquitectura Propuesta [Incluya un diagrama del modelo de Anlisis de la arquitectura propuesto como solucin, describa brevemente la generalidad del modelo.] Diagrama de secuencia de Escenario Tpico para la funcionalidad <Nombre de Funcionalidad> [Incluya un diagrama de secuencia para el caso tpico de cada funcionalidad, no es obligatorio el uso de este diagrama.] 3.4. Diagrama de Despliegue [Incluya un diagrama de despliegue para el sistema]

3.3.

4. Descripcin de la Solucin Propuesta

[Ingrese la informacin de cada modulo de la solucin propuesta, la columna llamada Estimacin del Esfuerzo es para informacin interna de la empresa y debe ser eliminada al momento de presentar este documento al cliente]

Mdulo
[Nombre de cada modulo mostrado en el diagrama del Modelo de Anlisis]

Descripcin
[Breve descripcin de la funcionalidad que cumple este modulo]

Solucin
[Nombre de la solucion propuesta, por ejemplo el lenguaje o herramienta]

Estimacin del Esfuerzo

[Cantidad de esfuerzo necesario, estimado por el arquitecto, para desarrollar la solucin]

184

8.4.6 Plantilla Solicitud de Requerimientos

<Nombre Del Proyecto> Solicitud de Requerimientos Versin <1.1.0>

[Esta plantilla tiene por finalidad servir de base para la confeccin del documento Solicitud de requerimientos. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento.]

185

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin <Detalles> Autor <Nombre>

186

Solicitud de Requerimiento
No. Interno: Detalle del Solicitante Nombre: Unidad: Gerencia de Divisin: Detalle del Requerimiento Tipo Sistema Nuevo Cambio requerido por un Cliente Correccin de un problema presentado con el sistema Descripcin: Prioridad:

Fecha solicitud: Centro Costo: Anexo:

Cambio Normativo Otros

Nombre del Sistema: ____________________________________________________ rea de Aplicacin: _____________________________________________________ Explicacin detallada del requerimiento: (Si es necesario incluya un anexo)

Justificacin: (Indique las razones, que a su juicio, justifican el requerimiento)

Comit Control de Cambios: Firma: Aprobado Comentarios: Rechazado Fecha:

187

Solo para Uso Interno de la Organizacin

Evaluacin Evaluado por: Recursos Externos: SI NO Costo total estimado: Firma: Recursos internos recomendados: Fecha:

Das/Hombre esfuerzo estimados:

Descripcin del Impacto: (Programas y archivos a crear, modificar, etc.)

Nombre:

Firma:

Fecha:

Fase de Ejecucin Jefe de Proyecto Asignado:

Firma:

Fecha de Inicio:

Empresa o recursos internos asignados:

Das/hombre reales:

Comentarios

Fecha Entrega a Pruebas:

Firma:

Fecha aprobacin pruebas: (a llenar por Ingeniera de Procesos)

Firma:

Fecha aprobacin formalidades liberacin: (a llenar por Informtica)

Firma:

Fecha Liberacin: (Comit Control de Cambios)

Firma:

188

8.4.7 Plantilla Check List del Ambiente

<Nombre del Proyecto> Checklist de Ambiente <Versin 1.1.0>

[Nota: Esta plantilla tiene por finalidad servir de base para la confeccin del documento Checklist de Ambiente. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. El formato del texto debe tener tipo de letra verdana.]

189

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

190

ndice
1 Introduccin 1.1 Propsito 1.2 mbito 1.3 Definiciones, acrnimos y abreviaciones. 1.4 Referencias 1.5 Resumen Ejecutivo 2 Check Lists 2.1 General 2.2 Ambiente de Desarrollo 2.3 Ambiente de Test 2.4 Ambiente de Produccin 2.5 Ambiente de General 191 191 191 191 191 191 192 192 192 193 193 194

191

Check List
1. Introduccin
1.1. Propsito [Una descripcin breve acerca del propsito de este Checklist. Tambin agregue una descripcin breve de a qu se aplica la Checklist; qu se ve afectado o influenciado por este documento.] 1.2. mbito [Describa el alcance de este Checklist; qu proyectos estn asociados a el y cualquier cosa que se vea afectada o influenciada por este documento.] Definiciones, acrnimos y abreviaciones. [Esta sub-seccin provee las definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente el Checklist. Esta informacin puede entregarse a modo de referencia al glosario del proyecto.] Referencias [Esta sub-seccin provee una completa lista de todos los documentos referenciados en cualquier punto del Checklist. Identifique cada documento por titulo, nmero de edicin (si es aplicable), fecha, y editorial. Especifique las fuentes de donde pueden obtenerse estas referencias.] 1.5. Resumen Ejecutivo [Describa brevemente que contiene el resto del Checklist y explique cmo est organizado este documento.]

1.3.

1.4.

192 2. Checklists
2.1. General

General Organigrama

Check

Rol
[Rol del Responsable]

Comentario
[Aada cualquier comentario correspondiente a este campo como sugerencias, tareas, descripciones o herramientas]

Disponibilidad Accesibilidad Seguridad Solicitudes de Necesidades Periodicidad y Participantes de Reuniones de Coordinacin Planes de Backup y Restore para ambiente de desarrollo y test
2.2.

Ambiente de Desarrollo

Ambiente de desarrollo Mquinas

Check Inicial

Check Final

Rol
[Rol del Responsable]

Comentario
[Aada cualquier comentario correspondiente a este campo como sugerencias, tareas, descripciones o herramientas]

Estaciones de trabajo Servidor web Servidor DB Servidor de componentes Servidor para SCM Caracterstica de la Red

193 Ambiente de desarrollo Software Sistema operativo Software para desarrollo

2.3.

Check Inicial

Check Final

Rol

Comentario

Ambiente de Pruebas

Ambiente de Pruebas Mquinas

Check Inicial

Check Final

Rol
[Rol del Responsable]

Comentario
[Aada cualquier comentario correspondiente a este campo como sugerencias, tareas, descripciones o herramientas]

Estaciones de trabajo Servidor Web Servidor DB Servidor de componentes Herramientas Herramientas para pruebas

2.4.

Ambiente de Produccin

Ambiente de Produccin Mquinas

Check Inicial

Check Final

Rol
[Rol del Responsable]

Comentario
[Aada cualquier comentario correspondiente a este campo como sugerencias, tareas, descripciones o herramientas]

Servidor Firewall Ambiente de produccin

Check Inicial

Check Final Rol Comentario

194 Servidor Web Servidor DB Servidor de componentes Schema de seguridad Conectividad Software Sistema operativo Firewall Servidor Web
2.5. Ambiente en General

Ambientes en General Protocolos

Check Inicial

Check Final

Rol
[Rol del Responsable]

Comentario
[Aada cualquier comentario correspondiente a este campo como sugerencias, tareas, descripciones o herramientas]

Topologa de la red en produccin Relacin Datos - Tablas Interfaces Diagramas de Navegacin

195

8.4.8 Plantilla Plan de Especificacin del Ambiente

<Nombre del proyecto> Plan de Especificacin de Ambiente Versin <1.1.0>

[Nota: Esta plantilla tiene por finalidad servir de base para la confeccin del documento Especificacin de Ambiente. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. El formato del texto debe tener tipo de letra verdana.]

196

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

197

ndice
1. Introduccin 1.1 Propsito 1.2 mbito 1.3 Definiciones, Acrnimos y Abreviaciones 1.4 Referencias 1.5 Resumen ejecutivo 2. Recursos 2.1 Recursos computacionales crticos 2.2 Personal y Responsables 3. Modelo de Ambientes 3.1 Ambiente de Desarrollo 3.2 Ambiente de Pruebas 3.3 Ambiente de Produccin 198 198 198 198 198 198 198 198 198 198 198 198 198

198

Especificacin de Ambiente
1. Introduccin
[La introduccin de la Especificacin de Ambiente proporciona una descripcin del documento completo. Este incluye el propsito, mbito, definiciones, acrnimos, abreviaciones, referencias, y una descripcin de este documento.] 2.6. Propsito [Especifica el propsito de este documento.] 2.7. mbito [Es una descripcin del mbito de esta Especificacin de Ambiente; que proyectos estn asociados con cualquier cosa que afecte o influya este documento.] 2.8. Definiciones, Acrnimos y Abreviaciones [Definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente la Especificacin de Ambiente. Esta informacin puede ser obtenida del Glosario del proyecto.] 2.9. Referencias [Lista completa de todos los documentos referenciados en cualquier lugar de la Especificacin de Ambiente. Identificando cada uno por ttulo, numero de edicin si es aplicable, fecha, y editorial. Especificando las fuentes de donde se pueden obtener las referencias. Ejemplo: [1] Visin del proyecto. [2] Lista de riesgos del proyecto.] 2.10. Resumen ejecutivo [Describe qu contiene el resto del documento y explica cmo est organizado.]

3. Recursos
3.1. Recursos computacionales crticos [Esta sub-seccin describe qu son recursos computacionales crticos tales como hardware, tiempo de disponibilidad, etc. Por ejemplo: para finalizar el proyecto faltan computadores para pruebas y falta acceso de mainframe, o para produccin se necesita un nuevo servidor. Si para un proyecto existen recursos computacionales crticos se necesitan poner como riesgo dentro de artefacto Lista de riesgos]. 3.2. Personal y Responsables [Describa en este punto los nombres de las personas asignadas a cada rol.]

4. Modelo de Ambientes
[Contiene diagramas de despliegue para cada ambiente. El modelo de ambiente contiene una descripcin detallada de aspectos tales como hardware y software] 4.1. Ambiente de Desarrollo [Incluya aqu los diagramas de despliegue correspondientes al ambiente de desarrollo] 4.2. Ambiente de Pruebas [Incluya aqu los diagramas de despliegue correspondientes al ambiente de pruebas] 4.3. Ambiente de Produccin [Incluya aqu los diagramas de produccin] despliegue correspondientes al ambiente de

199

8.4.9 Plantilla Plan del Desarrollo de Software

<Nombre del Proyecto> Plan de Desarrollo del Software Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de base para la confeccin del documento Plan de Desarrollo del Software. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]

[Nota: Para proyectos pequeos, los artefactos que deben estar contenidos en este plan y no como documentos independientes son: - Mapeo de Roles - Carta Gantt (en forma de tabla) - Lista de Riesgos - Plan SQA - Plan SCM. Los documentos obligatorios para proyectos pequeos, que no estn contenidos en este plan son: - Anlisis Preliminar - TEC - Configuracin del Proceso. ]

200

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

201

ndice
1 Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones, acrnimos y abreviaciones. 203 1.4 Referencias 1.5 Resumen Ejecutivo Resumen del Proyecto 2.1 Propsito del Proyecto, mbito, y Objetivos 2.2 Supuestos y Lmites 2.3 Entregables del Proyecto 2.4 Evolucin del Plan de Desarrollo del Software Organizacin del Proyecto 3.1 Estructura Organizacional 3.2 Interfaces externas 3.3 Roles y Responsabilidades Gestin del Proceso 4.1 Estimaciones del Proyecto 4.2 Plan de Desarrollo del Software 4.2.1 Plan de la fase 4.2.2 Objetivos de las iteraciones 4.2.3 Versiones 4.2.4 Agenda del Proyecto 4.2.5 Recursos del Proyecto 4.2.6 Presupuesto 4.3 Plan de Iteracin 4.4 Monitorizacin y Control del Proyecto 4.4.1 Plan de Administracin de Requerimientos 4.4.2 Agenda del Plan de Control 4.4.3 Plan de Control de Presupuesto 4.4.4 Plan de Control de Calidad 4.4.5 Plan de Reporte 4.4.6 Plan de Medicin 4.5 Plan de Administracin de Riesgos 4.6 Plan de Clausura Plan de Procesos Tcnicos 5.1 Configuracin de Proyecto 5.2 Mtodos, Herramientas, y Tcnicas 5.3 Plan de Infraestructura 5.4 Plan de Aceptacin del Producto Plan de Proceso de Soporte 6.1 Plan de CM 6.2 Plan de Evaluacin 6.3 Plan de Documentacin 6.4 Plan de Garanta de Calidad (QA) 203 203 203

203 204 205 205 205 205 208 208 208 208 209 209 209 209 209 211 211 211 214 214 214 215 215 215 215 215 215 216 216 216 216 216 216 216 216 217 217 217 217 217

202 6.5 Plan de Resolucin de Problemas 6.6 Plan Administracin de Subcontratista 6.7 Plan de Mejora de los Procesos 7 Planes Adicionales 8 Anexos 217 217 217 218 218

203

Plan de Desarrollo del Software

5. Introduccin
[Una descripcin breve acerca del propsito de Plan de Desarrollo del Software. Agregue tambin una descripcin breve de a que se aplica el Plan de Desarrollo del Software; que se ve afectado o influenciado por este documento.]

Este documento provee una visin global del enfoque de desarrollo propuesto basado en una metodologa de Rational Unified Process en la que nicamente se proceder a cumplir con las tres primeras fases que marca la metodologa, constando nicamente en la tercera fase de dos iteraciones. Es importante destacar esto puesto que utilizaremos la terminologa RUP en este documento. Se incluir el detalle para las fases de Inicio y Elaboracin y adicionalmente se esbozarn las fases posteriores de Construccin y Transicin para dar una visin global de todo proceso. El enfoque desarrollo propuesto constituye una configuracin del proceso RUP de acuerdo a las caractersticas del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos (entregables) que sern generados. Este documento es a su vez uno de los artefactos de RUP.
5.1. Propsito

El propsito de este documento es permitir organizar, controlar y administrar la documentacin referente al proyecto [Nombre del Proyecto]. En este documento se encuentra la referencia a todos los planes y documentos generados durante el proyecto los cuales se irn agregando a lo largo del proyecto.
5.2. Alcance [Prrafo obligatorio.] [Describa el alcance de este Plan de Desarrollo del Software; que proyectos estn asociados a l y cualquier elemento que se vea afectado o influenciado por este documento.] 5.3. Definiciones, acrnimos y abreviaciones. [Prrafo obligatorio si existen trminos, definiciones, acrnimos abreviaciones.] [Esta subseccin provee las definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente el Plan de Desarrollo del Software. Esta informacin puede entregarse como una referencia al Glosario del proyecto.] [Para pequeos proyectos el glosario se puede incorporar en esta subseccin. Si es incorporado en el documento Anlisis Preliminar, se debe hacer referencia.] [Recomendacin: Se sugiere mantener solo un glosario para el proyecto, ste puede mantenerse en el documento Glosario, en el Anlisis Preliminar o en el Plan de Desarrollo del Software.] 5.4. Referencias [Prrafo obligatorio si existen referencias.] [Esta subseccin provee una completa lista de todos los documentos referenciados en cualquier punto del Plan de Desarrollo del Software. Identifique cada o

204
documento por ttulo, nmero de edicin (si es aplicable), fecha, y editorial. Especifique las fuentes de donde pueden obtenerse estas referencias. Esta informacin puede entregarse como una referencia a un apndice o a otro documento. Para el Plan de Desarrollo del Software, la lista de artefactos referenciados debe incluir: 5.5. TEC Plan Asignacin de Roles Plan de Iteracin o Gantt de Iteracin Plan de Administracin de Requerimientos Plan de Mediciones Lista de Riesgos Configuracin de Proyecto Pautas de la Interfaz de Usuario Pautas de Diseo Pautas de Programacin Pautas de Test Gua de Estilo del Manual, Convenciones de Cdigo Especificacin de Ambiente Plan de Aceptacin del Producto Plan de Gestin de la Configuracin Plan de Evaluacin (Slo s ste es un plan por separado normalmente esta es parte del Plan de Desarrollo del Software en la seccin 6.2) Plan de Documentacin Plan SQA Plan de Resolucin de Problemas Plan de Administracin del Subcontratista Plan de Mejora de los Procesos]

Resumen Ejecutivo [Prrafo NO obligatorio.] [Describa brevemente que contiene el resto de Plan de Desarrollo del Software y explique cmo est organizado este documento.]

205 6. Resumen del Proyecto

6.1. Propsito del Proyecto, mbito, y Objetivos [Prrafo obligatorio.] [Describa brevemente el propsito y los objetivos de este proyecto, aada adems una breve descripcin de los entregables y a quien sern entregados.] 6.2. Supuestos y Lmites [Prrafo NO obligatorio.] [Liste los supuestos en los que se ha basado este plan y cualquier limitante, por ejemplo, presupuesto, staff, equipamiento, y fechas, que sean aplicables al proyecto.] 6.3. Entregables del Proyecto [Prrafo NO obligatorio.]

A continuacin se indican y describen cada uno de los artefactos que sern generados y utilizados por el proyecto y que constituyen los entregables. Esta lista constituye la configuracin de RUP desde la perspectiva de artefactos, y que proponemos para este proyecto. Es preciso destacar que de acuerdo a la filosofa de RUP (y de todo proceso iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, slo al trmino del proceso podramos tener una versin definitiva y completa de cada uno de ellos. Sin embargo, el resultado de cada iteracin y los hitos del proyecto estn enfocados a conseguir un cierto grado de completitud y estabilidad de los artefactos. Esto ser indicado ms adelante cuando se presenten los objetivos de cada iteracin.

1) Plan de Desarrollo del Software

Es el presente documento.

2) Modelo de Casos de Uso del Negocio

Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). Permite situar al sistema en el contexto organizacional haciendo nfasis en los objetivos en este mbito. Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos especficos para este modelo.

3) Modelo de Objetos del Negocio

Es un modelo que describe la realizacin de cada caso de uso del negocio, estableciendo los actores internos, la informacin que en trminos generales manipulan y los flujos de trabajo (flujos de trabajo) asociados al caso de uso del negocio. Para la representacin de este modelo se utilizan Diagramas de Colaboracin (para mostrar actores externos, internos y las entidades (informacin) que manipulan, un Diagrama de Clases para mostrar grficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo.

4) Glosario
Es un documento que define los principales trminos Permite establecer una terminologa consensuada. . usados en el proyecto.

206 5) Modelo de Casos de Uso

El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso.

6) Visin
Este documento define la visin del producto desde la perspectiva del cliente, especificando las necesidades y caractersticas del producto. Constituye una base de acuerdo en cuanto a los requisitos del sistema.

7) Especificaciones de Casos de Uso

Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripcin narrativa) se realiza una descripcin detallada utilizando una plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. Tambin, para casos de uso cuyo flujo de eventos sea complejo podr adjuntarse una representacin grfica mediante un Diagrama de Actividad.

8) Especificaciones Adicionales
Este documento capturar todos los requisitos que no han sido incluidos como parte de los casos de uso y se refieren requisitos no-funcionales globales. Dichos requisitos incluyen: requisitos legales o normas, aplicacin de estndares, requisitos de calidad del producto, tales como: confiabilidad, desempeo, etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc.

9) Prototipos de Interfaces de Usuario

Se trata de prototipos que permiten al usuario hacerse una idea ms o menos precisa de las interfaces que proveer el sistema y as, conseguir retroalimentacin de su parte respecto a los requisitos del sistema. Estos prototipos se realizarn como: dibujos a mano en papel, dibujos con alguna herramienta grfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Slo los de este ltimo tipo sern entregados al final de la fase de Elaboracin, los otros sern desechados. Asimismo, este artefacto, ser desechado en la fase de Construccin en la medida que el resultado de las iteraciones vayan desarrollando el producto final.

10) Modelo de Anlisis y Diseo

Este modelo establece la realizacin de los casos de uso en clases y pasando desde una representacin en trminos de anlisis (sin incluir aspectos de implementacin) hacia una de diseo (incluyendo una orientacin hacia el entorno de implementacin), de acuerdo al avance del proyecto.

11) Modelo de Datos

Previendo que la persistencia de la informacin del sistema ser soportada por una base de datos relacional, este modelo describe la representacin lgica de los datos persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se utiliza un archivo UML para Modelado de Datos, para conseguir la representacin de tablas, claves, etc.).

207 12) Modelo de Implementacin Este modelo es una coleccin de componentes y los subsistemas que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de cdigo fuente, y todo otro tipo de ficheros necesarios para la implantacin y despliegue del sistema. (Este modelo es slo una versin preliminar al final de la fase de Elaboracin, posteriormente tiene bastante refinamiento). 13) Modelo de Despliegue
Este modelo muestra el despliegue la configuracin de tipos de nodos del sistema, en los cuales se har el despliegue de los componentes.

14) Casos de Prueba

Cada prueba es especificada mediante un documento que establece las condiciones de ejecucin, las entradas de la prueba, y los resultados esperados. Estos casos de prueba son aplicados como pruebas de regresin en cada iteracin. Cada caso de prueba llevar asociado un procedimiento de prueba con las instrucciones para realizar la prueba, y dependiendo del tipo de prueba dicho procedimiento podr ser automatizable mediante un script de prueba.

15) Solicitud de Cambio

Los cambios propuestos para los artefactos se formalizan mediante este documento. Mediante este documento se hace un seguimiento de los defectos detectados, solicitud de mejoras o cambios en los requisitos del producto. As se provee un registro de decisiones de cambios, de su evaluacin e impacto, y se asegura que stos sean conocidos por el equipo de desarrollo. Los cambios se establecen respecto de la ltima baseline (el estado del conjunto de los artefactos en un momento determinado del proyecto) establecida. En nuestro caso al final de cada iteracin se establecer una baseline.

16) Plan de Iteracin

Es un conjunto de actividades y tareas ordenadas temporalmente, con recursos asignados, dependencias entre ellas. Se realiza para cada iteracin, y para todas las fases.

17) Evaluacin de Iteracin

Este documento incluye le evaluacin de los resultados de cada iteracin, el grado en el cual se han conseguido los objetivos de la iteracin, las lecciones aprendidas y los cambios a ser realizados.

18) Lista de Riesgos

Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados en orden decreciente de importancia y con acciones especficas de contingencia o para su mitigacin.

19) Manual de Instalacin

Este documento incluye las instrucciones para realizar la instalacin del producto.

208 20) Material de Apoyo al Usuario Final

Corresponde a un conjunto de documentos y facilidades de uso del sistema, incluyendo: Guas del Usuario, Guas de Operacin, Guas de Mantenimiento y Sistema de Ayuda en Lnea

21) Producto
Los ficheros del producto empaquetados y almacenadas en un CD con los mecanismos apropiados para facilitar su instalacin. El producto, a partir de la primera iteracin de la fase de Construccin es desarrollado incremental e iterativamente, obtenindose una nueva versin al final de cada iteracin. Los artefactos 19, 20 y 21 se generarn a partir de la fase de Construccin, con lo cual se han incluido aqu slo para dar una visin global de todos los artefactos que se generarn en el proceso de desarrollo. [Liste los artefactos adicionales no incluidos en la lista anterior que se crearan durante el proyecto, incluyendo las fechas objetivo de entrega. Se puede remplazar con una referencia a Gantt de proyecto, solo si Gantt contiene datos de los entregables.]

Fase

Iteracin

Artefacto
[nombre de artefacto]

Fecha de Entrega

6.4.

Evolucin del Plan de Desarrollo del Software [Prrafo obligatorio.] [Tabla de versiones propuestas del Plan de Desarrollo del Software, y el criterio usado para revisiones no programadas y la reedicin de este plan.]

7. Organizacin del Proyecto

7.1. Estructura Organizacional [Prrafo obligatorio.] [Describe la estructura organizacional del equipo del proyecto, incluyendo al administrador y otras autoridades de revisin. Se puede reemplazar con una referencia a documento Asignacin de Roles.] [Para pequeos proyectos la estructura se puede describir dentro del plan y no es necesario crear el documento Asignacin de Roles.] 7.2. Interfaces externas [Prrafo obligatorio.] [Describe como es la interfaz entre el proyecto y los grupos externos. Para cada grupo externo, identifique los nombres de los contactos internos y externos. Se puede reemplazar con una referencia a documento Asignacin de Roles.]

209
[Para Administracin de Requerimientos es necesario establecer quien o quienes sern la contraparte oficial para la aceptacin de cambios o nuevos requerimientos] [Para pequeos proyectos la estructura se puede describir dentro del plan y no es necesario crear el documento Asignacin de Roles.] 7.3. Roles y Responsabilidades [Prrafo obligatorio.] [Identifique las unidades organizacionales del proyecto que son responsables por cada una de las disciplinas, detalles del flujo de trabajo, y procesos de soporte. Se puede reemplazar con una referencia a documento Asignacin de Roles.] [Para pequeos proyectos la estructura se puede describir dentro del plan y no es necesario crear el documento Asignacin de Roles.]

A continuacin se describen las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo durante las fases de Inicio y Elaboracin, de acuerdo con los roles que desempean en RUP.
Puesto Responsabilidad Asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios, y mantiene al equipo del proyecto enfocado en los objetivos. El jefe de proyecto tambin establece un conjunto de prcticas que aseguran la integridad y calidad de los artefactos del proyecto. Adems, se encargar de supervisar el establecimiento de la arquitectura del sistema. Gestin de riesgos. Planificacin y control del proyecto. Captura, especificacin y validacin de requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaboracin del Modelo de Anlisis y Diseo. Colaboracin en la elaboracin de las pruebas funcionales y el modelo de datos. Construccin de prototipos. Colaboracin en la elaboracin de las pruebas funcionales, modelo de datos y en las validaciones con el usuario Gestin de requisitos, gestin de configuracin y cambios, elaboracin del modelo de datos, preparacin de las pruebas funcionales, elaboracin de la documentacin. Elaborar modelos de implementacin y despliegue.

Jefe de Proyecto

Analista de Sistemas

Programador

Ingeniero de Software

8. Gestin del Proceso

8.1. Estimaciones del Proyecto [Provee el costo estimado y agenda del proyecto, tambin las bases para estas estimaciones, los puntos y circunstancias en el proyecto que pueden provocar una re-estimacin de estos datos.] Plan de Desarrollo del Software 1.1.1.Plan de la fase [Para pequeos proyectos este prrafo NO es obligatorio] [Incluya lo siguiente:

8.2.

Estructura de desglose
Estructura de Desglose de Trabajo (WBS). WBS se define como: "Un WBS es una agrupacin de componentes del proyecto orientadas a entregables que organizan y definen el mbito total del proyecto; el trabajo no incluido en el WBS no pertenece al mbito del proyecto. - Project Management Body of Knowledge 2008, Project Management Institute, USA

210
Un TimeLine o Carta Gantt que muestre la posicin en el tiempo de las fases del proyecto o iteraciones Identifique las fases ms importantes y su criterio para ser archivados

Defina cualquier versin importante e interfaces previas a realizar. Se puede reemplazar con una referencia al Gantt del Proyecto si l mismo contiene el plan de cada fase del proyecto.]

El desarrollo se llevar a cabo en base a fases con una o ms iteraciones en cada una de ellas. La siguiente tabla muestra una la distribucin de tiempos y el nmero de iteraciones de cada fase (para las fases de Construccin y Transicin es slo una aproximacin muy preliminar)
Fase Fase de Inicio Fase de Elaboracin Fase de Construccin Fase de Transicin Nro. Iteraciones Duracin

Los hitos que marcan el final de cada fase se describen en la siguiente tabla.
Descripcin Fase de Inicio Hito En esta fase desarrollarn los requisitos del producto desde la perspectiva del usuario, los cuales sern establecidos en el artefacto Visin. Los principales casos de uso sern identificados y se har un refinamiento del Plan de Desarrollo del Proyecto. La aceptacin del cliente /usuario del artefacto Visin y el Plan de Desarrollo marcan el final de esta fase. En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo las partes ms relevantes y / o crticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos que sern implementados en la primera versin de la fase de Construccin deben estar analizados y diseados (en el Modelo de Anlisis / Diseo). La revisin y aceptacin del prototipo de la arquitectura del sistema marca el final de esta fase. En nuestro caso particular, por no incluirse las fases siguientes, la revisin y entrega de todos los artefactos hasta este punto de desarrollo tambin se incluye como hito. La primera iteracin tendr como objetivo la identificacin y especificacin de los principales casos de uso, as como su realizacin preliminar en el Modelo de Anlisis / Diseo, tambin permitir hacer una revisin general del estado de los artefactos hasta este punto y ajustar si es necesario la planificacin para asegurar el cumplimiento de los objetivos. Ambas iteraciones tendrn una duracin de una semana. Durante la fase de construccin se terminan de analizar y disear todos los casos de uso, refinando el Modelo de Anlisis / Diseo. El producto se construye en base a 2 iteraciones, cada una produciendo una versin a la cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboracin de material de apoyo al usuario. El hito que marca el fin de esta fase es la versin de la versin 2.0, con la capacidad operacional parcial del producto que se haya considerado como crtica, lista para ser entregada a los usuarios para pruebas beta. En esta fase se prepararn dos versiones para distribucin, asegurando una implantacin y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega de toda la documentacin del proyecto con los manuales de instalacin y todo el material de apoyo al usuario, la finalizacin del entrenamiento de los usuarios y el empaquetamiento del producto.

Fase de Elaboracin

Fase de Construccin

Fase de Transicin

211
8.2.1.1.
N [el nmero de tarea]
o

Carta Gantt de la fase en forma de tabla

Actividad [nombre de la actividad] Responsable [nombre de la persona que va realizar esta actividad] Fecha Comienzo [fecha] Fecha Trmino [fecha] Artefactos de Entrada [nombre de los artefactos de entrada para la actividad] Artefactos de Salida [nombre de los artefactos de salida para la actividad] A [nmero de la actividad anterior] D [nmero de la actividad siguiente]

[Nombre de la fase]

1.1.2.Objetivos de las iteraciones [Liste los objetivos que debern cumplirse en cada iteracin.]

Fase

Iteracin

Objetivo

1.1.3.Versiones [Describa brevemente cada versin de software y si corresponde a un demo, beta, etc.]

Fase

Iteracin

Release
[Si en fin de la fase o iteracin existe un release de software describir release y su versin, o si un release no existe poner N/A.]

1.1.4.Agenda del Proyecto [Prrafo obligatorio] [Tabla o Diagrama que muestra las fechas objetivo de finalizacin paras las iteraciones y fases, puntos de revisin, demos, y otras fases. Se puede reemplazar con Gantt de Proyecto haciendo referencia.] [Para pequeos proyectos se recomienda llenar la carta Gantt en forma de tabla y no manejar Gantt separado.]

Como se ha comentado, el proceso iterativo e incremental de RUP est caracterizado por la realizacin en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayora de los artefactos son generados muy tempranamente en el proyecto pero van desarrollndose en mayor o menor grado de acuerdo a la fase e iteracin del proyecto. La siguiente figura ilustra este enfoque, en ella lo ensombrecido

212 marca el nfasis de cada disciplina (flujo de trabajo) en un momento determinado del desarrollo.

Para el proyecto, segn lo establecido en la metodologa RUP, se ha establecido el siguiente calendario. La fecha de aprobacin indica cundo el artefacto en cuestin tiene un estado de completitud suficiente para someterse a revisin y aprobacin, pero esto no quita la posibilidad de su posterior refinamiento y cambios.
Disciplinas / Artefactos generados o modificados durante la Fase de Inicio Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visin Modelo de Casos de Uso Especificacin de Casos de Uso Especificaciones Adicionales Anlisis/Diseo Modelo de Anlisis/Diseo Modelo de Datos Implementacin Prototipos de Interfaces de Usuario Modelo de Implementacin Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Gestin de Cambios y Configuracin Gestin del proyecto Plan de Desarrollo del Software en su versin 1.0 y planes de las Iteraciones siguiente fase Durante todo el proyecto siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase siguiente fase Comienzo Aprobacin

213
Ambiente Durante todo el proyecto

Disciplinas / Artefactos generados o modificados durante la Fase de Elaboracin Modelado del Negocio Modelo de Casos de Uso del Negocio y Modelo de Objetos del Negocio Requisitos Glosario Visin Modelo de Casos de Uso Especificacin de Casos de Uso Especificaciones Adicionales Anlisis / Diseo Modelo de Anlisis / Diseo Modelo de Datos Implementacin Prototipos de Interfaces de Usuario Modelo de Implementacin Pruebas Casos de Pruebas Funcionales Despliegue Modelo de Despliegue Gestin de Cambios y Configuracin Gestin del proyecto Plan de Desarrollo del Software en su versin 2.0 y planes de las Iteraciones Ambiente

Comienzo

Aprobacin

aprobado

aprobado aprobado

Revisar en cada iteracin Revisar en cada iteracin

Revisar en cada iteracin Revisar en cada iteracin

Revisar en cada iteracin

Revisar en cada iteracin Durante todo el proyecto

Revisar en cada iteracin Durante todo el proyecto

8.2.1.2.
N [el nmer o de tarea]
o

Carta Gantt del proyecto en forma de tabla

Fase Actividad Respon sable [nom bre de la perso na que va realiz ar esta activi dad] Estado [estad o de la activi dad] Fecha Comienzo [fecha] Fecha Trmino [fecha] Artefactos de Entrada [nombre de los artefactos de entrada para la actividad] Artefactos de Salida [nombre de los artefactos de salida para la actividad] A [nm ero de la activi dad anter ior] D [nmer o de la activida d siguient e]

[nombr [nombre e de la de la fase o acrni mo] actividad]

[Acrnimos para las fases son:

214
C - Concepcin E - Elaboracin Co - Construccin T - Transicin] [Estados de una actividad son: P - Pendiente T - Terminada <Nmero>% - % de trabajo finalizado] 1.1.5.Recursos del Proyecto 8.2.1.3. Plan Del Staff

[Prrafo obligatorio.] [Identifique aqu el tipo de staff requerido y la cantidad, incluyendo cualquier habilidad especial, conocimiento o experiencia, calendarizado por fase del proyecto o iteracin. Se puede reemplazar con una referencia a documento TEC Plan.] 8.2.1.4. Plan de Adquisicin de recursos [Prrafo NO obligatorio. OBLIGATORIO EN CASO DE QUE EXISTA SUBCONTRATACIN] [Describa como se conseguir el personal necesario para el proyecto.] [Describa el plan de entrevistas a realizar entre estas alternativas o proponga la que ms se acomoda al proyecto: a) Entrevista Personal de conocimientos especficos b) Entrevista Grupal para medir interaccin entre pares] 8.2.1.5. Plan de capacitacin [Prrafo NO obligatorio. Es parte de programa de capacitacin de la empresa.] [Liste cualquier tipo de capacitacin especial que requieran los miembros del equipo del proyecto, con fechas objetivo para cuando se debe finalizar esta capacitacin.] 1.1.6.Presupuesto [Prrafo obligatorio.] [Asignacin de Costos versus el Estructura de Desglose del Trabajo y el Plan de Fase. Se puede reemplazar con una referencia a documento TEC Plan.] 8.3. Plan de Iteracin [Para pequeos proyectos este prrafo NO es obligatorio.] [Cada plan de Iteracin debe ser incluido en esta seccin como referencia. Este plan se puede representar con Gantt o un documento separado. Para proyectos pequeos, de duracin menor a un mes y un equipo de menos de 3 personas, se recomienda realizar el plan de iteraciones como parte integral del Plan de Desarrollo del Software.]

215
8.4. Monitorizacin y Control del Proyecto 1.1.7.Plan de Administracin de Requerimientos [Prrafo obligatorio.] [Debe Incluirse como una referencia.] 1.1.8.Agenda del Plan de Control [Prrafo obligatorio.] [Describa que aproximacin se tomara para monitorear el progreso versus la agenda programada para tomar las acciones correctivas que sean necesarias.]
[Se recomienda definir monitorizaciones al menos una vez por fase con el Senior Manager, y en perodos menores a una semana por parte del jefe de proyecto]

1.1.9.Plan de Control de Presupuesto [Prrafo NO obligatorio.] [Describa que aproximacin se tomar para monitorear los gastos vs. el presupuesto del proyecto y como tomar acciones correctivas cuando sea requerido. Para control de presupuesto del proyecto se necesita agregar TEC plan y el mismo usar para ingresar valores en el columna Plan de Presupuesto.]

Fase

Iteracin

Fecha Comienzo Plan Real

Fecha Termino Plan Real

Presupuesto Plan Real Diff.

Suma
1.1.10. Plan de Control de Calidad [Prrafo obligatorio.] [Describa cuando se aplicara el control de calidad y los mtodos que se usaran para los entregables del proyecto. Debe incluir adems como tomar acciones correctivas cuando sea necesario. Se puede reemplazar con referencia a documento Plan SQA.] [Para pequeos proyectos el Plan de SQA se puede describir dentro del Plan de Desarrollo del Software y no mantener documento independiente para Plan de SQA. En este plan e el Plan de Test se pueden incluir como puntos separados, o el Plan de Test se necesita desarrollar como documento separado. Ver prrafo 6.2 del Plan de Desarrollo del Software, Plan de Evaluacin.] 1.1.11. Plan de Reporte [Prrafo NO obligatorio.]

216
[Describa los reportes internos o externos que deben ser generados, incluya tambin la frecuencia y distribucin de cada publicacin.] 1.1.12. Plan de Medicin [Prrafo obligatorio.] [Debe Incluirse como una referencia.] [Para pequeos proyectos este prrafo debe contener una lista de medidas del proyecto.] 8.5. Plan de Administracin de Riesgos [Prrafo obligatorio.] [Debe Incluirse como una referencia a documento Lista de Riesgos.] [Para pequeos proyectos la Lista de Riegos se puede incorporar directamente en este plan, y no es necesario tener un documento separado.] 8.6. Plan de Clausura [Prrafo obligatorio.] [Describa las actividades para la finalizacin en orden del proyecto, incluyendo reasignaciones del staff, archivo de materiales del proyecto, reportes y resmenes post clausura, etc.]

9. Plan de Procesos Tcnicos

9.1. Configuracin de Proyecto [Prrafo obligatorio.] [Debe incluirse como una referencia al documento Configuracin de Proceso.] 9.2. Mtodos, Herramientas, y Tcnicas [Prrafo NO obligatorio.] [Liste los estndares tcnicos del proyecto documentados, como referencia, puede incluir: 9.3. Pautas de la Interfaz de Usuario Pautas del Modelado de Casos de Uso Pautas de Diseo Pautas de Programacin Pautas de Pruebas Gua de estilo del Manual]

Plan de Infraestructura [Prrafo obligatorio.] [Debe Incluirse como una referencia al documento Especificacin de Ambiente. Tambin este prrafo se puede realizar con un diagrama de despliegue.]

9.4.

Plan de Aceptacin del Producto [Prrafo obligatorio.] [Debe Incluirse como una referencia.]

217

10.Plan de Proceso de Soporte

[Prrafo NO obligatorio.] [Debe Incluirse como una referencia.] 10.1. Plan de Comunicaciones [Prrafo obligatorio.] [Debe Incluirse como una referencia a documento Plan SCM.] 10.2. Plan de Evaluacin [Prrafo obligatorio.] [Parte del Plan de Desarrollo del Software, este describe los planes del proyecto para la evaluacin del producto, y cubre las tcnicas, criterios, mtricas, y procedimientos usados para la evaluacin ste debe incluir instrucciones paso a paso, inspecciones, y revisiones. Note que ste es una adicin al plan de test que no est incluida en el Plan de Pruebas del Proyecto.] [Para pequeos proyectos el Plan de Pruebas se puede describir dentro del Plan de Desarrollo del Software y no mantener un documento independiente.] 10.3. Plan de Documentacin [Prrafo obligatorio.] [Este plan define todos los artefactos necesarios para el proyecto. Entregables (ver punto 2.3) es solo una parte del proyecto. Debe Incluirse como una referencia o se puede remplazar con una referencia a la Carta Gantt de Proyecto slo si la Gantt contiene informaciones de documentos de entrada y salida.] 10.4. Plan de Aseguramiento de Calidad (SQA) [Prrafo obligatorio.] [Debe Incluirse como una referencia a documento Plan SQA.] [Para pequeos proyectos el Plan de SQA se puede describir dentro del Plan de Desarrollo del Software y no mantener documento independiente para Plan de SQA. En este plan e el Plan de Test se pueden incluir como puntos separados, o el Plan de Test se necesita desarrollar como documento separado. Ver prrafo 6.2 del Plan de Desarrollo del Software, Plan de Evaluacin.] 10.5. Plan de Resolucin de Problemas [Prrafo obligatorio.] [Debe Incluirse como una referencia a documento Plan SQA.] [Para pequeos proyectos el Plan de SQA se puede describir dentro del Plan de Desarrollo del Software y no en forma separada.] 10.6. Plan Administracin de Subcontratista [Prrafo NO obligatorio.] [Debe Incluirse como una referencia.] 10.7. Plan de Mejora de los Procesos [Prrafo obligatorio.]

218
[Debe Incluirse como una referencia.]

11.Planes Adicionales
[Prrafo NO obligatorio.] [Planes adicionales que pueden ser requeridos por contrato o regularizaciones.]

12.Anexos
[Prrafo NO obligatorio.] [Material adicional para uso del lector de Plan de Desarrollo del Software.]

219

8.4.10 Plantilla Plan de Aseguramiento de la Calidad (SQA)

<Nombre del Proyecto> Plan de Aseguramiento de la Calidad (SQA) Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de base para la confeccin del documento Plan de ASEGURAMIENTO DE LA CALIDAD. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]

220

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

221

ndice
1 Introduccin 1.1 Propsito 1.2 Distribucin 1.3 Definiciones, acrnimos y abreviaciones. 1.4 Referencias 2 ASEGURAMIENTO DE LA CALIDAD Tareas 2.1 Revisiones y Auditorias 2.1.1 Plan de revisin del Proceso 2.1.2 Plan de revisin de Productos de Trabajo de acuerdo a Estndares definidos 2.1.3 Plan de auditorias y revisiones de Administracin de Configuraciones de Software 2.2 Reporte de problemas y seguimiento de las acciones correctivas. 2.2.1 Mecanismos de reportes 2.2.2 Seguimiento de acciones correctivas 2.3 Cambios en Procesos 2.3.1 Metas y Objetivos de los Cambios en el Proceso. 2.3.2 Descripcin de los Cambios 3 Evolucin del Plan 4 Anexos 222 222 222 222 222 223 223 223 223 223 223 223 223 224 224 224 224 224

222

Plan de Aseguramiento se La Calidad

1. Introduccin
12.1. Propsito Definir, planificar y documentar las actividades de Aseguramiento de Calidad del Proceso y Producto para el Proyecto. 12.2. Distribucin

[Describa las reas que se ven afectadas o interesadas por este documento.] 12.3. Definiciones, acrnimos y abreviaciones. [Esta subseccin provee las definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente el Plan de ASEGURAMIENTO DE LA CALIDAD. Esta informacin puede entregarse como una referencia al Glosario del proyecto.] 12.4. Referencias [Esta subseccin provee una completa lista de todos los documentos referenciados en cualquier punto del Plan de ASEGURAMIENTO DE LA CALIDAD. Identifique cada documento por titulo, nmero de edicin (si es aplicable), fecha, y editorial. Especifique las fuentes de donde pueden obtenerse estas referencias. Esta informacin puede entregarse como una referencia a un apndice o a otro documento. Para el Plan del Proyecto, la lista de artefactos referenciados debe incluir: Plan de Iteracin Plan de Administracin de Requerimientos Plan de Mediciones Plan de Administracin de Riesgos Caso de Desarrollo Pautas para el Modelado de Negocio Pautas de la Interfaz de Usuario Pautas de Diseo Pautas de Programacin Pautas de Pruebas Gua de Estilo del Manual Plan de Infraestructura Plan de Aceptacin del Producto Plan de Administracin de la Configuracin Plan Plan Plan Plan de de de de Documentacin Resolucin de Problemas Administracin del Subcontratista Mejora de los Procesos]

223 13.ASEGURAMIENTO DE LA CALIDAD Tareas

13.1. Revisiones y Auditorias 1.1.13. Plan de revisin del Proceso

Esta revisin se realiza sobre los artefactos definidos en la Configuracin del Proceso. En cuanto a modelos slo revisa su existencia de acuerdo a la fase en que se encuentre.
Fase Fecha Artefactos a ser revisados (Si es una revisin general indicar Documentos de Configuracin de Proceso) acuerdo a la

1.1.14. Plan de revisin de Productos de Trabajo de acuerdo a Estndares definidos

Esta revisin se realiza sobre modelos, fuentes y otros documentos asociados al producto final, buscando la adherencia a los estndares definidos para stos.
Fase Fecha Productos de Software Estndares Utilizados Recursos requeridos

[Indique si requiere de asistencia de recursos de otras reas para realizar esta revisin]
1.1.15. Plan de auditoras y revisiones de Administracin de Configuraciones de Software

Fecha

Descripcin de la revisin a ser realizada

13.2.

Reporte de problemas y seguimiento de las acciones correctivas. 1.1.16. Mecanismos de reportes

Se establece que el mecanismo de control es la Planilla Verificacin de Proceso

1.1.17. Seguimiento de acciones correctivas

[Indique aqu como se realizar el seguimiento de las acciones correctivas producto de las revisiones practicadas y registradas en la Planilla de Verificacin de Proceso.]

224
13.3. Cambios en Procesos 1.1.18. Metas y Objetivos de los Cambios en el Proceso. [Describa los motivos por los cuales no se sigue el proceso estndar que se describe. 1.1.19. Descripcin de los Cambios [Describa cambios realizados al procedimiento que debern ser tomados en cuenta por el ASEGURAMIENTO DE LA CALIDAD en sus revisiones]

14.Evolucin del Plan

El Plan de ASEGURAMIENTO DE LA CALIDAD deber ser actualizado a lo menos al final de cada Fase y a lo ms al final de cada iteracin

15.Anexos
[Material adicional al Plan de ASEGURAMIENTO DE LA CALIDAD]

225

8.4.11 Plantilla Plan de Administracin de Configuracin

<Nombre del Proyecto> Plan de Administracin de Configuracin (CM) <Versin 1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de base para la confeccin del documento Plan Administracin de Configuracin. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]

226

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

227

ndice
1 Introduccin 1.1 Propsito 1.2 mbito 1.3 Definiciones, acrnimos y abreviaciones. 1.4 Referencias 1.5 Resumen Ejecutivo Administracin de la Configuracin 2.1 Organizacin, Responsabilidades, e Interfaces 2.2 Herramientas, Entorno, e Infraestructura 2.2.1 Herramientas 2.2.2 Ubicacin fsica del las mquinas servidores y clientes 2.2.3 Ubicacin fsica del los documentos y lneas base Programa de Administracin de la Configuracin 3.1 Identificacin de la Configuracin 3.1.1 Mtodos de Identificacin 3.1.2 Lneas Base del Proyecto 3.2 Configuracin y Control de Cambios 3.2.1 Proceso de peticin de cambios y aprobacin 3.2.2 Comit de Control de Cambios (CCB) 3.3 Cuentas de Configuracin de Status 3.3.1 Almacenamiento de la media del Proyecto, y proceso de Versin 3.3.2 Reportes e intervenciones Fases Capacitacin y Recursos 228 228 228 228 228 228 228 228 228 229 229 229 230 230 230 230 230 230 230 230 230 231 231 231

4 5

228

Plan de Administracin de Configuracin

1. Introduccin
[La introduccin del Plan de Administracin de Configuracin provee un resumen del documento completo. Este incluye el propsito, mbito, definiciones, acrnimos, abreviaciones, referencias, y un resumen ejecutivo de este documento.] 1.1. 1.2. Propsito [Especifique el propsito de este Plan de Administracin de Configuracin.] mbito [Describa brevemente el mbito de este Plan de Administracin de Configuracin; que modelos se encuentran asociados, y cualquier elemento que se vea influenciado o afectado por l.] 1.3. Definiciones, acrnimos y abreviaciones. [Esta subseccin provee las definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente este Plan de Administracin de Configuracin. Esta informacin puede entregarse como una referencia al Glosario del proyecto.] Referencias [Esta subseccin provee una lista completa de todos los documentos a los que se haga una referencia en cualquier parte de este Plan de Administracin de Configuracin. Identifique cada documento por ttulo, edicin (si es aplicable, fecha y editorial. Especifique las fuentes de donde se pueden obtener estas referencias. Esta informacin puede ser entregada como una referencia a un apndice o a otro documento.] 1.5. Resumen Ejecutivo [Esta subseccin describe el resto del contenido del Plan de Administracin de Configuracin, adems explica cmo est organizado este documento.]

1.4.

2. Administracin de la Configuracin
2.1. Organizacin, Responsabilidades, e Interfaces [Describa quien ser responsable de llevar a cabo las diferentes actividades de Administracin de Configuracin (CM). Se puede hacer referencia a documento Asignacin de Roles, para determinar roles responsables para SCM. Interfaces: se necesita describir en qu manera se va comunicar con otros grupos y afectados. Por ejemplo: reuniones semanal, e-mail, video conferencia...] 2.2. Herramientas, Entorno, e Infraestructura [Describa el entorno computacional y las herramientas software que sern utilizadas para cumplir las funciones de CM a travs del proyecto o del ciclo de vida del producto. Describa las herramientas y procedimientos requeridos para ser utilizados en los tems de configuracin de control de versin generados a travs del proyecto o del ciclo de vida del producto. Los elementos involucrados en fijar el entorno de CM incluyen: Tamao anticipado de la data del producto (aprox.) Distribucin del equipo del producto

229
Ubicacin fsica de las maquinas servidoras y clientes

1.1.20. Herramientas

Actividad

Herramienta [Nombre de la herramienta que se va usar para la actividad. Por ejemplo: para actividad Administracin de Requerimientos, herramienta puede ser: MS Excel,MS OFFICE, Requisito Pro, DOORS,... . Se puede agregar y direccin donde se puede encontrarse la instalacin de la herramienta.]

[Nombre de la actividad que se va cubrir usando herramienta. Por ejemplo: Administracin de Requerimientos]

1.1.21. Ubicacin fsica del las mquinas servidores y clientes

IP [Por ejemplo: 1P:192.168.0.33]

Nombre [Por ejemplo SERVER] SCM

Responsable [Nombre de administrador de la maquina o nombre de usuario si maquina es estacin del trabajo]

1.1.22. Ubicacin fsica del los documentos y lneas base

Direccin [La direccin donde se va guardar las lneas base. Se recomienda usar nombres relativos \\<nombre de servidor>\<direccin> Por ejemplo: para lnea base de requerimientos: \\SCM SERVER\Reqs\]

Tipo de documento [Nombre del tipo de documento que se va guardar dentro de la lnea base. Por ejemplo: para la Administracin de Requerimientos, puede ser: .DOC, .TXT y como base de datos PROYECT1.mdf ]

230 3. Programa de Administracin de la Configuracin

3.1. Identificacin de la Configuracin 1.1.23. Mtodos de Identificacin [Describa como sern nombrados, marcados y numerados los artefactos del proyecto o del producto. El esquema de identificacin necesita cubrir el hardware, software de sistema, productos comerciales, y todos los artefactos desarrollados para la aplicacin, listados en la estructura de directorios del producto; por ejemplo, planes, modelos, componentes, software de test, resultados y data, ejecutables, etc.] 1.1.24. Lneas Base del Proyecto [Las Lneas Base proveen un estndar oficial en el cual se basarn los trabajos subsecuentes y a los cuales solo se le pueden aplicar cambios autorizados. Describa en qu puntos durante el proyecto o el ciclo de vida del producto se han establecido Lneas Base. La mayora de los Lneas Base comunes deberan estar al final de cada fase de Concepcin, Elaboracin, Construccin, y Transicin. Los Lneas Base tambin pueden ser generados al final de las iteraciones con las diferentes fases o incluso ms frecuentemente. Describa quien autoriza unas lneas base. Se puede hacer referencia a el documento "Poltica, estndar y procedimiento de CM" general, si proyecto no tiene algunas cosas especificas y si este documento existe dentro de la organizacin] 3.2. Configuracin y Control de Cambios 1.1.25. Proceso de peticin de cambios y aprobacin [Describa los procesos por los cuales los problemas y cambios se han enviado, revisado y dispuesto.] 1.1.26. Comit de Control de Cambios (CCB) [Describa los miembros y procedimientos para el proceso de peticin de cambios y aprobaciones que deben ser seguidos por el CCB. Se puede hacer referencia a el documento "Poltica, estndar y procedimiento de CM" general, si proyecto no tiene algunas cosas especificas y si este documento existe dentro de la organizacin.] 3.3. Cuentas de Configuracin de Status 1.1.27. Almacenamiento de la media del Proyecto, y proceso de Versin [Describa las polticas de retencin, de respaldos, desastres y planes de recuperacin. Tambin describa como se almacena la media online, offline, tipo de media, y el formato. Si existe un plan de respaldo general se puede hacer referencia a documento donde este plan esta escrito. Los procesos de versin deben describir que incluye la versin, a quien va dirigido, descripcin de cualquier problema conocido y cualquier instruccin de instalacin.]

231
1.1.28. Reportes e intervenciones [Describa el contenido, formato, y propsito de los reportes requeridos e intervenciones requeridas. Los reporte son usados para evaluar la calidad del producto en cualquier momento dado del proyecto o del ciclo de vida de producto. El reporte de los defectos basados en las peticiones de cambios pueden proveer indicadores de calidad muy tiles y, de este modo, alertar a administradores y desarrolladores acerca de reas particulares criticas de desarrollo. Los defectos son clasificados segn su importancia (alto, medio, y bajo) y deben ser reportados segn la siguiente base: Antigedad (Reportes basados en el tiempo): Hace cuanto se han establecido estos defectos? Cul es el tiempo de retraso desde que los defectos fueron encontrados hasta que fueron reparados? Distribucin (Reportes basados en nmeros):Cuantos defectos existen en cada categora, ordenados por autor, prioridad, y estado de reparacin? Tendencias (Reportes basados en Tiempo y Nmero): Cul es el nmero de defectos acumulativos encontrados y cuales se han solucionado despus del tiempo? Cul es el ratio de defectos descubiertos y reparados? Cul es el Boquete de Calidad en trminos de defectos reportados y reparados? Cul es el tiempo de resolucin promedio de un defecto?

4. Fases
[Identifique las fases internas y del cliente relativas al esfuerzo de CM del producto o del proyecto. Esta seccin debe incluir detalles de actualizaciones del Plan de CM. Se puede hacer referencia a el documento "Configuracin del Proceso", donde se puede ver plan de actualizaciones del plan de SCM.]

5. Capacitacin y Recursos
[Describa las herramientas de software, personal y capacitacin necesaria para implementar las actividades de CM especificadas. Si personal tiene conocimiento el prrafo se puede omitir.]

232

8.4.12 Plantilla Plan de Pruebas

<Nombre del Proyecto> Plan de Pruebas Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de Base para la confeccin del documento de Plan de Pruebas. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo.]

233

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin <1.1.0> Descripcin Documento inicial Autor <Nombre>

234

ndice
1 Introduccin 1.1 Propsito 1.2 mbito 1.2.1 Pruebas Unitario 1.2.2 Pruebas Funcionales 1.2.3 Riesgos 1.2.4 Identificacin del Proyecto 1.3 Dirigido a 1.4 Breve Descripcin 1.5 Terminologa del Documento y Acrnimos 1.6 Referencias Requerimientos para el Prueba 2.1 Casos de Uso 2.1.1 Vista Global 2.1.2 Caso de uso 1 2.1.3 Caso de uso 2 2.1.4 Caso de uso 3 2.2 Requerimientos Funcionales 2.2.1 Componentes Comunes 2.2.2 Componente 1 2.2.3 Componente 2 2.3 Requerimientos No - Funcionales (Matriz con Input/Output) 2.3.1 Componente 1 2.3.2 Componente 2 Estrategia del Pruebas 3.1 Tipos de Pruebas 3.1.1 Integridad de la Base de Datos y de los Datos 3.1.2 Pruebas Funcional 3.1.3 Pruebas de Ejecucin 3.1.4 Pruebas de Seguridad y de Acceso a Datos Recursos 4.1 Profesionales 4.2 Ambiente de Pruebas 4.2.1 Preparacin del Ambiente de Pruebas 4.2.2 Diseo del Ambiente de Pruebas 4.2.3 Diseo Ambiente de Pruebas 4.2.4 Integracin del Ambiente de Pruebas y Configuracin 4.2.5 Definicin del Banco de Datos de Prueba 4.2.6 Generacin de Datos Hitos del Proyecto de Pruebas Entregables 6.1 Modelo del Prueba 6.1.1 Criterio de entrada para el modelo de Prueba 6.1.2 Criterio de salida para el modelo de Prueba 6.1.3 Criterio de suspensin y reinicio 236 236 236 236 236 237 238 238 239 239 239 240 240 240 240 240 240 240 240 240 240 240 240 240 241 241 241 242 243 243 244 244 245 245 245 247 247 248 248 250 252 252 252 252 252

5 6

235 6.2 Resultados del Prueba 6.3 Reporte de Defectos 7 Anexos 7.1 A: Tareas del Proyecto 7.2 B: Pruebas de Ejecucin 7.3 C: Pruebas de Seguridad y de Control de Acceso 8 Flujo de trabajo del Pruebas 9 Necesidades del entorno 9.1 Hardware base del sistema 9.2 Elementos Software base en el entorno de Prueba 9.3 Herramientas de Productividad y Ayuda 9.4 Configuraciones de Entorno de Prueba 10 Responsabilidades, Personal, y Capacitacin Necesaria 10.1 Personas y Roles 10.2 Personal y entrenamiento necesario 11 Fases del proceso de Iteracin 12 Riesgos, Dependencias, Suposiciones y Limitaciones 13 Procesos administrativos y procedimientos 13.1 Medicin y determinacin del grado de la prueba 13.2 Reporte de la cobertura del Prueba 13.3 Reporte de problemas, extensin, y edicin de la resolucin. 13.4 Manejo de los ciclos de Pruebas 13.5 Estrategias de Trazabilidad 13.6 Aprobacin y Trmino 252 252 253 253 254 255 257 258 258 258 259 259 260 260 262 263 264 265 265 265 265 265 265 265

236

Plan de Pruebas
1. Introduccin
1.1. Propsito El propsito de este Plan de Pruebas es recopilar toda la informacin necesaria para planificar y controlar el esfuerzo de Pruebas de esta iteracin. Este documento describe una aproximacin al Pruebas del software y es el primer plan generado y utilizado por los administradores para dirigir el esfuerzo de Pruebas. Este Plan de Pruebas, para el proyecto <Nombre del Proyecto>, contempla los siguientes objetivos: [Identificar la informacin existente del proyecto y los componentes de software que deberan ser Probados a partir de los Casos de Uso Listar los requerimientos recomendados para el Prueba. (Alto Nivel) Recomendar y describir la estrategia de Pruebas que ser utilizada. Identificar los recursos requeridos y proveer una estimacin del esfuerzo que significar el Pruebas. Listar los elementos entregables del proyecto de Prueba.]

1.2. mbito [Proporciona una descripcin por escrito de a quin va dirigido este Modelo de Prueba. Nota: El contenido y el estilo de este documento puede alterarse en relacin de a quin va dirigido] 1.1.29. Pruebas Unitario [El Pruebas unitario de componentes corresponder a las pruebas unitarias que realizar el equipo de desarrollo.] 1.1.30. Pruebas Funcionales El Pruebas sealado en este plan ser de tipo Caja Negra. Este tipo de Pruebas pretende verificar el comportamiento de la unidad, observando cmo est implementado el comportamiento de dicha unidad. Con esta finalidad se utilizarn datos de entradas (input), se ejecutar el proceso y se obtendr un resultado esperado (output). Los datos de entrada sern los utilizados por las transacciones involucradas. Cada argumento de entrada puede seleccionar uno de los siguientes datos de Prueba, dependiendo este del resultado que se desea obtener (esperado), verificando as el comportamiento de la componente a Probar usando distintos valores de entrada:

Valores normales para cada transaccin Valores lmites para cada transaccin Valores de borde Valores ilegales

237
1.1.31. Riesgos Durante el desarrollo del Plan de Pruebas se pueden producir impactos sobre algunas fases (Diseo, Desarrollo o Implementacin) del Pruebas. Algunos riesgos a considerar:

1. Documentacin de especificacin errnea o incompleta. 2. Lista de requerimientos inconsistente con los Casos de Uso. 3. Componentes a Probar y componentes comunes correspondan a distintas versiones. 4. Hardware y Software no funcionen correctamente. 5. Herramientas de Pruebas automatizado estn mal configuradas. 6. Flujo de trabajo del seguimiento de defectos no sean llevados en forma adecuada, para plantear soluciones rpidas y mejoradas.
Los riesgos sern identificados de acuerdo a un concepto de Bajo, Medio o Alto, dependiendo de la importancia del Caso de Uso para el cual se est desarrollando el Pruebas. As mismo, para el proyecto <Nombre del Proyecto>se han identificado una serie de riesgos (calificados entre 1 y 10 dependiendo de su gravedad) los que estn detallados en el documento <Lista de Riesgos.doc> con sus alcances y acciones, en el presente plan, los enunciamos para sugerir algunas acciones.

1.2.1.1.

Matrices de Riesgos

1.2.1.1.1.Proyecto Pruebas

N Riesgo 1 2 3 4 5 6

Descripcin

Gravedad

Accin

1.2.1.1.2. <Nombre del Proyecto> N Riesgo 1

Descripcin

Gravedad

238 N Riesgo 2 3 4 5 6

Descripcin

Gravedad

1.1.32. Identificacin del Proyecto La siguiente tabla permite identificar la documentacin disponible para desarrollar el Plan de Pruebas.

Documento (versin / fecha) Documento de Visin Especificacin de Requerimientos Especificaciones Funcionales Informe de Casos de Uso Plan del Proyecto Especificacin de Diseo Prototipo Manuales de Usuario Modelo de Negocio y Flujo Modelo de Datos y Flujo Funciones del Negocio y Roles Proyecto / Listado Riesgos

Creado o Disponible Si No Si No Si No Si No Si No Si No Si No Si No Si No Si No Si No Si No

Recibido o Revisado Si No Si No Si No Si No Si No Si No Si No Si No Si No Si No Si No Si No

Autor u Origen

Notas

1.3. Dirigido a [Provee una descripcin acerca de para quien se est escribiendo este documento. Esto ayuda a los lectores del documento a identificar si es un documento creado para su uso, y ayuda a prevenir que este documento sea usado inapropiadamente. Nota: El contenido y el estilo del documento pueden ser modificados en relacin de a quin van dirigidos. Esta seccin debe tener una extensin entre tres y cinco prrafos de longitud.]

239

1.4. Breve Descripcin [Breve descripcin del proyecto con: descripcin corta de arquitectura, lgica de sistema, roles y personas responsables para Prueba, y los tipos de Pruebas como funcionalidad, usabilidad, seguridad, Ejecucin y soporte que sern direccionados por este Modelo de Pruebas. Tambin es importante entregar una indicacin general de reas significantes que sern excluidas de este punto, especialmente aquellas en las cuales se podra asumir, de forma razonable, que estn incluidas.] 1.5. Terminologa del Documento y Acrnimos [Esta seccin provee las definiciones de los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente este documento. Esta informacin puede contener referencias al Glosario del proyecto.] 1.6. Referencias [Este punto deber: Proveer una completa lista de todos los documentos referenciados en cualquier lugar del documento Plan de Pruebas. Identificar cada documento por un ttulo, nmero de reporte (si aplica), fecha y organizacin que la pblica. Especificar las fuentes desde las cuales las referencias pueden ser obtenidas.

Esta informacin puede estar referida a un apndice u otro documento.]

240

2. Requerimientos para el Prueba

La siguiente lista identifica los tems (Casos de Uso, Requerimientos Funcionales y Requerimientos no Funcionales) que se han identificado como requerimientos a ser Probados. 2.1. Casos de Uso 1.1.33. Vista Global [Agregar o eliminar segn corresponda] 1.1.34. Caso de uso 1 1.1.35. Caso de uso 2 1.1.36. Caso de uso 3 2.2. Requerimientos Funcionales 1.1.37. Componentes Comunes [Agregar o eliminar segn corresponda] 1.1.38. Componente 1 1.1.39. Componente 2

2.3. Requerimientos No - Funcionales (Matriz con Input/Output) 1.1.40. Componente 1

Nro. 1

Caso de Uso

Input

Output

1.1.41. Componente 2

Nro.

Caso de Uso

Input

Output

241

3. Estrategia del Pruebas

[A continuacin se describe la estrategia de Pruebas a ser utilizada en <nombre del proyecto>, en otras palabras, se indica cmo se realizar el Pruebas de los requerimientos analizados en la seccin precedente (Requerimientos para el Pruebas) la cual identifica qu se va a Probar. Se proponen varios tipos de Pruebas, en funcin de los riesgos identificados para el proyecto; sin embargo es slo el Pruebas Funcional el que ser desarrollado y ejecutado, los otros tipos de Pruebas se proponen como complementarios y estn sujetos a su factibilidad de ser ejecutados por <nombre de usuario>. 3.1. Tipos de Pruebas 1.1.42. Integridad de la Base de Datos y de los Datos [De acuerdo al Riesgo N1, identificado en el punto 1.2.3.1.2 de este documentos, y definido en el documento Lista de riesgos.doc, se sugiere realizar esta actividad, considerando el modelo que propone el RUP. El Administrador de Bases de Datos de <nombre del cliente>, deber asegurar que las bases de datos para el proyecto de Pruebas, sean un reflejo de las de produccin.] El Administrador de Bases de Datos deber indicar las herramientas y tcnicas para ejecutar esta prueba. Objetivo del Prueba: Tcnica a Utilizar: Asegurar que los mtodos de Acceso a la Base de Datos SQL y los procesos asociados, funcionan apropiadamente y sin riesgo de datos corruptos. Realizar la llamada a una Base de Datos y ejecutar algn proceso con datos vlidos e invlidos. Inspeccionar la Base de Datos para verificar que los procesos se han realizado correctamente. Criterio de Verificacin: Consideraciones Especiales: Todos los mtodos de acceso a la Base de Datos y sus procesos deben estar sin datos corruptos. La prueba puede requerir que el Administrador de Bases de Datos disee un ambiente o drivers para acceder a los datos directamente. Deben invocarse los procesos manualmente. Se debe utilizar una reducida cantidad de registros para facilitar la inspeccin de los datos e identificar eventos errneos. Observaciones:

242
1.1.43. Pruebas Funcional El Pruebas funcional se realizar sobre los requerimientos funcionales antes descritos y sus Casos de Uso. Este Prueba tiene por finalidad verificar la funcionalidad de la aplicacin a partir de datos vlidamente seleccionados sobre las transacciones del sistema. Este tipo de comprobacin se basa en las tcnicas de caja negra, que permiten verifica la aplicacin (y sus procesos interiores) actuando recprocamente con la aplicacin va el GUI y analizando el rendimiento (resultados). Objetivo del Prueba: Asegurar la funcionalidad del conjunto de casos, incluyendo la navegacin en la aplicacin, el ingreso de datos, el proceso y la recuperacin (resultados). Que la navegacin a travs de los casos de prueba refleje apropiadamente las reglas del negocio y los requerimientos, incluyendo ventana a ventana, campo a campo y usando los mtodos de acceso correctamente (tecla tab, movimiento del mouse, etc.) Que los objetos de las ventanas y sus caractersticas, tales como mens, tamao, posicin, estados y el foco, estn de acuerdo a los estndares. Tcnica a Utilizar: Ejecutar cada Caso de Uso, su flujo y funcionalidad usando tanto datos vlidos como invlidos para verificar lo siguiente: Que los resultados esperados ocurren cuando los datos vlidos son utilizados. Que el mensaje de error es el apropiados cuando se utilizan datos invlidos Que cada Regla de Negocio se utiliza apropiadamente. Crear y modificar los procedimientos de Prueba para cada ventana, para verificar los estados de los objetos y de la aplicacin. Todas la pruebas planificadas se ejecutaron correctamente Todos los defectos identificados han sido asignados. Cada ventana debe ser verificada para mantener la consistencia con la versin maestra y verificar que est dentro de los estndares aceptables.

Criterio de Verificacin:

Consideraciones Especiales: Observaciones:

[Puede que no todas las propiedades sean verificadas, considerar las ms importantes y/o definidas y no todos los objetos de terceras partes puedan ser verificados.]

243

1.1.44. Pruebas de Ejecucin [Este Pruebas no est considerado realizar en esta primera etapa, de tal forma que slo se enmarca en una recomendacin que <nombre de usuario> deber evaluar y decidir.] Un detalle de este tipo de Pruebas, adjunta en el Anexo B de este documento. 1.1.45. Pruebas de Seguridad y de Acceso a Datos [Este Pruebas no est considerado realizar en esta primera etapa, de tal forma que slo se enmarca en una recomendacin que <nombre de usuario> deber evaluar y decidir.] Este tipo de Pruebas se enmarca dentro de la metodologa del RUP. Un detalle de este tipo de Pruebas, adjunta en el Anexo B de este documento.

244

4. Recursos
Esta seccin presenta una recomendacin de recursos para el esfuerzo de Pruebas del sistema <Nombre del Proyecto>, sus principales responsabilidades y sus conocimientos y habilidades. 4.1. Profesionales La siguiente tabla muestra el equipo para el Proyecto de Pruebas: Recursos Humanos Trabajador Recursos mnimos recomendados (Nmero de trabajadores FullTime) Diseador del Prueba Identificar, priorizar e implementar los casos del Prueba Responsabilidades Probador Genera el plan de Prueba Genera el Modelo de Prueba Evaluar de forma efectiva el esfuerzo de Pruebas Responsabilidades especficas / Comentarios

Ejecutar los Prueba Responsabilidades: Ejecuta los Prueba Guarda estado de los resultados Recuperacin de errores Peticin de cambio de la documentacin Asegurar que el entorno de Prueba y valores estn controlados y mantenidos. Responsabilidades Administrar el sistema de control del Prueba Instalar / manejar el acceso de los trabajadores al sistema de Pruebas

Administrador de sistema del Prueba

Administrador de la Base de Datos / Encargado de la Base de Datos

Asegurar que el entorno de datos del Prueba (Base de Datos) y los valores que contiene estn controlados y mantenidos. Responsabilidades: Administra los datos del Prueba (Base de Datos)

245
Recursos Humanos Trabajador Recursos mnimos recomendados (Nmero de trabajadores FullTime) Diseador Identificar y definir las operaciones, atributos y asociaciones de las clases del Prueba. Responsabilidades: Implementador Identifica y define el(las) clase(s) de Prueba Identifica y define los paquetes del Prueba Responsabilidades especficas / Comentarios

Implementar y unir las clases de Prueba y los paquetes. Responsabilidades: Crea las clases de Prueba y los paquetes implementados en el Modelo de Prueba.

4.2. Ambiente de Pruebas Para el Ambiente de Pruebas se describen los recursos y las actividades necesarias para la configuracin del Ambiente de Pruebas. Se identifican los requerimientos de hardware, software y de comunicacin necesarios para crear y dar soporte permanente al Ambiente de Pruebas. Las actividades de instalacin y configuracin para el conjunto de los componentes del Ambiente de Pruebas, debern ser planificadas y calendarizadas. Se requiere que este ambiente sea seguro, estable y dedicado exclusivamente para las pruebas del sistema. 1.1.46. Preparacin del Ambiente de Pruebas Las pruebas unitarias y de regresin debern ser ejecutadas dentro del Ambiente de Desarrollo, las pruebas de aceptacin del usuario y del sistema se ejecutarn en este Ambiente de Pruebas. Este Ambiente deber representar una configuracin idntica al Ambiente de Produccin o al menos, una versin en menor escala del Ambiente Operacional (Produccin). Esto se requiere debido a que se debe replicar el rendimiento de la lnea base y las medidas de mejoramiento relacionadas.

1.1.47. Diseo del Ambiente de Pruebas La siguiente tabla identifica los recursos de sistema identificados para el proyecto de Pruebas. ITEM HARDWARE Estacin de Pruebas (Cliente) Procesador DESCRIPCIN OBSERVACIONES

246
ITEM Memoria RAM Espacio en Disco Tipo Monitor y Resolucin Unidad de Disquete Tarjeta de red Mdem Mouse Tipo Enlace Servidores (Pruebas) Procesador Memoria RAM Espacio en Disco Tipo Monitor y Resolucin Unidad de Disquete Tarjeta de red Mdem Mouse Tipo Enlace Tipo Enlace Clase de Enlace Tipo Enlace Impresoras Marca y Modelo Tipo Resolucin Ejecucin Dedicacin RED Topologa Medio Velocidad Protocolo Mdems Conexin Internet DESCRIPCIN OBSERVACIONES

247
ITEM Sistema de Respaldo / DESCRIPCIN OBSERVACIONES

Restauracin Unidad (Modelo y Marca) Capacidad Ubicacin SOFTWARE Estacin de Pruebas (Cliente) Sistema Operativo Herramienta de Pruebas Herramienta de Modelamiento BDMA Browser Software de Escritorio Repositorios Servidor Dominio / Cuenta

Seguridad

1.1.48. Diseo Ambiente de Pruebas El siguiente diagrama muestra la arquitectura del Ambiente de Pruebas requerido para realizar el Pruebas de <nombre del proyecto>. <<incluir_diagrama_de_la_arquitectura_del_ambiente_de_prueba>> 1.1.49. Integracin del Ambiente de Pruebas y Configuracin Para esta actividad se requerir la participacin de profesionales de <nombre de cliente> en cuanto a instalacin, configuracin y puesta en marcha del Ambiente de Pruebas. Principalmente se requiere del responsable de la Red y Administracin de Bases de Datos, de tal forma de obtener un ambiente lo ms consistente y smil al de produccin, con las bases de datos creadas y el software configurado para asegurar que el sistema funciona de acuerdo a diseo.

248
Las actividades generales a ser consideradas son:

Actividad

Responsable

Fecha Estimada

Fecha Real

Observaciones

1.1.50. Definicin del Banco de Datos de Prueba Para el tipo de Pruebas que se realizar, se debe asegurar que los requerimientos sern adecuadamente probados y verificados. En este sentido, se debern tomar las siguientes consideraciones al momento de generar el Banco de Datos.

4.2.1.1.1. Profundidad 4.2.1.1.2. Variacin 4.2.1.1.3. Alcances 4.2.1.1.4. Ejecucin 4.2.1.1.5. Condiciones
En esta consideracin, se requiere conocer la documentacin del sistema, de tal forma de obtener el mximo de informacin para la creacin de los datos. La documentacin que se requiere es:

Documentacin conceptual del sistema Definicin de Requerimientos Especificacin de software / hardware Diagrama entidad - relacin Diagrama de Casos de Uso Diagrama de Estado Diccionario de datos
1.1.51. Generacin de Datos La generacin de los datos para las pruebas consideran los siguientes aspectos, que se deben definir de acuerdo a los requerimientos y posibilidades de su obtencin. Los aspectos que se describen a continuacin, pretenden que tanto los datos sean los correctos, como la cobertura de los mismos cubra todos los riesgos y situaciones que se presenten.

249 4.2.1.2. Muestra de Produccin

Para que la muestra de datos sea realmente representativa, se deber elegir una fecha adecuada y que posibilite la mayor cobertura de datos. En este sentido se ha elegido como fecha el <<indicar_fecha_para_obtencin_de_datos>> Para la obtencin de datos por esta va, se debern definir las restricciones (por motivos de confidencialidad) y generar algn utilitario para filtrar los datos de tal forma de obtener la mayor variabilidad de datos posible. Adems se deben considerar los siguientes aspectos para asegurar que estos datos funcionen correctamente en el Ambiente de Pruebas:

Archivos Maestros al Inicio del Da Tablas de Parmetros Interfaces de Entrada Archivos de Movimientos del da o del periodo
Todos estos aspectos se deben considerar en los distintos ambientes donde los datos van a ser utilizados en las transacciones o actualizaciones.

4.2.1.3.

Datos Complementarios

En este aspecto se deben verificar si es necesario generar datos complementarios para cubrir todas las posibles variaciones que se puedan dar. La generacin de los datos complementarios depender de los datos obtenidos de produccin y de la informacin que est en la documentacin solicitada. Uno de los aspectos a considerar para generar datos complementarios, es el aspecto de fecha, para lo cual se deber considerar el envejecimiento de los datos a objeto de mantener la consistencia de las pruebas e independencia de la fecha de proceso.

4.2.1.4.

Envejecimiento de Datos de Prueba

En este aspecto se deben considerar los envejecimientos de los datos de prueba, de tal forma que cumplan con la validez de las pruebas. Los datos a envejecer sern tanto los obtenidos desde produccin como los complementarios generados para cubrir el total de las condiciones y variaciones. Esta consideracin es eventual y deber considerarse slo si es necesario. Tienen especial relevancia ciertas fechas en que, para <nombre de usuario>, se realizan procesos claves, las fechas en cuestin con sus implicancias se detallan a continuacin:

Fecha

Consideraciones

Observaciones

250 4.2.1.5. Procesos Batch

En este aspecto se consideran algunos procesos batch que son necesarios para la actualizacin de datos en <Nombre del proyecto>

Los procesos batch identificados son los siguientes:

Job

Archivo maestro

Archivo de Movimiento

Tablas

Interfaces

Informes

5. Hitos del Proyecto de Pruebas

[A continuacin se enumeran las actividades a realizar en el Proyecto de Pruebas.] Tareas Plan Prueba Identificar el Proyecto Definir Estrategia Estimar Actividades Identificar Recursos Documentar Plan de Pruebas Agenda de Actividades Revisin del Plan de Pruebas Diseo del Prueba Analizar Requerimientos Especificar Procedimientos de Prueba Especificar Prueba Case Revisar Cobertura de los requerimientos de Prueba Responsable Esfuer zo Fecha Inicio Fecha Trmino

251
Esfuer zo Fecha Inicio Fecha Trmino

Tareas Implementacin de Prueba Establecer Ambiente de Implementacin Desarrollar los Procedimientos de Prueba Probar y debugear los Procedimientos de Prueba Modificar los Procedimientos de Prueba Reprobar y debugear los Procedimientos de Prueba Ejecucin del Prueba Ejecutar Prueba Verificar Resultados Esperados Investigar Resultados Inesperados Log de Defectos Re-Ejecutar Prueba Evaluacin del Prueba Revisar el Log del Prueba Evaluar cobertura de los Casos de Prueba Evaluar Defectos Reportar Defectos

Responsable

252

6. Entregables
[En esta seccin se deben listar los documentos, herramientas, y reportes que sern creados, autor, destinatario y fecha de entrega] 6.1. Modelo del Prueba [Esta seccin identifica los reportes del Modelo de Prueba que sern creados y distribuidos. Estos artefactos pertenecientes al modelo de Prueba deben ser creados y referenciados en la herramienta ASQ] 1.1.52. Criterio de entrada para el modelo de Prueba [Especifica el criterio que se usara para determinar si la ejecucin del Modelo de Prueba puede comenzar] 1.1.53. Criterio de salida para el modelo de Prueba [Especifica el criterio que se usara para determinar si la ejecucin del Modelo de Prueba se ha completado o si contina en ejecucin sin entregar resultados] 1.1.54. Criterio de suspensin y reinicio [Especifica el criterio que se usara para determinar si el Pruebas debe ser suspendido prematuramente o finalizado antes que el modelo de Prueba haya sido ejecutado completamente, y bajo qu criterio puede ser reasumido el Pruebas ] 6.2. Resultados del Prueba [Describe los mtodos y las herramientas usadas para registrar y reportar en el Prueba los resultados y el status del Prueba] 6.3. Reporte de Defectos [Esta seccin identifica el mtodo y la(s) herramienta(s) usadas para registrar, ajustar y reportar los incidentes del Prueba y sus status]

253 7. Anexos
7.1. A: Tareas del Proyecto

La siguiente lista muestra las tareas relacionadas con el Prueba:

No Aplica

Plan de Pruebas (Preliminar) Identificar Requerimientos para el Pruebas Medir los Riesgos Desarrollar la Estrategia del Pruebas Identificar los Recursos del Pruebas Creacin del Inventario Generar Plan de Pruebas Disear el Pruebas Anlisis de Carga de Trabajo Identificar y Describir los Prueba Case Identificar y Estructurar los Procedimientos de Prueba Revisar y Accesar la Cobertura del Prueba Implementar el Prueba Grabar o Programar los Script del Prueba Identificar las funcionalidades de Prueba especficos en el modelo de diseo e implementacin. Establecer el Conjunto de Datos Externos Ejecutar el Prueba Ejecutar los Procedimientos de Prueba Evaluar la Ejecucin del Prueba Recuperacin de una Prueba interrumpida. Verificar los Resultados Investigar los Resultados Inesperados Log de Defectos Evaluar el Prueba Evaluar la cobertura de los Prueba Case

No Aplica

Evaluar la Cobertura del Cdigo Analizar Defectos Determinar si el Criterio de Carga y el Criterio de aceptacin fueron archivados

254

7.2. B: Pruebas de Ejecucin [De acuerdo al Riesgo N2, identificado en el punto 1.2.3.1.2 de este documento y definido en el documento Lista de riesgos.doc, se sugiere realizar este tipo de Pruebas. Las Pruebas de Ejecucin es una prueba para verificar los tiempos de respuestas, la tasa de transacciones y otros tiempos requeridos de desempeo. La finalidad de las Pruebas de Ejecucin es verificar que los tiempos de respuestas requeridos son los ptimos. Las Pruebas de Ejecucin verifican que el desempeo del sistema y la configuracin del hardware son adecuados frente a una serie de transacciones bajo ciertas condiciones de carga.] Para esto, se definen las transacciones de acuerdo a los Casos de Uso especficos que se espera que un actor del sistema realice usando un conjunto de datos para agregar o modificar transacciones.

Objetivo del Pruebas:

Verificar la conducta de Ejecucin para las transacciones seleccionadas o funcionalidades bajo las siguientes condiciones: - Una carga de trabajo normal - Una sobrecarga de trabajo Usar los procedimientos de pruebas desarrollados para el Pruebas Funcional. Modificar los archivos de datos para aumentar las transacciones o los script de robotizacin para incrementar el nmero de iteraciones de cada transaccin. Los script debern correr en una mquina (la mejor referencia es un solo usuario y una nica transaccin) y repetirla con mltiples clientes (virtuales o reales). Una Transaccin / Un Usuario: La finalizacin exitosa de los Prueba scripts sin ninguna falla dentro del tiempo esperado (por transaccin en forma independiente). Mltiples Transacciones / Mltiples Usuarios: La finalizacin exitosa de los Prueba scripts sin ninguna falla dentro tiempo estimado. La extensin de las Pruebas de Ejecucin requiere tener en background la carga de trabajo en el servidor. Existen varios mtodos que se pueden usar para realizar esto como por ejemplo:

Tcnica:

Criterio de Verificacin:

Consideraciones Especiales:

Gatillar transacciones directamente al servidor, normalmente en forma de llamadas de SQL. Crear una carga de usuarios virtuales para simular (normalmente varios cientos) los clientes. Para esto se utilizan herramientas de emulacin de terminales remotas para lograr esta carga. Esta tcnica tambin puede usarse para someter a la red a un alto trfico.

255
Usar mltiples clientes fsicos, cada uno corriendo los Prueba scripts para agregar una carga al sistema. Las Pruebas de Ejecucin deberan realizarse en una mquina dedicada o en un tiempo dedicado. Esto permite un control total y una exacta medicin. Las bases de datos utilizadas para realizar las Pruebas de Ejecucin debern ser del tamao equivalente a las de produccin o a escala similar. Observaciones: Este tipo de Pruebas no se planificar ni se ejecutar.

7.3. C: Pruebas de Seguridad y de Control de Acceso [De acuerdo al Riesgo N4, identificado en el punto 1.2.3.1.2 de este documento y definido en el documento Lista de riesgos.doc, se sugiere realizar este tipo de Pruebas.] Se recomienda que el Administrador de la Red y del Sistema planifique algunas pruebas en este sentido. [El Pruebas de Seguridad y de Control de Acceso enfoca en dos reas claves de la seguridad:] Seguridad a nivel de la Aplicacin, incluyendo acceso a los datos o funciones de negocio, y Seguridad a nivel del Sistema, incluyendo el login y/o el acceso remoto al sistema. La seguridad a nivel de la aplicacin, asegura que, sobre la base de la seguridad deseada, se restringen a los usuarios a ciertas funciones o Casos de Uso especficos o se les limita el acceso a datos disponible para ellos. La seguridad a nivel de sistema, asegura que slo los usuarios definidos en el sistema son capaces de acceder a la aplicacin y slo a travs de entradas apropiadas.

Objetivo del Prueba:

Seguridad a Nivel de Aplicacin: Verificar que un usuario puede acceder slo a las funcionalidades y datos para las cuales ese tipo de usuario tiene permiso. Seguridad a Nivel de Sistema: Verifica que slo esos usuarios con acceso al sistema y aplicacin tienen permitido el acceso.

256
Nivel de Aplicacin: Identifique y liste cada tipo de usuario y las funcionalidades y datos de cada tipo para las cuales tiene permiso. Cree Prueba para cada tipo de usuario y verifique cada permiso creando transacciones especficas para cada usuario. Modifique los tipos de usuarios y vuelva a ejecutar los Prueba case para los mismos usuarios. En cada caso verifique si las funcionalidades y los datos estn correctamente disponibles o denegados. Acceso a Nivel de Sistema: vea las consideraciones especiales ms abajo. Para cada tipo de usuario conocido, las funcionalidades y los datos correctos debieran estar disponibles y todas las transacciones ejecutadas debieran ejecutarse de acuerdo a lo esperado. El acceso al sistema debera ser verificado con el administrador de la red o del sistema. Este Pruebas quizs pueda requerir de la participacin del administrador de la red o del sistema. Este tipo de Pruebas no ser planificado y no se ejecutar.

Tcnica:

Criterio de Verificacin:

Consideraciones Especiales:

Observaciones:

257

8. Flujo de trabajo del Pruebas

[Proporciona un entorno del flujo de trabajo a seguir por el equipo de Prueba en el desarrollo y ejecucin del Modelo de Prueba El flujo de trabajo especfico del Pruebas que ser usado debe ser documentado por separado en los Casos de desarrollo del proyecto. Este debera explicar cmo, en el proyecto, se ha personalizado la base RUP de flujo de trabajo Pruebas. Los detalles ms especficos de las tares de Pruebas individuales estn definidas de diferentes formas, dependiendo de la naturaleza del proyecto; por ejemplo: Definido como una lista de tareas en esta seccin del Modelo de Prueba, en un apndice. Definido en un cronograma central del proyecto (a menudo con una herramienta como Microsoft Project) Documentado por separado, listas dinmicas To-Do para cada miembro del equipo, usualmente tambin estn detallados para ser ubicados en el Modelo de Prueba. Documentado en un panel central y actualizado dinmicamente. Documentado de manera no formal del todo.

Basado en la naturaleza del proyecto, debera listar las tareas especficas de Pruebas en este punto o entregar un texto descriptivo explicando los procesos que usa el equipo de Pruebas para manejar los detalles del plan y entregar una referencia de donde sern almacenados estos detalles, siempre y cuando sea apropiado. Para los planes de Pruebas maestros, se recomienda evitar la descripcin detallada de la tarea de planeamiento.]

258 9. Necesidades del entorno

[Esta seccin especfica los recursos no humanos requeridos por el Modelo de Prueba] 9.1. Hardware base del sistema La siguiente tabla establece los recursos necesarios por el Prueba enunciado en este Modelo de Prueba. [Los elementos especficos del sistema de Prueba pueden no ser comprendidos en su totalidad en las primeras iteraciones, por lo tanto se espera que esta seccin se complete despus del tiempo.] [Nota: Aadir o borrar tems segn sea necesario]

Recurso Servidor de Base de Datos Network o Subnet Nombre del Servidor Nombre de Base de Datos PCs clientes de Prueba Extras Configuracin Requerimientos Deposito de Prueba Network o Subnet Nombre del Servidor PCs de desarrollo del Prueba

Cantidad

Nombre y tipo

9.2. Elementos Software base en el entorno de Prueba Los siguientes elementos software base son requeridos en el entorno de Prueba de este Modelo de Prueba. [Nota: Aadir o borrar tems segn sea necesario]

Nombre del elemento Software NT Workstation Windows 2000 Internet Explorer Netscape Navigator Microsoft Outlook McAffee Antivirus

Versin

Tipo y Otras Notas Sistema Operativo Sistema Operativo Browser de Internet Browser de Internet Software cliente de eMail Deteccin de virus y recuperacin de software

259

9.3. Herramientas de Productividad y Ayuda Las siguientes herramientas sern empleadas como ayuda al Prueba para este Modelo de Prueba. [Nota: Aadir o borrar tems segn sea necesario]

Herramienta Categora o Tipo Manejo del Prueba Ajuste de Defectos Herramienta ASQ para Pruebas funcional Herramienta ASQ para Pruebas de Ejecucin Monitor del nivel de cobertura del Prueba Administracin del proyecto Herramientas DBMS

Marca de la herramienta

Vendedor o Local

Versin

9.4. Configuraciones de Entorno de Prueba Las siguientes Configuraciones de Entorno proporcionadas y soportadas para este proyecto. de Prueba necesitan ser

Nombre de la Configuracin Configuracin de usuario promedio Configuracin mnima soportada Visibilidad y Movilidad Probada S.O. Internacional de Doble Byte Instalacin de Network(No del cliente)

Descripcin

Implementado en configuracin fsica

260

10.Responsabilidades, Personal, y Capacitacin Necesaria

[Esta seccin presenta los recursos requeridos para dirigir el Prueba en el Modelo de Prueba; las responsabilidades generales y el conocimiento o habilidad requerida para estos recursos] 10.1.Personas y Roles Esta tabla muestra los roles del personal en el esfuerzo de Prueba. [Nota: Aadir o borrar tems segn sea necesario] Recursos Humanos Recursos Mnimos Recomendados Responsabilidades Especficas o Rol (nmero de roles asignados por tiempo Comentarios completo) Realiza un manejo superficial. Sus responsabilidades incluyen: Planeamiento y Logstica Misin de acuerdo Identificar los motivos Adquirir los recursos Encargado de apropiados Prueba Presentar reportes gerenciales Abogar por los intereses del Prueba Evaluar la efectividad del esfuerzo de Prueba Identifica y define los Prueba especficos que deben realizarse. Sus responsabilidades incluyen: Identificar las ideas del Prueba Analista de Definir los detalles del Prueba Prueba Determinar los resultados del Prueba Peticiones de cambios en la Documentacin Evaluar la calidad del producto

Rol

Diseador del Prueba

Recursos Humanos Recursos Mnimos Recomendados Responsabilidades Especficas o (nmero de roles asignados por Comentarios tiempo completo) Define el acercamiento tcnico para la implementacin del esfuerzo de Prueba. Sus responsabilidades incluyen: Define una aproximacin al Prueba Define la arquitectura de

261
automatizacin Verifica las tcnicas de Prueba Define la Pruebas de los elementos Estructura la implementacin del Prueba Implementa y ejecuta los Pruebas. Sus responsabilidades incluyen: Implementar los Pruebas y los Prueba suites. Ejecutar los Prueba suites. Guardar run registro de los resultados. Analizar y recuperarse de una falla en el Prueba. Documentar los incidentes. Asegura que el entorno de Prueba se encuentre en buenas condiciones. Sus responsabilidades incluyen: Administrar el sistema de Prueba Instala y da soporte para el acceso y recuperacin del entorno de configuraciones y laboratorios de Prueba. Asegura que el entorno de datos del Prueba (Base de Datos) se encuentre activo y en buenas condiciones. Sus responsabilidades incluyen: Dar soporte a la administracin de los datos del Prueba (Base de Datos)

Probador

Administrador de sistema del Prueba.

Administrador de la Base de Datos, Encargado de la Base de Datos

Rol

Diseador

Implementado r

Recursos Humanos Recursos Mnimos Recomendados Responsabilidades Especficas o (nmero de roles asignados por Comentarios tiempo completo) Identifica y define las operaciones, atributos, y asociaciones de las clases del Prueba. Sus responsabilidades incluyen: Definir las clases del Prueba requeridas para soportar los requerimientos de Pruebas como fueron definidos por el equipo de Prueba. Implementa y une los Pruebas de las clases y paquetes de Prueba. Sus responsabilidades incluyen:

262
Crear los componentes del Prueba requeridos para soportar los requerimientos de Pruebas como fueron definidos por el diseador.

10.2.Personal y entrenamiento necesario Esta seccin muestra como acercar al personal Prueba definidos para el proyecto.

y capacitarlos en los roles de

[La forma de acercar al personal y capacitarlo puede variar de un proyecto a otro. Si esta seccin es parte del Plan de Prueba Maestro, debera indicar en qu puntos del ciclo de vida del proyecto se necesitarn diferentes habilidades y nmero de personas. Si esta es una Iteracin del Plan de Prueba, debera enfocarse principalmente en donde y que capacitacin debe efectuarse durante la iteracin De todas maneras la etapa de capacitacin necesita un cronograma, esto basado en la filosofa del Just-In-Time (JIT). Ver las oportunidades de combinar herramientas de productividad comerciales con la capacitacin en estas herramientas. El equipo de Prueba requiere, a menudo, soporte y habilidades de miembros de otros equipos que no sean directamente parte de este equipo de Prueba. Asegurarse de tener en mente en el plan una apropiada disponibilidad de los Administradores de Sistemas, Administradores de la Base de Datos, y Desarrolladores quienes son necesarios para establecer el esfuerzo de Prueba.]

263

11.Fases del proceso de Iteracin

[Identificar las fechas claves de cada fase que fije el contexto para el esfuerzo de Prueba.]

Fase Acuerdo del Plan de Iteracin. Comienzo de la Iteracin Lnea Final de los requerimientos. Lnea Final de la Arquitectura Lnea Final de la Interfaz de Usuario Primer Entregable entregado para el Prueba Primer Entregable aceptado en el Prueba Primer Entregable que completa el ciclo de Prueba [El Segundo Entregable no ser Probado] Tercer Entregable entregado para el Prueba Tercer Entregable aceptado en el Prueba Tercer Entregable que completa el ciclo de Prueba Cuarto Entregable entregado al Prueba Cuarto Entregable aceptado en el Prueba Revisin de la evaluacin de la Iteracin Fin de la Iteracin

Fecha de Inicio planeada

Fecha de Inicio actual

Fecha de Termino planeada

Fecha de Termino actual

264

12.Riesgos, Dependencias, Suposiciones y Limitaciones

[Listar cualquier riesgo que pueda afectar la ejecucin satisfactoria de este Plan de Prueba, e identificar las estrategias de mitigacin y contingencia para cada riesgo. Indicar tambin un ranking de los riesgos ms esperados y de los que pueden producir el mayor impacto.]
Riesgo Estrategia de Mitigacin <Probador> Deber definir los prerrequisitos que se deben cumplir antes de empezar a cargar el Pruebas <Cliente> Deber esforzarse por cumplir los prerrequisitos indicados por el <Probador> <Cliente> Debe asegurar que un conjunto completo de datos del Prueba estn disponibles y sean apropiados Datos del Prueba de prueba son inadecuados <Probador> Deber indicar que es lo que se requiere y deber verificar que los datos del Prueba sean apropiados. <Administrador de Sistema> Deber preocuparse de que la Base de Datos sea regularmente actualizada, tan frecuente como sea requerido por el <Probador> Contingencia (El riesgo se realiza) Encontrar las salidas de los prerrequisitos Considerar una falla en la introduccin de los datos del Prueba Redefinir los datos del Prueba Revisar el Modelo de Prueba y modificar los componentes (estos son, scripts) Considerar una falla en la introduccin de los datos del Prueba Restaurar los datos y comenzar de nuevo Limpiar la Base de Datos

No se cumple el criterio de Prerrequisito de entrada.

La Base de Datos requiere actualizacin

[Listar cualquier dependencia identificada durante el desarrollo de este Modelo de Prueba que pueda afectar su ejecucin satisfactoria si estas dependencias no han sido mencionadas. Tpicamente estas dependencias que estn relacionadas con actividades en la ruta crtica son prerrequisitos o postrequisitos para una o ms actividades procedentes (o subsecuentes). Deber considerar las responsabilidades de miembros de otros equipos o del personal, externas al esfuerzo de Pruebas]

Dependencia entre

Potencial impacto o dependencia

Propietarios

[Listar cualquier suposicin realizada durante el desarrollo de este Modelo de Pruebas que puedan afectar su ejecucin satisfactoria. si estos supuestos comprueban que son incorrectos. Los supuestos estn relacionados]

Supuesto a probar

Impacto del supuesto si es incorrecto

Propietarios

265
[Listar cualquier restriccin puesta en el esfuerzo de Pruebas que haya tenido un efecto negativo en la manera en que se haya realizado este Modelo de Prueba]

Restriccin en

Impacto de la restriccin en el esfuerzo de Prueba

Propietarios

13.Procesos administrativos y procedimientos

[Describa qu procesos y procedimientos deben ser utilizados cuando los resultados cumplen con el Modelo de Prueba y con los resultados esperados] 13.1.Medicin y determinacin del grado de la prueba [Describa el proceso de medicin y cuantificacin que ser usado para ajustar el grado del Prueba] 13.2.Reporte de la cobertura del Prueba [Describa el proceso de cuantificacin para revisar y aceptar los reportes de este Modelo de Prueba] 13.3.Reporte de problemas, extensin, y edicin de la resolucin. [Defina como los problemas del proceso sern reportados y extendidos, y el proceso a seguir para llevar a cabo la resolucin.] 13.4.Manejo de los ciclos de Pruebas [Describa el manejo de los procesos de control para un ciclo de Pruebas] 13.5.Estrategias de Trazabilidad [Considere una adecuada estrategia de trazabilidad para: Cobertura del Prueba versus las especificaciones Establece una medida para el grado del Prueba Motivaciones para el Prueba Establece determinaciones de relevancia de los Prueba para ayudar a determinar donde mantener o retirar Pruebas Elementos del diseo de software Establece ajustes de los subsecuentes cambios en el diseo que harn necesario la re-ejecucin de Prueba o su retiro Peticin de los resultados de los cambios Permite a los Pruebas que descubrieron la necesidad de un cambio, ser identificados y ejecutados nuevamente para verificar que la peticin de cambios a sido completada satisfactoriamente ] 13.6.Aprobacin y Trmino [Describe el proceso de aprobacin y lista los ttulos de los trabajos (y nombres de los actuales Responsables), antes de esto el plan debe haber sido aprobado y los planes deben haber completado satisfactoriamente su ejecucin]

266

8.4.13 Plantilla Lista de Riesgos

<Nombre del proyecto> Lista de Riesgos Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de Base para la confeccin del documento de Lista de Riesgos. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. El formato del texto debe tener tipo de letra verdana. ]

267

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin <1.1.0> Descripcin Documento inicial Autor <Nombre>

268

ndice
1. Introduccin 269 1.1 Propsito 269 1.2 mbito 269 1.3 Definiciones, Acrnimos, y Abreviaciones 269 1.4 Referencias 269 1.5 Resumen Ejecutivo 269 2. Gestin de los Riesgos 270 3. Riesgos 271 3.1 Resumen de los riesgos 271 3.2 Nivel de magnitud y valores de Exposicin 271 3.3 Valores de Probabilidad e impacto 271 Tabla 3 271 4. Detalles de los riesgos 272 4.1 <Identificador de RiesgoUn nombre descriptivo o numero> 272 4.1.1 Magnitud del Riesgo o Ranking 272 4.1.2 Descripcin 272 4.1.3 Impactos 272 4.1.4 Indicadores 272 4.1.5 Estrategia de mitigacin 272 4.1.6 Plan de contingencia 272 4.2 <Siguiente identificador de RiesgoUn nombre descriptivo o numero> 272

269

Lista de Riesgos
1. Introduccin
[La introduccin de la Lista de Riesgos es un resumen del resto del documento. Incluye el propsito, mbito, definiciones, acrnimos, abreviaciones, referencias y una descripcin de esta Lista de Riesgos] 1.1. Propsito [Especificar el propsito de esta Lista de Riesgos.] 1.2. mbito [Es una descripcin del mbito de esta Lista de Riesgos; que proyectos estn asociados con cualquier cosa que afecte o influya este documento.] 1.3. Definiciones, Acrnimos, y Abreviaciones [Esta seccin entrega las definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente la Lista de Riesgos. Esta informacin puede ser obtenida del Glosario del proyecto] 1.4. Referencias [Esta seccin entrega una lista completa de todos los documentos referenciados en cualquier lugar de la Lista de Riesgos. Identificando cada documento por ttulo, edicin si es aplicable, fecha, y editorial. Especificando las Fuentes de donde se pueden obtener las referencias. Esta informacin puede ser entregada como referencia en un apndice o algn otro documento.]

1.5. Resumen Ejecutivo [Esta seccin describe que contiene el resto del documento y explica cmo est organizado.]

270

2.

Gestin de los Riesgos

El objetivo de la gestin de riesgos de los proyectos es identificar problemas potenciales antes de que ocurran de manera que las actividades de manejo de riesgos puedan ser planeadas y usadas cuando se necesiten durante la vida del proyecto para mitigar los impactos adversos que impidan alcanzar los objetivos del proyecto. RUP (Rational Unified Process) considera la evaluacin de los riesgos como una parte fundamental del proceso. Es necesario decidir cmo abordar, planificar y ejecutar las actividades de gestin de riesgos para un proyecto.
Id 1 Paso Identificar riesgos Analizar y priorizar Planear Hacer seguimiento y reportar Registro organizaciona l Descripcin En la fase de Inicio y Planeacin se identifican los riesgos del proyecto, en primera instancia se busca en el plan de riesgos los posibles riesgos, si no se encuentra en el listado se ingresa como un riesgo genrico del proyecto Asignar a cada riesgo la probabilidad de ocurrencia que debe estar entre 0 y 50% segn la priorizacin y el anlisis Formular estrategias, acciones y planes de mitigacin para los riesgos identificados Supervisar los planes de accin, verificar que los planes de mitigacin han sido implementados, en caso de que no funcionen, reportar el riesgo materializado, fecha, nmero de ocurrencias, magnitud de prdida en horas, solucin y accin correctiva y preventiva formulada Registrar en lecciones aprendidas aquellos riesgos que se materializaron en el proyecto y que deban formar parte del conocimiento organizacional para que sirvan de fuente de consulta para otros proyectos Responsable Vendedor PM Vendedor PM Vendedor PM Salida Plan de Riesgos Plan de Riesgos Plan de Riesgos Plan de Riesgos

2 3

PM

PM

Lecciones Aprendida s

271

3.
3.1.

Riesgos
Resumen de los riesgos

Fase/Iteracin del proyecto M a g n i t u d Tabla 1

3.2. Nivel de magnitud y valores de Exposicin
Concepcin 1 Elaboracin 1 Construccin 1 Transicin 1

Riesgo

Magnitud A Alto S Significativo M Moderado I Inferior B Baja Tabla 2

3.3. Valores de Probabilidad e impacto

Exposicin 6.4 a 10.0 3.6 a 6.4 1.6 a 3.6 0.4 a 1.6 0 a 0.4

Nivel Alto Significativo Moderado Inferior Bajo

Valores de Probabilidad 0.8 a 1.0 0.6 a 0.8 0.4 a 0.6 0.2 a 0.4 0.0 a 0.2 Tabla 3

Valores de Impacto 8.0 a 10.0 6.0 a 8.0 4.0 a 6.0 2.0 a 4.0 0.0 a 2.0

272

4.

Detalles de los riesgos

[Para lograr el xito del proyecto es necesario realizar un estudio a conciencia de todos los riesgos que inciden, sea de forma directa o indirecta, tomar las acciones necesarias, tener el control y darle total seguimiento a los mismos, con el fin de evitarlo o reducir el impacto que pueda generar.]

4.1.

<Identificador de RiesgoUn nombre descriptivo o numero>

[Identificar los riesgos: Consiste en determinar todos los riesgos posibles que podran afectar el proyecto y determinar sus caractersticas]. 1.1.55. Magnitud del Riesgo o Ranking [Un indicador de la magnitud del riesgo, puede ser asignado a un ranking de riesgos ordenado desde el ms daino al menos daino hacia el proyecto.] 1.1.56. Descripcin [Una descripcin del riesgo.] 1.1.57. Impactos [Lista el impacto en el proyecto o producto. El impacto (CONSECUENCIAS) hay que medirlo en el alcance: cuanto se afecta la duracin (por cunto tiempo se manifiesta el riesgo).] 1.1.58. Indicadores [Describe como monitorear y detectar que los riesgos han ocurrido o pueden ocurrir. Incluyendo aquellas cosas como mtricas y umbrales, resultados de las pruebas, eventos especficos, etc.] 1.1.59. Estrategia de mitigacin [Describe que se hace actualmente en el proyecto para reducir el impacto de los riesgos.] 1.1.60. Plan de contingencia [Describe el curso de accin a seguir en caso de que el riesgo de materialice. Soluciones alternativas, reduccin de funcionalidad, etc.] 4.2. <Siguiente identificador de RiesgoUn nombre descriptivo o numero>

273

8.4.14 Plantilla Minuta de la Reunin

<Nombre del proyecto> Minuta de la reunin

Versin: Descripcin: Hora inicio: <1.1.0> Fecha: Lugar Hora termino: a. <aaaa-mm-dd> <lugar> <hh:mm>

<Caracterstica genrica de la reunin>

<hh:mm>

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin <Detalles> Autor <Nombre>

1. Participantes
[Prrafo obligatorio.] [Ingresar todos los participantes de la reunin con nombre, cargo y empresa.]

Nombre

Cargo

Empresa

2.

Definiciones, Acrnimos y Abreviaciones

[Prrafo obligatorio si aplican.] [Si existen cosas como nombres cortos, signos, Por ejemplo nombre de la empresa o persona se puede describir con dos letras de nombre.]

3.

Referencias
[Prrafo obligatorio si existen referencias con otros artefactos.] [Nombrar documentos, informes o cosas similares conectadas con el tema de la reunin.]

4.

Temas
[Prrafo obligatorio.] [Describir todos los temas de reunin. Cada tema tiene su propia descripcin. Exponer opiniones de los participantes de la reunin sobre el tema]

274
4.1. <Tema 1>

5. Compromisos
[Prrafo obligatorio.] [Describir todos los compromisos acordados durante la reunin. Cada compromiso tiene sus acciones acordadas, su plazo y su(s) responsable(s). Por ejemplo, un compromiso puede ser un tema de la reunin, como Plan del Proyecto, y acciones acordadas pueden ser entregar plan del proyecto a Gerente.]

Compromiso

Acciones Acuerdos

Plazo

Responsable(s)

6.

Seguimiento
[Prrafo obligatorio si se realiza seguimiento.] [Listar las actividades a las cuales se les realiza seguimiento durante la reunin, con su responsable, el plazo de finalizacin y el avance al momento de la reunin.]

Actividad

Responsables (s)

Plazo

Avance

7.

Conclusiones
[Prrafo NO obligatorio.] [Describir todas las conclusiones de la reunin. Cada conclusin tiene su propia descripcin. Exponer responsables para cada conclusin.]

7.1. 7.2.

<Conclusin 1> <Conclusin 2>

275

8.4.15 Plantilla Asignacin de Roles

<Nombre de Proyecto> Asignacin de Roles Versin <1.1.0>

[Esta plantilla tiene por finalidad servir de base para la confeccin del documento Asignacin de Roles. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento.]

276

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <autor>

277

ndice
1 Introduccin ................................................................................................................ 278 1.1 Propsito ............................................................................................................... 278 1.2 mbito .................................................................................................................. 278 1.3 Definiciones, acrnimos y abreviaciones ............................................................... 278 1.4 Referencias ........................................................................................................... 278 1.5 Resumen Ejecutivo ............................................................................................... 278 2 Asignacin de Roles de la Organizacin y del Cliente ................................................. 279 2.1 Organigrama del Proyecto ..................................................................................... 279 2.2 Esquema de comunicaciones ................................................................................. 279 2.3 Asignacin de roles para el Proyecto ..................................................................... 280 3 Identificacin de Dependencias Crticas....................................................................... 281

278

14.Introduccin
[La introduccin debe proveer un resumen del documento completo. Presente cualquier informacin que el lector pueda necesitar para entender el documento en esta seccin.] 14.1.Propsito El propsito del documento es describir el equipo del proyecto y establecer sus responsabilidades y roles. 14.2.mbito [Describa el alcance de este documento, a qu proyecto est asociado y cualquier elemento que se vea afectado o influenciado por este documento.] 14.3.Definiciones, acrnimos y abreviaciones [Esta subseccin provee las definiciones de todos los trminos, acrnimos, y abreviaciones requeridas para interpretar correctamente el documento. Esta informacin puede entregarse a modo de referencia a documento Glosario del proyecto.] 14.4.Referencias [Esta subseccin provee una lista completa de todos los documentos referenciados en cualquier parte de este artefacto. Cada documento debe ser identificado por ttulo, edicin/versin, fecha, autor y nombre de archivo. Especificar las fuentes de donde se pueden obtener estas referencias. Esta informacin puede ser entregada como referencia a un apndice o a otro documento.] 14.5.Resumen Ejecutivo [Esta subseccin debe describir brevemente el resto del documento y explicar cmo est organizado.]

279 15.Asignacin de Roles de la Organizacin y del Cliente

15.1.Organigrama del Proyecto

El siguiente diagrama contiene la estructura de roles del proyecto:

[Incorporar todos los roles necesarios en el diagrama, la estructura debe corresponder a la realmente utilizada en el proyecto, la que se muestra solo es un ejemplo.]
Equipo del proyecto

Gerente de proyectos <Nombre>

Grte. de proyectos - Cliente <Nombre>

Analista de calidad <Nombre>

Jefe de proyecto - Cliente <Nombre>

Jefe de proyecto <Nombre>

Representante de los usuarios <Nombre>

Admin. De config. <Nombre>

Diseador graf. (Opcional) <Nombre>

Equipo de Desarrollo

[El Equipo de Desarrollo se compone de ingenieros de software y de sistemas (analistas, arquitectos, programadores, etc.), testeadores y documentadores, opcionalmente el diseador grfico puede ser externo a este grupo.] [Hay tres roles distintitos que como mnimo debe definir la organizacin Cliente en un proyecto. Estos son: Gerente de proyectos, Jefe de proyectos y Representante de los usuarios. Es decir, el Cliente debe actuar como contraparte efectiva en el proyecto, gestionando recursos por parte del cliente (Jefe de proyectos), colaborando en la definicin de los requerimientos, en la validacin/aceptacin de los productos y/o servicios (Representante de los usuarios), y en el seguimiento y aprobacin general del proyecto (Gerente de proyectos).] 15.2.Esquema de comunicaciones [En esta seccin se deben identificar todos los canales de comunicacin que son relevantes para el proyecto, al menos se debe considerar el documentar quin ser el interlocutor vlido para solicitudes de requerimientos.] De acuerdo a los roles identificados en el proyecto, por el lado de la organizacin el receptor de requerimientos ser el Jefe de proyecto, <Nombre del Jefe de proyecto> y el solicitante vlido de requerimientos o modificaciones a los mismos ser el <rol del solicitante>, <nombre del solicitante>.

280

15.3.Asignacin de roles para el Proyecto [Los roles consignados en la siguiente tabla corresponden a una representacin de roles en el modelo RUP los cuales se deben mapear con los utilizados en su organizacin. Se debe adoptar la nomenclatura y descripcin que se utilice en su organizacin, o adoptar los descritos.]
Roles en RUP Gerente de Proyectos Planifica y controla los recursos fsicos, humanos, monetarios e informticos que se le otorgan para lograr los resultados esperados de los distintos proyectos de desarrollo de su rea. Jefe de Proyecto Lidera y coordina al grupo de trabajo, verifica y revisa los productos, configura el proceso, decide y verifica el cumplimiento de las mejores prcticas, define, sigue y controla el plan del proyecto, define y sigue los riesgos, gestiona los contactos necesarios con los usuarios coordinando su interaccin con el grupo de trabajo. Grupo de Ing. de Software Trabaja en el desarrollo y mantencin de software, lleva a cabo actividades como anlisis, diseo, codificacin, testing, documentacin, y redaccin de informes tcnicos. Rol en la Organizacin [Ingrese en esta columna el rol equivalente en su organizacin] [Ej. Director de operaciones, Chief Operating Officer (COO) Senior Manager (SM)] [Ingrese en esta columna el rol equivalente en su organizacin] [Ej. Project Manager (PO),] Responsable [Ingrese en esta columna el nombre de la(s) persona(s) responsable(s)]

[Ingrese en esta columna el rol equivalente en su organizacin] [Otros Ejemplos, Arquitecto de SW, Diseador grfico, Diseador de BD, Diseador de SW, Diseador Grfico, Programador,] [Ingrese en esta columna el rol equivalente en su organizacin] [Otros Ejemplos, Analista, Analista de sistemas, Revisor de requerimientos, Especificador de requerimientos,] [Ingrese en esta columna el rol equivalente en su organizacin] [Otros Ejemplos, Diseador de casos de prueba, Analista de pruebas,] [Ingrese en esta columna el rol equivalente en su organizacin] [Otros Ejemplos, Configuration Management (CM) Group, Software Configuration Management (SCM) Group, ]

Grupo de Ing. de Sistemas Responsable por la especificacin de requerimientos, de asignar los requerimientos de hardware y software, de especificar las interfaces, y de controlar el diseo para mantener la consistencia de los componentes durante todo el ciclo de vida del proyecto. Probador Responsable de disear el plan de pruebas, desarrollar los casos de prueba, preparar el ambiente de pruebas, los datos de prueba y ejecutar los ciclos de prueba. Administrador de Configuraciones Planifica y realiza las actividades de administracin de configuracin. Controla y autoriza todos los cambios en las lneas base. La administracin del repositorio de lneas base es revisada y aprobada por este rol antes de tomar cualquier accin.

281
Roles en RUP Analista de Calidad Planifica y acta en actividades de aseguramiento de calidad de los procesos y en que los productos no se desven de los estndares. Es independiente de los grupos de Administracin y Desarrollo. Realiza reportes directamente a Gerente de proyectos. Rol en la Organizacin [Ingrese en esta columna el rol equivalente en su organizacin] [Otros Ejemplos, Process and Product Quality Assurance (PPQA) Group, PPQA Manager, Software Quality Assurance Group (SQA),] [Ingrese en esta columna el rol equivalente en su organizacin] [Otros Ejemplos, Evaluador tcnico, Marketing & Sales (MS),] [Ingrese en esta columna el rol equivalente en su organizacin] [Otros Ejemplos, Technical writer,] Responsable

Vendedor Responsable de la documentacin y del diseo de propuestas comerciales a Clientes y de los contratos con subcontratistas. Documentador Produce material generalmente para la implantacin y los usuarios finales aunque eventualmente puede colaborar con la redaccin de otros artefactos necesarios.

16.Identificacin de Dependencias Crticas

[Identificar y documentar dependencias crticas entre los involucrados en el proyecto. Para cada dependencia identificada se debe describir compromisos adquiridos entre las partes, criterios para determinar si los compromisos se satisfacen y un calendario de interaccin.]

282

8.4.16 Plantilla Plan de Despliegue del Proyecto

<Nombre del Proyecto> <Plan de Despliegue> Versin <1.1.0>

[Nota: Esta plantilla tiene por finalidad servir de base para la confeccin documentos o informes distintos a los definidos. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. Ninguno de los Campos definidos es obligatorio.]

283

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

284

ndice
1 Introduccin 1.1 Propsito 1.2 Alcance 2 Ambiente de instalacin 3 Pre-requisitos 4 Salidas 5 Entrenamiento 6 Respaldo 7 Pasos para llevar a cabo la instalacin 8 Seguridad 9 Agenda 10 Comprobacin instalacin 11 Tiempo para solucionar errores en instalacin 285 285 285 285 285 285 286 286 286 286 286 287 287

285

Plan de Despliegue del Proyecto

17.Introduccin
[Seccin NO obligatoria.]

17.1.Propsito [Objetivo, determinar qu se pretende conseguir con el procedimiento].

Describir el alcance y los elementos necesarios a cabo un despliegue del software en las instalaciones del cliente. El producto que se ha producido, disear como hacerlo llegar a los usuarios finales.
17.2.Alcance [Efecto o trascendencia del procedimiento. Hasta donde cubre. Si es posible, explicar qu no se cubre. Definir el alcance de la instalacin, qu funcionalidades y servicios quedarn habilitados una vez finalice la instalacin].

18.Ambiente de instalacin
[Definir los servidores, bases de datos y sitios dnde se llevar a cabo la instalacin Tiempo necesario para llevar a cabo la instalacin Riesgos que se pueden materializar durante la instalacin y plan de mitigacin en caso de materializarse Carga de datos o configuracin de tablas maestras para que el software pueda operar]

19.Pre-requisitos
[Identificar qu elementos deben estar listos antes de llevar a cabo la instalacin (estructura de directorios, imgenes, dlls, componentes, backup, etc.)]

20.Salidas
[Identificar todos los elementos que deben quedar listos una vez se concluya la instalacin:]

Base de datos WebServices Aplicacin Reportes Cron automtico Libreras Componentes Triggers, etc.

286 21.Entrenamiento
[Conocimientos necesarios para llevar a cabo la instalacin]

22.Respaldo
[Describir todos los elementos a los cuales se les debe sacar backup antes de realizar la instalacin, dnde sern almacenados en caso de ser necesario recuperar la informacin.]

1. 2. 3. 4.

Base de datos Fuentes Scripts Etc.

23.Pasos para llevar a cabo la instalacin

[Describir todo los pasos que van a ser necesarios para realizar la instalacin en los diferentes equipos del cliente, segn se especifico en el Plan del Proyecto de Desarrollo de Software] Por ejemplo:

1. 2. 3. 4. 5. 6. 7.

Backup Creacin base de datos Carga datos iniciales Instalar aplicacin Instalar componentes Configuracin sitio Montar contenedor (websphere, tomcat, resin, internet information server, application server) 8. Definir contexto 9. Creacin estructura de directorios del proyectos 10. Copia de archivos compilados 24.Seguridad
[En esta seccin es necesario tomar en cuenta todos los elementos existentes en el cliente, a la hora de realizar la instalacin de las aplicaciones.]

Integracin con Active Directory, LDAP Transacciones seguras SSL Registro de componentes de seguridad Etc...

25.Agenda
Actividad Fecha y hora inicial estimada Fecha y hora final estimada Responsable IG Responsable Cliente Recursos Observaciones Fecha y hora inicial real Fecha y hora final real

287 26.Comprobacin instalacin

[Describir las actividades que determinarn que la instalacin qued satisfactoria, especificar pruebas de instalacin]

27.Tiempo para solucionar errores en instalacin

[En caso de presentarse errores en la instalacin, especificar el tiempo mximo para solucionar errores, en caso de superar este tiempo, especificar que se aborta la instalacin y determinar cmo se dejar el software, en caso de ser un paralelo indicar que se deja corriendo el software anterior.]

288

8.4.17 Plantilla Lista de Revisin del Ciclo de Vida del Proyecto

DATOS GENERALES DEL PROYECTO

Responsable Proyecto Cliente

Administrador del Proyecto (PM) NOMBRE NOMBRE

Historia de Revisiones
Fecha <dd-mm-yyyy> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

Planeacin
Entregable Plan de desarrollo de software Plan Manejo de requisitos Plan de Administracin de Configuracin (CM) Plan de riesgos Lista de revisin ciclo de vida proyectos Acta del Proyecto Solicitud creacin estructura de repositorios Elaborar WBS Ordenamiento de actividades Estimacin duracin de actividades Criterios de aceptacin Kickoff interno Kickoff externo Planear siguiente iteracin Requerido S S S S S S S S S S S No No S Aprobacin Interna S S S S No No No No No No No No No No Aprobado Por PMO Comit requisitos CM PMO No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica Aprobacin Cliente S S No S No No No No No No S No No No

Requisitos
Entregable Documento Visin Glosario Documento de Especificacin de Requisitos de Software Modelo del negocio Modelo del dominio Lista de requisitos de alto nivel en EA Lista de actores en EA Documento de Atributos de los Requisitos Diagrama de casos de uso Plan de riesgos Acta de reunin de licitacin Documento especificacin caso de uso Matriz de trazabilidad de requisito Email solicitud revisin par Email con retroalimentacin revisin par Acta de entrega Presentacin requisito Lecciones aprendidas Acciones correctivas, preventivas, mejora Requerido S No No S S S S No S S S S S S S S No S S Aprobacin Interna S S S No No No No No No No No S No No No No No No No Aprobado Por Revisor par No aplica Revisor par No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica Revisor par No aplica No aplica No aplica No aplica No aplica No aplica No aplica Aprobacin Cliente S S S No No No No No No No S S No No No S No No No

Anlisis y Diseo
Entregable Requerido Aprobacin Interna Aprobado Por Aprobacin Cliente

289
Comit arquitectura No aplica No aplica No aplica Revisor par No aplica No aplica Revisor par Revisor par No aplica No aplica No aplica No aplica No aplica No aplica No aplica

Documento de arquitectura de software Acta comit de arquitectura Email solicitud revisin par Email con retroalimentacin revisin par Prototipo Flujo de navegacin Documento de usabilidad Documento especificacin caso de uso refinado Modelo de datos Cumplimiento estndar base de datos Diseo de pruebas unitarias Check list anlisis y diseo Acta de entrega Criterios de aceptacin Lecciones aprendidas Acciones correctivas, preventivas, mejora

S S S S No No S S S S S S S S S S

S No No No S No No S S No No No No No No No

S No No No S No S S S No No No S S No No

Implementacin
Entregable Acta de entrega de diseo Presentacin diseo Inventario de componentes Cdigo fuente de la solucin Cumplimiento estndares codificacin Cumplimiento convenciones nombramiento Prueba unitaria Email solicitud revisin par Registro de errores encontrados Lista de chequeo de desarrollo Diagrama de secuencia Integracin de componentes Artefactos para despliegue Manual de instalacin y configuracin Plan de despliegue Check list de instalacin Lecciones aprendidas Acciones correctivas, preventivas, mejora Requerido S No S S S S S S S S S S S S S S S S Aprobacin Interna No No No No No No No No No No No No No S No No No No Aprobado Por No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica No aplica Equipo pruebas No aplica No aplica No aplica No aplica Aprobacin Cliente S No No No No No No No No No No No No S S No No No

Prueba
Entregable Plan de pruebas Lista de ideas de prueba Check list de pruebas Registro de errores en Bugtracker Diseo y ejecucin casos de prueba Estadsticas Carta de certificacin Lecciones aprendidas Acciones correctivas, preventivas, mejora Requerido Opcional Opcional Opcional S S S S S S Aprobacin Interna S No No No No No S No No Aprobado Por PM No aplica No aplica No aplica No aplica No aplica Coordinador Pruebas No aplica No aplica Aprobacin Cliente No No No No No No No No No

Ejecucin
Entregable Gestionar avance cronograma Gestionar riesgos Gestionar facturacin Aseguramiento de calidad Requerido S S S S Aprobacin Interna No No No No Aprobado Por No aplica No aplica No aplica No aplica Aprobacin Cliente No No No No

Pruebas
Entregable Plan de pruebas Lista de ideas de prueba Check list de pruebas Registro de errores Diseo y ejecucin casos de prueba Requerido S S S S S Aprobacin Interna S No No No No Aprobado Por PM No aplica No aplica No aplica No aplica Aprobacin Cliente No No No No No

290
Estadsticas Carta de certificacin Lecciones aprendidas Acciones correctivas, preventivas, mejora S S S S No S No No No aplica Coordinador Pruebas No aplica No aplica No No No No

Despliegue
Entregable Plan de despliegue Inventario de componentes de despliegue Lista de chequeo despliegue Control de asistencia Evaluacin instructor Lecciones aprendidas Acciones correctivas, preventivas, mejora Requerido S S S S S S S Aprobacin Interna No No No No No No No Aprobado Por No aplica No aplica No aplica No aplica No aplica No aplica No aplica Aprobacin Cliente S No No No No No No

Control
Entregable Gestionar cronograma Gestionar control de cambios Gestionar personal (vacaciones, capacitacin) Gestionar riesgos Seguimiento interno proyecto (analistas) Informes estado proyecto Seguimiento interno proyecto (PMO) Informe de avance (cliente) Acta de reunin (cliente) Acciones correctivas, preventivas, mejora Requerido S S No S S S S S S S Aprobacin Interna No S S No No S No No No No Aprobado Por No aplica PM PMO No aplica No aplica PM No aplica No aplica No aplica No aplica Aprobacin Cliente No S No No No No No S S No

Entrega
Entregable Criterios de aceptacin Asistencia Plan capacitacin Evaluacin capacitacin Instalador Manual de instalacin y configuracin Manual de usuario Acta de entrega Lecciones aprendidas Acciones correctivas, preventivas, mejora Requerido S No No No S S S S S S Aprobacin Interna No No S No No No No No No No Aprobado Por No aplica No aplica PMO No aplica No aplica No aplica No aplica No aplica No aplica No aplica Aprobacin Cliente S No S No No S S S No No

291

8.4.18 Plantilla Documento Arquitectura del Software

<Nombre Proyecto> Documento de Arquitectura de Software Versin <1.0>

[Nota: Esta plantilla tiene como finalidad servir de base para la construccin del documento de la Arquitectura del Software, basada en Rational Unified Process. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) se incluye para proporcionar una gua al autor y debe ser borrado antes de publicar el documento. Un prrafo introducido siguiendo este estilo se ajustar automticamente a la normalidad (Texto Fsica =).]

292

Historia de Revisiones
Fecha <dd/mm/yy> Versin <x.x> Descripcin <detalles> Autor <nombre>

293

ndice
1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones, acrnimos y abreviaturas 1.4 Referencias 1.5 Resumen 2. Representacin Arquitectnica 3. Metas y Restricciones de la Arquitectura 4. Vista de Casos de Uso 4.1 Casos de Uso-Realizaciones 5. Vista Lgica 5.1 Resumen 5.2 Diseo Arquitectnico de Paquetes 6. Vista del Proceso 7. Vista de Despliegue 8. Vista de Implementacin 8.1 Informacin general 8.2 Capas 9. Vista de datos (opcional) 10. Tamao y Rendimiento 11. Calidad 294 294 294 294 294 295 295 295 296 296 296 296 296 297 297 297 297 297 297 298 298

294

Documento de Arquitectura de Software

1. Introduccin
Uno de los desarrollos ms importantes dentro de la construccin del software es el desarrollo de la arquitectura de software, que permite representar la estructura del sistema, sirviendo de comunicacin entre las personas involucradas en el desarrollo y ayudando a realizar diversos anlisis que orienten el proceso de toma de decisiones. La plantilla de este documento se bas en las especificaciones de RUP (Rational Unified Process) para el documento de arquitectura de software. [La introduccin del Documento de Arquitectura de Software proporciona una visin general del Documento completo. Incluye el propsito, alcance, definiciones, acrnimos, abreviaturas, referencias, y una visin general del Documento de Arquitectura de Software.] 1.1. Propsito

Este documento proporciona una descripcin de la arquitectura del sistema, haciendo uso de diversas visiones arquitectnicas para representar diversos aspectos del sistema. Se realiza con el fin de documentar las decisiones de arquitectura significativas que se han tomado en el sistema. [En esta seccin se define la funcin o el propsito del Documento de Arquitectura de Software, en la documentacin general del proyecto, y describe brevemente la estructura del documento. Las audiencias especficas para el documento se identifica, con indicacin de la forma en que se espera que utilicen el documento.] 1.2. Alcance [Una breve descripcin de lo que consiste el Documento de Arquitectura de Software. Lo que se ve afectada o influenciada por este documento, definiendo de manera detallada la distribucin de los paquetes del sistema en las diversas capas que ste presenta, as como una descripcin de las capas a utilizar.] 1.3. Definiciones, acrnimos y abreviaturas [Esta seccin provee las definiciones de los trminos, acrnimos y abreviaturas requeridas para interpretar apropiadamente el Documento de Arquitectura de Software. Esta informacin puede ser proporcionada por referencia al Glosario del proyecto.] 1.4. Referencias [Esta seccin provee una lista completa de todos los documentos referenciados en cualquier parte del Documento de Arquitectura de Software. Identifica cada documento por el nmero y nombre de informe, (si aplica), fecha y organizacin que lo publica. Especifique las fuentes de donde las referencias se pueden obtener. Esta informacin puede ser proporcionada por referencia a un apndice o a otro documento.]

Por ejemplo algunas de las referencias aplicables pueden ser:

295 1. 2. 3. 4. Documento de Especificacin de Requisitos de Software. Documento de Visin del Proyecto del Sistema. Glosario de Trminos del Sistema. Plan de Proyecto del Sistema.

1.5. Resumen [Esta seccin describe lo que el resto del Documento de Arquitectura de Software contiene y explica cmo el Documento de Arquitectura de Software est organizado.] Todas las secciones de este documento detallan la arquitectura del software a desarrollar. Para ello se presenta de manera clara el caso de uso que mas representa la arquitectura del sistema, empleando un lenguaje sencillo y directo, as como grficos y vistas de acuerdo a la metodologa utilizada. Por ejemplo: Se incluye la Vista de Casos de Uso, con una descripcin completa de cada uno de ellos y sus respectivos diagramas. Luego, se muestra la Vista Lgica en la que se muestran las principales clases que modelan al sistema y las relaciones que existen entre ellas, as como tambin el diseo de los paquetes de la arquitectura. Tambin se encuentra la Vista de Despliegue, cuyo principal objetivo es establecer los requerimientos del sistema en cuanto a la arquitectura requerida para su correcto funcionamiento.

2.

Representacin Arquitectnica
[Esta seccin describe lo que la arquitectura de software es que el sistema actual, y cmo se representa. De los casos de uso, lgico, Vista al proceso, el despliegue y ejecucin, se enumeran los puntos de vista que son necesarios, y para cada punto de vista, explica qu tipos de elementos del modelo que contiene.] Por ejemplo: La Arquitectura a utilizar ser Cliente-Servidor. El cliente es la aplicacin que ser implementada en el lugar donde se encuentra la empresa. Se desarrollar una sola aplicacin integrada, en la que solo se permitir el acceso a los usuarios registrados en el sistema y a las reas a las cuales tengan acceso autorizado. Se emplear un solo servidor centralizado.

3.

Metas y Restricciones de la Arquitectura

[Esta seccin describe los requisitos de software y los objetivos que tienen algn impacto significativo en la arquitectura, por ejemplo, la seguridad, la privacidad, el uso de un producto fuera de la plataforma, la portabilidad, la distribucin y la reutilizacin. Tambin captura las restricciones especiales que pueden aplicarse: Diseo y estrategia de implementacin, herramientas de desarrollo, la estructura del equipo, calendario, cdigo de la herencia, y as sucesivamente]

296 4. Vista de Casos de Uso

[Esta seccin muestra los casos de uso o escenarios del modelo de caso de uso si representan alguna funcionalidad significativa, en el centro del sistema final, o si tienen una gran cobertura arquitectnica-que ejercen muchos elementos arquitectnicos o si ilustran el estrs o un procedimiento especfico, punto delicado de la arquitectura.]

4.1. Casos de Uso-Realizaciones [En esta seccin se ilustra cmo el software funciona realmente dando un grupo selecto de casos de uso (o escenario) realizaciones, y explica cmo los diversos elementos de diseo de modelos de contribuir a su funcionalidad.]

5.

Vista Lgica
[Esta seccin describe las partes arquitectnicamente significativas del modelo de diseo, tales como su descomposicin en subsistemas y paquetes. Y para cada paquete importante, su descomposicin en clases y los servicios pblicos de clase. Usted debe introducir clases de gran importancia arquitectnica y describir sus responsabilidades, as como algunas relaciones muy importantes, operaciones y atributos.]

5.1.

Resumen

[Esta seccin describe la descomposicin general del modelo de diseo en cuanto a su jerarqua de paquetes y las capas. Soporta los requerimientos funcionales y los servicios que el sistema debe proveer a sus usuarios finales.]

5.2.

Diseo Arquitectnico de Paquetes

[Para el diseo de la arquitectura del sistema a desarrollar se utilizara la nocin de paquetes, los cuales representan el formato de tres capas que por el que se rige el desarrollo del proyecto. Para cada paquete principal, incluir un apartado con su nombre, breve descripcin y un diagrama con todas las clases y paquetes significativos contenidos en el paquete. Para cada clase significativa en el paquete, incluir su nombre, una breve descripcin y, opcionalmente, una descripcin de algunos de sus principales responsabilidades, operaciones y atributos.] Los paquetes ms utilizados normalmente son: Paquete Interfaz: Representa el fragmento del proyecto que interactuar con los distintos usuarios, recibir informacin y solicitudes por parte de stos as como tambin mostrar las respuestas a las diferentes solicitudes. Paquete Manejador: Se encargar del manejo de las consultas y utilizacin de la base de datos en la cual se encontrar toda la informacin relacionada a las distintas funcionalidades que ofrecer el sistema.

297
Paquete Lgico del Negocio: Se encarga de realizar todas las operaciones y mtodos que ofrece el sistema, as como tambin de la validacin de datos antes de realizar las consultas. Contiene la lgica para el manejo de las operaciones del negocio.

6.

Vista del Proceso

[Esta seccin describe la descomposicin del sistema en los procesos ligeros (hilos de control individuales) y los procesos de peso pesado (agrupaciones de procesos ligeros). Organizar la seccin de los grupos de procesos que se comunican o interactan. Describir las principales vas de comunicacin entre procesos, como el paso de mensajes, alarmas, y el encuentro. Se incluye aqu el Diagrama de Entidad Relacin, que es el diagrama principal para el Anlisis y Diseo, adems de la inclusin del Diccionario de Datos relacionado al Diagrama de Entidad Relacin]

7.

Vista de Despliegue
[Esta seccin describe una o ms de la red fsica (hardware) las configuraciones en las que se ha implementado el software y ser ejecutado. Se trata de un punto de vista del modelo de implementacin. Como mnimo para cada configuracin debe indicar los nodos fsicos (ordenadores, CPUs) que ejecutan el software y sus interconexiones (bus, LAN, punto a punto, y as sucesivamente.) Tambin incluyen un mapeo de los procesos del Proceso Ver en los nodos fsicos.]

8.

Vista de Implementacin
[Esta seccin describe la estructura general del modelo de implementacin, la descomposicin del software en capas y subsistemas en el modelo de implementacin, y cualquier otro componente de gran importancia arquitectnica.]

8.1.

Informacin general

[Esta seccin define los nombres y las diferentes capas y su contenido, las reglas que rigen la inclusin de una capa determinada, y los lmites entre las capas. Incluir un diagrama de componentes que muestra las relaciones entre las capas. ]

8.2.

Capas

[Para cada capa, incluyen una subseccin con su nombre, una enumeracin de los subsistemas situados en la capa, y un diagrama de componentes.]

9.

Vista de datos (opcional)

[Una descripcin de la perspectiva de volumen de datos generados por del sistema. Esta seccin es opcional si hay volumen de datos poco o nada, o la traduccin entre el modelo de diseo y el modelo de datos es trivial.]

298

10.

Tamao y Rendimiento

[Una descripcin de las caractersticas principales de dimensionamiento del software que afectan la arquitectura, as como las limitaciones de rendimiento de destino.] Se puede describir aspectos como:

Tiempo de respuesta en el acceso a la Base de Datos Tiempo de respuesta de transacciones Espacio en disco para el cliente Espacio en disco para el servidor de Base de datos

11.

Calidad

[Una descripcin de cmo la arquitectura del software contribuye a todas las capacidades (que no sea la funcionalidad) del sistema: extensibilidad, fiabilidad, portabilidad, y as sucesivamente. Si estas caractersticas tienen un significado especial, como la implicacin en la seguridad, la seguridad o privacidad, que debe estar claramente delimitada.]

Para un mejor aprovechamiento de la arquitectura de software se pueden revisar los siguientes aspectos: Usabilidad Eficiencia Seguridad Confiabilidad Mantenimiento Estndares

299

8.4.19 Plantilla Solicitud de Cambio de Requerimientos

Solicitud de Cambio de Requerimientos

Iniciador autorizado:

ID Cambio:

Estado: [ Abierto / Cerrado ]

Cambio propuesto Descripcin

Beneficio esperado / Justificacin

Anlisis de Impacto En calendario Comentarios: En recursos En costos

Evaluacin del Comit de Control de Cambios Beneficio / Prioridad: [ Crtico / Importante / til / Ninguna ] Comentarios:

Aprobado Emisor de la propuesta Firma: Responsable del anlisis de impacto Firma:

No aprobado Responsable por la evaluacin Firma: Iniciador notificado Firma: Cerrado Firma:

Fecha:

Fecha:

Fecha:

Fecha:

Fecha:

300

8.4.20 Plantilla Acta de Inicio del Proyecto

Nombre Proyecto: Cliente: Administrador Proyecto: Preparacin: Encargado Cliente:

Propsito del Proyecto o Justificacin:

[Definir la razn por la que est siendo creado el proyecto. En esta seccin se puede referir a un caso de negocio, el plan estratgico, los factores externos, contrato o cualquier otro documento o la razn para llevar a cabo el proyecto.]

Descripcin del Proyecto:

[Proporcionar una descripcin resumida a nivel del proyecto. En esta seccin se pueden incluir informacin a nivel macro de los productos y proyectos, as como el enfoque del proyecto.]

Proyecto y Requisitos del producto:

[Definir los requisitos principales que se deben cumplir para satisfacer el propsito del proyecto. Describir las caractersticas del producto y las funciones que deben estar presentes para satisfacer las necesidades y expectativas de los interesados. Esta seccin no se describe los requisitos detallados como los que estn cubiertos en la documentacin de requisitos.]

Criterios de aceptacin:
[Identificar los criterios que deben cumplirse para que el proyecto sea aceptado por el cliente o patrocinador.]

Riesgos Inciales:
[Documentar los riesgos inciales del proyecto. Estos luego sern incorporados a un Registro de riesgos, como la planificacin para el inicio del proyecto.]

301

Objetivos
Alcance
[Una declaracin que describe el alcance necesario para lograr los objetivos planteados para el proyecto.]

Criterios de xito
[Los criterios especficos y cuantificables que determinarn el xito del proyecto.]

Persona que Aprueba

[El nombre o la posicin de la persona que firma la aprobacin de los objetivos planteados.]

Tiempo
[Descripcin de los objetivos para lograr la finalizacin oportuna del proyecto] [Las fechas especficas que se deben cumplir para determinar el xito de la programacin.] [El nombre o la posicin de la persona que firma la aprobacin de los objetivos planteados.]

Costo
[Descripcin de los objetivos para los gastos que se incurrirn en el proyecto.] [El costo o el rango del costo que define el xito del presupuesto del proyecto] [Nombre o la posicin de la persona que firma la aprobacin de los objetivos planteados.]

Calidad
[Descripcin de los criterios de calidad que se establecern para lograr el xito el proyecto.] Medidas especficas que deben cumplirse para el proyecto y producto para ser considerado un xito. [El nombre o la posicin de la persona que firma la aprobacin de los objetivos planteados.]

Otros
[Cualquier otro tipo de objetivos apropiados que deban definirse para el proyecto.] [Resultados especficos medibles que definen el xito.] [El nombre o la posicin de la persona que firma la aprobacin de los objetivos planteados.]

Resumen de Hitos
[Hechos significativos en el proyecto. Estos pueden incluir la realizacin de objetivos clave, el comienzo o la finalizacin de una fase de proyecto o de la aceptacin del producto.]

Vencimiento
[Fecha terminacin hito.] de del

302

Presupuesto Estimado:
[Rango inicial del estimado de gastos para el proyecto]

Nivel de Autoridad del Administrador del Proyecto

Decisiones sobre el Personal:
[Definir la autoridad del administrador del proyecto para contratar, despedir, disciplinar, aceptar o no aceptar personal para el proyecto.]

Gestin del Presupuesto y Varianza

[Definir la autoridad del administrador del proyecto para tomar decisiones tcnicas sobre los entregables o el enfoque del proyecto.]

Decisiones Tcnicas
[Definir la autoridad del administrador del proyecto para tomar decisiones tcnicas sobre los entregables o el enfoque del proyecto.]

Resolucin de Conflictos
[Definir la autoridad del administrador del proyecto para resolver los conflictos dentro del equipo, dentro de la organizacin y con los interesados stakeholders externos.]

Escalamiento de los Lmites de Autoridad

[Define la ruta de escalamiento de asuntos ajenos al nivel de autoridad del administrador del proyecto.]

Aprobaciones:

Firma del Administrador del Proyecto

Firma del Cliente

Nombre del Administrador del Proyecto

Nombre del Encargado del Cliente

Fecha

Fecha

303

8.4.21 Plantilla Estructura de Desglose del Trabajo

304

8.4.22 Plantilla Cronograma del Proyecto

305

306

307

308

8.4.23 Plantilla Prototipos de Interfaces de Usuario

<Nombre del Proyecto> Prototipos de Interfaces de Usuario Versin <1.1.0>

[Nota: Este Plantilla tiene por finalidad servir de base para la confeccin de los prototipos de Interfaces de Usuario. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. Ninguno de los Campos definidos es obligatorio.]

309

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

310

ndice
1 Introduccin 1.1 Propsito 1.2 mbito 1.3 Definiciones, acrnimos y abreviaciones. 1.4 Referencias 1.5 Resumen Ejecutivo 2 Requerimientos de interfaz 3 Diseo de las interfaces de usuario 4 Otros aspectos a tomar en cuenta 4.1 Seguridad 4.2 Reportes 4.3 Rendimiento 4.4 Integracin con otro Software 311 311 311 311 311 311 311 312 312 312 313 313 313

311

Prototipos de Interfaces de Usuario

12.Introduccin
Uno de los principales problemas en el desarrollo de software es el poco conocimiento que se tiene de cmo unir la lgica del negocio con la forma en que se presentara esta a los usuarios finales del software. Se trata de prototipos que permiten al usuario hacerse una idea ms o menos precisa de las interfaces que proveer el sistema y as, conseguir retroalimentacin de su parte respecto a los requisitos del sistema, adems de esto definir como disear las interfaces graficas de usuario y describir algunos problemas que se deben tener en cuenta en el desarrollo de interfaces pero que van ms all del alcance de este proyecto.

12.1.Propsito El propsito del presente documento es delinear las interfaces grficas de las aplicaciones a desarrollar, documentando las pantallas y los flujos de navegacin entre las mismas. 12.2.mbito [Proporciona una descripcin por escrito de a quin va dirigido este documento.] 12.3.Definiciones, acrnimos y abreviaciones. [Esta seccin provee las definiciones de los trminos, acrnimos y abreviaturas requeridas para interpretar apropiadamente el documento. Esta informacin puede ser proporcionada por referencia al Glosario del proyecto.]

12.4.Referencias [Esta seccin provee una lista completa de todos los documentos referenciados en cualquier parte del Documento. Identifica cada documento por el nmero y nombre de informe, (si aplica), fecha y organizacin que lo publica. Especifique las fuentes de donde las referencias se pueden obtener. Esta informacin puede ser proporcionada por referencia a un apndice o a otro documento.]

12.5.Resumen Ejecutivo [Esta seccin describe lo que el resto del Documento contiene y explica cmo el mismo estar organizado.]

13.Requerimientos de interfaz
[Los requerimientos de interfaz son todos aquellos elementos que debe proveer el sistema para permitir la interaccin entre el usuario y las funcionalidades que este tiene, con el fin de que en el proceso de diseo se tenga claridad de las interfaces que se deben crear y la relacin que debe existir entre ellas. Para la definicin de los requerimientos de interfaz se deben identificar los siguientes elementos:

312
Id: Identifica de manera nica una interfaz grfica Descripcin: Indica los elementos que debe tener la interfaz. Requerimientos asociados: Indican las funcionalidades asociadas a la interfaz grfica.

En este nivel, no se va definir de manera detallada la interfaz, solo se pretende tener una primera aproximacin a los elementos que deben ser tenidos en cuenta en el desarrollo de estas.]

14.Diseo de las interfaces de usuario

[Las pantallas deben permitir una forma de interaccin entre el usuario y todas las funcionalidades que ofrece el sistema, cada una de ellas debe al menos presentar una funcionalidad para que su creacin este justificada. Los elementos comunes entre pantallas que se podran definir son: Encabezado (Opcional) Men (Opcional) Zona de mensajes (error, xito) Zona de Contenido Hojas de estilo

Los elementos que se deben definir para cada pantalla son: Informacin a presentar o recolectar Validaciones Relacin entre datos Flujo de pantallas

Una prctica recomendable para verificar la completitud entre las pantallas definidas y las funcionalidades del sistema es llenar una matriz y marcar la interseccin entre una pantalla y una funcionalidad, indica que la pantalla implementa esa funcionalidad.

Tomando en cuenta los aspectos anteriormente descritos, desplegar un pantallazo de la interfaz que ha sido creada, describiendo por cada una los elementos a definir y presentar.]

15.Otros aspectos a tomar en cuenta

15.1.Seguridad [Aspectos a tomar en cuenta en cuanto a la seguridad de acceso y control del software]

313
15.2.Reportes [Aspectos a tomar en cuenta relacionados con los reportes que deben ser desplegados o generados desde el software. Presentar algunos prototipos]

15.3.Rendimiento [Aspectos relacionados con el rendimiento que debe tener el software.]

15.4.Integracin con otro Software [En algunos casos, el nuevo desarrollo de software debe interfazarse con otros sistemas, tomar en cuenta y detallar estos aspectos en este punto]

314

8.4.24 Plantilla Documento de Lecciones Aprendidas

<Nombre del proyecto> Lecciones Aprendidas Versin [1.0]

[Este plantilla tiene como finalidad ser la base para elaborar la lista de verificacin de Lecciones Aprendidas. Esta checklist se compone (genera y mantiene) por los aportes realizados por todos los integrantes del grupo en la reunin quincenal y por las observaciones realizadas por el Director de Proyecto en la reunin de evaluacin de Fase. Los textos que aparecen entre parntesis rectos son explicaciones de que debe contener cada seccin. Dichos textos se deben seleccionar y sustituir por el contenido que corresponda. Para actualizar la tabla de Contenido, haga clic con el botn derecho del ratn sobre cualquier lnea del contenido de la misma y seleccione Actualizar campos, en el cuadro que aparece seleccione Actualizar toda la tabla y haga clic en el botn Aceptar. LAS SECCIONES PARA LAS QUE NO TENGA DATOS NO DEBE BORRARLAS; EN DICHOS CASOS MRQUELAS CON N/A O SIN DATOS]

315

Historia de revisiones
Fecha [dd/mm/aaaa] Versin [x.x] Descripcin [detalles] Autor [nombre]

316

ndice
1. Introduccin ....................................................................................................... 317 2. Por Disciplinas ................................................................................................... 317 2.1. Requerimientos ............................................................................................ 317 2.2. Diseo.......................................................................................................... 317 2.3. Implementacin ........................................................................................... 317 2.4. Verificacin ................................................................................................. 318 2.5. Implantacin ................................................................................................ 318 2.6. Gestin de Proyecto ..................................................................................... 318 2.7. Gestin de Configuracin y Control de Cambios .......................................... 318 2.8. Gestin de Calidad ....................................................................................... 318 2.9. Comunicacin .............................................................................................. 318 2.10. Formacin y Entrenamiento ...................................................................... 318 3. Otras lecciones ................................................................................................... 318 3.1. [Observaciones del Director] ........................................................................ 318 3.2. [otra lecc. 2] ................................................................................................. 318

317 1. Introduccin
Leccin Aprendida: Experiencia positiva o negativa obtenida durante la realizacin de alguna actividad. Se trata del registro de mejores prcticas, problemas recurrentes o experiencias exitosas, durante la implantacin del proceso. [El propsito de este documento es proveer de una herramienta que contenga el conjunto de lecciones aprendidas durante el transcurso del proyecto, para ser utilizada al momento de realizar la Planificacin de la Iteracin, o cuando se crea oportuno] Como la leccin aprendida es un conocimiento explcito que se obtiene como resultado de un proceso de aprendizaje e involucra reflexionar sobre la experiencia, es importante tener una gua que facilite su construccin. La leccin aprendida se vuelve como un ejemplo ilustrativo, basado en la experiencia, que resulta aplicable a una situacin general ms que a una circunstancia especfica. La leccin debera contener los siguientes aspectos: Tema de la leccin Supuesto original, antes de que se tuviera esta experiencia La nueva interpretacin o supuesto 1 o 2 ejemplos que confirman el nuevo supuesto La forma en que se lleg a esta nueva percepcin Por qu es importante la leccin Para qu sirve la leccin Quin es el autor de la leccin Fecha de creacin de la leccin Tambin, es importante definir un vocabulario comn para las lecciones, dependiendo del contexto. Esto permitir eliminar hasta cierto punto la ambigedad del lenguaje, precisando mucho ms la terminologa tcnica del dominio. La siguiente lista de verificacin es actualizada (agregando, modificando y/o eliminando tems, cada 15 das en la reunin de equipo).

2. Por Disciplinas
2.1. Requerimientos [En las reuniones con el cliente considerar...] [En las reuniones con el cliente siempre llevar...] [Los nuevos requerimientos deben aprobarlos/evaluarlos...] [Usar siempre el patrn de diseo...] [...]

2.2. Diseo

2.3. Implementacin [El plazo lmite para reportar las pruebas unitarias es...] [No modificar los elementos de lnea base sin gestin de cambios...]

318
[Atencin al integrar modulo xxx con modulo yyy...] [...]

2.4. Verificacin [...] [...] [Verificar que el servidor de produccin cuenta con...] [...] [Estimar las actividades de ... con una holgura de ...] [...]

2.5. Implantacin

2.6. Gestin de Proyecto

2.7. Gestin de Configuracin y Control de Cambios [monitorear el correcto uso de los elementos de lnea base...] [...]

2.8. Gestin de Calidad [Chequear la coherencia entre los cronogramas de los planes de proyecto, de verificacin y calidad...] [...] [Por consultas tcnicas dirigirse a...] [Por consultas del entorno del negocio dirigirse a ...]

2.9. Comunicacin

2.10.Formacin y Entrenamiento [...] [...]

3. Otras lecciones
3.1. [Observaciones del Director] [Para futuras reuniones cambiar...] [...]

3.2. [otra leccin. 2] [...]

319

8.4.25 Plantilla Plan de Gestin de los Costos

<Proyecto> <Plan de Gestin de los Costos> Versin <1.1.0>

[Nota: Esta Plantilla tiene por finalidad servir de base para la confeccin documentos o informes distintos a los definidos. El texto entre parntesis cuadrados y desplegado en azul itlico (estilo = InfoBlue) tiene por finalidad guiar al autor y debe ser borrado antes de la publicacin del documento. El estilo Body Text se activa automticamente cuando se ingresan prrafos de texto definitivo. Ninguno de los Campos definidos es obligatorio.]

320

Historia de Revisiones
Fecha <aaaa-mm-dd> Versin 1.1.0 Descripcin Documento inicial Autor <Nombre>

321

ndice
Historia de Revisiones 1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones, acrnimos y abreviaciones. 1.4 Referencias 1.5 Resumen Ejecutivo 2. Tipos De Estimacin Del Proyecto 3. Costo de los Recursos 1.6 Esfuerzo de Trabajo por Fase 4. Control de Costos del Proyecto 1.7 Condiciones de Facturacin y Pago 1.8 Ingresos Totales por Fases 1.9 Gastos Estimados 1.10 Fechas Reales de Cobranza 320 322 322 322 322 322 322 322 323 323 324 324 325 325 325

322

Plan de Gestin de los Costos

1. Introduccin
[El PMBOK propone muchas tcnicas para la estimacin de costos tales como Estimacin por analoga, Estimacin par a mtrica, Estimacin ascendente, Anlisis de reserva, Utilizacin de software de estimacin de costos para la direccin de proyectos, etc. Dependiendo de las necesidades de la organizacin, se deben de usar la tcnica ms adecuada para la estimacin de los costos del proyecto.] 1.1.Propsito El propsito de este documento es llevar el plan de gestin de los costes en los que el proyecto va a incurrir. Para ello se identificarn los costes asociados a cada tarea en funcin de los recursos utilizados. [Detallar cualquier otro aspecto relacionado al Plan que se est definiendo] 1.2.Alcance [Proporciona una descripcin por escrito de a quin va dirigido este documento.]

1.3.Definiciones, acrnimos y abreviaciones. [Esta seccin provee las definiciones de los trminos, acrnimos y abreviaturas requeridas para interpretar apropiadamente el documento. Esta informacin puede ser proporcionada por referencia al Glosario del proyecto.] 1.4.Referencias [Esta seccin provee una lista completa de todos los documentos referenciados en cualquier parte del Documento. Identifica cada documento por el nmero y nombre de informe, (si aplica), fecha y organizacin que lo publica. Especifique las fuentes de donde las referencias se pueden obtener. Esta informacin puede ser proporcionada por referencia a un apndice o a otro documento.] 1.5.Resumen Ejecutivo [Esta seccin describe lo que el resto del Documento contiene y explica cmo el mismo estar organizado.]

2. Tipos De Estimacin Del Proyecto

[Los tipos de estimacin a utilizar en el proyecto con indicacin del modo de formulacin y los niveles de precisin de cada tipo.]

TIPO DE ESTIMACIN [Especificar los tipos de estimacin a usar en el proyecto, ej. orden de magnitud, presupuesto, definitiva]

MODO DE FORMULACIN [Especificar en detalle el modo de formulacin del estimado indicando el porqu, quin, cmo, y cundo]

NIVEL DE PRECISIN [Especificar el nivel de precisin del estimado, ej. -15% +25%]

323

3. Costo de los Recursos

3.1.Esfuerzo de Trabajo por Fase [Se establece el porcentaje de tiempo que ser requerido cada uno de los recursos humanos para cada una de las fases del proyecto] Se presenta un ejemplo:

Etapa

Duracin Semanas

Gerente Director 5% 5% 5% 5% 0.38

Project Director 20% 20% 20% 20% 1.50

Arquitecto Analista 100% 25% 50% 50% 3.00

Programador Pginas 50% 0% 100% 100% 3.25

Programador Fbrica 50% 0% 100% 50% 3.00

Probador

Concepcin Elaboracin Construccin Transicin Total TOTAL

0.50 4.00 2.50 0.50 5.00 7.50

0% 50% 50% 50% 3.50

Esfuerzo 10 30 50 10 100 5 20 65 10 100

Variacin 0.5 1.5 2.5 0.5 5 0.25 1 3.25 0.5 5

3.2.Esfuerzo de Trabajo por Fase [En esta rea se establece el esfuerzo porcentual de trabajo que estar asignado cada uno de los recursos del proyecto]

Recurso Recurso 1 Recurso 2 Recurso3

Horas Requeridas 1.00 1.00 1.00 1.00 1.00 1.00

Precio UF/Hora 1.00 1.00 1.00 1.00 1.00 1.00

Total UF 1.00 1.00 1.00 1.00 1.00 1.00 6.00 0.60 6.60

Subtotal Margen 10 % Total

6.00 0.6 6.60

324 4. Control de Costos del Proyecto

[Ya una vez se encuentra el proyecto en desarrollo, se deben controlar los costos estimados contra los costos reales que ha implicado] Se establece un ejemplo:

Fase CONCEPCION

Gerente Gerente

Project Director 4.00 0.00 4.00

Arquitecto Analista 20.00 0.00 20.00

Programador Programador Pginas 10.00 0.00 10.00 Fabrica 10.00 0.00 10.00

TOTAL

Horas Planificadas Horas Reales Superavit/Deficit

1.00 0.00 1.00

45.00 0.00 45.00

Fase ELABORACION

Gerente Director

Project Director 32.00 0.00 32.00

Arquitecto Analista 40.00 0.00 40.00

Programador Programador Pginas 0.00 0.00 0.00 Fabrica 0.00 0.00 0.00

TOTAL

Horas Planificadas Horas Reales Superavit/Deficit

8.00 0.00 8.00

80.00 0.00 80.00

Fase CONSTRUCCION

Gerente Director

Project Director 20.00 0.00 20.00

Arquitecto Analista 50.00 0.00 50.00

Programador Programador Pginas 100.00 0.00 100.00 Fabrica 100.00 0.00 100.00

TOTAL

Horas Planificadas Horas Reales Superavit/Deficit

5.00 0.00 5.00

275.00 0.00 275.00

Fase TRANSICION

Gerente Director

Project Director 4.00 0.00 4.00

Arquitecto Analista 10.00 0.00 10.00

Programador Programador Pginas 20.00 0.00 20.00 Fabrica 10.00 0.00 10.00

TOTAL

Horas Planificadas Horas Reales Superavit/Deficit

1.00 0.00 1.00

45.00 0.00 45.00

4.1.Condiciones de Facturacin y Pago

Condiciones de Facturacin y Pago Hito 1 Hito 1 faltante Hito 3 Hito n Total Supervit / Dficit del Proyecto Fase Porcentaje Facturacin Total a Cobrar por Hito 0 0 0 0 0 Fecha Estimada de Cobranza

0% 0% 0% 0% 0%

0.00

325
4.2.Ingresos Totales por Fases
Fase Total Ingreso Real 0.00 0.00 0.00 0.00 Total Egreso Real 0.00 0.00 0.00 0.00 Supervit/Dficit

Concepcin Elaboracin Construccin Transicin

0.00 0.00 0.00 0.00

4.3.Gastos Estimados
Proveedores/Fbricas Egreso Estimado Egreso Real

Concepcin Elaboracin Construccin Transicin 4.4.Fechas Reales de Cobranza

Fecha Real de Cobranza Cobrado Real Cobrado Acumulado

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00