Ingenieria de Sistemas aplicada a la Libertad Financiera II: Ciclo de Vida

Siguiendo con el objetivo de aplicar ideas del trabajo a lo cotidiano, tal y como se hizo en el anterior post (ver parte I: Introduccion), traemos hoy otro tema de la ingeniería de sistema: el ciclo de vida (life cycle) de un proyecto. En este caso, el proyecto va a ser nuestra búsqueda de la Libertad Financiera.

Ciclo de Vida

Todo lo creado por el ser humano tiene un ciclo de vida. Este ciclo de vida puede ser definido como una serie de pasos a través de los cuales atraviesa un proyecto.

Vamos a descomponer la vida de los proyectos en fases mas o menos independientes.

En cada fase del proyecto tendremos en cuenta las necesidades de los pasos siguientes, tomando las decisiones requeridas con antelación, consiguiendo eficiencia y manteniendo los costes bajo control.

El ciclo de vida depende mucho del proyecto, y en particular de las necesidades del cliente.

En este caso de la Libertad Financiera, el proyecto es uno solo, el proyecto de nuestra vida. Y el cliente es también muy especial, porque somos nosotros mismos.

Fases del Proyecto

El ciclo de vida es una visión dinámica del proyecto que ayuda a asegurar que el sistema consiga la funcionalidad requerida a final de su desarrollo.

Se muestran aquí seis fases genéricas, junto con los milestones que dan paso de una fase a otra. Con milestone nos referimos a momentos relevantes en la vida de los proyectos, entre fase y fase, que dan por terminada la fase anterior e inauguran la fase siguiente (ver explicación más adelante).

Aunque idealmente las fases se muestran como independientes, en la práctica se pueden solapar elementos de unas fases con otras.

SysEng_04_CicloDeVida

Fase A: Estudio de Concepto

La fase de concepto comienza con el reconocimiento de que hay una necesidad. Para estar atento a estas necesidades, las empresas suelen tener departamentos de investigación, que se encargan de mirar al futuro y asegurar la continuidad de la empresa a largo plazo.

El objetivo en esta fase es delimitar claramente el proyecto, trazando el hilo general de las subsiguientes fases. Todo para evitar volver atrás en fases posteriores y tener que redefinir el concepto del proyecto.

Es habitual empezar esta fase con la idea de “requerimientos de usuario”.

En estos estudios iniciales se analizan conceptos de alto nivel, identificando cuales son los riesgos y dificultades que se van a encontrar.

En esta fase :

  • Se identifica claramente el problema que se quiere resolver.
  • Se identifican claramente las posibles soluciones.
  • Se genera unas estimaciones de coste.
  • Se genera una planificación de tiempos (schedule).

Tiene que quedar claro que la fase de concepto es el comienzo de proyecto, no un fin en si mismo, por lo que muchos elementos están todavía por definir.

Si hay varias posibilidades para implementar el proyecto de diferentes maneras, en esta fase se estudian todas ellas y al final se elige la mejor.

El coste de esta fase es relativamente bajo comparado con el coste del proyecto entero, por ello es importante aprovechar y definir bien el proyecto al principio, para evitar volver atrás en el futuro, cuando el coste sería mayor.

El final de esta fase puede ser el MCR (Mission Concept Review). El MCR confirma los objetivos del proyecto, y que el concepto elegido es capaz de cumplir esos objetivos.

Caso práctico: Libertad Financiera

Queremos obtener unos ingresos que complementen nuestro salario, idealmente que lo igualen, como si fuera una pensión.

Queremos que sean ingresos mas o menos pasivos, fáciles de gestionar, eficientes en coste. Estas son algunas posibilidades que analizamos durante la fase A “estudio de concepto”:

  • Comprar piso para alquilar: Requiere un cierto trabajo (buscar inquilinos, reparaciones), es caro (impuestos, notario), si se compra con hipoteca requiere apalancamiento (y por lo tanto un cierto riesgo de que algo vaya mal con el crédito).
  • Comprar acciones: Requiere un cierto trabajo para elegir las empresas, hay que pagar impuestos por los dividendos.
  • Comprar fondo de inversión: Fácil, porque una vez que se elige un buen fondo, no hay que hacer nada en particular. Permite acumular los dividendos y retrasar el pago de impuestos. Los fondos pueden ser más caros que comprar las acciones directamente.
  • Comprar fondo de inversión pasivo, es como un fondo de inversión convencional, pero más barato y típicamente con mayor diversificación. Y estadísticamente un fondo pasivo da mejores rendimientos que fondos convencionales equiparables.
  • Comprar cartera de fondos pasivos, formada por fondos de inversión pasivos, cuyos componentes estén descorrelacionados. Rebalancear periódicamente. Se consigue así una relativamente baja volatilidad con un rendimiento razonable. Es muy barata.

Tras analizar los pros y los contras, al final de la fase A “definición de concepto” elegimos invertir en una cartera de inversión con fondos pasivo. Esta es la decisión que se toma en el MCR.

Aún no conocemos los detalles del proyecto, pero sí que hemos delimitado la solución.

Fase B: Diseño Preliminar

En esta fase se diseña un sistema que cumple con los requisitos de usuario y que puede ser producido, utilizado, mantenido, y finalmente retirado.

Los requerimientos de los usuarios (de alto nivel, necesidades de los usuarios, definidas en la fase A) se utilizan para definir los requerimientos de sistema (de bajo nivel, detalles técnicos de la implementación). Al mismo tiempo, estos requerimientos del sistema lo que hacen es servir de guía para diseñar la arquitectura del sistema que va a proporcionar el servicio.

Se especifican las interfaces entre los diferentes subsistemas dentro del sistema general (documentado en ICDs, Interface Control Documents).

En esta fase se planifican las actividades de V&V (Verification and Validation). Se planifica con antelación, sin llegar a llevarse a cabo. El objetivo es estar seguro de que llegado el momento todo el equipo y los recursos estarán disponibles.

Por cierto, un comentario sobre la diferencia entre Verificación y Validación:

  • Verificación: Evaluación de si un producto o servicio cumple con la regulación, requerimientos, especificaciones, o cualquier otra condición. Suele ser un proceso interno, llevado a cabo por miembros de un proyecto.
  • Validación : Confirmación de que un producto o servicio cumple con las necesidades de sus usuarios. Suele ser un proceso externo a la empresa, porque requiere involucrar a los usuarios.

Al final de esta fase se produce el milestone PDR (Preliminary Design Review), donde se confirma que el proyecto avanza en la dirección apropiada.

Fase C: Diseño Final

La fase de diseño continua con a fase C. El milestone final es el CDR (Critical Design Review).

Ejemplo Práctico: Libertad Financiera

OK, vamos a invertir en una cartera pasiva. Va a tener estas características.

Comprar ETFs en vez de fondos convencionales. Razón: Obtienen mejores rendimientos y son más transparentes.

Que den dividendos en vez de acumular (esto nos viene bien a nosotros, para otras personas seguramente sea mejor acumular).

Siguiendo Bogleheads, 60% acciones y 40% bonos (es solo un ejemplo).

El 60% de acciones compuesto por VWRL (Vanguard FTSE All-World UCITS ETF).

El 40% de bonos compuesto por EUNH (iShares Core EUR Government Bond UCITS ETF).

Miramos los diferentes brokers. Degiro está bien y nos sirve.

Ummm… muy bien. Al final de esta fase, en el CDR, tenemos todo bien definido. Ya sabemos lo que queremos hacer, ahora hay que hacerlo realidad.

Fase D: Integración del Sistema

En esta fase es cuando el sistema se implementa.

Modificaciones pueden ser necesarias para resolver problemas encontrados. Es habitual crear AR (Anomaly Reports) indicando los problemas para que sean resueltos.

La resolución de estos ARs puede requerir modificaciones en el sistema. Si es así, habrá que estudiar el impacto en el sistema. Si el cambio es aceptado, posteriormente habrá que volver a verificar y validar el sistema.

Al final de esta fase el sistema es entregado al usuario.

Se hace el commissioning, comprobando que el sistema se comporta como se esperaba durante operaciones normales.

El milestone final es el ORR (Operational Readiness Review)

Abrimos cuenta en Degiro. Transferimos dinero por primera vez. Hacemos una primera compra de VWRL y EUNH. Tras unos días los activos comprados aparecen disponibles en la cuenta. Pasa un año, hacemos la declaración de hacienda con normalidad. OK, todo parece funcionar bien.

Fase E: Operaciones

Durante esta fase es cuando el sistema es operado en su entorno de trabajo.

Si hay problemas, se crean ARs como en la fase anterior.

Si durante esta fase se requieren grandes cambios en el sistema, la actualización puede ser definida como un proyecto por si mismo.

Cada pocos meses compramos un bloque de acciones de uno de los ETFs. O bien VWRL o EUNH, lo que corresponda para mantener las proporciones, según lo estipulado en la fase de diseño. Repetir así durante años. Tan aburrido como ver secarse la pintura en la pared.

Fase F: Finalización

Ahora es cuando el sistema deja de estar operativo y se retira de funcionamiento.

Esto puede parecer innecesario, y quizás lo fue en el pasado. Sin embargo regulaciones modernas hacen que el desarrollador sea responsable de la eliminación del producto o servicio al acabar su vida útil. Ejemplos son el reciclado de lavadoras que no funcionan, desplazar satélites a órbitas donde no molesten, o desmontar centrales nucleares.

Ha llegado el momento de hacer testamento. Hay que dejar por escrito qué va a suceder cuando ya no estemos por aquí. Habrá que apuntar qué cuentas existen, nombres de usuario, contraseñas; todo para hacerle fácil a los que vengan después.

Decisiones

A lo largo de la vida del proyecto se han ido alcanzando unos momentos especiales, a los que podemos llamar “hitos” (o en inglés milestones). Estos  indican que se ha conseguido algo reseñable. Un tipo de estos hitos serían las revisiones (o en inglés decision gates, o reviews), porque implican toma de decisiones.

Ejemplos de milestones son:

  • MCR (Mission Concept Review), para pasar de fase A (concepto) a la fase B (diseño preliminar).
  • PDR (Preliminary Design Review), para pasar de fase B (diseño preliminar) a fase C (diseño final).
  • CDR (Critical Design Review), para pasar de fase C (diseño final) a fase D (integración).
  • ORR (Operational Readiness Review), para pasar de fase D (integración) a fase E (operaciones).

Se pueden definir más milestones si el proyecto es muy grande y transcurre demasiado tiempo entre un milestone y otro. O con otro acrónimos si es que fueran más apropiados. A fin de cuentas, el objetivo con estas reviews no es mas que conocer el estado del proyecto y evitar sorpresas.

En cada una de estas revisiones se hacen preguntas que han de ser respondidas satisfactoriamente. Por ejemplo:

  • ¿Cumplirá el resultado del proyecto con las necesidades del cliente?
  • ¿Están los costes dentro del presupuesto?
  • ¿Va a terminar dentro de los plazos necesarios?

En una de estas revisiones (reviews) se busca que:

  • Los desarrollos realizados vayan a poder verificarse y validarse (V&V). Quizás no en esta revisión, pero nada deberá obstaculizar que se haga más adelante.
  • Asegurar que el siguiente paso se pueda conseguir, de forma que los riesgos estén bajo control. Si es un proyecto único que nunca se ha hecho antes, siempre habrá incertidumbre, pero ha de poder justificarse que el objetivo es alcanzable.
  • Fomentar el trabajo conjunto entre cliente y proveedor. Una revisión es un momento en el que ambos ponen en común el estado del proyecto.
  • Sincronizar las actividades del proyecto. Al fin y al cabo, si el proyecto es grande, habrá múltiples subsistemas que tendrán que implementarse en paralelo. Todos ellos deberán llegar a la revisión en el mismo estado de desarrollo.

Las decisiones que se toman en una revisión serán como estas:

  • Aceptable: Seguir al siguiente estado del proyecto.
  • Aceptable con reservas: Proceder al siguiente estado del proyecto, pero con la condición de resolver los (pequeños) problemas encontrados, documentados en “acciones” (action items).
  • No aceptable, seguir en el mismo paso: Continuar en este estado hasta que los problemas se resuelvan.
  • No aceptable, regresar al paso anterior: Una mala decisión en una revisión anterior ha llevado al proyecto a un estado demasiado avanzado, a pesar de que no se pueden conseguir los requerimientos.
  • No aceptable, paralizar el proyecto: Así hasta que se resuelvan los problemas.
  • Insalvable: Terminar el proyecto, ha ido tan mal que el proyecto ha de ser cancelado completamente.

Bien, ya hemos estudiado el ciclo de vida de un proyecto, aplicado al caso de la Libertad Financiera. Ahora podríamos preocuparnos por otros aspectos del proyecto. Por ejemplo, ¿cómo definir los requisitos del sistema? Lo veremos en el próximo post.

Autor: willyfog

Turista laboral por la Unión Europea. Por favor que dure. Lo que veo, leo o me cuentan no lo suelo encontrar en español, así que me gusta escribirlo por aquí.

2 comentarios en “Ingenieria de Sistemas aplicada a la Libertad Financiera II: Ciclo de Vida”

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s