Descargar la presentación
La descarga está en progreso. Por favor, espere
Publicada porJoaquín Bustamante Tebar Modificado hace 6 años
1
LA CALIDAD EN EL DESARROLLO DE SOFTWARE
Por : Lic. Adrián Quisbert Vilela
2
¿En dónde está el software?
INTRODUCCION ¿En dónde está el software?
3
Requerimientos del Usuario Desarrollo de Software
INTRODUCCION Modelo de proceso Requerimientos del Usuario Sistema de software Actividades Desarrollo de Software
4
Factores para el del desarrollo de software
Recursos Humanos La calidad del producto El proceso de desarrollo
5
Factores para el del desarrollo de software
El proceso de desarrollo El aseguramiento de la calidad El recurso humano Desarrollo de Software La gerencia del proyecto Las herramientas de desarrollo
6
Estado del arte en Ingeniería de Software:
El desarrollo de software requiere un RH altamente especializado y muy actualizado Estado del arte en Ingeniería de Software: Ingeniería de Software Orientada a Objetos Reutilización de activos y componentes de software Interfases Humano-Computador Interfases web y multimedia Integración de software heterogéneo Objetos y componentes distribuidos Arquitecturas de integración: CORBA, EJB, COM Arquitecturas de software, patrones de diseño.
7
Construcción de una casa para un perro
Puede hacerlo una sola persona. Modelado mínimo. MPC = ci M1, M2, ...,Mn P = 1 - (ET/ER) Proceso simple. Herramientas simples.
8
Construcción de una casa
Construida eficientemente y en un tiempo razonable por un equipo. Modelado: de planos simples a planos arquitectónicos. Proceso bien definido. Herramientas más sofisticadas.
9
Construcción de un Edificio
Construido por muchas compañías. Requiere Mucho modelado : planos complejos planos arquitectónicos, modelos a escala, planes de ingeniería. Proceso bien definido: equipos arquitectónico, políticas de planeación, Infraestructura de planeación, tablas de tiempos y agendas. Equipo pesado.
10
El proceso de desarrollo
11
Los procesos de software
Un proceso de software se define como un: "conjunto de actividades, métodos, prácticas y transformaciones que las personas usan para desarrollar y mantener software y los productos asociados [p.ej., planes, especificaciones, diseños y pruebas]" Una premisa fundamental: "La calidad de un producto de software está determinada, en muy buena medida, por la calidad del proceso. CALIDAD DEL PRODUCTO CALIDAD DEL PROCESO
12
Situación actual La industria del software no ha acabado de salir de la fase artesanal Padecemos de “prisa patológica”, que es consecuencia directa de: Desorganización Falta de planificación Alta dependencia de los “héroes” Dedicamos nuestros esfuerzos de hoy a arreglar lo que se hizo mal ayer
13
Situación actual La construcción del software en nuestro medio es muy artesanal.
14
En una organización inmadura (cont.):
Si hay plazos rígidos, se sacrifican funcionalidad y calidad del producto para satisfacer el plan No existen bases objetivas para juzgar la calidad del producto Cuando los proyectos está fuera de plan, las revisiones o pruebas se recortan o eliminan
15
Qué hacer ? Artesanía Ingeniería
16
Cambio cultural de todos los involucrados!
17
Por que debemos Cambiar
Calidad de Software
18
DEFINICIÓN DE CALIDAD DEL SOFTWARE
La calidad está de moda, en todos los aspectos, pero especialmente en el desarrollo de software. El interés por la calidad crece de forma continua, a medida que los clientes se vuelven más selectivos y comienzan a rechazar los productos poco fiables o que realmente no dan respuesta a sus necesidades. Ahora bien, ¿qué es la calidad del software?
19
Algunas Definiciones Según Deming, calidad es “Conformidad con los requisitos y confianza en el funcionamiento” Según Juran, calidad es “Adecuación para su uso” Crosby pone más énfasis en la prevención: “hacerlo bien a la primera” Veamos otras definiciones de calidad extraídas de estándares internacionales: “La calidad es la suma de todos aquellos aspectos o características de un producto o servicio que influyen 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” (IEEE ) “Capacidad del producto software para satisfacer los requisitos establecidos” (DoD 2168)
20
“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 ).
21
Unos de los modelos de calidad más antiguos y extendidos es el de McCall [McCall, 1977], y
22
El modelo de McCall Como ejemplo vamos a ver el modelo de McCall. El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto: - Operación del producto - Revisión del producto - Transición del producto El modelo de McCall se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente forma:
23
Factores que determinan la calidad del software
Se centran en tres aspectos importantes de un producto software (McCall): Características operativas Capacidad de soportar los cambios Adaptabilidad a nuevos entornos
24
Factores de calidad del Software
Características operativas Corrección. ¿Hace lo que quiero? Fiabilidad. ¿Lo hace de forma fiable todo el tiempo? Eficiencia. ¿Se ejecutará en mi hardware lo mejor que pueda? Seguridad (Integridad). ¿Es seguro? Facilidad de uso. ¿Está diseñado para ser usado?
25
Capacidad de soportar los cambios
Facilidad de mantenimiento. ¿Puedo corregirlo? Flexibilidad. ¿Puedo cambiarlo? Facilidad de prueba. ¿Puedo probarlo?
26
Adaptabilidad a nuevos entornos
Portabilidad. ¿Podré usarlo en otra máquina? Reusabilidad. ¿Podré reutilizar alguna parte del software? Interoperabilidad. ¿Podré hacerlo interactuar con otro sistema?
27
FACTOR CRITERIOS 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
28
Eficiencia - Eficiencia en ejecución - Eficiencia en almacenamiento 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
29
Reusabilidad - Auto descripción - Generalidad - Modularidad - Independencia entre sistema y software - Independencia del hardware Interoperabilidad - Modularidad - Compatibilidad de comunicaciones - Compatibilidad de datos Portabilidad - Auto descripción - Modularidad - Independencia entre sistema y software - Independencia del hardware
30
Pruebas de Software
31
Pruebas de Software Las pruebas es el proceso de ejercitar un
programa con la intención específica de encontrar errores previos a la entrega al usuario final.
32
¿Qué muestran las pruebas?
errores cumplimiento de requerimientos desempeño indicede calidad
33
¿Quién prueba el software?
desarrollador probador independiente Entiende el sistema pero, es condescendiente y, es dirigido por el “entregable” Debe entender el sistema, pero, intentará provocar fallas, y, es dirigido por la calidad
34
Prueba exhaustiva
35
Prueba Selectiva Ruta Seleccionada
36
Pruebas de Softwre métodos de métodos de caja blanca caja negra
Estrategias
37
Diseñar casos de prueba
“Los bugs se esconden en las esquinas y se congregan en los límites ..." OBJETIVO descubrir errores CRITERIO en forma completa
38
Pruebas de Caja Blanca ... el objetivo es asegurarse que todos
sentencias y condiciones han sido ejecutados por lo menos una vez ...
39
¿Por qué probar? Los errores lógicos y los supuestos incorrectos
inversamente proporcionales a la probabilidad de ejecución de las rutas frecuentemente creemos que una ruta no es probable que se ejecute; de hecho, la realidad frecuentemente hay que tomarlo en cuenta los errores tipográficos son aleatorios, su probailidad de que las rutas sin probar contendrán algunos
40
Pruebas de Ruta Básicas
Primero, calculamos la complejidad ciclomática: número de decisiones simples + 1 o número de áreas cerradas + 1 en este caso, V(G)=4
41
Pruebas de Ruta Básicas
Siguiente, se derivan las 1 2 3 4 5 6 7 8 rutas independientes: Dado que V(G) = 4, hay 4 rutas Ruta 1: 1,2,3,6,7,8 Ruta 2: 1,2,3,5,7,8 Ruta 3: 1,2,4,7,8 Ruta 4: 1,2,4,7,2,4,...7,8 Finalmente, se derivan casos de prueba para aplicarse a estas rutas.
42
Prueba de Iteraciones Iteración simple Iteraciones Anidadas
concatenadas Iteraciones no estructuradas
43
Pruebas de Caja Negra requerimeintos salida entrada eventos
44
Estrategias de Pruebas de Software
45
Estrategias de Prueba pruebas unitarias pruebas de integración pruebas
sistema pruebas de validación
46
Pruebas Unitaras módulo a ser probado resultados ingeniero de software
casos de prueba
47
Pruebas Unitarias módulo a ser probado interfaz
estructuras de datos locales condiciones de frontera rutas independientes rutas de manejo de errores casos de prueba
48
Pruebas de Alto Orden pruebas de validación pruebas de sistema
pruebas alfa y beta
Presentaciones similares
© 2025 SlidePlayer.es Inc.
All rights reserved.