1.
CONTENIDO
1.- MÉTRICAS ORIENTADAS A OBJETO (LORENZ Y KIDD)
-Tamaño de Clase (TC)
-Númerode OperacionesInvalidadas por una subclase (NOI).
- Índice de Especialización(IE).
2.- MÉTRICAS ORIENTADAS A CASO DE USO
- Modelode casos de uso
-Técnicasde estimación
- Puntosde casos de uso
-El objetivode la técnica
3.- MÉTRICAS DE PROYECTO WEBAPP.
4.- MÉTRICAS PARA CALIDAD DE SOFTWARE
5.- LA MEDICIÓNDE LA CALIDAD (GILB)
6.- EFICIENCIAEN LA REMOCIÓN DEL DEFECTO
Desarrollo
1.- METRICAS ORIENTADAS A OBJETO
En el librode métricasrealizadoporLorenzy Kidd0.0 [Laranjeira’90], dividen
lasmétricasbasadasen clasesencuatro categorías:tamaño, herencia,valores
internosyvaloresexternos.Lasmétricasorientadasatamañospara una clase 00 se
centranen cálculosde atributosyde operacionesparauna clase individual,y
promedianlosvaloresparael sistema00 ensu totalidad.Lasmétricasbasadasen
herenciase centranenla formaenque se reutilizanlasoperacionesa124 lolargoy
ancho de la jerarquíade clases.Las métricaspara valoresinternosde clase

2.
examinanlacohesiónyasuntosrelacionadosconel código,ylasmétricas
orientadasavaloresexternosexaminanel acoplamientoylareutilización.
Tamaño de Clase (TC).
El tamaño general de unaclase se puede determinarempleandolasmedidas
siguientes:
- El númerototal de operaciones(tantooperacionesheredadascomoprivadasde la
instancia) que estánencapsuladasdentrode laclase.
- El númerode atributos(tantoatributosheredadoscomoatributosprivadosde la
Instancia) que estánencapsuladosenlaclase.
Si existenvaloresgrandesde TCéstosmostraránque una clase puede tener
demasiadaresponsabilidad,locual reducirálareutilizabilidadde laclase y
complicarála implementaciónylacomprobación,porotra parte cuanto menorsea
el valormediopara el tamaño,másprobable esque lasclasesexistentesdentrodel
sistemase puedanreutilizarampliamente.
Númerode OperacionesInvalidadaspor una subclase (NOI).
Existencasosenque una subclase sustituye unaoperaciónheredadade su
superclase porunaversiónespecializadaparasupropiouso,ya estose le denomina
invalidación.Losgrandesvaloresde NOIsuelenindicarunproblemade diseñoya
que si NOI eselevado,entoncesel diseñadorhavioladolaabstracciónimplicadapor
la superclase.Estodalugara unajerarquía de clasesdébil,yaun software 00 que
puedaresultardifícil de comprobarymodificar.
Índice de Especialización(IE).
El índice de especializaciónproporcionaunaindicaciónaproximadadel grado
de especializaciónde cadaunade lassubclasesexistentesenunsistemaorientadoa
objetos.
La especializaciónse puedealcanzarañadiendooborrandooperaciones,obien
por invalidación.
IE = [NOIx nivel] Mtotal
En donde nivel esel nivel de lajerarquíade clasesenque reside laclase,y Mtotal
esel númerototal de métodosparala clase.Cuantomáselevadoseael valorde IE

3.
esmás probable que lajerarquíade clasestengaclasesque no se ajustana la
abstracciónde la superclase.
MÉTRICAS ORIENTADAS A CASO DE USO
Uno de losprincipalesproblemasalosque se enfrentanlosdesarrolladores
de software al momentode planear proyectoseslaestimación.Existendistintas
técnicasque permitenestimarproyectosde software,cadaunade ellasconsus
ventajasydesventajas,perolamayoríade ellasnoofrecenlaflexibilidadde estimar
software orientadoaobjetos,yse basanprácticamente enlaexperienciadel equipo
de desarrollo.Latécnicade estimaciónconpuntosde caso de uso nospermite
realizarestimacionesapartirde modelosorientadosaobjetosconunaprecisión
bastante aceptable.
Estimar,o cuantificar,software noesunatarea fácil.Lasmetodologíasde
desarrollode sistemashanevolucionado,desde losantiguossistemasporlotes,la
programaciónestructurada,hastala orientaciónaobjetos,perolastécnicasde
estimaciónnolohanhecho.Por un lado,se conocenalgunastécnicascomo
COCOMO,Puntosde Funcióny otras,pero lamayoría de ellasse basanencriterios
muypoco efectivosde aplicarcomolíneasde código,experienciapreviasobre
sistemassimilares,etc.De estaforma,hemospodidonotaruncambioenlas
metodologíasparael desarrollode software yde lamismamanera,existentécnicas
adecuadasque nospermitenrealizarestimaciones,comolatécnicade puntosde
casos de uso,la cual se basa enmetodologíasorientadasaobjetos,específicamente
enel modelode casosde uso.Este trabajo se enfocaenla descripciónde esta
técnica,lacual esmuy fácil de comprenderysu aplicaciónnoesmuydifícil de llevar
a cabo como podremosvera continuación.
Modelo de casos de uso
El modelode casosde usoes un artefactoque surge comoproducto de la
fase de requerimientosde lametodologíade desarrolloygestiónde proyectos
llamadaProcesoUnificadode Rational (RUP,porsussiglaseninglés).Dicha
metodología,propone unaserie de prácticasparael desarrollode proyectosde
software basadoenfases,atravésde unaserie de disciplinasque nospermitiránir
generandoartefactosencadauna de las iteraciones.Estametodologíaescíclica,es

4.
decir,por cada ciclose generandocumentosentregables(artefactos) que nos
permitiránmedirel avance de nuestrosproyectos,inclusive desde lasetapas
iniciales.
El modelode casosde uso esuna ampliayaceptada técnicaque captura el
procesode negocioylos requerimientosde unproyectode desarrollode software.
Esta es labase para lasestimaciones,yaque contiene laespecificacióndetalladade
losactores ycasos de uso.
Técnicas de estimación
La estimacióndel costoydel esfuerzodel software nuncaseráunaciencia
exacta.Sondemasiadasvariables -humanas,técnicas,de entorno,políticas- que
puedenafectarel costofinal del software ydel esfuerzoaplicadoparadesarrollarlo.
Sinembargo,laestimacióndel proyectode software puede dejarde serunarte
obscuropara convertirse enunaserie de pasossistemáticosque proporcionen
estimacionesconungrado de riesgoaceptable.
Existendistintastécnicasde estimación,de lascualespodemosmencionar
brevementeal modeloCOCOMO,lospuntosde función,yporsupuesto,lospuntos
de casos de uso. Cada unade ellaspresentaunaserie de ventajasydesventajas,
perosu discusiónestáfueradel alcance de este trabajoynosenfocaremosa
estudiarprincipalmente los puntosde casosde uso.
Puntos de casos de uso
Este métodode estimaciónde proyectosde software fuedesarrolladoen1993
por GustavKarner de Rational Software y estábasadoenuna metodología
orientadaa objetos,dándole el nombre de “estimaciónde esfuerzosconcasosde
uso”.Surgiócomo una mejoraal métodode puntosde funciónperobasandolas
estimacionesenel modelode casosde uso,productodel análisisde requerimientos.
Segúnsuautor, la funcionalidadvistaporel usuario(modelode casosde uso) esla
base para estimarel tamañodel software.
El objetivode la técnica
Estimarlas horasnecesariasparaejecutarun conjuntode casosde uso. Es
decir,necesitamospredecircuántotiempollevaráel desarrollode software y

5.
cuántas personasse requierenpararealizarlo.Paraello,esnecesariocuantificarla
complejidaddelsistemayel tiemponecesarioparaproducirunaunidadde
complejidad.
Al inicio,el métododependede casosde usobienestructuradosybien
escritos,conun nivel conveniente de detalletextual.Al final,se pretende obtener
un númeroúnicoque caracterice completamente al sistemayque se correlacione
con la productividadobservadadel ingeniero.
METRICAS DISEÑO PARA WEBAPPS:
Las métricasdebenofrecerrespuestascuantitativasalassiguientespreguntas:
¿La interfazde usuario promueve lafacilidadde uso?
¿La estéticade laWebApp esapropiadapara el dominiode la aplicación y
confortable al uso?
¿El contenido estádiseñadoenunaformaque proporcionamayor
información con el menoresfuerzo?
¿La navegacióneseficiente ydirecta?
¿La arquitecturade la WebApp se ha diseñado paraacomodar lasmetas y
objetivos especiales de losusuarios de laWebApp la estructurade contenidoy
funcionalidadyel flujo de navegación requerido parausar el sistemade manera
efectiva?
¿Los componentesestán diseñadosenunaformaque reduce lacomplejidady
aumentalaexactitud,laconfiabilidadyel desempeño?
Hasta el momentonoexiste unconjuntode métricascuantitativasporloque estos
debensertratadosde manera cualitativa. El diseñowebabarcaactividadestécnicas
y otras que no loson.La visiónyel sentidodel contenidose desarrollancomoparte
del diseñográfico,laplantillaestéticade lainterfazde usuariose creacomo parte
de diseñode lainterfazyla estructuratécnicade la webappse modelacomo parte
del diseñoarquitectónico yde navegación. Lawebapps abarcaseisdiferentestipos
de diseñocadauno contribuye ala calidadglobal de lawebestose puede verpor
mediode lapirámide siguiente:

6.
Tecnología
Métricas de interfaz:
Para webappspuedenconsiderarselassiguientesmedidas:
 Correcciónde plantilla
 Tiempode reconocimiento
 Complejidadde selección
 Tiempode adquisiciónde contenido...Etc
Los principiosydirectricesesencialesdel diseñode unaWebAppse pueden
mencionar:
 Uso equitativo
 Flexibilidadenel uso
 Uso sencilloe intuitivo
 Informaciónperceptible
 Toleranciaal error
 Esfuerzofísicoreducid
 Tamaño y espacioparaacercarse y usar
Dis.
de
interf
az
Diseño estético
Diseño de contenido
Diseño de navegación
Diseño arquitectónico
Diseño de componente

7.
Métricas estéticas:
Se apoya enel juiciocualitativoyporlogeneral noessensible alamediciónni
a las métricas.
SinembargoIvorypropone unconjuntode medidasque puedenserútilespara
valorarel impactodel diseñoestético.
El diseñoestético,tambiénllamadodiseñográfico,esunesfuerzoartísticoque
complementalosaspectostécnicosde laingenieríaWeb.Sinél unaWebApppuede
serfuncional,perosinatractivo.
Métricas de contenido:
Se enfocaenla complejidaddel contenidoyenlosgruposde contenidoque
se organizanenpáginas.
El diseñode contenidose enfocaendosasuntosde diseñodiferentes,cada
unolo abordanindividuoscondistintosconjuntosde habilidades.El diseñode
contenidodesarrollaunarepresentaciónde diseñoparalosobjetosde contenidoy
representalosmecanismosque se requierenparaque establezcansusrelaciones
unocon otro.
MÉTRICAS DE NAVEGACIÓN
Abordanla complejidaddel flujo de navegación.
En general,sonútilessóloparaaplicacioneswebestáticas,que noincluyen
vínculosy páginasgeneradosde maneradinámica.
El diseñadordebe definirlasrutasde navegaciónque habilitenparalaruta de
losusuariosel accesoal contenidoylasfuncionesde lasWebApp.Paraellose debe:
Identificarlasemánticade navegaciónparadiferentesusuariosdel sitio
Definirlamecánicaque lograla navegación.
MÉTRICAS PARA LA CALIDAD DEL SOFTWARE
Las Métricas de Calidadproporcionanunaindicaciónde cómose ajusta
el software,alosrequerimientosimplícitosyexplícitosdel cliente.

8.
El objetivoprincipal de laingenieríadel softwareesproducirunproductode
alta calidad.Paralograr este objetivo,losingenierosdel software debenutilizar
medicionesque evalúenlacalidaddel análisisylosmodelosde desafío,el código
fuente,yloscasosde pruebaque se han creadoal aplicarla ingenieríadel software.
Para lograr estaevaluaciónde lacalidadentiemporeal,el ingenierodebeutilizar
medidastécnicasque evalúanlacalidadconobjetividad,noconsubjetividad.
El primerobjetivodel equipode proyectoesmedirerroresydefectos.Las
métricasque provienende estasmedidasproporcionanunaindicaciónde la
efectividadde lasactividadesde control yde la garantía de calidad.
Métricas de calidad de software se enfocan sobre el proceso, el proyecto y el
producto. Estas métricas las podemos dividir en dos grupos; el primer grupo se le
recolecta antes de la entrega del producto y las otras luego de haberlo entregado.
MEDIDAS DE LA CALIDAD
 Corrección:Es el grado enque el software desempeñalafunciónparalaque
fue creado. Su medida es nº de defectos por KLDC.
 Facilidad de Mantenimiento: es la facilidad para corregir un error, adaptar
un programa a cambios, o mejorarlo si el cliente desea un cambio. Su
medida es TMC (tiempo medio de cambio).
 Integridad:Esla capacidadpara resistirataques,provocados o no, contra su
seguridad, ya sea sobre programas, datos y documentos. Se la puede
definir como:
Integridad = (amenaza x (1 – seguridad))
 Amenaza: es la probabilidad de que un cierto tipo de ataque ocurra en un
tiempo dado,
 Seguridad: es la probabilidad de que se pueda contrarrestar un cierto tipo
de ataque.
 Facilidadde uso:Se refiere a Habilidad intelectual y/o física requerida para
aprender a utilizar el sistema; es decir, “amistad con el usuario”.
MODELO DE CALIDAD ( Gilb ).

9.
Este modelopresentacomoaspectofundamentalladefiniciónde losatributos
de calidadque realmente interesan al usuario y el nivel de calidad que debe tener
cada uno de ellos para satisfacerlo ya que no tiene sentido exigir calidad en un
producto, si no se cuenta con esta base. Cada atributo tiene subatributos que
ayudan a la medición de este. Estos atributos son:
 Capacidad de trabajo: Evalúa la capacidad natural del sistema para realizar
su trabajo.
 Subatributos:capacidaddel proceso,capacidad de respuesta, capacidad de
almacenamiento.
 Disponibilidad: Refleja la medida de la disponibilidad del sistema para
realizar de forma útil el trabajo para el que fue diseñado.
o Subatributos: fiabilidad, Mantenibilidad e integridad.
 Adaptabilidad: Es la medida de la capacidad de un sistema para ser
modificado de manera adecuada.
o Subatributos: improbabilidad, extensibilidad y transportabilidad.
 Utilizabilidad: Es la medida de la facilidad con que la gente será capaz y
estará motivada para utilizar el sistema en la práctica.
o Subatributos: requisitos de entrada, requisitos de aprendizaje y
habilidad de manejo.
Tabla 8. Factores y criterios del modelo ARTHUR
Factores Criterios
Corrección Completitud, Consistencia, Seguimiento
Fiabilidad Complejidad,Consistencia, Modularidad,
Preciso, Simplicidad, Tolerante a errores
Eficiencia Concisión, Eficiencia de ejecución,
Operatividad
Integridad Auditabilidad, Instrumentación,
Seguridad
Utilizable Entrenamiento, Operatividad
Mantenible Auto-documentado, Concisión,
Consistencia, Instrumentación,
Modularidad, Simplicidad
Flexible
Auto-documentado, Complejidad,
Concisión, Consistencia, Expansibilidad,
Generalidad, Modularidad, Simplicidad

10.
Verificable Auditabilidad, Auto-documentado,
Complejidad, Instrumentación,
Modularidad, Simplicidad
Portable Auto-documentado, Generalidad,
Independencia de la máquina,
Independencia del sistema software,
Modularidad
Reutilizable Auto-documentado, Generalidad,
Independencia del hardware,
Independencia del sistema software,
Modularidad
Inter-operativo
Comunicaciones comunes, Datos
comunes, Generalidad, Modularidad
Fuente: ALONSO SECADES, Vidal. La Gestión del Conocimiento
Mediante el Método Gilb es posible especificar los atributos de calidad de
software en forma cuantitativa, incluyendo tanto tiempos de respuesta como
conceptos conocidos de usabilidad y portabilidad, entre otros.
Gilb propone características como la corrección, la integridad, la facilidad de
mantenimientoylafacilidadde uso,comobase para proporcionarindicadoresútiles
para losequiposde trabajoy sugiere lasdefiniciones,puntosde vistay medida para
cada uno de las siguientes características:
 Corrección.Grado en el que el software lleva a cabo su función requerida.
Si un programa no opera correctamente, no dará valor agregado a sus
usuarios
 Facilidad de mantenimiento. Posibilidad de corregir un programa si se
encuentra un error, adaptarlo si cambia su entorno, mejorarlo si el cliente
desea un cambio
 Integridad.Habilidadde unsistemapararesistirataques,tantoaccidentales
como intencionados, contra su seguridad, a nivel de cualquiera de los tres
principales componentes del software: programas, datos y documentos.
Para medir la integridad, Gilb sugiere la utilización de otros dos atributos
como base:

11.
 Amenaza. es la probabilidad (que se puede estimar o
deducir de la evidencia empírica) de que un ataque de
cualquier tipo ocurra en un tiempo determinado
 Seguridad. es la probabilidad de que se pueda repeler un
determinado ataque
 Facilidad de uso. Es un intento por cuantificar “lo amigable que puede
ser el producto con el usuario” Las características se pueden medir
mediante varias subcaracterísticas o métricas detalladas. Para cada una
de ellas se debe especificar los siguientes conceptos:
 Nombre y definición de la característica
 Escala o unidades de medición
 Recolección de datos o prueba
 El valor previsto
 El valor óptimo
 El valorenel sistemaactual
EFICACIA EN LA ELIMINACIÓN DE DEFECTOS
Habilidad de filtrar las actividades de la garantía de cualidad; cuando se considera
como un proyecto se la define como:
EED = E / (E + D)
Donde, E = Error y D = Defecto; el valor ideal de la EED es 1.
La EED también se puede aplicar al proceso para valorar la habilidad de un
equipode encontrarerroresantesde que pase a la siguienteactividaddel marco de
trabajo. En este contexto se la define como:

12.
EEDi = Ei / (Ei + E(i + 1) )
Donde i representa una actividad e i + 1 representa la siguiente actividad
luego de i;