Nombre del Proyecto

Autores

Fecha
I. MODELOS DEL SISTEMA
1.1. DESCRIPCIÓN DETALLADA DEL SISTEMA
1.2. MODELO DE REQUERIMIENTOS
1.2.1. Requisitos funcionales
1.2.2. Requisitos no funcionales
1.3. MODELO DE CASOS DE USO
1.3.1. Diagramas de caso de uso
1.3.2. Descripción de caso de uso
1.4. MODELO DE DISEÑO DEL SISTEMA
1.4.1. Diagrama de clases detallado
1.4.2. Diagramas de secuencias
1.4.3. Diagrama de componentes
1.5. PRODUCTO DEL SOFTWARE
II. PRUEBAS DEL SOFTWARE
II.1. INTRODUCCIÓN
II.2. PLANIFICACIÓN DE LAS PRUEBAS
II.2.1. Objetivos
II.2.2. Alcance
II.2.3. Ambiente de pruebas
II.2.4. Plan de pruebas
II.3. DISEÑO Y EJECUCIÓN DE LAS PRUEBAS
II.3.1. Pruebas Unitarias
II.3.1.1. Clases de equivalencia
II.3.1.2. Valores Limites
II.3.1.3. Camino básico
II.3.1.4. Diseño y ejecución de los casos de pruebas
 Diseño casos de pruebas
 Ejecución casos de pruebas
 Evaluación de la prueba
II.3.2. Pruebas de Integración
II.3.2.1. Pruebas incrementales
 Incremental Ascendente
 Incremental descendente
 Diseño casos de pruebas
II.3.2.2. Pruebas basadas en hilos
II.3.2.3. Diseño casos de pruebas
II.3.2.4. Ejecución de las pruebas
II.3.2.5. Evaluación de las pruebas
II.3.3. Pruebas de aceptación
II.4. COCLUSIONES
II.5. REFERENCIAS
III. METRICAS DEL SOFTWARE
III.1. Introducción
III.1.1. Objetivos
III.1.2. Alcance
III.1.3. Tipos y herramientas de métricas
III.2. Métricas de Producto: Atributos internos
III.2.1. Métricas de tamaño
III.2.2. Métricas de clases
III.2.3. Métricas de funcionalidad
III.2.4. Análisis métricas de producto
III.3. Métricas de productos con atributos externos
III.4. Aplicación herramientas de métricas
III.5. CONCLUSIONES
 2. PRUEBAS DEL SOFTWARE
2.1. Introducción
[La sección de introducción debe proveer un resumen general del contenido de
esta unidad referente a las pruebas del software.]
2.2. PLANIFICACIÓN DE LAS PRUEBAS
2.2.1. OBJETIVOS
[En este apartado se deberán describir los objetivos de las pruebas, d efinir
claramente lo que se quiere alcanzar en la fase de pruebas .]
2.2.2. ALCANCE
[Alcance del plan de pruebas, identificando los módulos y funcionalidades que
serán sometidas a pruebas y los tipos de prueba que se realizarán, por ejemplo:
unitarias, de integración, funcionales, de rendimiento, de volumen, de
disponibilidad de datos, de entorno, de seguridad, de interfaz de usuario, de
aceptación, de regresión, etc.]
Niveles, tipos y métodos de prueba
Niveles,
Métodos o Nombre Descripción
Tipos

Nivel de
pruebas

Técnicas de
pruebas

Métodos de
Prueba

2.2.3. AMBIENTE DE PRUEBAS

 Hardware
[La siguiente tabla relaciona los recursos de hardware que son necesarios para crear un
ambiente inicial de pruebas]
Equipo Procesador DD RAM Aplicación a
instalar
  Software
[Se especifica el software a instalar en el equipo de pruebas]

2.2.4. PLAN DE PRUEBAS

Tipos De Prueba: <Por cada tipo de prueba diligencie un cuadro>
<Tipo de prueba, por ejemplo: unitarias, de integración, funcionales, de
Tipo de prueba: rendimiento, de volumen, de disponibilidad de datos, de entorno, de
seguridad, de interfaz de usuario, de aceptación, de regresión, etc.>
Objetivo: <Objetivo de la ejecución del tipo de prueba>
<Técnica empleada para ejecutar la prueba. Secuencia de pasos y
Técnica:
condiciones que debe seguir el probador para ejecutar la prueba>
Precondiciones: <Condiciones previas para la ejecución de la prueba>
<Criterios para considerar que la ejecución de la prueba generó resultados
Criterios de éxito:
satisfactorios>

2.3. DISEÑO Y EJECUCION DE LAS PRUEBAS

2.3.1. Pruebas Unitarias
[Diseño de casos de prueba para cada componente, realización de las
pruebas, ejecución y evaluación]

2.3.1.1. Clases de equivalencia

[Para cada interfaz de entrada, coloque el pantallazo de la interfaz y
diseñe las clases de equivalencia]
 2.3.1.2. Valores Limites
[Para cada interfaz identifique las clases de equivalencia que aplican para
valores limites]

CAMPO CLASE DE EQUIVALENCIA DESCRIPCION DE LOS

CASOS DE PRUEBAS

2.3.1.3. Camino básico

[Para cada clase identifique los métodos, coloque el diseño detallado de
cada clase de su aplicación]

• Para cada clase identifique los métodos donde encuentre estructuras

• Elabore el grafo y encuentre los caminos a probar para cada método o
módulo, que tenga estructuras a validar. (utilice el siguiente formato por
cada método o modulo).

CAMINO DATOS ENTRADA ESCENARIO

2.3.1.4. Diseño y ejecución Casos de pruebas

Casos De Prueba: <Por cada tipo de prueba definido y por cada funcionalidad de cada módulo
sometido a pruebas, se debe generar un caso de prueba.>

Identificador: <Identificador único del caso de prueba>

Descripcion < Descripción, detalle del caso de prueba>
Probador: <Nombre de la persona que ejecuta la prueba>
Fecha Planeación: <Fecha en que se realiza la planeación de l caso de prueba>
Módulo <Módulo al que pertenece la funcionalidad que será sometida a pruebas con
este caso>
Funcionalidad a
probar: <Funcionalidad que será sometida a pruebas con este caso>

Objetivo de la
<Objetivo de la funcionalidad que será sometida a pruebas con este caso>
funcionalidad:
<Conjunto de condiciones que deben ser ciertas o que se deben cumplir antes
Precondiciones:
de iniciar el caso de uso>
<Resultado que se espera obtener con la ejecución de la prueba, se debe
Resultado esperado:
establecer antes de ejecutar la prueba>
<Resultado obtenido después de ejecutar la prueba. En caso de que el
Resultado obtenido: resultado obtenido sea diferente al resultado esperado se deben describir
dichas diferencias y las posibles causas que las generaron>

[Determine un conjunto de datos de pruebas por cada caso de prueba, asociada a una funcionalidad
de un componente del software, donde se integren las dos técnicas: Caja blanca y caja negra]

Respuesta esperada de la
Escenarios de prueba Coincide (Si/No)
aplicación
Tipo
Valor
escenario
<Dato de <Correcto/I <Descripción completa de respuesta que <sí/no, según la
prueba> ncorrecto> debe dar la aplicación al usar el campo respuesta obtenida>
especificado con el dato de prueba>

 Ejecución casos de pruebas

[Ejecutar las pruebas con la herramienta, coloque aquí los pantallazos de la
ejecución de las pruebas con la herramienta]

 Evaluación de la prueba
[Realice la evaluación de las pruebas ejecutadas con la herramienta]

Prueba
Componente / Caso de Resultado Seguimiento Conclusión
Producto prueba
[Especificar: el [Describir el
componente o [Especificar seguimiento que [Documentar de
[Describir el
producto de la el caso de se llevará a cabo ser el caso,
resultado obtenido
solución prueba en base a la cualquier
exitoso o fallido.]
tecnológica a efectuado.] evidencia hallazgo.]
probar.] obtenida.]
2.3.2. Pruebas de Integración
2.3.2.1. Técnicas de pruebas incrementales
 Incremental Ascendente
 Incremental descendente
 Diseño de casos de pruebas, utilice la siguiente plantilla por cada
integración

2.3.2.2. Pruebas basadas en hilos

Tomar tres casos de usos principales y aplicar estas pruebas, realizar el diseño y
aplicar la plantilla del punto anterior en el diseño de los casos de pruebas
Cada conjunto de casos de prueba para cada caso de uso deberá contemplar:

ELEMENTO DEL CASO DE USO CASO DE PRUEBA

Datos de entrada Verificar que los datos de entrada cumplan con:
 Obligatoriedad
 Tipo de datos
 Longitud
 Estructura
Reglas de Negocio Validar reglas de negocio que afecten los datos de
entrada (Dependencia de datos).
Validar reglas de negocio que afecten los flujos.
Flujos Alternos Verificar la ejecución de todos los flujos alternos.
Flujos de Excepción Verificar la ejecución de todos los flujos de
Excepción.
Flujo Básico Verificar la ejecución del flujo básico.
Generalidades: Los casos de prueba deben especificar
exactamente rutas, nombres de archivos, valores
para los datos de entrada.

2.3.2.3. Diseño de los casos de pruebas

 2.3.2.4. Ejecución de las pruebas
[Ejecutar las pruebas con la herramienta, coloque aquí los pantallazos de la
ejecución de las pruebas con la herramienta]

2.3.2.5. Evaluación de las pruebas

Prueba
Componente / Caso de Resultado Seguimiento Conclusión
Producto prueba
[Especificar: el [Describir el
componente o [Especificar seguimiento que [Documentar de
[Describir el
producto de la el caso de se llevará a cabo ser el caso,
resultado obtenido
solución prueba en base a la cualquier
exitoso o fallido.]
tecnológica a efectuado.] evidencia hallazgo.]
probar.] obtenida.]

2.3.3. PRUEBAS DE ACEPTACIÓN

El objetivo de las pruebas de aceptación es validar que la solución desarrollada
cumpla con el funcionamiento esperado y permitir al usuario de dicho sistema
determine su aceptación, desde el punto de vista de su funcionalidad y de su
rendimiento. Estas pruebas son realizadas por el cliente, donde comprueba que el
sistema cumple con lo definido y se obtiene la conformidad del cliente. Esta
prueba se realiza mediante el proceso de validación de caja negra.
2.3.4. Diseño de los casos de pruebas

Busque y utilice una plantilla plan de pruebas de aceptación

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/461
2.3.5. Ejecución de las pruebas
Ejecutar las pruebas con la herramienta

2.3.6. Evaluación de las pruebas

2.4. CONCLUSIONES
2.5. REFERENCIAS
 3. METRICAS DEL SOFTWARE

3.1. Introducción
Importancia de aplicar métricas al software y sus beneficios
3.1.1. Objetivos
Definir claramente lo que se quiere alcanzar en la fase de métricas.
3.1.2. Alcance
Definir los tipos de métricas aplicar en este trabajo
3.1.3. Tipos y herramientas de métricas
En esta parte se describen los modelos de métricas a utilizar y las
herramientas utilizadas.

3.2. Métricas de Producto

3.2.1. Métricas de tamaño
Determine las siguientes medidas de tamaño del producto
(Realice teniendo en cuenta el diagrama de clase del proyecto)
Clase / Métodos/ Módulos No No. Complejidad
Función Atributos LOC Ciclomatica

Clase 1 Metodo1
……
……
Método N
Subtotal Total métodos Total No. Total. Total
Clase1 Atributos LOC Complejidad
Clase 2 Metodo1
……
……
Método N
Subtotal Total métodos Total No. Total. Total
Clase2 Atributos LOC Complejidad
…..
……
…
Clase N
Total No. Total No. métodos Total Total. Total
Clases Atributos LOC Complejidad
* LOC- Líneas de código creadas por personal (no creadas por generador de
aplicaciones)
Teniendo en cuenta los datos recolectados en la tabla anterior determine cual
clase tiene mayor tamaño:
 Longitud - Líneas de códigos (LOC)
 Complejidad

3.2.2. Métricas de clases

Encuentre las siguientes medidas, interprételas y realice un análisis
Clase/ No. No. Métodos Profundidad del No. de Acoplamiento
módulos Atributos Métodos ponderados árbol de herencia hijos NOC entre clases
por clase WMC DIT CBO
Clase 1
Clase 2
……….
……….
Totales

 Teniendo en cuenta las medidas anteriores, indique y demuestre cual

clase tiene:
 Mayor acoplamiento
 Mayor cohesión
 Mayor grado de modularidad
 Mayor complejidad

 Considere las medidas de una clase, considerando la complejidad y

haga un análisis, compare: WMC, CBO y métodos por clases

3.2.3. Métricas de funcionalidad

Tome el documento de requerimientos funcionales, requerimientos no funcionales,

el diagrama de clases, las interfaces de entradas y salidas, determine:

Entidad – Archivo

Entradas del usuario

Salidas (Reportes, informes)

Consultas de usuarios
Interfaces (con otros sistemas)

 Determine el punto de función

 Encuentre el tamaño en miles de líneas de código KLOC

3.2.4. Análisis métricas de producto

 Considere las siguientes medidas de tamaño según la longitud y haga
un análisis:
1. Tome las medidas de tamaño del software en LOC: Las contadas, las
generadas por PF y las obtenidas con una herramienta
2. Teniendo el tamaño calcule el esfuerzo y la duración del proyecto

Duración =Esfuerzo/No. persona

LOC LOC/PF LOC Herramienta

Tamaño
Esfuerzo
Duración (meses)
3. Analice los resultados dados en la tabla anterior

3.3. Métricas de productos con atributos externos

3.3.1. Teniendo en cuenta los siguientes objetivos, aplique el
método GQM para cada objetivo que se quiera medir en el
proyecto, encuentre las medidas y establezca métricas.
Objetivo 1: Garantizar la integridad del sistemas
Objetivo 2: Garantizar que el software opere en diferentes ambientes
Objetivo 3: Evaluar el funcionamiento del software ante fallos
Objetivo 4: Evaluar la facilidad de uso del software
Objetivo 5: Evaluar la capacidad de respuesta del software
 3.3.2. Investigue métricas relacionadas con los siguientes criterios
de calidad, y aplique el proceso de métricas:
 Usabilidad
 Mantenibilidad
 Seguridad
 Adecuidad
 Disponibilidad

3.4. Aplicación herramientas de métricas

Utilice una herramienta de métricas, analice las medidas que genera y cuál
sería su análisis (Muestre el pantallazo de la herramienta analizando su
software).
3.5. CONCLUSIONES

CONCLUSIONES
BIBLIOGRAFÍA - REFERENCIAS