¿Que hacen hoy los Business Analyst?

El día de ayer recibí un link de un sitio dedicado al tema de requerimientos. Los estuve hurgando un poco y encontré un informe del rol actual del Analista de Negocio(BA), en el cual indican como se realiza la  participación de los analistas de negocio, donde están interviniendo, que esta herramientas están utilizando usando, donde están trabajando y otra serie de situaciones.
Espero les guste

El rol del analista de negocios

Gestión de Proyectos

Aunque se crean para no seguirlos, sin ellos andamos a la deriva. Y es que el mundo de hoy si no se cuenta con un plan concreto de las actividades que vamos a realizar, este no anda.

 

Contar con un plan o cronograma es vital para nuestros trabajos, en el tema de gestión de proyectos. Pero hay que decir lo que todos sabemos, hacer un cronograma es una tarea de titanes y mas cuando nos piden varias alternativas (varios planes) para tomar una decisión. Eso de cuadrar recursos, sobre asignación, dependencias, tiempos muertos es una tarea que sin ayuda la verdad seria imposible realizar a mano.

 

Por eso para aquellos que suelen realizar estas tareas y a veces no cuentan con las herramientas adecuadas, quiero compartirles una recopilación de herramientas que se pueden encontrar en la red y que permiten ayudarnos en esta labor.

Las Fábricas de Software

 

 

Este termino me hace remontar a la era Industrial, aunque se supone que estamos en la era del conocimiento, no entiendo el por que FABRICA.  El termino Fabrica de Software fue tomado del proceso de desarrollar software a la medida (Tipos de Fábrica de Software)

 

Tipos de Requerimientos Volátiles

Según los expertos existen los siguientes tipos o clasificaciones en los requisitos volátiles

Requerimientos Mutables

Son aquellos requerimientos el cambio es causado por el ambiente en que la organización opera. Entre este podemos tener cambios legales, nuevos reglas de mercado, etc. En cuanto al desarrollo de software a la medida, si se tiene que hacer software para una entidad regulada, por ejemplo, se sugiere que este tipo de requerimientos legales quedaran por fuera del alcance.

Background Process

Para aquellos que el tema de los Threads, se les dificulta, .NET ofrece un control que permite realizar ejecuciones de proceso de forma independiente del Thread principal. Este control orientado esta orientado para no afectar el rendimiento de interfaz gráfica de la aplicación.

Estimación PERT

Ya me he encontrado con variado artículo publicado donde exponen a PERT como técnica de estimación. Estos son unos de los sitios que me he encontrado:

• Software Estimation with Three point estimates
• Foundation Series: Basic PERT Estimate Tutorial

Estimaciones Extremas

Como muchos sabemos existen reportes donde indican que los proyectos de software casi nunca acaban en el tiempo indicado ni con el presupuesto indicado, es mas sobrepasan estas dos dimensiones.

Pues aunque existen variada razón para que los proyectos se desvíen, las cuales no sera parte de este post, me concentrare en las estimaciones.

Expectativas diferentes

En mi anterior post (Para quien se debe escribir los casos de uso) indicaba dependiendo del perfil o rol de las personas que leyeran el caso de uso tenían diferentes expectativas del mismo.

Según un comentario que me realizaron, los casos de uso no son el documento Dios, pero la verdad hay que tener en cuenta los diferentes Intereses de cada uno de los interesados

Para quien se deben escribir los casos de uso

En el proceso de desarrollo guiado por casos de uso, los analistas de requerimientos enfrentan una tarea sumamente complicada, escribir casos de usos para los interesados. Digo que es complicada dado que las espectativas de cada uno dce los interesados varia y en algunos momentos estas se sopreponen.

Tipos de requerimientos a tener en cuenta

Hace varios días leí un artículo de Tyner Blain donde mencionaba que existían formas de calificar o verificar los requerimientos, pero que sin embargo no existían formas de verificar que estuvieran todos los requerimientos especificados, es decir que todos los requerimientos de alguna manera estuvieran escritos (bien o mal).

Aunque no podemos garantizar que les extraeremos el total de información o requerimientos a los usuarios podemos establecer pautas básicas que sobre cualquier sistema debemos cubrir, y estos son: