Control de calidad del Software Ingeniería del Software Lic.Marisa Gouget UCSA 2006.
-
Upload
trinidad-cortes-ramos -
Category
Documents
-
view
224 -
download
3
Transcript of Control de calidad del Software Ingeniería del Software Lic.Marisa Gouget UCSA 2006.
Control de calidad del Control de calidad del SoftwareSoftware
Ingeniería del Software
Lic.Marisa Gouget
UCSA
2006
MindmappingMindmapping
CALIDAD
Definiciones de CalidadDefiniciones de Calidad
La totalidad de las características de un producto o servicio que le confieren aptitud para satisfacer necesidades establecidas e
implícitasISO
Calidad de software es cumplir con los requerimientos del cliente más la formalidad del
proceso con que fue desarrolladoSEI
Definiciones de CalidadDefiniciones de Calidad
Una definición de calidad de software es:
El conjunto medible de atributos del
producto y del proceso de producción, los cuales permiten determinar con claridad los costos,
beneficios y riesgos potenciales de su desarrollo, utilización/comercialización y posterior
evolución.
Atributos de Calidad de Productos y Atributos de Calidad de Productos y
ProcesosProcesos
Producto
Calidad
• Requerimientos• Mantenibilidad• Confiabilidad• Seguridad• Rendimiento• Disponibilidad
• Definido• Documentado• Soportado• Conocido• Practicado• Medido• Mejorable
Proceso
Problemas y costos de la No calidadProblemas y costos de la No calidad
• Problemas
• Requerimientos no cumplidos, mal interpretados
• Entregas tardías• Diseños mal realizados• Errores detectados por los
clientes• Errores de alto riesgo• Malas políticas de testing
• Costos relacionados
• Altos costos de retrabajo• Altos costos de soporte• Costos de oportunidad• Pérdida de mercados• Defectos recurrentes
Costo de CalidadCosto de Calidad
Costos asociados a la Calidad:• Prevención
– Planificación de calidad– RTF– Equipos de Pruebas– Formación
• Evaluación– Inspección en el proceso y entre procesos– Calibrado y mantenimiento del equipo– Pruebas
• Fallos– Internos (Retrabajo, Reparación, Análisis de fallos)– Externos (Resolución de quejas, Sustitución de productos,
Soporte)
Procesos principales de la Procesos principales de la gestión de calidadgestión de calidad
• Planificación de la calidad: identificación de los estándares de calidad y de cómo satisfacerlos.
• Aseguramiento de la calidad: evaluación del desempeño completo del proyecto para brindar confianza en que el proyecto cumplirá con los estándares de calidad.
• Control de calidad: verificación del cumplimiento de los estándares de calidad y modo de eliminar causas de desempeño insatisfactorio.
Planificación de la calidadPlanificación de la calidad• Entradas:
– Políticas de calidad– Enunciación del alcance – Descripción del producto– Estándares y regulaciones– Otras salidas de procesos
• Salidas:– Plan de gestión de la
calidad– Definiciones operativas– Listas de verificación– Entradas a otros procesos
•Técnicas y herramientas:–Análisis costo/beneficio–Estudios comparativos–Diagramas de flujo–Diseño de experimentos–Costo de la calidad
Aseguramiento de la calidadAseguramiento de la calidad• Entradas:
– Plan de gestión de la calidad
– Resultados de las mediciones de control de calidad
– Definiciones operativas
• Salidas:– Mejora de la calidad
•Técnicas y herramientas:–Técnicas y herramientas de la planificación de la calidad–Auditorías de la calidad
Control de la calidadControl de la calidad• Entradas:
– Resultados de los trabajos
– Plan de gestión de la calidad
– Definiciones operativas– Listas de verificación
• Salidas:– Mejora de la calidad– Decisiones de
aceptación– Reproceso– Listas de verificación
completadas– Ajustes al proceso
•Técnicas y herramientas:–Inspección–Gráficos de control–Diagramas de Pareto–Muestreo estadístico–Diagramas de flujo–Análisis de tendencias
Herrramientas para la planificación de la Herrramientas para la planificación de la calidadcalidad
Diagramas causa-efectoDiagramas causa-efecto
Tiempo Máquinas Método Material
Energía Mediciones Personal Ambiente
Defecto
Causas potenciales Efecto
Herramienta creada por Ishikawa para analizarpor categorías los factores principales que influyenen un proceso, evitando prestar atención solamente
a algunas causas.
Herrramientas para el control de la Herrramientas para el control de la calidadcalidad
Diagramas de paretoDiagramas de pareto
Herramienta creada por Pareto, es un gráfico de barras que muestra en forma descendente y de izquierda a derecha
la importancia de cada categoría de datos que permite armarla curva ABC conocida como 20-80
02468
10121416
1 2 3 4 5 6 7
Problemas
Control de calidad del software Control de calidad del software (SQA) Pressman(SQA) Pressman
• Para garantizar la calidad del software necesitamos:– Enfoque a la gestión de calidad– Tecnología (métodos y herramientas) de ingeniería de
Software y un equipo de SQA– Revisiones técnicas formales durante todo el proceso– Una estrategia de pruebas– Control de documentación del software y de los
cambios realizados– Procedimientos– Mecanismos de medición y de generación de informes
Control de calidad del software Control de calidad del software (SQA)(SQA)
De proceso
De producto
CALIDAD
Actividades del control de Actividades del control de calidad del software (SQA)calidad del software (SQA)
1. Establecimiento de un plan de SQA para el proyecto con:
a. Evaluaciones a realizarb. Auditorías y revisiones a realizarc. Estándares a aplicar en el proyectod. Procedimientos para información y
seguimiento de errorese. Documentos a producirf. Realimentación de información de desarrollo
Actividades del control de Actividades del control de calidad del software (SQA)calidad del software (SQA)
2. Participación del grupo SQA en el desarrollo de la descripción del proceso de software (proceso vs políticas, procesos de negocios, etc)
3. Revisión de las actividades de ingeniería de software para verificar su ajuste al proceso definido.
4. Auditoría de los procesos de software.5. Aseguramiento de la documentación de los desvíos del
producto y aplicación del procedimiento establecido.6. Registro de lo que no se ajuste e informe a los
superiores.7. Coordinación del control y gestión de cambios8. Colaboración en la recopilación y el análisis de las
métricas del software.
Revisiones técnicas formalesRevisiones técnicas formales• Objetivos:
– Descubrir errores en la función, la lógica o la implementación de cualquier representación del software.
– Verificar que el software bajo revisión alcanza sus requirimientos.
– Garantizar que el software ha sido representado de acuerdo a ciertos parámetros estándares predefinidos.
– Conseguir un software desarrollado de forma uniforme.
– Hacer que los proyectos sean más manejables.
Revisiones técnicas formalesRevisiones técnicas formales
• Forma:– Reunión de revisión para:
• Aceptar el producto• Rechazar el producto• Aceptar provisionalmente el producto
– Registro de la revisión:• ¿Qué fue revisado?• ¿Quién lo revisó?• ¿Qué se descubrió y cuáles fueron las
conclusiones?
Revisiones técnicas formalesRevisiones técnicas formales• Directrices para la revisión:
– Revisar el producto, no al productor– Fijar una agenda y mantenerla– Limitar el debate y las impugnaciones– Enunciar áreas de problemas, pero no intentar resolver
cualquier problema– Tomar notas escritas– Limitar el número de participantes e insistir en la preparación
anticipada– Desarrollar una lista de comprobación para cada producto que
se vaya a revisar– Disponer de recursos y tiempo para las RTFs, que se deben
planificar junto con el proceso de ingeniería de software.– Llevar a cabo un buen entrenamiento de todos los revisores
en el proceso de revisión (técnica) y en psicología humana (ej. Trabajo en equipo).
– Revisar las revisiones anteriores.
Proceso Proceso de una RTFde una RTF
Se realiza la RTF.
El productor le informa al líder que ha terminado su producto.
Productor
El líder evalúa si el producto está en condiciones de pasar a una RTF.
Líder de Proyecto
El líder evalúa si el producto está en condiciones de pasar a una RTF. Distribuye las copias a los revisores.Agenda la RTF.
Jefe de Revisión
Los revisores realizan la revisión previa a la reunión.
Revisores
Toma las anotaciones correspondientes para generar:La lista de sucesos de revisión y el informe sumario de revisión.Le pasa los informes al productor para que realice las correcciones pertinentes.Archiva la documentación para futuros controles.
Registrador
Proceso de una Revisión Técnica Formal
Estándares de calidad Estándares de calidad
• Otros aspectos de calidad:– Fiabilidad del software (Probabilidad de
operación libre de fallos, en un entorno y tiempo
determinado): • TMEF = TMDF + TMDR (tiempo medio entre fallos
= tiempo medio de fallo + tiempo promedio de reparación)
– Disponibilidad del software (Probabilidad de que un prg funcione de acuerdo con los req en un
momento dado):• Disponibilidad= TMDF/(TMDF+TMR) *100
Estándares de calidad - Estándares de calidad - Normas ISONormas ISO
• ISO 9001: es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.
• ISO 9000-3: es un documento específico que interpreta ISO 9001 para el desarrollador de SW.
• ISO 9000-4: soporta las directrices para el servicio de soporte a usuarios.
Factores de Calidad según ISO Factores de Calidad según ISO 91269126
Funcionalidad : Adaptación, Exactitud, Interoperación, Seguridad.
Confiabilidad: Madurez, Tolerancia a Defectos, Facilidad de Recuperación.
Eficiencia: Comportamiento en el Tiempo, de los Recursos.
Facilidad de Uso: Facilidad de Comprensión, de Aprendizaje, de Operación.
Facilidad de Mantenimiento: Facilidad de Análisis, de Cambios, de Pruebas, Estabilidad.
Portabilidad: Adaptabilidad, Facilidad de Instalación, de Reemplazo.
Árbol de las características de Árbol de las características de calidad del software. IEEE 1976calidad del software. IEEE 1976
UtilidadesGenerales
Portabilidad
Para el uso
Para el Mantenimiento
Confiabilidad
Eficiencia
Ingeniería Humana
Testeable
Comprensible
Modificable
Independientedel HW
Autocontenido
Consistente
Integro/Robusto
Compelto
Seguro
Comunicativo
Trazable
Eficiente con el HW
Accesible
Auto descriptivo
Conciso
Estructurado
Escalable
Legible
CMMCMM
Calidad del SoftwareCalidad del Software
Ingeniería del SoftwareIngeniería del Software
UCSAUCSA
Qué es un modelo de procesos?Qué es un modelo de procesos?
Un modelo es una colección estructurada de elementos que describen las
caractéristicas de un proceso eficiente y eficaz.
Un buen modelo de procesos contiene un gran cantidad de experiencia de campo
dentro de su estructura.
Qué es CMMQué es CMM
Una aplicación del sentido común para el gerenciamiento de procesos y conceptos de mejora de la calidad del desarrollo y mantenimiento del software
Una guía desarrollada por y para la comunidad profesional del software
Un modelo para la mejora organizacional
Una estructura confiable y consistente para evaluar y mejorar las capacidades de una organización
Qué puedo hacer con CMM ?Qué puedo hacer con CMM ?
Ayudar a la comunicación, al establecer un lenguaje común en el ámbito organizacional
Facilitar poner el foco de atención en cuestiones críticas
Proveer recomendaciones generales
Ayudar a priorizar acciones de mejora
Niveles de MadurezNiveles de Madurez
Estructura del CMMEstructura del CMM
Nivel de Madurez
Areas claves
Objetivos
Actividades aejecutar
CompromisoPara ejecutar
Habilidadesnecesarias
Medición yAnálisis
Contiene
Debe alcanzar
Facilidades comunes para la implantación
Verificación deImplantación
CMM CMM NivelNivel 1: Ini 1: Inicialcial
• Ambiente inestable que carece de prácticas de management– Los compromisos no están bajo control– Los éxitos se basan en el talento individual y el
esfuerzo de los héroes
• Las buenas prácticas y estándares son frecuentemente sacrificadas por otras prioridades del management– Usualmente se cuenta con cronogramas
• La capacidad del proceso es impredecible– Los objetivos de cronograma, costos y calidad
no se hallan definidos
CMM CMM NivelNivel 2: 2: RepetibleRepetible
• La necesidad es establecer una administración efectiva del proyecto de software
• Los procesos de Administración de Proyectos están definidos e implementados
• Las políticas organizacionales guían los proyectos
• Las prácticas exitosas usadas en proyectos previos, puede ser repetidas.
CMM CMM NivelNivel 3: Defin 3: Definidoido
• Los procesos de software están definidos, documentados, y son aplicados a través de toda la organización.
• Comprensión compartida de como funciona el proceso y roles establecidos
• La capacidad de los procesos satisface objetivos de cronograma, costos, y funcionalidad
CMM CMM NivelNivel 4: 4: AdministradoAdministrado
• La efectividad del proceso es medida.
• El control estadístico del proceso es iniciado.
• Se sigue un proceso que apunta a las causas de desviaciones en el producto.
CMM CMM NivelNivel 5: 5: OptimizadoOptimizado
• Los factores que imposibilitan la realización, son identificados y eliminados.
• La mejora continua está institucionalizada
• La transición a nuevas tecnologías es practicada rutinariamente
El CMM codifica buenas prácticas existentes
Es independiente de la tecnología y del área
Es difícil salir del nivel 1
Se puede ser exitoso en el nivel 1
Se puede ser un fracaso en el nivel 3
Es aplicable a todo tipo y tamaño de organizaciones de software
ConclusionesConclusiones
Los problemas de CMM y la Los problemas de CMM y la soluciónsolución
Problemas de CMM• Las disciplinas de Software y Sistemas nuncan han
sido bien integradas• La Importancia e influencia del software en los
sistemas se ha incrementado dramáticamente
La solución: CMMI• Integrar las disciplinas de software y sistemas en un
marco de mejoras a los procesos.• Proveer un marco de trabajo para introducir nuevas
disciplinas según necesidades.
Mejoras de CMMI sobre CMMMejoras de CMMI sobre CMMEnfasis en mejoras medibles para lograr objetivos del negocio
Han sido agregadas Areas de Procesos para poner más enfasís en algunas prácticas importantes
Gestión de RequerimientosIngeniería de ProcesosAnálisis de las decisiones
CMMI es significativamente más grande que el CMM:
Más objetivos y prácticasMás áreas de procesoMás detalles
Ventajas del CMMIVentajas del CMMI
Arquitectura del modelo más robusta y con mayor nivel de detalle
Aplicable a más de una disciplina
Mejor atención a las áreas de ingeniería
La representación continua permite focalizar mejoras de acuerdo a los objetivos del negocio
Desventajas del CMMIDesventajas del CMMI
• Tamaño y complejidad mucho mayor que modelos vigentes
• El proceso de avaluación es más costoso en tiempo y esfuerzo
• La complejidad de la evaluación continua puede atentar contra la definición de objetivos concretos de madurez
ConclusionesConclusiones
• Si usted viene del mundo del CMM trabaje con el modelo por niveles
• Si usted tiene bien claros los objetivos de su negocio y las debilidades de sus procesos, y además entiende las relaciones entre las áreas de proceso, la representación continua puede ser una buena alternativa
• Para ambos casos, defina un plan de migración sobre la base de su madurez actual y una buena comprensión de su negocio/productos
Gestión de configuración del Gestión de configuración del softwaresoftware
Ingeniería del Software
Lic.Marisa Gouget
UCSA
2006
Gestión de Configuración de Gestión de Configuración de
SoftwareSoftware DefiniciónDefinición
“La gestión de configuración es una actividad de auto protección que se aplica a lo largo del proceso de la
Ingeniería de Software y que tiene como objetivo identificar, organizar y
controlar las modificaciones que sufre el software que construye un equipo.”
Babich y Pressman
Gestión de Configuración de Gestión de Configuración de
SoftwareSoftware DefiniciónDefinición
Gestión de configuración
NO ES
Mantenimiento del Software
Actividades de la GCSActividades de la GCS
1. Identificar el cambio2. Controlar el cambio3. Garantizar que el cambio se
implementa adecuadamente4. Informar del cambio a los interesados.
Elementos de ConfiguraciónElementos de Configuración
• La Ingeniería del software produce:
– Programas– Datos– Documentos
Todos ellos se transforman en elementos de configuración del
software.
Los cambiosLos cambios
“Sin importar en qué momento del ciclo de vida nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo
de todo el ciclo de vida”.
• Los cambios se producen por:– Nuevos requerimientos del negocio– Nuevas necesidades del usuario– Reorganización comercial– Restricciones de presupuestos o
planificaciones
Los cambiosLos cambios
La GCS es un conjunto de actividades desarrolladas para
gestionar los cambios a lo largo del ciclo de vida del software.
La GCS es una actividad de garantía de calidad que se aplica en todas
las fases del proceso de la ingeniería del software.
Líneas de BaseLíneas de Base
Una línea de base es una especificación o producto que se
ha revisado formalmente, y que de ahí en adelante sirve como base
para un desarrollo posterior y que puede cambiarse solamente a
través de procedimientos formales de control de cambios.
Líneas de BaseLíneas de Base
• La Línea de base es un punto de referencia en el desarrollo del software que queda marcado con la aprobación de uno o más elementos de configuración del soft.
• Se pueden establecer por ejemplo al terminar cada fase del ciclo de vida que se esté utilizando.
Líneas de BaseLíneas de Base
Ingeniería del SistemaIngeniería del Sistema
Análisis de RequisitosAnálisis de Requisitos
Diseño del SoftwareDiseño del Software
CodificaciónCodificación
PruebaPrueba
EntregaEntrega
Especificación Del sistema
Especificación de requisitos
Especificación Del diseño
Planes,procedimientos,datos de pruebas
Código fuente
Sistema enfuncionamiento
Elementos de configuraciónElementos de configuraciónEjemplosEjemplos
• Especificación del sistema• Plan del Proyecto de Software• Especificación de requisitos del
software:– Modelo del análisis– Especificaciones de Procesos– Prototipos
• Manual de usuario• Especificación del diseño• Listados de códigos fuentes• Especificación de las pruebas• Manuales de operación y ejecución• Programas ejecutables• Descripción de la base de datosEtc....
Líneas de Base y Elementos de ConfiguraciónLíneas de Base y Elementos de Configuración
RelaciónRelación
Una línea de base
Varios elementosDe configuración
El proceso de la GCSEl proceso de la GCS
1. Identificación los elementos de configuración
2. Control de versiones3. Control de cambios4. Auditorías de Configuración:
1. Revisiones formales2. Auditorías de configuración
5. Generación de informes
El proceso de la GCSEl proceso de la GCS
1.-1.- Identificación los elementos de Identificación los elementos de configuraciónconfiguración
1. Identificar y organizar los objetos como básicos y compuestos (colección de básicos y compuestos)
2. Identificar al objeto con un nombre que lo identifique unívocamante.
3. Identificar las relaciones entre los objetos.
4. Documentarlos con gráficos o notaciones.
El proceso de la GCSEl proceso de la GCS2.- Control de versiones2.- Control de versiones
1. Combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creados durante el proceso de ingeniería de software.
2. Cada versión del software es un colección de ECS y cada versión puede estar compuesta de diferentes variantes.
3. A cada componente se le asigna una tupla de atributos, lista de características que definen si se ha de utilizar el componente cuando se va a construir una determinada versión del software.
El proceso de la GCSEl proceso de la GCS3.- El proceso del Control de cambios3.- El proceso del Control de cambios
• Combina procedimientos humanos y herramientas.
• Elementos del control de cambios:– Petición del cambio– Autoridad de control de cambios (ACC)– Orden de Ingeniería de cambios (OCI)– Procesos de alta y baja de objetos (control de
acceso y sincronización)– Nivel del cambio: informal (antes de la línea de
base), a nivel del proyecto (cambio local) o formal (cuando el software está en los clientes).
El Proceso Formal del Control de Cambios
El usuario reconoce la necesidad del cambio
El usuario pide el cambio
El desarrollador lo evalúa
Se genera un informe de cambios
La autoridad de control de cambios decide
Se genera la orden Se rechaza de cambio el cambio
Se informa al usuario
El Proceso Formal del Control de Cambios
Se genera la orden de cambio
Se identifican los elementos de configuración afectados
Se dan de baja los ECS (sincronización)
Se realiza el cambio
Se audita el cambio
Se aprueba el cambio
Se dan de alta los ECS afectados
Se incluyen cambios en producción
Se revisan los cambios en todos los ECS
Se distribuye una nueva versión con los cambios
El proceso de la GCS4.- Auditorías de Configuración4.- Auditorías de Configuración
1. Revisiones técnicas formales: es una reunión con determinadas premisas que se centra en la corrección técnica del ECS que ha sido modificado, evaluando su consistencia con otros ECS, las omisiones o efectos secundarios.
2. Auditorías de configuración: es una actividad independiente que es llevada a cabo por el grupo de garantía de calidad y tiene como objetivo asegurar que se ha hecho, revisado, implementado y comunicado correctamente el cambio, de acuerdo a los estándares.
El proceso de la GCS5.- Generación de informes de estado de 5.- Generación de informes de estado de
configuración (IEC)configuración (IEC)
Es una actividad que documenta (contabiliza):–¿Qué pasó?–¿Quién lo hizo?–¿Cuándo pasó?–¿Qué más se vio afectado?
en cada paso del proceso formal del control de cambios.
Su objetivo es el de mejorar la comunicación entre todas las personas involucradas en el proyecto.