domingo, 10 de junio de 2012

Revisando: El Analista Funcional (10/06/2012)


  • Analista Funcional en Argentina.
  • Desarrollo de software. El analista funcional y el analista orgánico.
  • El rol del Analista Funcional en equipos ágiles.
  • La importancia de un buen análisis funcional.
  • Actualidad y Tendencias: Analista (Funcional y de Testing).
  • ¿El Analista Funcional debe ser Técnico?.
  • ¿Dónde esta el límite entre un ‘Analista de Testing’ y un ‘Analista Funcional’?.
  • Análisis Funcional – Requisitos del mercado.



Analista Funcional en Argentina.

Fuente: marianariva.blogspot.com.ar

Función de un analista funcional por definición
  • Relevar y gestionar las necesidades funcionales del cliente en la elaboración y ejecución del proyecto, cumpliendo con los estándares y la documentación requerida por las normas de calidad de la empresa. Relevar las necesidades del cliente considerando las características de su operatoria. Especificar los requerimientos y funcionalidades de la solución. Determinar la viabilidad de adaptación del sistema de acuerdo a las características del negocio del cliente. Actualizar información sobre nuevas tecnologías y productos propiciando el aprendizaje permanente.

Tareas que actualmente el mercado requiere de un analista funcional
  • Relevamiento, analisis y documentación de procesos integrales, requerimientos técnicos, requerimientos de negocio, etc
  • Validación de Modelos de Diseño
  • Entrevistas con usuarios y proveedores
  • Revisión de estimaciones
  • Especificación de diseños funcionales de casos de uso
  • Emisión de procedimientos
  • Generar y mantener documentación sobre los circuitos operativos, sistemas que permita su análisis y mejoramiento.
  • Armado de lotes de prueba
  • Capacitación a usuarios
  • Detectar la necesidad de nuevos sistemas o proponer mejoras
  • Analizar alternativas de implementación
  • Parametrización
  • Implementar soluciones junto a el equipo de desarrollo
  • Soporte post implementación
  • Generar informes / reportes
Conocimientos técnicos requeridos
  • Metodologías formales de análisis y desarrollo
  • UML
  • SQL / PLSQL
  • Datawarehousing
  • Orientación de Objetos
  • Herramientas automáticas para soporte de procesos de testing
  • Herramientas Office / Project
Compentencias requeridas
  • Trabajo en equipo
  • Capacidad de análisis
  • Buena comunicación oral y escrita
  • Predisposición hacia el usuario
Actualmente, los requerimientos de analistas funcionales en el mercado son varios. Cada medio de publicación de búsquedas actualmente posee mas de 150 ofertas de este perfil.
En épocas pasadas, el analista funcional realizaba diversas y variadas funciones que con el correr del tiempo y la evolución de los equipos de desarrollo de sistemas en el país , han ido tomando nuevos caminos hacia la especialización.
Actualmente existen personas que se dedican SOLAMENTE al testing, al seguimiento de tiempos y aseguramiento de los mismos, a la calidad, documentación o administracion de requerimientos.
El analista funcional sigue teniendo un perfil amplio, que no solamente interviene en la primera etapa clásica del proyecto ( relevamiento, análisis y diseño) sino que las nuevas metodologías hace que intervenga constantemente y su tarea sea generalicia.
Hay requerimientos técnicos que siempre son bienvenidos, especialmente base de datos y lenguajes de consulta sobre las mismas.
También el analista debe conocer las diferentes arquitecturas de sistemas, para poder entender, diseñar y hasta implementar sistemas en tales entornos.
La comunicación debería ser su fuerte. Con el usuario, con el cliente interno, con el equipo completo.

Publicado por 



Desarrollo de software. El analista funcional y el analista orgánico.

Fuente: jummp.wordpress.com

¿Qué tareas realiza un analista funcional?, ¿cuáles un analista orgánico?. Depende de la entidad en la que trabajen y del proyecto en sí, la limitación de las funciones de cada uno.
Por regla general, se considera analista funcional a quien se encarga de la recopilación del catálogo de requisitos y de la definición de los casos de uso (o historias de usuario). Su objetivo es describir las funcionalidades del sistema y su comportamiento mediante el estudio de las necesidades del usuario. Su trabajo es muy importante y sin embargo no se le da el valor que se merece, ya he comentado en más de una ocasión que lo técnico suele resultar más glamuroso.
Los sistemas se desarrollan para el usuario y para que sean de utilidad hay que saber captar qué es lo que quiere el usuario y cómo desea interactuar con el sistema.
La técnica es muy importante, pero no lo es menos que la vertiente funcional, todos suman y todos restan si no hacen adecuadamente su trabajo.
El analista orgánico se encarga del diseño que no es otra cosa que la particularización de las necesidades del usuario a una implementación concreta. Para un proyecto concreto vendría a ser el arquitecto de la solución, ya que entraría incluso a definir el framework con el que se va a trabajar.
Lo habitual en los proyectos de desarrollo de software es encontrarnos con analistas que realizan las dos funciones, aunando en un solo perfil lo funcional y lo técnico. Tiene como principal ventaja que no es necesario transferir el conocimiento entre diferentes fases o procesos del desarrollo y que cada tarea es realizada por un experto en la misma. El principal inconveniente es que no existe una especialización, no obstante, hay que ser bastante bueno en uno de los dos perfiles para marcar de manera clara la diferencia respecto a analistas que realicen ambos trabajos (ahora, quien las marca es que es muy bueno y por tanto, vale mucho dinero).
En desarrollos iterativos e incrementales con una orientación ágil lo deseable es que la evolución del desarrollo sea rápida (realizándose los incrementos con cierta frecuencia) y resulta fundamental la participación del usuario, a ser posible como una pieza más del equipo de proyecto, lo normal es que no exista distinción entre analista funcional y orgánico, si bien, tendrá una vertiente más técnica, por las características particulares de este tipo de desarrollos. Existirán excepciones, en proyectos que por su naturaleza requiera de desarrolladores que den apoyo funcional, por la experiencia que tengan en un tipo de negocio concreto.



El rol del Analista Funcional en equipos ágiles.

Fuente: maypun.blogspot.com.ar


Tradicionalmente el Rol del Analista Funcional o Ingeniero de Requerimientos ha sido definido en el contexto de un proyecto utilizando el modelo cascada del ciclo de desarrollo de software (SDLC), donde el Analista recolecta todos los requerimientos y reglas de negocio en el comienzo, antes de empezar a desarrollar. Sin embargo, la demanda acelerada de soluciones ha modificado la dinámica del desarrollo de sistemas a un enfoque más ágil, donde los requerimientos y las reglas de negocio se definen al mismo tiempo que se desarrolla el software, en ciclos iterativos.


De aquí que surje la pregunta "¿Existe la necesidad del rol de Analista Funcional en un equipo de desarrollo de software ágil?"

Si el lector es de los que piensan que el rol del Analista Funcional no es necesario en el enfoque ágil, le pregunto si ha evaluado fehacientemente cómo se ve expandido el rol del desarrollador al incorpor las actividades necesarias para relacionarse directamente con el cliente.
Creo que independientemente del Ciclo de desarrollo de software elegido, el rol del analista funcional es necesario. En el caso del enfoque ágil, puede ser riesgoso para el proyecto que las funciones del Analista Funcional sean absorbidas por miembros del equipo de desarrollo.

Para los propósitos del artículo, tomaremos a Scrum como método ágil de desarrollo de software.


El Rol del Analista Funcional como Facilitador

Diferenciaremos el rol del Dueño del Producto (Product Owner) en Scrum, que es el de asegurar que se satisfagan las necesidades del negocio, del rol del del Analista Funcional que es traducir la visión del Dueño del Producto en el Listado de Requerimientos (Backlog) que servirán como entrada al equipo de desarrollo.
En algunos proyectos, ambos roles pueden estar representados en la misma persona.

El Analista Funcional funciona como enlace entre los interesados en el proyecto (stakeholders) y el equipo de desarrollo. Para ello, utiliza distintas técnicas y habilidades (tormentas de ideas, votación de las funcionalidades, análisis de costo-beneficio, generar participación activa, mantener el trabajo en foco, etc.) para asistir a los líderes del proyecto en el logro de los objetivos propuestos.


En proyectos de desarrollo utilizando el ciclo ágil, el Analista Funcional contribuye en dos actividades principales: asegurar el cumplimiento de la Visión y Alcance, y moderar las reuniones de Planificación y Revisión de cada Iteración.
Todo proyecto comienza con una definición de la Visión y Alcance de la solución a desarrollar para cumplir con una necesidad de negocio. En el enfoque ágil, la visión y el alcance se definen en un conjunto de reuniones, cada una representando una porción de la visión y alcance en ese momento, que es determinada por los interesados.

El desafío para el patrocinador del proyecto es el de asegurar que la visión y alcance del proyecto sean resultado de un esfuerzo colaborativo entre todos los interesados en el proyecto, de aquí la necesidad del rol del Analista Funcional como facilitador. El Analista Funcional debe utilizar técnicas que faciliten que todos los interesados en el proyecto participen, colaboren y lleguen a un consenso sobre el conjunto priorizado de funcionalidades de alto nivel que deben ser desarrolladas. Debe asegurarse de que estas funcionalidades están justificadas y que tienen correspondencia con las necesidades de negocio. Todas las funcionalidades estarán sujetas a la aprobación del patrocinador del proyecto.


Reuniones de Planificación, Sincronización y Retrospectiva

Luego de que se identificaron el conjunto de funcionalidades de alto nivel, las reuniones del equipo de desarrollo comienzan con un consenso sobre cuáles de ellas serán desarrolladas en la primera iteración. Una vez que se seleccionó un conjunto finito de funcionalidades y se les asignó una fecha de entrega (time-box), todos los días se realizan reuniones de sincronización para revisar el estado de avance y eliminar obstáculos. Finalmente, se valida el prototipo y se implementa, realizando luego la reunión de retrospectiva y volviendo al inicio con una nueva reunión de planificación de las funcionalidades a incluir en la siguiente iteración.

En estas reuniones, surge el mismo desafío, asegurarse de que el software desarrollado sea producto del esfuerzo colaborativo y consenso de los participantes. Una vez más surge la necesidad del rol del Analista Funcional como facilitador.
Estas reuniones involucran detalles técnicos y del negocio vitales a los efectos de la solución a desarrollar:

  • Requerimientos funcionales
  • Reglas de negocio asociadas
  • Interfaz de usuario
  • Métodos técnicos de implementación


En las reuniones de sincronización, el rol del Analista Funcional es diferente del que tiene en las de planificación. En las reuniones de planificación, el Analista Funcional definió y ejecutó una agenda, en las de sincronización el rol es el de asistir a los interesados en el proyecto y al equipo de desarrollo para determinar los requerimientos del sistema, con el propósito de construir los prototipos que conformen de manera incremental el sistema a desarrollar.

El Rol del Analista Funcional facilita lo anterior mediante la utilización de herramientas de Modelado del Negocio para identificar y analizar requerimientos de usuario, requerimientos del sistema y reglas de negocio:
  • Diagramas de Actividad - procesos manuales
  • Casos de Uso - requerimientos funcionales
  • Diagramas de Entidad-Relación
  • Diagramas de Transición de estados
  • Diagramas de clases - para implementaciones orientadas a objetos



La rigurosidad con la cual el Analista Funcional debe modelar el negocio es determinada por las necesidades del equipo de desarrollo. En lugar de realizar una documentación exhaustiva y detallada de los requerimientos como en el modelo en cascada (waterfall SDLC), el Analista genera la documentación "suficiente y necesaria" que permita que el equipo de desarrollo codifique los prototipos.


Conclusión

Mientras se van definiendo, priorizando, analizando y/o desarrollando las funcionalidades, el Analista Funcional se asegura que los interesados en el proyecto aprueben la solución final. El Rol del Analista Funcional podría ser llevado a cabo por un miembro del equipo de desarrollo, sin embargo, se debe considerar el riesgo que involucra que una persona menos entrenada y con menos experiencia en el Análisis Funcional sea la responsable de construir consenso entre los participantes. El nivel de productividad y consenso estará directamente relacionado con el uso efectivo de herramientas de Análisis Funcional.
Además, existe el riesgo de que los interesados en el proyecto y los desarrolladores se enfoquen en aspectos técnicos del prototipo en lugar de hacerlo en los requerimientos.

Es prudente evitar estos riesgos, y a los efectos de "asegurar" el éxito del equipo, la mejor práctica es que el rol del Analista Funcional se formalice en una persona que asista al equipo de desarrollo de software ágil.
Autor: Alejandro Grinsztajn

Fuente: Este artículo es un resumen y traducción del artículo de Mark A. Monteleone en www.batimes.com



La importancia de un buen análisis funcional.

Fuente: jummp.wordpress.com

De todos es sabido que cuanto antes se solucione un problema en un proyecto de desarrollo de software, menos coste tiene para el mismo y de ello salen beneficiados tanto proveedor como cliente.
Por ese motivo resulta esencial que un proyecto sea sólido desde la base, siendo la misma el análisis funcional, lo que hace que sea muy importante la figura del analista que es la persona o grupo de personas (si el proyecto es grande) que se tienen que encargar de entender, interpretar y traducir lo que el usuario demanda, sentando las bases de los posteriores procesos de diseño y construcción del sistema de información.
Hacer un buen análisis es una tarea bastante compleja, ya que resulta muy complicado obtener todos los requerimientos del usuario desde etapas muy tempranas, ya que por regla general el usuario empieza a descubrir el detalle de todo lo que quiere cuando empieza a utilizar el producto ya construido con ejemplos reales de su día a día de trabajo (también suelen comentar nuevos requisitos o enmendar requisitos previos, en otras etapas conforme se le vaya presentando la evolución del proyecto, de hecho no es malo que se corrijan, ya que cuanto más avanzado esté el proyecto, el esfuerzo de hacer los cambios es mucho mayor). De hecho es prácticamente inevitable no hacer evolutivos que solventen esos flecos que no se detectaron en análisis para dejar el producto lo más próximo posible a lo que los usuarios necesitan y demandan. Como consecuencia de lo anterior, y como es lógico, se puede considerar que un análisis funcional es más bueno conforme sea menor el número de ajustes que haya que hacer en etapas posteriores del proyecto.
Es importante matizar que un proyecto de desarrollo de software no es una barra libre y que es importante que el usuario conozca sus responsabilidades en el proceso de definición del sistema y que no se pueden estar cambiando de requisitos continuamente, como tampoco podría estar cambiando frecuentemente de opinión si le están construyendo una casa. Todo lo anterior además hay que compatibilizarlo con que todas las partes están interesadas en el que el proyecto vaya a buen término, por lo que tampoco es una buena política ser inflexibles en la modificación del catálogo de requisitos, porque si el resultado final no es el que quiere el usuario, el sistema de información tendrá muchas papeletas para no ser utilizado. Equilibrio complicado: evitar que los usuarios modifiquen continuamente requisitos y tener un poco de mano izquierda cuando se planteen esos cambios. Como ese equilibrio es complicado de mantener y es fuente frecuente de conflictos, hay que intentar que el análisis tenga la mayor calidad posible.
Hacer un análisis funcional por tanto es una tarea compleja, a lo que hay que sumar que en muchos casos hay que aprender mucho sobre el proceso de negocio que se pretende informatizar, para entender de mejor manera lo que el usuario demanda, ya que resulta todo más fácil si el lenguaje que se utiliza es el mismo. En muchas ocasiones esos procesos de negocio son tremendamente complejos y además se dispone también de poco tiempo para entenderlos, teniendo en cuenta que por regla general y como he comentado muchas veces en mi blog, los proyectos informáticos suelen estar infravalorados (por el que contrata y/o por el que es contratado (para conseguir el contrato)).
Dado que el análisis funcional consiste en abstraer un conjunto de necesidades de los usuarios es muy importante la implicación de los mismos y eso no siempre se consigue. Si los usuarios no están implicados, por muy buen analista funcional que tenga el proyecto, las probabilidades de que este salga mal crecen exponencialmente. Evidentemente un buen analista puede paliar esos huecos que deja el usuario e incluso conseguir una mayor participación de los usuarios, pero más tarde o más temprano los problemas aparecerán y al final siempre termina pagando el proyecto (en primera instancia) y el que lo desarrolla (en segunda). Por todo lo anterior, se puede pedir que un analista funcional aprenda un proceso de negocio complejo, que consiga extraer de los usuarios lo que buscan y necesitan y que además lo haga en un tiempo record, pero lo que no se le puede pedir es que haga magia y resuelva problemáticas que le trascienden, como el caso que he comentado de la inacción de los usuarios en determinados proyectos, siendo esa falta la implicación la primera causa de que un análisis no salga bien y por tanto una de las causas más importantes del fracaso de un proyecto y no se trata en este caso de tirar pelotas fuera y ponerme del lado de mis colegas de profesión, se trata de algo que he podido vivir en diferentes proyectos de manera muy directa.
Nadie es infalible y un analista funcional tampoco lo es. Habrá errores (independientemente de que la causa de los mismos sea provocada por circunstancias adversas en el proyecto o no), puede que en este proyecto sean muy pocos y que en otros sean mayores, por eso es importante que el analista lo tenga asumido desde un principio, como también lo es que de esos errores se debe aprender y que resultarán fundamentales en la formación del mismo. Al final esos errores terminan curtiendo y permiten que cada vez los análisis que se realicen sean mejores. Por tanto, la experiencia resulta importante. En cualquier caso, suponer un análisis perfecto es suponer que en un proyecto se dan circunstancias ideales y que todas las variables que pueden influir en que las cosas vayan mejor o peor, están todas a favor.
De todo lo comentado en los párrafos anteriores se extrae que es importante que un analista funcional sea un buen comunicador, primero con el usuario ya que resulta fundamental que el usuario conozca todo lo que hemos entendido y cómo se pretende llevar a cabo (no conseguir eso es ir a ciegas) y segundo con el equipo de proyecto ya que tiene que trasladar a documentación y hacerles entender la interpretación de lo que el usuario quiere y cómo lo quiere.
Un buen análisis funcional no asegura el éxito del proyecto, ya que la ejecución técnica del mismo también tiene un peso importante, pero lo que sí es seguro es que si el análisis funcional no es bueno, la ejecución técnica difícilmente puede salvar las deficiencias del mismo y tocará corregir el producto una vez construido y además, por regla general, en diferentes evoluciones, lo cual es muy costoso y tampoco asegura que ese árbol que empezó torcido, termine por enderezarse.



Actualidad y Tendencias: Analista (Funcional y de Testing).

Fuente: testingbaires.com

Actualidad y Tendencias: Analista (Funcional y de Testing) para proyectos SAP, Ágiles y WTF

Entiendo que la figura del “Analista Funcional” dentro de un proyecto, es aquella persona o grupo de personas que se ocupa/n de comprender, interpretar, y convertir la demanda o requerimiento del cliente o ‘usuario final’ en una especificación funcional, para permitir y facilitar que el desarrollador o equipo de desarrolladores construya el proceso de diseño y desarrollo de la solución informática, asi como también que el ‘probador’ o ‘tester’ pueda validar y verificar el desarrollo.
Hoy en día existen diferentes tipos de ‘Analistas Funcionales’ dependiendo del contexto de proyecto en el que se encuentre, ya que la diversidad de industrias requieren para sus soluciones, la ejecución de proyectos SAP,Ágiles ó Tradicionales/Modelo en cascada (Waterfall SDLC).
El DEBATE de este artículo lo pueden seguir en el grupo de discusión en Linkedin: TESTING & QA,
A continuación, expongo algunas de las funciones básicas que entiendo tienen los distintos tipos de Analistas Funcionales y luego, una serie de preguntas que procuraré encontrar respuestas, buscándolas en la net, o en libros, o bien, a partir de debates que genere en distintos foros.

Analista Funcional para proyectos SAP
Básicamente. algunas de sus funciones son:
  • Analizar especificaciones;
  • Preparar los casos de uso;
  • Analizar incidencias;
  • Documentar las soluciones a incidencias;
  • Ajustar configuraciones;
  •  Ejecutar pruebas unitarias;
  • Atender las consultas de usuarios;
  • Realizar actividades de soporte, mantenimiento correctivo y evolutivo de módulos implementados


Analista Funcional para proyectos Agiles
Básicamente. algunas de sus funciones son:
  • Traducir la visión del Dueño del Producto (Product Owner) a un Listado de Requerimientos (Backlog), generando la documentación suficiente y necesaria
  • Asegurar que se cumpla la visión y alcance del proyecto
  • Moderar y Facilitar las reuniones de planificación y revisión de cada iteración
  • Definir y ejecutar la agenda en las reuniones de planificación
  • Asistir a los stakeholders y desarrolladores para determinar los requerimientos, priorizar las funcionalidades y asi construir los prototipos
  • Asegurar la correspondencia entre las funcionalidades y las necesidades de negocio
  • Utilizar herramientas para el modelado de negocios
  • Buscar y Preocuparse por buscar la aprobación de la solución final


Analista Funcional para proyectos Tradicionales (Waterfall SDLC – Modelo en cascada)
Básicamente. algunas de sus funciones son:
  • Realizar tareas de relevamiento, análisis y diseño de sistemas
  • Asistir al desarrollador en el entendimiento de los requerimientos
  • Documentar de forma exhaustiva y detallada los requerimientos contenidos en las especificaciones del cliente 
  • Relevar los datos del proyecto
  • Diseñar las entradas, salidas, archivos del proyecto
  • Asistir al tester en el entendimiento de los requerimientos
  • Controlar el cumplimiento del plan de proyecto


  • ¿En qué proyecto, el Analista Funcional puede estar actuando mejor como ‘Facilitador’?
  • ¿En qué proyecto, el Analista Funcional puede ser ser más absorbido por el equipo de desarrollo?
  • ¿Qué riesgos asociados debe considerar el Analista Funcional en cada uno los proyectos?
  • ¿Cómo aumenta el Analista Funcional su nivel de productividad y consenso en cada uno de los proyectos?
  • ¿Qué tipo de Analista Funcional puede comprender mejor la denominada ‘Big Picture’ del proyecto?
  • ¿Cuál es el futuro del Analista Funcional en cada uno de estos proyectos?
  • ¿Cómo interactúa con el ‘Analista Funcional’, el ‘Analista Tester’ ó ‘Tester’ en cada uno de estos proyectos?
  • ¿Cuáles son las funciones básicas de un ‘Analista Tester’ ó ‘Tester’ en cada uno de estos proyectos?
  • ¿Cuál es el futuro del ‘Analista Tester’ en cada uno de estos proyectos?
Fuentes:



¿El Analista Funcional debe ser Técnico?.

Fuente: testingbaires.com


El siguiente texto fue extraído -previa autorización de su administrador- de uno de los debates que inició Daniel Mónaco desde su grupo de discusión en Linkedin.

Sé que con este tema hay muchas opiniones diferentes.
Se me ocurren hacer las siguientes divisiones:
1. Analista funcional con estudio en el Area de Sistemas
2. Analista funcional con estudio en otras Areas.
3. Analista de Negocio
4. Usuario Clave


1. Analista funcional con estudio en el Area de Sistemas:
Este profesional conoce los fundamentos de Programación, Base de Datos, Sistemas Operativos, etc. Estos conocimientos enriquecen al Analista y les permite ser bastante independiente para poder discriminar lo que el Sistema puede llegar a ser o que no, en base a los Requerimientos del Cliente. Además le permite trabajar no sólo en la etapa de Análisis, sino también en la de Diseño. Un Analista no debe quedarse sólo con lo que su rol Funcional le demande; debe conocer la tecnología a implementar o implementada, el Modelo de Clases y el Modelo de Datos que tendrá o tiene el Proyecto.
A este rol muchas veces se les denomina Analista funcional / técnico y tiene la responsabilidad de ser el nexo entre los Analistas y los Desarrolladores/Programadores del Sistema.
En el caso que un Proyecto sólo pueda contar con 1 Analista, me parece que este es el perfil más indicado.
2. Analista funcional con estudio en Areas que no son de Sistemas:
Generalmente este perfil tiene conocimiento en el negocio o puntualmente en el Análisis del Requerimiento o en el Análisis del Proceso.
Es muy útil y depende mucho de la experiencia que tenga el profesional.
Estos perfiles deben ser acompañados con perfiles de Analistas afines a Sistemas para complementarse.
Es bueno tener este perfil cuando se cuenta en el Proyecto con un Grupo de Analistas.

3. Analista de Negocio:
Este es un perfil relativamente nuevo y esta muy cerca de ser un usuario clave.
Puede tomar tareas de interprete entre el Cliente y el Analista funcional y ayuda puntualmente en el Análisis del Requerimiento.
Este perfil es recomendado en Proyectos grandes y donde el entendimiento del Negocio y de los Procesos sea complejo. Es un perfil requerido al utilizar metodología de
Proceso Unificado (UP).

4. Usuario Clave:
Este es un usuario que por su experiencia tiene un buen conocimiento del negocio y puede determinar las necesidades y el deseo del Cliente. Para algunas metodologías de Programación Extrema (XP), este perfil reemplaza al Analista funcional y es vital su participación 100% en el Proyecto. El problema que ocurre que al ser un Usuario clave, el Area que presta a este Usuario no puede tomarse el lujo de dejarlo participar enteramente en el Proyecto. Creo también que es un perfil complementario. Muchas empresas cometen el error al pensar que un Usuario Clave puede hacer el trabajo de un Analista Funcional por conocer el negocio. Son dos cosas distintas, conocer el negocio es sólo una parte de las tareas que debe realizar un Funcional.
En resumen, creo que un Analista de perfil de tipo 1 es indispensable en un Proyecto y los demás tipos deben complementarse y trabajar en conjunto con el primero. De no tenerse un Analista del tipo 1, tiene que aparecer la figura de un Analista puramente Técnico o un Arquitecto o un Responsable del Diseño del Sistema para acompañar a los Analistas de los otros tipos en las tomas de decisiones y en los análisis con los clientes.

Linkedin Group: http://www.linkedin.com/groups?mostPopular=&gid=3123613
Public Profile: http://ar.linkedin.com/pub/daniel-m%C3%B3naco/6/251/a67


¿Dónde esta el límite entre un ‘Analista de Testing’ y un ‘Analista Funcional’?

Fuente: testingbaires.com

El ‘Analista Funcional’ normalmente, analiza especificaciones (funcionales y/o técnicas) cuando participa en una estimación preliminar, un nuevo desarrollo o una modificación del código como consecuencia de una anomalía detectada por el cliente.
Luego de este análisis y en alguna instancia dentro del ciclo de desarrollo (antes o después de su finalización), deberá probar (testear). (*)
Por otra parte, ‘en la vereda de enfrente’ y hasta se podría decir, casi al mismo tiempo (por lo menos así se dá en algunos proyectos), el ‘Analista de QC (testing)’ también analiza las especificaciones, y en el caso de no estar diseñados los casos de uso, se los estará planteando él mismo para poder generar más tarde, los diferentes casos de prueba. En otras ocasiones, levanta el ‘producido’ por parte del ‘Analista Funcional’, lo revisa y genera los casos de prueba, es decir, en principio la matriz de cobertura de prueba.
Luego de este análisis y en alguna instancia dentro del ciclo de desarrollo (antes o después de su finalización), deberá tester. (*)
Ahora bien, es aquí donde planteo los siguientes interrogantes:
1. con qué metodología y técnica trabaja el ‘Analista Funcional’ al momento de realizar sus pruebas?
2. hasta que profundidad de prueba llega?
3. hay un momento en el que participa junto con el ‘Analista de QC’ en las pruebas?
4. en qué momento el ‘Analista de QC’ inicia sus pruebas?
5. hay un momento en el que participa junto con el ‘Analista Funcional’ en las pruebas?
6. el ‘Analista Funcional’ depende en algún momento del ‘Analista de QC’?
7. el ‘Analista de QC’ depende en algún momento del ‘Analista Funcional’?

Para leer los comentarios del debate iniciado en el grupo linkedin: TESTING & QA, acceder haciendo clic AQUI

Comentario dejado por un miembro:
“El analista Funcional es el que se encarga del relevamiento primario y posterior diseño de casos de uso (abarca diferente fases del diseño UML). En cambio el analista de Testing se encarga de diseñar los casos de prueba los cuales se fundamentan en la especificación lograda por los analistas Funcionales. Ambos roles son diferentes y no deberían solaparse, pero si tener un contacto permanente. Los analistas Funcionales no deberían intervenir directamente en el proceso de pruebas de integracion.”



Análisis Funcional – Requisitos del mercado.

Fuente: testingbaires.com

El siguiente, es parte de un debate iniciado en el grupo de discusión en linkedin: Análisis Funcional.
 
Requisitos del mercado

Estuve haciendo un estudio de las ofertas laborales en la Argentina y obtuve
los siguientes requisitos más pedidos para un puesto de Analista Funcional:


  • Dominio de Base de Datos relacionales
  • Conocimiento de lenguajes SQL (Transact-SQL, PL-SQL)
  • Habilidades de Gestión
  • Dominio de idioma inglés
  • UML
  • metodologías: Agiles (UP, Scrum, XP), CMMI
  • Utilización de métricas para elaborar estimaciones
  • Elaborar Casos de Prueba
  • Análisis y Diseño de Procesos
  • Manejo de alguna aplicación de Gestión de Proyecto (preferentemente MS Project).
  • Conocimiento del Negocio
  • Capacitación a Usuarios

Linkedin Group: Análisis Funcional
Public Profile: Daniel Mónaco

     

No hay comentarios:

Publicar un comentario en la entrada