SlideShare uma empresa Scribd logo
1 de 170
Baixar para ler offline
UNIVERSIDAD DE LAS FUERZAS ARMADAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
CARRERA DE INGENIERÍA EN SISTEMAS E INFORMÁTICA
Ing. Mauricio Campaña Ortega MsC. CCNA. CCIA.
INGENIERÍA DE SOFTWARE II
CALIDAD DEL SOFTWARE
 La integridad de un producto de software depende
de la acción combinada de tres tipos de disciplinas:
Desarrollo
Gestión
Control
 Dentro de las disciplinas de control se encuentra la
Garantía de Calidad del Software, cuyo objetivo es
asegurar un cierto nivel de calidad en el producto de
software desarrollado.
OBJETIVOS
Al finalizar esta unidad estará en capacidad de:
Comprender el significado de la terminología utilizada.
Ser capaz de caracterizar la calidad de un producto de software en
términos de un modelo de calidad.
Comprender en que consiste la Garantía de Calidad en un proyecto
de desarrollo de software.
Conocer las consideraciones que se debe tener en cuenta a la hora
de construir un Sistema de Garantía de Calidad.
Ser capaz de participar en una revisión o auditoría.
Ser consciente de las medidas que puede tomar para construir
productos de mayor calidad.
Conocer los principales métodos de evaluación del proceso de
desarrollo de software.
Conocer los principales modelos para la mejora del proceso de
desarrollo de software.
CALIDAD DE
PROCESO
CALIDAD DE PROCESO
Conjunto de actividades, métodos, prácticas y
transformaciones que la gente usa para desarrollar
y mantener software y los productos de trabajo
asociados (planes de proyecto, diseño de
documentos, código, pruebas y manuales de
usuario)”
“Proceso o conjunto de procesos usados por una
organización o proyecto, para planificar, gestionar,
ejecutar, monitorizar, controlar y mejorar sus
actividades software relacionadas”
CALIDAD DEL PRODUCTO DE
SOFTWARE
La calidad del producto de software se diferencia de la calidad de otros
productos de fabricación industrial, ya que el software tiene ciertas
características especiales:
 El software es un producto mental, no restringido por las leyes de la
física o por los límites de los proceso de fabricación. Es algo abstracto
y su calidad también lo es.
 Se desarrolla, no se fabrica. El coste esta fundamentalmente en el
proceso de diseño, no en la producción. Y los errores se introducen
también en el diseño no en la producción.
 El software no se deteriora con el tiempo. No es susceptible a los
efectos del entorno, y su curva de fallos es muy diferente de la del
hardware. Todos los problemas que surjan durante el mantenimiento
estaban allí desde el principio y afectan a todas las copias del mismo;
no se generan nuevos errores.
 Es artesanal en gran medida. El software en su mayoría se construye a
medida, en vez de ser construido ensamblando componentes
existentes y ya probados, lo que dificulta aún más el control de su
calidad. Aunque se ha escrito mucho sobre reutilización de software,
hasta ahora se han conseguido pocos éxitos tangibles.
CALIDAD DEL PRODUCTO DE
SOFTWARE
 El mantenimiento del software es mucho más complejo que el
mantenimiento del hardware. Cuando un componente de hardware se
deteriora se sustituye por una pieza de repuesto, pero cada fallo en el
software implica un error en el diseño o en el proceso mediante el cual
se tradujo el diseño en código máquina ejecutable.
 Es engañosamente fácil realizar cambios sobre un producto software,
pero los efectos de estos cambios se pueden propagar de forma
explosiva e incontrolada.
 Como disciplina, el desarrollo de software es aún muy joven, por lo que
las técnicas de las que se disponen aún no son totalmente efectivas o no
están totalmente calibradas.
 El software con errores no se rechaza. Se asume que es inevitable que el
software presenta errores.
PROBLEMAS DE LA CALIDAD DEL
PRODUCTO DE SOFTWARE
Los principales problemas a los que se enfrenta al hablar de la calidad del
producto de software son:
 La definición misma de la calidad del software: ¿Es realmente posible
encontrar un conjunto de propiedades en un producto software que de
una indicación de calidad? Para dar respuesta a esta pregunta aparecen
los Modelos de Calidad.
 Modelos de Calidad: La calidad de define de forma jerárquica. Resuelven la
complejidad mediante la descomposición. La calidad es un concepto que se deriva
de un conjunto de subconceptos.
 La comprobación de la calidad del software: ¿Cómo medir el grado de
calidad de un producto de software? Aparece el concepto de Control de
Calidad.
 Control de Calidad: Actividades para evaluar la calidad de los productos
desarrollados.
PROBLEMAS DE LA CALIDAD DEL
PRODUCTO DE SOFTWARE
 La mejora de la Calidad del Software: Cómo utilizar la información
disponible acerca de la calidad del producto de software para mejorar
su calidad a lo largo del ciclo de vida? No solo es posible “medir” la
calidad, sino también “construir” la calidad durante el proceso de
desarrollo del producto.Aparecen dos conceptos importantes:
Gestión de Calidad: Determinación y Aplicación de las políticas de
calidad de la empresa (objetivos y directrices generales)
Garantía o Aseguramiento de Calidad: Conjunto de Actividades
planificadas y sistemáticas necesaria para proporcionar confianza en
que el producto software satisfacerla los requisitos dados de calidad.
DEFINICIÓN DE CALIDAD
 Calidad es “Conformidad con los requisitos y confianza en el
funcionamiento” Deming.
 “Adecuación para su uso”. Jurán
 “Hacerlo bien a la primera” o sea poner más énfasis en la
prevención. Crosby
Definiciones de calidad extraídos de estándares internacionales
 “La calidad es la suma de todos aspectos o características de un
producto o servicio que influye en su capacidad para satisfacer las
necesidades, expresadas o implícitas”. ISO 8402.
 “Grado con el cual el cliente o usuario percibe que el software
satisface sus expectativas”. IEE 729-83.
 “Capacidad del producto software para satisfacer los requisitos
establecidos”. DoD 2168.
DEFINICIÓN DE CALIDAD
 La calidad es algo relativo, depende de los requisitos o necesidades que
se desea satisfacer.
 En un producto de software se tendrán tres visiones de la calidad:
Necesaria o requerida: La que quiere el cliente.
Programada o Especificada: La que se ha especificado explícitamente y
se intenta conseguir.
Realizada: la que se ha conseguido.
 A la intersección entre la Calidad Requerida y la Calidad Realizada se
llama Calidad Percibida y es la única que el cliente valora. Toda aquella
calidad que se realiza pero no se necesita es un gasto inútil de tiempo y
dinero.
TERMINOLOGÍA BÁSICA
 ERROR: como una incorrección cometida por un humano
durante el proceso de desarrollo.
 DEFECTO: es la consecuencia de un error. Así por ejemplo , si
una función tiene el objetivo de sumar 10 al valor que recibe
como entrada, y en realidad está sumando 20, eso es un defecto
debido al error del programador que escribió 20 en lugar de 10.
también se llama DEFECTO a una desviación en el valor
esperado para una cierta característica. Los defectos no tienen
porque afectar al funcionamiento del objeto defectuoso. Un
programa poco mantenible, por ejemplo, puede ser totalmente
correcto.
 FALLO (failure): la manifestación de un defecto en el software.
Por ejemplo cuando a la función anterior se le da como entrada
el valor 10 y la salida que se obtiene es 30 en lugar de 20 que es
el valor esperado.
TERMINOLOGÍA BÁSICA
FALLAS (fault): son los defectos que aún no
han sido detectados y eliminados cuando
comienzan las pruebas. Algunas de estas fallas se
convierten en fallos si se detectan durante las
pruebas o el uso del sistema.
INCIDENTE o INCIDENCIA: a una
situación en la que se produce y se informa de
un comportamiento no esperado en el sistema.
Una incidencia puede venir provocada por un
defecto o no.
Estructura de los modelos de calidad
En los modelos de calidad, la calidad se define de forma jerárquico. Es un
concepto que se deriva de un conjunto de subconjuntos cada uno de los cuales se
va a evaluar a través de un conjunto de indicadores o métricas. Tienen una
estructura de tres niveles:
Representan la calidad desde el punto de vista del usuario,
son las características que componen la calidad, también
se los conoce como Atributos de Calidad Externos.
Cada uno de los factores se descompone en un conjunto
de CRITERIOS de calidad, representan una visión de la
calidad desde el punto de vista del productos del software,
conocidos como Atributos de Calidad Internos.
Calidad del Software
Factores de Calidad
Criterios de Calidad del
Producto
Métricas del Producto
Son medidas cuantitativas de ciertas características del
producto que cuando están presentes dan una indicación
del grado en que dicho producto posee un determinado
atributo de calidad.
Modelos de Calidad
 La ventaja de los Modelos de Calidad, está en que la misma se convierte en algo
concreto, que se puede definir, que se puede medir y sobre todo se puede
planificar.
 Una desventaja es que aun no se ha demostrado su validez absoluta, las
conexiones que se establecen entre características, atributos y métricas se
derivan de la experiencia y de ahí que existan múltiples modelos.
MC CALL
MÉTODO GQM
BOEHM
ISO 9126
FURPS
 Organiza los factores en tres ejes o puntos de vista desde los cuales el
usuario puede contemplar la calidad del producto:
 Operación del Producto.
 Revisión del Producto.
 Transición del Producto
 El Modelo McCall se basa en 11 factores de calidad, que se organizan en
torno a los tres ejes de la siguiente forma:
ATRIBUTOS DEL MODELO DE Mc CALL
PUNTO DEVISTA FACTORES
Operación del Producto  Facilidad de Uso
 Integridad
 Corrección
 Fiabilidad
 Eficiencia
Revisión del Producto  Facilidad de Mantenimiento
 Facilidad de Prueba
 Flexibilidad
Transición del Producto  Facilidad de reutilización
 Interoperabilidad
 Portabilidad
FACILIDAD DE MANTENIMIENTO
(¿Puedo arreglarlo?)
FACILIDAD DE PRUEBA
(¿Puedo probarlo?)
FLEXIBILIDAD
(¿Puedo modificarlo?)
ATRIBUTOS DEL MODELO DE Mc CALL
OPERACIÓN
INTEROPERABILIDAD
(¿Puedo comunicarlo con otro sistema?)
PORTABILIDAD
(¿Podré utilizarlo en otra máquina?)
REUSABILIDAD
(¿Podré utilizar parte del software?)
CORRECCIÓN (¿Hace el software lo que yo quiero?)
FIABILIDAD (¿Lo hace de forma exacta todo el tiempo?)
EFICIENCIA (¿Se ejecutará sobre mi hardware lo mejor posible?)
INTEGRIDAD (¿Es seguro?)
FACILIDAD DE USO (¿Puedo ejecutarlo?)
Los factores de McCall desde el punto de vista de Operación del Producto se definen de
la siguiente forma:
FACTORES DE Mc CALL
• El coste y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e
interpretar la salida del mismo
Facilidad de
Uso
• Hasta que punto se controlan los accesos ilegales a programas o datos. Un programa
que permite el acceso de personas no autorizadas a ciertos datos es poco íntegro.Integridad
• Hasta que punto un programa cumple sus especificaciones y satisface los objetivos del
usuario. Ejemplo: si un programa debe ser capaz de sumar dos números y en lugar de
eso los multiplica. Es quizás el factor más importante, aunque puede no servir de nada
sin los demás factores
Corrección
• Hasta que punto se puede confiar en el funcionamiento sin errores del programa. Por
ejemplo, si el programa anterior suma dos números, pero en un 25 % de los casos el
resultado que da no es correcto, es poco fiable.
Fiabilidad
• Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un
programa para desempeñar su función. Un programa que suma dos números y
necesita 2 MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta
es poco eficiente.
Eficiencia
FACTORES DE Mc CALL
• El Coste de localizar y corregir defectos en un programa que
aparecen durante su funcionamiento
Facilidad de
Mantenimiento
• El coste de probar un programa para comprobar que satisface
sus requisitos. Por ejemplo, si un programa requiere desarrollar
una simulación completa de un sistema para poder probar que
funciona bien, en un programa difícil de probar.
Facilidad de
Prueba
• El coste de modificación del producto cuando cambian sus
especificaciones.Flexibilidad
Los factores de McCall desde el punto de vista de Revisión del Producto se definen de la
siguiente forma:
FACTORES DE Mc CALL
• Hasta que punto se puede transferir un módulo o programa del
presente sistema a otra aplicación, y con que esfuerzo.
Facilidad de
Reutilización
• El coste y esfuerzo necesario para hacer que el software pueda
operar conjuntamente con otros sistemas o aplicaciones de
software externos.
Interoperabilidad
• Conocido como transportabilidad. El coste de transportar o
migrar un producto de una configuración hardware o entorno
operativo a otro.
Portabilidad
Los factores de McCall desde el punto de vista de Transición del Producto se definen de
la siguiente forma:
 La Relación Factores – Criterio desde el Punto de Vista de Operación
del Producto
FACTORES – CRITERIOS MODELO DE Mc CALL
PUNTO DEVISTA FACTORES
Facilidad de Uso  Facilidad de Operación
 Facilidad de Comunicación
 Facilidad de Aprendizaje
Integridad  Control de accesos
 Facilidad de auditoría
Corrección  Completitud
 Consistencia
 Trazabilidad
Fiabilidad  Precisión
 Consistencia
 Tolerancia a fallos
 Modularidad
 Simplicidad
Eficiencia  Eficiencia en Ejecución
 Eficiencia en almacenamiento
CRITERIOS DE Mc CALL PARA EL FACTOR
FACILIDAD DE USO
• Atributos del software que determinan la facilidad de operación
del software
Facilidad de
Operación
• Atributos del software que proporcionan al usuario entradas y
salidas fácilmente asimilables
Facilidad de
Comunicación
• Atributos del software que facilitan la familiarización inicial del
usuario con el software y la transición desde el modo actual de
operación.
Facilidad de
Aprendizaje
Los criterios de McCall para el factor FACILIDAD DE USO se descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
INTEGRIDAD
• Atributos del software que proporcionan control de acceso al
software y los datos que maneja
Control
de
Accesos
• Atributos del software que facilitan el registro y la auditoría de
los accesos al software.
Facilidad
de
Auditoría
Los criterios de McCall para el factor INTEGRIDAD se descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
CORRECCIÓN
• Atributos del software que proporcionan la implementación
completa de todas las funciones requeridas.Completitud
• Atributos del software que proporcionan uniformidad en las
técnicas y notaciones de diseño e implementación utilizadas.Consistencia
• Conocido como Rastreabilidad. Atributos del software que
proporcionan una traza desde los requisitos a la
implementación con respecto a un entorno operativo concreto.
Trazabilidad
Los criterios de McCall para el factor CORRECCIÓN se descomponen en:
• Atributos del software que proporcionan el grado de
precisión requerido en los cálculos y los resultados.Precisión
• Atributos de software que proporcionan uniformidad en las
técnicas y notaciones de diseño e implementación utilizadasConsistencia
• Atributos del software que posibilitan la continuidad del
funcionamiento bajo condiciones no usuales.
Tolerancia a
fallos
• Atributos del software que proporcionan una estructura de
módulos altamente independientes.Modularidad
• Atributos del software que posibilitan la implementación de
funciones de la forma más compresible posibleSimplificidad
CRITERIOS DE Mc CALL PARA EL FACTOR
FIABILIDAD
Los criterios de McCall para el factor FIABILIDAD se descomponen en:
• Atributos del software que minimizan el tiempo de
procesamiento.
Eficiencia en
Ejecución
• Atributos del software que minimizan el espacio de
almacenamiento necesario.
Eficiencia en
Almacenamiento
Los criterios de McCall para el factor EFICIENCIA se descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
EFICIENCIA
 La Relación Factores – Criterio desde el Punto de Vista de Revisión del
Producto
FACTORES – CRITERIOS MODELO DE Mc CALL
PUNTO DEVISTA FACTORES
Facilidad de Mantenimiento  Modularidad
 Simplicidad
 Consistencia
 Concisión
 Auto descripción
Facilidad de Prueba  Modularidad
 Simplicidad
 Auto descripción
 Instrumentación
Flexibilidad  Auto descripción
 Capacidad de expansión
 Generalidad
 Modularidad
• Atributos del software que proporcionan una estructura
de módulos altamente independientes.Modularidad
• Atributos del software que posibilitan la implementación de
funciones de la forma más compresible posibleSimplicidad
• Atributos de software que proporcionan uniformidad en las
técnicas y notaciones de diseño e implementación utilizadas.Consistencia
• Atributos del software que posibilitan la implementación de una
función con la menor cantidad de código posible.Concisión
• Atributos del software que proporcionan explicaciones sobre la
implementación de las funciones.
Auto
descripción
CRITERIOS DE Mc CALL PARA EL FACTOR
FACILIDAD DE MANTENIMIENTO
Los criterios de McCall para el factor FACILIDAD DE MANTENIMEINTO se
descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
FACILIDAD DE PRUEBA
• Atributos del software que proporcionan una estructura de
módulos altamente independientes.Modularidad
• Atributos del software que posibilitan la implementación de
funciones de la forma más compresible posibleSimplicidad
• Atributos del software que proporcionan explicaciones sobre la
implementación de las funciones.Auto descripción
• Atributos del software que posibilitan la observación del
comportamiento del software durante su ejecución (para facilitar
las mediciones del uso o la identificación de errores )
Instrumentación
Los criterios de McCall para el factor FACILIDAD DE PRUEBA se descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
FLEXIBILIDAD
• Atributos del software que proporcionan explicaciones sobre la
implementación de las funciones.
Auto
descripción
• Atributos del software que posibilitan la expansión del software
en cuanto a capacidades funcionales y datos.
Capacidad de
expansión
• Atributos del software que posibilitan amplitud a las funciones
implementadas.Generalidad
• Atributos del software que proporcionan una estructura de
módulos altamente independientes..Modularidad
Los criterios de McCall para el factor FLEXIBILIDAD se descomponen en:
 La Relación Factores – Criterio desde el Punto de Vista de Transición
del Producto
FACTORES – CRITERIOS MODELO DE Mc CALL
PUNTO DEVISTA FACTORES
Facilidad de Reutilización  Auto descripción
 Generalidad
 Modularidad
 Independencia entre sistema y software
Interoperabilidad  Modularidad
 Compatibilidad de Comunicaciones
 Compatibilidad de datos
Portabilidad  Auto descripción
 Modularidad
 Independencia entre sistema y software
 Independencia del hardware
• Atributos del software que proporcionan explicaciones
sobre la implementación de las funciones.Auto descripción
• Atributos de software que proporcionan amplitud a
las funciones implementadas
Generalidad
• Atributos del software que proporcionan una
estructura de módulos altamente independientes.
Modularidad
• Atributos del software que determinan la
independencia del entorno operativo.
Independencia
entre sistema y
software
• Atributos del software que determinan su
independencia del hardware.
Independencia del
hardware
CRITERIOS DE Mc CALL PARA EL FACTOR
REUSABILIDAD
Los criterios de McCall para el factor REUSABILIDAD se descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
INTEROPRABILIDAD
• Atributos del software que proporcionan una estructura de
módulos altamente independientes.Modularidad
• Atributos del software que posibilitan el uso de protocolos de
comunicación e interfaces estándar.
Compatibilidad
de
Comunicaciones
• Atributos del software que proporcionan representaciones de
datos estándar.
Compatibilidad
de Datos
Los criterios de McCall para el factor INTEROPERABILIDAD se descomponen en:
CRITERIOS DE Mc CALL PARA EL FACTOR
PORTABILIDAD
• Atributos del software que proporcionan explicaciones sobre la
implementación de las funciones.
Auto
descripción
• Atributos del software que proporcionan una estructura de
módulos altamente independientes.Modularidad
• Atributos del software que determinan la independencia del
sistema operativo.
Independencia
entre sistema y
software
• Atributos del software que determinan su independencia del
hardware.
Independencia
del hardware
Los criterios de McCall para el factor PORTABILIDAD se descomponen en:
MODELO BOEHM
FURPS
Los factores de calidad FURPS provienen de
trabajos anteriores, definiendo los siguientes
atributos para cada uno de los cinco factores
principales:
• Funcionalidad
• Facilidad de uso
• Fiabilidad
• Rendimiento
• capacidad de soporte.
ISO/IEC 9126:TECNOLOGÍAS DE LA INFORMACIÓN
CALIDAD DE LOS PRODUCTOS SOFTWARE.
• Modelo de CalidadParte 1
• Métricas ExternasParte 2
• Métricas InternasParte 3
• Métricas de Calidad en UsoParte 4
calidad externa
e interna
funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad
adecuación
exactitud
interoperabilidad
seguridad de
acceso
cumplimiento de
la funcionalidad
madurez
tolerancia a
fallos
capacidad de
recuperación
cumplimiento de
la fiabilidad
capacidad para
ser entendido
capacidad para
ser aprendido
capacidad para
ser operado
capacidad de
atracción
cumplimiento de
la usabilidad
comportamiento
temporal
utilización de
recursos
cumplimiento de
la eficiencia
capacidad para
ser analizado
capacidad para
ser cambiado
estabilidad
capacidad para
ser probado
cumplimiento de
la mantenibilidad
adaptabilidad
instalabilidad
coexistencia
capacidad para
ser reemplazado
cumplimiento de
la portabilidad
MODELO DE CALIDAD PARA CALIDAD
INTERNAY EXTERNA
MODELO DE CALIDAD PARA CALIDAD EN USO
ENTORNOS O MODELOS
Son los 3 vértices donde descansa un proceso de
mejora que trabaja sobre 3 niveles de la organización.
CMM se enfoca a nivel organizacional
TSP se enfoca a un proceso de grupos de trabajo
PSP se enfoca a nivel personal
PSP
Personal Software Process
Definición
Justificación
Pasos para la Implantación
Ciclo deVida
DEFINICIÓN
Es un ciclo de vida del proceso de
software que se caracteriza por:
Ser
definido,
conciso
Altamente
prescriptivo
Rápido y
barato
JUSTIFICACIÓN DEL PSP
Los ingenieros de software rara vez basan su
trabajo en prácticas y metodologías establecidas
y son prácticamente escépticos a cambiar sus
hábitos de trabajo.
Los ingenieros están en un círculo vicioso, "sólo
creen en lo que han probado y no prueban otras
metodologías", por esta razón para poder
implantar PSP, se tuvo que obligarlos y se
tuvieron buenos resultados.
PASOS PARA IMPLANTACION PSP
Lo que sigue es optimizar la interacción entre equipos y aquí entraría Team
Software Process, el TSP extiende y refina los métodos de CMM y PSP sobre
desarrollo y mantenimiento de equipos, y llegar a lo que se le llama un equipo
auto dirigido.
Requiere un fuerte soporte de administración, es necesario que los
administradores entiendan el PSP, saber como apoyarlos y como monitorear sus
avances, sin un adecuado monitoreo los ingenieros caerán otra vez en los malos
hábitos.
La Capacitación es sobre grupos o equipos, y serán grupos que así lo han sido y
seguirán siendo.
Los ingenieros deben ser entrenados por un instructor calificado de PSP.
CICLO DEVIDA PSP
7 niveles del PSP
PSP3
Proceso Personal Cíclico
PSP2 y PSP2.1
Manejo Personal de calidad
PSP1 y PSP1.1
Proceso Personal de Planeación
PSP0 y PSP0.1
Línea Base del PSP
• Identificar actividades: definición, secuencia
• Bases mejoras: planeación, evaluación, resultados
• Documentar proceso Formas de:
• Actividades (Scripts)
• Tiempos (Logs Time)
• Defectos (Defect Logs)
• Resumir planes, resultados (Proyect plan summary)
PSP 0
• Registrar tamaño del producto y hacer un histórico:
• Líneas de código (LDC)
• Puntos de función (PF)
• Estandarización de la codificación
• Registrar problemas y mejoras de propuestas
PSP 0.1
• Mejora la planeación:
• Con la estimación de recursos
• Introducción de calendarizar, plasmar el plan con
números, un presupuesto
PSP 1
• Mejora la ejecución:
• Detección temprana de defectos, en base a la
predicción de estos.
• Revisiones de diseño
• Revisiones de código
• Uso de checklists (Listas de verificación
PSP 2
• Mejora el diseño:
• Al hacer uso de formas detalladas de diseño
(formas C76, C77)
PSP 2.1
• Mejora el ciclo, mejora del proceso en términos
de hacerlo repetible (cíclico):
• Para aplicación a programas de mayor tamaño
• Registro del seguimiento de asuntos
importantes
• Análisis del resumen de la planeación,
tiempos, tamaños y defectos por cada ciclo.
PSP 3
Material  monster is ii emco
CICLO DE VIDA PSP
FASE PLANEACIÓN
(PLAN DE PROYECTO)
INPUT
Descripción del
problema, resumen
del proyecto,
resumen cíclico,
tamaño estimado,
tiempo estimado,
formas de
planeación.
ACTIVIDAD
Requerimientos,
tamaño estimado,
desarrollo
estrategia,
estimados de
recursos,
planificación y
programas de
tareas, estimación
de defectos.
OUTPUT
Diseño conceptual,
resumen plan,
resumen del ciclo,
patrones estimados
de tamaño y
planeación de
tareas, programas
de patrones de
planeación, registro
de tiempos.
CICLO DEVIDA PSP
FASE DISEÑO DE
PRODUCTO
INPUT
Tipificación
requerimientos,
diseño conceptual,
patrones de
estimaciones de
tamaño, resumen
parte cíclico,
seguimiento.
ACTIVIDAD
Especificaciones
externas, diseño
modular,
prototipos,
estrategia de
desarrollo y
documentación,
seguimiento.
OUTPUT
Diseño de
programa,
escenarios
operacionales,
especificación de
funciones y lógica,
resumen cíclico,
seguimiento y
estrategias de
pruebas y ciclo.
CICLO DEVIDA PSP
FASE REVISIÓN O
VALIDACIÓN DEL DISEÑO
INPUT
Programa de
diseño, escenarios
operacionales,
especificación de
funciones y lógica,
resumen cíclico,
seguimiento y
estrategia de
pruebas y ciclo.
ACTIVIDAD
Diseño de
apariencia,
verificación de
máquinas y lógica,
consistencia del
diseño, rehúso,
estrategia de
verificación,
detectar errores.
OUTPUT
Diseño de alto
nivel, registro de
seguimiento,
tiempos y defectos.
CICLO DEVIDA PSP
FASE DESARROLLO O
IMPLEMENTACIÓN
INPUT
Diseño de alto
nivel, registro de
seguimiento,
tiempos y defectos,
ciclo de desarrollo,
estrategia de
pruebas, patrones
de operación y
función.
ACTIVIDAD
Diseño de módulos,
revisión de diseño,
código, revisión de
código,
compilación,
pruebas,
aseguramiento de
calidad y del ciclo.
OUTPUT
Módulos de SW,
patrón de diseño,
lista de verificación
de código y diseño,
resumen del ciclo,
patrón de reporte
de pruebas, registro
de tiempo, defectos
y seguimiento.
CICLO DEVIDA PSP
FASE POSMORTEM,
EVALUACIÓN CICLO
INPUT
Definición de problema
y requerimientos, plan
de proyecto, producto
de software, patrón de
diseño, lista de
verificación, diseño,
resumen del ciclo,
patrón de pruebas,
registro de tiempo,
defectos y seguimiento.
ACTIVIDAD
Defectos previstos,
removidos, tamaño,
tiempo del
producto.
OUTPUT
Producto, listas de
verificación, plan de
proyecto y ciclo,
patrón de reporte
de pruebas y
diseño, forma con
propuesta de
mejora, registro
seguimiento
pruebas y tiempo.
TSP
Team Software Process
Definición
Objetivos
Estructura
Ciclo deVida
Roles y Responsabilidades
DEFINICIÓN
TSP está formado por dos componentes primarios que
abarcan distintos aspectos del trabajo en equipo :
Formación del equipo
de trabajo
Gestión del equipo de
trabajo
Es una metodología para dirigir el trabajo de mejora y
desarrollo de software además de establecer un entorno
donde el trabajo efectivo de equipo sea normal y natural.
OBJETIVOS DELTSP
• Generar un marco basado en PSP
• Desarrollar productos en varios ciclos
• Establecer estándares para medir la calidad y el
comportamiento
• Proporcionar métricas para equipos
• Evaluar roles y equipos
• Guías para solución de problemas en equipos.
ESTRUCTURA DETSP
CICLO DEVIDATSP
• Durante esta fase, y siendo el primer
ciclo, se realiza una revisión de los
objetivos del curso.
Lanzamiento
• Se establece la estrategia de desarrollo
decidiendo que se producirá, y se
identifica los riesgos.
Estrategia
• Asignación a cada miembro del equipo.
Planeación
• Entrevistas con el cliente y se especifican.
Requerimientos
CICLO DEVIDATSP
• Diseño de alto nivel, donde se especifica
y examina cada parte identificada.Diseño
• Revisión, compilación y prueba unitaria.
Implementación
• Se integran todos los programas.
Prueba
• Análisis del producto, Generación de las
evaluaciones del equipo.Postmortem
ROLESY RESPONSABILIDADES
Líder del Equipo
Dirige al equipo, se asegura que todos reporten sus
datos de los procesos y completen su trabajo tal y
como se planeó.
Gestor de desarrollo Guía al equipo en el diseño y desarrollo del producto.
Gestor de
Planificación
Apoya y guía al equipo en la planificación y
seguimiento del trabajo.
Gestor de
Calidad/Proceso
Apoya al equipo en definir sus necesidades acerca del
proceso, establecer y administrar el plan de calidad.
Administrador de
Requerimientos/
Soporte
Dirige al equipo en el desarrollo de requerimientos
de software, administra el plan de configuración
CMMI
Capability Maturity Model
Integration
Definición
Representación Continua
Estructura de CMMI en Representación Continua
Representación Escalonada
Estructura de CMMI en Representación Escalonada
Componentes
DEFINICIÓN
CMMI es el sucesor de CMM.
El objetivo del proyecto CMMI es mejorar la usabilidad de
modelos de madurez integrando varios modelos diferentes en
un solo marco (framework).
Fue creado por miembros de la industria y el gobierno.
• Representación Continua (Continuous Representation)
• Escalonada (Staged Representation)
Tiene 2 representaciones:
REPRESENTACIÓN CONTINUA
6 NIVELES DEFINIDOS EN CMMI
• El proceso no se realiza, o no se consiguen
sus objetivos.Incompleto
• El proceso se ejecuta y se logra su objetivo.Ejecutado
• El proceso se planifica, se revisa y se evalúa
para comprobar que cumple los requisitos.Gestionado
• Se ajusta a la política de procesos que existe
en la organización, alineada con las
directivas de la empresa.
Definido
• Se controla utilizando técnicas cuantitativas.
Cuantitativamente
Gestionado
• De forma sistemática se revisa y modifica o
cambia para adaptarlo a los objetivos del
negocio. Mejora continua.
Optimizando
Material  monster is ii emco
REPRESENTACIÓN ESCALONADA
(STAGED REPRESENTATION)
Establece 5 Niveles de Madurez (Maturity Level) para clasificar a
las organizaciones, en función de qué áreas de procesos
consiguen sus objetivos y se gestionan con principios de
ingeniería.
Es lo que se denomina un modelo escalonado, o centrado en la
madurez de la organización.
• 7 PA para el nivel de madurez o ML1
• 2 PA para el ML2
• 11 PA para el ML3
• 2 PA para el ML4
• 2 PA para el ML5
La selección de los Áreas de Proceso está prefijado, habiendo:
Material  monster is ii emco
Material  monster is ii emco
CALIDAD DEL
PRODUCTO
SOFTWARE
¿QUÉ ES LA CALIDAD DEL
SOFTWARE?
• “Grado con el cual el cliente o usuario
percibe que el software satisface sus
expectativas” (IEEE 729-83).
• “Conjunto de propiedades y de
características de un producto o servicio,
que le confieren aptitud para satisfacer
una necesidades explícitas o implícitas”
(ISO 8402:1984)
¿QUÉ ES LA CALIDAD DEL
SOFTWARE?
“La calidad del software es el grado con el que un
sistema, componente o proceso cumple los
requerimientos especificados y las necesidades o
expectativas del cliente o usuario”. (IEEE, Std.
610-1990).
“Concordancia del software producido con los
requerimientos explícitamente establecidos, con
los estándares de desarrollo prefijados y con los
requerimientos implícitos no establecidos
formalmente, que desea el usuario” (Pressman,
1998)
¿QUÉ ES LA CALIDAD DEL
SOFTWARE?
La calidad del software puede ser entendida como
el grado con el cual el usuario percibe que el
software satisface sus expectativas (IEEE 729-83).
El tipo y número de actividades de garantía de
calidad que es necesario adoptar en un proyecto o
en una organización depende del tamaño y
complejidad de los productos software que se estén
desarrollando.
Calidad
en uso
Calidad
externa
Calidad
interna
Calidad de
proceso
Proceso Producto
Efecto del
producto
Influye Influye Influye
Depende de Depende de Depende de
Contextos
de uso
proveedor usuario
¿CÓMO MEDIR LA CALIDAD DE
UN PRODUCTO SOFTWARE?
Se emplea para ellos modelos , que
especifican la calidad mediante la definición
de un conjunto de atributos o
características.
Se basa en descomponer la calidad del
producto en características y estas en
criterios que pueden ser medidos mediante
métricas.
Material  monster is ii emco
ACTIVIDADES
DE CONTROL
Comprueban si un producto posee o no una determinada
característica de calidad en el grado requerido.
Identificar defectos en el producto para corregirlos.
OBJETIVO
CONTROLES ESTÁTICOS
El objetivo principal es analizar el objeto sin necesidad de
ejecutarlo.
CONTROLES ESTÁTICOS MANUALES INFORMALES
• Examinar a mano e individualmente el objeto
que se acaba de desarrollar.
• Se aplica a los requisitos, especificaciones de
diseño y código según se desarrollan.
• Es más efectivo si se hace intercambiando el
objeto a examinar con otro compañero.
Comprobación
de escritorio
(desk checking):
• Revisión del código de un programador por
otros programadores (sus pares).
• Se puede poner en práctica creando un panel
que se encarga de revisar periódicamente
muestras de código.
Revisión por
pares o iguales
(peer review):
CONTROLES ESTÁTICOS MANUALES DISCIPLINADOS
El objetivo principal es conseguir que la responsabilidad del
control de calidad no recaiga sólo sobre el propio
desarrollador.
1. AUDITORÍAS:
Auditorías de
proyecto
Auditorías de
gestión de
proyecto
PROCEDIMIENTO DE UNA AUDITORÍA
• Define los objetivos de la auditoria y su alcance
• Se elabora un Plan de Auditoria, dando respuesta a: Por qué se
realiza, Para qué se realiza, Cuál es el producto que va a ser
auditado, etc.
Planificación
• Se inicia con una reunión de apertura de la investigación.
• Se lleva a cabo mediante entrevistas y revisiones en las que
se recopilan datos.
Llevar a cabo la
investigación
• Se utilizan técnicas de análisis estadístico, por parte de los
auditores.
• Se realiza una evaluación en paralelo de los resultados por un
grupo de evaluadores.
Analizar los
datos recogidos
Sugerir soluciones a los problemas encontrados y posibles mejoras.
Elaborar y presentar un informe de resultados
2. REVISIONES:
Se consigue que el peso de la evaluación técnica no recaiga sobre las mismas
personas involucradas en la producción del software, pues no pueden ser
totalmente objetivos.
Ofrece a los gestores, información fiable acerca de los aspectos técnicos del
proceso de desarrollo de software.
Es una reunión formal donde se presenta el estado actual de los resultados de
un proyecto a un usuario, cliente u otro tipo de persona interesada, y se realiza
un análisis estructurado.
Características:
DIFERENCIAS ENTRE REVISIONESY AUDITORÍAS:
Las revisiones se llevan a
cabo desde las primeras
fases del desarrollo,
mientras que las
auditorías se llevan a
cabo en las fases finales.
El objetivo de las
revisiones es detectar
defectos, mientras que el
objetivo de las auditorías
es certificar conformidad
e identificar desviaciones.
TIPOS DE REVISIONES
Se diferencian por la forma en que se desarrolla la reunión de revisión.
Inspecciones
• Los participantes leen el documento, guiados por el autor
del mismo, y comprueban en cada paso el cumplimiento de
los criterios de una lista de comprobación.
Walkthrough
(visita guiada):
• Se demuestra la funcionalidad del objeto revisado mediante
la simulación de su funcionamiento con casos de prueba y
ejemplos.
Se introducen al objeto los casos de prueba y se van
registrando los resultados intermedios.
DIFERENCIAS:
WALKTHROUGH
Están planteados como una
medida de ayuda al desarrollador.
Su objetivo fundamental es
incrementar el entendimiento,
comprender mejor el objeto.
Esta guiado por la estructura del
producto revisado.
Se usan para asegurar la
satisfacción de los criterios de
salida establecidos entre
diferentes etapas del desarrollo
(revisiones de fase).
INSPECCIONES
Planteadas como una medida de
ayuda al gestor.
El objetivo fundamental es
detectar defectos.
Proceso guiado por la lista de
comprobación.
Se planifican y procesan de una
manera mucho más formal que
los walkthrough.
Material  monster is ii emco
FASES EN LA INSPECCION
PLANIFICACION
Objetivos, Criterios de finalización, Lugar y fecha,
Disponibilidad de participantes
(coordinador/moderador, secretario)
ORIENTACION
INICIAL
Reunión de orientación para dar una idea del
objeto
PREPARACION
INDIVIDUAL
Antes de la realización de la inspección, una copia
de la documentación asociada al objeto, y lista de
comprobaciones checklist
FASES EN LA INSPECCION
REUNION DE
INSPECCION
El presentador.-
Punto por punto la lista de comprobación;
Componente a componente del producto; Por
grupos de puntos dentro de la lista de
comprobación; Cualquier otra situación intermedia
Al final de la reunión de inspección, los
participantes, valoran los resultados de la
inspección: Se cierra la inspección sin que se hayan
encontrado defectos; Defectos eliminados; Si se
encuentran otros defectos se realiza otra
inspección
FASES EN LA INSPECCION
SEGUIMIENTO
Autor del objeto revisado se encarga de
corregir los defectos encontrados
EVALUACION
Determina si se ha corregido todos los
defectos y si han surgido nuevos problemas, el
moderador se encarga de realizar la
evaluación.
DOCUMENTOS GENERADOS EN UNA INSPECCION
Informe
resumen.-
Conclusiones breves para la dirección (¿Qué se ha
revisado?; ¿Quién lo ha revisado?; ¿Cual fue la
conclusión?)
Lista acciones
pendientes.-
Informe para los autores del producto revisado
explica que esta mal y se puede dar soluciones o
correcciones (no debe llegar a la dirección).
Informe de
asuntos
relacionados.-
Para registrar problemas que salen a la luz durante
la inspección ( no relacionados con el objeto
revisado)
Informe del
proceso de
inspección.-
Cuando algo ha salido mal en el proceso de
inspección en si mismo
Informe final.-
Para informar a la dirección el cierre de la
inspección.
Informes o documentos generados como resultado de una inspección son
los siguientes:
FASES EN UN WALKTHROUGH
PLANIFICACION.-
• Similar a la
planificación de
una inspección
con la diferencia
que no es
necesario asignar
roles específicos
a excepción del
presentador(
organizador del
WALKTHROUGH)
PREPARACION
INDIVIDUAL.-
• Cada revisor
examina el
objeto revisado
en este caso no
se entrega una
lista de
comprobación.
REUNION DE
WALKTHROUGH.-
• Discusión de
alternativas de
diseño, encontrar
errores.
FORMALIDAD EN LAS REVISIONES
• Es un evento público
• Se informa por escrito de los resultados
• Todos los participantes son responsables de la
calidad de la revisión
Una revisión es formal cuando:
La ventaja de realizar revisiones formales es
que los informes que se generan sirven con
hitos para el proyecto y el hecho de ser algo
público promueve una mejor preparación por
parte de los participantes.
REVISIONES TECNICASY DE GESTION
Revisión
de la
especific
ación de
requisito
s
Revisión
del
diseño
Revisión
del
código
Revisión
de las
pruebas
Revisión
del
manual
de
usuario
Las revisiones técnicas más comunes son:
OBJETIVOS DE LAS REVISIONES DEL PROYECTO SON:
Control de la progresión del proyecto.
Evaluación de los riesgos asociados al
proyecto con relación al costo, escala de
tiempo, recursos utilizados y calidad del
producto.
Evaluación general del producto.
Para que estos sea posible es necesario:
• Que exista un plan de desarrollo bien estructurado, con hitos bien
definidos, que permita evaluar la progresión del proyecto
• Que los resultados del proyecto se encuentren bien documentados, y
hayan sido examinados por la revisión técnica
REVISIÓN DE LA ESPECIFICACIÓN DE REQUISITOS
Es muy útil para facilitar el descubrimiento
de los errores introducidos en la
especificación de requisitos en fases
tempranas del desarrollo.
ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN
ENCONTRARSE EN UNA LISTA DE COMPROBACIONES
PARA LA ESPECIFICACIÓN DE REQUISITOS:
¿Se han
especificado
todos los recursos
hardware
necesarios?
¿Se han
especificado las
interfaces
externas
necesarias?
¿Existen
contradicciones
en la
especificación de
los requisitos?
¿Se han definido
los criterios de
aceptación para
cada una de las
funciones
especificadas?
REVISIÓN DEL DISEÑO
El objetivo de estas revisiones es determinar y
evaluar el estado en el que se encuentra el
proceso de diseño, así como descubrir errores o
contradicciones (entre la especificación de
requisitos y el diseño o en las interfaces entre
módulos)
ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN
ENCONTRARSE EN UNA LISTA DE COMPROBACIONES
PARA EL DISEÑO SON LAS SIGUIENTES:
¿Hay uniformidad en el diseño?
¿Se han definido correctamente las interfaces
entre módulos?
¿Se han definido correctamente las interfaces
externas?
¿Cubre el diseño todas las funciones incluidas en la
especificación de requisitos?
¿Cumple el diseño todos los requisitos no
funcionales?
REVISIÓN DEL CÓDIGO
Su objetivo es determinar que el código se corresponde con el diseño detallado
realizado.
Algunos de los aspectos que se examinan en una revisión de código son los
siguientes:
adherencia a los estándares de codificación 20
comentarios
entradas y salidas
fórmulas
utilización de variables
estructura del programa
interfaces
REVISIÓN DE LAS PRUEBAS
Se pueden efectuar dos tipos de
revisiones de las pruebas:
• Revisión del diseño de la prueba.
• Inspección de la prueba.
EL OBJETIVO DE LA REVISIÓN DEL DISEÑO DE LA PRUEBA ES
COMPROBAR QUE EL DISEÑO REALIZADO PARA LA PRUEBA
ESTÁ DE ACUERDO CON LOS OBJETIVOS QUE SE PERSIGUEN.
SE DEBEN COMPROBAR ASPECTOS COMO:
¿Se han tenido en cuenta todos los objetivos a la hora de diseñar los casos de
prueba?
¿Se han elegido los casos de prueba más adecuados para comprobar la
consecución de dichos objetivos?
• Los objetivos de las inspecciones de las pruebas, por su parte, son:
Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el
procedimiento de prueba especificado.
Análisis de los resultados obtenidos con cada prueba.
CONTROLES ESTÁTICOS AUTOMÁTICOS
Dentro de esta categoría tenemos el análisis estático
automático y la verificación formal de programas.
La mayor parte del análisis estático automático del código lo
realizan los compiladores, que pueden detectar desde
expresiones sintácticamente incorrectas hasta
incompatibilidades de tipo y otros errores de tipo semántico.
Otras técnicas de análisis estático automático de programas
son:
• Análisis de Flujo
• Ejecución simbólica
ANÁLISIS DE FLUJO
Consiste en determinar el
comportamiento de las variables del
programa desde su inicialización hasta
que termina la ejecución del programa.
CLASIFICANDO LAS VARIABLES EN:
REFERENCIADAS
Cuando se obtiene
su valor en
memoria durante la
evaluación de una
expresión en una
sentencia.
DEFINIDAS
Cuando se obtiene
un nuevo valor para
la variable como
consecuencia de la
ejecución de una
sentencia.
NO
REFERENCIADAS
Cuando ya no se
puede determinar
el valor de la
variable a partir del
flujo del programa.
EJECUCIÓN SIMBÓLICA
La mejor forma de analizarla es descomponerla
en una estructura de árbol, donde cada hoja
representa un camino de ejecución y cada
ramificación representa un punto de decisión en
el programa.
EJEMPLO
Función en ADA que calcula la suma de los N elementos de un array
entero A:
function SUM (A: INTARRAY; N: NATURAL) return INTEGER is
S: INTEGER := 0;
I: NATURAL := 1;
Begin
while I <= N loop
S := S + A(I);
I := I + 1;
end loop;
return (S);
End SUM;
RESULTADO DE LA EJECUCIÓN SIMBÓLICA
Y EN FORMA DE ÁRBOL
VERIFICACIÓN FORMAL
Consiste en demostrar matemáticamente la
corrección de un programa con respecto a sus
especificaciones.
Es también necesario que la especificación se haya
escrito en algún lenguaje formal. Por eso no siempre
es posible realizar este tipo de verificación.
Por lo general, esta técnica sólo se utiliza para
sistemas críticos, debido al coste que conlleva.
GESTIÓN DE
CALIDAD DEL
SOFTWARE
SISTEMA DE GESTIÓN
DE CALIDAD ISO
9001:2000
GESTIÓN DE CALIDAD DEL SOFTWARE
(SQM)
• Aspecto de la función general de la gestión que
determina y aplica la política y objetivos de la
calidad del software.
• Conjunto de actividades que dirigen y
controlan una empresa en lo relativo a la
calidad.
• Deben incluir el establecimiento de la política y
los objetivos de la calidad.
Material  monster is ii emco
Material  monster is ii emco
SISTEMA DE CALIDAD
Conjunto de las actividades relativas a
planificación, control, aseguramiento y mejora de la
calidad dentro de una empresa.
Las actividades de garantía de calidad que se
adoptan en un proyecto, depende mucho de la
complejidad y tamaño de los productos de
software.
SGC debe fijar la estructura de la organización, de
las responsabilidades, de las actividades, de los
recursos y de los procedimientos para llevar a cabo
la gestión de calidad.
SISTEMA DE CALIDAD
SGC debe determinar los procedimientos y métodos
a implantar para lograr una gestión de la calidad.
Define como implementar la garantía de calidad.
• Organización: Es este el nivel en el que normalmente
se establece el sistema de calidad.
• Proyecto.
• Fase de desarrollo.
Se puede definir un sistema de calidad en 3 niveles:
SISTEMA DE CALIDAD
Establece también de que forma se
reparten las tareas y las responsabilidades
entre el personal.
Un sistema de gestión de la calidad es la
forma en la que una empresa o institución
dirige y controla todas las actividades que
están asociadas a la calidad
PARTES QUE COMPONEN EL SISTEMA DE
GESTIÓN
Estructura organizativa: departamento de
calidad o responsable de la dirección de la
empresa.
Cómo se planifica la calidad.
Los procesos de la organización.
Recursos que la organización aplica a la
calidad.
Documentación que se utiliza.
SISTEMA DE GESTIÓN DE CALIDAD
SISTEMA DE GESTIÓN DE CALIDAD
ISO 9001:2000
• Especifica los requisitos para un SGC que
pueden utilizarse para su aplicación.
• Se centra en la eficacia del SGC para asegurar
la satisfacción del cliente.
• Promueve la adopción de un enfoque
orientado a procesos para el desarrollo,
implementación y la mejora de la eficacia de
un SGC.
ISO 9001:2000
• Consta de 20 clausulas que definen que
aspectos de un sistema de calidad deben estar
presentes en una organización.
• No da detalles de cómo deben implementarse e
institucionalizarse dichos aspectos.
• Asegura que la organización documenta todos
sus procesos y procedimientos de acuerdo con
los requisitos del estándar.
MODELO DE GESTIÓN DE CALIDAD
Material  monster is ii emco
CONTROLES
DINÁMICOSY
COSTOS DE
CALIDAD
CONTROLES DINÁMICOS
Requieren la ejecución del objeto
que se está probando o de un
modelo del mismo.
PRUEBA
DEL
SOFTWARE
Es el proceso en que se ejecuta un sistema
con el objetivo de detectar fallos.
• En proyectos grandes la prueba 50 - 60% del esfuerzo.
• Es muy importante seleccionar bien las pruebas
• Seleccionar casos de prueba que incidan en programa
complejos.
• La prueba es disciplina profesional que requiere formación
• El grupo de prueba debe ser independiente del de desarrollo y
debe adoptar una actitud positiva de destrucción creativa.
CARACTERÍSTICAS
DEPURACIÓN
Es el proceso en el que se localiza el defecto que
es la causa de un fallo.
• Se determina la forma de corregirlo
• Se evalúa el efecto de la corrección
• Se lleva a cabo la corrección
PASOS
TIPOS DE
PRUEBAS
• Estándar IEEE 1012-1986
 PRUEBA MODULAR
 PRUEBA DE INTEGRACIÓN
 PRUEBA DE SISTEMA
 PRUEBA DE ACEPTACIÓN
 PRUEBA DE REGRESIÓN
PRUEBA MODULAR
• Conocida también
como prueba
unitaria o prueba
de componentes
• Consiste en la
prueba de cada
módulo aislado
del resto del
sistema
PRUEBA DE INTEGRACIÓN
 Se realiza a medida que los diferentes módulos
del sistema se integran en el mismo
 El objetivo de esta prueba es comprobar que las
interfaces entre los distintos módulos son
correctas.
COMPROBACIONES
 Compatibilidad de tipos entre los
argumentos del procedimiento o función
y los parámetros de llamada
 Corrección en la sintaxis en la
invocación de procedimientos y
funciones
 Corrección y completitud de las
especificaciones de los módulos
Material  monster is ii emco
PRUEBAS DE INTEGRACIÓN
 Integración descendente
Módulo en
pruebas
Otros
módulos
Otros
módulos
Reales,
ya probados
Otros
módulos
simulados
(stubs)
PRUEBA DE SISTEMA
 Se realiza cuando se han integrado todos los módulos
 El objetivo es comprobar que el sistema satisface los
requisitos del usuario, tanto los funcionales como los no
funcionales
PRUEBA DE ACEPTACIÓN
• Se realiza una vez que el sistema se ha implantado en
su entorno real de funcionamiento
• El objetivo es demostrar al usuario que el sistema
satisface sus necesidades
PRUEBA DE REGRESIÓN
• Tiene como objetivo comprobar que toda nueva versión de un
producto software es de no menos calidad que la versión
anterior.
RELACIÓN ENTRE PRODUCTOS DE
DESARROLLO Y NIVELES DE
PRUEBA
MÉTODOS
DE CAJA
NEGRA
El objeto que se desea probar se ve
como una caja negra. (elección de
los casos de prueba no se basa en
el conocimiento la estructura del
objeto, sino en el conocimiento de
la funcionalidad deseada.
El objeto que se desea probar se ve
como una caja negra. (elección de los
casos de prueba no se basa en el
conocimiento la estructura del objeto,
sino en el conocimiento de la
funcionalidad deseada.
MÉTODOS DE CAJA BLANCA O CAJA
TRANSPARENTE
 El objeto que se prueba se ve como una caja blanca.
(elección de los casos de prueba se basan en
conocimiento que se tenga de la estructura del
objeto, diseño detallado, diagramas de flujo de datos
y de control, código fuente).
• Los basados en
métricas de
cobertura
• Los basados en
métricas de
complejidad
LOS MÉTODOS DE
CAJA BLANCA SE
PUEDEN
CLASIFICAR, A SU
VEZ, EN DOS
GRUPOS:
• Una prueba de caja blanca exhaustiva requeriría
la generación de un caso de prueba por cada
posible camino.
• Como esto no es posible, por lo general, se
utilizan métricas que dan una indicación de la
calidad de un determinado conjunto de casos de
prueba en función del grado de cobertura del
grafo que consiguen.
Cobertura de:
• Sentencias
• Segmentos entre decisiones.
• Decisiones de ramificación
• Condiciones
• Todas las combinaciones de
condiciones
• Caminos
Las métricas más
utilizadas son:
MÉTODOS BASADOS EN MÉTRICAS DE
COMPLEJIDAD
 Complejidad
ciclomática (arcos - nodos
+ 2 * número de
componentes conexos)
 Complejidad esencial
(complejidad ciclomática -
número de subgrafos
propios de entrada y salida
única)
 Complejidad real
(número de caminos
ejecutados)
LAS MÉTRICAS DE
COMPLEJIDAD MÁS
UTILIZADAS EN LA
GENERACIÓN DE
CASOS DE PRUEBA
SON LAS DE
MACCABE:
Material  monster is ii emco
METODOLOGÍA DE PRUEBA
 La prueba tiene su propio ciclo de vida.
 Los diferentes tipos de prueba implica la
realización de un conjunto de actividades
estándar y salidas estándar
 Para cada fase del proceso de desarrollo hay
alguna actividad de prueba importante.
PLANIFICACIÓN DE LA
PRUEBA
– El objetivo del proceso de prueba
– Los objetos que hay que probar
– Las característica que se prueban y las que no
– El método de prueba a utilizar
– Los recursos que se van a emplear
– El plan de tiempos
– Los productos a generar durante las pruebas
– El reparto de las responsabilidades
Es la creación
de un plan de
pruebas que
registra:
DISEÑO DE LAS PRUEBAS
 Cómo llevar a cabo la prueba para alcanzar
los objetivos deseados
 De qué forma se van a utilizar los métodos de
prueba
 Qué objetos se van a probar en cada una de
las pruebas
 Qué criterios se van a utilizar para
determinar si el objeto pasa o no pasa la
prueba.
CONSISTE EN
DAR
INSTRUCCIONES
SOBRE:
DETERMINACIÓ
N DE LOS
CASOS DE
PRUEBA
Consiste en especificar el conjunto de casos
de prueba a utilizar en función del diseño
realizado para la prueba, especificando:
– Qué objetos se van a probar
– Qué entradas se les van a dar y
– Cuáles son las salidas esperadas
PLANIFICACIÓN DEL PROCEDIMIENTO DE
PRUEBA
Consiste en fijar un conjunto de pasos para la
ejecución de la prueba, especificando:
• La secuencia exacta de ejecución.
• Los requisitos que hay que cumplir para la ejecución.
• Las condiciones de terminación de cada uno de ellos
EJECUCIÓN DE LA PRUEBA
• Consiste en ejecutar cada caso de prueba, (paso anterior), y
registrar los incidentes o problemas encontrados durante el
sistema.
COMPARACIÓN ENTRE LOS MÉTODOS DE
CONTROL DE CALIDAD
 Hay dos maneras para mejorar la calidad de los
productos que desarrollamos:
 Detectar los defectos lo antes posible
 Cometer menos errores
 Teniendo en cuenta que el proceso de detección
puede subdividirse en las siguientes fases:
 Identificar síntomas
 Deducir localización del defecto a partir de los
síntomas
 Averiguar qué es lo que está mal
 Decidir cómo arreglar el defecto
 Arreglarlo
 Verificar que se ha resuelto el problema
COMPARACIÓN ENTRE LOS MÉTODOS DE
CONTROL DE CALIDAD
 Por otro lado, se pueden usar una serie de métricas
para poder hacer una evaluación y comparación
cuantitativa entre diferentes actividades de control de
calidad.
 En primer lugar, se deben tomar una serie de métricas
directas:
 Tamaño del objeto examinado en la actividad
 Tiempo invertido en la actividad
 Número de defectos detectados
 A partir de estas métricas básicas, se puede calcular
una serie de métricas derivadas muy interesantes
COMPARACIÓN ENTRE LOS MÉTODOS DE
CONTROL DE CALIDAD
Número de Escapes:
 Son los defectos que estaban ahí y no han sido detectados
hasta después de concluida la actividad. Para poder
calcular esto es necesario conocer la fase en la que los
defectos fueron introducidos y eliminados.
Eficacia de la tarea (Yield)
 Es el porcentaje de defectos encontrados una actividad
sobre todos los que estaban ahí al iniciarse ésta.
 La fórmula para calcularla es:
MÉTRICAS DERIVADAS
 tarea_escapestarea_eliminados
_tareaeliminados
100

Yield
MÉTRICAS DERIVADAS
Densidad de defectos encontrados
 Se mide en número de defectos por unidad de tamaño del objeto
examinado

La fórmula para calcularla es:
Eficiencia de la tarea (Tasa de Eliminación de Defectos)
Nos indica cómo de rápido se encuentra defectos en la actividad
correspondiente.
La fórmula para calcularla es:
revisiones_en_invertido_tiempo
tarea_sencontrado
TED
revisado_objeto_tamaño
tarea_sencontrado
Densidad
Rapidez de la revisión
Es una métrica que se aplica sólo a las revisiones, y
nos indica la cantidad de material cubierto por unidad
de tiempo.
La fórmula para calcularla es:
 Cabe decir que no es bueno ir demasiado rápido. Se
recomienda no sobrepasar los 300 LOC/hora.
Generalmente resulta interesante ver la correlación
de esta métrica con la Eficacia (Yield), y comprobar
cómo a medida que aumenta la rapidez decrece la
eficacia.
revisioninvertidotamaño
revisadoobjetotamaño
Rapidez
__
__

MÉTRICAS DERIVADAS
 Poder de Eliminación de Defectos (Defect
Removal Leverage)
 Nos indica el ratio de eficiencia entre dos
actividades de detección de defectos. Dicho de
otro modo, permite ver cuánto más/menos
eficiente es una actividad con respecto otra.
 La fórmula para calcularla es:
-
2_
1_
PED
tareaPED
tareaPED

MÉTRICAS DERIVADAS
150
COSTOS DE CALIDAD
Representan la diferencia entre los costos reales de un
producto o servicio y el costo reducido si no hubiera la
posibilidad de un tener un servicio por debajo de los
estándares, fallas de productos, o defectos en su
manufactura.
• Costos de prevención
• Costos de evaluación
• Costos de falla interna
• Costos de falla externa
COSTOS DE CALIDAD
151
COSTOS DE PREVENCIÓN
 Son los costos de todas las actividades
específicamente diseñados para prevenir fallas de
calidad en productos o servicios
– Revisión de nuevos productos
– Planeación de la calidad (manuales,
procedimientos, etc.)
– Evaluación de capacidad de proveedores
– Esfuerzos de mejora a través de trabajo en
equipo
– Proyectos de mejora continua
– Educación y entrenamiento en calidad… etc.
EJEMPLO:
152
 Son los costos asociados con las actividades de medir,
evaluar y auditar los productos o servicios para
asegurar su conformidad a los estándares de calidad y
requerimientos de desempeño.
COSTOS DE EVALUACIÓN
– Inspecciones con el proveedor y en recibo
– Pruebas e inspecciones en proceso y al
producto terminado
– Auditorias al producto, proceso o servicio
– Calibración de equipos de prueba y medición
– Costos de materiales de prueba
EJEMPLO:
153
COSTOS DE FALLA INTERNA
 Son los costos resultantes de productos o servicios
no conformes a los requerimientos o necesidades del
cliente, antes del embarque del producto o la
realización del servicio.
• Desperdicio (maculatura)
• Retrabajos
• Reinspección y repetición de pruebas
• Revisión de materiales no conformes
• Reducción de precio por calidad reducida
EJEMPLO
154
COSTOS DE FALLA EXTERNA
 Son los costos resultantes de productos o servicios
no conformes a los requerimientos o necesidades del
cliente, después de la entrega del producto o
durante y después de la realización del servicio.
• Proceso de quejas y reclamaciones
• Devoluciones del cliente
• Garantías
• Campañas por productos defectivos
EJEMPLO
COSTOS TOTALES DE CALIDAD
 Es la suma de los costos de prevención,
apreciación, falla interna y falla
externa
 Los sistemas contables en general no
son capaces de identificar estos costos
 Es muy difícil ir al detalle del costo de
calidad tal como un error de la
secretaria
Planificación de
la Calidad
PLANIFICACIÓN
Es el proceso en el que se indica que la
empresa puede probar que realiza sus planes
de calidad, exponiendo un plan de calidad
para cada producto.
• Los objetivos de la calidad
• Planificación de la calidad.
Incluye dos aspectos centrales:
Material  monster is ii emco
Material  monster is ii emco
Material  monster is ii emco
Material  monster is ii emco
Material  monster is ii emco
Material  monster is ii emco
PLAN DE CALIDAD
Es el documento o conjunto de
documentos:
• Que establecen los objetivos de calidad,
• La especificación de los procesos
operativos necesarios y
• La disponibilidad de los recursos
apropiados para satisfacer tales objetivos,
para la elaboración del producto que
ocupa a la organización.
PLAN SQA
Proporciona un mapa
para institucionalizar la
garantía de calidad del
software.
Sirve como plantilla para
actividades de SQA
instituidas para cada
proyecto de software.
SECCIONES
Documentación
Gestión
Revisión y Auditoría
Pruebas
Otros
SECCIONES
DOCUMENTACIÓN
Situación de la
SQA dentro de la
estructura
organizativa
Las tareas y las
actividades de
SQA y su
emplazamiento a
lo largo del
proceso del
software
Los papeles y
responsabilidade
s organizativas
relativas a la
calidad del
producto
SECCIONES
Describe cada uno de los productos de
trabajo producidos como parte del proceso
de software.
Documentos del
proyecto (plan
del proyecto)
Modelos (DERs,
jerarquías de
clases),
Documentos
técnicos
(especificaciones,
planes de
prueba)
Documentos de
usuario (archivos
de ayuda)
GESTIÓN
SECCIONES
REVISIÓN Y AUDITORIA
Identifica las revisiones y auditorías que se van
a llevar a cabo por el equipo de ingeniería del
software, el grupo de SQA y el cliente.
Proporciona una visión general del enfoque de
cada revisión y auditoría.
SECCIONES
PRUEBAS
Hace referencia al
Plan y Procedimiento
de Pruebas del
Software
Define requisitos de
mantenimiento de
registros de pruebas.
SECCIONES
• Identifica las herramientas y métodos que soportan
actividades y tareas de SQA
• Define un enfoque de gestión de contratos
• Establece métodos para reunir, salvaguardar y
mantener todos los registros
• Identifica la formación que se requiere para cumplir
las necesidades del plan
• Define métodos para identificar, evaluar, supervisar
y controlar riesgos.

Mais conteúdo relacionado

Mais procurados

Evaluación de herramientas de software
Evaluación de herramientas de softwareEvaluación de herramientas de software
Evaluación de herramientas de softwareJesús Tramullas
 
Metodologia Thales
Metodologia ThalesMetodologia Thales
Metodologia Thalesyaquelin
 
Repositorios De Objetos De Aprendizaje
Repositorios De Objetos De AprendizajeRepositorios De Objetos De Aprendizaje
Repositorios De Objetos De AprendizajeEduardo Garay
 
EVEA Entornos virtuales de Enseñanza Aprendizaje
EVEA Entornos virtuales de Enseñanza Aprendizaje EVEA Entornos virtuales de Enseñanza Aprendizaje
EVEA Entornos virtuales de Enseñanza Aprendizaje Linda Martinez
 
Importancia de los objetos de aprendizaje en la educacion virtual
Importancia de los objetos de aprendizaje en la educacion virtualImportancia de los objetos de aprendizaje en la educacion virtual
Importancia de los objetos de aprendizaje en la educacion virtualMARCO OSCAR NIETO MESA
 
Presentacion de Moodle
Presentacion de MoodlePresentacion de Moodle
Presentacion de Moodlejveizaga
 
Repositorios de ovas
Repositorios de ovasRepositorios de ovas
Repositorios de ovasJabier Gomez
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativoLu Martinez
 
Herramientas Aprendizaje EVA
Herramientas Aprendizaje EVAHerramientas Aprendizaje EVA
Herramientas Aprendizaje EVAPrograma EVA
 
PRESENTACIÓN DE SOCRATIVE
PRESENTACIÓN DE SOCRATIVEPRESENTACIÓN DE SOCRATIVE
PRESENTACIÓN DE SOCRATIVEFcoJesusRiveraC
 
Recursos Educativos Digitales
Recursos Educativos DigitalesRecursos Educativos Digitales
Recursos Educativos DigitalesEquipoPereira
 
Silabo gestión y administración web
Silabo   gestión y administración webSilabo   gestión y administración web
Silabo gestión y administración webEdwin Mamani López
 
Lorena mejia cadavid_cuadro comparativo. modelos de calidad.
Lorena mejia cadavid_cuadro comparativo. modelos de calidad.Lorena mejia cadavid_cuadro comparativo. modelos de calidad.
Lorena mejia cadavid_cuadro comparativo. modelos de calidad.LorenaIsabelMC
 
Presentación Evaluación de los Aprendizajes para Entornos Virtuales
Presentación Evaluación de los Aprendizajes para Entornos VirtualesPresentación Evaluación de los Aprendizajes para Entornos Virtuales
Presentación Evaluación de los Aprendizajes para Entornos VirtualesNombre Apellidos
 

Mais procurados (20)

Evaluación de herramientas de software
Evaluación de herramientas de softwareEvaluación de herramientas de software
Evaluación de herramientas de software
 
Metodologia Thales
Metodologia ThalesMetodologia Thales
Metodologia Thales
 
Que Es Multimedia 1
Que Es Multimedia  1Que Es Multimedia  1
Que Es Multimedia 1
 
Ámbitos de la evaluación.
Ámbitos de la evaluación.Ámbitos de la evaluación.
Ámbitos de la evaluación.
 
Repositorios De Objetos De Aprendizaje
Repositorios De Objetos De AprendizajeRepositorios De Objetos De Aprendizaje
Repositorios De Objetos De Aprendizaje
 
EVEA Entornos virtuales de Enseñanza Aprendizaje
EVEA Entornos virtuales de Enseñanza Aprendizaje EVEA Entornos virtuales de Enseñanza Aprendizaje
EVEA Entornos virtuales de Enseñanza Aprendizaje
 
Importancia de los objetos de aprendizaje en la educacion virtual
Importancia de los objetos de aprendizaje en la educacion virtualImportancia de los objetos de aprendizaje en la educacion virtual
Importancia de los objetos de aprendizaje en la educacion virtual
 
¿Qué es un LMS?
¿Qué es un LMS?¿Qué es un LMS?
¿Qué es un LMS?
 
Presentacion de Moodle
Presentacion de MoodlePresentacion de Moodle
Presentacion de Moodle
 
Repositorios de ovas
Repositorios de ovasRepositorios de ovas
Repositorios de ovas
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativo
 
Modelo furps
Modelo furpsModelo furps
Modelo furps
 
Herramientas Aprendizaje EVA
Herramientas Aprendizaje EVAHerramientas Aprendizaje EVA
Herramientas Aprendizaje EVA
 
PRESENTACIÓN DE SOCRATIVE
PRESENTACIÓN DE SOCRATIVEPRESENTACIÓN DE SOCRATIVE
PRESENTACIÓN DE SOCRATIVE
 
Recursos Educativos Digitales
Recursos Educativos DigitalesRecursos Educativos Digitales
Recursos Educativos Digitales
 
Silabo gestión y administración web
Silabo   gestión y administración webSilabo   gestión y administración web
Silabo gestión y administración web
 
Lorena mejia cadavid_cuadro comparativo. modelos de calidad.
Lorena mejia cadavid_cuadro comparativo. modelos de calidad.Lorena mejia cadavid_cuadro comparativo. modelos de calidad.
Lorena mejia cadavid_cuadro comparativo. modelos de calidad.
 
Lenguaje multimedia
Lenguaje multimediaLenguaje multimedia
Lenguaje multimedia
 
Presentación Evaluación de los Aprendizajes para Entornos Virtuales
Presentación Evaluación de los Aprendizajes para Entornos VirtualesPresentación Evaluación de los Aprendizajes para Entornos Virtuales
Presentación Evaluación de los Aprendizajes para Entornos Virtuales
 
Guion didactico
Guion didacticoGuion didactico
Guion didactico
 

Destaque

Calidad general.
Calidad general.Calidad general.
Calidad general.Liz Cruz
 
4. introduccion a los modelos de calidad
4. introduccion a los modelos de calidad4. introduccion a los modelos de calidad
4. introduccion a los modelos de calidadJuan Pablo Carvallo
 
Calidad del Software en Proyectos Open Source
Calidad del Software en Proyectos Open SourceCalidad del Software en Proyectos Open Source
Calidad del Software en Proyectos Open SourceMarcos Blanco Galán
 
Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3Professional Testing
 
Calderas acuotubular guias
Calderas acuotubular guiasCalderas acuotubular guias
Calderas acuotubular guiasUNEFM
 
Fundamentos de Calidad del Software - Modelos y Estándares
Fundamentos de Calidad del Software - Modelos y EstándaresFundamentos de Calidad del Software - Modelos y Estándares
Fundamentos de Calidad del Software - Modelos y EstándaresLuis Eduardo Pelaez Valencia
 
Consideraciones para el Desarrollo de Aplicaciones Móviles
Consideraciones para el Desarrollo de Aplicaciones MóvilesConsideraciones para el Desarrollo de Aplicaciones Móviles
Consideraciones para el Desarrollo de Aplicaciones MóvilesSorey García
 

Destaque (12)

Calidad general.
Calidad general.Calidad general.
Calidad general.
 
4. introduccion a los modelos de calidad
4. introduccion a los modelos de calidad4. introduccion a los modelos de calidad
4. introduccion a los modelos de calidad
 
Calidad del Software en Proyectos Open Source
Calidad del Software en Proyectos Open SourceCalidad del Software en Proyectos Open Source
Calidad del Software en Proyectos Open Source
 
Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3Fundamentos de Pruebas de Software - Capítulo 3
Fundamentos de Pruebas de Software - Capítulo 3
 
técnicas estáticas
técnicas estáticastécnicas estáticas
técnicas estáticas
 
Calderas acuotubular guias
Calderas acuotubular guiasCalderas acuotubular guias
Calderas acuotubular guias
 
tecnicas de revisión del software
tecnicas de revisión del softwaretecnicas de revisión del software
tecnicas de revisión del software
 
Métodos Formales
Métodos FormalesMétodos Formales
Métodos Formales
 
Fundamentos de Calidad del Software - Modelos y Estándares
Fundamentos de Calidad del Software - Modelos y EstándaresFundamentos de Calidad del Software - Modelos y Estándares
Fundamentos de Calidad del Software - Modelos y Estándares
 
Verificación y Validación del Diseño
Verificación y Validación del DiseñoVerificación y Validación del Diseño
Verificación y Validación del Diseño
 
Consideraciones para el Desarrollo de Aplicaciones Móviles
Consideraciones para el Desarrollo de Aplicaciones MóvilesConsideraciones para el Desarrollo de Aplicaciones Móviles
Consideraciones para el Desarrollo de Aplicaciones Móviles
 
Flores proyecto
Flores proyectoFlores proyecto
Flores proyecto
 

Semelhante a Material monster is ii emco

TAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptx
TAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptxTAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptx
TAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptxJACKSSONYAMILMONTOYA
 
Calidad
CalidadCalidad
Calidadgmjuan
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de softwareingsistemas1
 
Gestión de la Calidad
Gestión de la CalidadGestión de la Calidad
Gestión de la CalidadMarcel Aponte
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del softwareDarleneperalta
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del softwarenaviwz
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del softwareEmily Moncada
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del softwareflaco_mendez
 
Actividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software natalyActividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software natalynataly duque
 
Trabajo investigacion (jeiner gonzalez.b)
Trabajo investigacion (jeiner gonzalez.b)Trabajo investigacion (jeiner gonzalez.b)
Trabajo investigacion (jeiner gonzalez.b)Jeiner Gonzalez Blanco
 
Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)Jeiner Gonzalez Blanco
 

Semelhante a Material monster is ii emco (20)

TAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptx
TAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptxTAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptx
TAREA 1_JACKSSON YAMIL MONTOYA ASPRILLA.pptx
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
Calidad
CalidadCalidad
Calidad
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
CALIDAD DE SOFTWARE
CALIDAD DE SOFTWARECALIDAD DE SOFTWARE
CALIDAD DE SOFTWARE
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
Gestión de la Calidad
Gestión de la CalidadGestión de la Calidad
Gestión de la Calidad
 
Gestion De Calidad Cap 26
Gestion De Calidad Cap 26Gestion De Calidad Cap 26
Gestion De Calidad Cap 26
 
Como se mide la Calidad de software
Como se mide la Calidad de softwareComo se mide la Calidad de software
Como se mide la Calidad de software
 
Calidad del Software
Calidad del SoftwareCalidad del Software
Calidad del Software
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del software
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
Unidad # 10 calidad del software
Unidad # 10 calidad del softwareUnidad # 10 calidad del software
Unidad # 10 calidad del software
 
Calidad del software
Calidad del softwareCalidad del software
Calidad del software
 
Gestión De Calidad
Gestión De CalidadGestión De Calidad
Gestión De Calidad
 
GestióN De Calidad
GestióN De CalidadGestióN De Calidad
GestióN De Calidad
 
Actividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software natalyActividad 2-aseguramiento-de-la-calidad-del-software nataly
Actividad 2-aseguramiento-de-la-calidad-del-software nataly
 
Trabajo investigacion (jeiner gonzalez.b)
Trabajo investigacion (jeiner gonzalez.b)Trabajo investigacion (jeiner gonzalez.b)
Trabajo investigacion (jeiner gonzalez.b)
 
Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)Mule investigation (jeiner gonzalez.b)
Mule investigation (jeiner gonzalez.b)
 

Material monster is ii emco

  • 1. UNIVERSIDAD DE LAS FUERZAS ARMADAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN CARRERA DE INGENIERÍA EN SISTEMAS E INFORMÁTICA Ing. Mauricio Campaña Ortega MsC. CCNA. CCIA. INGENIERÍA DE SOFTWARE II
  • 2. CALIDAD DEL SOFTWARE  La integridad de un producto de software depende de la acción combinada de tres tipos de disciplinas: Desarrollo Gestión Control  Dentro de las disciplinas de control se encuentra la Garantía de Calidad del Software, cuyo objetivo es asegurar un cierto nivel de calidad en el producto de software desarrollado.
  • 3. OBJETIVOS Al finalizar esta unidad estará en capacidad de: Comprender el significado de la terminología utilizada. Ser capaz de caracterizar la calidad de un producto de software en términos de un modelo de calidad. Comprender en que consiste la Garantía de Calidad en un proyecto de desarrollo de software. Conocer las consideraciones que se debe tener en cuenta a la hora de construir un Sistema de Garantía de Calidad. Ser capaz de participar en una revisión o auditoría. Ser consciente de las medidas que puede tomar para construir productos de mayor calidad. Conocer los principales métodos de evaluación del proceso de desarrollo de software. Conocer los principales modelos para la mejora del proceso de desarrollo de software.
  • 5. CALIDAD DE PROCESO Conjunto de actividades, métodos, prácticas y transformaciones que la gente usa para desarrollar y mantener software y los productos de trabajo asociados (planes de proyecto, diseño de documentos, código, pruebas y manuales de usuario)” “Proceso o conjunto de procesos usados por una organización o proyecto, para planificar, gestionar, ejecutar, monitorizar, controlar y mejorar sus actividades software relacionadas”
  • 6. CALIDAD DEL PRODUCTO DE SOFTWARE La calidad del producto de software se diferencia de la calidad de otros productos de fabricación industrial, ya que el software tiene ciertas características especiales:  El software es un producto mental, no restringido por las leyes de la física o por los límites de los proceso de fabricación. Es algo abstracto y su calidad también lo es.  Se desarrolla, no se fabrica. El coste esta fundamentalmente en el proceso de diseño, no en la producción. Y los errores se introducen también en el diseño no en la producción.  El software no se deteriora con el tiempo. No es susceptible a los efectos del entorno, y su curva de fallos es muy diferente de la del hardware. Todos los problemas que surjan durante el mantenimiento estaban allí desde el principio y afectan a todas las copias del mismo; no se generan nuevos errores.  Es artesanal en gran medida. El software en su mayoría se construye a medida, en vez de ser construido ensamblando componentes existentes y ya probados, lo que dificulta aún más el control de su calidad. Aunque se ha escrito mucho sobre reutilización de software, hasta ahora se han conseguido pocos éxitos tangibles.
  • 7. CALIDAD DEL PRODUCTO DE SOFTWARE  El mantenimiento del software es mucho más complejo que el mantenimiento del hardware. Cuando un componente de hardware se deteriora se sustituye por una pieza de repuesto, pero cada fallo en el software implica un error en el diseño o en el proceso mediante el cual se tradujo el diseño en código máquina ejecutable.  Es engañosamente fácil realizar cambios sobre un producto software, pero los efectos de estos cambios se pueden propagar de forma explosiva e incontrolada.  Como disciplina, el desarrollo de software es aún muy joven, por lo que las técnicas de las que se disponen aún no son totalmente efectivas o no están totalmente calibradas.  El software con errores no se rechaza. Se asume que es inevitable que el software presenta errores.
  • 8. PROBLEMAS DE LA CALIDAD DEL PRODUCTO DE SOFTWARE Los principales problemas a los que se enfrenta al hablar de la calidad del producto de software son:  La definición misma de la calidad del software: ¿Es realmente posible encontrar un conjunto de propiedades en un producto software que de una indicación de calidad? Para dar respuesta a esta pregunta aparecen los Modelos de Calidad.  Modelos de Calidad: La calidad de define de forma jerárquica. Resuelven la complejidad mediante la descomposición. La calidad es un concepto que se deriva de un conjunto de subconceptos.  La comprobación de la calidad del software: ¿Cómo medir el grado de calidad de un producto de software? Aparece el concepto de Control de Calidad.  Control de Calidad: Actividades para evaluar la calidad de los productos desarrollados.
  • 9. PROBLEMAS DE LA CALIDAD DEL PRODUCTO DE SOFTWARE  La mejora de la Calidad del Software: Cómo utilizar la información disponible acerca de la calidad del producto de software para mejorar su calidad a lo largo del ciclo de vida? No solo es posible “medir” la calidad, sino también “construir” la calidad durante el proceso de desarrollo del producto.Aparecen dos conceptos importantes: Gestión de Calidad: Determinación y Aplicación de las políticas de calidad de la empresa (objetivos y directrices generales) Garantía o Aseguramiento de Calidad: Conjunto de Actividades planificadas y sistemáticas necesaria para proporcionar confianza en que el producto software satisfacerla los requisitos dados de calidad.
  • 10. DEFINICIÓN DE CALIDAD  Calidad es “Conformidad con los requisitos y confianza en el funcionamiento” Deming.  “Adecuación para su uso”. Jurán  “Hacerlo bien a la primera” o sea poner más énfasis en la prevención. Crosby Definiciones de calidad extraídos de estándares internacionales  “La calidad es la suma de todos aspectos o características de un producto o servicio que influye en su capacidad para satisfacer las necesidades, expresadas o implícitas”. ISO 8402.  “Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas”. IEE 729-83.  “Capacidad del producto software para satisfacer los requisitos establecidos”. DoD 2168.
  • 11. DEFINICIÓN DE CALIDAD  La calidad es algo relativo, depende de los requisitos o necesidades que se desea satisfacer.  En un producto de software se tendrán tres visiones de la calidad: Necesaria o requerida: La que quiere el cliente. Programada o Especificada: La que se ha especificado explícitamente y se intenta conseguir. Realizada: la que se ha conseguido.  A la intersección entre la Calidad Requerida y la Calidad Realizada se llama Calidad Percibida y es la única que el cliente valora. Toda aquella calidad que se realiza pero no se necesita es un gasto inútil de tiempo y dinero.
  • 12. TERMINOLOGÍA BÁSICA  ERROR: como una incorrección cometida por un humano durante el proceso de desarrollo.  DEFECTO: es la consecuencia de un error. Así por ejemplo , si una función tiene el objetivo de sumar 10 al valor que recibe como entrada, y en realidad está sumando 20, eso es un defecto debido al error del programador que escribió 20 en lugar de 10. también se llama DEFECTO a una desviación en el valor esperado para una cierta característica. Los defectos no tienen porque afectar al funcionamiento del objeto defectuoso. Un programa poco mantenible, por ejemplo, puede ser totalmente correcto.  FALLO (failure): la manifestación de un defecto en el software. Por ejemplo cuando a la función anterior se le da como entrada el valor 10 y la salida que se obtiene es 30 en lugar de 20 que es el valor esperado.
  • 13. TERMINOLOGÍA BÁSICA FALLAS (fault): son los defectos que aún no han sido detectados y eliminados cuando comienzan las pruebas. Algunas de estas fallas se convierten en fallos si se detectan durante las pruebas o el uso del sistema. INCIDENTE o INCIDENCIA: a una situación en la que se produce y se informa de un comportamiento no esperado en el sistema. Una incidencia puede venir provocada por un defecto o no.
  • 14. Estructura de los modelos de calidad En los modelos de calidad, la calidad se define de forma jerárquico. Es un concepto que se deriva de un conjunto de subconjuntos cada uno de los cuales se va a evaluar a través de un conjunto de indicadores o métricas. Tienen una estructura de tres niveles: Representan la calidad desde el punto de vista del usuario, son las características que componen la calidad, también se los conoce como Atributos de Calidad Externos. Cada uno de los factores se descompone en un conjunto de CRITERIOS de calidad, representan una visión de la calidad desde el punto de vista del productos del software, conocidos como Atributos de Calidad Internos. Calidad del Software Factores de Calidad Criterios de Calidad del Producto Métricas del Producto Son medidas cuantitativas de ciertas características del producto que cuando están presentes dan una indicación del grado en que dicho producto posee un determinado atributo de calidad.
  • 15. Modelos de Calidad  La ventaja de los Modelos de Calidad, está en que la misma se convierte en algo concreto, que se puede definir, que se puede medir y sobre todo se puede planificar.  Una desventaja es que aun no se ha demostrado su validez absoluta, las conexiones que se establecen entre características, atributos y métricas se derivan de la experiencia y de ahí que existan múltiples modelos. MC CALL MÉTODO GQM BOEHM ISO 9126 FURPS
  • 16.  Organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad del producto:  Operación del Producto.  Revisión del Producto.  Transición del Producto  El Modelo McCall se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente forma: ATRIBUTOS DEL MODELO DE Mc CALL PUNTO DEVISTA FACTORES Operación del Producto  Facilidad de Uso  Integridad  Corrección  Fiabilidad  Eficiencia Revisión del Producto  Facilidad de Mantenimiento  Facilidad de Prueba  Flexibilidad Transición del Producto  Facilidad de reutilización  Interoperabilidad  Portabilidad
  • 17. FACILIDAD DE MANTENIMIENTO (¿Puedo arreglarlo?) FACILIDAD DE PRUEBA (¿Puedo probarlo?) FLEXIBILIDAD (¿Puedo modificarlo?) ATRIBUTOS DEL MODELO DE Mc CALL OPERACIÓN INTEROPERABILIDAD (¿Puedo comunicarlo con otro sistema?) PORTABILIDAD (¿Podré utilizarlo en otra máquina?) REUSABILIDAD (¿Podré utilizar parte del software?) CORRECCIÓN (¿Hace el software lo que yo quiero?) FIABILIDAD (¿Lo hace de forma exacta todo el tiempo?) EFICIENCIA (¿Se ejecutará sobre mi hardware lo mejor posible?) INTEGRIDAD (¿Es seguro?) FACILIDAD DE USO (¿Puedo ejecutarlo?)
  • 18. Los factores de McCall desde el punto de vista de Operación del Producto se definen de la siguiente forma: FACTORES DE Mc CALL • El coste y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e interpretar la salida del mismo Facilidad de Uso • Hasta que punto se controlan los accesos ilegales a programas o datos. Un programa que permite el acceso de personas no autorizadas a ciertos datos es poco íntegro.Integridad • Hasta que punto un programa cumple sus especificaciones y satisface los objetivos del usuario. Ejemplo: si un programa debe ser capaz de sumar dos números y en lugar de eso los multiplica. Es quizás el factor más importante, aunque puede no servir de nada sin los demás factores Corrección • Hasta que punto se puede confiar en el funcionamiento sin errores del programa. Por ejemplo, si el programa anterior suma dos números, pero en un 25 % de los casos el resultado que da no es correcto, es poco fiable. Fiabilidad • Cantidad de código y de recursos informáticos (CPU, memoria) que precisa un programa para desempeñar su función. Un programa que suma dos números y necesita 2 MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta es poco eficiente. Eficiencia
  • 19. FACTORES DE Mc CALL • El Coste de localizar y corregir defectos en un programa que aparecen durante su funcionamiento Facilidad de Mantenimiento • El coste de probar un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulación completa de un sistema para poder probar que funciona bien, en un programa difícil de probar. Facilidad de Prueba • El coste de modificación del producto cuando cambian sus especificaciones.Flexibilidad Los factores de McCall desde el punto de vista de Revisión del Producto se definen de la siguiente forma:
  • 20. FACTORES DE Mc CALL • Hasta que punto se puede transferir un módulo o programa del presente sistema a otra aplicación, y con que esfuerzo. Facilidad de Reutilización • El coste y esfuerzo necesario para hacer que el software pueda operar conjuntamente con otros sistemas o aplicaciones de software externos. Interoperabilidad • Conocido como transportabilidad. El coste de transportar o migrar un producto de una configuración hardware o entorno operativo a otro. Portabilidad Los factores de McCall desde el punto de vista de Transición del Producto se definen de la siguiente forma:
  • 21.  La Relación Factores – Criterio desde el Punto de Vista de Operación del Producto FACTORES – CRITERIOS MODELO DE Mc CALL PUNTO DEVISTA FACTORES Facilidad de Uso  Facilidad de Operación  Facilidad de Comunicación  Facilidad de Aprendizaje Integridad  Control de accesos  Facilidad de auditoría Corrección  Completitud  Consistencia  Trazabilidad Fiabilidad  Precisión  Consistencia  Tolerancia a fallos  Modularidad  Simplicidad Eficiencia  Eficiencia en Ejecución  Eficiencia en almacenamiento
  • 22. CRITERIOS DE Mc CALL PARA EL FACTOR FACILIDAD DE USO • Atributos del software que determinan la facilidad de operación del software Facilidad de Operación • Atributos del software que proporcionan al usuario entradas y salidas fácilmente asimilables Facilidad de Comunicación • Atributos del software que facilitan la familiarización inicial del usuario con el software y la transición desde el modo actual de operación. Facilidad de Aprendizaje Los criterios de McCall para el factor FACILIDAD DE USO se descomponen en:
  • 23. CRITERIOS DE Mc CALL PARA EL FACTOR INTEGRIDAD • Atributos del software que proporcionan control de acceso al software y los datos que maneja Control de Accesos • Atributos del software que facilitan el registro y la auditoría de los accesos al software. Facilidad de Auditoría Los criterios de McCall para el factor INTEGRIDAD se descomponen en:
  • 24. CRITERIOS DE Mc CALL PARA EL FACTOR CORRECCIÓN • Atributos del software que proporcionan la implementación completa de todas las funciones requeridas.Completitud • Atributos del software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadas.Consistencia • Conocido como Rastreabilidad. Atributos del software que proporcionan una traza desde los requisitos a la implementación con respecto a un entorno operativo concreto. Trazabilidad Los criterios de McCall para el factor CORRECCIÓN se descomponen en:
  • 25. • Atributos del software que proporcionan el grado de precisión requerido en los cálculos y los resultados.Precisión • Atributos de software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadasConsistencia • Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. Tolerancia a fallos • Atributos del software que proporcionan una estructura de módulos altamente independientes.Modularidad • Atributos del software que posibilitan la implementación de funciones de la forma más compresible posibleSimplificidad CRITERIOS DE Mc CALL PARA EL FACTOR FIABILIDAD Los criterios de McCall para el factor FIABILIDAD se descomponen en:
  • 26. • Atributos del software que minimizan el tiempo de procesamiento. Eficiencia en Ejecución • Atributos del software que minimizan el espacio de almacenamiento necesario. Eficiencia en Almacenamiento Los criterios de McCall para el factor EFICIENCIA se descomponen en: CRITERIOS DE Mc CALL PARA EL FACTOR EFICIENCIA
  • 27.  La Relación Factores – Criterio desde el Punto de Vista de Revisión del Producto FACTORES – CRITERIOS MODELO DE Mc CALL PUNTO DEVISTA FACTORES Facilidad de Mantenimiento  Modularidad  Simplicidad  Consistencia  Concisión  Auto descripción Facilidad de Prueba  Modularidad  Simplicidad  Auto descripción  Instrumentación Flexibilidad  Auto descripción  Capacidad de expansión  Generalidad  Modularidad
  • 28. • Atributos del software que proporcionan una estructura de módulos altamente independientes.Modularidad • Atributos del software que posibilitan la implementación de funciones de la forma más compresible posibleSimplicidad • Atributos de software que proporcionan uniformidad en las técnicas y notaciones de diseño e implementación utilizadas.Consistencia • Atributos del software que posibilitan la implementación de una función con la menor cantidad de código posible.Concisión • Atributos del software que proporcionan explicaciones sobre la implementación de las funciones. Auto descripción CRITERIOS DE Mc CALL PARA EL FACTOR FACILIDAD DE MANTENIMIENTO Los criterios de McCall para el factor FACILIDAD DE MANTENIMEINTO se descomponen en:
  • 29. CRITERIOS DE Mc CALL PARA EL FACTOR FACILIDAD DE PRUEBA • Atributos del software que proporcionan una estructura de módulos altamente independientes.Modularidad • Atributos del software que posibilitan la implementación de funciones de la forma más compresible posibleSimplicidad • Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.Auto descripción • Atributos del software que posibilitan la observación del comportamiento del software durante su ejecución (para facilitar las mediciones del uso o la identificación de errores ) Instrumentación Los criterios de McCall para el factor FACILIDAD DE PRUEBA se descomponen en:
  • 30. CRITERIOS DE Mc CALL PARA EL FACTOR FLEXIBILIDAD • Atributos del software que proporcionan explicaciones sobre la implementación de las funciones. Auto descripción • Atributos del software que posibilitan la expansión del software en cuanto a capacidades funcionales y datos. Capacidad de expansión • Atributos del software que posibilitan amplitud a las funciones implementadas.Generalidad • Atributos del software que proporcionan una estructura de módulos altamente independientes..Modularidad Los criterios de McCall para el factor FLEXIBILIDAD se descomponen en:
  • 31.  La Relación Factores – Criterio desde el Punto de Vista de Transición del Producto FACTORES – CRITERIOS MODELO DE Mc CALL PUNTO DEVISTA FACTORES Facilidad de Reutilización  Auto descripción  Generalidad  Modularidad  Independencia entre sistema y software Interoperabilidad  Modularidad  Compatibilidad de Comunicaciones  Compatibilidad de datos Portabilidad  Auto descripción  Modularidad  Independencia entre sistema y software  Independencia del hardware
  • 32. • Atributos del software que proporcionan explicaciones sobre la implementación de las funciones.Auto descripción • Atributos de software que proporcionan amplitud a las funciones implementadas Generalidad • Atributos del software que proporcionan una estructura de módulos altamente independientes. Modularidad • Atributos del software que determinan la independencia del entorno operativo. Independencia entre sistema y software • Atributos del software que determinan su independencia del hardware. Independencia del hardware CRITERIOS DE Mc CALL PARA EL FACTOR REUSABILIDAD Los criterios de McCall para el factor REUSABILIDAD se descomponen en:
  • 33. CRITERIOS DE Mc CALL PARA EL FACTOR INTEROPRABILIDAD • Atributos del software que proporcionan una estructura de módulos altamente independientes.Modularidad • Atributos del software que posibilitan el uso de protocolos de comunicación e interfaces estándar. Compatibilidad de Comunicaciones • Atributos del software que proporcionan representaciones de datos estándar. Compatibilidad de Datos Los criterios de McCall para el factor INTEROPERABILIDAD se descomponen en:
  • 34. CRITERIOS DE Mc CALL PARA EL FACTOR PORTABILIDAD • Atributos del software que proporcionan explicaciones sobre la implementación de las funciones. Auto descripción • Atributos del software que proporcionan una estructura de módulos altamente independientes.Modularidad • Atributos del software que determinan la independencia del sistema operativo. Independencia entre sistema y software • Atributos del software que determinan su independencia del hardware. Independencia del hardware Los criterios de McCall para el factor PORTABILIDAD se descomponen en:
  • 36. FURPS Los factores de calidad FURPS provienen de trabajos anteriores, definiendo los siguientes atributos para cada uno de los cinco factores principales: • Funcionalidad • Facilidad de uso • Fiabilidad • Rendimiento • capacidad de soporte.
  • 37. ISO/IEC 9126:TECNOLOGÍAS DE LA INFORMACIÓN CALIDAD DE LOS PRODUCTOS SOFTWARE. • Modelo de CalidadParte 1 • Métricas ExternasParte 2 • Métricas InternasParte 3 • Métricas de Calidad en UsoParte 4
  • 38. calidad externa e interna funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad adecuación exactitud interoperabilidad seguridad de acceso cumplimiento de la funcionalidad madurez tolerancia a fallos capacidad de recuperación cumplimiento de la fiabilidad capacidad para ser entendido capacidad para ser aprendido capacidad para ser operado capacidad de atracción cumplimiento de la usabilidad comportamiento temporal utilización de recursos cumplimiento de la eficiencia capacidad para ser analizado capacidad para ser cambiado estabilidad capacidad para ser probado cumplimiento de la mantenibilidad adaptabilidad instalabilidad coexistencia capacidad para ser reemplazado cumplimiento de la portabilidad MODELO DE CALIDAD PARA CALIDAD INTERNAY EXTERNA
  • 39. MODELO DE CALIDAD PARA CALIDAD EN USO
  • 41. Son los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organización. CMM se enfoca a nivel organizacional TSP se enfoca a un proceso de grupos de trabajo PSP se enfoca a nivel personal
  • 43. DEFINICIÓN Es un ciclo de vida del proceso de software que se caracteriza por: Ser definido, conciso Altamente prescriptivo Rápido y barato
  • 44. JUSTIFICACIÓN DEL PSP Los ingenieros de software rara vez basan su trabajo en prácticas y metodologías establecidas y son prácticamente escépticos a cambiar sus hábitos de trabajo. Los ingenieros están en un círculo vicioso, "sólo creen en lo que han probado y no prueban otras metodologías", por esta razón para poder implantar PSP, se tuvo que obligarlos y se tuvieron buenos resultados.
  • 45. PASOS PARA IMPLANTACION PSP Lo que sigue es optimizar la interacción entre equipos y aquí entraría Team Software Process, el TSP extiende y refina los métodos de CMM y PSP sobre desarrollo y mantenimiento de equipos, y llegar a lo que se le llama un equipo auto dirigido. Requiere un fuerte soporte de administración, es necesario que los administradores entiendan el PSP, saber como apoyarlos y como monitorear sus avances, sin un adecuado monitoreo los ingenieros caerán otra vez en los malos hábitos. La Capacitación es sobre grupos o equipos, y serán grupos que así lo han sido y seguirán siendo. Los ingenieros deben ser entrenados por un instructor calificado de PSP.
  • 46. CICLO DEVIDA PSP 7 niveles del PSP PSP3 Proceso Personal Cíclico PSP2 y PSP2.1 Manejo Personal de calidad PSP1 y PSP1.1 Proceso Personal de Planeación PSP0 y PSP0.1 Línea Base del PSP
  • 47. • Identificar actividades: definición, secuencia • Bases mejoras: planeación, evaluación, resultados • Documentar proceso Formas de: • Actividades (Scripts) • Tiempos (Logs Time) • Defectos (Defect Logs) • Resumir planes, resultados (Proyect plan summary) PSP 0 • Registrar tamaño del producto y hacer un histórico: • Líneas de código (LDC) • Puntos de función (PF) • Estandarización de la codificación • Registrar problemas y mejoras de propuestas PSP 0.1 • Mejora la planeación: • Con la estimación de recursos • Introducción de calendarizar, plasmar el plan con números, un presupuesto PSP 1
  • 48. • Mejora la ejecución: • Detección temprana de defectos, en base a la predicción de estos. • Revisiones de diseño • Revisiones de código • Uso de checklists (Listas de verificación PSP 2 • Mejora el diseño: • Al hacer uso de formas detalladas de diseño (formas C76, C77) PSP 2.1 • Mejora el ciclo, mejora del proceso en términos de hacerlo repetible (cíclico): • Para aplicación a programas de mayor tamaño • Registro del seguimiento de asuntos importantes • Análisis del resumen de la planeación, tiempos, tamaños y defectos por cada ciclo. PSP 3
  • 50. CICLO DE VIDA PSP FASE PLANEACIÓN (PLAN DE PROYECTO) INPUT Descripción del problema, resumen del proyecto, resumen cíclico, tamaño estimado, tiempo estimado, formas de planeación. ACTIVIDAD Requerimientos, tamaño estimado, desarrollo estrategia, estimados de recursos, planificación y programas de tareas, estimación de defectos. OUTPUT Diseño conceptual, resumen plan, resumen del ciclo, patrones estimados de tamaño y planeación de tareas, programas de patrones de planeación, registro de tiempos.
  • 51. CICLO DEVIDA PSP FASE DISEÑO DE PRODUCTO INPUT Tipificación requerimientos, diseño conceptual, patrones de estimaciones de tamaño, resumen parte cíclico, seguimiento. ACTIVIDAD Especificaciones externas, diseño modular, prototipos, estrategia de desarrollo y documentación, seguimiento. OUTPUT Diseño de programa, escenarios operacionales, especificación de funciones y lógica, resumen cíclico, seguimiento y estrategias de pruebas y ciclo.
  • 52. CICLO DEVIDA PSP FASE REVISIÓN O VALIDACIÓN DEL DISEÑO INPUT Programa de diseño, escenarios operacionales, especificación de funciones y lógica, resumen cíclico, seguimiento y estrategia de pruebas y ciclo. ACTIVIDAD Diseño de apariencia, verificación de máquinas y lógica, consistencia del diseño, rehúso, estrategia de verificación, detectar errores. OUTPUT Diseño de alto nivel, registro de seguimiento, tiempos y defectos.
  • 53. CICLO DEVIDA PSP FASE DESARROLLO O IMPLEMENTACIÓN INPUT Diseño de alto nivel, registro de seguimiento, tiempos y defectos, ciclo de desarrollo, estrategia de pruebas, patrones de operación y función. ACTIVIDAD Diseño de módulos, revisión de diseño, código, revisión de código, compilación, pruebas, aseguramiento de calidad y del ciclo. OUTPUT Módulos de SW, patrón de diseño, lista de verificación de código y diseño, resumen del ciclo, patrón de reporte de pruebas, registro de tiempo, defectos y seguimiento.
  • 54. CICLO DEVIDA PSP FASE POSMORTEM, EVALUACIÓN CICLO INPUT Definición de problema y requerimientos, plan de proyecto, producto de software, patrón de diseño, lista de verificación, diseño, resumen del ciclo, patrón de pruebas, registro de tiempo, defectos y seguimiento. ACTIVIDAD Defectos previstos, removidos, tamaño, tiempo del producto. OUTPUT Producto, listas de verificación, plan de proyecto y ciclo, patrón de reporte de pruebas y diseño, forma con propuesta de mejora, registro seguimiento pruebas y tiempo.
  • 56. DEFINICIÓN TSP está formado por dos componentes primarios que abarcan distintos aspectos del trabajo en equipo : Formación del equipo de trabajo Gestión del equipo de trabajo Es una metodología para dirigir el trabajo de mejora y desarrollo de software además de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural.
  • 57. OBJETIVOS DELTSP • Generar un marco basado en PSP • Desarrollar productos en varios ciclos • Establecer estándares para medir la calidad y el comportamiento • Proporcionar métricas para equipos • Evaluar roles y equipos • Guías para solución de problemas en equipos.
  • 59. CICLO DEVIDATSP • Durante esta fase, y siendo el primer ciclo, se realiza una revisión de los objetivos del curso. Lanzamiento • Se establece la estrategia de desarrollo decidiendo que se producirá, y se identifica los riesgos. Estrategia • Asignación a cada miembro del equipo. Planeación • Entrevistas con el cliente y se especifican. Requerimientos
  • 60. CICLO DEVIDATSP • Diseño de alto nivel, donde se especifica y examina cada parte identificada.Diseño • Revisión, compilación y prueba unitaria. Implementación • Se integran todos los programas. Prueba • Análisis del producto, Generación de las evaluaciones del equipo.Postmortem
  • 61. ROLESY RESPONSABILIDADES Líder del Equipo Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se planeó. Gestor de desarrollo Guía al equipo en el diseño y desarrollo del producto. Gestor de Planificación Apoya y guía al equipo en la planificación y seguimiento del trabajo. Gestor de Calidad/Proceso Apoya al equipo en definir sus necesidades acerca del proceso, establecer y administrar el plan de calidad. Administrador de Requerimientos/ Soporte Dirige al equipo en el desarrollo de requerimientos de software, administra el plan de configuración
  • 62. CMMI Capability Maturity Model Integration Definición Representación Continua Estructura de CMMI en Representación Continua Representación Escalonada Estructura de CMMI en Representación Escalonada Componentes
  • 63. DEFINICIÓN CMMI es el sucesor de CMM. El objetivo del proyecto CMMI es mejorar la usabilidad de modelos de madurez integrando varios modelos diferentes en un solo marco (framework). Fue creado por miembros de la industria y el gobierno. • Representación Continua (Continuous Representation) • Escalonada (Staged Representation) Tiene 2 representaciones:
  • 64. REPRESENTACIÓN CONTINUA 6 NIVELES DEFINIDOS EN CMMI • El proceso no se realiza, o no se consiguen sus objetivos.Incompleto • El proceso se ejecuta y se logra su objetivo.Ejecutado • El proceso se planifica, se revisa y se evalúa para comprobar que cumple los requisitos.Gestionado • Se ajusta a la política de procesos que existe en la organización, alineada con las directivas de la empresa. Definido • Se controla utilizando técnicas cuantitativas. Cuantitativamente Gestionado • De forma sistemática se revisa y modifica o cambia para adaptarlo a los objetivos del negocio. Mejora continua. Optimizando
  • 66. REPRESENTACIÓN ESCALONADA (STAGED REPRESENTATION) Establece 5 Niveles de Madurez (Maturity Level) para clasificar a las organizaciones, en función de qué áreas de procesos consiguen sus objetivos y se gestionan con principios de ingeniería. Es lo que se denomina un modelo escalonado, o centrado en la madurez de la organización. • 7 PA para el nivel de madurez o ML1 • 2 PA para el ML2 • 11 PA para el ML3 • 2 PA para el ML4 • 2 PA para el ML5 La selección de los Áreas de Proceso está prefijado, habiendo:
  • 70. ¿QUÉ ES LA CALIDAD DEL SOFTWARE? • “Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas” (IEEE 729-83). • “Conjunto de propiedades y de características de un producto o servicio, que le confieren aptitud para satisfacer una necesidades explícitas o implícitas” (ISO 8402:1984)
  • 71. ¿QUÉ ES LA CALIDAD DEL SOFTWARE? “La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE, Std. 610-1990). “Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente, que desea el usuario” (Pressman, 1998)
  • 72. ¿QUÉ ES LA CALIDAD DEL SOFTWARE? La calidad del software puede ser entendida como el grado con el cual el usuario percibe que el software satisface sus expectativas (IEEE 729-83). El tipo y número de actividades de garantía de calidad que es necesario adoptar en un proyecto o en una organización depende del tamaño y complejidad de los productos software que se estén desarrollando.
  • 73. Calidad en uso Calidad externa Calidad interna Calidad de proceso Proceso Producto Efecto del producto Influye Influye Influye Depende de Depende de Depende de Contextos de uso proveedor usuario
  • 74. ¿CÓMO MEDIR LA CALIDAD DE UN PRODUCTO SOFTWARE? Se emplea para ellos modelos , que especifican la calidad mediante la definición de un conjunto de atributos o características. Se basa en descomponer la calidad del producto en características y estas en criterios que pueden ser medidos mediante métricas.
  • 77. Comprueban si un producto posee o no una determinada característica de calidad en el grado requerido. Identificar defectos en el producto para corregirlos. OBJETIVO
  • 78. CONTROLES ESTÁTICOS El objetivo principal es analizar el objeto sin necesidad de ejecutarlo.
  • 79. CONTROLES ESTÁTICOS MANUALES INFORMALES • Examinar a mano e individualmente el objeto que se acaba de desarrollar. • Se aplica a los requisitos, especificaciones de diseño y código según se desarrollan. • Es más efectivo si se hace intercambiando el objeto a examinar con otro compañero. Comprobación de escritorio (desk checking): • Revisión del código de un programador por otros programadores (sus pares). • Se puede poner en práctica creando un panel que se encarga de revisar periódicamente muestras de código. Revisión por pares o iguales (peer review):
  • 80. CONTROLES ESTÁTICOS MANUALES DISCIPLINADOS El objetivo principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el propio desarrollador. 1. AUDITORÍAS: Auditorías de proyecto Auditorías de gestión de proyecto
  • 81. PROCEDIMIENTO DE UNA AUDITORÍA • Define los objetivos de la auditoria y su alcance • Se elabora un Plan de Auditoria, dando respuesta a: Por qué se realiza, Para qué se realiza, Cuál es el producto que va a ser auditado, etc. Planificación • Se inicia con una reunión de apertura de la investigación. • Se lleva a cabo mediante entrevistas y revisiones en las que se recopilan datos. Llevar a cabo la investigación • Se utilizan técnicas de análisis estadístico, por parte de los auditores. • Se realiza una evaluación en paralelo de los resultados por un grupo de evaluadores. Analizar los datos recogidos Sugerir soluciones a los problemas encontrados y posibles mejoras. Elaborar y presentar un informe de resultados
  • 82. 2. REVISIONES: Se consigue que el peso de la evaluación técnica no recaiga sobre las mismas personas involucradas en la producción del software, pues no pueden ser totalmente objetivos. Ofrece a los gestores, información fiable acerca de los aspectos técnicos del proceso de desarrollo de software. Es una reunión formal donde se presenta el estado actual de los resultados de un proyecto a un usuario, cliente u otro tipo de persona interesada, y se realiza un análisis estructurado. Características:
  • 83. DIFERENCIAS ENTRE REVISIONESY AUDITORÍAS: Las revisiones se llevan a cabo desde las primeras fases del desarrollo, mientras que las auditorías se llevan a cabo en las fases finales. El objetivo de las revisiones es detectar defectos, mientras que el objetivo de las auditorías es certificar conformidad e identificar desviaciones.
  • 84. TIPOS DE REVISIONES Se diferencian por la forma en que se desarrolla la reunión de revisión. Inspecciones • Los participantes leen el documento, guiados por el autor del mismo, y comprueban en cada paso el cumplimiento de los criterios de una lista de comprobación. Walkthrough (visita guiada): • Se demuestra la funcionalidad del objeto revisado mediante la simulación de su funcionamiento con casos de prueba y ejemplos. Se introducen al objeto los casos de prueba y se van registrando los resultados intermedios.
  • 85. DIFERENCIAS: WALKTHROUGH Están planteados como una medida de ayuda al desarrollador. Su objetivo fundamental es incrementar el entendimiento, comprender mejor el objeto. Esta guiado por la estructura del producto revisado. Se usan para asegurar la satisfacción de los criterios de salida establecidos entre diferentes etapas del desarrollo (revisiones de fase). INSPECCIONES Planteadas como una medida de ayuda al gestor. El objetivo fundamental es detectar defectos. Proceso guiado por la lista de comprobación. Se planifican y procesan de una manera mucho más formal que los walkthrough.
  • 87. FASES EN LA INSPECCION PLANIFICACION Objetivos, Criterios de finalización, Lugar y fecha, Disponibilidad de participantes (coordinador/moderador, secretario) ORIENTACION INICIAL Reunión de orientación para dar una idea del objeto PREPARACION INDIVIDUAL Antes de la realización de la inspección, una copia de la documentación asociada al objeto, y lista de comprobaciones checklist
  • 88. FASES EN LA INSPECCION REUNION DE INSPECCION El presentador.- Punto por punto la lista de comprobación; Componente a componente del producto; Por grupos de puntos dentro de la lista de comprobación; Cualquier otra situación intermedia Al final de la reunión de inspección, los participantes, valoran los resultados de la inspección: Se cierra la inspección sin que se hayan encontrado defectos; Defectos eliminados; Si se encuentran otros defectos se realiza otra inspección
  • 89. FASES EN LA INSPECCION SEGUIMIENTO Autor del objeto revisado se encarga de corregir los defectos encontrados EVALUACION Determina si se ha corregido todos los defectos y si han surgido nuevos problemas, el moderador se encarga de realizar la evaluación.
  • 90. DOCUMENTOS GENERADOS EN UNA INSPECCION Informe resumen.- Conclusiones breves para la dirección (¿Qué se ha revisado?; ¿Quién lo ha revisado?; ¿Cual fue la conclusión?) Lista acciones pendientes.- Informe para los autores del producto revisado explica que esta mal y se puede dar soluciones o correcciones (no debe llegar a la dirección). Informe de asuntos relacionados.- Para registrar problemas que salen a la luz durante la inspección ( no relacionados con el objeto revisado) Informe del proceso de inspección.- Cuando algo ha salido mal en el proceso de inspección en si mismo Informe final.- Para informar a la dirección el cierre de la inspección. Informes o documentos generados como resultado de una inspección son los siguientes:
  • 91. FASES EN UN WALKTHROUGH PLANIFICACION.- • Similar a la planificación de una inspección con la diferencia que no es necesario asignar roles específicos a excepción del presentador( organizador del WALKTHROUGH) PREPARACION INDIVIDUAL.- • Cada revisor examina el objeto revisado en este caso no se entrega una lista de comprobación. REUNION DE WALKTHROUGH.- • Discusión de alternativas de diseño, encontrar errores.
  • 92. FORMALIDAD EN LAS REVISIONES • Es un evento público • Se informa por escrito de los resultados • Todos los participantes son responsables de la calidad de la revisión Una revisión es formal cuando: La ventaja de realizar revisiones formales es que los informes que se generan sirven con hitos para el proyecto y el hecho de ser algo público promueve una mejor preparación por parte de los participantes.
  • 93. REVISIONES TECNICASY DE GESTION Revisión de la especific ación de requisito s Revisión del diseño Revisión del código Revisión de las pruebas Revisión del manual de usuario Las revisiones técnicas más comunes son:
  • 94. OBJETIVOS DE LAS REVISIONES DEL PROYECTO SON: Control de la progresión del proyecto. Evaluación de los riesgos asociados al proyecto con relación al costo, escala de tiempo, recursos utilizados y calidad del producto. Evaluación general del producto. Para que estos sea posible es necesario: • Que exista un plan de desarrollo bien estructurado, con hitos bien definidos, que permita evaluar la progresión del proyecto • Que los resultados del proyecto se encuentren bien documentados, y hayan sido examinados por la revisión técnica
  • 95. REVISIÓN DE LA ESPECIFICACIÓN DE REQUISITOS Es muy útil para facilitar el descubrimiento de los errores introducidos en la especificación de requisitos en fases tempranas del desarrollo.
  • 96. ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN ENCONTRARSE EN UNA LISTA DE COMPROBACIONES PARA LA ESPECIFICACIÓN DE REQUISITOS: ¿Se han especificado todos los recursos hardware necesarios? ¿Se han especificado las interfaces externas necesarias? ¿Existen contradicciones en la especificación de los requisitos? ¿Se han definido los criterios de aceptación para cada una de las funciones especificadas?
  • 97. REVISIÓN DEL DISEÑO El objetivo de estas revisiones es determinar y evaluar el estado en el que se encuentra el proceso de diseño, así como descubrir errores o contradicciones (entre la especificación de requisitos y el diseño o en las interfaces entre módulos)
  • 98. ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN ENCONTRARSE EN UNA LISTA DE COMPROBACIONES PARA EL DISEÑO SON LAS SIGUIENTES: ¿Hay uniformidad en el diseño? ¿Se han definido correctamente las interfaces entre módulos? ¿Se han definido correctamente las interfaces externas? ¿Cubre el diseño todas las funciones incluidas en la especificación de requisitos? ¿Cumple el diseño todos los requisitos no funcionales?
  • 99. REVISIÓN DEL CÓDIGO Su objetivo es determinar que el código se corresponde con el diseño detallado realizado. Algunos de los aspectos que se examinan en una revisión de código son los siguientes: adherencia a los estándares de codificación 20 comentarios entradas y salidas fórmulas utilización de variables estructura del programa interfaces
  • 100. REVISIÓN DE LAS PRUEBAS Se pueden efectuar dos tipos de revisiones de las pruebas: • Revisión del diseño de la prueba. • Inspección de la prueba.
  • 101. EL OBJETIVO DE LA REVISIÓN DEL DISEÑO DE LA PRUEBA ES COMPROBAR QUE EL DISEÑO REALIZADO PARA LA PRUEBA ESTÁ DE ACUERDO CON LOS OBJETIVOS QUE SE PERSIGUEN. SE DEBEN COMPROBAR ASPECTOS COMO: ¿Se han tenido en cuenta todos los objetivos a la hora de diseñar los casos de prueba? ¿Se han elegido los casos de prueba más adecuados para comprobar la consecución de dichos objetivos? • Los objetivos de las inspecciones de las pruebas, por su parte, son: Comprobar que la prueba se ha ejecutado correctamente, de acuerdo con el procedimiento de prueba especificado. Análisis de los resultados obtenidos con cada prueba.
  • 102. CONTROLES ESTÁTICOS AUTOMÁTICOS Dentro de esta categoría tenemos el análisis estático automático y la verificación formal de programas. La mayor parte del análisis estático automático del código lo realizan los compiladores, que pueden detectar desde expresiones sintácticamente incorrectas hasta incompatibilidades de tipo y otros errores de tipo semántico. Otras técnicas de análisis estático automático de programas son: • Análisis de Flujo • Ejecución simbólica
  • 103. ANÁLISIS DE FLUJO Consiste en determinar el comportamiento de las variables del programa desde su inicialización hasta que termina la ejecución del programa.
  • 104. CLASIFICANDO LAS VARIABLES EN: REFERENCIADAS Cuando se obtiene su valor en memoria durante la evaluación de una expresión en una sentencia. DEFINIDAS Cuando se obtiene un nuevo valor para la variable como consecuencia de la ejecución de una sentencia. NO REFERENCIADAS Cuando ya no se puede determinar el valor de la variable a partir del flujo del programa.
  • 105. EJECUCIÓN SIMBÓLICA La mejor forma de analizarla es descomponerla en una estructura de árbol, donde cada hoja representa un camino de ejecución y cada ramificación representa un punto de decisión en el programa.
  • 106. EJEMPLO Función en ADA que calcula la suma de los N elementos de un array entero A: function SUM (A: INTARRAY; N: NATURAL) return INTEGER is S: INTEGER := 0; I: NATURAL := 1; Begin while I <= N loop S := S + A(I); I := I + 1; end loop; return (S); End SUM;
  • 107. RESULTADO DE LA EJECUCIÓN SIMBÓLICA
  • 108. Y EN FORMA DE ÁRBOL
  • 109. VERIFICACIÓN FORMAL Consiste en demostrar matemáticamente la corrección de un programa con respecto a sus especificaciones. Es también necesario que la especificación se haya escrito en algún lenguaje formal. Por eso no siempre es posible realizar este tipo de verificación. Por lo general, esta técnica sólo se utiliza para sistemas críticos, debido al coste que conlleva.
  • 110. GESTIÓN DE CALIDAD DEL SOFTWARE SISTEMA DE GESTIÓN DE CALIDAD ISO 9001:2000
  • 111. GESTIÓN DE CALIDAD DEL SOFTWARE (SQM) • Aspecto de la función general de la gestión que determina y aplica la política y objetivos de la calidad del software. • Conjunto de actividades que dirigen y controlan una empresa en lo relativo a la calidad. • Deben incluir el establecimiento de la política y los objetivos de la calidad.
  • 114. SISTEMA DE CALIDAD Conjunto de las actividades relativas a planificación, control, aseguramiento y mejora de la calidad dentro de una empresa. Las actividades de garantía de calidad que se adoptan en un proyecto, depende mucho de la complejidad y tamaño de los productos de software. SGC debe fijar la estructura de la organización, de las responsabilidades, de las actividades, de los recursos y de los procedimientos para llevar a cabo la gestión de calidad.
  • 115. SISTEMA DE CALIDAD SGC debe determinar los procedimientos y métodos a implantar para lograr una gestión de la calidad. Define como implementar la garantía de calidad. • Organización: Es este el nivel en el que normalmente se establece el sistema de calidad. • Proyecto. • Fase de desarrollo. Se puede definir un sistema de calidad en 3 niveles:
  • 116. SISTEMA DE CALIDAD Establece también de que forma se reparten las tareas y las responsabilidades entre el personal. Un sistema de gestión de la calidad es la forma en la que una empresa o institución dirige y controla todas las actividades que están asociadas a la calidad
  • 117. PARTES QUE COMPONEN EL SISTEMA DE GESTIÓN Estructura organizativa: departamento de calidad o responsable de la dirección de la empresa. Cómo se planifica la calidad. Los procesos de la organización. Recursos que la organización aplica a la calidad. Documentación que se utiliza.
  • 118. SISTEMA DE GESTIÓN DE CALIDAD
  • 119. SISTEMA DE GESTIÓN DE CALIDAD
  • 120. ISO 9001:2000 • Especifica los requisitos para un SGC que pueden utilizarse para su aplicación. • Se centra en la eficacia del SGC para asegurar la satisfacción del cliente. • Promueve la adopción de un enfoque orientado a procesos para el desarrollo, implementación y la mejora de la eficacia de un SGC.
  • 121. ISO 9001:2000 • Consta de 20 clausulas que definen que aspectos de un sistema de calidad deben estar presentes en una organización. • No da detalles de cómo deben implementarse e institucionalizarse dichos aspectos. • Asegura que la organización documenta todos sus procesos y procedimientos de acuerdo con los requisitos del estándar.
  • 122. MODELO DE GESTIÓN DE CALIDAD
  • 125. CONTROLES DINÁMICOS Requieren la ejecución del objeto que se está probando o de un modelo del mismo. PRUEBA DEL SOFTWARE Es el proceso en que se ejecuta un sistema con el objetivo de detectar fallos. • En proyectos grandes la prueba 50 - 60% del esfuerzo. • Es muy importante seleccionar bien las pruebas • Seleccionar casos de prueba que incidan en programa complejos. • La prueba es disciplina profesional que requiere formación • El grupo de prueba debe ser independiente del de desarrollo y debe adoptar una actitud positiva de destrucción creativa. CARACTERÍSTICAS
  • 126. DEPURACIÓN Es el proceso en el que se localiza el defecto que es la causa de un fallo. • Se determina la forma de corregirlo • Se evalúa el efecto de la corrección • Se lleva a cabo la corrección PASOS TIPOS DE PRUEBAS • Estándar IEEE 1012-1986  PRUEBA MODULAR  PRUEBA DE INTEGRACIÓN  PRUEBA DE SISTEMA  PRUEBA DE ACEPTACIÓN  PRUEBA DE REGRESIÓN
  • 127. PRUEBA MODULAR • Conocida también como prueba unitaria o prueba de componentes • Consiste en la prueba de cada módulo aislado del resto del sistema
  • 128. PRUEBA DE INTEGRACIÓN  Se realiza a medida que los diferentes módulos del sistema se integran en el mismo  El objetivo de esta prueba es comprobar que las interfaces entre los distintos módulos son correctas.
  • 129. COMPROBACIONES  Compatibilidad de tipos entre los argumentos del procedimiento o función y los parámetros de llamada  Corrección en la sintaxis en la invocación de procedimientos y funciones  Corrección y completitud de las especificaciones de los módulos
  • 131. PRUEBAS DE INTEGRACIÓN  Integración descendente Módulo en pruebas Otros módulos Otros módulos Reales, ya probados Otros módulos simulados (stubs)
  • 132. PRUEBA DE SISTEMA  Se realiza cuando se han integrado todos los módulos  El objetivo es comprobar que el sistema satisface los requisitos del usuario, tanto los funcionales como los no funcionales PRUEBA DE ACEPTACIÓN • Se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento • El objetivo es demostrar al usuario que el sistema satisface sus necesidades PRUEBA DE REGRESIÓN • Tiene como objetivo comprobar que toda nueva versión de un producto software es de no menos calidad que la versión anterior.
  • 133. RELACIÓN ENTRE PRODUCTOS DE DESARROLLO Y NIVELES DE PRUEBA
  • 134. MÉTODOS DE CAJA NEGRA El objeto que se desea probar se ve como una caja negra. (elección de los casos de prueba no se basa en el conocimiento la estructura del objeto, sino en el conocimiento de la funcionalidad deseada. El objeto que se desea probar se ve como una caja negra. (elección de los casos de prueba no se basa en el conocimiento la estructura del objeto, sino en el conocimiento de la funcionalidad deseada.
  • 135. MÉTODOS DE CAJA BLANCA O CAJA TRANSPARENTE  El objeto que se prueba se ve como una caja blanca. (elección de los casos de prueba se basan en conocimiento que se tenga de la estructura del objeto, diseño detallado, diagramas de flujo de datos y de control, código fuente). • Los basados en métricas de cobertura • Los basados en métricas de complejidad LOS MÉTODOS DE CAJA BLANCA SE PUEDEN CLASIFICAR, A SU VEZ, EN DOS GRUPOS:
  • 136. • Una prueba de caja blanca exhaustiva requeriría la generación de un caso de prueba por cada posible camino. • Como esto no es posible, por lo general, se utilizan métricas que dan una indicación de la calidad de un determinado conjunto de casos de prueba en función del grado de cobertura del grafo que consiguen. Cobertura de: • Sentencias • Segmentos entre decisiones. • Decisiones de ramificación • Condiciones • Todas las combinaciones de condiciones • Caminos Las métricas más utilizadas son:
  • 137. MÉTODOS BASADOS EN MÉTRICAS DE COMPLEJIDAD  Complejidad ciclomática (arcos - nodos + 2 * número de componentes conexos)  Complejidad esencial (complejidad ciclomática - número de subgrafos propios de entrada y salida única)  Complejidad real (número de caminos ejecutados) LAS MÉTRICAS DE COMPLEJIDAD MÁS UTILIZADAS EN LA GENERACIÓN DE CASOS DE PRUEBA SON LAS DE MACCABE:
  • 139. METODOLOGÍA DE PRUEBA  La prueba tiene su propio ciclo de vida.  Los diferentes tipos de prueba implica la realización de un conjunto de actividades estándar y salidas estándar  Para cada fase del proceso de desarrollo hay alguna actividad de prueba importante. PLANIFICACIÓN DE LA PRUEBA – El objetivo del proceso de prueba – Los objetos que hay que probar – Las característica que se prueban y las que no – El método de prueba a utilizar – Los recursos que se van a emplear – El plan de tiempos – Los productos a generar durante las pruebas – El reparto de las responsabilidades Es la creación de un plan de pruebas que registra:
  • 140. DISEÑO DE LAS PRUEBAS  Cómo llevar a cabo la prueba para alcanzar los objetivos deseados  De qué forma se van a utilizar los métodos de prueba  Qué objetos se van a probar en cada una de las pruebas  Qué criterios se van a utilizar para determinar si el objeto pasa o no pasa la prueba. CONSISTE EN DAR INSTRUCCIONES SOBRE: DETERMINACIÓ N DE LOS CASOS DE PRUEBA Consiste en especificar el conjunto de casos de prueba a utilizar en función del diseño realizado para la prueba, especificando: – Qué objetos se van a probar – Qué entradas se les van a dar y – Cuáles son las salidas esperadas
  • 141. PLANIFICACIÓN DEL PROCEDIMIENTO DE PRUEBA Consiste en fijar un conjunto de pasos para la ejecución de la prueba, especificando: • La secuencia exacta de ejecución. • Los requisitos que hay que cumplir para la ejecución. • Las condiciones de terminación de cada uno de ellos EJECUCIÓN DE LA PRUEBA • Consiste en ejecutar cada caso de prueba, (paso anterior), y registrar los incidentes o problemas encontrados durante el sistema.
  • 142. COMPARACIÓN ENTRE LOS MÉTODOS DE CONTROL DE CALIDAD  Hay dos maneras para mejorar la calidad de los productos que desarrollamos:  Detectar los defectos lo antes posible  Cometer menos errores
  • 143.  Teniendo en cuenta que el proceso de detección puede subdividirse en las siguientes fases:  Identificar síntomas  Deducir localización del defecto a partir de los síntomas  Averiguar qué es lo que está mal  Decidir cómo arreglar el defecto  Arreglarlo  Verificar que se ha resuelto el problema COMPARACIÓN ENTRE LOS MÉTODOS DE CONTROL DE CALIDAD
  • 144.  Por otro lado, se pueden usar una serie de métricas para poder hacer una evaluación y comparación cuantitativa entre diferentes actividades de control de calidad.  En primer lugar, se deben tomar una serie de métricas directas:  Tamaño del objeto examinado en la actividad  Tiempo invertido en la actividad  Número de defectos detectados  A partir de estas métricas básicas, se puede calcular una serie de métricas derivadas muy interesantes COMPARACIÓN ENTRE LOS MÉTODOS DE CONTROL DE CALIDAD
  • 145. Número de Escapes:  Son los defectos que estaban ahí y no han sido detectados hasta después de concluida la actividad. Para poder calcular esto es necesario conocer la fase en la que los defectos fueron introducidos y eliminados. Eficacia de la tarea (Yield)  Es el porcentaje de defectos encontrados una actividad sobre todos los que estaban ahí al iniciarse ésta.  La fórmula para calcularla es: MÉTRICAS DERIVADAS  tarea_escapestarea_eliminados _tareaeliminados 100  Yield
  • 146. MÉTRICAS DERIVADAS Densidad de defectos encontrados  Se mide en número de defectos por unidad de tamaño del objeto examinado  La fórmula para calcularla es: Eficiencia de la tarea (Tasa de Eliminación de Defectos) Nos indica cómo de rápido se encuentra defectos en la actividad correspondiente. La fórmula para calcularla es: revisiones_en_invertido_tiempo tarea_sencontrado TED revisado_objeto_tamaño tarea_sencontrado Densidad
  • 147. Rapidez de la revisión Es una métrica que se aplica sólo a las revisiones, y nos indica la cantidad de material cubierto por unidad de tiempo. La fórmula para calcularla es:  Cabe decir que no es bueno ir demasiado rápido. Se recomienda no sobrepasar los 300 LOC/hora. Generalmente resulta interesante ver la correlación de esta métrica con la Eficacia (Yield), y comprobar cómo a medida que aumenta la rapidez decrece la eficacia. revisioninvertidotamaño revisadoobjetotamaño Rapidez __ __  MÉTRICAS DERIVADAS
  • 148.  Poder de Eliminación de Defectos (Defect Removal Leverage)  Nos indica el ratio de eficiencia entre dos actividades de detección de defectos. Dicho de otro modo, permite ver cuánto más/menos eficiente es una actividad con respecto otra.  La fórmula para calcularla es: - 2_ 1_ PED tareaPED tareaPED  MÉTRICAS DERIVADAS
  • 149. 150 COSTOS DE CALIDAD Representan la diferencia entre los costos reales de un producto o servicio y el costo reducido si no hubiera la posibilidad de un tener un servicio por debajo de los estándares, fallas de productos, o defectos en su manufactura. • Costos de prevención • Costos de evaluación • Costos de falla interna • Costos de falla externa COSTOS DE CALIDAD
  • 150. 151 COSTOS DE PREVENCIÓN  Son los costos de todas las actividades específicamente diseñados para prevenir fallas de calidad en productos o servicios – Revisión de nuevos productos – Planeación de la calidad (manuales, procedimientos, etc.) – Evaluación de capacidad de proveedores – Esfuerzos de mejora a través de trabajo en equipo – Proyectos de mejora continua – Educación y entrenamiento en calidad… etc. EJEMPLO:
  • 151. 152  Son los costos asociados con las actividades de medir, evaluar y auditar los productos o servicios para asegurar su conformidad a los estándares de calidad y requerimientos de desempeño. COSTOS DE EVALUACIÓN – Inspecciones con el proveedor y en recibo – Pruebas e inspecciones en proceso y al producto terminado – Auditorias al producto, proceso o servicio – Calibración de equipos de prueba y medición – Costos de materiales de prueba EJEMPLO:
  • 152. 153 COSTOS DE FALLA INTERNA  Son los costos resultantes de productos o servicios no conformes a los requerimientos o necesidades del cliente, antes del embarque del producto o la realización del servicio. • Desperdicio (maculatura) • Retrabajos • Reinspección y repetición de pruebas • Revisión de materiales no conformes • Reducción de precio por calidad reducida EJEMPLO
  • 153. 154 COSTOS DE FALLA EXTERNA  Son los costos resultantes de productos o servicios no conformes a los requerimientos o necesidades del cliente, después de la entrega del producto o durante y después de la realización del servicio. • Proceso de quejas y reclamaciones • Devoluciones del cliente • Garantías • Campañas por productos defectivos EJEMPLO
  • 154. COSTOS TOTALES DE CALIDAD  Es la suma de los costos de prevención, apreciación, falla interna y falla externa  Los sistemas contables en general no son capaces de identificar estos costos  Es muy difícil ir al detalle del costo de calidad tal como un error de la secretaria
  • 156. PLANIFICACIÓN Es el proceso en el que se indica que la empresa puede probar que realiza sus planes de calidad, exponiendo un plan de calidad para cada producto. • Los objetivos de la calidad • Planificación de la calidad. Incluye dos aspectos centrales:
  • 163. PLAN DE CALIDAD Es el documento o conjunto de documentos: • Que establecen los objetivos de calidad, • La especificación de los procesos operativos necesarios y • La disponibilidad de los recursos apropiados para satisfacer tales objetivos, para la elaboración del producto que ocupa a la organización.
  • 164. PLAN SQA Proporciona un mapa para institucionalizar la garantía de calidad del software. Sirve como plantilla para actividades de SQA instituidas para cada proyecto de software.
  • 166. SECCIONES DOCUMENTACIÓN Situación de la SQA dentro de la estructura organizativa Las tareas y las actividades de SQA y su emplazamiento a lo largo del proceso del software Los papeles y responsabilidade s organizativas relativas a la calidad del producto
  • 167. SECCIONES Describe cada uno de los productos de trabajo producidos como parte del proceso de software. Documentos del proyecto (plan del proyecto) Modelos (DERs, jerarquías de clases), Documentos técnicos (especificaciones, planes de prueba) Documentos de usuario (archivos de ayuda) GESTIÓN
  • 168. SECCIONES REVISIÓN Y AUDITORIA Identifica las revisiones y auditorías que se van a llevar a cabo por el equipo de ingeniería del software, el grupo de SQA y el cliente. Proporciona una visión general del enfoque de cada revisión y auditoría.
  • 169. SECCIONES PRUEBAS Hace referencia al Plan y Procedimiento de Pruebas del Software Define requisitos de mantenimiento de registros de pruebas.
  • 170. SECCIONES • Identifica las herramientas y métodos que soportan actividades y tareas de SQA • Define un enfoque de gestión de contratos • Establece métodos para reunir, salvaguardar y mantener todos los registros • Identifica la formación que se requiere para cumplir las necesidades del plan • Define métodos para identificar, evaluar, supervisar y controlar riesgos.