Control de calidad, Defectos y Olores del Software
Control de la calidad
Antes
de iniciar con el tema de control de calidad y los otros temas, es necesario
recordar lo que es el Aseguramiento de la
Calidad también conocido como "Quality
Assurance, que es el conjunto de actividades planificadas y sistemáticas
aplicadas en un Sistema de Calidad para que los requisitos de calidad de un
producto o servicio sean satisfechos. Entre estas actividades se encuentran la
medición sistemática, la comparación con estándares, el seguimiento de los
procesos, todas actividades asociadas con bucles de realimentación de
información. Estas actividades contribuyen a la prevención de errores, lo cual
se puede contrastar con el Control de
Calidad, que se centra en las salidas del proceso.
Continuando
con el tema de control de calidad, el problema principal para garantizar la
calidad en el software está en la concepción de la gran mayoría de las personas
cuando suponen que la garantía de calidad es algo que se impone bajo una medida
que se obtiene al finalizar un proyecto de software. El control de calidad en
el software se fundamenta en el principio de que la calidad se construye a
través de un proceso continuo de desarrollo, verificación (revisión) y
optimización en diferentes etapas. Es muy importante tener presente estas
“actividades” que ayudan a la prevención de errores mediante inspecciones de
software que surgen a partir de la necesidad de producir software de alta
calidad. Algunos grupos de desarrollo creen que la calidad del software es algo
en lo que deben preocuparse una vez que se ha generado el código, ¡Error!, la garantía de la calidad del
software es una actividad de protección que se aplica a lo largo de todo el
proceso de ingeniería de software.
Entonces,
la calidad en el software, este está en relación directa con el cumplimiento de
los requerimientos formulados por el usuario, de tal forma que si un programa
no cumple con alguno de estos requerimientos es un software de baja calidad.
Aunque el criterio de cumplimiento de los requerimientos es un factor
importante, no es el único factor, ya que existen condiciones implícitas que el
software debe cumplir como son eficiencia, seguridad, integridad, consistencia,
etc.; por lo tanto, no podemos afirmar que un software es de alta calidad
cuando cumple con los requerimientos del usuario. Además, en la calidad en el
software existen ciertos factores que varían de acuerdo con el usuario y con
los tipos de aplicación. Podemos resumir el concepto de la calidad en el
software en los siguientes puntos:
- Los requerimientos del usuario sobre un programa son los fundamentos desde los que se mide la calidad. La falta de concordancia con estos requerimientos es una falta de calidad.
- Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma como se aplica la ingeniería de software; si no se siguen estos estándares, probablemente se obtendrá software de baja calidad.
- Existe un conjunto de requerimientos implícitos que a menudo no se mencionan (eficiencia, facilidad de uso, facilidad de mantenimiento). Si el software falla en alcanzar los requerimientos implícitos, la calidad en el software queda en entredicho.
El
control de calidad en el software, denominado SQA ("Software Quality
Assurance"), se basa en las siguientes actividades:
- Uso de métodos y herramientas de análisis, diseño, codificación y prueba.
- Revisiones técnicas formales, que se aplican durante cada paso de la Ingeniería de software.
- Estrategia de prueba multiescalada.
- Control de la documentación del software y de los cambios realizados.
- Procedimientos que aseguren un ajuste a los estándares de desarrollo.
- Mecanismos de medida de la calidad ("métricas").
Comprobación de características de calidad
A continuación, se muestran las comprobaciones de
características de la calidad respecto de la definición del modelo de calidad de
software ISO 9126-1, el cual es presentar una visión general de la norma ISO
9126 y proporcionar una descripción detallada del modelo de calidad de software
utilizado por esta norma, con una explicación de las principales
características.
El modelo de calidad de software ISO 9126-1 identifica 6 características principales de calidad, a saber:
El modelo de calidad de software ISO 9126-1 identifica 6 características principales de calidad, a saber:
1. Funcionalidad: Un conjunto de atributos que dependen de la existencia de un conjunto de
funciones y sus propiedades especificadas. Las funciones son aquellas que satisfacen
necesidades declaradas o implícitas. (ISO 9126: 1991, 4.1).
Sub-características:
- Aptitud: Esta es la característica esencial de la funcionalidad y se refiere a la adecuación (a la especificación) de las funciones del software.
- Preciso: Esto se refiere a la corrección de las funciones.
- Operabilidad: Un componente o sistema de software dado no suele funcionar de forma aislada. Esta sub-característica se refiere a la capacidad de un componente de software para interactuar con otros componentes o sistemas.
- Conformidad: Cuando sea apropiado, se deben cumplir ciertas leyes y directrices de la industria. Esta sub-característica se refiere a la capacidad de software compatible.
- Seguridad: Esta sub-característica se refiere al acceso no autorizado a las funciones de software.
Sub-características:
- Madurez: Esta sub-característica se refiere a la frecuencia del fallo del software.
- Tolerancia a fallos: La capacidad del software de soportar (y recuperarse) de un componente, o de un fallo ambiental.
- Recuperabilidad: Capacidad para traer de vuelta un sistema fallido a la operación completa, incluyendo datos y conexiones de red.
Sub-características:
- Comprensibilidad: Determina la facilidad con la que se pueden entender las funciones de los sistemas, se relaciona con los modelos mentales de los usuarios en los métodos de interacción de la computadora humana.
- Aprendizaje: Esfuerzo de aprendizaje para diferentes usuarios, es decir, principiante, experto, casual, etc.
- Operabilidad: Capacidad del software para ser fácilmente operado por un usuario dado en un entorno dado.
Sub-características:
5. Mantenibilidad: Un conjunto de atributos
que dependen del esfuerzo necesario para realizar las modificaciones
especificadas. (ISO 9126: 1991, 4.5).
6. Portabilidad: Conjunto de atributos que
afectan a la capacidad del software para ser transferido de un entorno a otro.
(ISO 9126: 1991, 4.6).
Defectos del software y terminología
asociada
Olores del software
- Comportamiento del tiempo: Caracteriza los tiempos de respuesta para un determinado paso, es decir, tasa de transacción.
- Comportamiento del recurso: Caracteriza los recursos utilizados, es decir, la memoria, la CPU, el disco y el uso de la red.
Sub-características:
- Analizabilidad: Caracteriza la capacidad de identificar la causa raíz de un fallo dentro del software.
- Posibilidad de cambiar: Caracteriza la cantidad de esfuerzo para cambiar un sistema.
- Estabilidad: Caracteriza la sensibilidad al cambio de un sistema dado que es el impacto negativo que puede ser causado por los cambios del sistema.
- Testabilidad: Caracteriza el esfuerzo necesario para verificar (probar) un cambio del sistema.
Sub-características:
- Facilidad de instalación: Caracteriza el esfuerzo requerido para instalar el software.
- Conformidad: Similar al cumplimiento de la funcionalidad, pero esta característica se refiere a la portabilidad. Un ejemplo sería la conformidad de Open SQL que se relaciona con la portabilidad de la base de datos utilizada.
- Reemplazable: Caracteriza el aspecto plug and play de los componentes de software, que es lo fácil que es intercambiar un componente de software dado dentro de un entorno especificado.
Defectos del software y terminología
asociada
Una de las
limitaciones más importantes de las pruebas de software es que las pruebas
pueden mostrar sólo la presencia de fallos, no su ausencia. Esta es una
limitación fundamental y teórica; En general, el problema de encontrar todas
las fallas en un programa es indecidible. Los asesores a menudo llaman a una
prueba exitosa (o efectiva) una que encuentra un error. A continuación, se
presentan algunas definiciones vistas en clase con él profesor.
Una de las
distinciones más importantes a hacer es entre la validación y la verificación
1. Validación:
El proceso de evaluación del software al final del desarrollo del software para
garantizar el cumplimiento del uso previsto.
2. Verificación:
El proceso de determinar si los productos de una fase dada del proceso de
desarrollo de software cumplen con los requisitos establecidos durante la fase
anterior.
3. Fallo de software: Un defecto estático en el software.
4. Error de software: Un estado interno incorrecto que es la manifestación de alguna falla.
5. Fracaso de software: Comportamiento externo, incorrecto con respecto a los requisitos u otra
descripción del comportamiento esperado.
6. Pruebas:
Evaluar el software observando su ejecución.
7. Fracaso de
prueba: Ejecución que produce un error.
8. Depuración:
El proceso de encontrar una falla dada una falla.
9. Resultados esperados: El resultado que se producirá al ejecutar la prueba si y sólo si el
programa satisface su comportamiento previsto.
10. Observabilidad del software: Es fácil observar el comportamiento de un programa en términos de sus
salidas, sus efectos en el entorno y otros componentes de hardware y software.
11. Control de software: Es fácil proporcionar un programa con los insumos necesarios, en
términos de valores, operaciones y comportamientos.
12. Valores de prefijo: Cualquier entrada necesaria para poner el software en el estado
apropiado para recibir los valores del caso de prueba.
13. Valores de postfijo: Cualquier entrada que necesite ser enviada al software después de enviar
los valores del caso de prueba.
14. Valores de verificación: Valores necesarios para ver los resultados de los valores del caso de
prueba.
15. Comandos de salida: Valores necesarios para finalizar el programa o devolverlo a un estado
estable.
16. Caso de prueba: Un caso de prueba se compone de los valores de los casos de prueba,
resultados esperados, valores de prefijo y valores de postfijo necesarios para
una ejecución y evaluación completas del software bajo prueba.
17. Conjunto de pruebas: Un conjunto de pruebas es simplemente un conjunto de casos de prueba.
18. Script de prueba ejecutable: Un caso de prueba que se prepara en un formulario para ser ejecutado
automáticamente en el software de prueba y producir un informe.
Clasificación de defectos
Con respecto a la
clasificación de defectos la nace la pregunta: ¿Cómo se implementa la
clasificación de incidentes? Esta es quizás una de las preguntas más comunes
que surge cuando se intenta establecer la Gestión de Incidentes basada en la “Information
Technology Infrastructure Library” (ITIL). Según ITIL, el objetivo de la clasificación de incidentes y el apoyo
inicial es:
- Especificar el servicio con el que se relaciona el incidente.
- Asociar el incidente con un acuerdo de nivel de servicio (SLA).
- Identificar la prioridad basada en el impacto del negocio.
- Definir qué preguntas deben hacerse o información verificada.
- Determinar una matriz de informes primaria para información de gestión.
- Identificar una relación para coincidir con errores conocidos o soluciones.
- Seleccionar y / o definir el mejor especialista o grupo para manejar el incidente.
Por lo tanto, la
clasificación de incidentes existe principalmente para clasificar los
incidentes con el fin de proporcionar apoyo inicial. El soporte inicial
significa un análisis adecuado, evaluación y, si es necesario, enrutamiento.
1. Clasificación CTI (Categoría / Tipo / Artículo):
Muchas herramientas
de administración de servicios de TI que ofrecen automatización de
administración de incidentes usan una simple: categoría / tipo / artículo (CTI) para la clasificación. CTI es un
enfoque de tres niveles de definición de "Categoría", un
"Tipo" asociado con la "Categoría", y un "Artículo"
asociado con el "Tipo". Un enfoque popular sugiere que
Categoría y Tipo sean "sustantivos", y Artículo sea un "verbo".
CTI funciona bien cuando se conoce el trabajo requerido.
Este tipo de esquema
produce taxonomía de clasificación de la siguiente manera (usando taxonomía
CTI):
category noun (Database) | type
noun (Oracle) | item verb (Upgrade)
Así que básicamente
el enfoque esta en identificar una categoría sobre términos generales, un
sustantivo que me ayude a identificar que está siendo afectado y por último un
verbo que es el que indique la acción que queremos hacer.
2. Clasificación ITIL (Information Technology Infrastructure Library):
El soporte inicial
es determinar qué tipo de soporte necesita el cliente o usuario. La
clasificación determina el soporte inicial que el cliente o usuario requiere y
esto significa que la primera entrada en la clasificación taxonómica debe
indicar el tipo de trabajo a realizar; Debe definir claramente cómo debe
responder la organización de TI (no quién debe responder en la organización).
Por estas razones,
ITIL proporciona un ejemplo de esto y etiqueta el primer elemento de su taxonomía
de clasificación como "Tipo". La entrada Tipo describe la
amplia participación funcional requerida para apoyar al cliente o usuario. Después
de establecer el primer elemento, "Tipo", el siguiente
elemento, "Categoría", cambia basado en el Tipo. Por ejemplo,
considerando una Solicitud de Servicio para ayuda y orientación sobre una
aplicación de software, una clasificación bien formada podría ser (usando la
taxonomía de ITIL):
En este caso del ITIL lo resumimos en: que es lo que se solicita, el tipo de solicitud, que acción se ejecuta y sobre que lo estamos haciendo.
Service Request | Help User | Desktop Application
Olores del software
Cuando hablamos de calidad del software siempre hacemos
mención a cosas como patrones de diseño, anti-patrones, métricas de calidad,
etc; conceptos que tienen una aplicación concreta. En esta sección comentaremos
sobre los olores de software. En la actualidad, la actividad de programación de
aplicaciones de software exige que, quienes llevan a cabo la programación,
tengan presente que temprano o tarde, su código será sujeto de mantenimiento
producto de extensiones o cambios en los requerimientos del negocio.
¿Olor? Cuando
desarrollamos un software, siempre lo hacemos de la mejor manera que sabemos.
Pero ¿qué ocurre cuando ese desarrollo lleva un tiempo? Pues que ya sea por
desmotivación, prisas, cambios de alcance, cambios de diseño, este software se
oxida, se pudre… y, entonces, huele. Un olor, se puede definir, como
situaciones donde ciertas características del código hacen que sea difícil o
problemático su entendimiento, mantenimiento y pruebas. Los olores de software
son indicadores que apuntan y presagian que, la falta de atención a problemas
de diseño que puede causar dificultades en la evolución y mantenimiento del
software.
La presencia de olores puede pasar una cara factura a las
compañías que hacen uso de software para apalancar sus operaciones. Desde 1950
y hasta la fecha, las compañías han venido incrementando los porcentajes de
personal dedicado a labores de mantenimiento de software (cerca de un 80%).
Esta tendencia ejerce presión sobre las actividades de mantenimiento de
software. Las dificultades encontradas, producto del mantenimiento, pueden
convertirse en una situación problemática para las empresas que apuntan a
responder, de forma oportuna, a las necesidades cambiantes de sus clientes y
usuarios.
Existe una clasificación de 7 términos que nos puede indicar
si nuestro software se está oxidando.
1. Rigidez: Un
software es rígido cuando es difícil cambiarlo. Por ejemplo, si un cambio
aparentemente sencillo supone más tiempo del esperado. Posibles razones serían:
un simple cambio conlleva una cascada de cambios asociados, el código está tan
enrevesado que no se sabe cómo se debería cambiar, etc
2. Fragilidad: Un
software es frágil cuando un simple cambio provoca que se rompa en varios
sitios con poca relación. Por ejemplo, se modifica una clase css para cambiar un
color y se rompe una tabla que contiene un informe.
3. Inmovilidad: La
inmovilidad hace referencia a la dificultad de volver a usar partes de
código/módulos en otros sistemas. Tenemos un software que hace muchas cosas
maravillosas pero está tan acoplado al proyecto al que pertenece que el
esfuerzo que habría que realizar para usarlo de nuevo es demasiado grande.
4. Viscosidad: Por
lo general, siempre hay maneras de modificar un software. Para este olor las
vamos a englobar en 2: la manera en la que entra parte del diseño de la
aplicación y los workarounds (o hacks). La viscosidad hace referencia a la
facilidad que tiene un software de cambiar. Si es fácil realizar cambios que
mantengan el diseño, un software es poco viscoso. Sin embargo, si es más fácil
realizar workarounds significa que el software es viscoso.
5. Repeticiones innecesarias: Comúnmente llamado
copy-paste. Cuando por dejadez o inexperiencia copiamos y pegamos el mismo
trozo de código. Esto provoca que cuando que haya que realizar un cambio, éste
se tenga que realizar en varios sitios con lo que multiplica el esfuerzo.
Además, incrementa la posibilidad de que cuando corregimos un bug, no lo
hagamos correctamente.
6. Opacidad: Este
olor hace mención a lo complejo o difícil que puede ser leer o entender un código.
Cuanto más difícil de entender, más opaco se considera.
7. Complejidad innecesaria: Por último, este olor hace
referencia a cuando realizamos el código de manera demasiado compleja
intentando anticiparnos a los futuros cambios. El software ha de ser mantenible,
pero si aplicamos demasiadas abstracciones para prepararnos al futuro, puede
ser que lo que consigamos sea hacerlo demasiado complejo y caer en los olores
anteriores.
Conclusión
Es muy interesante notar como todo lo que se relaciona con el control de calidad, a
decir verdad, a mi criterio este es indispensable para lo que es el desarrollo
de un proyecto, ya que si no se tiene un control del software lo más probable
es que nos de problemas en un futuro, además que esto se verá reflejado en
gastos. Por otro lado, tenemos lo que es la comprobación de características de
calidad, que pues gracias al ISO 9126-1, el cual nos da una idea de cuales características
debe cumplir un proyecto para que puede considerarse dentro la norma, además es
muy importante tener en cuenta todas las características de este y manejarlas
de la mejor manera, lo que beneficia claro está, ya que poder tener un buen
control de calidad ayuda mucho a los proyectos, además que es de obligación entregar
un proyecto que cumpla con todos los requerimiento solicitados por el cliente, así
como que este no presente errores cada día y pues también que sea lo más
eficiente posible con el fin de entregar un producto que sea de la más alta
calidad y no algo que más bien sea un desastre total. También comentamos otros
temas como la clasificación de defectos en los cuales encontramos el CIT y el
ITIL que ciertamente son temas muy interesantes y a su vez complejos a la hora
de manejar lo que son los defectos y por
ultimo mencionamos lo que son los olores de software algo que sinceramente es
muy común en los programadores principiante, pero si estos olores se logran
evitar, la posibilidad de desarrollar un software de calidad es muy alta y por
ende al final del desarrollo tendremos como resultado un software de calidad
que cumple con todas las expectativas del cliente y del programador.
Referencias Bibliográficas
Arroyo, F. (23 de mayo de
2016). Los 7 olores del software. Obtenido de
https://www.beeva.com/beeva-view/desarrollo/los-7-olores-del-software/
Chavarria, L. J. (28 de
noviembre de 2016). CAMTIC. Obtenido de
http://www.camtic.org/hagamos-clic/presencia-de-olores-de-software-en-la-formacion-de-competencias-de-programacion/
Control de calidad del
software.
(s.f.). Obtenido de http://www.angelfire.com/my/jimena/ingsoft/calidad.htm
EcuRed. (s.f.). Obtenido de
Sistema de control de calidad:
https://www.ecured.cu/Sistema_de_control_de_calidad_de_software
ISO 9126 Software Quality
Characteristics. (s.f.). Obtenido de http://www.sqa.net/iso9126.html
JGS, i. (2 de marzo de
2014). infoxicadoblog.wordpress.com. Obtenido de
https://infoxicadoblog.wordpress.com/2014/03/02/aseguramiento-de-la-calidad-en-la-construccion/
L, J. H. (s.f.). Control
de calidad en el software. Obtenido de
https://repository.icesi.edu.co/biblioteca_digital/bitstream/item/4008/1/Control_calidad_software.pdf
Marquis, H. (23 de julio
de 2010). Dity. Obtenido de
http://www.itsmsolutions.com/newsletters/DITYvol6iss27.htm
Párraga, J. M. (s.f.). Control
de calidad del software. Obtenido de
https://jorgemontanoblog.files.wordpress.com/2011/10/control-de-calidad-de-software-final.pdf
Quality characteristics
and subcharacteristics. (s.f.). Obtenido de
http://www.issco.unige.ch/en/research/projects/ewg95/node55.html
Offutt, P. A. (2008). INTRODUCTION
TO SOFTWARE TESTING. New York: CAMBRIDGE UNIVERSITY PRESS.
Comentarios
Publicar un comentario