Your SlideShare is downloading. ×
La importancia del_modelado_en_la_producción_de_sw_vf
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

La importancia del_modelado_en_la_producción_de_sw_vf

391
views

Published on

La presentación tiene que ver con la importancia del modelado en las primeras etapas del proceso de desarrollo de software.

La presentación tiene que ver con la importancia del modelado en las primeras etapas del proceso de desarrollo de software.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
391
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Dr. Carlos Arias Méndez (UNPA - UMAG)Ing. Silvia Gabriela Rivadeneira (UNPA)Ing. Juan Enrique Fontana (UNPA)Ángel G. Páez (Estudiante Analista de Sistemas)Claudio R. Monserrat (Estudiante Analista deSistemas) Del 11 al 22 De Junio. Río Turbio. SANTA CRUZ
  • 2. • 1. m. Arquetipo o punto de referencia para imitarlo o reproducirlo.• 2. m. En las obras de ingenio y en las acciones morales, ejemplar que por su perfección se debe seguir e imitar.• 3. m. Representación en pequeño de alguna cosa.• 4. m. Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja, como la evolución económica de un país, que se elabora para facilitar su comprensión y el estudio de su comportamiento.• 5. m. Objeto, aparato, construcción, etc., o conjunto de ellos realizados con arreglo a un mismo diseño. Auto modelo 1976. Lavadora último modelo.• 6. m. Vestido con características únicas, creado por determinado modista, y, en general, cualquier prenda de vestir que esté de moda.• 7. m. En empresas, u. en aposición para indicar que lo designado por el nombre anterior ha sido creado como ejemplar o se considera que puede serlo. Empresa modelo. Granjas modelo.• 8. m. Esc. Figura de barro, yeso o cera, que se ha de reproducir en madera, mármol o metal.• 9. m. Cuba. impreso (‖ hoja con espacios en blanco).• 10. com. Persona de buena figura que en las tiendas de modas se pone los vestidos, trajes y otras prendas para que las vean los clientes.• 11. com. Esc. y Pint. Persona u objeto que copia el artista. • Diccionario de la Real Academia Española. PI 29/B134 "Modelado de Requerimientos y 2 Diseño de Sistemas Complejos"
  • 3. • Booch, Rumbaugh y Jacobson (2006) establecen que un modelo es una simplificación de la realidad, que modelamos para comprender mejor el sistema que estamos desarrollando, y agregan que cuando el sistema se complejiza, el modelado se vuelve muy importante ya que si no lo construimos no podemos comprender el sistema en su totalidad. PI 29/B134 "Modelado de Requerimientos y 3 Diseño de Sistemas Complejos"
  • 4. • Para comprender el sistema actual.• Para conceptualizar la solución.• Para mejorar la comunicación.• Para evitar ambigüedades e interpretaciones erróneas. PI 29/B134 "Modelado de Requerimientos y 4 Diseño de Sistemas Complejos"
  • 5. • Atómicos, Matemáticos, Económicos, Educativos, Pedagógicos, y otros. PI 29/B134 "Modelado de Requerimientos y 5 Diseño de Sistemas Complejos"
  • 6. • Programas de computadora, procedimientos, documentación posiblemente asociada y datos en relación con la operación de un sistema de computadora (IEEE Std 610.12-1990). PI 29/B134 "Modelado de Requerimientos y 6 Diseño de Sistemas Complejos"
  • 7. • Objetivos: • Dada una necesidad, pretende satisfacerla a través de una solución software. • Mantenimiento del software producido hasta el final de su vida útil.• La solución de un problema mediante ingeniería de software es una actividad de modelización que comienza con el desarrollo de modelos conceptuales (no formales) y los convierte en modelos formales (producto software). • Modelo conceptual determina la validez ¿es válido para ese problema? • Modelo formal determina la corrección ¿funciona correctamente el modelo? PI 29/B134 "Modelado de Requerimientos y 7 Diseño de Sistemas Complejos"
  • 8. • Análisis y Especificación de Requerimientos  ¿Qué hacer?• Diseño  ¿Cómo lo hacemos?• Codificación  hacerlo• Pruebas  probarlo• Instalación  usarlo• Mantenimiento  cuidarlo PI 29/B134 "Modelado de Requerimientos y 8 Diseño de Sistemas Complejos"
  • 9. Diseñar el Probar el• Necesidad sistema • Diseño sistema • Sistema o • Especificación • Código Producto de Software requerimientos Obtención de Programar el Instalación requerimientos código PI 29/B134 "Modelado de Requerimientos y 9 Diseño de Sistemas Complejos"
  • 10. • Un ciclo de vida debe: • Determinar el orden de las fases del proceso software. • Establecer los criterios de transición entre fases. PI 29/B134 "Modelado de Requerimientos y 10 Diseño de Sistemas Complejos"
  • 11. PI 29/B134 "Modelado de Requerimientos y 11 Diseño de Sistemas Complejos"
  • 12. • No existe un único ciclo de vida. Existen muchas aplicaciones para las que se construyen productos software. • El problema es conocido y pequeño, el grupo tiene experiencia en esos desarrollos, el usuario puede describir claramente los requisitos, un ciclo de vida tradicional en cascada es adecuado. • El problema es complejo o medianamente complejo, los requerimientos cambiantes, conlleva riesgos, conviene utilizar combinaciones por ejemplo iterativos e incremental. Donde a cada iteración o incremento se aplica el ciclo de vida tradicional en cascada. • El desarrollo tiene riesgos, el ciclo en espiral es más adecuado. • Probar el producto al usuario para mostrar su utilidad podemos usar el prototipado. PI 29/B134 "Modelado de Requerimientos y 12 Diseño de Sistemas Complejos"
  • 13. Desde la década del 60 hasta nuestros días PI 29/B134 "Modelado de Requerimientos y 13 Diseño de Sistemas Complejos"
  • 14. 90 – 00 Actualidad 60 – 70 70 – 80 80 – 90 00 – 10 Procesos IntegraciónArtesanía Cascada Productividad Agilidad concurrentes Global Arquitecturas de software especializadas por dominio. Conectividad global. Métodos orientados a Reutilización por línea Arquitecturas objetos de producto. orientadas a servicios. Código espagueti Métodos estructurados Reutilización basada en Arquitectura flexibilidad de empresarial. componentes. Líneas Computación en la de producto. nube. Medición de Métodos ágiles de productividad y calidad desarrollo. Equipos de trabajo Modelos de madurez. distribuidos.Artesanía del software Procesos cascada Afianzamiento en Nace el concepto de reutilización por línea fábrica de software de producto y modelo Métodos colaborativos Entornos integrados de madurez. con asistencias de (CASE) Groupware. PI 29/B134 "Modelado de Requerimientos y 14 Diseño de Sistemas Complejos"
  • 15. • Un servicio es una funcionalidad (ofrecida por una entidad y que satisface una necesidad de una entidad solicitante) y no la forma en que dicha funcionalidad es implementada en el sistema. Es una entidad autónoma.• Se basa en el paradigma de computación orientada a servicios.• Utiliza un conjunto de servicios para dar soporte a los requisitos de determinados procesos de negocio de una determinada organización.• No está unida a una plataforma o tecnología concreta, se puede usar por ejemplo Servicios Web.• Ejemplos • Sistemas que comparten información médica. • Sistemas de reservas. PI 29/B134 "Modelado de Requerimientos y 15 Diseño de Sistemas Complejos"
  • 16. • Promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto.• La mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas.• Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación.• Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteración.• Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto "Modelado de Requerimientos y PI 29/B134 Diseño de Sistemas Complejos" 16
  • 17. • DSD o desarrollo distribuido de software permite que stakeholders no estén en un mismo lugar físico. Cuando la lejanía incluye países distintos se denomina Desarrollo Global de Software (GSD).• Si los stakeholders no pertenecen a la misma organización se denomina tercerización (outsourcing).• Si se transfieren empleos a otro país se denomina deslocalización (offshoring). PI 29/B134 "Modelado de Requerimientos y 17 Diseño de Sistemas Complejos"
  • 18. • También denominado servicios en la nube.• Paradigma que permite ofrecer servicios de computación a través de internet. PI 29/B134 "Modelado de Requerimientos y 18 Diseño de Sistemas Complejos"
  • 19. Arquitectura versus Complejidad PI 29/B134 "Modelado de Requerimientos y 19 Diseño de Sistemas Complejos"
  • 20. En la ingeniería •Importancia de modelos de alto nivel que luego se refinan •Desarrollo basado en interfaces antes que clases •Uso de patrones y tácticas de arquitectura Desarrollo Basado en la ArquitecturaEn la gestión del proyecto En la calidad del producto•Estimar esfuerzo de construcción•Plan de construcción de los CU según su •Medición de la calidad “sobreimpacto en la arquitectura planos”•Nuevos esquemas de negociación del proyecto •Adopción de frameworks de atributos de calidad•Nuevos esquemas de interacción cliente/proveedor•La arquitectura como elemento para evaluar riesgos
  • 21. PhasesProcess Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test DeploymentSupporting Workflows Configuration Mgmt Management Environment Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter. Iteration(s) #1 #2 #n #n+1 #n+2 #n #n+1 Enfatiza la importancia de: •Especificación precisa de requisitos no funcionales •Pruebas de concepto de la arquitectura •Definición de la línea base de la arquitectura •Procesos formales de análisis y evaluación de la arquitectura PI 29/B134 "Modelado de Requerimientos y 21 Diseño de Sistemas Complejos"
  • 22. Qué? Por qué? Cualidades Características Satisface Del Sistema de la ArquitecturaArquitectura Requerimientos Restringe S/W Representación de la arquitectura Atributos de Calidad del sistema Produce Tecnología Defines Para qué? Quién? Analiza Arquitecto Procesos Habilidades Define roles Organización Stakeholders Fuente: Rational Software PI 29/B134 "Modelado de Requerimientos y 22 Diseño de Sistemas Complejos"
  • 23. usuario final Funcionalidad Rendimiento Seguridad gerente del usabilidad soporte proyecto aplicativo Bajo costo Rendimiento del equipo modificabilidad arquitecto líder de Corto tiempo en mercado Bajo costo y tiempo clientemercadeo Bajo costo; ventajas con de entrega, que no cambie productos similares muy a menudo PI 29/B134 "Modelado de Requerimientos y 23 Diseño de Sistemas Complejos"
  • 24. • En la medida que la complejidad de los sistemas crece, los algoritmos y las estructuras de datos dejan de convertirse en el mayor problema.• El diseño y especificación de la estructura general del sistema emerge como un nuevo tipo de problema: el diseño a nivel de arquitectura.• En aplicaciones OO las clases representan unidades de granularidad muy fina; en sistemas grandes se requiere hablar de unidades que represente una funcionalidad mayor (módulos / subsistemas / componentes de negocio) PI 29/B134 "Modelado de Requerimientos y 24 Diseño de Sistemas Complejos"
  • 25. Fuente: Architecture as a Business Competency. Bredemeyer ConsultingPI 29/B134 "Modelado de Requerimientos y 25 Diseño de Sistemas Complejos"
  • 26. • La complejidad de los sistemas deriva, directamente de la invención de la computadora y su utilización, y forman tanto parte de ellas que han sido incorporadas en la informática, sirviéndole de impulso.• Podemos hablar de las ciencias de la complejidad y estas se encuentran en la base de la modelización de los sistemas informáticos, dentro de estas ciencias encontramos, el caos, la geometría de fractales, la vida artificial, y las lógicas no- clásicas. Justamente la incorporación de está última a los sistemas informáticos desde hace un tiempo hacia acá, es la que a contribuido, al desarrollo de los sistemas actuales.• Un ejemplo de sistemas informáticos que nos permiten enfrentar situaciones complejas, Requerimientos y PI 29/B134 "Modelado de son los sistemas expertos. 26 Diseño de Sistemas Complejos"
  • 27. Es un software que incorpora conocimiento de un experto humano sobre un dominio de aplicación dado, de manera que es capaz de resolver problemas de relativa dificultad y apoyar la toma de decisiones inteligentes en base a un proceso de razonamiento simbólico. Se puede entender como una rama de la inteligencia artificial y está compuesta en forma general por:• Base de conocimientos (BC): Contiene conocimiento modelado extraído del diálogo con un experto.• Base de hechos (Memoria de trabajo): contiene los hechos sobre un problema que se ha descubierto durante el análisis.• Motor de inferencia: Modela el proceso de razonamiento humano.• Módulos de justificación: Explica el razonamiento utilizado por el sistema para llegar a una determinada conclusión.• Interfaz de usuario: es la interacción entre el SE y el usuario, y se realiza mediante 29/B134 "Modelado de Requerimientos y PI el lenguaje natural 27 Diseño de Sistemas Complejos"
  • 28. PI 29/B134 "Modelado de Requerimientos y 28 Diseño de Sistemas Complejos"
  • 29. Breve detalle PI 29/B134 "Modelado de Requerimientos y 29 Diseño de Sistemas Complejos"
  • 30. • PI 29/B134 Modelado de Requerimientos y Diseño de Sistemas Complejos • Radicado en UNPA – Unidad Académica Caleta Olivia • Inicio: 01.01.2012 Fin: 01.01.2014 • Directora: Lic. Gabriela Vilanova • Co-Directora: Ing. Silvia G. Rivadeneira Molina • Integrantes: Dr. Carlos Arias Méndez, Ing. Valeria Varas, Ing. Juan Fontana, Al. Brenda Ducasse, Al. Ángel Páez, Al. Claudio Monserrat. • Se está tramitando el ingreso de dos docentes investigadores (Ing. Gabriela Miranda y la Lic. Diana Cruz) PI 29/B134 "Modelado de Requerimientos y 30 Diseño de Sistemas Complejos"
  • 31. • Modelado BPMN (Business Process Modeling Notation).• Metodologías ágiles.• Desarrollo de software para dispositivos móviles.• Arquitectura de Sistemas Complejos.• Arquitecturas orientadas a servicios.• Innovaciones en la enseñanza de modelado de software. PI 29/B134 "Modelado de Requerimientos y 31 Diseño de Sistemas Complejos"
  • 32. • ¡Muchas gracias! PI 29/B134 "Modelado de Requerimientos y 32 Diseño de Sistemas Complejos"