Diego Colque Ramos - Christian Juárez Medina - Diego Sánchez Chacón - Jonathan Ventura Apaza

Diego Colque Ramos - Christian Juárez Medina - Diego Sánchez Chacón - Jonathan Ventura Apaza
Gestión de Seguridad Versión 1.0
Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014
Entregable 3
Plan de Aseguramiento de Calidad del Software de un Sistema de Gestión de Seguridad
Versión 1.0
1
Entregable 3
Historial de Revisiones
Fecha Versión Descripción Autor
25/SET/2014 1.0 ENTREGABLE 1 Diego Colque Ramos

Christian Juarez Medina
Diego Sánchez Chacón
Jonathan Ventura Apaza
23/OCT/2014 1.0 ENTREGABLE 2 Diego Colque Ramos

20/NOV/2014 1.0 ENTREGABLE 3 Diego Colque Ramos

2
Entregable 3
Tabla de Contenidos
1. Introducción 4
1.1. Propósito 4
1.2. Alcance 5
1.3. Definiciones, Acrónimos y Abreviaturas 5
1.4. Referencias 6
1.5. Visión de Conjunto 6
2. Objetivos de Calidad 6
3. Gestión 6
3.1. Organización 6
3.2. Tareas 7
3.3. Responsabilidades 7
4. Documentación 11
4.1. Documentación mínima requerida 11
4.1.1. Especificación de requerimientos 11
4.1.2. …… 12
4.3. Otra Documentación 13
5. Estándares y Métricas 13
5.1. Estándares para Documentación 13
5.2. Métricas 13
6. Revisiones 16
6.1. Descripción 16
6.1.1. Revisión de Calidad del
Producto 16
6.1.2. Revisión de Ajuste al
Proceso 16
6.1.3. Revisión Técnica Formal
(RTF) 16
6.2. Requerimientos
Mínimos 17
6.3. Agenda 23
6.3.1. Fase I - Inicial 23
6.3.1.1. Iteración I 23
6.3.1.2. Iteración II 23
6.3.2. Fase II – Elaboración 24
6.3.3. Fase III – Construcción 24
3
Entregable 3
6.3.4. Fase IV – Transición 25
7. Verificación 28
8. Reporte de Problemas y Acciones Correctivas 36
4
Entregable 3
Plan de Aseguramiento de Calidad del Software
1. Introducción
Este documento contiene el Plan de Aseguramiento de la Calidad [SQAP] para el proyecto
Sistema de Gestión de la Seguridad [SGS]. En este documento se describen las actividades de
cada uno de los roles interesados en el desarrollo del proyecto.
1.1. Propósito
El propósito de este documento es dar a conocer en detalle todas aquellas actividades de
desarrollo de un SGS para la empresa desarrolladora de software IaSoft teniendo como
sucursal en “La Unión 125 - B Urb. Municipal Cercado - Arequipa“ estando a cargo como
jefe de proyecto al Ing. Jose Tamayo Oporto empleada por la empresa IaSoft. Se
revisarán todas las normas, estándares y técnicas que se aplicaran en el ciclo de
desarrollo del módulo.
También se realizará un seguimiento de cada actividad y se informará al responsable de
dicha actividad de algún defecto encontrado para su pronta corrección. El uso de este
plan por parte del equipo será para poder guiarse a lo largo del proyecto y evitar futuras
complicaciones.
Para el director del proyecto, podrá verificar que el equipo de trabajo realice el proyecto
de acuerdo al plan. Para asegurar que el proyecto final tenga pocos errores y este a la
medida del cliente, se usará el modelo de construcción de prototipos en donde podremos
presentarle al cliente un bosquejo de cómo quedará el cliente y en caso de que el cliente
tenga alguna duda o mire que falta algún requerimiento se podrá modificar sobre el
prototipo de tal manera que no se compromete el proyecto original.
1.2. Alcance
El presente documento establece, de acuerdo a las actividades del Aseguramiento de la
Calidad del Software [SQA] que son ejecutadas durante el ciclo de vida de desarrollo del
software para el proyecto de SGS . Este ciclo comprende las etapas de planificación,
especificación de requerimientos, diseño, implementación, integración y pruebas,
aceptación y entrega, y mantención.
[1] El objetivo de SQA es entregar a la administración una visibilidad adecuada del
proceso utilizado y los productos construidos durante el SGS mediante acciones
planificadas y sistemáticas que aseguren la calidad de los procesos y productos.
La empresa a laborar el plan de aseguramiento de calidad tiene de razón social IaSoft.
Es una empresa que se dedica al desarrollo de software brindando servicios de: Páginas
5
Entregable 3
Web, Diseño Móvil, Juegos Publicitarios, Tiendas Online, Dominios, Hosting, Antivirus
(AVIRA), Mailing Publicitario y Outsorcing Web.
IaSoft trabaja con las plataformas y especialidades de IBM, en linux. lenguajes como
RPG, Cobol, Visual basic, C++, ASP. PHP, JAva, HTML. Gestores de base de datos
como DB2, Oracle, Sybase, SQL Server.
También en sus procesos de desarrollo realizan pruebas necesarias para que satisfagan
las necesidades mencionadas por los clientes. Con el testing realiazn una preparación y
ejecución de pruebas de resultados, generación de ambientes de pruebas, generación de
informes de gestión y mejoramiento de los procesos.
También utiliza el modelo CMM-I ya que contiene disciplinas de ingeniería de sistemas y
software. Esta integración fue propuesta par5a reducir el coste de la mejora de procesos
basados en modelo e implementación mediante varias disciplinas [2].
1.3. Definiciones, Acrónimos y Abreviaturas
SQAP: Plan Aseguramiento de la Calidad del Software.
SQA: Aseguramiento de la Calidad del Software.
SGS: Sistema de Gestión de la Seguridad
GP: Gestión del Proyecto
SCM: Gestión de Configuración del Software
ERS: Especificacion de Requerimientos de Software
Plan de Aseguramiento de Calidad del Software Fecha:

23/OCT/2014
Entregable 2
1.4. Referencias
[1] ISO 9126 - SQA Software Quality Assurance

[2] IASOFT (2014),extraido de http://www.iasoft.es/paginas/paginafinal.asp?idNodo=67
[3] ISO 9001:2008 Objetivos de Calidad [2] ISO 9001:2008 Objetivos de Calidad
[4] Formato de Especificación de Requerimientos (ERS) ANSI / IEEE – Std 830
[5]Procedimiento de Validacion y Verificacion, 2010 recuperado de
http://www.inin.gob.mx/transparencia/doctosnormateca/P.SI-
6
Entregable 3
5,%20Rev%202%20Verificaci%C3%B3n%20y%20Validaci%C3%B3n%20de%20Softwa
re.pdf
[6] ANSI / IEEE – Std 1036 “STANDARD FOR SOFTWARE USER
DOCUMENTATION”.
[7] ANSI / IEEE – Std 1016 “RECOMMENDED PRACTICE FOR SOFTWARE
DESCRIPTIONS”
[8] Checklist para la especificación de requerimientos - recuperado de
https://campusvirtual.univalle.edu.co/moodle/mod/resource/view.php?
1.5. Visión de Conjunto

Con SQAP aseguramos que el proyecto se realizará de manera correcta y en el
tiempo planeado, y que tenga la calidad adecuada en cada fase del ciclo de vida del
proyecto.
El equipo de trabajo se asegurará de que se construya un software eficiente y
que siga los estándares adecuados tanto para la documentación como para su
desarrollo del proyecto.
2. Objetivos de Calidad [2]

- Hacer cumplir los estándares y normas adecuadas para garantizar la calidad del
proyecto.
- Dar solución y metodologías de cómo se construirá el software de una manera
adecuada a lo largo del ciclo de vida.
- Prevenir los defectos que puedan ocurrir en el desarrollo del software y corregirlos
cuando aparezcan.
- Durante cada fase del desarrollo del software se hará un seguimiento y se darán los
consejos necesarios para poder avanzar a la siguiente fase y siempre tener en cuenta
los requerimientos iniciales.
3. Gestión
En las subsecciones siguientes se especifican los elementos de la organización que
tienen influencia sobre la calidad del software, como está conformada la línea de
gestión de calidad, y de quien es la autoridad y responsabilidad por la calidad del
7
Entregable 3
software. (3.1), la lista de tareas cubiertas por este plan (3.2) y las responsabilidades
por cada tarea (3.3).
3.1. Organización
El encargado del área de gestión de calidad en el proyecto es el responsable de
realizar la gestión que asegura que el proceso establecido sea realmente
implementado y que los productos de ese proceso cumplan con los criterios de calidad
establecidos en este plan.
La gestión de calidad es una disciplina de gestión, junto con Gestión de Proyectos
[GP] y Gestión de Configuración del Software [SCM].
Las disciplinas de gestión brindan soporte a las disciplinas básicas (Requerimientos,
Análisis, Diseño, Implementación, Implantación y Verificación) y se realizan en forma
paralela a ellas.
Área Objetivos Rol Persona
Requerimientos y -Verificar que el Administrador y - Diego Colque Ramos

Análisis proceso de obtención analista
(Inspección de de los requerimientos
Requerimientos) es correcto
-Ayudar a definir el
Alcance del Sistema
-Establecer pautas
para la interfaz del
usuario
Diseño -Verificar que el Diseñador - Christian Juarez Medina

(Inspección de Modelo de dominio
planes) sea el adecuado
-Verificar y corregir la
descripción de la
arquitectur
Implementación y -Realizar verificación Responsable de - Diego Sánchez Chacón

Verificación unitaria al código Verificación y
8
Entregable 3
desarrollado Validación
-Realizar Plan de
Verificación y
validación
-Realizar Plan de
Implantación
Gestión de la -Realizar Plan de Responsable de - Jonathan Ventura

configuración y Configuración de SCM SCM Apaza
control de -Realizar Informe de la
Cambios Línea Base del
Proyecto
3.2. Tareas
Actividad Entregable Descripción

Asociado
Realizar el Plan de SQA Plan de SQA Permite documentar las

actividades que se llevarán
a cabo para asegurar la
calidad del software
Identificar las propiedades Propiedades de Calidad Define las métricas para

de Calidad evaluar y ver que el
software va yendo de la
forma esperada.
Evaluar la calidad de los Informe de revisión de Mide el nivel de calidad del

productos SQA proceso de desarrollo del
software, y hacer las
regulaciones necesarias.
Revisar el ajuste al proceso Informe de revisión de Hace las revisiones

SQA necesarias de acuerdo a los
9
Entregable 3
pasos anteriores, para

poder tomar decisiones
futuras.
Realizar Revisión Técnica Informe de Revisión Se revisa si el sistema en

Formal Técnica Formal desarrollo va cumpliendo
con los requisitos y
estándares establecidos
Evaluar y ajustar el Plan de Documento de Permite ver, revisar y/o

SQA Evaluación y Ajustes al corregir en el plan de
Plan de SQA aseguramiento de calidad
Revisar la entrega semanal Entrega semanal de SQA Permite realizar

periódicamente una revisión
semanal, para poder
realizar correcciones sin
son necesarias
Realizar evaluación final de Evaluación final de SQA Se dan los últimos ajustes
SQA para poder ver en qué nivel
se encuentra después de
este plan
Reuniones de Apoyo a la No Aplica

calidad
3.3. Responsabilidades
El responsable de SQA es el responsable de realizar las actividades y entregables
mencionadas en la sección anterior.
Como parte de las actividades del Responsable de SQA se revisarán los productos
que se consideren relevantes para la calidad del producto y del proceso. A
continuación se identifican esos productos y el responsable de cada producto, que
será la referencia en caso de que dicho producto necesite correcciones.
10
Entregable 3
Producto Rol responsable Responsable
Especificación de requerimientos Analista Diego Colque Ramos
Alcance del sistema Responsable del SCM Jonathan Ventura Apaza
Descripción de la Arquitectura Diseñador Christian Juarez Medina
Interfase de Usuario Diseñador Christian Juarez Medina
Estándar de Implementación Diseñador Christian Juarez Medina
Estándar de Documentación Técnica Analista Diego Colque Ramos
Plan de Verificación y Validación Responsable de Diego Sanchez Chacon

verificacion y validacion
Estándar de Documentación de Usuario Analista Diego Colque Ramos
Materiales para soporte al Usuario Analista Diego Colque Ramos
Plan de Proyecto Administrador Diego Colque Ramos
Documento de Riesgos Analista Diego Colque Ramos
Plan de Gestión de Configuración Responsable de SCM Jonathan Ventura Apaza
4. Documentación
El objetivo de esta sección es especificar los documentos que dirigen el desarrollo del
proyecto y que deberán ser revisados como parte de las actividades de aseguramiento
de la calidad. Para cada documento se indica el objetivo del documento, la plantilla,
norma y/o estándar que se usa para elaborar el documento y el contenido mínimo que
debe tener dicho documento.
4.1. Documentación mínima requerida

4. 1.1. Especificación de Requerimientos
11
Entregable 3
[4] Para el Especificacion de Requerimientos (ERS) elaborada por el desarrollador, este

formato debe describir de forma clara y puntual cada uno de los requerimientos del sistema.
1. INTRODUCION
1.1.1. Objetivo
1.1.2. Alcance
1.1.3. Definiciones, acrónimos y abreviaciones
1.1.4. Referencias
1.1.5. Revisión
2. DESCRIPCION GENERAL
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características de los usuarios
2.4 Restricciones generales
2.5 Asunciones y dependencias
3. ESPECIFICACION DE REQUERIMIENTOS
3.1 Requerimiento Funcional
3.1.1. Introducción
3.1.2. Entradas
3.1.3. Procesos
3.1.4. Salidas
3.1.5. Interfaces externas
3.1.5.1. Interfaces del usuario
3.1.5.2. Interfaces del hardware
3.1.5.3. Interfaces del software
3.1.6 Requerimientos de rendimiento
3.1.7 Representación del diseño
3.1.8 Cumplimientos con estándares
3.1.9 Limitaciones del hardware
3.1.10 Atributos
3.1.10.1. Disponibilidad
3.1.10.2. Seguridad
3.1.10.3. Mantenibilidad
3.1.10.4. Transferencia / Conversión
3.1.10.5 Prevenciones
12
Entregable 3
3.1.11 Otros requerimientos

3.1.11.1. Base de datos
3.1.11.2. Operaciones
3.1.11.3. Adaptaciones
4.1.2. Reporte de validacion y verificacion

[5] Para poder realizar el plan para la verificación y verificación (v & v) se deberá seguir la
siguiente estructura
MODELO A USAR PARA EL CONTENIDO DEL V & V

1. OBJETIVO
2. ALCANCE
3. DEFINICIONES, ACRONIMOS Y ABREVIACIONES
4. ORGANIZACIÓN RESPONSABLES
5. CICLO DE VIDA DE VERIFICACION Y VALIDACION
REPORTES DE VERIFICACIÓN
REPORTE SUMARIO DE FASE V&V
Reporte #: Fase: Área: Fecha: Hora:

/ /
Descripción de las tareas realizadas:
Sumario de resultados de las tareas:
REPORTE DE ANOMALÍAS
Reporte #: Fase: Área: Fecha: Hora:

/ /
13
Entregable 3
Descripción de las tareas realizadas:
Impacto y causa
Recomendaciones
Equipo de trabajo
Nombre: Firma:
4.1.3 DOCUMENTACIÓN DE USUARIO

[6] La información específica de cada usuario debe ser incluida en la documentación del
usuario.Los usuarios del software utilizarán los documentos ya sea para aprender acerca del
software (modo de instrucciones) o para recordar acerca del software.
· Diseño del Sistema y Descripción de la Arquitectura

· Plan de Verificación y Validación
· Reportes de Verificación
· Documentación de Usuario
· Plan de Configuración
· Plan de Proyecto
4.1.4. DESCRIPCIÓN DEL DISEÑO DEL SOFTWARE (DDS)[7]
MODELO A USAR PARA EL CONTENIDO DEL DDS
1. INTRODUCION
1.1. Objetivo
14
Entregable 3
1.2. Alcance
1.3. Definiciones, acrónimos y abreviaciones
2. REFERENCIAS
3. DESCRIPCION DE DESCOMPOSICION
3.1. Descomposición de módulo
3.1.1. Descripción del módulo 1
3.1.n. Descripción del módulo n
3.2. Descomposición de procesos concurrentes
3.2.1. Descripción del proceso 1
3.2.n. Descripción del proceso n
3.3. Descomposición de datos
3.3.1. Descripción de la entidad de datos 1
3.3.n. Descripción de la entidad de datos n
4. DESCRIPCION DE DEPENDENCIA
4.1.Dependencia entre módulos
4.2.Dependencia entre procesos
4.3.Dependencia entre datos
5. DESCRIPCION DE INTERFACES
5.1. Interfaces de módulo
5.1.1. Descripción del módulo 1
5.1.n. Descripción del módulo n
5.2 Interfaces de procesos
5.2.1. Descripción del proceso 1
5.2.n. Descripción del proceso n
6. DISEÑO DETALLADO
6.1. Diseño detallado del módulo
6.1.1. Detalle del módulo 1
6.1.n. Detalle del módulo n
6.2. Diseño detallado de datos
6.2.1. Detalle de entidad de datos 1
6.2.2. Detalle de entidad de datos 2
5. Estándares y Métricas
5.1. Estándares para documentación
15
Entregable 3
Entregable Estándar
ESPECIFICACIÓN DE ANSI / IEEE – Std 830

REQUERIMIENTOS
DESCRIPCIÓN DEL ANSI / IEEE – Std 1016 “RECOMMENDED PRACTICE

DISEÑO DEL FOR SOFTWARE DESCRIPTIONS”
SOFTWARE (DDS)
DOCUMENTACIÓN DE ANSI / IEEE – Std 1036 “STANDARD FOR SOFTWARE

USUARIO USER DOCUMENTATION”.
En el Código
· Los nombres de las funciones deben de indicar su funcionalidad.
· Los comentarios dentro de un módulo deben estar separados del código, de

preferencia documentado en un informe aparte.
· Utilizar comentarios de más de una línea para realizar descripciones funcionales, y

comentarios de una línea para realizar especificaciones.
· Para asignar nombres a las variables debe de realizarse de una forma determinada:
(vNombre, vApellido, vDni).
5.1. Métrica
16
Entregable 3
La métrica para determinar la calidad de un programa será el número de defectos por

cada mil líneas de código.
La métrica de progreso del proyecto será el número de requerimientos funcionales

implementados versus faltantes.
6. Revisiones
6.1. Descripción
6.1.1. Revisión de Calidad del Producto
Objetivo:
Revisar los productos que se definieron como claves para asegurar la calidad. Detectar
desviaciones en los objetivos de calidad definidos e informar a los responsables para
que sean corregidas.
Mecanismo:
Se revisan los productos para verificar que cumplan con los estándares (sección 5) y con
los objetivos de calidad utilizando los checklists definidos para el producto.
Se debe verificar que no queden correcciones sin resolver en los informes de revisión
previos, si se encuentra alguna no resuelta, debe ser incluida en la siguiente revisión. Se
debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar
que se hayan realizado las correcciones.
Como salida se obtiene el Informe de revisión de SQA, que contiene todas las
desviaciones o defectos encontrados durante la revisión. Este informe debe ser
distribuido a los responsables del producto y se debe asegurar que ellos son conscientes
de las desviaciones o discrepancias encontradas y de las acciones correctivas que deben
realizar.
6.1.2. Revisión de Ajuste al Proceso
Objetivo:
Revisar si los productos se obtuvieron realizando las actividades que se indican en el
Modelo de Proceso.
Mecanismo:
Se revisan los productos que se definen como claves para verificar el cumplimiento de
las actividades definidas en el proceso, durante todo el ciclo de vida del software.
17
Entregable 3
Se debe recoger la información necesaria de cada producto, buscando hacia atrás los
productos previos que deberían haberse generado y son entrada para el producto objeto
de revisión, para poder establecer los criterios de revisión y evaluar si el producto
cumple con las especificaciones.
Esta información se obtiene de los siguientes documentos:

· Plan del Proyecto
· Plan de la Desarrollo
· Plan de Verificación y Validación
Se debe verificar si todos los pasos del proceso de desarrollo son seguidos
apropiadamente.
Antes de comenzar, se debe verificar en los informes de revisión previos que todas las
desviaciones fueron corregidas, si no es así, las faltantes se incluyen para ser evaluadas.
Como salida se obtiene el Informe de revisión de SQA correspondiente a la revisión de
ajuste al proceso, que contiene todas las desviaciones o defectos encontrados durante la
revisión. Este informe debe ser distribuido a los responsables de las actividades y se
debe asegurar que ellos son conscientes de las desviaciones o discrepancias encontradas
y de las acciones correctivas que deben realizar.
6.1.3. Revisión Técnica Formal
Objetivo:
Descubrir errores en la función, la lógica ó la implementación de cualquier producto del
software, verificar que satisface sus especificaciones, que se ajusta a los estándares
establecidos, señalando las posibles desviaciones detectadas.
Mecanismo:
Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes posible, los
posibles defectos o desviaciones en los productos que se van generando a lo largo del
desarrollo. Por esta característica se adopta esta práctica para productos que son de
especial importancia.
En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo.
Se debe convocar a la reunión formalmente a los involucrados, informar del material
que ellos deben preparar por adelantado, llevar una lista de preguntas y dudas que
surgen del estudio del producto a ser revisado.
Como salida se obtiene el Informe de RTF.
18
Entregable 3
6.2. Requerimientos Mínimos

- Especificación de Requerimientos (Modelo de Casos de Uso, Requerimientos
Suplementarios): El propósito de estos requerimientos son para determinar la forma de
uso de este documento e indicar los errores en la especificación de los requerimientos,
esto con el fin de poder evaluar el ERS, asegurar que estos sean los correctos y así
garantizar la calidad, es por eso que por medio del siguiente checklist validamos los
requerimientos[8].
Organización e integridad SI NO N/A Comentario
¿Están todas las referencias a otros requerimientos correctos?
¿Todos los requerimientos están escritos a un nivel consistente y

adecuado de detalle?
¿Los requerimientos proporcionan una adecuada base para el

diseño?
¿Está la prioridad de cada requerimiento incluida?
¿Están todas las interfaces de hardware, software, y comunicación

definidas?
¿Los requerimientos definidos tienen algoritmos intrínsecos?
¿La especificación incluye todo el conocimiento del cliente o las

necesidades del sistema?
Precisión
¿Algún requerimiento tiene conflicto o esta duplicado con otro

requerimiento?
¿Cada requerimiento está escrito de manera clara, concisa y sin

ambigüedades?
¿Cada requerimiento es verificable por medio de pruebas,

demostraciones, revisiones o análisis?
¿Cada requerimiento tiene un alcance para el proyecto?
19
Entregable 3
¿Cada requerimiento está libre de contenido innecesario y errores

gramaticales?
¿Hay información necesaria que haga falta en la especificación de

algún requerimiento?
¿Pueden los requerimientos ser implementados sin conocer las

restricciones?
¿Están los mensajes de error especificados de manera única y

significativa?
Atributos de Calidad
¿Los objetivos de desempeño están propiamente especificados?
¿Están todas las consideraciones de seguridad y protección

especificadas apropiadamente?
¿Hay otras metas de otros atributos de calidad que estén

explícitamente documentados y cuantificados, con sus aceptables
ventajas y desventajas?
Trazabilidad
¿Cada requerimiento es único y correctamente identificado?
¿Cada requerimiento funcional de software es trazable a un

requerimiento de alto nivel?
Temas Especiales
¿Son todos los requerimientos y sólo eso? Es decir, no diseños o

soluciones de implementación
¿Están todas las funciones de tiempo crítico identificadas, y sus

criterios de tiempo especificados?
¿Los temas de internacionalización han sido adecuadamente

tomados en cuenta?
Comentarios
20
Entregable 3
Otras Anomalías
Modelo de Diseño y Descripción de la Arquitectura:

- Capaz de evaluar el progreso, consistencia y suficiencia técnica del alcance de
diseño con los requerimientos funcionales de la ERS.
- Verificar la existencia y compatibilidad de las interfaces entre el software, el
hardware y los usuarios finales.
- Determinar un diseño de software que cumpla con los requerimientos.
- Se aplicara la revisión de Calidad de Producto tomando en cuenta la siguiente
plantilla de checklist.[9]
Checklist SI NO N/A Comentario
Estructura
¿Es el pseudocódigo consistente a nivel de detalle?
Datos
¿Todos los datos han sido propiamente definidos e inicializados?
¿Todos los datos son usados?
¿El nombre de los elementos y tipos de datos conforman el

diccionario de datos del proyecto?
Exactitud e integridad
¿Las especificaciones externas de cada módulo están completas y

comprobables?
¿Todos los métodos numéricos han analizados para la precisión?
21
Entregable 3
¿El presupuesto del diseño de alto nivel de memoria se ha ampliado

en más detalle y esta actualizado?
¿Todas las funciones están claramente específicas y son

lógicamente independientes?
¿Hay problemas de mantenimiento abordados adecuadamente?
¿Cada módulo tiene alta cohesión interna?
¿Cada módulo tiene bajo acoplamiento externo?
¿El diseño detallado es verificable?
¿Es la lógica correcta, clara y completa?
¿Todas los interfaces de usuario están totalmente diseñadas?
¿Pueden las condiciones de terminación de los ciclos ser realizadas?
¿Puede toda la lógica ser probada?
Robustez
¿Las condiciones de error son manejadas de una manera no

destructiva?
¿Pueden las medidas correctivas ser tomadas por cada módulo que
atrapa un error?
¿Las condiciones inusuales son manejadas de manera razonable y

no destructiva?
Aspectos generales
¿El diseño general implanta todos los requisitos explícitos? ¿Una

tabla de trazabilidad fue desarrollada?
¿El diseño en general cumplen todos los requisitos implícitos?
¿El diseño esta representado en una forma que es fácil de entender

por personas ajenas?
¿Esta la notación del diseño estandarizada? ¿Es consistente?
22
Entregable 3
Aspectos generales
¿El diseño fue creado con patrones y procedimiento reconocibles de

la arquitectura?
¿El diseño se esfuerza por incorporar componentes reutilizables?
¿El diseño es modular?
¿El diseño tiene definido tanto procedimiento y abstracción de los

datos que pueden ser reutilizados?
¿La arquitectura de software final ha sido particionada para facilitar

su implementación? ¿Y el mantenimiento?
¿Los conceptos de ocultamiento de la información y la

independencia funcional han sido seguidos a través del diseño?
¿La especificación de diseño ha sido desarrollada para el software?
Interfaz de usuario
Estructura
¿Es el pseudocódigo consistente a nivel de detalle?
Datos
¿Todos los datos han sido propiamente definidos e inicializados?
¿Todos los datos son usados?
¿El nombre de los elementos y tipos de datos conforman el

diccionario de datos del proyecto?
¿Son usados por default y están correctos?
Exactitud e integridad
¿Las especificaciones externas de cada módulo están completas y

comprobables?
23
Entregable 3
¿Todos los métodos numéricos han analizados para la precisión?
Diseño de componentes
¿Cada algoritmo ha sido probado para descubrir errores? ¿Cada

algoritmo es correcto?
¿Es el diseño del algoritmo consistente con las estructura de datos

que el componente manipula?
¿Hay alternativas algorítmicas de diseño que se han considerado?

En caso afirmativo, ¿por qué fue elegido este diseño?
¿La complejidad de cada algoritmo fue calculada?
Comentarios
Otras Anomalías
Recomendaciones
Firma de Aceptación
Nombre
6.3. Agenda
En esta sección se detallan todas las revisiones de calidad que se realizarán durante todo
el proyecto organizadas por fase e iteración.
6.3.1. Fase I - Inicial
6.3.1.1. Iteración I
Entregable Realizad Revisión Tipo de Revisión

o
24
Entregable 3
Visión de Fase I, Semana 1 Revisar el ajuste al

Conjunto Semana proceso
1
6.3.1.2. Iteración II
Entregabl Realizado Revisión Tipo de Revisión

e
Visión de Fase II, Semana 2 Revisar el ajuste al

Conjunto Semana 2 proceso
6.3.1.3. Iteración III
Entregable Realizado Revisión Tipo de Revisión
Objetivos de Fase III, Semana Semana 3 Revision Tecnica Formal

Calidad 3
6.3.2. Fase II – Elaboracion

6.3.2.1. Iteracion I
Entregabl Realizado Revisión Tipo de

e Revisión
Documenta Fase I, Semana 4 Revisar el contenido de

ción semana 4 la documentación
25
Entregable 3
minima
requerida
6.3.2.2. Iteracion II

e Revisión
Especificac Fase II, Semana 5 Evaluacion de la calidad

ión de semana 5 de los requerimiento del
Requerimie producto software
ntos
6.3.2.3. Iteracion III

e Revisión
Estándares Fase III, Semana 6 Revisar los estándares

para semana 6 para la correcta
Documenta documentacion
ción
6.3.3. Fase III – Construccion

e Revisión
26
Entregable 3


e Revisión

Objetivos de Fase III, Semana 3 Semana 3 Revision Tecnica

Calidad Formal
6.3.1.4. Iteración IV

e Revisión
Documentación Fase IV, Semana 4 Revisar el contenido de
27
Entregable 3
minima requerida semana 4 la documentación
6.3.1.4. Iteración V

e Revisión
Especificación de Fase V, Semana 5 Evaluacion de la calidad

Requerimientos semana 5 de los requerimiento del
producto software
6.3.3. Fase IV – Transicion

e Revisión


e Revisión
28
Entregable 3
Objetivos de Fase III, Semana 3 Semana 3 Revision Tecnica

Calidad Formal
6.3.1.4. Iteración IV
Entregabl Realizado Revisión Tipo de Revisión

e
Documentación Fase IV, Semana 4 Revisar el contenido de

minima requerida semana 4 la documentación
6.3.1.4. Iteración V

e Revisión
Especificación de Fase V, Semana 5 Evaluacion de la calidad

Requerimientos semana 5 de los requerimiento del
producto software
29
Entregable 3
7. Verificación
El proceso de V&V determina si los productos de una actividad de desarrollo o de mantenimiento se
encuentran conforme a las necesidades de la propia actividad y a la de sus antecesoras, y si el producto
software final satisface su propósito de uso y las necesidades del usuario. Por ello, se dice que la
verificación busca garantizar que los productos sean construidos de forma correcta, en el sentido de que
los productos de una actividad cumplan los requerimientos impuestos en actividades previas.
Por otra parte, la validación también busca garantizar que los productos sean construidos de forma
correcta, pero atendiendo a que respeten sus usos específicos. Ambos proceso comienzan en fases
tempranas del desarrollo o del mantenimiento, ofreciendo una valoración de cada producto relativo,
tanto a su inmediato predecesor como al sistema de requerimientos que debe satisfacer.
Es por ello que se realizaran las siguientes actividades sobre el sistema (software) Trámite de
Mercancías (TM):
Actividades de Verificación
Revisión del documento de Especificación de Requerimientos (ESRE)
Método Inspección.
Entradas Documento de Especificación de

Requerimientos (ESRE).
Salidas Reporte de anomalías. Reporte de

acciones correctivas.
Criterios de Salida Se especifican todas las funcionalidades

del sistema de manera correcta y
completa.
Momento de Realización Al momento en que se libera una nueva

versión del ESRE.
Recursos 3 inspectores, 1 moderador, 1 registrador,

el autor. PC con Microsoft Word y Visio
para registrar la información necesaria.
Supuestos para esta actividad El ESRE debe estar en una versión lista
para su liberación, es decir que debe
cubrir todas las funcionalidades del
30
Entregable 3
sistema, al momento de ser revisado.
Revisión del documento de Especificación de Diseño (ESDI)
Método Inspección.

Requerimientos (ESRE) y documento de
Especificación de Diseño (ESDI).

Criterios de Salida No se encuentran errores críticos ni

severos en el diseño.
Momento de Realización Al momento en que se libera una nueva

versión del ESDI.
Recursos 3 inspectores, 1 moderador, 1 registrador,

el autor. PC con Microsoft Word y Visio
Supuestos para esta actividad El ESDI debe estar en una versión lista
para su liberación, debe cubrir todas las
funcionalidades del sistema, al momento
de ser revisado.
Revisión del código fuente
Método Revisiones entre pares.

Especificación de Diseño (ESDI),
documento de estándares de codificación
y código fuente.

31
Entregable 3
Revisión del código fuente
Criterios de Salida Se han cerrado todos los defectos severos

y críticos.
Momento de Realización Se debe realizar cada vez que se codifica

por completo una funcionalidad del
sistema durante toda la etapa de
codificación.
Recursos Desarrolladores que no hayan generado el

código fuente que se revisa. PC con
ambiente de desarrollo y Microsoft Word
y Visio para registrar la información
necesaria.
Supuestos para esta actividad Quien revisa código fuente de otro

programador no podrá modificar el
mismo; deberá limitarse a emitir un
reporte con las observaciones pertinentes
para que el desarrollador que codifico
dicho modulo realice las correcciones
correspondientes.
Revisión de la especificación de los casos de prueba
Método Walkthrough

Especificación de Diseño (ESDI),
documento de estándares para casos de
prueba y casos de prueba.

32
Entregable 3
Criterios de Salida Cada funcionalidad del sistema tiene su

correspondiente caso de uso definido
según los estándares acordados. Cada caso
de prueba es trazable con el
correspondiente requerimiento (o grupo
de requerimientos) que cubre.
Momento de Realización Cada vez que se libera una nueva versión

del documento con las especificación de
los casos de prueba del sistema.
Recursos 4 pares desarrolladores que revisen el

documento. PC con Microsoft Word y Visio
Supuestos para esta actividad Los casos de prueba deben ser revisados
por primera vez una liberada su primera
versión; cada vez que el documento es
modificado y cada vez que el ESRE o el
ESDI son modificados para garantizar que
se mantiene coherencia y trazabilidad.
Test funcional
Método Testing de caja negra

Especificación de Diseño (ESDI), casos de
prueba y archivos ejecutables y de
almacenamiento de datos. Datos de
prueba.
Salidas Reporte de fallas detectadas. Reporte de

acciones correctivas. Reporte de
33
Entregable 3
sugerencias.
Criterios de Salida Se cubren todas las funcionalidades del

sistema y se cumplen todos los requisitos
de calidad para el sistema para las
funcionalidades implementadas en la
versión de trabajo.

del sistema.
Recursos 3 testers. PC con ambiente de producción,

Microsoft Word y Visio para registrar la
información necesaria.
Supuestos para esta actividad Cada versión que se testea no

necesariamente debe tener implementado
el sistema en su totalidad. Es posible
realizar testing sobre versiones parciales
del software.
Test de performance
Método Testing de desempeño y análisis de

consumo de recursos

prueba y escenarios de calidad para
performance.

34
Entregable 3
sugerencias.
Criterios de Salida Se cumplen todos los requisitos de calidad

referidos a la performance del sistema.

del sistema.
Recursos 2 testers y el gerente de proyecto. PC con

ambiente de producción, Microsoft Word
necesaria.

del software.
Test de carga (volumen de datos y stress)
Método Testing de manejo de grandes volúmenes

de datos y uso concurrente de múltiples
usuarios.

prueba y escenarios de calidad referidos
al manejo de volúmenes de datos y uso
concurrente.

35
Entregable 3
sugerencias.
Criterios de Salida Se cumplen todos los requisitos de calidad

referidos a al manejo de grandes
volúmenes de datos y acceso concurrente.

del sistema.
Recursos 2 testers y el gerente de proyecto. PC con

ambiente de producción, Microsoft Word
necesaria.

del software.
Actividades de Validación
Prueba de facilidad de uso
Método Eyetracking, Reunión con usuarios
Entradas · Producto completo o prototipo

terminado.
● Ambiente donde se va a utilizar el
software.
Salidas ● Reporte analizado sobre datos

recabados de las sesiones de
eyetracking.
● Datos recabados en reuniones con
usuarios.
36
Entregable 3
Criterios de Salida 90% de las pruebas de aceptación

exitosas.
Momento de Realización Cuando se tiene el producto terminado o

un prototipo de interfaz usable que
replique exactamente la experiencia del
usuario final.
Recursos ● Más de 30 usuarios finales

● El producto completo o prototipo
● Una persona capacitada en
técnicas de eyetracking.
● Tres personas para llevar a cabo
una o más reuniones.
Supuestos para esta actividad Los usuarios finales utilizados para esta
actividad, son una muestra representativa
de la totalidad de usuarios finales.
Prueba de seguridad
Método Prueba de stress
Entradas · Producto o módulo completo.
Salidas ● Reporte sobre fallas y agujeros de

seguridad existentes y/o
potenciales.
Criterios de Salida 80% de las pruebas de seguridad exitosas.
Momento de Realización Cuando se tiene el producto completo o el

módulo que necesita tener una seguridad
más ajustada que el resto del sistema.
Recursos ● Una o más personas

especializadas en seguridad de
software.
37
Entregable 3
Supuestos para esta actividad El software está instalado en el ambiente

final o en una réplica exacta del mismo.
Prueba de Instalación
Método Simulación
Entradas · Producto completo o prototipo

terminado.
● Ambiente donde se va a utilizar el
software.
Salidas Reporte sobre anomalías.
Criterios de Salida Se instaló el producto completo y se

realizó una prueba de caja negra sin fallas
severas.
Momento de Realización Cuando se tiene el producto terminado.
Recursos Una persona que instale el software en el

ambiente final.
Supuestos para esta actividad
Prueba de aceptación del producto
Método Entrevista con el cliente; usuario final del

sistema. Alfa test.
Entradas ESRE, sistema funcionando, datos y

ambiente de prueba.
Salidas Reporte de fallas detectadas, sugerencias

del usuario.
Criterios de Salida 96% de las pruebas exitosas.
38
Entregable 3
Momento de Realización Una vez terminada la construcción del

sistema; previo a su implantación.
Recursos 5 usuarios finales, gerente del proyecto de

la contraparte, testers.
Supuestos para esta actividad Para comenzar la prueba de aceptación

del cliente el sistema debe estar
construido en su totalidad y debe estar
montado en un ambiente similar al de
producción.
8. Reporte de Problemas y Acciones Correctivas
En esta sección se describen las prácticas y procedimientos que se van a utilizar para la
notificación, seguimiento y resolución de problemas de software, así como las
responsabilidades organizativas.
El propósito de un sistema de Gestión de Problemas y Acciones Correlativas es:
· Asegurar que todos los problemas de documentan, se corrigen y no caen en el olvido.

· Asegurar que se evalúa la validez de los informes de problemas.
· Retroalimentar al desarrollador y el usuario sobre el estado de los problemas.
· Proporcionar datos para medir y predecir la calidad y fiabilidad del software.
Cualquier problema en el producto de software que sea encontrado durante el ciclo de vida de
desarrollo de software, debe ser reportado a través de un reporte en el cual se detalla la fecha de
cuando fue encontrado el problema, una identificación preliminar del mismo, descripción, etc.,
39
Entregable 3
este reporte debe ser firmado por los que identificaron el problema, debe ser entregado a la
organización responsable de los problemas.
La organización responsable de los problemas del software, es la organización del SQA,

comandada por la organización del consultor, estas organizaciones son las encargadas de
determinar el cronograma, lugar y temario, para llevar a fijar la acción correctiva del problema.
Reporte Final de Problemas Pag: ...
# de Reporte Fecha: .../.../...
Lugar
a) Identificación del problema:
b) Descripción:
c) El evento ejecutado cuando se presentó el problema

es:
d) Posibles orígenes del problema:
Equipo de Trabajo: Firma
Nombre:
40

Diego Colque Ramos - Christian Juárez Medina - Diego Sánchez Chacón - Jonathan Ventura Apaza

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diego Colque Ramos - Christian Juárez Medina - Diego Sánchez Chacón - Jonathan Ventura Apaza

Cargado por

Copyright:

Formatos disponibles

Diego Colque Ramos - Christian Juárez Medina - Diego Sánchez Chacón - Jonathan Ventura Apaza

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Plan de Aseguramiento de Calidad del Software de un Sistema de Gestión de Seguridad

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Fecha Versión Descripción Autor

25/SET/2014 1.0 ENTREGABLE 1 Diego Colque Ramos

23/OCT/2014 1.0 ENTREGABLE 2 Diego Colque Ramos

20/NOV/2014 1.0 ENTREGABLE 3 Diego Colque Ramos

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Plan de Aseguramiento de Calidad del Software

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha:

[1] ISO 9126 - SQA Software Quality Assurance

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

1.5. Visión de Conjunto

2. Objetivos de Calidad [2]

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Área Objetivos Rol Persona

Requerimientos y -Verificar que el Administrador y - Diego Colque Ramos

Diseño -Verificar que el Diseñador - Christian Juarez Medina

Implementación y -Realizar verificación Responsable de - Diego Sánchez Chacón

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Gestión de la -Realizar Plan de Responsable de - Jonathan Ventura

Actividad Entregable Descripción

Realizar el Plan de SQA Plan de SQA Permite documentar las

Identificar las propiedades Propiedades de Calidad Define las métricas para

Evaluar la calidad de los Informe de revisión de Mide el nivel de calidad del

Revisar el ajuste al proceso Informe de revisión de Hace las revisiones

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

pasos anteriores, para

Realizar Revisión Técnica Informe de Revisión Se revisa si el sistema en

Evaluar y ajustar el Plan de Documento de Permite ver, revisar y/o

Revisar la entrega semanal Entrega semanal de SQA Permite realizar

Reuniones de Apoyo a la No Aplica

Gestión de Seguridad Versión 1.0

Plan de Aseguramiento de Calidad del Software Fecha: 20/NOV/2014

Producto Rol responsable Responsable

Especificación de requerimientos Analista Diego Colque Ramos

Alcance del sistema Responsable del SCM Jonathan Ventura Apaza

Descripción de la Arquitectura Diseñador Christian Juarez Medina

Interfase de Usuario Diseñador Christian Juarez Medina

Estándar de Implementación Diseñador Christian Juarez Medina

Estándar de Documentación Técnica Analista Diego Colque Ramos

Plan de Verificación y Validación Responsable de Diego Sanchez Chacon

Estándar de Documentación de Usuario Analista Diego Colque Ramos

Materiales para soporte al Usuario Analista Diego Colque Ramos

Plan de Proyecto Administrador Diego Colque Ramos

Documento de Riesgos Analista Diego Colque Ramos

Plan de Gestión de Configuración Responsable de SCM Jonathan Ventura Apaza