INSTITUTO TECNOLOGICO DE CIUDAD

ALTAMIRANO
TRAJO DE INVESTIGACION
UNIDAD 2
MATERIA: DESARROLLO E
IMPLEMENTACION DE SISTEMAS DE
INFORMACION

INTEGRANTES: ELVER GUTIERREZ GARCIA

Y
JOSE ORFANEL AGUIRRE SANTANA

NOMBRE DE LA FACILITADORA: YURI

MEDRANO NUEZ

TEMAS

2.4 DIAGRAMAS DE IMPLEMENTACIN

2.4.1 DEFINICIN
2.4.2 OBJETIVO
2.4.3 TIPOS
2.4.3.1 DIAGRAMA DE COMPONENTES
2.4.3.2 DIAGRAMA DE EJECUCIN
2.4.4 APLICACIONES
2.4.5 ADAPTACIONES DE UML
2.5 DISEO DE INTERFAZ DE USUARIO
2.5.1 INTERACCION HOMBRE MAQUINA
2.5.2 DISEO DE INTERFAZ HOMBRE MAQUINA
2.5.3 DIRECTRICES PARA EL DISEO DE INTERFACES
2.5.4 ESTANDARES DE INTERFAZ
2.6 DISEO DE LA BASE DE DATOS
2.6.1 OBJETIVOS
2.6.2 ALMACEN DE DATOS
2.7 MTRICAS DEL DISEO
2.7.1 FACTORES QUE AFECTAN
2.7.2 PRODUCTIVIDAD
2.7.3 MEDIDAS RELACIONADAS
2.7.3.1 TAMAO
2.7.3.2 FUNCION
2.7.3.3 PUNTOS DE OBJETO

2.7.4 METRICAS DE DISEO ARQUITECTONICO

2.7.5 METRICAS DE NIVEL DE COMPONENTES
2.7.6 METRICAS DE DISEO DE INTERFAZ

2.4 DIAGRAMAS DE IMPLEMENTACIN

2.4.1 DEFINICIN
Los diagramas de implementacin muestran las instancias existentes al ejecutarse
as como sus relaciones. Tambin se representan los nodos que identifican
recursos fsicos, tpicamente un ordenador as como interfaces y objetos
(instancias de las clases).
2.4.2 OBJETIVO

Muestran los aspectos de implementacin del modelo

Estructura del cdigo fuente y objeto

Estructura de la implementacin en ejecucin

2.4.3 TIPOS
Dos tipos de diagramas
2.4.3.1 DIAGRAMA DE COMPONENTES
Organizacin y dependencias entre los componentes software
Clases de implementacin
Artefactos binarios, ejecutables, ficheros de scripts
2.4.3.2 DIAGRAMA DE EJECUCIN
Configuracin de los elementos de proceso en tiempo de ejecucin y los
componentes software, procesos y objetos que viven en ellos
Distribucin de componentes
2.4.4 APLICACIONES
Visual Studio 2008
Los diagramas de implementacin evalan la implementacin de un sistema de
aplicaciones en un centro de datos lgico concreto. Existen dos maneras de crear
diagramas de implementacin. La primera es desde el Diseador de aplicaciones,
sin definir con anterioridad un sistema explcito. Los Diseadores de sistemas
distribuidos crean un sistema predeterminado mediante las definiciones de

aplicacin del diagrama de aplicaciones porque siempre se requiere que un

sistema describa una implementacin del sistema. La segunda opcin es crearlo
desde un sistema definido en el Diseador de sistemas.
Para crear un diagrama de implementacin desde el Diseador de aplicaciones
1.

En el Diseador de aplicaciones, elija Definir implementacin en el men

Diagrama.
Aparecer

el

cuadro

de

dilogo

Definir

implementacin.

Se

rellena

automticamente con el nombre de un diagrama de centros de datos lgicos, si

aparece uno en la solucin.
2.

Bajo Diagrama de centros de datos lgicos, elija un diagrama en la solucin

o haga clic en Examinar para buscar un diagrama (archivo .ldd) fuera de la

solucin.
3.

Haga clic en Aceptar.

Se abre el diagrama de implementacin en el Diseador de implementacin.

2.4.5 ADAPTACIONES DE UML
Existen dos tipos de metodologas: antiguas y recientes. Se entiende por
metodologa a la estructura y naturaleza de los pasos en un esfuerzo de
desarrollo. Pero antes de iniciar a programar los desarrolladores deben tener
claridad sobre el problema.
Mtodo antiguo
Las etapas deben suceder en lapsos definidos, una despus de otra. Obsrvese el
mtodo en cascada:
Este mtodo reduce el impacto de la comprensin obtenida en el proyecto. Si el
proceso no puede retroceder y volver a ver los primeros estados, es posible que
las ideas desarrolladas no sean utilizadas.
Mtodo reciente

Tiende a la colaboracin entre las fases de desarrollo esta moderna ingeniera de

programas, los analistas y diseadores hacen revisiones para desarrollar un slido
fundamento para los desarrolladores. Existe interaccin entre todo el equipo de
trabajo.
La ventaja es que conforme crece la comprensin, el equipo incorpora nuevas
ideas y genera un sistema ms confiable.
Lo que debe hacer un proceso de desarrollo
El equipo tiene que formarse de analistas para comunicarse con el cliente y
comprender el problema, diseadores para generar una solucin, programadores
para codificarla e ingenieros de sistemas para distribuirlas.
A su vez debe asegurar que sus fases no sean discontinuas.
GRAPPLE
Significa Guas para la Ingeniera de Aplicaciones Rpidas, tiene dentro de s una
condensacin de ideas de varias otras personas.
Consta de cinco segmentos en lugar de fases, cada segmento consta de diversas
acciones cada accin es responsabilidad de un jugador.
Los segmentos son: recopilacin, anlisis, diseo, desarrollo y distribucin. Lo que
otorga un acrnimo RADDD.
Recopilacin de necesidades
La funcin es comprender lo que desea el cliente.
Realice un anlisis del dominio
El objetivo es comprender de la mejor manera posible el dominio del cliente. El
analista debe acomodarse al cliente.
Descubra las necesidades del sistema
El equipo realiza su primera sesin de JAD (Desarrollo de conjunto de
aplicaciones).En dnde se rene a quienes toman las decisiones en la empresa

del cliente, a los usuarios potenciales y a los miembros de los equipos de

desarrollo.
Presentar los resultados al cliente
Cuando finaliza todas las acciones de Necesidades, el administrador de proyectos
presentar los resultados al cliente.
Anlisis
En este segmento aumenta la comprensin por parte del equipo. Se necesita
trabajar sobre: la comprensin del uso del sistema, hacer realidad de los casos de
uso, depurar los diagramas de clases, analizar cambios de estado en los objetos,
definir la comunicacin entre objetos, analizar la integracin con diagramas de
colaboraciones.
Diseo
El equipo trabajar con los resultados del segmento de Anlisis para disear la
solucin, en este punto se harn revisiones pertinentes hasta que el diseo se
haya completado. Contiene las siguientes fases: desarrollo y depuracin de
diagramas de componentes, desarrollo de diagramas de componentes, planeacin
para la distribucin, diseo y prototipos de la interfaz del usuario, pruebas de
diseo, iniciar la documentacin.
Desarrollo
De este segmento se encargan los programadores, debe realizarse con rapidez y
sin problemas.
Fases: generacin del cdigo, verificacin del cdigo, generacin de interfaces del
usuario y conexin con el cdigo, prueba, consumacin de la documentacin.
Distribucin
En este segmento se distribuye en el hardware adecuado y se integra con los
sistemas cooperativos.

Fases: planeacin para copias de seguridad y recuperacin, instalacin del

sistema terminado en el hardware adecuado, verificacin del sistema instalado,
celebracin.

2.5 DISEO DE INTERFAZ DE USUARIO

El diseo de interfaz de usuario o ingeniera de la interfaz es el diseo
de computadoras, aplicaciones, mquinas, dispositivos de comunicacin mvil,
aplicaciones de software, y sitios web enfocado en la experiencia de usuario y la
interaccin.
Normalmente es una actividad multidisciplinar que involucra a varias ramas es
decir al diseo y el conocimiento como el diseo grfico, industrial, web, de
software y la ergonoma; y est implicado en un amplio rango de proyectos, desde
sistemas para computadoras, vehculos hasta aviones comerciales.
Su objetivo es que las aplicaciones o los objetos sean ms atractivos y adems,
hacer que la interaccin con el usuario sea lo ms intuitiva posible, conocido como
el diseo centrado en el usuario. En este sentido las disciplinas del diseo
industrial y grfico se encargan de que la actividad a desarrollar se comunique y
aprenda lo ms rpidamente, a travs de recursos como la grfica, los
pictogramas, los estereotipos y la simbologa, todo sin afectar el funcionamiento
tcnico eficiente.
2.5.1 INTERACCION HOMBRE MAQUINA
Todava no hay una definicin concreta para el conjunto de conceptos que forman
el rea de la interaccin persona-computador. En trminos generales, podramos
decir

que

es

la

disciplina

que

estudia

el intercambio

de

informacin mediante software entre las personas y las computadoras. Esta se

encarga del diseo, evaluacin e implementacin de los aparatos tecnolgicos
interactivos, estudiando el mayor nmero de casos que les pueda llegar a afectar.
El objetivo es que el intercambio sea ms eficiente: minimizar errores, incrementar
la satisfaccin, disminuir la frustracin y, en definitiva, hacer ms productivas las
tareas que rodean a las personas y los computadores.
Aunque la investigacin en este campo es muy complicada, la recompensa una
vez conseguido el objetivo de bsqueda es muy gratificante. Es muy importante
disear sistemas que sean efectivos, eficientes, sencillos y amenos a la hora de

utilizarlos, dado que la sociedad disfrutar de estos avances. La dificultad viene

dada por una serie de restricciones y por el hecho de que en ocasiones se tienen
que hacer algunos sacrificios. La recompensa sera: la creacin de libreras
digitales donde los estudiantes pueden encontrar manuscritos medievales virtuales
de hace centenares de aos; los utensilios utilizados en el campo de la medicina,
como uno que permita a un equipo de cirujanos conceptualizar, alojar y monitorizar
una compleja operacin neurolgica; los mundos virtuales para el entretenimiento
y la interaccin social, servicios del gobierno eficientes y receptivos, que podran ir
desde renovar licencias en lnea hasta el anlisis de un testigo parlamentario; o
bien telfonos inteligentes que saben dnde estn y cuentan con la capacidad de
entender ciertas frases en un idioma. Los diseadores crean una interaccin con
mundos virtuales integrndolos con el mundo fsico.
2.5.2 DISEO DE INTERFAZ HOMBRE MAQUINA
La sigla HMI es la abreviacin en ingles de Interfaz Hombre Maquina. Los
sistemas HMI podemos pensarlos como una ventana de un proceso. Esta ventana
puede estar en dispositivos especiales como paneles de operador o en
computadora. Los sistemas HMI en computadoras se les conoce tambin como
software HMI o de monitoreo y control de supervisin. Las seales del proceso
son conocidas al HMI por medio de dispositivos como tarjetas de entrada / salida
en la computadoras, PLCs (controladores lgicos programables), RTU (unidades
remotas I/O) o DRIVEs (variadores de velocidad de motores). Todos estos
dispositivos deben tener una comunicacin que entienda el HMI.
2.5.3 DIRECTRICES PARA EL DISEO DE INTERFACES

No forzar al usuario a leer grandes cantidades de texto, ya que la lectura

en un monitor de un computador es, aproximadamente, un 25% ms
lenta que la lectura en papel.

Evitar

los

llamados

iconos

under

construction,

pues

causan

expectacin y pueden decepcionar al usuario si el resultado final no es

el esperado.

La informacin importante debe colocarse dentro de las dimensiones

tpicas de la ventana del navegador, ya que los usuarios prefieren no
desplazarse sobre la ventana.

Los mens de navegacin y las barras de cabecera de las pginas Web

deben ser consistentes y aparecer en todas las pginas que se le
muestrean al usuario.

La esttica nunca debe sustituir a la funcionalidad.

2.5.4 ESTANDARES DE INTERFAZ

Muchas aplicaciones web obvian algunos de los principios de los que hablaremos,
y dichos principios no cambian aunque sea una aplicacin web, todo lo contrario,
respetarlos puede llegar a ser an ms importante y necesario.
Las interfaces grficas efectivas son visualmente comprensibles y permiten
errores por parte del usuario, dndole una sensacin de control. Los usuarios ven
rpidamente el alcance de las opciones y comprenden como obtener sus metas y
realizar su trabajo.
Dichas interfaces ocultan al usuario el funcionamiento interno del sistema. El
trabajo se va guardando constantemente brindando una opcin de deshacer en
todo momento cualquier accin que se haya hecho. Las aplicaciones y servicios
efectivos realizan el mximo trabajo requiriendo la mnima informacin del usuario.
Anticiparse.
Una buena aplicacin intentar anticiparse a las necesidades y deseos de los
usuarios. No esperes que el usuario busque o recuerde informacin o
herramientas. Muestra al usuario toda la informacin y herramientas necesarias
para cada etapa en su trabajo.
Autonoma.
El ordenador, la interfaz y el entorno de la tarea pertenecen al usuario, pero no
podemos abandonarlo.

Ante una interface, al usuario hay que darle cuerda para que investigue y sienta
que tiene el control del sistema. No obstante, hay que tener en cuenta que los
adultos nos sentimos ms cmodos en un entorno que no sea ni muy restrictivo, ni
demasiado grande, un entorno explorable pero no peligroso.
Mantn informado al usuario del estado del sistema.
No existe autonoma en ausencia de control; y el control no se puede tener sin
informacin suficiente. Comunicar el estado es fundamental para que el usuario
responda apropiadamente con la informacin disponible.
Ejemplo: los trabajadores sin informacin del estado del sistema, tienden a
mantenerse bajo presin durante cortos periodos de tiempo hasta que el trabajo
se termina. Un estrs y fatiga innecesarios por lo que cuando venga la siguiente
carga de trabajo, puede que los trabajadores no estn en las mejores condiciones
fsicas y mentales.
Los usuarios no tienen que buscar la informacin de estado. De un vistazo
deberan ser capaces de hacerse una idea aproximada del estado del sistema. La
informacin de estado pude ser bastante sutil: el icono de la bandeja de entrada
puede mostrarse vaca, media llena o hasta los topes, por ejemplo. Sin embargo,
no es conveniente abusar: En Mac se utiliz durante aos un icono de la papelera
que pareca que iba a estallar en cualquier momento, aunque slo tuviese un
documento. Los usuarios adquirieron la costumbre de vaciar la papelera apenas
contuviese un documento, convirtieron un proceso de un paso en uno de dos
(primero llevamos el documento a la papelera, luego lo vaciamos). Esto tuvo el
efecto negativo de reducir una de las funciones bsicas de la papelera: la
posibilidad de deshacer la accin.

2.6 DISEO DE LA BASE DE DATOS

Son muchas las consideraciones a tomar en cuenta al momento de hacer el
diseo de la base de datos, quizs las ms fuertes sean:

La velocidad de acceso.

El tamao de la informacin.

El tipo de la informacin.

Facilidad de acceso a la informacin.

Facilidad para extraer la informacin requerida.

El comportamiento del manejador de bases de datos con cada tipo de

informacin.

No obstante que pueden desarrollarse sistemas de procesamiento de archivo e

incluso manejadores de bases de datos basndose en la experiencia del equipo
de desarrollo de software logrando resultados altamente aceptables, siempre es
recomendable la utilizacin de determinados estndares de diseo que garantizan
el nivel de eficiencia ms alto en lo que se refiere a almacenamiento y
recuperacin de la informacin.
De igual manera se obtiene modelos que optimizan el aprovechamiento
secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse
al usuario.
El proceso de diseo de una base de datos se gua por algunos principios. El
primero de ellos es que se debe evitar la informacin duplicada o, lo que es lo
mismo, los datos redundantes, porque malgastan el espacio y aumentan la
probabilidad de que se produzcan errores e incoherencias. El segundo principio es
que es importante que la informacin sea correcta y completa. Si la base de datos
contiene informacin incorrecta, los informes que recogen informacin de la base

de datos contendrn tambin informacin incorrecta y, por tanto, las decisiones

que tome a partir de esos informes estarn mal fundamentadas.

2.6.1 OBJETIVOS
Un buen diseo de base de datos es, por tanto, aqul que:
Divide la informacin en tablas basadas en temas para reducir los datos
redundantes.
Proporciona a Access la informacin necesaria para reunir la informacin de las
tablas cuando as se precise.
Ayuda a garantizar la exactitud e integridad de la informacin.
Satisface las necesidades de procesamiento de los datos y de generacin de
informes.

El proceso de diseo consta de los pasos siguientes:

Determinar la finalidad de la base de datos:
Esto le ayudar a estar preparado para los dems pasos.
Buscar y organizar la informacin necesaria:
Rena todos los tipos de informacin que desee registrar en la base de datos,
como los nombres de productos o los nmeros de pedidos.
Dividir la informacin en tablas:
Divida los elementos de informacin en entidades o temas principales, como
Productos o Pedidos. Cada tema pasar a ser una tabla.
Convertir los elementos de informacin en columnas:
Decida qu informacin desea almacenar en cada tabla. Cada elemento se
convertir en un campo y se mostrar como una columna en la tabla. Por ejemplo,

una tabla Empleados podra incluir campos como Apellido y Fecha de

contratacin.

Especificar claves principales:

Elija la clave principal de cada tabla. La clave principal es una columna que se
utiliza para identificar inequvocamente cada fila, como Id. de producto o Id. de
pedido.
Definir relaciones entre las tablas:
Examine cada tabla y decida cmo se relacionan los datos de una tabla con las
dems tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las
relaciones segn sea necesario.

Ajustar el diseo:
Analice el diseo para detectar errores. Cree las tablas y agregue algunos
registros con datos de ejemplo. Compruebe si puede obtener los resultados
previstos de las tablas. Realice los ajustes necesarios en el diseo.

Aplicar las reglas de normalizacin:

Aplique reglas de normalizacin de los datos para comprobar si las tablas estn
estructuradas correctamente. Realice los ajustes necesarios en las tablas.

2.6.2 ALMACEN DE DATOS

Los Almacenes de Datos son repositorios diseador para facilitar la confeccin de
los informes y la realizacin de anlisis; tal como ocurre con las bases de datos,
pueden ser completamente separados del sistema de informacin principal; lo cual

significa una ganancia enorme en el rendimiento de los sistemas cuando se

ejecuten las consultas.

El Procesamiento de Transacciones Online, usado normalmente por aplicaciones

orientadas a la transaccin como pueda ser vtiger CRM, no han sido construidas
teniendo en cuenta la creacin de bases de datos segregadas, y los potenciales
anlisis que puedan realizarse se hacen sobre los mismos datos usados por la
aplicacin, y tampoco han sido diseadas para situaciones donde la cantidad de
datos a ser analizados es considerable.

Modelo de Datos usado en OLTP (OnlineTransaction Processing).

Los Almacenes de datos (Datawarehouses) usados en OLAP (Analytical

Processing) utilizan un modelo de datos denominado multidimensional.

La topologa tpica usada para construir un almacn de datos se denomina

"modelo en forma de estrella": La tabla central se llama "tabla de hechos" y
referencia un nmero de "dimensiones" (que son las tablas que estn alrededor).
Usando este mtodo es posible producir informes que incluyan informacin tal
como, por ejemplo, la cantidad de procesador producidos en el segundo
cuatrimestre del 2006. Por esta razn se construyen (hiper)cubos, y mediante este
modelo de datos desde diferentes dimensiones (potencialmente todas variables)
pueden ser enlazadas todas juntas.

Modelo en forma de estrella usado en OLAP

Cubo OLAP con Tiempo, Cliente y Producto como dimensiones.

Finalmente indicar que los almacenes de datos crean versiones de la informacin
con el objeto de conservar "informacin histrica" en un intento de dar coherencia
a los informes a lo largo del tiempo. Por ejemplo, si el nombre de una cuenta
(cliente) cambia, el sistema BI crear una nueva versin marcada con un nueva
marca de tiempo de forma que las entidades que existan antes del cambio sigan
estando relacionadas con la misma cuenta mientras que las nuevas entidades que
se vayan a crear a partir de ahora se relacionen con la nueva versin.

Para este proyecto vtiger CRM - BI hemos construido un almacn de datos capaz
de almacenar toda la informacin contenida dentro de un vtiger CRM en
produccin. Todas las entidades del sistema son almacenadas como tablas de
dimensiones y versionadas segn una serie de decisiones tomadas durante el
anlisis realizado. Por ejemplo, la cuenta ha sido versionada cada vez que la
ciudad, pas, provincia, cdigo postal, direccin, miembro de, correo y el campo
"asignado a" sean modificados.
Hemos creado las siguientes tablas de hechos:

Ventas (que pueden ser estudiadas por Factura o Lneas de factura)

Incidencias post-venta (HelpDesk)

Campaas

Potenciales

Tarifas

En la tabla de hechos de Ventas hemos aadido clculos especficos para obtener

informacin importante sobre beneficios y rentabilidades:

Cantidad: nmero de unidades en cada lnea

Precio unitario: precio de cada unidad en la lnea

Beneficio bruto por lnea

Descuento en lnea de venda por promociones. Aunque esto pueda ser

reflejado en vtiger CRM con las tarifas, no podemos saber si se ha aplicado
una tarifa en una lnea determinada ya que vtiger CRM no guarda esta
informacin (siempre ser cero).

Detalle de descuento por lnea

Margen neto por lnea

Coste interno de la lnea para la empresa.

Beneficio total de la venta.

Impuestos aplicados.

Una vez creado el almacn de datos, necesitamos crear los procesos ETL
(Extract-Transform-Load) que peridicamente extraern la informacin desde el
vtiger CRM en produccin y cargarn con ella el Almacn de Datos, para ser
usado por las diversas herramientas de confeccin de informes (reporting) y
anlisis disponibles. El procedimiento esencial se muestra en la imagen siguiente:

Como puede verse, el almacn de datos refleja la lgica del negocio y debe ser
construida para adaptarse perfectamente a esta lgica. As pues, ser necesario
realizar cuantas adaptaciones sean necesarias, al almacn y al resto de procesos,
para conseguir esto y por consiguiente el mximo beneficio y aprovechamiento de
la herramienta BI.

2.7 MTRICAS DEL DISEO

Como ya se ha visto por las distintas mtricas estudiadas, la complejidad de un
programa crece con su tamao: los programas largos son ms difciles de
escribir y comprender, contienen habitualmente ms errores, y su depuracin
resulta ms compleja. Con objeto de reducir esta complejidad, los diseadores de
software han hecho un uso progresivo de tcnicas de modularizacin y diseo
estructurado. Entre las diversas ventajas de las tcnicas de diseo se
pueden destacar las siguientes:

Comprensibilidad:

programadores

usuarios

pueden

comprender

fcilmente la lgica del programa.

Manejabilidad: los gestores pueden asignar fcilmente personal y

recursos a los distintos mdulos representados por tareas.

Eficiencia: el esfuerzo de implementacin puede reducirse.

Reduccin de errores: los planes de prueba se simplifican notablemente.

Reduccin

favorece

que

del esfuerzo de mantenimiento: la divisin en mdulos

las

distintas

funciones

las

lleven

cabo

mdulos

diferenciados.
Aunque estos beneficios tambin son discutidos y para ello se alega toda clase de
inconvenientes, en general se admite que el paso a la modularidad es un gran
salto adelante. Pero el problema que se plantea ahora se refiere a los mdulos en
si: Cul es el tamao idneo, la complejidad mxima, la extensin adecuada de
un mdulo?
Algunas de las mtricas vistas hasta el momento tratan este problema. As
algunos autores estiman que el tamao de un mdulo debe oscilar entre las 50200 lneas de cdigo. Otros simplemente indican que un mdulo debe completar
una funcin por s solo. La complejidad lmite de un mdulo se fija en algunos
casos en un nmero de complejidad ciclomtica igual a 10.

Otras discusiones se centran en la organizacin de los mdulos en el

programa: estructuras en rbol, o lineales. Con objeto de obtener una valoracin
de los mdulos y una disposicin que pueda emplearse como base para
comparaciones, surgen las mtricas orientadas al diseo.
Muchas de estas mtricas son generalizaciones de otras referidas a mbitos ms
restringidos (nmeros de complejidad ciclomtica, mtricas de la ciencia del
software,...)
Uno de los estudios ms completos relativos a la cuestin de valorar los mdulos
software es el llevado a cabo por Troy y Zweben en el que se relaciona una serie
de mtricas bsicas con valores de calidad representados por la tasa de
modificaciones en pruebas.
En este estudio, un gran sistema fue dividido en mdulos usando varias
convenciones de diseo. Cada mdulo se codific, prob y prepar para la
integracin. Se registraron los cambios realizados en cada mdulo. Cada
implementacin de diseo se acompa de un grfico que representaba las
interconexiones entre los mdulos. En total se obtuvieron veintiuna mtricas
asociadas a cada grfico.
Los principios que dirigen estas mtricas son:

Acoplamiento:

Se mide como el nmero de interconexiones

entre

mdulos. El acoplamiento crece con el nmero de llamadas, o con la cantidad de

datos compartidos. Se supone que un diseo con un acoplamiento alto
puede contener ms errores. Se cuantifica como el nmero de conexiones por
nodo del grfico de diseo.

Cohesin: Valora las relaciones entre los elementos de un mdulo. En un

diseo cohesivo, las funciones estn ubicadas en un solo mdulo. Los diseos
con una cohesin baja contendrn ms errores. Las medidas que valoren

la

informacin compartida entre mdulos cuantificarn la cohesin.

Complejidad: Un diseo debe ser lo ms simple posible. La complejidad

crece con el nmero de construcciones de control, y el nmero de mdulos

de un programa. Un diseo complejo contendr ms errores. La complejidad se

evidencia en el nmero de elementos del grfico de diseo.

Modularidad: El grado de modularidad afecta a la calidad del diseo. Es

preferible un exceso a un defecto de modularidad, pues en este ltimo caso

contendr

ms

errores.

La cuantificacin

de la modularidad

se obtiene

midiendo la cantidad de elementos del grfico.

Tamao: Un diseo con grandes mdulos, o gran profundidad en su grfico

contendr ms errores. De hecho, complejidad y tamao estn muy relacionados y

las consecuencias de un exceso de cualquiera de los dos principios tienen los
mismos resultados.
Las conclusiones finales del estudio sugieren que a pesar de la correlacin
encontrada entre los factores estudiados y los errores encontrados, sigue
habiendo una serie de factores
calidad de un diseo.
interconexiones

De

no detectados que determinan

todas

formas

es

posible

a su vez la

afirmar

que

las

entre mdulos, y la complejidad de los diseos aumentan

notablemente los errores, y disminuyen la calidad.

Otras mtricas del software.
Adems de las mencionadas, existen algunas otras mtricas que valoran ciertos
aspectos del software.
Las mtricas de reusabilidad tratan de medir el grado en que un elemento software
puede ser empleado por otros programas, en otras palabras, su independencia.
Debido a que es difcil valorar objetivamente esta independencia, la referencia
ms comn es la independencia del hardware expresada en nmero de cambios
en el cdigo al adaptar un programa a una nueva plataforma. Esta medida puede
ampliarse al nmero de cambios realizados en el cdigo por lneas al adaptarlo a
un nuevo sistema operativo, o a un nuevo sistema grfico. Las mtricas de
portabilidad valoran aspectos muy similares.

Las mtricas de mantenibilidad se enuncian como funcin de los valores de

concisin, consistencia, instrumentacin, modularidad, auto documentacin y
simplicidad.
Las mtricas de testeabilidad (o capacidad de probar el software) son
funcin de la auditabilidad (capacidad de someter el software a auditora), la
complejidad de software (ciclomtica, contando los GOTO y bucles, o segn los
valores

de

la

Ciencia

del

Software),

instrumentacin,

modularidad,

autodocumentacin y simplicidad.
Las de flexibilidad tienen como componentes a la complejidad, la concisin,
la consistencia, la expandibilidad, la generalidad, la autodocumentacin, y la
simplicidad.
La interpretacin

que se da de los componentes de cada una de estas mtricas

es, no obstante, discutible e imprecisa, sin un mtodo definido para obtener

una valoracin. Tambin se carece de expresiones que determinen el peso que
cada componente tiene en la mtrica.
2.7.1 FACTORES QUE AFECTAN
McCall y Cavano [John A. McDermid 91 definieron un juego de factores de calidad
como los primeros pasos hacia el desarrollo de mtricas de la calidad del software.
Estos factores evalan el software desde tres puntos de vista distintos:
(1) Operacin del producto (utilizndolo),
(2) revisin del producto (cambindolo) y
(3) transicin del producto (modificndolo para que funcione en un entorno
diferente, por ejemplo: portndolo) Los autores describen la relacin entre estos
factores de calidad (lo que llaman un marco de trabajo) y otros aspectos del
proceso de ingeniera del software:
En primer lugar el marco de trabajo proporciona al administrador identificar en el
proyecto lo que considera importante, como: facilidad de mantenimiento y
transportabilidad, atributos del software, adems de su correccin y rendimiento

funcional teniendo un impacto significativo en el costo del ciclo de vida. En

segundo lugar, proporciona un medio de evaluar cuantitativamente el progreso en
el desarrollo de software teniendo relacin con los objetivos de calidad
establecidos. En tercer lugar, proporciona ms interaccin del personal de calidad,
en el esfuerzo de desarrollo. Por ltimo, el personal de calidad puede utilizar
indicaciones de calidad que se establecieron como pobres para ayudar a
identificar estndares mejores para verificar en el futuro. Es importante destacar
que casi todos los aspectos del clculo han sufrido cambios radicales con el paso
de los aos desde que McCall y Cavano hicieron su trabajo, teniendo gran
influencia, en 1978. Pero los atributos que proporcionan una indicacin de la
calidad del software siguen siendo los mismos. Si una

63 organizacin de

software adopta un juego de factores de calidad como una lista de comprobacin

para evaluar la calidad del software, es probable que el software construido hoy
siga exhibiendo la buena calidad dentro de las primeras dcadas del siglo XXI.
Incluso, cuando las arquitecturas del clculo sufran cambios radicales (como
seguramente ocurrir), el software que exhibe alta calidad en operacin, transicin
y revisin continuar sirviendo a sus usuarios.

2.7.2 PRODUCTIVIDAD
En el terreno de las metodologas de desarrollo de software, se aprecia una
necesaria mejora en la puesta en prctica de dichas metodologas de desarrollo,
as como la flexibilizacin de stas para potenciar la productividad de las mismas
sin renunciar a la calidad de los mismos.
Por esta razn se hace cada vez ms necesario disponer de herramientas
efectivas para aumentar la productividad, no solo desde un punto de vista terico
sino especialmente en la puesta en prctica de dichas metodologas, consiguiendo
que su despliegue impacte positivamente en el negocio de la empresa.
La mejora de la efectividad y la productividad en el desarrollo de software est
ligada a la utilizacin de buenas prcticas de Ingeniera de Software. En la
actualidad es indiscutible que el uso de una metodologa apropiada es un factor

clave para el xito de cualquier esfuerzo de ingeniera y tambin debera ser-lo en

la ingeniera del software. La ingeniera de software, por su relativa juventud como
disciplina y por la altsima variabilidad de los productos que gestiona, pocas
organizaciones que desarrollen software utilizan metodologas de forma
sistemtica, aunque esta tendencia est cambiando da a da.
La Ingeniera de Procesos contribuye en esta lnea, diseando y construyendo
metodologas en funcin de las necesidades especficas de cada organizacin. De
este modo, de la misma forma que las metodologas deben responder a
multiplicidad de estndares, tambin deben adaptarse a las caractersticas
particulares de cada uno de los proyectos que se llevan a cabo en la organizacin.
La complejidad del proceso hace imprescindible que una gran parte de las
actividades del desarrollo de software se automatice.
Los modelos y las metodologas basadas en modelos son la herramienta para
abstraer de los detalles irrelevantes en un determinado contexto y poder razonar
sobre el sistema a construir. Los modelos estn demostrando ser una herramienta
de productividad, acercando los modelos a los expertos del dominio de aplicacin.
Este enfoque permite separar los modelos que describen la solucin al problema
en trminos de negocio, de los modelos que describen la implementacin en
trminos de la plataforma software. Esta arquitectura de solucin separa los
aspectos del negocio de la tecnologa de implementacin facilitando que ambos
evolucionen independientemente uno de otro y posibilitando verdaderas factoras
de software estructuradas por dominio de aplicacin y por tecnologa de
implementacin.
2.7.3 MEDIDAS RELACIONADAS
Aunque hay muchas medidas de la calidad de software, la correccin, facilidad de
mantenimiento, integridad y facilidad de uso suministran indicadores tiles para el
equipo del proyecto. Gilb [Len O. Ejiogo 90] sugiere definiciones y medidas para
cada uno de ellos, tales como:
Correccin: A un programa le corresponde operar correctamente o suministrar
poco valor a sus usuarios. La correccin es el grado en el que el software lleva a

cabo una funcin requerida. La medida ms comn de correccin son los defectos
por KLDC, en donde un defecto se define como una falla verificada de
conformidad con los requisitos. Facilidad de mantenimiento. El mantenimiento del
software cuenta con ms esfuerzo que cualquier otra actividad de ingeniera del
software. La facilidad de mantenimiento es la habilidad con la que se puede
corregir un programa si se encuentra un error, se puede adaptar si su entorno
cambia o optimizar si el cliente desea un cambio de requisitos. No hay forma de
medir directamente la facilidad de 64mantenimiento; por consiguiente, se deben
utilizar medidas indirectas. Una mtrica orientada al tiempo simple es el tiempo
medio de cambio (TMC), es decir, el tiempo que se tarda en analizar la peticin de
cambio, en disear una modificacin apropiada, en efectuar el cambio, en probarlo
y en distribuir el cambio a todos los usuarios. En promedio, los programas que son
ms fciles de mantener tendrn un TMC ms bajo (para tipos equivalentes de
cambios) que los programas que son ms difciles de mantener. Hitachi ha
empleado una mtrica orientada al costo (precio) para la capacidad de
mantenimiento, llamada desperdicios. El costo estar en corregir

defectos

hallados despus de haber distribuido el software a sus usuarios finales.

Cuando la proporcin de desperdicios en el costo global del proyecto se simboliza
como una funcin del tiempo, es aqu donde el administrador logra determinar si la
facilidad de mantenimiento del software producido por una organizacin de
desarrollo est mejorando y asimismo se pueden emprender acciones a partir de
las conclusiones obtenidas de esa informacin. Integridad En esta poca de
intrusos informticos y de virus, la integridad del software ha llegado a tener
mucha importancia. Este atributo mide la habilidad de un sistema para soportar
ataques (tanto accidentales como intencionados) contra su seguridad. El ataque
se puede ejecutar en cualquiera de los tres componentes del software, ya sea en
los programas, datos o documentos.

Para medir la integridad, se tienen que

definir dos atributos adicionales: amenaza y seguridad. La amenaza es la

probabilidad (que se logra evaluar o concluir de la evidencia emprica) de que un
ataque de un tipo establecido ocurra en un tiempo establecido. La seguridad es la

probabilidad (que se puede estimar o 65 deducir de la evidencia emprica) de que

se pueda repeler el ataque de un tipo

establecido, en donde la integridad del

sistema se puede especificar como: integridad = [1- amenaza x (1- seguridad

donde se suman la amenaza y la seguridad para cada tipo de ataque.
Facilidad de uso. El calificativo amigable con el usuario se ha transformado
universalmente en disputas sobre productos de software. Si un programa no es
amigable con el usuario, prcticamente est prximo al fracaso, incluso aunque
las funciones que realice sean valiosas. La facilidad de uso es un intento de
cuantificar lo amigable que pude ser con el usuario y se consigue medir en
funcin de cuatro caractersticas:

(1) destreza intelectual y/o fsica solicitada para aprender el sistema;

(2) el tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del
sistema;
(3) aumento neto en productividad (sobre el enfoque que el sistema reemplaza)
medida cuando alguien emplea el sistema moderadamente y eficientemente, y (4)
valoracin subjetiva (a veces obtenida mediante un cuestionario) de la disposicin
de los usuarios hacia el sistema.
Los cuatro factores anteriores son slo un ejemplo de todos los que se han
propuesto como medidas de la calidad del software.
Medidas de fiabilidad y de disponibilidad. Los trabajos iniciales sobre fiabilidad
buscaron extrapolar las matemticas de la teora de fiabilidad del hardware a la
prediccin de la fiabilidad del software. La mayora de los modelos de fiabilidad
relativos al hardware van ms orientados a los fallos debidos al desajuste, que a
los fallos debidos a defectos de diseo, ya que son ms probables debido al
desgaste fsico (p. ej.: el efecto de la temperatura, del deterioro, y los golpes) que
los fallos relativos al diseo. Desgraciadamente, para el software lo que ocurre es
lo contrario. De hecho, todos los fallos del software, se producen por problemas de

diseo o de implementacin. Considerando un sistema basado en computadora,

una medida sencilla de la fiabilidad es el tiempo medio entre fallos (TMEF)
[Mayrhauser91], donde:
TMEF = TMDF+TMDR (4.2)
(TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparacin)).
Muchos investigadores argumentan que el TMDF es con mucho, una medida ms
til que los defectos/KLDC, simplemente porque el usuario final se enfrenta a los
fallos, no al nmero total de errores. Como cada error de un programa no tiene la
misma tasa de fallo, la cuenta total de errores no es una buena indicacin de la
fiabilidad de un sistema. Por ejemplo, consideremos un programa que ha estado
funcionando durante 14 meses. Muchos de los errores del programa pueden pasar
desapercibidos durante dcadas antes de que se 67 detecten. El TMEF de esos
errores puede ser de 50 e incluso de 100 aos. Otros errores, aunque no se hayan
descubierto an, pueden tener una tasa de fallo de 18 24 meses, incluso aunque
se eliminen todos los errores de la primera categora (los que tienen un gran
TMEF), el impacto sobre la fiabilidad del software ser muy escaso.
Adems de una medida de la fiabilidad debemos obtener una medida de la
disponibilidad. La disponibilidad (4.1.3.2) del software es la probabilidad de que un
programa funcione de acuerdo con los requisitos en un momento dado, y se define
como:
Disponibilidad = TMDF/(TMDF + TMDR) x 100 % (4.3)
La medida de fiabilidad TMEF es igualmente sensible al TMDF que al TMDR. La
medida de disponibilidad es algo ms sensible al TMDR ya que es una medida
indirecta de la facilidad de mantenimiento del software.

2.7.3.1 TAMAO
El proceso a seguir para realizar desarrollo orientado a objetos es complejo,
debido a la complejidad que nos vamos a encontrar al intentar desarrollar
cualquier sistema software de tamao medio-alto. El proceso est formado por
una serie de actividades y subactividades, cuya realizacin se va repitiendo en el
tiempo aplicado a distintos elementos.
En este apartado se va a presentar una visin general para poder tener una idea
del proceso a alto nivel, y ms adelante se vern los pasos que componen cada
fase.
Las tres fases al nivel ms alto son las siguientes:
Planificacin y Especificacin de Requisitos: Planificacin, definicin de
requisitos, construccin de prototipos, etc. 26 IV.1 Proceso de Desarrollo
Desarrollo Orientado a Objetos con UML Xavier Ferr Grau, Mara Isabel Snchez
Segura
Construccin: La construccin del sistema. Las fases dentro de esta etapa son
las siguientes:
- Anlisis: Se analiza el problema a resolver desde la perspectiva de los usuarios y
de las entidades externas que van a solicitar servicios al sistema.
- Diseo: El sistema se especifica en detalle, describiendo cmo va a funcionar
internamente para satisfacer lo especificado en el anlisis.
- Implementacin: Se lleva lo especificado en el diseo a un lenguaje de
programacin.
- Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software
funciona correctamente y que satisface lo especificado en la etapa de Planificacin
y Especificacin de Requisitos.
Instalacin: La puesta en marcha del sistema en el entorno previsto de uso.

De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo

y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un
enfoque iterativo, tomando en cada iteracin un subconjunto de los requisitos
(agrupados segn casos de uso) y llevndolo a travs del anlisis y diseo hasta
la implementacin y pruebas, tal y como se muestra en la
El sistema va creciendo incrementalmente en cada ciclo.
Con esta aproximacin se consigue disminuir el grado de complejidad que se trata
en cada ciclo, y se tiene pronto en el proceso una parte del sistema funcionando
que se puede contrastar con el usuario/cliente.
2.7.3.2 FUNCION
Hewlett-Packard ha desarrollado un conjunto de factores de calidad de software al
que se le ha dado el acrnimo de FURPS:
- Funcionalidad. Se aprecia evaluando el conjunto de caractersticas y
capacidades del programa, la generalidad de las funciones entregadas y la
seguridad del sistema global.
- Usabilidad (facilidad de empleo o uso) Se valora considerando factores
humanos, la esttica, consistencia y documentacin general.
- Fiabilidad. Se evala midiendo la frecuencia y gravedad de los fallos, la exactitud
de las salidas (resultados), el tiempo medio entre fallos (TMEF), la capacidad de
recuperacin de un fallo y la capacidad de prediccin del programa.
- Rendimiento. Se mide por la velocidad de procesamiento, el tiempo de
respuesta, consumo de recursos, rendimiento efectivo total y eficacia. 75
- Capacidad de soporte. Combina la capacidad de ampliar el programa
(extensibilidad), adaptabilidad y servicios (los tres representan mantenimiento),
as

como

capacidad

de

hacer

pruebas,

compatibilidad,

capacidad

de

configuracin, la facilidad de instalacin de un sistema y la facilidad con que se

pueden localizar los problema

2.7.3.3 PUNTOS DE OBJETO

Para conocer Puntos funcin, No ajustados y factor de complejidad.
Es necesario detectar ciertos parmetros:
-Entradas externas: Se cuenta cada entrada de usuario que proporciona diferentes
datos orientados a la aplicacin. Las entradas se deberan diferenciar de las
peticiones, las cuales se cuentan de forma separada.
-Salidas externas: Se cuenta cada salida que proporciona al usuario informacin
orientada a la aplicacin. En este contexto la salida se refiere a informes,
pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de
un informe no se cuentan de forma separada.
-Archivos lgicos. Se cuenta cada archivo maestro lgico (esto es, un grupo lgico
de datos que puede ser una parte de una gran base de datos o un archivo
independiente).
-Archivos externos de interface. Una peticin se define como una entrada
interactiva que produce la generacin de alguna respuesta del software inmediata
en forma de salida interactiva. Se cuenta cada peticin por separado.
-Consultas externas. Se cuentan todas las interfaces legibles por la mquina (por
ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir
informacin a otro sistema.
2.7.4 METRICAS DE DISEO ARQUITECTONICO
El diseo de ms alto nivel tambin es llamado: diseo general, arquitectnico o
conceptual. Tambin es una actividad de modelaje.
El objetivo del diseador: es producir un modelo o representacin del software que
se continuara ms adelante. El diseo del software es la primera de tres (3)
actividades tcnicas:
1) Diseo
2) Codificacin.

3) Prueba.
Diseo de Datos. Transforma el modelo del campo de informacin, creado durante
el anlisis, en las estructuras de datos que se van a requerir para implementar el
software.
Diseo Arquitectnico: Define las relaciones entre los principales elementos
estructurales del programa.
Diseo Procedimental: Transforma los elementos estructurales en una descripcin
procedimental del software. Se genera el cdigo fuente y para integrar y validar el
software, se llevan a cabo las pruebas.
Alcance del Diseo del Software:
1) Diseo de la arquitectura del sistema: Este es el proceso durante el cual se
produce una especificacin completa y verificada del hardware en general
2)

Diseo

detallado

del

software:

Este

ocurre

cuando

se

producen

especificaciones verificadas de estructuras de datos.

La eleccin de un mecanismo de persistencia adecuado:1)El tipo de sistema de
base de datos a utilizar.
2) La forma en que la aplicacin se comunicar con el mismo.
3) La distribucin de la lgica: qu parte resolver la aplicacin y qu otra se
delegar a mecanismos propios del sistema elegido las bases de datos de objetos
(OODBMS). Como su nombre lo indica, la forma en la que stas organizan y
almacenan la informacin se acerca bastante a la manera en que se trabaja con
objetos y referencias en las aplicaciones orientada a objeto las bases relacionales
(RDBMS)

han

demostrado

poseer

caractersticas:

1)

Constituyen

una

aproximacin robusta y flexible para el manejo de los datos.

2) Se encuentran soportadas por una teora capaz de, entre otras cosas, asegurar
la integridad de la informacin.
3) Estn sustentadas por estndares

Ciertas cuestiones se delegan al motor:

1) Almacenamiento, organizacin y recuperacin de informacin estructurada.
2) Concurrencia e integridad de datos.
3) Administracin de los datos compartidos.
La arquitectura de software de un sistema de programa o computacin es la
estructura de las estructuras del sistema, la cual comprende los componentes del
software, las propiedades de esos componentes visibles externamente, y las
relaciones entre ellos.
La arquitectura Mas bien, es la representacin que capacita al ingeniero del
software para:
1-Analizar la efectividad del diseo para la consecucin de los requisitos fijados.
2-Considerar las alternativas arquitectnicas en una etapa en la cual hacer
cambios en el diseo es relativamente fcil, y
3-Reducir los riesgos asociados a la construccin del software.
Porque es importante la arquitectura La arquitectura destaca decisiones
tempranas de diseo que tendrn un profundo impacto en todo el trabajo de
ingeniera del software que sigue
Sistemas basados en las arquitecturas de flujo de datos: Esta familia de estilos
enfatiza la reutilizacin y la modificabilidad. Es apropiada para sistemas que
implementan transformaciones de datos en pasos sucesivos. Histricamente l se
relaciona con las redes de proceso descriptas por Kahn hacia 1974 y con el
proceso secuenciales comunicantes (CSP) ideados por Tony Hoare cuatro aos
ms tarde.
Sistemas basados en arquitecturas de llamada y retorno (capas): Esta familia de
estilos enfatiza la modificabilidad y la escalabilidad. Son los estilos ms
generalizados en sistemas en gran escala. Existen dos subestilos dentro de esta
categora:

1-Arquitecturas de programa principal.

2-Arquitecturas de llamada de procedimiento remoto.
Las concepciones formuladas por el patriarca Edsger Dijkstra en la dcada de
1960,
Sistemas basados en arquitectura heterognea: Es la familia ms fuertemente
referida en los ltimos tiempos, se incluyen en este grupo formas compuestas o
indciles a la clasificacin en las categoras habituales. Es por cierto objetable y
poco elegante que existan clases residuales de este tipo en una taxonoma, pero
ninguna clasificacin conocida ha podido resolver este dilema conceptual
1-Sistemas de control de procesos: los sistemas de control de procesos se
caracterizan no slo por los tipos de componentes, sino por las relaciones que
mantienen entre ellos
2-Arquitecturas Basadas en Atributos: La arquitectura basada en atributos o ABAS
fue propuesta por Klein y Klazman. La intencin de estos autores es asociar a la
definicin del estilo arquitectnico un framework de razonamiento basado en
modelos de atributos especficos.
La arquitectura Cliente servidor el remitente de una solicitud es conocido
como cliente. Sus caractersticas son:
1-Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la
comunicacin
2-Espera y recibe las respuestas del servidor.
3-Por lo general, puede conectarse a varios servidores a la vez.
El diseo de un sistema de software se representa a travs de dos fases:
1-El diseo lgico: un diseo lgico escriben las especificaciones detalladas del
nuevo sistema, esto es, describen sus caractersticas como son: las salidas,

entradas, archivos, bases de datos y procedimientos; todas de manera que cubran

los requerimientos del proyecto.
2-El diseo fsico: El diseo fsico, actividad que sigue al diseo lgico, produce
programas de software, archivos y un sistema en marcha, las especificaciones del
diseo indican a los programadores qu debe hacer el sistema.
Diseo fsico deben delinearse las caractersticas de cada uno de los
componentes que se enumeran a continuacin:
1-Diseo de hardware: debe especificarse todo el equipo de cmputo, lo que
incluye todo dispositivo de entrada, procedimientos y salidas con sus
caractersticas de rendimiento
2- Diseo de software: deben especificarse las caractersticas de todo el software
3-Diseo de base de datos: es necesario detallar el tipo estructura y funciones de
las base de datos, las relaciones de los elementos de datos establecidos en el
diseo lgico y fsico

2.7.5 METRICAS DE NIVEL DE COMPONENTES

Las mtricas de diseo a nivel de componentes se concentran en las
caractersticas internas de los componentes del software e incluyen medidas de la
cohesin, acoplamiento y complejidad del mdulo. Estas tres medidas pueden 88
ayudar al desarrollador de software a juzgar la calidad de un diseo a nivel de
componentes. Las mtricas presentadas son de caja blanca en el sentido de que
requieren conocimiento del trabajo interno del mdulo en cuestin. Las mtricas
de diseo en los componentes se pueden aplicar una vez que se ha desarrollado
un diseo procedimental. Tambin se pueden retrasar hasta tener disponible el
cdigo fuente.

2.7.6 METRICAS DE DISEO DE INTERFAZ

Aunque existe una significativa cantidad de literatura sobre el diseo de interfaces
hombre-mquina, se ha publicado relativamente poca informacin sobre mtricas
que proporcionen una visin interna de la calidad y facilidad de empleo de la
interfaz.
Sears [Pressman 98] sugiere la conveniencia de la representacin (CR) como una
valiosa mtrica de diseo para interfaces hombre-mquina. Una IGU
(Interfaz Grfica de Usuario) tpica usa entidades de representacin, iconos
grficos, texto, mens, ventanas y otras para ayudar al usuario a completar tareas.
Para realizar una tarea dada usando una IGU, el usuario debe moverse de una
entidad de representacin a otra. Las posiciones absolutas y relativas de cada
entidad de representacin, la frecuencia con que se utilizan y el costo de la
transicin de una entidad de representacin a la siguiente contribuirn a la
conveniencia de la interfaz. Para una representacin especfica (p. ej.: un diseo
de una IGU especfica), se pueden asignar costos a cada secuencia de acciones
de acuerdo con la siguiente relacin:
Costos = [frecuencia de transicin (ki) x costos de transicin (ki)] (4.30)
Donde k es la transicin i especfica de una entidad de representacin a la
siguiente cuando se realiza una tarea especfica. Esta suma se da con todas las
transiciones de una tarea en particular o conjunto de tareas requeridas para
conseguir alguna funcin de la aplicacin. El costo puede estar caracterizado en
trminos de tiempo, retraso del proceso o cualquier otro valor razonable, tal como
la distancia que debe moverse el ratn entre entidades de la representacin.
La conveniencia de la representacin se define como:
CR = 100 x [(costo de la representacin ptima CR)/
(costo de la representacin propuesta)] .
(4.31)

95 donde CR = para una representacin ptima. Para calcular la

representacin ptima de una IGU, la superficie de la interfaz (el rea de la

pantalla) se divide en una cuadrcula. Cada cuadro de la cuadrcula representa

una posible posicin de una entidad de la representacin. Para una cuadrcula con
N posibles posiciones y K diferentes entidades de representacin para colocar, el
nmero posible de distribuciones se representa de la siguiente manera [Pressman
98]:
Nmero posible de distribuciones = [N !/
(K! * (N - K)!] * K!
(4.32)
La CR se emplea para valorar diferentes distribuciones propuestas de IGU y la
sensibilidad de una representacin en particular a los cambios en las
descripciones de tareas (por ejemplo, cambios en la secuencia y/o frecuencia de
transiciones) Es importante apuntar que la seleccin de un diseo de IGU puede
guiarse con mtricas tales como CR, pero el rbitro final debera ser la respuesta
del usuario basada en prototipos de IGU.