Calidad de Software PDF

Calidad de
Software
2
CARRERAS PROFESIONALES CIBERTEC

CALIDAD DE SOFTWARE 3
NDICE Pgina
Presentacin 7
Red de contenidos 8
Unidad de aprendizaje 1
1.1 Tema 1 : Calidad de Software 10

1.1.1. : Definicin de Calidad 10
1.1.2. : Poltica de Calidad 11
1.1.3. : Terminologa segn ISO 8402 11
1.1.4. : Definicin de Calidad de Software 13
1.2 Tema 2 : Aseguramiento y Control de Calidad 20
1.2.1. : SQA (Software Quality Assurance) no es lo mismo que 21
SQC (Software Quality Control)
1.2.2. : Funciones Generales del SQA 22
1.3 Tema 3 : Modelo de Procesos 25
1.3.1. : El Proceso de Desarrollo de Software 27
1.3.2. : Normas Relacionados con el Proceso de Desarrollo de 30
Software
1.3.3. : Los Procesos ISO 12207:2008 34
1.4 Tema 4 : Modelo de Ciclo de Vida de Software 35
1.4.1. : Codificar y Corregir (Code-and-Fix) 35
1.4.2. : Modelo en Cascada 35
1.4.3. : Desarrollo Evolutivo 37
1.4.4. : Desarrollo Formal de Sistemas 38
1.4.5. : Desarrollo Basado en Reutilizacin 39
1.4.6. : Procesos Iterativos 40
1.4.7. : Cul es el modelo de procesos ms adecuado? 42
CIBERTEC CARRERAS PROFESIONALES

4
1.5 Tema 5 : Verificacin y Validacin 44

1.5.1. : Verificacin 44
1.5.2. : Validacin 44
1.5.3. : Ventajas de las Revisiones de Software 45
1.5.4. : Desventajas de las Revisiones de Software 45
1.5.5. : Revisiones Informales y Formales 45
2.1 Tema 6 : Modelos de Calidad de Software 85

2.1.1. : Introduccin 86
2.1.2. : Perspectivas de Calidad 86
2.1.3. : Calidad desde el Punto de Vista del Proceso 87
2.1.4. : Calidad desde el Punto de Vista del Producto 88
2.1.5. : Calidad desde el Punto de Vista de las Personas 89
2.2 Tema 7 : Mtricas de Calidad de Producto Software 90
2.2.1. : ISO/IEC 9126-1 Modelo de Calidad 91
2.2.2. : ISO/IEC 9126-2 Mtricas Externas 93
2.2.3. : ISO/IEC 9126-3 Mtricas Internas 93
2.2.4. : Relacin entre las Mtricas Internas y Externas 94
2.2.5. : ISO/IEC 9126-4 Mtricas para Calidad en Uso 95
2.2.6. : ISO/IEC 25000:2005 SquaRE 96
2.3 Tema 8 : Evaluacin de Mtricas 98
2.3.1. : Definiciones 98
2.3.2. : Proceso de Evaluacin 98
3.1 Tema 9 : Pruebas de Software 105

3.1.1. : Principios Generales de las Pruebas 106
3.2 Tema 10 : Ciclo de Vida de las Pruebas 108
3.2.1 Planeacin y Control de Pruebas 108
3.2.2 Anlisis y Diseo de las Pruebas 108

3.2.3 Implementacin y Ejecucin de Pruebas 109

3.2.4 Evaluacin de Criterios de Salida y Reportes 109
3.2.5 Cierre de Pruebas 109
3.3 Tema 11 : Estrategia de Pruebas 111
3.3.1 Casos de Prueba 111
3.3.2 Diseo de Casos de Prueba 113
3.3.3 Realizar Casos de Prueba 116
3.3.4 Informe y Seguimiento de Pruebas 118
3.3.5 Relacin entre las Pruebas y la Depuracin 120

6

PRESENTACIN
Calidad de Software pertenece a la lnea formativa y se dicta en la carrera de

Computacin e Informtica y de Administracin y Sistemas. Brinda los conceptos
fundamentales de calidad que deben ser considerados en los proyectos de
desarrollo de sistemas de software.
El manual para el curso ha sido diseado bajo la modalidad de unidades de

aprendizaje, las que se desarrollan durante semanas determinadas. En cada una
de ellas, hallar los logros, que debe alcanzar al final de la unidad; el tema
tratado, el cual ser ampliamente desarrollado; y los contenidos, que debe
desarrollar, es decir, los subtemas. Por ltimo, encontrar las actividades que
deber desarrollar en cada sesin, que le permitirn reforzar lo aprendido en la
clase.
El curso tiene un formato terico prctico. Los conceptos desarrollados son

aplicados en el proyecto Integrado de Quinto Ciclo, desarrollado en el curso de
Desarrollo de Aplicaciones Web 1, y se complementa con los temas del curso de
Gestin de Proyectos de TI. Los conceptos y las tcnicas de control de calidad
se implementan tambin en el curso de Anlisis y Diseo de Sistemas III de la
carrera de Administracin y Sistemas, con verificaciones de entregables
previamente establecidos.
.

8
RED DE CONTENIDOS
Calidad de Software
Aseguramie Mtricas de Pruebas de

nto de la Software Software
Calidad de
Software
Modelos de Calidad Pruebas de Software

Calidad de Software
de Software
Aseguramiento y Mtricas de Calidad Ciclo de Vida de las

Control de Calidad de Productos de Pruebas
Sofware
Modelo de Procesos Estrategia de Pruebas
Evaluacin de
Mtricas
Modelos de Ciclo de
Vida de Software
Verificacin y
Validacin
UNIDAD DE
APRENDIZAJE

CALIDAD DE SOFTWARE
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad de aprendizaje, el alumno disea la lista de verificacin

del Reporte de Especificacin de Software y el Plan de Desarrollo
considerando los requerimientos previamente definidos por el Lder Usuario
para el proyecto integrado de quinto ciclo.
TEMARIO
1.1. Tema 1: Calidad de Software

1.1.1. Definicin de Calidad
1.1.2. Poltica de Calidad
1.1.3. Terminologa segn ISO 8402
1.1.4. Definicin de Calidad de Software
1.1.4.1. Control de Calidad
1.1.4.2. Aseguramiento de Calidad
1.2. Tema 2: Aseguramiento y Control de Calidad

1.2.1. SQA (Software Quality Assurance) no es lo mismo que SQC (Software
Quality Control)
1.2.2. Funciones Generales del SQA
1.3. Tema 3: Modelo de Procesos

1.3.1. El Proceso de Desarrollo de Software
1.3.2. Normas Relacionadas con el Proceso de Desarrollo de Software
1.3.2.1. Conceptos Clave
1.3.2.2. Ciclos de Vida, Procesos, Productos
1.3.3. Los Procesos ISO 12207:2008
1.4. Tema 4: Modelo de Ciclo de Vida de Software

1.4.1. Codificar y Corregir (Code-and-Fix)
1.4.2. Modelo en Cascada
1.4.3. Desarrollo Evolutivo
1.4.4. Desarrollo Formal de Sistemas
1.4.5. Desarrollo Basado en Reutilizacin
1.4.6. Procesos Iterativos
1.4.6.1. Desarrollo Incremental
1.4.6.2. Desarrollo en Espiral
1.4.7. Cul es el modelo de procesos ms adecuado?
1.5. Tema 5: Verificacin y Validacin de Software

1.5.1. Verificacin
1.5.2. Validacin
1.5.3. Ventajas de las Revisiones de Software
1.5.4. Desventajas de las Revisiones de Software
1.5.5. Revisiones Informales y Formales

10
1.1. CALIDAD DE SOFTWARE

Los conceptos relacionados con la calidad de software tienen relacin directa
con la aplicacin de la calidad a un producto desarrollado a travs de procesos
de ingeniera de software. En tal sentido empezaremos dando algunas
definiciones de calidad y luego ampliaremos el concepto hacia calidad de
software.
1.1.1. Definicin de Calidad

Existen muchas definiciones de calidad y muchos trminos que se utilizan

en la gestin de la misma.
Para la ISO 8402 (International Standard Organization), complemento de

normas de las series de normas ISO 9000, define La Calidad como: "El
conjunto de caractersticas de una entidad que le confieren la aptitud para
satisfacer las necesidades establecidas e implcitas.
Tambin podra decirse que es la conformidad con los requisitos y el

grado de excelencia. En un servicio la calidad se define como la
diferencia entre la percepcin del servicio y la expectativa que el cliente
tena del mismo. Calidad tambin es la satisfaccin del cliente.
La calidad la definen los clientes, por lo que la oferta deber estar de

acuerdo los lo que ellos definen (sus exigencias) y entonces deber
producirse exactamente lo que dichos clientes desean, en el plazo
convenido y al mnimo costo e incluso anticiparse a sus necesidades
satisfaciendo sus expectativas, lo que dar una ventaja competitiva frente
a la competencia.
La calidad no solo hace referencia a que un producto o servicio se ajuste

a las exigencias. La percepcin que los clientes tienen sobre su empresa
est basada en el producto o servicio que les suministra, pero tambin en
el contacto diario que mantienen con los directivos. El concepto de
calidad abarca no slo como se atienden las exigencias de sus clientes
sino tambin la forma en que se hace, cmo se atiende el telfono, la
rapidez con que se satisfacen consultas, tener nuevos servicios cuando
se los requiere, asegurarse que la factura que sale de la empresa es la
correcta. Cada contacto, llamados momentos de la verdad con el cliente,
muestra un reflejo de la compaa a los ojos de ese cliente.
El recepcionista que atiende las llamadas, los agentes de seguridad que

controlan los accesos, los ascensoristas que transportan a la gente y la
orientan, los administrativos que envan las facturas, los dictmenes de
los abogados, todos deben involucrarse en el concepto de calidad, en
satisfacer las exigencias del cliente, en crear una compaa con clase
reconocida. La calidad es un concepto objetivo que cada empleado puede
comprender y evaluar, y sobre el cual puede asumir responsabilidades.
La nica forma de alcanzar el objetivo de calidad es:
1. Comprender las exigencias de los clientes externos.

2. Conocer a fondo los procesos internos que le permitan satisfacer esas
exigencias.
3. Desarrollar un sistema y cultura empresarial que le aseguren que los
errores son evitados o eliminados
1.1.2. Poltica de Calidad

ISO 8402 la define como: "Directrices y objetivos generales de una
empresa relativos a la calidad, expresados formalmente por la Direccin
General". Es una de las vas para hacer operativa la estrategia. Al
desplegar verticalmente la poltica a travs de los niveles jerrquicos de la
organizacin:

12
Se proporciona orientacin precisa para que ejecutivos y mandos

elaboren planes concretos de accin.
Se cohesiona la organizacin para el cumplimiento de los objetivos
de calidad.
Se refuerza el compromiso del personal.
La poltica de calidad debe ser:
Adecuada a la empresa.
Coherente con las necesidades y expectativas de sus clientes.
Muy simple y fcilmente comprensible para que sea comunicable y
entendida sin dificultad.
En cuanto a su contenido, debera hacer referencia a:
Los grandes objetivos de la empresa.

Los colectivos que en ella conviven: personal, accionistas, clientes,
proveedores.
La disponibilidad de los recursos necesarios; por ejemplo, formacin.
La va a utilizar (ISO, Mejora Continua, etc.).
Es la totalidad de aspectos y caractersticas de un producto o servicio que

se refieren a su capacidad para satisfacer necesidades dadas en la
adecuacin de sus objetivos'.
El Instituto de Ingeniera de Software (SEI) en su modelo CMM define la

calidad como:
El grado en el cual un sistema, componente o proceso cumple con los
requisitos especificados.
El grado en el cual el sistema, componente o proceso cumple con las
expectativas del cliente o usuario.
1.1.3. Terminologa segn ISO 8402

1. Calidad: Conjunto de propiedades y caractersticas de un producto o
servicio que le confieren su aptitud para satisfacer unas necesidades
explicitas o implcitas.
2. Control de Calidad: Conjunto de tcnicas y actividades de carcter
operativo, utilizadas para verificar los requerimientos relativos a la
calidad del producto o servicio.
3. Garanta de Calidad: Conjunto de acciones planificadas y
sistemticas necesarias para proporcionar la confianza adecuada de
que un producto o servicio cumplir los requerimientos dados sobre
calidad.
4. Gestin de Calidad: Aspecto de la funcin de gestin que determina
y aplica la poltica de la calidad, los objetivos y las responsabilidades y
que lo realiza con medios tales como la planificacin de la calidad, el
control de la calidad, la garanta de calidad y la mejora de la calidad.
5. Sistema de Gestin de Calidad: Conjunto de la estructura de la
organizacin, de responsabilidades, procedimientos, procesos y
recursos que se establecen para llevar a trmino la gestin de
calidad.

El QS debe tener el volumen y alcance suficiente para conseguir

los objetivos de calidad.
El QS de una organizacin est fundamentalmente previsto para
satisfacer las necesidades internas de la organizacin. Es ms
amplio que los requerimientos de un cliente concreto que
nicamente valore el QS que le interesa (directamente).
Para finalidades contractuales o vinculantes en la valoracin de la
calidad, se puede exigir que se ponga de manifiesto la realizacin
de ciertos elementos del QS.
6. Aseguramiento de la Calidad: Es un conjunto de actividades

preestablecidas y sistematizadas, aplicadas al sistema de calidad, que
ha sido demostrado que son necesarias para dar confianza adecuada
de que un producto o servicio satisfar los requisitos para la calidad.
7. Accin Correctiva: Accin tomada para eliminar las causas de una no
conformidad, defecto o cualquier situacin indeseable existente, para
evitar su repeticin.
8. Accin Preventiva: Accin tomada para eliminar las causas de una no
conformidad, defecto o cualquier situacin indeseable potencial, con
el fin de evitar que se produzca.
9. Conformidad: Cumplimiento de requisitos especificados.
10. Costos de la no Calidad: Costos asociados con la provisin de
productos o servicios de baja calidad.
11. Defectos: No cumplimiento de un requisito o de una expectativa
razonable, ligada a un uso previsto, incluyendo los relativos a la
seguridad.
12. Inspeccin: Actividades como medir, examinar, ensayar o comparar
una o ms caractersticas de un producto o servicio, y comparar los
resultados con los requisitos especificados, con el fin de determinar la
conformidad con respecto a cada una de esas caractersticas.
13. No Conformidad: No satisfaccin de un requisito especificado.
14. Trazabilidad: Aptitud de reconstruir la historia, la utilizacin o la
localizacin de un producto por medio de identificaciones registradas.
15. Validacin: Confirmacin por examen y aporte de evidencias
objetivas de que los requisitos particulares para un uso especfico
previsto han sido satisfechos.
16. Verificacin: Confirmacin por examen y aporte de evidencias
objetivas que los requisitos especificados han sido satisfechos.

14
SISTEMA DE GESTIN DE LA
CALIDAD
MEJORA CONTINUA
C S
A
L R T
E Responsabilidad
I Q
de la Direccin I
S
E U F
I A
Gestin de Medicin,
N S
recursos anlisis y C
I C
T T
mejoramiento
I
E O
S
O
N
Realizacin
S Entrada Salida
Producto
o Servicio Producto
o Servicio
Figura 1.1 - Sistema de Gestin de Calidad
1.1.4. Definicin de Calidad de Software

La Calidad del Software es el conjunto de cualidades que lo caracterizan y
que determinan su utilidad y existencia.
Segn R. Pressman: La calidad del software se define como la

concordancia con los requisitos funcionales y de rendimiento
explcitamente establecidos, con los estndares y procesos de desarrollo
explcitamente documentados y con las caractersticas implcitas que se
espera de todo software desarrollado profesionalmente.
No hay duda de que la anterior definicin puede ser modificada o

ampliada. De hecho, no tendra fin una discusin sobre una definicin
definitiva de la calidad del software. Para los propsitos de este enfoque,
la anterior definicin sirve para hacer hincapi en tres puntos importantes:
1. Los requisitos del software son la base de las medidas de la calidad.
La falta de concordancia con los requisitos es una falta de calidad.
2. Los estndares especificados definen un conjunto de criterios de

desarrollo que guan la forma en que se aplica la ingeniera del
software o del conocimiento. En caso de no seguirse esos criterios,
casi siempre habr falta de calidad.
3. Existe un conjunto de requisitos implcitos que a menudo no se

mencionan (por ejemplo la necesidad de una interfaz intuitiva). Si el
software se ajusta a sus requisitos explcitos pero falla en alcanzar los
requisitos implcitos, la calidad del software se debilita.
Queda claro a partir de la definicin de calidad del software, que sta es

siempre relativa a los requisitos o necesidades que se desea satisfacer.
Por eso la evaluacin de la calidad del software siempre va a implicar la
comparacin entre los requisitos y el producto generado.

La Calidad del Software es medible y vara de un sistema a otro o de un

programa a otro. Por ejemplo: un software elaborado para el control de
naves espaciales debe ser confiable al nivel de "cero fallas"; un software
hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad;
mientras que un producto de software para ser explotado durante un largo
perodo (10 aos o ms) necesita ser confiable, mantenible y flexible para
disminuir los costos de mantenimiento y perfeccionamiento durante el
tiempo de explotacin.
La Calidad del Software puede medirse despus de elaborado el

producto. Pero esto puede resultar muy costoso si se detectan problemas
derivados de imperfecciones en el diseo, por lo que es imprescindible
tener en cuenta tanto la obtencin de la calidad como su control durante
todas las etapas del ciclo de vida del software.
Existen varios factores que determinan la calidad del software y la

eficiencia de la organizacin, entre ellos estn la complejidad del
producto, las tecnologas y las personas, as como algunas condiciones
de entorno que tambin tienen su impacto, estas pueden ser condiciones
de gestin (plazo de entrega, restricciones dentro de la organizacin),
entornos de desarrollo y caractersticas del cliente, sin embargo en el
centro de todas ellas se encuentra el proceso. El proceso es el nico
factor de los controlables al mejorar la calidad del software y su
rendimiento en la organizacin. Analizando y mejorando el proceso se
puede obtener mejores productos.
Figura 1.2 - Determinantes de la calidad del software y de la efectividad de

la organizacin
Los ejes de desarrollo de software se relacionan con la calidad de la

siguiente forma:
1. Persona: PSP, TSP

2. Producto: McCall, Boehm, ISO/IEC 9126-1
3. Proceso: CMM, ISO/IEC 15504
4. Mejora continua del proceso: IDEAL, ISO/IEC 15504, SPI
Por lo tanto:

16
Figura 1.3 - Dependencia entre Calidad de Producto y Calidad de Proceso
1.1.4.1. Control de Calidad:

Para controlar la Calidad del Software es necesario, definir los
parmetros, indicadores o criterios de medicin.
El software posee determinados ndices medibles que son las

bases para la calidad, el control y el perfeccionamiento de la
productividad.
Una vez seleccionados los ndices de calidad, debe establecerse

el proceso de control, que requiere los siguientes pasos:
1. Definir el software que va a ser controlado: clasificacin por

tipo, mbito de aplicacin, complejidad, etc., de acuerdo
con los estndares establecidos para el desarrollo del
software.
2. Seleccionar una medida que pueda ser aplicada al objeto de
control. Para cada clase de software es necesario definir los
indicadores y sus magnitudes.
3. Crear o determinar los mtodos de valoracin de los
indicadores: mtodos manuales como cuestionarios o
encuestas estndares para la medicin de criterios parciales
y herramientas automatizadas para medir los criterios de
clculo.
Los procedimientos pueden variar en cada organizacin, pero lo

importante es que estn escritos, personalizados, adaptados a
los procesos de la organizacin y, lo que es ms importante, que
se cumplan. La Calidad del Software debe implementarse a lo
largo de todo el ciclo de vida, debe correr paralela desde la
planificacin del producto hasta la fase de produccin del mismo.

Para ello se cuenta con una serie de ayudas, a travs de

distintas actividades para la implantacin del control de calidad
en el desarrollo que son:
Aplicacin de metodologa y tcnicas de desarrollo
Reutilizacin de procesos de revisin formales
Prueba del software
Ajustes a los estndares de desarrollo
Control de cambios, mediciones y recopilacin de
informacin
Gestin de informes sobre el control de calidad
Para la fase de Planificacin, se pueden utilizar elementos y

herramientas propias de la Gestin de proyectos, como la:
Estimacin de la duracin, costo y esfuerzo para la
construccin del producto. En lo referido a la estimacin
habr que tener presentes las Mtricas de software
Planificacin de tareas que hay que realizar, asignacin de
personas, tiempo, costo y otros parmetros para
construccin del producto
Para los procesos de Anlisis y Diseo deberemos contar con:

Sistemas de obtencin de requisitos
Mtricas de software
Herramientas de Generacin de Datos
Casos de Prueba
En los procesos de Construccin y pruebas deberamos usar:

Herramientas de Gestin de la Configuracin
Herramientas de Simulacin
Casos de Pruebas
Y, finalmente, para el proceso de Produccin, bsicamente

debemos utilizar:
Herramientas de monitoreo de resultados
Pruebas de produccin
Definir las regulaciones organizativas para realizar el control: quienes

participan en el control de calidad, cundo se realiza, qu documentos
deben ser revisados y elaborados, etc.
El Instituto de Ingeniera de Software (SEI) en su modelo CMM define la

calidad como:
El grado en el cual un sistema, componente o proceso cumple con los

requisitos especificados.
El grado en el cual el sistema, componente o proceso cumple con las
expectativas del cliente o usuario.

18
1.1.4.2. Aseguramiento de Calidad:

Es el conjunto de actividades planificadas y sistemticas
necesarias para aportar la confianza adecuada en que el
producto (software) satisfacer los requisitos dados de calidad.
El aseguramiento pretende dar confianza en que el producto
tiene calidad.
Aseguramiento de calidad se enfoca en identificar y evaluar los

defectos que puedan afectar al software. Si los errores se
pueden identificar de forma temprana en el proceso de software,
las caractersticas del diseo de software se pueden especificar
de modo que eliminarn o controlarn los peligros potenciales, al
corregir los errores mucho antes en cada etapa es decir durante
el proceso, ahorrando esfuerzos, tiempo y recursos.
Sridharan (Sridharan, 2000) indica que mientras el software que

se est desarrollando rene los requerimientos y su desempeo
sea el esperado, es preciso que se supervisen las actividades de
desarrollo del software y su rendimiento, en distintas
oportunidades durante cada fase del ciclo de vida. Este es el
papel del aseguramiento de la calidad del software.
Hay tres aspectos muy importantes con relacin al

aseguramiento de la calidad del software: (Wiegers, 1990)
i) La calidad no se puede probar, se construye.
ii) El aseguramiento de la calidad del software no es una tarea

que se realiza en una fase particular del ciclo de vida de
desarrollo.
iii) Las actividades asociadas con el aseguramiento de la calidad

del software deben ser realizadas por personas que no estn
directamente involucradas en el esfuerzo de desarrollo.
El aseguramiento de la calidad de software comprende una gran

variedad de tareas:
i) Participar en descripcin del proyecto de software.
ii) Auditar el producto de software para verificar el cumplimiento

del proceso de software definido.
iii) Asegurar que las divergencias en el trabajo de software sean

documentadas de acuerdo a los estndares definidos.
iv) Almacenar cualquier inconformidad y reportarla a la gerencia

media.
v) Revisiones del software que se aplican durante cada paso del

desarrollo del mismo. Las revisiones del software se aplican
en varios momentos del desarrollo, tanto en el anlisis como
en el diseo y la codificacin, de manera que puedan ser
eliminados cuanto antes.

vi) Gestin de configuraciones de software (control de la

documentacin del software y de los cambios realizados). El
proceso de control de cambios contribuye directamente a la
calidad del software.
Figura 1.4 - Componentes del Aseguramiento de Calidad de Calidad (SQA)
El grupo de aseguramiento de calidad participa en la revisin de

los productos seleccionados para determinar si se conforman o
no a los procedimientos, normas o criterios especificados, siendo
totalmente independiente del equipo de desarrollo.
Las actividades a realizar por el grupo de aseguramiento de

calidad vienen gobernadas por el plan. Sus funciones estn
dirigidas a:
i) Identificar las posibles desviaciones en los estndares

aplicados, as como en los requisitos y procedimientos
especificados.
ii) Comprobar que se han llevado a cabo las medidas

preventivas o correctivas necesarias.
iii) Las revisiones son una de las actividades ms importantes

del aseguramiento de la calidad, debido a que permiten
eliminar defectos lo ms pronto posible, cuando son menos
costosos de corregir.
Es importante sealar que la calidad de un producto software no se puede

referir nicamente a obtener un producto sin errores. La especificacin de
la calidad del software debe ser ms detallada y exacta, y el camino para
ello es la formalizacin de la calidad mediante un modelo de calidad.
Un modelo de calidad es un conjunto de buenas prcticas para el

desarrollo del software, enfocado en los procesos de gestin y desarrollo
de proyectos, cuyo objetivo es el desarrollo de productos de calidad de
manera consistente y predecible.

20
Existen distintos marcos de trabajo que nos ayudan a mejorar los

procesos de calidad de software. La finalidad de estos modelos es la de
mejorar los procesos de software, brindar pautas para efectuar
evaluaciones de la unidad informtica, determinar la potencialidad y la
efectividad de sus procesos, as como la madurez de la empresa. Se
busca mejorar los procesos de software, aumentar la productividad la
calidad reduciendo su costo.

1.2. ASEGURAMIENTO Y CONTROL DE CALIDAD
La Administracin de la Calidad, es un rea de conocimiento de todo proyecto,

que incluye tres fases bien identificadas: la Planificacin, el Aseguramiento y el
Control.
El proceso de Planificacin de la Calidad en todo proyecto, toma como

entradas las Polticas de Calidad de la compaa, el informe de Alcance del
proyecto, la descripcin del sistema (producto/s), normas, regulaciones y
estndares que deben aplicarse, para producir como salidas un Plan de
Direccin de Calidad, definiciones operativas y check-lists utilizadas por los
procesos de Aseguramiento y Control de Calidad.
Para ello se utilizan como herramientas el Anlisis de costo-beneficio,

diagramas de flujo, los diagramas de causa-efecto (Ishikawa), o el
Benchmarking. Esta fase es la ms importante en cuanto a calidad se refiere,
porque se identifican posibles cuellos de botella, duplicacin del trabajo o
problemas de seguridad, y se ofrecen soluciones dentro del Plan de Calidad.
El Control de la Calidad comprende el seguimiento de los resultados

especficos del proyecto para determinar si cumplen con las normas de calidad,
e identificar la forma de eliminar los resultados insatisfactorios.
Por lo tanto SQA o Software Quality Assurance, es el proceso de asegurar la

calidad, aplicado al software, que debe realizarse a lo largo de todos los
procesos de fabricacin: desde el anlisis de requerimientos hasta la puesta en
produccin.
Al igual que ocurri con la definicin de calidad hay varios puntos de vista
desde donde se puede definir el aseguramiento de la calidad del software.
Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la

calidad como:
Una gua planificada y sistemtica de todas las acciones necesarias para

proveer la evidencia adecuada de que un producto cumple los requerimientos
tcnicos establecidos. Un conjunto de actividades diseadas para evaluar el
proceso por el cual un producto es desarrollado o construido.
Daniel Galin define SQA como:
Un conjunto, sistemtico y planificado, de acciones necesarias para proveer la

evidencia adecuada de que el proceso de desarrollo o mantenimiento de un
sistema de software cumple los requerimientos tcnicos funcionales tan bien
como los requerimientos gerenciales para cumplir la planificacin y operar
dentro del presupuesto confinado.
Desde el punto de vista de la visibilidad, el SEI define SQA como
El aseguramiento de la calidad del software provee claro control del proceso

que est siendo usado por el proyecto y del producto que se est
construyendo.

22
Desde el punto de vista del aseguramiento, Don Reifer define SQA como
El aseguramiento de la calidad del software es el sistema de mtodos y

procedimientos usados para asegurar que el producto de software alcanza sus
requerimientos. El sistema involucra la planificacin, estimacin y monitoreo de
las actividades de desarrollo realizadas por otros.
Desde el punto de vista de la capacidad de uso Schulmeyer y McManus

definen SQA como
Las actividades sistemticas que proveen evidencia de la capacidad o

disponibilidad de uso del producto de software total.
1.2.1. SQA (Software Quality Assurance) no es lo mismo que SQC

(Software Quality Control)
Generalmente cuando le preguntamos a un profesional de sistemas que
es lo que entiende por aseguramiento de la calidad del software,
inmediatamente comienza a hablar de testing, algunos de ellos incluyen
a la validacin y verificacin y luego empiezan a hablar de revisiones,
las cuales son slo extensiones del testing. Es decir, a menudo hay una
confusin entre SQA y el testing (el cual actualmente forma parte del
rea de control de calidad del software SQC).
Haciendo slo testing y revisiones no aseguramos la calidad de los

productos, sino aseguramos el cumplimiento de especificaciones tanto
funcionales como tcnicas. En el desarrollo de software la diferencia
entre SQC y SQA no est clara y estos trminos a menudo se
confunden, SQA se encarga de controlar el cumplimiento del proceso,
mientras que SQC son aquellas acciones del aseguramiento de la
calidad que proporcionan un medio para controlar y medir las
caractersticas de un elemento, proceso o facilidad respecto a los
requisitos establecidos.
La Tabla 1 muestra las diferencias entre Aseguramiento de la calidad

(SQA) y Control de calidad (SQC)
SQA SQC
Asegura la adherencia a los Detecta problemas en los
procesos, estndares y productos de trabajo.
planes.
Evala que los procesos, Verifica que los productos
planes y estndares de trabajo cumplan con los
utilizados en el proyecto estndares de calidad
cumplan con los estndares especificados en el plan de
organizacionales proyecto.
Revisa procesos Revisa el contenido del
producto
Tabla 1 Diferencia entre SQA y SQC
En conclusin, el rol del SQA es auditar que los distintos equipos de

la organizacin, inclusive el de SQC siguen los procedimientos,
estndares y procesos establecidos. El equipo de SQA debera

establecer mtricas para medir la efectividad del proceso. Como

complemento el rol de SQC es tomar una actitud activa de
verificacin y validacin del resultado o salida del proceso
implementado.
1.2.2. Funciones Generales del SQA

Describir los diferentes roles que puede jugar el equipo de SQA en
una organizacin nos dar una visin clara de las funciones que
puede llevar a cabo.
Como polica del proceso

El trabajo del equipo de SQA es asegurar que el desarrollo sigue el
proceso establecido.
Entre sus funciones en este rol se encuentran:

Auditar los productos del trabajo para identificar deficiencias.
Determinar el cumplimiento del plan de desarrollo del proyecto y
del proceso de desarrollo de software.
Juzgar el proceso y no el producto.
Como abogado del cliente

El trabajo del equipo de SQA es representar al cliente.

Identificar la funcionalidad que al cliente le gustara encontrar.
Ayudar a la organizacin a sensibilizarse con las necesidades del
cliente.
Actuar como un cliente de prueba para obtener una alta
satisfaccin del cliente.
Como analista
El trabajo del equipo de SQA es recabar informacin.

Juntar muchos datos sobre todos los aspectos del producto y del
proceso.
Con esta informacin ayudar a mejorar los procesos y los
productos.
Como proveedor de informacin

El trabajo del equipo de SQA es revisar qu es lo que est hecho y
decir cules objetivos tcnicos realmente estn cumplidos para que
la gerencia pueda tomar mejores decisiones de negocios.

Proveer informacin tcnica objetiva para que la gerencia pueda
usarla para tomar mejores decisiones.
Proveer informacin apropiada de las clases de productos y de
los riesgos asociados con estos.
Concentrarse ms en la reduccin de los riesgos que en el
cumplimiento del proceso.

24
Como responsable de la elaboracin del proceso

El trabajo del equipo de SQA es participar en la definicin de los
planes, procesos, estndares y procedimientos para asegurar que se
ajustan a las necesidades del proyecto y que pueden ser usados
para realizar las evaluaciones de QA y cumplir los requerimientos del
proyecto y las polticas de la organizacin. Para cumplir este rol el
aseguramiento de la calidad debera comenzar en las fases
tempranas del proyecto.
Para ser efectivo, el equipo que realiza SQA debe ser independiente
de la organizacin de desarrollo. Aunque tener un grupo de auditora
independiente es difcil de aplicar en organizaciones chicas donde
hay pequeos ambientes de desarrollos. Pero si la organizacin es
madura y tiene una cultura orientada a la calidad, la funcin de SQA
puede estar embebida en el proceso. Cuando el equipo de SQA esta
embebido en el proceso, se deben resolver varios inconvenientes
para garantizar la objetividad:
Todo aquel que realice actividades de aseguramiento de la

calidad debera estar entrenado en el aseguramiento de la
calidad.
Las actividades de aseguramiento de la calidad realizadas para
un producto deberan ser separadas de aquellas involucradas en
el desarrollo y mantenimiento del mismo.
Debe estar disponible un canal de comunicacin independiente
en el nivel apropiado de la gerencia para poder escalar las no
conformidades cuando sea necesario.
El equipo de SQA provee a la gerencia de informacin fehaciente,

objetiva en el momento adecuado. La clave aqu est en que el
grupo de SQA provee a la gerencia de informacin tcnica objetiva.
La gerencia necesita ver a la gente de SQA como una fuente de
informacin significativa que puede ayudarla a tomar decisiones
difciles. La Gerencia usa esta informacin para tomar decisiones de
negocio apropiadas.
La objetividad en la evaluacin de calidad de los procesos y

productos es crtica para el xito del proyecto. La objetividad se logra
con independencia del equipo de SQA y sentido comn o criterio.
Hay diferentes maneras de realizar evaluaciones objetivas, entre las

que se incluyen:
Auditoras formales realizadas por un rea de SQA independiente

de la organizacin.
Revisiones de a pares que pueden ser realizadas con distintos
niveles de formalidad.
Revisiones rigurosas en el lugar de desarrollo.
Revisiones distribuidas y comentarios del producto.

La tarea del equipo de SQA es un conjunto planificado de tareas,

actividades y acciones ejecutadas independientemente de la
organizacin que desarrolla software, que provee a la gerencia del
proyecto informacin fehaciente en un momento preciso que puede
ser usada para tomar decisiones de negocio apropiadas

26
1.3. MODELO DE PROCESOS
Un sistema informtico est compuesto por hardware y software. En cuanto al

hardware, su produccin se realiza sistemticamente y la base de conocimiento
para el desarrollo de dicha actividad est claramente definida. La fiabilidad del
hardware es, en principio, equiparable a la de cualquier otra mquina construida
por el hombre. Sin embargo, respecto del software, su construccin y resultados
han sido histricamente cuestionados debido a los problemas asociados, entre
ellos podemos destacar los siguientes:
i) Los sistemas no responden a las expectativas de los usuarios.
ii) Los programas fallan con cierta frecuencia.
iii) Los costos del software son difciles de prever y normalmente superan las
estimaciones.
iv) La modificacin del software es una tarea difcil y costosa.
v) El software se suele presentar fuera del plazo establecido y con menos

prestaciones de las consideradas inicialmente.
vi) Normalmente, es difcil cambiar de entorno hardware usando el mismo

software.
vii) El aprovechamiento ptimo de los recursos (personas, tiempo, dinero,

herramientas, etc.) no suele cumplirse.
Segn el Centro Experimental de Ingeniera de Software (CEIS), el estudio de

mercado The Chaos Report realizado por Standish Group Internactional en
1996, concluy que slo un 16% de los proyectos de software son exitosos
(terminan dentro de plazos y costos y cumplen los requerimientos acordados).
Otro 53% sobrepasa costos y plazos y cumple parcialmente los requerimientos.
El resto ni siquiera llega al trmino. Algunas deficiencias comunes en el
desarrollo de software son:
i) Escasa o tarda validacin con el cliente.
ii) Inadecuada gestin de los requisitos.
iii) No existe medicin del proceso ni registro de datos histricos.
iv) Estimaciones imprevistas de plazos y costos.
v) Excesiva e irracional presin en los plazos.
vi) Escaso o deficiente control en el progreso del proceso de desarrollo.
vii) No se hace gestin de riesgos formalmente.
viii) No se realiza un proceso formal de pruebas.
ix) No se realizan revisiones tcnicas formales e inspecciones de cdigo.

El primer reconocimiento pblico de la existencia de problemas en la produccin

de software tuvo lugar en la conferencia organizada en 1968 por la Comisin de
Ciencias de la OTAN en Garmisch (Alemania), dicha situacin problemtica se
denomin crisis del software. En esta conferencia, as como en la siguiente
realizada en Roma en 1969, se estipul el inters hacia los aspectos tcnicos y
administrativos en el desarrollo y mantenimiento de productos software. Se
pretenda acordar las bases para una ingeniera de construccin de software.
Segn Fritz Bauer lo que se necesitaba era establecer y usar principios de
ingeniera orientados a obtener software de manera econmica, que sea fiable y
funcione eficientemente sobre mquinas reales. Esta definicin marcaba
posibles cuestiones tales como: Cules son los principios robustos de la
ingeniera aplicables al desarrollo de software de computadora? Cmo
construimos el software econmicamente para que sea fiable? Qu se necesita
para crear programas de computadora que funcionen eficientemente no en una
mquina sino en diferentes mquinas reales?. Sin embargo, dicho planteamiento
adems deba incluir otros aspectos, tales como: mejora de la calidad del
software, satisfaccin del cliente, mediciones y mtricas, etc.
El IEEE Standard Glossary of Software Engineering Terminology (Stad. 610.12-

1990) ha desarrollado una definicin ms completa para ingeniera del software:
La aplicacin de un enfoque sistemtico, disciplinado y cuantificable para el
desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de
ingeniera al software.
El estudio de enfoques en Pressman caracteriza la Ingeniera de Software como

una tecnologa multicapa, ilustrada en la Figura 3.1.
Figura 3.1 - Capas de la Ingeniera de Software
Dichas capas se describen a continuacin:
1. Cualquier disciplina de ingeniera (incluida la ingeniera del software) debe

descansar sobre un esfuerzo de organizacin de calidad. La gestin total de
la calidad y las filosofas similares fomentan una cultura continua de mejoras
de procesos que conduce al desarrollo de enfoques cada vez ms robustos
para la ingeniera del software.
2. El fundamento de la ingeniera de software es la capa proceso. El proceso

define un marco de trabajo para un conjunto de reas clave, las cuales
forman la base del control de gestin de proyectos de software y establecen
el contexto en el cual: se aplican los mtodos tcnicos, se producen
resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio
se gestiona adecuadamente.

28
3. Los mtodos de la ingeniera de software indican cmo construir

tcnicamente el software. Los mtodos abarcan una gran gama de tareas que
incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y
mantenimiento. Estos mtodos dependen de un conjunto de principios
bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de
modelado y otras tcnicas descriptivas.
4. Las herramientas de la ingeniera del software proporcionan un soporte

automtico o semi-automtico para el proceso y los mtodos, a estas
herramientas se les llama herramientas CASE (Computer-Aided Software
Engineering).
Dado lo anterior, el objetivo de la ingeniera de software es lograr productos de

software de calidad (tanto en su forma final como durante su elaboracin),
mediante un proceso apoyado por mtodos y herramientas.
A continuacin nos enfocaremos en el proceso necesario para elaborar un

producto de software.
1.3.1. El Proceso de Desarrollo de Software

Un proceso de desarrollo de software tiene como propsito la
produccin eficaz y eficiente de un producto software que rena los
requisitos del cliente. Dicho proceso, en trminos globales se muestra
en la Figura 3.2. Este proceso es intensamente intelectual, afectado por
la creatividad y juicio de las personas involucradas. Aunque un proyecto
de desarrollo de software es equiparable en muchos aspectos a
cualquier otro proyecto de ingeniera, en el desarrollo de software hay
una serie de desafos adicionales, relativos esencialmente a la
naturaleza del producto obtenido. A continuacin se explican algunas
particularidades asociadas al desarrollo de software y que influyen en su
proceso de construccin.
1. Un producto software en s es complejo, es prcticamente inviable

conseguir un 100% de confiabilidad de un programa por pequeo
que sea. Existe una inmensa combinacin de factores que impiden
una verificacin exhaustiva de las todas posibles situaciones de
ejecucin que se puedan presentar (entradas, valores de variables,
datos almacenados, software del sistema, otras aplicaciones que
intervienen, el hardware sobre el cual se ejecuta, etc.).
2. Un producto software es intangible y por lo general muy abstracto,

esto dificulta la definicin del producto y sus requisitos, sobre todo
cuando no se tiene precedentes en productos software similares.
Esto hace que los requisitos sean difciles de consolidar
tempranamente. As, los cambios en los requisitos son inevitables,
no slo despus de entregado en producto sino tambin durante el
proceso de desarrollo.
3. Adems, de las dos anteriores, siempre puede sealarse la

inmadurez de la ingeniera del software como disciplina, justificada
por su corta vida comparada con otras disciplinas de la ingeniera.
Sin embargo, esto no es ms que un intil consuelo.

Figura 3.2 - Proceso de Desarrollo de Software
4. El proceso de desarrollo de software no es nico. No existe un

proceso de software universal que sea efectivo para todos los
contextos de proyectos de desarrollo. Debido a esta diversidad, es
difcil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un

conjunto de actividades fundamentales que se encuentran presentes en
todos ellos:
1. Especificacin de software: Se debe definir la funcionalidad y

restricciones operacionales que debe cumplir el software.
2. Diseo e Implementacin: Se disea y construye el software de

acuerdo a la especificacin.
3. Validacin: El software debe validarse, para asegurar que cumpla

con lo que quiere el cliente.
4. Evolucin: El software debe evolucionar, para adaptarse a las

necesidades del cliente.
Adems de estas actividades fundamentales, Pressman menciona un

conjunto de actividades protectoras, que se aplican a lo largo de todo
el proceso del software. Ellas se sealan a continuacin:
1. Seguimiento y control de proyecto de software.
2. Revisiones tcnicas formales.
3. Garanta de calidad del software.
4. Gestin de configuracin del software.
5. Preparacin y produccin de documentos.
6. Gestin de reutilizacin.
7. Mediciones.
8. Gestin de riesgos.

30
Pressman caracteriza un proceso de desarrollo de software como se

muestra en la Figura 2.3. Los elementos involucrados se describen a
continuacin:
1. Un marco comn del proceso, definiendo un pequeo nmero de

actividades del marco de trabajo que son aplicables a todos los
proyectos de software, con independencia del tamao o
complejidad.
2. Un conjunto de tareas, cada uno es una coleccin de tareas de

ingeniera del software, hitos de proyectos, entregas y productos de
trabajo del software, y puntos de garanta de calidad, que permiten
que las actividades del marco de trabajo se adapten a las
caractersticas del proyecto de software y los requisitos del equipo
del proyecto.
3. Las actividades de proteccin, tales como garanta de calidad del

software, gestin de configuracin del software y medicin, abarcan
el modelo del proceso. Las actividades de proteccin son
independientes de cualquier actividad del marco de trabajo y
aparecen durante todo el proceso.
Figura 3.3 - Elementos del Proceso de Software
Otra perspectiva utilizada para determinar los elementos del proceso de

desarrollo de software es establecer las relaciones entre elementos que
permitan responder Quin debe hacer Qu, Cundo y Cmo debe
hacerlo.

Figura 3.4 - Relacin entre los Elementos del Proceso de Software
En la Figura 3.4 se muestran los elementos de un proceso de desarrollo

de software y sus relaciones. As las interrogantes se responden de la
siguiente forma:
1. Quin: Las Personas participantes en el proyecto de desarrollo

desempeando uno o ms Roles especficos.
2. Qu: Un Artefacto es producido por un Rol en una de sus

Actividades. Los Artefactos se especifican utilizando Notaciones
especficas. Las Herramientas apoyan la elaboracin de Artefactos
soportando ciertas Notaciones.
3. Cmo y Cundo: Las Actividades son una serie de pasos que lleva a
cabo un Rol durante el proceso de desarrollo. El avance del
proyecto est controlado mediante hitos que establecen un
determinado estado de terminacin de ciertos Artefactos.
La composicin y sincrona de las actividades est basada en un

conjunto de Principios y Prcticas. Las Prcticas y Principios enfatizan
ciertas actividades y/o la forma como deben realizarse, por ejemplo:
desarrollar iterativamente, gestionar requisitos, desarrollo basado en
componentes, modelar visualmente, verificar continuamente la calidad,
gestionar los cambios, etc.
1.3.2. Normas Relacionadas con el Proceso de Software

La calidad es un concepto que se ha difundido y establecido en diversas
actividades del quehacer humano y que se aprecia por su recurrente
utilizacin en distintos mbitos. En particular, en el campo de las
tecnologas de la informacin, se han desarrollado o se han adaptado,
de otros contextos, modelos para favorecer la adopcin de buenas
prcticas para la realizacin de los procesos del ciclo de vida del
software. Estos modelos en calidad de proceso software han
evolucionado, siendo quizs una de las ms interesantes el manejo de
los conceptos de capacidad de procesos y de madurez organizacional.
En especial, en los modelos definidos en las normas ISO/IEC 12207 e
ISO/IEC 15504 se presenta un modelo de madurez organizacional.

32
En el tema de calidad a nivel de procesos se han desarrollado diversas

propuestas para la industria en general como es el caso de los modelos:
Malcom Baldrige, EFQM e ISO 9001, entre otros; los mismos que en
alguna medida han sido utilizados por las organizaciones que
desarrollan software. Un caso particular es la ISO/IEC 90003, que es
una gua de aplicacin de la ISO 9001:2000 para el sector informtico.
En el campo de las tecnologas de informacin, relacionado a procesos

de software, se tienen una variedad creciente de propuestas y
estndares que han ido evolucionando o mejorando de acuerdo al
desarrollo tecnolgico.
Existen varios modelos que cubren diversos aspectos y han sido

desarrollados con distintos propsitos. Entre los modelos relacionados
de manera directa o indirecta con los procesos de software se pueden
mencionar: ISO/IEC 12207 (procesos del ciclo de vida de software),
CMMI (modelo de madurez y capacidad integrada, antes CMM-Sw),
RUP (Rational Unified Processes), ISO/IEC 20000 (gestin de servicios
de TI), ITIL (biblioteca de infraestructura de tecnologas de informacin),
ISO/IEC 15504 (modelo para la evaluacin de capacidades de procesos
y madurez de organizaciones), IDEAL (mejora de procesos
recomendado para CMMI), PSP (proceso de software para persona),
TSP (proceso de software para equipos de trabajo), SCAMPI (mtodo
de evaluacin de procesos usado para CMMI), Quick Locus (mtodo
ligero brasileo de evaluacin de CMMI), PMBOK (Cuerpo de
conocimiento de gestin de proyectos de PMI), ISO 10006 (directrices
para la calidad en la gestin de proyectos), MoProSoft (modelo de
procesos de referencia mexicano), EvalProSoft (mtodo de evaluacin
basado en 15504 para MoProSoft), SIMEP-Sw (conjunto de modelos
ligeros para mejor de procesos, colombiano), MPS.BR (modelos de
mejor y evaluacin de procesos brasileos), TMMI (modelo de madurez
para Pruebas de Software), SPIRE (modelo de mejora de la regin
Europea), TOPS (mejora de procesos para pymes), PROCESSUS,
IMPACT y RAPID entre otros.
El modelo de madurez organizacional es uno de los tipos de modelos

que ha recibido ms atencin en los ltimos aos. Dentro del campo de
la informtica se tienen entre otros a CMMI, MoProSoft, el par
ISO/IEC12207-ISO/IEC 15504 y TMMI; y fuera del campo de la
informtica se tiene a OPM3, SOA-MM, BP-MM y GIMM de una lista
mayor de propuestas. Todos estos modelos que pueden tener aspectos
diferentes influenciados por el dominio donde aplican, estn vinculados
necesariamente por el concepto que tratan de representar: un modelo
de madurez organizacional; sin embargo al no existir algn referente
que oriente como definir este tema, es posible que cada cual adopte el
suyo propio.

Figura 3.5 - Normas Relacionadas con el Proceso de Software
1.3.2.1. Conceptos Clave

i) Proceso:
Conjunto de actividades mutuamente relacionadas o que
interactan, las cuales transforman elementos de entrada
en resultados. NTP-ISO/IEC 12207 Procesos del Ciclo de
Vida del Software.
Figura 3.6 - Proceso
Figura 3.7 - El desarrollo de software es realmente un proceso?
ii) Modelo:
Esquema terico, generalmente en forma matemtica, de
un sistema o de una realidad compleja. DRAE
iii) Ciclo de desarrollo de software:

34
Periodo de tiempo que comienza con la decisin de

desarrollar el producto software y termina cuando el
software es entregado. IEEE Std. 610.12-1990 Software
Engineering Terminology
iv) Ciclo de vida de software:
Periodo de tiempo que comienza cuando el producto
software es concebido y termina cuando el software no
est disponible permanentemente para el usuario
(retirada del software) . IEEE Std. 610.12-1990 Software
Engineering Terminology.
v) Estados del ciclo de vida del software:
Constituye cada uno de los momentos (estados) por las
que pasa (evoluciona) el producto software. Ing.
Software. R.Fairley
Figura 3.8 - Ciclo de Vida y Ciclo de Desarrollo del Software
1.3.2.2. Ciclos de Vida, Procesos, Productos

Considerando al ciclo de vida como la evolucin del
producto de software, se infiere que dentro de cada una de
las etapas del ciclo de vida se implementen procesos de
desarrollo.
Proceso Ciclos de vida
Especificacin de
Necesidades Diseo Codigo Sistema Software
Requisitos
Obtener Disear
Codificar Probar
Requisitos Sistema
Figura 3.9 - Procesos y Ciclos de Vida

De la definicin de proceso se infiere que cada proceso

genera productos, tal como se muestra a continuacin:
Figura 3.10 - Procesos y Productos
1.3.3. Los Procesos ISO 12207:2008

El modelo ISO 12207:2008 establece un conjunto de buenas prcticas
para guiar a las organizaciones en la mejora de sus procesos de
desarrollo y mantenimiento software.
En concreto, define 43 procesos que pueden aplicarse durante la

adquisicin de un producto o servicio software y durante el suministro,
desarrollo, operacin, mantenimiento y evolucin de productos software.

36
Figura 3.11 - Modelo de Procesos ISO 12207:2008
CICLO DE VIDA:
: Nace Muere
INVOLUCRADOS
(STAKEHOLDERS) : Adquirientes, proveedores, usuarios, ...
PROCESOS
CORPORATIVOS
APLICACIN :
PROYECTOS PROYECTOS
PRODUCTOS SERVICIOS
PROCEDIMIENTO S,
PROCESOS , METODO LOG AS
,
DETALLES: : DEFINICIO NES Y TCNICAS ,
MTO DOS Y
DESCRIPCIONES MTRICAS HERRAM IENTAS Y
ENTORNOS
Figura 3.12 - Modelo de Procesos ISO 12207:2008 Alcance

1.4. MODELO DE CICLO DE VIDA DE SOFTWARE
Sommerville define modelo de proceso de software como Una representacin

simplificada de un proceso de software, representada desde una perspectiva
especfica. Por su naturaleza los modelos son simplificados, por lo tanto un
modelo de procesos del software es una abstraccin de un proceso real.
Los modelos genricos no son descripciones definitivas de procesos de software;
sin embargo, son abstracciones tiles que pueden ser utilizadas para explicar
diferentes enfoques del desarrollo de software.
Modelos que se van a discutir a continuacin:
Codificar y corregir
Modelo en cascada
Desarrollo evolutivo
Desarrollo formal de sistemas
Desarrollo basado en reutilizacin
Desarrollo incremental
Desarrollo en espiral
1.4.1. Codificar y corregir (Code-and-Fix)

Este es el modelo bsico utilizado en los inicios del desarrollo de
software. Contiene dos pasos:
Escribir cdigo.
Corregir problemas en el cdigo.
Se trata de primero implementar algo de cdigo y luego pensar acerca
de requisitos, diseo, validacin, y mantenimiento.
Este modelo tiene tres problemas principales:
Despus de un nmero de correcciones, el cdigo puede tener una
muy mala estructura, hace que los arreglos sean muy costosos.
Frecuentemente, an el software bien diseado, no se ajusta a las
necesidades del usuario, por lo que es rechazado o su reconstruccin
es muy cara.
El cdigo es difcil de reparar por su pobre preparacin para probar y
modificar.
1.4.2. Modelo en Cascada

El primer modelo de desarrollo de software que se public se deriv de
otros procesos de ingeniera. ste toma las actividades fundamentales
del proceso de especificacin, desarrollo, validacin y evolucin y las
representa como fases separadas del proceso.

38
El modelo en cascada consta de las siguientes fases:

1. Definicin de los requisitos: Los servicios, restricciones y objetivos
son establecidos con los usuarios del sistema. Se busca hacer esta
definicin en detalle.
2. Diseo de software: Se particiona el sistema en sistemas de
software o hardware. Se establece la arquitectura total del sistema.
Se identifican y describen las abstracciones y relaciones de los
componentes del sistema.
3. Implementacin y pruebas unitarias: Construccin de los mdulos y
unidades de software. Se realizan pruebas de cada unidad.
4. Integracin y pruebas del sistema: Se integran todas las unidades.
Se prueban en conjunto. Se entrega el conjunto probado al cliente.
5. Operacin y mantenimiento: Generalmente es la fase ms larga. El
sistema es puesto en marcha y se realiza la correccin de errores
descubiertos. Se realizan mejoras de implementacin. Se identifican
nuevos requisitos.
La interaccin entre fases puede observarse en la Figura 4.1. Cada fase

tiene como resultado documentos que deben ser aprobados por el
usuario.
Una fase no comienza hasta que termine la fase anterior y
generalmente se incluye la correccin de los problemas encontrados en
fases previas.
Figura 4.1 - Modelo de Desarrollo en Cascada
En la prctica, este modelo no es lineal, e involucra varias iteraciones e

interaccin entre las distintas fases de desarrollo. Algunos problemas
que se observan en el modelo de cascada son:
Las iteraciones son costosas e implican rehacer trabajo debido a la
produccin y aprobacin de documentos.
Aunque son pocas iteraciones, es normal congelar parte del
desarrollo y continuar con las siguientes fases.

Los problemas se dejan para su posterior resolucin, lo que lleva a

que estos sean ignorados o corregidos de una forma poco elegante.
Existe una alta probabilidad de que el software no cumpla con los
requisitos del usuario por el largo tiempo de entrega del producto.
Es inflexible a la hora de evolucionar para incorporar nuevos
requisitos. Es difcil responder a cambios en los requisitos.
Este modelo slo debe usarse si se entienden a plenitud los requisitos.
An se utiliza como parte de proyectos grandes.
1.4.3. Desarrollo Evolutivo

La idea detrs de este modelo es el desarrollo de una implantacin del
sistema inicial, exponerla a los comentarios del usuario, refinarla en N
versiones hasta que se desarrolle el sistema adecuado. En la Figura 4.2
se observa cmo las actividades concurrentes: especificacin,
desarrollo y validacin, se realizan durante el desarrollo de las versiones
hasta llegar al producto final.
Una ventaja de este modelo es que se obtiene una rpida
retroalimentacin del usuario, ya que las actividades de especificacin,
desarrollo y pruebas se ejecutan en cada iteracin.
Figura 4.2 - Modelo de Desarrollo Evolutivo
Existen dos tipos de desarrollo evolutivo:
Desarrollo Exploratorio:
El objetivo de este enfoque es explorar con el usuario los requisitos
hasta llegar a un sistema final. El desarrollo comienza con las partes
que se tiene ms claras. El sistema evoluciona conforme se aaden
nuevas caractersticas propuestas por el usuario.

40
Enfoque utilizando prototipos:

El objetivo es entender los requisitos del usuario y trabajar para mejorar
la calidad de los requisitos. A diferencia del desarrollo exploratorio, se
comienza por definir los requisitos que no estn claros para el usuario y
se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a
terminar de definir estos requisitos.
Entre los puntos favorables de este modelo estn:

La especificacin puede desarrollarse de forma creciente.
Los usuarios y desarrolladores logran un mejor entendimiento del
sistema. Esto se refleja en una mejora de la calidad del software.
Es ms efectivo que el modelo de cascada, ya que cumple con las
necesidades inmediatas del cliente.
Desde una perspectiva de ingeniera y administracin se identifican los

siguientes problemas:
Proceso no Visible: Los administradores necesitan entregas para
medir el progreso. Si el sistema se necesita desarrollar rpido, no es
efectivo producir documentos que reflejen cada versin del sistema.
Sistemas pobremente estructurados: Los cambios continuos pueden
ser perjudiciales para la estructura del software haciendo costoso el
mantenimiento.
Se requieren tcnicas y herramientas: Para el rpido desarrollo se
necesitan herramientas que pueden ser incompatibles con otras o
que poca gente sabe utilizar.
Este modelo es efectivo en proyectos pequeos (menos de 100.000

lneas de cdigo) o medianos (hasta 500.000 lneas de cdigo) con
poco tiempo para su desarrollo y sin generar documentacin para cada
versin.
Para proyectos largos es mejor combinar lo mejor del modelo de

cascada y evolutivo: se puede hacer un prototipo global del sistema y
posteriormente reimplementarlo con un acercamiento ms estructurado.
Los subsistemas con requisitos bien definidos y estables se pueden
programar utilizando cascada y la interfaz de usuario se puede
especificar utilizando un enfoque exploratorio.
1.4.4. Desarrollo Formal de Sistemas
Este modelo se basa en transformaciones formales de los requisitos

hasta llegar a un programa ejecutable.

Figura 4.3 - Paradigma de Programacin Automtica

La Figura 4.3 ilustra un paradigma ideal de programacin automtica.
Se distinguen dos fases globales: especificacin (incluyendo validacin)

y transformacin. Las caractersticas principales de este paradigma son:
La especificacin es formal y ejecutable constituye el primer
prototipo del sistema).
La especificacin es validada mediante prototipado.
Posteriormente, a travs de transformaciones formales la
especificacin se convierte en la implementacin del sistema.
En el ltimo paso de transformacin se obtiene una implementacin
en un lenguaje de programacin determinado.
El mantenimiento se realiza sobre la especificacin (no sobre el
cdigo fuente), la documentacin es generada automticamente y el
mantenimiento es realizado por repeticin del proceso (no mediante
parches sobre la implementacin).
Observaciones sobre el desarrollo formal de sistemas:

Permite demostrar la correccin del sistema durante el proceso de
transformacin. As, las pruebas que verifican la correspondencia
con la especificacin no son necesarias.
Es atractivo sobre todo para sistemas donde hay requisitos de
seguridad y confiabilidad importantes.
Requiere desarrolladores especializados y experimentados en este
proceso para llevarse a cabo.
1.4.5. Desarrollo Basado en Reutilizacin
Como su nombre lo indica, es un modelo fuertemente orientado a la

reutilizacin. Este modelo consta de 4 fases ilustradas en la Figura 4.4.

42
A continuacin se describe cada fase:
1. Anlisis de componentes: Se determina qu componentes pueden

ser utilizados para el sistema en cuestin. Casi siempre hay que
hacer ajustes para adecuarlos.
2. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos

para concordar con los componentes de la etapa anterior. Si no se
puede realizar modificaciones en los requisitos, hay que seguir
buscando componentes ms adecuados (fase 1).
3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco

de trabajo para el sistema. Se debe tener en cuenta los
componentes localizados en la fase 2 para disear o determinar este
marco.
4. Desarrollo e integracin: El software que no puede comprarse, se

desarrolla. Se integran los componentes y subsistemas. La
integracin es parte del desarrollo en lugar de una actividad
separada.
Las ventajas de este modelo son:
Disminuye el costo y esfuerzo de desarrollo.
Reduce el tiempo de entrega.
Disminuye los riesgos durante el desarrollo.
Figura 4.4 Desarrollo Basado en Reutilizacin de Componentes
Desventajas de este modelo:
Los compromisos en los requisitos son inevitables, por lo cual

puede que el software no cumpla las expectativas del cliente.
Las actualizaciones de los componentes adquiridos no estn en

manos de los desarrolladores del sistema.

1.4.6. Procesos Iterativos
A continuacin se expondrn dos enfoques hbridos, especialmente

diseados para el soporte de las iteraciones:
Desarrollo Incremental.
Desarrollo en Espiral.
1.4.6.1. Desarrollo Incremental

Mills sugiri el enfoque incremental de desarrollo como una
forma de reducir la repeticin del trabajo en el proceso de
desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el
sistema (ver Figura 4.5). Es una combinacin del Modelo de
Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y

da oportunidad para retrasar las decisiones hasta tener
experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el

modelo de cascada o evolutivo, dependiendo del
conocimiento que se tenga sobre los requisitos a
implementar. Si se tiene un buen conocimiento, se puede
optar por cascada, si es dudoso, evolutivo.
Figura 4.5 - Modelo de Desarrollo Iterativo Incremental
Entre las ventajas del modelo incremental se encuentran:
Los clientes no esperan hasta el fin del desarrollo para

utilizar el sistema. Pueden empezar a usarlo desde el
primer incremento.
Los clientes pueden aclarar los requisitos que no tengan

claros conforme ven las entregas del sistema.
Se disminuye el riesgo de fracaso de todo el proyecto, ya

que se puede distribuir en cada incremento.
Las partes ms importantes del sistema son entregadas

primero, por lo cual se realizan ms pruebas en estos
mdulos y se disminuye el riesgo de fallos.

44
Algunas de las desventajas identificadas para este modelo

son:
Cada incremento debe ser pequeo para limitar el riesgo

(menos de 20.000 lneas).
Cada incremento debe aumentar la funcionalidad.
Es difcil establecer las correspondencias de los

requisitos contra los incrementos.
Es difcil detectar las unidades o servicios genricos para

todo el sistema.
1.4.6.2. Desarrollo en Espiral

El modelo de desarrollo en espiral (ver Figura 4.6) es
actualmente uno de los ms conocidos y fue propuesto por
Boehm. El ciclo de desarrollo se representa como una
espiral, en lugar de una serie de actividades sucesivas con
retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:

1. Definicin de objetivos: Se definen los objetivos. Se
definen las restricciones del proceso y del producto. Se
realiza un diseo detallado del plan administrativo. Se
identifican los riesgos y se elaboran estrategias
alternativas dependiendo de estos.
2. Evaluacin y reduccin de riesgos: Se realiza un anlisis

detallado de cada riesgo identificado. Pueden
desarrollarse prototipos para disminuir el riesgo de
requisitos dudosos. Se llevan a cabo los pasos para
reducir los riesgos.
3. Desarrollo y validacin: Se escoge el modelo de

desarrollo despus de la evaluacin del riesgo. El modelo
que se utilizar (cascada, sistemas formales, evolutivo,
etc.) depende del riesgo identificado para esa fase.
4. Planificacin: Se determina si continuar con otro ciclo. Se

planea la siguiente fase del proyecto.
Este modelo a diferencia de los otros toma en consideracin

explcitamente el riesgo, esta es una actividad importante en
la administracin del proyecto.
El ciclo de vida inicia con la definicin de los objetivos. De

acuerdo a las restricciones se determinan distintas
alternativas. Se identifican los riesgos al sopesar los
objetivos contra las alternativas. Se evalan los riesgos con
actividades como anlisis detallado, simulacin, prototipos,
etc. Se desarrolla un poco el sistema. Se planifica la
siguiente fase.

Figura 4.6 - Modelo de Desarrollo en Espiral
1.4.7. Cul es el modelo de proceso ms adecuado?
Cada proyecto de software requiere de una forma de particular de

abordar el problema. Las propuestas comerciales y acadmicas
actuales promueven procesos iterativos, donde en cada iteracin puede
utilizarse uno u otro modelo de proceso, considerando un conjunto de
criterios (Por ejemplo: grado de definicin de requisitos, tamao del
proyecto, riesgos identificados, entre otros).
En la Tabla 2 se expone un cuadro comparativo de acuerdo con algunos

criterios bsicos para la seleccin de un modelo de proceso, la medida
utilizada indica el nivel de efectividad del modelo de proceso de acuerdo
al criterio (Por ejemplo: El modelo Cascada responde con un nivel de
efectividad Bajo cuando los Requisitos y arquitectura no estn
predefinidos):

46
Funciona con Produce Visin del

Permite
requisitos y software Gestin de progreso por el
Modelo de Proceso correcciones
arquitectura no altamente riesgos Cliente y el Jefe
sobre la marcha
predefinidos fiable de Proyecto
Codificar y Corregir Bajo Bajo Bajo Alto Medio
Cascada Bajo Alto Bajo Bajo Bajo

Evolutivo
Medio o Alto Alto Bajo Bajo Bajo
exploratorio
Evolutivo
Alto Medio Medio Alto Alto
prototipado
Desarrollo formal
Bajo Alto Bajo a Medio Bajo Bajo
de sistemas
Desarrollo
orientado a la Medio Bajo a Alto Bajo a Medio Alto Alto
reutilizacin
Incremental Bajo Alto Medio Bajo Bajo
Espiral Alto Alto Alto Medio Medio
Tabla 2 Comparacin entre modelos de proceso de software

1.5. VERIFICACIN Y VALIDACIN DE SOFTWARE
Los procesos de verificacin y validacin determinan si un producto software

satisface las necesidades del negocio y si se est construyendo acorde a las
especificaciones.
Segn el SWEBOK 2004, existen dos grupos de tcnicas para la comprobacin

de software:
1. Tcnica Esttica: Tcnica para evaluacin del software que no requiere la

ejecucin del mismo.
2. Tcnica Dinmica: Tcnica para evaluacin del software que s requiere la

ejecucin del mismo.
Figura 5.1 Revisiones y Pruebas
En la Figura 5.1 se puede apreciar que cuando se aplica la tcnica dinmica,

normalmente se usan pruebas; y cuando se aplica tcnica esttica se utilizan
revisiones.
1.5.1. Verificacin
Segn la ISO-IEC 12207, la Verificacin es el proceso para determinar

si los productos software de una actividad cumplen con los
requerimientos o condiciones que tienen impuestas por las actividades
precedentes.
La verificacin permite comprobar que el artefacto producido en un

proceso corresponde con el que se utiliz a la entrada del proceso.
La verificacin permite responder la pregunta: Estamos construyendo

el producto en forma correcta?
La verificacin se orienta al proceso.

48
1.5.2. Validacin
Segn la ISO-IEC 12207, la Validacin es el proceso para determinar si

los requerimientos y el sistema o producto software, tal como se ha
construido, cumple con su uso especfico previsto. La validacin se
puede llevar a cabo en etapas tempranas.
La validacin permite comprobar si el artefacto producido es lo que el

usuario necesita.
La validacin permite responder la pregunta: Estamos construyendo el

producto correcto?
La validacin se orienta al producto.
Las actividades de verificacin y validacin deben desarrollarse a lo largo de todo

el ciclo de vida de software (ver Figura 5.2).
Figura 5.2 Verificacin y Validacin
1.5.3. Ventajas de las Revisiones de Software

No requiere de cdigo ejecutable, por lo que puede ser realizada
desde el inicio (por lo tanto es menos costosa).
Se encuentran varios defectos a la vez.
Encuentra hasta un 85% de los defectos.
Se localiza la posicin exacta del defecto.
Refuerza el uso de estndares.
Mejora la capacitacin.
1.5.4. Desventajas de las Revisiones de Software

Requiere del tiempo de expertos.
No se puede verificar caractersticas no-funcionales (ejemplo
rendimiento).
Validan cumplimiento de lo que se especific, en vez de lo que
realmente desea el cliente.
Difcil de implementar (es vista como improductiva por los
desarrolladores).

1.5.5. Revisiones Informales y Formales

1. Informales:
No hay proceso definido.
No existen roles.
Usualmente no planeadas.
2. Formales:
Objetivos definidos.
Proceso documentado.
Roles definidos y personas entrenados en ellos.
Check-list, reglas y mtodos para encontrar defectos.
Reporte del resultado.
Recoleccin de datos para el control del proceso.
Figura 5.3 Tipos de Revisiones de Software

50
Actividades
Los alumnos debern presentar los documentos de Reportes de
Especificacin de Software del proyecto integrado, manual de usuario y
Reporte de Diseo de Software utilizando los formatos adjuntos.
Los alumnos debern elaborar un plan de verificacin y de validacin

de los entregables que se desarrollarn como parte del proyecto
integrado de quinto ciclo.
Los alumnos debern elaborar las listas de verificacin del RES las
que aplicarn en juego de roles como parte del ciclo de proyecto
integrado.
Los alumnos harn el seguimiento de levantamiento de las

observaciones en una segunda revisin de pares del RES.

Formatos
1. RES Reporte de Especificacin de Software
Reporte de
Especificacin de
Software (RES)
Versin <x.y.z>
[Nombre del proyecto]
[Este documento es la plantilla base para elaborar el documento Reporte de

Especificacin de Software. Los textos que aparecen entre parntesis rectos son
explicaciones de que debe contener cada seccin. Dichos textos se deben
seleccionar y sustituir por el contenido que corresponda. En caso que alguna de las
secciones del presente documento no aplique a su proyecto pueden usarse las
frases No hay cambios, No hay impacto en esta seccin, La solucin que se
est implementando no tiene impacto en esta seccin, No aplican para el
proyecto (No borrar secciones del documento)]

52
HISTORIAL DE REVISIONES
Fecha de Fecha de Revisado

Versin Autor Descripcin
Elaboracin Revisin por
<Persona <Persona(s)
que elabora <Fecha de <Fecha de que revisa(n)
<x.y.z> <Detalles>
el Elaboracin> Revisin> el
documento> documento>

Contenido
1. Antecedentes ..................................................................................... 54
2. Objetivos ............................................................................................. 54
3. Alcance ................................................................................................. 54
3.1. DENTRO DEL ALCANCE .......................................................................................................... 54
3.2. FUERA DEL ALCANCE ............................................................................................................. 54
3.3. RESTRICCIONES..................................................................................................................... 54
3.4. SUPUESTOS ............................................................................................................................ 55
4. Procesos de Negocio ....................................................................... 55

4.1. LISTA DE CASOS DE USO DE NEGOCIO.............................................................................. 55
4.1.1. LISTA DE ACTORES DEL NEGOCIO ................................................................................... 55
4.1.2. DIAGRAMA GENERAL DE CASO DEL NEGOCIO ................................................................ 55
4.1.3. ESPECIFICACIN DE LOS CASOS DE USO DEL NEGOCIO ............................................... 55
CUN01 NOMBRE DEL CASO DE USO DEL NEGOCIO ...................................................................... 55
4.2. REALIZACIN DE LOS CASOS DE USO DE NEGOCIO .......................................................... 56
4.3. LISTA DE TRABAJADORES DE NEGOCIO............................................................................... 56
4.4. REGLAS DE NEGOCIO ............................................................................................................ 56
5. Requisitos Funcionales .................................................................. 57

6. Requisitos No Funcionales............................................................ 57
7. Modelo de Casos de Uso del Sistema........................................ 60
7.1. LISTA DE ACTORES DE SISTEMA .......................................................................................... 60
7.2. DIAGRAMA DE ACTORES DEL SISTEMA ................................................................................ 61
7.3. ARQUITECTURA DEL SISTEMA DIAGRAMA DE PAQUETES ............................................... 61
7.4. LISTA DE CASOS DE USO DEL SISTEMA POR PAQUETE...................................................... 61
7.5. DIAGRAMA DE CASOS DE USO POR PAQUETE ..................................................................... 61
7.6. PRIORIZACIN DE LOS CASOS DE USO DEL SISTEMA ....................................................... 61
7.7. MATRIZ DE MODELO DE NEGOCIO Y MODELO DE SISTEMA .............................................. 62
7.8. ESPECIFICACIN DE LOS CASOS DE USO DEL SISTEMA .................................................... 62
CUS01 Nombre del caso de Uso ..................................................................................................... 63
8. Flujo General de Navegacin ....................................................... 64

9. Esquema de Seguridad .................................................................. 64
10. Modelo de Anlisis ........................................................................ 65
11. Modelo Conceptual ....................................................................... 66

54
1. Antecedentes
[Describa la situacin actual y las necesidades o problemas que se pretende
atender. Recuerde que debe tomar como informacin base lo registrado en el
Reporte de Solicitud de Requerimiento (RSRQ).]
Nota:
Para el caso de los cursos de quinto y sexto ciclo se puede tomar como
referencia tambin el documento de planificacin del proyecto (PP)
2. Objetivos
[Referidos a los objetivos del negocio alineados al producto software.
Es la explicacin resumida de los resultados que el negocio quiere
lograr con el sistema, estos pueden ser la solucin de alguno o varios
problemas, la generacin de nuevas oportunidades de negocio, alguna
mejora que los usuarios o clientes necesitan o mejorar la informacin
para la toma de decisiones directivas o ejecutivas. Recuerde que puede
tomar como informacin base lo registrado en el Reporte de solicitud
de requerimiento (SRQ).]
Nota: Para el caso de los cursos de quinto y sexto ciclo se puede tomar como
referencia tambin el documento de planificacin de proyecto (PP).]
3. Alcance
3.1. Dentro del Alcance

[En esta seccin deber incluir el alcance funcional del producto
software, dicho alcance se encuentra tambin definido en el
documento de Planificacin de Proyecto (PP). Es posible detallar el
alcance siempre y cuando no vare en cuanto al original definido en el
PP.
Nota: Para los cursos de ADSI y ADSII se define despus de haber sido
obtenida la Matriz de Actividades Vs. Requisitos.]
3.2. Fuera del Alcance

[En esta seccin deber incluir lo que no es parte del alcance funcional
del producto software. Se puede tomar como referencia lo indicado en
el documento de PP. Es posible detallar lo que queda fuera del alcance
siempre y cuando no vare en cuanto al original definido en el PP.
Nota: Para los cursos de ADSI y ADSII se define despus de haber sido
obtenida la Matriz de Actividades Vs. Requisitos.]
3.3. Restricciones
[En esta seccin deber incluir las restricciones de la solucin
propuesta relacionados al software, hardware y a la funcionalidad as
como lo referido a los lmites que impone la empresa contratante en el
desarrollo del producto software.]
Nota:
Para el caso de los cursos de quinto y sexto ciclo puede tomar como
referencia la seccin de restricciones del documento de planificacin de
proyecto (PP).

3.4. Supuestos
[En esta seccin deber incluir los principales supuestos relacionados
con la implementacin del sistema y lo referido a lo que la empresa
contratante posee a nivel de tecnologas de informacin.]
Nota: Para el caso de los cursos de quinto y sexto ciclo puede tomar
como referencia la seccin de supuestos del documento de
planificacin de proyecto (PP).
4. Procesos de Negocio
4.1. Lista de Casos de Uso de Negocio

[En esta seccin deber listar los casos de uso de negocio que se
obtuvieron a partir de los procesos de negocio identificados dentro del
mbito de la solucin y a los cuales se les dar el soporte con el
producto software. Cada Caso de Uso de Negocio deber ser
identificado con un cdigo nico y correlativo. Ejemplo CUN01. De ser
necesario deber incorporar un diagrama de casos de uso de negocio.]
Caso de uso del Descripcin

negocio
CUN01 [Nombre
del CUN01] [Descripcin del flujo de trabajo del CUN01.]
CUN02 [Nombre
del CUN02] [Descripcin del flujo de trabajo del CUN02.]
4.1.1. Lista de Actores del Negocio

[En esta seccin deber listar a los actores de negocio incluyendo una
descripcin por cada uno.]
Actor del Negocio Descripcin
4.1.2. Diagrama General de Caso del Negocio

[En esta seccin deber graficar el Diagrama general de Casos de uso
del Negocio.]
4.1.3. Especificacin de los Casos de Uso del Negocio

[Por cada caso de uso de negocio deber indicar el flujo de trabajo del
Caso de Uso del Negocio. Deber usar la plantilla que a continuacin se
detalla:
CUN01 Nombre del Caso de Uso del Negocio

1. Breve Descripcin
Reutilizar el resumen del punto 4.1
2. Objetivo
Referido al negocio y alineado al producto software.

56
3. Flujo de Trabajo
3.1 Flujo Bsico
1. Indicar el flujo bsico del CUN
3.2 Flujos Alternativos
1. Detalle del flujo alterno.
4. Categora
Se coloca si es bsica, estratgica o de apoyo.
5. Gestor del proceso

Se identifica a la persona que est interesada en el xito o
fracaso del proceso.
4.2. Realizacin de los Casos de Uso de Negocio

[En esta seccin deber desarrollar los diagramas de actividades y
diagrama de clases de negocio por cada Caso de Uso de Negocio
identificado en la seccin 4.1. Por cada juego de diagramas deber
identificar cules sern las actividades que sern automatizadas.]
4.3. Lista de Trabajadores de Negocio

[En esta seccin deber listar a los trabajadores de negocio incluyendo
una descripcin por cada uno.]
Trabajador del
Descripcin
Negocio
4.4. Reglas de Negocio

[En esta seccin deber identificar las reglas que regulan la estructura
del negocio y cmo ellos operan afectando el funcionamiento de los
procesos de negocio. Dichas reglas de negocio son las que se
considerarn para el diseo del sistema. Cada Regla de Negocio deber
ser identificada con un cdigo nico y correlativo. Ejemplo: RN01. Para
identificar las reglas de negocio puede considerar la siguiente
clasificacin:
Reglas de Estructura: Ejemplo (Todo pedido debe ser realizado por un

cliente, y que el mismo debe estar dado de alta. Adems una vez que
el cliente haya hecho algn pedido, se deber garantizar que no es
posible eliminarlo, al menos que previamente se eliminen todos sus
pedidos)
Reglas de Derivacin: Ejemplo (El total de un pedido se puede calcular

a partir de distintas lneas que lo componen, mientras que el total de
cada lnea se puede calcular a partir del nmero de unidades vendidas
y el precio por unidad)
Reglas de Interfaz o de Modelo de Datos: Ejemplo (No hay precio de

artculos negativos, el sexo de una persona slo puede ser masculino o

femenino, una fecha tiene que ser siempre una fecha vlida - no existe
30 de febrero)
Reglas de Operacin o Reglas de Flujo: Ejemplo (Un cliente puede

hacer una peticin de anlisis al laboratorio que anota un encargado:
hecho esto, se genera un parte para uno o ms analistas, estos
realizan las mediciones correspondientes y devuelven los partes con la
informacin pertinente, a partir de la cual se genera un informe de
anlisis, que ser un anlisis vlido solo cuando sea firmado por los
responsables de garantizar su correccin)
Cdigo Descripcin
RN-001
[Descripcin de la Regla 001]
RN-002
[Descripcin de la Regla 002]
RN-00n
5. Requisitos Funcionales
[De acuerdo a lo solicitado explcitamente por el rea usuaria, listar todos los
requisitos funcionales del producto software. Considere que los requisitos
funcionales que liste debern ser asociados posteriormente a los casos de uso
(funciones de software). Cada Requisito Funcional deber ser identificado con
un cdigo nico y correlativo. Ejemplo: RF01.
Nota: Esta lista proviene de la Matriz de Actividades Vs. Requisitos. Y de la
Matriz de Requisitos Funcionales Adicionales.]
Cdigo Descripcin Proceso de Negocio

[Cdigo del [Identificador del
[Descripcin detallada del
requisito proceso de negocio
requisito funcional.]
funcional] asociado]
[Descripcin detallada del [CUN01]
RF-001
requisito funcional 1.]
RF-002
requisito funcional 2.]
... ....
RF-00n
requisito funcional n.]
6. Requisitos No Funcionales
[Listar los requisitos no funcionales los mismos que debern ser considerados
para el modelo de calidad de producto. Cada Requisito No Funcional deber
ser identificado con un cdigo nico y correlativo. Ejemplo: RNF01.]
Tipo de Requisito Cdigo Descripcin Implementacin

[Nombre del tipo de [Cdigo del [Descripcin [Describir como
requisito no requisito no detallada del se implementar
funcional] funcional] requisito no el RNF-00n]

58

funcional.]
Restricciones del
Diseo
[Definir cualquier tipo de
restriccin de diseo,
tales como: proceso de
desarrollo de software, [Descripcin
sistemas operativos, RNF-001 detallada del
lenguajes de requisito no funcional
programacin, 1.]
administrador de base de
datos, conexin a la BD,
generador de reportes,
manejo de informacin,
etc.]
[Descripcin
detallada del
RNF-002
requisito no funcional
2.]
Componentes a
Adquirir
[Identificar los
componentes que se
deben adquirir o tener en [Descripcin
cuenta, para llevar acabo RNF-003 detallada del
el desarrollo y ejecucin requisito no funcional
del sistema. Ejemplo: 3.]
lenguajes de
programacin,
servidores, estaciones de
trabajo, etc.]
[Descripcin
detallada del
RNF-004
4.]
Interfaces de Usuario
[Describir las interfaces
de usuario que sern
implementados en el [Descripcin
software. Esto incluye RNF-005 detallada del
por ejemplo: formatos de requisito no funcional
la pantalla, pgina o 5.]
esquemas de las
ventanas, reportes,
mens, etc.]
[Descripcin
detallada del
RNF-006
6.]


Interfaces de
Hardware
[Definir cualquier [Descripcin
interfase de hardware RNF-007 detallada del
que ser soportado por el requisito no funcional
software, incluyendo 7.]
estructura lgica,
direcciones fsicas, etc.]
[Descripcin
detallada del
RNF-008
8.]
Interfaces de
Software
[Descripcin
[Especificar el uso de detallada del
otros productos software RNF-009 requisito no funcional
requeridos e interfaces 9.]
con otros sistemas de la
aplicacin.]
[Descripcin
detallada del
RNF-010
10.]
Interfaces de
Comunicaciones
[Describir las interfaces [Descripcin
de comunicacin para detallada del
otros sistemas RNF-011 requisito no funcional
dispositivos, tales como: 11.]
redes de rea local,
dispositivos de serie
remota.]
[Descripcin
detallada del
RNF-012
12.]
Requerimientos de
Licenciamiento [Descripcin
detallada del
[Identificar las licencias RNF-013 requisito no funcional
que se requieran para el 13.]
desarrollo del sistema.]
[Descripcin
detallada del
RNF-014
14.]
Seguridad [Descripcin
[Describir como ser RNF-015 detallada del
controlada la seguridad requisito no funcional
del sistema.] 15.]

60

[Descripcin
detallada del
RNF-016
16.]
Estndares aplicables [Descripcin
[Especificar con qu RNF-017 detallada del
estndares trabaja el requisito no funcional
sistema.] 17.]
[Descripcin
detallada del
RNF-018
18.]
Requisitos del Sistema
[Especificar los [Descripcin
requerimientos de detallada del
plataforma tecnolgica RNF-019 requisito no funcional
necesarios para el diseo 19.]
y el desarrollo del
sistema.]
[Descripcin
detallada del
RNF-020
20.]
Requisitos de
Desempeo
[Listar y especificar los [Descripcin
requisitos de desempeo detallada del
con los que debe trabajar RNF-021 requisito no funcional
el sistema. Ejemplo: 21.]
Tiempo de respuesta en
alguna consulta del
sistema.]
[Descripcin
detallada del
RNF-022
22.]
7. Modelo de Casos de Uso del Sistema

[En esta seccin deber desarrollar el modelo de sistema o modelo de
requisitos. Para ello deber indicar los actores de sistemas, la arquitectura de
sistema (organizada en paquetes) y la relacin de casos de uso por cada
paquete. Cada Caso de Uso deber ser identificado con un cdigo nico y
correlativo. Ejemplo: CUS01.]
7.1. Lista de Actores de Sistema

[Listar a los actores de sistema.]

Actor del sistema Descripcin
7.2. Diagrama de Actores del Sistema

[Incorpore el diagrama de actores del sistema.]
7.3. Arquitectura del Sistema Diagrama de Paquetes

[Incorpore el diagrama de paquetes que representa la arquitectura
modular del sistema. Cada Paquete deber ser identificado con un
cdigo nico y correlativo. Ejemplo: P01.]
7.4. Lista de Casos de Uso del Sistema por Paquete

[En esta seccin deber listar todos los casos de uso del sistema que
se han identificado. Para hacerlo deber tomar como referencia la
organizacin del sistema de acuerdo al diagrama de paquetes del
punto 7.3.]
Paquete: P01 Nombre del Paquete
Caso de uso del sistema Descripcin
CUS01 [Nombre del Caso [Descripcin del caso de uso. En la

de Uso] descripcin deber indicar las acciones que
permitir el caso de uso.]
CUS02 [Nombre del Caso [Descripcin del caso de uso. En la
de Uso] descripcin deber indicar las acciones que
permitir el caso de uso.]
7.5. Diagrama de Casos de Uso por Paquete

[Incorpore el diagrama de casos del uso del sistema de acuerdo a los
paquetes y la lista trabajada en el punto 7.4.]
Paquete: P01 Nombre del Paquete
7.6. Priorizacin de los Casos de Uso del Sistema

7.6.1. Clasificacin de los Casos de Uso del Sistema
[En esta seccin deber clasificar los casos de uso de sistema
indicando si son primarios o secundarios.]
0,4 0,3 0,2 0,1 CLASIFICACIN

CASO DE USO IMPORTANCIA COMPLEJIDAD RIESGO IMPACTO RNF TOTAL DE CU
CUS01-
XXXXXX Primario
CUS02-
XXXXXX Secundario
CUS03-
XXXXXX Secundario

62
7.6.2. Ciclos de Desarrollo de los Casos de Uso del

Sistema
[En esta seccin deber indicar en qu ciclo de desarrollo se
trabajarn cada uno de los casos de uso del sistema.]
Ciclo de desarrollo Nombre del caso de uso Clasificacin

Ncleo central o Ciclo 0 CUS01 Nombre del caso de uso Primario
Ciclo 1 CUS02 Nombre del caso de uso Secundario
CUS03 Nombre del caso de uso Secundario
7.7. Matriz de Modelo de Negocio y Modelo de Sistema

[En esta seccin deber incluir una matriz en la que se pueda
evidenciar la trazabilidad entre los procesos de negocio y las funciones
del producto software.]
Caso del uso Actividad a automatizar Requerimiento Caso de uso del

del negocio funcional sistema
N Nombre N Nombre Responsable N Nombre N Nombre Actor
CUN01 Caso de 1 Actividad a Trabajador de RF- Requisito CUS01 Casos de Actor
Uso de ser Negocio 001 Funcional Uso de
Negocio automatizada Sistema
2 Actividad a Trabajador de
ser Negocio
automatizada
3 Actividad a Trabajador de
ser Negocio
automatizada
7.8. Especificacin de los Casos de Uso del Sistema
7.8.1. Especificacin de Alto Nivel

[En esta seccin deber incluir la especificacin de alto nivel
de los casos de uso del sistema. Asimismo deber indicar que
requisitos funcionales estn asociados a cada caso de uso,
tomando como referencia lo indicado en la matriz del punto
7.7.]
Caso de uso: CUS01 Nombre del Caso de Uso
Actor(es): Nombre del actor
Propsito: Indicar el propsito del caso de uso
Caso de uso Indicar si existe algn caso de uso asociado. De no
asociado: haber indicar No Aplica.
Resumen: Describir brevemente el caso de uso. Para ello deber
indicar como empieza el caso de uso, que actividades
desarrolla y como termina.
Clasificacin Indicar la clasificacin del caso de uso
Requisitos Indicar el(los) cdigos de requisitos funcionales
asociados.

7.8.2. Especificacin Expandida

[Por cada caso de uso de sistema especificado deber incluir la
especificacin expandida de casos de uso. Para ello deber
indicar el flujo bsico y los flujos alternos e incorporar el
prototipo con la inclusin de los controles. Deber usar la
plantilla que a continuacin se detalla:
CUS01 Nombre del caso de Uso

1. Actores
Indicar la lista de actores
2. Propsito
Indicar el propsito
3. Breve Descripcin
Reutilizar el resumen del punto 7.4
4. Flujo Bsico de Eventos

Indicar el flujo bsico de eventos
Es posible hacer referencia a las reglas de negocio.
5. Sub Flujos
Indicar los subflujos del flujo bsico.
6. Flujos Alternos
6.1. Nombre del flujo alterno
1. Detalle del Flujo alterno

Se pueden incluir reglas de negocio.
7. Precondiciones
Descripcin de la precondicin
8. Pos condiciones
Descripcin de la pos condicin
9. Puntos de Extensin
Indicar si existen puntos de extensin.
10. Requerimientos Especiales

Indicar si existen requerimientos especiales.
11. Prototipos
Incluir los prototipos asociados al caso de uso.

64
8. Flujo General de Navegacin
[Incluir un rbol de navegacin que permita entender el flujo que se seguir en la

navegacin por el aplicativo. El siguiente ejemplo muestra un rbol de
navegacin: Aplicacin/mdulo/opcin/subopcin]
Ver Agenda
Encargar Accin
Agenda Ver Acciones
Ver Alarmas
Accin Propia
Clientes Consultar
APLICACION
Parmetros
Tablas Resultados
Razones
Mantenimiento
Matriz CAP
Relaciones
Matriz GAF
Acciones Enviadas
Avances
Reportes Resultados Histricos
Resultado de
Acciones
Seguimiento Semanal
9. Esquema de Seguridad
[En esta se documenta los esquemas de seguridad en base a perfiles y su acceso

a su informacin. Para ello se utiliza una matriz de perfiles de usuario y accesos
por Aplicativo/Mdulo/Funcin.]

Aplicativo
Funciones por Mdulo Perfil 1 Perfil 2 ... Perfil N
Mdulo A x x X x
Consulta de informacin de
empresas
Consulta de operadores x x X x
autorizados
Modificacin de operadores x x X x
autorizados
Mdulo B
Modificacin de cuentas x x X x
afiliadas
Modificacin de x x X x
combinaciones autorizadas
10. Modelo de Anlisis
10.1. Realizacin de Casos de Uso Anlisis

[Esta seccin ilustra cmo el software trabaja a partir de los casos de uso
o escenarios seleccionados, y explica cmo varios elementos del modelo
de anlisis contribuyen con ellos funcionalmente. Por cada caso de uso
deber desarrollar un diagrama de secuencia y de clases de anlisis. Para
ello deber usar el patrn MVC. Para la realizacin deber identificar los
escenarios. Dichos escenarios se obtienen de las combinaciones entre el
flujo principal y flujos alternativos del la especificacin expandida de
casos de uso (ver punto 7.8.2).]
Cdigo del CUS Nombre del CUS
Nombre del Escenario
[Identifica el escenario a ser realizado y una breve descripcin. Se

recomienda identificar con un cdigo nico a cada escenario. Por ejemplo
ESC01]
Diagrama de Secuencia de Anlisis
[Incluya el diagrama de secuencia de anlisis en el cual se observe el uso

del patrn MVC que implementa el escenario identificado.]
Diagrama de Clases de Anlisis
[Incluya el diagrama de clases de anlisis obtenido del conjunto de

diagramas de secuencia que se implementan por cada escenario.]

66
11. Modelo Conceptual
[Esta seccin ilustra cmo a partir de las clases del tipo entidad se pueden
identificar una primera propuesta de modelo de persistencia. Para ello se utiliza
un diagrama clases por cada paquete que forma parte de la arquitectura del
sistema. Se puede hacer uso de tarjetas CRC para documentar las
responsabilidades y colaboraciones de cada clase de persistencia identificada.]

2. MU Manual de Usuario
Manual de Usuario
(MU)
Versin <x.y.z>
[Nombre del sistema]
[Este documento es la plantilla base para elaborar el Manual de Usuario. Los textos
que aparecen entre parntesis rectos son explicaciones de que debe contener cada
seccin. Dichos textos se deben seleccionar y sustituir por el contenido que
corresponda. En caso que alguna de las secciones del presente documento no
aplique al sistema desarrollado pueden usarse las frases No hay cambios, No hay
impacto en esta seccin, La solucin que se est implementando no tiene impacto
en esta seccin, No aplican para el sistema (No borrar secciones del
documento)]

68

<x.y.z> <Detalles>

Contenido
1. Objetivo del Documento ................................................................ 70

2. Descripcin General del Sistema................................................ 70
3. Alcance del Sistema ........................................................................ 70
4. Ingreso al Sistema .......................................................................... 70
5. Funciones del Sistema ................................................................... 72
5.1. NOMBRE DE LA OPCIN ........................................................................................................ 72

70
12. Objetivo del Documento

[Describa el objetivo del documento.]
El Manual del Usuario del Sistema de Mantenimiento Correctivo de Equipos,

brinda las pautas bsicas para el fcil acceso a la informacin que este
sistema ofrece, es decir, muestra las principales funcionalidades del sistema,
as como la descripcin grfica de cmo navegar dentro del mismo
13. Descripcin General del Sistema

[Resuma de manera general las funciones que el sistema implementa
para dar soporte a las necesidades y requerimientos de los usuarios
finales]
El sistema permite la generacin del Registro de Incidentes para la atencin

correctiva solicitada por los usuarios va telefnica o personalmente.
Asimismo, se podr realizar un control de las atenciones realizadas, de las
horas hombres invertidos y los materiales e insumos utilizados.
Adems, este sistema permitir automatizar los paquetes de servicios con lo

que se mejora el control de activos. Siendo una de las necesidades bsicas de
la empresa el conocer la localizacin de las mquinas atendidas, as como las
mquinas con las que podra contar el cliente registrado. En este sistema se
implementar las opciones necesarias para el registro de los datos
mencionados
14. Alcance del Sistema
[Describa las funciones que el sistema implementa, indicando el

nombre de la funcin y detallndola a nivel de usuario]
Funcionalidad requerida Funcionalidad detallada

Descripcin de la funcin implementada
Nombre de la funcin que se
indicando las actividades que permite
implementa
realizar
Permite registrar la solicitud de reparacin
Registrar incidentes de maquinaria con los datos del cliente y
las mquinas a reparar
15. Ingreso al Sistema

[Detalle cmo se debe ingresar al sistema]
Ingrese al portal www.maskiner.com.pe, lo que lo llevar a la pgina de

logueo Al ingresar al Sistema de Mantenimiento Correctivo de Equipos,
primero pasar por la pantalla de Ingreso al Sistema.

Ingresar
Usuario
Ingresar
contrasea
Hacer clic en el botn

para ingresar al
Se ingresar los datos solicitados, los cuales, al hacer clic en Ingresar, sern
validados por el sistema para el acceso a la pantalla correspondiente al perfil
del usuario logueado.
Las siguientes pantallas, mostrarn una barra de men que permite el acceso
a las funcionalidades que se mencionan a continuacin:
Men Principal
Registrar Incidentes
Generar O/T de Inspeccin
Generar O/T
Registrar Inf.de Liquidacin
Aprobar Prefactura
Generar Factura.
Mantener de Clientes
Mantener Equipo
Mantener Paquetes

72
16. Funciones del Sistema

[Detalle cada una de las funciones del sistema, implementadas en cada una
de sus opciones. Se debe explicar brevemente cada opcin y luego incluir las
pantallas necesarias que le permitan al usuario final entender el cmo se debe
usar.]
16.1. Nombre de la Opcin

[Describa el funcionamiento de la opcin. Incorpore adems las pantallas
que le permitan describir el funcionamiento. Utilice llamadas de ser el
caso para clarificar la explicacin. Su explicacin debe ser clara orientada
a usuarios finales]
REGISTRAR INCIDENTES
Al ingresar al sistema, el usuario seleccionar la opcin de men
Registrar Incidentes que lo llevar a la opcin Nuevo Registro de
Incidentes.
En esta pantalla el sistema cargar los datos del Registrador

(usuario logueado) as como la fecha del da. Aqu deber seguir los
siguientes pasos:

Seleccionar la
opcin Buscar
Se mostrar la opcin Buscar Cliente donde deber:
1.Ingresar el
nombre del
cliente 2. Seleccione
El sistema listar los clientes que cumplan con el filtro ingresado.

Luego el usuario deber escoger el Cliente que desee seleccionando
el cono seleccionar ( ).

74
Seleccione
haciendo
El sistema regresar a la pantalla de Registro de Incidentes donde

se cargar en la memoria los datos del cliente seleccionado. Luego,
el usuario deber:
1.Seleccionar
sucursal
2.Seleccionar la
opcin Buscar
Maquinaria.
El sistema cargar las mquinas registradas para la sucursal

seleccionada:

1.Seleccione
la maquinaria.
1.Seleccionar la
Naturaleza de la
2.Ingrese la
descripcin de la
3.Hacer clic en
El sistema cargar en la grilla los datos de la avera. Para ingresar

nuevas mquinas deber repetir los mismos pasos y para eliminarla
se deber:

76
1.Marcar la casilla de
seleccin de la
mquina que desea
eliminar de la lista.
2.Hacer clic en
la opcin
Finalmente seleccionar la opcin GUARDAR y con ello se mostrar el

mensaje de confirmacin.

DERECHOS DE USO
La presente documentacin es propiedad de Maskiner S.A. y tiene carcter de confidencial y

no podr ser objeto de reproduccin total o parcial, tratamiento informtico ni transmisin de
ninguna forma o por cualquier medio, ya sea electrnico, mecnico, por fotocopia, registro o
cualquiera otro. Asimismo tampoco podr ser objeto de prstamo, alquiler o cualquier forma
de cesin de uso sin el permiso previo y escrito de Maskiner S.A., titular del copyright. El
incumplimiento de las limitaciones sealadas por cualquier persona que tenga acceso a la
documentacin ser perseguida conforme a ley.
Trminos de Confidencialidad:
Este manual est destinado exclusivamente para Maskiner

S.A. Su contenido no debe ser revelado, duplicado, usado, o
publicado total o parcialmente, fuera de su organizacin, o a
cualquier otra empresa, sin una autorizacin expresa escrita
del proveedor.
As mismo, el proveedor se compromete a no divulgar total o

parcialmente el contenido de este documento referido a
necesidades o requerimientos especficos para Maskiner
S.A., as como ningn tema de negocios relacionado y que
fuere mencionado en reuniones de trabajo previas.

78
3. RDS Reporte de Diseo de Software
Reporte de Diseo de
Software (RDS)
Versin <x.y.z>
[Este documento es la plantilla base para elaborar el documento Reporte de Diseo

de Software. Los textos que aparecen entre parntesis rectos son explicaciones de
que debe contener cada seccin. Dichos textos se deben seleccionar y sustituir por
el contenido que corresponda. En caso que alguna de las secciones del presente
documento no aplique a su proyecto pueden usarse las frases No hay cambios,
No hay impacto en esta seccin, La solucin que se est implementando no tiene
impacto en esta seccin, No aplican para el proyecto (No borrar secciones del
documento)]


<x.y.z> <Detalles>

80
Contenido
1. Introduccin ...................................................................................... 81
1.1. PROPSITO ............................................................................................................................ 81
1.2. ALCANCE ................................................................................................................................ 81
1.3. DEFINICIONES, ACRNIMOS Y ABREVIATURAS .................................................................. 81
1.3.1. Definiciones..................................................................................... 81
1.3.2. Acrnimos ........................................................................................ 81
1.3.3. Abreviaturas ................................................................................... 82
1.4. REFERENCIAS ......................................................................................................................... 82
2. Vista General de la Arquitectura ................................................ 82

3. Metas y Restricciones de la Arquitectura ............................... 83
4. Vista de Casos de Uso .................................................................... 83
5. Vista Lgica ........................................................................................ 83
5.1. REALIZACIN DE CASOS DE USO MODELO DE ANLISIS .............................................. 84
5.1.1. Cdigo del CUS Nombre del CUS .......................................... 84
5.1.2. Diagrama de Clases de Anlisis ............................................... 84
5.2. MODELO CONCEPTUAL .......................................................................................................... 84
5.3. MODELO LGICO ................................................................................................................... 84
5.4. MODELO DE DISEO ............................................................................................................. 85
5.4.1. Vista de Capas y Subsistemas .................................................. 85
5.4.1.1. Capa de Presentacin ....................................................................................................... 86
5.4.1.2. Capa de Negocio ................................................................................................................. 86
5.4.1.3. Capa de Integracin .......................................................................................................... 86
5.4.1.4. Capa de Datos ..................................................................................................................... 86
5.4.1.5. Capa de Entidad.................................................................................................................. 87
5.4.1.6. Capa de Interfaces o Elementos Comunes ............................................................... 87
5.4.2. Realizacin de Casos de Uso Modelo de Diseo ............. 87
5.4.2.1. Cdigo del CUS Nombre del CUS.............................................................................. 87
5.4.2.2. Diagrama de Clases de Diseo...................................................................................... 87
6. Vista de Despliegue ......................................................................... 88

7. Vista de Datos ................................................................................... 88

1. Introduccin
[Describa de manera breve el contenido del documento orientando la

descripcin hacia la utilidad que la misma busca. Recuerde que para la
elaboracin del documento debe considerar lo desarrollado en el Reporte de
Especificacin de Software (RES) y que es posible que en esta seccin se
pueda complementar la informacin del documento base RES.]
1.1. Propsito
[En esta seccin se debe proporcionar una visin general de la
arquitectura del sistema haciendo referencia a las diferentes vistas que
implementarn los diferentes aspectos.]
1.2. Alcance
[Indicar cul es el alcance del documento. Considere que en el RES se
ha desarrollado la Vista de Sistema (funcional) y que para completar la
visin total es necesario incluir la vista de arquitectura, vista lgica,
vista de implementacin, vista de despliegue y vista de datos. A
menudo es necesario incluir una representacin de la arquitectura con
consideraciones de infraestructura tecnolgica, relacin con otros
sistemas y una vista de procesos en donde se describe la
descomposicin del sistema en procesos y los mtodos de
comunicacin del sistema.]
1.3. Definiciones, Acrnimos y Abreviaturas

[Proporcione las definiciones, acrnimos y abreviaturas que se
utilizarn en el desarrollo del documento.]
1.3.1. Definiciones
[Indique cada una de las definiciones que son relevantes para
el entendimiento del presente documento. Cada definicin
deber ir acompaada de una breve descripcin.]
Definicin Descripcin
Asistente de Gestin Trabajador encargado de
procesar las rectificaciones de
los ciudadanos que lo solicitan.
Tambin coordina las entregas
de hologramas.
1.3.2. Acrnimos
[Indique cada una de los acrnimos que son relevantes para el
entendimiento del presente documento, para el entendimiento
de la arquitectura propuesta y para el diseo detallado. Cada
acrnimo deber ir acompaada de una breve descripcin.]
Acrnimo Descripcin
RUP Rational Unified Process

82
1.3.3. Abreviaturas
[Indique cada una de las abreviaturas que son relevantes para
el entendimiento del presente documento, para el
entendimiento de la arquitectura propuesta y para el diseo
detallado. Cada abreviatura deber ir acompaada de una
breve descripcin.]
Acrnimo Descripcin
SIGA Sistema Integrado de Gestin
Administrativa
1.4. Referencias
[Mencione los documentos que sirven como entrada, o salida, y
herramientas que se usarn para el desarrollo del presente
documento.]
2. Vista General de la Arquitectura
[En esta seccin describa la arquitectura de software para el sistema actual, y

cmo este ser representado. De las vistas de casos de uso, lgica, procesos,
despliegue e implementacin; se enumerarn las vistas necesarias, y por cada
vista, se deber explicar qu tipo de elementos del modelo contienen.]
Ejemplo:
A continuacin se muestra la Arquitectura del Sistema ABC, sta est
dividida en tres capas:
Capa de Presentacin
Capa de Negocios
Capa de Integracin
As mismo la aplicacin por un criterio de funcionalidad se ha dividido
en seis mdulos:
Mdulo de Administracin del Negocio
Mdulo de Empaquetamiento
Mdulo de Mensajera
Mdulo de Administracin de Datos
Servicios Web X12
Componentes EDI
Web SGSS Capa de

Presentacin
Servicios Web X12 Componentes Capa de

Mdulo de EDI Aplicacin y
Lgica de
Administracin Negocio
del Negocio Mdulo de Mdulo de
Aplicativo
Empaquetam. Mensajera
Externo 1
Mdulo de Administracin
Aplicativo
de Datos
Externo N
Capa de
Base de
Base de Datos del Sistema Base de Base de Base de Datos
Datos 1 Datos 2 Datos N
La figura anterior muestra la distribucin de los mdulos del software

que tendr el sistema, adems de brindar una visin general del

sistema. En el grfico, se observa la distribucin en tres capas de la
arquitectura, las cuales se describen a continuacin.
Capa de presentacin
En esta capa se encuentra la aplicacin Web dedicada a la
administracin y configuracin DEL SISTEMA XYZ, la cual estar
conformada por las pantallas de presentacin al usuario. Estas
aplicaciones Web sern pginas ASP.NET.
Capa de Lgica de Negocio

Esta capa provee todo lo que es la lgica del negocio, es decir la
funcionalidad del sistema, ya sean los procesos administrativos, y
los procesos referidos a la elegibilidad, crdito hospitalario (cartas
de garanta) y crdito ambulatorio (pedidos de reembolso).
Adems, en esta capa se encuentran los servicios publicados, como
los Web Services y los Servicios EDI sobre TCP/IP.
Capa de acceso a datos

Esta capa provee los servicios y conexiones a la base de datos
requeridos por la capa de lgica de Negocio. Por otro lado, el
manejador de base de datos utilizado para este sistema ser
Microsoft SQL Server 2000.
3. Metas y Restricciones de la Arquitectura
[En sta seccin se describe describen los requerimientos de software y

objetivos que tienen algn significativo impacto sobre la arquitectura; por
ejemplo: seguridad, privacidad de uso del producto, portabilidad, distribucin
y reuso. Esto tambin captura las restricciones especiales que quizs apliquen
en la: Estrategia de diseo e implementacin, herramientas de desarrollo,
estructura del equipo, cronograma, leyes y regulaciones legales y otros. Las
restricciones que aqu se recogen pueden complementar a las identificas en el
RES a excepcin de aquellas funcionales.]
4. Vista de Casos de Uso
[En sta seccin se listan los casos de uso o escenarios del modelo de casos
de uso. Debe tomar como referencia lo desarrollado en el RES en los puntos
punto 7.3, 7.4 y 7.5. Recuerde que debe respetar la codificacin indicada en
el RES para los paquetes y para los casos de uso. Si fuse necesario ampliar en
esta seccin recuerde que es necesario se actualice el RES.]
5. Vista Lgica
[La vista lgica est representada por los diagrama de clases del sistema
donde se muestran sus relaciones estructurales y de herencia. La definicin
de clase incluye definiciones para atributos y operaciones. El modelo de casos
del punto 3 del presente documento uso aporta informacin para establecer
las clases, objetos, atributos y operaciones.]

84
5.1. Realizacin de Casos de Uso Modelo de Anlisis

[Esta seccin ilustra cmo el software trabaja a partir de los casos de
uso o escenarios seleccionados, y explica cmo varios elementos del
modelo de anlisis contribuyen con ellos funcionalmente. Por cada caso
de uso deber desarrollar un diagrama de secuencia y de clases de
anlisis. Para ello deber usar el patrn MVC. Para la realizacin
deber identificar los escenarios. Dichos escenarios se obtienen de las
combinaciones entre el flujo principal y flujos alternativos del la
especificacin expandida de casos de uso (ver punto 7.8.2 del RES).]
5.1.1. Cdigo del CUS Nombre del CUS
[Identifica el escenario a ser realizado y una breve descripcin. Se

recomienda identificar con un cdigo nico a cada escenario. Por
ejemplo ESC01]
Diagrama de Secuencia de Anlisis
[Incluya el diagrama de secuencia de anlisis en el cual se

observe el uso del patrn MVC que implementa el escenario
identificado.]
5.1.2. Diagrama de Clases de Anlisis

[Incluya el diagrama de clases de anlisis obtenido del conjunto
de diagramas de secuencia que se implementan por cada
escenario.]
5.2. Modelo Conceptual

[Esta seccin ilustra cmo a partir de las clases del tipo entidad se
pueden identificar una primera propuesta de modelo de persistencia.
Para ello se utiliza un diagrama clases por cada paquete que forma
parte de la arquitectura del sistema. Se puede hacer uso de tarjetas
CRC para documentar las responsabilidades y colaboraciones de cada
clase de persistencia identificada.]
5.3. Modelo Lgico

[El modelo lgico es el refinamiento del Modelo Conceptual. Aqu se
reducen y/o aumentan clases y slo quedan aquellas que van a ser
diseadas como tablas de la Base de Datos. El modelo lgico debe
representarse con un diagrama de clases de acuerdo a la arquitectura
propuesta. Tenga presente que para la transformacin del modelo
conceptual al modelo lgico se debe tener en cuenta:
Pasar las reglas de negocio
Colocar las multiplicidades entre clases
Identificar los atributos de Enlace o Clase de Enlace de las
asociaciones de muchos a muchos
NO INCLUIR los atributos identificadores de la clase (se agregarn
en el modelo fsico)
Incluir los atributos de las clases que se necesitan para satisfacer
los requerimientos del sistema
Documentar un registro de glosario de trminos

Verificar que las reglas de negocio se sigan cumpliendo.

Se sugiere que por cada clase se tenga un diccionario que incluya el
nombre, el tipo, la descripcin, atributos, tipo de dato, visibilidad y
valor inicial]
Nombre Nombre de la Clase
Tipo Tipo de Clase (Ejemplo Entidad)
Descripcin Descripcin de la clase identificando que representa
Atributo Tipo de Dato Visibilidad Valor inicial
Nombre del Integer / String Pblico /
atributo / Boolean Privado
5.4. Modelo de Diseo

[En esta seccin debe representar el refinamiento del modelo de
anlisis considerando los requisitos no funcionales identificados en el
RES.]
5.4.1. Vista de Capas y Subsistemas

[Incluir el diagrama en el que se represente la arquitectura de
diseo. Para ello puede usar un patrn en el cual se usen
capas y subsistemas. Adems deber identificar subsistemas
requeridos por el uso de algn patrn de diseo como el DAO
Factory, Singleton, Front Controller, entre otros. Por cada capa
y subsistema deber identificar las clases de diseo que se
implementarn]

86
<<layer>>
Presentacion
<<layer>>
Business
<<layer>>
Integration
<<layer>>
Interface
<<layer>>
Entidad
<<layer>>
Data
5.4.1.1. Capa de Presentacin

[Identifique las clases de diseo de la capa de
presentacin. Ordene dicha identificacin
utilizando los paquetes al interior de las capas
denominados subsistemas.]
5.4.1.2. Capa de Negocio

negocio. Ordene dicha identificacin utilizando
los paquetes al interior de las capas
5.4.1.3. Capa de Integracin

integracin. Ordene dicha identificacin
5.4.1.4. Capa de Datos

datos. Ordene dicha identificacin utilizando los

paquetes al interior de las capas denominados

subsistemas.]
5.4.1.5. Capa de Entidad

entidad. Ordene dicha identificacin utilizando
los paquetes al interior de las capas
5.4.1.6. Capa de Interfaces o Elementos

Comunes
elementos comunes. Ordene dicha identificacin
5.4.2. Realizacin de Casos de Uso Modelo de Diseo

[Esta seccin deber desarrollar los diagramas de secuencia y
de clases de diseo a partir de los requisitos no funcionales
identificados en el RES y considerando los escenarios
identificados en el punto 4.1 del presente documento. Debe
asegurarse que las clases que se incorporen deben ser
aquellas que se han identificado en el punto 4.4.1 del presente
documento.]
5.4.2.1. Cdigo del CUS Nombre del CUS
[A partir de los casos de uso realizados del modelo
de anlisis deber identificar los casos de uso que
usar para las realizaciones de diseo.]
[Identifica el escenario a ser realizado y una breve

descripcin. Se recomienda identificar con un
cdigo nico a cada escenario. Por ejemplo ESC01.
Deber reusar los escenarios identificados en el
modelo de anlisis]
Diagrama de Secuencia de Diseo
[Incluya el diagrama de secuencia de diseo en el

cual se observe el uso de patrones de diseo para
las clases que implementarn cada una de las
clases lgicas.]
5.4.2.2. Diagrama de Clases de Diseo

[Incluya el diagrama de clases de diseo
obtenido del conjunto de diagramas de
secuencia que se implementan por cada
escenario.]

88
6. Vista de Despliegue
[En esta seccin se describen unas o ms configuraciones fsicas de la red
(hardware) que se usarn para el despliegue de los componentes de software
que forman parte de la solucin. Para ello puede usar un Diagrama de
Despliegue indicando como mnimo, para cada configuracin, en qu nodos
fsicos (computadoras, CPU) se ejecuta el software y sus interconexiones
(bus, LAN, punto a punto, y as sucesivamente). De ser posible se debe incluir
un mapeo de los procesos de la vista de procesos sobre los nodos fsicos.
Adems deber especificar los detalles tcnicos de cada nodo en la vista de
despliegue.]
Sistema Operativo
Windows 2000/XP/2003
Professsional
Internet Explorer 6.0 o
superior
PC Cliente Interno PC Cliente Interno
Sistema Operativo
Intranet Windows 2003 Server
COM+ (Component
Sistema Operativo
Services)
Windows 2003 Server
Sistema Operativo Net Framewok 2.0
SQL Server 2000
Windows 2003 Server
IIS (Internet Information
Server)
Net Framework 2.0
Servidor Intranet Servidor COM+ Servidor BD Sistema Operativo

Windows 2003 Server
Inmuebles SQL Server 2000
Adjudicados Sistemas:
Presupuesto Spring (Macro)
Contabilidad MC
Archivo Excel Adelantos (Macro)
Servidor BD Otros Sistemas Provisiones (Macro)
Inmuebles Propios
Internet
Mainframe IBM ZSeries
Web Service Interface Spring Comprobantes
PagoActivo Contabilidad
HOST
7. Vista de Datos
[Se debe describir la perspectiva persistente del almacenaje de datos
del sistema. Deber incluir el Modelo de Base de Datos Lgico y Fsico,
as como el diccionario de datos.]

Resumen
El desarrollo de sistemas hoy en da ha tomado gran importancia en el mundo
siendo sta cada vez ms creciente.
Aunque esta importancia tienda a aumentar, no todo tiene una buena

perspectiva, existen inconvenientes en el desarrollo de los sistemas: grandes
retrasos en la programacin, inconsistencia en su funcionamiento, entre otros;
pero lo ms importante es la falta de calidad, punto de gran inters e importancia
para el logro de eficiencia y productividad de los sistemas.
Es claro que si un sistema presenta errores al momento de ser utilizado, ese

producto pierde confiabilidad a los ojos del usuario hasta el nivel que podra ser
desechado como un producto defectuoso.
Por esta razn los proyectos de sistemas que presentan fallas impiden que el
sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por
ello, es necesario definir e impulsar lneas de accin tendientes a mejorar el
sistema producido. Dentro de estas lneas de accin est la relacionada con el
proceso mismo del desarrollo del sistema, y como necesidad primordial, la de
realizar una investigacin que permita conocer de primera mano el estado en que
se encuentra su proceso de desarrollo.
Si desea saber ms acerca de estos temas, puede consultar las siguientes

pginas.
http://www.calidaddelsoftware.com
Aqu encontrar diferentes temas relacionados con la mejora de procesos de
desarrollo de software.
http://alarcos.inf-cr.uclm.es/Competisoft/
Aqu encontrar diferentes temas relacionados con la mejora de procesos
enfocadas a pequeas empresas.

90

UNIDAD DE
APRENDIZAJE
MTRICAS DE SOFTWARE
Al trmino de la unidad de aprendizaje, el alumno elabora un catlogo de

mtricas de funcionalidad relacionadas con el producto software en
desarrollo en el curso de Desarrollo de Aplicaciones Web I.
TEMARIO
2.1. Tema 6: Modelos de Calidad de Software

2.1.1. Introduccin
2.1.2. Perspectivas de Calidad
2.1.3. Calidad desde el Punto de Vista del Proceso
2.1.4. Calidad desde el Punto de Vista del Producto
2.1.5. Calidad desde el Punto de Vista de las Personas
2.2. Tema 7: Mtricas de Calidad de Producto Software

2.2.1. ISO/IEC 9126-1 Modelo de Calidad
2.2.2. ISO/IEC 9126-2 Mtricas Externas
2.2.3. ISO/IEC 9126-3 Mtricas Internas
2.2.4. Relacin Entre las Mtricas Internas y Externas
2.2.5. ISO/IEC 9126-4 Mtricas para Calidad en Uso
2.2.6. ISO/IEC 25000:2005 - SQuaRE
2.3. Tema 8: Evaluacin de Mtricas

2.3.1. Definiciones
2.3.2. Proceso de Evaluacin

92
2.1. MODELOS DE CALIDAD DE SOFTWARE
2.1.1. Introduccin
Los Modelos de Calidad son aquellos documentos que integran la

mayor parte de las mejores prcticas, proponen temas de
administracin en los que cada organizacin debe hacer nfasis,
integran diferentes prcticas dirigidas a los procesos clave y permiten
medir los avances en calidad.
Los Estndares de Calidad son aquellos que permiten definir un

conjunto de criterios de desarrollo que guan la forma en que se aplica
la Ingeniera del Software. Los estndares suministran los medios para
que todos los procesos se realicen de la misma forma y son una gua
para lograr la productividad y la calidad.
Los Modelos y/o Estndares permiten que las Empresas de Software

realicen sus tareas y funciones teniendo en cuenta la Calidad.
Cualquier organizacin que se dedica a la investigacin, produccin y
comercializacin de software debe considerar la calidad, hoy con ms
razn, donde existe un mercado en el cual el cliente es cada vez ms
exigente, no slo en lo que se refiere al precio, sino sobre todo, en
cuanto a los servicios y a la confiabilidad que brindan los productos de
software. La calidad desempea un rol determinante para la
competitividad de la empresa. Cuando una empresa est funcionando
y decide implantar un Modelo / Estndar de Calidad del Software, es
seal que la empresa tiene el propsito de hacerse cada vez ms
profesional homogenizando los criterios sobre los cuales se debe
producir los productos y los servicios de software, que brindarn
satisfaccin a sus clientes y por lo tanto velarn por los intereses de
los accionistas.
2.1.2. Perspectivas de Calidad
Es necesario tener en cuenta cuales son las principales perspectivas

cuando se habla de La Calidad. Como se puede observar en la
siguiente figura, existen tres perspectivas bien diferenciadas y
relacionadas entre s, que en el caso del software seran:
La calidad desde el punto de vista del producto: que

tiene en cuenta las caractersticas internas y externas del
producto software en s.
La calidad desde el punto de vista de los procesos: que
tiene en cuenta las tareas, actividades y procesos que se
siguen para obtener el producto software.
La calidad desde el punto de vista de las personas:
evaluando la formacin, experiencia, etc. de las personas
involucradas en los procesos para obtener el producto
software.

2.1.3. Calidad desde el Punto de Vista del Proceso
La calidad desde el punto de vista del proceso considera el

hecho que el control de calidad no se realiza slo al sistema en
s mismo, sino tambin se abarca todas las actividades de los
procesos utilizados para desarrollar el producto software. En
este sentido en cada una de las etapas del ciclo de vida de
producto se llevarn actividades de control de calidad,
garantizando se ha verificado y validado cada uno de los
componentes de tal forma que se asegura la calidad del
producto a partir del aseguramiento de la calidad del proceso.
Es cierto que mientras ms se invierta en calidad del proceso

mayores sern los costos pero tambin es cierto que mayores
sern los beneficios obtenidos en la fase de mantenimiento del
software. La calidad del software, por lo tanto, no se disea y
planifica cuando ya se tiene el producto; muy por el contrario se
planifica desde las primeras etapas del ciclo de vida del
producto.
Una de las formas de evaluar la calidad es ejecutando

revisiones, las que permiten establecer un marco comn para la
definicin de distintas etapas de revisin en el ciclo de vida del
software este mecanismo no slo est pensado para las etapas
tempranas del ciclo de vida, sino que tambin puede - y debe -
ser utilizado en etapas como la de prueba de software y
mantenimiento. El mecanismo ms comn para su
implementacin es la reunin de revisin, la cual deber regirse,
para asegurar su xito, por una buena planificacin, control y,
sobre todo, por la participacin dedicada de todos y cada uno de
los involucrados.
Para implementar los conceptos de calidad desde el punto de

vista del proceso tambin existen diferentes Modelos y/o
Estndares de Calidad que proporcionan un marco comn para
orientar los esfuerzos de aseguramiento de calidad. Por ejemplo
la norma ISO/IEC 15504, tambin conocida como SPICE
(Software Process Improvement and Capability dEtermination),
es una norma internacional para establecer y mejorar la
capacidad y madurez de los procesos de las organizaciones,
proporcionando los principios requeridos para realizar una

94
evaluacin de la calidad de los procesos. Esta norma se puede

utilizar junto con la ISO/IEC 12207 que establece un conjunto de
buenas prcticas para guiar a las organizaciones en la mejora
de sus procesos de desarrollo y mantenimiento de software.
Dicha norma define 43 procesos que pueden aplicarse durante
la adquisicin de un producto o servicio software y durante el
suministro, desarrollo, operacin, mantenimiento y evolucin de
productos software.
La norma ISO/IEC 15504 permite adems realizar evaluaciones

usando niveles de madurez. Los niveles de madurez son
conjuntos predefinidos de procesos que ayudan a una
organizacin a mejorar en el desarrollo software evolucionando
por los distintos niveles.
En esta norma, se han establecido 6 niveles que indican la

madurez de la organizacin. Como se observa en la Figura No.
2.2., el nivel inferior (nivel 0) se corresponde con una
organizacin inmadura, los siguientes niveles van haciendo
crecer a la organizacin en su madurez, hasta el mximo nivel,
el nivel 5.
Figura 2.1 Niveles de Madurez
La consecucin de los niveles de madurez es de forma escalonada,

esto significa que para alcanzar un determinado nivel de madurez
deben haberse alcanzado tambin los niveles inferiores.
Cada nivel de madurez estar formado por un conjunto de procesos,

estos procesos se definen en los esquemas de certificacin

2.1.4. Calidad desde el Punto de Vista del Producto
La calidad desde el punto de vista del producto se aborda con el uso

de Modelos y/o Estndares de Calidad. Dichos modelos ayudan a la
puesta en prctica del concepto general de calidad ofreciendo una
definicin ms operacional.
En los Modelos de Calidad de Producto, la calidad se define de forma

jerrquica. Es un concepto que se deriva de un conjunto de sub-
conceptos, cada uno de los cuales se va a evaluar a travs de un
conjunto de indicadores o mtricas. La estructura es por lo general de
tres (3) niveles (Ver figura 2.2).
Figura 2.2 Estructura de un Modelo de Calidad de Software
Al utilizar los Modelos de Calidad de Producto, se lleva la calidad a

algo concreto, algo que se puede definir, que se puede medir y, sobre
todo, que se puede planificar. Tambin permiten identificar y
comprender las relaciones que se establecen y existen entre las
diferentes caractersticas de un producto de software.
La calidad del producto de software abarca los siguientes aspectos:

Calidad Interna: que se puede medir a partir de las caractersticas
intrnsecas del producto, por ejemplo el cdigo fuente.
Calidad Externa: que se puede medir a partir del comportamiento del
producto, por ejemplo durante la ejecucin de una prueba.
Calidad en Uso: que se puede medir durante la utilizacin efectiva que
hace del producto el usuario final.
Para lograr la calidad suficiente en estos tres aspectos es necesario

conocer con suficiente detalle las necesidades reales y expectativas
de los usuarios.

96
2.1.5. Calidad desde el Punto de Vista de las Personas
Claramente, cualquier proceso de software depende de la calidad de

la/s persona/s que lo desarrolla.
La optimizacin de los procesos provee un ambiente de disciplina para

trabajar de manera ms formal. La disciplina debe ser manejada con
cuidado, ya que, es fcil que se convierta en autoritarismo. La
diferencia entre un ambiente con disciplina y otro con autoritarismo, es
que el ambiente disciplinado controla el entorno y los mtodos para
especificar un estndar, mientras que un ambiente autoritario define la
forma actual del trabajo.
La disciplina es requerida en grandes proyectos de software para

asegurar, por ejemplo, que todo el personal involucrado utilice la
misma convencin, no daar los productos de otros equipos, y
sincronizar apropiadamente el trabajo.
En la tabla 3 se muestra una lista resumida de algunos modelos y

estndares de calidad.
Nivel de Calidad Modelo de Calidad de SW Estndar de Calidad de SW

CMMi ISO 9003
TickIT ISO 12207
Bootstrap ISO 15504 (SPICE)
Proceso Six Sigma Software IEE/IEA 12207
ISO 20000
ITIL
Cobit
Gilb ISO 9126-1
GQM ISO 25000 (SQUARE)
Mc Call IEEE Std. 1061-1998
Furps
Boehm
Producto
SATC
Dromey
C-QM
Metodologa SQAE
WebEQM
Personal SW Process (PSP)
Personas
Team SW Process (TSP)
Tabla No. 3 Modelos y Estndares de Calidad de Software

2.2. MTRICAS DE CALIDAD DE PRODUCTO SOFTWARE

La ISO, bajo la norma ISO-9126, ha establecido un estndar internacional para
la evaluacin de la calidad de productos de software el cual fue publicado en
1992 con el nombre de Information technology Software product evaluation:
Quality characteristics and guidelines for their use, en el cual se establecen las
caractersticas de calidad para productos de software.
El estndar ISO-9126 establece que cualquier componente de la calidad del

software puede ser descrito en trminos de una o ms de seis caractersticas
bsicas, las cuales son: funcionalidad, confiabilidad, usabilidad, eficiencia,
mantenibilidad y portatilidad; cada una de las cuales se detalla a travs de un
conjunto de subcaractersticas que permiten profundizar en la evaluacin de la
calidad de productos de software. La tabla 4 muestra la pregunta central que
atiende cada una de estas caractersticas.
Caracterstica Pregunta Central

Las funciones y propiedades satisfacen las necesidades
Funcionalidad explcitas e implcitas; esto es, el qu ?
Puede mantener el nivel de rendimiento, bajo ciertas
Confiabilidad condiciones y por cierto tiempo?
Usabilidad El software es fcil de usar y de aprender?
Eficiencia Es rpido y minimalista en cuanto al uso de recursos?
Mantenibilidad Es fcil de modificar y verificar?
Portabilidad Es fcil de transferir de un ambiente a otro?
Tabla No. 4 Caractersticas de ISO 9126 y aspecto que atiende cada una
La ISO/IEC 9126 est formada por las siguientes partes:

Parte 1 Modelo de Calidad
Parte 2 Mtricas Externas
Parte 3 Mtricas Internas
Parte 4 Calidad en Uso
2.2.1. ISO/IEC 9126-1 Modelo de Calidad
Esta parte de la ISO 9126 describe el modelo de calidad del producto de

software. La primera parte del modelo especifica 6 caractersticas de
calidad interna y externa, las cuales estn divididas en
subcaractersticas, que se manifiestan externamente cuando el software
es utilizado como parte de un sistema, y son un resultado de atributos
internos del software.
La calidad externa evala que el software satisfaga las necesidades del

usuario teniendo en cuenta las condiciones especificadas. Esta calidad
es medible en el comportamiento del producto.
La calidad interna evala el total de atributos que un software debe

satisfacer teniendo en cuenta condiciones especificadas. Esta calidad
es medible a partir de las caractersticas intrnsecas.

98
Las caractersticas definidas son aplicables a todo tipo de software. Las

caractersticas y subcaractersticas proveen una terminologa
consistente respecto de la calidad del producto del software.
Esta Norma permite especificar y evaluar la calidad del software desde

distintas perspectivas, las cuales estn asociadas a la adquisicin,
requerimientos, desarrollo, uso, evaluacin, soporte, mantenimiento,
aseguramiento de la calidad, y auditoria del software. Puede ser usada
por desarrolladores, evaluadores independientes y grupos de
aseguramiento de la calidad responsable de especificar y evaluar la
calidad del software.
La evaluacin de los productos de software que satisfacen las

necesidades de calidad del software es uno de los procesos del ciclo de
vida de desarrollo del software. La calidad del producto de software
puede ser evaluada por medio de la medicin de atributos internos,
externos o a travs de la calidad en uso (Figura 2.3). El objetivo es que
el producto tenga el efecto requerido en un contexto particular de uso.
La calidad del proceso contribuye a mejorar la calidad del producto, y la
calidad del producto contribuye a mejorar la calidad en uso. Evaluar y
mejorar la calidad de un proceso contribuye a mejorar la calidad del
producto; y esto contribuye a mejorar la calidad en uso. De manera
similar, evaluar la calidad en uso puede mejorar la calidad del producto,
y evaluar un producto puede mejorar un proceso.
Figura 2.3 Calidad en el Ciclo de Vida segn ISO/IEC 9126-1
Las necesidades de calidad del usuario contribuyen a especificar los

requisitos de calidad externa, los cuales contribuyen a especificar los
requisitos de calidad interna. La calidad interna indica la existencia
de calidad externa y sta indica la existencia de calidad en uso
(Figura No. 2.4).

Figura 2.4 Relacin de Mtricas del Modelo / Atributos en ISO/IEC 9126-1
2.2.2. ISO/IEC 9126-2 - Mtricas Externas
ISO/IEC TR 9126-2 provee mtricas externas para la medicin de

atributos a travs de 6 caractersticas de calidad externa definidas en
ISO/IEC 9126-1.
ISO/IEC TR 9126-2 define mtricas externas., ISO/IEC TR 9126-3

define mtricas internas e ISO/IEC 9126-4 define mtricas en calidad en
uso para la medicin de caractersticas o subcaractersticas.
Las mtricas internas miden el software en s mismo, las mtricas

externas miden el comportamiento del sistema basado en computadora
que incluye el software, y las mtricas de calidad en uso miden los
efectos de uso del software en un contexto de uso especfico.
Las mtricas externas usan medidas de un software, derivadas del

comportamiento del mismo, a travs de la prueba, operacin y
observacin del software. Antes de adquirir o usar un software, ste
debe ser evaluado usando las mtricas basadas en los objetivos del
rea usuaria de la institucin relacionados al uso, explotacin y
direccin del producto, considerando la organizacin y el ambiente
tcnico. La mtrica externa proporciona a los usuarios, evaluadores,
verificadores y desarrolladores, el beneficio que puedan evaluar la
calidad del software durante las pruebas o el funcionamiento.
Las mtricas externas listadas en ISO/IEC TR 9126-2 no estn

destinadas a ser un conjunto exhaustivo. Los desarrolladores,
evaluadores, gerentes de calidad y compradores pueden seleccionar

100
mtricas de ISO/IEC TR 9126-2 para definir requerimientos, evaluar

productos de software, medir aspectos de calidad y otros propsitos.
Los usuarios de ISO/IEC TR 9126-2 pueden seleccionar o modificar y

aplicar mtricas y mediciones a partir de ISO/IEC TR 9126-2 o pueden
definir mtricas especficas de la aplicacin para su dominio de
aplicacin en particular. ISO/IEC TR 9126-2 es usada junto con ISO/IEC
9126-1. ISO/IEC TR 9126-2 contiene una explicacin de cmo aplicar
las mtricas de calidad del software, un conjunto bsico de mtricas
para cada Subcaracterstica y un ejemplo de cmo aplicar las mtricas
durante el ciclo de vida del producto de software. ISO/IEC TR 9126-2 no
asigna un rango de valores para estas mtricas en niveles de
porcentajes o grados de conformidad, debido a que estos valores son
definidos en cada producto de software o en una parte del producto de
software, dependiendo de factores tales como la categora del software,
nivel de integridad y necesidades del usuario. Algunos atributos pueden
tener un rango de valores deseable, el cual no depende de las
necesidades especficas del usuario pero si depende de factores
genricos; por ejemplo factores humanos.
2.2.3. ISO/IEC 9126-3 - Mtricas Internas
ISO/IEC TR 9126-3 provee mtricas internas para la medicin de

atributos a travs de 6 caractersticas de calidad interna definidas en
ISO/IEC 9126-1.
La mtrica interna mide el software en s mismo y puede ser aplicada a

un software no ejecutable (como una especificacin o cdigo fuente)
durante el diseo y la codificacin. En el desarrollo de un software, los
productos intermedios deben ser evaluados usando mtricas internas
que permitan medir las propiedades intrnsecas, incluyendo aquellas
que pueden derivarse de comportamientos simulados. El propsito
principal de esta mtrica interna es asegurar que se logre la calidad
externa y la calidad de uso requerida. La mtrica interna proporciona a
los usuarios, evaluadores, verificadores y desarrolladores el beneficio
que puedan evaluar la calidad del software y lo referido a problemas de
calidad antes que el software sea puesto en ejecucin.
Las mtricas internas miden atributos internos o indican los atributos

externos, a travs del anlisis de las propiedades estticas de productos
intermedios o entregables del software. Las medidas de las mtricas
internas usan nmeros o frecuencias de elementos de composicin de
software, los cuales aparecen, por ejemplo, en las sentencias de cdigo
de fuente, control de grficos, flujo de datos y estados de
representacin de procesos Las mtricas listadas en ISO/IEC TR 9126-
3 no estn destinadas a ser un conjunto exhaustivo. Los
desarrolladores, evaluadores, gerentes de calidad y compradores
pueden seleccionar mtricas de ISO/IEC TR 9126-3 para definir
requerimientos, evaluar productos de software, medir aspectos de
calidad y otros propsitos. ISO/IEC TR 9126-3 es usada junto con
ISO/IEC 9126-1.
ISO/IEC TR 9126-3 contiene una explicacin de cmo aplicar las

mtricas de calidad del software, un conjunto bsico de mtricas para
cada Subcaracterstica y un ejemplo de cmo aplicar las mtricas

durante el ciclo de vida del producto de software. ISO/IEC TR 9126-3 no

asigna un rango de valores para estas mtricas en niveles de
porcentajes o grados de conformidad, debido a que estos valores son
definidos en cada producto de software o en una parte del producto de
software, dependiendo de factores tales como la categora del software,
nivel de integridad y necesidades del usuario. Algunos atributos pueden
tener un rango de valores deseable, el cual no depende de las
necesidades especficas del usuario pero si depende de factores
genricos; por ejemplo factores humanos.
En la tabla No. 5 se muestra un ejemplo de mtrica, tanto para calidad externa

como para calidad interna. Note que las entradas para la medicin difieren.
2.2.4. Relacin Entre las Mtricas Internas y Externas
Cuando los requisitos de calidad del software son definidos, se listan las
caractersticas o subcaractersticas de calidad del software que
contribuyen a dichos requisitos. Entonces, las mtricas externas
apropiadas y los rangos aceptables son especificados para cuantificar el
criterio de calidad que valida que el software satisface las necesidades
del usuario. Luego, los atributos de calidad interna del software se
definen y especifican para planear y finalmente lograr la calidad externa
y calidad en el uso requeridas, para construirlos durante el desarrollo
del producto. Ver Figura No. 2.5.
Las mtricas internas y los rangos aceptables son especificados para

cuantificar los atributos de calidad interna, as ellos pueden usarse para
verificar que el software intermedio rene las especificaciones de
calidad interna durante el desarrollo. Se recomienda que las mtricas
internas que se usen tengan en lo posible una fuerte relacin con la
mtrica externa diseada, para que ellas puedan ser usadas para
predecir los valores de las mtricas externas. Sin embargo, es
generalmente difcil disear un modelo terico riguroso que proporcione
una relacin fuerte entre la mtrica interna y la externa.
Caracterstica Funcionalidad
Sub Caracterstica Aplicabilidad
Mtrica Adecuacin Funcional (Calidad Externa) Adecuacin Funcional (Calidad Interna)
Prposito de la Mtrica Cun adecuadas son las funciones evaluadas? Cun adecuadas son las funciones revisadas?
Nmero de funciones que son adecuadas para Contar el nmero de funciones implementadas en
realizar las tareas especficas comparadas con el las que se detect problemas para realizar las tareas
nmero de funciones evaluadas especificadas y comparar con las funciones
implementadas.
Mtodo de Aplicacin
Se puede medir lo siguiente:
- todas o parte de las especificaciones de diseno
- mdulos/partes completadas de productos de
software
Frmula X=1-A/B X=1-A/B
Nmero de funciones en que se detectaron Nmero de funciones en que se detectaron
Valor A
problemas en la evaluacin problemas en la evaluacin
Valor B Nmero de funciones evaluadas Nmero de funciones revisadas
Interpretacin del valor 0<=X<=1 0<=X<=1
medido Lo ms cerca de 1,0 es lo mejor Lo ms cerca de 1,0 es lo mejor
Especificacin de requerimientos Especificacin de requerimientos
Entrada para la medicin
Reporte de validacin Reporte de validacin
Tabla No. 5 Mtricas de Calidad Externa e Interna

102
2.2.5. ISO/IEC 9126-4 - Mtricas para Calidad en Uso
ISO/IEC TR 9126-4 provee mtricas para la calidad en uso para la

medicin de los atributos definidos en ISO/IEC 9126-1.
Las mtricas de calidad en uso miden los efectos de uso del software en
un contexto especfico de uso. Estas mtricas miden si el producto se
corresponde con las necesidades especficas de los usuarios para as
obtener los objetivos especficos con eficiencia, productividad,
seguridad y satisfaccin en un contexto de uso especfico. Esto solo es
llevado a cabo en un ambiente de sistema realista.
Figura 2.5 Relacin de Calidad Externa / Calidad Interna en ISO/IEC 9126-1
2.2.6. ISO/IEC 25000:2005 SquaRE
SQuaRE (Software Quality Requirements and Evaluation) es una nueva

serie de normas que se basa en ISO 9126 y en ISO 14598 (Evaluacin
del software). Uno de los principales objetivos de la serie SQuaRE es la
coordinacin y harmonizacin del contenido de ISO 9126 y de ISO
15939:2002 (Measurement Information Model). ISO 15939 tiene un
modelo de informacin que ayuda a determinar que se debe especificar
durante la planificacin, performance y evaluacin de la medicin, Para
su aplicacin, cuenta con los siguientes pasos: (1) Recopilar los datos,
(2) Preparacin de los datos y (3) Anlisis de los datos.
Por otro lado, la familia de normas ISO 25000 est formada por 5
divisiones como podemos observar en la Figura No. 2.6 y tiene
principalmente dos objetivos:

1. Establecer un modelo de calidad para el producto software,

definiendo las caractersticas y subcaractersticas que se deben
tener en cuenta.
2. Definir el proceso de evaluacin de la calidad del producto software,

con el fin de poder establecer la calidad en funcin del modelo.
Figura 2.6 Composicin de ISO/IEC 25000
La familia de normas ISO 25000 est actualmente en estado de

desarrollo y desde el punto de vista de la calidad del producto, su
objetivo es sustituir a dos normas:
1. ISO/IEC 9126: que es el conjunto de normas que hasta ahora

defina el modelo de calidad para el producto software.
2. ISO/IEC 14598: que es el conjunto de normas que determina el
proceso para evaluar el producto software.
Por los tanto, mientras la norma ISO/IEC 15504 est orientada a los
procesos y puede ser utilizada para evaluar la capacidad de los
mismos y la madurez de una organizacin respecto a sus procesos, la
familia ISO 25000 est orientada al producto software, permitiendo
definir el modelo de calidad y el proceso a seguir para evaluar dicho
producto.
Finalmente la principal relacin entre estas normas radica en que la

serie de normas ISO 25000 se puede utilizar como referencia cuando se
evalan los procesos de medicin y aseguramiento de la calidad de
una organizacin.

104
Figura 2.7 Relacin ISO 25000 / SPICE
2.3. EVALUACIN DE MTRICAS

2.3.1. Definiciones
Desarrollador de producto software:

Es la persona u organizacin que fabrica un producto software.
Evaluacin de producto software:
Operacin tcnica que consiste en producir una evaluacin y
valorizacin de una o ms caractersticas de un producto de
software de acuerdo a un procedimiento especificado.
NOTA: El trmino evaluacin es preferido con el fin de evitar
confusin con la nocin de prueba ampliamente aceptada en el
campo de la ingeniera de software.
Evaluacin de producto software no es necesariamente una prueba
de conformidad en el contexto de un esquema de certificacin. Sin
embargo, las pruebas de conformidad pueden ser parte de una
evaluacin.
Evaluador:
Es la organizacin que efecta la evaluacin. Un evaluador puede
ser por ejemplo un laboratorio de prueba, el departamento de
calidad de una organizacin de desarrollo de software, una
organizacin gubernamental o un usuario.
Herramienta de evaluacin:
Es el instrumento que puede ser usado durante una evaluacin para
recopilar datos, para efectuar la interpretacin de datos o para
automatizar parte de la evaluacin. Ejemplos de herramientas son
los analizadores de cdigo fuente para calcular mtricas de cdigo,
herramientas CASE para producir modelos formales, ambientes de
prueba para hacer funcionar programas ejecutables, listas de control
para recopilar datos de inspeccin, hojas de clculo para producir
sntesis de medidas.
Mtodo de evaluacin:
Procedimiento que describe la accin a ser ejecutada por el
evaluador con el fin de obtener el resultado para la medicin
especificada o verificacin aplicada en los componentes de producto
especificados o en la totalidad del producto.
Registros de evaluacin:
Evidencia objetiva y documentada de todas las actividades
ejecutadas y de todos los resultados alcanzados dentro del proceso
de evaluacin.

Reporte de evaluacin:
Documento que presenta resultados de evaluacin y otra
informacin relevante a una evaluacin.
Solicitante de evaluacin:
Persona u organizacin que solicita una evaluacin.
2.3.2. Proceso de Evaluacin
Establecer requerimientos de evaluacin; que incluye el

establecimiento de propsitos de la evaluacin, identificar tipo(s) de
producto(s) y la especificacin del modelo de calidad (9126-1
Caractersticas de Calidad).
Especificar evaluacin; que incluye la seleccin de las mtricas
(9126-2 Mtricas Externas, 9126-3 Mtricas Internas), el
establecimiento de los niveles de puntuacin para las mtricas y
establecer los criterios para la evaluacin.
Disear evaluacin; que incluye la generacin del plan de
evaluacin.
Ejecutar evaluacin; que incluye la toma de medidas, comparar los
criterios y evaluar los resultados de la evaluacin.
En la figura No. 2.8 se presenta una propuesta de niveles de puntuacin

de las mtricas que debern ser evaluadas para las caractersticas de
calidad que se definieron, de acuerdo al modelo, para el componente de
producto.
Requerimientos
excedidos
Nivel Planeado
Rango objetivo Satisfactorio

Valor Medido
Nivel Actual
Mnimo
aceptable
Peor caso
Inaceptable
Insatisfactorio
Escala de Medicin Niveles de Puntuacin
Figura 2.8 Niveles de Puntuacin para Mtricas

106
Ejemplo:
A continuacin se presenta un ejemplo de una modelo de calidad con la

definicin de mtricas de calidad externa.
Proyecto SISTEMA DE ADMINISTRACIN DE HORARIOS ACADMICOS
Componente P01-DISPONIBILIDAD
Caracterstica peso % Sub-Caractersticas peso %

Aplicabilidad 7.0 54%
Precisin 6.0 46%
Funcionalidad 7.0 30% Seguridad 0.0 0%
Interoperabilidad 0.0 0%
Conformidad de funcionalidad 0.0 0%
Cambiabilidad 5.0 29%
Analizabilidad 4.0 24%
Facilidad de
5.0 22% Estabilidad 4.0 24%
mantenimiento
Testeabilidad 4.0 24%
Conformidad de facilidad de mantenimiento 0.0 0%
Entendibilidad 5.0 26%
Facilidad de aprendizaje 5.0 26%
Usabilidad 4.0 17% Atractividad 5.0 26%
Operabilidad 4.0 21%
Conformidad de usabilidad 0.0 0%
Madurez 3.0 50%
Tolerancia a fallos 3.0 50%
Fiabilidad 3.0 13%
Recuperabilidad 0.0 0%
Conformidad de fiabilidad 0.0 0%
Comportamiento en el tiempo 3.0 50%
Eficiencia 3.0 13% Utilizacin de recursos 3.0 50%
Conformidad de eficiencia 0.0 0%
Instalabilidad 3.0 33%
Adaptabilidad 2.0 22%
Portabilidad 1.0 4% Co-existencia 2.0 22%
Reemplazabilidad 2.0 22%
Conformidad de Portabilidad 0.0 0%
P01 - DISPONIBILIDAD
Carcaterstica Subcaraterstica Mtrica (Atributo de Calidad) Peso % Valor de Mtrica RNF

Las funciones del Mdulo de
Disponibilidad deben ser
Adecuacin funcional adecuadas por lo menos en el 70%
de los casos al proceso de Gestin
6 40% 70% de Horarios.
Aplicabilidad Disponibilidad deben estar
Integridad de Implementacin funcional
desarrolladas completamente por lo
5 33% 60% menos al 60%.
Disponibilidad deben estar
Cobertura de implementacin funcional
desarrolladas correctamente por lo
Funcionalidad 4 27% 60% menos al 60%.
El 60% de las funciones del
Mdulo de Disponibilidad deben
Precisin esperada
realizar los clculos con la
5 42% 60% precisin de 2 decimales definida.
Mdulo de Disponibilidad deben
Precisin Proveer la Informacin con un grado
realizar los clculos correctos con
necesario de precisin
la precisin de 2 decimales
4 33% 60% definida.
Exactitud de clculo Mdulo de Disponibilidad deben
3 25% 50% realizar los clculos correctos.
Figura 2.9 Modelo de Calidad
Figura 2.10 Mtricas de Calidad

CATALOGO DE MTRICAS DE FUNCIONALIDAD

SISTEMA DE ADMINISTRACIN DE HORARIOS ACADMICOS
1. P01 DISPONIBILIDAD
1.1. Mtricas de Aplicabilidad
Cdigo FUN-APLIC-001
Caracterstica Funcionalidad
Abreviatura Caract. FUN
Peso Caract. 7
Sub Caracterstica Aplicabilidad
Abreviatura Sub Caract. APLIC
Peso Sub Caract. 7
Atributo Adecuacion funcional
Nro Atributo 1
Enunciado 9126 u otro Cun adecuadas son las funciones evaluadas?
Pregunta (peso) Qu tan importante es que las funciones del Mdulo de
Disponibilidad sean adecuadas al proceso de Gestin de
Horarios Acadmicos?
Peso Relativo 40%
Peso Absoluto 6
Pregunta (mtrica) Cuntas de las funciones Crticas del Mdulo de
Disponibilidad deben ser adecuadas al proceso de Gestin de
Horarios Acadmicos?
Mtrica 70%
Mtodo de aplicacin Evaluar las funciones y contar las que son adecuadas respecto
del total evaluadas.
Frmula X =1A/B
Primer valor (A) 0
Segundo Valor (B) 1
Valor Obtenido 100%
Figura 2.11 Catlogo de Mtricas

108
Actividades
Desarrollar el modelo de calidad de los principales componentes del sistema
bajo desarrollo del proyecto integrado
Definir las mtricas de calidad externa, para cada uno de los principales
componentes del sistema bajo desarrollo del proyecto integrado, precisando
el peso absoluto y el peso relativo en funcin a la escala definida.
Actualizar el RES con los atributos de calidad previamente identificados.
Definir el catlogo de mtricas.
Actualizar el valor obtenido a partir del plan de pruebas y de evaluacin de
mtricas.

Resumen
El mundo globalizado exige cada vez ms la aplicacin de estndares

internacionales que garanticen la calidad de los productos. Por esta razn, es
necesario que todo aquel que se dedica al desarrollo de software incluya en sus
procesos, estndares de calidad que permitan certificarse en alguno de los
modelos.
Aqu se ha presentado un estndar, el ISO 9126, el cual establece una gua para
la evaluacin de la calidad de software, sin embargo es necesario que cada
empresa dedicada a producir software trabaje en establecer su modelo de calidad
que le permita valorar el nivel de excelencia de sus productos, en el que deber
incluirse instrumentos de medicin que permitan calificar cuantitativamente cada
una de las caractersticas aqu presentadas. Es importante mencionar, que
dependiendo de los distintos tipos de aplicaciones las mtricas podrn variar, ya
que aunque las caractersticas expuestas son comunes a la totalidad de los
productos, cada software particular requiere una evaluacin especifica.
Si desea saber ms acerca de estos temas, puede consultar las siguientes

pginas.
http://www.iso15504.es
Aqu encontrar diferentes temas relacionados con la calidad orientada al
proceso de software.
http://iso25000.com
Aqu encontrar diferentes temas relacionados con la calidad orientada al
producto de software.

110

UNIDAD DE
APRENDIZAJE
PRUEBAS DE SOFTWARE
Al trmino de la unidad de aprendizaje, el alumno elabora un plan de

pruebas en el que, haciendo uso de tcnicas de caja negra defina los casos
prueba a ser aplicados a las funciones desarrolladas en el software del
proyecto integrado de quinto ciclo. Asimismo deber generar el informe de
pruebas en el que se demuestre la aplicacin de los casos de pruebas y
adems se sustente el cumplimiento de las mtricas de funcionalidad.
TEMARIO
3.1. Tema 9: Pruebas de Software

3.1.1. Principios Generales de las Pruebas
3.2. Tema 10:Ciclo de Vida de las Pruebas

3.2.1. Planeacin y Control de Pruebas
3.2.2. Anlisis y Diseo de las Pruebas
3.2.3. Implementacin y Ejecucin de Pruebas
3.2.4. Evaluacin de Criterios de Salida y Reportes
3.2.5. Cierre de Pruebas
3.3. Tema 11: Estrategia de Pruebas

3.3.1. Casos de Prueba
3.3.2. Diseo de Casos de Prueba
3.3.3. Realizar Casos de Prueba
3.3.4. Informe y Seguimiento de Pruebas
3.3.5. Relacin entre las Pruebas y la Depuracin

112
3.1. PRUEBAS DE SOFTWARE

Los sistemas de software son una parte creciente en nuestra vida, desde
aplicaciones de negocio (bancos) hasta productos de consumo (autos).
Muchas personas han tenido experiencias con software que no trabaja como es
esperado. El software que no hace su trabajo correctamente puede acarrear
muchos problemas, desde prdida de dinero, tiempo o una mala reputacin, y
pueden incluso causar lesiones o muerte.
1. Papel de las pruebas en el desarrollo de software:
Las pruebas rigurosas a los sistemas y documentacin pueden ayudar a

reducir el riesgo de ocurrencia de problemas durante la operacin y
contribuyen a la calidad del sistema de software, si los defectos
encontrados son corregidos antes de que el sistema sea liberado para uso
operacional.
Las pruebas de software pueden ser requeridas tambin para conocer los
requisitos contractuales o trmites legales, o las
especificaciones/estndares industriales.
2. Pruebas y Calidad:
Con la ayuda de las pruebas, es posible medir la calidad del software en

trminos de defectos encontrados, tanto para requisitos funcionales o no
funcionales y caractersticas.
Las pruebas pueden dar la confianza sobre la calidad del software si

encuentra pocos o ningn defecto.
Se debe aprender de las lecciones de proyecto anteriores. Entendiendo las

causas races de los defectos encontrado en otros proyectos, los procesos
pueden ser mejorados, se debe evitar que esos efectos ocurran
nuevamente y como consecuencia, mejorar la calidad de futuros sistemas.
Esto es un aspecto del aseguramiento de la calidad.
Las pruebas deben ser integradas como parte de las actividades del
aseguramiento de la calidad
3. Cuntas pruebas son suficientes?:
En base al nivel de riesgo se determina cuantas pruebas se harn,

incluyendo riesgos tcnicos, de negocio y elementos del proyecto como
tiempo y presupuesto.
Las pruebas deben proveer suficiente informacin a los involucrados para la

toma de decisiones sobre la liberacin del software o sistema que est
siendo probado, para el paso o la entrega siguiente del desarrollo a los
clientes
Una percepcin comn de las pruebas es que nicamente consiste en la

ejecucin de scripts. Esto es parte de las pruebas, pero no todas las
actividades de la fase de pruebas.

Las actividades relacionadas a la fase de pruebas existen antes y despus

de la ejecucin de pruebas: planeacin y control, eleccin de condiciones
de pruebas, diseo de casos de prueba y revisin de resultados, evaluacin
de criterios de salida, reportes del proceso de pruebas, finalizacin y
clausura. Tambin incluye la revisin de documentos.
Existen diferentes objetivos para probar:

Encontrar defectos
Aumentar la confianza sobre el nivel de calidad
Prevenir defectos
El diseo de pruebas de manera temprana en el ciclo de vida puede ayudar

a prevenir que defectos san introducidos en el cdigo. La revisin de
documentos (por ejemplo: Requerimientos) tambin puede ayudar a
prevenir la aparicin de defectos en el cdigo.
La depuracin y las pruebas son diferentes. Las pruebas pueden mostrar

fallas causadas por defectos. La depuracin es la actividad de desarrollo
que identifica la causa de un defecto, repara el cdigo y revisa que el
defecto haya sido reparado correctamente. La informacin subsecuente del
probador asegura que la correccin ha resuelto la falla. La responsabilidad
para cada actividad es muy diferente.
3.1.1. Principios Generales de las Pruebas

`
Principio 1: Las pruebas muestran la presencia de defectos.
Las pruebas pueden mostrar que los defectos estn
presentes, pero no pueden probar que no son defectos.
Las pruebas reducen la probabilidad de mantener defectos
ocultos en el software pero, si no se encuentran defectos,
no es una prueba de que este correcto.
Principio 2: Las pruebas exhaustivas son imposibles.

Probar todo (todas las combinaciones de entradas y
precondiciones) no es viable excepto para casos
excepcionales. En lugar de pruebas exhaustivas, el anlisis
de riesgo y prioridades debera ser usado para enfocar las
pruebas.
Principio 3: Pruebas tempranas.

Las actividades relacionadas a las pruebas, deben iniciar
tan temprano como sea posible en el ciclo de vida de
desarrollo de software, y debe enfocarse en objetivos
definidos.
Principio 4: Agrupacin de defectos.

Un pequeo nmero de mdulos contienen la mayor parte
de los defectos encontrados durante la pre liberacin de
pruebas, o es responsable de la mayor parte de las fallas
operacionales.
Principio 5: Paradoja del pesticida.

Si las mismas pruebas son repetidas una y otra vez, ese
conjunto de casos de prueba no encontrar ms defectos.

114
Para evitar la paradoja del pesticida, los casos de prueba

necesitan ser revisados regularmente, deben escribirse
nuevos casos de prueba para probar diferentes partes del
software o sistema para potenciar el hallazgo de nuevos
errores.
Principio 6: Las pruebas son dependientes del contexto.

Las pruebas son diferentes en diferentes conceptos. Por
ejemplo, el software crtico para un banco es probado
diferente a un sitio de comercio electrnico.
Principio 7: La falacia de la ausencia de errores.

Encontrar y reparar defectos no ayuda si la construccin
del sistema es inoperable y no satisface las necesidades y
expectativas del cliente.

3.2. CICLO DE VIDA DE LAS PRUEBAS
La parte ms visible de las pruebas es la ejecucin, pero para qu sean

efectivas y eficientes, el plan de pruebas debe incluir el tiempo esperado para
la planeacin de pruebas, diseo de casos de prueba, preparacin para la
ejecucin y estatus de evaluacin.
El proceso bsico de pruebas consiste en las siguientes actividades
principales: (ver Figura 3.1)
Planeacin y control
Anlisis y diseo
Implementacin y ejecucin
Evaluacin de criterios de salida y reportes
Cierre de las actividades de prueba
Figura 3.1 Proceso Bsico de Pruebas
3.2.1. Planeacin y Control de Pruebas
La planeacin de pruebas es la actividad que verifica el objetivo de las

pruebas, define los objetivos y la especificacin de las actividades de
prueba.
El control de pruebas es la actividad que compara el progreso actual a

travs del plan, y reporta el estatus incluyendo las desviaciones del
plan. Implica tomar acciones necesarias para conocer la misin y
objetivos del proyecto.
3.2.2. Anlisis y Diseo de las Pruebas
Es la actividad donde los objetivos generales de las pruebas son

transformados en casos de prueba.

116
Contempla las siguientes actividades:

Revisin de las bases de pruebas (requerimientos, arquitectura,
diseo, interfaces).
Identificar y priorizar las condiciones de pruebas basadas en al
anlisis de la especificacin, estructura.
Diseo y priorizacin de casos de prueba.
Identificar la informacin necesaria para probar para dar soporte a los
casos e prueba y condiciones de prueba.
Diseo del ambiente de prueba e identificacin de cualquiera
herramienta o infraestructura requerida.
3.2.3. Implementacin y Ejecucin de Pruebas
Es la actividad donde los procedimientos de pruebas o scripts son

especificados combinando los casos de prueba en un orden particular e
incluyendo cualquier otra informacin necesaria para la ejecucin de
pruebas, el ambiente se preparara y se ejecutan las pruebas.
Se compone de las siguientes actividades:

Desarrollo, implementacin y priorizacin de casos de prueba.
Desarrollo y priorizacin de procedimientos de pruebas, creacin de
datos de prueba y opcionalmente codificacin de scripts de prueba
automatizados.
Creacin de paquetes de pruebas desde los procedimientos de
prueba para la ejecucin eficiente.
Verificar que el ambiente de prueba ha sido configurado
correctamente.
Ejecucin de procedimientos de pruebas ya sea manual o usando
herramientas de ejecucin, de acuerdo a la secuencia planeada.
Comparacin de resultados actuales contra los esperados.
Reportar discrepancias e incidentes y analizarlos para establecer su
causa (defecto en el cdigo, en el documento, error en la ejecucin).
3.2.4. Evaluacin de Criterios de Salida y Reportes
Es la actividad donde la ejecucin de pruebas se determina a travs de

los objetivos definidos.
Tiene las siguientes actividades:

Revisin de bitcora de pruebas a travs de los criterios de
salida especificados en el plan de pruebas.
Determinacin acerca de si es necesario ejecutar ms pruebas o
si los criterios de salida deben ser cambiados.
Preparar un reporte condensado de las pruebas a todos los
involucrados.
3.2.5. Cierre de Pruebas
Recopilan informacin de las pruebas completadas para consolidar

estadsticas, experiencias. Por ejemplo, cuando un sistema de software
es liberado, un proyecto de pruebas se completa, un hito es
completado.

Incluye las siguientes actividades:
Revisin de que entregables planeados han sido entregados, cierre

del reporte de incidentes o levantamiento de cambios,
documentacin y aceptacin del sistema.
Finalizacin y almacenamiento del ambiente de pruebas y la
infraestructura para su posterior reuso.
Anlisis de lecciones aprendidas para futuras liberaciones del
proyecto y la mejora de la madurez de pruebas.

118
3.3. ESTRATEGIA DE PRUEBAS

Una estrategia de prueba del software integra los mtodos de diseo de caso
de pruebas del software en una serie bien planeada de pasos que
desembocar en la eficaz construccin del software. La estrategia proporciona
un mapa que describe los pasos que se darn como parte de la prueba, indica
cundo se planean y cundo se dan estos pasos, adems de cunto esfuerzo,
tiempo y recursos consumirn. Por tanto, en cualquier estrategia de prueba
debe incorporar la planeacin de pruebas, el diseo de casos de pruebas, la
ejecucin de pruebas y la recoleccin y evaluacin de los datos resultantes.
Una estrategia de prueba del software debe ser lo suficientemente flexible

como para promover un enfoque personalizado. Al mismo tiempo, debe ser lo
adecuadamente rgido como para promover una planeacin razonable y un
seguimiento administrativo del avance del proyecto.
3.3.1. Casos de Prueba
Un Caso de Prueba es una especificacin, usualmente formal, de un

conjunto de entradas de prueba, condiciones de ejecucin y resultados
esperados, identificados con el propsito de hacer una evaluacin de
aspectos particulares de un elemento objeto de prueba:
Los Casos de Prueba reflejan trazabilidad con los CU

(Funcionalidad), ya que estos muestran una secuencia ordenada de
eventos, al describir flujos bsicos, flujos alternos, precondiciones y
pos condiciones.
Las especificaciones suplementarias de requerimientos ya que
existen otras caractersticas de calidad a evaluar, adems de la
funcionalidad, como Usabilidad, Confiabilidad, Eficiencia,
Mantenibilidad y Portabilidad.
Las especificaciones de diseo del Sistema, ya que se debe verificar
que el software fue implementado segn el diseo y que los
elementos arquitectnicos garantizan la calidad del software.
Esto garantiza que los procedimientos de pruebas sean compatibles con

las necesidades de los usuarios/clientes. En la prctica se tiende a
asumir que un Caso de Uso en s mismo es un Caso de Prueba y que el
equipo del proyecto trabaje correctamente sobre los Casos de Usos sin
planificar los Casos de Prueba. Cuando se sienta a probar los Casos de
Uso, intuitivamente asume datos y procedimientos de pruebas sin que
estas queden documentadas. Esto es un error ya que el Caso de
Prueba extiende o ampla la informacin contenida en un Caso de Uso;
por ejemplo, en los Casos de Uso no indicamos valores ni condiciones
para las pruebas.
Los Casos de Prueba son esenciales para todas las actividades de

pruebas:
Son la base para disear y ejecutar los procedimientos de pruebas.

La profundidad de las pruebas es proporcional al nmero de casos
de pruebas.
El diseo y desarrollo, y los recursos necesarios son gobernados por
los casos de pruebas requeridos.

Si los Casos de Prueba no son correctos, la Calidad del Sistema se

pone en duda y las pruebas dejan de ser confiables.
La Figura 3.2 muestra un modelo conceptual sobre los conceptos que

estn asociados a los Casos de Prueba.
En ella se puede observar que los Casos de Uso son la fuente principal
de los Casos de Prueba, estos se encuentran como entregables del
documento Plan de Pruebas.
Los Casos de Prueba se pueden agrupar mediante Suite de Pruebas.
Los Casos de Prueba estn relacionados con el nivel de la prueba y con

el tipo de prueba, la cual a su vez contiene la tcnica que permite
ejecutar el tipo de prueba.
Los Casos de Prueba proveen las instrucciones para el procedimiento

de las pruebas.
El procedimiento de la prueba se conforma de pasos, condiciones,

valores y resultados esperados y obtenidos. A su vez, el procedimiento
de las pruebas puede ser automatizado a travs de los script de
pruebas. Todos los conceptos indicados anteriormente permiten visionar
el enfoque de pruebas: qu se probar, cmo, quin, cundo, para
qu?
Una vez ejecutados todos los Casos de Prueba, estos resultados deben
reflejarse de manera global. Con ello, se establece si al validar el
sistema se cumpli con los criterios de aceptacin definidos con el
usuario.
Figura 3.2 Modelo conceptual asociado a Casos de Prueba

120
3.3.2. Diseo de Casos de Prueba
Un caso de prueba es un conjunto de entradas, condiciones de

ejecucin y resultados esperados, desarrollado para conseguir un
objetivo particular o condicin de prueba como, por ejemplo, verificar el
cumplimiento de un requisito especfico. Para llevar a cabo un caso de
prueba es necesario definir las precondiciones y post condiciones,
identificar unos valores de entrada, y conocer el comportamiento que
debera tener el sistema ante dichos valores. Tras realizar ese anlisis e
introducir dichos datos en el sistema, se observar si su
comportamiento es el previsto o no y por qu. De esta forma se
determinar si el sistema ha pasado o no la prueba. De ah su
importancia durante la ejecucin de pruebas.
A continuacin se describir los pasos que se realizarn en el curso

para disear casos de pruebas.
1. Definir escenarios
Se identifican los escenarios tomando como base las narrativas de

los Casos de Uso y considerando cada uno de los escenarios
especficos que ocurren para cada Caso de Uso. El flujo normal,
cada flujo alterno o la combinacin de ellos es un escenario, que
puede ser ejecutado y probado. Esto deriva que siempre el primer
escenario sea el que evoca todo el flujo normal de ese Caso de Uso
en particular y que la relacin entre Caso de Uso y escenarios sea de
uno a muchos.
Presentar grficamente la secuencia de eventos que se plantea en

cada Caso de Uso: esto permite, como lo muestra la Figura 3.3
abstraer los eventos que ocurren en un Caso de Uso: el flujo normal
o bsico y los flujos alternos, y sirve de apoyo para visualizar
fcilmente las posibles combinaciones que representaran un
escenario ya que establece en qu punto del flujo bsico ocurre y
adems qu sucede despus que se activa ese flujo alterno: finaliza
el Caso de Uso o retorna al flujo bsico.
Chequear que se hayan representado grficamente todos los Flujos

alternos con su accin de finalizacin o retorno.
Establecer a travs de una tabla todos los escenarios asociados a un

Caso de Uso, (ver Tabla 6)

Figura 3.3 Visualizacin de los Flujos en un CU
2. Identificar condiciones de entrada
Las condiciones de entrada son parte del dominio de valores de

entrada. Se pueden identificar condiciones de entrada con estados
vlidos (V) y no vlidas (NV); asimismo se consideran condiciones
de entrada con el estado que no se aplica (N/A) para un
determinado escenario.
Existen los siguientes tipos de condiciones de entrada:
Miembro de un conjunto
Lgico
Valor
Rango
Tabla No. 6 Escenarios por CU
Veamos un ejemplo. Considrese una aplicacin bancaria, donde el

usuario puede conectarse al banco por Internet y realizar una serie
de operaciones bancarias. Una vez accedido al banco con las
siguientes medidas de seguridad (clave de acceso y dems), la

122
informacin de entrada del procedimiento que gestiona las

operaciones concretas a realizar por el usuario requiere las
siguientes entradas:
Cdigo de banco. En blanco o nmero de tres dgitos. En este

ltimo caso, el primer dgito tiene que ser mayor que 1.
Cdigo de sucursal. Un nmero de cuatro dgitos. El primero de
ellos mayor de 0.
Nmero de cuenta. Nmero de cinco dgitos.
Clave personal. Valor alfanumrico de cinco posiciones.
Orden. Este valor se seleccionar de una lista desplegable,
segn la orden que se desee realizar. Puede estar en
Seleccione Orden o una de las dos cadenas siguientes:
Talonario o Movimientos
En el caso Talonario el usuario recibir un talonario de cheques,
mientras que en Movimientos recibir los movimientos del mes
en curso. Si no se especifica este dato, el usuario recibir los dos
documentos.
A continuacin se muestra una tabla con estados de las condiciones

de entrada para un caso de prueba por cada escenario:
En base a la regla de generacin de Casos de prueba a partir de

Clases de equivalencia, se deberan tener 12 casos de prueba.
CONDICIONES DE ENTRADA
ID CP Escenario Cdigo Cdigo de Nmero Clave Resultado esperado
Orden
de banco sucursal de cuenta personal
Mensaje "Envo de
CP1 Escenario 1 V V V V V
talonarios"
Mensaje "Envo de
CP2 Escenario 1 V V V V V
movimientos "
Mensaje "Envo de
CP3 Escenario 1 V V V V V talonarios y
movimientos"
Mensaje Cdigo de
CP4 Escenario 2 NV V V V V
banco incorrecto
Mensaje Cdigo de
CP5 Escenario 3 V NV V V V
sucursal incorrecto
Mensaje Nmero de
CP6 Escenario 4 V V NV V V
cuenta incorrecto
Mensaje Clave
CP7 Escenario 5 V V V NV V
incorrecta
Tabla No. 7 Condiciones de Entrada
3. Definir clases de equivalencia
Pueden usarse varias tcnicas para identificar los valores de los

datos de entrada, la tcnica de particiones o clases de equivalencias
es una de ellas.

Las clases de equivalencia se identifican examinando cada condicin

de entrada (normalmente una frase en la especificacin) y
dividindola en dos o ms grupos. Se definen dos tipos de clases de
equivalencia:
Condicin Clases Vlidas Clases No Vlidas

Sec. Tipo
de Entrada Entrada Cdigo Entrada Cdigo
Lgico (puede
En blanco CEV<01> Un valor no numrico CENV<01>
estar o no)
Cdigo de Cdigo de banco < 200 CENV<02>
1
banco Si est, es
200 <= Cdigo de banco <= 999 CEV<02>
Rango
Cdigo de banco > 999 CENV<03>
Cdigo de sucursal < 1000 CENV<04>

Cdigo de
2 Rango 1000 <= Cdigo de sucursal <=9999 CEV<03>
sucursal
Cdigo de sucursal > 9999 CENV<05>
Nmero de ms de cinco
CENV<06>
Nmero de dgitos
3 Valor Cualquier nmero de 5 dgitos CEV<04>
cuenta Nmero de menos de cinco
CENV<07>
dgitos
Cadena de ms de cinco
CENV<08>
Clave Cualquier cadena de caracteres posiciones
4 Valor CEV<05>
personal alfanumricos de 5 posiciones Cadena de menos de cinco
CENV<09>
posiciones
Miembro de un Orden = "Seleccione Orden" CEV<06>

conjunto, con
5 Orden Orden = "Talonario" CEV<07>
comportamient
o distinto
Orden = Movimientos CEV<08>
Tabla No. 8 Clases de Equivalencia
Clases Vlidas, que representan entradas vlidas al programa.

Clases no Vlidas, que representan valores de entrada errneos.
Estas clases se pueden representar en una tabla. A continuacin se
muestra las clases de equivalencia para el caso de gestin bancaria
anterior:
3.3.3. Realizar Casos de Prueba
En esta ltima etapa, se generan los casos de pruebas. Para ello, se

considera como referencia la tabla de condiciones de entrada, indicando
en cada caso de prueba las clases de equivalencia creadas. Por
ejemplo, para el caso bancario se tendra lo siguiente:

CONDICIONES DE ENTRADA
ID CP Clases de equivalencia Cdigo de Cdigo de Nmero de Resultado esperado
Clave personal Orden
banco sucursal cuenta
CEV<02>, CEV<03>, CEV<04>,
CP1 200 1000 10000 Aaaaa Talonario Mensaje "Envo de talonarios"
CEV<05>, CEV<07>
CEV<01>, CEV<03>, CEV<04>,
CP2 820 9999 99999 Zzzzz Movimientos Mensaje "Envo de movimientos "
CEV<05>, CEV<08>
CEV<02>, CEV<03>, CEV<04>, Seleccione Mensaje "Envo de talonarios y
CP3 999 1001 12345 A1b2c
CEV<05>, CEV<06> Orden movimientos"
CENV<01>, CEV<03>, CEV<04>, Seleccione
CP4 30A 1989 12345 1a2b3 Mensaje Cdigo de banco incorrecto
CEV<05>, CEV<07> Orden
CENV<04>, CEV<03>, CEV<04>, Seleccione Mensaje Cdigo de sucursal
CP5 210 999 12345 1a2b3
CEV<05>, CEV<07> Orden incorrecto
CENV<07>, CEV<03>, CEV<04>, Seleccione Mensaje Nmero de cuenta
CP6 210 1989 123 1a2b3
CEV<05>, CEV<07> Orden incorrecto
CENV<09>, CEV<03>, CEV<04>, Seleccione
CP7 210 1989 12345 Mensaje Clave incorrecta
CEV<05>, CEV<07> Orden
Tabla No. 9 Casos de Prueba

3.3.4. Informe y Seguimiento de Pruebas
De acuerdo al estndar de documentacin de pruebas de software IEEE Std

829-1998, se pueden distinguir histricos, incidencias y resmenes (ver
Figura No. 3.4).
Figura 3.4 Documentacin Relacionada con la Ejecucin de las Pruebas
El Histrico de Pruebas (Test Log) documenta todos los hechos relevantes

ocurridos durante la ejecucin de las pruebas. El Test Log suele tener la
siguiente estructura:
Identificador.
Descripcin de la prueba: elementos probados y entorno de la prueba.
Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo y el
final de la prueba)
El Informe de Incidente (Test Incident Report) documenta cada incidente (por

ejemplo, una interrupcin en las pruebas debido a un corte del fluido elctrico,
bloqueo del teclado) ocurrido en la prueba y que requiera de una posterior
investigacin. El Informe de Incidente, debe tener la siguiente estructura:

126
Identificador.
Resumen del incidente.
Descripcin de datos objetivos (fecha/hora, entradas, resultados
esperados)
Impacto que tendr sobre las pruebas.
El Informe Resumen de Pruebas (Test Summary Report) resume los

resultados de las actividades de prueba (las sealadas en el propio informe) y
aporta una evaluacin del software basada en dichos resultados. El Informe
Resumen de Pruebas deber tener la siguiente estructura:
Identificador.
Resumen de la evaluacin de los elementos probados.
Variaciones del software respecto de a su especificacin de diseo, as
como las variaciones en las pruebas.
Valoracin de la extensin de la prueba (cobertura lgica, funcional, de
requisitos).
Resumen de los resultados obtenidos en las pruebas.
Evaluacin de cada elemento software sometido a prueba (evaluacin
general del software incluyendo las limitaciones del mismo).
Firmas y aprobaciones de quienes deban supervisar el informe.
3.3.5. Relacin entre las Pruebas y la Depuracin
Depuracin es el proceso de analizar y corregir los efectos que sospecha que

contiene el software, ver Figura No. 3.5.
Figura 3.5 Proceso de Depuracin

CALI DA D DE SOFTW AR E 127
Durante la Depuracin es necesario tener en cuenta lo siguiente, para el

proceso de localizacin del error:
Analizar la informacin y pensar (analizar bien, en lugar de aplicar un
enfoque aleatorio de bsqueda del efecto).
Al llegar a un punto muerto, pasar a otra cosa (refresca la mente).
Al llegar a un punto muerto, describir el problema a otra persona (el
simple hecho de describir el problema a alguien puede ayudar).
Usar herramientas de depuracin slo como recurso secundario (no
sustituir el anlisis mental).
No experimentar cambiando el programa (no s qu est mal, as que
cambiar esto y ver lo que sucede No).
Se debe atacar los errores individualmente.
Se debe fijar la atencin tambin en los datos (no slo en la lgica del
programa).
Durante el proceso de correccin del error, es necesario considerar las

siguientes recomendaciones:
Donde hay un defecto, suele haber ms (lo dice la experiencia).
Debe fijarse el defecto, no sus sntomas (no debemos enmascarar
sntomas, sino corregir el efecto).
La probabilidad de corregir perfectamente un defecto no es del 100%
(cuando se corrige, hay que probarlo).
Cuidado con crear nuevos defectos (al corregir defectos se producen otro
nuevos).
La correccin debe situarnos temporalmente en la fase de diseo (hay
que retocar desde el comienzo, no slo el cdigo).
Cambiar el cdigo fuente, no el cdigo objeto.

128
Actividades
Elaborar el plan de pruebas para determinar las pruebas que sern aplicadas
en el proyecto integrado de quinto ciclo.
Desarrollar los casos de prueba de las funciones principales del aplicativo bajo
desarrollo en el curso de DAW1.
Ejecutar los casos de prueba, para completar los resultados y compararlos con
los resultados esperados.
Elaborar el informe de pruebas indicando el resultado por cada uno de los
mdulos del producto software probado.
Evaluar las mtricas de calidad externa definidas en el modelo de calidad de
producto software.

Formatos
PP Plan de Pruebas de Software
Plan de Pruebas
Versin <x.y.z>

130

<Persona que <Persona(s)
<Fecha de <Fecha de
<x.y.z> elabora el <Detalles> que revisa(n)
Elaboracin> Revisin>
documento> el documento>

Contenido
1. Introduccin
132
1.1 DEFINICIONES, ACRNIMOS Y ABREVIATURAS 132
1.2 DOCUMENTOS RELACIONADOS 132
2. Objetivo
132
3. Alcance
132
3.1 DENTRO DEL ALCANCE
133
3.2 FUERA DEL MBITO
133
4. Roles y Recursos
133
5. Tcnica a utilizar
133
6. Enfoque de las Pruebas
133
6.1 Pruebas Funcionales
134
6.2 ACTIVIDADES
134
6.2.1DISEO DE LOS CASOS DE PRUEBA
134
6.2.2GENERACIN DE LOS CASOS DE PRUEBA
134
6.2.3DEFINICIN DE LOS PROCEDIMIENTOS DE PRUEBA
135
6.2.4EJECUCIN DE LOS CASOS DE PRUEBA
135
6.2.5REPORTAR Y DOCUMENTAR LAS PRUEBAS
136
6.2.6 ANLISIS DE RESULTADOS OBTENIDOS
136
7. Planificacin
137

1. Introduccin
[Describa de manera breve el contenido del documento orientando la
descripcin hacia la utilidad que se quiere conseguir.]
[El presente documento describe el plan de pruebas de sistema, esto abarca la

metodologa, en donde se especifican mtodos, tcnicas y forma en que se disean,
ejecutan, evalan y reportan los resultados de las pruebas de sistema
Las pruebas de sistema a desarrollar, luego de leer este plan, se ejecutan en

cuanto se ha finalizado con las pruebas de Integracin, ya que se debe tener
el sistema completo para poner en prctica las pruebas de sistema. Luego de
realizar las pruebas, se verificar si el sistema XYZ cumple con los requisitos
exigidos por el usuario, en los cuales se debiera obtener los resultados
esperados, de no ser as, se determina que se han encontrado errores que
habr que reportar a los desarrolladores]
1.1 Definiciones, Acrnimos y Abreviaturas
1.2 Documentos Relacionados
Ttulo Fecha Identificador del

documento
Reporte de Especificacin 24 de enero de 2011 RES v2.0
de Software
2. Objetivo
[Describa de manera breve el propsito que se pretende alcanzar con la
aplicacin del plan de pruebas.]
El documento tiene como objetivo describir el plan a seguir para realizar las
pruebas al Sistema, con lo cual se especifican etapas a seguir para disear,
generar, definir procedimientos, ejecutar, evaluar y reportar los resultados
obtenidos de las pruebas. Al disear y generar las pruebas, stas se
validarn con las personas calificadas para ello, para luego ejecutarlas y
tomar los resultados obtenidos. Finalmente los resultados se evaluarn y
reportarn.
Las pruebas del sistema tienen como objetivo ejercitar el sistema

comprobando la integracin total del sistema, verificando el funcionamiento
correcto de las interfaces entre los distintos subsistemas que lo componen.
3. Alcance
[Describa de manera breve el alcance de las pruebas descritas en el plan de
pruebas.]
Las pruebas de sistema a realizar, sern pruebas funcionales sobre las
funciones del sistema, a partir de las condiciones de entrada y evaluando los
resultados obtenidos. No es necesario conocer la lgica del programa,
nicamente la funcionalidad que debe realizar.
Para probar correctamente el sistema, las pruebas se realizan basndose en

los requerimientos establecidos por el usuario del sistema

CIBERTEC
<Nombre del Proyecto> Versin: x.y.z
3.1 Dentro del Alcance

Se contemplan las siguientes actividades para el proceso de desarrollo de
pruebas Funcionales:
Diseo de casos de prueba
Generacin de casos de prueba
Definicin de los procedimientos de la prueba
Ejecucin de pruebas
Reportar y documentar pruebas
Anlisis de resultados obtenidos
Los mdulos y funciones a ser probados sern:
Mdulo 1
Funcin 1
Funcin 2
Mdulo 2
Funcin 1
Funcin 2
3.2 Fuera del mbito

Indicar que mdulos no sern objeto de la prueba
4. Roles y Recursos
Listar los roles y recursos asignados al proyecto
RECURSOS HUMANOS
Mnimos
Responsabilidades especficas o
Rol recursos Recurso
comentarios
recomendados
Proporcionar una gestin adecuada.
Responsabilidades:
Proporcionar una direccin Nombre del
Gestor de
1 tcnica. recurso
prueba
Adquirir los recursos (probador)
apropiados.
Informar de la gestin.
Identificar, priorizare implementar
los casos de prueba.
Diseador Nombre del
Responsabilidades:
de 3 recurso
Generar el Plan de pruebas.
prueba (probador)
Disear los Casos de prueba.
Evaluar el esfuerzo de prueba.
Ejecutar las pruebas.
Responsabilidades: Nombre del
Probador 3 Ejecutar pruebas. recurso
Recuperar los errores. (probador)
Documentar los defectos.
5. Tcnica a utilizar
La tcnica a utilizar para las pruebas de sistema son las de Caja
Negra.
6. Enfoque de las Pruebas

Los tipos de pruebas que se realizarn al software son:
133
134
6.1 Pruebas Funcionales

Estn enfocadas a asegurar que el software realiza correctamente
todas las funciones que se han detallado en los requerimientos dados
por el usuario. Se realizan pruebas para cada caso de uso y cada una
de las actividades a desarrollar se describe en la seccin 6.2
6.2 Actividades
De acuerdo a lo establecido en la seccin 3.1., las actividades sern:
6.2.1 Diseo de los Casos de Prueba

Para disear los casos de prueba de sistema, se identifica la
tcnica de caja negra descrita en la seccin 5.
Para confeccionar los casos de prueba con la tcnica Caja

Negra, sta provee distintos mtodos. Los que se ocuparn
son los siguientes:
A partir de especificaciones formas de casos de uso.

Particiones de Equivalencia (para condiciones de entrada
de tipo valor, rango de valores, miembro de un conjunto y
lgica).
Anlisis de Valores Lmite (para condiciones de entrada de
rango de valores, miembro de un conjunto y lgica)
6.2.2 Generacin de los Casos de Prueba

En la generacin o creacin de los casos de prueba, se
representan los datos que se utilizarn como condiciones de
entrada para ejecutar el software a probar. En concreto, los
casos de prueba determinan un conjunto de entradas,
condiciones de ejecucin y resultados esperados para un caso
de uso en particular.
La tcnica de caja negra proporciona distintos criterios para

generar los casos de prueba. A continuacin, en las tablas N
1 y 5 se presenta una tabla de formulario de casos de prueba
para cada criterio determinado.
En general, para la generacin de todos los casos de prueba se

debe tener lo siguiente:
Aplicativo: Nombre del aplicativo bajo pruebas.

Requerimiento: Cdigo del Requerimiento Funcional
asociado al CUS que se probar.
Proceso: Mdulo en el que reside el CUS que se probar.
Caso de Uso: Cdigo y nombre del CUS que se probar
Responsable: Nombre del responsable de ejecucin de la
prueba.
Pre-Condiciones: Que pueden tener relacin con la
precondicin del casos de uso.
Propsito: Objetivo del caso de prueba.
Escenario: Cdigo y nombre del escenario que ser
desarrollado por el caso de prueba.
Actividad: Descripcin de las acciones para ejercitar el caso
de prueba, a partir de las condiciones de entrada (que son
las entradas del sistema).

Clase de equivalencia: Cdigos de las clases de

equivalencia que sern utilizados en la prueba.
Resultado esperado: Es el resultado que producir el
software al ejecutar dicho caso, lo que es necesario para
detectar una posible falla en el programa, adems de
observaciones en caso necesario.
A continuacin se presentan los formularios para los casos de

pruebas
CASOS DE PRUEBA
Aplicativo: Sistema de Planificacin Peridica de Requerimientos Informticos
Requerimiento: 2
Proceso Conocimiento
Caso de Uso Mantenimiento de reas de Conocimiento
Responsible
Pre Condiciones
Propsito
Escenario 1.1 Agregar una nueva rea de conocimiento

Sec. Actividad Clase de equivalencia Resultado Esperado
1
2
3
Tabla N1 Formulario de Casos de Prueba con uso de

Criterios de Especificacin Formal, Clases de Equivalencia y Anlisis de Valores Lmite
6.2.3 Definicin de los procedimientos de prueba

Para llevar a cabo el procedimiento de prueba, se ha
determinado que las actividades de las pruebas funcionales,
sern abordadas como se indica a continuacin:
Que la encargada de Testing Claudia Melndez (T1), se

ocupar de disear, generar, ejecutar y reportar los casos
de prueba para los casos de uso de: Mdulo XYZ, Mdulo
ABC; descritos en el Reporte de Especificacin de Software
(RES) versin x.y.z.
Que la encargada de Testing Nadia Aliaga (T2), se ocupar

de disear, generar, ejecutar y reportar los casos de
prueba para casos de uso de: Mdulo RST, Mdulo UVW;
descritos en el Reporte de Especificacin de Software
(RES) versin x.y.z
Las fechas correspondientes a las actividades, se

mostrarn en la tabla N3 de la seccin 7.
6.2.4 Ejecucin de los Casos de Prueba

Para la ejecucin de los casos de prueba, teniendo el sistema
XYZ integrado, se aplicarn las entradas descritas para cada
caso de prueba generado en la seccin 6.2.2, a travs de las
interfaces del sistema, para lo cual se deber generar la Tabla
N2 de Resultados Obtenidos, en donde se ir comparando los
135
136
resultados obtenidos con los esperados para identificar las

posibles fallas (que ocurren cuando un programa no se
comporta adecuadamente, esto quiere decir que hay un
defecto en el cdigo) y que a continuacin se presenta:
Cdigo de Caso de Salida Esperada Salida obtenida (*)

Prueba
Tabla N2 Tabla de Resultados Obtenidos
(*): La respuesta de la salida obtenida deber ser el resultado

de comparar la salida obtenida con la esperada: OK (la
salida obtenida est dentro del rango previsto por la salida
esperada), falla menor (la diferencia entre las salidas es una
cuestin de formato), falla grave (el sistema no complet su
salida o la complet pero se "cay" despus).
6.2.5 Reportar y Documentar las Pruebas

Luego de haber ejecutado todos los casos de pruebas
validados, stos se deben documentar, con el resultado de la
ejecucin (salida obtenida), determinando el nmero de cules
pasaron satisfactoriamente, cules no lo hicieron y adems
que fallas se encontraron.
Para el completo reporte de las pruebas, se deber generar un

documento, Informe de Reportes de Casos de Prueba a
Requerimientos Funcionales, que deber contener:
Ttulo
Fecha
Realizado por
Historial de versiones
Dependiendo del criterio usado: Tabla de identificacin de
clases de equivalencia
Tablas de formulario de casos de prueba, aplicando el
criterio de clases de equivalencia y anlisis de valores
lmite (tabla N1, de la seccin 6.2.2) Tabla de Resultados
Obtenidos (Tabla 2) con todos los casos de pruebas
6.2.6 Anlisis de Resultados Obtenidos

Para realizar el anlisis de resultados obtenidos, se har de
acuerdo a la tabla de resultados obtenidos (tabla N2), y se
debern sacar conclusiones de acuerdo al nmero de
aprobaciones (resultados esperados OK) y fallas encontradas
(resultado obtenido falla menor o falla grave).
Para el completo reporte de anlisis de resultados, se deber

generar un documento que, deber ser llamado Informe de
anlisis de resultados obtenidos de Pruebas a Requerimientos
Funcionales, que deber contener:
Cul es el estado actual del software, en cuanto al nivel

probable de calidad que alcanz? Para esto, se debe
determinar el porcentaje de salidas obtenidas con
respuesta OK, las cuales se suman, obteniendo el total de
nivel de satisfaccin de las pruebas a requerimientos
funcionales. Se espera que este porcentaje sea superior a

un 85%, de lo contrario el sistema no estara cumpliendo

con los atributos de calidad mnimos requerido por el
equipo de Calidad.
Cunto tiempo se llevaron los procesos de prueba? Se
debe mencionar la cantidad de das u horas que se
necesit.
Cun efectivo fue el proceso de prueba? (cuntos fallas
se detectaron?) Se deber dar el nmero de fallas
encontradas.
Qu tipo de fallas se producen? Se debe mencionar
cuntas fallas menores y graves se registraron, cules
fueron ms frecuentes
Se debe realizar el proceso de depuracin? Esta
interrogante se responder en caso de haber encontrado
fallas en el sistema. En caso contrario, se comunica en el
informe que se ha terminado el proceso de pruebas.
La ltima interrogante mencionada llevar a determinar en

este informe si se termina el proceso de pruebas, esto para
saber si se puede dar por concluido. En caso negativo, se debe
planificar el proceso de depuracin dentro del informe de
anlisis de resultados obtenidos.
El proceso de depuracin consiste en arreglar las fallas en el

sistema que generaron los casos de prueba ejecutados, para
esto, se debe informar al lder relacionado, de modo que ste
avise al programador correspondiente. Por lo tanto, el
programador relacionado, deber depurar la falla encontrada
(salida obtenida no esperada) y el ejecutor de las pruebas
deber volver a ejecutar todos los casos de prueba
nuevamente (casos de prueba que no se ejecutaron
satisfactoriamente, y casos que se ejecutaron
satisfactoriamente). La razn de esto, es confirmar que la
correccin de un defecto no introdujo un nuevo defecto. Esto
se debe dejar en claro en el informe de anlisis de resultados
obtenidos.
7. Planificacin
Se contemplan las actividades relacionadas con el plan de Pruebas, en donde
se describe:
Actividad
Responsable, puede ser el equipo de testing (T1: Claudia Mndez y T2:
Nadia Aliaga), SQA: Mariela Orrego, Lderes (Fabin Lpez, Daniel
Vsquez, Alejandra Torres, Alfonso Morris)
Comienzo: fecha en que comienza la actividad
Trmino: fecha en que termina la actividad
Duracin
Actividad Responsable Comienzo Trmino Duracin

Casos de Prueba para
Requerimientos do 05-06-
T1 vi 10-06-05
Funcionales: nombre de 05 6 das
mdulo 1
Casos de Prueba para
do 05-06-
Requerimientos T2 vi 10-06-05 6 das
05
Funcionales: nombre de
137
138
mdulo 2
Informe de casos de pruebas sa 11-06- sa 11-06- 1 da
T1, T2
de Sistema 05 05
ma14-06- jue16-06- 3 das
Revisin de Informe SQA, Lderes
05 05
Vie17-06- Vie17-06- 1 da
Correccin de informe T1, T2
05 05
Envo de pruebas a equipo T1, T2 Sa18-06-05 Sa18-06-05 1 da
Ejecucin de Casos de Lderes,T1, ma 28-06- mi 29-06- 2 das
Prueba de Sistema T2, BD (*) 05 05
Informe de Reportes de 1 da
Pruebas de Sistema e Informe mi 29-06- mi 29-06-
T1, T2
de anlisis de resultados 05 05
obtenidos
Revisin de Reporte e informe 1 da
SQA, Lderes ju 30-06-05 ju 30-06-05
de anlisis
Correccin de Reporte e 1 da
T1, T2 ju 30-06-05 ju 30-06-05
informe de anlisis
Envo de Informes de reporte y 1 da
T1, T2 vi 01-07-05 vi 01-07-05
anlisis a equipo
Tabla N3 de Actividades del plan de pruebas de sistema

Resumen
La prueba del software es un elemento crtico para la garanta de la calidad del

software. El objetivo de la etapa de pruebas es garantizar la calidad del producto
desarrollado. Adems, esta etapa implica:
Verificar la interaccin de componentes.
Verificar la integracin adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de
entregar el software al cliente.
Disear pruebas que sistemticamente saquen a la luz diferentes clases de
errores, hacindolo con la menor cantidad de tiempo y esfuerzo.
La prueba es un proceso que se enfoca sobre la lgica interna del software y las
funciones externas. La prueba es un proceso de ejecucin de un programa con la
intencin de descubrir un error. Un buen caso de prueba es aquel que tiene alta
probabilidad de mostrar un error no descubierto
Una vez generado el cdigo fuente, es necesario probar el software para descubrir
(y corregir) la mayor cantidad de errores posible antes de entregarlo al cliente. Su
objetivo es disear una serie de casos de prueba que tengan una alta probabilidad
de encontrar errores. Aqu es donde entran las tcnicas de prueba del software.
Estas tcnicas proporcionan directrices sistemticas para pruebas de diseo que 1)
comprueben la lgica interna y las interfaces de todo componente del software y 2)
comprueben los dominios de entrada y salida del programa para descubrir errores
en su funcin, comportamiento y desempeo.
Durante las etapas iniciales del proceso, el desarrollador realiza todas las pruebas.
Sin embargo, a medida que avanza este proceso se irn incorporando
especialistas en pruebas.
139

Calidad de Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Calidad de Software PDF

Cargado por

Copyright:

Formatos disponibles

Calidad de

CARRERAS PROFESIONALES CIBERTEC

1.1 Tema 1 : Calidad de Software 10

CIBERTEC CARRERAS PROFESIONALES

1.5 Tema 5 : Verificacin y Validacin 44

2.1 Tema 6 : Modelos de Calidad de Software 85

3.1 Tema 9 : Pruebas de Software 105

CARRERAS PROFESIONALES CIBERTEC

3.2.3 Implementacin y Ejecucin de Pruebas 109

CIBERTEC CARRERAS PROFESIONALES

CARRERAS PROFESIONALES CIBERTEC

Calidad de Software pertenece a la lnea formativa y se dicta en la carrera de

El manual para el curso ha sido diseado bajo la modalidad de unidades de

El curso tiene un formato terico prctico. Los conceptos desarrollados son

CIBERTEC CARRERAS PROFESIONALES

Aseguramie Mtricas de Pruebas de

Modelos de Calidad Pruebas de Software

Aseguramiento y Mtricas de Calidad Ciclo de Vida de las

CARRERAS PROFESIONALES CIBERTEC

LOGRO DE LA UNIDAD DE APRENDIZAJE

Al trmino de la unidad de aprendizaje, el alumno disea la lista de verificacin

1.1. Tema 1: Calidad de Software

1.2. Tema 2: Aseguramiento y Control de Calidad

1.3. Tema 3: Modelo de Procesos

1.4. Tema 4: Modelo de Ciclo de Vida de Software

1.5. Tema 5: Verificacin y Validacin de Software

CIBERTEC CARRERAS PROFESIONALES

1.1. CALIDAD DE SOFTWARE

1.1.1. Definicin de Calidad

CARRERAS PROFESIONALES CIBERTEC

Existen muchas definiciones de calidad y muchos trminos que se utilizan

Para la ISO 8402 (International Standard Organization), complemento de

Tambin podra decirse que es la conformidad con los requisitos y el

La calidad la definen los clientes, por lo que la oferta deber estar de

La calidad no solo hace referencia a que un producto o servicio se ajuste

El recepcionista que atiende las llamadas, los agentes de seguridad que

La nica forma de alcanzar el objetivo de calidad es:

1. Comprender las exigencias de los clientes externos.

1.1.2. Poltica de Calidad

CIBERTEC CARRERAS PROFESIONALES

Se proporciona orientacin precisa para que ejecutivos y mandos

La poltica de calidad debe ser:

En cuanto a su contenido, debera hacer referencia a:

Los grandes objetivos de la empresa.

Es la totalidad de aspectos y caractersticas de un producto o servicio que

El Instituto de Ingeniera de Software (SEI) en su modelo CMM define la

1.1.3. Terminologa segn ISO 8402

CARRERAS PROFESIONALES CIBERTEC

El QS debe tener el volumen y alcance suficiente para conseguir

6. Aseguramiento de la Calidad: Es un conjunto de actividades

CIBERTEC CARRERAS PROFESIONALES

Figura 1.1 - Sistema de Gestin de Calidad

1.1.4. Definicin de Calidad de Software

Segn R. Pressman: La calidad del software se define como la

No hay duda de que la anterior definicin puede ser modificada o

2. Los estndares especificados definen un conjunto de criterios de

3. Existe un conjunto de requisitos implcitos que a menudo no se

Queda claro a partir de la definicin de calidad del software, que sta es

CARRERAS PROFESIONALES CIBERTEC

La Calidad del Software es medible y vara de un sistema a otro o de un

La Calidad del Software puede medirse despus de elaborado el

Existen varios factores que determinan la calidad del software y la

Figura 1.2 - Determinantes de la calidad del software y de la efectividad de