Este documento resume la sección 4 de la Guía Práctica del Análisis de Negocio publicada por el PMI. La sección se enfoca en la elicitación y análisis de requerimientos. Explica que la elicitación implica extraer información de los interesados para luego analizarla y derivar los requerimientos de la solución. También describe diferentes técnicas para la planificación, ejecución y documentación de las actividades de elicitación y análisis, así como la importancia de validar y verificar los requerimientos.
Identificación y nombre del proyecto
Descripción del proyecto
Fecha de inicio programada y real del proyecto
Fecha de término programada y real del proyecto
Descripción breve de entregables concluidos
Relación documental de la administración del proyecto
Identificación y nombre del proyecto
Descripción del proyecto
Fecha de inicio programada y real del proyecto
Fecha de término programada y real del proyecto
Descripción breve de entregables concluidos
Relación documental de la administración del proyecto
Como determinar cuales son las partes interesadas que son pertinentes al sistema de gestión de la calidad y los requisitos pertinentes de las partes interesadas, Se adjuntan Relaciones: (PODER/INTERÉS) - (COOPERACIÓN / IMPACTO) -(PODER/URGENCIA/-LEGITIMIDAD) como funciona y como se aplican.
https://edu.symbaloo.com/mix/pleayudascalidad
(Entorno Personal de Aprendizaje)
http://ayudascalidad.blogspot.com.co/
(Blogger Ayudas Calidad)
https://www.youtube.com/watch?v=ABLXLeeqWJ8&list=PLmDSY-JAYgtf1BHB7Id8I5zPie_J4ntWe
(Lista de reproducción Vídeos en YouTube – Ayudas Calidad)
https://www.youtube.com/channel/UCcO2zl8wUFfZxGBlXoqu5mw
(Canal de YouTube – Ayudas Calidad)
El tema de Lecciones Aprendidas en el transcurso de la ejecución de proyectos se nombra con frecuencia pero no hay demasiado escrito al respecto. Esta presentación pretende dar un paso inicial hacia la creación de un proceso dentro de la organización y brinda algunas pautas que podrán ser de utilidad para los Directores de Proyectos.
La industria cubana del software está llamada a convertirse en una significativa fuente de
ingresos nacional. Este reto demanda una sólida formación de los profesionales
informáticos y exige a las universidades cubanas garantizar que los egresados dominen y
apliquen consistentes y novedosas prácticas en el desarrollo de software. La gestión de
riesgos constituye uno de los procesos medulares en el empeño de determinar
continuamente qué puede ir mal en un proyecto informático: cuáles son los riesgos que lo
afectan, sus posibles consecuencias y estrategias de respuesta. Su introducción orgánica en
la formación y producción mejorará la preparación integral del profesional y la calidad de
los procesos y productos de software. En este artículo se presentan principios a tener en
cuenta para la incorporación de la gestión de riesgos en la formación de los profesionales
de la informática, y se describe la experiencia de su aplicación en la Universidad de las
Ciencias Informáticas como complemento y apoyo de la implementación del Modelo de
Gestión de Riesgos para Proyectos de Desarrollo de Software (MoGeRi).La industria cubana del software está llamada a convertirse en una significativa fuente de
ingresos nacional. Este reto demanda una sólida formación de los profesionales
informáticos y exige a las universidades cubanas garantizar que los egresados dominen y
apliquen consistentes y novedosas prácticas en el desarrollo de software. La gestión de
riesgos constituye uno de los procesos medulares en el empeño de determinar
continuamente qué puede ir mal en un proyecto informático: cuáles son los riesgos que lo
afectan, sus posibles consecuencias y estrategias de respuesta. Su introducción orgánica en
la formación y producción mejorará la preparación integral del profesional y la calidad de
los procesos y productos de software. En este artículo se presentan principios a tener en
cuenta para la incorporación de la gestión de riesgos en la formación de los profesionales
de la informática, y se describe la experiencia de su aplicación en la Universidad de las
Ciencias Informáticas como complemento y apoyo de la implementación del Modelo de
Gestión de Riesgos para Proyectos de Desarrollo de Software (MoGeRi).3. La Gestión de Riesgos: una necesidad en el entorno docente y
productivo de las universidades cubanas
Tanto sea para un análisis de negocios, como para la planificación y ejecución de un proyecto, la gestión de los interesados es siempre una actividad central y un gran desafío para el gerente.
Toda persona o agente, que se vea afectado directa o indirectamente, pasa a ser en forma inmediata parte interesada del proyecto o iniciativa. La importancia de la elicitación temprana de todo requisito, está íntimamente vinculada con la identificación temprana de interesados también.
Como determinar cuales son las partes interesadas que son pertinentes al sistema de gestión de la calidad y los requisitos pertinentes de las partes interesadas, Se adjuntan Relaciones: (PODER/INTERÉS) - (COOPERACIÓN / IMPACTO) -(PODER/URGENCIA/-LEGITIMIDAD) como funciona y como se aplican.
https://edu.symbaloo.com/mix/pleayudascalidad
(Entorno Personal de Aprendizaje)
http://ayudascalidad.blogspot.com.co/
(Blogger Ayudas Calidad)
https://www.youtube.com/watch?v=ABLXLeeqWJ8&list=PLmDSY-JAYgtf1BHB7Id8I5zPie_J4ntWe
(Lista de reproducción Vídeos en YouTube – Ayudas Calidad)
https://www.youtube.com/channel/UCcO2zl8wUFfZxGBlXoqu5mw
(Canal de YouTube – Ayudas Calidad)
El tema de Lecciones Aprendidas en el transcurso de la ejecución de proyectos se nombra con frecuencia pero no hay demasiado escrito al respecto. Esta presentación pretende dar un paso inicial hacia la creación de un proceso dentro de la organización y brinda algunas pautas que podrán ser de utilidad para los Directores de Proyectos.
La industria cubana del software está llamada a convertirse en una significativa fuente de
ingresos nacional. Este reto demanda una sólida formación de los profesionales
informáticos y exige a las universidades cubanas garantizar que los egresados dominen y
apliquen consistentes y novedosas prácticas en el desarrollo de software. La gestión de
riesgos constituye uno de los procesos medulares en el empeño de determinar
continuamente qué puede ir mal en un proyecto informático: cuáles son los riesgos que lo
afectan, sus posibles consecuencias y estrategias de respuesta. Su introducción orgánica en
la formación y producción mejorará la preparación integral del profesional y la calidad de
los procesos y productos de software. En este artículo se presentan principios a tener en
cuenta para la incorporación de la gestión de riesgos en la formación de los profesionales
de la informática, y se describe la experiencia de su aplicación en la Universidad de las
Ciencias Informáticas como complemento y apoyo de la implementación del Modelo de
Gestión de Riesgos para Proyectos de Desarrollo de Software (MoGeRi).La industria cubana del software está llamada a convertirse en una significativa fuente de
ingresos nacional. Este reto demanda una sólida formación de los profesionales
informáticos y exige a las universidades cubanas garantizar que los egresados dominen y
apliquen consistentes y novedosas prácticas en el desarrollo de software. La gestión de
riesgos constituye uno de los procesos medulares en el empeño de determinar
continuamente qué puede ir mal en un proyecto informático: cuáles son los riesgos que lo
afectan, sus posibles consecuencias y estrategias de respuesta. Su introducción orgánica en
la formación y producción mejorará la preparación integral del profesional y la calidad de
los procesos y productos de software. En este artículo se presentan principios a tener en
cuenta para la incorporación de la gestión de riesgos en la formación de los profesionales
de la informática, y se describe la experiencia de su aplicación en la Universidad de las
Ciencias Informáticas como complemento y apoyo de la implementación del Modelo de
Gestión de Riesgos para Proyectos de Desarrollo de Software (MoGeRi).3. La Gestión de Riesgos: una necesidad en el entorno docente y
productivo de las universidades cubanas
Tanto sea para un análisis de negocios, como para la planificación y ejecución de un proyecto, la gestión de los interesados es siempre una actividad central y un gran desafío para el gerente.
Toda persona o agente, que se vea afectado directa o indirectamente, pasa a ser en forma inmediata parte interesada del proyecto o iniciativa. La importancia de la elicitación temprana de todo requisito, está íntimamente vinculada con la identificación temprana de interesados también.
Arquitectura empresarial - Enfoque sistémico para el desarrollo de sistemas d...Julio Vasquez Paragulla
Conferencia magistral por la semana de la Facultad de Ciencias e Ingeniería, a cargo del Msc. Daniel Llanos Panduro en el auditorio de la Universidad de Ciencias e Ingeniería. 12 mayoo 2015.
Un resumen de los modelos, principios, inventarios, y proyectos que fueron descubiertos y creados mediante el uso de los conceptos más importantes de la arquitectura empresarial en una interpretación local.
La Arquitectura Empresarial es una disciplina básica para la gerencia o gestión de la información de las organizaciones. Esta determina la alineación entre el negocio y las tecnologías de información para incrementar la productividad de la empresa y la satisfacción de sus empleados y principalmente de sus clientes.
1 Introducción a la Arquitectura EmpresarialMatersys
Presentación del doctor Adolfo De Unánue en el taller Modelando su negocio mediante una arquitectura empresarial realizado el 19 de mayo en la ciudad de México con patrocinio de IBM y Matersys
La arquitectura empresarial y el análisis de negociosSergio Salimbeni
La arquitectura empresarial modela la empresa para mostrar cómo se cumplen las actividades estratégicas de los principales interesados, y para apoyar los esfuerzos de transformación de los negocios en curso.
La arquitectura empresarial proporciona descripciones y vistas arquitectónicas, conocidas como planos, para proporcionar una comprensión común de la organización con el propósito de alinear los objetivos estratégicos con las demandas tácticas. La disciplina de la arquitectura empresarial aplica el pensamiento analítico y los principios arquitectónicos a nivel empresa. Las soluciones pueden incluir cambios en el modelo de negocio, en el modelo operativo, en la estructura organizacional, o impulsar otras iniciativas.
El Análisis de Negocios es la práctica de desarrollar cambios en una empresa mediante la definición de necesidades (oportunidades y / o problemas) y la recomendación de soluciones que aporten valor a las partes interesadas.
El Análisis de Negocios permite a una organización articular las necesidades y la justificación del cambio, así como diseñar y describir soluciones que puedan aportar valor.
El Análisis de Negocios se desarrolla en una variedad de iniciativas dentro de una empresa. Las iniciativas pueden ser estratégicas, tácticas u operacionales.
El Análisis de Negocios puede desarrollarse dentro de los límites de un proyecto, o durante la evolución y la mejora continua de la empresa, es decir en operaciones.
El Análisis de Negocios se puede utilizar para entender el estado actual de una organización, definir su estado futuro, y determinar las actividades necesarias para pasar del estado actual al futuro.
Informes Gerenciales y Contables. Diferencias
Datos, Información y Toma de decisiones
Relevamiento preliminar para preparación de informes
Técnicas de relevamiento de información
Validación de datos relevados
Almacenamiento de la Información
Cuadros de Control
Uso de herramientas y técnicas en planilla de cálculo
Informes Gerenciales
Presentación
Actualización y Mantenimiento.
Best Practices for BA: Using enterprise architecture to deliver the right sol...Sergio Luis Conte
How to deliver the right solution is the "Business Analyst Dilema". This article talk about how to do that in a simple way using Enterprise Architecture as a guide.
Best Practices for BA: Using enterprise architecture to deliver the right sol...
BA by PMI - Seccion 4 - Elicitacion y Analisis de Requrimientos
1. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 1
BA by PMI® – Entendiendo la Guía Práctica del Análisis de Negocio
Sección 4: Elicitación y Análisis de Requerimientos (Requirements
Elicitation and Analysis)
Introducción.
La intención de esta serie de artículos es divulgar la Guía Práctica del Análisis de Negocio (“La
Guía”, en los párrafos siguientes) recientemente publicada por el PMI®. Esta organización
reconoce el crecimiento de la profesión del Análisis de Negocio y su importancia como factor
crítico de éxito de cada proyecto o programa que las organizaciones emprenden para solucionar
sus problemas de negocio satisfaciendo sus necesidades de transformación. La Guía incluye
también puntos aclaratorios respecto de cómo el Analista de Negocio (“BA” en lo que sigue) y
Administrador de Proyectos (“PM” en lo que sigue) colaboran para lograr los objetivos del
emprendimiento.
4.1. Resumen.
Según La Guía la Planificación del Análisis de Negocio consiste en el trabajo iterativas relacionadas
con definir planificar, preparar y realizar las actividades de elicitar información desde los
interesados, analizar y documentar los resultados y definir los requerimientos con suficiente
detalle para habilitar la definición y selección de la solución esperada. El BA usa un número de
técnicas de elicitación y aplica un número de modelos de análisis que soportarán las actividades de
elicitación y análisis.
4.2. Qué significa elicitar información.
Elicitar es el acto de tomar información desde los interesados y otras fuentes. Esto implica elicitar
información referente a las causas del problema de negocio o las razones para alcanzar una
oportunidad como así también toda la información necesaria que será utilizada para derivar con
suficiente detalle los requerimientos que permitan desarrollar e implementar la solución.
La Guía hace mención respecto que el proceso de elicitación es más que recolectar (collect) o
tomar (gather) requerimientos. El término “tomar” implica que los interesados tienen los
requerimientos listos para ser tomados y especificados y esto no es así. La Guía claramente
menciona que los requerimientos no están listos y esperando en la mente de los interesados o
dentro de documentos del negocio. Dice que los interesados tienen necesidades que, además,
generalmente no pueden expresar con claridad. Conocen que tienen un problema, pero no saben
exactamente cuál es. Conocen que deben tomar ventaja de una oportunidad, pero no saben como
empezar.
Nota del autor: la importancia del término “elicitar” es crítica. Implica que el Analista de Negocio
tiene la responsabilidad de extraer toda información desde los interesados y cualquier otra fuente
para luego convertirla en requerimientos. Este es un cambio radical en la forma de pensar el
2. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 2
trabajo relacionado a la problemática de extraer información para convertirla en los
requerimientos de la solución que se ajusta a las necesidades estratégicas de la organización.
4.3. Planear la Elicitación.
La Guía hace referencia a que gran parte de esta actividad se realiza durante la construcción del
Plan del Análisis de Negocio (Sección 3 de La Guía).
El plan de elicitación no es un entregable ya que es parte del Plan del Análisis de Negocio pero
debe incluir todo lo necesario para:
Entender qué información hay que elicitar.
Dónde encontrar la información.
o Se hace mención a otro concepto crítico: los componentes de la arquitectura
empresarial. Dentro de esta se pueden encontrar todos los documentos que dan
origen y mantienen la estructura de la organización.
Cómo obtener la información.
o En la sección 4.5.5 se listan varias técnicas que pueden utilizarse. Alguna de las
señaladas son:
Brainstorming, Análisis de Documentos, Workshops de Facilitación, Focus
Groups, Entrevistas, Observación, Prototipos, Cuestionarios.
La secuencia de actividades de elicitación junto con tiempos y recursos necesarios.
4.4. Prepararse para la Elicitación.
En este punto, se muestra la importancia de estar preparado para la actividad de elicitación.
Alguno de los puntos a tener en cuenta son 4.4.1. Determinar los objetivos, 4.4.2. Determinar los
participantes, 4.4.3. Determinar las preguntas (en caso que aplique para la técnica a utilizar).
4.5. Realizar la Actividad de Elicitación.
Según La Guía la actividad debe ser planificada y consta de cuatro partes principales:
Introducción: pone en claro el objetivo, el tiempo y el propósito.
Cuerpo: se realizan las preguntas. Según la guía los tipos de preguntas a utilizar pueden ser
Open-ended (la forma de respuesta la elige el entrevistado), Close-ended (la forma de
respuesta está limitada a seleccionar opciones), Contextual (la respuesta se limita al
contexto) y Context-free (la respuesta no tiene un contexto definido).
Cierre. revisión final de la sesión.
Seguimiento. la información se consolida y se confirma con los participantes.
4.6. Documentar la Salida de las Actividades de Elicitación.
Los documentos a generar dependen de varios factores pero se puntualiza que los resultados
deben documentarse formal o informalmente.
3. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 3
4.7. Completar la Elicitación.
La Elicitación debe considerarse una actividad progresiva de elaboración de información. La
información se elabora luego de analizar el resultado de la elicitación. Puntos tales como la
aprobación de los resultados de la elicitación, haber alcanzado el objetivo de la elicitación, haber
identificado claramente la solución pueden considerarse para declarar finalizada la actividad.
4.9. Analizar los Requerimientos.
La Guía define “Análisis” como el proceso de examinar, disgregar y sintetizar la información para
entenderla, completarla y mejorarla. El Análisis involucra el trabajo progresivo e iterativo con la
información para abstraer distintos niveles de detalle principalmente para proveer estructura a los
requerimientos y la información relacionada.
Hay que realizar la actividad de planeación del análisis definiendo que actividades y técnicas son
útiles y cuándo deben ser utilizadas. Muy importante es decidir qué tipos de modelos van a
utilizarse para realizar el análisis.
El BA trabaja con diferentes tipos de información pero principalmente el análisis se realiza sobre
los resultados de la elicitación1
. Si bien dependerá del enfoque o ciclo de vida utilizado en general
las tareas de elicitación y análisis son iterativas.
4.10. Modelar y Refinar los Requerimientos.
Para La Guía modelo significa la representación visual de la información, abstracta y específica,
que cumple con un conjunto de guías con el objetivo de presentar la información en forma
concisa.
La Guía hace mención a diferentes tipos de modelos, a saber:
Modelo de Alcance. Estructuran y organizan todo lo relativo a los límites del dominio.
Modelo de Proceso. Describen los procesos y la interacción de los interesados.
Modelo de Reglas. Describen conceptos y comportamientos relacionados con políticas.
Modelo de Datos. Documentan los datos utilizados en los procesos.
Modelo de Interfaces. Describen el sistema y sus relaciones.
La Guía menciona que la selección del modelo dependerá de factores tales como la metodología a
utilizar, las características del proyecto, el ciclo de vida del proyecto y el nivel de abstracción.
Las secciones 4.10.7 a 4.10.11 describen en detalle los modelos y las distintas herramientas que
pueden utilizarse para trabajar con ellos.
4.11. Documentar los Requerimientos de la Solución.
Según La Guía, luego de analizar toda la información resultado de la elicitación el analista de
negocio documenta los requerimientos resultantes en algún formato, dependiendo de la
1
La Guía deja implícito que los requerimientos se obtendrán luego de analizar el resultado de la elicitación. Lo mismo puede verse en
4.11.
4. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 4
organización, las necesidades del proyecto y el ciclo de vida del proyecto. El BA prepara el paquete
de requerimientos de manera tal que el equipo que genera la solución entienda claramente el
alcance de la solución y el problema u oportunidad de negocio al que está dirigida.
Dentro de la documentación propuesta La Guía hace mención a:
Documento de Requerimientos del Negocio. Mostrando claramente el problema u
oportunidad y la razón que impulsa a generar la solución.
Documentación de la Solución. Todo lo necesario y previamente definido para que la
solución pueda ser generada por el equipo seleccionado durante el proyecto definido.
La Guía hace clara mención a que los requerimientos del producto son responsabilidad del BA
mientras que los requerimientos del proyecto son responsabilidad del PM.
Los supuestos y restricciones deben ser documentados dentro de la especificación de
Requerimientos. El BA documenta las restricciones del producto y en caso de encontrar
restricciones del proyecto debe documentarlas y entregarlas al PM.
La Guía expresa también varios lineamientos que pueden ayudar como complemento sobre la
escritura de los requerimientos y su verificación mostrando que adhieren a los estándares de la
IEEE. También resalta la importancia de la priorización y de la documentación con técnicas
relacionadas al mundo de la tecnología y el software tales como Casos de Uso o Historias de
Usuario.
4.12. Validar Requerimientos.
La Guía define la validación como la garantía de que un producto, servicio o sistema cumple con
las necesidades del cliente y otros interesados. En Análisis de Negocio la validación de
requerimientos es el proceso de asegurar que los requerimientos muestran las intenciones y
expectativas de todos los interesados. También se lo conoce con el nombre de “Confirmar los
Requerimientos”.
También define el concepto de “confirmación continua” diciendo que, teniendo en cuenta que
confirmar no es lo mismo que aprobar, la confirmación puede realizarse toda vez que los
requerimientos son escritos en algún lugar y puestos a consideración de los interesados o todo
aquel que pertenezca al equipo de generación de la solución. Confirmar los requerimientos
significa obtener desde los interesados el acuerdo sobre que la solución alcanza los objetivos.
La técnica propuesta es el “requirements walkthrough” que permite revisar en conjunto los
requerimientos con los interesados.
4.13. Verificar Requerimientos.
La Guía define la verificación como el proceso de revisar los requerimientos en busca de errores o
problemas de calidad. Verificación debería ocurrir previa a la Validación. La Verificación se realiza
con los integrantes del equipo que genera la solución para asegurar que los requerimientos
cumplen con los estándares de calidad definidos.
5. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 5
La Guía define dos procesos de verificación:
Peer Review. Se realiza con otros pares del BA que conocen los estándares de calidad
definidos.
Inspection. Con la utilización de un checklist se verifica que los requerimientos
especificados en el documento a inspeccionar cumplen con los atributos señalados en el
checklist.
4.14. Sesiones de Aprobación.
En el final, los requerimientos deben ser aprobados formalmente. Según La Guía esta aprobación
formal podría ser un proceso automático. Los conflictos podrían ocurrir en este punto y a lo largo
de la Elicitación y el Análisis y es por eso que, en la sección 4.15, se expresa claramente que es
responsabilidad del BA resolverlos. Tres técnicas (Delphi, Multi-Voting y Ranking por Pesos) son
propuestas por La Guía como buenas herramientas para resolver y anticipar los conflictos.
Conclusión.
En esta sección puede verse que el PMI® agrega una importante consideración cuando de
requerimientos se trata: los requerimientos surgirán luego de analizar la información extraída
desde los interesados o desde cualquier otro tipo de fuente. Y muestra también la clara diferencia
entre requerimientos del proyecto y del producto, qué rol tiene responsabilidad sobre cada uno, y
la importancia de dos tareas críticas tales como la verificación y la validación.
Esta sección de La Guía está en línea con el Área de Conocimiento 3-Elicitation y 6-Requirements
Analysis de la Guía BABOK® del IIBA®. El lector encontrará, en caso de comparar ambas guías, que
esta última es mucho más consistente en puntos tales como las técnicas y métodos para encontrar
las necesidades del negocio. Vale aclarar que el PMI® ha señalado que esta es la primera versión
de La Guía y que sufrirá evoluciones.
6. 4 de Febrero de 2015
www.bawarp.com
BA by PMI – Entendiendo la Guía Práctica del Análisis de Negocio Sergio Luis Conte
P a g e | 6
ABOUT THE AUTHOR
Sergio Luis Conte, República Argentina
Sergio Luis Conte es Ph.D in Software Engineering egresado de la
Universidad Cargnegie Mellon, USA.
También obtuvo su título de Licenciado en Sistemas de la Universidad CAECE
y realizó estudios de Magister en Administración y Dirección Empresarial en
la Facultad de Ingeniería de la UBA, en Ingeniería de Software en la
Universidad CAECE y en Ingeniería del Conocimiento en el ITBA.
Actualmente trabaja en PepsiCO en el GPMG (Global Project Management
Group) como responsable de Programas de Transformación e Innovación
para Latino America.
Ha desarrollado el E2A Framework - NOELIA Method® utilizado en
organizaciones de todo el mundo y actualmente en PepsiCO.
A dictado conferencias en varios países de Latino América, Europa y en
Estados Unidos y es profesor en la Escuela de Negocio de varias
Universidades de Argentina y el exterior. Fué el primer Latino Americano en
ser invitado a dictar una conferencia en la “2012 ProjectWorld® & World
Congress for Business Analysts® Conference (www.projectworld.com)”
Sergio posee las certificaciones PMP®, PMI-PBA® y PMI-ACP® del PMI®,
CBAP® del IIBA® y DSDM AP&Coach (DSDM Agile Method).
Con el PMI® y el IIBA® y el DSDM Consortium® ha desarrollado y desarrolla
las siguientes actividades:
Reviewer PMI´s PMBOK 2008 and 2012
Co-Author PMI´s PMBOK Software Extension
Co-Author IIBA´s BABOK 2003 and 2013
Co-Author DSDM Method version 1 and 2
Subject Matter Expert, Quality Assurance, Examination for PMI´s
Certification Credentials.
En su faz personal, fué jugador de tenis de la ATP y posee la matrícula
profesional Level 1 de la ITF como Profesor y Entrenador de Tenis.
Para más información sobre sus antecedentes puede consultar:
http://ar.linkedin.com/pub/sergio-luis-conte/19/381/858