CALIDAD DEL SOFTWARE

CALIDAD DEL SOFTWARE

1. CALIDAD : “la calidad es un concepto complejo y de facetas múltiples” que puede describirse desde cinco diferentes puntos de vista:

   • 1. El punto de vista trascendental dice (como Persig) que la calidad es algo que se reconoce de inmediato, pero que no es posible definir explícitamente. 2.El punto de vista del usuario concibe la calidad en términos de las metas específicas del usuario final. Si un producto las satisface, tiene calidad.
   • 3. El punto de vista del fabricante la define en términos de las especificaciones originales del producto. Si éste las cumple, tiene calidad. 4. El punto de vista del producto sugiere que la calidad tiene que ver con las características inherentes (funciones y características) de un producto.
   • 5. Por último, el punto de vista basado en el valor la mide de acuerdo con lo que un cliente está dispuesto a pagar por un producto. En realidad, la calidad incluye todo esto y más.
   • En el desarrollo del software, la calidad del diseño incluye el grado en el que el diseño cumple las funciones y características especificadas en el modelo de requerimientos.
     • La calidad de la conformidad se centra en el grado en el que la implementación se apega al diseño y en el que el sistema resultante cumple sus metas de requerimientos y desempeño.
       • es mejor plantear una relación más intuitiva:
         • satisfacción del usuario = producto que funciona + buena calidad + entrega dentro del presupuesto y plazo
           • En última instancia, Glass sostiene que la calidad es importante, pero que si el usuario no está satisfecho, nada de lo demás importa.

2. Calidad del software

   • Incluso los desarrolladores de software más experimentados estarán de acuerdo en que obtener software de alta calidad es una meta importante. Pero, ¿cómo se define la calidad del software? En el sentido más general se define1 como: Proceso eficaz de software que se aplica de manera que crea un producto útil que proporciona valor medible a quienes lo producen y a quienes lo utilizan.
     • DIMENSIONES DE CALIDAD DE GARVIN
       • David Garvin [Gar87] sugiere que la calidad debe tomarse en cuenta, adoptando un punto de vista multidimensional que comience con la evaluación de la conformidad y termine con una visión trascendental (estética).
         • Calidad del desempeño. ¿El software entrega todo el contenido, las funciones y las características especificadas como parte del modelo de requerimientos, de manera que da valor al usuario final?
         • Calidad de las características. ¿El software tiene características que sorprenden y agradan la primera vez que lo emplean los usuarios finales?
         • Confiabilidad. ¿El software proporciona todas las características y capacidades sin fallar? ¿Está disponible cuando se necesita? ¿Entrega funcionalidad libre de errores?
         • Conformidad. ¿El software concuerda con los estándares locales y externos que son relevantes para la aplicación? ¿Concuerda con el diseño de facto y las convenciones de código? Por ejemplo, ¿la interfaz de usuario está de acuerdo con las reglas aceptadas del diseño para la selección de menú o para la entrada de datos?
         • Durabilidad. ¿El software puede recibir mantenimiento (cambiar) o corregirse (depurarse) sin la generación inadvertida de eventos colaterales? ¿Los cambios ocasionarán que la tasa de errores o la confiabilidad disminuyan con el tiempo?
         • Servicio. ¿Existe la posibilidad de que el software reciba mantenimiento (cambios) o correcciones (depuración) en un periodo de tiempo aceptablemente breve? ¿El equipo de apoyo puede adquirir toda la información necesaria para hacer cambios o corregir defectos?
         • Estética. No hay duda de que todos tenemos una visión diferente y muy subjetiva de lo que es estético. Aun así, la mayoría de nosotros estaría de acuerdo en que una entidad estética posee cierta elegancia, un flujo único y una “presencia” obvia que es difícil de cuantificar y que, no obstante, resulta evidente.
         • Percepción. En ciertas situaciones, existen prejuicios que influirán en la percepción de la calidad por parte del usuario.
     • Factores de la calidad de McCall
       • McCall, Richards y Walters [McC77] proponen una clasificación útil de los factores que afectan la calidad del software.
         • se centran en tres aspectos importantes del producto de software: sus características operativas, su capacidad de ser modificado y su adaptabilidad a nuevos ambientes.
           • hacen las descripciones siguientes:
             • Corrección. Grado en el que un programa satisface sus especificaciones y en el que cumple con los objetivos de la misión del cliente. Confiabilidad. Grado en el que se espera que un programa cumpla con su función y con la precisión requerida [debe notarse que se han propuesto otras definiciones más completas de la confiabilidad (véase el capítulo 25)]. Eficiencia. Cantidad de recursos de cómputo y de código requeridos por un programa para llevar a cabo su función.
             • su función. Integridad. Grado en el que es posible controlar el acceso de personas no autorizadas al software o a los datos. Usabilidad. Esfuerzo que se requiere para aprender, operar, preparar las entradas e interpretar las salidas de un programa. Facilidad de recibir mantenimiento. Esfuerzo requerido para detectar y corregir un error en un programa (ésta es una definición muy limitada).
             • Flexibilidad. Esfuerzo necesario para modificar un programa que ya opera. Susceptibilidad de someterse a pruebas. Esfuerzo que se requiere para probar un programa a fin de garantizar que realiza la función que se pretende. Portabilidad. Esfuerzo que se necesita para transferir el programa de un ambiente de sistema de hardware o software a otro. Reusabilidad. Grado en el que un programa (o partes de uno) pueden volverse a utilizar en otras aplicaciones (se relaciona con el empaque y el alcance de las funciones que lleva a cabo el programa). Interoperabilidad. Esfuerzo requerido para acoplar un sistema con otro.
     • Transición a un punto de vista cuantitativo
       • La comunidad de la ingeniería de software trata de obtener mediciones precisas de la calidad de éste y a veces se ve frustrada por la naturaleza subjetiva de la actividad.
         • Cavano y McCall [Cav78] analizan esta situación:
           • La subjetividad y la especialización también se aplican a la determinación de la calidad del software. Para ayudar a resolver este problema, es necesario tener una definición más precisa de la calidad del software, así como una forma de realizar mediciones cuantitativas de la calidad a fin de hacer análisis objetivos…

3. EL DILEMA DE LA CALIDAD DEL SOFTWARE

   • Es correcto afirmar que los ingenieros de software deben tratar de producir sistemas de alta calidad. Es mejor aplicar buenas prácticas al intento de lograrlo. Pero la situación descrita por Meyer proviene de la vida real y representa un dilema incluso para las mejores organizaciones de ingeniería de software.
     • Software “suficientemente bueno”
       • En palabras sencillas, si damos por válido el argumento de Meyer, ¿es aceptable producir software “suficientemente bueno”? La respuesta a esta pregunta debe ser “sí”,
       • Crean software con errores detectados y lo distribuyen a una gran población de usuarios finales. Reconocen que algunas de las funciones y características de la versión 1.0 tal vez no sean de la calidad más alta y planean hacer mejoras en la versión 2.0.
         • El software suficientemente bueno contiene las funciones y características de alta calidad que desean los usuarios, pero al mismo tiempo tiene otras más oscuras y especializadas que contienen errores conocidos.
       • Si trabaja en ciertos dominios de aplicación (por ejemplo, software incrustado en tiempo real) o si construye software de aplicación integrado con hardware (como el software automotriz o de telecomunicaciones), entregar software con errores conocidos es una negligencia y deja expuesta a su compañía a litigios costosos.
         • En ciertos casos, incluso, puede ser un delito. ¡Nadie quiere tener software suficientemente bueno en los aviones!
           • Así que proceda con cautela si piensa que lo “suficientemente bueno” es un atajo que puede resolver los problemas de calidad de su software. Tal vez funcione, pero sólo para unos cuantos y en un conjunto limitado de dominios de aplicación.
   • Si produce un sistema de software de mala calidad, usted pierde porque nadie lo querrá comprar. Por otro lado, si dedica un tiempo infinito, demasiado esfuerzo y enormes sumas de dinero para obtener un elemento perfecto de software, entonces tomará tanto tiempo terminarlo y será tan caro de producir que de todos modos quedará fuera del negocio. En cualquier caso, habrá perdido la ventana de mercado, o simplemente habrá agotado sus recursos. De modo que las personas de la industria tratan de situarse en ese punto medio mágico donde el producto es suficientemente bueno para no ser rechazado de inmediato, no en la evaluación, pero tampoco es un objeto perfeccionista ni con demasiado trabajo que lo convierta en algo que requiera demasiado tiempo o dinero para ser terminado.
   • El costo de la calidad
     • No hay duda de que la calidad tiene un costo, pero la mala calidad también lo tiene —no sólo para los usuarios finales que deban vivir con el software defectuoso, sino también para la organización del software que lo elaboró y que debe darle mantenimiento
       • El costo de la calidad incluye todos los costos en los que se incurre al buscar la calidad o al realizar actividades relacionadas con ella y los costos posteriores de la falta de calidad.
         • El costo de la calidad puede dividirse en los costos que están asociados con la prevención, la evaluación y la falla.
   • Riesgos
     • La implicación es que el software de mala calidad aumenta los riesgos tanto para el desarrollador como para el usuario final.
       • . En la subsección anterior se analizó uno de dichos riesgos (el costo). Pero lo perjudicial de las aplicaciones mal diseñadas e implementadas no siempre se mide en dólares y tiempo.
         • La mala calidad del software puede ocasionar accidentes y daños serios, puede suceder en ámbitos laborales como en hospitales, maquinaria pesada, aeropuertos etc.