Ultimo resumen

TECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC LICENCIATURA EN INFORMÁTICA

MATERIA: MODELADO DE NEGOCIOS

PROFESOR(A): M.I.S.C. ELIZABETH PULIDO ROMERO

ALUMNO(A): VARGAS HERNANDEZ WITNE NAYELI

1.1. Teoría de la Medición del Software Uno de los campos más influyente en los orígenes de la disciplina de la medición del software ha sido la teoría de la medición. La medición es una actividad que aplicamos continuamente en nuestra vida cotidiana y nos permite obtener información que nos guía en la loma de decisiones, seleccionar entre distintas alternativas la que más ventajosa nos resulta-o desechar una opción por no adaptar.

Fenton y Pfleegcr (1997) definen la medición como: "el proceso de asignar números o símbolos a los atributos de las entidades del mundo real de forma que se puedan describir de acuerdo a unas regios claramente definidas".

De acuerdo a la anterior definición, una entidad puede ser un objeto físico, un evento que ocurre en un determinado momento de tiempo o una actividad que transcurre en un determinado intervalo de tiempo, como por ejemplo: un programa, un hito y la fase de pruebas de un proyecto software, respectivamente. Un atributo es una característica de una entidad, como por ejemplo el tamaño del código de un determinado programa o el esfuerzo requerido para llevar a cabo una determinada actividad.

De acuerdo a la anterior definición, un evento que ocurre en un determinado momento de tiempo o una actividad que transcurre en un determinado intervalo de tiempo, como por ejemplo: un programa, un hito y la fase de pinchas de un proyecto software, respectivamente. Un atributo es una característica de una entidad, como por ejemplo el (Tamaño del código de un determinado programa o el esfuerzo requerido para llevar a cabo una determinada actividad.

Por lo tanto, en el campo de la medición es necesario especificar tanto las entidades como los atributos que se evalúan de dichas entidades. Algunos aspectos relevantes a considerar en el contexto de la teoría de la medición aplicada a la medición del software son los siguientes (Fenion y Pfleegcr, 1997):  Escala. Las escalas permiten establecer el tipo de representación más adecuado para un atributo de forma (pie se puedan comparar los valores de los mismos. Considerando que diferentes escalas pueden medir el mismo atributo, una cuestión importante a plantear es qué escala es más apropiada en cada caso. Para ello, en la teoría de la medición aplicada al software destacan cinco tipos principales de escalas:  Escala Nominal. Es la escala más básica, que sitúa a las entidades en diferentes clases o categorías asignando al atributo un nombre. Este modo las clases se identifican únicamente mediante un número o símbolo que no puede ser interpretado salvo como un mero identificador. Por ejemplo, distinguir de forma nominal a los jugadores de un equipo de baloncesto por su dorsal. El jugador "3(f~ no puede interpretarse como dos veces superior al jugador "15".  Escala Ordinal. Con esta escala, los atributos pueden ser ordenados en rangos pero la distancia ente los mismos no es significativa. Por ejemplo,

las respuestas a una encuesta podrían ser: "Q=totalmente en desacuerdo", "I = ni de acuerdo ni en desacuerdo", "2 = de acuerdo".

 Escala de Intervalo. Este tipo de escala es como la ordinal pero con la diferencia de que la distancia entre los atributos sí tiene sentido. Por ejemplo, si se mide la temperatura en grados centígrados. La distancia entre 30 y 40 es la misma que entre 60 y 70. Sin embargo, en esta escala las comparaciones de tipo ratio no tienen sentido, como por ejemplo: 80 °C no es el doble de calor que 40 °C (aunque el valor sí es el doble).  Escala de Rallo, que es la más útil en la medición del software, ya que preserva el orden, el tamaño de los intervalos y también los ratios entre las entidades. Además, tiene un punto fijo de referencia: el cero. La escala debe comenzar en el 0 y se incrementa en pasos iguales. Además, con los valores de esta escala se pueden realizar las operaciones matemáticas de suma, resta, multiplicación y división, El peso es, por ejemplo, una variable de tipo ratio.  Escala absoluta, que es utilizada únicamente cuando sólo hay una forma posible de medir un atributo. En general, los atributos evaluados mediante un método basado en contar el número de elementos son de este tipo de escala, como por ejemplo el número de defectos encontrados o el número de personas en un proyecto.

Clasificación de Entidades, En medición del software se puede distinguir entre tres tipos de entidades:

   

Proceso, en el que se incluyen las mediciones relacionadas a las actividades del software.

Producto, que incluye los entregables y documentos resultantes de las actividades de los procesos.

Recursos, que incluye los recursos necesarios para el desarrollo de los proyectos software tales como personal, software, hardware, etc., Atributo internos y externos. Los atributos internos son aquellos que pueden ser medidos de una entidad sin necesidad de evaluar el comportamiento externo de dicha entidad. Ejemplos de atributos internos son: tamaño y complejidad de código fuente, que pueden ser evaluados sin necesidad de ejecutar el código. Los atributos externos son mediciones sobre cómo una entidad está relacionada con el entorno, como por ejemplo los atributos calidad y estabilidad de requisitos, en cuyo caso es necesario ejecutar el código para obtenerlos. Estos atributos son mucho más difíciles de evaluar que los atributos



Internos y la necesidad de disponer de mediciones de atributos internos para obtener el valor de atributos externos es bastante clara. Por ejemplo, para evaluar el atributo externo calidad del software es necesario conocer atributos internos como por ejemplo el número de fallos obtenidos en la actividad de pruebas.



Mediciones directas e indirectas. Otro de los aspectos a destacar de la teoría de la medición es la distinción que establece entre mediciones directas c indirectas. Una medición directa es la medición de un atributo de una entidad sin estar otras entidades implicadas. Por ejemplo, el atributo tamaño de la entidad código fuente puede ser medido sin necesidad de evaluar ningún atributo de otras entidades. Las mediciones indirectas requieren de otros atributos, como por ejemplo la medición del atributo productividad, que requiere las mediciones tanto del tamaño como del esfuerzo y es obtenido media ante la división de ambos.

1.1. Terminología de la Medición de Software Dado que la medición de software es una disciplina relativamente joven, no existe aún un consenso general sobre la definición exacta de los conceptos y tecnología que maneja. A pesar de contar con diversos estándares internacionales que tratan de normalizar estos temas (IEEE, 1998b; ISü, 1993; 1999; 2002a), se han detectado ciertas lagunas e inconsistencias en los términos que dichos estándares definen, como son por ejemplo los conceptos de medida, métrica, medición, indicador, etc.

La situación no es mucho mejor en los contextos académicos c industriales, donde las distintas propuestas de modelos de medición de software tampoco han logrado consensuar una terminología coherente y ampliamente aceptada entre toda la comunidad científica (García, 2005).

Con el fin de contribuir a la armonización de los diferentes estándares y propuestas de investigación y de establecer una tecnología consistente (en el sentido de consenso y libre de contradicciones) se ha desarrollado una ontología de la medición del software (García et al., 2005).

En la figura 9.1 se muestra de forma gráfica mediante un diagrama en UML los conceptos de la ontología y sus relaciones.

El objetivo de esta ontología es establecer una guía de referencia que incluya los conceptos relacionados con la medición del software. Para facilitar su comprensión, la ontología de la medición del software se divide en las siguientes sub-onto!ogins:

Acción de Medir, en la que se identifican los conceptos relacionados con la forma en la que se lleva a cabo la medición software.

 Métricas, en la que se especifica la definición y características básicas de las métricas software. Una métrica se define como una forma de medir (método de medición, función de cálculo o modelo de análisis) y una escala, definidas para realizar mediciones de uno o varios atributos. Las métricas pueden ser de tres tipos en función de su forma de medir:  Métricas Directas cuya forma de medir es un método de medición, es decir, se pueden realizar mediciones de dicha métrica sin depender de ninguna otra.  Métricas Indirectas, cuya forma de medir es una función de cálculo, es decir, las mediciones de dicha métrica utilizan las medidas obtenidas en mediciones de otras métricas directas o indirectas.  Indicadores, cuya forma de medir es un modelo de análisis, es decir, las mediciones de dicha métrica utilizan las medidas obtenidas en las mediciones de otras métricas (directas, indirectas o indicadores) junio con criterios de decisión.  Formas de Medir, en la que se describen las distintas formas de medir métricas software.

En la elaboración y división de la ontología de la medición del Software en subontologías, se han identificado y establecido los conceptos y aspectos más relevantes relacionados con la medición del software y las etapas fundamentales componen dicho proceso.

Todo proceso de medición del software tiene como objetivo fundamental satisfacer necesidades de información. Un proceso de medición no puede obtener resultados útiles si estos no satisfacen alguna necesidad de información detectada en la empresa en la que se lleva a cabo. A partir de las necesidades de información se deben identificar las entidades y los atributos de dichas entidades que son candidatos a ser medidos. Esta parte significativa del proceso de medición es la que se aborda en la sub-ontología de caracterización y objetivos.

Una vez identificados los atributos objeto de la medición, se deben definir las métricas necesarias. Pala clarificar qué elementos generales hay que considerar en la definición de las métricas se ha definido la sub-ontología de las métricas, en la que se identifican los principales tipos de métricas que se pueden definir.

En la definición general de una métrica se deben especificar aspectos como la unidad en la que se expresa, la escala a la que pertenece, el atributo o atributos para los que se define, etc.

La definición de las métricas se debe realizar a distintos niveles o alcances, y que resultaría excesivamente complejo definir de forma directa métricas a partir de tal cuales se satisfagan las necesidades de información. Por ello, es fundamental definir en primer lugar métricas que se aplican directamente sobre las características de una entidad para evaluar un determinado atribulo. A partir de estas métricas directas se pueden definir métricas indirectas y finalmente se podrían definir métricas con el objetivo de proporcionar información útil para la toma de decisiones, ‘y por lo tanto, más cercanas i satisfacer las necesidades de información. Estos aspectos se tratan en la sub-ontología de las formas de medir, en la que se identifican los métodos concretos para definir o calcular las métricas definidas en función de su tipo.

1.2. Proceso de creación de Métricas Desde los años setenta se han propuesto una gran cantidad de métricas para capturar atributos de los procesos y productos software de una forma cuantitativa (véase apartado 4.3 de este capítulo). Tradicionalmente estas métricas se han realizado confiando en el conocimiento de los expertos, y si bien esta experiencia es importante, puede resultar no ser suficiente. En la actualidad muchas de las métricas propuestas han fracasado, siendo sólo unas pocas las que ha sobrevivido con éxito la fase inicial de definición y son usadas actualmente en la industria.

Ello es debido a varios problemas (Bridan, 1999):

•

•

•

•

Las métricas no están siempre definidas en un contexto en el que el objetivo de interés Industrial que se pretende alcanzar mediante su utilización es explícito y queda bien definido. Por ejemplo: la reducción del esfuerzo de desarrollo o la reducción de los fallos presentes en los productos software.

En ocasiones, aunque el objetivo sea explícito, las hipótesis experimentales a menudo no están hechas de forma explícita, por ejemplo ¿qué se pretende deducir del análisis?, ¿resulta creíble el resultado?

Las definiciones de métricas no siempre tienen en cuenta el entonto o el contexto en el cual serón aplicadas, por ejemplo ¿se puede utilizar una métrica definida para un entorno no orientado a objetos en un contexto orientado a objetos?

A menudo, no es posible realizar una adecuada validación teórica de las métricas porque el atribulo que una métrica pretende cuantificar no está bien definido, por ejemplo, la noción de complejidad.

Esta situación ha conducido frecuentemente a cierto grado de ambigüedad e imprecisión en las definición, propiedades y suposiciones de tas métricas, haciendo que su uso sea difícil, la interpretación peligrosa y que los resultados sean contradictorios en varios estudios de validación.

Los problemas citados anteriormente son propios de cualquier disciplina joven, y especialmente de aquellas que son intensamente humanas, como es el caso que se está tratando. Los fenómenos estudiados en este campo implican un número de variables que dependen del comportamiento humano y no pueden ser controladas fácilmente. No se debe esperar, por tanto, encontrar leyes cuantitativas que sean válidas y aplicables de modo general, y que tengan la misma precisión y exactitud que, por ejemplo, las Ieyes físicas.

Todas estas características no significan que no se pueda progresar en el camino de las métricas software, pero para poder conseguir este propósito las métricas deben ser definidas de una forma metodológica y disciplinada, teniendo dicha definición una base sólida con objetivos de medición claros y debiendo satisfacer las necesidades de la organización. Con este fin, se puede encontrar en la bibliografía diversos métodos para la definición de métricas software en los que se integran todos los aspectos que es necesario tener en cuenta en la validación de las métricas, como el método MMLC (Cantone y Donzellt, 2000) y la propuesta del Grupo Alarcos (Serrano 2002), que se ilustra en la figura 9.2 y en la que las flechas continuas representan el flujo de las métricas y las discontinuas representan el flujo de información a lo largo de torio el proceso.

La propuesta del Grupo Alarcos consta de dos fases:  Identificación. En esta etapa se pretende identificar los objetivos de la medición y las hipótesis bajo las cuales se crean las métricas. Los objetivos indican lo que se pretende conseguir con la utilización del proceso de medición y representan la razón por la que se llevará el proceso de medición (el "parqué"). Las hipótesis son la forma en la que se pretende llevar a cabo la medición (el "cómo"), identificando la información que se debe manejar para conseguir alcanzar los objetivos deseados, tiste proceso suele estar basado en la experiencia y el conocimiento de los expertos y puede utilizar mecanismos basados en (QQM: Basili and Weiss, 1984; Basili y Rombach, 1988; Van Solingeu and Berghout, 1999). Como resultado de esta fase se deben obtener los requisitos que debe cumplir la métrica, los cuales serán utilizados en la etapa de creación. Además, como se observa en la figura 9.2, los objetivos serán utilizados en las etapas de aceptación, aplicación y acreditación.  Creación. El proceso de Creación es aquel en el que a partir de los requisitos obtenidos en la etapa de Identificación se creará una métrica válida, lisia para ser aplicada en entornos reales. El proceso de creación de las métricas es evolutivo c iterativo y se subdivide en varias etapas intermedias. Como resultado de la realimentación, las métricas deben ser redefinidas de acuerdo a las validaciones, teóricas o empíricas, fallidas.

Al final de la etapa de creación, las métricas se considerarán válidas y aquellas que no sean válidas, serán descartadas. Las etapas en las que se subdivide la creación son:  Definición. Es el primer paso de esta fase que debe realizarse considerando tas características del producto que vamos a medir y la experiencia de los profesionales. En la definición se deben considerar objetivos claros, es decir, realizar una definición de la métrica orientada al objetivo identificado en la fase anterior para evitar obtener una definición de la métrica que no cumple con el objetivo deseado. Es deseable que la definición de las métricas se realice de manera formal para evitar ambigüedades.

 Validación teórica. El objetivo principal de la validación teórica es demostrar que la métrica mide el atributo que pretende medir, es decir, comprobar si la idea intuitiva acerca del atributo que está siendo medido se refleja en la métrica. Además la validación teórica proporciona información relacionada con las escalas de las métricas y así se puede determinar qué tipo de operaciones matemáticas y test estadísticos aplicar a la hora de analizar los valores de las métricas en estudios empíricos.

Lamentablemente no existe un estándar para la validación teórica a través del cual obtener la información matemática de las métricas definidas, sin embargo, hay dos tendencias principales en la validación: los marcos basados en propiedades (que definen formalmente propiedades deseables de las métricas para un atributo software concreto) (Weyukcr, 1988; Briand el al., 19%) y los que se basan en la teoría de la medida (Whitmire, 1997; Zuse, 1998; Poels y Dedene, 2000), cuyo objetivo es obtener la escala matemática a la que pertenece una métrica y por tanto sus transformaciones admisibles, estadísticos y test aplicables y especificar un marco general en el que las métricas deben ser definidas.  Validación empírica. El objetivo de esta etapa es probar la utilidad práctica de las métricas propuestas. El saber general, la intuición o la especulación, no son fuentes fiables de conocimiento (Basili et al., 1999) por lo que es necesario realizar validaciones empíricas de las métricas.

La validación empírica se utiliza para obtener información objetiva sobre la utilidad de las métricas propuestos ya que puede que una métrica sea correcta desde un pimío de vista formal, pero no tener relevancia práctica para un problema determinado. Así pues, el estudio empírico resulta necesario para comprobar y entender las implicaciones de las métricas de nuestros productos. Esto se consigue a través de hipótesis en el mundo real, más allá de la pura teoría, que habrá que comprobar con datos empíricos. Algunos trabajos relevantes que proporcionan la guía necesaria para llevar a cabo estudios empíricos son los realizados por Robson (1993), Wohlin et al. (2000), Jurista y Moreno (2001). Basili et ai. (1999) y Perry el al. (2000) (véase capítulo 11).  Explicación psicológica. Idealmente es necesario tener la capacidad de explicar la influencia de los valores de las métricas desde un punto de vista psicológico. Algunos autores, como Siau (1999), proponen el uso de la psicología cognitiva como una disciplina de referencia. De esta manera, las teorías como (T {AJaplative Control of TJwughi) (Anderson, 1983) pueden justificar la influencia de ciertas métricas en la comprensión de los sistemas.  Aceptación. Suele ser necesaria la existencia de una fase de pruebas en laboratorio en la que se realice una experimentación sistemática en entornos reales y con usuarios reales para verificar si cumple los objetivos buscados dentro de un entonto de trabajo real. Esta etapa se diferencia de los casos

de estudio en que en éstos últimos se suele trabajar en el entorno final de aplicación. En definitiva, cada etapa se intenta averiguar si las métricas "válidas" que se consiguieron al final de la fase de creación son aceptables en entornos tic aplicación reates, teniendo en cuenta los objetivos obtenidos en la etapa de identificación. Esta etapa debe ser realizada con proyectos no críticos y con riesgos controlados. Idealmente debería usarse en proyectos piloto de manera que el fracaso de aceptación de la métrica no suponga un fracaso en un proyecto importante. Si consigue demostrar que la métrica sigue cumpliendo los objetivos, es posible pasar a la etapa de aplicación, y si no es así, es necesario volver a la etapa de creación.  Aplicación. En esta etapa se utiliza la métrica ya aceptada en el entorno real. Esla fase se lleva a cabo en paralelo con la fase de acreditación.  Acreditación. Bata Última fase del proceso es una etapa dinámica que persigue el aseguramiento de la métrica y la mejora continua tic la misma, en función de cómo evoluciona el entorno de aplicación, de manera que se puedan seguir cumpliendo los objetivos que se perseguían al principio del método. En ocasiones el entorno puede variar tanto (por ejemplo, pasar de un entorno estructurado a uno orientado a objetos) que la métrica no sea aplicable, en este caso, la métrica debería ser descartada y el conocimiento adquirido durante su tiempo de vida debería ^alimentarse a la etapa de identificación de manera que podamos crear una métrica adecuada para el nuevo entorno cumpliendo los objetivos perseguidos. Además al utilizar la experiencia de la utilización de la métrica descartada, se tendrán más probabilidades de formular hipótesis conectas en la etapa de identificación.

2. ESTÁNDARES Y METODOLOGÍAS DE MEDICIÓN Antes de poder aplicar planes de mejora en una organización es necesario partir de una base cuantitativa que permita determinar de una forma objetiva los puntos fuertes y débiles de los procesos. Las métricas software constituyen la base necesaria para poder llevar a cabo un proceso de evaluación y posteriormente, una mejora de los procesos software. Por ello, la medición es un aspecto que se tiene muy en cuenta en los modelos de evaluación como en ISO/1EC 15501, en el que se define un proceso de la medición, o como CMM1 en el que se incluye un área clave de proceso en el nivel dos de madurez denominada "Medición y Análisis". Como soporte al proceso de medición se pueden: destacar diversos marcos de trabajo como el mencionado QQM o PSM (Practica! Software Measurement) (McGarry et al., 2002), así como ciertos estándares, entre los que destacan ISO 15939 (ISO, 2002c) e IEEE Std 1061-1998 (IEEE, 1998b). El objetivo de estos estándares y marcos de trabajo es proporcionar la referencia necesaria para poder llevar a cabo el proceso de

medición de una forma efectiva y sistemática, partiendo de la base de que la medición es un proceso que debe ser llevado a cabo en base a una serie de objetivos.

Ante las distintas propuestas metodológicas existentes sobre la medición de software es necesario analizar la relación entre las mismas. Para ello se ha seguido la comparativa realizada por Jones (2003) con la que se llega a la conclusión de que existe un cada vez mayor esfuerzo por coordinar las distintas propuestas. En la figura 9.3 se muestra la relación existente entre algunas de las propuestas más significativas relacionadas con la medición del software.

Ante las distintos propuestas método lógicas existentes sobre La medición de software es necesario analizar la relación entre las mismas. Para ello se ha seguido la comparativa realizada por Jones (2003) con la que se llega a la conclusión de que existe un cada vez mayor esfuerzo por coordinar las distintas propuestas, fin la figura 9.3 se muestra la relación existente entre algunas de las propuestas más significativas relacionadas con la medición del software. Los principales aspectos a considerar en la relación entre las diferentes propuestas son los siguientes: •

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. PSM proporciona detalles adicionales respecto de las actividades y tareas de ISO 15939.

LINKS MAPAS bubbl.us:

https://bubbl.us/?h=258408/4cbea5/24MK4TLDRCzPc&r=537772855 https://bubbl.us/?h=258408/4cbe92/24o3AYTx1F5oM&r=1589438452 https://bubbl.us/?h=258408/4cbe92/24o3AYTx1F5oM&r=58679031