El Desarrollo de la Mtrica y la OPM (Objetivo, Pregunta, Mtrica) Uno de los problemas al que se han enfrentado los trabajadores de las mtricas durante las dos ltimas dcadas es la de desarrollar mtricas que fueran tiles para el diseador de software. Se haban empleado criterios basados en la facilidad de la medida mas que emplear cualquier criterio relacionados con la utilidad.

El panorama de la ltima mitad de los aos 80 y la primera mitad de la dcada de los 90, constat el hecho de que mientras haba sido desarrollado mucho trabajo en la validacin de la mtrica y en el esclarecimiento de los principios tericos detrs de ella, muy poco haba sido hecho para dotar al diseador de software con herramientas para la seleccin o construccin de mtricas.

El objetivo de esta seccin es describir OPM, que es el mtodo de desarrollo de mtrica ms aplicado y mejor conocido, desarrollado por Victor Basili y sus colaboradores de la Universidad de Maryland. Este mtodo surgi de un trabajo que fue desarrollado dentro de un laboratorio de ingeniera del software esponsorizado por la Agencia Americana del Espacio, NASA.

Basili estableca que para que una organizacin tuviera un programa de medida exacto era necesario que tuviera constancia de tres componentes: 1. Un proceso donde pudieran articularse metas u objetivos para sus proyectos. 2. Un proceso donde estas metas pudieran ser traducidas a los datos del proyecto que exactamente reflejasen dichas metas u objetivos en trminos de software. 3. Un proceso que interpretara los datos del proyecto con el fin de entender los objetivos.

La importancia de OPM proviene no solamente del hecho de que es uno de los primeros intentos de desarrollar un conjunto de medidas adecuado que pueda ser aplicado al software, sino tambin al hecho de que est relacionado con el paradigma de mejora de procesos que ha sido discutido previamente. Basili ha proporcionado una serie de plantillas que son tiles para los desarrolladores que deseen utilizar OPM para desplegar mtricas realistas sobre sus proyectos. Los objetivos de OPM pueden articularse por medio de tres plantillas que cubren el propsito, la perspectiva y el entorno.

La plantilla o esquema de clculo denominada de propsito se utiliza para articular o comparar lo que est siendo analizado y el propsito de dicha parte del proyecto. Una segunda plantilla est relacionada con la perspectiva. Esta plantilla pone su atencin en los factores que son importantes dentro del propio proceso o producto que est siendo evaluado.

Hay varios enfoques que pueden hacerse sobre el proceso de desarrollo de software - el del cliente y el del diseador son los dos ms tpicos y la eleccin de una u otra perspectiva tiene un efecto muy grande sobre los anlisis que se llevan a cabo. Una tercera plantilla implica el entorno. Este es el contexto dentro del cual el mtodo OPM se aplica e implica el examen del personal, la propia empresa y los entornos de recursos en los que el anlisis se est llevando a cabo.

Una vez que tanto el propsito como la perspectiva y el entorno de un objetivo han sido bien especificados, el proceso de planteamiento de cuestiones y el desarrollo de una mtrica o valoracin puede comenzar. Veamos un ejemplo de aplicacin de estos tres puntos:

Deseamos examinar el efecto de utilizar un constructor de interfaces grficas, sobre la mejora de las interfaces hombre-mquina, que producimos para nuestros sistemas de administracin. En particular, deseamos examinar cmo puede esto afectar a la facilidad de manejo de estas interfaces por arte del usuario. Un foco de atencin principal es cmo percibirn los usuarios de estos sistemas que dichas interfaces han cambiado.

Aqu, el propsito es analizar una herramientacon el objetivo de determinar una mejora con respecto a la facilidad de uso, bajo el punto de vista del usuario dentro del contexto de los sistemas administrativos.

Variacin de la Gestin: Control de Procesos Estadsticos Debido a que el proceso de software y el producto que tal proceso produce son ambos influenciados por muchos parmetros como: El nivel de habilidad de los realizadores de dichos procesos. La estructura del equipo de software. El conocimiento del cliente. La tecnologa que va a ser implementada. Las herramientas que sern usadas en la actividad de desarrollo.

La mtrica elegida para un proyecto o producto no ser la misma que otras mtricas similares seleccionadas para otro proyecto. Se dispone de una tcnica grfica para determinar si los cambios y la variacin en los datos de la mtrica son significativos. Esta tcnica llamada grfico de control permite que las personas interesadas en la mejora de procesos de software determinen si la dispersin y la localizacin o mtrica de procesos es estable o inestable.

Mtricas para organizaciones pequeas La amplia mayora de las organizaciones de desarrollo de software tienen menos de 20 personas dedicadas al software. Es poco razonable, y en la mayora de los casos no es realista, esperar que organizaciones como stas desarrollen programas mtricos de software extensos.

Sin embargo, si es razonable sugerir que organizaciones de software de todos los tamaos midan y despus utilicen las mtricas resultantes para ayudar a mejorar sus procesos de software local y la calidad y oportunidad de los productos que realizan. Kautz describe un escenario tpico que ocurre cuando se piensa en programas mtricos para organizaciones pequeas de software:

Originalmente, los desarrolladores de software acogan nuestras actividades con un alto grado de escepticismo, pero al final las aceptaban debido a que nosotros conseguamos que nuestras medidas fueran simples de realizar, adaptadas a cada organizacin y se aseguraba que dichas medidas producan una informacin vlida y til. Es una lnea de accin que funciona razonablemente bien en muchas actividades.

Una organizacin pequea puede seleccionar el siguiente conjunto de medidas fcilmente recolectables: Tiempo (horas o das) que transcurren desde el momento que es realizada una peticin hasta que se complete su evaluacin. Esfuerzo (horas-persona) para desarrollar la evaluacin. Tiempo (horas o das) transcurridos desde la terminacin de la evaluacin a la asignacin de una orden de cambio al personal. Esfuerzo (horas-persona) requeridas para realizar el cambio.

Tiempo requerido (horas o das) para realizar el cambio. Errores descubiertos durante el trabajo para realizar el cambio. Defectos descubiertos despus de que el cambio se haya desviado a la base del cliente.

Establecimiento de un programa de mtricas de software El Instituto de Ingeniera del Software (IIS) ha desarrollado una gua extensa para establecer un programa de medicin de software dirigido hacia objetivos.

La gua sugiere los siguientes pasos para trabajar:1. Identificar los objetivos del negocio. 2. Identificar lo que se desea saber o aprender. 3. Identificar los sub-objetivos.

4. Identificar las entidades y atributos relativos a esossub-objetivos. 5. Formalizar los objetivos de la medicin. 6. Identificar preguntas que puedan cuantificarse y los indicadores relacionados que se van a usar para ayudar a conseguir los objetivos de medicin. 7. Identificar los elementos de datos que se van a recoger para construir los indicadores que ayuden a responder a las preguntas planteadas. 8. Definir las medidas a usar y hacer que estas definiciones sean operativas. 9. Identificar las acciones que sern tomadas para mejorar las medidas indicadas. 10. Preparar un plan para implementar estas medidas.

Los pasos anteriores son resumidos, cuando hay mucho que hablar, sin embargo podemos repasar brevemente los puntos clave. Ya que el software, en primer lugar, soporta las funciones del negocio, en segundo lugar, diferencia o clasifica los sistemas o productos basados en computadora, y en tercer lugar puede actuar como un producto en s mismo, los objetivos definidos para el propio negocio pueden casi siempre ser seguidos de arriba abajo hasta los objetivos ms especficos a nivel de ingeniera de software.

Por ejemplo, considrese una compaa que fbrica sistemas avanzados para la seguridad del hogar que tienen un contenido de software sustancial. Trabajando como un equipo, los ingenieros de software y los gestores del negocio, pueden desarrollar una lista de objetivos del propio negocio convenientemente priorizados:

Mejorar la satisfaccin de nuestro cliente con nuestros productos. Hacer que nuestros productos sean ms fciles de usar. Reducir el tiempo que nos lleva sacar un nuevo producto al mercado. Hacer que el soporte que se d a nuestros productos sea ms fcil. Mejorar nuestro beneficio global.

La organizacin de software examina cada objetivo de negocios y se pregunta: Qu actividades gestionaremos (ejecutaremos) y qu queremos mejorar con estas actividades? Para responder a estas preguntas el IIS recomienda la creacin de una lista de preguntas-entidad, en la que todas las cosas (entidades) dentro del proceso de software que sean gestionadas o estn influenciadas por la organizacin de software sean anotadas convenientemente.

Ejemplo de tales entidades incluye: recursos de desarrollo, productos de trabajo, cdigo fuente, casos de prueba, peticiones de cambio, tareas de ingeniera de software y planificaciones. Para cada entidad listada, el personal dedicado al software desarrolla una serie de preguntas que evalan las caractersticas cuantitativas de la entidad (por ejemplo: tamao, coste, tiempo para desarrollarlo).

Las cuestiones derivadas como una consecuencia de la creacin de una lista tal de preguntas-entidad, conducen a la derivacin de un conjunto de objetivos de segundo nivel (sub-objetivos) que se relacionan directamente con las entidades creadas y las actividades desarrolladas como una parte del proceso del software.