Evaluación: El ciclo de vida de un producto digital

Una sola respuesta.

• Trasladar el impacto de una etapa a otra sin darse cuenta
• Que el fabricante declare menos emisiones de las reales
• Que se cuenten dos veces las emisiones de uso
• Ninguno: el ACV sólo mide la fase de fabricación

Trasladar el impacto de una etapa a otra sin darse cuentaSólo mirando el ciclo completo, de la cuna a la tumba, se sabe el balance. Una decisión es buena si reduce el impacto total, no sólo el de la fase que estás mirando.

Una sola respuesta.

• El despliegue y uso, porque se repite millones de veces
• El diseño y desarrollo, por los portátiles y la integración continua
• El mantenimiento, por las actualizaciones
• La retirada, por la migración de datos

El despliegue y uso, porque se repite millones de vecesCada petición, transferencia y procesado en el navegador se multiplica por usuarios, visitas y días en producción. Por eso lo que se decide al diseñar pesa tanto.

Sí o no.

• Sí
• No

NoSuele ser menor, pero no es cero: un pipeline que compila todo en cada commit o un entorno de preproducción encendido todo el fin de semana también suman.

Escribe el valor.

GB

8 GB (± 0,1)200 kB × 40.000 = 8.000.000 kB = 8 GB al día, casi 3 TB al año. Una decisión de cinco minutos multiplicada por cada visita.

Escribe el valor.

veces

288 veces12 ejecuciones por hora × 24 horas = 288 al día, más de cien mil al año. Cada decisión sobre esa tarea se multiplica por esa cifra.

Una sola respuesta.

• Al hardware que hay que fabricar porque la aplicación exige más potencia, aunque no sea tuyo
• Al hardware que usa el equipo de desarrollo
• Al hardware que se recicla al retirar la aplicación
• A los servidores que se encienden automáticamente con la carga

Al hardware que hay que fabricar porque la aplicación exige más potencia, aunque no sea tuyoSi tu aplicación exige un móvil potente o un servidor mayor, está provocando su fabricación. Es la vía por la que el software, que no pesa nada, acaba generando carbono incorporado.

Una sola respuesta.

• Toda la de sus servidores, copias y registros, y ninguno de sus beneficios
• Ninguna, porque sin peticiones los servidores no consumen
• Sólo la de las copias de seguridad
• Sólo la de su fase de desarrollo, que ya ocurrió

Toda la de sus servidores, copias y registros, y ninguno de sus beneficiosEs software zombi: consume electricidad y ocupa hardware sin aportar nada. Retirarlo es una decisión de sostenibilidad, y conviene planificarla desde el diseño.