Professional Documents
Culture Documents
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
Facultad de Ingeniería
Curso:
Calidad de Software
Profesor:
ARIAS CAYCHO,JESUS
Tarea 1
Alumno:
Jaime Ramirez
Lima – Perú
Julio-2018
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
Proyecto:
Versión: 01
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
Historial de Revisiones
VERSIÓN FECHA AUTOR DESCRIPCIÓN
1.0.1 14/11/2018 Antonio Borda
1.0.2 15/11/2018 Juan Carlos Silva
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
CONTENIDO
1. Introducción
2. Objetivos
2.1 Objetivos de SQA
2.2 El rol de SQA
2.3 Responsabilidades de SQA
2.4 Funciones de SQA
3. Documentos relacionados
4. Destinatarios
5. Administración
5.1 Organización
5.2 Responsabilidades
7. Tareas de SQA
8. Apéndices
8.1 Glosario
8.2 Historia de Cambios
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
1. Introducción:
2. Objetivo:
Los principales objetivos del Aseguramiento de la Calidad del Software son los
siguientes:
Las personas responsables del proyecto de software (desarrollo y cliente) son las únicas
que pueden ser responsables por la calidad. El rol de SQA es monitorear la manera en
que estos grupos ejecutan sus responsabilidades. Por lo tanto, existen los siguientes
peligros latentes:
• Es un error asumir que el personal de SQA puede por sí solo hacer algo por la
calidad del proyecto.
• A menos que la dirección de línea requiera que SQA trate de resolver sus no-
conformidades con la dirección del proyecto antes de elevarlas, SQA y
desarrollo no trabajarán efectivamente.
Todo lo que puede hacer SQA es alertar a la dirección sobre las desviaciones a los
estándares y procedimientos establecidos.
• Participar en todas las revisiones a fin de cada fase del proyecto y registrar
formalmente si los estándares y procedimientos no se alcanzaron
satisfactoriamente.
Las principales funciones del rol de SQA, a través de todo el ciclo de vida, son las
siguientes:
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
• Evaluación del proceso de diseño: se definen los medios para asegurar que el diseño
sigue las metodologías planificadas, que implementa los requerimientos y que la
calidad del diseño propiamente dicha es revisada independientemente.
• Evaluación del uso del proceso de control y gerenciamiento del proyecto: asegurando
que los procesos de gerenciamiento están funcionando, SQA ayuda a garantizar que
todo el grupo de proyecto está orientado a producir resultados de calidad.
• Adaptación de los procedimientos de SQA: El plan de SQA debe ser adaptado a las
necesidades específicas del proyecto.
3. Documentos Relacionados
4. Destinatarios
5. Administración
Esta sección del Plan de SQA describe aspectos relacionados con el management del
equipo de SQA del proyecto. Se describen la organización del equipo de SQA, los roles,
responsabilidades y tareas, el cronograma de actividades y los riesgos que pueden
amenazar los objetivos de este plan.
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
5.1 Organización
5.2 Responsabilidades
En la siguiente tabla se define cada una de las responsabilidades que tiene cada
persona, con el fin de asegurar la calidad del producto final.
Rol Responsabilidad
Encargado de la gestión de la calidad del proyecto, además de
Jefe de proyecto
comunicar si existe algún error en el plan de calidad.
Realiza las funciones de análisis de los requisitos del sistema del cual se
Analista parte a desarrollar la aplicación y organizar sus datos en base a los
estándares de calidad.
Desarrollar el diseño de arquitectura y bajo nivel del software, según
Ingeniero de software
los estándares de calidad que se encuentran en el plan de calidad.
Su función es la de construir el codigo que dará lugar al producto
Desarrolladores basado en métricas, estándares y herramientas de codificación
establecidas.
Verificadores Llevar a cabo las revisiones de software en todas las fases del proyecto.
6.1 Estándares
6.2 Checklists
Producto Planificación
Objetivo Cuantificable La Planificación del proyecto debe respetar los plazos
establecidos.
Se requiere la participación del cliente.
Atributos de Calidad Claridad, Mantenimiento, Flexibilidad, Confiabilidad, Corrección,
Facilidad de uso, Eficiencia, Integridad.
Encargado (s) revisión final Jefe de Proyecto, Cliente
Producto Análisis
Objetivo Cuantificable Se requiere la participación del cliente.
Se requiere la participación del Analista de Negocios
No se debe consumir más de un 30% del tiempo total del
proyecto.
Se deben identificar las soluciones que satisfagan la
Especificación de Requerimientos, en un 100%, y seleccionar
solo una.
Se debe documentar la Solución Propuesta en un 100%.
Se debe preparar el Plan inicial del Proyecto en un 70% del total
y de QA en un 80%, basado en la Solución Propuesta.
Producto Diseño
Objetivo Cuantificable No se debe consumir más de un 60% del tiempo total del
Proyecto.
Se requiere de la participación del Arquitecto de Sistema.
Se requiere la participación del Diseñador.
Se requiere de la participación del Jefe de Proyectos.
Se requiere participación del Analista de Negocios
Se debe definir la Funcionalidad y Solución Física que va a
satisfacer los Requerimientos en un 90%.
Se debe planificar cómo se va a implementar y aceptar la
Solución Propuesta en un 90%.
Se debe planificar el soporte de la Solución Propuesta en un
90%.
Producto Implementación
Objetivo Cuantificable No se debe consumir más de un 60% del total del Proyecto.
Las Pruebas no deben superar más del 30% del total del
Proyecto.
A continuación, se definen los productos de trabajo que deberían entregarse dentro del
desarrollo del proyecto:
Plan de Proyecto
Para contar con una forma de monitorear y controlar lo que se está llevando a cabo dentro del
desarrollo del proyecto. El Plan de Proyecto proporciona un repositorio central que contiene la
información de planificación e implementación requerida para ejecutar el plan de proyecto
entero. Provee un resumen y una integración de todos los planes contenidos en el proyecto y
de todos los proyectos contenidos en el programa. Posibilita el monitoreo del progreso del
proyecto de manera consistente con el plan.
El Plan de Proyecto inicial refleja la información que está disponible en la fase de análisis. Al
tener información más detallada, según avanza el proyecto, el plan de proyecto es actualizado
de acuerdo con esto. La cobertura del Plan de Proyecto es el proyecto completo, pero en
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
cualquier punto del tiempo, normalmente contendrá actividades detalladas solamente para la
fase actual y la fase siguiente.
0
Plan de Riesgos
El Plan de Riesgos establece las posibles situaciones en las que el proyecto podría verse
afectado. Para ello, se realiza un Análisis de Riesgos, a través de la cual se establecerán las
acciones a tomar en caso que se concreten dichas situaciones. Básicamente, el Plan de Riesgos
debe contemplar la: definición de los riesgos, la posibilidad de que se concrete cada uno de los
riesgos detectados, definir qué tan grande sería el impacto de cada riesgo identificado en el
proyecto, definir e indicar cuales son los eventos indicadores de que el riesgo se ha concretado,
y definir el plan de contingencia para cada uno de ellos.
1
Especificación de Requerimientos
La Especificación de Requerimientos proporciona un repositorio central que contiene la
información actualizada de cada uno de los requerimientos detectados, como el número
secuencial que identifica en forma única al requerimiento, tipo de requerimiento, identificación
de requerimiento original (cuando es reclasificado), estado del requerimiento, persona que lo
planteó, categoría del requerimiento, nombre del requerimiento, fecha en que se da por
aprobado el requerimiento por parte del cliente, nombre de la persona que da por aprobado el
requerimiento. Todo esto, permitirá una administración correcta de los requerimientos del
proyecto. Por otra parte, la Especificación de Requerimientos refleja las necesidades de
negocio, los requerimientos necesarios para resolver aquellas necesidades, y objetivos del
cliente que buscan una solución. Este es el primer documento que se genera en un proyecto y
debe ser conciso, claro y completo; de modo tal que sea la base para las siguientes etapas. Por
otro lado, debe ser escrito en un lenguaje de alto nivel, en términos del negocio. Debiera ser
capaz de ser producido en un tiempo limitado, y no debería contener detalles específicos a
menos que sean considerados requisitos para el negocio. La Especificación de Requerimientos
forma la base para el desarrollo de la Solución Propuesta, pero al mismo tiempo difieren, pues
ésta refleja las necesidades y objetivos de negocio traducidos en requerimientos para una
solución. La Solución Propuesta detalla especificaciones para una solución específica
seleccionada a partir de un número de alternativas posibles.
Especificación Funcional
La Especificación Funcional especifica en términos no técnicos, qué es lo que la solución hace
para el usuario. Este es un documento muy importante, porque provee una única definición
formal del total de los requerimientos que satisface la solución, y por qué es la base para
planificar el diseño y para desarrollar e implementar el Proyecto. Para el desarrollo de la
Especificación Funcional, se toma como base lo escrito en los documentos de Especificación de
Requerimientos y Solución Propuesta.
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
Plan de pruebas
El Plan de Pruebas es un documento estrechamente alineado con la Especificación Funcional,
el cual describe las pruebas que serán llevadas a cabo para demostrar al cliente que la solución
satisface los requerimientos y que la solución cumple con el uso que se pretende en el
ambiente operacional del cliente (Verificación y Validación).
Manual de usuario
Explica el comportamiento del sistema desde el punto de vista funcional de la Aplicación. Para
ello, se basa en el documento de Especificación Funcional.
Avances de la Aplicación
Subproductos que evaluará el cliente
6.4 Mediciones
E = A + B x (KLOC)C
Métricas De Éxito
Registra el porcentaje de usuarios de la prueba capaces de lograr lo que se pidió.
Fórmula: Éxito = (nº tareas terminadas +(nº medias 0.5))100/n°total de tareas.
Métricas de Eficiencia
Páginas de Acceso Rápido: El tiempo de descarga estará en función del tamaño de la
página estática y la velocidad de la línea de conexión establecida.
CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
7. Tareas De SQA
Se identifican como puntos de revisión aquellos que permiten validar y controlar las
tareas realizadas dentro de cada etapa del ciclo de desarrollo y por cada cambio
producido en mantención. Debe ser utilizado por la unidad de SQA durante la
planificación para verificar el correcto establecimiento de los hitos de calidad
Planificación
Análisis
Diseño
Implementación
Operación (Mantención)
8. Apéndices
9. Glosario