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

proyecto demasiados largos, insatisfacción del

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

conceptualización, especulación,

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

Figura 1 - PMBOK Project Management Process Groups mapped to Jim Highsmith's Agile Project Management framework

Figura 2 - - How is Agile Different from Traditional Approaches? The Paradigm Shift

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

estilo del manejo de riesgos en ágiles es como el

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

correctamente se descompone en tareas simples, a los

Figura 3 - Planificación de respuesta al riesgo usaldo las categorías DeMarco/Lister

Figura 4 - EVM and the Basic PM Process

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

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

Figura 5 - Control Account Matrix

analysis Class Model

Actor

Límite

ServicioEntidad

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]

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

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

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

negocios estudiado, a un análisis de requerimientos basados en

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

a partir de descripciones parciales del comportamiento del sistema.

Figura 6 - Elementos básicos de un diagrama Iconix

Figura 7 - - Elementos Iconix para 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

Capturar Requerimientos

•Evitar abstracciones orientadas a una solución

•Brindar una visión más amplia del comportamiento del macro sistema

Proveer un medio de

comunicación

(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

desarrollo

•Facilitar la validación de los requerimientos con el usuario

•Comprometer al usuario en el desarrollo

•Validar el LEL

Contar con un instrumento

de traceability

•Documentar los requerimientos

•Capacitar a nuevos miembros del equipo para comprender la

aplicación

•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.

Contexto Acciones previas necesarias para iniciar el

escenario.

Recursos Objetos pasivos con los cuales los actores

Template de escenarios

trabajan.

Actores Entidades que se involucran activamente en el

escenario.

Episodio

Una acción realizada por actores con uso de

recursos, se incluyen las restricciones del

escenario o de cada episodio.

Casos alternativos Casos de excepción, que pueden corresponder a

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:

Replanteando estas dos tablas por claridad, se puede ver la influencia en la

creación de escenarios desde otro punto de vista:

Cabe destacar que a diferencia del sujeto, todos

los otros elementos tienen influencia directa sobre

los episodios, dando a entender que un análisis del

dominio se podría “contar” como una historia del

usuario, escenario o caso de uso directamente en

un gráfico sin necesidad de redactar los mismos y

evitando la generación de mucha documentación

textual y sin perder contenido en el proceso.

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, Entidad

Actor, Entidad. Determina junto a los objetos y servicios afectados los límites de interacción

Nombre del Modelo. Determinación de actores. Determinación de los límites de interacción

Objeto Entidad, Servicio

Servicio o parte del mismo. Entidad persistente. Requerimiento no funcional

Requerimientos funcionales, no funcionales y persistencia. Graficado con enlaces

Verbos Servicio Servicios funcionales. Enlaces

Genera cambios de estado en el dominio. Graficado con enlaces. Indica interacción con el límite y entre objetos

Estado Servicio, Entidad

Servicio o parte del mismo. Entidad persistente afectada. Los enlaces indican el cambio de estado

Refleja los cambios dinámicos del sistema. Permita la validación y el seguimiento del modelo. Graficado con nombres en enlaces

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

1-Sujeto 5-¿quién es? 9-¿qué hace?

2-Objeto 6-¿qué es? 10-¿qué le hacen?

3-Verbos 7-¿cuál es el fin? 11-¿cómo se hace?

4-Estado 8-¿cómo se encuentra ahora? 12-¿transición?

Escenarios

Nombre 3,9

Objetivo 7

Contexto 4

Recursos 2,6

Actores 1,5

Episodios 8,10,11,12

Elemento Elemento Noción (¿qué es?)

Impacto (¿cómo influye?)

Sujeto Actores Actores Nombre

Objeto Recursos Recursos Episodios

Verbos Nombre Objetivo Episodios

Estado Contexto Episodios Episodios

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?)

Sujeto -Solicitante -Cajero

-Solicitante -Cajero

-Cobrar trámite

Objeto

-Formulario -Máquina timbradora -Pago

-Formulario -Máquina timbradora

-Presentación del importe -Formulario aprobado

Verbos

-Cobrar trámite -Controlar formulario -Timbrar formulario

-Cobrar el trámite al solicitante.

-Formulario controlado -Formulario cobrado -Formulario timbrado

Estado

-Trámite sin cobrar -Trámite pagado -Formulario sin timbrar -Formulario timbrado

-Presentar formulario en caja para pagarlo -Pagar el trámite -Colocar timbre en formulario

-Formulario presentado en caja -El formulario debe tener los datos del solicitante y la marca del tipo de trámite.

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 funcional

Máquina timbradora

Límites Recepción de formulario Recepción de Pago

Iconix Análisis LEL

Cambio de Estado de Entidades

Formulario sin presentar Formulario presentado Formulario sin cobrar Formulario cobrado Formulario sin timbrar Formulario timbrado Formulario entregado

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

analysis Cobrar trámite

Cajero

Solicitante

Cobrar trámite

Controlar formulario

Recepción de

formulario

Recepción de Pago

Formulario

Solicitante

Cajero

Timbrar formulario

Presentar formulario en caja

Pagar el trámiteFormulario sin timbrar

Colocar timbre en formulario

Formulario presentado

Formulario sin cobrar

Formulario cobrado

Formulario entregadoEntregar formulario

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