METRICAS PARA LA EVALUACIN DEL ANLISIs 4.1.

METRICAS DEL MODELO DE ANALISIS Empezaremos por definir los posibles trminos que se encuentranencerrados en la palabra mtrica, porque es muy comn asociarla con laspalabras medicin y medida, aunque estas tres son distintas. La medicin es elproceso por el cual los nmeros o smbolos son asignados a atributos o entidadesen el mundo real tal como son descritos de acuerdo a reglas claramente definidas [Fenton 91]. Una medida proporciona una indicacin cuantitativa deextensin, cantidad, dimensiones, capacidad y tamao de algunos atributos de unproceso o producto [Pressman98]. El IEEE Standard Glosary of Software Engering Terms define como mtrica como una medida cuantitativa del grado enque un sistema, componente o proceso posee un atributo dado [Len O. Ejiogo91]. Qu son las mtricas de software? Michael [99] define las mtricas de software como La aplicacin continua de mediciones basadas en tcnicas para el proceso de desarrollo del software y sus productos para suministrar informacin relevante a tiempo, as el administrador junto con el empleo de ests tcnicas mejorar el proceso y sus productos. Las mtricas de software proveen la informacin necesaria para la toma de decisiones tcnicas. En la figura 2.1 se ilustra una extensin de esta definicin para incluir los servicios relacionados al software como la respuesta a los resultados del cliente:

En esta fase es deseable que las mtricas tcnicas proporcionen una visin interna a la calidad del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el "tamao" del sistema resultante; es probable que el tamao y la complejidad del diseo estn directamente relacionadas.

4.1.1 METRICAS BASADAS EN LA FUNCIN Se relacionan con la funcionalidad total del software entregado. La productividad se expresa en trminos de la cantidad de funcionalidad til producida en un tiempo dado. Ejemplos de estas medidas son puntos de funcin y puntos de objetos. Punto Funcin y La mtrica del punto de funcin (PF) se puede utilizar como medio para predecir el tamao de un sistema obtenido a partir de un modelo de anlisis. Para visualizar esta mtrica se utiliza un diagrama de flujo de datos, el cual se evala para determinar las siguientes medidas clave que son necesarias para el clculo de la mtrica de punto defuncin: Nmero de entradas del usuario Nmero de salidas del usuario Nmero de consultas del usuario Nmero de archivos Nmero de interfaces externas La Mtrica Bang. Puede aplicarse para desarrollar una indicacin del tamao del software a Implementar como consecuencia del modelo del anlisis. 4.1.2 METRICAS DE LA CALIDAD DE LA ESPECIFICACION Mtricas de la calidad de la especificacin: y En estas mtricas se emplea una lista de caractersticas que pueden emplearse para valorar la calidad del modelo de anlisis y la correspondiente especificacin de requisitos Estas mtricas poseen un modelo de valoracin entre cero (0) y cinco (5), y por decisin del equipo de trabajo, se puede asumir una valoracin en porcentajes como se muestra en la tabla siguiente as: 0 1 2 3 4 5 No influencia Ninguna 0% Incidental Insignificante 1 - 20% Moderado Moderada 21 - 40% Medio Media 41 60% Significativo Significativa 61 80% Esencial Fuerte 81 100% 0 10% 11 20% 21 30% 31 40% 41 50% > 50%

4.2.1 REVISIONES TECNICAS FORMALES Una revisin tcnica formal (RTF) es una actividad de garanta de calidad de los sistemas de informacin. Los objetivos de la RTF son : 1. Describir errores en la funcin, la lgica o la implementacin de cualquier representacin de los sistemas de informacin. 2. Verificar que los sistemas bajo revisin alcancen sus requisitos. 3. Garantizar que los sistemas han sido representados de acuerdo con ciertos estndares predefinidos. 4. Conseguir un sistema desarrollado en forma uniforme. 5. Hacer que los proyectos sean ms manejables. Tambin sirve como campo de entrenamiento para que el personal ms joven puedan observar los diferentes enfoques al anlisis, diseo e implementacin de los sistemas. EL RTF Sirve para promover la seguridad y continuidad, ya que varias personas se familiarizarn con partes del sistema de informacin, que de otro modo, no hubieran visto. Es una clase de revisin que incluye recorridos, inspecciones, torneo de revisiones y otras tareas de revisin tcnica de los sistemas. Cada RTF se lleva a cabo mediante una reunin y slo tendr xito si es bien planificada, controlada y atendida. 4.2.1 LA REUNION DE REVISION 1. Reunin de revisin: Idealmente deben ser entre 3 y 5 personas. Deben ir preparados. No se deben invertir ms de dos horas. La reunin de revisin Independientemente del formato que se elija para la RTF, cualquier reunin de revisin debe apegarse a las siguientes restricciones:
y y y

Deben convocarse a la revisin entre tres y cinco personas. Se debe preparar por adelantado, pero sin que requiera ms de dos horas de trabajo a cada personas. La duracin de la reunin de revisin debe ser menor de dos horas.

4.2.2 REGISTRO E INFORME DE LA REVISIN Registro e informes de la revisin: Qu fue revisado? Quin lo revisar? Qu se descubri y cules fueron las conclusiones?

4.2.3 DIRECTRICES PARA LA REVISION Estas son algunas de las directrices para las RTF : 1. Revisar el producto no el productor.- Una RTF involucra gente y egos, debe de llevar a los integrantes a un sentimiento agradable de estar cumpliendo con su deber. Se deben sealar los errores correctamente; el tono de la reunin debe ser distendido y constructivo; no debe intentarse dificultar o batallar. El jefe de revisin debe moderar la reunin para garantizar que se mantiene un tono y una actitud adecuados. 2. Fijar una agenda y mantenerla.- No realizar la reunin a la deriva. La RTF debe seguir un plan de trabajo concreto. El jefe debe mantener el plan de la reunin y cortar a la gente cuando empiece a divagar. 3. Limitar el debate y las impugnaciones. Cuando un supervisor proporcione una pega, puede no ser unnime, en lugar de discutirla registrar el hecho y la discusin se lleve a cabo en otro momento. 4. Enunciar reas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto. Una reunin no es una sesin de resolucin de problemas, se debe dejar eso al productor por si solo o con la ayuda de otra persona. 5. Tomar notas escritas. Es conveniente que el registrador anote en una pizarra, de forma que las declaraciones puedan ser comprobadas por los dems revisores. 6. Limitar el nmero de participantes e insistir en la preparacin anticipada. No es conveniente un nmero grande de revisores, ya que puede no haber la debida comunicacin y adems deben de prepararse por anticipado (el jefe de la revisin debe pedir comentarios escritos para saber si realmente se revis el material). 7. Llevar a cabo un entrenamiento adecuado de los revisores. Todos los participantes deben tener un entrenamiento formal, principalmente en aspectos relacionados con el proceso, as como las consideraciones psicolgicas humanas que ataen a la revisin. 8. Repasar las revisiones anteriores. Las revisiones de informacin pueden ser beneficiosas para descubrir problemas en el propio proceso de revisin. El primer producto que se haya revisado puede establecer las directivas de revisin. METRICAS DE LA CALIDAD DEL SOFTWARE Es difcil obtener medidas precisas acerca de la calidad del software. A continuacin se tratar un conjunto de mtricas del software que se pueden aplicar para garantizar cuantitativamente la calidad del software. En todos los casos estas mtricas representan medidas indirectas, es decir, nunca se mide realmente la calidad del software, sino algunas de sus manifestaciones. Indices de calidad de los sistemas de informacin.