UNIVERSIDAD DE LAS FUERZAS ARMADAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
CARRERA DE INGENIERÍA EN SISTEMAS E INFORMÁT...
CALIDAD DEL SOFTWARE
 La integridad de un producto de software depende
de la acción combinada de tres tipos de disciplina...
OBJETIVOS
Al finalizar esta unidad estará en capacidad de:
Comprender el significado de la terminología utilizada.
Ser c...
CALIDAD DE
PROCESO
CALIDAD DE PROCESO
Conjunto de actividades, métodos, prácticas y
transformaciones que la gente usa para desarrollar
y mant...
CALIDAD DEL PRODUCTO DE
SOFTWARE
La calidad del producto de software se diferencia de la calidad de otros
productos de fab...
CALIDAD DEL PRODUCTO DE
SOFTWARE
 El mantenimiento del software es mucho más complejo que el
mantenimiento del hardware. ...
PROBLEMAS DE LA CALIDAD DEL
PRODUCTO DE SOFTWARE
Los principales problemas a los que se enfrenta al hablar de la calidad d...
PROBLEMAS DE LA CALIDAD DEL
PRODUCTO DE SOFTWARE
 La mejora de la Calidad del Software: Cómo utilizar la información
disp...
DEFINICIÓN DE CALIDAD
 Calidad es “Conformidad con los requisitos y confianza en el
funcionamiento” Deming.
 “Adecuación...
DEFINICIÓN DE CALIDAD
 La calidad es algo relativo, depende de los requisitos o necesidades que
se desea satisfacer.
 En...
TERMINOLOGÍA BÁSICA
 ERROR: como una incorrección cometida por un humano
durante el proceso de desarrollo.
 DEFECTO: es ...
TERMINOLOGÍA BÁSICA
FALLAS (fault): son los defectos que aún no
han sido detectados y eliminados cuando
comienzan las pru...
Estructura de los modelos de calidad
En los modelos de calidad, la calidad se define de forma jerárquico. Es un
concepto q...
Modelos de Calidad
 La ventaja de los Modelos de Calidad, está en que la misma se convierte en algo
concreto, que se pued...
 Organiza los factores en tres ejes o puntos de vista desde los cuales el
usuario puede contemplar la calidad del product...
FACILIDAD DE MANTENIMIENTO
(¿Puedo arreglarlo?)
FACILIDAD DE PRUEBA
(¿Puedo probarlo?)
FLEXIBILIDAD
(¿Puedo modificarlo?)
...
Los factores de McCall desde el punto de vista de Operación del Producto se definen de
la siguiente forma:
FACTORES DE Mc ...
FACTORES DE Mc CALL
• El Coste de localizar y corregir defectos en un programa que
aparecen durante su funcionamiento
Faci...
FACTORES DE Mc CALL
• Hasta que punto se puede transferir un módulo o programa del
presente sistema a otra aplicación, y c...
 La Relación Factores – Criterio desde el Punto de Vista de Operación
del Producto
FACTORES – CRITERIOS MODELO DE Mc CALL...
CRITERIOS DE Mc CALL PARA EL FACTOR
FACILIDAD DE USO
• Atributos del software que determinan la facilidad de operación
del...
CRITERIOS DE Mc CALL PARA EL FACTOR
INTEGRIDAD
• Atributos del software que proporcionan control de acceso al
software y l...
CRITERIOS DE Mc CALL PARA EL FACTOR
CORRECCIÓN
• Atributos del software que proporcionan la implementación
completa de tod...
• Atributos del software que proporcionan el grado de
precisión requerido en los cálculos y los resultados.Precisión
• Atr...
• Atributos del software que minimizan el tiempo de
procesamiento.
Eficiencia en
Ejecución
• Atributos del software que mi...
 La Relación Factores – Criterio desde el Punto de Vista de Revisión del
Producto
FACTORES – CRITERIOS MODELO DE Mc CALL
...
• Atributos del software que proporcionan una estructura
de módulos altamente independientes.Modularidad
• Atributos del s...
CRITERIOS DE Mc CALL PARA EL FACTOR
FACILIDAD DE PRUEBA
• Atributos del software que proporcionan una estructura de
módulo...
CRITERIOS DE Mc CALL PARA EL FACTOR
FLEXIBILIDAD
• Atributos del software que proporcionan explicaciones sobre la
implemen...
 La Relación Factores – Criterio desde el Punto de Vista de Transición
del Producto
FACTORES – CRITERIOS MODELO DE Mc CAL...
• Atributos del software que proporcionan explicaciones
sobre la implementación de las funciones.Auto descripción
• Atribu...
CRITERIOS DE Mc CALL PARA EL FACTOR
INTEROPRABILIDAD
• Atributos del software que proporcionan una estructura de
módulos a...
CRITERIOS DE Mc CALL PARA EL FACTOR
PORTABILIDAD
• Atributos del software que proporcionan explicaciones sobre la
implemen...
MODELO BOEHM
FURPS
Los factores de calidad FURPS provienen de
trabajos anteriores, definiendo los siguientes
atributos para cada uno de...
ISO/IEC 9126:TECNOLOGÍAS DE LA INFORMACIÓN
CALIDAD DE LOS PRODUCTOS SOFTWARE.
• Modelo de CalidadParte 1
• Métricas Extern...
calidad externa
e interna
funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad
adecuación
exactitud
...
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 niv...
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
prescriptiv...
JUSTIFICACIÓN DEL PSP
Los ingenieros de software rara vez basan su
trabajo en prácticas y metodologías establecidas
y son ...
PASOS PARA IMPLANTACION PSP
Lo que sigue es optimizar la interacción entre equipos y aquí entraría Team
Software Process, ...
CICLO DEVIDA PSP
7 niveles del PSP
PSP3
Proceso Personal Cíclico
PSP2 y PSP2.1
Manejo Personal de calidad
PSP1 y PSP1.1
Pr...
• Identificar actividades: definición, secuencia
• Bases mejoras: planeación, evaluación, resultados
• Documentar proceso ...
• Mejora la ejecución:
• Detección temprana de defectos, en base a la
predicción de estos.
• Revisiones de diseño
• Revisi...
CICLO DE VIDA PSP
FASE PLANEACIÓN
(PLAN DE PROYECTO)
INPUT
Descripción del
problema, resumen
del proyecto,
resumen cíclico...
CICLO DEVIDA PSP
FASE DISEÑO DE
PRODUCTO
INPUT
Tipificación
requerimientos,
diseño conceptual,
patrones de
estimaciones de...
CICLO DEVIDA PSP
FASE REVISIÓN O
VALIDACIÓN DEL DISEÑO
INPUT
Programa de
diseño, escenarios
operacionales,
especificación ...
CICLO DEVIDA PSP
FASE DESARROLLO O
IMPLEMENTACIÓN
INPUT
Diseño de alto
nivel, registro de
seguimiento,
tiempos y defectos,...
CICLO DEVIDA PSP
FASE POSMORTEM,
EVALUACIÓN CICLO
INPUT
Definición de problema
y requerimientos, plan
de proyecto, product...
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...
OBJETIVOS DELTSP
• Generar un marco basado en PSP
• Desarrollar productos en varios ciclos
• Establecer estándares para me...
ESTRUCTURA DETSP
CICLO DEVIDATSP
• Durante esta fase, y siendo el primer
ciclo, se realiza una revisión de los
objetivos del curso.
Lanzami...
CICLO DEVIDATSP
• Diseño de alto nivel, donde se especifica
y examina cada parte identificada.Diseño
• Revisión, compilaci...
ROLESY RESPONSABILIDADES
Líder del Equipo
Dirige al equipo, se asegura que todos reporten sus
datos de los procesos y comp...
CMMI
Capability Maturity Model
Integration
Definición
Representación Continua
Estructura de CMMI en Representación Continu...
DEFINICIÓN
CMMI es el sucesor de CMM.
El objetivo del proyecto CMMI es mejorar la usabilidad de
modelos de madurez integra...
REPRESENTACIÓN CONTINUA
6 NIVELES DEFINIDOS EN CMMI
• El proceso no se realiza, o no se consiguen
sus objetivos.Incompleto...
REPRESENTACIÓN ESCALONADA
(STAGED REPRESENTATION)
Establece 5 Niveles de Madurez (Maturity Level) para clasificar a
las or...
CALIDAD DEL
PRODUCTO
SOFTWARE
¿QUÉ ES LA CALIDAD DEL
SOFTWARE?
• “Grado con el cual el cliente o usuario
percibe que el software satisface sus
expectati...
¿QUÉ ES LA CALIDAD DEL
SOFTWARE?
“La calidad del software es el grado con el que un
sistema, componente o proceso cumple l...
¿QUÉ ES LA CALIDAD DEL
SOFTWARE?
La calidad del software puede ser entendida como
el grado con el cual el usuario percibe ...
Calidad
en uso
Calidad
externa
Calidad
interna
Calidad de
proceso
Proceso Producto
Efecto del
producto
Influye Influye Inf...
¿CÓMO MEDIR LA CALIDAD DE
UN PRODUCTO SOFTWARE?
Se emplea para ellos modelos , que
especifican la calidad mediante la defi...
ACTIVIDADES
DE CONTROL
Comprueban si un producto posee o no una determinada
característica de calidad en el grado requerido.
Identificar defectos...
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 ap...
CONTROLES ESTÁTICOS MANUALES DISCIPLINADOS
El objetivo principal es conseguir que la responsabilidad del
control de calida...
PROCEDIMIENTO DE UNA AUDITORÍA
• Define los objetivos de la auditoria y su alcance
• Se elabora un Plan de Auditoria, dand...
2. REVISIONES:
Se consigue que el peso de la evaluación técnica no recaiga sobre las mismas
personas involucradas en la pr...
DIFERENCIAS ENTRE REVISIONESY AUDITORÍAS:
Las revisiones se llevan a
cabo desde las primeras
fases del desarrollo,
mientra...
TIPOS DE REVISIONES
Se diferencian por la forma en que se desarrolla la reunión de revisión.
Inspecciones
• Los participan...
DIFERENCIAS:
WALKTHROUGH
Están planteados como una
medida de ayuda al desarrollador.
Su objetivo fundamental es
incrementa...
FASES EN LA INSPECCION
PLANIFICACION
Objetivos, Criterios de finalización, Lugar y fecha,
Disponibilidad de participantes
...
FASES EN LA INSPECCION
REUNION DE
INSPECCION
El presentador.-
Punto por punto la lista de comprobación;
Componente a compo...
FASES EN LA INSPECCION
SEGUIMIENTO
Autor del objeto revisado se encarga de
corregir los defectos encontrados
EVALUACION
De...
DOCUMENTOS GENERADOS EN UNA INSPECCION
Informe
resumen.-
Conclusiones breves para la dirección (¿Qué se ha
revisado?; ¿Qui...
FASES EN UN WALKTHROUGH
PLANIFICACION.-
• Similar a la
planificación de
una inspección
con la diferencia
que no es
necesar...
FORMALIDAD EN LAS REVISIONES
• Es un evento público
• Se informa por escrito de los resultados
• Todos los participantes s...
REVISIONES TECNICASY DE GESTION
Revisión
de la
especific
ación de
requisito
s
Revisión
del
diseño
Revisión
del
código
Revi...
OBJETIVOS DE LAS REVISIONES DEL PROYECTO SON:
Control de la progresión del proyecto.
Evaluación de los riesgos asociados a...
REVISIÓN DE LA ESPECIFICACIÓN DE REQUISITOS
Es muy útil para facilitar el descubrimiento
de los errores introducidos en la...
ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN
ENCONTRARSE EN UNA LISTA DE COMPROBACIONES
PARA LA ESPECIFICACIÓN DE REQUISITOS:
¿Se ...
REVISIÓN DEL DISEÑO
El objetivo de estas revisiones es determinar y
evaluar el estado en el que se encuentra el
proceso de...
ALGUNAS DE LAS PREGUNTAS QUE PODRÍAN
ENCONTRARSE EN UNA LISTA DE COMPROBACIONES
PARA EL DISEÑO SON LAS SIGUIENTES:
¿Hay un...
REVISIÓN DEL CÓDIGO
Su objetivo es determinar que el código se corresponde con el diseño detallado
realizado.
Algunos de l...
REVISIÓN DE LAS PRUEBAS
Se pueden efectuar dos tipos de
revisiones de las pruebas:
• Revisión del diseño de la prueba.
• I...
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...
CONTROLES ESTÁTICOS AUTOMÁTICOS
Dentro de esta categoría tenemos el análisis estático
automático y la verificación formal ...
ANÁLISIS DE FLUJO
Consiste en determinar el
comportamiento de las variables del
programa desde su inicialización hasta
que...
CLASIFICANDO LAS VARIABLES EN:
REFERENCIADAS
Cuando se obtiene
su valor en
memoria durante la
evaluación de una
expresión ...
EJECUCIÓN SIMBÓLICA
La mejor forma de analizarla es descomponerla
en una estructura de árbol, donde cada hoja
representa u...
EJEMPLO
Función en ADA que calcula la suma de los N elementos de un array
entero A:
function SUM (A: INTARRAY; N: NATURAL)...
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...
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 o...
SISTEMA DE CALIDAD
Conjunto de las actividades relativas a
planificación, control, aseguramiento y mejora de la
calidad de...
SISTEMA DE CALIDAD
SGC debe determinar los procedimientos y métodos
a implantar para lograr una gestión de la calidad.
Def...
SISTEMA DE CALIDAD
Establece también de que forma se
reparten las tareas y las responsabilidades
entre el personal.
Un sis...
PARTES QUE COMPONEN EL SISTEMA DE
GESTIÓN
Estructura organizativa: departamento de
calidad o responsable de la dirección d...
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...
ISO 9001:2000
• Consta de 20 clausulas que definen que
aspectos de un sistema de calidad deben estar
presentes en una orga...
MODELO DE GESTIÓN DE CALIDAD
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
E...
DEPURACIÓN
Es el proceso en el que se localiza el defecto que
es la causa de un fallo.
• Se determina la forma de corregir...
PRUEBA MODULAR
• Conocida también
como prueba
unitaria o prueba
de componentes
• Consiste en la
prueba de cada
módulo aisl...
PRUEBA DE INTEGRACIÓN
 Se realiza a medida que los diferentes módulos
del sistema se integran en el mismo
 El objetivo d...
COMPROBACIONES
 Compatibilidad de tipos entre los
argumentos del procedimiento o función
y los parámetros de llamada
 Co...
PRUEBAS DE INTEGRACIÓN
 Integración descendente
Módulo en
pruebas
Otros
módulos
Otros
módulos
Reales,
ya probados
Otros
m...
PRUEBA DE SISTEMA
 Se realiza cuando se han integrado todos los módulos
 El objetivo es comprobar que el sistema satisfa...
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...
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...
• Una prueba de caja blanca exhaustiva requeriría
la generación de un caso de prueba por cada
posible camino.
• Como esto ...
MÉTODOS BASADOS EN MÉTRICAS DE
COMPLEJIDAD
 Complejidad
ciclomática (arcos - nodos
+ 2 * número de
componentes conexos)
...
METODOLOGÍA DE PRUEBA
 La prueba tiene su propio ciclo de vida.
 Los diferentes tipos de prueba implica la
realización d...
DISEÑO DE LAS PRUEBAS
 Cómo llevar a cabo la prueba para alcanzar
los objetivos deseados
 De qué forma se van a utilizar...
PLANIFICACIÓN DEL PROCEDIMIENTO DE
PRUEBA
Consiste en fijar un conjunto de pasos para la
ejecución de la prueba, especific...
COMPARACIÓN ENTRE LOS MÉTODOS DE
CONTROL DE CALIDAD
 Hay dos maneras para mejorar la calidad de los
productos que desarro...
 Teniendo en cuenta que el proceso de detección
puede subdividirse en las siguientes fases:
 Identificar síntomas
 Dedu...
 Por otro lado, se pueden usar una serie de métricas
para poder hacer una evaluación y comparación
cuantitativa entre dif...
Número de Escapes:
 Son los defectos que estaban ahí y no han sido detectados
hasta después de concluida la actividad. Pa...
MÉTRICAS DERIVADAS
Densidad de defectos encontrados
 Se mide en número de defectos por unidad de tamaño del objeto
examin...
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 p...
 Poder de Eliminación de Defectos (Defect
Removal Leverage)
 Nos indica el ratio de eficiencia entre dos
actividades de ...
150
COSTOS DE CALIDAD
Representan la diferencia entre los costos reales de un
producto o servicio y el costo reducido si ...
151
COSTOS DE PREVENCIÓN
 Son los costos de todas las actividades
específicamente diseñados para prevenir fallas de
calid...
152
 Son los costos asociados con las actividades de medir,
evaluar y auditar los productos o servicios para
asegurar su ...
153
COSTOS DE FALLA INTERNA
 Son los costos resultantes de productos o servicios
no conformes a los requerimientos o nece...
154
COSTOS DE FALLA EXTERNA
 Son los costos resultantes de productos o servicios
no conformes a los requerimientos o nece...
COSTOS TOTALES DE CALIDAD
 Es la suma de los costos de prevención,
apreciación, falla interna y falla
externa
 Los siste...
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 ...
PLAN DE CALIDAD
Es el documento o conjunto de
documentos:
• Que establecen los objetivos de calidad,
• La especificación d...
PLAN SQA
Proporciona un mapa
para institucionalizar la
garantía de calidad del
software.
Sirve como plantilla para
activid...
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
...
SECCIONES
Describe cada uno de los productos de
trabajo producidos como parte del proceso
de software.
Documentos del
proy...
SECCIONES
REVISIÓN Y AUDITORIA
Identifica las revisiones y auditorías que se van
a llevar a cabo por el equipo de ingenier...
SECCIONES
PRUEBAS
Hace referencia al
Plan y Procedimiento
de Pruebas del
Software
Define requisitos de
mantenimiento de
re...
SECCIONES
• Identifica las herramientas y métodos que soportan
actividades y tareas de SQA
• Define un enfoque de gestión ...
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
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
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
Próxima SlideShare
Cargando en…5
×

Material monster is ii emco

677 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
677
En SlideShare
0
De insertados
0
Número de insertados
1
Acciones
Compartido
0
Descargas
16
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Material monster is ii emco

  1. 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. 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. 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.
  4. 4. CALIDAD DE PROCESO
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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:
  35. 35. MODELO BOEHM
  36. 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. 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. 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. 39. MODELO DE CALIDAD PARA CALIDAD EN USO
  40. 40. ENTORNOS O MODELOS
  41. 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
  42. 42. PSP Personal Software Process Definición Justificación Pasos para la Implantación Ciclo deVida
  43. 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. 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. 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. 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. 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. 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
  49. 49. 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.
  50. 50. 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.
  51. 51. 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.
  52. 52. 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.
  53. 53. 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.
  54. 54. TSP Team Software Process Definición Objetivos Estructura Ciclo deVida Roles y Responsabilidades
  55. 55. 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.
  56. 56. 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.
  57. 57. ESTRUCTURA DETSP
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 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:
  63. 63. 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
  64. 64. 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:
  65. 65. CALIDAD DEL PRODUCTO SOFTWARE
  66. 66. ¿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)
  67. 67. ¿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)
  68. 68. ¿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.
  69. 69. 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
  70. 70. ¿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.
  71. 71. ACTIVIDADES DE CONTROL
  72. 72. 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
  73. 73. CONTROLES ESTÁTICOS El objetivo principal es analizar el objeto sin necesidad de ejecutarlo.
  74. 74. 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):
  75. 75. 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
  76. 76. 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
  77. 77. 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:
  78. 78. 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.
  79. 79. 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.
  80. 80. 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.
  81. 81. 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
  82. 82. 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
  83. 83. 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.
  84. 84. 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:
  85. 85. 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.
  86. 86. 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.
  87. 87. 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:
  88. 88. 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
  89. 89. 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.
  90. 90. 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?
  91. 91. 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)
  92. 92. 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?
  93. 93. 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
  94. 94. 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.
  95. 95. 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.
  96. 96. 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
  97. 97. 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.
  98. 98. 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.
  99. 99. 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.
  100. 100. 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;
  101. 101. RESULTADO DE LA EJECUCIÓN SIMBÓLICA
  102. 102. Y EN FORMA DE ÁRBOL
  103. 103. 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.
  104. 104. GESTIÓN DE CALIDAD DEL SOFTWARE SISTEMA DE GESTIÓN DE CALIDAD ISO 9001:2000
  105. 105. 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.
  106. 106. 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.
  107. 107. 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:
  108. 108. 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
  109. 109. 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.
  110. 110. SISTEMA DE GESTIÓN DE CALIDAD
  111. 111. SISTEMA DE GESTIÓN DE CALIDAD
  112. 112. 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.
  113. 113. 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.
  114. 114. MODELO DE GESTIÓN DE CALIDAD
  115. 115. CONTROLES DINÁMICOSY COSTOS DE CALIDAD
  116. 116. 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
  117. 117. 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
  118. 118. 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
  119. 119. 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.
  120. 120. 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
  121. 121. 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)
  122. 122. 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.
  123. 123. RELACIÓN ENTRE PRODUCTOS DE DESARROLLO Y NIVELES DE PRUEBA
  124. 124. 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.
  125. 125. 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:
  126. 126. • 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:
  127. 127. 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:
  128. 128. 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:
  129. 129. 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
  130. 130. 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.
  131. 131. 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
  132. 132.  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
  133. 133.  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
  134. 134. 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
  135. 135. 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
  136. 136. 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
  137. 137.  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
  138. 138. 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
  139. 139. 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:
  140. 140. 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:
  141. 141. 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
  142. 142. 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
  143. 143. 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
  144. 144. Planificación de la Calidad
  145. 145. 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:
  146. 146. 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.
  147. 147. 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.
  148. 148. SECCIONES Documentación Gestión Revisión y Auditoría Pruebas Otros
  149. 149. 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
  150. 150. 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
  151. 151. 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.
  152. 152. SECCIONES PRUEBAS Hace referencia al Plan y Procedimiento de Pruebas del Software Define requisitos de mantenimiento de registros de pruebas.
  153. 153. 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.

×