![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjv1nIiMR91FztROo2dUNdr0rrGAl40gqdoTc4HaZHWu2NYIcSJwd-Hm8EzgsCPXPHrWuRLAvtXgmOvwaV8z4DKgKGAVGUQiU1Z86JF-2EJhyphenhyphen0mrMPcoZera2U2Y1MKNPwrF2CSFbZMGUY/s320/CRITERIOS.jpg)
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.
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.).
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.
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.
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.
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.
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.
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.
En esta actividad se define el plan con las actividades de evaluación que se deben realizar.
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.
En esta actividad se ejecutan las actividades de evaluación obteniendo las métricas de calidad y aplicando los criterios de evaluación.
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.
Se aplican los criterios de decisión para las métricas seleccionadas sobre los valores obtenidos en la medición del producto.
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.
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.
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.
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.
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:
o Las métricas orientadas al tamaño y
o
·
·
Las métrica de
lineas 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 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, unos lenguajes 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:
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).
A continuación, tenemos el ejemplo de una aplicación software de
la seguridad de una vivienda.
No hay comentarios:
Publicar un comentario