Patrones Arquitectónicos
|
|
- Montserrat Peralta Valverde
- hace 8 años
- Vistas:
Transcripción
1 Diseño de Sistemas Curso: 3K3 Unidad: 2 - Diapositivas de clases Docentes: Ing. Marcela F. Cattaneo Ing. María Irene Mac William Ing. Germán Vélez Ing. Claudia Sánchez Arquitectura de Software Revisión de Concepto La Arquitectura del Software de un sistema de cómputo es la estructura o las estructuras del sistema que incluyen los componentes del software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos (L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley, 2003) La Arquitectura se define como la organización fundamental de un sistema, incluyendo sus componentes, las relaciones entre ellos y el entorno, y los principios que gobiernan su diseño y evolución (ANSI / IEEE Std ) 2 1
2 Arquitectura de Software Vistas de la Arquitectura La Arquitectura de Software es un artefacto de diseño complejo por eso, como la mayoría de los artefactos complejos, hay varias formas de visualizar y comprender una arquitectura. El término Vistas de la Arquitectura fue introducido por Philippe Krutchen en 1995 en su publicación: The 4+1 View Model of Sotware Architecture (IEEE Sotware, Nov. 1995) 3 Arquitectura de Software Vistas de la Arquitectura La publicación de Krutchen presenta una forma de describir y comprender la arquitectura basada en las siguientes cuatro vistas: Vista Lógica Vista de Procesos Vista Física Vista de Desarrollo 4 2
3 Arquitectura de Software Vistas de la Arquitectura Vista Lógica: Describe los elementos significativos arquitectónicamente y las relaciones entre ellos. Esencialmente captura la estructura de la aplicación utilizando diagramas de clases o equivalentes. Vista de Procesos: Se enfoca en describir la concurrencia y elementos de comunicación de una arquitectura. El interés principal en esta vista es decribir los componentes multi-threaded (multi-hilos) o replicados y los mecanismos de comunicación sincrónos y asíncronos utilizados. 5 Arquitectura de Software Vistas de la Arquitectura Vista Física: Describe cómo se mapean los principales procesos y componentes en los nodos de hardware. Podría mostrar, por ej., cómo los servidores Web y de Base de Datos para una aplicación son distribuidos a través de un número de equipos servidores. Vista de Desarrollo: Captura la organización interna de los componentes de software, típicamente cómo están contenidos en un entorno de desarrollo o una herramienta de gestión de la configuración. Por ej. la descripción de un paquete anidado y una jerarquía de clases para una aplicación Java representaría la vista de Desarrollo de una arquitectura. 6 3
4 Arquitectura de Software Vistas de la Arquitectura Estas cuatro vistas están unidas por los casos de uso arquitectónicamente significativos. Estos casos de uso básicamente capturan los requerimientos para la arquitectura, de ahí que estén relacionados con más de una vista particular. Vista de diseño Vista de Casos de Uso Vista de implementación Vista de procesos Vista de despliegue 7 Proceso de Arquitectura de Software Para guiar al arquitecto hacia la definición de la arquitectura de la aplicación es útil seguir un proceso definido. La siguiente figura muestra un proceso de arquitectura iterativo en tres pasos que puede ser usado para guiar las actividades durante el diseño: Determinar los requerimientos significativos para la arquitectura Diseño de la Arquitectura Validación 8 4
5 Proceso de Arquitectura de Software 1. Definir requerimientos significativos para la arquitectura: Involucra la creación de una sentencia o modelo de los requerimientos que conducirán el diseño de la arquitectura. 2. Diseñar la arquitectura: Implica definir la estructura y responsabilidades de los componentes que comprenden la arquitectura. 3. Validación: Implica el testing (la prueba) de la arquitectura, típicamente revisar el diseño contra los requerimientos existentes y cualquier posible futuro requerimiento conocido. 9 Proceso de Arquitectura de Software Determinar requerimientos significativos Antes que la solución arquitectónica sea diseñada es necesario tener una buena idea de los requerimientos para la arquitectura de la aplicación, para ello debemos: 1. Identificar requerimientos significativos. 2. Priorizar los requerimientos significativos para la arquitectura. 10 5
6 Proceso de Arquitectura de Software Determinar requerimientos significativos Identificar requerimientos significativos: las principales fuentes para los requerimientos de arquitectura son: El documento de requerimientos funcionales Otros documentos que capturan diversas necesidades de los stakeholders (atributos de calidad y requerimientos no funcionales) Requerimientos Funcionales Determinar Requerimientos de la Arquitectura Requerimientos de la Arquitectura Requerimientos de los Stakeholders 11 Proceso de Arquitectura de Software Determinar requerimientos significativos Priorizar los requerimientos de arquitectura: Es muy raro que todos los requerimientos de arquitectura de una aplicación sean iguales. Frecuentemente la lista de requerimientos contiene items que son de prioridad baja o características del tipo sería bueno tenerla pero no necesario. En consecuencia, es importante identificar explícitamente estos casos y clasificar los requerimientos en función de su prioridad. Inicialmente, es suficiente ubicar cada requerimiento en una de estas tres categorías: Alta Media Baja 12 6
7 Proceso de Arquitectura de Software Determinar requerimientos significativos Priorizar los requerimientos de arquitectura: Prioridad Alta: La aplicación debe soportar este requerimiento. Estos requerimientos conducen el diseño de la arquitectura. Prioridad Media: Este requerimiento necesitará ser soportado en alguna etapa, pero no necesariamente en las primeras iteraciones. Prioridad Baja: Es parte de la lista de deseos de los requerimientos. Las soluciones que pueden componer estos requerimientos son deseadas pero no conducen el diseño de la arquitectura. La priorización puede provocar conflictos entre los requerimientos. Ejemplo 13 Proceso de Arquitectura de Software Si bien todas las tareas para realizar la arquitectura son importantes, lo que realmente importa es la calidad del diseño de la arquitectura. Los buenos arquitectos son resultado de muchos años de ingeniería de software y experiencia en diseño. En la siguiente figura se muestran las entradas y salidas de la actividad de diseño de la arquitectura. 14 7
8 Proceso de Arquitectura de Software Entradas y salidas del diseño de la Arquitectura Requerimientos de la Arquitectura Elegir el Framework (Patrones Arquitectónicos) Distribuir Componentes Vistas de la Arquitectura Documento de Arquitectura 15 Proceso de Arquitectura de Software Elegir el Framework de la Arquitectura: Ian Gorton, comenta que la mayoría de las aplicaciones en las que trabajó en los últimos años se basan en un número pequeño de bien comprendidas y probadas arquitecturas. Hay una razón para ello Funcionan Trabajaremos con los siguientes Patrones de Arquitectura: N Tier Client- Server Messaging Publish Suscribe Broker Process Cordinator 16 8
9 Proceso de Arquitectura de Software : Patrones de Arquitectura N Tier Client-Server Client Tier (Capa Cliente) Web Client Web Client Web Client Web Client Web Server Tier (Capa de Servidor Web) Business Logic Tier (Capa de lógica de Negocio) Web Server Application Server Data Managment Tier (Capa Administración Databases de datos) 17 Patrones de Arquitectura: Patrón N-Tier Las propiedades clave de este patrón son: Separación de intereses: La presentación, lógica de negocio y administración de datos están claramente particionadas en diferentes capas. Comunicaciones sincrónicas: Las comunicaciones entre capas son sincrónicas. Las peticiones van en una única dirección desde la capa cliente a través de las capas de servidor Web y lógica de negocios hacia la capa de administración de datos. Cada capa espera la respuesta de la otra capa antes de proceder Despliegue flexible: No hay restricciones respecto de cómo las aplicaciones multi-capa se despliegan. Todas las capas podrían correr en la misma máquina o en el otro extremo- cada capa puede ser desplegada en su propia máquina. En las aplicaciones Web, la capa cliente es usualmente un navegador corriendo en un equipo de escritorio del usuario comunicándose de manera remota vía Internet con los componentes de la capa Web. 18 9
10 Patrones de Arquitectura: Patrón N-Tier Atributo de calidad Disponibilidad Manejo de Fallas Cambiabilidad Características Los servidores en cada capa pueden estar replicados, de modo que si uno falla los otros continúan disponibles. En general, la aplicación proveerá una baja calidad de servicio hasta que el servidor que falló sea restaurado. Si un cliente se está comunicando con el servidor que falla, la mayoría de los servidores y aplicaciones Web implementan transparencia frente a fallos. Esto significa que la petición del cliente, sin que él lo sepa, será re-direccionada a la réplica del servidor que puede satisfacer la petición. La separación de intereses favorece la cambiabilidad, dado que la presentación, lógica de negocios y administración de datos están claramente encapsulados. Cada una puede tener modificaciones de su lógica interna, en muchos casos sin cambios en las otras capas. 19 Patrones de Arquitectura: Patrón N-Tier Atributo de calidad Características Rendimiento Escalabilidad Esta arquitectura prove alto rendimiento. Elementos clave a considerar son la cantidad de hilos concurrentes soportados en cada servidor, la velocidad de las conexiones entre capas y el volumen de transferencia de datos. Como en todos los sistemas distribuidos, es sensato minimizar las llamadas necesarias entre capas para completar cada petición. Como los servidores en cada capa pueden ser replicados y múltiples instancias de servidores corren en el mismo o diferentes equipos servidores, la arquitectura puede escalarse bien. En la práctica la capa de administración de datos frecuentemente se convierte en un cuello de botella en la capacidad de un sistema
11 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón N Tier Client-Server Sistema: Gestión de Tasa Comercio e Industria Municipal Capa Cliente (Presentación) Cliente Web Cliente Web Atención al público Dirección de Rentas Procuración Fiscal Capa de Servicios Web Servidor Web Capa de lógica de Negocio Capa de Administración de datos Servidor de Aplicaciones del Municipio Servidor de Bases de Datos del Municipio 21 Proceso de Arquitectura de Software : Patrones de Arquitectura Messaging Client Queue Server Cliente Cola Servidor 22 11
12 Patrones de Arquitectura: Messaging Las propiedades clave de este patrón son: Comunicaciones asincrónicas: Los clientes envían las peticiones a la cola, donde los mensajes son almacenados hasta que una aplicación los remueve. Después que el cliente ha escrito un mensaje en la cola, continúa trabajando sin esperar que el mensaje sea removido. Calidad del Servicio (QoS) Configurable: La cola puede ser configurada para alta velocidad, noconfiable o baja, entrega confiable. Las operaciones de la cola se pueden coordinar con las transacciones de la base de datos. Libre de Acoplamiento: No hay binding (ligadura/atadura) directo entre clientes y servidores. 23 Atributo de calidad Patrones de Arquitectura: Messaging Características Disponibilidad Manejo de Fallas Cambiabilidad Las colas físicas con el mismo nombre lógico se pueden replicar a través de diferentes instancias de servidores messaging. Cuando una falla, los clients envían los mensajes a la réplica de la cola. Si un cliente se está comunicando con una cola que falla, puede encontrar una réplica de la cola y colocar el mensaje allí. Messaging es inherentemente libre de acoplamientos y promueve la alta cambiabilidad ya que clientes y servidores no están directamente sujetos a través de una interfaz. Cambiar el formato de los mensajes enviados por los clientes pueden causar cambios en las implementaciones de los servidores. Los formatos de mensajes autodefinidos pueden ayudar a reducir esta dependencia
13 Atributo de calidad Patrones de Arquitectura: Messaging Características Rendimiento Escalabilidad La tecnología de cola de mensajes puede entregar miles de mensajes por segundo. Los mensajes noconfiables son más rápidos que los confiables, con la diferencia dependiente de la calidad de tecnología de mensajería utilizada. Las colas pueden ser alojadas en los puntos finales de comunicación o ser replicados a través de clusters de servidores de mensajes alojados en un único o en múltiples equipos servidores. Esto lo hace una solución altamente escalable. 25 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Messaging Sistema HCU Provincial (Historia Clínica Unificada) Sistemas Centros Médicos Regionales Cola Replicar/Sincronizar Servidor de Aplicaciones Sistema HCU BD Replicar Información de consultas atendidas y datos de pacientes de los centros de salud a la base de datos del Ministerio de Salud de la Provincia
14 Proceso de Arquitectura de Software : Patrones de Arquitectura Publish Suscribe Publisher Topic Suscriber Publicante Tópico Suscriptor 27 Patrones de Arquitectura: Publish-Suscribe Las propiedades clave de este patrón son: Mensajería Muchos-a-Muchos: Los mensajes publicados son enviados a todos los suscriptores que se han registrado en un tópico. Muchos publicantes pueden publicar sobre el mismo tópico y muchos suscriptores pueden escuchar sobre el mismo tópico. Calidad del Servicio (QoS) Configurable: Además de los mensajes no-confiables y confiables, el mecanismo de comunicación puede ser punto-a-punto o broadcast/multicast. El primero envía un mensaje diferente para cada suscriptor en un tópico, el otro envía un mensaje que cada suscriptor recibe. Libre de Acoplamiento: Al igual que messaging, no hay ligaduras ( binding ) entre publicantes y suscriptores. Los publicantes no conocen quién recibe sus mensajes, y los suscriptores no conocen qué publicante envió el mensaje
15 Patrones de Arquitectura: Publish-Suscribe Atributo de calidad Características Disponibilidad Manejo de Fallas Cambiabilidad Los tópicos con el mismo nombre lógico pueden ser replicados en diferentes instancias de servidores administrados como un cluster. Cuando uno falla, los publicantes envían los mensajes a las réplicas. Si un publicante se está comunicando con un tópico alojado en un servidor que falla, puede encontrar un servidor réplica y enviar el mensaje allí. Publish-subscribe es inherentemente libre de acoplamiento promueve la alta cambiabilidad. Nuevos publicantes y suscriptores pueden agregarse al sistema sin cambiar la arquitectura o la configuración. Cambios en el formato de los mensajes publicados pueden causar cambios en las implementaciones de los suscriptores. 29 Patrones de Arquitectura: Publish-Suscribe Atributo de calidad Rendimiento Escalabilidad Características Publish-subscribe puede entregar miles de mensajes por segundo, con mensajes no-confiables más rápido que con los confiables. Si el broker publish-subscribe soporta multicast/broadcast, entregará múltiples mensajes en un tiempo más uniforme a cada suscriptor. Los tópicos pueden estar replicados a través de clusters de servers alojados en un único o en múltiples equipos servidores. Los clusters de servidores pueden escalarse para proveer un muy alto volumen de entrega de mensajes. También las soluciones multicast/ broadcast se escalan mejor que sus contrapartes punto-a-punto
16 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Publish Suscribe Sistema de notificaciones de tarjeta de débito Consultas de saldo Gestión de Compras Gestión de Novedades Tópico Generación de avisos Servicio de notificaciones por correo electrónico Servicio de notificaciones por celular Publicantes Tópico Suscriptores 31 Proceso de Arquitectura de Software : Patrones de Arquitectura Broker: Sender-1 inport 1 Sender-2 inport 2 OutPort 1 Receiver-1 Broker Receiver-2 OutPort 2 Remitente Broker Receptor 32 16
17 Patrones de Arquitectura: Broker Las propiedades clave de este patrón son: Arquitectura Hub-and-spoke (Eje-rayo): El broker actúa como un hub de mensajería (eje) y los Remitentes y Receptores se conectan como rayos (como en una rueda de bicicleta). Las conexiones con el broker son a través de puertos que están asociados con un formato de mensaje específico. Realiza ruteo de mensaje: El broker embebe la lógica de procesamiento para entregar un mensaje recibido en un puerto de entrada en un puerto de salida. El camino de entrega puede estar en el código o depender de valores en el mensaje de entrada. Realiza transformación del mensaje: La lógica del broker transforma el tipo de mensaje fuente recibido en el puerto de entrada al tipo de mensaje de destino requerido en el puerto de salida. 33 Atributo de calidad Disponibilidad Manejo de Fallas Cambiabilidad Patrones de Arquitectura: Broker Características Para construir arquitecturas con alta disponiblidad, los brokers deber estar replicados. Esto es típicamente soportado utilizando mecanismos similares al cluster de servidores del messaging y publish-subscribe Como los brokers tienen puertos de entrada de tipos definidos, validan y descartan cualquier mensaje enviado en un formato erróneo. Con Brokers replicados, los remitentes pueden sobrellevar una falla dirigiéndose a una réplica del broker en falla. Los Brokers separan la lógica de transformación y de ruteo del mensaje desde los remitentes a los receptores. Esto mejora la cambiabilidad ya que cambios en la lógica de ruteo o transformación pueden hacerse sin afectar a los remitentes o receptores
18 Atributo de calidad Patrones de Arquitectura: Broker Características Rendimiento Escalabilidad Los Brokers pueden potencialmente convertirse en cuellos de botella especialmente si deben manejar grandes volúmenes de mensajes y ejecutar lógica de transformaciones complejas. Su rendimiento será típicamente más bajo que un messaging simple con entrega confiable. Reunir en clusters instancias de Brokers hace posible construir sistemas escalables para manejar grandes cargas de peticiones. Los Brokers se adaptan a aplicaciones en las cuales los componentes intercambian mensajes que requieren una extensa transformación entre los formatos fuente y destino. 35 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Broker: Sistema de Información Radiológica (RIS) Sistema de reconocimiento interactivo de voz Captura de imágenes BD Pacientes Y consultas Puertos de entrada RIS (protocolo HL7) Puertos de salida Generador de reportes Almacenamiento formato texto Almacenamiento de imágenes (distintos formatos) Almacenamiento de sonido (distintos formatos) Remitentes Broker Receptores 36 18
19 Proceso de Arquitectura de Software : Patrones de Arquitectura Process Cordinator Start process request Process Cordinator Process result Paso 1 Paso 2 Paso 3 Paso 4 Server-1 Server-2 Server-3 Server-4 37 Patrones de Arquitectura: Process Cordinator Las propiedades clave de este patrón son: Encapsulamiento de Proceso: El coordinador de proceso encapsula la secuencia de pasos necesaria para completar un proceso de negocio. La secuencia puede ser arbitrariamente compleja. El coordinador es un único punto de definición para el proceso de negocio, haciendo fácil su comprensión y modificación. Recibe la petición de inicio del proceso, llama a los servidores en el orden definido por el proceso y emite los resultados. Libre de Acoplamiento: Los componentes servidores son inconcientes de su rol en todo el proceso de negocio y del orden de los pasos en el proceso. Los servidores simplemente definen un conjunto de servicios que deben realizar y el coordinador los llama como una parte necesaria del proceso de negocio. Comunicaciones flexibles: Las comunicaciones entre el coordinador y los servidores pueden ser sincrónicas o asincrónicas. Para comunicaciones sincrónicas el coordinador espera hasta que los servidores responden. Para las comunicaciones asincrónicas el coordinador provee un mecamismo de callback o queue/topic y espera hasta que el servidor responda utilizando el mecanismo definido
20 Patrones de Arquitectura: Process Cordinator Atributo de calidad Disponibilidad Características El coordinador es un único punto de falla. De ahí que necesite ser replicado para crear una solución con alta disponiblidad. Manejo de Fallas Cambiabilidad El manejo de fallas es complejo, puede ocurrir en cualquier etapa de la coordinación del proceso de negocio. Una falla en los últimos pasos en el proceso puede requerir que los primeros pasos sean deshechos usando transacciones de compensación. El manejo de fallas necesita un diseño cuidadoso para asegurar que los datos mantenidos en los servidores sigan siendo consistentes. La cambiabilidad del proceso se favorece porque la definición del proceso está encapsulada en el Coordinador de Procesos. Los servidores pueden cambiar su implementación sin afectar al coordinador o a los otros servidores mientras que la definición del servicio externamente no cambie. 39 Patrones de Arquitectura: Process Cordinator Atributo de calidad Características Rendimiento Escalabilidad Para proporcionar alto rendimiento el coordinador debe poder manejar múltiples peticiones concurrentes y administrar el estado de cada una a medida que progresan a través del proceso. También, el rendimiento de cualquier proceso está limitado por los pasos más lentos (denominados los servidores lentos en el proceso). El coordinador puede ser replicado para escalar la aplicación. El patrón Coordinador de Proceso es comúnmente utilizado para implementar procesos de negocio complejos que deben resolver peticiones de varios componentes de servidores diferentes 40 20
21 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Process Cordinator Start process request Paso 1 Sistema Bancario Gestión de Préstamos Paso 2 Paso 3 Process result Paso 4 Server Solicitudes Server Evaluación Financiera Server Riesgo crediticio Server Liquidaciones 41 Documentar la Arquitectura de Software Razones para documentar nuestras arquitecturas: Otras personas pueden comprender y evaluar el diseño. Esto incluye cualquiera de los stakeholders, pero más comúnmente otros miembros del equipo de diseño. Podemos comprender el diseño cuando retornamos a él después de un período de tiempo. Otras personas del equipo de proyecto y de la organización de desarrollo pueden aprender sobre la arquitectura asimilando los conceptos detrás del diseño. Podemos hacer análisis sobre el diseño, tal vez para valorar su probable rendimiento 42 21
22 Documentar la Arquitectura de Software Por otro lado documentar las arquitecturas, puede ser problemático porque : No hay una forma de documentación estándar universalmente aceptada. Una arquitectura puede ser compleja y documentarla en una manera comprensible es tiempo consumido y no de manera trivial. Una arquitectura tiene varias vistas posibles. Documentar todas las potencialmente útiles es tiempo consumido y costoso. Un diseño de la arquitectura frecuentemente evoluciona a medida que el sistema se desarrolla incrementalmente y se gana más conocimiento sobre el dominio de problema. 43 Vistas Arquitectónicas Utilizaremos algunos de los diagramas provistos por UML 2.0 para representar las vistas arquitectónicas más significativas. Diagramas de Casos de Uso Diagramas de Estructura Compuesta Diagrama de Despliegue Se pueden utilizar también diagramas de clases pero sin entrar en detalles innecesarios a nivel del diseño arquitectónico y diagramas de secuencia para modelar el comportamiento de los componentes en una arquitectura. Vistas Arquitectónicas 44 22
23 Vistas Arquitectónicas Vistas de la arquitectura: Vista Arquitectónica de la Funcionalidad: Casos de Uso significativos para la Arquitectura Vista Arquitectónica del Diseño: Subsistemas e Interfaces Vista Arquitectónica del Despliegue: Nodos y Componentes principales Vista Arquitectónica del Despliegue: Niveles de Hardware Ejemplo Vistas Arquitectónicas 45 Documento de Arquitectura Plantilla para Documentación de la Arquitectura: Nombre del proyecto: XXX 1 Contexto del Proyecto 2 Requerimientos de la Arquitectura 2.1 Descripción general de los objetivos clave. 2.2 Casos de Uso significativos para la arquitectura. 2.3 Requerimientos de Arquitectura de los Stakeholders 2.4 Restricciones 2.5 Requerimientos No Funcionales 2.6 Riesgos Vistas Arquitectónicas 46 23
24 Documento de Arquitectura Plantilla para Documentación de la Arquitectura (continuación): 3 Solución 3.1 relevantes. 3.2 Descripción general de la Arquitectura 3.3 Vistas Estructurales 3.4 Vistas de Comportamiento 3.5 Beneficios de Implementación 4 Análisis de la Arquitectura 4.1 Análisis de escenarios 4.2 Riesgos Vistas Arquitectónicas 47 Bibliografía Gorton Ian, Essential Sofware Architecture (2006), Springer. Patrones y Vistas Arquitectónicas 48 24
25 Anexo Componente Un componente se puede mostrar por uno o más artefactos. Un componente se dibuja como un cuadro con el estereotipo <component> y/o un ícono de componente. Los componentes pueden tener interfaces provistas y requeridas y puertos. Un componente puede tener una estructura interna. Puede mostrar las partes anidadas dentro del componente, así como sus interfaces provistas y requeridas. Vistas Arquitectónicas 49 Anexo Componente Modelado de componentes: Partes del componente Interfaces requeridas Interfaces provistas Otra vista de los componentes: Vista externa de los componentes: Vistas Arquitectónicas 50 25
26 Anexo Estructura interna de los Componentes Para modelar la estructura interna de los componentes utilizamos el Diagrama de Estructura Compuesta. Interfaz provista Interfaz requerida 51 DSI 3K3 - Vistas Arquitectónicas Anexo Componentes y Artefactos Un componente puede englobar, como en el ejemplo, la clase contexto, la interfaz estrategia y las clases que implementan la estrategia y se realizan por un solo artefacto que contiene código fuente. Vistas Arquitectónicas 52 26
27 Anexo Estereotipos de Componente Build Component Entity Implementation Specification Process Estereotipo Significado Un componente que define un conjunto de elementos para fines organizativos o de desarrollo a nivel sistema. Un componente de información persistente que representa un concepto de negocio. Una definición de componentes que no tiene especificación. Es un implementación para una <specification>. Un clasificador que especifica un dominio de objetos sin definir implementación física, sólo indica interfaces proporcionadas y requeridas. Un componente basado en transacción Service Subsystem Un componente funcional sin estado que computa un valor. Una unidad de descomposición jerárquica para grandes sistemas. Vistas Arquitectónicas 53 27
Capítulo 5. Cliente-Servidor.
Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor
Más detallesProceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:
PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo
Más detallesArquitectura de sistema de alta disponibilidad
Mysql Introducción MySQL Cluster esta diseñado para tener una arquitectura distribuida de nodos sin punto único de fallo. MySQL Cluster consiste en 3 tipos de nodos: 1. Nodos de almacenamiento, son los
Más detallesPatrones de software y refactorización de código
Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.
Más detallesUNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos
2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven
Más detalles3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)
3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.
Más detallesARC 101 Architecture Overview Diagram
ARC 101 Architecture Overview Diagram Estudio de Arquitectura para la evolución tecnológica de los aplicativos de ATyR Banco de Previsión Social ATYR Evolución Tecnológica Pág 1 of 10 Tabla de Contenidos
Más detallesElementos requeridos para crearlos (ejemplo: el compilador)
Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción
Más detallese-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red.
Comercio electrónico. (e-commerce) Las empresas que ya están utilizando la red para hacer comercio ven como están cambiando las relaciones de la empresa con sus clientes, sus empleados, sus colaboradores
Más detallesLICITACIÓN N L13045 NUEVO SISTEMA LEY DE TRANSPARENCIA
LICITACIÓN N L13045 NUEVO SISTEMA LEY DE TRANSPARENCIA ACLARACIONES Y RESPUESTAS A CONSULTAS SEGUNDA PARTE De acuerdo a lo señalado en el numeral 11 de las Bases de Licitación, a continuación se presenta
Más detalles4. Programación Paralela
4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios
Más detallesEmpresa Financiera Herramientas de SW Servicios
Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través
Más detalles3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE
3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar
Más detallesLos mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:
SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas
Más detallesPRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE
PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,
Más detallesARQUITECTURA DE DISTRIBUCIÓN DE DATOS
4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia
Más detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer
Más detalles<Generador de exámenes> Visión preliminar
1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,
Más detallesFigure 7-1: Phase A: Architecture Vision
Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como
Más detallesWorkflows? Sí, cuántos quiere?
Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención
Más detallesEntidad Formadora: Plan Local De Formación Convocatoria 2010
Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú
Más detallesMetodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales
Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com
Más detallesIntroducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com
Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.
Más detallesSistema de SaaS (Software as a Service) para centros educativos
Sistema de SaaS (Software as a Service) para centros educativos Definiciones preliminares: Qué es SaaS? SaaS (1) es un modelo de distribución del software que permite a los usuarios el acceso al mismo
Más detallesWindows Server 2012: Infraestructura de Escritorio Virtual
Windows Server 2012: Infraestructura de Escritorio Virtual Módulo 1: Application Virtualization Módulo del Manual Autores: James Hamilton-Adams, Content Master Publicado: 5 de Octubre 2012 La información
Más detallesBPMN Business Process Modeling Notation
BPMN (BPMN) es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes
Más detallesPatrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms
Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura
Más detallesCapítulo V. Implementación
Capítulo V Implementación En este capítulo se especifican los recursos utilizados en la implementación de la interfaz, así como se describe su arquitectura funcional y las características principales.
Más detallesGestión de la Configuración
Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de
Más detallesGLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.
GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.
Más detalles1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).
1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada
Más detallesNovedades en Q-flow 3.02
Novedades en Q-flow 3.02 Introducción Uno de los objetivos principales de Q-flow 3.02 es adecuarse a las necesidades de grandes organizaciones. Por eso Q-flow 3.02 tiene una versión Enterprise que incluye
Más detallesInteroperabilidad de Fieldbus
2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en www.plantwebuniversity.com. Fieldbus 201 Interoperabilidad de Fieldbus Generalidades Qué es interoperabilidad?
Más detallesSISTEMAS DE INFORMACIÓN II TEORÍA
CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR
Más detallesADMINISTRACIÓN CENTRALIZADA DELL POWERVAULT DL2000 CON TECNOLOGÍA SYMANTEC
ADMINISTRACIÓN CENTRALIZADA DELL POWERVAULT DL2000 CON TECNOLOGÍA SYMANTEC RESUMEN EJECUTIVO Es un método ideal para que cualquier departamento de TI logre realizar respaldos y restauraciones más rápidas
Más detallesCapítulo VI. Estudio de Caso de Aplicación del Integrador de Información Desarrollado
Capítulo VI Estudio de Caso de Aplicación del Integrador de Información Desarrollado 6.1 Organización elegida La Organización elegida para el caso de aplicación, es la empresa CTM Tours del grupo Costamar,
Más detallesMicrosoft SQL Server Conceptos.
Microsoft Conceptos. Microsoft 2005 es una plataforma de base de datos a gran escala de procesamiento de transacciones en línea (OLTP) y de procesamiento analítico en línea (OLAP). La siguiente tabla muestra
Más detallesInfraestructura Tecnológica. Sesión 1: Infraestructura de servidores
Infraestructura Tecnológica Sesión 1: Infraestructura de servidores Contextualización La infraestructura de cualquier servicio o mecanismo es importante, define el funcionamiento de los elementos en que
Más detallesCAPÍTULO 3 Servidor de Modelo de Usuario
CAPÍTULO 3 Servidor de Modelo de Usuario Para el desarrollo del modelado del estudiante se utilizó el servidor de modelo de usuario desarrollado en la Universidad de las Américas Puebla por Rosa G. Paredes
Más detallesIntroducción a las redes de computadores
Introducción a las redes de computadores Contenido Descripción general 1 Beneficios de las redes 2 Papel de los equipos en una red 3 Tipos de redes 5 Sistemas operativos de red 7 Introducción a las redes
Más detallesPropuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA
Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)
Más detallesM.T.I. Arturo López Saldiña
M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil
Más detalles6.8 La Arquitectura del Sistema. [Proceso]
6.8 La Arquitectura del Sistema. [Proceso] En el Caso de Estudio se ha hecho énfasis en los objetos del Dominio del problema, ya que representan la esencia del sistema y definen su comportamiento. Sin
Más detallesInfraestructura Tecnológica. Sesión 5: Arquitectura cliente-servidor
Infraestructura Tecnológica Sesión 5: Arquitectura cliente-servidor Contextualización Dentro de los sistemas de comunicación que funcionan por medio de Internet podemos contemplar la arquitectura cliente-servidor.
Más detallesCMMI (Capability Maturity Model Integrated)
CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla
Más detallesMarco Normativo de IT
Marco Normativo de IT PC0901 - Proceso de control de cambios en software de aplicación provisto por Organismos Gobierno de la Ciudad Autónoma de Buenos Aires PC0901 - Proceso de control de cambios en software
Más detallesAnálisis y diseño del sistema CAPÍTULO 3
Análisis y diseño del sistema CAPÍTULO 3 36 CAPÍTULO 3 Análisis y diseño del sistema En este capítulo se pretende realizar un análisis detallado de los requerimientos del software a desarrollar para la
Más detallesGestión y Desarrollo de Requisitos en Proyectos Software
Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería
Más detallesJAVA EE 5. Arquitectura, conceptos y ejemplos.
JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones
Más detallesProcesos Críticos en el Desarrollo de Software
Metodología Procesos Críticos en el Desarrollo de Software Pablo Straub AgileShift Imagine una organización de desarrollo de software que consistentemente cumple los compromisos con sus clientes. Imagine
Más detallesFundamentos del diseño 3ª edición (2002)
Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software
Más detallesUnidad III. Software para la administración de proyectos.
Unidad III Software para la administración de proyectos. 3.1 Herramientas de software para administrar proyectos. El software de administración de proyectos es un concepto que describe varios tipos de
Más detalles2 EL DOCUMENTO DE ESPECIFICACIONES
Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir
Más detallesPrimer avance de proyecto de software para la gestión de inscripciones en cursos
Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados
Más detallesSoporte y mantenimiento. Generalidades
Soporte y mantenimiento Generalidades 2014 Tabla de Contenido 1 Introducción... 3 2 Objetivos generales... 3 3 Caso de soporte... 3 4 Condiciones... 4 5 Restricciones... 5 6 Sistema de soporte... 5 Página
Más detallesIngeniería de Software. Pruebas
Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en
Más detallesEstilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura
Estilos de Arquitectura y Patrones de Diseño Arquitectónico Gastón Mousqués - AR 1 Patrones de Arquitectura Gastón Mousqués - AR 2 Principales Categorías de Patrones (Software) Patrones de Análisis Expresan
Más detallesCONSTRUCCIÓN DEL PROCESO TRANSACCIONAL Bizagi Process Modeler
Bizagi Process Modeler Copyright 2011 - bizagi Contenido 1. INTRODUCCIÓN A LAS TRANSACCIONES... 3 2. DIAGRAMA DEL PROCESO... 4 SUB PROCESO RESERVA... 5 SUB PROCESO REPORTE DE GASTOS... 8 3. MODELO DE DATOS...
Más detallesSistema de Mensajería Empresarial para generación Masiva de DTE
Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE
Más detallesLa Pirámide de Solución de TriActive TRICENTER
Información sobre el Producto de TriActive: Página 1 Documento Informativo La Administración de Sistemas Hecha Simple La Pirámide de Solución de TriActive TRICENTER Información sobre las Soluciones de
Más detallesTópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN
Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.
Más detallesDocumento Técnico Gerardo Barcia Jonathan Trujillo María Alejandra Uribe
Documento Técnico Gerardo Barcia Jonathan Trujillo María Alejandra Uribe Índice de contenido 1. Introducción...3 2. El modelo de negocio...3 2.1 Antecedentes...3 2.2 Planteamiento del problema actual...3
Más detallesPEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO
PEEPER Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la compañía de
Más detallescomputadoras que tienen este servicio instalado se pueden publicar páginas web tanto local como remotamente.
Investigar Qué es un IIS? Internet Information Services o IIS es un servidor web y un conjunto de servicios para el sistema operativo Microsoft Windows. Originalmente era parte del Option Pack para Windows
Más detallesPlaneación del Proyecto de Software:
Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los
Más detallesCRM Gestión de Oportunidades Documento de Construcción Bizagi Process Modeler
Bizagi Process Modeler Copyright 2011 - Bizagi Tabla de Contenido CRM- Gestión de Oportunidades de Venta... 4 Descripción... 4 Principales Factores en la Construcción del Proceso... 5 Modelo de Datos...
Más detallesSERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO
SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3
Más detallesSIGPRE Sistema de Gestión Presupuestaria
SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009
Más detallesWINDOWS 2008 5: TERMINAL SERVER
WINDOWS 2008 5: TERMINAL SERVER 1.- INTRODUCCION: Terminal Server proporciona una interfaz de usuario gráfica de Windows a equipos remotos a través de conexiones en una red local o a través de Internet.
Más detalleshttp://www.statum.biz http://www.statum.info http://www.statum.org
ApiaMonitor Monitor de Infraestructura BPMS Por: Ing. Manuel Cabanelas Product Manager de Apia Manuel.Cabanelas@statum.biz http://www.statum.biz http://www.statum.info http://www.statum.org Abstract A
Más detallesCapítulo 1 Introducción
Capítulo 1 Introducción Dentro de los muchos campos que abarca la universidad para la investigación científica, se encuentra el de los Sistemas de Información Geográfica (SIG). Para ello, cuenta con el
Más detallesCapítulo IV. Manejo de Problemas
Manejo de Problemas Manejo de problemas Tabla de contenido 1.- En qué consiste el manejo de problemas?...57 1.1.- Ventajas...58 1.2.- Barreras...59 2.- Actividades...59 2.1.- Control de problemas...60
Más detallesServidores Donantonio
Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3
Más detallesOMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento
OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje
Más detallesUna puerta abierta al futuro
Una puerta abierta al futuro SOA E ITIL EN LA LEY DE ACCESO ELECTRÓNICO DE LOS CIUDADANOS A LOS SERVICIOS PÚBLICOS (LAECSP) por francisco javier antón Vique La publicación de la Ley de Acceso electrónico
Más detallesLINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN
LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN Tabla de Contenidos LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN... 1 Tabla de Contenidos... 1 General... 2 Uso de los Lineamientos Estándares...
Más detallesIngeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML
Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo
Más detallesITIL FOUNDATION V3 2011
ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la
Más detallesGestión de Oportunidades
Gestión de Oportunidades Bizagi Suite Gestión de Oportunidades 1 Tabla de Contenido CRM Gestión de Oportunidades de Negocio... 4 Elementos del Proceso... 5 Registrar Oportunidad... 5 Habilitar Alarma y
Más detallesSoporte y mantenimiento. Generalidades
Soporte y mantenimiento Generalidades Tabla de Contenido 1. Introducción 2. Objetivos generales 3. Caso de soporte 4. Condiciones 5. Restricciones 6. Sistema de soporte Soporte y mantenimiento 1. Introducción
Más detallesSoporte Técnico de Software HP
Soporte Técnico de Software HP Servicios Tecnológicos HP Servicios contractuales Datos técnicos El Soporte Técnico de Software HP ofrece servicios integrales de soporte remoto de para los productos de
Más detallesCONSEJO DE NORMALIZACIÓN Y CERTIFICACIÓN DE COMPETENCIA LABORAL NORMAS TÉCNICAS DE COMPETENCIA LABORAL
I. Datos Generales de la Calificación CINF0286.01 Título Análisis y diseño de redes de datos Propósito Proporcionar un referente para evaluar la competencia en las funciones relativas al análisis y diseño
Más detallesResumen General del Manual de Organización y Funciones
Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de
Más detallesMACROPROCESO GESTIÓN TECNOLÓGICA
Versión 1.0 Página 1 de 5 1. OBJETIVO Suministrar las fases para la puesta en producción de aplicaciones y sistemas de información desarrollados o adquiridos por el Instituto Colombiano de Bienestar Familiar
Más detallesUnidad 1. Fundamentos en Gestión de Riesgos
1.1 Gestión de Proyectos Unidad 1. Fundamentos en Gestión de Riesgos La gestión de proyectos es una disciplina con la cual se integran los procesos propios de la gerencia o administración de proyectos.
Más detallesTesting. Tipos, Planificación y Ejecución de Pruebas
Testing Tipos, Planificación y Ejecución de Pruebas Contenido Definiciones del Testing de Software Objetivos, conceptos Tipos de Test Testing a-la RUP Rol del Testing en el proceso Artefactos Trabajadores
Más detallesVisión General de GXportal. Última actualización: 2009
Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de
Más detallesSAP BusinessObjects Edge BI Standard Package La solución de BI preferida para. Empresas en Crecimiento
SAP BusinessObjects Edge BI Standard Package La solución de BI preferida para Empresas en Crecimiento Portfolio SAP BusinessObjects Soluciones SAP para Empresas en Crecimiento Resumen Ejecutivo Inteligencia
Más detallesCapítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema
Capítulo2 Planteamientodelproblema 38 2.1Antecedentesycontextodelproyecto En lo que respecta a los antecedentes del proyecto, se describe inicialmente el contexto donde se utiliza el producto de software.
Más detallesPrácticas ITIL para un mejor flujo de trabajo en el helpdesk
Prácticas ITIL para un mejor flujo de trabajo en el helpdesk Se diferencia tres partes de gestión para mejorar la resolución de las incidencias de soporte técnico según el marco ITIL: 1. Gestión de Incidencias
Más detallesPortal de Compras del Gobierno del Estado de Baja California (www.comprasbc.gob.mx) A. Antecedentes
Buenas prácticas en la implementación de las recomendaciones de la Guía para Mejorar la Calidad Regulatoria de Trámites Estatales y Municipales e Impulsar la Competitividad de México Portal de Compras
Más detallesTELECOMUNICACIONES Y REDES
TELECOMUNICACIONES Y REDES Redes Computacionales I Prof. Cristian Ahumada V. Unidad V: Capa de Red OSI 1. Introducción. 2. Protocolos de cada Red 3. Protocolo IPv4 4. División de Redes 5. Enrutamiento
Más detallesGUÍA DE SEGURIDAD DE LA INFORMACIÓN GUÍA GOBIERNO CORPORATIVO PARA EMPRESAS SEP
GUÍA DE SEGURIDAD DE LA INFORMACIÓN GUÍA GOBIERNO CORPORATIVO PARA EMPRESAS SEP 1. Introducción La información puede adoptar o estar representada en diversas formas: impresa o escrita (papeles de trabajo,
Más detallesArquitectura. 1.- Aplicaciones Web. Definición. Arquitectura clásica. Contenidos. 1.- Aplicaciones Web
Arquitectura 1.- Aplicaciones Web Definición Contenidos 1.- Aplicaciones Web 2.- Arquitectura de aplicaciones Web Lo que distingue una aplicación Web de una mero sitio Web reside en la posibilidad que
Más detallesRequerimientos Técnicos para mantenimiento anual de certificación del Área Perimetral
Requerimientos Técnicos para mantenimiento anual de certificación del Área Perimetral Trabajo a realizar Cotización de mantenimiento anual de certificación de seguridad informática para el área perimetral
Más detallesAnexo 4 Documento de Arquitectura
Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de
Más detallesGuía de uso del Cloud Datacenter de acens
guíasdeuso Guía de uso del Cloud Datacenter de Calle San Rafael, 14 28108 Alcobendas (Madrid) 902 90 10 20 www..com Introducción Un Data Center o centro de datos físico es un espacio utilizado para alojar
Más detallesIntroducción a la Firma Electrónica en MIDAS
Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento
Más detallesEjercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO
Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software
Más detalles