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: 02/DIC/2014

Entregable 4

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

Versión 1.0

1
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: 02/DIC/2014

Entregable 4

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

Christian Juarez Medina
Diego Sánchez Chacón
Jonathan Ventura Apaza

20/NOV/2014 1.0 ENTREGABLE 3 Diego Colque Ramos

Christian Juarez Medina
Diego Sánchez Chacón
Jonathan Ventura Apaza

02/DIC/2014 1.0 ENTREGABLE 4 Diego Colque Ramos

Christian Juarez Medina
Diego Sánchez Chacón
Jonathan Ventura Apaza

2
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: 02/DIC/2014

Entregable 4

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
[Link]. Iteración I 23
[Link]. Iteración II 23
6.3.2. Fase II – Elaboración 24

3
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: 02/DIC/2014

Entregable 4

[Link]. Iteración I 24
[Link]. Iteración II 24
6.3.3. Fase III – Construcción 24
[Link]. Iteración I 24
[Link]. Iteración II 25
6.3.4. Fase IV – Transición 25
[Link]. Iteración I 27
[Link]. Iteración II 27
7. Verificación 28
8. Reporte de Problemas y Acciones Correctivas 37
9. Herramientas, Técnicas y Metodologías 38
10. Gestión de Configuración 40
10.1. Métodos para la Gestión de Configuración 41
10.2. Actividades para Asegurar la Calidad 41
11. Gestión de Riesgos 42
11.1. Métodos para la Gestión de Riesgos 42
11.2. Actividades para asegurar la Calidad. 43

4
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: 02/DIC/2014

Entregable 4

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
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: 02/DIC/2014

Entregable 4

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

Gestión de Seguridad Versión 1.0

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 [Link]
[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
[Link]

6
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: 02/DIC/2014

Entregable 4

5,%20Rev%202%20Verificaci%C3%B3n%20y%20Validaci%C3%B3n%20de%20Softwa
[Link]
[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
[Link]

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
software. (3.1), la lista de tareas cubiertas por este plan (3.2) y las responsabilidades
por cada tarea (3.3).

7
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: 02/DIC/2014

Entregable 4

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
desarrollado Validación
-Realizar Plan de
Verificación y
validación

8
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: 02/DIC/2014

Entregable 4

-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
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

9
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: 02/DIC/2014

Entregable 4

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.

Producto Rol responsable Responsable

Especificación de requerimientos Analista Diego Colque Ramos

Alcance del sistema Responsable del SCM Jonathan Ventura Apaza

10
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: 02/DIC/2014

Entregable 4

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
[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

11
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: 02/DIC/2014

Entregable 4

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
[Link]. Interfaces del usuario
[Link]. Interfaces del hardware
[Link]. 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
[Link]. Disponibilidad
[Link]. Seguridad
[Link]. Mantenibilidad
[Link]. Transferencia / Conversión
[Link] Prevenciones
3.1.11 Otros requerimientos
[Link]. Base de datos
[Link]. Operaciones
[Link]. Adaptaciones

4.1.2. Reporte de validacion y verificacion

12
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: 02/DIC/2014

Entregable 4

[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 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

13
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: 02/DIC/2014

Entregable 4

Nombre:

4.1.3 DOCUMENTACIÓN DE USUARIO

[6] La información específica de cada usuario debe ser incluida en la documentación del
[Link] 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
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

14
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: 02/DIC/2014

Entregable 4

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.2. 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.2. Descripción del módulo n
5.2 Interfaces de procesos
5.2.1. Descripción del proceso 1
5.2.2. 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

Entregable Estándar

ESPECIFICACIÓN DE ANSI / IEEE – Std 830

REQUERIMIENTOS

15
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: 02/DIC/2014

Entregable 4

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”.

Para el código fuente del sistema se considera:

· 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

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

16
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: 02/DIC/2014

Entregable 4

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.
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

17
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: 02/DIC/2014

Entregable 4

· 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.

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í

18
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: 02/DIC/2014

Entregable 4

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? x

¿Todos los requerimientos están escritos a un nivel consistente y x
adecuado de detalle?

¿Los requerimientos proporcionan una adecuada base para el x

diseño?

¿Está la prioridad de cada requerimiento incluida? x Se incluirá

más adelante

¿Están todas las interfaces de hardware, software, y comunicación x

definidas?

¿La especificación incluye todo el conocimiento del cliente o las x

necesidades del sistema?

Precisión

¿Algún requerimiento tiene conflicto o esta duplicado con otro x

requerimiento?

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

ambigüedades?

¿Cada requerimiento es verificable por medio de pruebas, x

demostraciones, revisiones o análisis?

¿Cada requerimiento tiene un alcance para el proyecto? x

¿Cada requerimiento está libre de contenido innecesario y errores x
gramaticales?

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

algún requerimiento?

¿Pueden los requerimientos ser implementados sin conocer las x

restricciones?

19
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: 02/DIC/2014

Entregable 4

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

significativa?

Atributos de Calidad

¿Los objetivos de desempeño están propiamente especificados? x

¿Están todas las consideraciones de seguridad y protección x
especificadas apropiadamente?

¿Hay otras metas de otros atributos de calidad que estén x

explícitamente documentados y cuantificados, con sus aceptables
ventajas y desventajas?

Trazabilidad

¿Cada requerimiento es único y correctamente identificado? x

¿Cada requerimiento funcional de software es trazable a un x
requerimiento de alto nivel?

Temas Especiales

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

criterios de tiempo especificados?

¿Los temas de internacionalización han sido adecuadamente x

tomados en cuenta?

Comentarios

La documentación de los requerimientos seguirá el

Formato de Especificación de Requerimientos (ERS)
ANSI / IEEE – Std 830

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.

20
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: 02/DIC/2014

Entregable 4

- 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 aplicará la revisión de Calidad de Producto tomando en cuenta la siguiente
plantilla de checklist.[9]

Estructura SI NO N/A Comentario

¿Es el pseudocódigo consistente a nivel de detalle? x

Datos

¿Todos los datos han sido propiamente definidos e inicializados? x

¿Todos los datos son usados? x
¿El nombre de los elementos y tipos de datos conforman el x
diccionario de datos del proyecto?

Exactitud e integridad

¿Las especificaciones externas de cada módulo están completas y x

comprobables?

¿Todos los métodos numéricos han sido analizados para la x

precisión?

¿El presupuesto del diseño de alto nivel de memoria se ha ampliado x

en más detalle y esta actualizado?

¿Todas las funciones están claramente específicas y son x

lógicamente independientes?

¿Hay problemas de mantenimiento abordados adecuadamente? x

¿El diseño detallado es verificable? x
¿Es la lógica correcta, clara y completa? x
¿Todas los interfaces de usuario están totalmente diseñadas? x

21
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: 02/DIC/2014

Entregable 4

¿Puede toda la lógica ser probada? x

Robustez

¿Las condiciones de error son manejadas de una manera no x

destructiva?

¿Pueden las medidas correctivas son tomadas por cada módulo que x
atrapa un error?

¿Las condiciones inusuales son manejadas de manera razonable y x

no destructiva?

Aspectos generales

¿El diseño en general cumplen todos los requisitos implícitos? x

¿El diseño esta representado en una forma que es fácil de entender x
por personas ajenas?

¿Esta la notación del diseño estandarizada? ¿Es consistente? x

Aspectos generales

¿El diseño fue creado con patrones y procedimiento reconocibles de x

la arquitectura?

¿El diseño se esfuerza por incorporar componentes reutilizables? x

¿El diseño es modular? x
¿El diseño tiene definido tanto procedimiento y abstracción de los x
datos que pueden ser reutilizados?

¿La arquitectura de software final ha sido particionada para facilitar x

su implementación? ¿Y el mantenimiento?

¿Los conceptos de ocultamiento de la información y la x

independencia funcional han sido seguidos a través del diseño?

¿La especificación de diseño ha sido desarrollada para el software? x

Comentarios

22
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: 02/DIC/2014

Entregable 4

Otras Anomalías

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
[Link]. Iteración I

Entregable Realizad Revisión Tipo de Revisión

o

Visión de Fase I, Semana 1 Revisar el ajuste al

Conjunto Semana proceso
1

[Link]. 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

[Link]. Iteración III

Entregable Realizado Revisión Tipo de Revisión

23
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: 02/DIC/2014

Entregable 4

Objetivos de Fase III, Semana Semana 3 Revision Tecnica Formal

Calidad 3

6.3.2. Fase II – Elaboracion

[Link]. 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
minima
requerida

[Link]. Iteracion II

Entregabl Realizado Revisión Tipo de

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

[Link]. Iteracion III

Entregabl Realizado Revisión Tipo de

e Revisión

24
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: 02/DIC/2014

Entregable 4

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

Entregabl Realizado Revisión Tipo de

e Revisión

Visión de Fase I, Semana 1 Revisar el ajuste al

Conjunto Semana 1 proceso

[Link]. Iteración II

Entregabl Realizado Revisión Tipo de

e Revisión

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

Conjunto Semana 2 proceso

[Link]. Iteración III

Entregable Realizado Revisión Tipo de Revisión

25
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: 02/DIC/2014

Entregable 4

Objetivos de Fase III, Semana 3 Semana 3 Revision Tecnica

Calidad Formal

[Link]. Iteración IV

Entregabl Realizado Revisión Tipo de

e Revisión

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

minima requerida semana 4 la documentación

[Link]. Iteración V

Entregabl Realizado Revisión Tipo de

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

Entregabl Realizado Revisión Tipo de

e Revisión

26
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: 02/DIC/2014

Entregable 4

Visión de Fase I, Semana 1 Revisar el ajuste al

Conjunto Semana 1 proceso

[Link]. Iteración II

Entregabl Realizado Revisión Tipo de

e Revisión

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

Conjunto Semana 2 proceso

[Link]. Iteración III

Entregable Realizado Revisión Tipo de Revisión

Objetivos de Fase III, Semana 3 Semana 3 Revision Tecnica

Calidad Formal

[Link]. Iteración IV

Entregabl Realizado Revisión Tipo de Revisión

e

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

27
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: 02/DIC/2014

Entregable 4

minima requerida semana 4 la documentación

[Link]. Iteración V

Entregabl Realizado Revisión Tipo de

e Revisión

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

Requerimientos semana 5 de los requerimiento del
producto software

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

28
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: 02/DIC/2014

Entregable 4

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
sistema, al momento de ser revisado.

Revisión del documento de Especificación de

Diseño (ESDI)

Método Inspección.

Entradas Documento de Especificación de

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

Salidas Reporte de anomalías. Reporte de

acciones correctivas.

Criterios de Salida No se encuentran errores críticos ni

29
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: 02/DIC/2014

Entregable 4

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
para registrar la información necesaria.

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.

Entradas Documento de Especificación de

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

Salidas Reporte de anomalías. Reporte de

acciones correctivas.

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

30
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: 02/DIC/2014

Entregable 4

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

Entradas Documento de Especificación de

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

Salidas Reporte de anomalías. Reporte de

acciones correctivas.

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.

31
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: 02/DIC/2014

Entregable 4

Recursos 4 pares desarrolladores que revisen el

documento. PC con Microsoft Word y Visio
para registrar la información necesaria.

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

Entradas Documento de Especificación de

Requerimientos (ESRE) y documento de
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
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.

Momento de Realización Cada vez que se libera una nueva versión

del sistema.

32
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: 02/DIC/2014

Entregable 4

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

Entradas Documento de Especificación de

Requerimientos (ESRE) y documento de
Especificación de Diseño (ESDI), casos de
prueba y archivos ejecutables y de
almacenamiento de datos. Datos de
prueba y escenarios de calidad para
performance.

Salidas Reporte de fallas detectadas. Reporte de

acciones correctivas. Reporte de
sugerencias.

Criterios de Salida Se cumplen todos los requisitos de calidad

referidos a la performance del sistema.

Momento de Realización Cada vez que se libera una nueva versión

del sistema.

Recursos 2 testers y el gerente de proyecto. PC con

ambiente de producción, Microsoft Word

33
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: 02/DIC/2014

Entregable 4

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 carga (volumen de datos y stress)

Método Testing de manejo de grandes volúmenes

de datos y uso concurrente de múltiples
usuarios.

Entradas Documento de Especificación de

Requerimientos (ESRE) y documento de
Especificación de Diseño (ESDI), casos de
prueba y archivos ejecutables y de
almacenamiento de datos. Datos de
prueba y escenarios de calidad referidos
al manejo de volúmenes de datos y uso
concurrente.

Salidas Reporte de fallas detectadas. Reporte de

acciones correctivas. Reporte de
sugerencias.

Criterios de Salida Se cumplen todos los requisitos de calidad

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

Momento de Realización Cada vez que se libera una nueva versión

del sistema.

34
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: 02/DIC/2014

Entregable 4

Recursos 2 testers y el gerente de proyecto. 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.

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.

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.

35
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: 02/DIC/2014

Entregable 4

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.

Supuestos para esta actividad El software está instalado en el ambiente

final o en una réplica exacta del mismo.

36
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: 02/DIC/2014

Entregable 4

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.

Momento de Realización Una vez terminada la construcción del

sistema; previo a su implantación.

37
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: 02/DIC/2014

Entregable 4

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.,
este reporte debe ser firmado por los que identificaron el problema, debe ser entregado a la
organización responsable de los problemas.

38
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: 02/DIC/2014

Entregable 4

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.

9. Herramientas, Técnicas y Metodologías

Herramientas
Algunas de las herramientas son:

· Utilidades del sistema operativo WINDOWS 7 y 8.

· Documentación de ayuda.
· Microsoft Project
· DIA
· Microsoft Quality Testing Framework

· Utilidades del sistema operativo WINDOWS 7 y 8

Se utiliza como plataforma para poder ejecutar el programa y asi ver como es que
funciona el sistema.

· Documentación de ayuda.
Documentos digitales utilizados para una mejor compresión de los temas a desarrollar a
demás de como optimizar nuestras pruebas de test.

· Microsoft Project (o MSP) es un software de administración de proyectos diseñado,

desarrollado y comercializado por Microsoft para asistir a administradores de proyectos
en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso,
administrar presupuesto y analizar cargas de trabajo.

· DIA
Dia está diseñado como un sustituto de la aplicación comercial Visio de Microsoft. Se
puede utilizar para dibujar diferentes tipos de diagramas. Actualmente se incluyen
diagramas entidad-relación, diagramas UML, diagramas de flujo, diagramas de redes,
diagramas de circuitos eléctricos, etc. Nuevas formas pueden ser fácilmente agregadas,
dibujándolas con un subconjunto de SVG e incluyéndolas en un archivo XML.

39
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: 02/DIC/2014

Entregable 4

· Microsoft Quality Testing Framework

Se utilizará el marco de trabajo de Microsoft para la implementación de casos de prueba,
con el objetivo de incrementar la integración de las pruebas con Visual Studio 2012, y así
asegurar la calidad de la información generada por la herramienta de análisis de código y
cubrimiento de pruebas de Visual Studio 2012.
Técnicas
· La técnica Arrange-Act-Assert para la definición de casos de prueba (Jeff Grigg, 2009)
Todas las pruebas se deben implementar y diseñar utilizando el patrón Arrange-Act-
Assert para asegurar la legibilidad del diseño e implementación de los casos de prueba,
donde, en la sección Arrange se define el estado previo a la ejecución de la prueba, en la
sección Act se ejecuta el objeto bajo prueba, y finalmente en la sección Assert se verifica
que estado final, resultante de ejecutar el objeto bajo prueba, sea el esperado.

· Unit Test
Un unit test es un método que prueba una unidad de código. Al hablar de una unidad de
código nos referimos a un requerimiento. Prueba solamente pequeñas cantidades de
código: Solamente prueba el código del requerimiento específico.

Metodología
· Pruebas Iterativas basadas en el uso (Usage-based testing) (Chan, 2006)
Se debe analizar los perfiles operacionales de la aplicación, para generar pruebas
priorizadas acorde a la probabilidad de uso (en cualquier día) de cada funcionalidad de la
aplicación, dentro de los límites de tiempo asignados para el desarrollo de pruebas.
Conforme se implementen los requerimientos del sistema, se desarrollan los casos de
prueba de dado requerimiento. El objetivo de usar esta metodología es generar el número
óptimo de pruebas para validar la funcionalidad crítica del sistema, con el tiempo
disponible para pruebas.

10. Gestión de Configuración

El objetivo del SQA en esta área es asegurar que se realizan las actividades de gestión
de configuración establecidas en el Plan de Configuración y que se realizan tal como
están establecidas en el proceso.

40
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: 02/DIC/2014

Entregable 4

● Asegurar que se generó la Línea Base del proyecto en el momento

establecido en el modelo de proceso.
● Asegurar que la Línea Base del proyecto generada es correcta.
● Se verifica periódicamente que el Responsable de SCM mantiene
apropiadamente el control de la línea base, así como el registro completo de
cambios para requerimientos, diseño, código, verificación y documentación.
● Se monitorean los procedimientos del Comité de Control de Cambios para
verificar que son efectivamente realizados como se especificaron en el Plan
de configuración.

10.1. Métodos para la Gestión de Configuración

● Se Mantendrá un historial de las versiones
● Herramientas: proceso de check-in/check-out
● Se almacenaran los archivos generados en un repositorio; con acceso solo al personal
involucrado en el proyecto y que tenga necesidad de acceder a los archivos.
● Ante cada modificación importante se guardara nuevas versiones
● También se tendrá un registro de entregas
● Versiones de los artefactos usadas (+ código fuente y artefactos asociados).
● Bibliotecas y artefactos de terceros reutilizados.
● Programa de instalación y archivos de datos.
● Plataforma usada para la construcción y la entrega. Compiladores y otras
herramientas de construcción usadas.

10.2. Actividades para Asegurar la Calidad

El objetivo del SQA en esta área es asegurar que se realizan las actividades de gestión de
configuración establecidas en el Plan de Configuración y que se realizan tal como están.
Se pueden definir las siguientes actividades mínimas que se deberían realizar:

Actividad Como se Realizara

Asegurar que se generó la Línea Base del Se hará mediante una revisión de este
proyecto en el momento establecido en el documento comparando con la fecha

41
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: 02/DIC/2014

Entregable 4

modelo de proceso. establecida en la agenda de revisiones

Se confrontara las actividades a realizar

Asegurar que la Línea Base del proyecto durante el desarrollo con el plazo dado para
generada es correcta. la realización del proyecto.
Verificar que los procesos de desarrollo
más críticos tengan un plazo adecuado para
su desarrollo

Se verifica periódicamente que el El responsable de SCM deberá entregar un

Responsable de SCM mantiene informe del control que realiza a la línea
apropiadamente el control de la línea base, base del proyecto
así como el registro completo de cambios
para requerimientos, diseño, código,
verificación y documentación.

Se monitorean los procedimientos del Esto será realizado por el encargado de

Comité de Control de Cambios para verificar gestión de riesgos
que son efectivamente realizados como se
especificaron en el Plan de configuración.

11. Gestión de Riesgos

Los riesgos que pueden afectar el plan de calidad en sí, ya que cualquier cambio en los
requerimientos o en el alcance del proyecto generaría un cambio en las pruebas y
actividades críticas planteadas en los puntos anteriores.

11.1 Métodos para la Gestión de Riesgos

1.- Identificación del riesgo: en el que debemos registrar el riesgo y analizar globalmente
su consecuencia respecto al plan general. Es importante fijarse aquí la relevancia que
cobra la planificación que hemos venido haciendo ya que somos capaces de estimar el
impacto en el conjunto del proyecto, de una forma eficaz y eficiente.

42
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: 02/DIC/2014

Entregable 4

2.- Analizar el riesgo: para conocer su naturaleza, causa y consecuencias como paso
previo a ejercer un plan de acción sobre el mismo.
3.- Plan de actuación: preparar las acciones de prevención y contingencia, señalar un
responsable con medios para ejercer las acciones pertinentes sobre el mismo, fijar
calendarios y mantener informados a los afectados.
4.- Seguimiento y control: revisar el estado del mismo, los cambios necesarios y la
efectividad del plan.

No olvidemos, aunque ya lo veremos en su momento, que esta circunstancia puede

provocar un cambio en el proyecto y habrá que hacer una gestión del cambio, ya que
probablemente impacte en costes, plazos y/o resultados.

11.2. Actividades para asegurar la Calidad.

Cualquier esfuerzo que emprendan las entidades en torno a la valoración de riesgo llega a
ser en vano, si no culmina en un adecuado manejo y control de los mismos

Se pueden tener en cuenta alguna de las siguientes opciones, las cuales pueden
considerarse cada una de ellas independientemente, interrelacionadas o en conjunto

· Evitar riesgos: Se logra cuando al interior de los procesos se generan cambios

sustanciales por mejoramiento, rediseño o eliminación, resultado de unos adecuados
controles y acciones emprendidas Un ejemplo de esto puede ser el control de calidad,
manejo de insumos, mantenimientos preventivo de los equipos, desarrollo tecnológico,
etc.
· Reducir el Riesgo: Si el riesgo no puede ser evitado porque crea grandes dificultades
operacionales el siguiente paso es reducirlo al más bajo nivel posible. La reducción del
riesgo es probablemente el método más sencillo y económico para superar debilidades
antes de aplicar medidas más costosas y difíciles
· Dispersar y atomizar el riesgo: Se logra mediante la distribución o localización del
riesgo en diversos lugares, Es así como por ejemplo, la información de gran importancia
se puede duplicar y almacenar en un lugar distante y de ubicación segura, en vez de
dejarla concentrada en un solo lugar.
· Transferir el riesgo: Hace referencia a buscar respaldo y compartir con otro parte del
riesgo como por ejemplo tomar pólizas de seguros, esta técnica es usada para eliminar el

43
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: 02/DIC/2014

Entregable 4

riesgo de un lugar y pasarlo a otro o de un grupo a otro. Así mismo, el riesgo puede ser
minimizado compartiéndolo con otro grupo o dependencia.
· Asumir el riesgo: Luego de que el riesgo ha sido reducido o transferido puede quedar un
riesgo residual que se mantiene, en este caso el gerente del proceso simplemente acepta la
pérdida residual probable y elabora planes de contingencia para su manejo

Una vez establecidas cuáles de las anteriores opciones de manejo del riesgo se van a
concretar, estas deben evaluarse con relación a beneficio-costo para proceder a elaborar
el mapa de riesgos, el cual permitirá visualizar todo el proceso de valoración, análisis y
manejo de los riesgos.

44