1) ¿Cómo te aseguraste de que los requisitos que recogiste de los usuarios son exactamente lo

que buscan?
Después de cada sesión de recopilación de requisitos, elaboraba un acta de la reunión que era un
borrador preliminar de los requisitos recopilados. Estas actas se enviaron a los usuarios
empresariales implicados para que las revisaran y comprobaran si había alguna desconexión o
información adicional. Tras recibir la aprobación de todas las partes implicadas, se elaboró el
documento final y se introdujo en un formato de plantilla formal para que los usuarios
empresariales lo aprobaran.

2) Al final del proyecto, ¿hubo algún caso en el que el usuario dijera que esto no era lo que
esperaba del sistema? (En otras palabras, esperaba más del sistema.) ¿Cómo lo gestionó? ¿Ha
mejorado los requisitos y ha vuelto a lanzar el producto?
Me encontré en una situación así durante mi proyecto más reciente. Los usuarios esperaban una
funcionalidad que no estaba contemplada en la primera versión y pensaban que el requisito existía
en el documento de requisitos funcionales. Saqué el documento de especificación de requisitos, el
acta de la reunión y les mostré que la funcionalidad nunca se había solicitado. Como no se trataba
de un requisito inmediato, los usuarios de la empresa acordaron esperar a la siguiente versión de
la aplicación para incorporar la funcionalidad.

3) ¿Ha trabajado con alguna herramienta Rational?

Normalmente he trabajado con la metodología RUP y las herramientas de Rational se basan en la
misma. Estoy bastante versado con Rational Rose para hacer diagramas de casos de uso,
documentos de casos de uso, realizaciones, etc. He utilizado Requisite pro para gestionar y
documentar los requisitos.
4) ¿Hasta qué punto participó en la fase de pruebas?
Éstas serían específicas para tu currículum en función del proyecto del que se hable.

Ejemplo:
Durante la fase de pruebas fui responsable de:
Desarrollo de casos y planes de prueba.
Registrar las observaciones de los usuarios e informar de ellas a mi jefe.
Discutir cualquier cambio o actualización con el usuario y, en caso necesario, gestionar
los procedimientos y el seguimiento de las solicitudes de cambio.

5) ¿Cómo decide qué funciones incluir en cada versión?

Todo el mundo quiere que sus características se publiquen en la primera iteración. Normalmente
decidimos las características de la primera versión o de las siguientes en función de:
Prioridad empresarial
Qué característica va en primer lugar en función del documento de alcance.
Revise con los responsables de la empresa lo que necesitan en la primera versión y
obtenga su aprobación.
Complejidad empresarial/Riesgo

6) ¿Cuál es su principal punto fuerte o qué cree que ha conseguido en su último proyecto de lo que
se siente más orgulloso?
Creo que mi punto fuerte es mi capacidad para ser detallista. Siempre hay momentos en los que
se producen desconexiones o cambios constantes en el proyecto y, si la información y los
documentos no están bien organizados, puede provocar un desastre y el fracaso.
También soy bastante detallista, lo que me ayuda a enumerar los casos de uso y los requisitos de
forma adecuada y exhaustiva para que haya el mínimo elemento de duda.
7) ¿Cuáles eran los riesgos del proyecto? ¿Cómo se le ocurrieron las soluciones para esos riesgos?
El proyecto entrañaba varios riesgos:
Normativa sobre valores: En este proyecto había muchas normas que debían tenerse en cuenta al
desarrollar el sitio web. Por ejemplo: quién debe tener qué tipo de acceso al sistema, qué camino
seguirá el documento ¿Cómo tratar a las partes interesadas difíciles?
A veces puede resultar difícil tratar con las partes interesadas, pero podemos superar esta
situación:
Escucharles pacientemente y ser educado.  Hacerles comprender la situación desde una
perspectiva que ellos entiendan.
Muestre su compromiso de trabajar con ellos.
Hazles ver cómo sus intereses se harán realidad cuando sean más abiertos y
colaboradores.
Involúcrelos y hágales ver que su contribución se valora.

¿Qué importancia tiene un organigrama?

Los diagramas de flujo ofrecen una representación gráfica clara de un proceso aplicado,
Esto hace que el sistema sea fácil de entender para todas las personas implicadas en el
proyecto.

¿Explique brevemente el modelo de casos de uso?

El modelo de casos de uso requiere un diagrama de casos de uso que describa el entorno
empresarial,
Su objetivo principal es mostrar la serie de eventos y acciones que un actor llevará a cabo
en un proceso determinado.

¿Qué es el modelado UML?

UML significa Unified Modeling Lanugae (Lenguaje de Modelado Unificado). Se trata
de un lenguaje estándar para construir, visualizar y documentar los distintos componentes
de un sistema.

¿Cuáles son las competencias que debe tener un analista de negocio?

Buen oyente, aprendiz rápido y continuo, capacidad analítica, enfoque de resolución de
problemas, pensamiento más allá de la caja, conocedor de la tecnología (puede mantener al día
cuáles son las últimas tecnologías lanzadas en el mercado y cómo son importantes). Gestión de
equipos o personas, comunicación sólida, capacidad de documentación (inglés escrito), trabajar
en equipo, idear nuevas soluciones, estudios de mercado, etc. (si conoce alguno más, puede
añadirlo).

¿Qué opina de los retos a los que se enfrentan los analistas empresariales?
La gestión del cambio es el mayor reto, porque también ocurre en tiempo real. Después de la fase
de requisitos, cuando se inicia el desarrollo, el cliente realizará algunos cambios o mejoras.
Gestión entre departamentos o equipos, como la gestión de conflictos entre equipos. También
individuos. Para ello se requieren aptitudes interpersonales e inteligencia. Problemas de
comunicación - En tiempo real puede ocurrir. Puede que se te dé bien hablar y entender el inglés.
PERO a veces ocurre que diferentes personas de todo el mundo hablan un inglés diferente. En
EE.UU. mismo México la gente habla inglés de manera diferente. Los romanos hablan un inglés
diferente. Así que al principio entender el acento puede ser un reto, pero después de algún tiempo
se convertirá en perfecto.
 ¿Qué opina de los riesgos y los problemas?
El riesgo es algo que puede preverse y que puede gestionarse formulando planes de mitigación. El
riesgo que se ha producido se denomina Emisión. Habrá gestión de contingencias o gestión de
problemas para resolverlos. Básicamente no vamos a solucionar el problema, pero intentaremos
hacer un control de daños y tomarlo como aprendizaje para otros proyectos.

¿Qué haría si no ha recibido todas las firmas requeridas en la documentación de la fase presentada
para su aprobación? Destacar el proceso de gestión de riesgos: ¿cómo señalarlos? Resolución - de
tales escenarios, trabajando junto a PM

Explique cómo organiza o prioriza su carga de trabajo

Haz una lista. Piensa en qué tareas son urgentes y en la importancia de cada una de ellas.
Si no está seguro de lo que es urgente y lo que no, o de la importancia de las distintas
tareas

¿Qué es la HIPPA?

270-271 es para la investigación de elegibilidad

276-277 es para la respuesta sobre el estado de la reclamación
820 pago de la prima
Facturación de primas 811
275 información pt, medicación pt ya ha tomado
278 servicio de asistencia sanitaria/antes de que se preste el servicio, ¿tiene o no derecho a esta
pat?

Proceso de facturación médica

1. El paciente acude al hospital
2. Los servicios se prestan, (Signos y síntomas serán revisados por el dictador y de acuerdo
con que el procedimiento y los servicios se realizan, y el procedimiento y el servicio se
convertirá en un código)HCPC
3. Después de la descarga, la entrada de carga se producirá
4. Es entonces cuando comienza el proceso de facturación propiamente dicho.
5. A. Entrada de datos (toda la información del paciente se introduce en el sistema, La
información de los médicos
El NPEl DX ,Los códigos de procedimiento
b..Entrada de cargos, El cartel de caja contabilizará los cargos en el sistema
c .las reclamaciones se tramitarán y los reclamantes se dirigirán a las interfaces para
obtener el pago de las reclamaciones
Reclamaciones electrónicas 837 y 835
Después de que se presenten las reclamaciones, vienen los rechazos y las aprobaciones,
que siguen como un círculo, las reclamaciones serán denegadas por no ser médicamente
necesarias o porque el código DX no es un DX válido o un código HCPC válido, etc.