1 Contenido

2 INTRODUCCION ........................................................................................................................... 4
SQAP .................................................................................................................................................... 5
3 ORGANIZACION ........................................................................................................................... 5
IES (Ingenieros Especializados en Software) ....................................................................................... 5
Mision..6
Visin................................................................................................................................................... 5
Poltica de Calidad .............................................................................................................................. 5
Patrn de Desarrollo .......................................................................................................................... 6
4 PROPOSITO .................................................................................................................................. 6
5 ACRNIMOS ................................................................................................................................ 6
6 DEFINICIONES .............................................................................................................................. 7
7 REFERENCIAS ............................................................................................................................... 7
8 GESTIN ...................................................................................................................................... 8
8.1 Organizacin........................................................................................................................ 8
8.1.1 Organizacin del Grupo de Desarrollo ........................................................................ 8
8.1.2 Organizacin del Especialista en SQA ......................................................................... 9
8.1.3 Organizacin del Cliente.............................................................................................. 9
8.1.4 Organizacin del Grupo SQA ....................................................................................... 9
8.2 Tareas ................................................................................................................................ 10
8.3 Responsabilidades ............................................................................................................. 13
9 Documentacin ......................................................................................................................... 14
9.1 Especificacinoes de Requerimientos (SRS) ........................................................................ 15
9.1.1 MODELO A USAR PARA EL CONTENIDO DEL SRS ...................................................... 15
9.2 Descripcion del Diseo(Arquitectura) DDS ....................................................................... 16
9.2.1 MODELO A USAR PARA EL CONTENIDO DEL DDS ..................................................... 18
9.3 Plan de Validacin y Verificacin(SVVP)............................................................................ 20
9.3.1 MODELO A USAR PARA EL CONTENIDO DEL (SVVP) ................................................. 20
9.3.2 Ciclo de Vida de Verificacin y Validacin................................................................. 20
9.4 Reportes de Verificacion ................................................................................................... 20
6.4.1 Reporte sumario de fases SVVP. .................................................................................. 21
 9.4.2 Reporte de Anomalas. .............................................................................................. 22
6.4.3 Reporte Final SVVP. ................................................................................................... 23
9.5 Documento de Usuario ..................................................................................................... 24
9.5.1 Modo Instruccional ................................................................................................... 24
9.5.2 Modo de Referencia .................................................................................................. 24
6.4 Descripcin del uso de documentos ............................................................................ 25
6.5 Documentos relacionados ............................................................................................... 25
6.6 Convenciones ....................................................................................................................... 25
6.7 Instrucciones de reportes de problemas ................................................................... 25
9.6 Plan de Gestion de Configuracion (SCMP) ........................................................................ 27
9.7 Plan de Proyecto ............................................................................................................... 27
9.7.1 MODELO A USAR PARA EL CONTENIDO DEL PLAN DE PROYECTO ............................ 28
10 Estndares, prcticas y convenciones ................................................................................... 29
10.1 Estndares para Documentacin. ..................................................................................... 29
10.2 Estndar de Codificacin. .................................................................................................. 29
10.3 Estndar de Comentario. .................................................................................................. 31
10.4 Responsabilidades de Verificar el Cumplimiento.............................................................. 31
11 Revisiones del software......................................................................................................... 31
11.1 Propsito ........................................................................................................................... 31
11.2 Requerimientos Mnimos .................................................................................................. 32
11.3 Agenda .............................................................................................................................. 32
11.3.1 Revisar cada producto ............................................................................................... 33
11.3.2 Revisar el apego al proceso ....................................................................................... 36
Objetivo: ................................................................................................................................ 36
Mecanismo: ........................................................................................................................... 36
11.3.3 Revisar el ajuste al proceso: ...................................................................................... 37
11.3.4 Realizar Revisin Tcnica Formal .............................................................................. 38
12 Testeo .................................................................................................................................... 38
13 Informacin sobre problemas y accin correctiva ................................................................ 38
14 Herramientas, tcnicas y metodologas ................................................................................ 42
15 Control de cdigo .................................................................................................................. 42
16 Control de medios ................................................................................................................. 43
17 Recopilacin de registros, mantenimiento y retencin ........................................................ 43
18 Formacin.............................................................................................................................. 44
19 Gestin de Riesgos ................................................................................................................ 45
2 INTRODUCCION

El mundo actual se encuentra inmerso en cambios constantes y ms an

tecnolgicos, donde todos y cada uno de los miembros que lo conforman se
encuentran interrelacionados convergiendo en una constante competencia para
ser sobresalientes, en definitiva en busca de ser los mejores. En efecto este
inters hace que busquen el desarrollo integral de todas sus partes y elementos
que los constituyen, en el cual dan importancia a un factor importante que es el
control de calidad, que maneja el conjunto de tcnicas y actividades que
utilizanpara evaluar los requisitos que se deben cumplir respecto a la calidad del
producto o servicio. Esto implica a que surjan nuevas exigencias, cambios y
mejoras en su proceso, en el cual las organizaciones tendrn que cumplir con los
nuevos requisitos, seguir procesos para satisfacer necesidades ms exigentes,
teniendo que demostrar la calidad que tienen.

Muchas veces las entidades desarrolladoras de software tratan de realizar

grandes cambios para lograr mejoras sustanciales en la actividad que realizan, sin
embargo mediante pequeos cambios podemos incrementar su rendimiento y
hacerlas superior, adicionndoles un control a los procesos para obtener
resultados ms satisfactorios. Es por esta razn que nosotros tomamos en cuenta
la creacin de un manual de calidad para ayudar a nuestra empresa a tomar la
calidad como una ventaja competitiva, tomar a la calidad como la estrategia y la
planificacin para que pueda mejorar su desempeo y satisfacer a sus clientes
para que de esa manera vuelva a usar los servicios de nuestra empresa. Al
requerir nuevamente el producto y lo recomiende con seguridad, permitir que la
empresa tenga mejor supervivencia en el largo plazo.

Es por eso el presente manual para la empresa desarrolladora de software, el cual

se encuentra fundamentado en la norma IEE730 es una recomendacin para
elaborar un Plan de Aseguramiento de la Calidad del Software (SQAP, Software
Quality Assurance Plan) para los proyectos de desarrollo de software.
Proporciona los requisitos mnimos aceptables para la preparacin y el contenido
de los planes de aseguramiento de la calidad de software. Fue escrito para ser
utilizado en las fases de desarrollo y mantenimiento del software. El plan SQA
sirve como gua de las actividades de SQA en el proyecto.

SQAP
PLAN DE GARANTIA DE CALIDAD DEL
SOFTWARE(SQAP)

3 ORGANIZACION
IES (Ingenieros Especializados en Software)

Slogan: No te esfuerces, nosotros lo haremos por ti!

Misin

Convertirnos en actores importantes dentro del mercado del software y

nuevas tecnologas a nivel nacional e internacional, ofreciendo a nuestros
clientes soluciones tecnolgicas de avanzada.

Visin

Consolidarnos como una empresa de Software de la ms alta calidad capaz de

brindar a travs de nuestros productos una solucin integral para el control
ms eficiente del funcionamiento del rea de negocios de nuestros clientes.

Poltica de Calidad

Somos un equipo de trabajo cuyas acciones diarias las ejecutamos con

una elevada vocacin de servicio a los Clientes en nuestra visin de
empresa de categora mundial, basadas en los siguientes principios:

1. INTEGRIDAD PERSONAL como expresin de disciplina, orden,

respeto, honestidad y entusiasmo.
 2. CREATIVIDAD E INNOVACIN como parte de nuestro reto diario para
el mejoramiento continuo.

3. PRODUCTIVIDAD en nuestro trabajo y en el empleo de los recursos.

4. CONSCIENCIA en la prctica de un trabajo libre de errores y en el

COMPROMISO leal con nuestros clientes y con las realizaciones de
calidad.

Patrn de Desarrollo

Como patrn de desarrollo, utilizamos el Proceso Unificado de Desarrollo de

Software para crear software robusto de manera que garantice un proyecto
correcto, tambin se trabaja con una programacin orientada a objetos para
mejorar la estructura de nuestros software y programacin estructural para
garantizar el mejor rendimiento posible. De esta forma, generar calidad de
aplicaciones y productividad de la empresa.

4 PROPOSITO
El proposito de este plan es especificar las actividades que se realizan para
asegurar la calidad de software a construir. En el se detallan los productos que
se van a revisar y los estndares, normas o mtodos a aplicar, los mtodos y
procedimientos que se utilizaran para revisar que la elaboracin de los
productos se realice como lo establece el modelo de ciclo de vida del proyecto:
para informar a los responsables de los productos los defectos encontrados y
realizar un seguimiento de dichos defectos hasta su correccin.

5 ACRNIMOS
SQA: Aseguramiento de la Calidad del Software.

SCM: Gestin de Configuracin del Software.

GP: Gestin del Proyecto.

6 DEFINICIONES
Funcionalidad: capacidad del software para proporcionar funciones que
satisfacen las necesidades fijadas y solicitadas, cuando el software se
usa bajo condiciones especificadas.

Fiabilidad: capacidad del software para mantener su nivel de

funcionamiento, cuando se usa en condiciones especificas.

Usabilidad: Capacidad del software para ser entendido, aprendido, usado

y aceptado por el usuario.

Eficiencia: Capacidad del software para proporcionar el funcionamiento

requerido, relativo a la cantidad de recursos usados, bajo condiciones
establecidas

7 REFERENCIAS
Para alcanzar la calidad total de los productos y la mejora continua, se
utilizan los siguientes estndares:

[1] IEEE Std 730-1998, IEEE Standard for Software Quality Assurance
Plans.

[2] IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance
Planning.

[4] IEEE Std 828: Anlisis de requerimientos del software

[5] IEEE STD-829: Estndar para documentacin de pruebas de

software.

[6] IEEE STD-830: Estndar para especificacin de requerimientos de

software.

[7] IEEE STD-1012: Estndar para la planificacin de verificacin y

validacin de software.
 [8] IEEE STD-1063: Estndar para los manuales de usuarios de
software.

8 GESTIN
El tema de esta seccin es relacionar los elementos de la Gestin de Calidad
con las actividades especficas del proyecto y/o de SQA en la institucin,
especificando organizacin, tareas y responsabilidades

8.1 Organizacin
La estructura organizativa que influye y controla la calidad del software es
de la siguiente manera:

Organizacin de Grupo de Desarrollo de Software (CDS).

Organizacin de Especialistas en SQA
Organizacin del Cliente.
Organizacin del grupo SQA

8.1.1 Organizacin del Grupo de Desarrollo

Es la organizacin encargada del desarrollo del software, su trabajo est
regido de acuerdo a las especificaciones y contratos establecidos por el
cliente. Para la empresa se encuentra estructurado de la siguiente
forma:

Lista de Personas

1 Gestor
2 Analistas
2 Diseador
3 Implementadores o programador
1 Agente de prueba
8.1.2 Organizacin del Especialista en SQA
Es la organizacin fiscalizadora del producto de software, teniendo
la potestad delegada por el cliente, para establecer normas, supervisar
el desarrollo y hacer cumplir con los contratos establecidos.
Generalmente el consultor toma el papel de intermediario entre el
cliente y el grupo de desarrollo. Presenta la siguiente estructura:

Lista de Personas

1 Gerente General
1 Experto en Proyectos
1 Experto en Ciencias de la Computacin
1 Secreataria
Organizacin y Organigrama

Gerente
General

Secretaria

Expertos en Departamento
Proyectos de Informatica

Estos tipos de reactivo pueden avaluar muchos datos en un tiempo

breve, adems que permiten la evolucin del aprendizaje en todos los
niveles de complejidad, pueden ser confiables si se los desarrolla
siguiendo los alineamientos establecidos para cada uno de ellos.

8.1.3 Organizacin del Cliente

La organizacin del cliente depende de la estructura de su empresa o de
la funcin que realice. Vara de acuerdo al proyecto de software que se
est desarrollando.

8.1.4 Organizacin del Grupo SQA

Es la organizacin que discute las normas y sugerencias generadas por
el consultor, para luego aceptarlas y liberar versiones sucesivas del
SQAP para el desarrollo e implementacin del software, esta
 organizacin se obtiene de las tres organizaciones anteriores. La
especificacin de la organizacin de la SQA es la siguiente:

Lista de Personas

1 Gerente Administrativo
1 Jefe de Departamento de Informtica
1 Experto en Proyectos
1 Experto en Ciencias de la Computacin
1 Director de Equipo de Desarrollo (Gestor)

8.2 Tareas
La relacin de tareas asociadas con el ciclo de vida de desarrollo de
software y las actividades de la SQA son las siguientes, las cuales se
ejecutarn durante el desarrollo del producto de software:

Actividad Entregable Asociado

Elaboracin del Plan de SQA Plan de SQA

Identificar propiedades de Calidad Plan de SQA

Evaluacin de la calidad de los Informe de revisin de SQA

productos

Revisar el ajuste al proceso Informe de revisin de SQA

Realizar Revisin Tcnica Formal Informe de Revisin Tcnica

Formal

Evaluar y ajustar el Plan de SQA Documento de Evaluacin y

Ajustes al Plan de SQA

Evaluacion final de SQA Informe final de SQA

Revisar la entrega semanal Entrega semanal de SQA

CICLO DE VIDA DEL TAREAS Y ACTIVIDADES ASOCIADAS AL
SOFTWARE (PUDS) CICLO DE VIDA DEL SOFTWARE

Capturar de requisitos de software

Generacin de especificaciones

Requerimientos Revisin de especificaciones

Revisin de las especificaciones de software

Anlisis de las especificaciones

Revisin del anlisis

Anlisis Anlisis detallado

Revisin del anlisis detallado del software

Diseo preliminar

Generacin de especificaciones de diseo

preliminar

Revisin del diseo preliminar

Diseo detallado

Diseo Generacin de especificaciones de diseo

detallado

Revisin del diseo detallado

Revisin del diseo preliminar

Revisin del diseo detallado del software

(Ambos versus las especificaciones)

Codificacin

Generacin de cdigo

Implementacin Revisin de cdigo

 Revisin de cdigo versus la documentacin

generada

Elaboracin de pruebas de unidad y

generacin de resultados
Pruebas
Revisin de resultados

Elaboracin de las pruebas de unidad y de

integracin del software

Revisin de los resultados de las pruebas

Revisin de las pruebas funcionales y

evaluacin de los resultados

Instalacin del producto software

Prueba final bajo ambiente real

Generacin de resultados de prueba

Instalacin y Prueba Revisin de resultados

Final
Revisin de la instalacin del software y

evaluacin de

Resultados
Las actividades de SQA definidas en el modelo de proceso son:

Actividad Entregable Asociado

Elaboracin del Plan de SQA Plan de SQA

Identificar propiedades de Calidad Plan de SQA

Evaluacin de la calidad de los productos Informe de revisin de SQA

Revisar el ajuste al proceso Informe de revisin de SQA

Informe de Revisin Tcnica

Realizar Revisin Tcnica Formal
Formal

Documento de Evaluacin y
Evaluar y ajustar el Plan de SQA
Ajustes al Plan de SQA

Evaluacin final de SQA Informe final de SQA

Revisar la entrega semanal Entrega semanal de SQA

8.3 Responsabilidades
El responsable de SQA es el responsable de realizar las actividades y
entregables mencionados en la seccin anterior.

Como parte de las actividades del Responsable de SQA se revisarn los

productos que se consideren relevantes para la calidad del producto y del
proceso. A continuacin se identifican esos productos y el responsable de las
acciones correctivas para eliminar los defectos de cada producto.
 Producto Rol responsable Responsable
Documento de Requerimientos
Modelo de Casos de Uso
Alcance del Sistema
Descripcin de la Arquitectura
Modelo de Diseo
Modelo de Datos
Estndar de Implementacin
Estndar de documentacin
tcnica
Documento de Estimaciones
Documento de Riesgos
Plan del Proyecto
Plan de Verificacin y Validacin
Reporte de pruebas unitarias, de
integracin y del Sistema
Plan de Implantacin
Estndar de Documentacin de
Usuario
Documentacin de Usuario
Plan de Gestin de Configuracin

9 Documentacin
se debe identificar la documentacin que asegura que la implementacin del
software satisface los requerimientos planteados, la cual est compuesta
segn el std. 730-1 como mnimo por la siguiente:

Especificacin de Requerimientos (SRS)

Descripcin del Diseo (Arquitectura)
Plan de Verificacin y Validacin (SVVP)
Reportes de Verificacin
Documentacin de Usuario
Plan de Gestin de Configuracin (SCMP)
Plan del Proyecto
Se identifica toda la documentacin que gobernar el desarrollo, validacin y
verificacin, mantenimiento y uso del software.
9.1 Especificacinoes de Requerimientos (SRS)
Es elaborada por el desarrollador, y se basa en el estndar ANSI / IEEE
Std 830 Gua par especificaciones de requerimientos de software (SRS).

La SRS deber describir claramente y de forma precisa cada uno de los

requerimientos del software, tal como: funciones, rendimiento, restricciones
de diseo y atributos.

9.1.1 MODELO A USAR PARA EL CONTENIDO DEL SRS

1. INTRODUCION
1.1Objetivo
1.2Alcance
1.3Definiciones, acrnimos y abreviaciones
1.4Referencias
1.5Revisin
2. DESCRIPCION GENERAL
2.1 Perspectiva del producto

2.2 Funciones del producto

2.3 Caractersticas de los usuarios

2.4 Restricciones generales

2.5 Asunciones y dependencias

3. ESPECIFICACION DE REQUERIMIENTOS
3.1 Requerimiento Funcional

3.1.1. Introduccin

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 Representacin del diseo

3.1.8 Cumplimientos con estndares

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

3.1.10.5 Prevenciones

3.1.11 Otros requerimientos

3.1.11.1. Base de datos

3.1.11.2. Operaciones

3.1.11.3. Adaptaciones

4. APENDICES

5. INDICE

6. ANEXOS

9.2 Descripcion del Diseo(Arquitectura) DDS

La generacin y documentacin de la descripcin del diseo de Software

se basa en el estndar ANSI / IEEE Std 1016 RECOMMENDED PRACTICE
FOR SOFTWARE DESCRIPTIONS
 VISTA DE ALCANCE ATRIBUTOS EJEMPLOS DE
DISEO DE ENTIDAD REPRESENTACIONES

Descripcin de Particin del Identificacin, Diagrama de

descomposicin sistema dentro tipo, objetivo, descomposicin,
de entidades de funcin, jerarqua y lenguaje
diseo. subordinacin. natural.

Descripcin de Descripcin de Identificacin, Diagrama de

dependencia las relaciones tipo, objetivo, estructura.
entre entidades y dependencias,
recursos del recursos.

Descripcin de Lista de cada Identificacin, Tablas de parmetros.

interfaces interfaz de funcin,
diseador, interfaces.
programador, o
pruebas

Descripcin de Identificacin, Diagrama de flujos.

los detalles de procesamiento,
Descripcin de diseo internos datos.
detalle en una entidad.
9.2.1 MODELO A USAR PARA EL CONTENIDO DEL DDS

1. INTRODUCION
Objetivo
Alcance
Definiciones, acrnimos y abreviaciones
2. REFERENCIAS
3. DESCRIPCION DE DESCOMPOSICION
3.1. Descomposicin de mdulo

3.1.1. Descripcin del mdulo 1

3.1.2. Descripcin del mdulo 2

3.1.n. Descripcin del mdulo n

3.2. Descomposicin de procesos concurrentes

3.2.1. Descripcin del proceso 1

3.2.2. Descripcin del proceso 2

3.2.n. Descripcin del proceso n

3.3. Descomposicin de datos

3.3.1. Descripcin de la entidad de datos 1

3.3.2. Descripcin de la entidad de datos 2

3.3.n. Descripcin de la entidad de datos n

4. DESCRIPCION DE DEPENDENCIA
Dependencia entre mdulos
Dependencia entre procesos

Dependencia entre datos

5. DESCRIPCION DE INTERFACES
Interfaces de mdulo
5.1.1. Descripcin del mdulo 1

5.1.2. Descripcin del mdulo 2



5.1.n. Descripcin del mdulo n

5.2 Interfaces de procesos

5.2.1. Descripcin del proceso 1

5.2.2. Descripcin del proceso 2

5.2.n. Descripcin del proceso n

6. DISEO DETALLADO

6.1. Diseo detallado del mdulo

6.1.1. Detalle del mdulo 1

6.1.2. Detalle del mdulo 2

6.1.n. Detalle del mdulo n

6.2. Diseo detallado de datos

6.2.1. Detalle de entidad de datos 1

6.2.2. Detalle de entidad de datos 2

6.2.n. Detalle de entidad de datos n

APENDICES

INDICE

ANEXOS
9.3 Plan de Validacin y Verificacin(SVVP)
La generacin y documentacin del Plan de Verificacin y Validacin
(SVVP) es la siguiente:

9.3.1 MODELO A USAR PARA EL CONTENIDO DEL (SVVP)

1. OBJETIVO
2. ALCANCE
3. DEFINICIONES, ACRONIMOS Y ABREVIACIONES
4. ORGANIZACIN RESPONSABLES
5. CICLO DE VIDA DE VERIFICACION Y VALIDACION

APENDICE

INDICE

La organizacin responsable por las tareas de verificacin y validacin del

software es la organizacin de SQA comandada por la organizacin del
consultor, la cual interacta con la organizacin de desarrollo para alcanzar
los objetivos del plan. En casos necesarios de conflictos extremos entre el
consultor y el desarrollador se recurrir al cliente.

9.3.2 Ciclo de Vida de Verificacin y Validacin.

El plan se basa en el siguiente ciclo de vida del software:

Fase de requerimientos
Fase de diseo
Fase de implementacin
Fase de prueba
Fase de instalacin y prueba
Fase de operacin y mantenimiento

9.4 Reportes de Verificacion

El formato para los reportes de los resultados de la implementacin del plan
de verificacin y validacin del software es la siguiente:
6.4.1 Reporte sumario de fases SVVP.
9.4.2 Reporte de Anomalas.
6.4.3 Reporte Final SVVP.
9.5 Documento de Usuario
Esta descripcin de documentacin de usuario se basa en el estndar ANSI/
IEEE Std 1036 STANDARD FOR SOFTWARE USER DOCUMENTATION.

La informacin especificada debe ser incluida en la documentacin del

usuario, esta documentacin de usuario comprender de un conjunto. En
cada documento se debe tomar en cuenta y describir los siguientes puntos.

Los documentos de usuario sern presentados en dos modos: instruccional

y de referencia.

Los usuarios del software utilizarn los documentos ya sea para aprender
acerca del software (modo instruccional) o para refrescar su memoria
acerca del software (modo de referencia).

9.5.1 Modo Instruccional

Un modo instruccional de documento debe:

Proveer el ambiente y la informacin necesaria para entender el

sistema.
Proveer la informacin necesaria para aprender lo que puede hacer
con el software y como lo puede usar.
Proveer ejemplos para reforzar el proceso de aprendizaje.

9.5.2 Modo de Referencia

Un documento de modo de referencia debe:

Organizar y proveer informacin necesaria.

Facilitar accesos aleatorios a la informacin.
 Los documentos de modo de referencia que debe ser incluido son:

a. Manual de comandos.
b. Manual de mensajes de error.
c. Manual de llamadas de programas.
d. Gua de referencia rpida.
e. Manual de Herramientas del software.
f. Manual de utilitarios.

MODELO A USAR PARA EL CONTENIDO DE LA DOCUENTACION DE

USUARIO

TITULO DE LA PAGINA

RESTRICCIONES

GARANTIAS Y OBLIGACIONES CONTRACTUALES

TABLA DE CONTENIDO

LISTA DE ILUSTRACIONES

INTRODUCCION

Descripcin de audiencia

Declaracin de aplicacin

Declaracin de objetivos

6.4 Descripcin del uso de documentos

6.5 Documentos relacionados

6.6 Convenciones

6.6.1 Smbolos

6.6.2 Convenciones de estilo

6.6.3 Convenciones de sintaxis de comandos

6.7 Instrucciones de reportes de problemas

CUERPO DEL DOCUMENTO

 7.1. Cuerpo del documento en modo instruccional

7.1.1 Alcance

7.1.2 Materiales

7.1.3 Preparaciones

7.1.4 Precauciones y prevenciones

7.1.5 Mtodos

7.1.6 Informacin relacionada

7.2. Cuerpo del documento en modo de referencia

7.2.1 Objetivo

7.2.2 Materiales

7.2.3 Preparaciones

7.2.4 Entradas

7.2.5 Precauciones y prevenciones

7.2.6 Invocacin

7.2.7 Operaciones de suspensin

7.2.8 Operaciones de terminacin

7.2.9 Salidas

7.2.10 Condiciones de error

7.2.11 Informacin relacionada

MENSAJES DE ERROR, CONOCIMIENTO DE PROBLEMAS, RECUPERACION DE

ERROR

ANEXOS

10. BIBLIOGRAFIA

11. GLOSARIO

12. INDICE
9.6 Plan de Gestion de Configuracion (SCMP)
La gestin de configuracin del software es una actividad de
autoproteccin que se aplica durante el proceso del software. Como el
cambio se puede producir en cualquier momento, las actividades de GCS
sirven para:

Identificar el cambio.
Controlar el cambio.
Garantizar que el cambio se implementa adecuadamente.
Informar del cambio a todos aquellos que puedan estar interesados.

Es importante distinguir claramente entre el mantenimiento del software

y la gestin de configuracin del software. El mantenimiento es un
conjunto de actividades de ingeniera del software que se producen
despus de que el software se haya entregado al cliente y est en
funcionamiento. La gestin de configuracin del software es un conjunto
de actividades de seguimiento y control que comienzan cuando se inicia
el proyecto de ingeniera del software y termina slo cuando el software
queda fuera de la circulacin.

Para controlar y gestionar los elementos de configuracin, se debe

identificar cada uno de forma nica y luego organizarlos mediante un
enfoque orientado a objetos.

Se pueden identificar dos tipos de objetos: objetos bsicos y objetos

compuestos.

9.7 Plan de Proyecto

La gestin de un proyecto de software comienza con un conjunto de

actividades que globalmente se denominan planificacin del proyecto. Antes de
que el proyecto comience, el gestor y el equipo de software deben realizar una
estimacin del trabajo a realizar, de recursos necesarios y del tiempo que
transcurrir desde el comienzo hasta el final de su realizacin. Siempre que
estimamos, estamos mirando hacia el futuro y aceptamos resignados cierto
grado de incertidumbre.

9.7.1 MODELO A USAR PARA EL CONTENIDO DEL PLAN DE PROYECTO

1 PLAN DE PROYECTO
2 INTRODUCCIN
2.1 Propsito del Plan
2.2 mbito del Proyecto y Objetivos
2.2.1 Antecedentes
2.2.2 Descripcin del problema
2.2.3 Situacin Problemtica
2.2.4 Objetivos
2.2.5 Justificacin
2.2.6 Funciones Principales
2.2.7 Alcance del Proyecto
2.2.8 Aspectos de Rendimiento
2.2.9 Restricciones Tcnicas y de Gestin
3 Estimaciones del Proyecto
3.1 Datos Histricos usados para las estimaciones
3.1.1 Mtricas Orientadas al Tamao
3.1.2 Mtricas Orientadas a la Funcin
3.2.5 Ecuacin del Software
3.3 Conciliacin de las Estimaciones
3.2.1 Estimaciones Basadas en Lneas de Cdigo
3.2.2 COCOMO I
3.2.3 COCOMO II
3.2.4 Calculo del Esfuerzo
Riesgo

4 GESTIN DE RIESGO
4.1 Tabla de Riesgos

4.2 Plan RSGR para cada

4.2.1 Reduccin de Riesgo

 4.2.1 Supervisor del Riesgo

5 PLANIFICACIN TEMPORAL
6 RECURSOS DEL PROYECTO
7 ORGANIZACIN DEL PERSONAL
7.1 Estructura del Equipo

8 MECANISMOS DE SEGUIMIENTO Y CONTROL

8.1 Formularios para RTF

8.2 Recurso

10 Estndares, prcticas y convenciones

se identifican los estndares definidos para el proyecto, como normas de
documentacin, de cdificacin, notacin UML, normas IEEE que aplican,
etc. y de que forma se asegurar el cumplimiento de los mismos.

10.1 Estndares para Documentacin.

La documentacin del software se realizara en Word que estar compuesta
por:

un ndice
Desarrollo de este
Con determinada sangra, interlineado
Separado por partes

10.2 Estndar de Codificacin.

La codificacin del software se realizar en la plataforma Java. Que se

definen de la siguiente forma:

El software debe ser subdividido en mdulos independientes, de

acuerdo al diseo establecido.
La documentacin de un programa debe tener el siguiente formato:
o Nombre del programa
o Objetivo
o Nombre de las entradas:
 - Base de Datos
- Archivos
- Registros
- Formatos de pantalla
o Nombre de las salidas:
- Base de Datos
- Archivos
- Registros
- Formatos de pantalla
- Reportes
o Nombre de los archivos de actualizacin:
- Base de Datos
- Archivos
- Registros
o Nombre del autor
o Fecha de creacin
o Historial de actualizaciones
- Versin
- Fecha de cambio
- Objetivo de cambio
-
Cada mdulo debe explicar sus funciones
La declaracin de cualquier variable debe estar comentada,
explicando su funcin.
Debe existir una sola instruccin por cada lnea de cdigo.
Cada funcin debe de estar debidamente documentada, explicar la
funcionalidad, la funcin de cada parmetro.
Cada mensaje de error o excepciones deben de indicar el lugar donde
se origin y la funcin o procedimiento en el cual se produjo.
Los nombres de las funciones deben de indicar su funcionalidad.
Cada clase implementada debe de estar comentada de la siguiente
forma:
o Nombre
o Fecha y hora de creacin
o Autor
o Nombre del mdulo al que pertenece
o Funcionalidad
10.3 Estndar de Comentario.

Un comentario debe explicar porque se realiza alguna accin.

Los comentarios dentro de un mdulo deben estar separados del
cdigo.
Utilizar comentarios de ms de una lnea para realizar descripciones,
y comentarios de una lnea para realizar especificaciones.

10.4 Responsabilidades de Verificar el Cumplimiento.

Los responsables de realizar la verificacin del cumplimiento con los

estndares definidos son:

El jefe del equipo de desarrollo.

La organizacin del SQA.

11 Revisiones del software

11.1 Propsito
Los responsables de estas revisiones es la organizacin del SQA, con la
participacin de todo elemento de la organizacin que tengan que ver con los
requerimientos, tales como: los diseadores del software, agentes de pruebas.

Las revisiones y auditorias de los resultados del desarrollo se realizan a medida

que se terminan cada una de las fases del ciclo de vida de desarrollo de
software, con el fin de:

Conocer el progreso alcanzado en el desarrollo.

Evaluar el ajuste a los requerimientos del sistema.
Evaluar la eficiencia en el trabajo.

Se deben llevar a cabo, al menos, las siguientes revisiones y auditorias:
11.2 Requerimientos Mnimos
Los elementos mnimos que debern ser revisados son:

Especificacin de Requerimientos
Modelo de Diseo y Descripcin de la Arquitectura
Plan de Verificacin y Validacin
Plan de Gestin del Proyecto
Plan de Gestin de Configuracin
Diseo vs. Especificacin de requerimientos
Implementacin vs. Diseo
Verificacin vs. Especificacin de requerimientos

11.3 Agenda
En esta seccin se detallan todas las revisiones de calidad que se realizarn
durante todo el proyecto, organizadas por fase e iteracin.

Fase I Inicial

Iteracin I

Entregable Realizado Revisin Tipo de

revisin

Nombre del Fase, iteracin Semana, si se Tipo de

entregable o producto y semana en quiere tambin revisin que
a revisar que se debe la fecha, en la se realizar:
realizar la que se realizar
Evaluacin de
versin del la revisin del
la calidad de
producto a entregable o
revisar producto
los productos,
Revisar el
ajuste al
proceso o
Revisin
Tcnica
Formal
 .

Iteracin N

Fase II Elaboracin

Iteracin I

Iteracin N

Fase III Construccin

Iteracin I

Iteracin N

Y as sucesivamente para cada una de las fases del ciclo de vida de desarrollo
de software.

11.3.1 Revisar cada producto

11.3.1.1 Auditoria Funcional:

Esta verificacin es realizada antes de la entrega del software, para
verificar que todos los requerimientos especificados en la ERS fueron
alcanzados.

La verificacin funcional compara el cdigo con los requerimientos

documentados del software, como se estableci en ERS. Su propsito es
asegurar que el cdigo hace todo y solo lo que se indica en la
documentacin establecida por la ERS.

Se definen los siguientes puntos:

Nomenclatura
Nmero de identificacin de la especificacin
Nmero de tem de configuracin
La especificacin de requerimientos de software
Copia de cdigo objeto
 Listado actualizado de tems de configuracin especificados
El reporte de verificacin y validacin del software
Listado del cumplimiento exitoso de pruebas funcionales
Listado de todo lo planificado y pruebas que no fueron ejecutadas
Actualizaciones para la documentacin previamente liberada
deber ser revisada para asegurar su exactitud y consistencia

11.3.1.2 Auditoria Fsica:

Esta verificacin es realizada para verificar que el software y su
documentacin son internamente consistentes y estn listas para su
entrega.

La verificacin fsica compara el cdigo con su documentacin de

soporte, su propsito es asegurar que la documentacin a ser entregada
describa correctamente el cdigo.

La documentacin necesaria para realizar la verificacin fsica es la

siguiente:

Descripcin del diseo del software DDS

Productos de software
Documentacin asociada
Para proveer evidencia de un adecuado control del contenido del sistema
y consistencia del equipo de auditoria se examina lo siguiente:

Los documentos de especificacin del sistema para formatos y

cumplimientos
Reportes funcionales para discrepancia y acciones tomadas
Descripcin del diseo para smbolos, etiquetas, referencias y
descripcin de datos
Los manuales para formatos de completitud y cumplimiento con la
descripcin de datos.
Los elementos de software liberados en el medio son ptimos
para transferir y transmitir
Identificar los cambios en los tems de configuracin de datos
11.3.1.3 Auditorias del Proceso:
Estas verificaciones sern desarrolladas dentro de los procesos de
desarrollo del software, como ser el diseo para verificar la consistencia
del diseo incluyendo:

Cdigo versus documentacin del diseo

Especificaciones de interfaces hardware / software.
Implementacin de diseo versus requerimientos funcionales
El objetivo es verificar la consistencia del producto a travs del proceso
del desarrollo para determinar que:

Las interfaces hardware/software sean consistentes con el diseo

de requerimientos en la ERS.
Los requerimientos funcionales de la ERS, sean completamente
probados por el SVVP.
El diseo del producto especificado en la DDS, satisface los
requerimientos funcionales del ERS.
El cdigo es consistente con la DDS.

11.3.1.4 Revisiones de gestin:

Estas revisiones son realizadas peridicamente para evaluar la ejecucin

del SQAP. Estas revisiones debern ser realizadas por el elemento
organizacional del consultor.

Para cada tipo de revisin, se debe explicar:

Su objetivo.
Qu producto es el que se evala.
Sus propsitos.
Cul es el elemento organizativo responsable de llevar a cabo la
revisin.
Cules son los elementos organizativos que deben tomar parte de
la revisin.
Cules son los requisitos de revisin.
 Dnde deben documentarse los resultados de la revisin.

Para cada tipo de auditoria se debe explicar:

Su objetivo.
Cul es el elemento organizativo responsable de llevar a cabo la
auditoria.
Dnde deben documentarse los resultados de la auditoria.
Cules son las entradas para la auditoria.

Se definen los tres tipos de revisiones (Evaluacin de la calidad de los

productos, Revisar el ajuste al proceso y Revisin Tcnica Formal RTF),
sus objetivos y mecanismos.

11.3.2 Revisar el apego al proceso

11.3.2.1 Evaluacin de la calidad de los productos:

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 estndares y
con los objetivos de calidad definidas para el producto. Se debe verificar
que no queden correcciones sin resolver en los informes de revisin
previos, si se encuentra alguna no resuelta, debe ser incluida en la
siguiente revisin. 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 revisin de SQA, que contiene

todas las desviaciones o defectos encontrados durante la revisin. 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.

11.3.3 Revisar el 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 informacin necesaria de
cada producto, buscando hacia atrs los productos previos que deberan
haberse generado y son entradas para el producto objeto de revisin,
para poder establecer los criterios de revisin y evaluar si el producto
cumple con las especificaciones.

Esta informacin se obtiene de los siguientes documentos:

Plan del Proyecto

Plan de la iteracin
Plan de Verificacin
Se debe verificar si todos los pasos del proceso de desarrollo son
seguidos apropiadamente.

Antes de comenzar, se debe verificar en los informes de revisin 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 revisin de SQA correspondiente a

la evaluacin de ajuste al Proceso, que contiene todas las desviaciones o
defectos encontrados durante la revisin. 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.
11.3.4 Realizar Revisin Tcnica Formal

Objetivo:
Descubrir errores en la funcin, la lgica la implementacin de
cualquier producto del software, verificar que satisface sus
especificaciones, que se ajusta a los estndares establecidos, sealando
las posibles desviaciones detectadas.

Mecanismo:
Es un proceso de revisin 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 caracterstica se
adopta esta prctica para productos que son de especial importancia. En
la reunin participan el responsable de SQA e integrantes del equipo de
desarrollo. Se debe convocar a la reunin 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.

12 Testeo
se deben detallar, si existieran, las pruebas que se realizarn sobre el software
cubierto por el SQAP y que no estn includas en el Plan de Verificacin y Validacin
(SVVP), por ejemplo de propiedades de calidad identificadas que as lo requieran

13 Informacin sobre problemas y accin correctiva

En esta seccin se describen las prcticas y procedimientos que se van a
utilizar para la notificacin, seguimiento y resolucin de problemas de
software, as como las responsabilidades organizativas.

El propsito de un sistema de Gestin de Problemas y Acciones Correlativas es:

Asegurar que todos los problemas de documentan, se corrigen y no caen

en el olvido.
 Asegurar que se evala la validez de los informes de problemas.
Realimentar 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 travs de un
reporte en el cual se detalla la fecha de cuando fue encontrado el problema,
una identificacin preliminar del mismo, descripcin, etc., este reporte debe
ser firmado por los que identificaron el problema, debe ser entregado a la
organizacin responsable de los problemas.

La organizacin responsable de los problemas del software, es la organizacin

del SQA, comandada por la organizacin del consultor, estas organizaciones
son las encargadas de determinar el cronograma, lugar y temario, para llevar a
fijar la accin correctiva del problema.
 REPORTE FINAL DE PROBLEMAS Pg.

......

# De Reporte: Fecha: / ./_

Lugar: Hora:

a) Identificacin del problema:

b) Descripcin:

c) El evento ejecutado cuando se present el problema es:

d) Posibles orgenes del problema:

Equipo de Trabajo:

Nombre: Firma
Las acciones a seguir para corregir los problemas presentados se describen de
la siguiente manera:

Antes de la identificacin de la presencia de un problema se debe

buscar los posibles orgenes del mismo sin desechar ninguna de las
posibilidades, para esto se debe tomar dos rutas para generar el
reporte de problema completo y consistente.
o Registrar las causas sospechosas del origen del problema, esto
asegura que no se descarta ninguna situacin posible.
o Registrar causas adicionales
o Registrar causas plenamente identificadas, esto es, causas
verificadas por detectores del problema
o Registrar otras causas externas o relacionadas a las identificadas
anteriormente
Generar el reporte del problema, este debe estar completamente
detallado y de acuerdo a los puntos que contiene el mismo, este
reporte debe ser entregado a la organizacin responsable por los
problemas.
La organizacin responsable por los problemas, convocan a una
reunin tcnica, en la cual participarn adems de la organizacin
responsable, los elementos de las organizaciones afectadas por el
problema, quienes describirn el problema y darn recomendaciones
necesarias para solucionar el problema.
La especificacin de acciones correctivas generada en la reunin
tcnica, ser entregada a los elementos organizacionales afectados
por el problema para que estos implementen las acciones correctivas
respectivas.
14 Herramientas, tcnicas y metodologas
En esta seccin se identifican todas las herramientas, tcnicas y metodologas
que se van a utilizar en el desarrollo que apoyan el Aseguramiento de Calidad.

Algunas de las herramientas son:

Utilidades del sistema operativo WINDOWS XP.

Utilidades del sistema operativo LINUX.
Documentacin de ayuda.
Instaladores.
Las tcnicas que ayudan a la evaluacin o mejora de la calidad son:

ANSI / IEEE STD 830 Guide for Software Requirements

Specifications
ANSI / IEEE STD 1016 Recommended Practice for Software Design
Descriptions
ANSI / IEEE STD 1008 Standard for Software Unit Testing
ANSI / IEEE STD 1063 Standard for Software User Documentation
ANSI / IEEE STD 1028 Standard for Software Reviews and Audits
Las metodologas de Aseguramiento de Calidad sern conjuntos integrados de
tcnicas, de entre los anteriores.

15 Control de cdigo

En esta seccin se definen los mtodos, tcnicas y facilidades que se van a

utilizar para controlar el almacenamiento y mantenimiento de versiones del
cdigo.

Se especifica un procedimiento de control del Cdigo que:

Defina cul es el software que se va a controlar.

Describa un mtodo estndar para identificar, etiquetar y catalogar el
software.
Liste la localizacin fsica del software bajo control.
 Describa la localizacin, forma de mantenimiento y de uso de las copias
de seguridad.
Describa los procedimientos para distribucin de copias.
Identifique la documentacin que se ver afectada por los cambios.
Describa los procedimientos para la construccin de una nueva versin.

16 Control de medios
El medio del programa de computadora se define como aquellos medios sobre
los cuales los datos En esta seccin se definen los mtodos y facilidades que se
van a utilizar para proteger el medio fsico de accesos no autorizados y daos y
degradaciones inesperadas, y las organizaciones responsables para realizar
este control.

La organizacin responsable por esta tarea es la organizacin de desarrollo,

con la supervisin de la organizacin de la SQA.

Se debera asegurar que:

Est garantizado el almacenamiento y recuperacin de software.

El software est accesible nicamente para aquellos que lo necesitan.
Se controla el entorno para que no se degrade el medio fsico en el que
se almacena el software.
Se almacenan copias del software crtico y del cdigo en lnea base fuera
de las instalaciones de la organizacin.

17 Recopilacin de registros, mantenimiento y retencin

Las organizaciones responsables por las tareas de esta seccin, es la
organizacin del consultor, en coordinacin con la organizacin de la SQA.

Se identifica aquella documentacin que se debe retener, y se especifican los

mtodos y facilidades que se utilizarn para recolectar, proteger y mantener
esta documentacin.
Tambin se especificar el perodo de retencin para cada tipo de registro.

Se puede registrar no slo documentacin, sino tambin los medios fsicos que
contienen las versiones de los programas y los materiales utilizados en las
pruebas, para asegurar la repetibilidad de los tests en el futuro.

Los documentos que son requeridos son los siguientes:

Plan de garanta de calidad del software.

Especificacin de requerimientos del software.
Descripcin del diseo del software.
Plan de verificacin y validacin del software.
Documentacin del usuario.
El mantenimiento de los registros del software, ser realizado por versiones
sucesivas de actualizaciones de las mismas, para esto se lleva un registro de
actualizaciones de la documentacin.

Los documentos verificados y validados, deben ser documentados en libros

impresos, con tres copias de cada documento y almacenado en lugares
diferentes y ambiente adecuados.

La retencin de registros se realizar en cada finalizacin de las fases del ciclo

de vida de desarrollo de software y segn los puntos de verificacin y
validacin.

18 Formacin
CIS 740 Software Engineering

CIS 748 Software Management

CIS 771 Software Specifications

CIS 890 Agent-Oriented Software Engineerin

19 Gestin de Riesgos
Probabilida
Probabilidad de
Riesgos d de
Presencia
Impacto

R1. El tamao estimado es menor al tamao

45% Influyente
real del software.

R2. El personal no cuenta con la debida

60% Crtico
experiencia.

R3. La fecha de entrega es muy limitada. 50% Influyente

R4. El cliente no est contento con el sistema. 30% Crtico

R5. El cliente no est preparado para la

40% Moderado
utilizacin del sistema.

R6. La reutilizacin es menor a la prevista. 70% Influyente

R7. Habr muchos cambios de personal. 20% Moderado

R8. La complejidad del Software es mayor a la

25% Influyente
prevista

Reduccin de Riesgo

Riesgo N1:

Contar con datos histricos fiables y que sean proporcionadas por

empresas similares en el medio.
Riesgo N2:

Durante el transcurso del desarrollo del software, capacitar al personal en

las herramientas que se utilizarn durante la fase de codificacin.

Riesgo N3:
 Negociar con el cliente un tiempo adicional para la entrega del
producto en caso de presentarse algunas dificultades en el proceso
de desarrollo.
Riesgo N4:

Durante el transcurso del desarrollo del software, tener una estrecha

comunicacin con el cliente.

Riesgo N5:

Planificar cursos de capacitacin a los usuarios finales ya sea durante

la fase de pruebas o mantenimiento.
Riesgo N6:

Poner mayor atencin en la recopilacin de requisitos durante la fase

inicial o Ingeniera del Software.
Riesgo N7:

Pedir al personal alguna garanta o compromiso por escrito de que

cumplir con sus obligaciones.

Riesgo N8:

Utilizar componentes ya desarrollados y acomodarlos al proyecto.

Supervisin de Riesgos

Riesgo N1: Nombrar una persona del equipo de desarrollo que se

encargue de las estadsticas propias de los proyectos ya realizados
mediante la creacin de una base da datos amplios y confiables.
Riesgo N2: Fijar horarios dentro de los cules, el personal estar
obligado a aprender el uso de una herramienta especfica.
Riesgo N3: El gestor de proyectos se har cargo de la negociacin de
un tiempo de holgura para la entrega del producto.
Riesgo N4: El gestor deber planificar la cantidad necesaria de
reuniones con el cliente a fin de que recabar todos los requisitos.
 Riesgo N5: Fijar horarios para un curso de capacitar a los usuarios
finales del sistema.
Riesgo N6: l gestor se encargar de la redaccin de los contratos para
el personal restante.
Riesgo N7: Obligar a los desarrolladores que se programe utilizando
estndares de codificacin.
Riesgo N8: Modularizar el proyecto al mximo posible y as reducir los
problemas que se presenten para que sean mas fciles de encarar.