miércoles, 25 de junio de 2014

Diagramas UML





  DEFINICIÓN Y CONCEPTO DE UML

 
UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”. Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).
 
logo uml
 
 
¿QUÉ ES Y PARA QUÉ SIRVE UML?
 
El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software. Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándares que dicen cómo se debe representar algo.
 
UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir el código) y analistas-programadores (aquellos que dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o documentación de procesos que no tengan que ver con la informática.
 
Hemos dicho que UML es un estándar. Vamos a aclarar primero qué es un estándar. Supongamos que vamos a definir un estándar llamado “LMAPR” o lenguaje de modelado de aprenderaprogramar.com. Ahora definimos dentro de nuestro estándar estas normas:
 
Un animal debe representarse con su nombre escrito enteramente en minúsculas enmarcado dentro de un rectángulo doble. Encima del nombre debe etiquetarse el tipo de animal así: <<Tipo de Animal>>. Por ejemplo, <<Gato>>.
 
Si un animal envía un mensaje a otro animal deben conectarse los dos animales con una línea punteada terminada en flecha encima de la cual debe figurar el texto msg(“Contenido del mensaje”).

Ahora supongamos que tenemos dos gatos, uno de los cuales le dice al otro “Caza un ratón y tráemelo aquí por favor”. Veamos formas de representar esto:


Esta es una forma de representación. Sin embargo, no se adapta al estándar que hemos definido por varios motivos: no indica <<Gato>> encima de los nombres de los animales, no escribe los nombres en minúsculas, no representa los animales con un rectángulo, etc.
 
Veamos la representación que sí se adaptaría al estándar definido:
 




Con este ejemplo sencillo hemos tratado de hacer explícito qué es y para qué sirve UML: un conjunto de normas que nos dicen cómo hay que representar esquemas de software. En el caso del software orientado a objetos, en vez de gatos tendremos clases u objetos instanciados, y dispondremos de numerosos tipos de esquemas y diagramas para representar distintas cosas. Un esquema que cumple las normas UML podría tener este aspecto:





O también este otro:
¿Por qué si ambos esquemas cumplen con UML tienen un aspecto tan distinto? Porque UML define normas para construir muchos tipos de esquemas, no esquemas de un solo tipo.
 
¿Quién usa UML? UML lo suelen usar las empresas o medianos o grandes equipos de desarrollo software con el objetivo de planificar y documentar cómo se construyen los programas informáticos complejos. Los usuarios individuales o pequeños equipos de desarrollo de 2 ó 3 personas no suelen usar herramientas UML. UML es un término que se relaciona mucho con “Ingeniería del software”. Al igual que un proyecto de edificio requiere la participación de un arquitecto y unos plantos, un proyecto software requiere la participación de ingenieros informáticos y una planificación y documentación.

Elementos
Ejemplo:
Supongamos que tenemos tenemos un el caso del Diccionario implementado mediante un árbol binario, en donde cada nodo posee:
  • key: Variable por la cual se realiza la búsqueda, puede ser generica.
  • item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también puede ser genérico.
Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como item, solo se mostrarán las relaciones para la implementación del Diccionario:


Bibliografia

http://www.aprenderaprogramar.com/index.php?option=com_attachments&task=download&id=611
 

miércoles, 18 de junio de 2014

Diagrama de Actividades



Diagramas de actividades 

Capturar las acciones internas de un proceso.
Son abstracciones a nivel muy alto relacionadas entre sí presentando todos los procesos todos los procesos que ocurren dentro del sistema
Un diagrama de actividades muestra un flujo de acciones (nodos ejecutan un proceso), generalmente secuencias además presentan los resultados de dichas acciones

Usos.
·         Capturar las acciones internas de un proceso.
·         Capturar la especificación de un caso de uso.
·         Mostrar flujos entre procesos del negocio.
Simbología



Figura 1.- Simbología ocupada en diagramas de actividades

Unión Es en el nodo donde se combinan los caminos de  un no do de decisión. Marca el fin condicional.

Ejemplo de consignación la secuencia de acciones que se realiza para hacer una consignación en una entidad bancaria. Cada actividad se realiza cuando finaliza la actividad anterior. Cuando uno llna el formato antes de entregarlo, junto con el dinero, al cajero.



Figuran 2 Asignaciones


Acciones.
La actividad es el proceso de hacer algo. Las acciones son un paso en toda la actividad.
Ejemplo:
Actividad: Lavar un auto
Acciones: enjabonar, enjuagar, secar (Figura 3)

Figura 3 : Acciones de Diagrama de Actividades

Las decisiones son usadas cuando se quiere seguir alguna acción dependiendo de cierta condición figura 4

Figura 4:
Los caminos que salen del diamante tiene un nombre entre [] el cual indica la condición por la cual se toma ese camino.
Dicha condición se evalúa con un ture o false figura  5





Figura 5

Si algunas acciones no dependen de otra, puede ocurrir al mismo tiempo, en paralelo , se señalan utilizando forks y joins


Figura 7:

Después de un fork , el flujo se separa en dos o más caminos simultáneos, todas las acciones que surjan en el camino se ejecutan al mismo tiempo.

No todos los caminos se terminarán al mismo tiempo.

El join marca el nodo en donde se esperará a que todos los caminos simultáneos hayan terminado sus tareas. No se puede proceder después del join sin haber terminado todos los caminos anteriores.

Metodo Delphi


El primer estudio de Delphi fue realizado en 1950 por la Rand Corporation para la fuerza aérea de Estados Unidos, y se le dio el nombre de Proyecto Delphi. Su objetivo era la aplicación de la opinión de expertos a la selección de un sistema industrial norteamericano óptimo y la estimación del número de bombas requeridas para reducir la producción de municiones hasta un cierto monto.

 Es un método de estructuración de un proceso de comunicación grupal que es efectivo a la hora de permitir a un grupo de individuos, como un todo, tratar un problema complejo. (Linstone y Turoff, 1975)

La capacidad de predicción de la Delphi se basa en la utilización sistemática de un juicio intuitivo emitido por un grupo de expertos.

El objetivo de los cuestionarios sucesivos, es “disminuir el espacio intercuartil, esto es cuanto se desvía la opinión del experto de la opinión del conjunto, precisando la mediana”, de las respuestas obtenidas.

Dentro de los métodos de pronóstico, habitualmente se clasifica al método delphi dentro de los métodos cualitativos o subjetivos.

 La calidad de los resultados depende, sobre todo, del cuidado que se ponga en la elaboración del cuestionario y en la elección de los expertos consultados.


El proceso operativo del Método Delphi se puede desglosar en las siguientes fases:


1. Selección del tema y las personas responsables de la organización del proceso de encuesta. Debido a que las preguntas deben ser cerradas, debe prestarse especial atención a los temas cubiertos en las mismas, para extraer de la forma más precisa posible la información.
2. Selección de expertos. En todas las investigaciones basadas en el Método Delphi, el rol que ejerce cada participante es crucial. Por tanto, todos deben ser especialistas en el campo determinado que se estime necesario.
3. Desarrollo de cuestionarios para la primera etapa de la encuesta. Los organizadores necesitan decidir el número de rondas de cuestionario (las preguntas del formulario deben ser claras y estar enunciadas de forma que faciliten la recogida estadística de datos)
4. En el primer formulario de encuesta también se pide a los expertos una evaluación sobre sus conocimientos y competencias sobre el tema a tratar (la evaluación solo se realiza una vez en todo el proceso)
5. E necesario hacer una lectura en profundidad, y una edición del primer cuestionario (revisando los errores ortográficos y lógicos, y eliminando aquellas cuestiones poco clara o ambiguas)
6. Tras esto, puede hacerse el envío de los primeros cuestionarios a los expertos (por correo o e-mail), esperando su respuesta en un plazo estimado de 10 días.
7. Recopilación, análisis y elaboración de resultados de la primera etapa de la encuesta (presentación estadística de resultados)
8. Elaboración del segundo cuestionario –las preguntas son más concretas y detalladas- Además de las preguntas, se incluyen los resultados y opiniones de la primera fase. Si uno o varios de los expertos tienen una opinión totalmente diferente de la tendencia general o del consenso alcanzado, se les pide que revisen las otras opiniones, justifiquen su punto de vista y aporten su opinión final (que puede ser la misma o cambiar)
9. Envío del segundo formulario a los expertos
10. Recopilación, análisis y elaboración de resultados de la primera etapa de la encuesta (mismo procedimiento que en la primera fase),
11. El proceso descrito puede repetirse todas las veces que sea preciso para alcanzar un consenso común.
12. La fase final incluye el desarrollo del informe final y presentación de resultados de la encuesta.



Bibliografía 
http://www.eoi.es/blogs/nataliasuarez-bustamante/2012/02/11/%C2%BFque-es-el-metodo-delphi/

http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&cad=rja&uact=8&ved=0CEIQFjAH&url=http%3A%2F%2Fwww.prospectiva.eu%2Fzaharra%2F03_Delphi_ESTE.pdf&ei=4S6iU-7eG5KaqAb9_4DgDg&usg=AFQjCNEXvA6s0n4v6lSezdt_Sd2hWrQUXA&bvm=bv.69137298,d.b2k


http://www.slideshare.net/camiloan40/diagrama-de-actividades-uml
Dispositivas Dr.  Juan Manuel Gonzalez Calleros 

miércoles, 11 de junio de 2014

05 julio -11 Julio


Modelado de Tareas
Introducción

Hoy en día cualquier proyecto que se lleve a cabo debe llevar una serie de pasos y de tal forma que se formalice y se lleve a un lenguaje estandarizado y unificado

Con esto queremos decir que el desarrollo de todo proyecto y no solo del software sea orientado a objetos, se pueda visualizar, se especifique y se documentó con un lenguaje común ya que esto llevara a la reproducción del mismo siguiendo los pasos documentados.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notación estándar y semánticas esenciales, para el modelado de un sistema orientado a objetos.

El UML unido a un gestión de calidad, evita malos entendidos  y  entrega ciertas precauciones en la evolución y mantención de programas. Especialmente en lo referente a los requerimientos asociados al levantamiento y diseño funcional de un sistema. En efecto, por ejemplo con los Clientes Dilema, quienes no podrán hacer pensar que el cambio que están solicitando es pequeño, cuando detrás de la petición existe una enorme cantidad de tareas relacionadas al requerimiento.


Qué es UML?
 
El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso.
 
El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999).
 
UML incrementa la capacidad de lo que se puede hacer con otros métodos de análisis y diseño orientados a objetos. Los autores de UML apuntaron también al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.
El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.
La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

Ver  RobotDocIRS y  ¿Cuáles son las características que debe tener una herramienta UML? 
Semántica y Notación
 
Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.
 
La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).
 
Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.
El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:
•Modelamiento de Clases
•Casos de Uso
•Diagrama de Interacción
 
 
 
•Los diagramas de clases de UML forman la vista lógica.

•Los diagramas de interacción de UML constituyen la vista de proceso.

•La vista de desarrollo captura el software en su entorno de desarrollo.

• Los diagramas de despliegue integran la vista física .

•Los escenarios: el modelo de casos de uso.


Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
•Actor.

•Casos de Uso.

•Relaciones de Uso, Herencia y Comunicación.

Elementos
•Actor:


Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
  •Caso de Uso:



Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

•Relaciones: ◦Asociación


◦Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

◦Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
◦Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.


bibliógrafa
Ceria, Santiago, 2014 Casos de Uso Un Método Práctico para Explorar Requerimientos, Ingeniería de Software I  Texto recuperado URL http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.PDF
11-06-2014

miércoles, 4 de junio de 2014

Métodos Clásicos y ágiles


 
 
Metodologías tradicionales


Las metodologías tradicionales son denominadas, a veces, de forma peyorativa, como metodologías pesadas.

Centran su atención en llevar una documentación exhaustiva de todo el proyecto y en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las características importantes dentro de este enfoque, son los altos costes al implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es volátil.

Las metodologías tradicionales (formales) se focalizan en la documentación, planificación y procesos (plantillas, técnicas de administración, revisiones, etc.)






METODOLOGÍAS ÁGILES
Historia

    En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado
al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su
objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar
software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las
actividades desarrolladas.
 
Tras esta reunión se creó The Agile Alliance3, una organización, sin ánimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las
organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto
Ágil, un documento que resume la filosofía “ágil”.

Según el Manifiesto se valora:

        · Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las
herramientas. La gente es el principal factor de éxito de un proyecto software. Es más
importante construir un buen equipo que construir el entorno. Muchas veces se comete el
error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es
mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus
necesidades.
· Desarrollar software que funciona más que conseguir una buena documentación. La
regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata
para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo
fundamental.
 
La colaboración con el cliente más que la negociación de un contrato. Se propone que
exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración
entre ambos será la que marque la marcha del proyecto y asegure su éxito.
· Responder a los cambios más que seguir estrictamente un plan. La habilidad de
responder a los cambios que puedan surgir a los largo del proyecto (cambios en los
requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del
mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de
software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información
dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí
mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y
según esto ajusta su comportamiento.
 
Otros métodos ágiles


· SCRUM5 [16]. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

· Crystal Methodologies6 [5]. Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

· Dynamic Systems Development Method7 (DSDM) [17]. Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases.

 · Adaptive Software Development8 (ASD) [9]. Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

· Feature -Driven Development9 (FDD) [3]. Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.


· Lean Development10 (LD) [15]. Definida por Bob Charettes a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios.

Referencias

(2006 ) METODOLOGÍAS Y CICLOS DE VIDA, recuperado de URL http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.PDF

Canos, Joseh. Letelier, Patricio. Penades Ma. Carmen , Métodologías Ágiles en el Desarrollo de Software, Articulo recuperado de http://noqualityinside.com.ar/nqi/nqifiles/XP_Agil.pdf