Tema 2

2.3 MODELOS DE PROCESO PRESCRIPTIVO fueron propuestos originalmente para poner orden en el caos del desarrollo de
software. La historia indica que estos modelos tradicionales han dado cierta estructura til al trabajo de ingeniera de software y que
constituyen un mapa razonablemente eficaz para los equipos de software. Sin embargo, el trabajo de ingeniera de software y
el producto que genera siguen al borde del caos, Nogueira y sus colegas afirman lo siguiente:
El borde del caos se define como el estado natural entre el orden y el caos, un compromiso grande entre la estructura y la sorpresa. El
borde del caos se visualiza como un estado inestable y parcialmente estructurado. Es inestable debido a que se ve atrado
constantemente hacia el caos o hacia el orden absoluto. Tenemos la tendencia de pensar que el orden es el estado ideal de la
naturaleza. Esto podra ser un error las investigaciones apoyan la teora de que la operacin que se aleja del equilibrio genera
creatividad, procesos auto-organizados y rendimientos crecientes. El orden absoluto significa ausencia de variabilidad, que podra ser
una ventaja en los ambientes impredecibles. El cambio ocurre cuando hay cierta estructura que permita que el cambio pueda
organizarse, pero que no sea tan rgida como para que no pueda suceder. Por otro
lado, demasiado caos hace imposible la coordinacin y la coherencia. La falta de
estructura no siempre significa desorden.
Si los modelos de proceso prescriptivo5 buscan generar estructura y orden, son
inapropiados para el mundo del software, que se basa en el cambio? Pero si
rechazamos los modelos de proceso tradicional (y el orden que implican) y los
reemplazamos con algo menos estructurado,
hacemos imposible la coordinacin y coherencia en el trabajo de software?
No hay respuestas fciles para estas preguntas, pero existen alternativas
disponibles para los ingenieros de software. En las secciones que siguen se estudia
el enfoque de proceso prescriptivo en el que los temas dominantes son el orden y la
consistencia del proyecto. El autor los llama prescriptivos porque prescriben un
conjunto de elementos del proceso: actividades estructurales,
acciones de ingeniera de software, tareas, productos del trabajo, aseguramiento
de la calidad y mecanismos de control del cambio para cada proyecto. Cada
modelo del proceso tambin prescribe un flujo del proceso (tambin llamado flujo
de trabajo), es decir, la manera en la que los elementos del proceso se relacionan
entre s.
Todos los modelos del proceso del software pueden incluir las actividades
estructurales generales, pero cada una pone distinto nfasis en ellas y define en
forma diferente el flujo de proceso que invoca cada actividad estructural (as como
acciones y tareas de ingeniera de software).

2.3.1 Modelo de la cascada

Hay veces en las que los requerimientos para cierto problema se comprenden bien: cuando el trabajo desde la comunicacin hasta el
despliegue fluye en forma razonablemente lineal. Esta situacin se encuentra en ocasiones cuando deben hacerse adaptaciones o
mejoras bien definidas a un sistema ya existente. Tambin ocurre en cierto nmero limitado de nuevos esfuerzos de desarrollo, pero slo
cuando los requerimientos estn bien definidos y tienen una estabilidad razonable.

El modelo de la cascada, a veces llamado ciclo de vida clsico, sugiere un enfoque sistemtico y secuencial6 para el desarrollo del
software, que comienza con la especificacin de los requerimientos por parte del cliente y avanza a travs de planeacin, modelado,
construccin y despliegue, para concluir con el apoyo del software terminado. Una variante de la representacin del modelo de la
cascada se denomina modelo en V. En la se ilustra el modelo en V, donde se aprecia la relacin entre las acciones para el
aseguramiento de la calidad y aquellas asociadas con la comunicacin, modelado y construccin temprana.
En realidad, no hay diferencias fundamentales entre el ciclo de vida clsico y el modelo en V. Este ltimo proporciona una forma de
visualizar el modo de aplicacin de las acciones de verificacin y validacin al trabajo de ingeniera inicial.
El modelo de la cascada es el paradigma ms antiguo de la ingeniera de software. Sin embargo, en las ltimas tres dcadas, las crticas
hechas al modelo han ocasionado que incluso sus defensores ms obstinados cuestionen su eficacia. Entre los problemas que en
ocasiones surgen al aplicar el modelo de la cascada se encuentran los siguientes:
1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo
hace en forma indirecta. Como resultado, los cambios generan confusin conforme el equipo del proyecto avanza.
2. A menudo, es difcil para el cliente enunciar en forma explcita todos los requerimientos. El modelo de la cascada necesita que se haga
y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos.
3. El cliente debe tener paciencia. No se dispondr de una versin funcional del(s) programa(s) hasta que el proyecto est muy
avanzado. Un error grande sera desastroso si se detectara hasta revisar el programa en funcionamiento.
Hoy en da, el trabajo de software es acelerado y est sujeto a una corriente sin fin de cambios. El modelo de la cascada suele ser
inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso til en situaciones en las que los requerimientos son
fijos y el trabajo avanza en forma lineal hacia el final.

2.3.2 Modelos de proceso

incremental Combina elementos de los
flujos de proceso lineal y paralelo.
Debe observarse que el flujo de proceso
para cualquier incremento puede
incorporar el paradigma del prototipo.
Cuando se utiliza un modelo incremental,
es frecuente que el primer incremento sea
el producto fundamental. Es decir, se
abordan los requerimientos bsicos, pero
no se proporcionan muchas
caractersticas suplementarias (algunas
conocidas y otras no). El cliente usa el
producto fundamental (o lo somete a una
evaluacin detallada). Como resultado del
uso y/o evaluacin, se desarrolla un plan
para el incremento que sigue. El plan
incluye la modificacin del producto
fundamental para cumplir mejor las
necesidades del cliente, as como la
entrega de caractersticas adicionales y
ms funcionalidad. Este proceso se repite despus de entregar cada incremento, hasta terminar el producto final.

El modelo de proceso incremental se centra en que en cada incremento se entrega un

producto que ya opera. Los primeros incrementos son versiones desnudas del producto
final, pero proporcionan capacidad que sirve al usuario y tambin le dan una plataforma de
evaluacin. El desarrollo incremental es til en particular cuando no se dispone de
personal para la implementacin
completa del proyecto en el plazo establecido por el negocio. Los primeros incrementos se
desarrollan con pocos trabajadores. Si el producto bsico es bien recibido, entonces se
agrega ms personal (si se requiere) para que labore en el siguiente incremento. Adems,
los incrementos se planean para administrar riesgos tcnicos. Por ejemplo, un sistema
grande tal vez requiera que se disponga de hardware nuevo que se encuentre en
desarrollo y cuya fecha de entrega sea incierta. En este caso, tal vez sea posible planear
los primeros incrementos de forma que eviten el uso de dicho hardware, y as proporcionar
una funcionalidad parcial a los
usuarios finales sin un retraso importante.

2.3.3 Modelos de proceso evolutivo

El software evoluciona en el tiempo. Es frecuente que los requerimientos del negocio y del
producto cambien conforme avanza el desarrollo, lo que hace que no sea realista trazar
una trayectoria rectilnea hacia el producto final; los plazos apretados del mercado hacen
que sea imposible la terminacin de un software perfecto, pero debe lanzarse una versin
limitada a fin de aliviar la presin de la competencia o del negocio; se comprende bien el
conjunto de requerimientos o el producto bsico, pero los detalles del producto o
extensiones del sistema an estn por definirse. En estas situaciones y otras parecidas se
necesita un modelo de proceso diseado explcitamente para adaptarse a un producto que evoluciona con el tiempo.
Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez ms completas
del software.
Hacer prototipos. Es frecuente que un cliente defina un conjunto de objetivos generales
para el software, pero que no identifique los requerimientos detallados para las funciones
y caractersticas.
En otros casos, el desarrollador tal vez no est seguro de la eficiencia de un algoritmo,
de la adaptabilidad de un sistema operativo o de la forma que debe adoptar la
interaccin entre el humano y la mquina. En estas situaciones, y muchas otras, el
paradigma de hacer prototipos tal vez ofrezca el mejor enfoque.
Es posible hacer prototipos como un modelo de proceso aislado, es ms comn usarlo
como una tcnica que puede implementarse en el contexto de cualquiera de los modelos
de proceso descritos en este captulo. Sin importar la manera en la que se aplique, el
paradigma de hacer prototipos le ayudar a usted y a otros participantes a mejorar la
comprensin de lo que hay que elaborar cuando los requerimientos no estn claros.
El paradigma de hacer prototipos comienza con comunicacin. Se planea rpidamente
una iteracin para hacer el prototipo, y se lleva a cabo el modelado (en forma de un
diseo rpido). ste se centra en la representacin de aquellos aspectos del software
que sern visibles para los usuarios finales (por ejemplo, disposicin de la interfaz
humana o formatos de la pantalla de salida). El diseo rpido lleva a la construccin de
un prototipo. ste se entrega y es evaluado por los participantes, que dan
retroalimentacin para mejorar los requerimientos. La iteracin ocurre a medida de que el prototipo es afinado para satisfacer las
necesidades de distintos participantes, y al mismo tiempo le permite a usted entender mejor lo que se necesita hacer.
El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del software.
Tanto a los participantes como a los ingenieros de software les gusta el paradigma de hacer prototipos. Los usuarios adquieren la
sensacin del sistema real, y los desarrolladores logran construir algo de inmediato. No obstante, hacer prototipos llega a ser
problemtico por las siguientes razones:
--No se percibe la prisa por hacer que funcione.
--No se considera la calidad general del software.
--Como ingeniero del software, quizs utiliza un sistema operativo inapropiado, un algoritmo ineficiente.
Aunque puede haber problemas, hacer prototipos es un
paradigma eficaz para la ingeniera de software, la clave es
definir el principio del primero de las reglas del juego.
El modelo espiral. Propuesto por Barry Boehm, es un modelo
evolutivo del proceso del software y se acopla con la
naturaleza iterativa de hacer prototipos con los aspectos
controlados y sistmicos del modelo de cascada. Tiene el
potencial para hacer un desarrollo rpido de versiones cada
vez ms completas. Boehm describe el modelo del modo
siguiente:
El modelo de desarrollo espiral es un generador de modelo de
proceso impulsado por el riesgo, que se usa para guiar la
ingeniera concurrente con participantes mltiples de sistemas
intensivos en software. Tiene dos caractersticas distintivas
principales.
-- Enfoque cclico para el crecimiento del grado de definicin
de un sistema y su implementacin, mientras que disminuye su
grado de riesgo.
-- Conjunto de puntos de referencia de anclaje puntual para
asegurar el compromiso del participante con soluciones
factibles y satisfactorias.
El primer circuito alrededor de la espiral da como resultado el desarrollo de una especificacin del producto; las vueltas sucesivas se
usan para desarrollar un prototipo y, luego, versiones cada vez ms sofisticadas del software
A diferencia de otros modelos del proceso que finalizan cuando se entrega el software, el modelo espiral puede adaptarse para aplicarse
a lo largo de toda la vida del software de cmputo.
El modelo espiral es un enfoque realista para el desarrollo de sistemas y de software a gran escala. Como el software evoluciona a
medida que el proceso avanza, el desarrollador y cliente comprenden y reaccionan mejor ante los riesgos en cada nivel de evolucin. El
modelo espiral usa los prototipos como mecanismo de reduccin de riesgos, pero, ms importante, permite aplicar el enfoque de hacer
prototipos en cualquier etapa de la evolucin del producto. Mantiene el enfoque de escaln sistemtico sugerido por el ciclo de vida
clsico, El modelo espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto
No hay duda de que habr problemas si algn riesgo importante no se descubre y administra.

2.3.4 Modelos concurrentes

En ocasiones llamado ingeniera concurrente, permite que un equipo de software represente elementos iterativos y concurrentes de
cualquiera de los modelos de proceso descritos en este captulo. Por ejemplo, la actividad de modelado definida para
el modelo espiral se logra por medio de invocar una o ms de las siguientes acciones de software:
hacer prototipos, anlisis y diseo.
Todas las actividades de ingeniera de software existen de manera concurrente, pero se hallan en diferentes estados.

Por ejemplo, la actividad de comunicacin (no se muestra en la figura) termina su primera iteracin al principio de un proyecto y existe en
el estado de cambios en espera. La actividad de modelado (que exista en estado inactivo mientras conclua la comunicacin inicial,
ahora hace una transicin al estado en desarrollo. Sin embargo, si el cliente indica que deben hacerse cambios en los requerimientos, la
actividad de modelado pasa del estado en desarrollo al de cambios en espera.
El modelado concurrente define una serie de eventos que desencadenan transiciones de un estado a otro para cada una de las
actividades, acciones o tareas de la ingeniera de software.
Por ejemplo, durante las primeras etapas del diseo (accin importante de la ingeniera de software que ocurre durante la actividad de
modelado), no se detecta una inconsistencia en el modelo de requerimientos. Esto genera el evento correccin del modelo de anlisis,
que disparar la accin de anlisis de requerimientos del estado terminado al de cambios en espera.
El modelado concurrente es aplicable a todos los tipos de desarrollo de software y proporciona un panorama apropiado del estado actual
del proyecto. En lugar de confinar las actividades, acciones y tareas de la ingeniera de software a una secuencia de eventos, define una
red del proceso. Cada actividad, accin o tarea de la red existe simultneamente con otras actividades, acciones o tareas. Los eventos
generados en cierto punto de la red del proceso desencadenan transiciones entre los estados.

2.3.5 Una ltima palabra acerca de los procesos evolutivos

El software de cmputo moderno se caracteriza por el cambio continuo, por tiempos de entrega muy apretados y por una necesidad de
satisfaccin del cliente.
Los modelos de procesos evolutivos fueron concebidos para cumplir esos requisitos pero aun as tienen debilidades.
A pesar de los beneficios de los procesos evolutivos de software existen algunas preocupaciones.
--La primera es que hacer prototipos plantea un problema para la planeacin del proyecto debido a la incertidumbre en el nmero de
ciclos que se requiere para elaborar el producto.
--En segundo lugar los procesos evolutivos de software no establecen la velocidad mxima de la evolucin. Si las evoluciones
ocurren demasiado rpido, el proceso ser un caos. Y si la velocidad es muy lenta perjudicara la productividad.
--En tercer lugar, los procesos de software deben centrase en la flexibilidad y capacidad de extensin en lugar de la alta calidad. Debe
darse prioridad a la velocidad el desarrollo con el enfoque de cero defectos, extender al desarrollo para lograr una alta capacidad
podra resultar como la entrega tarda de un producto.
El objetivo de los modelos evolutivos es desarrollar software de alta calidad 14 en forma iterativa o incremental. Sin embargo, es posible
usar un proceso evolutivo para hacer nfasis en la flexibilidad, expansibilidad y velocidad del desarrollo. El reto para los equipos de
software y sus administradores es establecer un balance apropiado entre estos parmetros crticos del proyecto
y el producto, y la satisfaccin del cliente (rbitro definitivo de la calidad del software).

2.4 MODELOS DE PROCESO ESPECIALIZADO Tienen muchas de las caractersticas de uno o ms de los modelos tradicionales que
se presentaron en las secciones anteriores, dichos modelos tienden a aplicarse cuando se elige un enfoque de ingeniera de software
especializado.
2.4.1 Desarrollo basado en componentes Incorpora muchas de las caractersticas del modelo espiral. Es de naturaleza
evolutiva y demanda un enfoque iterativo para la creacin de software. Sin embargo, el modelo de desarrollo basado en componentes
construye aplicaciones a partir de fragmentos de software prefabricados.
Las actividades de modelado y construccin comienzan con la identificacin de candidatos de componentes. stos pueden disearse
como mdulos de software convencional o clases orientadas a objetos o paquetes16 de clases. Sin importar la tecnologa usada para
crear los componentes, este modelo incorpora las etapas siguientes (con uso de un enfoque evolutivo):
1. Se investigan y evalan, para el tipo de aplicacin de que se trate, productos disponibles basados en componentes.
2. Se consideran los aspectos de integracin de los componentes.
3. Se disea una arquitectura del software para que reciba los componentes.
4. Se integran los componentes en la arquitectura.
5. Se efectan pruebas exhaustivas para asegurar la funcionalidad apropiada.
El modelo del desarrollo basado en componentes lleva a la reutilizacin del software, y eso da a los ingenieros de software varios
beneficios en cuanto a la mensurabilidad.
2.4.2 El modelo de mtodos formales Agrupa actividades que llevan a la especificacin matemtica formal del software de
cmputo. Los mtodos formales permiten especificar, desarrollar y verificar un sistema basado en computadora por medio del empleo de
una notacin matemtica rigurosa.
Aunque el modelo de los mtodos formales no es el ms seguido, promete un software libre de defectos. Sin embargo, se han expresado
preocupaciones acerca de su aplicabilidad en un ambiente de negocios:
El desarrollo de modelos formales consume mucho tiempo y es caro.
Debido a que pocos desarrolladores de software tienen la formacin necesaria para aplicar mtodos formales, se requiere mucha
capacitacin.
Es difcil utilizar los modelos como mecanismo de comunicacin para clientes sin complejidad tcnica.
A pesar de esto, el enfoque de los mtodos formales ha ganado partidarios entre los desarrolladores que deben construir software de
primera calidad en seguridad, y desarrolladores que sufriran graves prdidas econmicas si ocurrieran errores en su software.

2.4.3 Desarrollo de software orientado a aspectos

Sin importar el proceso del software que se elija, los constructores de software complejo implementan de manera invariable un conjunto
de caractersticas, funciones y contenido de informacin localizados. Estas caractersticas localizadas del software se modelan como
componentes y luego se construyen dentro del contexto de una arquitectura de sistemas.
La ICOA usa el concepto de rebanadas horizontales a travs de componentes de software descompuestos verticalmente, llamados
aspectos, para caracterizar las propiedades globales funcionales y no funcionales de los componentes.
An no madura un proceso distinto orientado a aspectos. Sin embargo, es probable que un proceso as adopte caractersticas tanto de
los modelos de proceso evolutivo como concurrente.
El modelo evolutivo es apropiado en tanto los aspectos se identifican y despus se construyen.
La naturaleza paralela del desarrollo concurrente es esencial porque la ingeniera de aspectos se hace en forma independiente de los
componentes de software localizados; aun as, los aspectos tienen un efecto directo sobre stos. De esta forma, es esencial disponer de
comunicacin asincrnica entre las actividades de proceso del software aplicadas a la ingeniera, y la construccin de los aspectos y
componentes.
El anlisis detallado del desarrollo de software orientado al aspecto se deja a libros especializados en el tema. Si el lector tiene inters en
profundizar, se le invita a consultar.

2.5 EL PROCESO UNIFICADO Reconoce la importancia de la comunicacin con el cliente y los mtodos directos para
describir su punto de vista respecto de un sistema (el caso de uso). Hace nfasis en la importancia de la arquitectura del software y
ayuda a que el arquitecto se centre en las metas correctas, tales como que sea comprensible, permita cambios futuros y la reutilizacin:
Sugiere un flujo del proceso iterativo e incremental, lo que da la sensacin evolutiva que resulta
esencial en el desarrollo moderno del software.

2.5.1 Breve historia

Al principio de la dcada de 1990, James Rumbaugh, Grady Booch
e Ivar Jacobson comenzaron a trabajar en un mtodo unificado
que combinara lo mejor de cada uno de sus mtodos individuales
de anlisis y diseo orientado a objetos. El resultado fue un
UML, lenguaje de modelado unificado, que contiene una notacin
robusta para el modelado y desarrollo de los sistemas orientados a
objetos. se presenta un mtodo introductorio a la enseanza para
quienes no estn familiarizados con las reglas bsicas de notacin
y modelado con el UML. En los siguientes aos, Jacobson,
Rumbaugh y Booch desarrollaron el proceso unificado, estructura
para la ingeniera de software orientado a objetos que utiliza UML.
Actualmente, el proceso unificado (PU) y el UML se usan mucho en
proyectos de toda clase orientados a objetos. El modelo iterativo e
incremental propuesto por el PU puede y debe adaptarse
para que satisfaga necesidades especficas del proyecto.

2.5.2 Fases del proceso unificado

Tema 3

MTRICAS DE PROCESO Y DE PROYECTO

La medicin permite ganar comprensin acerca del proceso y del proyecto, al proporcionar un mecanismo de evaluacin objetiva.
25.1 MTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO Su intencin es proporcionar un conjunto de indicadores de
proceso que conduzca a mejorar el proceso de software a largo plazo.
Las mtricas de proyecto permiten al gerente de un proyecto de software: 1) valorar el estado de un proyecto en marcha,
2) rastrear riesgos potenciales,
3) descubrir reas problema antes de que se vuelvan crticas,
4) ajustar el flujo de trabajo o las tareas
5) evaluar la habilidad del equipo del proyecto para controlar la calidad de los productos
operativos del software. Muchas de las mtricas se usan tanto en los dominios del proceso como en los del proyecto.
25.1.1 Las mtricas del proceso y la mejora del proceso de software La nica forma racional para mejorar cualquier proceso es
medir atributos especficos del mismo, desarrollar un conjunto de mtricas significativas con base en dichos atributos y luego usarlas para
proporcionar indicadores que conducirn a una estrategia para mejorar. Algunas mtricas de proceso son privadas para el equipo de
proyecto del software, pero pblicas para todos los miembros del equipo. Grady sugiere una etiqueta de mtrica de software q sea
adecuada para gerentes y para profesionales:
Usar el sentido comn y sensibilidad organizacional cuando se interpreten datos de mtricas.
Proporcionar retroalimentacin regular a los individuos y equipos que recopilan medidas y mtricas.
No usar mtricas para valorar a los individuos.
Trabajar con los profesionales y con los equipos para establecer metas y mtricas claras que se usarn para lograr las primeras.
Nunca usar mtricas para amenazar a los individuos o a los equipos.
No considerar negativos los datos de mtricas que indiquen un rea problemtica. Dichos datos simplemente son un indicio para
mejorar el proceso.
No obsesionarse con una sola mtrica ni excluir otras mtricas importantes.
25.1.2 Mtricas de proyecto A diferencia de las mtricas de proceso de software que se usaron con propsitos estratgicos, las
medidas de proyecto de software son tcticas. La intencin de las mtricas de proyecto es doble. 1ro, se usan para minimizar el
calendario de desarrollo al hacer los ajustes necesarios para evitar demoras y mitigar potenciales problemas y riesgos. 2do, para valorar
la calidad del producto sobre una base en marcha y, cuando es necesario, modificar el enfoqe tcnico para mejorar la calidad.
Conforme la calidad mejora, los defectos se minimizan, y conforme el conteo de defectos baja, la cantidad de reelaboracin requerida
durante el proyecto tambin se reduce. Esto conduce a una reduccin en el costo global del proyecto.
25.2 MEDICIN DEL SOFTWARE Las medidas directas del proceso de software incluyen costo y esfuerzo aplicado.
Las medidas directas del producto incluyen lneas de cdigo (LOC) producidas, rapidez de ejecucin, tamao de memoria y defectos
reportados sobre cierto espacio de tiempo. Las medidas indirectas del producto incluyen funcionalidad, calidad, complejidad, eficiencia,
confiabilidad, capacidad de mantenimiento y muchas otras habilidades.
25.2.1 Mtricas orientadas a tamao Se derivan al normalizar las medidas de calidad y/o productividad para considerar el tamao
del software que se produjo. No se aceptan universalmente como la mejor forma de medir el proceso de software. La mayor parte de la
controversia gira en torno del uso de lneas de cdigo como medida clave.
25.2.2 Mtricas orientadas a funcin Usan una medida de la funcionalidad entregada por la aplicacin como un valor de
normalizacin. La mtrica orientada a funcin de mayor uso es el punto de funcin.
25.2.3 Reconciliacin de mtricas LOC y PF La relacin entre lneas de cdigo y puntos de funcin depende del lenguaje de
programacin que se use para implementar el software y la calidad del diseo. Las medidas LOC y PF se usan frecuentemente para
calcular mtricas de productividad.
25.2.4 Mtricas orientadas a objeto Las mtricas de proyecto de software convencional (LOC o PF) pueden usarse para estimar
proyectos de software orientados a objeto. Lorenz y Kidd sugieren el siguiente conjunto de mtricas para proyectos OO:
Nmero de guiones de escenario. Es una secuencia detallada de pasos qe describen la interaccin entre el usuario y la aplicacin.
Nmero de clases clave. Son los componentes enormemente independientes que se definen tempranamente en el anlisis orientado a
objeto.
Nmero de clases de apoyo. Se requieren para implementar el sistema, pero no se relacionan de inmediato con el dominio del
problema.
Nmero promedio de clases de apoyo por clase clave Se conoce para un dominio de problema determinado, la estimacin se
simplificar enormemente.
Nmero de subsistemas. Es un agregado de clases que apoyan una funcin que es visible para el usuario final de un sistema.
25.2.5 Mtricas orientadas a casos de uso Se utilizan ampliamente como un mtodo para describir los requerimientos en el dominio
en el nivel del cliente o empresarial, que implican caractersticas y funciones del software.
25.2.6 Mtricas de proyecto webapp El objetivo es entregar al usuario final una combinacin de contenido y funcionalidad. Entre las
medidas estn:
Nmero de pginas web estticas Las pginas web con contenido esttico son las + comunes de todas las caractersticas webapp.
Nmero de pginas web dinmicas Las pginas web con contenido dinmico son esenciales en toda aplicacin de comercio
electrnico, motores de bsqueda, aplicaciones financieras y muchas otras categoras webapp.
Nmero de vnculos de pgina internos Son punteros q proporcionan un hipervnculo hacia alguna otra pgina web dentro d la wp
Nmero de objetos de datos persistentes. Una webapp puede tener acceso a uno o ms objetos de datos persistentes
Nmero de sistemas externos puestos en interfaz Conforme crecen los reqerimientos para interfacs, tb crecen la complejidad y el
desarrollo del sistema.
Nmero de objetos de contenido estticos Abarcan informacin basada en texto, grfica, video, animacin y audioesttica, que se
incorporan dentro de la webapp. Mltiples objetos de contenido pueden aparecer en una sola pgina web.
Nmero de objetos de contenido dinmicos Se generan con base en las acciones del usuario final y abarcan informacin basada en
texto, grfica, video, animacin y audio, generada internamente, que se incorpora dentro de la webapp.

Nmero de funciones ejecutables. Una funcin ejecutable proporciona cierto servicio computacional al usuario final. Conforme el
nmero de funciones ejecutables aumenta, tambin crece el esfuerzo de modelado y construccin.
25.3 MTRICAS PARA CALIDAD DE SOFTWARE La meta dominante de la ingeniera del software es producir un sistema,
aplicacin o producto de alta calidad dentro de un marco temporal que satisfaga una necesidad de mercado. Para lograr esta meta,
deben aplicarse mtodos efectivos acoplados con herramientas modernas dentro del contexto de un proceso de software maduro.
La calidad de un sistema, aplicacin o producto slo es tan buena como los requerimientos que describen el problema, el diseo que
modela la solucin, el cdigo que conduce a un programa ejecutable y las pruebas que ejercitan el software para descubrir errores.
25.3.1 Medicin de la calidad Aunq existen muchas medidas de calidad del software, la exactitud, capacidad de mantenimiento,
integridad y usabilidad proporcionan tiles indicadores para el equipo del proyecto. Gilb sugiere definiciones y medidas para cada una.
Exactitud. Es el grado en el cual el software realiza la funcin requerida.
Capacidad de mantenimiento. Es la facilidad con la que un programa puede corregirse si se encuentra un error, la facilidad con que se
adapta si su entorno cambia o de mejorar si el cliente quiere un cambio en requerimientos.
Integridad. La integridad del software se ha vuelto cada vez ms importante en la era de los ciberterroristas y hackers. Mide la habilidad
de un sistema para resistir ataques a su seguridad.
Usabilidad. Es un intento por cuantificar la facilidad de uso y puede medirse en trminos.

23.3.7 Mtricas orientadas a operacin

Puesto que la clase es la unidad dominante en los sistemas OO, se han propuesto menos mtricas para operaciones que residen dentro
de una clase. Churcher y Shepperd analizan esto cuando afirman: Los resultados de estudios recientes indican que los mtodos tienden
a ser pequeos, tanto en trminos de nmero de enunciados como en complejidad lgica, lo que sugiere que la estructura de
conectividad de un sistema puede ser ms importante que el contenido de los mdulos individuales. Sin embargo, puede obtenerse algo
de comprensin al examinar las caractersticas promedio para los mtodos (operaciones).
Tres mtricas simples, propuestas por Lorenz y Kidd, son apropiadas:
Tamao promedio de operacin (TO). El tamao puede determinarse al contar el nmero de lneas de cdigo o el de mensajes
enviados por la operacin. Conforme aumenta el nmero de mensajes enviados por una sola operacin, es probable que las
responsabilidades no se hayan asignado bien dentro de una clase.
Complejidad de la operacin (CO). La complejidad de una operacin puede calcularse usando cualquiera de las mtricas de
complejidad propuestas para software convencional. Puesto que las operaciones deben limitarse a una responsabilidad especfica, el
diseador debe luchar por mantener la CO tan baja como sea posible.
Nmero promedio de parmetros por operacin (NP). Mientras ms grande sea el nmero de parmetros de operacin, ms compleja
es la colaboracin entre objetos. En general, el NP debe mantenerse tan bajo como sea posible.

23.3.8 Mtricas de diseo de interfaz de usuario

Aunque hay considerable literatura acerca del diseo de interfaces hombre/computadora, se ha publicado relativamente poca informacin
acerca de las mtricas que proporcionaran comprensin de la calidad y de la usabilidad de la interfaz.
Sears sugiere que la correccin de la plantilla (CP) es una mtrica de diseo valioso para las interfaces hombre/computadora.
Una GUI tpica usa entidades de plantilla (conos grficos, texto, mens, ventanas) para auxiliar al usuario a completar tareas.
Un estudio de mtricas de pgina web indica que las caractersticas simples de los elementos de la plantilla tambin pueden tener un
impacto significativo sobre la calidad percibida del diseo GUI.
Es importante observar que la seleccin de un diseo GUI puede guiarse con mtricas como CP, pero el rbitro final debe ser la entrada
del usuario con base en los prototipos GUI.

23.4 MTRICAS DE DISEO PARA WEBAPPS Un til conjunto de medidas y mtricas para webapps proporciona respuestas
cuantitativas a las siguientes preguntas:
La interfaz de usuario promueve usabilidad?
La esttica de la webapp es apropiada para el dominio de aplicacin y agrada al usuario?
El contenido se dise de tal forma que imparte ms informacin con menos esfuerzo?
La navegacin es eficiente y directa?
La arquitectura de la webapp se dise para alojar las metas y objetivos especiales de los usuarios de la webapp, la estructura de
contenido y funcionalidad, y el flujo de navegacin requerido para usar el sistema de manera efectiva?
Los componentes se disearon de manera que se reduce la complejidad procedimental y se mejora la exactitud, la confiabilidad y el
desempeo?
En la actualidad, cada una de estas preguntas puede abordarse slo de manera cualitativa, porque todava no existe una suite validada
de mtricas que proporcionen respuestas cuantitativas.
Mtricas estticas (diseo grfico). Por su naturaleza, el diseo esttico se apoya en el juicio cualitativo y por lo general no es sensible
a la medicin ni a las mtricas. Sin embargo, Ivory proponen un conjunto de medidas que pueden ser tiles para valorar el impacto del
diseo esttico:
Mtricas de contenido. Las mtricas en esta categora se enfocan en la complejidad del contenido y en los grupos de objetos de
contenido que se organizan en pginas.
Mtricas de navegacin. Las mtricas en esta categora abordan la complejidad del flujo de navegacin. En general, son tiles slo para
aplicaciones web estticas, que no incluyen vnculos y pginas generados de manera dinmica.
Usar un subconjunto de las mtricas sugeridas puede servir para derivar relaciones empricas que permiten a un equipo de desarrollo
webapp valorar la calidad tcnica y predecir el esfuerzo con base en las estimaciones de complejidad estimadas. En esta rea todava
queda mucho trabajo por hacer.

23.6 MTRICAS PARA PRUEBAS Los examinadores deben apoyarse en las mtricas de anlisis, diseo y cdigo para guiarlos en el
diseo y la ejecucin de los casos de prueba.
Las mtricas del diseo arquitectnico proporcionan informacin acerca de la facilidad o dificultad asociada con las pruebas de
integracin y de la necesidad de software de pruebas especializado (por ejemplo, resguardos y controladores). La complejidad
ciclomtica (una mtrica de diseo en el nivel de componente) yace en el centro de la prueba de ruta base, un mtodo de diseo de
casos de prueba. Adems, la complejidad ciclomtica puede usarse para dirigirse a mdulos como candidatos para prueba de unidad
extensa. Los mdulos con alta complejidad ciclomtica tienen ms probabilidad de ser proclives al error que los mdulos donde su
complejidad ciclomtica es menor. Por esta razn, debe emplear esfuerzo por arriba del promedio para descubrir errores en tales
mdulos antes de que se integren en un sistema.

23.6.2 Mtricas para pruebas orientadas a objetos

Las mtricas del diseo OO proporcionan un indicio de la calidad del diseo. Tambin ofrecen un indicio general de la cantidad de
esfuerzo de prueba requerido para ejercitar un sistema OO. Binder sugiere un amplio arreglo de mtricas de diseo que tienen influencia
directa sobre la comprobabilidad de un sistema OO. Las mtricas consideran aspectos de encapsulacin y herencia.
Falta de cohesin en mtodos (FCOM).15 Mientras ms alto sea el valor de la FCOM, ms estados deben ponerse a prueba para
garantizar que los mtodos no generan efectos colaterales.
Porcentaje pblico y protegido (PPP). Los atributos pblicos se heredan de otras clases y, por tanto, son visibles para dichas clases.
Los atributos protegidos son accesibles a los mtodos en las subclases. Esta mtrica indica el porcentaje de los atributos de clase que

son pblicos o protegidos. Valores altos de PPP aumentan la probabilidad de efectos colaterales entre las clases porque los atributos
pblicos y protegidos conducen a alto potencial para acoplamiento.16 Las pruebas deben disearse para garantizar el descubrimiento de
tales efectos colaterales.
Acceso pblico a miembros de datos (APD). Esta mtrica indica el nmero de clases (o mtodos) que pueden acceder a otros
atributos de clase, una violacin de la encapsulacin.
Valores altos de APD conducen al potencial de efectos colaterales entre clases. Las pruebas deben disearse para garantizar el
descubrimiento de tales efectos colaterales.
Nmero de clases raz (NCR). Esta mtrica es un conteo de las distintas jerarquas de clase que se describen en el modelo de diseo.
Deben desarrollarse las suites de prueba para cada clase raz y la correspondiente jerarqua de clase. Conforme el NCR aumenta,
tambin aumenta el esfuerzo de prueba.
Fan-in (FIN). Cuando se usa en el contexto OO, el fan-in (abanico de entrada) en la jerarqua de herencia es un indicio de herencia
mltiple. FIN > 1 indica que una clase hereda sus atributos y operaciones de ms de una clase raz. FIN > 1 debe evitarse cuando sea
posible.