¿Ejemplo de dependencia "de principio a fin"?

¿Me puede dar un ejemplo de una dependencia de principio a fin ? Wikipedia lo describe así:

  • De principio a fin (SF)

    A SF B = B no puede terminar antes de que comience A

    Diagrama de dependencia "A SF B"

Esa es una muy buena pregunta, haría +1 dos veces si pudiera...

Respuestas (23)

No creo que haya usado esto nunca, pero generalmente he pensado en una dependencia de Inicio - Finalización que se usa cuando se requiere un período de entrega acordado entre dos actividades.

Considere el siguiente escenario:

En un proyecto de implementación de un sistema, sería bastante normal que el personal del proyecto proporcione un nivel de soporte para un sistema durante un período de establecimiento después de la puesta en marcha. En algún momento, la responsabilidad del apoyo debe transferirse (en nuestro ejemplo hipotético) a un equipo de apoyo en vida. Durante un período definido, digamos dos semanas, tanto los recursos del proyecto como los recursos en la vida brindan soporte, mientras se realiza una transferencia de uno a otro.

Esta es una dependencia de Inicio - Finalización, porque el equipo de In-life tiene que comenzar a dar soporte al sistema antes de que el equipo del Proyecto pueda terminar.

Este ejemplo es más claro que el mío...+1. Esto deja en claro cómo funcionan las dependencias de SF.
Este ejemplo ¿Qué lógica impulsa entonces el inicio del apoyo en la vida? ¿Normalmente no usaría una dependencia SS con retraso? Tenga en cuenta que la dirección lógica debe ser activada por el predecesor de la tarea. En este caso, el inicio del apoyo en vida está dictado por eventos anteriores y la fecha de inicio debe tener la dependencia necesaria.

Una dependencia de SF se verá exactamente como una dependencia de FS con una ventaja en unidades de tiempo si observa el diagrama de red (a pesar de las flechas). La diferencia se reduce a la lógica de la restricción. Por ejemplo, la dependencia de FS con un adelanto de dos días dice que la tarea 2 está programada para comenzar dos días antes de que finalice la tarea 1. La lógica asumida con este cronograma es que la tarea 2 puede comenzar dentro de los dos días posteriores a la finalización de la tarea 1, pero puede comenzar antes si los recursos lo permiten y puede comenzar más tarde si está fallando por otras razones.

En una dependencia de SF con un adelanto de dos días, la tarea 2 debe comenzar dos días antes de que finalice la tarea 1; de lo contrario, la tarea 1 no puede terminar. La lógica asumida aquí es un deber versus una lata.

Un ejemplo aproximado podría ser el uso de una grúa para levantar un objeto pesado al piso 35 de un edificio en construcción. El paquete de trabajo que contiene los recursos (humanos y equipos) para operar la grúa es la tarea 1. Levanta con éxito el objeto hasta el piso 35 y se posiciona con éxito para transferirlo. Sin embargo, el siguiente paquete de trabajo, la tarea 2, que contiene los recursos de recepción, tanto el equipo como el personal, no están allí y no están listos para comenzar. La tarea 1, aunque haya completado su acción de destino a tiempo y esté lista para transferirse, permanecerá "activa" hasta que comience el siguiente paquete. La salida del paquete uno y la entrada del paquete dos deben ocurrir juntas.

¡+1 por el ejemplo en sí y haría +1 nuevamente por ofrecer un ejemplo que proviene de fuera de TI!
@TiagoCardoso Me complace agregar el +1 adicional para el ejemplo que no es de TI. ¡Muy buena!
Lo que impulsa el inicio de la tarea 2. Una ventaja de la programación con dependencias es la capacidad de mover dinámicamente la programación cuando sea necesario. Digamos que la entrega del "objeto pesado" se retrasa un mes, entonces las tareas relevantes deberían retrasarse. Si la tarea 1 tiene una dependencia SF en la tarea 2, la tarea 2 no se deslizará. Si agrega una dependencia para impulsar la tarea 2 de tareas anteriores, probablemente agregará un bucle lógico que el software no permitirá.
@rapscalli, Otros paquetes podrían desencadenar la tarea dos. Fue un trabajo complejo. Hubo muchos otros predecesores que tuvieron lugar simultáneamente.

Tanto David como Iain han dado buenos ejemplos.

Como dijo David, es la lógica la que impulsa la dependencia. La mayoría de las tareas son FS: la tarea B no puede comenzar hasta que la tarea A esté completa, y las dependencias de las tareas se consideran transferencias directas. SF simplemente invierte la lógica: la tarea B no se puede considerar completa hasta que la tarea A haya comenzado (se haya producido el traspaso).

Creo que una dependencia de FS es útil cuando tiene una actividad que no puede terminar antes de que comience el dependiente. Imagínese: se contrata a un vigilante para cuidar un edificio durante las noches y el gerente le dice que su actividad no puede terminar hasta que llegue el administrador del edificio por la mañana. La hora de llegada puede variar cada día pero el vigilante no puede terminar su actividad hasta que llegue el administrador y empiece a trabajar.

Otro ejemplo para una fecha fija de fecha de inicio: tengo que colocar los formularios para una columna después de que estos se retiren de otra ya vertida y curada. Sé cuál es la fecha de inicio para comenzar a formar la nueva columna (fecha fija) y necesito instalar la barra de refuerzo para esa columna previamente. Por lo tanto, puedo vincular la instalación de encofrado de columnas (b) y la instalación de barras de refuerzo (a) con una relación SF, lo que significa que la actividad b debe comenzar para que la actividad a se considere terminada.

Siempre me gustó el ejemplo de la niñera, que quiere terminar de cuidar al niño pero no puede terminar hasta que regresa un padre (y comienza a cuidar al niño).

Este es el término más confuso e incomprendido. Incluso la última edición de PMBOK hace un lío. Más bien, hace el hazmerreír cuando, al dar el ejemplo de los turnos de seguridad, dice que el "primer" turno de seguridad es una ACTIVIDAD SUCESORA y el "segundo" turno de seguridad (que vendrá después del primer turno) es un PREDECESOR actividad. ¡Y luego examinan a las personas para PMP!

Soy un firme creyente de la Doctrina KISS (Keep It Simple Stupid). Tome el ejemplo de un generador que está en línea y proporciona energía a un edificio. Llame a esta actividad A. El generador no se detendrá hasta que se encienda la electricidad de la red principal. Llame a la actividad que involucra energía de la red B. Por lo tanto, la actividad predecesora A no terminará hasta que comience la actividad sucesora B.

En el diagrama de red, esta dependencia se representará de la siguiente manera:

una. Cuadro B a la derecha del Cuadro A, para representar el orden cronológico correcto. b. Flecha desde el inicio del Cuadro B (para representar el inicio de la actividad) hasta el final del Cuadro A (para representar el final de la actividad).

Esto será exactamente lo opuesto a la dependencia de Finalizar a Iniciar.

Así he entendido yo el tema.

Considere este ejemplo simple que puede probar en Microsoft Project para ver cómo funciona en la práctica. Para explicar el uso de una dependencia de principio a fin (SF), también explicaré en qué se diferencia de una dependencia FS.

Tiene dos tareas, prepararse para la apertura de la tienda y el día de apertura . El día de apertura está planeado para un viernes y necesita 2 días para prepararse. La tarea Día Inaugural no puede moverse y debe ocurrir el viernes.

Terminar para comenzar: Preparar para la apertura de la tienda se ejecuta durante el miércoles y el jueves y está vinculado (FS) al día de apertura, que es el viernes. Si se da cuenta de que necesita 4 días para prepararse y cambia la duración de la tarea Preparar para la apertura de la tienda a 4 días, la tarea del día de apertura pasará a la semana siguiente, lo que no puede suceder.

De principio a fin: el mismo escenario, configura las tareas usando una dependencia de SF y luego se da cuenta de que necesita 4 días en lugar de 2 días para prepararse. Con la relación SF, cuando actualiza la duración a 4 días, mantiene el día de apertura el viernes y más bien adelanta la fecha de inicio de la tarea Preparar para la apertura de la tienda, ya que aumenta la duración. Esto significará que ahora debe comenzar los preparativos el lunes para llegar a tiempo al Día Inaugural.

El mejor ejemplo de implementación de principio a fin implica el siguiente análisis, del cual, por simplicidad, proporciono la URL: Ejemplo de principio a fin

Utilizamos SF en la industria de la construcción cuando es necesario eliminar tareas relacionadas (como encofrado y refuerzo) de la actividad principal de verter el hormigón. El uso de SF permite que el vertido de hormigón se vea afectado por los retrasos, pero no necesariamente por el encofrado y el refuerzo, que requieren mucha mano de obra y son sensibles a la entrega.
SF es una herramienta invaluable para proteger la integridad de la ruta crítica en proyectos grandes en los que el contratista asume riesgos mayores de lo normal, como en los proyectos BOT. Nos permite, como planificadores, eliminar las tareas "desordenadas" de la ruta crítica, haciendo que nuestras rutas críticas reflejen mejor los efectos del mundo real de los retrasos anteriores.
Esta es una respuesta de solo enlace. Considere agregar un extracto relevante de la publicación de blog a la que se hace referencia en su respuesta aquí, ya que la información sobre PMSE debe ser en gran medida independiente.

Un ejemplo concreto de un proyecto de construcción.

El ejemplo de la niñera es bueno. Sin embargo, aquí hay un ejemplo concreto (¡juego de palabras!) de un proyecto de construcción:

Digamos que está comprando un cobertizo prefabricado. La empresa prefabricada le envió el dibujo de los cimientos de hormigón y la ubicación de los pernos de los cimientos para colocar el cobertizo. Los cimientos con los pernos están listos y curados y el camión que transporta el cobertizo completamente ensamblado ha llegado al sitio. Ahora tienes las siguientes tareas en tu agenda:

  • descargar el cobertizo
  • instalar el cobertizo

Es posible que haya contratado una grúa de un proveedor para descargar el cobertizo y un equipo de instalación por separado. La tarea de descarga puede comenzar: puede montar los cables y preparar los puntos de elevación. Sin embargo, ¿puede dejar que la grúa complete el trabajo de descarga del cobertizo aunque el equipo de instalación aún no haya comenzado a trabajar?

No, la tarea de descarga no se puede completar hasta que comience la tarea de instalación. Esta es una dependencia de principio a fin (SF).

Baby sitter y hadover, ambos son los mejores ejemplos para que un alumno entienda el significado de SF. Si el trabajo se completa, la entrega no se puede iniciar hasta que comience el equipo de toma de control... y, por lo tanto, el trabajo no se puede considerar completo ya que la entrega no se ha iniciado...

Un ejemplo de relación SF.

Actividad sucesora - La noche se asienta en Nueva York durante 12 horas Actividad predecesora - La luz del día se eleva en Nueva York durante 12 horas

Si se supone que 12 horas es el tiempo de espera de cada actividad, el Sucesor continúa durante 12 horas hasta que el Predecesor se despierta al borde de la Finalización del Sucesor y continúa durante 12 horas O viceversa. Esto tiene lugar en un proceso cíclico todos los días.

Todos los Procesos Cíclicos formados por 2 actividades (Uno Sucesor y otro Predecesor) comparten relación Tipo SF. Este es un tipo raro de relación que se utiliza en Realtime Projects, ya que la mayoría de las Redes de Realtime Project tienen actividades que tienen un Pase hacia adelante o un Pase hacia atrás, pero no de naturaleza cíclica.

La dependencia Start-Finish desde el inicio de la actividad A hasta el final de la actividad B exige que la actividad B finalice después de que haya comenzado la actividad A. El predecesor (actividad A) y el sucesor (actividad B) se refieren a la lógica CPM, es decir , el tiempo de la actividad B se calcula después y en relación con el tiempo de la actividad A, aunque la actividad B puede terminar antes que la actividad A del cálculo.

Start-Finish puede modelar lo siguiente:

  1. Un relevo : por ejemplo , el equipo B supervisa un sitio hasta que llega el equipo A.

    Nota : si la actividad B tiene una fecha de inicio fija, es mejor modelarla con una actividad hamoc.

  2. Un período de traspaso : por ejemplo , el equipo B entrena al equipo A durante su última semana de trabajo.

    Nota : el retraso se da como una duración positiva para tener una superposición.

  3. Planifique lo más tarde posible cuando el software aplique lo antes posible la planificación de todo el programa: por ejemplo , la actividad B es una entrega que finaliza justo a tiempo para la instalación en la actividad A.

  4. Hacer cumplir la continuidad : por ejemplo, la actividad A y B son solo una tarea continua que tuvo que dividirse con fines contables y que se planificó después de la actividad C con una dependencia Finalizar-Finalizar. La actividad A (la última parte) está correctamente planificada después de la actividad C, pero se necesita un Inicio-Finalización de A a B para considerarlas como una sola tarea.

Nota : para programarse como se espera, las actividades deben planificarse lo antes posible y la actividad B debe tener una flotación mayor o igual a 0.

Supongamos que estás escalando rocas. Tienes que empezar a sujetar con una mano para terminar de sujetar con la otra para poder avanzar.

Supongamos que está protegiendo algo. El equipo de reemplazo debe comenzar su trabajo para que usted termine el suyo.

Supongamos que va a cambiar los cables de energía de un sistema crítico. El UPS debería comenzar a funcionar para que pueda cortar la electricidad.

La relación de principio a fin se utiliza para programar el tiempo de la tarea sucesora. es decir, cuándo debe comenzar la tarea B para terminar con el inicio de la tarea A.

Por ejemplo: en este proyecto, las tareas críticas son el diseño, la construcción, el montaje y la entrega. Pero hay 2 tareas no críticas que deben estar "listas" exactamente el día en que comienza la tarea de ensamblaje; esas 2 tareas son (compra de componentes eléctricos y compra de sujetadores).

Esas 2 tareas deben programarse para comenzar lo suficientemente temprano, de modo que terminen (y estén listas) el día que comience el ensamblaje, no tarde o temprano.

Las tareas de compra no deben terminar demasiado pronto, para no desperdiciar recursos en costos de inventario para almacenar esos componentes, pero tampoco esos componentes deben llegar demasiado tarde, porque son necesarios para el ensamblaje. Entonces, la compra de esos componentes debería terminar justo el día en que comienza la construcción.

El propósito de este tipo de dependencia: es programar tareas para que finalicen en relación con el inicio de la tarea predecesora.

En este ejemplo, comprar componentes eléctricos : debe comenzar el 13 de mayo para terminar el 15 de mayo comprar sujetadores : debe comenzar el 12 de mayo para terminar el 15 de mayo

En la línea de tiempo: las tareas rosas son tareas críticas, mientras que las dos tareas oscuras no son críticas, y su dependencia de la tarea "Ensamblar" se define como de principio a fin, como se muestra.

Las tareas de compra deben Tarea de construcción de principio a fin

votado a favor debido a la captura de pantalla / diagrama de cómo se ve esto realmente con un buen ejemplo

Mi proyecto tiene una bomba contra incendios. Puedo comenzar el trabajo eléctrico para la bomba contra incendios, pero no puedo terminarlo hasta que la instalación de la bomba contra incendios haya comenzado, pero la bomba contra incendios no tiene que estar completa para que la electricidad termine, es decir, de principio a fin.

SF no es una relación común, pero puede ser útil bajo ciertas condiciones.

Su uso principal es cuando existe un requisito de continuidad.

En el caso de una operación de 24 horas, debe haber al menos un turno de servicio a la vez; El Turno 1 podría vincularse al Turno 2 usando una relación SF. Si el turno 2 se retrasa, el turno 1 debe continuar trabajando después de la hora programada inicialmente.

De manera similar, si tuviera que pasar de un sistema antiguo a uno nuevo en un entorno que requería continuidad, por ejemplo, un gran banco estaba realizando cambios en su sistema bancario en línea. Se podría utilizar una relación de principio a fin para vincular las operaciones de los sistemas; Es decir, el Sistema 1 no podía terminar hasta que el Sistema 2 hubiera comenzado.

Este artículo profundiza en https://scopetraining.com.au/project-management/finish-start-relathionships/Start to Finish Relationships

El turno de noche terminará cuando comience el turno de día. B terminará cuando comience A.

Aquí está mi opinión sobre esto.

Creo que SF es simplemente una restricción de relación que describe lo que no debería suceder.

"La segunda tarea no puede terminar antes de que comience la primera tarea"

La segunda tarea necesita algún tipo de entrada de la primera tarea y puede comenzar temprano si esa entrada se obtiene antes. Digamos que la tarea 1 de 8 horas tiene esa entrada lista a las 9 am del día 1, la tarea 2 puede comenzar el día 0 (en lugar del día 2) y finalizar tan pronto como la entrada esté disponible (considerando que la tarea 2 requiere que entrada antes de que termine), digamos a las 10 a. m. del día 1. Debe haber esa superposición. La finalización de la tarea 2 antes de que comience la tarea 1 significa que, básicamente, la tarea 2 no necesita nada de la tarea 1 y rompe la restricción de SF. En ese caso, ambos deberían ejecutarse en paralelo y no secuencialmente.

Siempre he visto esto desde la perspectiva no del "flujo del proceso", sino de "¿cuál es la lógica que impulsa la programación?". El ejemplo simple que he visto anteriormente es el de revisión para un examen. Puede decir "No puedo rendir el examen hasta que haya hecho la revisión" (el final de la revisión impulsa el inicio del examen) o "Tengo que planificar mi revisión para que termine a tiempo para el examen" (el inicio del examen impulsa el final de la revisión ). En este ejemplo, es bastante fácil de entender ya que en la práctica los exámenes suelen ser fijos y es la finalización del trabajo preparatorio lo que debe programarse para que coincida con la fecha del examen. Si el examen se mueve o cambia el tiempo necesario para la revisión, la relación final-inicio mantiene las cosas alineadas como deberían.

Mi comprensión de una relación SF es que el "predecesor no puede terminar hasta que comience el sucesor". Al igual que el ejemplo de "cambios de guardia" que mucha gente usa: el final del predecesor (Turno 1) es impulsado por la cantidad de retraso en el inicio del sucesor (Turno 2). Mi ejemplo es: un contratista debe proporcionar mantenimiento preventivo (predecesor) para un avión hasta que el cliente tome posesión para realizar sus pruebas de aceptación (sucesor). Si el cliente retrasa las pruebas de aceptación, el mantenimiento preventivo anterior realizado por el contratista debe continuar, lo que puede aumentar el costo de esa actividad anterior.[Puede tener el efecto contrario: El inicio del mantenimiento preventivo es la recepción de la Prueba de ensamblaje final; por lo tanto, si el cliente decide realizar la prueba de aceptación inmediatamente después de la prueba de ensamblaje final del contratista, la fecha de finalización del mantenimiento preventivo aún depende del inicio de la prueba de aceptación del cliente. En este caso, sin embargo, la fecha de inicio del mantenimiento preventivo (impulsado (FS) por la prueba de ensamblaje final) y la fecha de finalización (impulsado por el inicio de la prueba de aceptación del cliente) serían la misma fecha; en este caso, el costo del mantenimiento preventivo virtualmente "0"]

La única vez que he visto que esto se usa correctamente es cuando un evento, que tiene una fecha específica, impulsa la finalización de tareas de preparación anteriores.

Por ejemplo, un paquete de trabajo de preparación para el examen, dos tareas
1 - estudio de examen
2 - examen de asiento

"sit exam" es una fecha codificada, por ejemplo, el 1 de diciembre. cuando esta tarea comienza, desencadena el final del estudio del examen. si la fecha del examen se mueve, esto cambia las fechas de estudio del examen.

Pero...
(al menos en MS Project) Si todo el proyecto tiene una fecha de finalización, entonces será mejor "programar desde" "Fecha de finalización" en la información del proyecto y usar las dependencias de FS.
O
bien, si solo desea configurar una parte de una programación para que se ejecute a partir de una fecha de hito, marque los predecesores relevantes "lo más tarde posible" en información de la tarea > avanzada y vuelva a utilizar las dependencias de FS.

Creo que los pasos para hacer café podrían ser un excelente ejemplo aquí. Imagínese que se levanta por la mañana, bosteza y va a la cocina y se da cuenta de que olvidó programar su cafetera para preparar automáticamente. Ahora todo depende de ti, si te sacudes el sueño y empiezas a preparar el café. También sabrá que tendrá que seguir los siguientes pasos:

Agregar agua Moler granos de café Medir el café en el filtro Agregar el filtro de café Colocar la jarra en la bandeja de calentamiento Presionar la preparación, etc. etc. No estoy seguro, pero creo que este artículo " Principios básicos de PMP " puede ayudarlo. Espero que encuentre hechos fáciles de entender a través de mi respuesta. ¡Gracias!

En la construcción usamos esto muy a menudo.

Un ejemplo: se está levantando un equipo del suelo y debe montarse en el 4.º piso.

Hay dos equipos diferentes: uno que eleva el equipo desde la planta baja hasta el 4.º piso verticalmente y otro que tira del equipo horizontalmente desde las columnas exteriores del 4.º piso hacia el interior de la estructura.

Por lo tanto, la segunda tarea (sucesora) de llevar el equipo al interior del cuarto piso no puede terminar a menos que la tarea anterior (elevación del equipo) haya terminado.