Diseño de la jerarquía de casos
3 Tareas
2 horas
Escenario
Front Stage ha finalizado sus requerimientos con respecto a la organización de eventos al aire libre, incluida la preparación meteorológica, las reservas de habitaciones de hotel y el estacionamiento. El monitoreo meteorológico está incluido en el precio de un evento. La reserva de hotel y el estacionamiento se ofrecen como servicios opcionales con cargo adicional.
Analice los requerimientos clave para esta aplicación. Los requerimientos clave a tener en cuenta son los siguientes:
Procesos: la preparación meteorológica, la solicitud de habitaciones de hotel y la funcionalidad de los servicios de estacionamiento se deben ejecutar de forma independiente.
Extensibilidad: debe ser posible ampliar la aplicación de reserva para admitir diferentes tipos de lugares.
Reportes: se deben definir reportes para eventos que muestren ingresos, costos y ganancias (ganancias por tipo de evento).
Datos: los usuarios de las instalaciones no deben poder ver la información financiera.
UI: cotización del cliente, revisión del gestor de eventos y pantallas de reserva de hotel.
Revise todas las opciones de diseño viables y enumere los pros y las contras de cada una para generar una recomendación sobre la estructura de casos más adecuada para la aplicación.
Opcional: genere una lista de preguntas adicionales para hacerle a Front Stage, lo que puede ayudar a producir un diseño que satisfaga los requerimientos actuales y se adapte a los requerimientos futuros con una refactorización mínima.
Tareas detalladas
1 Identificar opciones de diseño
Caso único con subprocesos (subflujos)
Un solo caso de evento no satisface los requerimientos del proceso debido a problemas de bloqueo. Los requerimientos de extensibilidad y reportes se cumplen fácilmente, y el requerimiento de la UI se puede satisfacer con objetos de datos independientes que rastrean cada hotel. Sin embargo, se requiere trabajo adicional para actualizar el estado de cada hotel.
El requerimiento de datos se puede satisfacer ocultando los datos de los usuarios de la instalación, pero esta no es una solución óptima para proteger los datos.
Sin embargo, el requerimiento de los procesos no puede satisfacerse por completo debido al bloqueo del caso, porque esto impide que dos usuarios actualicen el caso simultáneamente. El bloqueo optimista puede solucionar el problema, pero es posible que esto no sea óptimo porque puede restar valor a la experiencia del usuario durante el procesamiento de casos. La adición de más servicios podría exacerbar este problema.
Caso único con casos hijo (subcasos)
Una alternativa viable es un caso de nivel superior de evento con subcasos para servicios (actualmente clima, hotel y estacionamiento). La modificación del esquema de bloqueo predeterminado para bloquear subcasos independientemente del caso padre resuelve el problema de bloqueo y permite el procesamiento paralelo sin interrupción. Este enfoque también proporciona extensibilidad al diseño, ya que puede ser fácil manejar servicios adicionales. Considere manejar la coordinación de la resolución del subcaso con el caso padre usando esta posible opción de diseño. Los subcasos de hotel deben completarse antes de que comience el evento, y el caso de estacionamiento está activo durante el evento real y posiblemente después. Además, considere el efecto de agregar servicios adicionales en el futuro.
Múltiples casos (con subflujos/procesos)
Una alternativa al caso de evento único de nivel superior es tener un caso de cotización separado que proporcione la cotización inicial. Si se aprueba, se crea un caso de evento de pares. Este enfoque proporciona la posibilidad de crear un caso de evento solo si el cliente y los ejecutivos aprueban el evento.
Caso de nivel superior circunstanciado (con subflujos/procesos)
Otra alternativa es proporcionar la capacidad de cotización de autoservicio del cliente mediante una circunstancia de caso de evento de canal de Mashup. Si el cliente está de acuerdo con la cotización generada dentro de la etapa de creación, al enviarla, el caso de evento avanzará a la etapa de cotización. El cliente no tendrá acceso a esta etapa. Si el cliente no desea seguir adelante, puede cancelar el proceso en la etapa de creación. Esto resuelve el caso de evento. En la etapa de cotización, un ejecutivo de ventas puede rechazar o aprobar una cotización enviada por el cliente. Si no se habla con el cliente directamente cuando un ejecutivo de ventas aprueba una cotización enviada por el cliente, se le puede pedir al cliente que confirme su decisión, también mediante una interfaz de Mashup.
2 Evaluar opciones de diseño
Pros y contras de cada opción de diseño
| Diseño | Pros | Contras |
|---|---|---|
| Caso único con subprocesos |
|
|
| Caso individual con casos hijo |
|
|
| Múltiples casos |
|
|
| Caso individual con casos hijo, caso individual circunstanciado para Mashup |
|
|
3 Recomendar la mejor opción de diseño
Se prefiere un caso de evento con subcasos porque:
- Satisface completamente los requerimientos de bloqueo de aplicaciones
- Se facilita el cumplimiento del requerimiento de UI
- Ayuda a que la aplicación se adapte mejor a los requerimientos futuros porque los subcasos ofrecen más opciones de especialización
El autoservicio del cliente que se agrega al caso de nivel superior no afecta la decisión de escindir los subcasos una vez que haya pasado la etapa de cotización. Se debe tener cuidado de no mostrar información al cliente, como costos y ganancias, que solo deben ver los Ejecutivos de ventas.
Disponible en la siguiente misión:
¿Quiere ayudarnos a mejorar este contenido?