Trabajo de Investigación

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Trabajo de Investigación"

Transcripción

1 Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un sistema y su incorporación en ArchE para la mejora del análisis, evaluación y soporte en la toma de decisiones durante el desarrollo arquitectónico Alumno: Jesús Martín Fernández septiembre 2010

2 Tabla de contenidos 1. Introducción 2. El Ciclo de las Arquitecturas de Negocio (ABC) 3. Comprendiendo la Arquitectura Software 4 Comprendiendo los atributos de calidad del software: 4.1 Funcionalidad y arquitectura 4.2 Los escenarios de atributos de calidad 4.3 Los principales atributos de calidad en detalle 5 El Proceso de la Arquitectura Software 5.1 Establecer los Requisitos Software 5.2 Diseño de la Arquitectura 5.3 Validación del Diseño 5.4 El Diseño Dirigido por Atributos de Calidad (ADD) 6 Cómo alcanzar los atributos de calidad 6.1 Tácticas arquitectónicas de disponibilidad 6.2 Tácticas arquitectónicas de rendimiento/desempeño 6.3 Tácticas arquitectónicas de modificabilidad 6.4 Tácticas arquitectónicas de seguridad 6.5 Tácticas arquitectónicas de usabilidad 6.6 Tácticas arquitectónicas de testeabilidad 7 Comprendiendo los Patrones Arquitectónicos en términos de Tácticas y Modelos 8 Diseño de la Arquitectura Software con ArchE 8.1 ArchE como sistema experto 8.2 Conceptos clave 8.3 Actividades básicas 8.4 Marcos de razonamiento: creando modelos de atributos de calidad 9 Utilizando ArchE en un caso práctico: CTAS 9.1 Descripción del caso práctico 9.2 Casos de uso 9.3 Especificación de los requisitos y sus relaciones en ArchE 9.4 Ejemplos prácticos 9.5 Valoración de ArchE 10 Conclusiones Referencias 1

3 Lista de Figuras Figura 1: Figura 2: Figura 3: Figura 4: Figura 5: Figura 6: Figura 7: Figura 8: Figura 9: Figura 10: Figura 11: Figura 12: Figura 13: Figura 14: Figura 15: Figura 16: Figura 17: Figura 18: Figura 19: Figura 20: Figura 21: Figura 22: Figura 23: Figura 24: Figura 25 Figura 26 Figura 27 Figura 28 Figura 29 Figura 30 Figura 31 Figura 32 Figura 33 El Ciclo de las Arquitecturas de Negocio Relaciones entre los conceptos Modelo de Referencia, Patrón Arquitectónico, Arquitectura de Referencia y Arquitectura Software Modelo Arquitectónico de 4+1 Vistas de Philippe Kruchten Relación entre las arquitecturas software, los atributos de calidad, los objetivos de negocio y la funcionalidad del sistema Partes de los escenarios de calidad El Proceso de la Arquitectura Software Entradas y salidas en la determinación de los requisitos arquitectónicos Entradas y salidas en el diseño de la arquitectura El modelo de ciclo de vida de la arquitectura software Los pasos del Diseño Dirigido por Atributos de Calidad (ADD) Utilización de tácticas para controlar los estímulos Resumen de las tácticas de disponibilidad Resumen de las tácticas de rendimiento Resumen de las tácticas de modificabilidad Resumen de las tácticas de seguridad Resumen de las tácticas de usabilidad Resumen de las tácticas de testeabilidad Estructura del patrón intermediario Estructura del patrón modelo-vista-controlador Estructura del patrón micro-núcleo Estructura del patrón reflexión Flujo global en ArchE Conceptos clave en ArchE y sus relaciones Implementación de un marco de razonamiento Estructura arquitectónica del sistema ArchE Diagrama de secuencia de la interacción entre ArchE y los marcos de razonamiento Diagrama de casos de uso de CTAS Relación de escenarios de CTAS Pantalla de ArchE para añadir/modificar una relación entre responsabilidades Modelo inicial propuesto por ArchE para CTAS Gráfico inicial de responsabilidades del sistema CTAS Vista de Evaluación de Resultados de CTAS Vista de evaluación de resultados mostrando la evaluación de resultados de aplicar las tácticas sobre los escenarios 2

4 Figura 34 Vista de evaluación inicial de resultados del ejemplo 1 Figura 35 Vista de evaluación de resultados del ejemplo 1 después de la primera iteración Figura 36 Vista de evaluación de resultados del ejemplo 1 después de la segunda iteración Figura 37 Modelo final propuesto por ArchE para el ejemplo 1 Figura 38 Figura 39 Pantalla de ArchE para añadir o modificar un escenario Vista de mapeos entre escenarios y responsabilidades Figura 40 Pantalla de ArchE para añadir o modificar un mapeo entre un escenario y una responsabilidad Figura 41 Modelo final propuesto por ArchE para el ejemplo 2 Figura 42 Gráfico final de responsabilidades del ejemplo 2 3

5 Lista de Tablas Tabla 1: Comparativa entre estilo arquitectónico y patrón arquitectónico Tabla 2: Actores del sistema CTAS Tabla 3: Atributos de calidad del sistema CTAS Tabla 4: Relación de casos de uso del sistema CTAS por actor Tabla 5: Relación de funciones del sistema CTAS Tabla 6: Relación de responsabilidades del sistema CTAS Tabla 7: Mapeo de escenarios a responsabilidades Tabla 8: Tabla de generación de escenarios generales de modificabilidad Tabla 9 Tabla de generación de escenarios generales de rendimiento Tabla 10 Relación de preguntas formuladas por ArchE para el diseño inicial del sistema CTAS Tabla 11 Descripción del escenario del ejemplo 2 Tabla 12 Descripción del escenario del ejemplo 3 Tabla 13 Descripción del escenario del ejemplo 4 Tabla 14 Descripción del escenario del ejemplo 5 Tabla 15 Descripción del escenario del ejemplo 6 4

6 1. Introducción La arquitectura del software está reconocida desde hace ya algunos años como una disciplina crucial en la ingeniería del software. De hecho, la arquitectura del software de un sistema se considera como clave en la comunicación y en la comprensión del sistema. Pero el proceso de análisis y diseño de la arquitectura del software es complejo. Las arquitecturas están determinadas por requisitos, tanto funcionales como de atributos de calidad, que a su vez están fuertemente condicionados por los objetivos de negocio de la organización y por sus restricciones. La introducción de los patrones arquitectónicos permitió gestionar mejorar el proceso de diseño de la arquitectura software y reducir la complejidad de la tarea. Sin embargo, aunque los patrones arquitectónicos han ayudado mucho en el diseño arquitectónico, estos patrones siguen siendo complejos y en cualquier caso siguen existiendo muchos detalles por resolver, como son por ejemplo las interacciones entre los distintos patrones. Los objetivos de este trabajo son múltiples. En primer lugar describir cómo los atributos de calidad ejercen una influencia decisiva sobre el diseño arquitectónico de los sistemas software. En segundo lugar mostrar cómo estos atributos de calidad pueden ser codificados de forma que puedan ser utilizados para analizar las arquitecturas y tomar mejores decisiones en el diseño arquitectónico. En tercer lugar analizar cómo la utilización de tácticas arquitectónicas y el diseño dirigido por atributos de calidad permiten mejorar el diseño arquitectónico. Para ello analizaré cada conjunto de tácticas arquitectónicas asociadas a cada uno de los principales atributos de calidad y veremos como estas tácticas nos ayudan a alcanzar los requisitos de atributos de calidad de nuestro sistema. Finalmente me centraré en el núcleo del trabajo que es analizar el asistente arquitectónico ArchE y ver en qué medida es capaz de incorporar los conceptos introducidos en los apartados anteriores, en especial las tácticas arquitectónicas y el diseño dirigido por atributos de calidad, de forma que ayude a los diseñadores a generar el diseño de las arquitecturas software que satisfagan los requisitos tanto funcionales como de atributos de calidad. En primer lugar se presenta el denominado ciclo ABC (Architectural Business Cycle). de arquitecturas de negocio. Considero de gran importancia empezar describiendo el ciclo de dependencias que existen sobre las arquitecturas, dado que de esta forma nos resultará más fácil comprender las ideas subyacentes en la arquitectura software, en los procesos de diseño y en los objetivos finales que se persiguen. La principal referencia bibliográfica utilizada fue [Bass 2003]. A continuación trato de explicar detalladamente el concepto de arquitectura software junto con todas sus implicaciones. También presento algunas definiciones de conceptos inter-relacionados como son los patrones arquitectónicos, los modelos de referencia y las arquitecturas de referencia. A partir de estos conceptos me centro en poner de manifiesto la importancia de la arquitectura software, que es lo que va a justificar el resto del trabajo. Incluyo, por su gran importancia, un apartado relativo a la documentación de las arquitecturas software: las estructuras y las vistas, para finalmente presentar el modelo arquitectónico de 4+1 vistas de Philippe Kruchten que hoy en día está institucionalizado como una de las bases conceptuales del Proceso Unificado de desarrollo de software para describir de forma completa la arquitectura de los sistemas software. Para esta parte del trabajo recopilé información de las siguientes referencias bibliográficas [Bass 2003, Clements 2003, Gorton 2006 y Shaw 96]. 5

7 Aprovecho también para hacer un recorrido por el proceso de la arquitectura software dado que nos resultará útil para posteriormente comprobar cómo la herramienta ArchE implementa los distintos pasos del proceso software, identificando los requisitos arquitectónicos, diseñando la arquitectura y validando los diseños de forma iterativa. Especial atención merece el apartado en el que se presenta el diseño dirigido por atributos de calidad (ADD Atribute Driven Design). ADD toma como entrada un conjunto de requisitos de atributos de calidad representados como escenarios y utiliza el conocimiento existente relativo a la relación entre atributos de calidad y arquitecturas software, para diseñar la arquitectura. Con respecto al apartado dedicado a ADD, las referencias que utilicé fueron [Bachmann 2000, Wood 2007 y Wojcik 2006]. El siguiente apartado se centra en determinar cómo alcanzar los atributos de calidad del software a través de las tácticas arquitectónicas. Hasta este punto se han caracterizado los atributos de calidad de un sistema en términos de una colección de escenarios, pero no se ha dicho nada de cómo el arquitecto es capaz de obtener estas cualidades requeridas por el sistema. Es el momento de ver de qué manera las tácticas arquitectónicas nos permiten crear diseños que satisfagan los requisitos de calidad especificados. Esta parte del trabajo está basada en las siguientes publicaciones [Barbacci 1996, Bachmann 2002 y Bachmann 2003]. Avanzando un poco más en los conceptos ya presentados, el siguiente apartado trata de explicar los patrones arquitectónicos en términos de tácticas y modelos arquitectónicos. Explico detalladamente los principales patrones arquitectónicos, indicando los problemas que se plantean, de qué forma se solucionan dichos problemas y cómo se implementan las distintas tácticas en los patrones arquitectónicos. Se trata también de un apartado muy importante de este trabajo, dado que serán estas tácticas las que trataremos de aplicar a través de la herramienta ArchE para mejorar nuestros diseños arquitectónicos y ser capaces de satisfacer tanto los requisitos funcionales como los de atributos de calidad del sistema a desarrollar. La principal referencia bibliográfica utilizada fue [Buschmann 1996], aunque también utilicé otras como [Bachmann 2007 y Scott 2007]. Una vez comprendidos todos los conceptos presentados en detalle hasta este punto, nos centramos en analizar la herramienta ArchE y ver de qué manera es capaz de soportar estos conceptos y ofrecer asistencia a los diseñadores para obtener mejores arquitecturas software. En primer lugar presentamos ArchE como sistema experto, sus conceptos clave y sus actividades básicas. ArchE es una herramienta que pretende servir como asistente en el diseño de las arquitecturas software. Para ello ArchE incorpora en un sistema experto conocimientos de teorías relativas a atributos de calidad, junto con las relaciones que existen entre los requisitos de los atributos de calidad y el diseño arquitectónico. ArchE utiliza estas teorías para predecir la respuesta de las arquitecturas a los atributos de calidad en situaciones concretas. Este apartado del trabajo es fundamental y en el utilizo ideas y conceptos obtenidos de buena parte de las referencias indicadas, aunque es cierto que existen algunas publicaciones específicas de ArchE como [Bachmann 2003 y SEI 2007], y otras relativas a sistemas expertos y marcos de razonamiento como [Bass 2005 y Friedman- Hill 2003] que me resultaron de gran ayuda. Como punto final del trabajo y apartado fundamental del mismo, utilicé la herramienta ArchE en un caso práctico: CTAS, que es el ejemplo que acompaña a la herramienta. El objetivo es analizar el funcionamiento de ArchE, su usabilidad para los propósitos identificados y su utilidad para alcanzar los objetivos establecidos. Las principales publicaciones utilizadas fueron el manual de usuario de ArchE obtenido de [SEI 2007] y [Bachmann 2007]. 6

8 En primer lugar presento en detalle el caso práctico CTAS, indicando la descripción de los actores identificados, el diagrama de casos de uso y los requisitos de atributos de calidad del sistema. A continuación detallo cómo a través de la herramienta ArchE podemos especificar los requisitos funcionales en forma de responsabilidades, los requisitos de atributos de calidad en forma de escenarios y como establecer las relaciones entre responsabilidades y escenarios. El siguiente paso es mostrar cómo ArchE, a partir de la información que le ha sido facilitada, es capaz de proponer un diseño inicial del sistema e indicar cuáles de los escenarios son satisfechos. Además, veremos cómo ArchE también nos propone las mejores tácticas arquitectónicas para mejorar nuestro diseño y nos solicita toda aquella información que pueda necesitar para poder realizar sus estimaciones y cálculos. A partir del caso inicial incluyo seis ejemplos en los cuales planteo distintas situaciones, en general la agregación de nuevos escenarios al sistema. Estos ejemplos me servirán para analizar la usabilidad de ArchE, su funcionalidad y determinar en qué medida ArchE es capaz de incorporar los métodos y conceptos analizados en los apartados anteriores. El objetivo final del presente trabajo de investigación es pues analizar y evaluar la herramienta ArchE para determinar su utilidad en el diseño de la arquitectura software, ver de qué manera es capaz de gestionar los atributos cualitativos del sistema, transformarlos en escenarios, utilizar el diseño dirigido por atributos de calidad y aplicar las tácticas arquitectónicas para mejorar la toma de decisiones en el desarrollo arquitectónico, de acuerdo con los objetivos de negocio de la organización. 7

9 2. El Ciclo de las Arquitecturas de Negocio (ABC) Lo primero que se debe tener presente es el hecho de que todo sistema informático se construye para satisfacer unos determinados objetivos de negocio, y un aspecto clave en su desarrollo es la arquitectura software del sistema. La cuestión que nos planteamos en este momento es la relación que existe entre la arquitectura software de un sistema y el entorno en el cual dicho sistema va a ser construido y va a existir. Como respuesta nos encontramos que toda arquitectura software es el resultado de una serie de influencias de su propio entorno: técnicas, sociales y del negocio. De hecho la propia arquitectura software va a afectar el ambiente técnico, social y de negocio que le rodea, y que posteriormente influenciará futuras arquitecturas. Este ciclo de influencias, del entorno a la arquitectura y de la arquitectura al entorno, se denomina Ciclo de las Arquitecturas de Negocio (ABC Arquitecture Business Cycle). En todo desarrollo software la gestión de los requisitos explicita solamente algunas de las propiedades deseadas del sistema final. En general no todos los requisitos de un sistema están directamente relacionados con las propiedades deseadas en dicho sistema. Las arquitecturas software normalmente son influenciadas por: Los objetivos de la organización La composición de la organización La formación y la experiencia de los arquitectos El ambiente técnico A su vez las arquitecturas afectan a los factores que las influencian: La composición de la organización Los objetivos de la organización Los requisitos del cliente La experiencia de los arquitectos La figura 1 muestra gráficamente este ciclo de influencias. Figura 1 El Ciclo de las Arquitecturas de Negocio (ABC Architecture Business Cycle) Las arquitecturas en primer lugar están influenciadas por todas aquellas personas que están interesadas en la construcción del sistema software: clientes, usuarios finales, desarrolladores, jefe de proyecto, encargados del mantenimiento e incluso las 8

10 personas responsables de comercializar el producto final. El conjunto de todas estas personas se conoce con el nombre de stakeholders. El problema que surge es que cada stakeholder tiene diferentes preocupaciones, intereses y objetivos, algunos de los cuales pueden ser incluso contradictorios. En la práctica no resulta habitual que los catálogos de requisitos de un sistema incluyan todos los requisitos de calidad del sistema deseado en un formato que pueda ser verificado. Además de por los objetivos de la organización expresados a través de los requisitos del sistema, las arquitecturas software son influenciadas por la propia estructura y/o naturaleza de la organización. En general se distinguen tres tipos de influencias: - Una organización que haya invertido recientemente en activos tales como determinadas arquitecturas o productos basados en ellas, estimará que un nuevo proyecto software deberá aprovechar esta circunstancia y reutilizar al máximo dichas arquitecturas y/o productos relacionados. - Una organización puede desear realizar una inversión a largo plazo en una determinada infraestructura con el fin de alcanzar unos objetivos estratégicos. En este caso un nuevo sistema software se verá como una oportunidad para financiar y extender dicha infraestructura. - Muchas veces la propia estructura de la organización puede dar forma a la arquitectura software. Las arquitecturas claramente son influenciadas por la experiencia y la formación de los arquitectos. Si un arquitecto ha tenido buenos resultados utilizando un determinado enfoque arquitectónico es muy probable que en el próximo proyecto utilice la misma aproximación. De la misma forma, si sus experiencias previas con un determinado enfoque han sido malas, el arquitecto se mostrará reacio a probar otra vez con dicho enfoque. Por lo tanto muchas veces las decisiones arquitectónicas están fuertemente condicionadas por la educación y la formación del arquitecto, el contacto satisfactorio con patrones arquitectónicos o con sistemas que han funcionado particularmente bien o mal. En algunos casos los arquitectos también desearán experimentar determinadas técnicas o nuevos patrones de diseño que han estudiado en algún libro o curso reciente. Un caso especial es el entorno técnico en el momento del diseño de una arquitectura. Este entorno técnico normalmente incluye las prácticas estándar de la industria, o las técnicas de ingeniería del software más frecuentes en las comunidades profesionales. En general, la mayoría de los arquitectos software estará fuertemente condicionado por este entorno técnico. Podemos concluir, por tanto, que los arquitectos son influenciados por los requisitos del sistema de acuerdo con la visión de los stakeholders, por la estructura y objetivos de la propia organización, por el entorno técnico disponible y por sus propios conocimientos y experiencia. Ahora bien, las arquitecturas también afectan a aquellos factores que las han influenciado. Las relaciones entre los objetivos de negocio, los requisitos del sistema, la experiencia del arquitecto y las arquitecturas forman un círculo que se realimenta continuamente y que debe ser gestionado con el propósito de manejar el crecimiento de la organización y aprovechar las inversiones previas en arquitecturas y en la construcción de sistemas. 9

11 El Ciclo de las Arquitecturas de Negocio funciona de la siguiente forma: 1. La arquitectura afecta a la estructura de la organización. Las arquitecturas prescriben unidades de software que deben ser desarrolladas u obtenidas para integrarse y formar un sistema. Estas unidades son la base para el desarrollo de la estructura de un proyecto. Los equipos de trabajo se forman para desarrollar estas unidades de software y las actividades de desarrollo, prueba e integración giran en torno a ellas. De la misma forma, los presupuestos y calendarios de trabajo distribuyen los recursos de acuerdo con partes de dichas unidades. Los equipos de trabajo tienden, por tanto, a arraigarse en la estructura de la organización 2. La arquitectura puede afectar a los objetivos de la organización. Por ejemplo, si una compañía desarrolla con éxito un producto, la arquitectura subyacente puede proporcionar oportunidades para producir de forma eficiente productos similares, de forma que la organización puede ajustar sus objetivos para aprovechar esta situación. 3. La arquitectura también puede influir en los requisitos del cliente para el siguiente sistema, ofreciéndole la oportunidad de recibir un sistema basado en la misma arquitectura y que, por tanto, será más fiable, más económico y más rápido de desarrollar que si fuese desarrollado desde cero. En muchos casos el cliente se mostrará predispuesto a relajar ciertos requisitos con tal de beneficiarse de estas economías. 4. Los sistemas construidos afectarán la experiencia de los arquitectos. Los sistemas desarrollados satisfactoriamente mediante una determinada herramienta o tecnología podrán dar lugar al desarrollo de nuevos sistemas similares en el futuro. De la misma forma, arquitecturas que han fracasado en un proyecto serán probablemente rechazadas en futuros proyectos. 5. En algunos casos determinados sistemas influenciarán y de hecho cambiarán la cultura de la ingeniería del software, esto es, el entorno técnico en el cual los sistemas serán construidos. La arquitectura software es, por tanto, mucho más que el resultado de los requisitos funcionales de un sistema. Es también el resultado de los conocimientos y experiencia del arquitecto, de su entorno técnico y de los objetivos de negocio de la organización. La arquitectura influencia a su vez el entorno que la rodea proporcionando nuevas experiencias técnicas y oportunidades de negocio. 10

12 3. Comprendiendo la Arquitectura Software Len Bass [Bass 2003] define la arquitectura software de un sistema informático como la estructura del sistema incluyendo los elementos software, las propiedades de dichos elementos que son visibles externamente y las relaciones entre ellos. De la definición anterior se obtienen algunas consideraciones importantes. La primera se refiere al hecho de que la arquitectura define elementos de software, incorpora información acerca de cómo estos elementos se relacionan entre sí y omite expresamente información que no se refiere a dicha interacción. Por lo tanto una arquitectura es, en primer lugar, una abstracción del sistema que aísla detalles de sus elementos que no afectan a la forma en que son utilizados, se relacionan o interaccionan entre sí. La arquitectura se preocupa por el lado público de los elementos, los detalles privados que sólo se refieren a la implementación interna del sistema no forman parte de la arquitectura. En segundo lugar, la definición de arquitectura software implica que todo sistema informático posee una arquitectura software, dado que todo sistema puede ser visto como un conjunto de elementos y las relaciones entre ellos. En tercer lugar nos encontramos con que el comportamiento de cada elemento es parte de la arquitectura en la medida en que dicho comportamiento puede ser observado desde el punto de vista de otro elemento. Este comportamiento es lo que permite a los elementos interaccionar entre sí, lo cual forma parte claramente de la arquitectura. Por último, otra importante conclusión de la definición es que ésta no está vinculada al hecho de que la arquitectura de un sistema sea buena o mala (en el sentido de que permita al sistema alcanzar sus requisitos funcionales o de rendimiento). Otras definiciones importantes son las de patrones arquitectónicos, modelos de referencia y arquitecturas de referencia. Un patrón arquitectónico es la descripción de los elementos y sus tipos de relaciones junto con las restricciones relativas a cómo pueden ser usados. Un patrón puede considerarse como un conjunto de restricciones sobre una arquitectura, de forma que el conjunto de restricciones establece una familia de arquitecturas que satisfacen dichas restricciones. Una de los aspectos más importantes de los patrones arquitectónicos es que tienen asociados conocidos atributos de calidad. Mientras que unos patrones representan soluciones conocidas a problemas de rendimiento, otros aseguran una alta disponibilidad o grandes niveles de seguridad. Un modelo de referencia describe una división en la funcionalidad junto con el flujo de datos entre los elementos. Se trata de una descomposición estándar de un problema conocido en una serie de partes que cooperativamente solucionan el problema. Por su lado una arquitectura de referencia es un modelo de referencia que está vinculado a elementos software, que cooperativamente implementan la funcionalidad definida en el modelo de referencia, y al flujo de datos entre dichos elementos. Mientras que un modelo de referencia divide la funcionalidad, la arquitectura de referencia vincula dicha funcionalidad con la descomposición del sistema en elementos que cooperativamente ofrecen la misma funcionalidad. 11

13 En la figura 2 se muestran las relaciones entre los distintos conceptos que acabamos de presentar. Las flechas indican que los conceptos subsiguientes contienen elementos de diseño adicionales. Modelo de Referencia Arquitectura de Referencia Arquitectura Software Patrón Arquitectónico Figura 2. Relaciones entre los conceptos Modelo de Referencia, Patrón Arquitectónico, Arquitectura de Referencia y Arquitectura Software. Para comprender el significado de la arquitectura software resulta de gran valor comprender las razones por las cuales resulta tan importante. Podemos considerar que existen tres razones fundamentales en la importancia de la arquitectura del software. La primera se refiere a la comunicación entre los stakeholders. La arquitectura representa una abstracción del sistema que puede ser utilizada como base para la negociación, consenso, comunicación y el entendimiento mutuo. En segundo lugar las arquitecturas facilitan la posibilidad de tomar decisiones lo antes posible; de hecho las arquitecturas establecen las primeras decisiones relativas al diseño de los sistemas. Por último, las arquitecturas software constituyen un modelo abstracto del sistema que permite comprender cómo está estructurado el sistema y cómo sus elementos trabajan juntos. Estos modelos pueden además ser transferidos entre sistemas, de forma que pueden ser aplicados a otros sistemas que presenten requisitos funcionales y atributos de calidad similares. La arquitectura software representa el primer conjunto de decisiones de diseño que se realiza de un sistema. Estas decisiones, las más tempranas en realizarse, son trascendentales siendo las más difíciles de realizar y las que entrañan mayor carga de trabajo si resulta necesario cambiarlas durante el posterior proceso de desarrollo. La arquitectura también define restricciones en la implementación de los sistemas. De hecho una implementación se dice que exhibe una arquitectura si es conforme con las decisiones de diseño estructural descritas en dicha arquitectura. Esto significa que toda implementación debe ser dividida en elementos que deben interaccionar entre sí de acuerdo con la forma preestablecida y cada elemento debe cumplir con todas sus responsabilidades tal y como establece la arquitectura. La arquitectura no sólo prescribe la estructura de los sistemas, también tiene una gran influencia en la estructura de los proyectos de desarrollo e incluso en la estructura de la propia organización. Dado que la arquitectura de un sistema incluye la descomposición de más alto nivel del sistema, ésta es típicamente utilizada como base para realizar la estructura de descomposición de trabajos (WBS Work Breakdown Structure), la cual establece las unidades de planificación, programación y presupuesto, canales de comunicación, control de configuración, procedimientos y planes de prueba, etc. La arquitectura permite o impide alcanzar los atributos de calidad de un sistema. El hecho de que un sistema sea capaz de exhibir los atributos de calidad deseados o 12

14 requeridos está substancialmente condicionado por su arquitectura. Las estrategias para alcanzar los atributos de calidad son fundamentalmente de carácter arquitectónico, aunque las arquitecturas por sí solas son incapaces de garantizar la calidad o la funcionalidad deseada. Lógicamente las decisiones a lo largo de todo el ciclo de vida de un sistema afectan a la calidad final, pero si queremos asegurar la calidad una buena arquitectura será necesaria. La arquitectura también permite realizar estimaciones más precisas del presupuesto y la planificación de los proyectos. Las estimaciones basadas en el entendimiento de las piezas del sistema son siempre más precisas que aquellas que están basadas en el conocimiento del sistema completo. Cada equipo podrá realizar estimaciones más precisas sobre las piezas individuales de las que está encargado, que el propio jefe de proyecto. Además los equipos podrán responsabilizarse mejor de hacer realidad dichas estimaciones. Por otro lado la definición inicial de una arquitectura supone que los requisitos de un sistema han sido revisados y de alguna manera validados. En lo que se refiere a la arquitectura como modelo reutilizable, cabe decir que cuanto antes se aplique la reutilización en el ciclo de vida de un sistema, mayor será el beneficio que podrá ser obtenido. Es por esta razón que aun cuando la reutilización de código es muy beneficiosa, la reutilización a nivel arquitectónico proporciona unas enormes ventajas estratégicas. La cuestión es que no solo el código puede ser reutilizado, también es posible reutilizar los requisitos de una arquitectura de gran éxito. Cuando las decisiones arquitectónicas pueden ser reutilizadas sobre múltiples sistemas diferentes, también son transferidas todas las ventajas relativas a las tempranas decisiones de diseño. Estructuras y Vistas de la Arquitectura Los sistemas informáticos son cada vez más y más complejos, lo que hace que su comprensión resulte difícil. En general resulta más adecuado restringir nuestra atención a un pequeño número de estructuras de forma simultánea, ya que de esta forma nos resultará más sencillo captar tanto la idea global como los detalles subyacentes. De la misma forma, para comunicarnos de forma más eficiente acerca de la arquitectura de un sistema, resulta necesario tener claro de que estructura o estructuras arquitectónicas estamos hablando en cada momento. Es por esta razón que introducimos los conceptos de estructuras y vistas arquitectónicas. Una vista es una representación de un conjunto coherente de elementos arquitectónicos y de las relaciones entre ellos. Una estructura arquitectónica es el conjunto de elementos arquitectónicos tal y como existen en el software y/o hardware. Las estructuras arquitectónicas suelen dividirse en tres grandes grupos dependiendo de la naturaleza de los elementos que muestran: Estructuras modulares. Los elementos que representan son módulos, considerados como unidades de implementación del sistema. Los módulos son áreas asignadas de responsabilidad funcional. Estructuras de componentes y conectores. En este caso los elementos son los componentes en tiempo de ejecución y los conectores (vehículos de comunicación entre los componentes). Estructuras de asignación. Este tipo de estructuras tratan de mostrar las relaciones entre los elementos software y los elementos en uno o más entornos externos en los cuales el software es creado y ejecutado. Estos tres tipos de estructuras arquitectónicas se corresponden con los tres grandes tipos de decisiones involucrados en el diseño arquitectónico: 13

15 Cómo se estructura el sistema en términos de unidades de código (módulos). Cómo se estructura el sistema en términos de elementos que tienen un comportamiento en tiempo de ejecución (componentes) e interaccionan entre sí (conectores). Cómo está relacionado el sistema con otras estructuras no software dentro de su entorno. Las estructuras basadas en módulos incluyen los siguientes tipos: Descomposición. Esta estructura muestra la descomposición de grandes módulos en otros sub-módulos más pequeños, que pueden ser comprendidos más fácilmente. Los módulos representan un punto de partida en el diseño y de forma recursiva el arquitecto va detallando las responsabilidades de las distintas unidades de código y asignándolas a los módulos para el subsiguiente diseño detallado y su eventual implementación. Esta estructura suelen utilizarse como la base para la organización del desarrollo del proyecto. Usos. Las unidades de esta estructura pueden ser módulos, procedimientos o recursos en las interfaces de los módulos. Las unidades están relacionadas entre sí por relaciones de uso. Una unidad se dice que usa otra unidad si para la corrección de la primera es necesaria una versión correcta de la segunda. La habilidad para descomponer fácilmente un sistema que funciona, permite el desarrollo incremental. Capas. Las capas son conjuntos coherentes de funcionalidad relacionada. Las capas normalmente se diseñan como abstracciones que ocultan la implementación específica a las capas inferiores. En una estructura de capas estricta, la capa n sólo puede utilizar los servicios de la capa n 1. Clases o generalizaciones. Este tipo de vistas soporta razonamientos sobre colecciones de elementos que tienen comportamientos similares, de forma que es posible parametrizar las diferencias a través de sub-clases. Las estructuras de clases permiten razonar en términos de re-utilización y adición incremental de funcionalidad. Las estructuras de componentes y conectores incluyen los siguientes tipos: Procesos de comunicación. Esta estructura trata los aspectos dinámicos de un sistema en tiempo de ejecución. Las unidades que se representan son procesos o hilos de ejecución que están conectados entre sí por operaciones de comunicación, sincronización y/o exclusión. Se trata de un tipo de estructura que facilita la comprensión del rendimiento y disponibilidad de los sistemas en ejecución. Concurrencia. Este tipo de estructura permite al arquitecto determinar oportunidades para el paralelismo, así como localizar puntos en los que puedan producirse problemas de congestión. Las unidades que se representan son componentes y los conectores son hilos de ejecución lógicos. Datos compartidos o repositorios. Representan componentes y conectores que crean, almacenan y acceden datos persistentes. Estas estructuras muestran cómo los datos son producidos y consumidos por los elementos software en tiempo de ejecución. Pueden utilizarse para mejorar el rendimiento y la integridad de los datos. Cliente-Servidor. Los componentes son los clientes y los servidores, mientras que los conectores son los protocolos y los mensajes que comparten para llevar a cabo el trabajo del sistema. Se trata de estructuras útiles para separar responsabilidades, para la distribución física y para el balanceo de carga. 14

16 Las estructuras de asignación incluyen los siguientes tipos: Despliegue. Estas estructuras muestran cómo se asigna el software a los procesos hardware y a los elementos de comunicación. Los elementos representados son procesos software, entidades hardware (procesadores) y canales de comunicación. Las relaciones muestran las asignaciones de los elementos software a unidades físicas en las que residen. Se trata de estructuras especialmente interesantes en sistemas distribuidos, que permiten razonar aspectos como el rendimiento, la integridad de datos, la disponibilidad y la seguridad. Implementación. Muestran cómo los elementos software se transforman en la estructura de ficheros durante el desarrollo del sistema, su integración y en el control de la configuración. Se trata de estructuras útiles en la gestión de las actividades de desarrollo y en la construcción de procesos. Asignación de trabajo. Esta estructura asigna las responsabilidades para implementar e integrar los módulos a los equipos de desarrollo apropiados. Aunque normalmente pensamos en la estructura de un sistema en términos de su funcionalidad, existen otras propiedades del sistema, tales como la distribución física, los procesos de comunicación y sincronización, que deben ser considerados a nivel arquitectónico. Es, en este sentido, que cada tipo de estructura proporciona un método para razonar sobre unos atributos de calidad u otros. Cada estructura proporciona una perspectiva diferente del diseño de un sistema, pero no son independientes entre sí, sino que los elementos de una estructura están relacionados con los elementos de otras estructuras. Kruchten propuso un modelo arquitectónico de vistas, denominado 4+1, con objeto de asegurar que las diferentes estructuras de un sistema no entran en conflicto unas con otras y que en su conjunto describen el sistema correctamente, cumpliendo con sus requisitos. Actualmente esta aproximación se ha popularizado y se ha institucionalizado como una de las bases conceptuales del Proceso Unificado de desarrollo de software. Kruchten propuso las siguientes cuatro vistas para describir la arquitectura de un sistema software: 1. Vista lógica. Su preocupación es la funcionalidad que el sistema proporciona a los usuarios finales. Los diagramas UML utilizados para su representación son: diagramas de clases, de secuencia y de comunicación. Se trata de la estructura de módulos. 2. Vista de desarrollo. Esta vista muestra el sistema desde el punto de vista del programador, muestra la organización de los módulos software, las librerías, subsistemas y unidades de desarrollo. Se centra en la gestión del software. Utiliza los diagramas de componentes y de paquetes. Se trata de una estructura de asignación 3. Vista de procesos. Esta vista se ocupa de los aspectos dinámicos del sistema, explica los procesos del sistema y cómo se comunican entre sí. Utiliza los diagramas de actividades para representar problemas de concurrencia, distribución de la funcionalidad, rendimiento o escalabilidad. Se trata de las estructuras de componentes y conectores. 4. Vista física. Describe el sistema desde el punto de vista del ingeniero de sistemas. Está centrada en la topología de los componentes software en la capa software y en la comunicación entre ellos. También se conoce como vista de despliegue, y se trata de una estructura de asignación. Utiliza diagramas de despliegue para su representación. 15

17 Vista Lógica Vista de Desarrollo Escenarios Vista de Procesos Vista Física Figura 3 Modelo Arquitectónico de 4+1 Vistas de Philippe Kruchten La descripción de la arquitectura se ilustra mediante un pequeño conjunto de casos de uso o escenarios que forman la quinta vista del modelo. Los escenarios describen secuencias de interacciones entre objetos y entre procesos. Se utilizan para identificar elementos arquitectónicos y para ilustrar y validar el diseño de la arquitectura. Para representar esta vista se utilizan los diagramas de casos de uso. En la figura 3 se muestra el Modelo de 4+1 Vistas, y se pueden observar además las interdependencias entre las vistas. Por ejemplo la dependencia de la vista lógica y la vista de desarrollo muestra como el modelo lógico (una clase) se puede implementar en un módulo, paquete, etc. La dependencia entre la vista lógica y la vista de procesos identifica características como quien invoca a quien (autonomía) o desde donde son accesibles las operaciones (persistencia, distribución). 16

18 Comprendiendo los Atributos de Calidad del Software 4.1 Funcionalidad y Arquitectura Como hemos visto en los apartados anteriores, los objetivos de negocio de una organización determinan los atributos de calidad necesarios en un sistema y que deben ser alcanzados a través de las arquitecturas software. Estos atributos de calidad son adicionales a la propia funcionalidad del sistema, y aunque están íntimamente relacionados, a menudo son los requisitos de funcionalidad los que guían los procesos de desarrollo de software. Como resultado de ello muchas veces los sistemas deben ser rediseñados no porque su funcionalidad sea deficiente, sino por las dificultades en su mantenimiento o en su portabilidad, o por problemas de rendimiento o de seguridad. Los atributos de calidad y la funcionalidad suelen considerarse conceptos ortogonales, en el sentido de que es posible elegir de forma independiente el nivel deseado para cada uno de ellos. La funcionalidad es, en buena parte, independiente de la estructura. De hecho, en general, la funcionalidad puede ser obtenida mediante la utilización de múltiples estructuras diferentes (si la funcionalidad fuese el único requisito entonces el sistema podría existir como un único módulo monolítico sin ninguna estructura interna). La arquitectura software lo que hace es establecer restricciones sobre la estructura del sistema cuando resulta necesario alcanzar determinados atributos de calidad. Objetivos de Negocio / Misión de la organización Atributos de Calidad S I S T E M A Determina el nivel de calidad Dirige / Guía Arquitectura Software Dirige / Guía Calidad del Software Capacidades del Sistema Figura 4 Relación entre las arquitecturas software, los atributos de calidad, los objetivos del negocio y la funcionalidad del sistema Los atributos de calidad más comunes son: rendimiento, disponibilidad, seguridad, usabilidad, modificabilidad, y testeabilidad o capacidad de prueba. Pero podríamos citar otros atributos como, por ejemplo, la fiabilidad, la portabilidad o la interoperabilidad. Más adelante definiremos y profundizaremos en los principales atributos de calidad. Vamos a ver como para obtener los mejores resultados a la hora de diseñar un sistema software, es necesario que todo el equipo de desarrollo, junto con el resto de la organización, comprenda y esté de acuerdo con los atributos de calidad del sistema a desarrollar. También veremos que para poder obtener los atributos de calidad de un sistema deberemos tener en cuenta todas las fases del ciclo de vida. Ningún atributo de calidad depende exclusivamente del diseño, de la implementación o del despliegue. 17

19 Los resultados satisfactorios solamente se alcanzan cuando consideramos tanto la arquitectura del sistema como los detalles de su implementación. La arquitectura es crítica en la obtención de muchos atributos de calidad de un sistema, de modo que es necesario diseñar y evaluar estos atributos de calidad durante la fase de definición de la arquitectura del sistema. Pero, en cualquier caso, no debemos olvidar que la arquitectura por si sola es incapaz de lograr alcanzar los atributos de calidad. La arquitectura establece las bases pero es necesario que durante el diseño, la implementación y el despliegue del sistema se preste gran atención a todos los detalles. Como ejemplo práctico podemos analizar qué es lo que ocurre con el rendimiento de un sistema. El rendimiento tiene claramente dependencias tanto arquitectónicas como no arquitectónicas: depende del grado de comunicación necesaria entre los componentes del sistema (arquitectónica), de cómo la funcionalidad ha sido distribuida entre los componentes (arquitectónica), de cómo los recursos compartidos se han asignado (arquitectónico), de la selección de algoritmos que implementan la funcionalidad (no arquitectónico) o de cómo se han codificado dichos algoritmos (no arquitectónico). En todo proceso de desarrollo software resulta imprescindible identificar los atributos de calidad del sistema, determinar qué es requerido y qué es deseable para cada uno de ellos. Una vez definidos los atributos de calidad del sistema, el siguiente paso es determinar en qué medida la aplicación que se está desarrollando puede alcanzar las expectativas establecidas. Si no resulta posible alcanzar los atributos de calidad de acuerdo con lo establecido, entonces será necesario cambiar la arquitectura, de forma que se consiga satisfacer todos los requisitos de los atributos de calidad. A continuación tendremos que revisar los requisitos funcionales y verificar si han sufrido modificaciones y, en su caso, reajustar la aplicación. 4.2 Los Escenarios de Atributos de Calidad El siguiente problema que se plantea al tratar de establecer los atributos de calidad de un sistema es que, en general, la definición de un atributo de calidad no es operativa y además los atributos de calidad tienden a solaparse unos con otros. Incluso a menudo tienen efectos en cadena: el éxito de uno de ellos suele tener efectos, a veces positivos otras veces negativos, en el logro de otros atributos de calidad. Como solución a estos problemas se considera la utilización de los escenarios como medio para caracterizar los atributos de calidad. Los escenarios constan de seis partes (ver figura 5): Origen del estímulo: es la entidad que genera el estímulo. Puede ser una persona, un sistema informático,... Estímulo: es el evento que está actuando sobre el sistema. Entorno: las condiciones concretas en las cuales el estímulo se ha producido. Artefacto: el sistema completo o las partes del sistema que son estimuladas. Respuesta: se trata de la actividad realizada como consecuencia del estímulo. Medida de la respuesta: toda vez que ocurre una respuesta, ésta debe ser medida con objeto de evaluar si el requisito ha sido alcanzado. 18

20 Figura 5 Partes de los Escenarios de Atributos de Calidad Cuando hablamos de escenarios de atributos de calidad se distingue entre escenarios generales: aquellos que son independientes de un sistema y que potencialmente pueden pertenecer a cualquier sistema, y los escenarios concretos: aquellos que son específicos de un sistema en particular. En concreto podemos decir que la caracterización de los atributos de calidad es una colección de escenarios generales, pero si queremos traducir estos atributos a requisitos concretos para un determinado sistema, los escenarios generales tienen que ser convertidos a escenarios concretos. Será esta colección de escenarios concretos la que podrá ser usada para representar los requisitos de calidad de un sistema, dado que cada escenario concreto aporta la información suficiente que necesita el arquitecto y los detalles de la respuesta permiten evaluar si el sistema final alcanza los requisitos de calidad establecidos. 4.3 Los principales Atributos de Calidad en detalle A continuación vamos a analizar con más detalle los seis atributos de calidad que se pueden considerar como más comunes e importantes. El propósito es identificar los conceptos que subyacen y además proporcionar una vía para generar escenarios generales para cada uno de ellos. Disponibilidad. La disponibilidad de un sistema se refiere a la posibilidad de que se produzcan fallos en el funcionamiento de un sistema y a las consecuencias que se puedan derivar. Lo primero que es necesario indicar es que el fallo de un sistema se produce cuando el sistema no es capaz de ofrecer el servicio que se espera de acuerdo con su especificación. Estos fallos pueden ser observados tanto por otros sistemas como por personas. Las principales inquietudes son: cómo detectar los fallos, con qué frecuencia ocurren, qué ocurre cuando se produce un fallo, cuánto tiempo puede estar un sistema fuera de servicio como consecuencia de un fallo, cómo pueden prevenirse los fallos de un sistema y cuáles serían las notificaciones requeridas cuando se produce un fallo. Una vez que se ha producido el fallo de un sistema, un concepto muy importante es el del tiempo necesario para su reparación. Desde que el fallo de un sistema es observable por otros usuarios, el tiempo de reparación es el tiempo transcurrido hasta que el fallo deja de ser observable. La disponibilidad ( de un sistema suele definirse como la probabilidad de que un sistema esté operativo cuando es necesario: 19

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingenierí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 detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables.

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Para obtener el grado de Maestro en Ciencias (Ciencias y Tecnologías de la Información) P R E S E N T A Lic.

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos 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 detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Modelado y Diseño de Arquitectura de Software

Modelado y Diseño de Arquitectura de Software Modelado y Diseño de Arquitectura de Software CONCEPTOS DE MODELADO Fernando Barraza A. MS.c. fernando.barraza@gmail.com 2 Desarrollo de sistemas de software Requisitos funcionales del software Si todo

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

Más detalles

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN DOCUMENTACIÓN DE ARQUITECTURAS DE SISTEMAS EN UN BANCO TESIS PARA OPTAR AL GRADO DE MAGISTER EN

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Introducción En este apartado se va a proporcionar una apreciación global del SRS.

Introducción En este apartado se va a proporcionar una apreciación global del SRS. INTRODUCCIÓN Se pretende desarrollar una aplicación web para la gestión de un restaurante que ofrece espectáculos en fechas determinadas con el fin de poner en práctica los principios de planificación

Más detalles

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril

Más detalles

Evolución histórica 60 -. Metodologías

Evolución histórica 60 -. Metodologías TEMA 1 INTRODUCCIÓN Historia Evolución de las técnicas de programación Qué es orientado a objetos? Factores cruciales que miden la calidad del software Externos Internos La familia Orientada a objetos

Más detalles

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje Escuela Universitaria de Ingeniería Industrial, Informática y Sistemas Área de Computación e Informática Universidad Tarapacá Arica Aplicaciones Web que Permitan Administrar Portafolios para Gestionar

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE 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 detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

1. Cuál es el objetivo del proceso de Análisis del Sistema de Información? del sistema. a. 10. b. 12. c. 9. d. 11. Análisis

1. Cuál es el objetivo del proceso de Análisis del Sistema de Información? del sistema. a. 10. b. 12. c. 9. d. 11. Análisis 1. Cuál es el objetivo del proceso de del Sistema de Información? a. La obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestió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 detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

Qué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso 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 detalles

PROGRAMACIÓ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. 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

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Diseño y Arquitectura de Software Grado en Ingeniería de Software Carlos E. Cuesta carlos.cuesta@urjc.es Arquitectura de Software Introducción Motivación Incremento en el tamaño

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

El Software. Es lo que se conoce como el ciclo de vida del software.

El Software. Es lo que se conoce como el ciclo de vida del software. El Software Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación, y mejora. Para construir un nuevo elemento software

Más detalles

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES Denominación de la materia SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES créditos ECTS = 36 carácter = OBLIGATORIA Ubicación dentro del plan de estudios y duración La materia está formada por 6 asignaturas

Más detalles

Aseguramiento de la Calidad

Aseguramiento de la Calidad ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-CAL 1: IDENTIFICACIÓN DE LAS PROPIEDADES DE CALIDAD PARA EL SISTEMA... 3 Tarea EVS-CAL 1.1: Constitución del Equipo

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones 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 detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 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 detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES

GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES GUÍA DE IMPLANTACIÓN DEL MODELO DE PROCESOS DE CALIDAD DEL DESARROLLO DE SOFTWARE EN EL NIVEL 2 DE MADUREZ SPICE EN LAS PYMES Tabla de contenido INTRODUCCIÓN AL MODELO... 4 OBJETO DE ESTA GUÍA... 7 1.

Más detalles

Tó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 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 detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

Ingeniería de Software II Segundo Cuatrimestre 2007

Ingeniería de Software II Segundo Cuatrimestre 2007 Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 4 Parte 1: Introducción a las Arquitecturas de Software Buenos Aires, 3 de Septiembre de 2007 Diagramas de ejemplo Analizando dibujitos Banco 3

Más detalles

CICLO DE VIDA DEL SOFTWARE

CICLO DE VIDA DEL SOFTWARE CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en

Más detalles

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos 65 CAPITULO 3 DISEÑO 3.1. DISEÑO El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software. 66 Diseño procedural Diseño de la

Más detalles

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Patrones de software y refactorización de código

Patrones 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 detalles

Empresa Financiera Herramientas de SW Servicios

Empresa 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 detalles

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

Más detalles

Jazmín Hernández jazminpalom@gmail.com. Technical Report COMP-029-2009. Abstract

Jazmín Hernández jazminpalom@gmail.com. Technical Report COMP-029-2009. Abstract Guía para la Documentación de Arquitecturas de Software Como Base Para el Desarrollo de Sistemas de Información en la Iglesia Adventista del Séptimo Día Jazmín Hernández jazminpalom@gmail.com Technical

Más detalles

OMG 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 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 detalles

Ejercicio 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 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

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes DESARROLLO DE SOFTWARE EMPRESARIAL Jonás Montilva C. Judith Barrios A. Universidad de Los Andes Desarrollo de Software Empresarial Derechos Reservados. Ninguna parte de este documento puede ser reproducida,

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

Metodología para el diseño y desarrollo de interfaces de usuario

Metodología para el diseño y desarrollo de interfaces de usuario Metodología para el diseño y desarrollo de interfaces de usuario Versión Historia de Revisión Fecha Versión Descripción Responsable 20/06/2005 Creación. Alejandro Báez Cristian Castañeda Diego

Más detalles

Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS

Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS Proyecto Fin de Carrera Ingeniería Informática Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS Autor: Mariola Valiente

Más detalles

Desarrollo de Aplicaciones Windows Con Visual Studio 2010

Desarrollo de Aplicaciones Windows Con Visual Studio 2010 Desarrollo de Aplicaciones Windows Con Visual Studio 2010 (.NET FRAMEWORK 4.0) ACERCA DEL CURSO: Esta Especialidad está diseñado para desarrollar los conocimientos y habilidades para el desarrollo de aplicaciones

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

MACROPROCESO GESTIÓN TECNOLÓGICA

MACROPROCESO 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 detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 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 detalles

Unidad Zacatenco Departamento de Computación. Arquitectura de software para aplicaciones Web

Unidad Zacatenco Departamento de Computación. Arquitectura de software para aplicaciones Web Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional Unidad Zacatenco Arquitectura de software para aplicaciones Web Tesis que presenta Juan Tahuiton Mora para obtener el

Más detalles

Desarrollo y comercialización de productos de software [El proceso unificado]

Desarrollo y comercialización de productos de software [El proceso unificado] Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo

Más detalles