Aspectos del estándar ISO 25000
Normas ISO 25000
La
Norma ISO 25000, conocida como SQuaRE (System and Software
Quality Requeriments and Evaluation) pertenece a una familia de normas que
tiene por objeto la creación de un marco de trabajo común para evaluar la
calidad del producto software. La finalidad es organizar, enriquecer y unificar
dos procesos principales: especificación de requerimientos de calidad
del software y evaluación de la calidad del software,
soportada por el proceso de medición de calidad del software.
Generalidades:
El modelo
de calidad ISO 25000, es un patrón muy detallado que abarca la calidad tanto
interna y externa de un producto determinado, en este caso desde su mismo uso,
proporcionando una visión general de los contenidos, en este orden de ideas, es
importante resaltar que esta parte en esencia es un sinónimo de medición de la
calidad. Lo que se busca con este tipo de modelo es guiar el desarrollo, con
los requisitos y la evaluación de atributos de calidad que conllevan a realizar
un análisis más profundo y significativo, elementos primordiales que hacen de
este modelo muy diferente a otros modelos que desde su creación se han especializado
en la búsqueda de la calidad de los productos al cual evalúan.
La norma
de calidad ISO 25.000, establece un modelo mencionado SQuaRE (Software product
Quality Requiments and Evolution),que significa Requisitos de calidad del
producto y evaluación; su especialidad es ante todo, es buscar un enfoque mucho
más amplio y completo, sin descuidar en ningún momento el proceso; en este
sentido atiende específicamente las características internas y externas
del producto, trayendo como consecuencia que el protocolo también permite
establecer que los requisitos de calidad sean los adecuados y de esa forma
contribuya a que el producto tengan una mayor calidad.
Con relación al Modelo de la ISO 25000, las
características internas y externas indican que para que un producto de
software sea producido con calidad, se debe tomar en cuenta no solo la calidad
del mismo, sino también la calidad del proceso que se está generando en el
momento. La calidad interna refleja la calidad externa y la de uso, lo anterior
se lleva a cabo mediante la implementación de 6 aspectos trascendentales:
funcionabilidad, fiabilidad, usabilidad, eficiencia, mantenibilidad,
portabilidad.
 |
- ISO
2500n: gestión de calidad.
- ISO
2501n: modelo de calidad: compuesto entre otros por fiabilidad, seguridad,
mantenibilidad y usabilidad.
- ISO
2502n: medición de calidad.
- ISO
2503n: requisitos de calidad.
- ISO
2504n: evaluación de calidad.
La familia ISO/IEC
25000 es el resultado de la evolución 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.
La Norma ISO 25000,
proporciona una guía para el uso de las series de estándares internacionales
llamados requisitos y Evaluación de Calidad de Productos Software (SQuaRE). La
norma establece criterios para la especificación de requisitos de calidad de
productos software, sus métricas y su evaluación, e incluye un modelo de
calidad para unificar las definiciones de calidad de los clientes con los
atributos en el proceso de desarrollo.
Las características de
calidad y sus mediciones asociadas pueden ser útiles no solamente para evaluar
el producto software sino también para definir los requerimientos de calidad. La
serie ISO/IEC 25000:2005 reemplaza a dos estándares relacionados: ISO/IEC
9126
(Software Product Quality) e ISO/IEC
14598 (Software
Product Evaluation).
Características:
La certificación de la calidad del producto
software con ISO 25000 permite a las empresas conocer la calidad de sus
productos, y a las empresas que compran software, decidirse por una solución u
otra en función de sus necesidades.
El beneficio principal de adoptar una norma ISO 25000 es el mismo que el de cualquier norma de este calibre,
asegurar que productos y servicios sean seguros, de confianza y sobre todo de
buena calidad.
La pregunta más común con respecto a la Norma ISO 25000 es cómo obtener la certificación, y es tan sencillo
como seguir los siguientes pasos:
1. Solicitud de la evaluación de calidad de un producto.
2. Informe de Evaluación de la calidad.
3. Solicitud de la certificación.
4. Solicitud del Informe de Evaluación.
5. Resultados de la evaluación realizada.
6. Resultado y Certificado de la calidad del
producto.
Esta evaluación y certificación supone un hito sin precedentes a nivel
internacional en el sector de la calidad e ingeniería del software, siendo el
primer caso en el que se evalúa y certifica un producto software para la
característica de adecuación funcional bajo los requisitos del estándar ISO 25000.
ISO/IEC
25010-Modelos del sistema y calidad del software: Detalla el modelo de la
calidad del producto, describiendo ocho características para evaluar el
software, las cuales son: A continuación, se detallan algunas de las
características del modelo de calidad:
Adecuación funcional
Permite
medir la capacidad que tiene un producto de software para proveer las funciones
que satisfacen requerimientos explícitos e implícitos cuando el software se usa
en determinadas condiciones.
Eficiencia de desempeño
Es el
comportamiento del sistema: funcionalidad, capacidad, utilización de recursos y
respuesta temporal. Dentro de sus características se encuentra que el sistema
requiere la utilización de un mínimo de recursos (por ejemplo, tiempo de CPU)
para ejecutar una tarea determinada.
Compatibilidad
Es el
proceso en el cual dos o más sistemas intercambian información y llevan a cabo
funciones requeridas en cuanto a su entorno hardware o software compartido.
Usabilidad
Algunas
de las características que la conforman son: comprensibilidad, aprendibilidad,
operabilidad, atractivo, cumplimiento de usabilidad, capacidad para reconocer
su adecuación, capacidad de aprendizaje, capacidad de ser usado, protección
contra errores de usuario, estética de la interfaz de usuario, accesibilidad.
También fácil de usar, fácil de aprender, atractivo para el usuario, conforme a
normas, uso intuitivo.
Fiabilidad
Madurez,
tolerancia a defectos, recuperabilidad, cumplimiento de fiabilidad.
En
determinadas condiciones, el software del sistema mantendrá su
capacidad-funcionalidad a lo largo de un periodo de tiempo.
Seguridad
Capacidad
de proteger la información y los datos de manera que no puedan ser leídos o
modificados por personas o sistemas no autorizados. La autenticidad, la
confidencialidad y la responsabilidad son sus principales características.
Mantenibilidad
Es la
medida del esfuerzo requerido para realizar cambios en los componentes de un
sistema de manera efectiva y eficiente. Algunas de sus características son
analizabilidad, modificabilidad, estabilidad, testabilidad, cumplimiento de
mantenibilidad, modularidad.
Portabilidad
Es la
capacidad del software de ser transferido a un nuevo entorno (software,
hardware, organización). Es fácil de instalar y desinstalar, además permite ser
adaptado de forma efectiva a diferentes entornos de hardware o software.
Criterios de evaluación y
métricas de evaluación
ISO/IEC 25040 define el proceso para llevar a cabo la evaluación del producto software. Dichos criterios de evaluación constan de un total de cinco actividades.
Establecer los requisitos de la evaluación.
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 del
proyecto en desarrollo, comparar la calidad del producto con productos de la
competencia, etc.).
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.
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.
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.
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.
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.
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.
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.
Diseñar la
evaluación.
En esta actividad se define el plan con las actividades de
evaluación que se deben realizar.
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 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.
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.
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.
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.
Aplicar
los criterios de decisión de la evaluación.
Se aplican los criterios de decisión para las métricas seleccionadas
sobre los valores obtenidos en la medición del producto.
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.
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.
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.
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.
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.
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.
Métricas.
Existen dos
tipos de métricas:
- Las métricas orientadas al tamaño y
- Las métricas orientadas a la función.
· Las métricas orientadas al tamaño su
objetivo es medir el tamaño (LCD) y las orientadas a la función (PF). Puntos
de función, cuyo objetivo es medir la funcionalidad del software.
· Las métrica de líneas de códigos consiste en medir
cuantas líneas de códigos posee nuestro sistema software, esta medida es
directa y se puede realizar utilizando cualquier tipo de herramienta que posee
en forma nativa los freeware de desarrollo del software para realizar la
medición, el objetivo es que conforme vamos participando en proyectos y vamos
completándolo deberíamos generar un histórico en información asociado a cada
proyecto, en la tabla de podemos ver dos tipos de proyectos, el cual nos indica
las líneas de código, el esfuerzo (horas mes), el coste económico, número de
páginas (doc), numero de errores detectados, defectos detectados y número de
personas.
Una vez tengamos este histórico podemos medir
métricas que son de gran utilidad, ejemplo, número de errores por línea código,
numero de defectos detectados por el cliente por línea de código o el coste
económico de cada línea de código, esto sirve para realizar una comparación de
los distintos tipos de proyectos y valorar la rentabilidad o la productividad
adquirida en cada proyecto de software.
Pero a pesar que este tipo de métrica es muy sencilla posee dos desventajas, depende del lenguaje de programación, ya que existen algunos lenguajes que son más expresivos que otros y algunos nos permiten implementar cierta funcionalidad, un lenguaje permite implementarse con una menor línea de códigos que con respecto a otro, esta diferencia es penalizada y es tenida en cuenta por las líneas de código y afecta al cálculo.
Por otro lado, la línea de código no
es justa con aquellos programadores que son eficientes a la hora de programar,
ya que algunos pueden hacerlo con una menor línea de códigos que otros.
Para intentar superar estos inconvenientes existe una segunda alternativa que son las métricas orientadas a función, estas métricas lo que pretenden es medir funcionalidad del software lo cual es independiente a la tecnología que se haya utilizado para desarrollar el proyecto, un ejemplo de este tipo de métrica consiste en los puntos de función, los puntos de función es una medida directa donde vamos a poder medir directamente sobre el código, y se centra en medir la funcionalidad de nuestra aplicación software.
El cálculo de los puntos de función
viene determinado por la anterior fórmula.
En esta fórmula existen dos
componentes, cuenta total y códigos de ajustes, la cuenta total se ajuste
mediante la siguiente fórmula:
En esta fórmula existen dos distintos
componentes cuenta total y factores de ajustes. El cálculo de cuenta total
consiste en analizar nuestra aplicación software e identificar cinco tipos de
valores de dominio estos tipos de valores son entradas de usuario, salidas de
usuarios, peticiones del usuario, archivos e interfaces externas.
Las entradas representan las entradas de información que el usuario proporciona a la aplicación, las salidas de usuarios representan aquellas peticiones y salidas interacción que ha tenido el usuario con la aplicación los archivos hacen referencia a aquellas bases de datos o a aquellos recursos de información que necesita nuestra aplicación para funcionar y ejecutarse correctamente y el quinto valor que son las interfaces externas que representa aquellas interfaces de comunicación que nuestra aplicación mantiene con otras aplicaciones o con otro módulos externos el objetivo es que debemos para cada uno de estos valores de dominio identificar cuanto resiste en números y para cada uno de estos se les ponderará por un factor de ponderación existen tres tipos de factores de ponderación según el grado de complejidad: un grado simple, otro medio y el complejo, si asumimos que nuestra aplicación tiene una complejidad media por ejemplo entradas de usuarios el valor sería multiplicado por cuatro, salidas por cinco, peticiones de usuario por cuatro y así consecutivamente, el objetivo es que cada uno de estos valores sea multiplicado por valor de ponderación, se obtiene un valor por cada valor de dominio y se suma y se obtiene un valor de conteo total, con esto tendríamos el primer componente de la fórmula.
El cálculo de factores de ajuste consiste en evaluar quince distintos tipos de valores, los cuales valoran la complejidad y otros aspectos del sistema software, el objetivo es evaluar cada uno de estos valores y asignarle un valor entre cero y cinco, siendo cero la de menor valor (poca influencia) y cinco la de mayor valor (valor esencial).
Mapa mental
Comentarios
Publicar un comentario