Gestión de Calidad de Software
¿Que es la calidad del software?
- La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.
Elementos que permiten evaluar la calidad en el software:
Los factores de calidad que afectan a la calidad del software se dividen en dos grandes grupos:
- Los que miden directamente (defectos descubiertos en las pruebas).
- Los que se miden directamente (facilidad de uso o de mantenimiento).
En cada caso debe presentarse una medición. Se debe comparar el software con algún conjunto de datos y obtener así algún indicio sobre la calidad. McCall, Richards & Walters (1977), propusieron una clasificación de los factores que afectan directamente a la calidad del software. Estos factores se muestran en la figura 2.30 En ella se concentran tres aspectos importantes de un software:- Características operativas.
- Capacidad para experimentar cambios.
- Capacidad para adaptarse a nuevos entornos.
A continuación se describen los factores que propone McCall, Richards & Walters.- Corrección.
El grado en que el programa cumple con su especificación y satisfacer los objetivos que propuso el cliente.- Confiabilidad.
El grado en que se esperaría que un programa desempeña su función con la precisión requerida.- Eficiencia.
La cantidad de código y de recursos de cómputo necesarios para que un programa realice su función.- Integridad.
El grado de control sobre el acceso al software o los datos por parte de las personas no autorizadas.- Facilidad de uso.
El esfuerzo necesario para aprender, operar y preparar los datos de entrada de un programa interpretan la salida.- Facilidad de mantenimiento.
El esfuerzo necesario para localizar y corregir un error en un programa.- Flexibilidad.
El esfuerzo que demanda probar un programa con el fin de asegurar que realiza su función.- Portabilidad.
El esfuerzo necesario para transferir el programa de un entorno de hardware o software a otro.- Facilidad de reutilización.
El grado en que un programa o partes de él pueden reutilizarse en otras aplicaciones(en relación con el empaquetamiento y el alcance de las funciones que realiza el programa).- Interoperabilidad.
El esfuerzo necesario para acoplar un sistema con otro.Es difícil y en algunos casos imposible, desarrollar medidas directas de estos factores de la calidad. En realidad, muchas de las métricas que definen McCall et al. Sólo se miden de forma subjetiva. Ya que es común que las métricas adquieran la forma de una lista de comprobación que se emplea para “asignar una graduación” a atributos específicos del software. Vega et al. (2008), proponen un modelo con métricas distintas al propuesto por McCall y que ha sido utilizado y comprobado en distintos proyectos de desarrollo de software. Los factores que conforman al modelo y su descripción, se presentan a continuación.- Corrección.
El grado en que un producto de software satisface sus especificaciones y consigue los objetivos de la misión encomendada por el usuario.- Confiabilidad.
El grado en que se puede esperar que un producto de software lleve a cabo sus funciones esperadas con la precisión requerida.- Eficiencia.
La cantidad de recursos computacionales y de código requeridos por un producto de software para llevar a cabo las funciones encomendadas.- Integridad.
El grado en que puede controlarse (facilitar y restringir) el uso y acceso al software y a los datos, tanto al personal autorizado como al no autorizado.- Facilidad de uso.
El esfuerzo requerido para aprender, trabajar, preparar la entrada e interpretar la salida de un producto de software.- Facilidad de mantenimiento.
El esfuerzo necesario para localizar y corregir los errores en un producto de software.- Flexibilidad.
El esfuerzo requerido para modificar un producto de software una vez que se encuentra ya liberado o en producción, esto es, una vez que el usuario esté haciendo uso de él.- Facilidad de prueba.
El esfuerzo requerido para probar un producto de software, de tal forma que se asegure que realiza las funciones especificadas por el usuario.- Potabilidad.
El esfuerzo requerido para transferir un producto de software de una plataforma (entorno de hardware y software) a otra.- Reusabilidad.
El grado en que un producto de software (o alguna de sus partes) pueda volver a ser utilizado en otras aplicaciones, aún cuando la funcionalidad de la misma cambie.- Facilidad de interoperación.
El esfuerzo requerido para lograr que un producto de software trabaje con otro, compartiendo recursos.- Ejemplo de calidad de software:
Ejemplo 1: procesos
- Como regla general, tener procesos y reglas ayuda a los equipos de desarrollo a trabajar más eficientemente. Por una parte, facilita que nos concentremos en lo que estamos haciendo y no en el cómo . Por otra, facilita la automatización.
Sin embargo, los procesos y las reglas pueden quedarse obsoletos. Por ejemplo, digamos que uno o dos miembros del equipo causan problemas con la integración continua: con frecuencia hacen cambios que hacen fallar a la batería de pruebas y no tienen disciplina para escribir pruebas. Ante esta situación, decidimos que cada cambio enviado al repositorio debe contener alguna modificación a algún fichero de pruebas. La medida funciona más o menos bien, esos miembros del equipo empiezan a tomarse las pruebas más en serio, y así aumentamos la productividad del equipo con ella.
Ahora bien, todas las reglas tienen partes buenas y partes malas, como todo. Esta medida concreta puede ser molesta cuando simplemente queramos arreglar una falta de ortografía en un comentario, actualizar la documentación, o reformatear el código (ya que nuestro cambio no modificaría ningún fichero de pruebas). Por tanto, si en algún momento esos miembros del equipo se marchan o llegan al punto de escribir buenas pruebas y no necesitar la anterior medida, puede que llegue el momento de eliminar esta regla. Mantener y seguir reglas simplemente porque «siempre han funcionado» es caer en la tentación de seguir el «culto al cargo». - Una de las constantes en los artículos de este libro es el uso de pruebas automáticas. Aunque es desde luego una de las prácticas más recomendadas y útiles, también es verdad que con frecuencia tenemos que trabajar con código legado (es decir, sin pruebas). En esos casos, ¿qué hacemos?
Ejemplo 2: automatización de pruebas
Por ejemplo, digamos que nos unimos a un equipo que no tiene cultura de pruebas automáticas, y vamos retrasados con la siguiente entrega. Una parte concreta del código está dando bastantes problemas, y las pruebas manuales (la manera en la que el equipo prueba el código) no están encontrando suficientes fallos, o no lo suficientemente pronto. Aunque automatizar las pruebas es probablemente la mejor idea a largo plazo, no hay ninguna regla exenta de excepciones . Puede que el equipo no tenga suficiente experiencia en pruebas automáticas como para que introducirlas mejore la situación antes de la entrega. Puede que las partes críticas del proyecto en el que trabajamos no sean fáciles de probar de manera fiable con pruebas automáticas, y empeñarnos en poner énfasis en éstas a toda costa no ayude al equipo en el contexto de esta entrega. Puede que la tensión de ir retrasados haga al equipo ser «optimistas» al escribir pruebas, y las pruebas den un falso sentido de seguridad. Puede que los que toman las decisiones no estén convencidos, y que a corto plazo no valga la pena gastar tiempo y energía en convencerlos. Y puede que hayamos convencido a los que toman las decisiones, pero el equipo no esté convencido, e intentar forzarlos a escribir pruebas sólo vaya a provocar un bajón de moral y un conjunto de pruebas automáticas de muy mala calidad.
Y si por la razón que sea llegamos a la conclusión de que intentar implantar pruebas automáticas para la próxima entrega no es una buena idea, ¿qué podemos hacer? Una de las posibilidades es empezar haciendo más efectivo al equipo sin cambiar radicalmente su filosofía de trabajo. Por ejemplo, puede que tras analizar la situación descubramos que esa parte del programa es más difícil de probar de manera manual porque no da suficiente información. Quizás añadir una opción «escondida» que haga esa parte menos opaca puede ser suficiente hasta la fecha clave. O simplemente mejorar la comunicación entre los miembros del equipo. Porque, entre otras cosas, siempre es positivo respetar la manera de trabajar de un equipo («que siempre ha funcionado»): no sólo mejora las relaciones entre sus miembros, sino que ayuda a ganarse su respeto y atención, que serán necesarios más tarde para poder implementar cambios grandes como desarrollo dirigido por pruebas o simplemente escribir pruebas automáticas. Y mientras tanto, podemos ir enseñando poco a poco al equipo a automatizar las pruebas para ir cambiando a un modelo (posiblemente) más escalable.Cuando se desarrolla software normalmente se tienen especificaciones. Pueden ser formales (un documento) o informales (el conocimiento compartido del equipo). El objetivo de las especificaciones es poder concentrarse en la solución técnica sin tener que estar preguntando continuamente a los clientes o al resto del equipo sobre el enfoque a la hora de resolver el problema. Pero, de nuevo, las especificaciones son sólo una herramienta, y cumplir más a rajatabla con las especificaciones no tiene por qué garantizar una mayor calidad del proyecto una vez completado.
Digamos que estamos desarrollando el software que conduce un coche automático. Uno de los requisitos del coche es que pare en los pasos de peatones cuando detecte que una persona está cruzando. Sin embargo, mucha gente no cruza por los pasos de peatones, así que el coche sería mucho más seguro si no dependiera de éstos, sino que pudiera detectar por sí mismo si tiene algo delante que podría llegar a atropellar. Es decir, las especificaciones son una herramienta muy útil, pero nunca son el objetivo final del desarrollo de software. Las personas que escriben las especificaciones cometen errores, las condiciones del proyecto cambian, etc. Mantener siempre el escepticismo y una visión más completa de nuestros objetivos, y no dejarnos llevar por el «no es mi trabajo», el «no me pagan por esto» o el «yo sólo hago lo que me dicen», es mucho más importante que cumplir la especificación diligentemente. Dicho de otra manera, nuestro trabajo no es escribir software que cumple a rajatabla una descripción textual de un problema. Es hacer software útil y resolver problemas.Una parte importante de la calidad es, por supuesto, tener código mantenible. El código mantenible normalmente se consigue con código legible y un diseño simple. Sin embargo, y como muchas otras cosas, estos dos aspectos son sólo una herramienta para conseguir calidad: un código legible y un diseño simple hacen que el código contenga, de media, menos errores, y éstos serán más fáciles de detectar y corregir.
Ahora, ¿qué pasa si en algún momento las necesidades del proyecto chocan con nuestro (por ahora) diseño simple? La respuesta es obvia: las necesidades del cliente son el objetivo número uno, y lo demás se tiene que adaptar a éstas. Intentar adaptar las necesidades del cliente al diseño de la aplicación es, en la mayoría de los casos, un error. Si para resolver el nuevo problema hacemos el diseño menos lineal o más complejo, no estamos «haciendo una chapuza porque el cliente no tiene las ideas claras» o porque «no sabe cómo funciona la aplicación»: estamos ayudando a resolver un problema real. Si eso implica hacer una «chapuza» en el código, eso probablemente significa que tenemos que revisar el diseño de nuestra aplicación. No porque lo hayamos hecho mal desde el principio, sino porque hemos descubierto nuevos requisitos, o refinado los que teníamos.Anexos
https://es.wikipedia.org/wiki/Calidad_de_software
http://www.eumed.net/tesis-doctorales/2014/jlcv/calidad-software.htm- https://emanchado.github.io/camino-mejor-programador/html/ch07.html
No hay comentarios.:
Publicar un comentario