METODOS ESPECIFICOS

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.

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

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.

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.

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.

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.

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.

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.

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

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

17.  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.

18. INTELIGENCIA ARTIFICIAL
PEDIATRÍA
SISTEMAS INTELIGENTES
INGENIERÍA MEDICINA
DE SISTEMAS
SISTEMAS BASADOS EN
CONOCIMIENTO
ADAPTACIÓN
NEONATAL
SISTEMAS EXPERTOS

19.  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.

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

21.  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.

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

24.  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

25. ¡ GRACIAS !

26. 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.
UNIV. STEPHANIE

27. Desarrollo iterativo
Verificación de la calidad Administración de
del software requisitos
Modelado visual del Uso de arquitectura
software basada en componentes
Control de cambios
UNIV. STEPHANIE

28. Análisis y
Requerimiento
Diseño
Evaluació Implementació
n n
Cada
iteración
produce
un Prueba
producto
ejecutable
UNIV. STEPHANIE

29. Artefacto
¿QUÉ generar?
Artefactos
¿QUIÉN las hace?
Roles
Workflow ¿CÓMO se hace?
Rol
Actividades
¿CUÁNDO se hace?
Workflow
Actividad
UNIV. STEPHANIE

30. Demostrar
Elevar el Enfocarse
Adaptar el Equilibrar valor Colaboración
nivel de en la
proceso prioridades iterativa- entre equipos
abstracción
mente calidad
UNIV. STEPHANIE

31. UNIV. STEPHANIE SORIA

32. Documento con la visión del
Fase de inicio proyecto.
MCU
Glosario inicial del proyecto.
Descripción arquitectura del
software
Fase de elaboración Prototipo ejecutable de
arquitectura
Manual preliminar de usuario
El producto software integrado
Fase de construcción Los manuales de usuario
Descripción de la versión
actual
Fase de transición Usuarios prueban producto
Desarrolladores corrigen
errores
Actividades
UNIV. STEPHANIE SORIA

34.  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.

35.  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.

37. •Para esta fase del proyecto se
•Se lleva a cabo un análisis detallado
definen los objetivos específicos. Se
para cada uno de los riesgos del
identifican las restricciones del
proyecto. Se definen los pasos para
procesos y el producto, y se estipula
reducir dichos riesgos. Por ejemplo
un plan detallado de administración.
si existe el riesgo de tener
Se identifican los riesgos del
requerimientos inapropiados, se
proyecto. Dependiendo de esos
desarrolla un prototipo del sistema.
riesgos, se planean estrategias
alternativas.
2.EVALUACIÓN Y
1.DEFINICION
REDUCCIÓN DE
DE OBJETIVOS:
RIESGOS:
3.DESARROLLO Y
4.PLANIFICACIÓN:
VALIDACIÓN:
• Revisamos todo lo hecho,
evaluándolo, y con ello decidimos •Después de la evaluación
si continuamos con las fases de riesgos, se elige un
siguientes y planificamos la modelo para el desarrollo
próxima actividad. del sistema.

38.  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.

39.  Genera mucho tiempo en el desarrollo
del sistema.
 Modelo costoso.
 Requiere experiencia en la identificación
de riesgos.

40.  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

41.  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.

43. El equipo lo conforman los jefes de
proyecto, desarrolladores y el cliente.
Se rige por valores y principios.

44. RETROALIMEN
COMUNICACIÓN SIMPLICIDAD VALENTIA
TACIÓN
Empezar con
Crear software Del sistema, Crear software
lo necesario y
requiere de del cliente, y requiere de
requerido y
sistemas del equipo. sistemas
trabajar desde
comunicados. comunicados.
ahí.

45. 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.

46. 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.
Se puede incrementar o disminuir por la cantidad
de personas que se contraten en el proyecto.
La calidad interna
La calidad externa
“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.

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

48.  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.

49. 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

51. 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.

52. 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

53.  COMPROMISO
 ENFOQUE
 TRANSPARENCIA/HONESTIDAD
 RESPETO
 CORAJE

54. 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.

55.  Para crear un producto se realiza
la recolección de requisitos
teniendo en cuenta la visión del
cliente y del usuario.
 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 QUEREMOS
HACER
 Con esas historias de usuario
contruimos la lista de requisitos
del producto o PRODUCT
BACKLOG

56. Una de las figuras fundamentales de SCRUM es
la reunión diaria de todo el equipo que debe
hacerse de la siguiente forma:
1. Las reuniones se hacen diariamente con
preferencia ala misma hora y no mas de 15 a
30 min. y se realiza de pie.
2. 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?
3. Y la transparencia todos saben lo que hacen
todos.

58. 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”.

59. 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

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

61.  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.

64. DSDM
Tiene un enfoque iterativo e incremental
que enfatiza a la participación continua del usuario.
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.

65. Entregar el software en
el tiempo previsto.
DSDM
Entregar el software
con el presupuesto
establecido.

66. 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.

67. Es un modelo relativamente nuevo.
No es muy común.
Es dificultoso para entenderlo.

68. 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.

69. Responsable: Wilson René Cossío Mendoza

70. 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).

71. 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.

72. 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.

73. 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.

74. 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

75.  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.

76. Corresponde al ciclo de “revisión y
mejoramiento”
del conocimiento deductivo.
 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.

77.  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.