Metodos especificos

METODOS ESPECIFICOS

1. METODOS ESPECIFICOS

2.   SIMULACIÓN

3. Simulación es el desarrollo de un modelo lógico-matemático de un sistema, de tal forma que se obtiene una imitación de la operación de un proceso de la vida real o de un sistema a través del tiempo. Sea realizado a mano o en una computadora. Dos pasos básicos de la simulación son: Desarrollo del modelo. Experimentación. Definición

4. El desarrollo del modelo incluye la construcción de ecuaciones lógicas representativas del sistema y la preparación de un programa computacional. Desarrollo del modelo.

5. La segunda fase, se experimentar con el modelo para determinar cómo responde el sistema a cambios en los niveles de algunas variables de entrada. Experimentación .

6. Es un medio para ganar experiencia artificial mediante el uso de un modelo que da apariencia o efecto de realidad. Se usa para problemas que son demasiado complejos para ser resueltos mediante técnicas analíticas y/o matemáticas. Algunos significados acerca del modelado en simulación :

7. Una vez construido, el modelo puede ser modificado de manera rápida con el fin de analizar diferentes políticas o escenarios. Generalmente es más barato mejorar el sistema vía simulación, que hacerlo directamente en el sistema real. Es mucho más sencillo comprender y visualizar los métodos de simulación que los métodos puramente analíticos. Ventajas

8. Los modelos de simulación en una computadora son costosos y requieren mucho tiempo para desarrollarse y validarse. Se requiere gran cantidad de corridas computacionales para encontrar "soluciones óptimas", lo cual repercute en altos costos. Es difícil aceptar los modelos de simulación . Desventajas

9. Discreto Variables de estado cambian solo en puntos contables en el tiempo. Continuo Las variables de estado cambian en forma continua a través del tiempo. TIPOS DE SIMULACIÓN

10. Estática Es una representación de un sistema en determinado punto en el tiempo . Dinámica Es una representación de cómo evoluciona un sistema a través del tiempo.

11. PROCESO DE DESARROLLO DE UN MODELO DE SIMULACIÓN

12. Método de Desarrollo de Buchanan

13. Se destacan 6 etapas fundamentales: Etapas FASE 1 FASE 2 Optimización del S. E.

14. Participantes – Expertos del dominio – Ingenieros de conocimiento – Usuarios Características del problema – Tipo – Subtareas – Terminología Recursos disponibles – Fuentes de conocimiento – Recursos computacionales – Tiempo de desarrollo – Financiación Metas – Formalización del conocimiento del experto – Distribución de experiencia – Formación de nuevos expertos 1. Identificación

15. Adquisición de Conocimiento

16. Organización del conocimiento según un esquema conceptual. Búsqueda de conceptos que representen el conocimiento del experto. Identificación del flujo de información durante el proceso de resolución de problemas. 2. Conceptualización

17. INTELIGENCIA ARTIFICIAL SISTEMAS INTELIGENTES SISTEMAS BASADOS EN CONOCIMIENTO SISTEMAS EXPERTOS MEDICINA PEDIATRÍA ADAPTACIÓN NEONATAL INGENIERÍA DE SISTEMAS Contextualización

18. Proceso de traducción de… - Conceptos clave. - Subproblemas . Características del flujo de información. Construcción de representaciones formales basadas en… - Herramientas de desarrollo. - Esquemas de ingeniería del conocimiento. 3. Formalización

19. Sistemas de Diagnóstico Médico Extracción del Conocimiento Entrenamiento Clasificación Interacción con el Medio Sistemas Expertos Redes Neuronales Agentes Inteligentes Reglas Casos Lógica Difusa Multilayer Perceptron Minería Datos Reactivos Proactivos Multi Agentes 1 2 3 4 Contextualización

20. Formulación de reglas. Formulación de estructuras de control. Obtención de un prototipo: - Permite comprobar si hemos conceptualizado bien el conocimiento del dominio. - Permite comprobar si hemos formalizado bien el conocimiento del dominio. 4. Implementación

21. Evaluación del rendimiento del prototipo construido. Identificación de errores. Identificación de anomalías en… - Base de conocimientos. - Mecanismos de inferencia. 5. Prueba

22. Desarrollo y Mantenimiento

23. Los lazos de realimentación no tienen por qué seguir estrictamente la secuencia del esquema propuesto por Buchanan Las retroalimentaciones pueden aparecer entre cualquier par de fases de la metodología 6. Optimización del S. E.

24. ¡ GRACIAS !

25. UNIV. STEPHANIE SORIA MÉTODO RUP Rational Unified Process (RUP o Proceso Racional Unificado), es un proceso de ingeniería de software que ofrece un enfoque disciplinado para asignar tareas y responsabilidades dentro de la organización del desarrollo.

26. UNIV. STEPHANIE SORIA CARACTERÍSTICAS

27. UNIV. STEPHANIE SORIA CARACTERÍSTICAS Cada iteración produce un producto ejecutable

28. UNIV. STEPHANIE SORIA CARACTERÍSTICAS

29. PRINCIPIOS UNIV. STEPHANIE SORIA

30. UNIV. STEPHANIE SORIA FASES DE RUP

31. UNIV. STEPHANIE SORIA FASES DE RUP Documento con la visión del proyecto. MCU Glosario inicial del proyecto. Descripción arquitectura del software Prototipo ejecutable de arquitectura Manual preliminar de usuario El producto software integrado Los manuales de usuario D escripción de la versión actual Usuarios prueban producto Desarrolladores corrigen errores Actividades

32. Método Espiral

33. Método espiral CONCEPTO : El modelo en espiral del proceso del software que originalmente fue propuesto por Boehm (1988). El modelo en espiral es una de las metodologías más recomendables para el desarrollo y creación de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en una manera continua y cíclica.

34. Funcionamiento Se parte de una escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan, y se establece una aproximación a la siguiente interacción. Cada iteración supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel: Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas. En cada bucle alrededor del espiral, la culminación del análisis de riesgo resulta una decisión de “seguir” o “no seguir”. En el modelo en espiral, las primeras iteraciones son las menos costosas. Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseño, la implementación del producto y la prueba del mismo.

35. REPRESENTACIÓN GRÁFICA

36. Cada ciclo de la espiral se divide en 4 etapas:

37. Ventajas: El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc. Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

38. Desventajas: Genera mucho tiempo en el desarrollo del sistema. Modelo costoso. Requiere experiencia en la identificación de riesgos.

39. Inconvenientes. Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia. El  IEEE  clasifica al desarrollo en espiral como modelo no operativo en sus clasificaciones de MCV. 2

40. Conclusión: El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.

41. XP PROGRAMACIÓN EXTREMA

42. ¿QUÉ ES XP? Método para un ágil desarrollo de software. Programación basada en los deseos del cliente. El equipo lo conforman los jefes de proyecto, desarrolladores y el cliente. Se rige por valores y principios.

43. Crear software requiere de sistemas comunicados. VALORES DE XP COMUNICACIÓN Empezar con lo necesario y requerido y trabajar desde ahí. Del sistema, del cliente, y del equipo. Crear software requiere de sistemas comunicados. SIMPLICIDAD RETROALIMENTACIÓN VALENTIA

44. ACTIVIDADES Codificación: La parte mas importante de XP. Pruebas: Nunca se puede estar seguro de algo hasta haberlo probado. Escuchar: Escuchar los requisitos del cliente acerca del sistema a crear. Diseño: Crear una estructura del diseño para evitar problemas.

45. PLANEACIÓN DE XP Para planear la programación extrema debemos de tomar en consideración algunas piezas clave como son costo, la calidad, el tiempo y el alcance que puede tener. S e puede incrementar o disminuir por la cantidad de personas que se contraten en el proyecto. La calidad interna La calidad externa COSTO CALIDAD “El desarrollo de un software no es un proceso rígido” “Los clientes toman decisiones de negocio y los programadores toman decisiones técnicas”. Como decisiones técnicas tenemos a los días y prioridades y como las técnicas se encuentran los estimados. TIEMPO ALCANCE

46. VENTAJAS Y DESVENTAJAS VENTAJAS Programación organizada. Menor taza de errores. Satisfacción del programador. Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar. DESVENTAJAS

47. CONCLUSIONES El cliente tiene el control sobre las prioridades. Se hacen pruebas continuas durante el proyecto. La programación extrema es mejor utilizada en la implementación de nuevas tecnologías donde los requerimientos cambian rápidamente.

48. UNIVERSIDAD MAYOR DE SAN ANDRES FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMATICA MATERIA : TALLER DE LICENCIATURA I DOCENTE: FATIMA CONSUELO DOLZ UNIV.: SILVIA E. MARCA VARGAS

49. METODO SCRUM

50. Scrum significa Melé, es una jugada del deporte Rugby. Todos los jugadores de ambos equipos se agrupan en una formación en la cual lucharán por obtener el balón que se introduce por el centro. Si un miembro del equipo se viene abajo, se cae toda le melé . En consecuencia, los jugadores deben estar bien coordinados, apoyarse en sus compañeros para empujar al mismo tiempo y con ello, avanzar a la misma velocidad . ¿Que significa scrum ?

51. DEFINICIÓN SCRUM Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por HIROTAKA TAKEUCHI E IKUJIRO NONAKA a mediados de los 80. En 1996 se definió por primera vez un patrón para aplicar esos principios de desarrollo en “CAMPOS DE SCRUM” al software. Esta fue la primera definición de un patrón Scrum aplicado al software, diseñada por Jeff Sutherland y Ken Schwaber y presentada en OOPSLA 96

52. VALORES SCRUM COMPROMISO ENFOQUE TRANSPARENCIA/HONESTIDAD RESPETO CORAJE

53. SPRINTS El mercado exige ciclos de desarrollo cada vez mas cortos. Para logarlo se utiliza el SPRINT BACKLOG que es una lista en la que se detalla como se van a construir los diferentes requisitos del producto. Los requisitos de PROUCT BACKLOG se TROCEAN para transfórmalos en tareas de no mas de 16 horas. Cada sprint suele realizarse entre 2 y 4 semanas. Al final el objetivo es entregar algo que funcione Para que el usuario lo pruebe y se realicen nuevos cambios , esto es los que nos permitirá ser flexibles.

54. SCRUM Para ello se utilizan las historias de usuario, que son unas sencillas tarjetas con información esquemática y un lenguaje claro del QUE ES LO QUE Q UEREMOS HACER Con esas historias de usuario contruimos la lista de requisitos del producto o PRODUCT BACKLOG Para crear un producto se realiza la recolección de requisitos teniendo en cuenta la visión del cliente y del usuario.

55. REUNION DIARIA Una de las figuras fundamentales de SCRUM es la reunión diaria de todo el equipo que debe hacerse de la siguiente forma: Las reuniones se hacen diariamente con preferencia ala misma hora y no mas de 15 a 30 min. y se realiza de pie. Se realizan solo 3 preguntas. Que has hecho o ha realizado desde la ultima reunión? Que va hacer hoy? Que ayuda necesita para seguir haciéndolo ? Y la transparencia todos saben lo que hacen todos.

56. Una gallina y un cerdo paseaban por la carretera. La gallina dijo al cerdo: “Quieres abrir un restaurante conmigo ”. El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. La gallina respondió: “HUEVOS CON JAMON”. El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que tu estarías sólo implicada”. ROLES

57. SCRUM diferencia entre estos dos grupos para garantizar que quienes tienen la responsabilidad tienen también la autonomía necesaria para poder lograr el éxito, y que quienes no tienen la responsabilidad no producen interferencias innecesarias EL PAPEL DE LOS POLLOS O SEA LOS COMPROMETIDOS SON: LOS USUARIOS DEL PRODUCTO LOS CLIENTES Y VENDEDORES LOS GESTORES Y DIRECTIVOS

58. ROLES Product owner (dueño del producto) Team (equipo) ScrumMaster SIGUIENDO LA LOGICA LOS IMPLICADOS QUE CONTRIBUYEN CON SU JAMON SON:

59. ROLES PRODUCT OWNER Responsable de marcar prioridades del proyecto es el director del proyecto SCRUM MASTER Es el líder, su principal papel es de el de dejar el camino libre de obstáculos e impedimentos para el equipo. SCRUM TEAM Es el equipo de 5 a 9 personas encargados de realizar el proyecto.

60. GRACIAS

61. Dynamic System Development Method Método de Desarrollo de Sistemas Dinámicos

62. Introducción Tiene un enfoque iterativo e incremental que enfatiza a la participación continua del usuario. DSDM   Es ideal para el desarrollo de software que necesita colocar una gran importancia de la interfaz de usuario o de aspectos de usabilidad de los productos.

63. Propósito DSDM Entregar el software en el tiempo previsto. Entregar el software con el presupuesto establecido.

64. 9 PRINCIPIOS DEL DSDM   1.- Participación del usuario es imprescindible en el desarrollo del software 2.- El equipo debe estar dispuesto a tomar decisiones de forma rápida. 3.- Enfocarse en la entrega frecuente. 4.- Aptitud para los negocios es un criterio necesario para la aceptación de las entregas. 5.- El desarrollo incremental e iteraciones son obligatorios 6.- todos los cambios durante el desarrollo deben ser reversibles. 7.- Los requisitos son la base línea de alto nivel. 8.- Deben haber pruebas integradas a lo largo del ciclo. 9.- Acercamiento colaborativo y cooperativo entre el usuario y los desarrolladores.

65. LIMITACIÓN DEL DSDM Es un modelo relativamente nuevo. No es muy común. Es dificultoso para entenderlo.

66. VENTAJAS Participación activa del usuario a pesar de la vida del proyecto, lo cual mejora el desarrollo de la calidad del producto. Asegura entregas rápidas. Ambos factores dan como resultado la disminución del proyecto.

67. Desarrollo de sistemas expertos Metodología de Grover Responsable: Wilson René Cossío Mendoza

68. METODOLOGIA DE GROVER Se concentra: En el la definición del dominio (conocimiento, referencias, situaciones y procedimientos) En la formulación del conocimiento fundamental (reglas elementales, creencias y expectativas) En la consolidación del conocimiento de base (revisión y ciclos de corrección).

69. ETAPAS La metodología de adquisición de conocimiento para el dominio del problema de Grover tiene tres fases: DEFINICIÓN DEL DOMINIO FORMULACIÓN FUNDAMENTAL DEL CONOCIMIENTO CONSOLIDACIÓN DEL CONOCIMIENTO BASAL.

70. PRIMERA FASE: DEFINICIÓN DEL DOMINIO Generación del Manual de Definición del Dominio: Descripción general del problema. Bibliografía de los documentos referenciados. Glosario de términos, acronismos y símbolos. Identificación de expertos autorizados. Definición de métricas de performance apropiadas y realistas. Descripción de escenarios de ejemplos razonables.

71. SEGUNDA FASE: FORMULACIÓN FUNDAMENTAL DEL CONOCIMIENTO Se revisan los escenarios seleccionados por el experto que satisfacen los siguientes cinco criterios de conocimiento “fundamental”: el más nominal el más esperado el más importante el mas arquetípico el mejor entendido.

72. SEGUNDA FASE Esta revisión forma una base para: Determinar la performance mínima Realizar el testeo y efectuar corrección Determinar las capacidades del sistema experto que pueden ser expandidas y sujetas a experimentación. Esta base del conocimiento fundamental debe incluir: Una ontología de entidades del dominio, relaciones entre objetos (clases) y descripciones objetivas

73. SEGUNDA FASE Un léxico seleccionado (vernáculo) Una definición de fuentes de entrada y formatos Una descripción del estado inicial incluyendo el conocimiento estático Un conjunto básico de razones y reglas de análisis Una lista de estrategias humanas (meta-reglas) las cuales pueden ser consideradas por los diseñadores del sistema experto como reglas a incluir en la base de conocimiento.

74. TERCERA FASE: CONSOLIDACION DEL CONOCIMIENTO BASAL La actividad basal puede ser definida en el mismo sentido que la medicina: el menor nivel de actividad (comportamiento del sistema) esencial para el mantenimiento de funciones vitales. Corresponde al ciclo de “revisión y mejoramiento” del conocimiento deductivo.

75. En un sistema experto, esto refiere a que todos los componentes del sistema experto operacional están desarrollados, pero sin la amplitud ni profundidad que la versión final necesitará. La corroboración con expertos adicionales puede colaborar en el cumplimiento de este objetivo. En esta etapa pueden trabajarse los niveles de confianza de las distintas piezas de conocimiento.

76. METODOLOGIA DE GROVER