TEST TBW TEMA 7

Se puede definir despliegue como transformación de su forma “empaquetada” (desarrollo) a un estado operativo. V. F.

Es necesario activar la web una vez que tenemos una versión de prueba suficientemente estable. V. F.

La gestión de proyecto sirve para el control de versiones. V. F.

En el control de versiones es necesario utilizar comentarios informativos pero no hay que adoptar esquemas de numeración. V. F.

El esquema de numeración de un proyecto será major.minor[.build]. V. F.

La versión alpha de un proyecto es la primera versión completa del programa, la cual es enviada a los verificadores para probarla. Habitualmente se asocia a versiones que satisfacen los requisitos básicos pero tienen errores. V. F.

La versión beta de un proyecto es la primera versión completa del producto que ya tiene características “congeladas”. Los desarrolladores lanzan un grupo de beta testers para una prueba de usuario. V. F.

La versión candidata definitiva (RC) de un proyecto es la versión candidata para el lanzamiento para publicarse como versión definitiva. Considerada muy estable y relativamente libre de errores. V. F.

La versión de disponibilidad general (RTM) de un proyecto es la versión final sin errores y con cambios de última hora. Versión comercializada. V. F.

La versión candidata definitiva (RC) de un proyecto es la versión final sin errores y con cambios de última hora. Versión comercializada. V. F.

La versión beta de un proyecto es la primera versión completa del programa, la cual es enviada a los verificadores para probarla. Habitualmente se asocia a versiones que satisfacen los requisitos básicos pero tienen errores. V. F.

La versión beta de un proyecto es considerada muy estable y relativamente libre de errores. V. F.

La BBDD de desarrollo y de producción son interdependientes. V. F.

La BBDD de desarrollo nunca estará cargada con datos reales. V. F.

La configuración de un proyecto en desarrollo debe ser igual a cuando el proyecto está en producción. V. F.

La configuración de un proyecto en producción debe mostrar mensajes de error / depuración y tener el caching deshabilitado. V. F.

En un repositorio se pueden tener varias versiones del proyecto en marcha. V. F.

Las bases de datos en producción pueden trabajar con datos de prueba o reales. V. F.

Una base de datos en producción debe ser segura, estar disponible y ser eficaz. V. F.

Un proyecto en proyección debe tener el caching activado, logs para monitorización, depuración activada, URL mapping y acceso a la BBDD. V. F.

Un repositorio en producción es igual que uno en desarrollo y se actualizará desde una versión release. V. F.

Un plan de despliegue indica todos los pasos necesarios para pasar a producción con garantías. Normalmente se tiene un único plan. V. F.

Un plan de contingencias empresarial es una estrategia sobre cómo responderá tu organización en caso de eventos importantes o críticos para tu negocio. V. F.

Un plan de contingencias no es importante, pero si ayuda a mitigar los riegos y volver a la normalidad lo antes posible. V. F.

El plan de contingencias facilita el plan de despliegue de un proyecto. V. F.

Un plan de contingencias debe identificar todos y cada uno de los riesgos que afectan al plan de despliegue. V. F.

Una vez hemos detectado los riesgos hay que evaluarlos solo según su gravedad. A mayor impacto, mayor gravedad. V. F.

Tras evaluar los riesgos hay que identificar cuales son los importantes y cuales los menos importantes. V. F.

Un riesgo alto/medio con probabilidad alta debe tener un plan sólido y mitigación de daños sólida. V. F.

Si un riesgo tiene gravedad alta y probabilidad media, lo más probable es que su efecto no sea severo. V. F.

Un riesgo de gravedad baja y probabilidad alta no necesita un plan sólido como uno de gravedad media y probabilidad baja ya que los daños no serán severos. V. F.

Si tenemos un riesgo de gravedad baja y probabilidad alta los planes sólidos deben enfocarse tanto en las partes interesadas como en las que no. V. F.

Si un riesgo es de gravedad media con media probabilidad no es necesario crear planes de contingencia. V. F.

Los únicos riesgos que no necesitan planes de contingencia son gravedad media y probabilidad baja , gravedad baja y probabilidad media o gravedad baja y probabilidad baja. V. F.

Una vez identificado los mayores riesgos, hay que elaborar un plan de contingencias y aprobarlo, es decir, los implicados deben conocer el plan, revisarlo y evaluar si el curso de acción es el correcto. V. F.

Los planes de contingencia siempre se deben mantener accesibles en todo momento con los implicados. Esto permitirá una actuación rápida y fluida. V. F.

Uno de los principales errores al desarrollar un plan de contingencias es centrarnos en planes B en vez del plan de contingencia principal. V. F.

Un plan de contingencia será probablemente no muy bueno si no se revisa una vez terminado. V. F.