01 Calidad Del Software

BISOFT-32
Calidad,
verificación y
validación de
software
Temas
• Calidad
• Calidad del software
Requerimientos y calidad
• Calidad y factores económicos.
• La calidad como factor de competitividad
Características de calidad Aseguramiento de
la calidad
• Control de la calidad Responsabilidades en
torno a la calidad
• Factores de éxito en la administración de la calidad del
software
• Beneficios reales del aseguramiento de la calidad
© Copyright Cenfotec S.A. 2000..2018

Q
Q
Qué es la calidad?
"La totalidad de las características de un producto o

servicio, que tienen que ver con su capacidad de
satisfacer necesidades enunciadas o implícitas"
ISO 8402
The International Standard Quality Vocabulary

Q
Calidad – desde la manufactura
• Construido con materiales seleccionados

• Construido acorde con estándares y tolerancias
• Construido por un proceso repetible
Calidad del proceso Calidad del producto
Monitoreada por Control estadístico de la calidad

Q
Visiones
• Visión del usuario
– grado de adecuación al propósito
• Visión del productor
– conformidad con la especificación
• Visión del producto
– ligada a características inherentes del producto
• Visión basada en valor
– ¿cuánto está dispuesto el cliente a pagar?
• Visión trascendental
– puede ser reconocida pero no definida

Vistas de calidad - Garvin
1. Basada en el valor
(diseño s/ precio) 5. Transcendente
Calidad por costo (excelencia innata)
Reputación
Calidad 4. Basada en el producto

2. Basada en el usuario (obtener lo que se paga)
(adecuación al propósito) Mismo producto –
Visión del cliente más características
3. Basada en el proceso
(conforme a los requerimientos)
Satisfacer especificación del cliente

Calidad - comparativa
La calidad es el grado de excelencia que posee una cosa
“Se ve bien” “Buen valor por el dinero” “Confiable”

Q
Calidad - cuantitativa
Grado de conformidad, grado de diferencia con un
ideal. Niveles aceptables de calidad

Calidad – adecuación a propósito
Calidad del producto = utilidad y practicidad

Dificultades con la calidad
• La calidad es relativa:
– No hay valores mínimos o máximos para la
calidad (¿Hay un carro absolutamente mejor o
peor?)
– Necesidad de contexto de uso (¿4x4, familiar?
¿todo terreno, poco consumo, compacto para
estacionar en ciudad?)
16
• La calidad es multidimensional:
– Nos puede interesar el precio, la confiabilidad,
mantenibilidad, facilidad de uso, entre otros.
Muchos factores pueden contribuir a la calidad
– Las dimensiones pueden ser dependientes –
cualidades como confiabilidad y precio no son
independientes. Lograr mayor confiabilidad o
facilidad de uso tiende a costar más
17
© Copyright Cenfotec S.A. 2000..2018 © Copyright Cenfotec S.A. 2000..2017
Debe Buen
trabajar por rendimiento
largo tiempo Fácil de usar
Adaptado a mis
necesidades
Sin pulgas
específicas
ni defectos

• Hay frecuentemente restricciones sobre la

calidad:
• Producir un sistema 100% confiable puede ser
imposible tecnológicamente. Conseguir uno 90%
confiable puede serlo, pero pasar al 99% de
confiabilidad puede costar 100 veces más. De ahí la
importancia de establecer los mínimos aceptables y
el máximo presupuesto. Lograr calidad requiere
soluciones intermedias – los niveles realistas deben
ser negociados entre las partes (cliente, team)

Calidad de software
• Objetivo último de la Ingeniería de Software:

producir software de calidad
• Calidad engloba todo el proceso, y está

determinada por factores directos e indirectos
• Calidad es un concepto complejo y multifacético,

que puede describirse desde diversas perspectivas

Una definición
“Grado con el cual el cliente o usuario percibe que

el software satisface sus expectativas”
IEEE 729-83

Calidad de sistemas
• Calidad = satisfacción del usuario

• Satisfacer los requerimientos del usuario
• Características buenas de rendimiento
• Cumplimiento de estándares explícitamente
documentados
• Otras características implícitas del trabajo
profesional
Pressman

Otra caracterización (CSQE)
• Calidad del software: satisfacción de

requerimientos explícitos de funcionalidad y
rendimiento, estándares de desarrollo
explícitamente documentados, y características
implícitas como mantenibildad y modularidad.

Beneficios para el cliente
• Satisfacción del cliente

• Mayor confiabilidad del software
• Reducción de errores al operar el software
• Satisfacción de los requerimientos del usuario
• Disminución de impactos operativos /
económicos

Beneficios para la organización
• Se satisfacen los requerimientos del cliente

• Estabilidad de los requerimientos
• Verificación de que los requerimientos para las
diversas características han sido implementados
• Los procesos se aplican de manera consistente
• El proceso mejora al transcurrir el tiempo
• Se produce mejor software a menor costo *

Calidad – Proceso Unificado
• “La característica de haber demostrado la

producción de un producto que satisface o excede
requerimientos acordados - medidos de acuerdo
con criterios y medidas acordados - y que es
producido por un proceso acordado”
Kruchten, The Rational Unified Process

Calidad del producto
• La calidad del producto principal que se produce

(software o sistema) y los elementos que lo
componen (componentes, subsistemas,
arquitectura, etc.)
Kruchten

Calidad del proceso
• Grado en el cual se ha implementado y respetado

un proceso aceptable (incluyendo mediciones y
criterios de calidad) en la producción de un
producto
• También tiene que ver con la calidad de los
artefactos (planes, diseños, pruebas, etc.)
producidos para apoyar el producto principal. Se
les aplica los mismos conceptos de calidad de
producto
Kruchten

Por qué calidad?
• Es un asunto de competitividad
• Es esencial para la supervivencia
• Es esencial para mercadeo internacional
• Es eficaz respecto del costo
• Retiene clientes e incrementa utilidades
• Es característica de empresas e instituciones de
clase mundial

© Copyright Cenfot ec S.A. 2000..230017
Modelo de calidad de McCall
Facilidad de Mantenimiento Portabilidad

(¿Puedo corregirlo?) (¿Podré usarlo en otra máquina?)
Reutilizabilidad
Flexibilidad
(¿Podré reutilizar alguna parte del software?)
(¿Puedo cambiarlo?)
Revisión
Transició Interoperabilidad
Facilidad de Prueba n (¿Podré hacerlo interactuar
(¿Puedo probarlo?) con otro sistema?)
Operación
Correctitud (¿Hace lo que quiero?)
Confiabilidad (¿Lo hace de forma confiable todo el tiempo?)
Eficiencia (¿Se ejecutará en mi hardware lo mejor que pueda?)
Integridad (¿Es seguro?)
Facilidad de uso (¿Está diseñado para ser usado?)

Modelo de McCall
• Operación del producto – el software existente corre

sin problemas
• Revisión del producto – facilidad de cambio del
software y de la reparación de defectos
• Transición del producto – grado en el cual el software
puede ser utilizado en más de un ambiente (portabilidad),
extensión en la cual partes del software pueden ser re-
aplicadas (reutilización), el grado en el cual el sistema
puede comunicarse con otros sistemas (interoperabilidad)

Características de la calidad
• Externas: aquellas perceptibles por el usuario del

producto de software
• Internas: aquellas relevantes para los
constructores del producto de software

• Funcionalidad
Existencia de un conjunto de funciones (servicios)
para satisfacer necesidades.
• Utilizabilidad
Esfuerzo necesario para el uso eficaz del sistema.

• Eficiencia
Relación entre rendimiento y recursos utilizados.
• Confiabilidad
Capacidad para mantener el nivel de desempeño
bajo condiciones enunciadas y períodos de tiempo
enunciados.

• Corrección (“correctitud”)
Grado en el cual un sistema está libre de defectos
en su especificación, diseño e implementación.
• Adaptabilidad
La extensión en la cual el sistema puede ser
usado, sin modificaciones, en aplicaciones y
ambientes distintos de aquellos para los cuales fue
diseñado específicamente.

• Integridad
Grado en que se puede controlar el acceso al
sistema (software y/o datos) por agentes (personas
o sistemas) no autorizados.
• Comprobabilidad o auditabilidad
Facilidad para determinar que el sistema hace lo
requerido, ni más ni menos.

• Exactitud
Grado en el cual un sistema, tal cual fue
construido, está libre de errores – particularmente
en cuanto a salidas cuantitativas.
• Robustez
Grado en el cual un sistema continúa funcionando
en presencia de datos de entrada incorrectos o
condiciones ambientales límite.

• Mantenibilidad
Esfuerzo necesario para realizar modificaciones
especificadas.
• Reutilizabilidad
Grado en que puede ser utilizado de nuevo un
sistema, o parte de él, en otros sistemas.

• Portabilidad
Capacidad de transferir un sistema de un ambiente
operativo a otro.
• Interoperabilidad
Esfuerzo requerido para integrar o acoplar un
sistema con otro.

• Flexibilidad
Facilidad para modificar un sistema para usos o
ambientes distintos de aquellos para los cuales fue
diseñado específicamente.
• Legibilidad
Facilidad para leer y entender el código fuente de
un sistema – especialmente en el nivel de
enunciados detallados.

• Comprobabilidad
Grado en el cual se pueden hacer pruebas sobre
un sistema; grado en el cual se puede verificar que
el sistema satisface sus requerimientos.
• Comprensibilidad
Facilidad con la cual se puede comprender un
sistema en los niveles organizativo (arquitectónico)
y de detalle. Coherencia.

Conflictos entre factores McConnell
Cómo un
Integridad
Eficiencia
Utilizabili-
Robustez
Adaptabili-
Confiabili-
factor de
‘Correcti-
Exactitud
dad
abajo afecta
un factor a la
tud’
dad
dad
derecha
‘Correctitud’
    
Utilizabilidad
  
McConnell
Eficiencia
      
Confiabilidad
     
Integridad
  
Adaptabilidad
  
Exactitud
     
Robustez
       
S.A. 2000..2017
Modelo de calidad ISO 9126
ISO 9126 >>> ISO 25000 SQuaRE
Atributos de la calidad
• Formas de medir requerimientos no
funcionales
– Rendimiento:
• Transacciones procesadas por segundo
• Tiempo de respuesta a la acción del usuario
– Confiabilidad:
• Tasa de ocurrencia de fallos
• Media del tiempo de fallo
– Disponibilidad:
• Probabilidad de fallo en regímenes de alta demanda
• Formas de medir requerimientos no

funcionales
– Usabilidad:
• Tiempo que toma aprender el 80% de la funcionalidad
• Número de errores realizados por los usuarios en un
periodo de tiempo.
– Robustez:
• Tiempo de re-inicio luego de un fallo del sistema
– Portabilidad:
• Número de sistemas destino en los que puede utilizarse

• Usabilidad:
– Grado en el que un producto puede ser utilizado
por usuarios específicos con efectividad,
eficiencia y satisfacción en un determinado
contexto de uso.
– Atributos:
• Facilidad de Aprendizaje
• Eficiencia
• Recuerdo en el tiempo
• Tasa de errores
• Satisfacción
Análisis con ISO 9126

Funcionalidad ISO-9126
• Capacidad del producto de software para proporcionar funciones que
cubren las necesidades explícitas e implícitas en un determinado
contexto de uso.
– Adecuación: Capacidad del producto software para proporcionar un
conjunto apropiado de funciones para tareas y objetivos de usuario
especificados.
– Exactitud: Capacidad del producto software para proporcionar los
resultados o efectos correctos o acordados, con el grado necesario
de precisión.
– Interoperabilidad: Capacidad del producto software para
interactuar con uno o más sistemas especificados.
– Seguridad de acceso: Capacidad del producto software para
proteger información y datos de manera que las personas o
sistemas no autorizados no puedan leerlos o modificarlos, al tiempo
que no se deniega el acceso a las personas o sistemas autorizados
– Cumplimiento funcional: Capacidad del producto software para
adherirse a normas, convenciones o regulaciones en leyes y
prescripciones similares relacionadas con funcionalidad.
Fiabilidad ISO-9126
• Capacidad del producto de software de mantener un nivel
específico de rendimiento en un contexto determinado de
uso.
– Madurez: Capacidad del producto software para evitar
fallar como resultado de fallos en el software.
– Tolerancia a fallos: Capacidad del software para
mantener un nivel especificado de prestaciones en caso
de fallos software o de infringir sus interfaces
especificados.
– Capacidad de recuperación: Capacidad del producto
software para reestablecer un nivel de prestaciones
especificado y de recuperar los datos directamente
afectados en caso de fallo.
– Cumplimiento de la fiabilidad: Capacidad del producto
software para adherirse a normas, convenciones o
regulaciones relacionadas con al fiabilidad.
Usabilidad ISO-9126
• Capacidad del producto de software de ser entendido, aprendido, usado
y atractivo al usuario, en un contexto determinado de uso.
– Capacidad para ser entendido: Capacidad del producto software
que permite al usuario entender si el software es adecuado y cómo
puede ser usado para unas tareas o condiciones de uso
particulares.
– Capacidad para ser aprendido: Capacidad del producto software
que permite al usuario aprender sobre su aplicación.
– Capacidad para ser operado: Capacidad del producto software
que permite al usuario operarlo y controlarlo.
– Capacidad de atracción: Capacidad del producto software para ser
atractivo al usuario.
– Cumplimiento de la usabilidad: Capacidad del producto software
para adherirse a normas, convenciones, guías de estilo o
regulaciones relacionadas con la usabilidad.

Eficiencia ISO-9126
• Capacidad del producto de software de proporcionar un
rendimiento apropiado, en referencia a la cantidad de
recursos utilizados, bajo condiciones de uso específicas.
– Comportamiento temporal: Capacidad del producto
software para proporcionar tiempos de respuesta,
tiempos de proceso y potencia apropiados, bajo
condiciones determinadas.
– Utilización de recursos: Capacidad del producto
software para usar las cantidades y tipos de recursos
adecuados cuando el software lleva a cabo su función
bajo condiciones determinadas.
– Cumplimiento de la eficiencia: Capacidad del producto
software para adherirse a normas o convenciones
relacionadas con la eficiencia.
Mantenibilidad ISO-9126
• Capacidad del producto de software de ser modificado. Modificaciones
pueden incluir correcciones, mejoras o adaptación del producto de
software a cambios en el entorno, en requisitos y en especificaciones
funcionales.
– Capacidad para ser analizado: Es la capacidad del producto
software para serle diagnosticadas deficiencias o causas de los
fallos en el software, o para identificar las partes que han de ser
modificadas.
– Capacidad para ser cambiado: Capacidad del producto software
que permite que una determinada modificación sea implementada.
– Estabilidad: Capacidad del producto software para evitar efectos
inesperados debidos a modificaciones del software.
– Capacidad para ser probado: Capacidad del producto software
que permite que el software modificado sea validado.
– Cumplimiento de la mantenibilidad: Capacidad del producto
software para adherirse a normas o convenciones relacionadas con
la mantenibilidad.
Portabilidad ISO-9126
• Capacidad del producto de software para ser transferido de un entorno
a otro.
– Adaptabilidad: Capacidad del producto software para ser adaptado
a diferentes entornos especificados, sin aplicar acciones o
mecanismos distintos de aquellos proporcionados para este
propósito por el propio software considerado.
– Instalabilidad: Capacidad del producto software para ser instalado
en un entorno especificado.
– Coexistencia: Capacidad del producto software para coexistir con
otro software independiente, en un entorno común, compartiendo
recursos comunes.
– Capacidad para reemplazar: Capacidad del producto software para
ser usado en lugar de otro producto software, para el mismo
propósito, en el mismo entorno.
– Cumplimiento de la portabilidad: Capacidad del producto software
para adherirse a normas o convenciones relacionadas con la
portabilidad.
Calidad en uso – ISO-9126
• Definición: Capacidad del producto de software

para permitir a usuarios específicos conseguir
metas determinadas con efectividad,
productividad, seguridad y satisfacción en
contextos específicos de uso.

Calidad en uso – ISO-9126
• Efectividad: Capacidad del producto de software para
permitir a los usuarios alcanzar objetivos especificados
con exactitud y completitud, en un contexto de uso
especificado.
• Productividad: Capacidad del producto de software para
permitir a los usuarios gastar una cantidad adecuada de
recursos en relación con la efectividad alcanzada, en un
contexto de uso especificado.
• Seguridad física: Capacidad del producto de software
para alcanzar niveles aceptables del riesgo de hacer daño
a personas, al negocio, al software, a las propiedades o al
medio ambiente en un contexto de uso especificado.
• Satisfacción: Capacidad del producto de software para
satisfacer a los usuarios en un contexto de uso
especificado.
Análisis
• Ejemplos
– El sistema debe de mantenerse activo a pesar de que ocurra una
excepción no esperada en los módulos de carga al servidor en un 95%
de las transferencias al mes.
– El sistema debe de evitar en un 80% de las descargas del usuario la
pérdida del archivo por problemas de sobrecarga de datos del servidor
cada 6 meses.
– El sistema debe respaldar su información el domingo de 1am a 7am al
servidor de contingencia.
– El sistema debe de notificar al administrador por medio de un correo
electrónico en caso de que el proceso de respaldo falle por algún
motivo.
– El sistema debe de notificar al administrador por medio de un correo
electrónico en caso de que el proceso de actividad regular del servidor
falle por algún motivo.
– El sistema debe evitar estar sin acceso por más de 30 minutos.
Análisis
• Ejemplos
– El sistema debe ser capaz de recuperarse de un fallo,
trasladando su actividad al servidor de contingencia cuando
se cumple el minuto 28 de falta de acceso.
– El sistema debe de tener acceso a la ayuda en línea
contextual en cada módulo.
– El sistema debe de tener un foro en línea donde se atiendan
las dudas de los usuarios del sistema.
– El sistema ofrecerá una curva de aprendizaje de 2
sesiones de media hora para lograr un 70% de la
funcionalidad total del sistema.
– El sistema deberá de sufrir una reducción en la curva de
aprendizaje de un 50% en usuarios que lo hayan utilizado
anteriormente.
Análisis
• Ejemplos
– El sistema deberá tener un tiempo de respuesta máximo en el
módulo de imágenes de 5 segundos, si el usuario cumple con
los requerimientos de hardware.
– El sistema deberá tener un tiempo de respuesta máximo en el
módulo de música de 10 segundos, si el usuario cumple con
– El sistema deberá tener un tiempo de respuesta máximo en
el módulo de notas de 2 segundos, si el usuario cumple con
– El sistema no deberá cargar el disco duro con mas de 100 megas
por usuario y siempre tendrá un espacio libre del 30% del disco
duro.
– El sistema deberá registrar en una tabla de la base de datos todas
las sesiones del sistema.
– El sistema deberá ser desarrollado bajo una arquitectura orientada a
servicios.
© Copyright Cenfotec S.A. 2000..2018 © Copyright Cenfotec S.A. 2000..2017
Análisis
• Ejemplos:
– El sistema deberá detectar las funcionalidades principales por medio
de un archivo XML que lo va a descargar de un servicio.
– El sistema deberá presentar una pantalla de notificación al
usuario en caso de que el sistema se encuentre en
mantenimiento.
– El sistema deberá ser 100% funcional en FireFox.
– El sistema deberá ser 100% funcional en Internet Explorer.
– El sistema deberá ser 100% funcional en Opera.
– El sistema deberá tener instalado el FrameWork .Net 2.0
– El sistema deberá tener instalado el Windows media player 8 o
superior.
– El sistema deberá estar corriendo en un servidor sin ninguna otra
aplicación compitiendo por recursos.

Ejercicio
• Liste al menos 5 requerimientos no funcionales de

un proyecto o producto práctico, basándose en la
norma ISO-9126

La primera pulga (bicho)
Palomilla encontrada por Grace Murray Hopper atrapada en un relé (#70, pánel F)
de la computadora Mark II de Aiken, mientras era probada en la Universidad de
Harvard, 09.09.1945. Después de extraer la palomilla y pegarla a la bitácora de la
máquina, ella reportó, usando un eufemismo originado por Thomas A. Edison, que
había “despulgado la computadora” ("debugged the computer“).

Bug
Goof
Failure
Anomaly
Blunder
Error >>> Defecto >>> Falla

Error >>> Defecto >>> Falla
Proceso de desarrollo de software
error de software
defecto de software
falla de software

Defectos de software
• Orígenes de defectos (típicos)

– requerimientos
– diseño
– código
– documentación
– malas correcciones

Causas más comunes
• Definición de requerimientos errónea
• Fallas en la comunicación entre cliente y desarrollador
Desviaciones deliberadas de los requerimientos de
software Errores de diseño lógico
• Errores de codificación
• No cumplimiento de instrucciones de documentación
y codificación
• Deficiencias en el proceso de
pruebas Problemas de interfaz de
usuario Errores en procedimientos
• Errores de documentación

Problemas serios de calidad
Weinberg

Fuentes de defectos

Costos de reparar defectos
• Requerimientos $ 45 (< 1 h./p.)

• Diseño $ 450 (6 h./p.)
• Codificación $ 1,500 (20 h./p.)
• Integración $ 1,500 (20 h./p.)
• Pruebas finales $ 45,000 (600 h./p.)
• Entrega $ 450,000 (6,000 h./p.)
Hewlett-Packard 1991

Costos de reparación IBM

Q
Acumulación de defectos
Problema
Especif. Especif.
correcta incorrecta
Diseño Diseño Diseño de

correcto erróneo espec. errónea
Construcción Construcción Construyó s/un Construyó s/

correcta errónea diseño erróneo ideas erróneas
Funciones Errores Errores Problemas

correctas corregibles incorregibles ocultos

Trabajo y re-trabajo
requerimientos diseño programación pruebas aceptación

Detección tradicional

Detección localizada

BISOFT-32
Calidad,
verificación y
validación de
software

01 Calidad Del Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01 Calidad Del Software

Cargado por

Copyright:

Formatos disponibles

BISOFT-32

© Copyright Cenfotec S.A. 2000..2018

"La totalidad de las características de un producto o

© Copyright Cenfotec S.A. 2000..2018

• Construido con materiales seleccionados

Calidad del proceso Calidad del producto

Monitoreada por Control estadístico de la calidad

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

Calidad 4. Basada en el producto

© Copyright Cenfotec S.A. 2000..2018

“Se ve bien” “Buen valor por el dinero” “Confiable”

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

• Hay frecuentemente restricciones sobre la

© Copyright Cenfotec S.A. 2000..2018

• Objetivo último de la Ingeniería de Software:

• Calidad engloba todo el proceso, y está

• Calidad es un concepto complejo y multifacético,

© Copyright Cenfotec S.A. 2000..2018

“Grado con el cual el cliente o usuario percibe que

© Copyright Cenfotec S.A. 2000..2018

• Calidad = satisfacción del usuario

© Copyright Cenfotec S.A. 2000..2018

• Calidad del software: satisfacción de

© Copyright Cenfotec S.A. 2000..2018

• Satisfacción del cliente

© Copyright Cenfotec S.A. 2000..2018

• Se satisfacen los requerimientos del cliente

© Copyright Cenfotec S.A. 2000..2018

• “La característica de haber demostrado la

Kruchten, The Rational Unified Process

© Copyright Cenfotec S.A. 2000..2018

• La calidad del producto principal que se produce

© Copyright Cenfotec S.A. 2000..2018

• Grado en el cual se ha implementado y respetado

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

Facilidad de Mantenimiento Portabilidad

© Copyright Cenfotec S.A. 2000..2018

• Operación del producto – el software existente corre

© Copyright Cenfotec S.A. 2000..2018

• Externas: aquellas perceptibles por el usuario del

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

• Formas de medir requerimientos no

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

• Definición: Capacidad del producto de software

© Copyright Cenfotec S.A. 2000..2018

© Copyright Cenfotec S.A. 2000..2018

• Liste al menos 5 requerimientos no funcionales de

© Copyright Cenfotec S.A. 2000..2018