Instructivo Iso 25000

Universidad de Cundinamarca
Facultad de Ingeniería
Escuela de Ingeniería de Sistemas
JOSE LUIS BONILLA
JHON JAIRO CACIANO
1
Protocolos de evaluación para la calidad del software
José Luis Bonilla
John Jairo Caciano
2
Contenido
CAPITULO PAG.
Introducción. 4
Objetivos 5
1. Conceptos 6
2. Norma ISO 25000 8
3. Modelo de calidad ISO 25010 11
4. Proceso de evaluación de software ISO 25040 19
5. Herramienta de Evaluación 25
6. Protocolos 30
Glosario
Bibliografía
3
Introducción
El avance de las tecnologías y los sistemas informáticos actuales ha crecido a niveles
exponenciales a partir del año 2000, la programación y las herramientas que usábamos para
desarrollar software han pasado de unas sencillas líneas blancas a sofisticadas interfaces y
funciones que atraen a las personas sin importar el área en el que se desempeñen.
A pesar de ser una ventaja el desarrollar software de modo cómodo en la mayoría de
casos se olvida la calidad del producto que se entrega y ya no es cuestionar solo la calidad de una
interfaz, es cuestionar muchos elementos que se requieren hoy en día para agradar al cliente.
Muchas empresas desarrolladoras de software compiten por crear productos que ellos
pueden considerar muy buenos, pero la responsabilidad y la decisión final está en el cliente, son
pocas las que se preocupan por conocer la opinión de ellos y aun mas, saber qué expectativas
tienen al momento de adquirirlos, esto les da una ventaja competitiva muy alta.
Esta guía presenta indicadores para evaluar la calidad de un software al momento de la
entrega, basados en los estándares de calidad sugeridos la norma ISO 25000 perteneciente a la
ISO (Organización Internacional de Normalización).
El desarrollo o selección de productos software que tengan calidad es muy importante en
la actualidad en muchas instituciones públicas, ya que su función es procesar toda la información
que estas poseen y nos permite definirla como el activo principal en una organización.
4
Objetivos
• Orientar a estudiantes y docentes del programa de ingeniería de sistemas en los estándares
mínimos de calidad para recibir o entregar un desarrollo.
• Aumentar y mantener la calidad en el desarrollo de las aplicaciones realizadas dentro del
programa de ingeniería de sistemas.
• Sensibilizar a los estudiantes sobre la importancia de la certificación de calidad software.
• Aportar un modelo o instrumento para la evaluación de aplicaciones informáticas
institucionalmente.
● Determinar las principales faltantes de calidad en los procesos de elaboración de los software
por lo estudiantes de ingeniería de sistemas.
5
Conceptos
Calidad
Conjunto de propiedades y características de un producto o servicio, que le confieren
aptitud para satisfacer unas necesidades explícitas o implícitas (ISO 8402)
Calidad del software
La calidad del software es el grado con el que un sistema, componente o proceso cumple
los requerimientos especificados y las necesidades o expectativas del cliente o usuario.
Norma Técnica
Es el documento establecido por consenso y aprobado por un organismo reconocido, que
suministra, para uso común y repetido, reglas, directrices y características para las actividades o
sus resultados, encaminadas al logro del grado óptimo de orden en un contexto dado.
Estándar
La normalización o estandarización es la redacción y aprobación de normas que se
establecen para garantizar el acoplamiento de elementos construidos independientemente, así
como garantizar el repuesto en caso de ser necesario, garantizar la calidad de los elementos
fabricados, la seguridad de funcionamiento y trabajar con responsabilidad social.
6
Protocolo
Es un procedimiento previamente establecido para llevar a cabo determinada función,
actividad o servicio.
7
Norma ISO 25000
Es conocida como SQuaRE (System and Software Quality Requirements and
Evaluation), es un conjunto de normas que tiene por objetivo la creación de un marco de trabajo
común para evaluar la calidad del producto software.
La familia ISO/IEC 25000 es el resultado de la fusión y mejoramiento de otras normas
anteriores, especialmente de las normas ISO/IEC 9126, que describe las particularidades de un
modelo de calidad del producto software e ISO/IEC 14598, que abordaba el proceso de
evaluación de productos software. Esta familia de normas ISO/IEC 25000 se encuentra
compuesta por cinco divisiones.
Ilustración 1. Divisiones ISO 25000. 2014. Recuperado de
http://iso25000.com/index.php/normas-iso-25000
8
ISO/IEC 2500n – División de Gestión de Calidad. Las normas que forman este
apartado definen todos los modelos, términos y definiciones comunes referenciados por todas las
otras normas de la familia 25000.
Actualmente esta división se encuentra formada por:
ISO/IEC 25000 - Guide to SQuaRE. Contiene el modelo de la arquitectura de SQuaRE,
la terminología de la familia, un resumen de las partes, los usuarios previstos y las partes
asociadas, así como los modelos de referencia.
ISO/IEC 25001 - Planning and Management establece los requisitos y orientaciones
para gestionar la evaluación y especificación de los requisitos del producto software.
ISO/IEC 2501n – División de Modelo de Calidad. Las normas de este apartado
presentan modelos de calidad detallados incluyendo características para calidad interna, externa
y en uso del producto software.
ISO/IEC 25010 - System and software quality models. Describe el modelo de calidad
para el producto software y para la calidad en uso. Esta Norma presenta las características y
subcaracterísticas de calidad frente a las cuales evaluar el producto software.
ISO/IEC 25012 - Data Quality model. Define un modelo general para la calidad de los
datos, aplicable a aquellos datos que se encuentran almacenados de manera estructurada y
forman parte de un Sistema de Información.
ISO/IEC 2502n – División de Medición de Calidad. Estas normas incluyen un modelo
de referencia de la medición de la calidad del producto, definiciones de medidas de calidad
(interna, externa y en uso) y guías prácticas para su aplicación.
9
ISO/IEC 25020 - Measurement reference model and guide. Presenta una explicación
introductoria y un modelo de referencia común a los elementos de medición de la calidad.
También proporciona una guía para que los usuarios seleccionen o desarrollen y apliquen
medidas propuestas por normas ISO.
ISO/IEC 25021 - Quality measure elements. Define y especifica un conjunto
recomendado de métricas base y derivadas que puedan ser usadas a lo largo de todo el ciclo de
vida del desarrollo software.
ISO/IEC 25022 - Measurement of quality in use. Define específicamente las métricas
para realizar la medición de la calidad en uso del producto.
ISO/IEC 25023 - Measurement of system and software product quality. Define
específicamente las métricas para realizar la medición de la calidad de productos y sistemas
software.
ISO/IEC 25024 - Measurement of data quality. Define específicamente las métricas para
realizar la medición de la calidad de datos.
ISO/IEC 2503n – División de Requisitos de Calidad. Las normas que forman este
apartado ayudan a especificar requisitos de calidad que pueden ser utilizados en el proceso de
elicitación de requisitos de calidad del producto software a desarrollar o como entrada del
proceso de evaluación. Para ello, este apartado se compone de:
ISO/IEC 25030 - Quality requirements. Provee de un conjunto de recomendaciones para
realizar la especificación de los requisitos de calidad del producto software.
10
ISO/IEC 2504n – División de Evaluación de Calidad. Este apartado incluye normas
que proporcionan requisitos, recomendaciones y guías para llevar a cabo el proceso de
evaluación del producto software.
Esta división se encuentra formada por:
ISO/IEC 25040 - Evaluation reference model and guide. Propone un modelo de
referencia general para la evaluación, que considera las entradas al proceso de evaluación, las
restricciones y los recursos necesarios para obtener las correspondientes salidas.
ISO/IEC 25041 - Evaluation guide for developers, acquirers and independent
evaluators. Describe los requisitos y recomendaciones para la implementación práctica de la
evaluación del producto software desde el punto de vista de los desarrolladores, de los
adquirentes y de los evaluadores independientes.
ISO/IEC 25042 - Evaluation modules. Define lo que la Norma considera un módulo de
evaluación y la documentación, estructura y contenido que se debe utilizar a la hora de definir
uno de estos módulos.
ISO/IEC 25045 - Evaluation module for recoverability. Define un módulo para la
evaluación de la subcaracterística Recuperabilidad (Recoverability).
11
Modelo de calidad ISO 25010
El modelo de calidad representa la piedra angular en torno a la cual se establece el
sistema para la evaluación de la calidad del producto. En este modelo se determinan las
características de calidad que se van a tener en cuenta a la hora de evaluar las propiedades de un
producto software determinado.
La calidad del producto software se puede interpretar como el grado en que dicho
producto satisface los requisitos de sus usuarios aportando de esta manera un valor. Son
precisamente estos requisitos (funcionalidad, rendimiento, seguridad, mantenibilidad, etc.) los
que se encuentran representados en el modelo de calidad, el cual categoriza la calidad del
producto en características y subcaracterísticas.
El modelo de calidad del producto definido por la ISO/IEC 25010 se encuentra
compuesto por las ocho características de calidad que se muestran en la siguiente figura:
Ilustración 2. Modelo de calidad norma ISO 25010, 2014.
Recuperado de http://www.iso25000.com/index.php/normas-iso-25000/iso-25010
12
Adecuación Funcional
Representa la capacidad del producto software para proporcionar funciones que
satisfacen las necesidades declaradas e implícitas, cuando el producto se usa en las
condiciones especificadas.
Completitud funcional. Grado en el cual el conjunto de funcionalidades cubre
todas las tareas y los objetivos del usuario especificados.
Corrección funcional. Capacidad del producto o sistema para proveer resultados
correctos con el nivel de precisión requerido.
Pertinencia funcional. Capacidad del producto software para proporcionar un
conjunto apropiado de funciones para tareas y objetivos de usuario especificados.
Eficiencia de desempeño
Esta característica representa el desempeño relativo a la cantidad de recursos
utilizados bajo determinadas condiciones.
Comportamiento temporal. Los tiempos de respuesta y procesamiento y los ratios
de throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones
determinadas en relación con un banco de pruebas (benchmark) establecido.
Utilización de recursos. Las cantidades y tipos de recursos utilizados cuando el
software lleva a cabo su función bajo condiciones determinadas.
13
Capacidad. Grado en que los límites máximos de un parámetro de un producto o
sistema software cumplen con los requisitos.
Compatibilidad
Capacidad de dos o más sistemas o componentes para intercambiar información y/o
llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o
software.
Coexistencia. Capacidad del producto para coexistir con otro software
independiente, en un entorno común, compartiendo recursos comunes sin detrimento.
Interoperabilidad. Capacidad de dos o más sistemas o componentes para
intercambiar información y utilizar la información intercambiada.
Usabilidad
Capacidad del producto software para ser entendido, aprendido, usado y resultar
atractivo para el usuario, cuando se usa bajo determinadas condiciones.
Capacidad para reconocer su adecuación. Capacidad del producto que permite al
usuario entender si el software es adecuado para sus necesidades.
14
Capacidad de aprendizaje. Capacidad del producto que permite al usuario
aprender su aplicación.
Capacidad para ser usado. Capacidad del producto que permite al usuario
operarlo y controlarlo con facilidad.
Protección contra errores de usuario. Capacidad del sistema para proteger a los
usuarios de hacer errores.
Estética de la interfaz de usuario. Capacidad de la interfaz de usuario de agradar
y satisfacer la interacción con el usuario.
Accesibilidad. Capacidad del producto que permite que sea utilizado por usuarios
con determinadas características y discapacidades.
Fiabilidad
Capacidad de un sistema o componente para desempeñar las funciones
especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados.
Madurez. Capacidad del sistema para satisfacer las necesidades de fiabilidad en
condiciones normales.
Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible
para su uso cuando se requiere.
15
Tolerancia a fallos. Capacidad del sistema o componente para operar según lo
previsto en presencia de fallos hardware o software.
Capacidad de recuperación. Capacidad del producto software para recuperar los
datos directamente afectados y reestablecer el estado deseado del sistema en caso de
interrupción o fallo.
Seguridad
Capacidad de protección de la información y los datos de manera que personas o
sistemas no autorizados no puedan leerlos o modificarlos. Esta característica se subdivide a
su vez en las siguientes subcaracterísticas:
Confidencialidad. Capacidad de protección contra el acceso de datos e información
no autorizados, ya sea accidental o deliberadamente.
Integridad. Capacidad del sistema o componente para prevenir accesos o
modificaciones no autorizados a datos o programas de ordenador.
No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar,
de manera que dichas acciones o eventos no puedan ser repudiados posteriormente.
Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una
entidad.
16
Autenticidad. Capacidad de demostrar la identidad de un sujeto o un recurso.
Mantenibilidad
Esta característica representa la capacidad del producto software para ser
modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o
perfectivas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de
componentes discretos) que permite que un cambio en un componente tenga un impacto
mínimo en los demás.
Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un
sistema software o en la construcción de otros activos.
Analizabilidad. Facilidad con la que se puede evaluar el impacto de un
determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas de
fallos en el software, o identificar las partes a modificar.
Capacidad para ser modificado. Capacidad del producto que permite que sea
modificado de forma efectiva y eficiente sin introducir defectos o degradar el desempeño.
17
Capacidad para ser probado. Facilidad con la que se pueden establecer criterios
de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas
para determinar si se cumplen dichos criterios.
Portabilidad
Capacidad del producto o componente de ser transferido de forma efectiva y eficiente de un
entorno hardware, software, operacional o de utilización a otro. Esta característica se
subdivide a su vez en las siguientes subcaracterísticas:
Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma
efectiva y eficiente a diferentes entornos determinados de hardware, software,
operacionales o de uso.
Capacidad para ser instalado. Facilidad con la que el producto se puede instalar
y/o desinstalar de forma exitosa en un determinado entorno.
Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en
lugar de otro producto software determinado con el mismo propósito y en el mismo
entorno.
18
Proceso de evaluación de software ISO 25040
ISO 25040 define el proceso para llevar a cabo la evaluación del producto software.
Dicho proceso de evaluación consta de un total de cinco actividades.
Ilustración 3. Modelo de evaluación ISO 25040, 2014.
Recuperado de http://www.iso25000.com/index.php/normas-iso-25000/iso-25040
Actividad 1: Establecer los requisitos de la evaluación
El primer paso del proceso de evaluación consiste en establecer los requisitos de la
evaluación.
Tarea 1.1: Establecer el propósito de la evaluación. En esta tarea se documenta el
propósito por el que la organización quiere evaluar la calidad de su producto software
(asegurar la calidad del producto, decidir si se acepta un producto, determinar la viabilidad
19
del proyecto en desarrollo, comparar la calidad del producto con productos de la
competencia, etc.).
Tarea 1.2: Obtener los requisitos de calidad del producto. En esta tarea se
identifican las partes interesadas en el producto software (desarrolladores, posibles
adquirientes, usuarios, proveedores, etc.) y se especifican los requisitos de calidad del
producto utilizando un determinado modelo de calidad.
Tarea 1.3: Identificar las partes del producto que se deben evaluar. Se deben
identificar y documentar las partes del producto software incluidas en la evaluación. El tipo
de producto a evaluar (especificación de requisitos, diagramas de diseño, documentación de
las pruebas, etc.) depende de la fase en el ciclo de vida en que se realiza la evaluación y del
propósito de ésta.
Tarea 1.4: Definir el rigor de la evaluación. Se debe definir el rigor de la
evaluación en función del propósito y el uso previsto del producto software, basándose, por
ejemplo, en aspectos como el riesgo para la seguridad, el riesgo económico o el riesgo
ambiental. En función del rigor se podrá establecer qué técnicas se aplican y qué resultados
se esperan de la evaluación.
Actividad 2: Especificar la evaluación.
En esta actividad se especifican los módulos de evaluación (compuestos por las
métricas, herramientas y técnicas de medición) y los criterios de decisión que se aplicarán
en la evaluación.
20
Tarea 2.1: Seleccionar los módulos de evaluación. En esta tarea el evaluador
selecciona las métricas de calidad, técnicas y herramientas (módulos de evaluación) que
cubran todos los requisitos de la evaluación. Dichas métricas deben permitir que, en
función de su valor, se puedan realizar comparaciones fiables con criterios que permitan
tomar decisiones. Para ello se puede tener en cuenta la Norma ISO/IEC 25020.
Tarea 2.2: Definir los criterios de decisión para las métricas. Se deben definir
los criterios de decisión para las métricas seleccionadas. Dichos criterios son umbrales
numéricos que se pueden relacionar con los requisitos de calidad y posteriormente con los
criterios de evaluación para decidir la calidad del producto. Estos umbrales se pueden
establecer a partir de benchmarks, límites de control estadísticos, datos históricos,
requisitos del cliente, etc.
Tarea 2.3: Definir los criterios de decisión de la evaluación. Se deben definir
criterios para las diferentes características evaluadas a partir de las subcaracterísticas y
métricas de calidad. Estos resultados a mayor nivel de abstracción permiten realizar la
valoración de la calidad del producto software de forma general.
Actividad 3: Diseñar la evaluación
En esta actividad se define el plan con las actividades de evaluación que se deben
realizar.
Tarea 3.1: Planificar las actividades de la evaluación. Se deben planificar las
actividades de la evaluación teniendo en cuenta la disponibilidad de los recursos, tanto
21
humanos como materiales, que puedan ser necesarios. En la planificación se debe tener en
cuenta el presupuesto, los métodos de evaluación y estándares adaptados, las herramientas
de evaluación, etc.
El plan de evaluación se revisará y actualizará proporcionando información
adicional según sea necesario durante el proceso de evaluación.
Actividad 4: Ejecutar la evaluación.
En esta actividad se ejecutan las actividades de evaluación obteniendo las métricas
de calidad y aplicando los criterios de evaluación.
Tarea 4.1: Realizar las mediciones. Se deben realizar las mediciones sobre el
producto software y sus componentes para obtener los valores de las métricas seleccionadas
e indicadas en el plan de evaluación. Todos los resultados obtenidos deberán ser
debidamente registrados.
Tarea 4.2: Aplicar los criterios de decisión para las métricas. Se aplican los
criterios de decisión para las métricas seleccionadas sobre los valores obtenidos en la
medición del producto.
Tarea 4.3: Aplicar los criterios de decisión de la evaluación. En esta última tarea
se deben aplicar los criterios de decisión a nivel de características y subcaracterísticas de
calidad, produciendo como resultado la valoración del grado en que el producto software
cumple los requisitos de calidad establecidos.
22
Actividad 5: Concluir la evaluación
En esta actividad se concluye la evaluación de la calidad del producto software,
realizando el informe de resultados que se entregará al cliente y revisando con éste los
resultados obtenidos.
Tarea 5.1: Revisar los resultados de la evaluación. Mediante esta tarea, el
evaluador y el cliente de la evaluación (en caso de existir) realizan una revisión conjunta de
los resultados obtenidos, con el objetivo de realizar una mejor interpretación de la
evaluación y una mejor detección de errores.
Tarea 5.2: Crear el informe de evaluación. Una vez revisados los resultados, se
elabora el informe de evaluación, con los requisitos de la evaluación, los resultados, las
limitaciones y restricciones, el personal evaluador, etc.
Tarea 5.3: Revisar la calidad de la evaluación y obtener feedback. El evaluador
revisará los resultados de la evaluación y la validez del proceso de evaluación, de los
indicadores y de las métricas aplicadas. El feedback de la revisión debe servir para mejorar
el proceso de evaluación de la organización y las técnicas de evaluación utilizadas.
Tarea 5.4: Tratar los datos de la evaluación. Una vez finalizada la evaluación, el
evaluador debe realizar el adecuado tratamiento con los datos y los objetos de la evaluación
según lo acordado con el cliente (en caso de ser una tercera parte), devolviéndolos,
archivándolos o eliminándolos según corresponda.
23
Herramienta de Evaluación
Usando como referencia este documento se desarrolló un instrumento de evaluación
conforme a la información recolectada en el modelo de calidad de la ISO 25010.
Este instrumento está desarrollado en formato Excel, permitiendo a los usuarios de
la guía aplicar la evaluación en cualquier ambiente que permita trabajar una hoja de
cálculo.
Consta de 11 hojas diseñadas de tal modo que el usuario solo complete los campos
de evaluación y generara automáticamente los cálculos y graficas correspondientes.
A continuación explicaremos de forma breve el contenido del Excel para que sea
más fácil identificar y trabajar la herramienta.
Hoja 1
24
En la primer hoja encontramos la plantilla de portada, en esta se coloca toda la
información base del software que se va a evaluar, entre estos tenemos la fecha, la ciudad,
el nombre del software, los objetivos generales del software, los objetivos específicos(si los
hay) y finalmente los evaluadores o quienes utilizan la plantillas.
Es necesario que la plantilla esté firmada y que la fecha sea precisa al momento de
evaluar.
Hoja 2
En la segunda hoja tenemos los parámetros, en esta hoja encontramos los ítems a
evaluar, la cantidad de preguntas por ítem y el porcentaje total por cada ítem, este
porcentaje o ponderado puede variar conforme el software que se desee evaluar, ya que
25
según la norma ISO 25040 no existe aún un estándar de porcentajes definido para algún
software en específico, por eso es dinámico y para esta herramienta se han definido los
porcentajes más altos para los ítems de adecuación funcional y mantenibilidad ya que son
las recomendaciones de un experto en esta certificación como lo es AENOR.
En caso que sea necesario cambiar esos porcentajes el evaluador puede hacerlo, eso
depende de su criterio.
El total siempre debe ser el 100%, ni menos ni más.
Hoja 3 - 10
26
Las hojas de la 3 a la 10 se componen de 3 partes descritas de la siguiente forma:
Evaluación. Se compone de los ítems y sus respectivos elementos a evaluar
asignando un valor entre 0 y 3 con base a los criterios de evaluación, también tienen una
casilla de descripción para detallar cualquier observación de ser necesaria.
Criterios de evaluación. Es una pequeña lista donde se muestran las equivalencias
entre los números y los porcentajes.
Grafica. Es una representación o modo de visualizar mejor los resultados, cada
grafica es automática y permite realizar un mejor análisis.
Hoja 11
27
Los resultados se muestran por ítem o categoría, resumiendo la calificación
realizada anteriormente en las hojas 3 a la 10, nos muestra el porcentaje inicial que se
definió en la hoja de parámetros (en la tabla se aprecia cómo máximo que es igual al valor
máximo que se puede tomar para esa categoría) y finalmente el porcentaje de ese ítem con
respecto al total de todos los ítems evaluados, dándonos una perspectiva global y un
análisis más preciso de la evaluación.
Las gráficas nos permiten analizar de modo más sencillo y observar el
comportamiento de la evaluación.
28
Protocolos
ÍTEM Protocolo
Adecuación
Funcional
- Observar los objetivos del software y verificar que se cumplan
Completitud
en el mismo.
funcional.
- Probar todos los campos que contengan información con
diferentes tipos de datos para verificar si hay controles y/o las
Corrección
restricciones funcionan bien para la información.
funcional.
- Luego llenar datos correctos y verificar que el resultado final
sea el que se espera del software.
- Verificar que tareas promete hacer el software.
Pertinencia - Probar 1 a 1 las diferentes actividades, así como las
funcional. direcciones, links y multimedia, para verificar que cumplen su
función.
Eficiencia de
Desempeño
- Verificar primero que complementos necesita para ejecutarse.
- Que versiones de complementos son los recomendados y
cuáles son los óptimos (mirar los más actuales).
Comportamiento
- Con esta información se procede a ejecutar el software y
temporal.
observar los tiempos de respuesta de sus acciones, como lo
son el tiempo de abrir, cerrar, cambiar de una actividad a otra,
etc.
- Verificar primero que complementos necesita para ejecutarse.
- Que versiones de complementos son los recomendados y
cuáles son los óptimos (mirar los más actuales).
- Con la información anterior lista procedemos a observar el
Utilización de
comportamiento de la aplicación en cuanto a rendimiento del
recursos
computador, sean recursos físicos o recursos de software.
- Observemos que al cerrarse la aplicación no queden procesos
en segundo plano ejecutándose o que al cerrar el software no
afecte las aplicaciones que estén abiertas.
- Verificar si el software tiene rangos máximos definidos
- En caso de tenerlos, hacer la respectiva prueba llevándolos a
Capacidad. ese límite.
- En caso de no tenerlos simplemente se evalúan como no
descritos.
Compatibilidad
- Al instalar el software verificar que las demás aplicaciones
Coexistencia. que estén activas no entren en conflicto.
29
- Instalar el software y observar si al ejecutarlo los

componentes se relacionan bien entre sí.
- En caso de un sistema de información por ejemplo verificar si
la base de datos, el servidor y la interfaz responden bien entre
sí.
Interoperabilidad.
- En caso de una página web, verificar lo que se muestra en el
navegador seleccionado.
- En caso de ser un software general, relacionar elementos
como plugins, extensiones u otro software que se requiera
para trabajar y que no presente problemas.
Usabilidad
- Al instala el software debe haber algún enlace que le permita
Capacidad para al usuario dar su opinión, sugerencias y/o contacto con la
reconocer su empresa o las personas que realizaron el software.
adecuación. - Se evalúa que todas las funciones correspondan a lo esperado
por el usuario.
- Al final del uso del software sabremos si es fácil su uso, su
aplicación para las actividades que el usuario requiere, esto
Aprendizaje
lograra que el usuario entienda su utilidad.
- Al abrir el software el movimiento entre él debe ser sencillo,

que las direcciones u contenidos no sean tediosos o
complicados de entender, esto facilitara bastante la
Operabilidad navegación por el mismo.
- Su instalación debe ser sencilla o las instrucciones para
instalarlo deben ser muy claras.
- Debe tener control de errores o restricciones para los datos o

Protección contra
el uso del software, ya sea para modificar o borrar algún
errores de
elemento.
usuario.
- La aceptación de la interfaz varía según el usuario, pero debe
haber al menos una básica.
Estética de la - Que no hayan elementos como botones o links muy grandes,
interfaz de colores extravagantes, textos muy pequeños o muy grandes.
usuario. - Dar un buen uso al espacio de la pantalla, es decir que la
interfaz no quede muy corta o que siempre se vea pequeña.
- Si es a color, debe tener un sistema de colores para daltónicos.

- Subtítulos para las personas que no pueden oír.
Accesibilidad - Audio para las personas con discapacidad visual.
- Pueden agregarse muchos elementos más según el fin del
software o a quien esté destinado.
Fiabilidad
30
- Si el software se cierra al encontrar un error puede reiniciarse

para continuar.
Madurez
- Si se cierra una sesión activa, puede recuperar la información
que se estaba trabajando o no.
- Al encontrar un error verificar que partes del software siguen
Tolerancia a funcionando o si al contrario todo el software deja de trabajar.
errores
- Si el software contiene información muy importante que

pueda perderse o borrarse, necesita un sistema de back up.
- Si el sistema de back ups esta implementado, realizar varias
Recuperabilidad
pruebas en diferentes condiciones para verificar que las
funciones del back up estén trabajando todas.
- Identificar qué elementos requieren conexión con otro

software o que requieran acceso a internet.
Disponibilidad. - Probar las actividades o funciones del software para conocer
la disponibilidad de las mismas o bajo qué circunstancias
pueden presentarse problemas.
Seguridad
- La base de datos no puede ser visible ni accesible sin los
permisos necesarios, ya sea desde el software o físicamente.
- Preferiblemente el software debe manejar permisos sobre el
Confidencialidad
sistema operativo que se instala, para que el administrador sea
el único que pueda hacer modificaciones.
- El software no debe poder editarse o modificarse de ningún

Integridad modo con otro software.
- Si el software tiene sistema de registros, lograr acceder a ellos

No repudio y verificar las acciones de los usuarios.
- Verificar si el software crea registros de los usuarios y sus

Responsabilidad acciones con fecha, hora, ciudad, ip, etc.
- Es necesario que el software cuente con roles o perfiles para

saber que usuarios acceden, que permisos tienen y que
Autenticidad
actividades pueden utilizar.
Mantenibilidad
31
- Se puede cambiar algún componente o elemento sin que

afecte los demás para ser ejecutado el software.
- Si sus funciones se pueden agregar o quitar sin alterar la
Modularidad
relación de las mismas, asi como los enlaces y/o multimedias
que contenga el software.
- Si el software viene en modulos y se puede integrar a otros

sistemas.
Reusabilidad - Si en las especificaciones del software se facilitan los códigos
fuentes del mismo.
- Verificar que tenga un modelo o guía de todas las actividades,

con eso se pueden analizar posibles cambios y elementos que
Analizabilidad
se relacionen.
- Verificar si el software incluye código fuente o módulos que

Capacidad para sean modificables en caso de ser requeridos.
ser modificado
- El software debe ser sencillo para examinar y evaluar, con

Capacidad para base a todos los aspectos planteados en la evaluación.
ser probado
Portabilidad
- Si el software trabaja en html, probarlo en diferentes
navegadores, al menos 4.
- Si el software se instala en sistema operativo, probarlo al
menos con 3 sistemas diferentes, preferiblemente Linux y
Windows teniendo en cuenta sus versiones.
- Si el software requiere elementos como servidores locales u
Adaptabilidad algún otro software, realizar varias pruebas en estas
herramientas.
- Si es un aplicativo móvil, probarlo en 2 sistemas operativos
con diferentes versiones, ejemplo con android 2.0 y 4.0.
- Si se realizan pruebas de hardware, al menos en 3 equipos en
condiciones bajas, medias y altas de capacidad para conocer
los recursos que se requieran.
- Instalar correctamente y sin errores.
- Que el instalador posea opciones para el usuario, como rutas o
Capacidad para contenidos específicos a instalar.
ser instalado - Que posea opciones de modificar, eliminar o reinstalar.
- Que la desinstalación sea limpia y no deje archivos de ningún
tipo ni carpetas (esto si el usuario lo desea).
32
- Los contenidos son sencillos de reemplazar en otro software.

- Utiliza un lenguaje muy antiguo o software antiguo y se puede
Capacidad para
preveer un cambio.
ser reemplazado
- Es muy sencillo y puede ser remplazado fácilmente por un
software más robusto.
33
Glosario
Atributo: Una característica física o abstracta mesurable de una entidad. Los atributos
pueden ser internos o externos.
Calidad: Son todas las características de una entidad que forman parte de su habilidad para
satisfacer las necesidades propias e implícitas.
Calidad externa: La extensión para la cual un producto satisface necesidades explícitas e
implícitas cuando es usado bajo condiciones específicas.
Calidad interna: Es la totalidad de atributos del producto que determinan su habilidad para
satisfacer las necesidades propias e implícitas bajo condiciones específicas.
Calificación: La acción de evaluar el valor medido al nivel de calificación adecuado. .
Defecto: Un paso, proceso o definición de dato incorrecto en un programa de computadora.
Desarrollador: Una organización que realiza actividades de desarrollo (incluyendo análisis
de los requisitos, diseño y pruebas de aceptación) durante el proceso del ciclo de vida del
software.
Escala: Un conjunto de valores con propiedades definidas.
Falla: La terminación de la capacidad de un producto de realizar una función requerida o
su incapacidad para realizarla dentro de límites previamente especificados.
Indicador: Una medida que se puede utilizar para estimar o para predecir otra medida.
Medición: Actividad que usa la definición de la métrica para producir el valor de una
medida.
Medida: Número o categoría asignada a un atributo de una entidad mediante una medición.
34
Medida directa: Una medida de un atributo que no depende de la medida de ningún otro
atributo.
Métrica: Es un método definido de valoración y su escala de valoración.
Medida externa: Una medida indirecta de un producto derivada de las medidas del
comportamiento del sistema del que es parte.
Modelo cualitativo: Es una serie de características y la relación entre las mismas, que
conforman la base de los requerimientos cualitativos específicos y la valoración cualitativa.
Módulo de evaluación: Un paquete de tecnología de evaluación para una característica o
sub característica de calidad de un software específico.
Necesidades implícitas: Necesidades que pueden no haber sido especificadas pero que son
necesidades reales cuando la entidad es usada en condiciones particulares.
Nivel de calificación: Un punto en la escala ordinal que es utilizado para categorizar una
escala de medida.
Servicio: Es una organización que presta servicios de mantenimiento.
Sistema: Una composición integrada que consiste en uno o más procesos, hardware,
software, instalaciones y personas, que proveen una capacidad para satisfacer una
necesidad establecida o un objetivo.
Software: Todo o parte de los programas, procedimientos, reglas y documentación
asociada a un sistema de procesamiento de información.
Usuario: Un individuo que utiliza el producto de software para realizar una función
específica.
Valoración: Emplear una métrica para asignar uno de los valores de una escala (el mismo
que puede ser un número o categoría) al atributo de una entidad.
35
Valoración Cualitativa: Es una evaluación sistemática del grado o capacidad de una
entidad para satisfacer necesidades o requerimientos específicos.
Validación: Confirmación por inspección y provisión de evidencia objetiva de que los
requerimientos particulares para un uso específico son alcanzados.
Verificación: Confirmación por examen y provisión de evidencia objetiva que los
requerimientos específicos han sido alcanzados.
36
Bibliografía.
Referencias bibliográficas
Norma ISO/IEC TR 9126-3: 2003 - Software engineering -- Product quality --
Norma ISO/IEC 14598-5:1998 - Part 5: Process for evaluators.
Norma [ISO 8402] ISO 8402:1994 Quality - Vocabulary
Referencias electrónicas
http://www.monografias.com/trabajos5/call/call.shtml
http://www.gestiopolis.com/canales2/gerencia/1/modcalidad.htm
http://es.wikipedia.org/wiki/ISO/IEC_9126
GUIA EVALUACION SOFTWARE, 2004 – ONGEI
Norma ISO/IEC 9126-1: 2001 - Software engineering -- Product quality -- Part
1: Quality model.
• Norma ISO/IEC TR 9126-2: 2003 - Software engineering -- Product quality --
Part 2: External metrics.
• Norma ISO/IEC TR 9126-3: 2003 - Software engineering -- Product quality --
Part 3: Internal metrics.
• Norma ISO/IEC 14598-1:1999 - Part 1: General overview.
• Norma ISO/IEC 14598-2:2000 - Part 2: Planning and management.
• Norma ISO/IEC 14598-3:2000 - Part 3: Process for developers.
• Norma ISO/IEC 14598-5:1998 - Part 5: Process for evaluators.
37

Instructivo Iso 25000

Cargado por

Información del documento

Descripción 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

Instructivo Iso 25000

Cargado por

Copyright:

Formatos disponibles

Universidad de Cundinamarca

JOSE LUIS BONILLA

JHON JAIRO CACIANO

Protocolos de evaluación para la calidad del software

José Luis Bonilla

John Jairo Caciano

2. Norma ISO 25000 8

3. Modelo de calidad ISO 25010 11

4. Proceso de evaluación de software ISO 25040 19

El avance de las tecnologías y los sistemas informáticos actuales ha crecido a niveles

A pesar de ser una ventaja el desarrollar software de modo cómodo en la mayoría de

Esta guía presenta indicadores para evaluar la calidad de un software al momento de la

ISO (Organización Internacional de Normalización).

El desarrollo o selección de productos software que tengan calidad es muy importante en

la actualidad en muchas instituciones públicas, ya que su función es procesar toda la información

• Orientar a estudiantes y docentes del programa de ingeniería de sistemas en los estándares

mínimos de calidad para recibir o entregar un desarrollo.

• Aumentar y mantener la calidad en el desarrollo de las aplicaciones realizadas dentro del

programa de ingeniería de sistemas.

• Sensibilizar a los estudiantes sobre la importancia de la certificación de calidad software.

• Aportar un modelo o instrumento para la evaluación de aplicaciones informáticas

por lo estudiantes de ingeniería de sistemas.

Conjunto de propiedades y características de un producto o servicio, que le confieren

aptitud para satisfacer unas necesidades explícitas o implícitas (ISO 8402)

Calidad del software

los requerimientos especificados y las necesidades o expectativas del cliente o usuario.

Es el documento establecido por consenso y aprobado por un organismo reconocido, que

La normalización o estandarización es la redacción y aprobación de normas que se

establecen para garantizar el acoplamiento de elementos construidos independientemente, así

fabricados, la seguridad de funcionamiento y trabajar con responsabilidad social.

Es un procedimiento previamente establecido para llevar a cabo determinada función,

Norma ISO 25000

Es conocida como SQuaRE (System and Software Quality Requirements and

común para evaluar la calidad del producto software.

La familia ISO/IEC 25000 es el resultado de la fusión y mejoramiento de otras normas

evaluación de productos software. Esta familia de normas ISO/IEC 25000 se encuentra

compuesta por cinco divisiones.

Ilustración 1. Divisiones ISO 25000. 2014. Recuperado de

otras normas de la familia 25000.

Actualmente esta división se encuentra formada por:

ISO/IEC 25000 - Guide to SQuaRE. Contiene el modelo de la arquitectura de SQuaRE,

asociadas, así como los modelos de referencia.

ISO/IEC 25001 - Planning and Management establece los requisitos y orientaciones

para gestionar la evaluación y especificación de los requisitos del producto software.

ISO/IEC 2501n – División de Modelo de Calidad. Las normas de este apartado

y en uso del producto software.

Actualmente esta división se encuentra formada por:

subcaracterísticas de calidad frente a las cuales evaluar el producto software.

datos, aplicable a aquellos datos que se encuentran almacenados de manera estructurada y

forman parte de un Sistema de Información.

ISO/IEC 2502n – División de Medición de Calidad. Estas normas incluyen un modelo

de referencia de la medición de la calidad del producto, definiciones de medidas de calidad

(interna, externa y en uso) y guías prácticas para su aplicación.

Actualmente esta división se encuentra formada por:

introductoria y un modelo de referencia común a los elementos de medición de la calidad.

medidas propuestas por normas ISO.

ISO/IEC 25021 - Quality measure elements. Define y especifica un conjunto

vida del desarrollo software.

ISO/IEC 25022 - Measurement of quality in use. Define específicamente las métricas

para realizar la medición de la calidad en uso del producto.

ISO/IEC 25023 - Measurement of system and software product quality. Define

específicamente las métricas para realizar la medición de la calidad de productos y sistemas

realizar la medición de la calidad de datos.