Una breve explicación de lo que se refiere a métricas con opm

1. Ingeniería de Software
Integrantes: Jefferson Palacios
Xiomara Paladines

2.  Uno de los problemas al que se han enfrentado los
trabajadores de las métricas durante las dos últimas
décadas es la de desarrollar métricas que fueran
útiles para el diseñador de software.
 Se habían empleado criterios basados en la facilidad
de la medida mas que emplear cualquier criterio
relacionados con la utilidad
El Desarrollo de la Métrica y la
OPM(Objetivo, Pregunta, Métri
ca)

3. Desarrollo de la Métrica y la OPM
 El panorama de la Última mitad de los años 80 y la primera
mitad de la década de los 90,constató el hecho de que
mientras había sido desarrollado mucho trabajo en la
validación dela métrica y en el esclarecimiento de los
principios teóricos detrás de ella, muy poco había sido hecho
para dotar al diseñador de software con herramientas para la
selección o construcción de métricas.

4. Objetivo
 Es describir OPM, que es el método de desarrollo de métrica
más aplicado y mejor conocido, desarrollado por Víctor Basili
y sus colaboradores de la Universidad de Maryland.
 Este método surgió de un trabajo que fue desarrollado
dentro de un laboratorio de ingeniería del software
esponsorizado por la Agencia Americana del Espacio, NASA.

5. Componentes
 Basili establecía que para que una organización 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 términos de software
3. Un proceso que interpretara los datos del proyecto con el
fin de entender los objetivos

6. Importancia
 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 también 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 métricas realistas sobre sus
proyectos. Los objetivos de OPM pueden
articularse por medio de tres plantillas que
cubren el propósito, la perspectiva y el
entorno.

7. Hay varios enfoques que pueden hacerse
sobre le proceso de desarrollo de
software- el del cliente y el del diseñador
Plantillas son los mas típicos y la elección de una u
otra perspectiva tiene un efecto muy
grande sobre los análisis que se llevan a
cabo
Una tercera plantilla
La plantilla o Una segunda implica el entorno.
esquema plantilla está Este es el contexto
de cálculo relacionada con la dentro del cual el
denominada de perspectiva. Esta método OPM se
propósito se utiliza plantilla pone aplica e implica el
para articular o su atención en los examen del
comparar lo que factores que son personal, la propia
está siendo importantes dentro empresa y los
analizado y el del propio proceso o entornos de recursos
propósito de dicha producto que está en los que el análisis
parte del proyecto. siendo evaluado. se está llevando a
cabo.

8. Variación de la Gestión: Control de
Procesos Estadísticos
 El nivel de habilidad de los
 Debido a que el realizadores de dichos procesos.
proceso de software y
 La estructura del equipo de
el producto que tal software.
proceso produce  El conocimiento del cliente.
son ambos
 La tecnología que va a
influenciados ser implementada.
por muchos
 Las herramientas que serán
parámetros como: usadas en la actividad de
desarrollo

9. La métrica elegida para un
proyecto o producto no será
la misma que otras métricas
similares seleccionadas
para otro proyecto.
Se dispone de una técnica
gráfica para determinar si los
cambios y la variación en los
datos de la métrica son
significativos. Esta técnica
llamada gráfico
de control permite que las
personas interesadas en la
mejora de procesos de
software determinen si la
dispersión y la localización
o métrica de procesos es
estable o inestable
Para Recordar

10. Grafico

11. Métricas para Organizaciones
Pequeñas
La amplia mayoría de las organizaciones
de desarrollo de software tienen menos de
20 personas dedicadas al software. Es
poco razonable, y en la mayoría de
los casos no es realista, esperar que
organizaciones como éstas desarrollen
programas métricos de software extensos.

12. Métricas para Organizaciones
pequeñas
 Sin embargo, si es razonable sugerir que organizaciones
de software de todos los tamaños midan y después utilicen
las métricas resultantes para ayudar a mejorar sus procesos
de software local y la calidad y
oportunidad de los productos que realizan
 Kautz describe un escenario típico que ocurre cuando se
piensa en programas métricos para organizaciones
pequeñas de software.

13. Escenario de Kurts
 Originalmente, los desarrolladores de software acogían
nuestras actividades con un alto grado de escepticismo, pero
al final las aceptaban debido a que nosotros conseguíamos
que nuestras medidas fueran simples de realizar, adaptadas
a cada organización y se aseguraba que dichas medidas
producían una información válida y útil.
 Es una línea de acción que funciona razonablemente bien en
muchas actividades

14. Medidas fácilmente recolectadles
para pequeñas Organizaciones
 Tiempo(horas o días) que transcurren desde el momento que es
realizada un petición hasta que se complete su evaluación.
 Esfuerzo(horas-persona) para desarrollar la evaluación
 Tiempo(horas o días) transcurridos desde la terminación de la
evaluación a la asignación de una orden de cambio al personal
 Esfuerzo(horas-persona) requeridas para realizar el cambio.
 Tiempo requerido(horas o días) para realizar el cambio.
 Errores descubiertos después de que el cambio se haya desviado a
la base del cliente
.

15. Establecimiento de un programa
de métricas de software
 El instituto de Ingeniería del Software (IIS) ha desarrollado una
guía extensa para establecer un programa de medición de
software dirigido hacia objetivos
 La guía sugiere los siguientes pasos para trabajar:
Identificar los objetivos del negocio
Identificar lo que se desea saber o aprender
Identificar los sub –objetivos
Identificar las entidades y atributos relativos a esos sub-
objetivos
Formalizar los objetivos de la medición

16. Guía de Pasos a seguir
Identificar preguntas que puedan cuantificarse y los
indicadores relacionados que se van a usar para ayudar a
conseguir los objetivos de medición.
Identificar los elementos de datos que se van a recoger para
construir los indicadores que ayuden a responder a las
preguntas planteadas.
Definir las medidas a usar y hacer que estas definiciones
sean operativas.
Identificar las acciones que serán tomadas para mejorar las
medidas indicadas
Preparar un plan para implementar estas medidas

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

18. Gracias Gente…!!! =P