Probablemente has escuchado este concepto, relacionado a desarrollo de software, en alguna parte: “Analista de negocio” (Business analyst, en Inglés), “Analista de sistemas” o “Análisis del negocio”. Es un perfil que suelen solicitar las empresas entre sus vacantes, o una habilidad requieren para algunos puestos que buscan, como el de los Product Owner.

¿Por qué quiero hablarte hoy del Análisis de negocio (o de sistemas)? Como lo he hecho a lo largo del tiempo de este boletín, porque es algo importante en el área. Mucho más de lo que algunos creen.

Quizás estás pensando “Edgar, yo no quiero que me contraten como analista de sistemas; a mí me gusta escribir y probar el código, ¿por qué necesito desarrollar esas habilidades?”. Es un buen apunte, sin embargo, en la misma idea podemos desarrollar otra pregunta: ¿cuál es el impacto que tiene tu código en el sistema? Entiende “sistema” como todo el conjunto de partes que incluyen el software, el hardware y las personas.

Las habilidades de análisis de negocio y de sistemas son importantes para todo ingeniero de software y debes trabajar en ellas, como una de tus responsabilidades. Abordemos, pues, lo que es esta disciplina.

¿Qué es el análisis de sistemas?

En palabras simples, es el proceso de comprender las necesidades de las personas, mismas que pueden estar en organizaciones o por su cuenta.

Hacer un análisis de sistema involucra conocer y entender los flujos de actividades que están realizando las personas en un momento dado y hacer un modelo. Mediante ese modelo, se identifican oportunidades y las situaciones que se deben de resolver, pues hacerlo brindará un valor mayor.

 

El análisis te permite proponer soluciones adecuadas, que están orientadas a las personas y no a la tecnología. En vez de pensar “voy a hacer un componente que permita agregar renglones a una tabla en la pantalla” lo dirás así: “crearé una solución para que el usuario capture sus ventas fácilmente y las visualice en su pantalla”. ¿Observas que anteponemos la actividad y el usuario antes de todo? Eso es lo que estamos buscando.

Contar con esta habilidad también te permite anticiparte a los problemas, pues conoces el impacto que tendrá un cambio de cualquier tamaño en el sistema. Incluso, permite encontrar oportunidades y necesidades en las que nadie había pensado o no veían como tales; por ejemplo, optimizar un proceso que funciona bien o crear actividades nuevas, que abren nuevas áreas de negocio y que se pueden aprovechar mediante el apoyo de tecnología.

¿Cómo se hace el análisis de negocio?

El proceso se basa, principalmente, en analizar los flujos de información:

• Dónde se originan los datos
• Qué transformaciones ocurren a los datos
• Cuántos pasos o actividades trabajan con esos datos
• Cuál es el destino de cada dato
• Qué significa la información para quien la está recibiendo

Lo primero es involucrarse en las actividades de las personas y recabar información mediante diferentes técnicas. Después, hacer un modelo de análisis, para identificar las oportunidades y hacer propuestas.

 

En desarrollo de software, existen métodos para hacerlo. Las más comunes son:

• Análisis estructurado: Se enfoca en describir la estructura de la información y los flujos de datos, principalmente, en diferentes niveles. Visualiza las actividades algorítmicamente y las modela como tal.
• Análisis orientado a objetos: Se enfoca en describir conceptos del dominio del negocio de una forma amigable y compatible con las personas que están involucradas en esa área. Representa los conceptos como “objetos” de información y modela las diferentes interacciones que tienen en el tiempo, con los que se consiguen ciertos objetivos.

Ten mucho cuidado de no confundir estos métodos con paradigmas de programación; son cosas diferentes, aunque tienen una relación cercana.

¿Qué debes evitar al hacer el análisis de negocio?

Lo primero que debemos evitar, al hablar de análisis de negocio, es pensar que se trata de una “fase” dentro del Ciclo de Vida del Software. Como mencioné durante el desarrollo de este texto, es una habilidad que nos permite visualizar El Sistema y conocer el impacto de nuestras decisiones en él. Por lo tanto, debes verlo como una actividad continua: cada vez que quieres escribir código en el software, lo harás evaluando continuamente el impacto que tendrá y en el valor para las personas.

Una segunda práctica a evitar es la de crear toneladas de documentación. El fin del análisis de sistemas es proponer soluciones a problemas reales, y no generar cientos de documentos que explican el problema, la solución, ambas o cosas sin relación. Todos los elementos definidos por los métodos de Análisis son herramientas sugeridas, que ayudan a conseguir el objetivo principal. Nunca ha sido el propósito que tengas que crear todos y cada uno de los diagramas UML recomendados en el análisis orientado a objetos, sino que los emplees cuando sea necesario para crear modelos y después continuar con el trabajo.

La tercera recomendación es solo para reforzar el párrafo anterior: no seguir métodos ciegamente. Aprende y adopta las prácticas que te sirvan mejor en un contexto y mejóralas continuamente.

Esta es una breve introducción al tema de análisis de negocio y de sistemas. Reitero que es una habilidad importante y necesaria en todos los ingenieros de software.

En las siguientes entregas te hablaré con más detalle del Análisis Estructurado y el Análisis Orientado a Objetos.

¡Nos vemos en al siguiente entrega!