Subido por Guadalupe Ramirez

Analisis de la norma ISO IEC 9126

Anuncio
UNIVERSIDAD ABIERTA Y A DISTANCIA DE MEXICO
Unidad 3
Actividad 2
“Análisis de la norma ISO/IEC 9126”
Por:
Marco A. González Salinas
Matricula
AL12501118
Trabajo realizado para la asignatura de Modelos de Calidad de Software, impartida por la
Mtra. María de Lourdes Santiago Zaragoza
al grupo DS-DMCS-1701-B2-001.
Mayo 27 del 2017
Índice
1. Introducción..………….....…………………………………………………..……
Pág.
3
2. Objetivo de la actividad……………………………………………....………….
4
3. Modelo de calidad de la norma ISO/IEC 9126 -1 (9126-2: Métricas
Externas, 9126-3: Métricas Internas y 9126-4: Métricas de Calidad en
Uso).…………………………………………………………………………………
4. Descripción del Software (Sistema en línea)…..........................................
4
7
4.1 Información General del Software implicado en el Caso de Estudio..…
7
4.2 Descripción de Funcionalidad desde el punto de vista usuario…….……
8
4.3 Descripción de la empresa.…………………………………………...……...
10
4.4 Detección de las características más importantes del Software
implicado en el Caso de Estudio…………………………………………………
11
5. Resultados del análisis…………………………………………………………….
31
5.1 Características de funcionalidad……………………………………………..
31
5.2 Características de fiabilidad…………………………………………………..
33
5.3 Características de usabilidad…………………………………………………
36
5.4 Características de eficiencia………………………………………………….
44
5.5 Características de mantenimiento……………………………………………
46
5.6 Características de portabilidad……………………………………………….
46
6. Análisis de la norma ISO 14598. Evaluación de producto de software………
52
6.1 Diagrama de flujo del método de Evaluación de producto de software
de la norma ISO 14598……………………………………………………………
55
7. Análisis de la norma ISO 15504. Evaluación de procesos de desarrollo de
software de la norma ISO 15504…………………………………………………
56
7.1 Diagrama de flujo del método de Evaluación de procesos de desarrollo
de software de la norma ISO 15504……………………………………………..
57
8. Reflexión sobre las ventajas e importancia de las 3 normas estudiadas en
este trabajo y conclusión sobre ventajas competitivas de las empresas de
software que cuentan con productos certificados en esta norma…………..
59
9. Fuente de consulta…………………………………………………………………
60
Instrucciones
1. Analiza la Estructura del modelo de calidad de la norma ISO 9126-2. Métricas externas.
2. Analiza la Estructura del modelo de calidad de la norma ISO 9126-3. Métricas internas
3. Analiza la Estructura del modelo de calidad de la norma ISO 9126-4. Calidad en las métricas de uso
4. De tu propia autoría en un organizador gráfico describe las características de calidad y sub características
asociadas al modelo de calidad de la norma ISO IEC 9126-2, 9126-3 y 9126-4.
ANÁLISIS DEL CASO DE ESTUDIO.
5. Analiza y expone las características de calidad del CASO DE ESTUDIO (previamente asignado). NO SE
RECIBEN TRABAJOS CON CASOS DE ESTUDIO DIFERENTES AL CASO DE ESTUDIO ASIGNADO.
6. Registra la información en un Reporte Técnico de acuerdo a los siguientes puntos:
I.
Índice de Contenido
II.
Introducción
III.
Objetivo
IV.
Modelo de calidad de Métricas internas, externas, y en uso
V.
Descripción del Software
a. Información General del Software implicado en el Caso de Estudio.
b. Descripción de Funcionalidad desde el punto de vista usuario
c. Detección de las características más importantes del Software implicado en el Caso de Estudio
VI.
Emite los Resultados del análisis con base al formato tabular sugerido por el docente mismo que te
hará llegar. **NO SE HACE RECEPCIÓN DEL FORMATO DE ANÁLSIS SI ES DIFERENTE AL
ESTABLECIDO POR EL DOCENTE.
a. Características de funcionalidad.
b. Características de fiabilidad
c. Características de usabilidad
d. Características de eficiencia
e. Características de mantenimiento
f. Características de portabilidad
VII.
Análisis de la norma ISO 14598. Evaluación de producto de software
a. Diagrama de flujo del método de Evaluación de producto de software de la norma ISO 14598
VIII.
Análisis de la norma ISO 15504. Evaluación de procesos de desarrollo de software de la norma ISO
15504
a. Diagrama de flujo del método de Evaluación de procesos de desarrollo de software de la norma
ISO 15504
IX.
Reflexión sobre las ventajas e importancia de las 3 normas estudiadas en este trabajo y conclusión
sobre ventajas competitivas de las empresas de software que han adoptado e implementado esta
norma.
X.
Bibliografía en formato APA
7. Integra el desarrollo de tu actividad en un documento con carátula y los datos de identificación completos,
posteriormente guarda tu actividad con el nombre DMCS_A2_U3_XXYZ. Sustituye las XX por las dos
16
primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido.
8. Envía tu trabajo.
9. Espera y atiende la retroalimentación correspondiente.
17
1. Introducción.
En el estudio que hemos venido desarrollando acerca de los modelos de calidad del software, es
necesario tener presente la definición de calidad; el diccionario de la Real Academia Española define
el concepto como: “la propiedad o conjunto de propiedades inherentes a una cosa que permite
apreciarla como igual, mejor o peor que las restantes de su misma especie” [1] Este concepto señala
dos características importantes implícitas:
1. La valoración de calidad es subjetiva
2. No se trata de una cualidad absoluta, sino de un atributo relativo
Estas ambigüedades han repercutido en todas las áreas de interés humano, en donde ha sido
necesario establecer los parámetros para producir bienes o servicios, para la gestión o la dirección.
El concepto de calidad ha evolucionado a lo largo de los años hasta nuestros días. Se dice que el
objetivo fundamental de la calidad, como filosofía empresarial, es satisfacer las necesidades del
consumidor, sin embargo, considerando enfoques relacionados en distintos ámbito como los son: la
teoría económica, el marketing psicológico o neuro marketing, resulta ser controvertido porque no
coinciden, lo que se refleja en las aportaciones al conocimiento de las necesidades que deben
considerarse centradas en el cliente.
La industria del desarrollo de software no se aleja de esta realidad, parte de la misma premisa con el
objetivo de subsanar las carencias de los productos desarrollados, así como de la planeación y la
gestión de los proyectos. Las empresas que se interesan por mejorar sus productos de software,
tienen como objetivo contar con parámetros y niveles mínimos para que sus productos sean
considerados de calidad. Es así, como buscan apegarse a las normas y estándares internacionales
establecidos y a su vez, las normas y estándares persiguen mejorar los parámetros y métricas para
su aplicación.
18
2. Objetivo
Comprender la importancia, evolución y aplicación de las normas y modelos de calidad ISO: 9126,
14598 y 15504.
•
Analizar la estructura
del modelo de calidad de la norma ISO/IEC 9126, así como su
aplicación en la evaluación de un caso concreto.
•
Analizar la estructura de la norma ISO 14598
•
Analizar la estructura de la norma ISO/IEC 15504
3.
Modelo de calidad de la norma ISO / IEC 9126
La descripción de la norma en Software Engineering – Product quality – Part 3 (2003) nos dice que:
“Es un reporte técnico que incluye las métricas internas que se pueden aplicar a un producto
de software; cabe destacar que al ser métricas internas se aplican a productos de software no
ejecutables; además, presenta una serie de ejemplos sobre métricas que pueden ser aplicadas
y un marco de trabajo (framework) para realizar mediciones a un producto de software
particular”
El objetivo de la norma es proponer una estructura para evaluar la calidad el software a través de un
modelo de calidad que se pueda aplicar a cualquier tipo de software, para ello el modelo establece
seis características que describen la calidad del software.
En otras palabras, la norma ISO/IEC 9126 nos presenta el concepto de calidad en uso, calidad
externa y calidad interna, relacionadas con el punto de vista del usuario, el desarrollador y el producto
en sí.
Veamos a continuación las 4 partes en que se dividen la norma y cómo cada una de ellas trata
diferentes aspectos.
Estándar ISO / IEC 9126
División del
estándar
Tipo de métricas
ISO / IEC
Modelo de
9126-1
calidad
Descripción de la
Métricas
métrica
relacionadas
Observaciones
Clasifica la calidad
Esta parte proporciona los conceptos básicos
del software en un
de característica, sub característica, atributo,
conjunto
métrica así como también muestra un modelo
estructurado de
de calidad con seis características, las cuales a
características y
su vez se sub-dividen en sub características.
sub características
Miden el
ISO/ IEC TR
Define métricas
9126-2 : 2003
externas.
comportamiento
del sistema
basado en
computadora que
Proporciona
• No pretenden ser un conjunto exhaustivo. Los
métricas externas
desarrolladores, evaluadores, gerentes de
para medir atributos
calidad y adquirentes pueden seleccionar
de seis
características de
calidad externas
métricas para definir requisitos, evaluar
productos de software, medir aspectos de
19
incluye el
definidas en ISO /
software.
IEC 9126-1.
calidad y otros propósitos.
• Está destinado a utilizarse junto con la norma
ISO / IEC 9126-1.
• Contiene una explicación de cómo aplicar
métricas de calidad de software, un conjunto
básico de métricas para cada sub característica
y un ejemplo de cómo aplicar métricas durante
el ciclo de vida del producto de software.
• No asigna rangos de valores de estas métricas
a niveles nominales o a grados de
cumplimiento, ya que estos valores se definen
para cada producto de software o parte del
producto de software, por su naturaleza,
dependiendo de factores tales como la
categoría del software, la integridad Nivel y las
necesidades de los usuarios. Algunos atributos
pueden tener un rango deseable de valores,
que no depende de las necesidades específicas
del usuario, sino que depende de factores
genéricos; Por ejemplo, factores cognitivos
humanos.
Aplican a un producto de software no ejecutable.
Aplican durante las etapas de su desarrollo.
Permiten medir la calidad de los entregables
intermedios.
ISO / IEC TR
Define métricas
9126-3
internas.
Miden el software
en sí.
Permiten predecir la calidad del producto final.
Permiten al usuario iniciar acciones correctivas
temprano en el ciclo de desarrollo.
Puede seleccionar o modificar y aplicar métricas y
medidas de ISO / IEC TR 9126-2: 2003 o puede
definir métricas específicas de la aplicación para su
dominio de aplicación individual.
Define las
métricas de
calidad en uso,
ISO / IEC
9126-4
para la medición
de las
características o
las sub
Miden los efectos
del uso del
software en un
contexto
específico de uso.
características.
20
Figura 1. Esquema de la norma ISO/IEC 9126, características y sub características.
21
4.
Descripción del software (sistema en línea)
4.1 Información general del software implicado en el caso de estudio.
Registro de alta de servicio en línea y pagos del servicio de luz en la Página CFE.
Página web de localización
http://www.cfe.gob.mx/casa/serviciosenlinea/Paginas/Servicios-en-linea.aspx
Figura 2. Página principal de servicios en línea de CFE
22
4.2 Descripción de funcionalidad desde el punto de vista usuario
Alta del servicio
•
Registro de usuario. Permite registrar un usuario para hacer uso de los servicios en línea
ofrecidos.
•
Cambiar contraseña. Permite al usuario cambiar la contraseña de acceso al sistema.
•
Cambio de correo electrónico. Permite al usuario cambiar la dirección de correo electrónico
registrado.
•
Cerrar sesión. Finaliza la sesión del usuario.
Registro de alta de servicio en línea:
http://app.cfe.gob.mx/Aplicaciones/CCFE/Recibos/Registro/
Figura 3. Sección de alta de usuarios, servicios en línea de CFE
23
Pagos del servicio de luz en la Página.
https://app.cfe.gob.mx/Aplicaciones/CCFE/Recibos/Consulta/login.aspx
Alta de servicio en línea.
Pago del servicio de luz.
•
Pago en línea. Ofrece al usuario pagar uno o más recibos de luz, para lo cual debe registrar
primero los recibos a pagar.
•
Nuevo contrato. Permite al usuario solicitar el servicio de abastecimiento de energía eléctrica
mediante el llenado de una solicitud.
•
Avisar fallas de luz. El usuario puede reportar fallas en el servicio llenando un formulario con sus
datos y seleccionando la descripción de la falla.
•
Aclaración del recibo. Permite al usuario solicitar una aclaración de su recibo, llenando un
formulario con los datos del recibo, e-mail y las observaciones correspondientes.
•
Revisión del medidor. El usuario tiene la oportunidad de solicitar la revisión de su medidor,
enviando la información a través de un formulario.
•
Incremento de carga.
•
Cambios en las instalaciones de CFE. A través de esta opción, el usuario puede solicitar la
reubicación de alguno o más componentes físicos del suministro eléctrico mediante el llenado de
un formulario.
•
Solicitar libranza. Permite al usuario solicitar suspensión temporal del servicio eléctrico.
•
Consultar una solicitud. Sí el usuario ha solicitado algún servicio, en esta opción puede consultar
el estatus de dicha petición suministrando la información requerida.
•
Consultar recibo. En esta opción, el usuario puede consultar su recibo o recibos que tiene
registrados.
•
Cambio de servicio primario
•
Descargar factura por serie y folio. En esta opción se ofrece al usuario poder descargar las
facturas correspondientes a los pagos realizados del servicio.
•
Factura centralizada
24
Figura 4. Ingreso al sistema, página de servicios de CFE
4.3 Descripción de la empresa
Empresa pública del sector primario a nivel nacional, dedicada a la generación, transmisión,
distribución y comercialización de energía eléctrica para más de 35.6 millones de clientes al mes de
marzo, cada año incorpora a más de un millón de clientes.
En la página web de la CFE (2015), encontramos la declaración de la misión y visión que expresan
como:
Nuestra Misión
Prestar el servicio público de energía eléctrica con criterios de suficiencia, competitividad y
sustentabilidad, comprometidos con la satisfacción de los clientes, con el desarrollo del país y
con la preservación del medio ambiente. (cfe.gob.mx)
Visión al 2030
Ser una empresa de energía, de las mejores en el sector eléctrico a nivel mundial, con
presencia internacional, fortaleza financiera e ingresos adicionales por servicios relacionados
con su capital intelectual e infraestructura física y comercial. (cfe.gob.mx)
Una empresa reconocida por su atención al cliente, competitividad, transparencia, calidad en el
servicio, capacidad de su personal, vanguardia tecnológica y aplicación de criterios de
desarrollo sustentable.
La CFE obtuvo la certificación bajo la norma ISO-9001 en el año 2006, logrando 100% de 9 procesos
de alto impacto: generación, distribución, construcción, programación, CENACE, transmisión,
administrativo, financiero y técnico.
25
En el mismo año, la CFE obtiene 576 puntos como nivel de madurez en la implantación del Modelo
de Dirección por Calidad. De igual manera se aprobó el Plan Maestro del Programa Seis Sigma para
el desarrollo del Modelo de Gestión Seis Sigma, la preparación de niveles directivos y alta gerencia
de la CFE.
CFE cuenta también con Gestión de la Calidad en suministros implantado en el Proyecto
Hidroeléctrico El Cajón.
En materia de Gestión Ambiental, CFE cuenta con un certificado bajo la norma internacional ISO14001:2004 la cual está respaldada por tecnologías de la información, la cual establece el control de
los aspectos ambientales de mayor relevancia, en obras en construcción como en las que están en
operación.
De esta manera CFE pone de manifiesto las acciones de mejora, evaluación y seguimiento que le
permiten mejorar la eficacia de su desempeño ambiental.
4.4 Detección de las características más importantes del Software implicado
en el Caso de Estudio
La interfaz de usuario es intuitiva y está claramente organizada de tal manera que el usuario puede
encontrar la opción deseada fácilmente.
Ofrece a los usuarios acceso a servicios relacionados con todo lo concerniente al suministro de
energía eléctrica, pagos del servicio, reportes de fallas, aclaraciones, entre otros, a través de una
sesión protegida con credenciales de acceso, además de permitir al usuario gestionarlas.
El sistema es accesible desde cualquier equipo de cómputo o dispositivo que cuente con un
navegador y conexión de internet. Posiblemente también se pueda tener acceso desde cualquier
punto geográfico. Lo anterior es posible gracias al modelo de comunicación Cliente Servidor en el que
está diseñado.
Antes de comenzar con la revisión de las características, sub características y fórmulas para la
evaluación, veamos el informe técnico
ISO para conocer más acerca de las medidas y
recomendaciones para leer y usar las tablas de métricas.
26
El usuario de estos Informes Técnicos Internacionales debe seleccionar las características de
calidad y las sub características a evaluar, de ISO / IEC 9126-1; Identificar las medidas directas
e indirectas apropiadas, identificar las métricas pertinentes y luego interpretar el resultado de la
medición de una manera objetiva. El usuario de estos Informes Técnicos Internacionales
también puede seleccionar procesos de evaluación de la calidad del producto durante el ciclo
de vida del software de la serie de normas ISO / IEC 14598. Éstos proporcionan métodos para
medir, evaluar y evaluar la calidad del producto de software. Están destinados a ser usados por
desarrolladores, compradores y evaluadores independientes, particularmente los responsables
de la evaluación de productos de software.
Las métricas internas pueden aplicarse a un producto de software no ejecutable durante sus
etapas de desarrollo (como solicitud de propuesta, definición de requisitos, especificación de
diseño o código fuente). Las métricas internas proporcionan a los usuarios la capacidad de
medir la calidad de los entregables intermedios y así predecir la calidad del producto final. Esto
permite al usuario identificar problemas de calidad e iniciar acciones correctivas tan pronto
como sea posible en el ciclo de vida del desarrollo.
Las métricas externas pueden usarse para medir la calidad del producto de software midiendo
el comportamiento del sistema del que forma parte. Las métricas externas sólo se pueden
utilizar durante las etapas de prueba del proceso del ciclo de vida y durante cualquier etapa
operativa. La medición se realiza cuando se ejecuta el producto de software en el entorno del
sistema en el que se pretende operar.
Las métricas de calidad de uso miden si un producto satisface las necesidades de usuarios
específicos para alcanzar las metas especificadas con eficacia, productividad, seguridad y
satisfacción en un contexto específico de uso. Esto sólo se puede lograr en un entorno de
sistema realista.
Las necesidades de calidad de los usuarios se pueden especificar como requisitos de calidad
mediante métricas de calidad de uso, métricas externas ya veces métricas internas. Estos
requisitos especificados por las métricas se deben utilizar como criterios cuando se evalúa un
producto.
Se recomienda utilizar métricas internas que tengan una relación lo más fuerte posible con las
métricas externas de destino, de manera que puedan utilizarse para predecir los valores de las
métricas externas. Sin embargo, a menudo es difícil diseñar un modelo teórico riguroso que
proporcione una fuerte relación entre las métricas internas y las métricas externas. Por lo tanto,
un modelo hipotético que puede contener ambigüedad puede ser diseñado y el alcance de la
relación puede ser modelado estadísticamente durante el uso de métricas.
27
Las recomendaciones y requisitos relacionados con la validez y la fiabilidad se dan en ISO / IEC
9126-1, cláusula A.4. En el Anexo A de este Informe Técnico Internacional se presentan
consideraciones adicionales detalladas al utilizar métricas.
Cómo leer y usar las tablas de métricas
Las métricas enumeradas en la cláusula 8 se clasifican por las características y sub
características de la norma ISO / CEI 9126-1. Se proporciona la siguiente información para cada
métrica de la tabla:
A) Nombre de la métrica: Las métricas correspondientes en la tabla de métricas internas y la
tabla de métricas externas tienen nombres similares.
B) Propósito de la métrica: Esto se expresa como la pregunta a ser respondida por la aplicación
de la métrica.
C) Método de aplicación: Proporciona un esquema de la aplicación.
D) Cálculos de medidas, fórmulas y elementos de datos: Proporciona la fórmula de medición y
explica los significados de los elementos de datos utilizados.
E) NOTA: En algunas situaciones se propone más de una fórmula para una métrica.
F) Interpretación del valor medido: Proporciona el rango y los valores preferidos.
G) Tipo de escala métrica: Tipo de escala utilizada por la métrica. Los tipos de escala utilizados
son; Escala nominal, escala ordinaria, escala de intervalo, escala de proporción y escala
absoluta.
H) NOTA: Una explicación más detallada se da en el anexo C.
I) Tipo de medida: Los tipos utilizados son; Tipo de tamaño (por ejemplo, Tamaño de la
función, Tamaño de la fuente), Tipo de tiempo (por ejemplo, Tiempo transcurrido, Tiempo del
usuario), Tipo de recuento (por ejemplo, Número de cambios, Número de fallos).
J) NOTA: Una explicación más detallada se da en el Anexo C.
K) Entrada a la medición: Fuente de los datos utilizados en la medición.
L) ISO / IEC 12207 SLCP Referencia: Identifica el proceso del ciclo de vida del software donde
la métrica es aplicable.
M) Público objetivo: Identifica al usuario (s) de los resultados de las mediciones.
Tablas de métricas
Las métricas enumeradas en esta cláusula no pretenden ser un conjunto exhaustivo y pueden
no haber sido validadas. Se enumeran por características de calidad de software y sub
características, en el orden introducido en ISO / CEI 9126-1.
Las métricas, que pueden ser aplicables, no se limitan a las enumeradas aquí. Se proporcionan
métricas
específicas
adicionales
para
propósitos
particulares
en
otros
documentos
relacionados, como la medición del tamaño funcional o la medición precisa de la eficiencia en el
tiempo.
28
Nota: Se recomienda remitir una métrica específica o un formulario de medición a normas
específicas, informes técnicos o directrices. La medición del tamaño funcional se define en la
norma ISO / IEC 14143. Un ejemplo de medición precisa de la eficiencia en el tiempo puede
consultarse en la norma ISO / IEC 14756.
Las métricas deben ser validadas antes de la aplicación en un ambiente específico (ver Anexo
A).
Nota: Esta lista de métricas no está finalizada y puede ser revisada en futuras versiones de este
Informe Técnico Internacional. Se invita a los lectores de este Informe Técnico Internacional a
dar su opinión.
Métricas de funcionalidad
Una métrica de funcionalidad externa debe ser capaz de medir un atributo como el
comportamiento funcional de un sistema que contiene el software. El comportamiento del
sistema puede observarse desde las siguientes perspectivas:
A. Diferencias entre los resultados ejecutados reales y la especificación de requisitos de
calidad;
Nota: La especificación de requisitos de calidad para la funcionalidad se describe
normalmente como la especificación de requisitos funcionales.
B. La inadecuación funcional detectada durante el funcionamiento real del usuario, que no se
indica, sino que está implícita como requisito en la especificación.
Nota: Cuando se detectan operaciones o funciones implícitas, deben revisarse, aprobarse y
establecerse en las especificaciones. Debe acordarse su alcance.
Métricas de adecuación
Una métrica externa de aptitud debe ser capaz de medir un atributo tal como la ocurrencia de
una función insatisfactoria o la ocurrencia de una operación insatisfactoria durante la prueba y el
funcionamiento del usuario del sistema.
Una función o operación insatisfactoria puede ser:
A. Funciones y operaciones que no funcionan como se especifica en los manuales de usuario o
en la especificación del requisito.
B. Funciones y operaciones que no proporcionan un resultado razonable y aceptable para
lograr el objetivo específico previsto de la tarea del usuario.
Métricas de precisión
Una métrica de precisión externa debe ser capaz de medir un atributo como la frecuencia de los
usuarios que se encuentran con la ocurrencia de cuestiones inexactas que incluye:
A. Resultado incorrecto o impreciso causado por datos inadecuados; Por ejemplo, datos con
29
muy pocos dígitos significativos para un cálculo preciso;
B. Inconsistencia entre los procedimientos de operación reales y los descritos en el manual de
operación;
C. Diferencias entre los resultados esperados reales y razonables de las tareas realizadas
durante el funcionamiento.
Métricas de interoperabilidad
Una métrica de interoperabilidad externa debe ser capaz de medir un atributo como el número
de funciones o apariciones de menor comunicatividad que involucran datos y comandos, que se
transfieren fácilmente entre el producto de software y otros sistemas, otros productos de
software o equipos conectados.
Métricas de seguridad
Una métrica de seguridad externa debe ser capaz de medir un atributo como el número de
funciones con o los sucesos de problemas de seguridad, que son:
A. No impedir la fuga de información o datos de salida segura;
B. No evitar la pérdida de datos importantes;
C. No defender contra el acceso ilegal o la operación ilegal.
Nota:
1. Se recomienda que se realicen pruebas de penetración para simular el ataque, ya que este
ataque de seguridad normalmente no ocurre en las pruebas habituales. Las métricas reales
de seguridad sólo se pueden tomar en "el entorno del sistema de la vida real", que es
"calidad en el uso".
2. Los requisitos de protección de seguridad varían ampliamente desde el caso de un sistema
autónomo al caso de un sistema conectado a Internet. La determinación de la funcionalidad
requerida y el aseguramiento de su efectividad han sido abordados extensamente en las
normas relacionadas. El usuario de esta norma debe determinar las funciones de seguridad
utilizando métodos y normas apropiados en aquellos casos en que el impacto de cualquier
daño causado sea importante o crítico. En el otro caso, el usuario puede limitar su alcance a
las medidas de protección "Tecnología de la Información (IT)" generalmente aceptadas,
como los métodos de copia de seguridad de protección contra virus y el control de acceso.
Métricas de cumplimiento de funcionalidad
Una métrica de cumplimiento de funcionalidad externa debe ser capaz de medir un atributo
como el número de funciones con problemas de cumplimiento o de problemas de cumplimiento,
30
que son los productos de software que no cumplen con las normas, convenciones, contratos u
otros requisitos reglamentarios.
5. Resultados del análisis
5.1 Características de funcionalidad
Sub característica:
Interoperabilidad
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
La capacidad el producto software para comunicarse con otras aplicaciones
¿Cómo se han implementado las funciones de interfaz para el intercambio y la
transferencia de datos específicos?
A = Número de elementos de cumplimiento de
Fórmula:
Intercambio de
datos
(Basado en el
formato de
datos)
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol
responsable
evaluación:
𝑋=
𝐴
𝐵
funcionalidad especificados que no se han
implementado durante las pruebas
B = Número total de elementos de cumplimiento de
0≤𝑋≤1
funcionalidad especificados
Entre más cerca
de 1 es mejor
Revisión - pruebas
de
Desarrollador
Usuario
Sub característica:
Interoperabilidad
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
La capacidad el producto software para comunicarse con otras aplicaciones
• ¿Con que frecuencia el usuario final no puede intercambiar datos entre el software
destino y otro software?
• ¿Con qué frecuencia la transferencia de datos entre el software destino y otro
software son exitosas?
Fórmula:
Intercambiabili
𝑨
a) 𝑿 = 𝟏 − 𝑩
dad
(Basado en los
Nombre de la métrica
propuesta:
intentos de
éxito del
0≤𝑋≤1
Entre más cerca
de 1 es mejor
𝑨
b) 𝒀 = 𝑻
0≤𝑌
usuario)
A = Número de veces en los que el usuario no pudo
intercambiar datos con otro software o sistemas
B = Número de casos en los que el usuario intentó
intercambiar datos
T = Período de tiempo de operación
Entre más cerca a
cero es mejor.
Etapa de posible
evaluación:
Rol
responsable
evaluación:
Revisión - pruebas
de
Desarrollador
Usuario
31
Sub característica:
Cumplimiento de la funcionalidad
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Exactitud
¿Son aceptables las diferencias entre los resultados reales y los esperados?
Fórmula:
𝑿=
Nombre de la métrica
propuesta:
Expectativa de
exactitud
𝑨
𝑻
0≤𝑋
Entre más
cerca de 0
mejor.
Etapa de posible
evaluación:
Rol
responsable
evaluación:
A = Número de casos en los que el usuario encontró
una diferencia opuesta razonable en los resultados
esperados mayor a lo permitido.
T = Tiempo en operación
Validación
Aseguramiento de la calidad
de
Desarrollador
Usuario
Sub característica:
Cumplimiento de la funcionalidad
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Exactitud
¿Con qué frecuencia los usuarios finales encuentran resultados inexactos?
Fórmula:
𝑿=
Nombre de la métrica
propuesta:
Precisión
computacional
𝑨
𝑻
0≤𝑋
Entre más
cerca de 0
mejor.
Etapa de posible
evaluación:
Rol
responsable
evaluación:
A = Número de cálculos inexactos encontrados por
los usuarios
T = Tiempo en operación
Validación
Aseguramiento de la calidad
de
Desarrollador
Usuario
32
Sub característica:
Cumplimiento de la funcionalidad
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Exactitud
¿Con qué frecuencia los usuarios finales encuentran resultados con una precisión
inadecuada?
Fórmula:
𝑿=
Nombre de la métrica
propuesta:
Precisión
𝑨
𝑻
0≤𝑋
Entre más
cerca de 0
mejor.
Etapa de posible
evaluación:
Rol
responsable
evaluación:
A = Número de resultados encontrados por los
usuarios con un nivel de precisión diferente del
requerido.
T = Tiempo en operación
Validación
Aseguramiento de la calidad
de
Desarrollador
Usuario
5.2 Características de fiabilidad
Sub característica:
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
Tolerancia a fallos
Frecuencia de fallos
¿Con qué frecuencia el producto software provoca la degradación del entorno de
producción?
Fórmula:
𝑨
𝑩
0≤𝑋≤1
Entre más cerca
de 1.0 es mejor
𝑿= 𝟏−
Nombre de la métrica
propuesta:
Prevención de
daños
Etapa de posible
Integración
Pruebas de calificación
evaluación:
A: Número de averías
B: Número de fallos
Operación
Rol responsable de
Desarrollador
evaluación:
Usuario
33
Sub característica:
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
Tolerancia a fallos
Frecuencia de fallos
¿Cuántos patrones de fallas fueron puestos bajo control para evitar fallas críticas y
graves ocurridas?
Fórmula:
𝑨
𝑩
0≤𝑋≤1
Entre más cerca de 0 es
mejor ya que el usuario
puede evitar con mayor
frecuencia el fallo crítico
o grave.
𝑿=
Nombre de la métrica
propuesta:
Prevención de
fallas
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Integración
Pruebas de calificación
Validación
Desarrollador
Usuario
Sub característica:
Tolerancia a fallos
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
A: Número de averías
B: Número de fallos
Frecuencia de fallos
¿Cuántas funciones se implementan con capacidad de evitar operaciones incorrectas?
Fórmula:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Prevención de
operación
incorrecta
𝑨
𝑩
0≤𝑋≤1
Entre más cerca de 1.0 es
mejor ya que evita el
funcionamiento incorrecto
𝑿=
A: Número de fallos críticos y graves
evitados
B: Número de pruebas realizadas con
un patrón de funcionamiento incorrecto
(casi causando fallas) durante la prueba
Integración
Pruebas de calificación
Operación
Ing. De software.
Usuario
34
Características de fiabilidad
Sub característica 2:
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
Recuperabilidad
Capacidad de recuperación de un fallo y grado de previsión.
¿Cuál es la disponibilidad del sistema para su uso durante un periodo específico?
Fórmula:
𝑿=
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
𝑻𝟎
𝑻𝟎 + 𝑻𝒓
0≤𝑋≤1
Entre más cerca de 1.0
mejor, ya que el usuario
Disponibilidad puede utilizar el software
por más tiempo.
𝑨𝟏
𝒀=
𝑨𝟐
0≤𝑌≤1
Entre más cerca de 1.0
mejor.
Pruebas de calificación
Operación
Ing. de Software
Usuario.
𝑇0 ∶ Tiempo en funcionamiento
𝑇𝑟 ∶ Tiempo de reparación
𝑨𝟏 : Número de casos disponibles
cuando el usuario usó el software con
éxito.
𝑨𝟐 : Número total de casos de intentos
del usuario de usar el software durante
un tiempo de observación.
Características de fiabilidad
Sub característica 2:
Descripción de la Sub
característica:
Justificación del criterio de
calidad (o evaluación)
seleccionado con base al
caso de estudio:
Recuperabilidad
Capacidad de recuperación de un fallo y grado de previsión.
¿Cuál es el tiempo promedio en que el sistema permanece inactivo cuando se
produce un fallo durante el arranque?
Fórmula:
𝑿=
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Tiempo de
inactividad
𝑻
𝑵
0<𝑋
Entre más pequeño es mejor,
el sistema estará inactivo por
menos tiempo
𝑻 ∶ Tiempo en funcionamiento
𝑵 ∶ Tiempo de reparación
Integración
Pruebas de calificación
Operación
Ing. de Software
Usuario.
35
5.3 Características de usabilidad
Sub característica:
Facilidad de aprendizaje
Descripción de la Sub
característica:
Facilidad de uso incluye todos aquellos atributos que facilitan la interacción de
un usuario con el sistema.
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
¿Cuánto tarda el usuario en aprender a utilizar una funcionalidad?
Nombre de la métrica
propuesta:
Facilidad de
aprendizaje de
las
funcionalidades
Etapa
de
evaluación:
posible
Rol responsable
evaluación:
de
Fórmula:
𝑻
0<𝑇
Entre más cerca
de 0 mejor.
T: Tiempo medio empleado para aprender a
utilizar correctamente una funcionalidad.
Validación
Pruebas de calificación
Operación
Usuario
Ing. De Software
Sub característica:
Facilidad de aprendizaje
Descripción de la Sub
característica:
Facilidad de uso incluye todos aquellos atributos que facilitan la interacción de
un usuario con el sistema.
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
¿Cuánto tarda el usuario en aprender cómo realizar la tarea especificada de manera
eficiente?
Nombre de la métrica
propuesta:
Etapa
de
evaluación:
posible
Rol responsable
evaluación:
de
Fórmula:
Facilidad de
aprendizaje
𝑻
para mejorar el
0<𝑇
uso de una
Entre más cerca
tarea.
de 0 mejor.
Validación
Pruebas de calificación
Operación
Usuario
Ing. De Software
T: Suma del tiempo de operación del usuario
hasta que el usuario logre realizar la tarea
especificada en un tiempo corto
36
Sub característica:
Facilidad de aprendizaje
Descripción de la Sub
característica:
Facilidad de uso incluye todos aquellos atributos que facilitan la interacción de
un usuario con el sistema.
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
¿Qué proporción de tareas se puede completar correctamente después de usar la
documentación del usuario y / o el sistema de ayuda?
Nombre de la métrica
propuesta:
Eficacia de la
documentación
del usuario y / o
del sistema de
ayuda
Etapa
de
evaluación:
posible
Rol responsable
evaluación:
de
Fórmula:
𝑨
𝑩
0≤𝑋≤1
Entre más cerca
de 1.0 mejor.
𝑿=
A = Número de tareas completadas con éxito
después de acceder a la ayuda en línea y / o
documentación
B = Total del número de tareas probadas
Validación
Pruebas de calificación
Operación
Usuario
Diseñador de la Interfaz humana
Sub característica:
Facilidad de aprendizaje
Descripción de la Sub
característica:
Facilidad de uso incluye todos aquellos atributos que facilitan la interacción de
un usuario con el sistema.
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
¿Qué proporción de funciones se pueden utilizar correctamente después de leer la
documentación o usar sistemas de ayuda?
Nombre de la métrica
propuesta:
Eficacia de la
documentación
del usuario y / o
sistemas de
ayuda en uso
Etapa
de
evaluación:
posible
Rol responsable
evaluación:
de
Fórmula:
𝑨
𝑩
0≤𝑋≤1
Entre más cerca
de 1.0 mejor.
𝑿=
A = Número de funciones que se pueden utilizar
B = Número total de funciones proporcionadas
Validación
Pruebas de calificación
Operación
Usuario
Diseñador de la Interfaz humana
37
Sub característica:
Facilidad de aprendizaje
Descripción de la Sub
característica:
Facilidad de uso incluye todos aquellos atributos que facilitan la interacción de
un usuario con el sistema.
Justificación del criterio
de calidad (o
evaluación)
seleccionado con base
al caso de estudio:
¿Con qué frecuencia un usuario tiene que acceder a la ayuda para aprender la
operación para completar su tarea?
Fórmula:
𝑿= 𝑨
0≤𝑋
Entre más cerca
de 0 mejor.
Nombre de la métrica
propuesta:
Frecuencia de
ayuda
Etapa
de
evaluación:
Validación
Pruebas de calificación
Operación
posible
Rol responsable
evaluación:
de
A = Número de accesos para ayudar hasta que
un usuario complete su tarea.
Diseñador de la Interfaz humana
Características de usabilidad.
Subcaracterística 2:
Operabilidad. A) Cumple con las expectativas operativas del usuario
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Qué tan consistente es el componente de la interfaz de usuario?
Fórmula:
𝑨
𝑩
0≤𝑋≤1
Entre más cerca
de 1,0 mejor
𝑿=𝟏−
Nombre de la métrica
propuesta:
Consistencia
operativa
durante el uso
𝑵
𝑼𝑶𝑻
0≤𝑌
Entre más cercano
a 0 es el mejor.
𝒀=
Etapa de posible
evaluación:
Rol responsable de
evaluación:
A = Número de mensajes o funciones que el
usuario encontró inaceptablemente
inconsistentes con la expectativa del usuario.
B = Número de mensajes o funciones
N = Número de operaciones que el usuario
encontró inaceptablemente inconsistentes con
la expectativa del usuario
UOT = tiempo de funcionamiento del usuario
(durante el período de observación)
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
38
Subcaracterística 2:
Operabilidad. B) Controlable
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Puede el usuario corregir fácilmente el error en las tareas?
Fórmula:
Nombre de la métrica
propuesta:
Error de
corrección
𝑻 = 𝑻𝒄 − 𝑻𝒔
0<𝑇
Entre más cerca
de 0 mejor.
𝑻𝒄: Tiempo de completar la corrección de los
errores de tipo especificados de la tarea
realizada
𝑻𝑺 Tiempo de inicio de la corrección de errores
de tipos especificados de la tarea realizada
Rol responsable de
evaluación:
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
Subcaracterística 2:
Operabilidad. B) Controlable
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
Etapa de posible
evaluación:
¿Puede el usuario recuperar fácilmente sus errores o reintentar las tareas?
Fórmula:
Nombre de la métrica
propuesta:
Corrección de
errores en uso
𝑿=
𝑨
𝑼𝑶𝑻
Entre más cerca
de 0 mejor.
Etapa de posible
evaluación:
Rol responsable de
evaluación:
A = número de veces que el usuario logra
cancelar su operación de error
UOT = tiempo de operación del usuario durante
el período de observación
Nota:
Cuando se prueba la función una por una,
también se puede calcular la relación, es decir,
la relación de número de funciones que el
usuario logra cancelar su operación a todas las
funciones
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
39
Subcaracterística 2:
Operabilidad. B) Controlable
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Puede el usuario recuperar fácilmente su entrada?
Fórmula:
Nombre de la métrica
propuesta:
Corrección de
errores en uso
𝑨
𝑩
0≤𝑋≤1
Entre más cerca
de 1.0 mejor.
A = Número de pantallas o formularios donde
los datos de entrada se modificaron o
modificaron con éxito antes de ser elaborados
𝑿=
B = Número de pantallas o formularios en los
que el usuario intentó modificar o cambiar los
datos de entrada durante el tiempo de
funcionamiento del usuario observado
Rol responsable de
evaluación:
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
Subcaracterística 2:
Operabilidad. C) Adecuado para la operación de la tarea
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
Etapa de posible
evaluación:
¿Puede el usuario seleccionar fácilmente valores de parámetros para su cómoda
operación?
Fórmula:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Disponibilidad
de valor
predeterminado
en uso
𝑨
𝑩
0≤𝑋≤1
Entre más cerca
de 1.0 mejor.
𝑿 = 𝟏−
A = El número de veces que el usuario no
puede establecer o seleccionar valores de
parámetros en un período corto (porque el
usuario no puede usar valores predeterminados
proporcionados por el software)
B = Número total de veces que el usuario
intenta establecer o seleccionar valores de
parámetros
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
40
Subcaracterística 2:
Operabilidad. D) Auto descriptivo (Guía)
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Rol responsable de
evaluación:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Puede el usuario entender fácilmente los mensajes del sistema de software?
¿Hay algún mensaje que haya causado al usuario un retraso en la comprensión antes
de iniciar la siguiente acción?
¿Puede el usuario memorizar fácilmente un mensaje importante?
A = número de veces que el usuario hace una
Fórmula:
pausa durante un largo período o falla
𝑨
sucesivamente y repetidamente en la misma
𝑿=
Comprensión
𝑼𝑶𝑻
operación, debido a la falta de comprensión del
del mensaje
mensaje.
en uso
0≤𝑋
Entre más cerca
UOT= tiempo de funcionamiento del usuario
de 1.0 mejor.
(período de observación)
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
Subcaracterística 2:
Operabilidad. D) Auto descriptivo (Guía)
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
¿En qué proporción de condiciones de error el usuario propone la acción de
recuperación correcta?
Fórmula:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Mensajes de
error auto
explicativos
𝑿=
𝑨
𝑩
0≤𝑋
A = Número de condiciones de error para las
que el usuario propone la acción de
recuperación correcta
B = Número de condiciones de error probadas
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
41
Subcaracterística 2:
Operabilidad. E) Tolerante al error operativo (sin errores humanos)
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Puede el usuario recuperar fácilmente su peor situación?
Fórmula:
Nombre de la métrica
propuesta:
Recuperabilidad
del error
operativo en
uso
𝑿=𝟏−
𝑨
𝑩
0≤𝑋≤1
Cuanto más cerca
de 1.0 es mejor
A = Número de situación recuperada sin éxito
(después de un error o cambio del usuario) en
el que el usuario no fue informado acerca de un
riesgo por el sistema
B = Número de errores o cambios de usuario
Rol responsable de
evaluación:
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
Subcaracterística 2:
Operabilidad. E) Tolerante al error operativo (sin errores humanos)
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
Etapa de posible
evaluación:
¿Puede el usuario operar el software lo suficiente sin error humano?
Fórmula:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Tiempo entre
operaciones
de error
humano en
uso
𝑻
𝑵
(en el tiempo 𝑡
durante [𝑡 − 𝑇, 𝑡])
0<𝑋
Cuanto más cerca
de 1.0 es mejor
𝑿=
T = tiempo de operación durante la observación
(O La suma del tiempo de funcionamiento entre
las operaciones de error humano del usuario)
N = número de ocurrencias de la operación de
error humano del usuario
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
42
Subcaracterística 2:
Operabilidad. E) Tolerante al error operativo (sin errores humanos)
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Con qué frecuencia el usuario corrige correctamente los errores de entrada?
¿Con qué frecuencia el usuario deshace correctamente los errores?
Fórmula:
𝑨
𝑩
(en el tiempo 𝑡
durante [𝑡 − 𝑇, 𝑡])
𝑿=
Nombre de la métrica
propuesta:
Disponibilidad
para deshacer
(Corrección de
errores del
usuario)
0≤𝑋≤1
Cuanto más cerca
de 1.0 es mejor
𝑨
𝑩
0≤𝑌≤1
Cuanto más cerca
de 1.0 es mejor
𝒀=
A = Número de errores de entrada que el
usuario corrige correctamente
B = Número de intentos para corregir errores
de entrada
A = Número de condiciones de error que el
usuario corrige correctamente
B = Número total de condiciones de error
probadas
Rol responsable de
evaluación:
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
Subcaracterística 2:
Operabilidad. F) Adecuado para la individualización
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Puede el usuario personalizar fácilmente los procedimientos de operación para su
conveniencia?
¿Puede un usuario, que instruye a los usuarios finales, configurar fácilmente plantillas
de procedimientos de operaciones personalizadas para prevenir sus errores?
¿Qué proporción de funciones se pueden personalizar?
A = Número de funciones personalizadas con
Fórmula:
éxito.
𝑨
Personalización
𝑿=
𝑩
B = Número de intentos de personalizar
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
Etapa de posible
evaluación:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
43
Subcaracterística 2:
Operabilidad. F) Adecuado para la individualización
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Describe qué es lo que el usuario debe ser capaz de hacer a través del sistema
software.
¿Puede el usuario reducir fácilmente los procedimientos de operación para su
comodidad?
Fórmula:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Reducción del
procedimiento
de operación
𝑨
𝑩
0≤𝑋<1
Cuanto más cerca
de 1.0 es mejor.
𝑿=𝟏−
A = Número de procedimientos de operación
reducidos después de la operación de
personalización.
B = Número de procedimientos de operación
antes de personalizar la operación.
Validación
Pruebas de calificación
Operación
Usuario.
Diseñador de la interfaz humana
5.4 Características de eficiencia
Sub característica:
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Comportamiento en el tiempo. A) Tiempo de Respuesta
¿Cuál es el tiempo que se tarda en completar una tarea especificada?
¿Cuánto tiempo se tarda antes de la respuesta del sistema a una operación
especificada?
Tiempo
de
respuesta
Fórmula:
𝑇
0<𝑇
Cuanto antes mejor.
Integración Sistema / Software
Pruebas de calificación
Operación
Mantenimiento
Desarrollador
Ing. De Software
SQA
T = (tiempo de obtener el resultado)
- (tiempo de entrada del comando terminado)
44
Sub característica:
Comportamiento en el tiempo. A) Tiempo de Respuesta
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Sub característica:
Descripción de la
Sub característica:
Justificación del
criterio de calidad
(o evaluación)
seleccionado con
base al caso de
estudio:
¿Cuál es el tiempo de espera promedio que experimenta el usuario después de emitir
una solicitud hasta que la solicitud se completa dentro de una carga de sistema
especificada en términos de tareas concurrentes y utilización del sistema?
Fórmula:
𝑻𝒎𝒆𝒂𝒏
𝑿=
𝑻𝑿𝒎𝒆𝒂𝒏
0≤𝑋
El más cercano a
1.0
Integración sistema / software
Pruebas de calificación
Operación
Mantenimiento
Desarrollador
Ing. De Software
SQA
Tiempo de
respuesta
(Tiempo
medio de
respuesta)
𝑇𝑖
𝑝𝑎𝑟𝑎 (𝑖 = 1 ℎ𝑎𝑠𝑡𝑎 𝑁)
𝑁
𝑻𝑿𝒎𝒆𝒂𝒏 = 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎 𝑚𝑒𝑑𝑖𝑎 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑜
𝑻𝒊 : 𝑡𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎 𝑝𝑎𝑟𝑎 𝑙𝑎 𝑖 − é𝑠𝑖𝑚𝑎 𝑒𝑣𝑎𝑙𝑢𝑎𝑐𝑖ó𝑛
𝑵 = 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑒𝑣𝑎𝑙𝑢𝑎𝑐𝑖𝑜𝑛𝑒𝑠 (𝑡𝑜𝑚𝑎𝑠 𝑚𝑢𝑒𝑠𝑡𝑟𝑒𝑎𝑑𝑎𝑠)
𝑻𝒎𝒆𝒂𝒏 = ∑
Comportamiento en el tiempo. A) Tiempo de Respuesta
¿Cuál es el límite absoluto de tiempo necesario para cumplir una función?
En el peor de los casos, ¿el usuario puede obtener respuesta dentro del límite de tiempo
especificado?
En el peor de los casos, ¿puede el usuario seguir recibiendo respuesta del software dentro de
un tiempo lo suficientemente corto como para ser tolerable para el usuario?
𝑻𝒎𝒂𝒙 = 𝑀𝐴𝑋 (𝑇𝑖 ) (𝑝𝑎𝑟𝑎 𝑖 = 1 ℎ𝑎𝑠𝑡𝑎 𝑁)
𝑹𝒎𝒂𝒙 = 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎 𝑚á𝑥𝑖𝑚𝑜 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑜
𝑴𝑨𝑿 (𝑻𝒊 ) 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎 𝑚á𝑥𝑖𝑚𝑜 𝑒𝑛𝑡𝑟𝑒 𝑙𝑎𝑠 𝑒𝑣𝑎𝑙𝑢𝑎𝑐𝑖𝑜𝑛𝑒𝑠
𝑻𝒊 : 𝑡𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎 𝑝𝑎𝑟𝑎 𝑙𝑎 𝑖 − é𝑠𝑖𝑚𝑎 𝑒𝑣𝑎𝑙𝑢𝑎𝑐𝑖ó𝑛
𝑵 = 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑒𝑣𝑎𝑙𝑢𝑎𝑐𝑖𝑜𝑛𝑒𝑠 (𝑡𝑜𝑚𝑎𝑠 𝑚𝑢𝑒𝑠𝑡𝑟𝑒𝑎𝑑𝑎𝑠)
Nombre de la
métrica propuesta:
Tiempo de
respuesta
(Relación de
tiempo de
respuesta de
peor caso)
Fórmula:
𝑻𝒎𝒂𝒙
𝑿=
𝑹𝒎𝒂𝒙
0≤𝑋
El más
cercano a 1.0
Nota. La distribución se puede calcular como se ilustra a
continuación.
𝑇
Relación máxima estadística 𝑌 = 𝑅 𝑑𝑒𝑣
𝑚𝑎𝑥
𝑻𝒅𝒆𝒗 = 𝑇𝑚𝑒𝑎𝑛 + 𝐾(𝐷𝐸𝑉 )
𝑻𝒅𝒆𝒗 Se desvía del tiempo desde el tiempo medio hasta el
tiempo particular: p. 2 o 3 veces la desviación estándar.
𝐾 Coeficiente (2 o 3)
𝑫𝑬𝑽 = √∑
𝑻𝒎𝒆𝒂𝒏 = ∑
(𝑇𝑖 − 𝑇𝑚𝑒𝑎𝑛 )2
; 𝑝𝑎𝑟𝑎 𝑖 = 1 ℎ𝑎𝑠𝑡𝑎 𝑁
𝑁−1
𝑇𝑖
𝑝𝑎𝑟𝑎 (𝑖 = 1 ℎ𝑎𝑠𝑡𝑎 𝑁)
𝑁
45
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Integración sistema / software
Pruebas de calificación
Operación
Mantenimiento
Desarrollador
Ing. De Software
SQA
Sub característica:
Descripción de la Sub
característica:
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
Utilización de recursos
Se refiere a la velocidad del sistema y su eficiencia en utilización de recursos.
¿Cuál es el tiempo que se tarda en completar una tarea especificada?
¿Cuánto tiempo se tarda antes de la respuesta del sistema a una operación
especificada?
Tiempo
de
respuesta
Fórmula:
𝑇
0<𝑇
Cuanto antes mejor.
Integración Sistema / Software
Pruebas de calificación
Operación
Mantenimiento
Desarrollador
Ing. De Software
SQA
T = (tiempo de obtener el resultado)
- (tiempo de entrada del comando terminado)
5.5 Características de mantenimiento
Sub característica:
Capacidad para ser probado
Descripción de la Sub
característica:
Incluye requisitos de instalación y configuración, así como facilidades para
mantener y administrar la operación del sistema.
Justificación del criterio
de calidad (o evaluación)
seleccionado con base al
caso de estudio:
¿Puede el usuario y el mantenedor realizar fácilmente pruebas operativas con puntos de
verificación después del mantenimiento?
Fórmula:
𝑨
𝑩
Restablecer
0≤𝑋≤1
la prueba
Cuanto más grande
y más cercano a 1.0
es mejor.
Pruebas de codificación
Operación
Mantenimiento
Desarrollador
Ing. De Software
𝑿=
Nombre de la métrica
propuesta:
Etapa de posible
evaluación:
Rol responsable de
evaluación:
A = Número de casos en los que el mantenedor
puede pausar y reiniciar la ejecución de la prueba
en los puntos deseados para comprobar paso a
paso
B = Número de casos de pausa de ejecución de
la prueba
46
Tabla de resultados de la evaluación del sistema en línea de CFE.
No
Característica
Sub
Nombre
característica
métrica
de
la
Consideraciones
Fórmula
Valor
Resultado
óptimo
El funcionamiento del sistema
1
Funcionalidad
Interoperabilidad
Intercambio de
datos
(Basado en el
indica que todos los elementos
formato de datos)
cumplieron la funcionalidad
funcionales se implementaron
durante las pruebas y que todos
𝑿=
𝟏
𝟏
1
1
1
1
requerida.
Para la evaluación se ingresó al
sistema
desde
navegadores
diferentes
web
(Firefox,
Chrome, Internet Explorer y MSIntercambiabilidad
2
Funcionalidad
Interoperabilidad
(Basado
en
los
intentos de éxito
del usuario)
Edge), así como desde diferentes
dispositivos
(Smart
pone
Samsung Galaxy S3 y Tablet
𝑿=𝟏−
𝟎
𝟒
Samsung Galaxy A) encontrando
consistencia e integridad en las
funcionalidades del sistema, por
lo tanto se observó que el sistema
puede intercambiar datos con
diferentes plataformas.
Durante
Cumplimiento
3
Funcionalidad
de
la
funcionalidad
Expectativa
de
exactitud
las
pruebas
los
resultados fueron consistentes y
constantes por lo que no hubo
discrepancias.
El
tiempo
𝑿=
𝟎
𝟏𝟎
0
0
𝑿=
𝟎
𝟏𝟎
0
0
𝑿=
𝟎
𝟏𝟎
0
0
𝑨
→𝟎
𝑩
1
1
0
0
de
prueba fue de 10 minutos.
Durante
Cumplimiento
4
Funcionalidad
los
constantes por lo que no hubo
computacional
funcionalidad
pruebas
resultados fueron consistentes y
Precisión
de la
las
discrepancias.
El
tiempo
de
prueba fue de 10 minutos.
Durante
las
pruebas
los
resultados fueron consistentes y
5
Funcionalidad
Exactitud
Precisión
constantes por lo que no hubo
discrepancias.
El
tiempo
de
prueba fue de 10 minutos.
6
7
Fiabilidad
Fiabilidad
Tolerancia
a
fallos
Tolerancia
fallos
Prevención
de
daños
a
Prevención
fallas
Durante la fase de pruebas, no se
registró ningún daño o avería por
𝑿=𝟏−
lo que el cociente tiende a cero
de
Durante la fase de pruebas, no se
registró ningún daño o avería por
𝑿=
𝑨
→𝟎
𝑩
lo que el cociente tiende a cero
47
Se asume que todos los fallos han
8
Fiabilidad
Tolerancia
a
fallos
Prevención
de
sido
evitados
puesto
se
que
mantuvo
el
operación
sistema
en
incorrecta
funcionamiento y estable durante
𝑿=
𝑨
→𝟎
𝑩
0
0
1
1
0
0
0
𝑇≈0
0
𝑇≈0
1
0.8
1
1
0
𝑇≈0
la fase de pruebas.
9
Fiabilidad
Recuperabilidad
10
Fiabilidad
Recuperabilidad
En toda la etapa de evaluación, el
Disponibilidad
𝒀=
sistema estuvo disponible.
Tiempo
de
inactividad
En toda la etapa de evaluación, el
sistema estuvo disponible.
𝑿=
𝟏
𝟏
𝑻
→𝟎
𝑵
El uso del sistema es intuitivo, los
11
Usabilidad
Facilidad
de
aprendizaje
Facilidad
de
aprendizaje de las
funcionalidades
campos
describen
la
funcionalidad claramente por lo
𝑻→𝟎
que la curva de aprendizaje es
inmediata y el tiempo invertido es
mínimo, casi cero.
Durante la fase de prueba, se
realizaron tareas específicas, tal
Facilidad
12
Usabilidad
Facilidad
de
aprendizaje
de
aprendizaje
para
mejorar el uso de
una tarea.
como dar de alta un usuario
nuevo y cambiar dirección de email.
El
proceso
para
los
𝑻→𝟎
diferentes usuarios que realizaron
las tareas fue inmediato, por lo
que el tiempo de aprendizaje es
casi cero.
El sistema no cuenta con un
apartado
Eficacia
13
Usabilidad
Facilidad
de
aprendizaje
de
la
para
búsquedas
concretas de ayuda, únicamente
documentación
tiene una sección de preguntas
del usuario y / o
frecuentes relacionadas con los
del
servicios de la empresa. Sí el
sistema
de
ayuda
usuario
tiene
dudas
𝑿=
𝟒
𝟓
del
funcionamiento del sistema no
tiene manera de consultarlas.
Eficacia
14
Usabilidad
Facilidad
de
aprendizaje
de
la
documentación
Cada servicio cuenta con un
del usuario y / o
apartado
sistemas
referentes al servicio y al proceso.
de
de
instrucciones
𝑨
𝑩
𝑨=𝑩
𝑿=
ayuda en uso
El uso del sistema es intuitivo, los
15
Usabilidad
Facilidad
aprendizaje
de
Frecuencia
ayuda
de
campos
describen
la
funcionalidad claramente por lo
𝑻→𝟎
que la curva de aprendizaje es
inmediata y el tiempo invertido es
48
mínimo, casi cero.
Durante
Consistencia
16
Usabilidad
Operabilidad
operativa durante
el uso
las
pruebas
los
resultados fueron consistentes y
constantes por lo que no hubo
𝑿=
𝑨
→𝟎
𝑩
0
0
0
0.5
0
𝑋≈0
1
1
1
1
0≤𝑋
1
1
1
1
1
discrepancias.
La
funcionalidad
para
la
evaluación fue la de ingresar un
correo y un nombre de usuario
erróneo en el inicio de sesión, el
17
Usabilidad
Operabilidad
Error
de
corrección
sistema indicó el error y mostró
una recomendación, por lo que al
𝑻 = 𝟏𝟎 − 𝟏𝟎. 𝟓
usuario le fue fácil realizar la
corrección
de
manera
inmediata.
Las
unidades
casi
de
tiempo en la medición fueron en
segundos.
18
Usabilidad
Operabilidad
Corrección
de
errores en uso
Usabilidad
Operabilidad
𝑿=
proporcionales en cuanto a los
→𝟎
𝑨
𝑼𝑶𝑻
eventos realizados.
Disponibilidad de
19
Las pruebas fueron directamente
valor
Durante el periodo de pruebas el
usuario
puede
realizar
y
establecer los valores de los
predeterminado
𝑿=
𝑨
→𝟎
𝑩
parámetros de la funcionalidad
en uso
que utilizó.
Para la evaluación se recurrió a la
“ingreso
funcionalidad
20
Usabilidad
Operabilidad
de
Comprensión del
usuario”, en dónde se ingresaron
mensaje en uso
datos erróneos, el mensaje del
sistema fue claro y directo para
𝑿=
𝑨
𝑼𝑶𝑻
𝑨 = 𝑼𝑶𝑻
poder corregirlo.
La relación en el valor de los
21
Usabilidad
Operabilidad
Mensajes de error
auto explicativos
parámetros durante la prueba
fueron
directamente
proporcionales en una relación
𝑨
𝑩
𝑨=𝑩
𝑿=
1:1.
Durante la fase de evaluación no
22
Usabilidad
Operabilidad
Recuperabilidad
se presentó ninguna falla que
del error operativo
pusiera en riesgo al sistema y de
en uso
la
cual
el
usuario
no
𝑿 = 𝟏−𝟎
fuera
informado.
Tiempo
23
Usabilidad
Operabilidad
operaciones
entre
Durante la evaluación se realizó
de
un registro de errores por parte
error humano en
del usuario, siendo en su mayoría
𝑿=
𝑻
𝑵
𝑻=𝑵
49
uso
inherentes al sistema.
La relación de los parámetros
durante
24
Usabilidad
Disponibilidad
para
deshacer
(Corrección
de
errores
del
usuario)
Operabilidad
la
prueba
fueron
directamente proporcionales en
una relación 1:1 entre el número
de
corrección
de
errores
de
𝑨
𝑩
𝑨=𝑩
1
1
𝑨
𝑩
𝑨=𝑩
-
1
1
1
𝑻→𝟎
𝑇≈0
1
1
1
1
T
𝑻→𝟎
𝑇≈0
𝑨
𝑩
𝑨=𝑩
1
1
𝑿=
entrada del usuario y el número
de intentos para corregirlos.
La relación del valor de los
parámetros durante la prueba
fueron
25
Usabilidad
Operabilidad
Personalización
directamente
proporcionales en una relación
1:1 entre el número de funciones
𝑿=
personalizadas con éxito y el
número de intentos.
La
Reducción
26
Usabilidad
Operabilidad
evaluación
es
concluyente
del
debido a que las funcionalidades
procedimiento de
son concretas y suficientes en
operación
cuanto
los
requerimientos
𝑿 = 𝟏−𝟎
del
usuario.
27
Eficiencia
Comportamiento
Tiempo
en el tiempo.
respuesta
de
Las
ejecuciones
de
las
T
funcionalidades son instantáneas.
Durante el periodo de evaluación,
Tiempo
28
Eficiencia
de
Comportamiento
respuesta
en el tiempo.
(Tiempo medio de
respuesta)
la
relación
del valor
de
los
parámetros fueron directamente
proporcionales
en una relación
𝑿=
𝑻𝒎𝒆𝒂𝒏
𝑻𝑿𝒎𝒆𝒂𝒏
1:1 en cuanto al tiempo de
respuesta requerido y el número
de evaluaciones.
Tiempo
de
respuesta
29
Eficiencia
Comportamiento
(Relación
de
en el tiempo.
tiempo
de
respuesta de peor
caso)
30
Eficiencia
31
Mantenimiento
Utilización
de
Tiempo
recursos
respuesta
Capacidad para
Restablecer
ser probado
prueba
Durante el periodo de evaluación,
la
relación
del valor
de
los
parámetros fueron directamente
proporcionales
𝑿=
𝑻
𝑹
en una relación
1:1 en cuanto al tiempo de
𝑻=𝑹
respuesta requerido y el número
de evaluaciones.
de
Las ejecuciones de las tareas son
instantáneas.
la
𝑿=
50
Análisis de los resultados de la evaluación del sistema CFE en línea bajo la
norma ISO/IEC 9126
Se obtuvieron 30 resultados óptimos de las 31 evaluaciones realizadas, lo que significa 96.77% de
calificación bajo la norma ISO/IEC 9126. Sin embargo estos resultados pueden variar en función de la
apreciación y de las consideraciones para establecer el valor de los parámetros durante la evaluación
de quiénes la realizan. Con esto no se trata de afirmar que los resultados son erróneos, sino
subjetivos pero al mismo tiempo suficientes, que para efectos del objetivo de la aplicación de la
norma ISO/IEC 9126 como modelo de calidad, son válidos.
La afirmación anterior fue expuesta por Khelifi, Suryn & Seffah, en su trabajo publicado en el 2003
reclamaron que: “aunque no es exhaustivo, estas series constituyen el más extenso modelo de
calidad de software desarrollado a la fecha ”esto es solo un modelo fácil para los no especialistas en
contratar, el ejemplo más simple que el modelo IEEE P1484.1 LTSA, SCORM o IMS. A diferencia de
otros esquemas, ISO 9126 cubre un amplio espectro de Rasgos del sistema”
Del mismo modo, Luz Amira Duarte, en su ensayo Debilidades de la Norma ISO 9126 (2015) [1],
argumenta que:
“La serie de normas ISO/IEC 9126 establece un modelo de calidad de producto y muestra la
identificación de los requerimientos de calidad como un paso necesario para la calidad de
producto. Sin embargo, no establece el modo en que se ha de determinar los requerimientos de
calidad (interna, externa, o en uso) relevantes para el producto a construirse y tampoco
establece como determinar los niveles esperados en las métricas a usarse. Determinar los
requerimientos de calidad y los niveles de métricas, aparentan ser actividades sencillas, pero
podrían resultar ser engorrosas y propensas a errores si no se tiene establecido un esquema
sistemático para su determinación”
Estos y otros señalamientos fueron reconocidos por la ISO y en su esfuerzo por mejorar las normas
ISO/IEC 9126, trabajó en la generación de nuevos estándares de calidad de productos de software,
los cuales ha denominado Requisitos de Calidad de Productos Software y Evaluación bajo la norma
ISO 25000 que remplaza a la actual ISO 9126 y la serie ISO 14598, la cual analizaremos en el
siguiente apartado.
[1] En el ensayo de Luz Amira, se puede encontrar un análisis más detallado de las deficiencias de la norma
ISO/IEC 9126, así como comparaciones con otras normas ISO relacionadas, críticas de otros autores y otras
referencias.
51
6. Análisis de la norma ISO 14598. Evaluación de producto de software
ISO 14598 es una norma orientada al producto en el área de tecnología de la información, sirve para
la evaluación del mismo. Proporciona un marco de trabajo para evaluar la calidad de todo tipo de
producto software e indica los requisitos para los métodos de medición y el proceso de evaluación,
proporcionando métricas y requisitos para los procesos de evaluación, a través de 6 etapas.
La descripción de las etapas no se encontraron en la página de ISO así que para exponerlas se ha
tomado como referencia el trabajo de fin de grado en Ingeniería de Software realizado por Javier
Valenciano López; Auditoría Mantenibilidad, Aplicaciones según la ISO/IEC 25000 (2015):
1. SO/IEC 14598-1 Visión General:
Establece un resumen de las otras cinco etapas, explica la relación entre la evaluación del
producto software y el modelo de calidad.
Actividades:
• Establecer los requisitos de evaluación
• Especificar la evaluación
• Planear la evaluación
• Ejecutar la evaluación
2. ISO/IEC 14598 - 2 Planificación y Gestión
Contiene requisitos y guías para las funciones de soporte tales como la planificación y gestión de
la evaluación del producto del software.
Actividades:
• Preparación de políticas
• Definición de objetivos
• Identificación de la tecnología
• Asignación de responsabilidades
• Evaluación de software desarrollado y adquirido
3. ISO/IEC 14598-3 Proceso de desarrolladores:
Dirigido a las organizaciones que planean desarrollar un producto o mejorar uno existente, realiza
evaluaciones de producto utilizando indicadores que puede predecir la calidad de los productos
finales.
Actividades:
• Organización
• Planeamiento
• Especificaciones, Diseño, Montaje
4. SO/IEC 14598-4 Proceso de comparadores:
Dirigido a las organizaciones que pretenden comparar o rehusar un producto de software
existente, se aplica con el propósito de aceptación de un producto.
Actividades:
52
•
•
•
•
Requerimientos
Especificación evaluación
Diseño evaluación
Ejecución evaluación
5. ISO/IEC 14598-5 Proceso evaluadores:
Este proceso lo utilizan organizaciones encargadas de evaluar, provee los requisitos y guías para
la evaluación del producto software.
Actividades:
• Trazabilidad
• Resultados
• Problemas
• Mejoras
• Conclusiones
6. ISO/IEC 14598-6 Modulo evaluación:
Especifica las mediciones que van a ser tomadas sobre los atributos de calidad que se definieron
en la etapa anterior, provee las guías para la documentación de la evaluación.
Actividades:
•
•
•
•
Introducción
Alcance
Entradas
Resultados
Figura 5. Estructura ISO/IEC 14598
Es importante señalar que en la página de ISO está publicada una revisión que se realizó en el mes
de abril del año 1999, en la que señala que la norma ISO 14598-1 actualmente está retirada. También
especifica que ISO/IEC 14598-1: 1999 ha sido revisada por ISO/IEC 25040: 2011.
53
Al principio de la sección, se mencionó que tanto ISO/IEC 9126 como ISO/IEC 14598-1 están
orientadas al producto, lo podemos revisar en el siguiente esquema.
Figura 6. Relación entre ISO/IEC 2196 e ISO/IEC14598
54
Figura 7. La calidad en el ciclo de vida del software
6.1 Diagrama de flujo del método de Evaluación de producto de software de la
norma ISO 14598
En la práctica, es decir, durante la fase de evaluación, el procedimiento se puede describir de
acuerdo al siguiente diagrama.
Figura 8. Diagrama de flujo del método de evaluación del producto software bajo la norma ISO 14598
55
7. Análisis de la norma ISO 15504. Evaluación de procesos de desarrollo de software
de la norma ISO 15504
La norma ISO/IEC 15504 tiene sus orígenes en el año de 1993, cuando la organización ISO aprobó
un programa de trabajo para el desarrollo de un modelo estándar internacional con el fin de
establecer y mejorar la capacidad y madurez de los procesos de las organizaciones.
En un principio se conoció como SPICE
(Software Process Improvment and Capability
Determination) cuya primera versión apareció en el año de 1995. En el año de 1998 después de las
primeras revisiones de trabajo recibió la categoría de informe técnico bajo la denominación ISO/IEC
TR 15504. Fue hasta el año del 2003, en que oficialmente se dio a conocer como estándar y partir de
entonces se han hecho varias mejoras con el propósito de fortalecerla.
La norma ISO 15504 sirve para evaluar la capacidad de los procesos y la madurez de una
organización, provee un marco de trabajo (framework) para evaluar de manera general cualquier
modelo de procesos, es importante señalar que no es específica del software. Sin embargo, ofrece
ejemplos para la evaluación y mejora de la calidad de proceso de desarrollo y mantenimiento de
software junto con el modelo de procesos ISO 12207.
Una descripción de la estructura de la ISO/IEC 15504, la encontramos en la publicación de la revista
virtual Católica del Norte (2011) por Catherine, A. González, J. y Rodríguez, A., quiénes especifican
que:
“La ISO/IEC 15504 presenta la estructura de la figura 1, contempla las partes normativas (1,
2, 7), que se refieren a aquellas donde se definen los requisitos mínimos para realizar una
mejora de procesos de desarrollo y para medir el nivel de madurez de la organización en
cuanto al desarrollo de software, y por otro lado, las no normativas (3, 4, 5, 6), en donde se dan
las guías de interpretación de los requisitos mínimos y en sí sobre la norma”.
56
Figura 9. Estructura del estándar ISO/IEC 15504.
7.1 Diagrama de flujo del método de Evaluación de procesos de desarrollo de
software de la norma ISO 15504
Figura 10. Contexto de la evaluación de procesos
57
58
8. Reflexión sobre las ventajas e importancia de las 3 normas estudiadas en este
trabajo y conclusión sobre ventajas competitivas de las empresas de software
que cuentan con productos certificados en esta norma.
Durante el desarrollo del presente trabajo, conocimos la estructura de tres normas de ISO
relacionadas con la calidad, aprendimos que en conjunto cubren los aspectos de mayor relevancia
relacionados con el software; cualidades internas y externas, métodos de evaluación, requisitos para
la evaluación y el proceso en sí de evaluación. Así mismo, se realizó una evaluación aplicando y
considerando las propiedades de las métricas, en un caso específico.
El conjunto de las tres normas, es también un indicio de los avances que se han tenido para
estandarizar los criterios de la evaluación, se puede decir que los aspectos cuantitativos han sido
cubiertos en gran medida. Por lo tanto podemos reconocer el gran valor que aportan a las empresas
dedicadas al desarrollo de software que las incorporan en sus procesos, debido a que pueden
controlar y prever los defectos y fallas desde las etapas tempranas de los proyectos para entregar un
producto que cumpla las expectativas de los involucrados. La ventaja competitiva que aportan es
clara y evidente, desde el hecho de contar con una certificación, las empresas tienen la manera de
garantizar los resultados, esto lo puede identificar el consumidor, no hace falta ser un especialista o
conocedor para saber cuándo un producto reúne las características deseadas, o lo que es lo mismo,
cuando un producto resuelve un problema en lugar de crear otros.
59
9. Fuente de Consulta
http://www.softwcare.com/pdf/ISO%2015504%20para%20mejora%20y%20evaluaci%F3n%20de%20procesos.pdf
Molina, C. (2003). Auditoría proceso desarrollo de software. [En línea]. < https://es.slideshare.net/pedrogarciarepetto/ai07proc-desar-soft >. [Mayo, 20017].
Garzás, J. Fernández, M. (2009). Una aplicación de la norma ISO/IEC 15504 para la evaluación por niveles de madurez de
Pymes y pequeños equipos de desarrollo. [En línea]. <
https://navabautista.wikispaces.com/file/view/Aplicacion+del+Modelo+de+Calidad+ISO.pdf >. [Mayo, 2017]
Valenciano, J. (2015). Auditoría mantenibilidad, aplicaciones según la ISO/IEC 25000. [En línea]. <
http://eprints.ucm.es/37485/1/AUDITOR%C3%8DA%20MANTENIBILIDAD%20APLICACIONES%20SEG%C3%9AN%20LA
%20ISO_IEC%2025000.pdf >. [Mayo, 2017]
Catherine, A. González, J., Rodríguez, S. (2011). Guía para pymes desarrolladoras de software, basada en la norma
ISO/IEC 15504. [En línea]. < http://revistavirtual.ucn.edu.co/index.php/RevistaUCN/article/viewFile/339/651>. [Mayo, 2017].
Carreras, O. (2012). Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística. [En línea]. <
https://olgacarreras.blogspot.mx/2012/03/estandares-formales-de-usabilidad-y-su.html >. [Mayo, 2017].
Tamayo, M. (2015). Calidad del software. [En línea]. < https://es.slideshare.net/fmrodriv/guia-iso-9126 > . [Mayo, 2017].
ISO/IEC JTC1/SC7. Secretariat CANADA. (1997). Software engineering –Product quality – Part 2: External metrics. [En
línea]. < www.cse.unsw.edu.au>. [Mayo, 2017].
Angeleri, P. (2015). ¿Cómo evaluar Productos de Software? Introducción a SQuaRE y caso de Estudio MyFEPS. [En línea].
< www.unit.org.uy >. [Mayo, 2017].
Alfonzo, P. (2013). Los estándares internacionales y su importancia para la industria del software. [En línea]. <
http://www.cyta.com.ar/ta1202/v12n2a3.htm >. [Mayo, 2017].
Amira, L.(2015). Debilidades de la norma ISO 9126. [En línea]. < https://es.slideshare.net/yohanaandrea39/265570212ensayodebilidadesdelanormaiso9126 >. [Mayo, 2017]
60
Descargar