CALIDAD

Al hablar de problemas relacionados con la calidad del software no tenemos una definicin
precisa de lo que sta significa. Sin una definicin clara, concisa y medible de lo que es la calidad
del software, no podemos tomar buenas decisiones de negocio respecto del uso de los recursos,
ni en qu reas mejorar la calidad, ni que herramientas y tcnicas utilizar para mejorar la calidad.
Hay diferentes puntos de vista para definir calidad de software.

Desde el punto de vista del cumplimiento de los requerimientos Roger Pressman define la
calidad de software como:

El cumplimiento de los requerimientos funcionales y de performance explcitamente

definidos, de los estndares de desarrollo explcitamente documentados y de las
caractersticas implcitas esperadas del desarrollo de software profesional.

Desde el punto de vista del cliente o usuario Watts Humphrey dice:

El foco principal de cualquier definicin de calidad de software debera ser las necesidades del
cliente.

Crosby al igual que Pressman define la calidad como conformidad con los requerimientos.
Mientras uno puede discutir la diferencia entre requerimientos, necesidades y deseos, la
definicin de calidad debe considerar la perspectiva de los usuarios. Entonces las preguntas
claves son Quines son los usuarios?, Qu es importante para ellos? Y Cmo sus prioridades
se relacionan con la manera en que se construye, empaqueta y se da soporte al producto?

Al Davis define calidad del software como:

La calidad no se trata de tener cero defectos o una mejora medible de la proporcin de

defectos, no se trata de tener los requerimientos documentados. No es ms ni menos que
satisfacer las necesidades del cliente (por ms que las necesidades estn o no correctamente
documentadas)

Finalmente, desde estas dos perspectivas el glosario de la IEEE para la ingeniera de software
define la calidad del software como:

El grado con el cual un sistema, componente o proceso cumple con los requerimientos y con
las necesidades y expectativas del usuario.
ASEGURAMIENTO DE LA CALIDAD
Historia

En los aos 50, el software comenz a encontrar su camino dentro de los sistemas del DoD (del
ingls Deparment of Defense of USA). Usualmente estos proyectos estaban muy alejados de la
planificacin, se pasaban del presupuesto y tenan muchos problemas tcnicos. Frecuentemente
no funcionaban como se esperaba y muchos proyectos eran cancelados antes de ser entregados.
Durante este periodo los contratistas - 27 - desarrollo de para el software a menudo hacan
estimaciones muy optimistas sobre el estado del desarrollo del software.

El DoD normalmente no era notificado de los problemas en la planificacin, en la gestin del

presupuesto y de problemas tcnicos hasta muy avanzado el proyecto, cuando ya no eran
capaces de entender los problemas ni de evaluar el impacto de stos. Para intentar resolver este
problema se estableci la Verificacin y Validacin Independientes (IV&V del ingls Independent
Verification and Validation), un proceso de ingeniera que empleaba metodologas rigurosas
para evaluar la correctitud y calidad del software a lo largo de su ciclo de vida. El primer software
en usar IV&V fue el programa del misil atlas a finales de los aos 50. Desde el proyecto atlas se
ha recolectado mucha informacin que indica que los proyectos con IV&V se realizan o ejecutan
mucho mejor que los proyectos sin IV&V. Con el tiempo el rol del IV&V se convirti crtico. La
actividad que llamamos SQA evoluciona directamente de la Verificacin y Validacin
Independientes(IV&V), muchas de las tareas que asociamos con SQA son originarias de IV&V.
Luego durante los aos 70 la actividad de desarrollo de software comenz a expandirse y las
compaas de desarrollo de software fueron experimentando los mismos pobres resultados que
las agencias gubernamentales (DoD, NASA etc.) en las dcadas tempranas. Las compaas tenan
dificultad para entregar el software dentro de los plazos, presupuesto y calidad planificados.
Varios proyectos desarrollados entre 1980 y 1990 fueron desastrosos, muchos excedan
ampliamente el presupuesto y la planificacin o entregaban software de baja calidad que no se
poda usar. Durante los 80 esta experiencia se convirti en lo que conocemos como crisis del
software, el tiempo consumido en el mantenimiento exceda el tiempo insumido en la
construccin de nuevos productos de software. Luego de la crisis del Software en los aos 80,
SQA evoluciono hacia una herramienta que las compaas de desarrollo de software utilizaban
para identificar de forma temprana los problemas de calidad en el proceso de desarrollo.
Mientras SQA era visto como un pequeo paso dentro del proceso del desarrollo del software,
muchos jefes de - 28 - proyectos vieron beneficios cuantificables a partir de integrar SQA dentro
del proceso de desarrollo de software. En los 90 varias compaas de software ya tenan
funciones de SQA dentro de sus organizaciones.

DEFINICION

Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la calidad como

Una gua planificada y sistemtica de todas las acciones necesarias para proveer la evidencia
adecuada de que un producto cumple los requerimientos tcnicos establecidos. Un conjunto
de actividades diseadas para evaluar el proceso por el cual un producto es desarrollado o
construido.

Daniel Galin define SQA como

Un conjunto, sistemtico y planificado, de acciones necesarias para proveer la evidencia

adecuada de que el proceso de desarrollo o mantenimiento de un sistema de software cumple
 los requerimientos tcnicos funcionales tan bien como los requerimientos gerenciales para
cumplir la planificacin y operar dentro del presupuesto confinado.

Desde el punto de vista de la visibilidad, el SEI define SQA como

El aseguramiento de la calidad del software provee claro control del proceso que est siendo
usado por el proyecto y del producto que se est construyendo.[8]

Para certificar madurez de procesos, hay que evidenciar que uno aplica un cierto proceso y
para esto se deben registrar las distintas actividades de tal proceso de desarrollo, como ste es
el objetivo que persigue el software a desarrollar como parte de esta tesis

Atributos No Observables

Usabilidad
La usabilidad se define como la capacidad de un software de ser comprendido,
aprendido, usado y ser atractivo para el usuario, en condiciones especficas de uso. Para
el estndar ISO 9241, que trata los requerimientos ergonmicos, la usabilidad es el
grado en el que un producto puede ser utilizado por usuarios especficos para conseguir
objetivos especficos con efectividad, eficiencia y satisfaccin en un determinado
contexto de uso. WICC 2012 656 2012 XIV Workshop de Investigadores en Ciencias de
la Computacin Los mtodos de evaluacin de usabilidad pueden ser heursticos o
empricos. Los heursticos (tambin llamados no empricos), implican la participacin de
expertos especialistas en usabilidad [9]. Los empricos constan de tcnicas e
instrumentos que requieren de la participacin de usuarios

Portabilidad
Es la habilidad del sistema para ser ejecutado en diferentes ambientes de cmputo.
Estos ambientes pueden ser hardware, software o una combinacin de los dos
(Kazman et. al., 2001).

Re-Usabilidad
Es la capacidad de disear un sistema de forma tal que su estructura o parte de sus
componentes puedan ser reutilizados en futuras aplicaciones (Bass et. al. 1998).

http://sedici.unlp.edu.ar/bitstream/handle/10915/3956/3_-
_Aseguramiento_de_la_calidad_del_software.pdf?sequence=11

http://sedici.unlp.edu.ar/bitstream/handle/10915/19202/Documento_completo.pdf%3Fseque
nce%3D1

https://sophia.javeriana.edu.co/~cbustaca/docencia/DEAS-2017-
01/presentaciones/AtributosCalidadSoftware.pdf