Propuesta de métrica de perfeccionamiento de gestión de la calidad en el proceso de desarrollo de Sofware (página 2)
MATERIAL Y
MÉTODOS
Los métodos utilizados para
desarrollar la investigación fueron los
Métodos teóricos Analítico Sintético, pues
a partir de un estudio detallado de las teorías, tendencias y
documentos relacionados con el
tema se sintetizaron los elementos más importantes y de
mayor utilidad para el desarrollo del trabajo y en el momento de
proponer una solución acertada y el histórico
lógico pues estudia toda la trayectoria, evolución y desarrollo
de los fenómenos, en nuestro caso, los fenómenos
relacionados con la gestión de la calidad y la aplicación de
métricas de software.
DESARROLLO
En la actualidad el uso de las métricas se
está poniendo en práctica con éxito en el amplio
mercado del software
pues las empresas productoras están reconociendo la
importancia que tienen las mediciones para cuantificar y
por consiguiente gestionar de forma más efectiva la
calidad de los procesos y productos de software.
En empresas que se dedican exclusivamente a la informática, se
tiene noción de la necesidad de formalizar los
mecanismos de estimación, comprendiendo que los
registros históricos
de antiguos proyectos realizados
pueden ayudar a estimar con mayor exactitud el esfuerzo,
tiempo de desarrollo,
costo, posibles errores,
recursos y tamaño
para los nuevos proyectos. Es válido aclarar que en
ocasiones los resultados de los procesos de medición no son
interpretados de la mejor manera, pues aún existen
compañías que no tienen una cultura adecuada sobre
la medición, desconociendo el alcance de madurez y
calidad que pudiera alcanzar el producto
final.Varios estándares y modelos de madurez han
incluido a las métricas de software, a
continuación se muestran algunos de ellos.ISO 15504
Incluye dentro de la categoría de los
procesos organizacionales (en la segunda parte de la norma)
al proceso de
medición, incluyendo la definición de
métricas, la gestión de los datos (incluidos los
históricos), y el uso de las métricas en la
organización.Familia ISO
9000-2000Se establece la necesidad de implementar el
proceso de medición con el objetivo de controlar la
calidad del producto, la capacidad del proceso y la
satisfacción del cliente, la gestión
usa métricas como una entrada fundamental para la
planificación,
control y gestión
del proyecto.CMMI
Incorpora un área de proceso denominada
"Medición y Análisis", cuyo
objetivo es desarrollar y establecer una capacidad de
medición que se pueda usar para dar soporte a las
necesidades de información de
la organización y
que proporcionen resultados objetivos que sean
útiles para la toma de decisiones y
acciones
correctivas.PSM
PSM constituye el documento base a partir del que
se ha elaborado el nuevo estándar ISO/IEC 15939 sobre la
medición del software, para la que proporciona
detalles adicionales respecto de las actividades y
tareas.También otros modelos incluyen métricas
para evaluar diferentes atributos de calidad del producto
casi siempre en el nivel del diseño o del
código entre estos
se encuentran el FCM (Factor Criterio Métrica), GQM
(Metas Preguntas Métricas).A pesar de esto, en una encuesta realizada en el
2006 sobre el nivel de conocimiento en el tema,
en el sitio Web
www.CalidaddelSoftware.com integrado por más de 900
miembros de los cuales el 83% son de España y 14% de
Iberoamérica, cuyo objetivo es mantener en contacto a
personas y organizaciones
interesadas en la Calidad y la Mejora del Proceso Software,
se preguntó: ¿Sobre qué cree que hay mayor
carencia de conocimientos? El mayor porciento de votos
entre las nueve áreas propuestas fue para la respuesta
estimación y métricas con un 26.84%.Es un problema la gran variedad de métricas
que existen y que en la mayoría de los casos no se
tiene un conocimiento explícito de sus objetivos y la
manera en que puedan aplicarse. Cada empresa es responsable
de definir las métricas que van a implementar teniendo
en cuenta sus objetivos organizacionales y necesidades de
información, las métricas deben estar alineadas
con el calendario, costo y niveles de calidad
propuestos.Un país con gran prestigio en el mercado de
software es la India, y en la
última década en el sector de las
tecnologías de la información (TI) ha tenido un
crecimiento promedio de 50%. Evidentemente es resultado de
la exportación de
software de calidad, pues de las 32 empresas certificadas
en el mundo con un nivel 5 de CMMI, 16 son de la India, lo
que indica entre otras cosas que implementan las
métricas que le permiten alcanzar dicha
certificación, pues como ya fue mencionado a partir
del nivel 2 en las áreas de proceso que se definen se
menciona la necesidad de las mediciones.En una de las sesiones del Foro de las Nuevas Tecnologías
dedicada a la calidad y certificación del software y
sus implicaciones para la empresa en
España en el 2001, se vieron reflejadas las
deficiencias en el sector de la calidad del software, pues
José Domingo Carrillo, presidente de la
Asociación Española de Métricas de Software
(AEMES) manifestó que para obtener software de calidad
no bastaba con aplicar una ingeniería del
producto adecuada, sin considerar todos los procesos que
intervienen en su desarrollo de una manera integrada,
sistemática y sincronizada para obtener un producto de
calidad, en los plazos y coste acordados. Además
comentaba acerca de las posibles métricas a aplicar al
producto y al proceso de desarrollo de software. . En abril
del 2004 dicha asociación edita una revista nacional
llamada: "Revista de Procesos y Métricas de las
tecnologías de la Información", pretendiendo
tratar todos aquellos temas que puedan ser incluidos dentro
del área de la gestión de los Procesos de las
Tecnologías de la Información.1. El mundo actual de las
Empresas de
Software.La Industria Cubana del Software (ICSW) está
llamada a convertirse en una significativa fuente de
ingresos nacional, como
resultado del correcto aprovechamiento de las ventajas del
considerable capital humano disponible.
La preparación de estos recursos humanos
especializados para las TIC es un factor clave
de la estrategia cubana de
Informatización. . La Universidad de las
Ciencias
Informáticas y el sistema de empresas
cubanas vinculadas a este trabajo jugarán un papel
importante en el desarrollo de la ICSW, y en la
materialización de los proyectos asociados al programa cubano de
informatización.A raíz de las visitas realizadas en algunas
de estas empresas y los resultados del cuestionario aplicado a
los encargados de calidad en las mismas puede decirse que
existen empresas que tienen definidas métricas basadas
fundamentalmente en la norma ISO 9126, pero no se
están aplicando en todos los proyectos pues depende en
gran medida de la decisión de los líderes y
desarrolladores. Se guardan registros históricos que
se utilizan para realizar estimaciones. Sin embargo en
otras empresas no se aplican métricas en los procesos
de desarrollo de software pues se considera que es
necesario lograr una mayor organización y
definición de los procesos de la empresa antes de
comenzar a utilizar un conjunto de métricas o al menos
una base sólida que justifique la aplicación de
las mismas, sin que esto constituya una pérdida de
tiempo.2
La industria Cubana del
softwareTodas las organizaciones de software exitosas
implementan mediciones como parte de sus actividades
cotidianas pues estas brindan la información objetiva
necesaria para la toma de decisiones y que tendrá un
impacto efectivo en el negocio y desempeño en la
ingeniería.Para poder asegurar que un
proceso o sus productos resultantes son de calidad o poder
compararlos, es necesario asignar valores, descriptores,
indicadores o algún
otro mecanismo mediante el cual se pueda llevar a cabo
dicha comparación.Para entender mejor el concepto de métrica es
necesario aclarar que los términos, métricas,
medición y medida no tienen el mismo
significado.Medida: Proporciona una indicación
cuantitativa de la extensión, cantidad, dimensiones,
capacidad o tamaño de algunos atributos de un proceso
o producto.Medición: La medición es el acto
de determinar una medida.Métrica: Es una medida cuantitativa
del grado en que un sistema, componente o proceso posee un
atributo dado.Se definen las métricas de software como "La
aplicación continua de mediciones basadas en técnicas para el
proceso de desarrollo del software y sus productos, para
suministrar información relevante a tiempo, así
el administrador junto con el
empleo de estás
técnicas mejorará el proceso y sus productos"
.Para una definición más completa debe
incluirse los servicios relacionados
al software como la respuesta a los resultados del cliente:
Ver Figura 1.1.
Figura 1.1. Concepto de
Métricas.Para que sea útil en el contexto del
mundo real, una métrica del software debe ser
objetiva, simple y calculable, consistente en el empleo
de unidades y tamaños, persuasiva, además
debería ser independiente del lenguaje de
programación y proporcionar una
realimentación eficaz para el desarrollador de
software.¿Por qué asegurarnos de que las
métricas cumplen estas condiciones?Las métricas deben ser un instrumento que
ayude a mejorar el proceso, producto o proyecto de
software, no tiene mucho sentido aplicar métricas
que lejos de ayudar a los desarrolladores constituyan
un problema; bien por ser demasiado complejas, porque
no se entiendan correctamente los objetivos que
persiguen o porque arrojen resultados imprecisos que no
puedan ser interpretados por los ingenieros de
software.Es importante entonces que una métrica
pueda obtenerse fácilmente, que se entienda por
qué y para qué se utiliza, que los
cálculos no produzcan resultados ambiguos o en los
que existan extrañas combinaciones de unidades, y
que la interpretación
de valores obtenidos esté acorde a las nociones
intuitivas del ingeniero de software. Por otra parte
las métricas no deben ser específicas para
ningún lenguaje de programación o
metodología de
desarrollo.4.
Características de las
Métricas5. Proceso de
Medición
3. Métricas de
Software
Todo proceso de medición del software tiene como
objetivo fundamental satisfacer necesidades de información a
partir de las cuales se deben identificar las entidades y los
atributos que deben ser medidos.
El proceso de medición, se caracteriza en cinco
actividades :
- Formulación: Obtención de medidas
y métricas del software apropiadas para la
presentación del software en cuestión. - Colección: Mecanismo empleado para
acumular datos necesarios para obtener las métricas
formuladas. - Análisis: Cálculo de las
métricas y la aplicación de herramientas matemáticas. - Interpretación: La evaluación de los
resultados de las métricas en un esfuerzo por conseguir
una visión interna de la calidad de la
presentación. - Retroalimentación: Recomendaciones
obtenidas de la interpretación de métricas y
técnicas transmitidas al equipo de desarrollo de
software.
6.
Clasificación de las
MétricasExisten innumerables métricas con
propósitos diferentes que reflejan o describen la
conducta del software,
estas pueden medir entre otros aspectos la competencia, calidad,
desempeño y la complejidad del software contribuyendo
a establecer de una manera sistemática y objetiva una
visión interna del trabajo mejorando así la
calidad del producto.A continuación se muestra la
clasificación de las mismas:Métricas de complejidad: Son todas las
métricas de software que definen de una u otra forma
la medición de la complejidad; Tales como volumen, tamaño,
anidaciones, costo (estimación) y configuración.
Estas son los puntos críticos de la concepción,
viabilidad, análisis, y diseño de
software.Métricas de calidad: Son todas las
métricas de software que definen de una u otra forma
la calidad del software; tales como exactitud,
estructuración o modularidad, pruebas, mantenimiento,
reusabilidad, entre otras. Estas son los puntos
críticos en el diseño, codificación,
pruebas y mantenimiento.Métricas de competencia: Son todas las
métricas que intentan valorar o medir las actividades
de productividad de los
programadores o practicantes con respecto a su certeza,
rapidez, eficiencia y
competencia.Métricas de desempeño:
Corresponden a las métricas que miden la conducta de
módulos y sistemas de un software,
bajo la supervisión del
sistema operativo o
hardware. Generalmente
tienen que ver con la eficiencia de ejecución, tiempo,
almacenamiento,
complejidad de algoritmos
computacionales, etc.Métricas estilizadas: Son las
métricas de experimentación y de preferencia; Por
ejemplo: estilo de código, las convenciones
denominando de datos, las limitaciones, etc. Pero estas no
se deben confundir con las métricas de calidad o
complejidad.Variedad de métricas: Tales
como portabilidad, facilidad de localización,
consistencia, etcétera.Estas clasificaciones de métricas fortalecen
la idea, de que más de una métrica puede ser
deseable para valorar la complejidad y la calidad del
software, teniendo en cuenta que para ello es necesario
medir los atributos del software.Un punto de partida para realizar estimaciones es
establecer una línea base de métricas que permita
a una organización sintonizar su proceso de
ingeniería del software para eliminar las causas de
los defectos que tienen el mayor impacto en el desarrollo
del software, es fundamental que una línea base
contenga datos recopilados de proyectos desarrollados
anteriormente lo que requiere una investigación
histórica de los mismos, la línea base no es
más que la recopilación de medidas, métricas
e indicadores que guíen el proyecto o el
proceso.
Figura 1.2. Proceso de
recopilación de métricas del
Software.Por lo general la información reunida no
necesariamente tiene que ser diferente. Las mismas
métricas pueden obtener beneficios a nivel de proceso,
proyecto y producto.7. Establecimiento de una
línea base8. Métricas del
Proceso
Las métricas del proceso se recopilan de todos los
proyectos y durante un largo período de tiempo. Su intento
es proporcionar indicadores que lleven a mejoras de los procesos
de software a largo plazo.. Un indicador es una
métrica o una combinación de métricas que
proporcionan una visión profunda del proceso del software,
del proyecto de software o del producto en si.
La medición del proceso implica las mediciones de
las actividades relacionadas con el software siendo algunos de
sus atributos típicos el esfuerzo, el coste y los defectos
encontrados. Las métricas permiten tener una visión
profunda del proceso de software que ayudará a tomar
decisiones más fundamentadas, ayudan a analizar el trabajo desarrollado,
conocer si se ha mejorado o no con respecto a proyectos
anteriores, ayudan a detectar áreas con problemas para poder
remediarlos a tiempo y a realizar mejores
estimaciones.
Para mejorar un proceso se deben medir los atributos del
mismo, desarrollar métricas de acuerdo a estos atributos y
utilizarlas para proporcionar indicadores que conduzcan la mejora
del proceso. Los errores detectados antes de la entrega del
software, la productividad, recursos y tiempo consumido y ajuste
con la planificación son algunos de los resultados que
pueden medirse en el proceso, así como las tareas
específicas de la ingeniería del software.
Actualmente existen muchas métricas, y éstas
deben usarse conforme se ajusten al proceso.
Las métricas del proceso se caracterizan
por:
- El control y ejecución del proyecto.
- Medición de tiempos del análisis,
diseño, implementación, implantación y
postimplantación. - Medición de las pruebas (errores, cubrimiento,
resultado en número de defectos y número de
éxito). - Medición de la transformación o
evolución del producto.
- 8.1 ¿Por qué el proceso?
Como se observa en la figura 1.3 , existen varios
factores que determinan la calidad del software y la eficiencia
de la organización, entre ellos están la complejidad
del producto, las tecnologías y las personas, así como
algunas condiciones de entorno que también tienen su
impacto, estas pueden ser condiciones de gestión (Ej.: plazo
de entrega, regla de empresa), entornos de desarrollo y
características del cliente, sin embargo en el centro de
todas ellas se encuentra el proceso pues es el único factor
de los controlables al mejorar la calidad del software y su
rendimiento como organización. Analizando y mejorando el
proceso se puede obtener mejores productos.
Figura 1.3. Determinantes de la calidad
del software y de la efectividad de la
organización.
Dado que el proyecto engloba todos los recursos,
actividades y artefactos, que se organizan para lograr un
producto de software es de vital importancia definir algunas
mediciones que ayuden al mejoramiento del mismo. A nivel de
proyecto se minimiza la planificación de desarrollo haciendo
los ajustes necesarios para evitar retrasos o riesgos potenciales, minimizar
los defectos, y por tanto la cantidad de trabajo que ha de
rehacerse, lo que ocasiona una reducción del coste global
del proyecto, además puede evaluarse la calidad de los
productos en el momento actual y cuando sea necesario.
La primera aplicación de métricas de proyectos
en la mayoría de los proyectos de software ocurre durante la
estimación. Las métricas recopiladas de proyectos
anteriores se utilizan como una base desde la que se realizan las
estimaciones del esfuerzo y del tiempo para el actual trabajo del
software. A medida que avanza un proyecto, las medidas del
esfuerzo y del tiempo consumido se comparan con las estimaciones
originales (y la planificación de proyectos). El gestor de
proyectos utiliza estos datos para supervisar y controlar el
avance. A medida que comienza el trabajo técnico, otras
métricas de proyectos comienzan a tener significado. Se
miden los índices de producción representados
mediante páginas de documentación, las horas
de revisión, los puntos de función y las líneas
fuentes entregadas, en el
proyecto se sigue la pista de los errores detectados durante
todas las tareas de ingeniería del software. Cuando va
evolucionando el software desde la especificación del
diseño, se recopilan las métricas técnicas para
evaluar la calidad del mismo y para proporcionar indicadores que
influirán en el enfoque tomado para la generación y
prueba del código.
Finalmente los indicadores de proyecto
permiten:
- Evaluar el estado del proyecto en
curso. - Seguir la pista de los riesgos
potenciales. - Detectar las Áreas de problemas antes de que se
conviertan en "críticas". - Ajustar el flujo y las tareas del
trabajo. - Evaluar la habilidad del equipo del proyecto en
controlar la calidad de los productos de trabajo del
software.
10. Métricas del
Producto
Las métricas del producto se centran en las
características del software y no en cómo fue
producido. Un producto no es solo el software o sistema
funcionando sino también los artefactos, documentos,
modelos, módulos, o componentes que lo conforman, por
tanto, las métricas del producto deben hacerse sobre la
base de medir cada uno de estos.
En los artefactos del producto se mide, entre otras
cosas, el tamaño, la calidad (teniendo en cuenta los
defectos, la complejidad, la primitividad, entre otros), la
totalidad, rastreabilidad, volatilidad, esfuerzo .
11. Métricas y
Calidad
El principal objetivo de los ingenieros del software es
producir un sistema, aplicación o producto de alta calidad,
para lo cual emplean métodos y herramientas efectivas dentro
del contexto de un proceso maduro de desarrollo del software y
además deben desarrollar mediciones que den como resultado
sistemas de alta calidad. Para obtener esta evaluación, el
ingeniero debe utilizar medidas técnicas, que evalúan
la calidad con objetividad, no con subjetividad.
En la norma ISO 9126 se proponen un grupo de métricas que
atribuyen a los factores de calidad descritos, alguna de las
cuales se incluyen en la propuesta.
A pesar del avance en el desarrollo de software y las
tecnologías, con el paso de los años los atributos que
proporcionan una indicación de la calidad del software
siguen siendo los mismos, en este sentido en inevitable mencionar
el trabajo desarrollado por McCall y Cavano en cuanto a la
definición de factores de calidad, pues a pesar del tiempo,
sus estudios han sido una guía para otros modelos y normas de calidad, La norma ISO
9126 es un ejemplo de ello, muchas características y
subcaracterísticas definidas en la misma hacen referencia a
la operación, transición y revisión del software y
aunque no las dividen en estos tres grupos, señalan entre otras
cosas la necesidad de lograr que el software opere correctamente
y con el grado de exactitud requerido, que los usuarios sean
capaces de entenderlo y usarlo, es decir que sea amigable con
quienes interactúen con él, que sea capaz de responder
correctamente ante fallos o cambios del entorno y que proporcione
una ejecución o desempeño apropiado, teniendo en cuenta
los recursos utilizados.
PROPUESTA DE
MÉTRICAS
Las métricas propuestas miden el desarrollo de los
proyectos y ayudan a los líderes y directivos de los mismos
en la toma decisiones y acciones correctivas, así como el
mejoramiento continuo de los procesos, obteniéndose mejores
resultados.
En el área de proceso captura de requisitos una
correcta gestión de requisitos contribuye en gran medida al
éxito de los proyectos de software, aportando el
entendimiento y la comprensión de los problemas que se
necesitan solucionar y cómo resolverlos, definiendo con
claridad, sin ambigüedades, en forma consistente y compacta
lo que se desea producir.
Las métricas propuestas fueron:
Entendimiento de los requisitos, referida a la
capacidad de entender el significado de los requisitos, o sea que
no exista ambigüedad, que cada requisito tenga una sola
interpretación.
Estabilidad de los requisitos, referida a los
cambios que sufren los requisitos a lo largo de todo el ciclo de vida del software
incluyendo la eliminación, inserción y
modificación, estos continuos cambios en la
especificación de los requisitos traen consigo un atraso en
el cronograma de trabajo.
La elaboración del plan de proyecto es otra de las
áreas en las que se propusieron métricas. El plan
constituye una guía para la realización y el control
del proyecto y sus actividades, en él se asignan las
responsabilidades, recursos y fechas de cumplimiento a las
tareas. El plan incluye estimación de los elementos de
trabajo y tareas, recursos necesarios, negociación de compromisos,
establecimiento de un calendario, e identificación y
análisis de los posibles riesgos que pueda tener el
proyecto.
Dentro de la planificación del proyecto se proponen
las siguientes métricas relacionadas con las tareas a
cumplir, los plazos destinados a las mismas, el tiempo, esfuerzo
y productividad.
Porciento de tareas completadas, con el objetivo
de llevar un registro de las mediciones de las
tareas que se desarrollan durante el proyecto, pues de esta
manera pueden realizarse mejores asignaciones de recursos y
tiempo, así como tener una medida del progreso del trabajo
realizado respecto al planificado teniendo en cuenta el
cumplimiento de las tareas.
Porciento de error de estimación de
Tamaño, teniendo registros de cuanto puede desviarse el
tamaño real del software respecto al planificado pueden
realizarse mejores estimaciones para futuros trabajos con
características similares, de manera que pueda minimizarse
lo más posible el porciento de error en la estimación
del tamaño. La estimación del tamaño es un punto
de partida para realizar cálculos y estimaciones de tiempo,
costo y esfuerzo.
Porciento de error de estimación de Tiempo,
de manera análoga a la métrica anterior también
puede analizarse el error de estimación del tiempo. Estos
registros ayudarán a hacer mejores estimaciones de tiempo
para trabajos futuros.
Productividad con el objetivo de calcular la
producción de código por unidad de tiempo y el esfuerzo
necesario para desarrollar un software. A medida que se avanza en
los ciclos de desarrollo del proyecto, la productividad se
incrementa.
Otra de las áreas es la gestión de riesgos, en la
que pueden identificarse tempranamente los posibles riesgos y
tomar medidas correctivas para mitigarlos a tiempo, estos deben
tenerse en cuenta para decidir si se continúa con el
proyecto.
Esta es una de las actividades que se inicia en la
primera etapa de un proyecto y se desarrolla a lo largo de todo
su ciclo de vida llegando finalmente hasta la aceptación del
producto obtenido.
Medición de la Identificación de los
Riesgos, es una medida para guardar los riesgos más
comunes en cada una de las etapas del desarrollo del software
así como las consecuencias que traen consigo cada uno de
ellos (el incremento de los costos, la cancelación del
proyecto, la insatisfacción del cliente, entre otras), de
manera tal que al cabo de cierto tiempo guardando estos registros
históricos al comenzar un nuevo proyecto se tengan
identificados los posibles riesgos y prevenirlos, valorando
además su repercusión en cuanto al alcance (cuánto
se afecta) y la duración (por cuánto tiempo se
manifiesta).
Probabilidad de que ocurran riesgos de un mismo
tipo, calculando la probabilidad de ocurrencia de
riesgos de un tipo determinado (personal, organizativos, de
herramientas, de requerimientos, de estimación, de presupuesto, entre otros), se
logrará organizarlos y según la prioridad mitigarlos
para contrarrestar los efectos que puedan ocasionar al
sistema.
Efectividad de la mitigación de riesgos, con
el objetivo de determinar la relación existente entre los
riesgos mitigados y el total de riesgos identificados. Guardando
estos datos puede conocerse cuán efectivos han sido los
planes de mitigación de riesgo, o sea ya se tendrá
un conocimiento de las soluciones que fueron
efectivas y por lo tanto pueden ser usadas nuevamente para
mitigar riesgos similares a los resueltos.
Finalmente la etapa de prueba que es tan o más
importante que todas las realizadas hasta el momento, en ella se
refleja la calidad con que ha sido llevada a cabo la
proyección del sistema. En esta etapa no se puede asegurar
la ausencia de defectos solo puede demostrarse la existencia de
los mismos. En todas las fases del desarrollo del proyecto hay
que probar el software que se va construyendo y resulta muy
importante definir un conjunto de mediciones para guardar los
resultados de las mismas de manera que aporten información
relevante para pruebas sucesivas.
Las métricas utilizadas durante la fase de pruebas,
junto con las técnicas de estimación adecuadas dan
soporte para predecir y controlar los defectos esperados, la
duración de las pruebas, los recursos dedicados, los
defectos remanentes, etcétera.
Rendimiento de la eliminación de defectos,
con el objetivo de conocer la relación entre los defectos
eliminados y todos los existentes en una etapa determinada del
proyecto de software. Es importante que todos los defectos sean
encontrados y eliminados en la etapa que se esté analizando
y se reduzcan los defectos evadidos.
Integridad de la implementación funcional,
es una medida de cuán completa ha sido la
implementación según la especificación de
requisitos, se detectan el número de funciones perdidas, aquellas que
fueron descritas en la especificación de requisitos y no
fueron implementadas. Con esta métrica se evalúa la
completitud de la implementación, si se tienen muchas
funcionalidades perdidas, no si se desarrolló una buena
implementación, lo cual implicará la toma de acciones
correctivas para controlar este proceso de manera tal que no se
vea afectada la calidad del producto final.
Cobertura de las pruebas, indica cómo se van
cumpliendo los casos de prueba especificados, por lo tanto
mientras mayor sea la cobertura, mayor número de casos de
prueba se estarán cumpliendo, de esta manera se llevará
un control del cumplimiento de los casos de prueba requeridos
para cubrir los requisitos lo que por supuesto da una medida de
cuan correctamente se está desarrollando el proceso de
prueba.
La Madurez de las pruebas es un indicador de
qué tan bien se esta desarrollando el proceso de pruebas, no
solo se preocupa de la completitud de los casos de prueba
según los definidos para cumplir los requisitos, sino que
también se interesa por cuales han obtenido resultados
satisfactorios, para ello es necesario llevar un control de los
casos de prueba que arrojaron resultados satisfactorios y el
total de los casos de prueba definidos para el cumplimiento de
los requisitos.
El Porcentaje de defectos por tipo, se calcula
con el objetivo es identificar los tipos de defectos más
comunes que puedan presentarse en cualquiera de las etapas del
proceso de desarrollo del software, es aplicable de manera
individual para cada desarrollador o por equipo de trabajo. Este
porcentaje sería de los tipos de defectos que se encontraron
tanto en las revisiones, como luego en las compilaciones y en las
pruebas.
Porciento del tiempo total dedicado a las
pruebas, es una medida del porciento del tiempo dedicado a
las pruebas respecto al tiempo total del proyecto. El tiempo de
la prueba será mayor mientras más defectos se hayan
introducido en el software. Este tiempo dedicado a las pruebas
dependerá en gran medida del tamaño y complejidad del
software que se esté desarrollando, los proyectos similares
al analizado tendrán una referencia para estimar el tiempo
que deben emplear a las pruebas.
CONCLUSIONES
El creciente desarrollo de la Industria de Software ha
traído consigo la necesidad de producir software de Calidad,
y para lograrlo se tienen en cuenta numerosos factores entre los
que se encuentran las métricas de software, una herramienta
indiscutible para ayudar a mantener el control de los procesos y
productos durante el desarrollo del software.
El desarrollo de este trabajo ha permitido llegar a las
siguientes conclusiones, de manera que se evidencia el
cumplimiento a los objetivos propuestos:
- La Calidad es un factor determinante para lograr el
éxito en la Industria de Software. - Las métricas de software contribuyen al control,
seguimiento y mejora de la calidad del proceso de desarrollo de
software. - Se realizó una propuesta de métricas para
comenzar a aplicarlas en los proyectos de Realidad
Virtual.
REFERENCIAS
BIBLIOGRÁFICAS
Sinopsis de los modelos CMM y CMMI. Historia y Evolución. 2006 [cited;
Available from:
.
Solo Requisitos 2006. Jornadas Prácticas sobre la
gestión e ingeniería de requisitos del software y el
modelo de mejora CMMI. Los
requisitos en la Software Factory. 2006 [cited; Available
from:
http://www.calidaddelsoftware.com/documentos/II%20Semana%20CMMI/brochure.pdf
Bertoa, M.F. Aspectos de Calidad en el Desarrollo de
Software Basado en Componentes. 2002 [cited; Available
from:
http://congresos.lcc.uma.es/~av/Publicaciones/02/CalidadDSBC.pdf.
Nodarse, D.F.A.F. Experiencias en la concepción de
una metodología para el desarrollo y control decalidad de
productos y servicios informáticos orientada a la Educación a distancia y
el ComercioElectrónico en Internet. 2002 [cited; Available
from:
http://espejos.unesco.org.uy/simplac2002/Ponencias/ambientes%20digitales/AD057.doc.
Arregui, J.J.O. Revisión Sistemática de
Métricas de Diseño Orientado a Objetos. 2005 [cited;
Available from:
http://is.ls.fi.upm.es/doctorado/Trabajos20042005/Olmedilla.pdf.
Lovelle, J.M.C. Calidad del Software. 1999 [cited;
Available from:
http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF.
Diez, E. Generación Asistida del Mapa de
Actividades de Proyectos de Desarrollo de Software. 2003 [cited;
Available from:
http://www.itba.edu.ar/capis/rtis/rtis-5-1/generacionmapaactividades.pdf.
Gracia, J. CMM – CMMI Nivel 2. 2005 [cited; Available
from:
http://www.ingenierosoftware.com/calidad/cmm-cmmi-nivel-2.php.
Requisitos del software: organización y calidad.
2006 [cited; Available from:
http://www.ie.inf.uc3m.es/grupo/docencia/reglada/psi/unidad8-DOC.pdf
Mendoza, G.M. Métricas Internas de la Calidad del
producto de Software. 2006 [cited; Available from:
http://mena.com.mx/gonzalo/maestria/calidad/presenta/iso_9126-3/.
Anaya, V. Trazabilidad de Requisitos Adaptada a las
Necesidades del Proyecto: Un Caso de Estudio Usando
Alternativamente RUP y XP. 2001 [cited; Available from:
http://issi.dsic.upv.es/publications/archives/f-1055508123529/Ideas2003.pdf
Palacio, J. Compendio de Ingeniería del Software.
2006 [cited; Available from:
http://www.navegapolis.net/files/cis/CIS%20Glosario%20004.pdf.
Ávila, L.G. Procedimiento para el desarrollo
del proceso de ingeniería de requisitos en un proyecto
software (PROCIR). 2007 [cited; Available from:
Casañola, Y.T. Propuesta de Modelo de
Producción de Software para la Universidad de las Ciencias
Informáticas. 2006 [cited; Available from:
http://www.informaticahabana.com/evento_virtual/files/CAL049.doc.
Chalini, L., Métricas y estándares de
comparación in Tesis Maestría. Ciencias
con Especialidad en Ingeniería en Sistemas Computacionales.
2004, Universidad de las Américas Puebla.
Esteves, J. Implementación y Mejora del Método de Gestión
Riesgos del SEI en un proyecto universitario de desarrollo de
software. 2001 [cited; Available from:
http://www.ewh.ieee.org/reg/9/etrans/Marzo2005/paper119.pdf.
Delgado, N.C.C. Informe -Técnico previo de
Evaluación del software de Gestión de riesgos No
009-GT1000. 2007[cited; Available from:
http://www.bcrp.gob.pe/bcr/dmdocuments/Licitacion/IT_20060009.pdf.
Vigil, A.C. CMM Y la Gerencia de Procesos. 2003
[cited; Available from:
http://www.acis.org.co/memorias/JornadasGerencia/IJNGP/Presentacion%20CMM%20y%20PMI.pdf.
Autoras:
Ing. Ludisley la Torre Hernández
Departamento: Ingeniería de software y
Práctica profesional
Institución: Universidad de las Ciencias Informáticas –
Facultad 5
País: Cuba
Ing. Mariela Cepero Nuñez
Departamento:
Ingeniería de software y Práctica profesional
Institución: Universidad de las Ciencias Informáticas –
Facultad 5
País: Cuba
Universidad de las Ciencias
Informáticas
 Página anterior | Volver al principio del trabajo | Página siguiente  |