TC023

Material de la materia planificación de proyectos (TC023)
Index Commits Files Refs README
ModeNameSize
-rw-r--r--README.md456L
-rw-r--r--definicion_de_producto.gv12L
-rw-r--r--definicion_de_producto.png30997B
-rw-r--r--parcial_09_06_25_pdp_fiuba.pdf242520B
-rw-r--r--proceso_de_diseno.gv14L
-rw-r--r--proceso_de_diseno.png38255B
-rw-r--r--wbs4.png36992B

Planificación de Proyectos

\tableofcontents

Proceso de Diseño

El diseño de ingeniería se vincula con la concepción de sistemas, equipos, componentes o procesos con el fin de satisfacer una necesidad

Un proyecto de ingeniería es definido como: "Un proceso único consistente en un conjunto de actividades coordinadas y controladas, con fechas establecidas de inicio y finalización, desarrolladas con el fin de alcanzar un objetivo para conformar requerimientos específicos, incluyendo restricciones de tiempo, costo y recursos".

Las tareas involucradas y su desarrollo reúnan las siguientes condiciones:

La salida debe resultar de un proceso de optimización del diseño, buscando simplificar, mejorar, innovar, y reducir desperdicios, valiéndose de herramientas específicas tales como:

Proceso de Diseño

Determinación de la necesidad

El proceso de diseño parte del reconocimiento de una necesidad insatisfecha, mal satisfecha, o susceptible de mejorar en algún sentido. Las necesidades resultan o surgen por motivaciones muy variadas:

Definición de producto

Los requerimientos son las necesidades, funcionalidades o condiciones que un sistema, producto o proyecto debe cumplir para satisfacer los objetivos. Los requerimientos se pueden dividir en funcionales y no funcionales, los funcionales describen qué debe hacer el sistema, por ejemplo: "El sistema debe permitir al usuario crear una cuenta", mientras que los no funcionales describen como se debe comportar el sistema, o que características de calidad debe tener, por ejemplo "El sistema debe responder en menos de 2 segundos".

Los requerimientos son la base de las especificaciones, la cual es una descripción detallada, clara y precisa de cómo debe ser el producto, sistema o componente para cumplir con los requerimientos definidos.

Proceso de Diseño

Especificaciones técnicas

Detallan los aspectos funcionales, mecánicos, eléctricos, de software, etc. Ejemplo: "El sistema debe usar una base de datos PostgreSQL y soportar hasta 1000 usuarios concurrentes."

Especificaciones funcionales

Describen lo que el sistema debe hacer. Ejemplo: "El sistema debe permitir registrar nuevos usuarios mediante un formulario web."

Especificaciones de diseño

Incluyen planos, diagramas, prototipos o interfaces. Ejemplo: un wireframe de una aplicación móvil.

Especificaciones de producto o fabricación

Usadas en ingeniería o industria. Ejemplo: materiales, dimensiones, tolerancias, procesos.

Diseño detallado

El propósito de esta etapa del proyecto es:

Pensamiento de Diseño (Design Thinking)

El pensamiento de diseño es una metodología que se aplica en el diseño de productos, esta metodología esta centrada en las personas, ya que se basa en entender las necesidades del usuario, generando ideas, prototipando soluciones y probándolas corrigiéndolas y volviendo a empezar, esto ultimo notando el comportamiento iterativo de la metodología.

Etapas del pensamiento de diseño

Principalmente, el pensamiento de diseño se estructura en 5 fases

  1. Empatizar
  2. Definir
  3. Idear
  4. Prototipar
  5. Evaluar

Empatizar

Durante esta etapa se busca comprender al usuario, para esto se puede seguir la regla observar-escuchar-involucrarse.

Mapas de Empatía

Es una herramienta que ayuda a sintetizar la información obtenida del usuario (en etapas previas, como entrevistas, o mediante observación, etc) de manera tal que resulte mas fácil identificar descubrimientos claves (insights) que no se obtienen solo con datos.

La estructura típica de un mapa de empatía es:

  1. Dice
  2. Piensa
  3. Siente
  4. Hace
  5. Esfuerzos
  6. Necesidades

Definir

Se sintetiza la información para formular un problema claro y bien enfocado, basado en las necesidades detectadas en etapas anteriores.

POV Statement

Un POV Statement (Point of View Statement) es una declaración clara del problema desde la perspectiva del usuario, que ayuda a enfocar la ideación en una necesidad humana específica.

La estructura tipica de un POV Statement es <usuario> necesita <necesidad> porque <insight>, por ejemplo en el contexto del sistema de acceso al estacionamiento desde el punto de vista del operador de sistema: "el operador necesita registrar vehículos de forma rápida y sin cometer errores, porque debe atender a varios usuarios en poco tiempo y asegurarse de que la información esté bien cargada**.

Idear

El propósito principal de la etapa de idear es generar soluciones creativas al problema definido a partir de los hallazgos de las fases anteriores, existen muchas dinámicas para generar ideas, como por ejemplo brainstorming, SCAMPER, entre otras

Brainstorming

El brainstorming es una herramienta dinámica grupal (o individual) para generar una gran cantidad de ideas sin juzgarlas, con el fin de explorar todas las posibles soluciones a un reto o necesidad del usuario.

Prototipar

Durante esta etapa se convierten las ideas seleccionadas de la etapa anterior en soluciones tangibles y experimentales con las cuales el usuario pueda interactuar, de esta forma detectando posibles fallas, oportunidades o malentendidos.

Algunas formas de prototipar incluyen realizar bocetos, maquetas, videos simulados, entre otras.

Evaluar

Durante la etapa de testeo o evaluación se ponen a prueba las soluciones prototipadas con los usuarios para ver si realmente satisfacen sus necesidades, resuelven sus problemas y generan valor.

Con la información obtenida durante esta etapa se puede decidir si volver a etapas anteriores, o rediseñar el prototipo de alguna manera, y en caso de hacer cambios importante repetir la etapa de evaluación.

Work Breakdown Structure (WBS)

Se debe tener definido el propósito, el objetivo y el alcance del proyecto. El propósito, es la razón de ser o el significado más profundo del proyecto. El objetivo es la meta concreta y tangible que se busca alcanzar, basada en el propósito y el alcance se define los límites y fronteras del proyecto, es la suma de todos los requerimientos y las restricciones.

En un WBS o EDT (Estructura de Desglose del Trabajo, en español) se plasma el alcance y los requerimientos del proyecto, para esto se divide la totalidad del proyecto en actividades intermedias únicas.

Los niveles del WBS representan el grado de detalle o descomposición del proyecto en partes más manejables, cuanto mayor sea el nivel mayor será la especificidad de la tarea o actividad. Por lo general las actividades de un WBS se eligen de manera tal que no ocupan mas de 80 horas de trabajo por persona

\

Activity on Node (AON)

En el AON se muestran todas las actividades necesarias para completar el proyecto en un diagrama de nodos y flechas, de manera que se pueda ver las dependencias de cada actividad y se pueda estimar tiempos.

Para estimar tiempos en un diagrama AON, se asigna una duración estimada a cada actividad representada por los nodos, esto puede ser mediante expertos en el area o si se ha realizado proyectos similares antiguamente o bien mediante la técnica PERT (la cual es similar a un promedio ponderado); luego de la estimación de tiempos se analiza la secuencia de actividades para calcular la duración total del proyecto, así como identificar el camino crítico.

El camino critico es el camino de actividades que de retrasarse, se retrasa todo el proyecto, es el de mayor duración, o de holgura nula. La holgura es el tiempo que puede retrasarse (en iniciar o finalizar) sin que se retrasen otras actividades dependientes de esa.

Técnica CPM

La técnica Critical Path Method (CPM) es un método de estimación y gestión de tiempos que se utiliza para planificar, programar y controlar proyectos. Es útil cuando se tiene la duración estimada de cada actividad y se necesita encontrar la secuencia de tareas críticas para completar el proyecto en el menor tiempo posible. Se realiza un gráfico de nodos y flechas con cada una de las actividades del proyecto contemplando las dependencias jerárquicas y temporales

El tiempo mas temprano de un nodo es el instante más inmediato en el cual puede ocurrir el evento correspondiente a dicho nodo. El tiempo más tarde para un nodo es el último instante en el cual puede ocurrir el evento correspondiente al nodo sin retrasar la duración total del proyecto.

La diferencia entre el tiempo más tardío y el tiempo más temprano se define como holgura.

Una actividad crítica es una actividad que no puede retrasarse. Si se retrasa afecta a la duración total del proyecto. En otras palabras, el tiempo más temprano y el tiempo más tarde de inicio de la actividad son idénticos, es decir, tiene tiempo de holgura nulo.

Técnica de estimación de tiempos PERT

La técnica PERT (Program Evaluation and Review Technique) es una herramienta de planificación utilizada para estimar la duración de actividades en proyectos, especialmente cuando hay incertidumbre en los tiempos, esto puede ocurrir cuando no se conoce con certeza cuánto tiempo tomará la actividad, por ejemplo en investigaciones o desarrollos nuevos.

Es una formula probabilística que permite obtener una estimación de tiempo mas real a partir de 3 tiempos estimados de una actividad: el tiempo optimista ($O$), el mas probable ($M$) y el tiempo pesimista ($P$).

$$T_{e} = \frac{O + 4*M + P}{6}$$

El calculo de la varianza de cada actividad se utiliza para determinar la incertidumbre de que se termine el proyecto de acuerdo al programa.

$$Varianza = {\sigma}^2 = \left({\frac{P - O}{6}}\right) ^2$$

Metodologías Ágiles

La metodología ágil es un enfoque flexible para la gestión de proyectos que se centra en la colaboración, la comunicación y la entrega de valor de manera iterativa y continua. En lugar de planificar exhaustivamente al inicio, las metodologías ágiles permiten adaptarse a los cambios en los requisitos y prioridades a lo largo del proyecto

Metodología Scrum

Es una forma de organizar el trabajo en equipo en ciclos cortos y repetitivos llamados Sprints, con el objetivo de entregar valor rápidamente, adaptarse a cambios y mejorar continuamente.

Roles en Scrum

Product Backlog

El Product Backlog es una lista ordenada de todo lo que se necesita hacer para desarrollar el producto. Es la fuente única de requisitos para cualquier cambio que se necesite en el producto. El Product Owner se encarga de crear y mantenerlo, de asignar las prioridades a cada item en funciona del valor de negocio y de asegurarse de que este bien claro y comprendido. El product backlog se actualiza de manera continua, por ejemplo al terminar un sprint o cuando cambian las necesidades de los usuarios.

Los items pueden ser historias de usuario, los cuales son una forma ágil y centrada en el usuario de describir requisitos funcionales.

Historias de Usuario

Las historias de usuario son una forma de describir lo que el usuario necesita de manera simple, clara y centrada en el valor que aportará esa funcionalidad o característica.

El formato mas común de historia de usuario es Como <usuario> quiero <lo que desea> para <beneficio o valor>. Por ejemplo en el sistema de acceso al estacionamiento: "Como operador del sistema, quiero poder registrar los datos del vehículo al ingresar, para llevar un control preciso de los accesos."

Para crear historias de usuario de manera efectiva se puede seguir la regla de las 3 Cs: Card-Conversation-Confirmation (tarjeta, conversación, confirmación)

Temas, Épicas y Tareas

Sprint Backlog

El sprint backlog lo crea el equipo de desarrollo previo a la ejecución de un sprint (sprint planning) teniendo en cuenta las prioridades del product backlog y es el conjunto de item a desarrollar durante el sprint siguiente.

Incremento

Producto potencialmente entregable al final de cada Sprint.

Riesgos

Los riesgos son cualquier "evento" que altera la planificación original de objetivos y planes del proyecto.

Gestión de riesgos

La gestión de riesgo implica identificar los riesgos, sus efectos y tratar de reducir sus consecuencias. Esto no elimina los riesgos, pero maximiza la chance de éxito a pesar de los problemas.

Establecer planes de contingencia para todos los riesgos implica el incremento de costos. Debemos decidir cuáles riesgos serán mitigados en base a distintos criterios los cuales deben ser correctamente explicados y conocidos por todos los interesados e involucrados en el proyecto.

Para definir si se debe contar con un plan de mitigación de un riesgo se lo puede;

  1. Identificar los riesgos: determinar que aspectos del plan o del proyecto podrían cambiar.
  2. Estimar las consecuencias de esos riesgos: evaluar qué podría pasar si esos aspectos cambian.
  3. Elaborar planes para mitigar sus efectos: determinar cómo se puede proteger el proyecto ante los riesgos.
  4. Seguir el estado de los riesgos: su probabilidad de ocurrencia, la aparición de nuevos riesgos, etc.
  5. Informar a todos los interesados sobre los riesgos.

Para detectar cuál riesgo conviene mitigar primero se puede utilizar el "RPN"; en inglés, "Risk Priority Number".

$$ RPN = Prob. de Ocurrencia * Factor de Severidad * (1 – Prob. de Detección)$$

Siendo "Prob. de Ocurrencia": Probabilidad que ocurra ese evento; Factor de Severidad: Indicador del daño potencial que podría generar. (Valoración subjetiva de 0 a 1) y Probabilidad de Detección: la probabilidad de detectar la ocurrencia del evento con anticipación.

Gestión Económica

La gestión económica de un proyecto busca garantizar el uso eficiente de los recursos disponibles para cumplir con los objetivos dentro del alcance, tiempo y costo definidos. Es parte fundamental de la triple restricción: tiempo–alcance–costo.

La elaboración de presupuestos es una de las actividades claves en la planificación de proyectos, ya que permite anticipar recursos, justificar decisiones y evaluar la viabilidad.

Los costos se pueden clasificar en directo e indirectos

Costos directos

Los costos directos son aquellos que se pueden asociar directamente con un producto, servicio o entregable del proyecto. Por ejemplo el hardware, las licencias de uso, los materiales para la instalación, etc.

Costos indirectos

Los costos indirectos no se pueden asociar directamente a un entregable particular, pero son necesarios para que el proyecto se lleve a cabo. Por ejemplo, la mano de obra (programadores, instaladores), el mantenimiento preventivo, los costos de gestión o administración, etc.

Cost Breakdown Structure (CBS)

El Cost Breakdown Structure (CBS) es la organización jerárquica de los costos del proyecto, alineada a los entregables y actividades del Work Breakdown Structure (WBS).