DIAGRAMAS DE IMPLEMENTACIN

2.4.1 DEFINICIN DE LOS DIAGRAMAS DE IMPLEMENTACINLos 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).Los diagramas de implementacin ofrecen una ilustracin de la arquitectura fsica del hardware, del software y de los artefactos del sistema. Los diagramas de implementacin pueden entenderse como lo contrario de loscasos de uso, porque ilustran la forma fsica del sistema, en lugar de representar conceptualmente los usuarios y dispositivos que interactan con el sistema.Los diagramas de implementacin son un elemento importante de la documentacin de sistemas que pueden ayudarle a planificar proyectos complejos con artefactos (como archivos ejecutables, archivos de datos, documentos XML y archivos de configuracin), que a fin de cuentas residen en plataformas de hardware independientes. El uso de diagramas de implementacin claros y detallados tambin permite entender mejor toda la arquitectura del proyecto, sobre todo si se trabaja en un equipo muy grande.2.4.2 OBJETIVOS DE LOS DIAGRAMAS DE IMPLEMENTACINOBJETIVO Muestranlosaspectosdeimplementacindelmodelo. Estructuradelcdigofuenteyobjeto. Estructuradelaimplementacinenejecucin.

2.4.3 TIPOS DE DIAGRAMAS DE IMPLEMENTACINExisten dos tipos de diagramas de implementacin: Diagrama de componentes Diagrama de despliegue2.4.3.1 DE COMPONENTESEs una unidad autnoma que forma parte del sistema y proporciona la implementacin de un conjunto de interfaces.Tipos de componentes Componentes de despliegue: son necesarios para formar un sistema ejecutable. Componentes de productos de trabajo: estos son generados en el proceso de desarrollo Componentes de ejecucin: consecuencia de la ejecucin del sistema.ELEMENTOS Requisitos: ayudan a documentar el comportamiento funcional de los elementos del software. Restricciones: son aquellos que indican el entorno en donde operan. Escenarios: describe las acciones de los objetos a lo largo del tiempo y describe la forma en la cual un componente trabaja, adems se pueden crear mltiples escenarios para describir tanto el camino bsico, como las excepciones, errores y otras condiciones. Trazabilidad: un componente puede implementar otro elemento del modelo (por ejemplo en un caso de uso) o puede ser implementado por otro elemento.UTLIZACION Los diagramas de componentes son utilizados para: Modelar la vista (lgica) de implementacin esttica en un sistema. Modelar cdigo fuente Modelar versiones ejecutables. Modelar base de datos fsicas Modelar sistemas adaptables.ESTEREOTIPOS EN LOS COMPONENTES Executable: especifica un componente que se puede ejecutar en un nodo. Library: especifica una biblioteca de objetos esttica o dinmica. Table: especifica un componente que representa una tabla de una base de datos. File: especifica un componente que representa un documento que contiene cdigo. fuente o datos. Documents: especifica un componente que representa un documento.Diseo de un diagrama de componentes

Ejemplo:

2.4.3.2. DIAGRAMA DE DESPLIEGUEEs la etapa del desarrollo que describe la configuracin del Sistema para su ejecucin en un ambiente del mundo real. Para el despliegue se deben tomar decisiones sobre los parmetros de la configuracin, funcionamiento, asignacin de recursos, distribucin y concurrencia.Un diagrama de despliegue muestra la configuracin de nodos que participan en la ejecucin y de los componentes que residen en ellos.RELACIONES FISICAS Muestran las relaciones entre los componentes del hardware y software en el sistema final as como su configuracin. Formados por instancias de componentes software que son los que representan manifestaciones de cdigo e tiempo de ejecucin. REPRESENTACION Grafos de nodos unidos por conexiones de comunicacin. Diagramas de clase que se encargan de modelar los nodos del sistema.

USOS Sistemas empotrados: coleccin de hardware con gran cantidad de software que controla los dispositivos. Sistema cliente- servidor: conectividad de los clientes sobre los servidores y distribucin fsica de los nodos. Sistemas distribuidos: incluyen varios niveles de servidores; cambios continuos de topologas.Nodos Es un objeto fsico en tiempo de ejecucin que representa un recurso computacional generalmente tiene memoria y capacidad de procesamiento. Los nodos pueden contener objetos, instancias, instancias del componente, adems, un nodo representa tpicamente un procesador o un dispositivo sobre el que se pueden desplegar los componentes.Cada nodo tiene los siguientes atributos que los distingue del resto: (Nombre simple, nombre compuesto).

RELACIONES Las relaciones entre los nodos permiten modelar: Un canal de comunicacin entre existente entre nodos y el tipo. La cardinalidad de la relacin.

ARTEFACTOS Son aquellos que representan las especificaciones de un elemento de implementacin concreto y real: Archivos (ejecutables, de datos, de configuracin, HTML, documentos, resultados del proceso de desarrollo. Etc.) Tablas de la base de datos.

Estos artefactos se despliegan en los nodos, indicando que recurso computacional los va albergar y ejecutar.Ejemplo

De EjecucinUn diagrama de ejecucin muestra la configuracin de los elementos de procesamiento en tiempo de ejecucin y los componentes software, procesos y objetos que se ejecutan en ellos. Instancias de los componentes software representan manifestaciones en tiempo de ejecucin del cdigo. Componentes que solo sean utilizados en tiempo de compilacin deben mostrarse en el diagrama de componentes.Un diagrama de ejecucin es un grafo de nodos conectados por asociaciones de comunicacin. Un nodo puede contener instancias de componentes software, objetos, procesos (un caso particular de un objeto). Las instancias de componentes software pueden estar unidos por relaciones de dependencia, posiblemente a interfaces.Un ejemplo de diagrama de ejecucin es el siguiente:

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 aplicaciones1.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 antiguoLas 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 recienteTiende 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 desarrolloEl 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.GRAPPLESignifica Guas para la Ingeniera de Aplicaciones Rpidas. 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 necesidadesLa funcin es comprender lo que desea el cliente.Realice un anlisis del dominioEl objetivo es comprender de la mejor manera posible el dominio del cliente. El analista debe acomodarse al cliente.Descubra las necesidades del sistemaEl 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 clienteCuando finaliza todas las acciones de Necesidades, el administrador de proyectos presentar los resultados al cliente.

AnlisisEn 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.DiseoEl 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.DesarrolloDe 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.DistribucinEn 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 USUARIOEldiseo de interfaz de usuariooingeniera de la interfazes el diseo decomputadoras, aplicaciones, mquinas, dispositivos de comunicacinmvil, aplicaciones desoftware, 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 eldiseo grfico,industrial,web, de software y laergonoma; 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 MAQUINATodava no hay una definicin concreta para el conjunto de conceptos que forman el rea de lainteraccin persona-computador. En trminos generales, podramos decir que es la disciplina que estudia elintercambio de informacinmediantesoftwareentre laspersonas y lascomputadoras. 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 MAQUINALa 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 DATOSSon muchas las consideraciones a tomar en cuenta al momento de hacer el diseo de la base de datos, quizs las ms fuertes sean: Lavelocidadde acceso. El tamao de la informacin. El tipo de la informacin. Facilidad de acceso a la informacin. Facilidad para extraer la informacin requerida. Elcomportamientodel manejador debases de datoscon 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 OBJETIVOSUn 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 DATOSLos 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.

2.7 MTRICAS DEL DISEOEntre las diversas ventajas de las tcnicas de diseo se pueden destacar las siguientes:Comprensibilidad: programadores y 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 del esfuerzo de mantenimiento: la divisin en mdulos favorece que las distintas funciones las lleven a cabo mdulos diferenciados.Algunas de las mtricas vistas hasta el momento tratan este problema. La complejidad lmite de un mdulo se fija en algunos casos en un nmero de complejidad ciclomtica igual a 10.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.2.7.1 FACTORES QUE AFECTANFactores 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.2.7.2 PRODUCTIVIDADEn 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.2.7.3 MEDIDAS RELACIONADASAunque 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. 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 u optimizar si el cliente desea un cambio de requisitos. No hay forma de medir directamente la facilidad de mantenimiento; 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. 2.7.3.1 TAMAOEl 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 RequisitosLa 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. 2.7.3.2 FUNCIONHewlett-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. - 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 problema2.7.3.3 PUNTOS DE OBJETOPara 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 ARQUITECTONICOEl 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.2.7.5 METRICAS DE NIVEL DE COMPONENTESLas 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 INTERFAZAunque 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.

BIBLIOGRAFIAhttp://es.slideshare.net/zonickx/diagramas-de-implementacionhttp://www.altova.com/es/umodel/uml-deployment-diagrams.htmlhttps://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.htmlhttps://www.google.com.mx/webhp?sourceid=chromeinstant&ion=1&espv=2&es_th=1&ie=UTF-8#q=adaptaciones+de+uml