# data[].attributes.body
Julián Hernández

Emily Hernández

Roger Barquero

Yoander Ramírez

Gabriel Mata

# data[].attributes.body
Entidad-Relación: es un diagrama que sirve para mostrar de una forma gráfica el diseño de las tablas y los atributos de las entidades de una base de datos relacional, y poder identificar el tipo de relación entre ellas.

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.

# data[].attributes.body
Diagrama de secuencia: Muestra cómo los objetos se comunican entre sí con mensajes en el tiempo. Es como ver una conversación paso a paso.

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.

# data[].attributes.body
El diagrama de clase describe la estructura estática de un sistema, mostrando las clases, sus atributos, métodos y cómo se relacionan entre sí. Por ejemplo, en una biblioteca, la clase `Libro` tendría atributos como `-titulo: String` y `-autor: String`, y métodos como `+prestar()` o `+devolver()`. Esta clase podría asociarse con `Usuario` mediante una relación de préstamo, indicando que un usuario puede tener múltiples libros prestados. También podríamos usar herencia si existe una clase `Material` como padre de `Libro` y `Revista`, representada con una flecha hueca.

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.

# data[].attributes.body
el de clase va a enseñar como se relacionan los objetos uno con otro mostrando metodos, clases y relaciones y el diagrama de estado es mas cuando enseña lo que va pasando la transicion en los objetos y mostrando los diferentes estados

# data[].attributes.body
Diagrama de clase es una visualización como funcionan, organizan, estructuran los diferentes procesos y atributos.

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.

# data[].attributes.body
El diagrama de clase lo entiendo como algo visual que representa ciertos atributos y también los métodos y como todo esto se relaciona entre sí. Y el diagrama de estado valga la redundancia pasa por diferentes estados o transiciones y así se puede apreciar el comportamiento de un sistema.

# data[].attributes.body
El diagrama de clases muestra sus componentes de una manera solida ,como clases atributos y demas ,siendo muy util para la orientacion de objetos y el diagrama de estado muestra un objeto y de ahi todo lo que acontece con el mismo permitiendo ver la manera en que evoluciona

# data[].attributes.body
Diagrama de clase se presenta el nombre especifico, atributos y operaciones de una manera visual en comunicación entre los mismos, y diagramas de estado visualiza los distintos estados y reglas que pasan los objetos dependiendo de los eventos que pase.

# data[].attributes.body
Diagrama de Clases: Es una representación gráfica que muestra las clases de un sistema, sus atributos, métodos y las relaciones entre ellas.

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.

# data[].attributes.body
El diagrama de clases: Representa la estructura estática de un sistema, mostrando las clases, sus atributos, métodos y las relaciones

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

# data[].attributes.body
Diagrama de Clase, muestra la parte estructural de un desarrollo, los objetos de como se realacionan uno con el otro pudiendo observar sus relaciones y conexiones, por otra parte el diagrama de estado nos da una funcion de dinamismo, aprovechando la visualizacion de comportamiento logico de la funcionalidad del proyecto.

# data[].attributes.body
Diagrama de Secuencia: Es el que describe la relación de los objetos en un sistema a través del tiempo.

Diagrama de Actividad: Es una clase de diagrama que ilustra el flujo laboral o el flujo de control de un proceso o actividad.

# data[].attributes.body
Clases: es un diagrama que nos ayuda a visualizar cómo funcionan y se organizan los procesos, además de identificar los atributos de cada proceso y las acciones que podrían realizar.

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.

# data[].attributes.body
diagrama de secuencia es como comunicarse en un proceso pero paso a paso osea ordenado y el de actividades mas que todo se puede accionar diferente y al final encajar

# data[].attributes.body
Diagrama de secuencia muestra cómo los objetos o componentes interactúan entre sí a lo largo del tiempo, enfocándose en el orden de los mensajes o llamadas entre ellos.

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.

# data[].attributes.body
Los diagramas de secuencia son los que hacen referencia a la interacción entre los objetos que pueda contener un sistema en el cual se establece un orden. Los diagramas de actividades son las que muestran el flujo de las operaciones como las acciones que se realizan.

# data[].attributes.body
Entiendo por diagrama de secuencia como un diagrama que conlleva relación entre si de los objetos de un sistema mostrando a interacción y diagrama de actividades como pasos o acciones del flujo de tareas o actividades

# data[].attributes.body
Por diagrama de secuencia entiendo que es un diagrama que necesita hacer varias cosas a la vez, pero de una manera ordenada o que va por pasos. En cuanto al de actividades pueden modelar diferentes acciones para llegar al final del proceso encajando con otros diagramas diferentes

# data[].attributes.body
entendí que el diagrama de secuencia me muestra cómo se comunican los objetos o personas en un proceso, paso a paso y en el orden en que ocurre, usando flechas y leyéndose de arriba hacia abajo. En cambio, el diagrama de actividades me sirve para ver qué acciones se realizan en un proceso y en qué orden, mostrando también decisiones (como un "sí o no") y los diferentes caminos que se pueden seguir según lo que pase.

# data[].attributes.body
Los diagramas de actividades y de secuencia son herramientas clave en UML para modelar comportamientos en sistemas.

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

# data[].attributes.body
Diagrama de secuencia, este nos da un marco referencia visual sobre los objetos o componentes de un sistema a diagrama de secuencia muestra el flijo de trabajo o los pasos que sigue cada proceso

# data[].attributes.body
Diagrama de Secuencia: Es el que muestra cómo los objetos interactúan en un sistema a lo largo del tiempo.

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

# data[].attributes.body
Entiendo que el diagrama de secuencia representa la interacción entre objetos en un sistema a lo largo del tiempo, mostrando el orden en que los mensajes se envían y reciben.

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

# data[].attributes.body
Presentación Sala 2 - Diagramas UML

# data[].attributes.attachment_link.title
Presentación Tecnología Consejos Móvil Ordenador Iconos Profesional Azul

# data[].attributes.body
Matriz y RACI

# data[].attributes.body
Presentación de: MAR y RACI

# data[].attributes.attachment_link.title
Matriz de asignación de responsabilidades - RACI

# data[].attributes.body
Resumen Ejecutivo - Matrices

# data[].attributes.body
Segundo video Matriz RACI

# data[].attributes.body
Matriz Responsabilidades, video

# data[].attributes.body
Emily Hernández

# data[].attributes.body
Caso de Uso

# data[].attributes.body
Casos de Uso

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.

# data[].attributes.attachment_link.description
Check out this Presentation designed by Trabajos Universidad.

# data[].attributes.body
sería como el usuario va a interactuar con el sistema para que se logre el objetivo propuesto

# data[].attributes.body
Es la relación o comunicación del usuario con el sistema en un determinado proceso

# data[].attributes.body
Se usa para un análisis para concretar un objetivo en específico

# data[].attributes.body
Los casos de usos son como el usuario interactúa con un sistema, como en diseño o en diagramas de software.

# data[].attributes.body
Un caso de uso es básicamente una documento o diagrama que explica cómo una persona o un sistema van a comunicarse o relacionarse con una aplicación o plataforma para lograr algo específico

# data[].attributes.body
Son como distintas situaciones y formas en las que el usuario interactúa con el sistema

# data[].attributes.body
Casos de uso

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

# data[].attributes.body
Es un tipo de diagrama para ver como seria la interacción del cliente con el software, ademas de represantar el flujo de los datos.

# data[].attributes.body
Son descripciones de cómo los usuarios interactúan con un sistema para lograr un objetivo y sirven para entender las necesidades de los usuarios y planificar las funcionalidades del software. Esto ayuda a los developersa saber qué hacer en cada situación y a asegurarse de que el sistema cumpla con lo que se espera.

# data[].attributes.body
Casos de Uso:

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

# data[].attributes.body
describe como el usuario debería interactuar con el software

# data[].attributes.body
Pruebas de Software

# data[].attributes.attachment_link.title
Light Blue Futuristic Technology Project Proposal Presentation

# data[].attributes.body
1. Las pruebas demuestran la presencia de defectos, no su ausencia

2. Las pruebas exhaustivas son imposibles

3. Las pruebas tempranas ahorran tiempo y dinero

4. Agrupación de defectos

5. Paradoja del pesticida

6. Las pruebas dependen del contexto

7. Falacia de ausencia de errores

# data[].attributes.body
Las pruebas solo muestran si hay fallos, no que todo esté perfecto.

No se puede probar absolutamente todo.

Hay que tener cuidado con la trampa del pesticida: si siempre se prueba lo mismo, se dejan de encontrar errores nuevos.

Probar desde el inicio ahorra plata y tiempo.

Los errores suelen juntarse en ciertos lugares.

No todas las pruebas sirven para todo, dependen de la situación.

Que no haya errores no significa que el sistema funcione bien.

# data[].attributes.headline
Roger Barquero 7 Principios Pruebas de Software

# data[].attributes.subject
Roger Barquero 7 Principios Pruebas de Software

# data[].attributes.body
1-Las pruebas demuestran la presencia de defectos, no su ausencia.

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.

# data[].attributes.body
1.Las pruebas demuestran la presencia de defectos, no su ausencia

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

# data[].attributes.body
1-Demuestran presencia no ausencia

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

# data[].attributes.body
1. Las 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. Agrupacion de defectos

5. Tener cuidado con la paradoja del pesticida

6. Las pruebas dependen del contexto

7. Falacia de ausencia de errores

# data[].attributes.body
1 La prueba muestran presencia de defectos

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

# data[].attributes.body
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

# data[].attributes.body
Los 7 principios de las Pruebas de Software

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.

# data[].attributes.body
1.Presencia de defectos, no su ausencia

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

# data[].attributes.body
Principios de prueba de software.

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.

# data[].attributes.body
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.AGRUPACION DE DEFECTOS.

5.TENER CUIDADO CON LA PARADOJA DEL PESTICIDA

6.LAS PRUEBAS DEPENDEN DEL CONTEXTO

7.FALACIA DE AUSENCIA DE ERRORES

# data[].attributes.body
La retroalimentación positiva es cuando te dicen qué hiciste bien para motivarte. La negativa es cuando te señalan algo que puedes mejorar para aprender y crecer.

# data[].attributes.body
Retroalimentación positiva, Dar comentario u opiniones que pueda fomentar alguna motivación para destacar algún aspecto, La retroalimentación negativa, no precisamente tiene que ser algo malo, únicamente da el punto de vista de algo que se puede mejorar o cambiar para obtener la finalidad deseada

# data[].attributes.body
La retroalimentación positiva se da cuando por medio del cambio se busca una mejoría en cuestión y la negativa se podría decir que viene siendo algo que regula o busca equilibrar.

# data[].attributes.body
Para mi la retroalimentación positiva busca ver de que manera impacta a la persona dando una enseñanza para su propio crecimiento con base en un hecho sucedido mientras que la negativa busca la manera de hacer lo posible para perjudicar a la persona.

# data[].attributes.body
La retroalimentación positiva refuerza un cambio, haciendo que siga creciendo o intensificándose. En cambio, la retroalimentación negativa busca equilibrio, ajustando las cosas para mantener la estabilidad.