EMPRESA SANTA CRUZ SOFTWARE DEVELOPER Ltda.

PLAN DE PROYECTO PARA ALCANZAR EL NIVEL 2 DEL CMMI

Control de la documentacin Control de la Configuracin. Histrico de Versiones. Histrico de Cambios. 1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones, Acrnimos y Abreviaturas 1. 4 Referencias 1.5 Objetivo 1.5 Documentos a generar 2. Proceso de Gestin de Requisitos 2.1 Introduccin 2.1.1 Propsito 2.1.2 alcance 2.2 Organizacin De Gestin De Requisitos 2.2.1 Roles 2.2.2 Responsabilidades 2.3 Proceso De Gestin de Requisitos 2.4 Herramientas 2.5 Documentos a generar 3. Proceso de Planificacin del Proyecto 3.1 Introduccin 3.1.1 Propsito 3.1.2 Alcance 3.2 Definicin de Polticas 3.2.1 Metodologa 3.2.2 Ciclo de vida 3.3 Organizacin De La Planificacin del Proyecto 3.2.1 Roles

5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 7 7 9 9 Error! Marcador no definido. 11 11

3.2.2 Responsabilidades 3.3 Proceso De La Planificacin del Proyecto 3.3.1 Definir estrategia de desarrollo 3.3.2 Elaborar el plan de proyecto 3.3.2 .1 Estimacin de esfuerzo 3.3.2.2 Resumen de actores y casos de uso 3.3.2.3 Planificacin de Recursos Humanos 3.3.2.4 Estructura de las actividades 3.3.2.5 Calendario de actividades 3.4 Herramientas 3.5 Documentos a generar 4. Proceso De Seguimiento y Control del Proyecto 4.1 Introduccin 4.1.1 Propsito 4.1.2 alcance 4.1 Organizacin De Seguimiento y Control del Proyecto 4.2.1 Roles 4.2.2 Responsabilidades 4.3 Proceso De Seguimiento y Control del Proyecto 4.4 Herramientas 4.5 Documentos a generar 5. Proceso de Gestin de Acuerdos con Proveedores 5.1 Introduccin 5.1.1 Propsito 5.1.2 alcance 5.1 Organizacin de Gestin de Acuerdos con Proveedores 5.2.1 Roles 5.2.2 Responsabilidades 5.3 Proceso de Gestin de Acuerdos con Proveedores 5.4 Herramientas 5.5 Documentos a generar 6. Proceso de Medicin y Anlisis

12 13 13 Error! Marcador no definido. 18 18 Error! Marcador no definido. 23 24 25 26 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 27 28

6.1 Introduccin 6.1.1 Propsito 6.1.2 alcance 6.1 Organizacin de Medicin y Anlisis 6.2.1 Roles 6.2.2 Responsabilidades 6.3 Proceso de Medicin y Anlisis 6.4 Herramientas 6.5 Documentos a generar 7. Proceso de Aseguramiento de la Calidad del Proceso y del Producto 8.1 Introduccin 8.1.1 Propsito 8.1.2 Alcance 8.1 Organizacin de Aseguramiento de la Calidad del Proceso y del Producto 8.2.1 Roles 8.2.2 Responsabilidades 8.3 Proceso de Aseguramiento de la Calidad del Proceso y del Producto 8.4 Herramientas 8.5 Documentos a generar 9. Proceso de Gestin de la Configuracin 9.1 Introduccin 9.1.1 Propsito 9.1.2 Alcance 9.1 Organizacin de Gestin de la Configuracin 9.2.1 Roles 9.2.2 Responsabilidades 9.3 Proceso de Gestin de la Configuracin 9.4 Herramientas 9.5 Documentos a generar 10. Formularios del PSP 0 10.1 Formulario de Registros de Tiempo 10.2 Formulario de Defectos

28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 28 29 29 29 29 29 29 29 29 29 29 29 29 29

ANEXOS

29

Control de la documentacin
Control de la Configuracin.
Ttulo: Referencia: Autores: Fecha: Ninguna Santa Cruz Software Developer 18/07/2013

Histrico de Versiones. Versin Fecha Estado

0.1 7/14/2013 Revisin

Responsable
Santa Cruz Software Developer

Nombre de Archivo
GestConfig.docx

Histrico de Cambios. Versin Fecha

0.1 7/14/2013

Cambios
Ninguna primera versin.

1. Introduccin
1.1 Propsito 1.2 Alcance 1.3 Definiciones, Acrnimos y Abreviaturas 1. 4 Referencias 1.5 Objetivo 1.5 Documentos a generar

2. Proceso de Gestin de Requisitos

2.1 Introduccin

2.1.1 Propsito 2.1.2 alcance

2.2 Organizacin De Gestin De Requisitos

2.2.1 Roles 2.2.2 Responsabilidades

2.3 Proceso De Gestin de Requisitos 2.4 Herramientas 2.5 Documentos a generar

3. Proceso de Planificacin del Proyecto

3.1 Introduccin

La planificacin del proyecto es una versin preliminar preparada para realizar implementacin de un proyecto cuyos procesos se rigen a normas de calidad basado en el modelo CMMI nivel 2.

Este proyecto es una propuesta basada en la metodologa AUP en la que se proceder a cumplir con las tres primeras fases de la metodologa.

El enfoque desarrollo propuesto constituye una configuracin de la metodologa AUP de acuerdo a las caractersticas del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos (entregables) que sern generados. 3.1.1 Propsito

El propsito de la planificacin del proyecto es proporcionar la informacin necesaria para controlar el proyecto. En l se describe el enfoque de desarrollo del software. Los usuarios del Plan de Desarrollo del Software son: El lder del proyecto lo utiliza para organizar la agenda y necesidades de recursos, y para realizar su seguimiento.
Los miembros del equipo de desarrollo lo usan para entender lo qu deben hacer, cundo deben hacerlo y qu otras actividades dependen de ello.

3.1.2 Alcance

La planificacin del proyecto describe el plan global usado para el desarrollo de proyectos de software. Durante el proceso de desarrollo se definen las caractersticas del producto a desarrollar, lo cual constituye la base para la planificacin de las fases o actividades que se deben cumplir hasta la implementacin del proyecto. En ese contexto definiremos los procesos que implican el xito del mismo:

Proceso de gestin de requisitos Esta rea de proceso tiene como propsito mantener bajo control los requerimientos que el producto a desarrollar deber satisfacer. Las prcticas incluidas aqu apuntan a que los requerimientos no solo estn claramente identificados, sino tambin que todos los involucrados en el proyecto (el cliente, el equipo de proyecto, etc.) estn de acuerdo en su significado. Adicionalmente, los requerimientos deben ser la entrada a las actividades de planificacin. Proceso de planificacin Esta rea de proceso tiene como propsito establecer y mantener el plan que ser empleado para ejecutar y monitorear el proyecto. El plan se desarrolla sobre la base de los requerimientos administrados por el rea de requerimientos. Dentro de esta rea de proceso se incluyen todas las actividades necesarias para determinar el

alcance del proyecto (funcionalidad a desarrollar, actividades incluidas y excluidas, etc.), estimar esfuerzo y costos, establecer el cronograma, identificar riesgos, y obtener el compromiso de todos los involucrados respecto al plan de proyecto. Proceso de seguimiento y control No tiene sentido formular planes para algo que no se tiene intenciones de gestionar. Esta rea de proceso es complementaria y una consecuencia de Planificacin del Proyecto su propsito es monitorear la ejecucin del proyecto empleando para ello el plan y gestionar acciones correctivas en el caso de detectarse desvos. Para poder cumplir con estos objetivos ser necesario implementar prcticas de seguimiento, tales como el reporte de horas trabajadas en el proyecto, el informe de avance peridico, revisiones en puntos particulares del proyecto (por ejemplo, al final de cada fase), etc. Proceso de gestin de acuerdos con proveedores Esta rea de proceso apunta a resolver otro de los problemas habituales en muchas Organizaciones: el de la tercerizacin. Si bien est originalmente pensada para todo lo relacionado con la adquisicin de productos que vayan a ser incorporados en la solucin a entregar al cliente, las prcticas incluidas aqu tambin sirven para todo aquello que sea necesario comprar pero que no ser finalmente entregado al cliente, como por ejemplo herramientas de desarrollo. Proceso de medicin y anlisis Una premisa presente en todos los movimientos de calidad es que lo que no puede medirse no puede mejorarse. Esta rea de proceso apunta, justamente, a desarrollar y mantener capacidades de medicin que permitan satisfacer las necesidades de informacin de la organizacin. Proceso de aseguramiento de la calidad Una vez establecidos procesos y estndares ser necesario evaluar su aplicacin. El objetivo de esta rea es justamente ese: proveer una evaluacin objetiva de los procesos y de los artefactos producidos. Es importante aclarar que las prcticas de esta rea implican: Evaluar los procesos ejecutados, los artefactos producidos y los servicios provistos versus los estndares y descripciones de proceso aplicables.

Identificar no conformidades, comunicarlas a los responsables, y asegurar su resolucin. Informar a los interesados (bsicamente, el equipo de proyecto y la gerencia) el resultado de las actividades de aseguramiento de la calidad.

Proceso de gestin de la configuracin Esta rea de proceso tiene como propsito mantener la integridad de todos los artefactos (entregables o no ) producidos por el proyecto, lo cual implica identificar los tems de configuracin, realizar sobre ellos cambios de manera controlada, generar y mantener lneas base, y proveer informacin precisa acera del estado del estado de la configuracin a todos los interesados.

3.2 Definicin de Polticas

Metodologa

Como metodologa para el desarrollo se utilizara AUP, sus ventajas nos permitirn alcanzar nuestros objetivos establecidos. Ventajas de AUP El personal sabe lo que est haciendo: no obliga a conocer detalles. Simplicidad: apuntes concisos. Agilidad: procesos simplificados del RUP Centrarse en actividades de alto valor: esenciales para el desarrollo. Herramientas independientes: a disposicin del usuario.

Polticas por proceso

Cada proceso debe tener: poltica de trabajo, descripcin del proceso, definicin de roles y actividades, adicionalmente esta informacin generada debe ser documentada y respaldada para su posterior seguimiento y control.

Control del plan del proceso

Deben realizarse reuniones programadas para llevar un control sobre el cumplimiento del plan del proceso, posteriormente debe documentarse el acta de reuniones realizadas y generar reportes del avance y cumplimiento de los objetivos establecidos en el plan.

Reglas de versionamiento Para el versionamiento de nuestro cdigo fuente usaremos la herramienta GIT. Los elementos del repositorio sern versionados de la siguiente manera: Al agregar el elemento en el repositorio se crea la rama principal del mismo y se genera la versin 1 del elemento contenida en esa rama. Con cada cambio (checkout y checkin) que se efecte sobre el elemento, se genera una nueva versin, incrementanto por unidades enteras (versiones 2, 3, 4, etc). Cuando se decide crear una versin ramificada de un elemento (operacin branch) se crea una nueva rama (secundaria) del mismo y se genera la versin 1 del elemento contenida en esa rama. Con cada cambio que se efecte sobre la ramificacin, se genera una nueva versin, incrementando por unidades enteras (al igual que en la rama principal). En cualquier momento se puede decidir fusionar la versin de la rama principal con la de la rama secundaria (operacin merge). Repositorio de cdigo fuente

Para tener un mejor control y registro del cdigo fuente usaremos assembla, esta herramienta nos proporcionara estas ventajas: 1) Solucin al problema de la concurrencia. Que varias personas quieran trabajar con el mismo fichero ya no es problema, el repositorio de codigo me ayudar a evitar errores y a tener un control total. 2) Trazabilidad completa. Voy a poder controlar todas las versiones que se han producido de forma automtica para cada una de las modificaciones de un fichero. Podr compararlas entre ellas, conocer la fecha de modificacin y su autor. Tengo control sobre el cdigo y los cambios que se producen sobre el mismo.

3) Voy a poder retornar a una versin anterior de la aplicacin sin problema, y a partir de dicha versin abrir una nueva rama que difiera de la que se tom en su momento. Soy capaz de lanzar una actualizacin de una versin ya cerrada aunque est a mitad de un desarrollo, y adems, hacer que para la nueva versin que estoy preparando dicho error tambin est solventado. El repositorio de cdigo me ayudar. 4) Seguridad. Control de acceso al cdigo, slo usuarios autenticados podrn realizar modificaciones, borrar, crear nuevos ficheros.

3.3 Planificacin de Recursos humanos 3.3.1 Organigrama del equipo de trabajo

3.3.1 Asignacin de Roles

Tipo de Rol

Roles asociados

Responsable

Lder de proyecto

Gestor de planificacin

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, coordina y mantiene los contactos necesarios con los usuarios coordinando su interaccin con el grupo de trabajo. Planifica y controla los recursos fsicos, humanos, monetarios e informticos que se le otorgan para

Joshep Lujan Pardo

Eliana Mancilla Vargas

lograr los resultados esperados de los distintos proyectos de desarrollo del rea. Gestor de calidad Planifica y acta en actividades de aseguramiento Heydy Barja de calidad de los procesos y en que los productos no se desven de los estndares. El gestor de calidad es independiente de los grupos de Administracin y Desarrollo. El gestor de calidad realiza reportes directamente al gestor de planificacin. Planifica y realiza las actividades de Patricia Juchani autoriza todos los cambios en las lneas base. La administracin del repositorio de lneas base es revisada y aprobada por el gestor de configuracin antes de tomar cualquier accin. Gestor de desarrollo Trabaja en desarrollo y mantencin de software, Betty Chaca lleva a cabo actividades como requerimientos, anlisis, diseo, codificacin, testing, y documentacin, e informes tcnicos.

Gestor de configuracin administracin de la configuracin. Controla y

3.3.2 Definicin de Responsabilidades

Para la definicin de responsabilidades se utilizar el formato RACI-V, que consiste en utilizar una de las 5 siglas (R, A, C, I o V) en funcin de: R: Responsible (Responsable). Encargado de ejecutar o de que se ejecute la tarea. A: Accountable (Aprobador). Responsable de aprobar y cerrar una tarea. C: Consult (Consultado). Persona a la que se debe consultar y que debe proporcionar informacin necesaria para la ejecucin de la tarea. I: Inform (Informado). Persona a la que se debe informar del resultado o de la completitud de la ejecucin de la tarea. V: Verify (Verificador). Persona que debe validar o verificar la ejecucin de una tarea (normalmente sus productos) generalmente como paso previo a la aprobacin formal por parte del aprobador.

Personas Actividades Verificar cumplimiento actividades Desarrollo del plan del proyecto Actividades Aseguramiento calidad Administracin de la configuracin. Requerimientos, anlisis, diseo, codificacin, testing, y documentacin, e informes tcnicos. de de de

Joshep Lujan R

Eliana Mancilla

Heydy Barja V

Patricia Juchani

Betty Chaca

3.4 Desarrollo del plan del proyecto 3.4.1 Definir metodologa de desarrollo

La metodologa que utilizaremos ser la metodologa gil AUP (Agile UnifiedProcess tambin conocido como Desarrollo Agil de Software) ya que se pretende trabajar con el cliente muy de cerca y dicha metodologa AUP se adapta a las necesidades de nuestro proyecto. Adems de tener versiones en etapas tempranas del desarrollo del proyecto. AUP es una versin simplificada del Proceso Unificado de Rational RUP, la cual describe en una forma simple, fcil de entender y brinda un enfoque de desarrollo de software utilizando tcnicas giles y conceptos del RUP. En comparacin de las disciplinas del RUP que son 9, el AUP tiene solamente 7: 1. Modelo: Entender el negocio de la organizacin, el problema de dominio que se abordan en el proyecto, y determinar una solucin viable para resolver el problema de dominio.

2. Implementacin: Transformar el modelo(s) en cdigo ejecutable y realizar un nivel bsico de pruebas individuales. 3. Prueba: Realizar una evaluacin objetiva para garantizar la calidad. Esto incluye la bsqueda de defectos, validar que el sistema funciona tal como est establecido, y verificar que se cumplan los requisitos. 4. Despliegue: Realizar un plan para la presentacin del sistema y ejecutarlo para hacer que el sistema se encuentre a disposicin de los usuarios finales. 5. Gestin de Configuracin: Realizar la gestin de acceso a artefactos de su proyecto. Esto incluye no slo el seguimiento de las versiones del artefacto en el tiempo, sino tambin el control y la gestin de cambios para ellos. 6. Gestin del Proyecto: Dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestin de los riesgos, la direccin de personas (la asignacin de tareas, el seguimiento de los progresos, etc.), y coordinar con las personas para garantizar que se entrega a tiempo y dentro del presupuesto. 7. Ambiente: Apoyar el resto de los esfuerzos por garantizar que el proceso adecuado, la orientacin (normas y directrices), y herramientas (hardware, software, etc.) estn disponibles para el equipo segn cuando ellos lo necesiten.

3.4.2 Ciclo de vida del proyecto El ciclo de vida del AUP:

Al igual que en RUP, en AUP se establecen cuatro fases que transcurren de manera consecutiva y que acaban con hitos claros alcanzados:

Inception(Concepcin): El objetivo de esta fase es obtener una comprensin comn cliente- equipo de desarrollo del alcance del nuevo sistema y definir una o varias arquitecturas candidatas para el mismo.

Elaboracin: El objetivo es que el equipo de desarrollo profundice en la comprensin de los requisitos del sistema y en validar la arquitectura.

Construccin: Durante la fase de construccin el sistema es desarrollado y probado al completo en el ambiente de desarrollo.

Transicin: el sistema se lleva a los entornos de preproduccin donde se somete a pruebas de validacin y aceptacin y finalmente se despliega en los sistemas de produccin.

Las disciplinas

se llevan a cabo de manera

sistemtica,

a la definicin

de las

actividades que realizan los miembros del equipo de desarrollo a fin de desarrollar, validar, y entregar el software de trabajo que responda a las necesidades de sus interlocutores. Las disciplinas son: 1. Modelo. El objetivo de esta disciplina es entender el negocio de la organizacin, el problema de dominio que se abordan en el proyecto, y determinar una solucin viable para resolver el problema de dominio. 2. Aplicacin. El objetivo de esta disciplina es transformar su modelo (s) en cdigo ejecutable y realizar un nivel bsico de las pruebas, en particular, la unidad de pruebas. 3. Prueba. El objetivo de esta disciplina consiste en realizar una evaluacin objetiva para garantizar la calidad. Esto incluye la bsqueda de defectos, validar que el sistema funciona tal como est establecido, y verificando que se cumplan los requisitos. 4. Despliegue. El objetivo de esta disciplina es la prestacin y ejecucin del sistema y que el mismo este a disposicin de los usuarios finales. 5. Gestin de configuracin. El objetivo de esta disciplina es la gestin de acceso a herramientas de su proyecto. Esto incluye no slo el seguimiento de las versiones con el tiempo, sino tambin el control y gestin del cambio para ellos. 6. Gestin de proyectos. El objetivo de esta disciplina es dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestin de riesgos, la direccin de personas (la asignacin de tareas, el seguimiento de los progresos, etc), coordinacin con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto. 7. Entorno. El objetivo de esta disciplina es apoyar el resto de los esfuerzos por

garantizar que el proceso sea el adecuado, la orientacin (normas y directrices), y herramientas (hardware, software, etc) estn disponibles para el equipo segn sea necesario.

Los equipos de AUP suelen ofrecer versiones de desarrollo al final de cada iteracin en pre- produccin rea (s). Una versin de desarrollo de una aplicacin es algo que podran ser liberados en la produccin si se ponen a travs de su pre-produccin de garanta de calidad (QA), las pruebas y los procesos de despliegue.

Principios de AUP

La AUP es gil, porque est basada en los siguientes principios: El personal sabe lo que est haciendo

La gente no va a leer detallado el proceso de documentacin, pero algunos quieren una orientacin de alto nivel y / o formacin de vez en cuando. La AUP producto proporciona enlaces a muchos de los detalles, si usted est interesado, pero no obliga a aquellos que no lo deseen. Manual de Funciones de los Roles o del Personal

Simplicidad

Todo se describe concisamente utilizando un puado de pginas, no miles de ellos.

Agilidad

gil ARRIBA El ajuste a los valores y principios de la Alianza gil.

Centrarse en actividades de alto valor

La atencin se centra en las actividades que se ve que son esenciales para el de desarrollo, no todas las actividades que suceden forman parte del proyecto.

Herramienta de la independencia

Usted puede usar cualquier conjunto de herramientas que usted desea con el gil UP. Lo aconsejable es utilizar las herramientas que son las ms adecuadas para el trabajo, que a menudo son las herramientas simples o incluso herramientas de cdigo abierto.

Adaptacin de este producto para satisfacer sus propias necesidades

El AUP producto es de fcil acomodo comn a travs de cualquier herramienta de edicin de HTML. No se necesita comprar una herramienta especial, o tomar un curso, para adaptar la AUP.

3.4.3 Estimacin de esfuerzo Para la estimacin del esfuerzo se aplicar la tcnica de Puntos de caso de uso (UCP, Use Case Points) [Peralta, M.L. 2004][Ribu, K. 2001]. La tcnica toma como entrada los casos de uso identificados para el sistema bajo anlisis y produce un estimado en horas hombre del esfuerzo necesario para el desarrollo del mismo. A continuacin se detallan los pasos efectuados para la aplicacin de la tcnica. Los conceptos sern expuestos a medida que se relata su aplicacin. 3.4.3.1 Resumen de actores y casos de uso

Como punto de partida para la aplicacin de la tcnica es necesario haber efectuado la identificacin de actores y casos de uso del sistema. Los actores y casos de uso identificados se detallaron en el apartado 2 (Proceso gestin de requisitos). Tomando como base la informacin contenida en dicho apartado, se contina con la aplicacin de la tcnica. 3.4.3.2 Clculo de los Puntos de caso de uso sin ajustar

El paso siguiente en la tcnica consiste en determinar la complejidad asignada a cada uno de los actores y casos de uso identificados.

Para los actores se sigue el criterio definido en la siguiente tabla:

Tipo de actor Descripcin Peso 1

Simple

Medio

complejo

Otro sistema que interacta con el sistema a desarrollar mediante una interfaz de programacin (API, Application Programming Interface) Otro sistema que interacta con el sistema a desarrollar mediante un protocolo o una interfaz basada en texto. Una persona que interacta con el sistema mediante una interfaz grfica.
Criterio para la asignacin de complejidad a los actores.

Para los casos de uso, el criterio a seguir es el que se muestra en la tabla:

Tipo de caso de uso
Simple

Descripcin
El Caso de Uso contiene de 1 a 3 transacciones (*) El Caso de Uso contiene de 4 a 7 transacciones (*) El Caso de Uso contiene ms de 8 transacciones (*)

Medio
Complejo

Peso 5 10 15

Criterio para la asignacin de complejidad a los Casos de uso.

Una vez que se han asignado los pesos a los actores y a los casos de uso de acuerdo a su dificultad, se calculan los Puntos de caso de uso sin ajustar de acuerdo a la siguiente formula. UUCP = UAW + UUCW donde: UUCP: Puntos de Casos de Uso sin ajustar UAW: Sumatoria de los factores de peso de los actores UUCW: Sumatoria de los factores de peso de los casos de uso

Ahora mostramos los valores asignados para los actores y casos de uso del sistema.
Elemento
Registrar marca

complejidad
Complejo Complejo

Peso 3 3 6

Justificacin
Se trata de una persona interactuando con el sistema a travs de una interfaz grfica Se trata de una persona interactuando con el sistema a travs de una interfaz grfica

Registrar producto

Puntos de caso de uso sin ajustar (UUCP)

Valores asignados a los actores y casos de uso del sistema, y valor resultante. Referencia

Continuando con la aplicacin de la tcnica, los puntos de caso de uso calculados en el apartado anterior deben ajustarse de acuerdo a un conjunto de parmetros que miden la complejidad tcnica y los factores de ambiente del proyecto. El coeficiente de incidencia de la complejidad tcnica se obtiene asignando valores a los criterios que se muestran en la siguiente tabla. Los valores a asignar van desde 0 hasta 5 de acuerdo a la incidencia del criterio en el proyecto.
Factor
TCF01 TCF02

Descripcin

Justificacin

Peso 2 1

Valor 0 1

TCF03 TCF04 TCF05 TCF06 TCF07 TCF08 TCF09 TCF010

Sistema distribudo Objetivos de performance o tiempo de respuesta Eficiencia del usuario final Procesamiento interno complejo El cdigo debe ser reutilizable Facilidad de instalacin Facilidad de uso Portabilidad Facilidad de cambio Concurrencia

El sistema no es distribuido Los objetivos de performance son fciles de lograr Los requerimientos de eficiencia son altos El procesamiento interno es simple Slo dentro del sistema, por buenas prcticas de programacin. Debe ser muy fcil de instalar Debe ser muy fcil de utilizar El sistema debe ser portable a varios sistemas operativos. Debe ser relativamente fcil de modificar. No hay requerimientos de concurrencia. El sistema es monousuario. No hacen falta caractersticas especiales de seguridad. No debe proveer acceso a terceros. Slo al usuario. Debe tener ayudas online y guas para el usuario.

1 1 1 0.5 0.5 2 1 1

5 1 3 5 5 5 3 0

TCF011 TCF012 TCF013

Incluye objetivos especiales de seguridad Provee acceso directo a terceras partes Se requieren facilidades especiales de entrenamiento a usuarios

1 1 1

1 0 5

Coeficiente de incidencia de la complejidad tcnica (TCF)

Criterios para el coeficiente de incidencia de la complejidad tcnica.

0.94

Finalmente, el coeficiente de incidencia para la complejidad tcnica se calcula de acuerdo a la siguiente frmula: TCF = 0.6 + 0.01 x (Peso i x Valor asignado i) TCF = 0.6 + 0.01 x (34) TCF = 0.94

El coeficiente de incidencia de los factores de ambiente se obtiene asignando valores a los criterios que se muestran en la siguiente tabla. Los valores a asignar van desde 0 hasta 5 de acuerdo a la incidencia del criterio en el proyecto.
Factor
ECF01

Descripcin

Justificacin

Peso 1.5

Valor 3

ECF02

ECF03 ECF04 ECF05 ECF06 ECF07 ECF08

Familiaridad con el modelo de Se conocen los conceptos de proyecto utilizado Mtrica 3 pero es la primera vez que se aplica. Experiencia en la aplicacin Se tiene gran experiencia en Java, aunque no en aplicaciones standalone. Experiencia en orientacin a Se tiene gran experiencia en objetos orientacin a objetos. Capacidad del analista lder El analista tiene mucha experiencia en casos de uso. Motivacin Se tiene una alta motivacin para completar el proyecto. Estabilidad de los Los requerimientos son altamente requerimientos estables. Personal part-time Todos los involucrados en el proyecto son part-time. Dificultad del lenguaje de El lenguaje a utilizar es de programacin dificultad media.

0.5

1 0.5 1 2 -1 -1

4 4 5 4 5 3

Coeficiente de incidencia del factor de ambiente (ECF)

Criterios para el coeficiente de incidencia de los factores de ambiente.

0.905

ECF = 1.4 - 0.03 x (Peso i x Valor asignado i) ECF = 1.4 - 0.03 x (16.5) ECF = 0.905

Finalmente, los Puntos de caso de uso ajustados se obtienen mediante la frmula: UCP = UUCP x TCF x ECF Donde: UCP: Puntos de Casos de Uso ajustados UUCP: Puntos de Casos de Uso sin ajustar TCF: Coeficiente de incidencia de la complejidad tcnica ECF: Coeficiente de incidencia del factor ambiente Puntos de caso de uso ajustados (UCP) 35 UCP = UUCP x TCF x ECF UCP= 6*0.94*0.905 UCP= 5.104 3.4.4 Calculo del esfuerzo El esfuerzo se calcula multiplicando la cantidad de puntos de caso de uso ajustados por un factor de conversin que lo convierte en horas/hombre. Inicialmente se sugiri para este coeficiente un valor de 20 horas/hombre por punto de caso de uso, pero con posterioridad surgieron al menos tres variantes [Ribu, K. 2001]:

La primera de ellas sugiere la siguiente aproximacin: o Se contabilizan entre los factores ECF01 a ECF06 cuntos estn por debajo del valor medio (3). o Se contabilizan entre los factores ECF07 a ECF08 cuntos estn por encima del valor medio (3). o Si el total es 2 o menos, se utiliza el factor de conversin 20 horas-hombre/ punto de caso de uso, es decir, un punto de caso de uso toma 20 horashombre. o Si el total es 3 o 4, se utiliza el factor de conversin 28 horas-hombre/ punto de caso de uso, es decir, un punto de caso de uso toma 28 horas hombre. o Si el total es mayor o igual que 5, se recomienda efectuar cambios en el proyecto, ya que se considera que el riesgo de fracaso del mismo es demasiado alto.

La segunda se basa en estadsticas de la industria del software y plantea que el valor del coeficiente vara entre 15 y 30 horas-hombre/punto de caso de uso, de acuerdo a las caractersticas del proyecto. La tercera sugiere un valor ms conservador de 36 horas-hombre/punto de caso de uso.

Para nuestro caso se tiene que entre ECF01 y ECF06 hay un solo valor por debajo de 3 (ECF02), y entre ECF07 y ECF08 hay un solo valor por encima de 3 (ECF07). Con estos valores y adoptando la primera de las aproximaciones mencionadas, el factor de conversin resulta de 20 horas-hombre/punto de caso de uso. Esfuerzo estimado=20 horas- hombre * UCP Esfuerzo estimado=20 horas- hombre * 5.104 Esfuerzo estimado= 102.08 horas-hombre 3.4.5 Estructura de las actividades A continuacin se muestran las actividades y tareas de Mtrica v3 [Mtrica V3, 2000] que se llevarn a cabo durante el desarrollo del proyecto. Para cada proceso o interfaz de la metodologa, se construye una tabla donde se muestran las actividades y tareas a llevar a cabo, y los productos de salida de cada una de ellas.
Proceso: Gestin de requerimientos Tareas

Actividades

Productos

Proceso: Gestin de planificacion Actividades Tareas Productos Establecimiento del alcance Estudio de la solicitud Descripcin general del del proyecto. sistema Catalogo de objetivos de la planificacin del proyecto. Identificacin del alcance del Descripcin general del sistema sistema. Catalogo de requisitos Catalogo de usuarios Especificacin del alcance del Catalogo de objeticos de la sistema planificacin del proyecto Definicin de los requisitos del Identificacin de requisitos Identificacin de requisitos proyecto. Catalogo de requisitos

Anlisis del proyecto Diseo del proyecto Construccin implantacin Proceso: Gestin de Aseguramiento de la calidad Actividades Tareas

Productos

3.4.6 Calendario de actividades

Teniendo en cuenta la estimacin del esfuerzo llevada a cabo, la estrategia de desarrollo seleccionado, y las actividades, tareas y productos de la metodologa indicados en el apartado anterior, se elabor un plan en el cual se detallan las iteraciones, procesos y actividades, remarcando los hitos fundamentales del proyecto. A continuacin se muestra el plan desde lo ms general a lo ms especfico, de manera de facilitar su comprensin. Diagramas de gantt 3.5 Aseguramiento de la calidad 3.5.1 Propiedades de calidad Para evaluar la calidad del sistema se tendrn en cuenta las siguientes propiedades:

Correspondencia del sistema con los requisitos planteados. Documentacin de los distintos modelos del sistema (anlisis, diseo, implementacin y testing). Eficiencia. Fiabilidad. Facilidad de uso. Facilidad de mantenimiento.

3.5.2 Plan de aseguramiento de la calidad

3.5.2.1 Propsito y alcance

Evaluar objetivamente la ejecucin de los procesos, los elementos de trabajo y servicios contra las descripciones de procesos, estndares y procedimientos. Identificar y documentar los elementos no conformes. Proporcionar informacin a las personas que estn usando los procesos y a los gestores, de los resultados de las actividades del aseguramiento de la calidad. Asegurar de que los elementos no conformes son arreglados.

Dichas actividades se realizarn a lo largo de todo el proyecto, retroalimentando constantemente el desarrollo de manera que las desviaciones sobre la calidad planificada sean corregidos apenas se detectan. Las actividades contempladas por el plan consisten fundamentalmente de revisiones a efectuar durante el desarrollo del proyecto. Los resultados de dichas revisiones se documentan en el apartado 7 (Proceso de Aseguramiento de la Calidad del Proceso y del Producto)
3.5.2.2 Plan de actividades

El plan de las actividades que se llevarn a cabo para el Aseguramiento de la calidad, se encuentra detallado en las secciones 8.1 (Organizacin de Aseguramiento den Calidad del Proceso y del Producto), 8.3 (Proceso de Aseguramiento de la Calidad del Proceso y del Producto), 8.4 (Herramientas) Por tal motivo, no se repite la planificacion en este apartado.
3.6 Herramientas

3.7 Compromiso con el plan

3.7.1 Revisar los planes que afectan al proyecto Los planes desarrollados en otras reas de proceso tpicamente contienen informacin similar a la que se pide en el plan general del proyecto. Estos planes pueden proporcionar ms orientacin detallada y debe ser compatible y apoyar el plan general del proyecto para indicar quin tiene la autoridad, responsabilidad, rendicin de cuentas y el control. Todos los planes que afectan al proyecto deben ser revisados para asegurarse de que contengan un entendimiento comn sobre el alcance, objetivos, roles y relaciones que son necesarias para que el proyecto tenga xito. Para esta tarea debemos llevar un registro de las revisiones de los planes que afectan al proyecto.

3.7.2 Ajustar el plan de proyecto para reflejar recursos estimados vs. Disponibles Para que nuestro proyecto sea viable, debemos obtener un compromiso con los involucrados relevantes y reconciliar las diferencias entre las estimaciones y los recursos disponibles. La reconciliacin es tpicamente realizada mediante la modificacin o aplazamiento de los requisitos, la negociacin de ms recursos, encontrar formas de aumentar la productividad, la subcontratacin, adaptacin de la combinacin de habilidades del personal, o la revisin de todos los planes que afectan al proyecto o sus cronogramas. Tpicos productos de trabajo 1. Los mtodos de revisin y los correspondientes parmetros de estimacin (por ejemplo, las mejores herramientas, el uso de los componentes de fuera de la plataforma) 2. Los presupuestos renegociados 3. Los cronogramas revisados 4. La lista revisada de las necesidades 5. Los acuerdos de renegociaciones de los involucrados relevantes

3.7.3 Obtener compromisos respecto al plan

Lograr el compromiso implica la interaccin entre todos los involucrados relevantes, tanto internos como externos al proyecto. El individuo o grupo de hacer un compromiso debe tener confianza en que el trabajo puede realizarse dentro de los costos, plazos, y las limitaciones de rendimiento.
Para ellos llevaremos a cabo las siguientes tareas:

1. Las solicitudes documentadas de los compromisos

2. Compromisos documentados
3.8 Documentos a generar

Organigrama del equipo de trabajo Tabla de rol y responsable Matriz de asignacin de responsabilidades Polticas del proceso Calendario de actividades

4. Proceso De Seguimiento y Control del Proyecto

4.1 Introduccin

4.1.1 Propsito 4.1.2 alcance

4.1 Organizacin De Seguimiento y Control del Proyecto

4.2.1 Roles 4.2.2 Responsabilidades

4.3 Proceso De Seguimiento y Control del Proyecto 4.4 Herramientas 4.5 Documentos a generar

5. Proceso de Gestin de Acuerdos con Proveedores

5.1 Introduccin

5.1.1 Propsito 5.1.2 alcance

5.1 Organizacin de Gestin de Acuerdos con Proveedores

5.2.1 Roles 5.2.2 Responsabilidades

5.3 Proceso de Gestin de Acuerdos con Proveedores 5.4 Herramientas 5.5 Documentos a generar

6. Proceso de Medicin y Anlisis

6.1 Introduccin

6.1.1 Propsito 6.1.2 alcance

6.1 Organizacin de Medicin y Anlisis

6.2.1 Roles 6.2.2 Responsabilidades

6.3 Proceso de Medicin y Anlisis 6.4 Herramientas 6.5 Documentos a generar

7. Proceso de Aseguramiento de la Calidad del Proceso y del Producto

8.1 Introduccin

8.1.1 Propsito 8.1.2 Alcance

8.1 Organizacin de Aseguramiento de la Calidad del Proceso y del Producto

8.2.1 Roles 8.2.2 Responsabilidades

8.3 Proceso de Aseguramiento de la Calidad del Proceso y del Producto 8.4 Herramientas 8.5 Documentos a generar

9. Proceso de Gestin de la Configuracin

9.1 Introduccin

9.1.1 Propsito 9.1.2 Alcance

9.1 Organizacin de Gestin de la Configuracin

9.2.1 Roles 9.2.2 Responsabilidades

9.3 Proceso de Gestin de la Configuracin 9.4 Herramientas 9.5 Documentos a generar

10. Formularios del PSP 0

10.1 Formulario de Registros de Tiempo 10.2 Formulario de Defectos

ANEXOS