Simulador EGEL Informática

🚀 Implementación de aplicaciones informáticas

Implementación de aplicaciones informáticas

La implementación abarca la instalación, configuración, pruebas, migración y puesta en operación de una aplicación, junto con su mantenimiento posterior. El proceso se enmarca en el ciclo de vida definido por ISO/IEC/IEEE 12207 (edición 2017), que incluye el Proceso de Mantenimiento de software entre los procesos técnicos.

Pruebas. ISTQB e ISO/IEC/IEEE 29119 reconocen cuatro niveles de prueba: componente (unitaria), integración, sistema y aceptación. La técnica de caja blanca examina la estructura interna del código, mientras que la de caja negra evalúa el comportamiento externo sin conocer la implementación. Las pruebas de aceptación validan que el sistema cumple los requisitos del usuario; según ISTQB incluyen aceptación de usuario (UAT), aceptación operacional (OAT), aceptación contractual y regulatoria, además de pruebas alfa y beta. La prueba de regresión reejecuta casos tras una modificación para confirmar que no se introdujeron defectos ni se expusieron defectos en áreas no modificadas, y la prueba de humo (smoke test) verifica la funcionalidad principal antes de iniciar pruebas más detalladas.

Migración y puesta en operación. La migración de datos suele apoyarse en el proceso ETL, con tres fases: extracción, transformación y carga (Extract, Transform, Load). Kendall & Kendall describen cuatro estrategias de conversión:

El despliegue azul-verde (blue-green) usa dos entornos de producción idénticos: uno atiende el tráfico en vivo mientras el otro recibe la nueva versión; el cambio de rutas entre ellos reduce el tiempo de inactividad y facilita el rollback. La capacitación de usuarios finales, la documentación técnica y de usuario y la gestión del cambio organizacional acompañan la puesta en marcha para asegurar la adopción.

Mantenimiento. ISO/IEC 14764 (equivalente a IEEE Std 14764) clasifica el mantenimiento posterior a la entrega en cuatro categorías, agrupadas en dos clases —correcciones (correctivo y preventivo) y mejoras (adaptativo y perfectivo)—: el correctivo corrige defectos descubiertos; el adaptativo mantiene el software utilizable ante un entorno cambiado o cambiante; el perfectivo mejora el rendimiento o la mantenibilidad; y el preventivo detecta y corrige fallas latentes antes de que se conviertan en fallas efectivas. En ISO/IEC 25010:2011 (SQuaRE), la mantenibilidad es una de las ocho características de calidad y se descompone en cinco subcaracterísticas: modularidad, reusabilidad, analizabilidad, modificabilidad y testeabilidad.

Practica el banco completo y haz simulacros gratis

Preguntas de muestra (35)

1. En la puesta en operación de un sistema de información, la estrategia de conversión directa (también llamada 'big bang') consiste en:

  1. Sustituir por completo el sistema anterior por el nuevo en una fecha determinada, sin que ambos operen al mismo tiempo.
  2. Operar el sistema anterior y el nuevo de manera simultánea durante un periodo para comparar resultados.
  3. Implementar el nuevo sistema en una sola sucursal o departamento antes de extenderlo al resto de la organización.
  4. Sustituir el sistema anterior de manera gradual, módulo por módulo, hasta cubrir toda la funcionalidad.

La conversión directa reemplaza el sistema anterior por el nuevo sin operación simultánea, a diferencia de la paralela (ambos operan a la vez), la piloto (un solo sitio primero) o la de fases (módulo por módulo). (Kendall & Kendall, Systems Analysis and Design — estrategias de conversión de sistemas.)

2. Una cadena de farmacias con 40 sucursales va a reemplazar su sistema de punto de venta. Para minimizar el riesgo de una falla generalizada, la gerencia decide implementar el nuevo sistema primero en una sola sucursal, evaluar su desempeño durante varias semanas y, solo si los resultados son satisfactorios, extenderlo al resto de las sucursales. Esta forma de puesta en operación corresponde a la estrategia de conversión:

  1. Por fases
  2. Piloto
  3. Directa
  4. En paralelo

Probar primero en un solo sitio antes de extender a los demás define la estrategia piloto; difiere de la conversión por fases, que despliega módulos o funciones sucesivas en toda la organización. (Kendall & Kendall, Systems Analysis and Design — estrategia de conversión piloto.)

3. En un banco, el área de sistemas decide que, durante los primeros dos meses de operación del nuevo sistema de créditos, el personal capture las mismas transacciones tanto en el sistema anterior como en el nuevo, comparando los resultados de ambos antes de dar de baja el sistema anterior. Esta estrategia de conversión se conoce como:

  1. Conversión directa
  2. Conversión piloto
  3. Conversión en paralelo
  4. Conversión por fases

Operar ambos sistemas de manera simultánea para contrastar resultados antes de retirar el anterior define la conversión en paralelo, distinta de la directa, que no mantiene ambos sistemas activos a la vez. (Kendall & Kendall, Systems Analysis and Design — estrategia de conversión en paralelo.)

4. De las siguientes técnicas de puesta en operación de un sistema, ¿cuál NO corresponde a una de las cuatro estrategias clásicas de conversión?

  1. Sustitución directa del sistema completo en una fecha única.
  2. Implementación gradual del sistema por fases o módulos.
  3. Prueba piloto del sistema en un grupo reducido de usuarios.
  4. Reversión automática del sistema a una versión anterior (rollback).

Las cuatro estrategias clásicas de conversión son directa, paralela, piloto y por fases; el rollback es una técnica de reversión usada en despliegues (por ejemplo, en blue-green), pero no forma parte de esa clasificación. (Kendall & Kendall, estrategias de conversión; Martin Fowler, 'BlueGreenDeployment' (rollback).)

5. El despliegue azul-verde (blue-green deployment) consiste en mantener:

  1. Dos entornos de producción idénticos, donde uno atiende el tráfico en vivo mientras el otro recibe la nueva versión.
  2. Un entorno de prueba y un entorno de desarrollo que se sincronizan antes de cada versión.
  3. Un solo entorno de producción que se actualiza por módulos de manera sucesiva.
  4. Tres entornos de producción que reciben el tráfico de manera rotativa cada semana.

El blue-green deployment usa dos entornos de producción idénticos; el cambio de enrutamiento entre ambos reduce el tiempo de inactividad y facilita el rollback. (Martin Fowler, 'BlueGreenDeployment' (martinfowler.com/bliki/BlueGreenDeployment.html).)

6. Una empresa de comercio electrónico necesita publicar una nueva versión de su aplicación sin interrumpir el servicio a los clientes y, en caso de detectar errores graves, poder revertir el cambio de manera casi inmediata. ¿Cuál estrategia de despliegue es la más adecuada para este requerimiento?

  1. Conversión por fases, liberando un módulo nuevo cada mes.
  2. Despliegue azul-verde, cambiando el enrutamiento del tráfico entre los dos entornos.
  3. Conversión piloto, limitada a un grupo reducido de usuarios.
  4. Conversión directa, sustituyendo el sistema anterior en una sola fecha límite.

El requerimiento de mínimo tiempo de inactividad y reversión casi inmediata corresponde al despliegue azul-verde, que permite regresar el tráfico al entorno anterior con solo cambiar el enrutamiento. (Martin Fowler, 'BlueGreenDeployment'.)

7. En un proyecto de migración de datos previo a la puesta en operación de un nuevo sistema, el proceso ETL sigue el siguiente orden de fases:

  1. Carga, extracción y transformación de los datos.
  2. Transformación, extracción y validación de los datos.
  3. Extracción, transformación y carga de los datos.
  4. Extracción, carga y depuración de los datos.

ETL significa Extract-Transform-Load: primero se extraen los datos de la fuente, luego se transforman y por último se cargan al sistema destino. (Kimball & Caserta, The Data Warehouse ETL Toolkit.)

8. De acuerdo con el modelo de evaluación de la capacitación de Donald Kirkpatrick, el primer nivel, llamado 'reacción', mide:

  1. El grado en que los participantes aplican lo aprendido en su trabajo diario.
  2. Los resultados organizacionales, como productividad o reducción de errores, atribuibles a la capacitación.
  3. Los conocimientos y habilidades que los participantes adquirieron durante el curso.
  4. La satisfacción y la percepción de los participantes respecto al curso recibido.

El nivel 1 (reacción) del modelo de Kirkpatrick mide la satisfacción de los participantes con la capacitación; el aprendizaje, la conducta y los resultados corresponden a los niveles 2, 3 y 4. (D. Kirkpatrick, Evaluating Training Programs — modelo de cuatro niveles.)

9. Tres meses después de un curso de capacitación sobre el nuevo sistema de nómina, el área de recursos humanos observa si los usuarios efectivamente aplican en su trabajo diario los procedimientos enseñados. Esta evaluación corresponde al nivel del modelo de Kirkpatrick llamado:

  1. Conducta (comportamiento)
  2. Resultados
  3. Reacción
  4. Aprendizaje

Observar si lo aprendido se aplica en el puesto de trabajo corresponde al nivel 3 (conducta); el nivel de resultados mide un impacto organizacional más amplio, como productividad o costos. (D. Kirkpatrick, Evaluating Training Programs.)

10. En el modelo de diseño instruccional ADDIE, utilizado para planear la capacitación de usuarios finales, la primera etapa consiste en:

  1. Evaluar los resultados obtenidos después de impartir el curso.
  2. Analizar las necesidades de capacitación y las características de los usuarios.
  3. Desarrollar los materiales, contenidos y ejercicios prácticos del curso.
  4. Diseñar los objetivos y la estructura general del curso.

ADDIE inicia con la etapa de Análisis (de necesidades y audiencia), seguida de Diseño, Desarrollo, Implementación y Evaluación. (Modelo ADDIE de diseño instruccional (Analysis, Design, Development, Implementation, Evaluation).)

11. Antes de definir el temario y los materiales del curso sobre el nuevo sistema de facturación, el equipo de implementación entrevista a los futuros usuarios para identificar qué conocimientos ya tienen y qué brechas de habilidades deben cubrirse. Esta actividad corresponde a la etapa de ADDIE denominada:

  1. Implementación
  2. Desarrollo
  3. Análisis
  4. Diseño

Identificar brechas de conocimiento y necesidades de los usuarios antes de diseñar el curso es propio de la etapa de Análisis del modelo ADDIE. (Modelo ADDIE de diseño instruccional.)

12. Para capacitar a 300 empleados de una empresa en un nuevo sistema, el equipo de proyecto capacita primero a un grupo reducido de empleados con buen dominio del proceso de negocio, quienes después replican la capacitación a sus compañeros de área. Esta práctica se conoce como:

  1. Modelo de certificación externa obligatoria previa.
  2. Modelo de aprendizaje autodirigido sin instructor.
  3. Modelo de evaluación por niveles de Kirkpatrick.
  4. Modelo de usuarios clave o "train the trainer".

Formar primero a un grupo reducido de usuarios expertos que luego capacitan a sus compañeros es el esquema de usuarios clave o 'train the trainer', común en implementaciones de sistemas empresariales. (Práctica de gestión de proyectos de TI — esquema de usuarios clave / train-the-trainer.)

13. Una buena práctica reconocida en la planeación de la capacitación de usuarios finales es programar las sesiones:

  1. Lo más cerca posible de la fecha de puesta en operación del sistema.
  2. En una sola sesión intensiva de varios días, sin importar la fecha de arranque.
  3. Después de que el sistema ya está en operación, para capacitar con casos reales.
  4. Varios meses antes de la puesta en operación, para dar tiempo de asimilar el contenido.

Programar la capacitación cerca de la fecha de arranque reduce el olvido del contenido antes de que los usuarios lo apliquen; capacitar con mucha anticipación incrementa la curva de olvido. (Práctica de gestión de proyectos de TI — planeación de la capacitación previa al go-live.)

14. Un mes después de implementado un nuevo sistema de inventarios, los usuarios cometen errores frecuentes porque olvidaron varios pasos aprendidos en la capacitación inicial y no cuentan con material de consulta rápida. ¿Cuál acción corresponde de manera más directa a subsanar esta causa raíz?

  1. Posponer la evaluación de reacción de los participantes al curso.
  2. Elaborar y distribuir guías rápidas (job aids) como material de refuerzo.
  3. Aumentar el número de usuarios clave que replican la capacitación.
  4. Repetir el curso completo de capacitación inicial sin modificaciones.

Cuando la causa es el olvido de pasos por falta de material de referencia, la solución directa es reforzar con guías rápidas (job aids), no repetir el curso completo ni otras acciones que no atacan la causa raíz. (Práctica de gestión de la capacitación de usuarios finales — materiales de refuerzo (job aids).)

15. El modelo de cambio organizacional de Kurt Lewin propone que todo proceso de cambio debe pasar por tres etapas, comenzando por:

  1. Consolidación, para anclar los resultados obtenidos en la organización.
  2. Cambio, para introducir directamente las nuevas prácticas de trabajo.
  3. Descongelamiento, para reducir las fuerzas que mantienen el comportamiento actual.
  4. Recongelamiento, para estabilizar el nuevo comportamiento en la cultura.

El modelo de Lewin inicia con el descongelamiento (reducir la resistencia al comportamiento actual), seguido de cambio y recongelamiento; 'consolidación' no es una de sus tres etapas. (K. Lewin — modelo de cambio de tres etapas (unfreezing-changing-refreezing).)

16. Al iniciar un proyecto de implementación de un nuevo sistema, el director general comunica a toda la organización cifras de pérdidas y riesgos si no se moderniza el sistema actual, buscando que el personal perciba la necesidad inmediata de actuar. De acuerdo con el modelo de ocho pasos de Kotter, esta acción corresponde al paso de:

  1. Generar triunfos a corto plazo visibles para todos.
  2. Anclar los nuevos enfoques en la cultura organizacional.
  3. Formar una coalición conductora con poder para liderar el cambio.
  4. Crear un sentido de urgencia en la organización.

Comunicar riesgos y la necesidad de actuar de inmediato corresponde al primer paso del modelo de Kotter, 'crear un sentido de urgencia'; formar la coalición ocurre en un paso posterior. (J. Kotter, Leading Change — modelo de ocho pasos para el cambio organizacional.)

17. En el modelo de ocho pasos de John Kotter para liderar el cambio organizacional, después de crear una visión de cambio, el siguiente paso consiste en:

  1. Comunicar esa visión ampliamente a toda la organización.
  2. Anclar los nuevos enfoques en la cultura organizacional.
  3. Formar la coalición que guiará el proceso.
  4. Consolidar las mejoras y generar más cambio.

Tras crear la visión, Kotter señala como paso siguiente comunicarla ampliamente; formar la coalición es un paso anterior, y anclar o consolidar son pasos posteriores. (J. Kotter, Leading Change — modelo de ocho pasos.)

18. Según el modelo ADKAR, los empleados de un área entienden por qué es necesario el cambio y saben exactamente qué deben hacer de manera distinta, pero se resisten porque preferirían seguir trabajando como antes. ¿Cuál elemento del modelo ADKAR está fallando principalmente en este caso?

  1. Conciencia de la necesidad del cambio.
  2. Deseo de participar y apoyar el cambio.
  3. Habilidad para implementar el cambio en la práctica.
  4. Conocimiento de cómo llevar a cabo el cambio.

Entender la necesidad del cambio (conciencia) y saber qué hacer (conocimiento) ya están presentes; lo que falta es el deseo personal de apoyar el cambio, segundo elemento del modelo ADKAR. (Prosci — modelo ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement).)

19. ¿Cuál de las siguientes acciones NO forma parte de los ocho pasos del modelo de cambio organizacional de John Kotter?

  1. Generar triunfos a corto plazo que sean visibles para toda la organización.
  2. Anclar los nuevos enfoques en la cultura de la organización.
  3. Reducir el presupuesto de todas las áreas para financiar el proyecto de cambio.
  4. Formar una coalición conductora con suficiente poder para liderar el esfuerzo.

Kotter no incluye recortar presupuestos como paso de su modelo; sus ocho pasos van desde crear urgencia hasta anclar los cambios en la cultura, pasando por formar la coalición y generar triunfos a corto plazo. (J. Kotter, Leading Change — modelo de ocho pasos.)

20. En la gestión del cambio organizacional durante la implementación de sistemas, el 'agente de cambio' cumple principalmente la función de:

  1. Certificar que el sistema cumple con los requerimientos funcionales especificados.
  2. Programar la infraestructura técnica donde se instalará el nuevo sistema.
  3. Aprobar el presupuesto total asignado al proyecto de implementación.
  4. Facilitar la comunicación y el seguimiento a la adopción del cambio.

El agente de cambio actúa como enlace entre el proyecto y los usuarios, facilitando la comunicación y el seguimiento de la adopción; las demás funciones corresponden a otros roles del proyecto. (Prosci — rol del agente de cambio en proyectos de implementación de sistemas.)

21. En un proyecto de implementación de sistemas, el patrocinador ejecutivo (sponsor) tiene como responsabilidad principal:

  1. Respaldar visiblemente el proyecto y asignar los recursos necesarios para su éxito.
  2. Elaborar los manuales de usuario y las guías rápidas de referencia.
  3. Configurar los parámetros técnicos del sistema en el entorno de producción.
  4. Capacitar directamente a los usuarios finales en el uso del nuevo sistema.

El patrocinador ejecutivo respalda el proyecto ante la organización y asigna los recursos necesarios; la capacitación, la configuración técnica y los manuales corresponden a otros roles del equipo. (Prosci / gestión de proyectos — rol del patrocinador ejecutivo en el cambio organizacional.)

22. Durante la fase de pruebas de un sistema, un analista diseña casos de prueba a partir de las especificaciones funcionales del sistema, sin considerar cómo está construido internamente el código. ¿Qué estrategia de prueba está aplicando?

  1. Prueba de regresión
  2. Prueba de caja negra
  3. Prueba de aceptación
  4. Prueba de caja blanca

La prueba de caja negra parte únicamente de las especificaciones funcionales, sin conocer la estructura interna del código; la aceptación también se basa en especificaciones, pero es un nivel específico de prueba, no esta técnica general de diseño de casos. (ISTQB Foundation Level Syllabus — técnicas de prueba basadas en especificación (caja negra))

23. Un programador diseña casos de prueba analizando el código fuente del módulo, con el objetivo de ejercitar rutas y decisiones específicas dentro de la lógica del programa. ¿Qué tipo de estrategia de prueba corresponde a esta descripción?

  1. Prueba de aceptación
  2. Prueba de caja blanca
  3. Prueba de regresión
  4. Prueba de caja negra

La prueba de caja blanca se basa en el conocimiento de la estructura interna del código para diseñar casos que ejerciten rutas y decisiones específicas; la caja negra ignora esa estructura, y la aceptación y la regresión no se definen por el análisis del código fuente. (ISTQB Foundation Level Syllabus — técnicas de prueba basadas en la estructura (caja blanca))

24. Para reducir el número de casos de prueba de un campo que acepta edades de 18 a 65 años, un analista agrupa las entradas posibles en subconjuntos (menores de 18, de 18 a 65, mayores de 65) y selecciona un valor representativo de cada uno. ¿Qué técnica de prueba de caja negra está utilizando?

  1. Cobertura de decisión
  2. Análisis de caminos básicos
  3. Partición de equivalencia
  4. Cobertura de sentencias

La partición de equivalencia divide el dominio de entrada en clases donde se espera un comportamiento similar y prueba un valor por clase; la cobertura de decisión, la de sentencias y el análisis de caminos básicos son técnicas de caja blanca basadas en la estructura del código. (ISTQB Foundation Level Syllabus — partición de equivalencia (caja negra))

25. Un equipo de pruebas exige que, para cada instrucción condicional (if) del código, se ejecute al menos una vez la rama verdadera y al menos una vez la rama falsa, sin importar cuántas sentencias contengan. ¿Qué criterio de cobertura de caja blanca describe esta exigencia?

  1. Análisis de valores límite
  2. Cobertura de decisión
  3. Partición de equivalencia
  4. Cobertura de sentencias

La cobertura de decisión (también llamada cobertura de rama) exige ejercitar cada resultado posible, verdadero y falso, de cada condición; la cobertura de sentencias solo exige que cada línea de código se ejecute al menos una vez, sin importar el resultado de la condición. (ISTQB Foundation Level Syllabus — niveles de cobertura de caja blanca (sentencias y decisión))

26. Un módulo contiene una única instrucción IF sin cláusula ELSE que, si la condición es verdadera, invoca a una función de validación; después de la instrucción IF el módulo continúa con otras sentencias. Se diseña un único caso de prueba que hace que la condición resulte siempre verdadera. ¿Qué nivel de cobertura se alcanza con ese caso de prueba?

  1. 100% de cobertura de decisión, pero no 100% de cobertura de sentencias
  2. 0% de cobertura de sentencias y 0% de cobertura de decisión
  3. 100% de cobertura de sentencias y 100% de cobertura de decisión
  4. 100% de cobertura de sentencias, pero no 100% de cobertura de decisión

Al ejecutarse siempre la rama verdadera se recorren todas las sentencias del módulo (100% de cobertura de sentencias), pero la rama falsa nunca se ejercita, por lo que no se alcanza el 100% de cobertura de decisión; es el ejemplo clásico de que la cobertura de sentencias es más débil que la de decisión. (ISTQB Foundation Level Syllabus — relación entre cobertura de sentencias y cobertura de decisión)

27. Antes de autorizar el paso a producción de un nuevo sistema, el área de administración de infraestructura verifica los procedimientos de respaldo, recuperación ante fallas, instalación y mantenimiento del sistema, sin evaluar si sus funciones cumplen los requisitos del negocio. ¿Qué tipo de prueba de aceptación están realizando?

  1. Prueba de aceptación de usuario
  2. Prueba de aceptación contractual
  3. Prueba de aceptación operacional
  4. Prueba de aceptación regulatoria

La prueba de aceptación operacional (OAT) la realiza el personal de operaciones para verificar aspectos no funcionales como respaldo, recuperación, instalación y mantenibilidad; la prueba de aceptación de usuario valida en cambio que el sistema cumpla las necesidades del negocio. (ISTQB Foundation Level Syllabus — tipos de prueba de aceptación (OAT))

28. ¿Cuál de las siguientes afirmaciones distingue correctamente la prueba beta de la prueba alfa, de acuerdo con el lugar donde se realiza y la presencia del equipo desarrollador?

  1. La prueba alfa se realiza en el sitio del cliente y sin el equipo desarrollador presente
  2. La prueba beta se realiza en el sitio del desarrollador y con su equipo presente
  3. La prueba beta se realiza en el sitio del cliente y sin el equipo desarrollador presente
  4. La prueba alfa se realiza fuera de la organización y sin ningún tipo de supervisión

La prueba beta se lleva a cabo en las instalaciones de clientes potenciales, sin la presencia del equipo desarrollador; la prueba alfa se realiza en el sitio de la organización desarrolladora, generalmente con acompañamiento del equipo de desarrollo. (ISTQB Foundation Level Syllabus — pruebas alfa y beta)

29. Una empresa debe demostrar, antes de recibir el pago final por un sistema desarrollado a la medida, que este cumple las cláusulas de cumplimiento pactadas en el contrato de desarrollo. ¿Qué tipo de prueba de aceptación corresponde a esta verificación?

  1. Prueba de aceptación operacional
  2. Prueba de aceptación regulatoria
  3. Prueba de aceptación de usuario
  4. Prueba de aceptación contractual

La prueba de aceptación contractual verifica que el sistema cumple los criterios establecidos en un contrato de desarrollo, a menudo como condición para el pago; difiere de la prueba de aceptación de usuario, centrada en validar la utilidad del sistema para las tareas del negocio. (ISTQB Foundation Level Syllabus — tipos de prueba de aceptación (contractual y de regulación))

30. Una organización decide suspender por completo el uso del sistema anterior en una fecha establecida y, a partir de ese mismo día, operar únicamente con el sistema nuevo, sin ejecutar ambos sistemas de forma simultánea. ¿Qué estrategia de puesta en operación está siguiendo?

  1. Conversión directa
  2. Conversión por fases
  3. Conversión piloto
  4. Conversión en paralelo

La conversión directa (o 'big bang') reemplaza de golpe el sistema anterior por el nuevo en una fecha determinada, sin un periodo de operación simultánea entre ambos, lo que reduce el costo pero incrementa el riesgo si el nuevo sistema falla. (Kendall & Kendall, Systems Analysis and Design — estrategias de conversión)

31. Durante dos meses, una empresa opera al mismo tiempo su sistema de nómina anterior y el nuevo sistema, procesando la misma información en ambos y comparando los resultados antes de retirar definitivamente el sistema anterior. ¿Qué estrategia de puesta en operación describe este procedimiento?

  1. Conversión piloto
  2. Conversión en paralelo
  3. Conversión directa
  4. Conversión por fases

La conversión en paralelo mantiene funcionando simultáneamente el sistema anterior y el nuevo durante un periodo, comparando sus resultados para verificar la confiabilidad del nuevo sistema antes de retirar el anterior, aunque implica un costo operativo mayor. (Kendall & Kendall, Systems Analysis and Design — estrategias de conversión)

32. Antes de implementar un nuevo sistema de ventas en las 40 sucursales de una cadena comercial, la empresa lo instala por completo únicamente en una sucursal representativa, evalúa los resultados durante tres meses y, si son satisfactorios, lo extiende al resto de las sucursales. ¿Qué estrategia de puesta en operación está aplicando?

  1. Conversión por fases
  2. Conversión en paralelo
  3. Conversión piloto
  4. Conversión directa

La conversión piloto instala el sistema completo en una sola unidad organizacional representativa para evaluarlo antes de extenderlo al resto; se distingue de la conversión por fases, que introduce el sistema gradualmente por módulos o funciones en toda la organización. (Kendall & Kendall, Systems Analysis and Design — estrategias de conversión)

33. Un hospital no puede suspender la operación del sistema anterior ni cuenta con presupuesto para operar dos sistemas completos de forma simultánea, por lo que decide implementar el nuevo sistema de información un módulo a la vez (primero admisión, después farmacia, después facturación) en toda la institución. ¿Qué estrategia de puesta en operación resulta más adecuada para esta situación?

  1. Conversión en paralelo
  2. Conversión por fases
  3. Conversión directa
  4. Conversión piloto

La conversión por fases introduce el sistema nuevo módulo por módulo o función por función en toda la organización, lo que reduce el riesgo sin requerir operar dos sistemas completos en paralelo ni contar con una unidad piloto separada. (Kendall & Kendall, Systems Analysis and Design — estrategias de conversión)

34. Una institución financiera con presencia en varias regiones necesita reducir al mínimo el riesgo de una falla generalizada, no dispone de recursos para mantener dos sistemas completos operando a la vez en todas las regiones, y quiere validar el nuevo sistema en condiciones reales de operación en una región antes de comprometer al resto de la institución. ¿Qué estrategia de puesta en operación satisface mejor estas tres condiciones a la vez?

  1. Conversión en paralelo
  2. Conversión directa
  3. Conversión por fases
  4. Conversión piloto

La conversión piloto permite validar el sistema completo en condiciones reales dentro de una sola región antes de extenderlo, sin operar dos sistemas completos en paralelo en toda la institución, lo que la distingue de la conversión por fases, que introduce funciones parciales en toda la organización desde el inicio. (Kendall & Kendall, Systems Analysis and Design — estrategias de conversión)

35. Un equipo de operaciones mantiene dos entornos de producción idénticos: uno atiende el tráfico en vivo mientras el otro recibe la versión nueva del sistema; una vez validada la nueva versión, el tráfico se conmuta de un entorno al otro, lo que permite revertir rápidamente si ocurre una falla. ¿Qué estrategia de despliegue describe este procedimiento?

  1. Conversión piloto
  2. Despliegue azul-verde
  3. Conversión directa
  4. Conversión en paralelo

El despliegue azul-verde usa dos entornos de producción idénticos y conmuta el tráfico entre ellos para minimizar el tiempo de inactividad y facilitar el rollback; a diferencia de la conversión en paralelo, no implica operar ambas versiones de forma prolongada procesando la misma carga de trabajo del negocio. (Martin Fowler, 'BlueGreenDeployment' (martinfowler.com/bliki/BlueGreenDeployment.html))

Comienza gratis