Importancia

Los diseños de diálogo son clave en la ingeniería de software porque hacen que la interacción entre usuarios y sistemas sea más fluida, intuitiva y eficiente

Son importantes porque mejoran la interacción usuario-sistema al proporcionar información clara y facilitar la toma de decisiones.

Para mi es para mejorar la eficiencia y efectividad de un proceso en alguna organización o funcionalidad

Detalles del Video:

La comunicación y el proceso son la base sobre la cual se construyen aplicaciones y servicios en el mundo digital

Para mi sería como reducir el tiempo o el esfuerzo que toma realizar algún trabajo o tarea

Video:

Se debe llevar todo un proceso para que un sistema en este caso una computadora funcione. Desde recibir los inputs del usuario, almacenar los datos, hasta mostrar los outputs o resultados

Video

Es importante tener en cuenta los pasos de lo que se considera un proceso y el flujo que hay entre ellos. Se debe conocer lo que es considerado tipo "input" y tipo "output" ya que a veces se genera un poco de confusión.

Es como una forma de comentar y conversar sobre algún trabajo o proyecto en proceso, para identificar algunos puntos a mejorar desde el punto de vista de un tercero.

Las pruebas y mecanismo son como distintos métodos y procesos para retroalimentar sobre algo.

Retroalimentar es brindar información sobre el desempeño para ajustar, optimizar o corregir acciones y así mejorar los resultados.

Retroalimentación Positiva: Puede realizar un cambio significativo en un sistema o realizar otros cambios.

Retroalimentación Negativa: No busca muchos cambios y busca mantener un equilibrio o estabilizarlo

Funciona como una conversación en la que se comenta e identifica varios puntos en los que se puede mejorar más.

Retroalimentación negativa

Busca cambiar por completo los puntos erróneos o innecesarios del trabajo.

2.LAS PRUEBAS EXHAUSTIVAS NO EXISTEN.

3.LAS PRUEBAS TEMPRANAS AHORRAN TIEMPO Y DINERO.

4.AGRUPACION DE DEFECTOS.

5.TENER CUIDADO CON LA PARADOJA DEL PESTICIDA

6.LAS PRUEBAS DEPENDEN DEL CONTEXTO

7.FALACIA DE AUSENCIA DE ERRORES

1.       Las pruebas demuestran la presencia de defectos, no su ausencia.

2.       Las pruebas exhaustivas no existen.

3.       Las pruebas tempranas ahorran tiempo y dinero.

4.       Agrupación de defectos.

5.       Tener cuidado con la paradoja del pesticida.

6.       Las pruebas dependen del contexto.

7.       Falacia de ausencia de errores.

2.pruebas exhaustivas no exixte

3.pruebas tempranas ahorran tiempo y dinero

4 Agrupación de defectos

5.Cuidado con la paradoja del pesticida

6.Las pruebas dependen del contexto

7.Falacia de ausencia de errores

1) La pruebas demuestran la presencia de defectos, no su ausencia.

2) Las pruebas exhaustivas no existen (o son imposibles).

3) Las pruebas tempranas ahorran tiempo y dinero.

4) Agrupación de defectos.

5) Tener cuidado con la paradoja del pesticida.

6) Las pruebas dependen del contexto.

7) Falacia de ausencia de errores.

2. Las pruebas exhaustivas no existen

3. Las pruebas tempranas ahorran tiempo y dinero

4. Agrupación de defectos

5. Tener cuidado con la paradoja del pesticida

6. Las pruebas dependen del contexto

7. Falacia de ausencia de errores

2 Las pruebas exhautivas no existen

3 Las pruebas temprana ahorran tiempo y dinero

4 Agrupación de defectos

5 Tener cuidado con la paradoja pesticida

6 Las pruebas dependen del contexto

7 Falacia de ausencia de errores

2-Las exhaustivas no existen

3-Prueban tempranas ahorran tiempo y dinero

4-Agrupacion de Defectos

5-Paradoja del Pesticida

6-Dependen del contexto

7-Falacia de ausencia de errores

2.Las pruebas exhautivas no existen

3.Las pruebas tempranas ahorran tiempo y dinero

4.Agrupación de defectos

5.Tener cuidado con la paradoja del pesticida

6.Las pruebas dependen del contexto

7.Falacia de ausencia de errores

2-Las pruebas exhaustivas no existen. (Ej- Temperatura por ciudad)

3-Las pruebas Tempranas ahorran tiempo y dinero. (pruebas tempranas por defectos ahorran dinero ya que los defectos con el tiempo aumenta su costo)

4-Agrupación por defectos

5-Tener cuidado con la paradoja del pesticida. (quiere decir no hacer la misma prueba, al contrario al haber nuevos defectos necesitamos actualizar las pruebas)

6- Las pruebas dependen del contexto

7-Falacia de ausencia de errores.

Es cuando los usuarios interactúan con un sistema para lograr un objetivo específico

• ¿Qué son?

Son una forma de explicar cómo el usuario interactúa con un sistema para lograr algo.

• ¿Para qué sirven?

Ayudan a entender qué necesita hacer el sistema y cómo debe funcionar.

Qué son?

Son eventos donde en el desarrollo de software, se planea todos los usos que pueden tener los actores en ciertas funciones del software.

Para que sirven?

Sirve definir el rol de un usuario especifico, y como este interactúa con el software.

Cuál es su función?

Ayudan a crear la estructura y proporcionan la información para el proceso de desarrollo del software.

Y el de actividades describe el flujo de trabajo o proceso de un sistema, mostrando las acciones y decisiones como un flujo secuencial.

Diagrama de Actividad: Es un tipo de diagrama que representa el flujo de trabajo o el flujo de control de un proceso o actividad.

El diagrama de actividades representa flujos de trabajo o procesos mediante acciones (actividades) conectadas por flechas, donde un nodo inicial marca el comienzo y uno final la terminación. Usa bifurcaciones (diamantes) para decisiones como "¿Hay stock?" y barras de sincronización para tareas paralelas, como "Enviar pedido" y "Generar factura" al mismo tiempo. Por ejemplo, en un proceso de compra online, se modelaría: "Inicio → Verificar stock → [Sí] Facturar → Enviar → Fin".

El diagrama de secuencia, en cambio, detalla cómo interactúan objetos en el tiempo, con líneas de vida verticales (como "Cliente", "Servidor") y flechas que representan mensajes (ej.: "Cliente envía login → Servidor valida credenciales → Base de Datos responde"). Las barras de activación muestran cuándo un objeto está procesando una acción, y fragmentos como `opt` (para opciones) o `loop` (repeticiones) añaden complejidad. Por ejemplo, en un login fallido: "Cliente ingresa datos → Servidor rechaza → Muestra error".

Mientras el de actividades se enfoca en pasos generales (¿qué hacer?), el de secuencia profundiza en interacciones concretas (¿quién hace qué y cuándo?).

Diagrama de actividad representa el flujo de trabajo o procesos, mostrando las actividades y decisiones desde el inicio hasta el fin de un proceso.

Diagrama de clases muestra las clases de un sistema, sus atributos, métodos y relaciones entre ellas. Se usa para representar la estructura estática del software.

Diagrama de estados muestra los diferentes estados por los que pasa un objeto y cómo cambia de estado en respuesta a eventos. Representa el comportamiento dinámico.

Estado: es un diagrama que muestra los cambios de estado de un objeto a lo largo del tiempo, dependiendo de la respuesta a ciertos eventos o acciones.

Y el diagrama de estado muestra los estados por los que pasa un objeto y las transiciones entre ellos, desencadenadas por eventos.

Diagrama de Estado: Es una representación gráfica que muestra los estados de un objeto a lo largo de su vida y las transiciones entre esos estados en respuesta a eventos.

Diagrama de estado va a mostrar los diferentes cambios de estado de un objeto a lo largo del tiempo eso va a depender de los diferentes eventos que puedan ocurrir a través del tiempo.

El diagrama de estado, en cambio, se enfoca en cómo un objeto cambia su comportamiento a lo largo del tiempo, pasando por distintos estados. Por ejemplo, un `Pedido` en una tienda en línea podría comenzar en el estado `En Proceso`, luego pasar a `Pagado` cuando se confirma el pago, y finalmente a `Enviado` cuando se despacha. Las transiciones entre estos estados se disparan por eventos como `pago recibido` o `envío confirmado`, y pueden incluir condiciones como `[pago verificado]`. Un estado final marcaría cuando el pedido se entrega y el proceso termina.

Mientras el diagrama de clase responde a "¿qué componentes tiene el sistema y cómo se conectan?", el diagrama de estado responde a "¿cómo reacciona un objeto a eventos y qué estados atraviesa?". Por ejemplo, en un cajero automático, el diagrama de clase mostraría las clases `Cuenta`, `Tarjeta` y `Transacción`, mientras que el diagrama de estado describiría cómo la `Tarjeta` pasa de `Insertada` a `Validando PIN` y luego a `Mostrando Menú`, dependiendo de las acciones del usuario.

En resumen, el diagrama de clase es como un mapa arquitectónico del sistema, y el diagrama de estado es como un manual de uso que sigue el flujo de vida de un objeto. Ambos son complementarios y cruciales para modelar sistemas complejos de manera clara y eficiente.

Diagrama de actividades: Representa el flujo de trabajo o los pasos que sigue un proceso. Es como un mapa de tareas con decisiones y caminos.

Diagrama de clases: Muestra las "plantillas" de los objetos (clases), con sus atributos, métodos y cómo se relacionan. Es como el esqueleto del sistema.

Diagrama de estado: Describe cómo cambia el estado de un objeto según los eventos. Es como ver las etapas de vida de un objeto.

Diagrama entidad-relación: Sirve para modelar bases de datos, mostrando entidades (cosas importantes) y cómo se relacionan. Es como definir los personajes y sus vínculos.

Diagrama de colaboración: Muestra cómo interactúan los objetos para lograr algo, enfocándose en las relaciones más que en el tiempo. Es como ver un grupo resolviendo una tarea juntos.

Colaboración: es un diagrama que muestra cómo interactúan los objetos entre sí para realizar un proceso, mostrando que objeto interactúa con que objeto y el orden que debe tener todo el proceso hasta el final.

Emily Hernández

Roger Barquero

Yoander Ramírez

Gabriel Mata