Norma Iso 25000

CODIGO Linux01
VERSION 1.0.2
Plan de Calidad de Software. PAGINA
Facultad de Ingeniería
Carrera Profesional de Ingeniería de Sistemas e Informática
Curso:
Calidad de Software
Profesor:
ARIAS CAYCHO,JESUS
Tarea 1
Alumno:
Antonio Alexander Borda Castro
Juan Carlos Silva
Jaime Ramirez
Lima – Perú
Julio-2018
CODIGO Linux01
VERSION 1.0.2
Plan de calidad de software
Proyecto:
Versión: 01
CODIGO Linux01
VERSION 1.0.2
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
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
6. Estándares, Practicas, Convenciones Y Mediciones

6.1 Estándares
6.2 Checklists
6.3 Procesos, Guías y Procedimientos
6.4 Mediciones
7. Tareas de SQA
8. Apéndices
8.1 Glosario
8.2 Historia de Cambios
CODIGO Linux01
VERSION 1.0.2
1. Introducción:
La rapidez con que el mercado mundial avanza hacia la globalización, hace

imprescindible el uso de la tecnología como primer recurso para concretarla. Dentro de
ella, lo que ha tenido éxito en el último tiempo es la aparición de nuevos sistemas
operativos, los cuales tienen como finalidad, actuar como intermediario entre el
usuario y el computador, de manera que el usuario pueda ejecutar programas y usar el
equipo de manera adecuada. Para que todo esto sea posible, el sistema debe
responder de manera eficiente. Dentro de tales características, el sistema operativo
que ha destacado al respecto es Linux.
Llevado al ámbito nacional, se puede apreciar que dicho recurso ha experimentado un
desarrollo cada vez más creciente en los últimos años, con lo cual se hace patente la
necesidad de las empresas y las personas en general, de encontrar una manera
apropiada de adquirir los conocimientos que les permitan desenvolverse dentro de
esta tecnología emergente.
Linux está avanzando en todos los campos de la informática y su número de usuarios
crece rápidamente. Las ventajas técnicas de Linux por sobre otros sistemas operativos
comerciales son muy importantes y evidentes (es estable, y gratuito). Debido a esto, en
un futuro cercano Linux podría convertirse en el sistema operativo del mañana.
Usando las herramientas y tecnología que la informática provee, el equipo del proyecto
equipo contribuirá proporcionando los elementos adecuados para satisfacer las
necesidades de todos aquellos con mayor desconocimiento en el área de utilización de
Linux, mediante una aplicación de software que facilite su autoaprendizaje, es decir,
una herramienta que guíe y ayude al usuario a utilizar Linux.
El presente documento establece, de acuerdo a la política organizacional, las
actividades de SQA que deberán ser ejecutadas durante el ciclo de vida del software
definido para la aplicación. El ciclo de vida comprende las etapas de Planificación,
Especificación de Requerimientos, Análisis, Diseño, Implementación, Instalación
(aceptación y entrega), y Operación (Mantención).
El objetivo del Plan de Calidad es comunicar el ámbito, recursos, y herramientas a los
gestores del software y personal técnico, además de entregar a la administración una
visibilidad adecuada del proceso utilizado y los productos construidos durante el
proyecto mediante acciones planificadas y sistemáticas que aseguren la calidad de los
procesos y productos.
Se trabaja con una metodología apropiada de desarrollo.
 El proyecto usa estándares y procedimientos en su trabajo.

 Se conducen revisiones y auditorías independientes.
 Se produce documentación para garantizar el futuro mantenimiento.
 La documentación se produce durante y no después del desarrollo.
 Existen mecanismos, y son usados, para controlar los cambios.
CODIGO Linux01
VERSION 1.0.2
 El testing se enfatiza en las áreas de producto de alto riesgo.

 Cada tarea en el proceso de desarrollo se completa satisfactoriamente antes de
que la siguiente comience.
 Las desviaciones de los estándares y procedimientos se exponen lo antes
posibles.
 El proyecto es auditable por profesionales externos en cualquier momento
 La tarea de control de calidad se ejecuta siguiendo estándares previamente
establecidos.
 El plan de SQA y el plan de desarrollo son compatibles.
2. Objetivo:
El principal objetivo es brindar a los administradores del proyecto y a su equipo

de trabajo información relevante sobre los procesos que involucran el
desarrollo del sistema.
Con el fin de que el sistema se ajuste a las necesidades del cliente, se

establecen las siguientes pautas:
 Identificar y atender los puntos que no cumplan con los estándares

establecidos.
 Evaluar los procesos que involucran al sistema.
 Crear un plan de cumplimiento.
2.1 Objetivos de SQA
Los principales objetivos del Aseguramiento de la Calidad del Software son los
siguientes:
• Mejorar la calidad del software monitoreando apropiadamente tanto los

productos de software como el proceso de desarrollo que los genera.
• Asegurar el cumplimiento de los estándares y procedimientos establecidos para

el software y el proceso de software establecidos.
• Asegurar que cualquier desviación en el producto, el proceso, o los estándares

son elevados a la gerencia para poder resolverlas.
CODIGO Linux01
VERSION 1.0.2
2.2 El Rol de SQA
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.
• La existencia de una función de SQA no asegura que se siguen los estándares y

los procedimientos.
• Sólo si la dirección demuestra periódicamente su soporte a SQA, siguiendo sus

recomendaciones, SQA podrá ser efectiva.
• 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.
2.3 Responsabilidades de SQA
Las principales responsabilidades del rol de SQA son las siguientes:

1
• Verificar la completitud en los planes de desarrollo y de calidad del proyecto.
• Participar como moderador en inspecciones de diseño, de código u otros

productos.
• Auditar periódicamente para determinar el cumplimiento de los estándares
• 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.
2.4 Funciones de SQA
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
Prácticas de QA: se definen y están disponibles herramientas, técnicas, métodos y

estándares de desarrollo adecuados para ser usados como estándares de las revisiones
de QA.
• Evaluación de la planificación del proyecto de software: si no se planifican prácticas

de calidad adecuadas desde el inicio y sincronizadas con el plan del proyecto, luego no
serán implementadas.
• Evaluación de los requerimientos: como es extremadamente inusual que se

desarrollen productos de alta calidad a partir de requerimientos de baja calidad, los
requerimientos iníciales deben ser revisados contra los estándares de calidad
establecidos.
• 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 de las prácticas de codificación: prácticas apropiadas de codificación

deben ser establecidas y usarse.
• 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
A continuación, se nombran los productos de trabajos que soportan la construcción del

sistema.
Producto de Trabajo Descripción

Plan de Proyecto Documentación para controlar y monitorear el Proyecto.
Documentación sobre las posibles situaciones en las que el Proyecto puede
Plan de Riesgos
verse afectado.
Repositorio central que contiene la información actualizada de cada uno de los
requerimientos detectados.
Especificación de Requerimientos
Descripción de los requerimientos del cliente que deben ser satisfechos por el
equipo de desarrollo.
Documentación sobre la situación actual, sus problemas y las mejoras que
Especificación del sistema (Solución Propuesta)
introduce el desarrollo de la solución que se propone.
Documentación que especifica en términos no técnicos, que es lo que la
Especificación Funcional
solución hace que se propone.
Documentación que describe las pruebas que serán llevadas a cabo para
Plan de pruebas
demostrar al cliente que la solución satisface los requerimientos definidos.
CODIGO Linux01
VERSION 1.0.2
Documentación que define la Arquitectura de la Solución e identifica todos los

Especificación de Diseño de Sistema
componentes del sistema.
Documentación detallada de los requerimientos de soporte desde la fase de
Especificación de Diseño de Soporte
Implementación a la de Operación.
Documentación que define todas las actividades de aseguramiento de calidad
Plan de aseguramiento de calidad SQA
que se harán durante el Proyecto.
Documentación que describe la metodología que se seguirá para realizar la
Plan de gestión de la configuración SCM gestión de la configuración en el proceso de desarrollo de software,
formularios y checklist.
Documentación que describe los resultados de las pruebas, los cuales
Informe de pruebas (testing)
ayudarán a comprobar el “buen” funcionamiento del software.
Documentación que describe el comportamiento del sistema desde el punto
Manual de usuario
de vista funcional de la aplicación.
Documentación de la especificación de los componentes de instalación y la
Manual de instalación del sistema
forma en que se debe realizar esta tarea.
Avances de la Aplicación Subproductos que evaluará el cliente.
Diseño de imágenes y escenarios Elementos gráficos que forman parte de la aplicación
4. Destinatarios
El propósito del presente plan es definir la organización, actividades y

responsabilidades asociadas al proceso de SQA durante todo el ciclo de vida del
proyecto. Además, entregar guías para la ejecución de las actividades de SQA, definir
los estándares, los procedimientos y las convenciones que serán utilizados durante
estas actividades y establecer las herramientas, técnicas y metodologías que
soportarán las prácticas de SQA.
Por lo tanto, el plan de SQA está dirigido al jefe de proyecto, los desarrolladores y al
grupo de SQA, responsable de la elaboración, actualización y monitoreo del plan.
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
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. Estándares, Practicas, Convenciones y Mediciones
El propósito de esta sección es definir los estándares, prácticas, convenciones y

mediciones utilizadas para lograr los objetivos definidos en este Plan.
CODIGO Linux01
VERSION 1.0.2
6.1 Estándares
 Estándares de la World Wide Web Consortium (W3C).

 Diseño y aplicaciones web (Involucra los estándares de HTML 5, CSS 3, Ajax y
otros).
 Arquitectura web
 Web de los Dispositivos
 Norma ISO 9126 (reemplazado por el proyecto SQuaRE, ISO 25000:2005): El

modelo establece diez características, seis que son comunes a las vistas interna
y externa y cuatro que son propias de la vista en uso.
 IEEE 1012 – 2004: Estándar de Verificación y Validación de Software:

Determina si los productos de una actividad de desarrollo dada se ajustan a los
requisitos de que la actividad y si el software satisface su uso previsto y las
necesidades del usuario.
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 Especificación de Requerimientos (Definición)

Objetivo Cuantificable Se requiere la participación del cliente.
No se debe consumir más de un 20% del tiempo total del
proyecto.
Deben estar identificados los problemas o necesidades de
Negocios en un 90%.
Las metas de la organización, sus objetivos y factores críticos de
éxito deben ser analizados en un 100%.
Los Procesos de Negocios y flujos de información actuales
deben ser analizados en un 100%.
Los Requerimientos de la Solución, en términos de Procesos y
principios de negocios, estructura organizacional y arquitectura
tecnológica, deben ser analizados en un 100%
Los beneficios de la Solución e impacto en la organización,
recursos humanos y ambiente tecnológico deben ser analizados
en un 100%.
Nota: En esta etapa no se debe pensar en posibles soluciones,
sino solamente en el problema, es decir, se debe describir el
CODIGO Linux01
VERSION 1.0.2
problema en forma de Requerimientos

Atributos de Calidad Claridad, Mantenimiento, Flexibilidad, Corrección, Confiabilidad,
Facilidad de uso, Integridad, Eficiencia
Encargado (s) revisión final Cliente, Jefe de Proyectos
Producto Análisis
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.
Atributos de Calidad Completitud, Claridad, Mantenimiento, Flexibilidad, Corrección,

Confiabilidad, Facilidad de uso, Integridad, Eficiencia
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%.
Atributos de Calidad Claridad, Completitud, Mantenimiento, Flexibilidad, Corrección,

Encargado (s) revisión final Arquitecto de Sistema, Jefe de Proyectos, Cliente
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.
Los componentes de la Solución deben ser construidos en un

100%.
Las Pruebas deben cubrir el 100% de los Componentes

construidos.
Atributos de Calidad Corrección, Claridad, Mantenimiento, Integridad, Completitud,

CODIGO Linux01
VERSION 1.0.2
Encargado (s) revisión final Jefe de Proyecto, Cliente, Arquitecto de Sistema
Producto Instalación (Aceptación y Entrega)

La Solución se prueba 100% en un ambiente operacional hasta

que esté lista para la prueba de aceptación formal por parte del
cliente.
El cliente debe estar de acuerdo en que la Solución cumple la

Especificación Funcional, que la Solución ha sido distribuida y
que la Organización acepta la propiedad de la Solución, en un
100%.
Se debe registrar, revisar y corregir la Solución para los defectos

identificados en un 100%.
Se debe involucrar al personal de Soporte para facilitar el

traspaso exitoso, en un 80%.
Atributos de Calidad Mantenimiento, Corrección, Claridad, Confiabilidad, Integridad,

Completitud, Facilidad de uso, Eficiencia
Encargado (s) revisión final Cliente
Producto Operación (Mantención)

Se debe hacer una revisión para registrar datos estadísticos y

discutir sobre áreas de experiencia que puedan ser útiles para
otros proyectos en el futuro, en un 80%.
Se debe archivar el contenido del Proyecto y considerar el

proyecto como terminado, en un 100%.
Se debe proveer soporte para la Mantención de la Solución en

un 100%.
Atributos de Calidad Corrección, Flexibilidad, Facilidad de uso, Corrección,

Confiabilidad, Claridad
Encargado (s) revisión final Cliente
Producto Plan de Proyecto

Objetivo Cuantificable El documento no debe superar las 200 hojas
Debe ser comprendido en un 98% por la totalidad del Equipo de

trabajo.
La Planificación del Proyecto debe ser capaz de soportar Eventos

No Planificados que se puedan producir en el transcurso del
Proyecto. Los EVNP no deben cubrir más de un 10% del tiempo
CODIGO Linux01
VERSION 1.0.2
total del Proyecto.
Se requiere participación del cliente.
El Plan del Proyecto debe contemplar la estrategia, organización,

riesgos, contingencias, recursos y tareas, en un 100% para la
fase de diseño.
Atributos de Calidad Claridad, Mantenimiento, Flexibilidad, Confiabilidad, Facilidad

de uso, Integridad, Eficiencia
Producto Plan de Riesgos

Objetivo Cuantificable El documento no debe superar las 50 hojas.
El documento como mínimo debe contener 20 riesgos.
Atributos de Calidad Claridad, Mantenimiento, Flexibilidad, Corrección, Confiabilidad,

Facilidad de uso, Integridad, Eficiencia.
Encargado (s) revisión final Jefe de Proyectos
Producto Especificación de Requerimientos

Objetivo Cuantificable Se requiere participación del Jefe de Proyectos.
Se requiere participación del Analista de Negocios.
Debe existir un 100% de conformidad en los acuerdos entre
Cliente y Jefe de Proyectos.
Se debe permitir una administración eficiente ante los estados y
cambios que sufran los requerimientos, en un 100%.
Debe ser suficientemente claro, es decir, explicado de manera
No técnica para el entendimiento del cliente.
Deben estar contemplados el 100% de los Requerimientos
planteados por el cliente.
Deben estar contemplados un 100% de los Requerimientos
Derivados.
Atributos de Calidad Completitud, Mantenimiento, Claridad, Flexibilidad, Corrección,
Encargado (s) revisión final Jefe de Proyectos, Cliente
Producto Especificación de Sistema (Solución Propuesta)

Objetivo Cuantificable Se requiere participación del Jefe de Proyectos.

cliente y desarrolladores.
Debe ser claro, es decir, explicado de manera No técnica para el

CODIGO Linux01
VERSION 1.0.2
entendimiento del cliente en un 100%.
La Solución que se presenta al cliente debe ser rigurosa en sus

restricciones, en un 100%.

Producto Especificación Funcional

Objetivo Cuantificable Se requiere participación del cliente.
Se requiere participación del Jefe de Proyectos.
Debe ser suficientemente claro, es decir, explicado de manera
No técnica para el entendimiento del cliente en un 100%.
Producto Plan de Pruebas

Se requiere participación del Arquitecto de Sistemas.
El plan de pruebas debe abarcar todos los módulos de la

aplicación.
Las Pruebas deben cubrir el 100% de la Aplicación.
Las Pruebas deben abordar en un 100% los tipos de prueba:

unitaria, integración, y sistema.
Las Pruebas deben abordar en un 100% los enfoques: Funcional,

Seguridad, Calidad, Rendimiento, Aceptación, e Instalación.
Atributos de Calidad Claridad, Completitud, Mantenimiento, Flexibilidad, Corrección,

Encargado (s) revisión final Cliente, Jefe de Proyectos, Analista de Negocios
Producto Especificación de Diseño de Sistema

Se requiere participación del Arquitecto de Sistemas.

CODIGO Linux01
VERSION 1.0.2
El desarrollador debe comprender en un 98% el documento.
La Solución (desde el punto de vista del Diseño) debe

contemplar el 100% de los Requerimientos acordados con el
cliente.
La Solución (desde el punto de vista del Diseño) debe

contemplar el 100% de los Requerimientos derivados.
La Solución (desde el punto de vista del Diseño) debe ser lo

suficientemente flexible para soportar en el futuro nuevas
funcionalidades en un 90%

Producto Especificación de Diseño de Soporte


El Documento no debe superar las 100 hojas.

Producto Plan de Aseguramiento de Calidad (SQA)

Objetivo Cuantificable Se requiere la participación del Jefe de QA.
Se requiere la participación del Jefe de Proyectos.
Se debe asegurar en un 100%, que la calidad requerida para la

solución y el proceso de desarrollo esté definido, incorporado y
verificado en todas las fases del proyecto.
En el Plan de QA se deben definir en un 100% todas las

actividades de aseguramiento de calidad que se harán durante
el proyecto.
Atributos de Calidad Mantenimiento, Claridad, Flexibilidad, Corrección, Confiabilidad,

Encargado (s) revisión final Jefe de Proyectos, Jefe de QA

CODIGO Linux01
VERSION 1.0.2
Producto Informe de Pruebas (Testing) de la Integridad del Sistema,

Unidad, y Aceptación
Objetivo Cuantificable El cliente debe comprender en un 98% el documento.
Se deben detectar a lo menos un 40% de errores en los Casos de

Prueba aplicados.

Encargado (s) revisión final Cliente, Persona de QA, Jefe de Proyectos
Producto Manual de Usuario

Objetivo Cuantificable El manual no debe manejar un lenguaje técnico, debe ser
entendido en un 95% por los usuarios finales
No debe superar las 50 hojas

Encargado (s) revisión final Desarrollador, Jefe de Proyectos
Producto Manual de Instalación del Sistema

Objetivo Cuantificable El manual no debe superar las 50 hojas

Encargado (s) revisión final Desarrollador, Jefe de Proyectos
6.3 Procesos, Guías y Procedimientos
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
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 del Sistema (Solución Propuesta)

Mostrando como es la situación actual, sus problemas y las mejoras que introduce el desarrollo
de la solución que se propone. La Solución Propuesta específica en términos no técnicos cómo
la solución satisface al cliente y es la base para la Especificación Funcional, que es producida en
la fase de diseño. Incluye también el soporte operacional propuesto que es la base para
formular en la Especificación de Diseño de Soporte.
 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 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).
 Especificación de Diseño de Sistema

La Especificación de Diseño del Sistema define la Arquitectura de la Solución e identifica todos
los componentes del sistema. Establece las interfaces y la especificación a alto nivel de cada
componente. Para cada componente se establece: la descripción de la componente, diagrama
de flujo de datos de la componente, interfaces de la componente, estructura de datos de la
componente, diseño funcional de la componente, criterios de diseño y restricciones de la
componente, especificación de test de la componente e integración, y ambiente de la
componente. Por otro lado, también especifica un nivel básico de implementación y los test de
componentes e integración que se utilizan en la fase de implementación.
 Especificación de Diseño de Soporte

La Especificación de Diseño de Soporte provee documentación detallada de los requerimientos
de soporte desde la fase de implementación a la de operación. Los requerimientos de soporte
al cliente deben ser claramente establecidos para identificar áreas críticas que pudieran
requerir recursos significativos.
 Plan de Aseguramiento de Calidad SQA

El Plan de QA define todas las actividades de aseguramiento de calidad que se harán durante el
proyecto. La importancia de este plan reside en contar con un documento formal con
instrucciones explícitas acerca de la forma de llevar a cabo cada una de las actividades
previamente planificadas y de esta forma poder controlar cada una de las variables que inciden
en el correcto desarrollo del producto.
 Plan de Gestión de la Configuración SCM

Describe la metodología que se seguirá para realizar la gestión de la configuración en el
proceso de desarrollo de software, los formularios y checklist.
 Informe de pruebas (testing)

Los resultados de estas pruebas ayudarán a comprobar el “buen” funcionamiento del software
una vez integrados sus componentes.
 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.
 Manual de instalación del sistema

Especificación de los componentes de instalación y la forma en que se debe realizar esta tarea.
 Avances de la Aplicación
Subproductos que evaluará el cliente
 Diseño de imágenes y escenarios

CODIGO Linux01
VERSION 1.0.2
Elementos gráficos que forman parte de la aplicación.
6.4 Mediciones
Métricas de Calidad y Fiabilidad

 Tiempo medio entre fallos: Tiempo de operatividad del sistema antes de que
aparezcan fallos.
 TMEF = TMDF + TMDR
 Disponibilidad: Probabilidad de que el sistema se encuentre disponible para su

uso.
 Disponibilidad = TMDF / (TMDF + TMDR) ×100
Estimación de Esfuerzo de Desarrollo de Software

Líneas de código
 Generalmente, el modelo de estimación de esfuerzo consiste de dos partes. La
primera provee una base de estimación como una función del tamaño del
software, y es de la siguiente forma:
E = A + B x (KLOC)C
Métricas de Usabilidad Web

Métricas y Heurísticas de Usabilidad
 Comprensión Global del Sitio
 Ayuda y Retroalimentación
 Aspectos de Interfaces y Estéticos
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 Y Heurísticas De Funcionalidad

 Búsqueda y Recuperación
 Búsqueda Restringida
 Búsqueda Global
 Personalización de la Recuperación
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
Fórmula: tiempo descarga = f( T, c) siendo T tamaño de la página y c la velocidad de

conexión.
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
 Revisión y aprobación del plan de SQA.

 Revisión y aprobación del plan de proyecto.
 Revisión y aprobación del plan de riesgos.
 Reporte del estado y los resultados de las actividades de SQA.
 Especificación de requerimientos (Definición)
 Revisión y aprobación de la especificación de requerimientos.

 Análisis
 Revisión y Aprobación de la Especificación del Sistema (Solución Propuesta).

 Diseño
 Revisión y aprobación de la Especificación de Diseño de Sistema.

 Revisión y aprobación de la Especificación Funcional del Sistema.
 Revisión y aprobación de la Especificación de Diseño de Soporte del
Sistema.
 Revisión y aprobación del Plan de Pruebas del sistema
 Implementación
 Revisión y aprobación de los casos de prueba.

 Revisión y aprobación de la especificación de los procedimientos de prueba.
 Revisión y aprobación del código y su documentación.
 Revisión y aprobación de los resultados de la prueba de unidad, integración,
y sistema
CODIGO Linux01
VERSION 1.0.2

 Revisión y aprobación del Manual de Usuario.
 Revisión y Aprobación del Manual de Instalación del Sistema
 Instalación (Aceptación y entrega)
 Revisión y aprobación el software y su documentación.

 Operación (Mantención)
 Revisión y aprobación de cada cambio producido durante la mantención en

su especificación, diseño, implementación y prueba.
 Revisión y aprobación de la documentación asociada a los cambios.
 Revisión y aprobación de la nueva versión del software y de su
documentación.
8. Apéndices
9. Glosario

Norma Iso 25000

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Norma Iso 25000

Загружено:

Авторское право:

Доступные форматы

CODIGO Linux01

Carrera Profesional de Ingeniería de Sistemas e Informática

Antonio Alexander Borda Castro

Juan Carlos Silva

Plan de calidad de software

6. Estándares, Practicas, Convenciones Y Mediciones

La rapidez con que el mercado mundial avanza hacia la globalización, hace

Se trabaja con una metodología apropiada de desarrollo.

 El proyecto usa estándares y procedimientos en su trabajo.

 El testing se enfatiza en las áreas de producto de alto riesgo.

El principal objetivo es brindar a los administradores del proyecto y a su equipo

Con el fin de que el sistema se ajuste a las necesidades del cliente, se

 Identificar y atender los puntos que no cumplan con los estándares

2.1 Objetivos de SQA

• Mejorar la calidad del software monitoreando apropiadamente tanto los

• Asegurar el cumplimiento de los estándares y procedimientos establecidos para

• Asegurar que cualquier desviación en el producto, el proceso, o los estándares

2.2 El Rol de SQA

• La existencia de una función de SQA no asegura que se siguen los estándares y

• Sólo si la dirección demuestra periódicamente su soporte a SQA, siguiendo sus

2.3 Responsabilidades de SQA

Las principales responsabilidades del rol de SQA son las siguientes:

• Participar como moderador en inspecciones de diseño, de código u otros

• Auditar periódicamente para determinar el cumplimiento de los estándares

2.4 Funciones de SQA

Prácticas de QA: se definen y están disponibles herramientas, técnicas, métodos y

• Evaluación de la planificación del proyecto de software: si no se planifican prácticas

• Evaluación de los requerimientos: como es extremadamente inusual que se

• Evaluación de las prácticas de codificación: prácticas apropiadas de codificación

A continuación, se nombran los productos de trabajos que soportan la construcción del

Producto de Trabajo Descripción

Documentación que define la Arquitectura de la Solución e identifica todos los

El propósito del presente plan es definir la organización, actividades y

6. Estándares, Practicas, Convenciones y Mediciones

El propósito de esta sección es definir los estándares, prácticas, convenciones y

 Estándares de la World Wide Web Consortium (W3C).

 Norma ISO 9126 (reemplazado por el proyecto SQuaRE, ISO 25000:2005): El

 IEEE 1012 – 2004: Estándar de Verificación y Validación de Software:

Producto Especificación de Requerimientos (Definición)

problema en forma de Requerimientos

Atributos de Calidad Completitud, Claridad, Mantenimiento, Flexibilidad, Corrección,

Atributos de Calidad Claridad, Completitud, Mantenimiento, Flexibilidad, Corrección,

Los componentes de la Solución deben ser construidos en un

Las Pruebas deben cubrir el 100% de los Componentes

Atributos de Calidad Corrección, Claridad, Mantenimiento, Integridad, Completitud,

Encargado (s) revisión final Jefe de Proyecto, Cliente, Arquitecto de Sistema

Producto Instalación (Aceptación y Entrega)

La Solución se prueba 100% en un ambiente operacional hasta

El cliente debe estar de acuerdo en que la Solución cumple la

Se debe registrar, revisar y corregir la Solución para los defectos

Se debe involucrar al personal de Soporte para facilitar el

Atributos de Calidad Mantenimiento, Corrección, Claridad, Confiabilidad, Integridad,

Encargado (s) revisión final Cliente

Producto Operación (Mantención)

Se debe hacer una revisión para registrar datos estadísticos y

Se debe archivar el contenido del Proyecto y considerar el

Se debe proveer soporte para la Mantención de la Solución en

Atributos de Calidad Corrección, Flexibilidad, Facilidad de uso, Corrección,

Encargado (s) revisión final Cliente

Producto Plan de Proyecto

Debe ser comprendido en un 98% por la totalidad del Equipo de

La Planificación del Proyecto debe ser capaz de soportar Eventos

total del Proyecto.

Se requiere participación del cliente.