7/25/2019 tema 2y3

1/6

Tema 2

2.3 MODELOS DE PROCESO PRESCRIPTIVOfueron propuestos originalmente para poner orden en el caos del desarrollo desoftware. La historia indica que estos modelos tradicionales han dado cierta estructura til al trabajo de ingeniera de software y queconstituyen un mapa razonablemente eficaz para los equipos de software. Sin embargo, el trabajo de ingeniera de software yel 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 grandeentre la estructura y la sorpresa. Elborde del caos se visualiza como un estado inestable y parcialmente estructurado. Es inestable debido a que se ve atradoconstantemente hacia el caos o hacia el orden absoluto. Tenemos la tendencia de pensar que el orden es el estado ideal de lanaturaleza. 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 seruna ventaja en los ambientes impredecibles. El cambio ocurre cuando hay cierta estructura que permita que el cambio puedaorganizarse, pero que no sea tan rgida como para que no pueda suceder. Por otrolado, demasiado caos hace imposible la coordinacin y la coherencia. La falta deestructura no siempre significa desorden.Si los modelos de proceso prescriptivo5 buscan generar estructura y orden, soninapropiados para el mundo del software, que se basa en el cambio? Pero sirechazamos los modelos de proceso tradicional (y el orden que implican) y losreemplazamos con algo menos estructurado,hacemos imposible la coordinacin y coherencia en el t rabajo de software?No hay respuestas fciles para estas preguntas, pero existen alternativasdisponibles para los ingenieros de software. En las secciones que siguen se estudiael enfoque de proceso prescriptivo en el que los temas dominantes son el orden y laconsistencia del proyecto. El autor los llama prescriptivos porque prescriben unconjunto 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. Cadamodelo del proceso tambin prescribe un flujo del proceso (tambin llamado flujode trabajo), es decir, la manera en la que los elementos del proceso se relacionanentre s.Todos los modelos del proceso del software pueden incluir las actividadesestructurales generales, pero cada una pone distinto nfasis en ellas y define enforma 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 cascadaHay veces en las que los requerimientos para cierto problema se comprenden bien: cuando el trabajo desde la comunicacin hasta eldespliegue fluye en forma razonablemente lineal. Esta situacin se encuentra en ocasiones cuando deben hacerse adaptaciones omejoras bien definidas a un sistema ya existente. Tambin ocurre en cierto nmero limitado de nuevos esfuerzos de desarrollo, pero slocuando 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 delsoftware, 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 lacascada se denomina modelo en V. En la se ilustra el modelo en V, donde se aprecia la relacin entre las acciones para elaseguramiento 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 devisualizar 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 crticashechas al modelo han ocasionado que incluso sus defensores ms obstinados cuestionen su eficacia. Entre los problemas que enocasiones 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, lohace 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 hagay 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 muyavanzado. 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 serinapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso til en situaciones en las que los requerimientos sonfijos y el trabajo avanza en forma lineal hacia el final.

2.3.2 Modelos de procesoincremental Combina elementos de losflujos de proceso lineal y paralelo.Debe observarse que el flujo de procesopara cualquier incremento puedeincorporar el paradigma del prototipo.

Cuando se utiliza un modelo incremental,es frecuente que el primer incremento seaelproducto fundamental. Es decir, seabordan los requerimientos bsicos, perono se proporcionan muchascaractersticas suplementarias (algunasconocidas y otras no). El cliente usa elproducto fundamental (o lo somete a unaevaluacin detallada). Como resultado deluso y/o evaluacin, se desarrolla un planpara el incremento que sigue. El planincluye la modificacin del productofundamental para cumplir mejor lasnecesidades del cliente, as como laentrega de caractersticas adicionales y

ms funcionalidad. Este proceso se repite despus de entregar cada incremento, hasta terminar el producto final.

7/25/2019 tema 2y3

2/6

El modelo de proceso incremental se centra en que en cada incremento se entrega unproducto que ya opera. Los primeros incrementos son versiones desnudas del productofinal, pero proporcionan capacidad que sirve al usuario y tambin le dan una plataforma deevaluacin.El desarrollo incremental es til en particular cuando no se dispone depersonal para la implementacincompleta del proyecto en el plazo establecido por el negocio. Los primeros incrementos sedesarrollan con pocos trabajadores. Si el producto bsico es bien recibido, entonces seagrega ms personal (si se requiere) para que labore en el siguiente incremento. Adems,los incrementos se planean para administrar riesgos tcnicos. Por ejemplo, un sistemagrande 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 planearlos primeros incrementos de forma que eviten el uso de dicho hardware, y as proporcionaruna funcionalidad parcial a losusuarios finales sin un retraso importante.

2.3.3 Modelos de proceso evolutivoEl software evoluciona en el tiempo. Es frecuente que los requerimientos del negocio y delproducto cambien conforme avanza el desarrollo, lo que hace que no sea realista trazaruna trayectoria rectilnea hacia el producto final; los plazos apretados del mercado hacenque sea imposible la terminacin de un software perfecto, pero debe lanzarse una versinlimitada a fin de aliviar la presin de la competencia o del negocio; se comprende bien elconjunto de requerimientos o el producto bsico, pero los detalles del producto oextensiones 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 generalespara el software, pero que no identifique los requerimientos detallados para las funcionesy 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 lainteraccin entre el humano y la mquina. En estas situaciones, y muchas otras, elparadigma de hacer prototipos tal vez ofrezca el mejor enfoque.Es posible hacer prototipos como un modelo de proceso aislado, es ms comn usarlocomo una tcnica que puede implementarse en el contexto de cualquiera de los modelosde proceso descritos en este captulo. Sin importar la manera en la que se aplique, elparadigma de hacer prototipos le ayudar a usted y a otros participantes a mejorar lacomprensin de lo que hay que elaborar cuando los requerimientos no estn claros.El paradigma de hacer prototipos comienzacon comunicacin. Se planea rpidamenteuna iteracin para hacer el prototipo, y se lleva a cabo el modelado (en forma de undiseo rpido). ste se centra en la representacin de aquellos aspectos del software

que sern visibles para los usuarios finales (por ejemplo, disposicin de la interfazhumana o formatos de la pantalla de salida). El diseo rpido lleva a la construccin deun 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 lasnecesidades 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 lasensacin del sistema real, y los desarrolladores logran construir algo de inmediato. No obstante, hacer prototipos llega a serproblemtico 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 unparadigma eficaz para la ingeniera de software, la clave esdefinir el principio del primero de las reglas del juego.El modelo espiral. Propuesto por Barry Boehm, es un modeloevolutivo del proceso del software y se acopla con lanaturaleza iterativa de hacer prototipos con los aspectoscontrolados y sistmicos del modelo de cascada. Tiene elpotencial para hacer un desarrollo rpido de versiones cadavez ms completas. Boehm describe el modelo del modosiguiente:El modelo de desarrollo espiral es un generador de modelo deproceso impulsado por el riesgo, que se usa para guiar laingeniera concurrente con participantes mltiples de sistemasintensivos en software. Tiene dos caractersticas distintivasprincipales.-- Enfoque cclico para el crecimiento del grado de definicinde un sistema y su implementacin, mientras que disminuye sugrado de riesgo.-- Conjunto de puntos de referencia de anclaje puntual para

asegurar el compromiso del participante con solucionesfactibles y satisfactorias.El primer circuito alrededor de la espiral da como resultado el desarrollo de una especificacin del producto; las vueltas sucesivas seusan 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 aplicarsea 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 amedida que el proceso avanza, el desarrollador y cliente comprenden y reaccionan mejor ante los riesgos en cada nivel de evolucin. Elmodelo espiral usa los prototipos como mecanismo de reduccin de riesgos, pero, ms importante, permite aplicar el enfoque de hacerprototipos en cualquier etapa de la evolucin del producto. Mantiene el enfoque de escaln sistemtico sugerido por el ciclo de vidaclsico, El modelo espiral demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyectoNo hay duda de que habr problemas si algn riesgo importante no se descubre y administra.2.3.4 Modelos concurrentesEn ocasiones llamado ingeniera concurrente, permite que un equipo de software represente elementos iterativos y concurrentes decualquiera de los modelos de proceso descritos en este captulo. Por ejemplo, la actividad de modelado definida parael 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.

7/25/2019 tema 2y3

3/6

Por ejemplo, la actividad de comunicacin (no se muestra en la figura) termina su primera iteracin al principio de un proyecto y existe enel 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, laactividad 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 lasactividades, 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 demodelado), 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 unared del proceso. Cada actividad, accin o tarea de la red existe simultneamente con otras actividades, acciones o tareas. Los eventosgenerados en cierto punto de la red del proceso desencadenan transiciones entre los estados.2.3.5 Una ltima palabra acerca de los procesos evolutivosEl software de cmputo moderno se caracteriza por el cambio continuo, por tiempos de entrega muy apretados y por una necesidad desatisfaccin 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 deciclos 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 evolucionesocurren 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. Debedarse prioridad a la velocidad el desarrollo con el enfoque de cero defectos, extender al desarrollo para lograr una alta capacidadpodra resultar como la entrega tarda de un producto.

El objetivo de los modelos evolutivos es desarrollar software de alta calidad14 en forma iterativa o incremental. Sin embargo, es posibleusar un proceso evolutivo para hacer nfasis en la flexibilidad, expansibilidad y velocidad del desarrollo. El reto para los equipos desoftware y sus administradores es establecer un balance apropiado entre estos parmetros crticos del proyectoy el producto, y la satisfaccin del cliente (rbitro definitivo de la calidad del software).

2.4 MODELOS DE PROCESO ESPECIALIZADOTienen muchas de las caractersticas de uno o ms de los modelos tradicionales quese presentaron en las secciones anteriores, dichos modelos tienden a aplicarse cuando se elige un enfoque de ingeniera de softwareespecializado.2.4.1 Desarrollo basado en componentes Incorpora muchas de las caractersticas del modelo espiral. Es de naturalezaevolutiva y demanda un enfoque iterativo para la creacin de software. Sin embargo, el modelo de desarrollo basado en componentesconstruye aplicaciones a partir de fragmentos de software prefabricados.Las actividades de modelado y construccin comienzan con la identificacin de candidatos de componentes. stos pueden disearsecomo mdulos de software convencional o clases orientadas a objetos o paquetes16 de clases. Sin importar la tecnologa usada paracrear 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 variosbeneficios en cuanto a la mensurabilidad.2.4.2 El modelo de mtodos formalesAgrupa actividades que llevan a la especificacin matemtica formal del software decmputo. Los mtodos formales permiten especificar, desarrollar y verificar un sistema basado en computadora por medio del empleo deuna 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 expresadopreocupaciones 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 muchacapacitacin. 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 aspectosSin importar el proceso del software que se elija, los constructores de software complejo implementan de manera invariable un conjuntode caractersticas, funciones y contenido de informacin localizados. Estas caractersticas localizadas del software se modelan comocomponentes 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, llamadosaspectos, 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 delos 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 loscomponentes de software localizados; aun as, los aspectos tienen un efecto directo sobre stos. De esta forma, es esencial disponer decomunicacin asincrnica entre las actividades de proceso del software aplicadas a la ingeniera, y la construccin de los aspectos ycomponentes.El anlisis detallado del desarrollo de software orientado al aspecto se deja a libros especializados en el tema. Si el lector tiene inters enprofundizar, se le invita a consultar.

2.5 EL PROCESO UNIFICADO Reconoce la importancia de la comunicacin con el cliente y los mtodos directos paradescribir su punto de vista respecto de un sistema (el caso de uso).Hace nfasis en la importancia de la arquitectura del software yayuda 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 resultaesencial en el desarrollo moderno del software.

7/25/2019 tema 2y3

4/6

2.5.1 Breve historiaAl principio de la dcada de 1990, James Rumbaugh, Grady Booche Ivar Jacobson comenzaron a trabajar en un mtodo unificadoque combinara lo mejor de cada uno de sus mtodos individualesde anlisis y diseo orientado a objetos. El resultado fue unUML, lenguaje de modelado unificado, que contiene una notacinrobusta para el modelado y desarrollo de los sistemas orientados aobjetos. se presenta un mtodo introductorio a la enseanza paraquienes no estn familiarizados con las reglas bsicas de notaciny modelado con el UML. En los siguientes aos, Jacobson,

Rumbaugh y Booch desarrollaron elproceso unificado, estructurapara la ingeniera de software orientado a objetos que utiliza UML.

Actualmente, el proceso unificado (PU) y el UML se usan mucho enproyectos de toda clase orientados a objetos. El modelo iterativo eincremental propuesto por el PU puede y debe adaptarsepara que satisfaga necesidades especficas del proyecto.

2.5.2 Fases del proceso unificado

Tema 3

MTRICAS DE PROCESO Y DE PROYECTOLa 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 PROYECTOSu intencin es proporcionar un conjunto de indicadores deproceso 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 productosoperativos 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 esmedir atributos especficos del mismo, desarrollar un conjunto de mtricas significativas con base en dichos atributos y luego usarlas paraproporcionar indicadores que conducirn a una estrategia para mejorar. Algunas mtricas de proceso son privadas para el equipo deproyecto del software, pero pblicas para todos los miembros del equipo. Grady sugiere una etiqueta de mtrica de softwareq seaadecuada 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 negativoslos datos de mtricas que indiquen un rea problemtica. Dichos datos simplemente son un indicio paramejorar el proceso.No obsesionarse con una sola mtrica ni excluir otras mtricas importantes.25.1.2 Mtricas de proyectoA diferencia de las mtricas de proceso de software que se usaron con propsitos estratgicos, lasmedidas de proyecto de software son tcticas. La intencin de las mtricas de proyecto es doble. 1ro, se usan para minimizar elcalendario de desarrollo al hacer los ajustes necesarios para evitar demoras y mitigar potenciales problemas y riesgos. 2do, para valorarla 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 requeridadurante el proyecto tambin se reduce. Esto conduce a una reduccin en el costo global del proyecto.25.2 M

EDICIN 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 defectosreportados 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 lacontroversia 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 denormalizacin. La mtrica orientada a funcin de mayor uso es el punto de funcin.25.2.3 Reconciliacin de mtricas LOC y PFLa relacin entre lneas de cdigo y puntos de funcin depende del lenguaje deprogramacin que se use para implementar el software y la calidad del diseo. Las medidas LOC y PF se usan frecuentemente paracalcular mtricas de productividad.25.2.4 Mtricas orientadas a objetoLas mtricas de proyecto de software convencional (LOC o PF) pueden usarse para estimarproyectos 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 independientesque se definen tempranamente en el anlisis orientado aobjeto.Nmero de clases de apoyo. Se requieren para implementar el sistema, pero no se relacionan de inmediato con el dominio delproblema.Nmero promedio de clases de apoyo por clase clave Se conoce para un dominio de problema determinado, la estimacin sesimplificar 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 usoSe utilizan ampliamente como un mtodo para describir los requerimientos en el dominioen 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 lasmedidas 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 comercioelectrnico, 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 wpNmero de objetos de datos persistentes. Una webapp puede tener acceso a uno o ms objetos de datos persistentesNmero de sistemas externos puestos en interfaz Conforme crecen los reqerimientos para interfacs, tb crecen la complejidad y eldesarrollo del sistema.Nmero de objetos de contenido estticosAbarcan informacin basada en texto, grfica, video, animacin y audioesttica, que seincorporan 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.

7/25/2019 tema 2y3

5/6

Nmero de funciones ejecutables. Una funcin ejecutable proporciona cierto servicio computacional al usuario final. Conforme elnmero 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 quemodela 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 calidadAunq 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 seadapta 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 habilidadde 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 Mtr icas or ient adas a op erac in

Puesto que la clase es la unidad dominante en los sistemas OO, se han propuesto menos mtricas para operaciones que residen dentrode una clase. Churcher y Shepperd analizan esto cuando afirman: Los resultados de estudios recientes indican que los mtodos tiendena ser pequeos, tanto en trminos de nmero de enunciados como en complejidad lgica, lo que sugiere que la estructura deconectividad de un sistema puede ser ms importante que el contenido de los mdulos individuales. Sinembargo, puede obtenerse algode 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 mensajesenviados por la operacin. Conforme aumenta el nmero de mensajes enviados por una sola operacin, es probable que lasresponsabilidades 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 decomplejidad propuestas para software convencional. Puesto que las operaciones deben limitarse a una responsabilidad especfica, eldiseador 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 complejaes 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 informacinacerca 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 unimpacto 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 entradadel usuario con base en los prototipos GUI.

23.4 MTRICAS DE DISEO PARA WEBAPPS Un til conjunto de medidas y mtricas para webapps proporciona respuestascuantitativas 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 decontenido 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 eldesempeo?En la actualidad, cada una de estas preguntas puede abordarse slo de manera cualitativa, porque todava no existe una suite validadade 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 sensiblea la medicin ni a las mtricas. Sin embargo, Ivory proponen un conjunto de medidas que pueden ser tiles para valorar el impacto deldiseo esttico:Mtricas de contenido. Las mtricas en esta categora se enfocan en la complejidad del contenido y en los grupos de objetos decontenido 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 paraaplicaciones 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 desarrollowebapp valorar la calidad tcnica y predecir el esfuerzo con base en las estimaciones de complejidad estimadas. En esta rea todavaqueda mucho trabajo por hacer.

23.6 MTRICAS PARA PRUEBAS Los examinadores deben apoyarse en las mtricas de anlisis, diseo y cdigo para guiarlos en eldiseo 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 deintegracin y de la necesidad de software de pruebas especializado (por ejemplo, resguardos y controladores). La complejidadciclomtica (una mtrica de diseo en el nivel de componente) yace en el centro de la prueba de ruta base, un mtodo de diseo decasos de prueba. Adems, la complejidad ciclomtica puede usarse para dirigirse a mdulos como candidatos para prueba de unidadextensa. Los mdulos con alta complejidad ciclomtica tienen ms probabilidad de ser proclives al error que los mdulos donde sucomplejidad ciclomtica es menor. Por esta razn, debe emplear esfuerzo por arriba del promedio para descubrir errores en talesmdulos antes de que se integren en un sistema.23.6.2 Mtricas para pruebas orientadas a objetosLas mtricas del diseo OO proporcionan un indicio de la calidad del diseo. Tambin ofrecen un indicio general de la cantidad deesfuerzo de prueba requerido para ejercitar un sistema OO. Binder sugiere un amplio arreglo de mtricas de diseo que tienen influenciadirecta 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 paragarantizar 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

7/25/2019 tema 2y3

6/6

son pblicos o protegidos. Valores altos de PPP aumentan la probabilidad de efectos colaterales entre las clases porque los atributospblicos y protegidos conducen a alto potencial para acoplamiento.16 Las pruebas deben disearse para garantizar el descubrimiento detales efectos colaterales.Acceso pblico a miembros de datos (APD). Esta mtrica indica el nmero de clases (o mtodos) que pueden acceder a otrosatributos 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 eldescubrimiento 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 herenciamltiple. FIN > 1 indica que una clase hereda sus atributos y operaciones de ms de una clase raz. FIN > 1 debe evitarse cuando seaposible.