¿Qué es ser un analista de un sistema de información?

Realizar un análisis de un sistema de información es estudiar, investigar, organizar y documentar un sistema de información.

El analista debe prepararse para descubrir lo cubierto. No es un dibujante y no es un documentador, es  un comprendedor.

No copia; crea, sugiere, define y expone un sistema subyacente en una organización o negocio.

El analista de hoy recomienda e incorpora requerimientos que el usuario aún no visualiza; por lo menos los expone, luego el usuario tomará la decisión sobre si se quedan o se van. Casi siempre se quedan.

Algunos creen y es un pensamiento muy facilista que un analista tiene por objetivo documentar. Me gusta pensar que el analista deja pruebas de lo acontencido para el resto de los profesionales y del negocio respecto de los descubrimientos realizados.

El analista construye y deconstruye a la organización a partir de datos e información. Libera en su mente una sustancia llamada asociación que amalgama y teje redes entre los datos, los procesos y la información.

El analista abre los portales de un universo oculto y lo expone. Lo manifiesta. El analista, metafóricamente hablando, es un explorador de una dimensión no visible para el común de la gente.

Juntando pruebas para estimar el esfuerzo

Desde el comienzo cualquier oráculo (lease libro, incluye libros electrónicos) dirá que la estimación es una aproximación. Con esto básicamente todos los autores se lavan las manos e introducen alguno de los riesgos siguientes: subestimar o sobreestimar el esfuerzo de un proyecto de software. Estos son riesgos gemelos que nunca se verán (claro, cuando uno se presenta el otro no lo hace). 
Al estimar ya se introducen los 2 riesgos, pero uno solo se materializará. La única certeza es que uno de los 2 se hace presente. Nunca, pero nunca estimarás y concidirá con la realidad. JAMÁS. 
Superada esa necesidad de ser perfecto, como todo informático, alcanzarás el paraíso, aunque sea mientras estimás.
Lo único que podés hacer es reducir la incertidumbre, para ello debes hacer historia. Y todos sabemos que la historia se recuerda si se registra. Entonces lo que debes hacer es:

1.  Registrar la estimación, registrar los requerimientos que se estiman, los supuestos y las fuentes.
2. Monitorear tu proyecto. Hacer un registro de las circunstancias, hechos e impresiones detectadas.  Hacé un bitácora, si, una bitacora, como la de la película (film) de viaje a las estrellas.
3. Registrar el trabajo real
4. Llevar adelante un lecciones aprendidas o bien, una restrospectiva del proyecto.

Con loselementos mencionados juntarás la prueba que avalará tus decisiones.

Las pruebas según el CMMI: (esto es una visión totalmente personal, no está escrito en CMMI)

1. Nivel 1. Inicial. Arranco y dejo. Comienzo y abandono. Resultado: material incompleto. Moraleja: perdiste el tiempo; pero aprenderás. Aprenderás que así no funciona.
2. Nivel 2: generás tu historia, pero como lo haces a tu modo. Resultará útil solo para ti, pero  poco utilizada para otros. Te vuelves cada vez menos aproximado, pero nunca serás certero. Habrá quienes te crean y quienes te lean. Resultado: Tu sabes la verdad. Los desvíos son menos que en otros tiempos. Ups de repente tengo capacidades especiales (el poder X de estimar). Ojo hay otros heroes que juegan igual.
3. Nivel 3. La organización se preocupa y ocupa por cumplir los pasos mediante un mecanismo uniforme. Los datos ahora son comparables. Hay aprendizaje organizacional.
4. Nivel 4. Hay indicadores que regulan a la estimación. La organización cree en esos indicadores. Quien se corre de los indicadores es un disidente.
5. Nivel 5. Lo dejo a tu criterio.

Conclusión 
Estimar es una experiencia unica para quien cumpla con esa función, pero debe procurar aprender de sus errores o falsas visiones. Eso lo mejorará radicalmente como profesional. Los pasos son fundamentales para demostrar que soy serio al momento de hacer mi trabajo.

¿Cuál requerimiento analizo primero?

No resulta fácil distribuir el trabajo del análisis, y esto es por varias razones. 
La razón que vamos a trabajar aquí tiene que ver con las dependencias entre los requerimientos. Supóngase que tiene 10 casos de uso de usuario (no historias de usuario, hablo de casos de uso 😡) y el análisis lo tiene que distribuir entre 2 analistas o más.¿Cuáles son los casos que asigna a un analista y cuáles a otros?¿ Pueden comenzar los analistas a trabajar en paralelo?¿Debe haber una coordinación?

Para la explicación voy a plantear un ejemplo, pues transcribir el enunciado lo haría muy pesado. Estimado lector vas a tener que creerme que es así

El ejemplo trata de un sistema de información para cumplir con la meta de Realizar giras de álbumes de cantantes que los promocionan.
La matriz de dependencias de requerimientos que se plantea ( y no puede discutirse) es la siguiente:

		1.01	1.02	1.03	1.04
1.01	Definir Gira	---
1.02	Confirmar Gira	Si	---
1.03	Cerrar Gira	Si		---
1.04	Cerrar Presentación				---

¿Cómo se lee?
un cambio en el caso de uso de 1.03 afecta o impacta al caso de uso 1.01. Nota: recuerde que un caso de uso es un conjunto de requerimientos, principalmente funcionales)

Sin importar cuantos analistas hay, con la matriz de dependencias se puede evidenciar que los análisis de los casos de uso no son paralelos. Si se analiza el caso de uso 1.01, luego cuando se analice el caso de uso 1.03, el caso de uso 1.01 se modificará. 
Entonces está solución no aplica:

mientras que esta solución si:

Conclusión
La segunda programación es más realista y factible. Esto es independientemente de los recursos que se asignen.
Falta trabajar un poco más en la programación, pero esta segunda opción sin dudarlo es mejor que la primera.

Gestión de requerimientos adentro

Hoy en día nadie duda que el desarrollo de aplicaciones y especificamente el desarrollo de aplicaciones de sistemas de información resultan bastante más complejos que ayer, hace un año, 10 o 20. De esta afirmación no hay dudas.
Casi todos los desarrollos padecen del riesgo de requerimientos inestables y/o requerimientos incompletos, e independientemente del ciclo de vida en el que este basado, en el proyecto tarde o temprano volvemos sobre un requerimiento ya pensados. 
Puede parecer que la causa de esto sea que el cliente no tenga claro que necesita o una baja capacidad del analista en entender lo que el cliente intenta transmitir, pero quizás en muchos casos sea que todos estamos aprendiendo cuales son los requerimientos verdaderos. Entonces no podemos dejar de volver ya que encontramos inconsistencias o mejoras a las luz de nuevos conocimientos.
Si a lo anterior le agregamos escala o volumen, equipos de varios analistas, múltiples actores y docenas de puntos de vista, no cabe duda que alguien debe tomar el toro por las astas y guiar el trabajo, esa guía debe realizarse a través de la aplicación de la gestión de los requerimientos.

Definición: Gestionar requerimientos CMMI
El propósito de la Gestión de requerimientos (REQM) es gestionar los requerimientos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requerimientos y los planes y productos de trabajo del proyecto.

Prefiero entender las gestión de los requerimientos de la siguiente manera:

1. identificar requerimientos, 
2. determinar las relaciones que existen entre ellos, 
3. evaluar el impacto de un cambio, agregado o eliminación de un requerimiento, 
4. visualizar el cambio de alcance del desarrollo o mantenimiento,
5. controlar completitud e inconsistencas respecto de un plan de proyecto / trabajo o cualquier sinónimo del mismo y respecto de requerimientos versus requerimientos.
6. mantener la trazabilidad de las relaciones entre ellos.
7. monitorear el desarrollo de los requerimientos a lo largo de todo el proyecto y vida del producto.

Para hacer gestión se necesita un responsable. El responsable no es el lider de proyecto bajo ningún término. El responsable de la gestión de requerimiento trabajará desde la definción de los requerimientos como un lider en el analisis y verificador cuando se avance sobre otras areas/fases de desarrollo. Su rol, si se quiere es el de guardián de requerimientos. El intentará protegerlos de la exageración, el fanatismo y del olvido del resto del equipo (incluido el cliente). Algo que invariablemente sucederá.

No hacer gestión de requerimientos solo genera tensiones inútiles, inconsistencias, olvidos e incompletitudes, perdida de tiempo y perdida del por qué o para qué se hace lo que se hace.
Si en tu proyecto "mediano" no hay un responable de gestion de requerimientos al menos, considera que tenés un riesgo con alta probabilidad de ocurrencia.
No ahorrés dinero donde no conviene.

Procesos de Negocio. Importancia

Nota del autor: algunas cuestiones no resultan importantes entre ciertos profesionales de la ingenieria en general, tal es el tema de los procesos, bueno  aqui va mi opinión, espero quede bien fundamentada.

Me gusta pensar que los procesos generan igualdad. En una organización, los procesos colaboran a que cualquiera de sus integrantes obtengan la misma meta, independientemente de quienes son, cual es su rol, o que poder poseen.

También me gusta pensar que los procesos dan garantías. Esto es, que ejecutando sus tareas / actividades se alcanzan o concretan las metas para las que estan diseñados.

Me gusta imaginar que los procesos completos ( aunque es díficil que lo esten) cubren la mayoría de los casos, lo que permite a la organización ser estable. Todos saben que deben hacer y cuando; esto no es un tema menor.

Por último, los procesos forman la cultura en la organización. Esto es casi consecuencia de todo lo anterior.

En algunos momentos hemos conversado con otros colegas sobre la importancia de tener  documentados los procesos de negocio y sobre la forma de documentación. Solo quiero decir esto al respecto:

• Se debe documentar lo que se considera importante. Lo que sirve para lo mencionado arriba.
• Si se desea comprar o desarrollar aplicaciones para ser más eficaces y eficientes, los procesos deberian estar concientes, entonces deben existir más allá de las personas que hoy trabajan en la organización. Los procesos deben estar institucionalizados.
• Los procesos explicitados permiten a la organización desarrollarse sobre base cimientales fuertes
• Si vas a estudiar un sistema de información necesitarás documentación que avale los requerimientos y posibles oportunidades de mejora. Bueno allí necesitas procesos documentados.
• Entender un sistema de información suele implicar entender primero el proceso de negocio subyacente.

Respecto de la documentación he encontrado múltiples variantes que van desde texto puro a gráficos. Personalmente me gustan los diagramas de actividad y los casos de uso con alcance de negocio, pero no son los únicos. También existen formas como: manuales de procedemiento y cursogramas, diagramas de flujos de datos, entre otros. Debo decir que usando los diagramas de actividad y casos de uso, no he vuelto sobre otras herramientas.

Documentos relacionados: Procesos de negocio. Introducción

Procesos de Negocio. Introducción

Nota del autor: es inevitable que para llegar al punto en cuestión tenemos que buscar un punto común para comenzar el relato y de allí avanzar. Está introducción tiene ese objetivo.

Introducción
Las organizaciones, las personas, la sociedad, las ciudades, las familias, entre otras, se organizan persiguiendo metas u objetivos. Si querés, las cosas no se hacen porque si, por lo menos no en la mayoría de los casos. En la mayoría existe una meta aunque sea implícita que los moviliza.
Conseguir objetivos se hace realizando acciones, tareas y actividades, o subprocesos, procesos, incluso superprocesos. La variedad de agrupamientos ( y en breve aclararé por qué digo agrupamientos) es importante. Nota: Intentaré no copiar, ni traducir definiciones de otros, pero no puedo asegurarlo. :)
Proceso
Diremos que un proceso de negocio es un conjunto de actividades diseñadas y organizadas para alcanzar una meta dentro de un negocio u organización; sea la organización gubernamental, pública, privada, con fines de lucro, sin fines de lucro, institucional y mil etc. más.

Una organización, para alcanzar sus objetivos organizacionales, debe crear e implementar procesos de negocio que interactuan o se realcionan entre ellos y posiblemente con otros que están fuera de la organización.Superprocesos
Cuando tomo varios procesos de varias organizaciones cuya interralación pemiten alcanzar metas más altas, entonces estamos en precencia de superprocesos.  Por lo tanto un superproceso de negocio es un conjunto de proceso en donde participan al menos 2 organizaciones distintas para alcanzar metas que las trascienden.
Bueno pero no vayamos tan alto.
En una organización puede tener varios procesos que al unirse alcance metas mayores. El concepto de negocio surge como agrupamiento dentro del límite de una organización. Ahora esas fronteras estan en jaque. Si se conjugan todos los procesos de la organzacion tambien estamos en presencia de un superproceso; en este caso el superproceso es intra organizacional.
Subproceso
Un proceso de negocio podria subagrupar sus actividades en subprocesos. si se quiere, un subproceso es un proceso de negocio que alcanza un meta, pero esta no alcanza por si sola a cumplir una meta organizacional. Aqui me quiero detener pues la meta de un proceso tampoco  es exclusiva de las metas de la organización, podemos estar refieriendonos a otra cosa. Ejemplo el proceso de pago de empleados no cumple una meta organizacional en una organizacion cuya meta es de negocio; sin embargo tiene la fueza de un proceso. La linea es delgada :(
Actividad 
En cuanto a las actividades, para este documento coincidirán con tarea. En ambos casos las trataremos como sinónimos. Una actividad es un conjunto de acciones diseñadas y organizadas para alcanzar una meta dentro de la misma línea de tiempo. Esto es, una actividad se resuelve en forma continuada hastaalcanzarse la meta o fallar, a esto suelo denominarlo continuidad temporal.
En un proceso la continuidad temporal es interrumpida, en la actividad no. Dicho de otro modo, cuando realizó acciones en forma continua y continuada, entonces estás en presencia de una actividad, de otro modo será un proceso.

Me gusta pensar que no tengo la última palabra, pero avanzo en la dirección planteada. Espero estás ideas sumen.

No se si habrá procesos de una sola actividad, pero si he encontrado actividades de una sola acción. No puedo asegurar que las otras combinaciones no existan.

Matriz de Dependencia de requerimientos

Introducción

Cuando realizamos proyectos en donde los requerimientos no están estabilizados, se produce mantenimiento o evolucionan por alguna otra razón, es más que conveniente establecer las relaciones de dependencias entre los mismos.
No suele ser muy visto en la práctica profesional, pero es una técnica importante para establecer y medir los impactos rápidos de los requerimientos ante la presencia de un cambio.

La matriz

La matriz de dependencias de requerimientos suele ser utilizada para varios fines. Un fin inmediato es poder observar el impacto que se tiene en los requerimientos, ante el cambio de un requerimiento.
La matriz de dependencias puede ser util para determinar los grupos de requerimientos altamente relacionados para que sean trabajados en distintos equipos en cualquiera de las disciplinas de un desarrollo clásico: análisis, diseño, programación y prueba.
Matriz de dependencias de ejemplo

Expliquemos las dependencias

El requerimiento 4 es un requerimiento de información, por lo que este muestre debe ser ingresado (y posiblemente modificarse). Esto es natural, la información no aparece de la nada, necesita de un alta; pero si se desconoce que se requiere consultar; lo que se presuma en el alta estará incompleto hasta llegar al requerimiento 4, entonces será necesario ajustar el alta posteriormente. No conviene comenzar por los requerimientos que no son de información. 
El requerimiento 3 refiere  a una modificación; existen muchos datos (quizás todos) que puedan ser modificados; pero para crear una modificación se debe primero saber que es posible modificar y cuales datos de los ingresados; consecuencia es conveniente conocer el alta (o altas) para aplicar la modificación.
No todas las dependencias son tan lineales, existen complejidades adicionales, pero uno puede suponer con escaso margen de error que si se requieren nuevos datos del requerimiento 4, posiblemente habrá impacto en el requerimiento 1 y con otra probabilidad en el requerimiento 3 que es un requerimiento que depende del requerimiento 1.

Los profesionales de sistemas sabemos que rapidamente aparecen nuevos requerimientos y hablar de un sistema con 50 requeirmientos no es ni lejano, ni loco. Si esta situación se presenta se deben agrupar los requerimientos. ejemplo en casos de uso.

Otras utilidades

El orden de dependencia sirve para que el analista pueda establecer una estrateria de trabajo si lo necesitara.