INGENIERÍA DE SOFTWARE IV

Unidad 10

Reingeniería

MsC. PATTY PEDROZA BARRIOS

 REINGENIERIA
“Rehacer la Ingeniería de nuestros negocios; mediante la
potencia de la tecnología moderna y así tener mejoras
drásticas de su rendimiento” (Michael Hammer 1990)

Modificar reglas para mejorar efectividad (software sigue el

ritmo)

• Implica creación de nuevos sistemas.

• Reconstrucción o modificación de las aplicaciones existentes.
Modificación

SISTEMA TECNOLOGIA
Creación
 REINGENIERÍA
Se originó a finales de la década de 1980 aunque se popularizó en la
década de 1990.

La reingeniería es un proceso que trata de dar respuesta a una

interrogante: ¿Estamos acaso haciendo las cosas bien o podríamos
hacerlas mejor?

Es el rediseño o cambio drástico de un proceso en un negocio (deriva

hacia el producto). Es comenzar de cero, cambio de todo o nada.
REINGENIERÍA DE PROCESOS DE
NEGOCIO - RPN
RPN.-Búsqueda e implementación de
cambios radicales en el proceso de
Negocios para lograr un avance
significativo.

Procesos de Negocio.- Conjunto de

tareas lógicamente relacionadas que
se llevan a cabo para obtener un
determinado resultado de negocio
 Definición del
Negocio

MODELO DE Refinamiento
e

REINGENIERÍA instanciación
Se integra en
un sistema de

DE PROCESO Creación de
Prototipos
Neg.
Definición
de Procesos
DE NEGOCIO Se
comprueba
“Procesos
Criticos”
el proceso
para
Especificació
refinamiento Evaluación
n y diseño
de Procesos
de Procesos
Casos prácticos Costes y tiempos
para diseño de de tareas
Proc.
 PRINCIPIOS DE LA
REINGENIERÍA
The Boston Consulting Group, gracias a sus años de experiencia en la
consultoría relacionada con la Reingeniería, estima en doce los principios
clave en los que se basa la BPR:

1. Se necesita el apoyo de la gerencia de primer nivel o nivel estratégico,

que debe liderar el programa
2. La estrategia empresarial debe guiar y conducir los programas de la
BPR.
3. El objetivo último es crear valor para el cliente.
4. Hay que concentrarse en los procesos, no en las funciones,
identificando aquellos que necesitan cambios.
 PRINCIPIOS DE LA
REINGENIERÍA
5. Son necesarios equipos de trabajo, responsables y capacitados, a los que hay
que incentivar y recompensar con puestos de responsabilidad en la nueva
organización que se obtendrá tras el proceso de Reingeniería.
6. La observación de las necesidades de los clientes y su nivel de satisfacción
son un sistema básico de retroalimentación que permite identificar hasta qué
puntos se están cumpliendo los objetivos.
7. Es necesaria la flexibilidad a la hora de llevar a cabo el plan. Si bien son
necesarios planes de actuación, dichos planes no deben ser rígidos, sino que
deben ser flexibles a medida que se desarrolla el programa de BPR y se
obtienen las primeras evaluaciones de los resultados obtenidos.
8. Cada programa de Reingeniería debe adaptarse a la situación de cada
negocio, de forma que no se puede desarrollar el mismo programa para
distintos negocios.
 PRINCIPIOS DE LA
REINGENIERÍA
9. Se requiere el establecimiento de correctos sistemas de medición del
grado de cumplimiento de los objetivos. En muchos casos, el tiempo es
un buen indicador. Sin embargo, no es el único posible y en
determinadas ocasiones no es el más adecuado.
10. Se debe tener en cuenta el factor humano a la hora de evitar o reducir la
resistencia al cambio, lo cual puede provocar un fracaso, o al menos
retrasos en el programa.
11. La BPR no debe ser visto como un proceso único, que se deba realizar
una única vez dentro de la organización si no que se debe contemplar
como un proceso continuo, en el que se plantean nuevos retos.
12. La comunicación se constituye como un aspecto esencial, no sólo a
todos los niveles de la organización, sino traspasando sus fronteras
(prensa, comunidad, sistema político, etc.).
 REINGENIERÍA DE SOFTWARE
• Surge de Software Antiguos Mejorados pero Inestables a
cambios
• “Forma de modernización para mejorar las capacidades y/o
mantenibilidad de los sistemas de información heredados
mediante la aplicación de tecnologías y practicas
modernas”.
• «Es el examen y alteración de un sistema para reconstruirlo
de una nueva forma y la subsiguiente implementación de
esta nueva forma»
• Absorbe recursos y requiere mucho tiempo aplicando
estrategias.
 REINGENIERÍA DE SOFTWARE
 La reingeniería es un proceso que altera los elementos
internos de toda obra, no es una sola remodelación de la
fallada.
 La reingeniería ayuda a la evolución y mantenimiento del
software.
 La Reingeniería de Software ofrece una disciplina de
preparación para migrar un sistema de información heredado
hacia un sistema evolucionable.
 El proceso aplica principios de ingeniería para un sistema
existente para encontrar nuevos requerimientos
 REINGENIERÍA DE SOFTWARE
• La Reingeniería de software es costosa y consumidora de
tiempo
• La reingeniería es una actividad de reconstrucción, preferible
de realizar antes de que se “derrumbe” la obra
• Antes de derribar una casa, quizás se necesita corroborar qué
está mal.
REINGENIERÍA DEL SOFTWARE

El Instituto de • “La reingeniería es la transformación

Ingeniería de sistemática de un sistema existente
software (SEI) dentro de una nueva forma de realizar
mejoramientos de calidad en una
desarrollo una operaciones, capacidad del sistema,
definición de funcionabilidad, rendimiento o
Reingeniería evolucionabilidad a bajo costo, agendas o
riesgos para el cliente.”
como:
REINGENIERÍA DEL SOFTWARE

Para Roger • “La reingeniería del software abarca una serie de

Pressman actividades entre las que se incluye el análisis de
inventario, la reestructuración de documentos, la
una definición ingeniería inversa, la reestructuración de programas
y datos, y la ingeniería directa. El objetivo de esas
completa de actividades consiste en crear versiones de los
programas existentes que muestren una mayor
reingeniería calidad, y una mejor mantenibilidad.”

implica:
 MODELO DE
PROCESO DE
REINGENIERÍA
DE SOFTWARE
• Se divide en
procesos
separados que se
llevan a cabo
secuencialmente:
 CUÁNDO ES NECESARIA LA
REINGENIERÍA?

Los candidatos a • Frecuentes fallas de producción (fiabilidad

cuestionable).
la reingeniería • Problemas de rendimiento.
• Tecnología obsoleta.
aparecen • Problemas de integración del sistema.
• Código de calidad pobre.
usualmente si • Dificultad (peligroso) al cambio.
• Dificultad para probar.
cumplen estas • Mantenimiento caro.
condiciones: • Incremento de problemas del sistema.
 CUÁNDO ES NECESARIA LA
REINGENIERÍA?

A pesar de estas
razones, y antes de • Dejar el producto como está.
reconstruir un sistema
• Adquirir uno en el mercado que
en uso, es conveniente realice la misma función.
analizar las diversas
alternativas • Reconstruirlo.
disponibles:
RELACIONES TÉRMINOS
REINGENIERÍA
PASOS DE LA REINGENIERÍA DEL
SOFTWARE
La reingeniería del software involucra diferentes actividades como son:
• análisis de inventarios
• reestructuración de documentos
• ingeniería inversa
• reestructuración de programas y datos
• ingeniería directa

Con la finalidad de crear versiones de programas ya existentes que sean de

mejor calidad y los mismos tengan una mayor facilidad de mantenimiento.
PASOS DE LA REINGENIERÍA DEL
SOFTWARE
 REINGENIERÍA: ANÁLISIS DE
INVENTARIOS
Todas las organizaciones Los candidatos a la
de software deberían tener reingeniería aparecen
un inventario de todas sus cuando se ordena esta Es importante señalar que
aplicaciones. El inventario información en función de el inventario deberá
tal vez no sea más que un su importancia para el visitarse con regularidad, el
modelo en una hoja de negocio, longevidad, estado de las aplicaciones
cálculo que contenga mantenibilidad actual y puede cambiar en función
información que otros criterios localmente del tiempo y, como
proporcione una importantes. Es entonces resultado, cambiarán las
descripción detallada cuando es posible asignar prioridades para la
(tamaño, edad, importancia recursos a las aplicaciones reingeniería.
para el negocio) de las candidatas para el trabajo
aplicaciones activas. de reingeniería.
REINGENIERÍA: RESTRUCTURACIÓN
DE DOCUMENTOS

La documentación débil
es la marca de muchos
El sistema es crucial
sistemas heredados.
La documentación debe para el negocio y debe Cada una de estas
¿Pero que se hace
actualizarse pero se volver a documentarse opciones es viable. Una
acerca de ellos?
tiene recursos limitados. por completo incluso en organización de software
¿Cuáles son las
Se utiliza un enfoque de este caso un enfoque debe elegir la más
opciones? Crear
“documentar cuando se inteligente es recortar la apropiada para cada
documentación consume
toque”. documentación a un caso.
mucho tiempo, si el
mínimo esencial.
sistema funciona vivirá
con lo que tenga.
 REINGENIERÍA: INGENIERÍA
INVERSA
Este término tiene sus orígenes en el mundo del hardware. Una cierta compañía
desensambla un producto de hardware competitivo en un esfuerzo por comprender los
“secretos” del diseño y fabricación de su competidor.

Estos secretos se podrán comprender más fácilmente si se obtuvieran las especificaciones

de diseño y fabricación del mismo. Pero estos documentos son privados, y no están
disponibles para la compañía que efectúa la ingeniería inversa.

En esencia, una ingeniería inversa con éxito precede de una o más especificaciones de diseño y
fabricación para el producto, mediante el examen de ejemplos reales de ese producto.
 REINGENIERÍA: INGENIERÍA
INVERSA
La ingeniería inversa del software es algo similar. En la mayoría de los casos, el programa del cual
hay que hacer una ingeniería inversa no es el de un rival, sino, más bien, el propio trabajo de la
compañía.

Los “secretos” que hay que comprender resultan incomprensibles porque nunca se llegó a
desarrollar una especificación.

Consiguientemente, la ingeniería inversa del software es el proceso de análisis de un programa con

el fin de crear una representación de programa con un nivel de abstracción más elevado que el
código fuente.
La Ingeniería inversa es un proceso de recuperación de diseño. Con las herramientas de la
ingeniería inversa se extraerá del programa existente información del diseño arquitectónico y de
proceso, e información de los datos.
 REINGENIERÍA:
RESTRUCTURACIÓN DEL CÓDIGO
El tipo más común de reingeniería es la reestructuración de código, se puede hacer con
módulos individuales que se codifican de una manera que dificultan comprenderlos, probarlos y
mantenerlos.

Llevar a cabo esta actividad requiere analizar el código fuente empleando una herramienta de
reestructuración, se indican las violaciones de las estructuras de programación estructurada, y
entonces se reestructura el código (esto se puede hacer automáticamente).

El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan

introducido anomalías. Se actualiza la documentación interna del código.
 REINGENIERÍA:
RESTRUCTURACIÓN DE DATOS
La reestructuración de datos es una actividad de reingeniería a gran escala. En la mayoría de los casos, la
reestructuración de datos comienza con una actividad de ingeniería inversa. La arquitectura de datos
actual se analiza con minuciosidad y se define los modelos de datos necesarios, se identifican los
objetivos de datos y los atributos, y después se revisa la calidad de las estructuras de datos existentes.

Cuando la estructura de datos es débil (por ejemplo, actualmente se implementan archivos planos, cuando
un enfoque relacional simplificaría muchísimo el procesamiento), se aplica una reingeniería a los datos.

Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del programa, y también
sobre los algoritmos que lo pueblan, los cambios en datos darán lugar invariablemente a cambios o bien
de arquitectura o bien de código.
 REINGENIERÍA: INGENIERÍA
DIRECTA
La ingeniería directa no solo
Después de un espacio de
recupera la información de
tiempo corto, es probable que
En un mundo ideal, las diseño a partir del software
llegue a aparecer este “motor”,
aplicaciones se reconstruyen existente, también utiliza esta
pero los fabricantes de CASE
utilizando un “motor de información para alterar o
han presentado herramientas
reingeniería” automatizado. En reconstruir el sistema
que proporcionan un
el motor se insertaría el existente con la finalidad de
subconjunto limitado de estas
programa viejo, que lo mejorar su calidad global. En
capacidades y que se
analizaría, reestructuraría y la mayoría de los casos el
enfrentan con dominios de
después regeneraría la forma software sometido a
aplicaciones específicos. Lo
de exhibir los mejores reingeniería vuelve a
que es más importante, estas
aspectos de la calidad del implementar la función del
herramientas de reingeniería
software. sistema existente y también
cada vez son más
añade nuevas funciones o
sofisticadas.
mejoras
 TALLER
• Hacer una investigación acerca de la Reingeniería de Software,
según Ian Sommerville.
• Defina los diferentes Métodos y modelos de la Reingeniería
Importante: La comunicación entre docente y estudiantes es únicamente a través del
correo electrónico: [email protected]
Igualmente se reciben desde el correo institucional del estudiantes pnombres-
[email protected]
También utilizaremos la plataforma Microsoft Teams
 INGENIERÍA DE SOFTWARE IV
Unidad 9
Métricas en los Sistemas Orientados a
Objetos

MsC. PATTY PEDROZA BARRIOS

 MÉTRICAS PARA
SISTEMAS ORIENTADOS A OBJETOS
Las métricas para sistemas OO deben de ajustarse a las características que
distinguen el software OO del software convencional.

Estas métricas hacen hincapié en el encapsulamiento, la herencia,

complejidad de clases y polimorfismo.

Por lo tanto las métricas OO se centran en métricas que se pueden aplicar a

las características de encapsulamiento, ocultamiento de información, herencia
y técnicas de abstracción de objetos que hagan única a esa clase.
 MÉTRICAS PARA
SISTEMAS ORIENTADOS A OBJETOS

Como en todas las métricas los objetivos

principales de las métricas OO se derivan
del software convencional:
comprender mejor la
mejorar la calidad del
calidad del producto,
trabajo realizado a nivel
estimar la efectividad del
del proyecto.
proceso y
 OBJETIVO DE LAS MÉTRICAS
ORIENTADOS A OBJETOS
Los objetivos principales de las métricas
orientadas a objetos son los mismos que los
existentes para las métricas surgidas para el
software estructurado:
• Comprender mejor la calidad del producto
• Estimar la efectividad del proceso
• Mejorar la calidad del trabajo realizado en el nivel del proyecto.
 OBJETIVO DE LAS MÉTRICAS
ORIENTADOS A OBJETOS
Cada uno de estos objetivos es importante en sí, pero
para el ingeniero de software, la calidad del producto
debe de ser lo esencial. [Laranjeira 1990].
• ¿Cómo se puede medir la calidad de un sistema 0.0?
• ¿Que características del modelo de diseño se pueden estimar para
decretar si el sistema será o no fácil de implementar?
• ¿Se podrá probar, que será fácil de modificar?
• y lo que es más importante, ¿resultará tolerable para los usuarios
finales?
 CARACTERÍSTICAS DEL
SOFTWARE ORIENTADOS A OBJETOS
Berard define cinco características que dan lugar a
unas métricas especializadas:
• Localización,
• Encapsulamiento,
• Ocultamiento de información,
• Herencia y
• Técnicas de abstracción de objetos.
 CARACTERÍSTICAS DEL
SOFTWARE OO: LOCALIZACIÓN
La localización es una característica del software que indica la forma que se concentra la información dentro de
un programa.

En el contexto OO, la información se concentra mediante el encapsulamiento tanto de datos como de procesos
dentro de los límites de una clase u objeto.

Dado que las clases constituyen la unidad básica de los sistemas OO, la localización está basada en los objetos.
Por tanto, las métricas deberían de ser aplicables a la clase (objeto) como si se tratara de una entidad completa.

Además, la relación entre operaciones (funciones) y clases no es precisamente uno-a-uno. Por tanto, las métricas
que reflejan la forma en que colaboran las clases deben de ser capaces de adaptarse a las relaciones uno-a-
muchos y muchos-a-uno.
 CARACTERÍSTICAS DEL SOFTWARE
OO: ENCAPSULAMIENTO
Pressman define el encapsulamiento como “el empaquetamiento (o enlazado) de una colección de elementos.

Para los sistemas OO, el encapsulamiento comprende las responsabilidades de una clase, incluyendo sus atributos (y
otras clases para objetos agregados) y operaciones, y los estados de la clase, según se definen mediante valores
específicos de atributos.

El encapsulamiento influye en las métricas cambiando el objetivo de la medida, que pasa de ser un único módulo a ser un
paquete de datos (atributos) y de módulos de procesamiento (operaciones).

Además, el encapsulamiento impulsa a la medida hasta un nivel de abstracción más elevado.

 CARACTERÍSTICAS DEL SOFTWARE
OO: OCULTAMIENTO DE LA
INFORMACIÓN
El ocultamiento de información suprime los detalles operativos de
un componente de un programa. Tan sólo se proporciona la
información necesaria para acceder a ese componente o a
aquellos otros componentes que deseen acceder a él.

Un sistema OO bien diseñado debería de impulsar al ocultamiento

de información. Por tanto, aquellas métricas que proporcionen una
indicación del grado en que se ha logrado el ocultamiento
proporcionarán una indicación de la calidad del diseño OO.
 CARACTERÍSTICAS DEL SOFTWARE
OO:
HERENCIA
La herencia es un mecanismo que hace posible que los compromisos de un objeto se
difundan a otros objetos. La herencia se produce a lo largo de todos los niveles de la
jerarquía de clases.

Dado que la herencia es una característica fundamental de muchos sistemas OO, hay
muchas métricas OO que se centran en ella.

Ejemplos:
• se cuentan el número de descendientes (número de instancias inmediatas de una clase),
• número de predecesores (número de generalizaciones inmediatas),
• grado de anidamiento de la jerarquía de clases (profundidad de una clase dentro de una jerarquía de
herencia) y otros.
 CARACTERÍSTICAS DEL SOFTWARE
OO:
ABSTRACCIÓN
La abstracción es un mecanismo que permite al diseñador centrarse en los detalles esenciales de
algún componente de un programa (tanto si es un dato como si es un proceso) sin preocuparse por
los detalles de nivel inferior.

Cuando los niveles de abstracción van elevándose, se ignoran más y más detalles, por lo tanto, se proporciona una
visión más general de un concepto u objeto. A medida que pasamos a niveles mas reducidos de abstracción, se
muestran más detalles, esto es, se proporciona una visión más específica de un concepto u objeto.

Dado que una clase es una abstracción que se puede visualizar con muchos niveles distintos de detalles, y de muchas
maneras diferentes, las métricas OO representan la abstracción en términos de medidas de una clase (p.ej.: número de
instancias por clase por aplicación).
 MÉTRICAS PARA EL MODELO DE
DISEÑO ORIENTADO A OBJETOS
Gran parte del diseño orientado a objetos es subjetivo, un diseñador experimentado “sabe”
como puede caracterizar un sistema OO para que se implemente de forma efectiva los
requisitos del cliente.

Pero a medida que los modelos de diseño OO van creciendo de tamaño y complejidad,
puede resultar beneficiosa una visión más objetiva de las características del diseño, tanto
para el diseñador experimentado como para el menos experimentado.

Una visión objetiva del diseño debería de tener un componente cuantitativo y esto nos
lleva a las métricas OO, en donde se pueden aplicar no solo al modelo de diseño, sino
también al modelo de análisis [Laranjeira].
 MÉTRICAS ORIENTADAS A
CLASES

Se sabe que la clase es la unidad principal de todo sistema OO. Por consiguiente, las medidas y
métricas para una clase individual, la jerarquía de clases, y las colaboraciones de clases resultarán
sumamente valiosas para un ingeniero de software que tenga que estimar la calidad de un diseño.

Se ha visto que la clase encapsula a las operaciones (procesamiento) y a los atributos (datos). La
clase suele ser el “predecesor” de las subclases (que a veces se denominan “descendientes”) que
heredan sus atributos de operaciones.

La clase suele colaborar con otras clases. Todas estas características se pueden utilizar como bases
de las métricas explicadas , a continuación:
 MÉTRICAS ORIENTADAS A CLASES:
CONJUNTO DE MÉTRICAS CK

Uno de los conjuntos de métricas de software OO a los que se hace más ampliamente referencia es el
propuesto por Chidamber y Kemener . Estas métricas propuestas de diseño basadas en clases, a las
cuales suele aludirse con el nombre de conjunto de métricas CK para sistemas OO.

Los métodos ponderados por clase (MPC), son aquellos en donde se definen n métodos de complejidad
C1, C2..., Cn, para una clase C. La métrica de complejidad específica que se selecciona debe de
normalizarse de tal modo que la complejidad nominal para un método tome el valor 1.0.

MPC = Ó Ci, para i = 1 hasta n

MÉTRICAS ORIENTADAS A CLASES:
CONJUNTO DE MÉTRICAS CK
Finalmente, a medida que el
El número de métodos y su Además, cuanto mayor sea el
número de métodos crece
complejidad es un indicador número de métodos, más
para una clase dada; es más
razonable de la cantidad de complejo será el árbol de
probable que se vuelva cada
esfuerzo necesaria para herencia, (todas las subclases
vez más específico de la
implementar y comprobar una heredan el método de sus
aplicación, imitando por tanto
clase. predecesores).
su potencial de reutilización.

Por todas estas razones,

MPC debería de mantener un
valor tan bajo como sea
razonable.
MÉTRICAS ORIENTADAS A CLASES:
MÉTRICAS PROPUESTAS POR
LORENZ Y KIDD
Las métricas orientadas a tamaños para una clase
OO se centran en cálculos de atributos y de
operaciones para una clase individual, y promedian
los valores para el sistema 00 en su totalidad.

Las métricas basadas en herencia se centran en la

forma en que se reutilizan las operaciones a lo
Lorenz y Kidd dividen largo y ancho de la jerarquía de clases.
las métricas basadas
en clases en cuatro
categorías: Las métricas para valores internos de clase
examinan la cohesión y asuntos relacionados con
el código,

y las métricas orientadas a valores externos

examinan el acoplamiento y la reutilización.
 MÉTRICAS ORIENTADAS A
OPERACIONES
Dado que la clase es la unidad dominante en los
sistemas OO, se han planteado menos métricas para
las operaciones de clases. Churcher y Shepperd
describen esto cuando afirman:
• Los resultados de los últimos estudios indican que los métodos
tienden a ser pequeños, tanto en términos del número de sentencias
como en términos de su complejidad lógica [WIL92], lo cual sugiere
que la estructura de conectividad de un sistema pueda resultar más
importante que el contenido de los módulos individuales.
 MÉTRICAS ORIENTADAS A
OPERACIONES

Sin embargo, existen algunas ideas que pueden llegar a estimarse, se indican
a continuación tres métricas sencillas propuestas por Lorenz y Kidd:

1. Tamaño medio de operación (TOavg).

• Aunque se lograría utilizar las líneas de código como indicador para el tamaño de operación, la
medida LOC padece de considerables problemas. Por esta razón, el número de mensajes
enviados por la operación proporciona una alternativa para el tamaño de la operación. A medida
que asciende el número de mensajes enviados por una única operación, es posible que las
responsabilidades no hayan sido bien estipuladas dentro de la clase.
 MÉTRICAS ORIENTADAS A
OPERACIONES
Sin embargo, existen algunas ideas que pueden llegar a estimarse,
se indican a continuación tres métricas sencillas propuestas por
Lorenz y Kidd:

2. Complejidad de operación (CO).

• La complejidad de una operación se consigue calcular empleando cualquiera de las

métricas de complejidad propuestas para el software convencional Sabiendo que las
operaciones convendrían limitarlas a una responsabilidad específica, en donde el
diseñador debería esforzarse por mantener el valor de CO tan bajo como sea posible.
 MÉTRICAS ORIENTADAS A
OPERACIONES
Sin embargo, existen algunas ideas que pueden llegar a
estimarse, se indican a continuación tres métricas sencillas
propuestas por Lorenz y Kidd:

3. Número Medio de Parámetros por operación (NPavg).

• En cuanto sea más grande el número de parámetros de la operación, será más

compleja la colaboración entre objetos. En general, NPavg debería de
mantenerse tan bajo como sea posible.
 MÉTRICAS PARA PRUEBAS
ORIENTADAS A OBJETOS
Las métricas de diseño proporcionarán una predicción de la calidad del
diseño, también proporcionan una indicación general de la cantidad de
esfuerzo de pruebas necesario para aplicarlo en un sistema OO.

Pressman sugiere una amplia gamma de métricas de diseño que tienen

influencia directa en la “comprobabilidad” de un sistema OO.

Las métricas se crean en categorías que reflejan características de diseño

importantes:
 MÉTRICAS PARA PRUEBAS OO:
ENCAPSULAMIENTO

• Cuanto más alto sea el valor

Carencia de de CCM, más estados
Cohesión tendrán que ser probados
para asegurar que los
en Métodos métodos no den lugar a
(CCM). efectos secundarios.
 MÉTRICAS PARA PRUEBAS OO:
ENCAPSULAMIENTO
• Los atributos públicos se heredan de otras clases,
y por tanto son visibles para esas clases.
Porcentaje • Los atributos protegidos son una especialización y
son privados de alguna subclase específica.
Público y • Esta métrica indica el porcentaje de atributos de
Protegido clase que son públicos.
• Unos valores altos de PPP incrementan la
(PPP). probabilidad de efectos colaterales entre clases, y
por lo tanto es preciso diseñar comprobaciones
que aseguren que se descubran estos efectos
colaterales.
MÉTRICAS PARA PRUEBAS OO:
ENCAPSULAMIENTO

Acceso • Esta métrica muestra el número de

clases (o métodos) que pueden
Público a acceder a los atributos de otra clase,
violando así el encapsulamiento.
Datos • Unos valores altos de APD dan lugar
a un potencial de efectos colaterales
miembros entre clases.
• Es preciso diseñar comprobaciones
(APD). para asegurar que se descubran
estos efectos colaterales.
MÉTRICAS PARA PRUEBAS OO:
HERENCIA

Número • Esta métrica es un recuento de las

jerarquías de clases distintas que se
de describen en el modelo de diseño, en
donde será preciso desarrollar
Clases conjuntos de pruebas para cada una
de las clases raíz, y para la
Raíz correspondiente jerarquía de clases.
• A medida que crece NCR crece
(NCR). también el esfuerzo de comprobación.
MÉTRICAS PARA PRUEBAS OO:
HERENCIA
• Cuando se utiliza en el contexto OO, la
admisión es una indicación de herencia
múltiple.
ADMisión • Cuando la ADM sea mayor a 1, indica
que una clase hereda sus atributos y
(ADM). operaciones de más de una clase raíz.
• Siempre que sea posible, es preciso
evitar un valor de ADM mayor a 1.
 MÉTRICAS PARA PROYECTOS
ORIENTADOS A OBJETOS
Se sabe que el trabajo del administrador de un proyecto es
planificar, coordinar, seguir y controlar un proyecto de
software.

¿Pero qué sucede con las medidas? ¿Existen métricas OO

especializadas que pueda utilizar el administrador del
proyecto para disponer de una mejor visión de su progreso?
• La respuesta es por supuesto que “sí”.
 MÉTRICAS PARA PROYECTOS
ORIENTADOS A OBJETOS
La primera actividad que desarrolla el administrador del proyecto es
la planificación y una de las primeras tareas de la planificación es la
estimación.

Por tanto, el plan y sus estimaciones de proyecto se visitan después

de cada iteración de
• Análisis Orientado a Objetos(A00),
• Diseño Orientados a Objetos (D00), e incluso
• la Programación Orientada a Objetos (POO).
 MÉTRICAS PARA PROYECTOS
ORIENTADOS A OBJETOS

Uno de los problemas fundamentales a los que

se enfrenta un administrador de proyectos
durante la planificación es, la estimación del
tamaño implementado del software, ya que se
conoce que el tamaño es directamente
proporcional al esfuerzo y la duración.
 MÉTRICAS PARA PROYECTOS
ORIENTADOS A OBJETOS
Las métricas OO siguientes pueden aportar
ideas acerca del tamaño del software:
• Las clases clave se centran directamente en el dominio del negocio para el
Número de problema que se estará analizando, y tendrán menor probabilidad de ser
implementadas mediante reutilización.

Clases Clave • Por esta razón, unos valores elevados NCC indican que en nuestro camino
encontraremos una cantidad notable de trabajo de desarrollo.
• Lorenz y Kidd sugieren que entre el 20 y el 40 por ciento de todas las clases
(NCC). de un sistema OO típico son clases clave. El resto sirve como
infraestructura de apoyo (IGU, comunicaciones, bases de datos, etc.).
MÉTRICAS PARA PROYECTOS
ORIENTADOS A OBJETOS
Las métricas OO siguientes pueden
aportar ideas acerca del tamaño del
software:
Número de • El número de subsistemas proporciona una
idea general de la asignación de recursos,
SUBsistemas de la planificación (con especial hincapié en
el desarrollo en paralelo), y del esfuerzo
(NSUB). global de integración.
MÉTRICAS PARA PROYECTOS
ORIENTADOS A OBJETOS
Las métricas NCC y NSUB se pueden escoger para otros
proyectos OO anteriores, y se pueden relacionar con el
esfuerzo invertido en el proyecto y también con las
actividades de proceso individuales.

Estos datos se pueden utilizar también junto con métricas de

diseño, con el objeto de calcular “métricas de productividad”
tales como el número medio de clases por desarrollador o el
promedio de métodos por persona y mes.

En su conjunto, estas métricas se pueden utilizar para estimar

el esfuerzo, la duración, el personal y otras informaciones
acerca del proyecto para el proyecto actual.
 EJERCICIO
• Se determina la siguiente información:

IMS = [Mr – (Fa + Fc + Fd)]/ Mr

IMS = [940 – (90 + 40 + 12)]/ 940
IMS = 798 / 940 = 0.849

• De acuerdo con este resultado, IMS = 0,849, se puede decir que el

sistema ha comenzado a estabilizarse ya que el IMS se está
aproximando a 1
Importante: La comunicación entre docente y estudiantes es únicamente a través del
correo electrónico: [email protected]
Igualmente se reciben desde el correo institucional del estudiantes pnombres-
[email protected]
También utilizaremos la plataforma Microsoft Teams