Está en la página 1de 8

1.

Plan de calidad
1.1.Introduccin
El plan de calidad que se define en este documento, est orientado a enmarcar el proceso de desarrollo de software en un mbito de buenas prcticas, que sirvan de gua para controlar el estado del proyecto y apoye la toma de decisiones en un momento dado. 1.1.1. Propsito

Establecer un marco conceptual de trabajo que defina los lineamientos necesarios que debe seguir el equipo para mantener un trabajo organizado y orientado a la calidad de los procesos. Adems de establecer un punto de referencia que conduzca el equipo al aseguramiento de la calidad en el proceso de desarrollo de software, el plan de calidad propuesto pretende: Mantener registro y control sobre las actividades desarrolladas, de modo que faciliten la toma de decisiones en beneficio del proyecto.

Recopilar informacin valiosa que sirva de referencia durante la especificacin de futuros proyectos. 1.1.2. Definiciones, Acrnimos y Abreviaciones

Calidad:

1. Conjunto de propiedades inherentes a un producto o servicio que le confieren capacidad para satisfacer necesidades implcitas o explcitas.

2. La calidad es diferenciarse cualitativa y cuantitativamente respecto de algn atributo requerido.

3. Es el resultado de una actitud enrgica y comprometida de esfuerzos sinceros de una ejecucin talentosa.

TSP: Team Software Process

Project Charter: Acta de constitucin del proyecto. WBS: Work Breakdown Structure 1.1.3. Referencias

http://es.wikipedia.org/wiki/Calidad#Definiciones_de_la_calidad IEEE Standard 730.1-1989 1.1.4. Gestin

Teniendo en cuenta que el proceso de desarrollo de software est fundamentado en la metodologa propuesta por TSP, la estructura para la administracin y organizacin del proyecto est definida de acuerdo a los roles, tareas, artefactos de inspeccin y el plan de calidad propuestos por TSP. El equipo conformado para la ejecucin del proyecto estar compuesto por 4 estudiantes de la especializacin en construccin de software de la Universidad de los Andes, entre los cuales se har la distribucin de los respectivos roles. 1.1.5. Estndares, Prcticas, Convenciones y Mtricas 1.1.5.1. Estndares y Convenciones

Documentacin: Cada artefacto entregable debe contemplar como mnimo los siguientes elementos:

Encabezado: Nombre del artefacto, Logo empresa, Ao Pie de pgina: Nombre del artefacto Identificacin del documento (proyecto, artefacto, versin) Tabla de Contenido (Si aplica) Tabla de Figuras (Si aplica) Tabla de Cuadros (Si aplica) Tabla de control de revisiones (fecha <dd/mm/yyyy>, versin, descripcin y autor)

Formato de texto: Fuente Calibri Encabezado y pie de pgina: tamao 11 Portada: tamao de la letra 18 excepto la versin (tamao 14) Tablas de contenido, figuras y cuadros tamao 10 12 Contenido: tamao de la letra 12 y justificado

Interlineado sencillo Encabezado de tablas: texto centrado, tamao 12 y negrilla Cuerpo de tablas: texto justificado y tamao 10 Ttulos de nivel 1 y 2 en negrilla Ttulos de nivel 3 en cursiva Ttulos de nivel 4 y posterior estilo normal Ttulo de las figuras y cuadros en tamao 10

Deben ser documentos concretos, no muy extensos y a la medida que se requiera con ilustraciones o cuadros que consoliden la informacin. Codificacin: Se utilizar el estndar propuesto por Sun Microsystem.

http://java.sun.com/docs/codeconv/ 1.1.5.2. Mtricas

Las mtricas de calidad utilizadas en el proyecto estn basadas en el plan summary propuesto por TSPi, estas mtricas son:

Defectos por Pgina: Muestra el nmero de defectos removidos de cada pgina de documento elaborado en el proyecto.

Defectos por KLOC: Defectos encontrados por cada 1000 lneas de cdigo desarrolladas.

A/FR: Es una proporcin que se obtiene al dividir la cantidad de tiempo invertido en las revisiones e inspecciones entre el tiempo invertido en las pruebas del producto. Lo ideal sera que el tiempo de revisiones e inspecciones fuera el doble del tiempo de las pruebas.

Proporcin de Defectos: Es una proporcin que se obtiene al dividir la cantidad de defectos encontrados en las revisiones de diseo del producto entre los defectos encontrados en las pruebas unitarias.

Porcentaje de Revisiones: Indica el porcentaje de pginas, para el caso de documentos, o LOC para el caso de cdigo, revisadas por hora.

Porcentaje de Inspecciones: Indica el porcentaje de pginas, para el caso de documentos, o LOC para el caso de cdigo, inspeccionadas por hora.

Porcentaje de defectos inyectados: Indica el porcentaje de defectos inyectados por hora en los diferentes artefactos elaborados.

Porcentaje de defectos removidos: Indica el porcentaje de defectos removidos por hora de los diferentes artefactos revisados e inspeccionados.

Tiempo por fases: Compara el tiempo planeado contra el tiempo real en la elaboracin de los artefactos definidos para las fases del proyecto. 1.1.6. Inspecciones

El propsito de esta seccin es definir como parte de las estrategias trazadas por el equipo de trabajo un modelo practico para soportar el proceso de inspeccin de artefactos. A continuacin se listan los lineamientos o reglas bsicas de trabajo para atender estas actividades de la mejor forma: Definir un formato estndar para el reporte de los defectos encontrados. Definir la lista de chequeo con los tems a evaluar para cada artefacto construido. Cada integrante del equipo responsable de elaborar un artefacto, debe hacer la revisin del mismo y elaborar el reporte de defectos respectivo (lista de chequeo y anlisis de defectos). Las inspecciones se distribuirn previa evaluacin del equipo y bajo la coordinacin del lder de grupo. Cada inspector ser responsable de hacer el reporte de inspeccin (lista de chequeo y anlisis de defectos) y estar en la capacidad de hacer las correcciones necesarias sobre el artefacto cuando estas son de forma; en caso de presentarse defectos de contenido, stos debern ser discutidos con el autor del artefacto y si es necesario hacer correcciones, el creador estar en la obligacin de hacerlos lo ms pronto posible sin afectar el plan de la semana, y notificar el resultado al moderador para llevar a cabo la actualizacin de los reportes de inspeccin. Todo el proceso debe estar supervisado por el moderador, persona responsable de elaborar semanalmente el reporte consolidado del proceso y discutir con el grupo durante las reuniones de seguimiento los factores positivos y negativos con el objetivo de madurar y fortalecer la mecnica del proceso. Cada artefacto debe contar con una seccin de control de versiones, donde se registre la fecha, responsable y una breve descripcin del cambio. Cuando los cambios se hagan como resultado de una revisin o inspeccin se debe colocar el identificador del reporte.

1.1.7. TSPi QUALITY PLAN: FORM SUMQ

FORM SQMQ Summary Rates LOC/hour % Reuse (% of total LOC) % New Reuse (% of N&C LOC) Percent Defect-free (PDF) In compile In unit test In build and integration In system test Defect/page Requirements Inspection HDL Inspection Defects/KLOC DLD review DLD inspection Code Review Compile Code inspection Unit test Build and integration System test Total development Defect Ratios Code review/Compile DLD review / Unit test Development time ratios(%) Requirements inspection/Requirements HLD inspection/HLD DLD/code DLD review/DLD Code review/code A/FR Review rates DLD lines/hour Code LOC/hour Inspection rates Requirements pages/hour HLD pages/hour

Plan 15 0 0 0 0 0 0

1 0 5 2 2 1 2 3 10 0 0

15 0.5 0.5

FORM SQMQ DLD lines/hour Code LOC/hour Defect-injection Rates (Defects/Hr.) Requirements HLD DLD Code Compile Unit test Build and integration System test Defect-removal Rates (Defects/Hr.) Requirements inspection HLD inspection DLD review DLD inspection Code review Compile Code inspection Unit test Build and integration System test Phase Yields Requirements inspection HLD inspection DLD review Test development DLD inspection Code review Compile Code inspection Unit test Build and integration System test Process Yields % before compile % before unit test % before build and integration & before system test % before system delivery 50 15 2 0 0 3 0 1 2 2 2 0 0 5 3 2 3 1 2 2 1 0 0 1 3 2 3 1 2 2 0 2 2 2 2

1.1.8. Anlisis de Defectos

Los defectos encontrados tanto en las revisiones como en las inspecciones deben ser registrados por el responsable de la actividad en los formatos establecidos por TSP para tal fin. Dentro de los formatos de inspeccin se encuentran:

SUMS: Size Summary SUMT: Development time summary SUMQ: Quality Plan SUMP: Plan Summary SUMDI: Defects Injected Summary SUMDR: Defects Removed Summary LOGD INS: Inspecciones

1.1.9. Herramientas, Tcnicas y Metodologas

A continuacin se realiza una descripcin de la metodologa y las herramientas adoptadas para la ejecucin del ciclo I del proyecto.

TSP: Team Sofware Process es un proceso iterativo para el desarrollo de software que define roles, actividades, fases y ciclos. Presenta conceptos para la conformacin eficiente de equipos de trabajo. Las fases definidas para el desarrollo del software son:

Lanzamiento Estrategia Planeacin Requerimientos Diseo Implementacin Pruebas Postmortem

Una de las estrategias de TSP para conformar equipos de trabajo, es dividir las responsabilidades entre todos los integrantes del grupo. Por eso define los siguientes roles:

Lider del Grupo Lider de Calidad LIder de Soporte Lider de Desarrollo Lider de Planeacin

Cada rol es responsable de tareas especficas del proyecto pero todos son responsables de la implementacin del producto. TSPiPlanSummary: Formato para llevar el seguimiento del proyecto con respecto a mtricas de calidad.

Metrics: Herramienta para obtener mtricas a nivel de cdigo. Ser utilizada para apoyar nuestros indicadores de gestin.