2010

Diego Farias - dfarias2004@gmail.com,

Juan Pablo Juan Delpino - juan.p.delpino@gmail.com,
Fernando Garcia - fernando.d.garcia@gmail.com,
Federico Repond - frepond@gmail.com,
Marcelo Samia - msamia@gmail.com

[METODOLOGÍAS ÁGILES Y EL
CUERPO DE CONOCIMIENTO
(PMBOK)]
El presente trabajo muestra los acuerdos y desacuerdos entre el PMBOK y las metodologías ágiles
Resumen (Abstract)
Desde hace unos años el uso de metodologías ágiles para el desarrollo de proyectos se fue
incorporando como una herramienta estándar para la creación de software. Sin embargo, estas no
parecen estar incluidas como una parte del manejo del proyecto descripto como cuerpo de
conocimiento o pmbok por estar íntimamente ligadas al proceso de desarrollo en sí mismo. Este
documento analiza las diferentes posturas respecto a la convivencia que estas dos herramientas
tienen en la actualidad y analiza cómo una metodología ágil en particular, Iconix, utilizada en conjunto
con otra herramienta llamada Léxico Extendido del Lenguaje pueden incluirse como parte del ciclo de
vida de un proyecto a partir del análisis de los requerimientos.

Introducción
A medida que se leen diferentes publicaciones es fácil distinguir dos posturas bien enfrentadas,
aquellos que apoyan las metodologías ágiles y los que lo hacen con la guías del pmbok. Es notorio
que se fuerce una comparación entre ambas ya que no son equiparables puesto que el pmbok es una
guía, en el sentido amplio de la palabra, de cómo llevar adelante proyectos, no una metodología de
cómo hacerlo. Esto queda claro cuando las guías del pmbok se aplican a proyectos que no tiene nada
que ver con el software, como los de la industria de la construcción [1]. Otra notoria asociación es la
de considerar al pmbok relacionado directamente con proyectos en cascada, cuando en el apartado
2.2 del mismo se define la interacción con los stakeholders y la el formato iterativo que tiene el
desarrollo de un proyecto [2]. Más aún, desde hace más de diez años se tiene en consideración
metodologías “ágiles” como “Rapid Throwaway Prototypes”, “Incremental Development” o
“Evolutionary Prototypes”, para citar algunos, que se comparan con los proyectos en cascada [3]. Por
otra parte, es en este punto también donde se enfatiza la colaboración con los stakeholders, su
participación constante y las iteraciones a partir de dicha colaboración [4]. Se pueden citar más
ejemplos que apoyen que las comparaciones entre ambos no son muy acertadas y la razón de esto
es que el pmbok es un framework y no una metodología. Entonces la pregunta que nace
inmediatamente es ¿las metodologías ágiles tienen lugar dentro de este framework?, y si es así,
¿cómo lo tienen?

¿Tiene sentido manejar un proyecto de software con el pmbok?

Si bien esta pregunta puede parecer extraña hay fundamento para formularla. Las metodologías
ágiles han tenido mucho éxito respecto de las consideradas tradicionales (pmbok) y su punto de
lanzamiento fueron, por mucho, los proyectos Web. Según mediciones del año 2003, aquellos que
adoptaron metodologías ágiles reportaron:

 93% indico una mejora en la productividad

 88% fundamentó que la calidad de las aplicaciones mejoró
 83% experimentó mejoras en la satisfacción del negocio con el software

Estas metodologías, notablemente, promueven técnicas de gestión muy diferentes a las tradicionales,
como ser:

 No intentar terminar rápidamente los requerimientos anticipadamente en el proyecto

 Promover la incorporación de requerimientos de cambio a lo largo del ciclo de vida del
proyecto
  Menos énfasis en la rigidez del planeamiento anticipado

Sin embargo a pesar que los números favorecen a las metodologías ágiles las membrecías al PMI se
incrementa un 20% anual [5]. Esto se debe a
que el cuerpo de conocimientos incorpora en su
framework la experiencia de campo de muchos
profesionales y su “correcta aplicación” en un
proyecto garantiza el éxito. Esta última frase es
la clave, ¿qué se entiende por correcta
aplicación?

Los detractores de las metodologías

tradicionales se quejan básicamente de los
mismos problemas: exceso de documentación,
alcance de la solución, tiempos asignados al Figura 1 - PMBOK Project Management Process Groups mapped to
proyecto demasiados largos, insatisfacción del Jim Highsmith's Agile Project Management framework
cliente y costos muy elevados. Para sustentar
tales afirmaciones se han expuesto en trabajos en congresos forzando comparaciones entre los
métodos tradicionales y las metodologías ágiles. Uno de los fundamentos más importantes es que se
considera a los primeros manejado por el planeamiento y a los segundos por el valor agregado. La
Figura 1 muestra como se establece la comparación [6 y 7].

¿Si las metodologías ágiles tiene en evidencia de ser tan eficientes por qué insistir en compararlas
con las tradicionales utilizando como argumento el PMBOK? La respuesta es bastante simple: al ser
un framework sólo indica que se puede utilizar en el desarrollo de un proyecto, pero no implica el uso
obligatorio de todos sus componentes y las metodologías ágiles parecen no ajustarse a muchas
partes del framework. La razón de esto es que gran parte de la gestión del proyecto de estas últimas
se basan en la refactorización y la reingeniería localizada.

Ante las diferencias se trató, inclusive,

de generar un framework de
equivalencia al PMBOK, como el
propuesto por Jim Highsmith que se
muestra en la Figura 2, donde se utiliza
el siguiente criterio: “el PMBOK
identifica la inicialización, planificación,
ejecución, control y cierre de las fases
del proceso dentro de la gestión del
proyecto. Highsmith reconfigura estas
fases para reflejar mejor la realidad de
cómo el software es realmente
desarrollado, y se define como Figura 2 - - How is Agile Different from Traditional Approaches? The Paradigm
conceptualización, especulación, Shift
estudio, adaptación y cierre. En base a
estas equivalencias se enuncia que hay seis áreas de gestión del conocimiento clave en el PMBOK
que merecen especial atención y son la Gestión de Integración del Proyecto, Gestión del Alcance del
Proyecto y Gestión del Tiempo Proyecto, la Gestión
de Calidad del Proyecto y la Gestión de Riesgos
del Proyecto, y la Gestión de Recursos Humanos
del Proyecto. Para cada una de estas áreas, las
prácticas preconizadas por el PMBOK tienen sus
primos en ágiles, pero son significativamente
diferentes en su aplicación [8].

Particularmente, la Gestión de Riesgos marca la

diferencia de interpretación en la metodología ágil
respecto del PMBOK. Si bien se han hecho
esfuerzos para generar modelos (templates) que
acerquen el uno al otro [9], la realidad es que el Figura 3 - Planificación de respuesta al riesgo usaldo las categorías
estilo del manejo de riesgos en ágiles es como el DeMarco/Lister

que muestra la Figura 3 [8].

Como se puede apreciar, la forma de documentar es muy pobre, pero favorece el brainstorming de
los integrantes de todo el equipo. Esto además se apoya en la distribución del trabajo
descomponiéndolo y asignándolo a equipos con funcionalidades recíprocas donde todos participan en
la evolución del proyecto [10].

Sin embargo, el PMBOK tiene su propia respuesta, como siempre, apoyada en las experiencias
llamada “Practice Standard for Earned Value Management” para “agilizar” una gestión correcta del
proyecto. Esta, a diferencia de la anterior, se basa en organizarse a través de la metodología
necesaria para integrar la gestión del alcance, tiempos y costos del proyecto y juega un rol crucial en
responder preguntas críticas para el éxito del mismo, como ser:

 ¿Se está atrasado o adelantado en el proyecto?

 ¿Qué tan eficientemente se está utilizando el tiempo?
 ¿Cuándo se cree que se va a terminar?
 ¿Se está por encima o por debajo del presupuesto?
 ¿Qué tan eficientemente se utilizan los recursos?
 ¿Cuánto va a costar el trabajo que falta?
 ¿Cuánto va a costar el proyecto entero?
 ¿Cuánto se estará por arriba o debajo del presupuesto al terminar?

Al usar esta metodología se puede identificar

 ¿Dónde ocurren los problemas?

 ¿Cuándo son críticos o no?
 ¿Cuánto costará reencaminar el proyecto?

Todo esto permite un amplio control sobre la

planificación y su correspondiente ejecución, como
muestra la Figura 4. Para poder manejarlo Figura 4 - EVM and the Basic PM Process
correctamente se descompone en tareas simples, a los
que comúnmente se llaman cuentas de control, que
permiten generar WBS (Work Breakdown Structures).
Mediante un OBS (Organization Breakdown Structure)
se puede asignar estas tareas más simples a
individuos o equipos de trabajo, como muestra la
Figura 5. Por lo tanto, esto brindará una unidad de
medida aproximada, minimizará los riesgos y reducirá
los costos [12]. Arriesgando una conclusión
prematura, se puede establecer que ambas posturas
tienen sus formas de enfrentar los costos, los tiempos Figura 5 - Control Account Matrix
de desarrollo, la gestión de riesgos, etc. Si se parecen
tanto, ¿cómo una no puede tener cabida en la otra?

La respuesta es nuevamente simple: la tiene, sólo que al comparar una metodología con un
framework las diferencias parecen mayores a las similitudes. En el capítulo 2 (Ciclo de Vida del
Proyecto y Organización) del PMBOK se puede leer acerca de las fases, específicamente de las
relaciones de fase a fase y, aún más específico, la relación iterativa

“…sólo una fase está planificada en un momento dado y la planificación para la próxima se
lleva a cabo a medida que el trabajo avanza en la fase actual y los resultados finales. Este
enfoque es útil en entornos indefinidos, inciertos, o cambiantes rápidamente en gran medida,
como la investigación, pero puede reducir la capacidad de proporcionar planificación a largo
plazo. El alcance es entonces administrado por brindar de manera permanente los
incrementos del producto y dar prioridad a ciertos requerimientos para reducir al mínimo los
riesgos del proyecto y maximizar el valor del producto del negocio. También puede implicar
que todos los miembros del equipo de proyecto (por ejemplo, los diseñadores,
desarrolladores, etc) estén disponibles en todo el proyecto o, como mínimo, de dos fases
consecutivas.”

Tal vez la respuesta se encuentra en un punto medio, donde la metodología es en parte ágil y en
parte tradicional, permitiendo documentar, pero no mucho, gestionar riesgos y mantener formas de
comunicación con los equipos de desarrollo sin necesidad de pegar papeles con ideas sobre un
pizarrón, que pueda plasmar rápidamente los requerimientos y hacer ingeniería y análisis con ellos.
En pro de encontrar dicho punto medio, se comenzará con una propuesta de solución que arranca de
los documentos de especificación de requerimientos, conocidos como “system/software requirements
specification (SRS)”

Especificaciones Requisitos de Software

Este es el primer producto tangible de la mayoría de los ciclos de vida de desarrollo y una de las
principales fuentes de problemas en fases posteriores. Se han generado diferentes herramientas para
el planteo de este documento, como el del RUP (Rational Unified Process) o el de William M. Wilson
[14]. Todos proponen diferentes alternativas para categorizar los requerimientos utilizando distintos
atributos a los que se asignan valores dependiendo del estado del mismo. Inclusive, se propuso la
creación de herramientas gráficas que puedan categorizarlos minimizando la información textual [15].
Todas ellas además, desembocan escenarios, historias del usuario o casos de uso (junto con sus
respectivos diagramas, cuando esto es aplicable). Sin embargo, una herramienta surge como más
interesante en el análisis de requerimientos por su capacidad para aprovecharla más allá de cualquier
otra metodología utilizada, el LEL (Léxico Extendido del Lenguaje y Escenarios).

La ingeniería de requerimientos carece actualmente de representaciones gráficas estándares. Sin

embargo se puede utilizar el léxico extendido del lenguaje y la metodología ágil Iconix extendiéndose
su funcionalidad para analizar y representar a los mismos. El documento propone una forma de
simplificar el desarrollo de sistemas y su ciclo de vida.

Una metodología ágil indica moverse rápidamente hacia delante y no invertir meses o años en
producir largas especificaciones de un proyecto para conseguir cumplir con los requerimientos del
producto planteado por el usuario. Sin embargo, moverse directamente desde los escenarios o casos
de uso al desarrollo de código provoca inevitablemente una refactorización o inclusive una
reingeniería constante en el ciclo de vida de un proyecto.

Se puede adaptar una metodología ágil para reducir la refactorización y la reingeniería. Esto tan sólo
agrega un poco más de documentación y se logra a cambio una mejora notable en los procesos de
análisis de requerimientos. Este documento propone una forma de realizar dicha mejora.

Análisis de robustez – Iconix [16, 17] analysis Class Model

Desde hace un tiempo esta metodología fue ganando adeptos

porque cubre el vacío que existe entre los casos de uso, las
historias de los usuarios o los escenarios y los diagramas de clases
UML.. A primera vista parece una herramienta gráfica que sólo se Límite
Actor
limita a cubrir dicha necesidad. Sin embargo se puede encontrar
una relación directa desde el léxico extendido del lenguaje (LEL) a
los diagramas que propone Iconix. Explotando dicha relación se
puede extenderlo su uso que originalmente fue pensado como una
forma de resolver en una primera fase de análisis los patrones de Entidad Servicio

diseño MVC que se detectaban dentro del análisis del modelo de

negocios estudiado, a un análisis de requerimientos basados en Figura 6 - Elementos básicos de un
diagrama Iconix

LEL y reflejados mediante Iconix.

Iconix se basa en diagramas simples como los que se muestran en

la Figura 6 y todos se pueden refinar iterativamente.

Existen herramientas modernas que han aumentado la capacidad

de diagramas incluyendo componentes gráficos que registran
elementos no considerados en los cuatro gráficos elementales
originales y son los de la Figura 7

LEL [18]
El LEL (Léxico Extendido del Lenguaje y Escenarios) se introduce
como una herramienta para la creación y análisis de los escenarios
Figura 7 - - Elementos Iconix para
a partir de descripciones parciales del comportamiento del sistema. interacción de los requerimientos
Esta herramienta permite construir correctamente escenarios y determinará el dominio de un sistema
apoyándose en modelos (templates) pre diseñados. A partir de un análisis de componentes estándar
dentro de la narración de los requerimientos por parte del usuario, como ser el sujeto, objeto, verbo y
estado se descubren la noción (lo que representa cada uno de estos elementos) y el impacto (cómo
influye cada uno de ellos en el análisis). Esto permite determinar los elementos estándar de los
escenarios como el nombre, objetivo, contexto, recursos, actores y episodios.

Objetivos del enfoque

Objetivos Consecuencias
•Evitar abstracciones orientadas a una solución
Capturar Requerimientos
•Brindar una visión más amplia del comportamiento del macro sistema

(Derivan de la utilización del lenguaje de la aplicación)

•Asegurar la comunicación entre el usuario y el ingeniero de software

•Garantizar la comunicación entre los miembros del equipo de

Proveer un medio de desarrollo
comunicación
•Facilitar la validación de los requerimientos con el usuario

•Comprometer al usuario en el desarrollo

•Validar el LEL

•Documentar los requerimientos

•Capacitar a nuevos miembros del equipo para comprender la

Contar con un instrumento aplicación
de traceability •Promover la evolución de los escenarios a medida que avanza el
proceso de desarrollo

•Generar casos de prueba

Template de escenarios
Nombre Identifica al escenario.

Objetivo Establece la finalidad del escenario.

Acciones previas necesarias para iniciar el

Contexto
escenario.

Recursos Objetos pasivos con los cuales los actores

Template de escenarios
trabajan.

Entidades que se involucran activamente en el

Actores
escenario.

Una acción realizada por actores con uso de

Episodio recursos, se incluyen las restricciones del
escenario o de cada episodio.

Casos de excepción, que pueden corresponder a

Casos alternativos
otros escenarios.

Dudas Puntos pendientes a clarificar con el usuario.

Escenarios
Descripción parcial del comportamiento del sistema

Formas de representación:

– narrativa textual,
– storyboards,
– vídeo mock-ups,
– prototipos escritos o situaciones físicas.
– No son formales

El nivel de detalle depende de:

– importancia de los hechos específicos

– fase en la que se encuentra el proceso de desarrollo.

Se relacionan semánticamente entre sí

Evolucionan durante el ciclo de vida del software.

¿Son necesarios los casos de uso y los escenarios?

El LEL plantea una herramienta útil para la creación de escenarios y casos de uso mientras que
Iconix demostró ser eficiente para cubrir el vacío que se encuentra entre los escenarios o casos de
uso y el diseño de clases. Sin embargo, nacen inmediatamente las siguientes preguntas, ¿se podría
pasar directamente desde el análisis que ofrece LEL a Iconix?, ¿cómo se incorporaría una acción
semejante dentro del ciclo de vida de un proyecto?, ¿podría reflejarse esto dentro del cuerpo de
conocimiento del pmbok?

Las siguientes tablas muestran cómo influyen los elementos del LEL en los templates de escenarios:
 Impacto (¿cómo Escenarios
Elemento Noción (¿qué es?) influye?) Nombre 3,9
1-Sujeto 5-¿quién es? 9-¿qué hace? Objetivo 7
2-Objeto 6-¿qué es? 10-¿qué le hacen? Contexto 4
3-Verbos 7-¿cuál es el fin? 11-¿cómo se hace? Recursos 2,6
8-¿cómo se encuentra 1,5
4-Estado ahora? 12-¿transición? Actores
Episodios 8,10,11,12
Replanteando estas dos tablas por claridad, se puede ver la influencia en la
creación de escenarios desde otro punto de vista:

Noción Impacto Cabe destacar que a diferencia del sujeto, todos

Elemento Elemento (¿qué (¿cómo los otros elementos tienen influencia directa sobre
es?) influye?) los episodios, dando a entender que un análisis del
dominio se podría “contar” como una historia del
Sujeto Actores Actores Nombre usuario, escenario o caso de uso directamente en
Objeto Recursos Recursos Episodios un gráfico sin necesidad de redactar los mismos y
evitando la generación de mucha documentación
Verbos Nombre Objetivo Episodios
textual y sin perder contenido en el proceso.
Estado Contexto Episodios Episodios
Notar que esto también favorece elementos fundamentales como el seguimiento, la validación del
modelo y la verificación del modelo construido.

Es en este punto cuando se puede echar mano a una teoría existente para realizar la parte gráfica y
es donde interviene Iconix. Se puede tomar algunos elementos gráficos del mismo para generar una
representación simple de los requerimientos que no pierda información. La propuesta con las
respectivas equivalencias se muestra en una tabla comparativa respecto de LEL.

Elemento Elemento Noción (¿qué es?) Impacto (¿cómo influye?)

Sujeto Actor, Actor, Entidad. Determina Nombre del Modelo. Determinación
Entidad junto a los objetos y de actores. Determinación de los
servicios afectados los límites de interacción
límites de interacción
Objeto Entidad, Servicio o parte del mismo. Requerimientos funcionales, no
Servicio Entidad persistente. funcionales y persistencia.
Requerimiento no Graficado con enlaces
funcional
Verbos Servicio Servicios funcionales. Genera cambios de estado en el
Enlaces dominio. Graficado con enlaces.
Indica interacción con el límite y
entre objetos
Estado Servicio, Servicio o parte del mismo. Refleja los cambios dinámicos del
Entidad Entidad persistente sistema. Permita la validación y el
afectada. Los enlaces seguimiento del modelo. Graficado
indican el cambio de con nombres en enlaces
estado
El LEL toma cualquier forma de representación para obtener la información que determinarán los
requerimientos, lo cual va, por ejemplo, desde la narrativa textual a los storyboards o vídeo mock-ups.

En el siguiente ejemplo se muestra un análisis simple utilizando LEL para un sistema que permite la
obtención del pasaporte

Ejemplo:

Análisis LEL

Elemento Elemento Noción (¿qué es?) Impacto (¿cómo influye?)

-Solicitante -Solicitante
Sujeto -Cobrar trámite
-Cajero -Cajero
-Formulario
-Máquina -Formulario -Presentación del importe
Objeto
timbradora -Máquina timbradora -Formulario aprobado
-Pago
-Cobrar trámite
-Controlar -Formulario controlado
-Cobrar el trámite al
Verbos formulario -Formulario cobrado
solicitante.
-Timbrar -Formulario timbrado
formulario
-Trámite sin
cobrar
-Presentar formulario en caja
-Trámite pagado -Formulario presentado en caja
para pagarlo
Estado -Formulario sin -El formulario debe tener los datos del
-Pagar el trámite
timbrar solicitante y la marca del tipo de trámite.
-Colocar timbre en formulario
-Formulario
timbrado

Escenario
Nombre: COBRAR TRAMITE

Objetivo: Cobrar el trámite al solicitante.

Contexto: El solicitante debió completar el formulario y pasar por el control de documentación.

Recursos:
 formulario
 máquina timbradora

Actores:
 Solicitante
 Cajero
Set de Episodios:

El solicitante se presenta con el formulario en la Caja.

El cajero informa el importe del trámite según el tipo de trámite que figura en el formulario.
El solicitante paga el trámite.
El cajero timbra el formulario con el importe.
El cajero entrega el formulario al solicitante.
Restricciones:
El formulario debe tener los datos del solicitante y la marca del tipo de trámite.

Casos Alternativos:
Máquina timbradora falla.

Del Análisis LEL a Iconix sin los escenarios

Sólo a fines de clarificar el traspaso de LEL a Iconix se presenta una tabla con las equivalencias
utilizadas, según se mostró en la Tabla anterior

Iconix Análisis LEL

Nombre Cobrar trámite
Actores Solicitante
Cajero
Servicios y Enlaces
Cobrar trámite
Controlar formulario
Timbrar formulario
Pagar el trámite
Colocar timbre en formulario
Cobrar el trámite al solicitante.
Presentar formulario en caja
Pagar el trámite
Colocar timbre en formulario
Entregar formulario

Entidades Solicitante
Cajero
Formulario
Máquina timbradora
Requerimiento no Máquina timbradora
funcional
Límites Recepción de formulario
Recepción de Pago
Iconix Análisis LEL
Cambio de Estado de Formulario sin presentar
Entidades Formulario presentado
Formulario sin cobrar
Formulario cobrado
Formulario sin timbrar
Formulario timbrado
Formulario entregado

analysis Cobrar trámite

Formulario presentado
Recepción de
formulario
Controlar formulario Solicitante

Caj ero Presentar formulario en caja Formulario sin cobrar

Formulario entregado
Entregar formulario
Formulario cobrado
Cobrar trámite
Formulario
Colocar timbre en formulario

Pagar el trámite
Formulario sin timbrar

Recepción de Pago
Solicitante Timbrar formulario
Cajero

Se debe tener en cuenta que el diagrama permite verificar, seguir y validar los requerimientos y
plantea un análisis inicial del problema del dominio que puede refinarse iterativamente.

Esta combinación de técnicas de ingeniería de requerimientos y análisis del dominio nos permite
plantear el problema principal, ¿cómo se incluiría una herramienta semejante dentro del esquema del
cuerpo de conocimiento? La respuesta es nuevamente simple. Esta combinación permite el desarrollo
de planes y su concreción con un mínimo esfuerzo incluyendo constantemente al stakeholder en el
proceso mediante un lenguaje gráfico simple.

Conclusión
La alternativa presentada permite ajustarse mejor a la guía del PMBOK que otras metodologías

La metodología ágil propuesta cumple con los 12 puntos establecidos en el Agile Manifesto.

Posee la documentación suficiente para cambiar los equipos de trabajo o solucionar problemas si
algo anda mal.

Se demostró que pueden existir alternativos ágiles que se ajusten al framework del PMBOK
Referencias
[1]Building Better Software › What about Agile? - Andrew Stellman, Jennifer Greene -
http://www.stellman-greene.com/2007/04/27/what-about-agile/

[2]A guide to Project Management Body of Knowlegde – PMI Standards Committee

[3] A Strategy for Comparing Alternative Software Development Life Cycle Models - Alan M. Davis,
Edward H. Bersoff, and Edward R. Comer

[4] Building Better Software › Some great questions about PMP and Agile development- Andrew
Stellman, Jennifer Greene - http://www.stellman-greene.com/2007/12/06/some-great-questions-about-
pmp-and-agile-development/

[5] Using Agile Alongside the PMBOOK – Mike Griffiths -

http://leadinganswers.typepad.com/files/using-agile-alongside-the-pmbok_paper.pdf

[6] Agile Project Management: PMBOK vs. Agile - Neil Chaudhuri - Natalia Vainshtein

[7] Mapping the PMBOK Knowledge Areas to Agile Practices - Michele Sliger

[8] Relating PMBOK Practices to Agile Practices - Michele Sliger -

http://www.stickyminds.com/pop_print.asp?ObjectId=10365&ObjectTy

[9] Communicating Risk Information in Agile and Traditional Environments - Jaana Nyfjord and Mira
Kajko-Mattsson

[10] Distributed Scrum: Agile Project Management with Outsourced Development Teams - Jeff
Sutherland, Anton Viktorov and Jack Blount

[11] Practice Standard for Earned Value Management - Project Management Institute

[12] Earned Value, Clear and Simple - Tammo T. Wilkens

[13] Agile is in the PMBOK so it must be true - http://thecriticalpath.info/2010/06/04/agile-is-in-the-

pmbok-so-it-must-be-true/

[14] Writing Effective Requirements Specifications - William M. Wilson

[15] On Requirements Visualization - Orlena C.Z. Gotel, Francis T. Marchese, Stephen J. Morris

[16] Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example

Doug Rosenberg, Kendall Scott - Chapter 5. Robustness Analysis

[17] Agile Development with Iconix Process - Doug Rosenberg, Matt Stephens and Marl Collins-Cope

[18] Enhancing a Requirements Baseline with Scenarios - Julio Cesar Sampaio do Prado Leite,
Gustavo Rossi, Federico Balaguer, Vanesa Maiorana, Gladys Kaplan, Graciela Hadad and Alejandro
Oliveros