Contenido sqap

7/31/2019 Contenido sqap

1/47

1 Contenido2 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 ................................................................................................................................ 66 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


2/47

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


3/47

16 Control de medios ................................................................................................................. 43

17 Recopilacin de registros, mantenimiento y retencin ........................................................ 43

18 Formacin.............................................................................................................................. 44

19 Gestin de Riesgos ................................................................................................................ 45


4/47

2 INTRODUCCIONEl 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 obtenerresultados 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.


5/47

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.

SQAPPLAN DE GARANTIA DE CALIDAD DEL

SOFTWARE(SQAP)

3 ORGANIZACIONIES (Ingenieros Especializados en Software)

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

Misin

Convertirnos en actores importantes dentro del mercado del software ynuevas tecnologas a nivel nacional e internacional, ofreciendo a nuestrosclientes soluciones tecnolgicas de avanzada.

Visin

Consolidarnos como una empresa de Software de la ms alta calidad capaz debrindar a travs de nuestros productos una solucin integral para el controlms 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 deempresa de categora mundial, basadas en los siguientes principios:

1. INTEGRIDAD PERSONAL como expresin de disciplina, orden,

respeto, honestidad y entusiasmo.


6/47

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 proyectocorrecto, tambin se trabaja con una programacin orientada a objetos para

mejorar la estructura de nuestros software y programacin estructural paragarantizar el mejor rendimiento posible. De esta forma, generar calidad deaplicaciones y productividad de la empresa.

4 PROPOSITOEl 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 losproductos 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 ACRNIMOSSQA: Aseguramiento de la Calidad del Software.

SCM: Gestin de Configuracin del Software.

GP: Gestin del Proyecto.


7/47

6 DEFINICIONESFuncionalidad: 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 REFERENCIASPara 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/47

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

software.

8 GESTINEl 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 OrganizacinLa 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 DesarrolloEs la organizacin encargada del desarrollo del software, su trabajo est

regido de acuerdo a las especificaciones y contratos establecidos por elcliente. 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


9/47

8.1.2 Organizacin del Especialista en SQAEs 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 elcliente 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

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 ClienteLa organizacin del cliente depende de la estructura de su empresa o de

la funcin que realice. Vara de acuerdo al proyecto de software que seest desarrollando.

8.1.4 Organizacin del Grupo SQAEs 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

GerenteGeneral

Expertos enProyectos

Departamentode Informatica

Secretaria


10/47

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 TareasLa relacin de tareas asociadas con el ciclo de vida de desarrollo de

software y las actividades de la SQA son las siguientes, las cuales seejecutarn 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

productos

Informe de revisin de SQA

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


11/47

CICLO DE VIDA DELSOFTWARE (PUDS)

TAREAS Y ACTIVIDADES ASOCIADAS ALCICLO DE VIDA DEL SOFTWARE

Requerimientos

Capturar de requisitos de software

Generacin de especificaciones

Revisin de especificaciones

Revisin de las especificaciones de software

Anlisis

Anlisis de las especificaciones

Revisin del anlisis

Anlisis detallado

Revisin del anlisis detallado del software

Diseo

Diseo preliminar

Generacin de especificaciones de diseo

preliminar

Revisin del diseo preliminar

Diseo detallado

Generacin de especificaciones de diseo

detallado

Revisin del diseo detallado

Revisin del diseo preliminar

Revisin del diseo detallado del software

(Ambos versus las especificaciones)

Implementacin

Codificacin

Generacin de cdigo

Revisin de cdigo


12/47

Revisin de cdigo versus la documentacin

generada

Pruebas

Elaboracin de pruebas de unidad y

generacin de resultadosRevisin 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 yevaluacin de los resultados

Instalacin y PruebaFinal

Instalacin del producto software

Prueba final bajo ambiente real

Generacin de resultados de prueba

Revisin de resultados

Revisin de la instalacin del software y

evaluacin de

Resultados


13/47

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

8.3 ResponsabilidadesEl 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 losproductos que se consideren relevantes para la calidad del producto y delproceso. A continuacin se identifican esos productos y el responsable de lasacciones correctivas para eliminar los defectos de cada producto.

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

Realizar Revisin Tcnica FormalInforme de Revisin Tcnica

Formal

Evaluar y ajustar el Plan de SQADocumento de Evaluacin y

Ajustes al Plan de SQA

Evaluacin final de SQA Informe final de SQA

Revisar la entrega semanal Entrega semanal de SQA


14/47

Producto Rol responsable ResponsableDocumento de RequerimientosModelo de Casos de UsoAlcance del SistemaDescripcin de la ArquitecturaModelo de Diseo

Modelo de DatosEstndar de ImplementacinEstndar de documentacintcnicaDocumento de EstimacionesDocumento de RiesgosPlan del ProyectoPlan de Verificacin y ValidacinReporte de pruebas unitarias, deintegracin y del SistemaPlan de ImplantacinEstndar de Documentacin de

UsuarioDocumentacin de UsuarioPlan de Gestin de Configuracin

9 Documentacinse 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 yverificacin, mantenimiento y uso del software.


15/47


16/47

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) DDSLa generacin y documentacin de la descripcin del diseo de Software

se basa en el estndar ANSI / IEEE Std 1016 RECOMMENDED PRACTICE

FOR SOFTWARE DESCRIPTIONS


17/47

VISTA DEDISEO

ALCANCE ATRIBUTOSDE ENTIDAD

EJEMPLOS DEREPRESENTACIONES

Descripcin dedescomposicin

Particin delsistema dentrode entidades dediseo.

Identificacin,tipo, objetivo,funcin,subordinacin.

Diagrama dedescomposicin,

jerarqua y lenguajenatural.

Descripcin dedependencia

Descripcin delas relaciones

entre entidades yrecursos del

Identificacin,tipo, objetivo,

dependencias,recursos.

Diagrama deestructura.

Descripcin deinterfaces

Lista de cadainterfaz dediseador,programador, opruebas

Identificacin,funcin,interfaces.

Tablas de parmetros.

Descripcin dedetalle

Descripcin delos detalles dediseo internosen una entidad.

Identificacin,procesamiento,datos.

Diagrama de flujos.


18/47

9.2.1 MODELO A USAR PARA EL CONTENIDO DEL DDS

1. INTRODUCIONObjetivoAlcanceDefiniciones, acrnimos y abreviaciones

2. REFERENCIAS3. DESCRIPCION DE DESCOMPOSICION

3.1. Descomposicin de mdulo

3.1.1. Descripcin del mdulo 1


3.1.n. Descripcin del mdulo n3.2. Descomposicin de procesos concurrentes

3.2.1. Descripcin del proceso 1


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 DEPENDENCIADependencia entre mdulos

Dependencia entre procesosDependencia entre datos

5. DESCRIPCION DE INTERFACESInterfaces de mdulo




19/47

5.1.n. Descripcin del mdulo n

5.2 Interfaces de procesos



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


20/47

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. OBJETIVO2. ALCANCE3. DEFINICIONES, ACRONIMOS Y ABREVIACIONES4. ORGANIZACIN RESPONSABLES5. CICLO DE VIDA DE VERIFICACION Y VALIDACION

APENDICE

INDICELa 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 VerificacionEl formato para los reportes de los resultados de la implementacin del plan

de verificacin y validacin del software es la siguiente:


21/47

6.4.1 Reporte sumario de fases SVVP.


22/47

9.4.2 Reporte de Anomalas.


23/47

6.4.3 Reporte Final SVVP.


24/47

9.5 Documento de UsuarioEsta 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.


25/47

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 DEUSUARIO

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


26/47

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 DEERROR

ANEXOS

10. BIBLIOGRAFIA

11. GLOSARIO

12. INDICE


27/47

9.6 Plan de Gestion de Configuracion (SCMP)La gestin de configuracin del software es una actividad de

autoproteccin que seaplica durante el proceso del software. Como elcambio 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 ProyectoLa gestin de un proyecto de software comienza con un conjunto de

actividades que globalmente se denominanplanificacin del proyecto. Antes deque el proyecto comience, el gestor y el equipo de software deben realizar unaestimacin del trabajo a realizar, de recursos necesarios y del tiempo quetranscurrir desde el comienzo hasta el final de su realizacin. Siempre que


28/47

estimamos, estamos mirando hacia el futuro y aceptamos resignados ciertogrado de incertidumbre.

9.7.1 MODELO A USAR PARA EL CONTENIDO DEL PLAN DE PROYECTO1PLAN DE PROYECTO

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

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

4GESTIN DE RIESGO

4.1 Tabla de Riesgos

4.2Plan RSGR para cada

4.2.1Reduccin de Riesgo


29/47

4.2.1 Supervisor del Riesgo

5PLANIFICACIN TEMPORAL

6 RECURSOS DEL PROYECTO

7ORGANIZACIN DEL PERSONAL7.1 Estructura del Equipo

8MECANISMOS DE SEGUIMIENTO Y CONTROL

8.1 Formularios para RTF

8.2 Recurso

10Estndares, prcticas y convencionesse identifican los estndares definidos para el proyecto, como normas dedocumentacin, de cdificacin, notacin UML, normas IEEE que aplican,

etc. y de que forma se asegurar el cumplimiento de los mismos.

10.1Estndares 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.2Estndar 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 programao Objetivoo Nombre de las entradas:


30/47

- 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 autoro Fecha de creacino 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


31/47

10.3Estndar 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.4Responsabilidades 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.

11Revisiones del software11.1PropsitoLos responsables de estas revisiones es la organizacin del SQA, con la

participacin de todo elemento de la organizacin que tengan que ver con losrequerimientos, 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:


32/47

11.2Requerimientos MnimosLos 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 AgendaEn 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 delentregable o productoa revisar

Fase, iteraciny semana enque se deberealizar laversin delproducto arevisar

Semana, si sequiere tambinla fecha, en laque se realizarla revisin delentregable oproducto

Tipo derevisin quese realizar:Evaluacin dela calidad delos productos,

Revisar elajuste alproceso oRevisinTcnicaFormal


33/47

.

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

11.3.1 Revisar cada producto11.3.1.1Auditoria Funcional:

Esta verificacin es realizada antes de la entrega del software, para

verificar que todos los requerimientos especificados en la ERS fueronalcanzados.

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


34/47

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.2Auditoria 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 asociadaPara 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


35/47

11.3.1.3Auditorias 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.4Revisiones 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.


36/47

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 proceso11.3.2.1Evaluacin 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 alos 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


37/47

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


38/47

11.3.4 Realizar Revisin Tcnica FormalObjetivo: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 dedesarrollo. 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.

12Testeose 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 correctivaEn 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.


39/47

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


40/47

REPORTE FINAL DE PROBLEMAS Pg.

......

# De Reporte:

Lugar:

Fecha: / ./_

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


41/47

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 lasposibilidades, 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 identificadasanteriormente

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.


42/47

14Herramientas, tcnicas y metodologasEn 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.

15Control de cdigoEn 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.


43/47

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.

16Control de mediosEl 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.

17Recopilacin de registros, mantenimiento y retencinLas 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.


44/47

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

18FormacinCIS 740 Software Engineering

CIS 748 Software Management

CIS 771 Software Specifications

CIS 890 Agent-Oriented Software Engineerin


45/47

19Gestin de RiesgosRiesgos

Probabilidad de

Presencia

Probabilida

d de

Impacto

R1. El tamao estimado es menor al tamao

real del software.45% Influyente

R2. El personal no cuenta con la debida

experiencia.60% Crtico

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

utilizacin del sistema.40% Moderado

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 laprevista

25% Influyente

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:


46/47

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.


47/47

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.

Documents

Contenido sqap