Propuesta de métrica de perfeccionamiento de gestión de la calidad en el proceso de desarrollo de Sofware (página 2)
Enviado por Ludisley La Torre Hern�ndez
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-2000
Se 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 software
Todas 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étricas
5. 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étricas
Existen 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 base
8. 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ñezDepartamento: 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 siguiente |