SISTEMAS DE INFORMACIÓN II (IF202)

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

Download "SISTEMAS DE INFORMACIÓN II (IF202)"

Transcripción

1 SISTEMAS DE INFORMACIÓN II (IF202) UN APUNTE PRELIMINAR Separata 8: Pruebas (Incluye bibliografía y acrónimos) Ingº Manuel A. Peñaloza Figueroa Departamento Académico de Informática Universidad Nacional de San Antonio Abad del Cusco Cusco, Perú 1

2 2

3 En Informática, nada es absoluto, todo es relativo. Leunam. 3

4 4

5 8 Pruebas Propósito La disciplina de Prueba actúa en muchos aspectos como un proveedor de servicios para las otras disciplinas. La prueba se enfoca primariamente sobre la evaluación o valoración de la calidad del producto realizado a través de un número de prácticas core (centrales). El propósito de las Pruebas es: Encontrar y documentar defectos en la calidad del software. Generalmente aconsejar acerca de la calidad de software percibida. Probar la validez de los supuestos hechos en las especificaciones de requerimientos y en el diseño a través de demostración concreta. Validar las funciones del producto de software como fue diseñado. Validar que los requerimientos han sido implementados apropiadamente. 8.1 Prueba: Flujo de trabajo Este diagrama representa el flujo de trabajo por defecto para la Disciplina de 5

6 Pruebas durante el curso de una iteración típica. Este flujo de trabajo puede requerir variantes basadas en las necesidades específicas de cada iteración y cada proyecto. 8.2 (P): Actividades y Roles de los detalles del flujode-trabajo 6

7 8.2.1 (P): Detalle del Flujo-de-trabajo: Planear y Diseñar Prueba Actividad: Planear Prueba Propósito: Recolectar y organizar la información de planeamiento-de-la-prueba. Crear el plan de prueba. Pasos: Identificar los Requerimientos para la Prueba Evaluar el Riesgo Desarrollar la Estrategia de Prueba Identificar Recursos Crear el Cronograma Generar Plan de Prueba 7

8 Crear el Cronograma Crear un cronograma incluye: Estimar el esfuerzo de la prueba Generar el cronograma de prueba El cronograma del proyecto de prueba puede ser construido a partir de los estimados de trabajo y de las asignaciones de recursos: En el entorno del desarrollo iterativo, un proyecto de prueba separado es necesitado para cada iteración. Todas las actividades de prueba son repetidas en cada iteración. En una iteración particular: Las actividades de Planear prueba y Diseñar prueba abordan nuevas funciones en el software, La actividad de Implementación de la prueba involucra: crear nuevos casos de prueba para nuevas funciones y modificar casos de prueba para funciones que han cambiado. Los pasos de ejecución de la prueba y de evaluación valida nuevas funciones y lleva a cabo pruebas de regresión para funciones existentes. Las primeras iteraciones introducen un gran número de nuevas funciones y de nuevas pruebas. A medida que el proceso de integración continua, el número de nuevas pruebas disminuye, y un número creciente de pruebas de regresión necesitan ser ejecutados para validar las funciones acumuladas. Consecuentemente, las primeras iteraciones requieren más trabajo sobre diseño y planificación de pruebas mientras las últimas iteraciones son pesadas para con la ejecución y evaluación de las pruebas. 8

9 No es posible proveer cronogramas detallados para cada iteración: No es conocido en general cuantas iteraciones habrán ó en que iteración un cierto criterio de prueba será satisfecho. Usando el esfuerzo estimado y los recursos asignados, crear un cronograma para su esfuerzo de prueba. La tabla de ejemplo de abajo resume todas las actividades de prueba. Los estimados del trabajo son mostrados como líneas-de-guía para la cantidad relativa de trabajo para cada tarea. Cuando se desarrolla el cronograma tiene que asegurarse que ello es realista. Hay pocas cosas tan desmoralizantes como los cronogramas tan ambiciosos que uno no tiene tiempo o energía para seguir, y, en el peor caso, resultando en que ninguna de las pruebas está siendo satisfactoriamente llevada a cabo. 9

10 Tarea Trabajo Relativo #d #d #d Total del esfuerzo 38 Planificar Prueba 7 Identificar proyecto a probar 1 Definir estrategia de la prueba 1 Estimar trabajo 1 Identificar recursos 1 Cronogramar actividades de prueba 1 Documentar plan de la prueba 2 Especificar Casos de Prueba 5 Determinar casos de prueba 5 Diseñar Prueba 7 Analizar requerimientos de la prueba 2 Especificar procedimientos de la prueba 3 Especificar casos de prueba 1 Revisar cobertura de los requerimientos de la 1 prueba Implementar Prueba 12 Establecer entorno de implementación de la 1 prueba Registrar y play back scripts del prototipo 1 Desarrollar procedimientos de la prueba 5 Probar y depurar procedimientos de la prueba 1 Modificar procedimientos de la prueba 2 Establecer conjuntos de datos externos 1 Re-probar y depurar procedimientos de la prueba 1 Ejecutar Prueba del Sistema 6 Establecer un sistema de prueba 1 Ejecutar pruebas 2 Verificar resultados esperados 1 Investigar resultados no esperados 1 Log los defectos 1 Evaluar Prueba 1 Revisar los logs de prueba 0.25 Evaluar la cobertura de los casos de prueba 0.25 Evaluar defectos 0.25 Determinar si el criterio de compleción de la

11 prueba son satisfechos Generar Plan de Prueba Para generar un plan de prueba, lleve a cabo lo siguiente: Revisar/refinar materiales existentes Identificar entregables de la prueba Propósito: Identificar y definir como los artefactos de la prueba serán creados, mantenidos, y hechos disponibles a otros. Estos artefactos incluyen: Casos de Prueba Solicitud/Pedido de Cambio Generar el plan de prueba El último paso en la actividad: Planear Prueba es generar el plan de prueba. Esto es conseguido con ensamblar toda la información de pruebas recogida y generada dentro de un reporte simple. El plan de prueba debe de ser distribuido en al menos los siguientes: todos los roles de prueba representante de los desarrolladores representante de los accionistas representante de los interesados representante del cliente representante del usuario-final Actividad: Diseñar Prueba Propósito: Identificar un conjunto de casos de uso verificables para cada build. Identificar los procedimientos de prueba que muestran como los casos de prueba serán realizados. Pasos: Identificar y Describir los Casos de Prueba 11

12 Identificar y Estructurar los Procedimientos de Prueba Revisar y Valorar la Cobertura de la Prueba Identificar y Estructurar los Procedimientos de Prueba Propósito: Analizar los flujos-de-trabajo del caso de uso y de los casos de prueba para identificar procedimientos de prueba. Identificar, en el modelo de prueba, la(s) (inter)relacion(es) entre los casos de prueba y los procedimientos de prueba creando el modelo de prueba. Llevar a cabo lo siguiente: Revisar los flujos-de-trabajo de la aplicación ó el mapa de la aplicación. Desarrollar el Modelo de Prueba Propósito: Comunicar lo que será probado, como ello será probado, y como las pruebas serán implementadas. Para cada procedimiento de prueba descrito (ó mapa de la aplicación y scripts de prueba generados), lo siguiente es hecho para crear el modelo de prueba: Identificar la (inter)relación o secuencia del procedimiento de prueba a otros procedimientos de prueba (ò los scripts de prueba generados a cada quien). Identificar la condición ó estado de inicio y la condición o estado final para el procedimiento de prueba. Indicar los casos de prueba a ser ejecutados por el procedimiento de prueba (ó por los scripts de prueba generados). Lo siguiente debe de ser considerado mientras desarrollando el modelo de prueba: Muchos casos de prueba son variantes de algún otro, lo cual puede significar que ellos pueden ser satisfechos por el mismo procedimiento de prueba. Muchos casos de prueba pueden requerir solapar el comportamiento para ser ejecutado. 12

13 Para ser capaz de re-usar la implementación de tal comportamiento, Ud. puede elegir estructurar Ud. mismo los procedimientos de prueba de modo que un procedimiento de prueba pueda ser usado para varios casos de prueba. Muchos procedimientos de prueba pueden incluir acciones o pasos que son comunes a muchos casos de prueba u otros procedimientos de prueba. En estos casos, debe de ser determinado si un procedimiento de prueba estructurado separado (para aquellos pasos comunes) debe de ser creado, mientras los pasos específicos del caso de prueba permanecen en un procedimiento de prueba estructurado separado. Cuando usando una automatizada herramienta de generación de script de prueba, revise el mapa de aplicación y scripts de prueba generados para asegurar que lo siguiente esté reflejado en el modelo de prueba: Los controles apropiados/deseados están incluidos en el mapa de la aplicación y en los scripts de prueba. Los controles son ejercitados en el orden deseado. Los casos de prueba están identificados para aquellos controles requiriendo datos de prueba. Las ventanas o cajas de dialogo en el cual los controles son displayados. Estructurar los procedimientos de prueba 13

14 8.2.2 (P): Detalle del Flujo-de-trabajo: Implementar Prueba Actividad: Diseñar Clases de Prueba Propósito: Diseñar funcionalidad específica-para-la-prueba. Pasos: Identificar Clases Específicas-para-la-Prueba Diseñar Interfase para Herramienta de Prueba Automatizada Diseñar Comportamiento del Procedimiento de Prueba 14

15 Actividad: Implementar Componentes de la Prueba Propósito: Implementar funcionalidad específica-para-la-prueba. Pasos: Implementar y Prueba de Unidad Drivers / Stubs. Implementar y Prueba de Unidad Interfase a Herramienta(s) de Test Automatizadas. Implementar y Prueba de Unidad Comportamiento del Procedimiento del Test. 15

16 8.2.3 (P): Detalle del Flujo-de-trabajo: Ejecutar Prueba Actividad: Ejecutar Prueba Propósito: Ejecutar pruebas y capturar resultados de las pruebas. Pasos: Ejecutar Procedimientos de Prueba Evaluar Ejecución de la Prueba Verificar Resultados de la Prueba Recuperarse desde Pruebas Detenidas Ejecutar Procedimientos de Prueba Propósito: Ejecutar los procedimientos de prueba (o scripts de prueba si la prueba es automatizada). Pasos: Set-up/Establecer el entorno de la prueba para asegurarse que todos los 16

17 componentes necesitados (hardware, software, herramientas, datos, etc.) han sido implementados y están en el entorno de prueba. Inicializar el entorno de prueba para asegurarse que todos los componentes están en el estado inicial correcto para el arranque de la prueba. Ejecutar los procedimientos de prueba. La ejecución de los procedimientos de prueba variarán dependiendo de si la prueba es automatizada o manual. Prueba automatizada: Los scripts de prueba creados durante la actividad: Implementar Prueba son ejecutados. Ejecución manual: Los procedimientos de prueba estructurados desarrollados durante la actividad: Diseñar Prueba son usados para manualmente ejecutar la prueba. Evaluar Ejecución de la Prueba Propósito: Determinar si la prueba ejecutada hasta finalización o parada Determinar si acción correctiva es requerida La ejecución de la prueba finaliza o termina en una de 2 condiciones: Normal: Todos los procedimientos de prueba (o scripts) se ejecutan como pretendido y hasta conclusión/finalización. Si la prueba termina normalmente, entonces continuar con Verificar Resultados de la Prueba. Anormal ó Prematuro: Los procedimientos de prueba (ó scripts) no se ejecutan completamente ó como pretendido. Cuando la prueba termina anormalmente, los resultados de la prueba pueden ser poco fiables. La causa de la terminación anormal/prematura necesita ser identificada, corregida, y las pruebas re-ejecutadas antes que algunas actividades de prueba adicionales sean llevadas a cabo. 17

18 Si la prueba termina anormalmente, continuar con Recuperarse desde Pruebas Detenidas. Recuperarse desde Pruebas "Detenidas" Propósito: Determinar la acción correctiva apropiada para recuperarse desde una prueba detenida. Corregir el problema, recuperarse, y re-ejecutar las pruebas. Hay 2 tipos mayores de de pruebas detenidas: Errores fatales El sistema falla (fallas de red, "crashes" de hardware, etc.) Fallas de los Comandos del Script de Prueba Específico a Pruebas automatizadas, esto es cuando un script de prueba no puede ejecutar un comando (ó línea de código). Ambos tipos de terminación anormal al probar pueden exhibir los mismos síntomas: muchas acciones, ventanas, o eventos inesperados ocurren mientras el script de prueba está ejecutándose. el entorno de prueba parece no responder o en un estado indeseable (tal como colgado o "crashed"). Para recuperarse desde pruebas detenidas, hacer lo siguiente: Determinar la causa actual del problema Corregir el problema Re-establecer el entorno de prueba Re-inicializar el entorno de prueba Re-ejecutar las pruebas 18

19 ETAPAS DEL TEST La realización de pruebas es usualmente aplicada a tipos diferentes de objetivos en diferentes etapas o niveles del esfuerzo de trabajo. Estos niveles son distinguidos típicamente por cuales roles están mejor calificados/preparados para diseñar y conducir los tests, y en cuales técnicas son la más apropiadas para probar en cada nivel. Es importante asegurar un balance de enfoque que es retenido a través de estos diferentes esfuerzos de trabajo. Pruebas de Unidad Una diferenciación tradicional, pruebas de unidad, implementada temprano en la iteración, se enfoca en verificar los más pequeños elementos testeables del software. La prueba de unidad es típicamente aplicado a componentes en el Modelo de Implementación para verificar que los flujos de control y los flujos de datos están cubiertos y funcionan como esperado. Estas expectativas están basadas en como el componente participa en ejecutar un caso de uso, lo cual se encuentra a partir de los diagramas de secuencia para ese caso de uso. El Implementador lleva a cabo la prueba de unidad a medida que la unidad es desarrollada. Los detallaes de las pruebas de unidad son descritas en la disciplina de Implementación. Prueba de Integración Una diferenciación tradicional, una prueba de integración es ejecutada para asegurar que los componentes en el Modelo de Implementación operan apropiadamente cuando combinados para ejecutar un caso de uso. El objetivo del test es un paquete ó conjunto de paquetes en el Modelo de Implementación. Con frecuencia los paquetes a ser combinados vienen de diferentes organizaciones de desarrollo. El test de integración expone incomplitud o errores en las especificaciones de interface del paquete. 19

20 Prueba del Sistema Una diferenciación tradicional, el test del sistema es tradicionalmente hecho cuando el software está funcionando como un todo. Un ciclo de vida iterativo permite que los test del sistema ocurran mucho más temprano, tan pronto como subconjuntos bien-formados del comportamiento del caso de uso son implementados. El blanco/objetivo es típicamente elementos funcionantes extremo-a-extremo del sistema. Prueba de Aceptación EL test de aceptación "usuario" es típicamente la acción de prueba final previo a desplegar el software. La meta del test de aceptación es verificar que el software esta listo y puede ser usado por los usuarios finales para ejecutar aquellas funciones y tareas que el software fue construido para hacer. 20

21 Bibliografía - The Enterprise Unified Process: Extending the Rational Unified Process Scott W. Ambler, John Nalbone, Michael Vizdos Prentice Hall PTR, Aspect-Oriented Software Development with Use Cases Pan-Wei Ng, Ivar Jacobson Addison Wesley, Software Engineering Process with the UPEDU Pierre N. Robillard, Philippe Kruchten, Patrick d Astous Addison Wesley, Rational Unified Process Made Easy, The: A Practitioner s Guide to the RUP Per Kroll, Philippe Kruchten Addison Wesley, INGENIERÍA DE SOFTWARE Una perspectiva orientada a objetos Eric J. Braude Alfaomega, UML y PATRONES 2e Una introducción al análisis y diseño orientado a objetos y el proceso unificado Craig Larman Prentice Hall, Use Case Modeling Kurt Bittner, Ian Spence Addison Wesley, Building J2EE Applications with the Rational Unified Process Peter Eeles, Kelli Houston, Wojtek Kozaczynski Addison Wesley, A Practical Guide to Feature-Driven Development Sthefen R. Palmer, John M. Felsing Prentice Hall,

22 - EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3e Martin Fowler Addison Wesley, MDA Explained: The Model Driven Architecture Practice and Promise Anneke Kleppe, Jos Warmer, Win Bast Addison Wesley, The Object Primer 3e: Agile Model Driven Development with UML 2 Scott W. Ambler Cambridge University Press,

23 Acrónimos: ADD : Attribute-Driven Design ADM : Advanced Development Method AOSD : Aspect Oriented Software Development API : Application Program Interface ASL : Action Semantic Language ASP : Active Server Pages ASP : Application Services Provider ATA : Advanced Technology Attachment (dispositivos de almacenamiento) ATM : Asynchronous Transfer Mode (redes) ATM : Automated Teller Machine BPR : Business Process Reengineering CAM : Computer-Aided Manufacturing CASE : Computer-Aided Software Engineering CBD : Component-Based Development CGI : Common Gateway Interface CIFS : Common Internet File System CIM : Computer-Integrated Manufacturing CM : Configuration Management CMM : Capability Maturity Model CMMI : Capability Maturity Model Integration COBOL : COmmon Business Oriented Language COCOMO : COnstruction COst Model COM : Common Object Model CORBA : Common Object Request Broker Architecture CRC : Class-Responsibility-Collaboration CRM : Customer Relationship Management CWM : Common Warehouse Meta-model DCOM : Distributed Component Object Model ERP : Enterprise Resource Planning GIMP : GNU Image Manipulation Program GNU : GPL : General Public Licence GRASP : GUI : Graphical User Interface HPEC : High Performance Embedded Computing HTML : HyperText Markup Language IBM : International Business Machines 23

24 ICSE : International Conference on Software Engineering IDE : Integrated Development Environment IDE : Integrated Drive Electronics (hardware) IDL : Interface Description Language IEEE : Institute of Electrical and Electronics Engineers IIOP : Internet Inter-ORB Protocol IMAP4 : Internet Message Access Protocol-version 4 ISO : International Standardization Organization ISP : Internet Server Provider ISV : Independent Software Vendor IT : Information Technology I/O : Input/Output JAD : Joint Application Design JMI : Java Metadata Interface JSF : Java ServerFaces JVM : Java Virtual Machine J2EE : Java 2 platform, Enterprise Edition KISS : Keep It Simple, Silly MDD : Model Driven Development MDSD : Model-Driven Software Development MEP : Message Exchange Pattern MFC : Microsoft Foundation Classes MIME : Multipurpose Internet Mail Extension MIT : Massachusetts Institute of Technology MOF : Meta-Object Facility MOF : Microsoft Operations Framework MPLS : MultiProtocol Label Switching NAT : Network Address Translation OCL : Object Constraint Language OLE : Object Linking and Embedding OMG : Object Management Group OML : Object Modeling Language OMT : Object Modeling Technique OO : Object Oriented OOAD : Object Oriented Analysis and Design ORB : Object Request Broker OSS : Open Source Software PDA : Personal Desktop Assistant PERL : Practical Extraction & Reporting Language 24

25 PERT : Project Evaluation and Review Technique PGP : Pretty Good Privacy PIN : Personal Identification Number PMI : Project Management Institute POS : Point-of-Sale PRM : Peer Review Meeting P2P : Peer to Peer QA : Quality Assurance QoS : Quality of Service QVT : Query, Views, and Transforms RAD : Rapid Application Development RAS : Reusable Asset Specification RFC : Request For Comment RFI : Request For Information RFP : Request For Proposal RMI : Remote Method Invocation ROI : Return On Investment ROOM : Real-time Object-Oriented Method ROP : Rational Objectory Process RPC : Remote Procedure Call RPM : Rational Process Workbench RTE : RoundTrip Engineering RUP : Rational Unified Process SAP : Systems, Applications, and Products SCM : Software Configuration Management SEI : Software Engineering Institute SIP : Signal and Image Processing SLA : Service Level Agreements SLOC : SOA : Service Oriented Architecture SPEM : Software Process Engineering Metamodel SPI : Software Process Improvement SPICE : Software Process Improvement Capability determination SQA : Software Quality Assurance SQL : Structured Query Language SQS : Software Quality Systems TCO : Total Cost of Ownership TCP/IP : Transmission Control Protocol/Internet Protocol TDD : Test-Driven Development 25

26 TPS TQM UCD UI UML UPEDU URL PUDS USPM WSA : Transaction Processing System : Total Quality Management : User Centered Design : User Interface : Unified Modeling Language : Unified Process for EDUcation : Uniform Resource Locator : Proceso Unificado de Desarrollo de Software : Unified Software Process Metamodel : Web Service Architecture WYSIWYG : What You See Is What You Get W3C : World Wide Web Consortium XDE : extended Development Environment XMI : XML Metadata Interchange XML : extensible Markup Language 3GL 4GL : Third-Generation Language : Fourth-Generation Language 26

UNIVERSIDAD NACIONAL DE SAN ANTONIO ABAD DEL CUSCO

UNIVERSIDAD NACIONAL DE SAN ANTONIO ABAD DEL CUSCO FACULTAD DE CS. QUIMICAS, FISICAS Y MATEMATICAS I. DATOS GENERALES DEPARTAMENTO ACADEMICO DE INFORMATICA SILABO 1.1 Asignatura : SISTEMAS DE INFORMACION II 1.2 Categoría : OE 1.3 Código : IF202AIN 1.4

Más detalles

El Proceso Unificado Rational para el Desarrollo de Software.

El Proceso Unificado Rational para el Desarrollo de Software. Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar

Más detalles

Objetos Distribuidos - Componentes. Middleware

Objetos Distribuidos - Componentes. Middleware Objetos Distribuidos - Componentes Middleware Middleware Component Oriented Development Arquitecturas 3 Tier Middleware es el software que: conecta y comunica los componentes de una aplicacion distribuida

Más detalles

UML, OCL y Patrones en el contexto MDA

UML, OCL y Patrones en el contexto MDA UML, OCL y Patrones en el contexto MDA Ana Garis email: agaris@unsl.edu.ar Maestría en Ingeniería de Software Agenda Model Driven Architecture (MDA) Unified Modeling Language (UML) y Perfiles UML Object

Más detalles

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software UML El Lenguaje de Modelado Unificado Maestría en Ingeniería de Software Agenda Model Driven Architecture (MDA) Unified Model Language (UML) Object Constraint Language (OCL) Patrones Conclusiones Contenido

Más detalles

Curso: El Proceso de Desarrollo de Software

Curso: El Proceso de Desarrollo de Software Curso: El Proceso de Desarrollo de Software EL PROCESO DE DESARROLLO DE SOFTWARE... 1 OBJETIVO...1 CONTENIDO...1 BIBLIOGRAFÍA...4 DOCENTE...4 MODALIDAD DEL DESARROLLO...4 El proceso de Desarrollo de Software

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Estudio Comparativo de Técnicas de Modelado de Negocio

Estudio Comparativo de Técnicas de Modelado de Negocio Estudio Comparativo de Técnicas de Modelado de Negocio Juan José Cadavid 1, Carlos Andrés Ospina 1, Juan Bernardo Quintero 2 1 Avansoft S.A. Medellín, Colombia {jjcadavid, caospina}@avansoft.com 2 ABC-Flex

Más detalles

Componentes y Middleware. Arquitectura de Software Componentes y Middleware [1] Stakeholders. Sobre el informe. Calidad según los stakeholders

Componentes y Middleware. Arquitectura de Software Componentes y Middleware [1] Stakeholders. Sobre el informe. Calidad según los stakeholders sistema Componentes y Middleware Arquitectura de Software Componentes y Middleware [1] Componentes Middleware Políticas y mecanismos Ejemplo de notación ad-hoc Hernán Astudillo Departamento de Informática

Más detalles

Arquitectura de Software Componentes y Middleware [1] Componentes y Middleware. Sobre el informe

Arquitectura de Software Componentes y Middleware [1] Componentes y Middleware. Sobre el informe Arquitectura de Software Componentes y Middleware [1] Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María Componentes y Middleware Componentes Middleware

Más detalles

Enterprise Architect y UML Basic

Enterprise Architect y UML Basic Enterprise Architect y UML Basic Diciembre 2008 Carlos Alexander Zuluaga Agenda Presentación del curso. Introducción a Enterprise Architect. Exploración del modelo de ejemplo. Introducción a UML. Definición

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio M. Teresa García 1, Mercedes Ruiz 1 y Cristina Vicente-Chicote 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad

Más detalles

Extensión MDA (Model Driven Architecture) para proceso basado en RUP (Rational Unified Process)

Extensión MDA (Model Driven Architecture) para proceso basado en RUP (Rational Unified Process) Extensión MDA (Model Driven Architecture) para proceso basado en RUP (Rational Unified Process) Andrea Delgado, Natacha Carballal, Catalina Rapetti Universidad de la República, Facultad de Ingeniería,

Más detalles

Proceso Unificado de Rational (RUP)

Proceso Unificado de Rational (RUP) Especialización en Telemática Proceso Unificado de Rational (RUP) Arquitecturas de Sistemas Telemáticos Dr. Ing. Álvaro Rendón Gallón Cali, mayo de 2012 Temario 2 Antecedentes Objetivos Características

Más detalles

Historia de revisiones

Historia de revisiones Binary Rain Glosario Versión 1.1 Historia de revisiones Fecha Versión Descripción Autor 17/08/2012 1.0 Creación del documento Carolina Trias 18/08/2012 1.1 Revisado y corregido por SQA Mercedes Marzoa

Más detalles

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Ing. Marcela Daniele AC. Daniel Romero Dpto. de Computación. Facultad: Ciencias Exactas,

Más detalles

IBM Software Development Platform

IBM Software Development Platform IBM Group IBM Development Platform Seminario. antonio.alonso@es.ibm.com IBM Group software Agenda 1. Introducir plataforma de desarrollo de IBM. 2. DEMO: Construcción de aplicaciones J2EE con RAD. 3. Café

Más detalles

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del 1. OBJETIVOS: Incorporar los conceptos de indicador, métrica, medida, escala de medición, y proceso de medición. Entender la importancia de los indicadores de desempeño de procesos, su medición y seguimiento.

Más detalles

Guía Docente 2013/2014

Guía Docente 2013/2014 Guía Docente 2013/2014 Ingeniería del Software II Software Engineering II Grado en Ingeniería Informática Presencial Universidad Católica San Antonio de Murcia Tlf: (+34) 902 102 101 info@ucam.edu www.ucam.edu

Más detalles

Programación del curso

Programación del curso Ingeniería Software 4º Físicas Programación del curso José M. Drake (drakej@unican.es) Patricia López Martínez ( lopezpa@unican.es ) Computadores y Tiempo Real Santander, 2008 Ingeniería de Programación

Más detalles

Desarrollo de Software con enfoque en el Negocio

Desarrollo de Software con enfoque en el Negocio Desarrollo de Software con enfoque en el Negocio Andrea Delgado Instituto de Computación Facultad de Ingeniería Universidad de la República 11300, Montevideo, Uruguay adelgado@fing.edu.uy Resumen Las Organizaciones

Más detalles

Planificaciones. 7509 - Análisis de la Información. Docente responsable: VILLAGRA SERGIO GUSTAVO. 1 de 6

Planificaciones. 7509 - Análisis de la Información. Docente responsable: VILLAGRA SERGIO GUSTAVO. 1 de 6 Planificaciones 7509 - Análisis de la Información Docente responsable: VILLAGRA SERGIO GUSTAVO 1 de 6 OBJETIVOS Que los alumnos: a) Entiendan la naturaleza del software y las complejidades de su desarrollo.

Más detalles

Programa del curso IC 6821. Diseño de Software. Escuela de Computación Carrera de Ingeniería en Computación, Plan 410

Programa del curso IC 6821. Diseño de Software. Escuela de Computación Carrera de Ingeniería en Computación, Plan 410 Programa del curso IC 6821 Diseño de Software Escuela de Computación Carrera de Ingeniería en Computación, Plan 410 I parte: Aspectos relativos al plan de estudios 1 Datos generales Nombre del curso: Código:

Más detalles

Glosario. B Best in Class: Mejor en su clase Business Case: Caso de Negocio

Glosario. B Best in Class: Mejor en su clase Business Case: Caso de Negocio Glosario A AMS Asset Management Solutions: Servicios de Administración de Aplicaciones de software las cuales pueden ser monitoreadas remotamente. Assesment: Evaluación realizada a una empresa, en el cual

Más detalles

Tema 1: Introducción a las tecnologías

Tema 1: Introducción a las tecnologías Tema 1: Introducción a las tecnologías de integración de aplicaciones Índice Introducción Integración de Aplicaciones Arquitectura de referencia Capa de Integración de Plataforma Capa de Acceso e Integración

Más detalles

Ing. Norman Vargas Chévez Facultad de Electrotecnia y Computación Universidad Nacional de Ingeniería e-mail: norman.vargas@uni.edu.

Ing. Norman Vargas Chévez Facultad de Electrotecnia y Computación Universidad Nacional de Ingeniería e-mail: norman.vargas@uni.edu. MODELACIÓN DEL PROCESO DE INFORMACIÓN EN LA COMPRA VENTA DE ENERGÍA EN EL MERCADO ELÉCTRICO DEREGULADO EN NICARAGUA - DESDE EL PUNTO DE VISTA DEL CENTRO NACIONAL DE DESPACHO DE CARGA- Ing. Norman Vargas

Más detalles

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio Arturo Cepeda Pérez, Sergio Bravo Martín, Francisco José García Peñalvo Universidad de Salamanca, Facultad

Más detalles

Lista de acrónimos... 15

Lista de acrónimos... 15 Índice general Lista de acrónimos... 15 CAPÍTULO 1. Visión general y entorno de desarrollo... 17 1.1. Qué hace Android especial?... 18 1.2. Los orígenes... 19 1.3. Comparativa con otras plataformas...

Más detalles

Oscar Alberto, Custodio Izquierdo Carlos Arturo, Hernández Torruco José Fecha de elaboración: 28 de Mayo de 2010 Fecha de última actualización:

Oscar Alberto, Custodio Izquierdo Carlos Arturo, Hernández Torruco José Fecha de elaboración: 28 de Mayo de 2010 Fecha de última actualización: PROGRAMA DE ESTUDIO Laboratorio de diseño de software Universidad Juárez Autónoma de Tabasco Programa Educativo: Área de Formación : Licenciatura en Informática Administrativa Sustantiva Profesional Horas

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

servicios. El API es definido al nivel de código fuente y proporciona el nivel de

servicios. El API es definido al nivel de código fuente y proporciona el nivel de GLOSARIO API Application Program -ming- Interface Es la interfaz por la cual una aplicación accede al sistema operativo u a otros servicios. El API es definido al nivel de código fuente y proporciona el

Más detalles

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM Fabio A. Zorzan y Daniel Riesco Resumen Esta línea de investigación propone una alternativa para lograr la automatización de la gestión

Más detalles

Curso: Arquitectura de Software (201101-Nuevo Pensum) Profesor: Juan Bernardo Quintero Institución: Universidad de Antioquia

Curso: Arquitectura de Software (201101-Nuevo Pensum) Profesor: Juan Bernardo Quintero Institución: Universidad de Antioquia Curso: Arquitectura Software (201101-Nuevo Pensum) Profesor: Juan Bernardo Quintero Institución: Universidad Antioquia 1. Objetivo General Brindar a los estudiantes herramientas para facilitar el uso metodologías

Más detalles

Perfil UML para el desarrollo de aplicaciones WAP

Perfil UML para el desarrollo de aplicaciones WAP Perfil UML para el desarrollo de aplicaciones WAP Ricardo Soto D., Mauricio Camara J. Escuela de Ingeniería Informática, Pontificia Universidad Católica de Valparaíso, Chile E-mail: ricardo.soto@ucv.cl,

Más detalles

Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado)

Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado) Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado) Mg. Elsa Estévez Universidad Nacional del Sur T.2 Contenidos 1 1) lenguaje XML extensible

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

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

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Pontificia Universidad Católica del Ecuador

Pontificia Universidad Católica del Ecuador 1. DATOS INFORMATIVOS: MATERIA O MÓDULO: INGENIERÍA DE SOFTWARE I CÓDIGO: CARRERA: SISTEMAS NIVEL: QUINTO No. CRÉDITOS: 4 CRÉDITOS TEORÍA: 4 SEMESTRE/AÑO ACADÉMICO: Segundo Semestre 2011-2012 CRÉDITOS

Más detalles

Guía Docente Curso 2012-2013

Guía Docente Curso 2012-2013 ESCUELA TÉCNIICA SUPERIIOR DE IINGENIIERÍÍA Guía Docente Curso 2012-2013 Titulación Ingeniería Informática DATOS DE LA ASIGNATURA * * Asignatura en experiencia piloto de implantación del sistema de créditos

Más detalles

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3 Contenido INGENIERIA DE SOFTWARE Tema 6: Administración de la calidad del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Introducción 2.

Más detalles

Técnico Certified Software Engineer Professional (CSIP)

Técnico Certified Software Engineer Professional (CSIP) Técnico Certified Software Engineer Professional (CSIP) Dirigido a: Profesionales de la ingeniería de sistemas Estudiantes universitarios de ingeniería en sistemas Requisitos: Requisitos para aplicar a

Más detalles

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Fabio A. Zorzan 1 y Daniel Riesco 2 Resumen Esta línea de investigación pretende aportar a la mejora

Más detalles

Java XML Web Services.

Java XML Web Services. Java XML Web Services. Desarrollo de Servicios Web XML con JWSDP_1.2 Bajo Plataforma GNU/Linux. Por: Xtecuan! Ufo. (Catedratico GFET) Objetivos. Presentar los conceptos básicos sobre Web Services. Presentar

Más detalles

PROGRAMA CONTENIDOS. Laudon, Kenneth C. y Laudon, Jane P. - SISTEMAS DE INFORMACIÓN GERENCIAL Editorial Prentice Hall, sexta edición 2002.

PROGRAMA CONTENIDOS. Laudon, Kenneth C. y Laudon, Jane P. - SISTEMAS DE INFORMACIÓN GERENCIAL Editorial Prentice Hall, sexta edición 2002. PROGRAMA 1) OBJETIVOS DE LA ASIGNATURA Que el Estudiante forme su criterio profesional integrando los conocimientos y experiencia práctica necesarios para poder construir e implementar un Sistema de Información

Más detalles

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Introducción al Unified Process Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Unified Process - UP Un framework de Proceso de Desarrollo de Software, una de cuyas versiones es el más documentado

Más detalles

Qué es una arquitectura?

Qué es una arquitectura? Dra. Maricela Bravo Qué es una arquitectura? IEEE 1471 El nivel conceptual más alto de un sistema en su ambiente. Arquitectura es la organización fundamental de un sistema descrita en: Sus componentes.

Más detalles

5. Modelos de Sistemas Distribuidos

5. Modelos de Sistemas Distribuidos Sistemas Distribuidos 5. Modelos de Sistemas Distribuidos Prof. María Feldgen Curso 2006 Índice Modelos Modelo Cliente-Servidor Framework CORBA Java RMI Microsoft DCOM Message-Oriented Middleware Dificultades

Más detalles

Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT

Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT Fabio A. Zorzan 1, Daniel Riesco 2 CONTEXTO La línea de investigación presentada en este trabajo se desarrolla en el marco del

Más detalles

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores.

Glosario Acoplamiento. API. Archivos de recursos. ASCII. Balanceo de carga. Bases de datos federadas. BBDD. Clientes. Constructores. GLOSARIO Glosario Acoplamiento. Posibilidad que tiene un servicio de funcionar de forma autónoma. Se dice que un servicio o aplicación es bajamente acoplado cuando puede funcionar de forma independiente

Más detalles

IBM Rational Software Architect

IBM Rational Software Architect Unificación de todos los aspectos del diseño y del desarrollo de software IBM Rational Software Architect Un conjunto completo de herramientas de diseño y desarrollo Incorpora todas las capacidades en

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Contenidos. Tema 3. El Método de desarrollo. El Proceso Unificado. Objetivos del tema. 3.1 Métodos actuales de desarrollo OO

Contenidos. Tema 3. El Método de desarrollo. El Proceso Unificado. Objetivos del tema. 3.1 Métodos actuales de desarrollo OO Tema 3. El Método de desarrollo. El Proceso Unificado Miguel A. Laguna Contenidos 3.1 Métodos actuales de desarrollo OO 3.1.1 Concepto de Método y Proceso 3.1.2 Generaciones de métodos OO 3.2 El Proceso

Más detalles

Período Teoría Práctica Laboratorio de crédito Electiva 3 0 0 3 Requisitos Metodología del Software

Período Teoría Práctica Laboratorio de crédito Electiva 3 0 0 3 Requisitos Metodología del Software Asignatura METODOLOGÍAS ÁGILES DE GESTIÓN Y DESARROLLO DE PROYECTOS DE TI Vigente desde: Marzo 2008 Horas semanales Unidades Período Teoría Práctica Laboratorio de crédito Electiva 3 0 0 3 Requisitos Metodología

Más detalles

GUÍA DOCENTE INGENIERÍA DEL SOFTWARE Grado en Ingeniería Informática. Profesorado: Juan Manuel Gimeno Illa Montserrat Sendin Veloso

GUÍA DOCENTE INGENIERÍA DEL SOFTWARE Grado en Ingeniería Informática. Profesorado: Juan Manuel Gimeno Illa Montserrat Sendin Veloso Año académico 2014-15 GUÍA DOCENTE INGENIERÍA DEL SOFTWARE Grado en Ingeniería Informática Profesorado: Juan Manuel Gimeno Illa Montserrat Sendin Veloso Información general de la asignatura Denominación

Más detalles

Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP

Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP Fabio A. Zorzan 1, Daniel Riesco 2, Nora Szasz 3 CONTEXTO La línea de investigación

Más detalles

(Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un

(Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un (Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un compilador/intérprete y un depurador (localización de errores lógicos).

Más detalles

Reporte Técnico RT 07-02

Reporte Técnico RT 07-02 PEDECIBA Informática Instituto de Computación Facultad de Ingeniería Universidad de la República Montevideo, Uruguay Reporte Técnico RT 07-02 Extensión MDA (Model Driven Architecture para proceso basado

Más detalles

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA).

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). López, G. 1 ; Jeder, I. 1 ; Echeverría, A. 1 ; Fierro, P. (PhD.) 2 1. Laboratorio de Informática de Gestión

Más detalles

PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE

PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS POSTGRADO EN CIENCIAS DE LA COMPUTACIÓN PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE INFORMACIÓN GENERAL Profesor: Francisca Losavio

Más detalles

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2007-2008 Índice Introducción Tipos de servidores Ventajas Desventajas Arquitectura de una

Más detalles

Diagrama de actividad

Diagrama de actividad Diagrama de actividad Se utiliza para representar los procedimientos o secuencia de pasos dentro de procedimientos, procesos o flujo de información. Contenido Generalidades de un diagrama de actividad...

Más detalles

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado Diseño lógico de sistemas aplicando el lenguaje de modelado unificado No. De Registro CGPI: 20061221. Director del proyecto: Roberto De Luna Caballero. Profesores participantes: M. en C Fabiola Ocampo

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

Aplicaciones Distribuidas. Informática III

Aplicaciones Distribuidas. Informática III Aplicaciones Distribuidas Informática III Temario Elementos arquitecturales Arquitecturas tradicionales Arquitecturas Cliente/Servidor Arquitecturas distribuidas Elementos Arquitecturales Componentes de

Más detalles

INGENIERÍA DE SOFTWARE Rational Unified Process RUP

INGENIERÍA DE SOFTWARE Rational Unified Process RUP 1 INGENIERÍA DE SOFTWARE Rational Unified Process RUP Rubby Casallas Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Referencias 2 http://www.rational.com/ http://www-306.ibm.com/software/awdtools/rup/

Más detalles

Edgar Fernando Hernández Salgado

Edgar Fernando Hernández Salgado Edgar Fernando Hernández Salgado Arquitecto SOA 1. DATOS PERSONALES Nacionalidad: Mexicana Fecha de Nacimiento: 7 de Julio de 1983 Idiomas: Inglés (Intermedio) 2. PERFIL PROFESIONAL Software Enginering

Más detalles

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Andrea Delgado 1, Ignacio García-Rodríguez de Guzmán 2, Francisco Ruiz 2, Mario Piattini 2 1 Instituto de Computación,

Más detalles

Una Introducción al UML. El Modelo Físico

Una Introducción al UML. El Modelo Físico Una Introducción al UML Autor: Geoffrey Sparks, Sparx Systems, Australia Traducción: Fernando Pinciroli (Solus S.A., Argentina) y Aleksandar Orlic (Craftware Consultores Ltda., Chile) www.sparxsystems.com.ar

Más detalles

Introducción. El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad

Introducción. El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad Dra. María a José Escalona Cuaresma mjescalona@us.es www.iwt2.org Universidad de Sevilla Grupo de Ingeniería Web y Testing

Más detalles

Cuándo estoy listo para pasar a producción?

Cuándo estoy listo para pasar a producción? IBM Software Expo 2006. Madrid 23 de Mayo Cuándo estoy listo para pasar a producción? antonio.alonso @ es.ibm.com IBM Software 2005 IBM Corporation Agenda IBM Software Expo 2006. Madrid, 23 de mayo La

Más detalles

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

Más detalles

Guía Docente 2015-2016

Guía Docente 2015-2016 Guía Docente 2015-2016 Modelado del software Modeling Software Grado en Ingeniería Informática A distancia lf: Índice Modelado del Software... 3 Breve descripción de la asignatura... 3 Brief Description...

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Alejandro J Bianchi. Software Architecture Professional Certficate Software Engineering Institute, CMU University.

Alejandro J Bianchi. Software Architecture Professional Certficate Software Engineering Institute, CMU University. Ciclos de Vida guiados por la Arquitectura: Balanceando entre agilidad, eficiencia y calidad Alejandro J Bianchi ATAM Evaluator Certificate Software Architecture Professional Certficate Software Engineering

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS (L40629) Sabino Miranda-Jiménez

PROGRAMACIÓN ORIENTADA A OBJETOS (L40629) Sabino Miranda-Jiménez PROGRAMACIÓN ORIENTADA A OBJETOS (L40629) Sabino Miranda-Jiménez Paradigmas de programación 2 Paradigmas de programación Paradigma de programación estructurada Enfatiza la separación datos de un programa

Más detalles

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web

Servicio Web. Estándares empleados. Ventajas de los servicios web. Inconvenientes de los servicios Web Servicio Web Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Plan de iteraciones RUP Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes (miniproyectos)

Más detalles

IBM Rational for Power i. The business-driven development lifecycle

IBM Rational for Power i. The business-driven development lifecycle IBM Rational for Power i The business-driven development lifecycle Agenda Business Driven Development Rational Development Lifecycle DEMO 2 The business-driven development lifecycle Prioritize Plan Manage

Más detalles

Principios de Análisis Informático. Tema 2: El proceso unificado de desarrollo de software

Principios de Análisis Informático. Tema 2: El proceso unificado de desarrollo de software Principios de Análisis Informático Tema 2: El proceso unificado de desarrollo de software Eduardo Mosqueira Rey LIDIA Laboratorio de Investigación y desarrollo en Inteligencia Artificial Departamento de

Más detalles

Carrera: IFM - 0434 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: IFM - 0434 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Sistemas de I Licenciatura en Informática IFM - 0434 3-2-8 2.- HISTORIA DEL PROGRAMA

Más detalles

UNIVERSIDAD POLITÉCNICA DE CARTAGENA

UNIVERSIDAD POLITÉCNICA DE CARTAGENA UNIVERSIDAD POLITÉCNICA DE CARTAGENA ESCUELA SUPERIOR DE INGENIERÍA DE TELECOMUNICACIÓN Estudio de herramientas de desarrollo de software basado en modelos: MDA y Factorías de Software AUTOR Ramón García

Más detalles

Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a partir de procesos del negocio en un contexto de Negocio Bajo Demanda

Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a partir de procesos del negocio en un contexto de Negocio Bajo Demanda Una recomendación basada en MDA, BPM y SOA para el desarrollo de software a partir de procesos del negocio en un contexto de Negocio Bajo Demanda Miguel Ángel Sánchez Vidales Escuela Universitaria de Informática

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

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2004-2005 Índice Introducción Tipos de servidores Ventajas Separación de funciones Modelos

Más detalles

Desarrollo de Software

Desarrollo de Software Especialización en Telemática Desarrollo de Software Arquitecturas de Sistemas Telemáticos Dr. Ing. Álvaro Rendón Gallón Cali, mayo de 2012 Temario 2 Tarea 1: Ordenar datos Tarea 2: Un juego en red Consideraciones

Más detalles

DEFINIDOR VISUAL BAJO ECLIPSE EUROPA

DEFINIDOR VISUAL BAJO ECLIPSE EUROPA UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITÉCNICA SUPERIOR INGENIERÍA EN INFORMÁTICA PROYECTO FIN DE CARRERA DEFINIDOR VISUAL BAJO ECLIPSE EUROPA Autora: Mónica Burcio Sánchez Tutora: Pilar Aránzazu

Más detalles

BIBLIOGRAFÍA. MCCONNELL, Steve. Desarrollo Y Gestión De Proyectos Informáticos. Washington, Estados Unidos: Escala, 1997. 710 p. (ISB: 8448112296).

BIBLIOGRAFÍA. MCCONNELL, Steve. Desarrollo Y Gestión De Proyectos Informáticos. Washington, Estados Unidos: Escala, 1997. 710 p. (ISB: 8448112296). BIBLIOGRAFÍA HARTMANN, Deborah, Interview: Jim Johnson of the Standish Group. Internet: http://www.infoq.com/articles/interview-johnson-standish-chaos. THE STANDISH GROUP INTERNATIONAL. 1994; 1995. The

Más detalles

Introducción a Rational Unified Process (RUP)

Introducción a Rational Unified Process (RUP) Qué es un Proceso de Desarrollo de SW? Introducción a Patricio Letelier letelier@dsic.upv.es Departamento Sistemas Informáticos y Computación (DSIC) (UPV) - España Define Quién debe hacer Qué, Cuándo y

Más detalles

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de GLOSARIO Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de una descripción de bajo nivel (código fuente) para generar descripciones con un mayor grado de abstracción.

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

Ciencias Holguín E-ISSN: 1027-2127 revista@ciget.holguin.inf.cu. Centro de Información y Gestión Tecnológica de Santiago de Cuba.

Ciencias Holguín E-ISSN: 1027-2127 revista@ciget.holguin.inf.cu. Centro de Información y Gestión Tecnológica de Santiago de Cuba. Ciencias Holguín E-ISSN: 1027-2127 revista@ciget.holguin.inf.cu Centro de Información y Gestión Tecnológica de Santiago de Cuba Cuba Leyva Miranda, Enrique José; González Prieto, Mileidys Una adaptación

Más detalles

BOA, un framework MDA de alta productividad

BOA, un framework MDA de alta productividad BOA, un framework MDA de alta productividad Padrón Lorenzo, J. 1, Estévez García A. 1, Roda García J.L. 2, García López F. 2 1 Open Canarias SL, Santa Cruz Tenerife, España http://www.opencanarias.com

Más detalles

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Autora: Vasquez Pilar María Directora: Dra. Giandini Roxana Codirectora: Mg. Bazán Patricia Agenda Introducción.

Más detalles

Servidores Donantonio

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

IBM RATIONAL JAZZ ROADSHOW

IBM RATIONAL JAZZ ROADSHOW IBM Software Group IBM RATIONAL JAZZ ROADSHOW Jazz -Plataforma de Desarrollo Rational Collaborative Lifecycle Management Marzo de 2012 2011 IBM Corporation Qué es Jazz? IBM Software Group Rational software

Más detalles

Proyecto Tutelkán. Tutelkan Process Framework (TPF) - Fundamentos del Metamodelo

Proyecto Tutelkán. Tutelkan Process Framework (TPF) - Fundamentos del Metamodelo Proyecto Tutelkán Tutelkan Process Framework (TPF) - Fundamentos del Metamodelo MARZO 2009 Tabla de Contenidos 1. INTRODUCCIÓN...4 2. ESTADO DEL ARTE...5 3. ESTRATEGIA DE DESARROLLO DE TPF...5 3.1. SELECCIÓN

Más detalles