<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="es">
	<id>https://www.ecured.cu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Pedroad100110jcvcl</id>
	<title>EcuRed - Contribuciones del colaborador [es]</title>
	<link rel="self" type="application/atom+xml" href="https://www.ecured.cu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Pedroad100110jcvcl"/>
	<link rel="alternate" type="text/html" href="https://www.ecured.cu/Especial:Contribuciones/Pedroad100110jcvcl"/>
	<updated>2026-06-07T03:09:58Z</updated>
	<subtitle>Contribuciones del colaborador</subtitle>
	<generator>MediaWiki 1.31.16</generator>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Archivo:Lud.jpg&amp;diff=1346643</id>
		<title>Archivo:Lud.jpg</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Archivo:Lud.jpg&amp;diff=1346643"/>
		<updated>2012-01-30T16:49:34Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Sumario ==&lt;br /&gt;
&lt;br /&gt;
== Estado de copyright: ==&lt;br /&gt;
&lt;br /&gt;
== Fuente: ==&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Ludwig_von_Bertanlanffy&amp;diff=1346562</id>
		<title>Ludwig von Bertanlanffy</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Ludwig_von_Bertanlanffy&amp;diff=1346562"/>
		<updated>2012-01-30T16:37:19Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: Página creada con '{{Ficha Persona |nombre       = Ludwig Von Bertanlanffy |nombre completo = Karl Ludwig von Bertalanffy |imagen       = lud.jpg |tamaño       = 250 |descripción  =  |fecha de n...'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Ficha Persona&lt;br /&gt;
|nombre       = Ludwig Von Bertanlanffy&lt;br /&gt;
|nombre completo = Karl Ludwig von Bertalanffy&lt;br /&gt;
|imagen       = lud.jpg&lt;br /&gt;
|tamaño       = 250&lt;br /&gt;
|descripción  = &lt;br /&gt;
|fecha de nacimiento = 19 de septiembre de 1901 &lt;br /&gt;
|lugar de nacimiento = Austria&lt;br /&gt;
|fecha de fallecimiento = 12 de junio de 1972&lt;br /&gt;
|lugar de fallecimiento = Estados Unidos&lt;br /&gt;
|nacionalidad = Austriaca&lt;br /&gt;
|educación    = &lt;br /&gt;
|alma máter   = Universidad de Viena &lt;br /&gt;
|ocupación    = Biología, Teoría de sistemas&lt;br /&gt;
|conocido     =  Teoría general de sistemas&lt;br /&gt;
|titulo       = &lt;br /&gt;
|termino      = &lt;br /&gt;
|predecesor   = &lt;br /&gt;
|sucesor      = &lt;br /&gt;
|partido político = &lt;br /&gt;
|cónyuge      = &lt;br /&gt;
|hijos        = &lt;br /&gt;
|padres       = &lt;br /&gt;
|familiares   = &lt;br /&gt;
|obras        = &lt;br /&gt;
|premios      = &lt;br /&gt;
|titulos      =&lt;br /&gt;
|récords      =&lt;br /&gt;
|plusmarcas   = &lt;br /&gt;
|web          = &lt;br /&gt;
|notas        = &lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div align=&amp;quot;justify&amp;quot;&amp;gt; &lt;br /&gt;
==Biografía==&lt;br /&gt;
Karl Ludwig von Bertalanffy nació en [[Atzgersdorf]], [[Austria]], recibió una formación familiar muy amplia y estudió historia del arte, filosofía y ciencias en la universidades de [[Innsbruk]] y [[Viena]], siguiendo los pasos en esta última de los destacados profesores [[Robert Reininger]] y [[Moritz Schlick]], fundadores del [[Círculo de Viena]]. En 1926, finalizó su doctorado, con la discusión de su tesis doctoral, bajo al dirección de Schlick, sobre la el pionero de la psicofísica [[Gustav Fechner]] (1801-1887). Dos años después, publicó su primer libro sobre biología teórica, [[''Kritische Theorie der Formbildung Teorías Modernas del Crecimiento'']] (1928). En 1937 se trasladó a [[Estados Unidos]] con una beca de la [[Fundación Rockefeller]], permaneciendo dos años en la [[Universidad de Chicago]], donde hace las primeras exposiciones conceptuales sobre su [[Teoría general de los sistemas]] en un seminario dirigido por el [[Charles Morris]], que trabajaba en la [[Teoría de los signos y la unidad de la ciencia]] y era el valedor en Estados Unidos del [[Exilio intelectual de origen germánico]]. Bertalanffy no puede continuar en Estados Unidos tras ser discriminado por no haberse querido presentar como víctima del nazismo, lo que le hizo volver a [[Europa]]. En 1939, se incorpora como profesor de la [[Universidad de Viena]], donde permaneció hasta 1948. Después de una breve estancia como profesor de la [[Medical School del londinense Middlessex Hospital]], en 1949 emigró a [[Canadá]], prosiguiendo sus investigaciones en la [[Universidad de Ottawa]] (1950-54) y en el [[Mount Sinai Hospital de Los Ángeles]], en Estados Unidos (1955-58). Fue profesor de biología teórica en la canadiense [[Universidad de Alberta]] en [[Edmonton]] (1961-69), período en el que publica los libros [[Robots, Men and Minds]] (1967), [[General System Theory. Foundations]], [[Development, Applications]] (1968) y [[The Organismic Psychology and Systems Theory]] (1968). Su actividad académica &lt;br /&gt;
concluyó como profesor de la [[Facultad de Ciencias Sociales de la State University de Nueva York]] en Búfalo (1969-72). Pese a ser uno de los pensadores más influyentes del siglo XX, la propuesta para premio Nobel no prosperó.&lt;br /&gt;
&lt;br /&gt;
==Bertalanffy en el campo de la biología==&lt;br /&gt;
Planteó una teoría de los sistemas abiertos en física y biología (1950), concibió una explicación de la vida y la naturaleza como la de un complejo sistema, sujeto a interacciones y dinámicas, que más tarde trasladó al análisis de la realidad social y a las estructuras organizadas bajo una descripción de amplio espectro que denominará teoría general de los sistemas, cuya expresión definitiva, después de tres décadas de desarrollo, apareció en el libro [[General System Theory]] (1969).&lt;br /&gt;
En 1954, logró reunir a científicos de otras disciplinas que trazaban visiones sistémicas en torno a la [[Society for General Systems Research]] (hoy, [[International Society for the Systems Sciences]]), entre los que se contaban el economista [[Kenneth Boulding]], el psicólogo [[James Grier Miller]], el matemático [[Anatol Rapoport]] y el filósofo [[Ralph Gerard]], a los que se irían uniendo muchas de las figuras relevantes de la ciencia del siglo XX.&lt;br /&gt;
&lt;br /&gt;
==Libros publicados en español==&lt;br /&gt;
&lt;br /&gt;
En lengua española, han sido editados los libros: &lt;br /&gt;
* Robots, hombres y mentes, Guadarrama, Madrid, 1971&lt;br /&gt;
* Teoría general de los sistemas, Fondo de Cultura Económica, México, 1976&lt;br /&gt;
* Perspectivas en la teoría general de sistemas, Alianza Universidad, Madrid, 1979.&lt;br /&gt;
&lt;br /&gt;
==Pensamiento y expresión científica==&lt;br /&gt;
&lt;br /&gt;
La teoría de sistemas plantea un nuevo marco de enfoque metodológico de muy amplia aplicación en distintas áreas de conocimiento, esto es nuevo paradigma científico que retoma la visión holística e integradora, como necesaria para una comprensión de la realidad, frente a los reduccionismos analíticos que fijaban su atención en aspectos muy concretos, sin considerar que éstos estaban sujetos a la dinámica del conjunto. La teoría de sistemas contempla los ambientes e interacciones de las estructuras organizadas cuya naturaleza diferencial radica en su propia organización, con determinados equilibrios internos, modalidades de alimentación y conservación, etcétera. Estas propiedades de los sistemas, advertidas inicialmente en los organismos vivos y en la naturaleza, eran exportables a otros escenarios para la observación y comprensión de sus estructuras dinámicas, como los de las ciencias humanas y sociales. Bertalanffy era consciente de que su propuesta de cambio en los marcos de registro del conocimiento conectaba con las necesidades de la ciencia en su deriva hacia la construcción de una realidad cada vez más compleja. Por ello, la teoría de sistemas no sólo va a ser contemporánea de otras teorías, sino que vendrá a ahormarlas, a relacionarlas entre sí bajo un nuevo paradigma de percepción de la realidad científica. Estrechamente relacionadas aparecen la [[Teoría de la información]], la cibernética de segundo orden y el constructivismo radical (von Foerster y Ashby, muy especialmente), pero su estela no se cierra al panorama científico cambiante de mediados del siglo XX, sino que se proyecta en una progresiva impregnación de estructuras de conocimiento susceptibles de ser descritas mediante marcos sistémicos (por ejemplo, en el campo de la comunicación y de las ciencias sociales, [[Niklas Luhmann]]) y en su proyección embrionaria sobre otros recorridos que alcanzan a la teoría del caos, la genética o a la física cuántica. &lt;br /&gt;
&lt;br /&gt;
==Obra==&lt;br /&gt;
&lt;br /&gt;
* 1928, Kritische Theorie der Formbildung, Borntraeger&lt;br /&gt;
* 1930, Lebenswissenschaft und Bildung, Stenger, Erfurt 1930&lt;br /&gt;
* 1937, Das Gefüge des Lebens, Leipzig: Teubner&lt;br /&gt;
* 1940, Vom Molekül zur Organismenwelt, Potsdam: Akademische Verlagsgesellschaft Athenaion&lt;br /&gt;
* 1949, Das biologische Weltbild, Bern: Europäische Rundschau. In English: Problems of Life: An Evaluation of Modern Biological and Scientific Thought, New York: Harper, 1952&lt;br /&gt;
* 1953, Biophysik des Fliessgleichgewichts, Braunschweig: Vieweg. 2nd rev. ed. by W. Beier and R. Laue, East Berlin: Akademischer Verlag, 1977&lt;br /&gt;
* 1953, &amp;quot;Die Evolution der Organismen&amp;quot;, in Schöpfungsglaube und Evolutionstheorie, Stuttgart: Alfred Kröner Verlag, pp 53-66&lt;br /&gt;
* 1959, Stammesgeschichte, Umwelt und Menschenbild, Schriften zur wissenschaftlichen Weltorientierung Vol 5. Berlin: Lüttke&lt;br /&gt;
* 1962, Modern Theories of Development, New York: Harper&lt;br /&gt;
* 1967, Robots, Men and Minds: Psychology in the Modern World, New York: George Braziller, 1969 hardcover: ISBN 0-8076-0428-3, paperback: ISBN 0-8076-0530-1&lt;br /&gt;
* 1968, General System theory: Foundations, Development, Applications, New York: George Braziller, revised edition 1976: ISBN 0-8076-0453-4&lt;br /&gt;
* 1968, The Organismic Psychology and Systems Theory, Heinz Werner lectures, Worcester: Clark University Press&lt;br /&gt;
* 1975, Perspectives on General Systems Theory. Scientific-Philosophical Studies, E. Taschdjian (eds.) New York: George Braziller, ISBN 0-8076-0797-5&lt;br /&gt;
* 1981, A Systems View of Man: Collected Essays, editor Paul A. LaViolette, Boulder: Westview Press, ISBN 0-86531-094-7&lt;br /&gt;
&lt;br /&gt;
==Fuentes==&lt;br /&gt;
*http://www.infoamerica.org/teoria/bertalanffy1.htm&lt;br /&gt;
*http://www.buenastareas.com/ensayos/Biografia-Karl-Ludwig-Von-Bertalanffy/1636254.html&lt;br /&gt;
*http://www.richardjung.cz/bert1.pdf&lt;br /&gt;
*http://www.scribd.com/doc/27468769/Biografia-Ludwig-Von-Bertalanffy&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
[[Category: Biología]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Archivo:Eup.jpg&amp;diff=1224584</id>
		<title>Archivo:Eup.jpg</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Archivo:Eup.jpg&amp;diff=1224584"/>
		<updated>2011-12-01T16:26:31Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Sumario ==&lt;br /&gt;
&lt;br /&gt;
== Estado de copyright: ==&lt;br /&gt;
&lt;br /&gt;
== Fuente: ==&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Essential_Unified_Process&amp;diff=1224478</id>
		<title>Essential Unified Process</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Essential_Unified_Process&amp;diff=1224478"/>
		<updated>2011-12-01T16:14:40Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Essential Unified Process&lt;br /&gt;
|imagen=eup.jpg&lt;br /&gt;
|tamaño=250&lt;br /&gt;
|concepto= El proceso esencial Unificado (EssUP) es un conjunto de prácticas que en conjunto forman el conocimiento esencial de un ciclo de vida de desarrollo de software.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
==Introducción==&lt;br /&gt;
&lt;br /&gt;
[[Essential unified process]] (EssUP), fue creado por Ivar Jacobson, como una mejora sobre el Rational Unified Process(RUP) y mucho mas &amp;quot;liviana&amp;quot; que [[Microsoft Solution Framework]] (MSF). Esta basada en MSF y será incluida como parte del [[Team System]]. Consiste en la integración de prácticas eficaces entre los tres principales campos de procesos: el proceso unificado, los métodos ágiles y el proceso de madurez. Cada uno de estos procesos contribuye con diferentes capacidades o características como son: la estructura, la agilidad y la mejora de procesos.&lt;br /&gt;
EssUP esta basado en casos de uso, [[CMMI]] y desarrollo ágil. Se considera una mejora sobre RUP ya que en este último todas las prácticas están relacionadas y no pueden ser usadas de forma aislada. &lt;br /&gt;
EssUP está soportado por Microsoft Visual Studio Team System, y Eclipse.&lt;br /&gt;
&lt;br /&gt;
==Definición==&lt;br /&gt;
&lt;br /&gt;
El proceso esencial Unificado (EssUP) es un conjunto de prácticas que en conjunto forman el conocimiento esencial de un ciclo de vida de desarrollo de software. Las prácticas integran principios que se han mostrado efectivos en los campos del proceso unificado, del desarrollo ágil y la madurez de los procesos, haciendo énfasis en las capacidades que ofrecen: estructura, agilidad y mejora de procesos. &lt;br /&gt;
 &lt;br /&gt;
==Características==&lt;br /&gt;
 &lt;br /&gt;
Ess UP identifica prácticas como desarrollo en base a casos de uso, desarrollo iterativo, architecture driven development, practicas para el equipo y practicas para los procesos, que son tomados de RUP, CMMI, y desarrollo ágil. &lt;br /&gt;
== Essential Practicess==&lt;br /&gt;
La metodología denomina Essential Practicess al conjunto de prácticas, las cuales esta divididas en 6 prácticas técnicas y 4 prácticas transversales.&lt;br /&gt;
 &lt;br /&gt;
==Practicas Técnicas==&lt;br /&gt;
 &lt;br /&gt;
==Architecture Essentials==&lt;br /&gt;
&lt;br /&gt;
Esta práctica está destinada a obtener una base firme para el desarrollo de sistemas de alta calidad y robustos. Permite a los equipos: &lt;br /&gt;
*Identificar de forma efectiva los riesgos técnicos del proyecto. &lt;br /&gt;
*Consensuar las decisiones principales sobre la estructura y organización del sistema implementado. &lt;br /&gt;
*Verificar que el sistema integra las características clave esperadas por el cliente. &lt;br /&gt;
*Probar de forma objetiva que el sistema elegido es adecuado a su propósito.&lt;br /&gt;
 &lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
*Documentación acerca de la arquitectura. &lt;br /&gt;
*Casos de prueba sobre la arquitectura. &lt;br /&gt;
*Vistas de la arquitectura. &lt;br /&gt;
*Verificación de la arquitectura de forma incremental. Se testea cada vez que se produce una nueva versión del sistema. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
*Identificar y clarificar los requisitos relevantes para la arquitectura para establecer los objetivos de la misma. &lt;br /&gt;
*Determinar la arquitectura a implementar y especificar el conjunto de pruebas que se usarán para verificar y probar la implementación. &lt;br /&gt;
*Producir un sistema básico verificado y probado para cumplir los requisitos. &lt;br /&gt;
*Entrenar al equipo para usarlo. &lt;br /&gt;
A partir de aquí la arquitectura evoluciona en función de nuevos requisitos y resultados de las pruebas. Todos los sistemas construidos están sujetos al cumplimiento de los test para asegurar la validez de la implementación de la arquitectura. &lt;br /&gt;
&lt;br /&gt;
==Iterative Essentials==&lt;br /&gt;
 &lt;br /&gt;
Esta práctica reduce el riesgo del proyecto mediante el desarrollo incremental del sistema sobre un número de iteraciones. &lt;br /&gt;
El proyecto se descompone en trozos más pequeños o mini proyectos, independientes y limitados en el tiempo. Esta práctica permite al equipo: &lt;br /&gt;
*Planear de forma colaborativa y objetiva, ejecutar y seguir el proyecto. &lt;br /&gt;
*Una gestión del tiempo más eficaz y de más calidad. &lt;br /&gt;
*Demostrar la importancia de trabajar desde un primer momento en el software contando con los feedbacks de clientes y usuarios. &lt;br /&gt;
*Ser ágiles en respuesta a los cambios. &lt;br /&gt;
*Entregar más alta calidad, soluciones más apropiadas, más frecuentemente. &lt;br /&gt;
*Tener un sistema operacional disponible desde bien pronto en el proyecto, que incrementalmente crezca para convertirse finalmente en un sistema completo. &lt;br /&gt;
&lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
Esta práctica implica la producción de un conjunto de elementos relacionados con la administración: &lt;br /&gt;
*El backlog (trabajo atrasado) se llena de cambios, cosas que no funcionan correctamente o fallos, y otras tareas que representan el trabajo por ser realizado. &lt;br /&gt;
*El plan de proyecto identifica el número y tipo de las iteraciones que serán llevadas a cabo. &lt;br /&gt;
*La planificación y las iteraciones son necesarias por los riesgos que implica el proyecto. &lt;br /&gt;
*La iteración de los planes y los ajustes son necesarias para conocer el propósito y el resultado de cada iteración. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
*La práctica comienza adaptando los planes del proyecto existentes para integrar las iteraciones al ámbito del proyecto. &lt;br /&gt;
*Los objetivos, criterios de evaluación y trabajo para la primera iteración son aceptados. &lt;br /&gt;
*La práctica guía entonces al equipo a través de la iteración dónde tienen que aplicar otras prácticas para conseguir los objetivos de la iteración. &lt;br /&gt;
*Al final del periodo establecido para la iteración sus resultados serán evaluados y utilizados para ayudar a adaptar los planes a la realidad del proyecto y establecer la siguiente iteración. &lt;br /&gt;
*Esta secuencia se sigue para cada iteración de trabajo del proyecto hasta que, tras los resultados de la iteración final sean evaluados y el proyecto concluya. &lt;br /&gt;
&lt;br /&gt;
==Use-Case Essentials==&lt;br /&gt;
&lt;br /&gt;
Una forma ágil, sencilla de controlar y de seguir el desarrollo del proyecto software. &lt;br /&gt;
Esta práctica permite al equipo: &lt;br /&gt;
*Trabajar con los clientes para capturar los requerimientos verdaderamente esenciales. &lt;br /&gt;
*Trabajar juntos más eficientemente para desarrollar rápidamente una solución utilizable. &lt;br /&gt;
*Identificar y entregar el valor esperados del sistema. &lt;br /&gt;
*Establecer el nivel correcto de detalle de los requisitos para satisfacer nuestras necesidades y la de los clientes. &lt;br /&gt;
*Priorizar e identificar subconjuntos de requisitos de una solución mínima para usarla en el desarrollo iterativo. &lt;br /&gt;
*Utilizar un acercamiento sistemático al correcto diseño, implementación y verificación de requisitos.&lt;br /&gt;
 &lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
Esta práctica implica la producción de un conjunto de requisitos, así como el diseño y prueba de elementos: &lt;br /&gt;
*Un caso de uso basado en la especificación de los requisitos, escenarios y casos de prueba. &lt;br /&gt;
*La realización del caso de uso conduce al desarrollo del software. &lt;br /&gt;
*La generación de pruebas y los resultados de las pruebas sirven para probar el sistema y grabar los resultados de las pruebas. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
*La práctica comienza identificando los actores y los casos de uso, y eligiendo y priorizando los casos de uso a ser desarrollados. &lt;br /&gt;
*Sigue especificando los casos de uso y sus pruebas, e implementando el software que hallará las pruebas. &lt;br /&gt;
*Finaliza ejecutando las pruebas y siguiendo el progreso en términos de verificado. &lt;br /&gt;
&lt;br /&gt;
==Component Essentials==&lt;br /&gt;
&lt;br /&gt;
Esta práctica se utiliza para desarrollar complejos sistemas formados de componentes más pequeños y más simples. &lt;br /&gt;
Esta práctica permite al equipo: &lt;br /&gt;
*Gestionar la complejidad asociada con el desarrollo del sistema software. &lt;br /&gt;
*Desarrollar complejos sistemas de una forma extensible y mantenible. &lt;br /&gt;
*Desarrollar y verificar las partes separadas de un sistema independientemente y en paralelo. &lt;br /&gt;
*Identificar oportunidades para la reutilización y aprovechamiento de componentes reutilizables. &lt;br /&gt;
*Utilizar la tercera parte de los frameworks y los componentes de biblioteca. &lt;br /&gt;
&lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
Esta práctica implica la producción de un número de implementaciones y elementos de prueba: &lt;br /&gt;
*Un diseño modelado del sistema a implementar, identificando el conjunto de componentes requeridos. &lt;br /&gt;
*Una descripción de cada componente, incluyendo su comportamiento e interfaces. &lt;br /&gt;
*Código fuente y unidades de prueba para componente. &lt;br /&gt;
*Construcciones integradas del sistema del componente y las pruebas y los resultados para verificar las construcciones. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
*La práctica comienza identificando el conjunto de componentes que son necesarios para hallar los requisitos del sistema, y plasmar esta práctica en la especificación del sistema. Esto incluye identificar un adecuado conjunto de pruebas para verificar el sistema. &lt;br /&gt;
*Se sigue definiendo los componentes, incluyendo sus interfaces y unidades de prueba, y desarrollando los componentes para implementar las interfaces y pasar estas pruebas. &lt;br /&gt;
*Finalizamos integrando el sistema, ejecutando las pruebas para verificar el sistema producido y entonces fomentando la utilización tal y cómo los componentes han sido concebidos. &lt;br /&gt;
&lt;br /&gt;
==Product Essentials==&lt;br /&gt;
 &lt;br /&gt;
Administrando versiones del producto Esta práctica se utiliza para administrar el desarrollo de sucesivas evoluciones de un sistema software como una serie de versiones del producto. &lt;br /&gt;
Esta práctica permite al equipo: &lt;br /&gt;
*Planear el proyecto como una serie de versiones de un producto superior estando cada entrega real en pos del beneficio empresarial. &lt;br /&gt;
*Involucrar a los stakeholders en la decisión de fabricación del proceso. &lt;br /&gt;
*Asegurar que el producto realizado cubrirá las necesidades reales de los stakeholders. &lt;br /&gt;
*Gestionar la evolución del software de forma controlada y enfocada al negocio. &lt;br /&gt;
&lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
Esta práctica implica la producción de un conjunto de elementos de negocio, de planeamientos y de requisitos:&lt;br /&gt;
*El caso de negocio para establecer el valor del producto. &lt;br /&gt;
*El análisis de los stakeholders para asegurar que ellos comprenden y están involucrados en el proyecto. &lt;br /&gt;
*La lista de capacidades, glosario y descripción de cada versión para definir el producto y sus versiones. &lt;br /&gt;
*El plan de proyecto para extraer cómo las series de versiones serán producidas. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
*Esta práctica comienza iniciando el proyecto y estableciendo el caso de negocio de producto. &lt;br /&gt;
*Continúa especificando y planificando las versiones del producto &lt;br /&gt;
*Concluye con el empaquetado de la versión y su aceptación por parte del cliente.&lt;br /&gt;
 &lt;br /&gt;
==Bussiness Use Case Essentials==&lt;br /&gt;
 &lt;br /&gt;
Caso de uso de negocio: gestionando tus requisitos de negocio. &lt;br /&gt;
Podremos captar y redefinir tal y como requieren tus procesos de negocio para que se llegue a una solución software más eficaz y que mejore las prestaciones y el valor que te aportará. &lt;br /&gt;
Con nuestra práctica de caso de uso de negocio esencial, tu equipo se enriquecerá al comprender las necesidades del negocio, y cómo involucrar al negocio para lograr cubrir las necesidades de la organización. &lt;br /&gt;
&lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
El caso de uso de negocio esencial te permitirá: &lt;br /&gt;
*Adaptar una solución tecnológica a los requisitos con las necesidades del negocio. &lt;br /&gt;
*Maximizar los beneficios generados por la introducción de soluciones automatizadas. &lt;br /&gt;
*Comprender el impacto de las soluciones propuestas al negocio. &lt;br /&gt;
*Incrementar el beneficio realizado por el software a partir del desarrollo de proyectos software. &lt;br /&gt;
&lt;br /&gt;
==Prácticas Transversales==&lt;br /&gt;
 &lt;br /&gt;
==Unified Process Lifecycle Essentials==&lt;br /&gt;
 &lt;br /&gt;
Esta práctica se utiliza para establecer un control sobre el ciclo de vida de un proyecto de desarrollo iterativo y permite a los equipos: &lt;br /&gt;
*Establecer un ciclo de vida del proyecto. &lt;br /&gt;
*Compartir un conjunto de hitos (milestones) comunes con otros proyectos y equipos. &lt;br /&gt;
*Identificar los objetivos a corto plazo para reducir los niveles de riesgo que se presentan. &lt;br /&gt;
*Estructurar los planes en una secuencia de fases bien comprendidas. &lt;br /&gt;
*Aprovechar al máximo los beneficios del desarrollo iterativo. &lt;br /&gt;
Patrones de ciclo de vida&lt;br /&gt;
Está práctica presenta un conjunto de &amp;quot;Patrones de ciclo de vida&amp;quot; que al ser aplicados en el proyecto permiten al equipo: &lt;br /&gt;
*Entender en que estado está el proyecto y como de correcta se está llevando a cabo la gestión de los riesgos. &lt;br /&gt;
*Adoptar un marco de control estándar para guiarlos en el establecimiento apropiado de objetivos y de hitos. &lt;br /&gt;
*Iterar de una manera controlada. &lt;br /&gt;
*Observar la evolución de la arquitectura y los requisitos junto con el desarrollo de una solución de software de alta calidad.&lt;br /&gt;
&lt;br /&gt;
'''The Common Milestones''' &lt;br /&gt;
&lt;br /&gt;
Este patrón define un conjunto de hitos o puntos de paso, apropiado para la planificación y el seguimiento de todas las variantes de desarrollo iterativo e incremental de los proyectos software. Los tres principales hitos se muestran a continuación: &lt;br /&gt;
*Objetivos del Ciclo de Vida (Lifecycle Objectives) - Se toman las decisiones clave sobre lo que será y no será en el producto/versión. Los requisitos operativos del software son acordados. &lt;br /&gt;
*Arquitectura del ciclo de vida (Lifecycle Architecture) - Se establece la arquitectura del software y se establece el plan para los riesgos principales asociados. &lt;br /&gt;
*Capacidad operativa inicial (Initial Operational Capability) - El software es totalmente funcional y se realizan los preparativos para la transición del software al cliente y/o el entorno de producción. &lt;br /&gt;
&lt;br /&gt;
'''The Lifecycle Phases'''&lt;br /&gt;
&lt;br /&gt;
Esta práctica perfecciona el patrón Common Milestones mediante la definición de cuatro fases para el adecuado progreso del proyecto hacia el éxito a través de los tres milestones anteriores. &lt;br /&gt;
El proyecto o ciclo de lanzamiento del producto/versión se divide en cuatro fases secuenciales, cada una de las cuales tiene objetivos bien definidos: &lt;br /&gt;
*Inicio (Inception) - Confirmación del alcance y objetivos y control de los riesgos asociados al negocio. &lt;br /&gt;
*Elaboración (Elaboration) - Concreción de los planes y control de los riesgos arquitectónicos y técnicos. &lt;br /&gt;
*Construcción (Construction) - Construcción del producto y control de los riesgos asociados a la ejecución del proyecto. &lt;br /&gt;
*Transición (Transition) - Entrega del producto y control de los riesgos de despliegue. &lt;br /&gt;
Estas cuatro fases son tomadas de RUP por lo que en dicha metodología se puede encontrar información ampliada y actividades concretas a realizar en cada fase. &lt;br /&gt;
&lt;br /&gt;
==Team Essentials==&lt;br /&gt;
&lt;br /&gt;
Esta práctica es utilizada para reunir un equipo de proyecto y establecer un ambiente de trabajo efectivo. Para ello el equipo debe: &lt;br /&gt;
*Adoptar las medidas de liderazgo y de organización. &lt;br /&gt;
*Establecer y adquirir las competencias necesarias para tener éxito. &lt;br /&gt;
*Desarrollar formas efectivas de colaborar y organizar su trabajo. &lt;br /&gt;
*Crear una ambiente en el que todos los miembros del equipo sean capaces de contribuir al máximo de su capacidad durante todo el proyecto. &lt;br /&gt;
&lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
El objetivo es la creación de trabajo en equipo eficaz y la producción de elementos relacionados: &lt;br /&gt;
*En la carta del equipo se refleja la estructura del equipo y las responsabilidades. &lt;br /&gt;
*Los miembros integrados en el equipo deben evolucionar hacia maneras efectivas de colaborar. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
*La práctica comienza con la formación del equipo inicial del proyecto como parte de la puesta en marcha del mismo. &lt;br /&gt;
*A lo largo del desarrollo, los planes de proyecto se adaptan para reflejar la dotación de personal y la eficacia del equipo, el equipo del proyecto está orientado a mejorar el trabajo del equipo y eliminar los obstáculos que impiden que el trabajo efectivo del equipo.&lt;br /&gt;
&lt;br /&gt;
==Process Essentials==&lt;br /&gt;
&lt;br /&gt;
Está práctica permite mejorar y adaptar la forma de trabajo del equipo, en concreto, permite al equipo: &lt;br /&gt;
*Identificar, preparar y reunir un conjunto de prácticas y herramientas adecuadas para conseguir los objetivos del proyecto. &lt;br /&gt;
*Introducir nuevas prácticas individual y gradualmente según sea necesario. &lt;br /&gt;
*Comparar e integrar prácticas estándar y particulares preservando los aspectos que el equipo ejecuta correctamente y señalando aquellos que no. &lt;br /&gt;
*Evolucionar las prácticas en base a la experiencia y las lecciones aprendidas. &lt;br /&gt;
&lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
El objetivo es el establecimiento de una forma efectiva de trabajo y la producción de una serie de prácticas y herramientas: &lt;br /&gt;
*La forma de trabajar está compuesta de un número de prácticas. Cada práctica debe describirse en formato de cartas y guidelines. &lt;br /&gt;
*La forma de trabajar está soportada por un número de herramientas. Cada herramienta puede suministrar una descripción referente a la configuración así como realizar ciertas actividades definidas por las prácticas. &lt;br /&gt;
*La forma de trabajar se resume en el documento de aproximación. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
*La práctica comienza estableciendo y lanzando un conjunto inicial de prácticas y herramientas como parte del lanzamiento del proyecto. &lt;br /&gt;
*Las mejoras fundamentalmente provienen de peticiones de cambio o por la adopción de nuevas prácticas y herramientas. El equipo es entrenado al inicio y vuelve a serlo con las nuevas prácticas y las mejoras. El resultado del uso de estás prácticas debe ser evaluado, uno de los indicadores son las peticiones de cambio. &lt;br /&gt;
*El ciclo de mejora, entrenamiento y evaluación posibilita una mejora continua de los procesos. Se pueden añadir tantas prácticas y herramientas como sean necesarias para hacer frente a los riesgos del proyecto. Aquellas prácticas que demuestren ser no efectivas pueden ser mejoradas o eliminadas. &lt;br /&gt;
&lt;br /&gt;
==Modeling Essentials==&lt;br /&gt;
&lt;br /&gt;
Esta práctica se utiliza para establecer un estilo y tipo apropiados para guiar las actividades de desarrollo. Con los modelos podremos: &lt;br /&gt;
*Comunicar los requisitos, estructura y comportamiento del sistema. &lt;br /&gt;
*Ver diferentes perspectivas del sistema y entender cómo se relacionan entre sí. &lt;br /&gt;
*Emplear los modelos adecuados que mejor se adaptan a cada necesidad. &lt;br /&gt;
*Ser ágil en la forma de abordar el modelado y documentación. &lt;br /&gt;
*Concentrarse en lo esencial para evitar la producción de documentación innecesaria.&lt;br /&gt;
 &lt;br /&gt;
'''Qué produce'''&lt;br /&gt;
&lt;br /&gt;
La clave para un modelado efectivo es establecer un conjunto ligero de Guías de Modelado detallando como los modelos se relacionan y como deberían ser usados. Estas guías influirán y tendrán en cuenta los distintos modelos introducidos en el proyecto por otras prácticas. &lt;br /&gt;
&lt;br /&gt;
'''Qué hay que hacer'''&lt;br /&gt;
&lt;br /&gt;
El soporte al equipo en las actividades de modelado se inicia cuando se establece el proyecto y debe permanecer durante todo el desarrollo del mismo. &lt;br /&gt;
El equipo recibe entrenamiento en la aplicación de los modelos y estándares seleccionados. Los resultados del trabajo de modelado se evalúan y las formas de trabajar con modelos son mejoradas continuamente.&lt;br /&gt;
&lt;br /&gt;
==Fuente==&lt;br /&gt;
&lt;br /&gt;
*http://elbruno.com/2005/11/25/eup-essential-unified-process/&lt;br /&gt;
*https://sites.google.com/site/.../home/essential-unified-process-essup&lt;br /&gt;
*http://www.comunidadjava.org/?q=node/101&lt;br /&gt;
*http://www.cs.umss.edu.bo/doc/material/mat_gral_42/EssUP.doc&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Essential_Unified_Process&amp;diff=1224345</id>
		<title>Essential Unified Process</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Essential_Unified_Process&amp;diff=1224345"/>
		<updated>2011-12-01T14:41:36Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: Página creada con '{{Definición |nombre= Essential Unified Process |imagen=eup.jpg |tamaño=250 |concepto= El proceso esencial Unificado (EssUP) es un conjunto de prácticas que en conjunto forma...'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Essential Unified Process&lt;br /&gt;
|imagen=eup.jpg&lt;br /&gt;
|tamaño=250&lt;br /&gt;
|concepto= El proceso esencial Unificado (EssUP) es un conjunto de prácticas que en conjunto forman el conocimiento esencial de un ciclo de vida de desarrollo de software.&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
==Introducción==&lt;br /&gt;
&lt;br /&gt;
[[Essential unified process]] (EssUP), fue creado por Ivar Jacobson, como una mejora sobre el Rational Unified Process(RUP) y mucho mas &amp;quot;liviana&amp;quot; que [[Microsoft Solution Framework]] (MSF). Esta basada en MSF y será incluida como parte del [[Team System]]. Consiste en la integración de prácticas eficaces entre los tres principales campos de procesos: el proceso unificado, los métodos ágiles y el proceso de madurez. Cada uno de estos procesos contribuye con diferentes capacidades o características como son: la estructura, la agilidad y la mejora de procesos.&lt;br /&gt;
EssUP esta basado en casos de uso, [[CMMI]] y desarrollo ágil. Se considera una mejora sobre RUP ya que en este último todas las prácticas están relacionadas y no pueden ser usadas de forma aislada. &lt;br /&gt;
EssUP está soportado por Microsoft Visual Studio Team System, y Eclipse.&lt;br /&gt;
&lt;br /&gt;
==Definición==&lt;br /&gt;
&lt;br /&gt;
El proceso esencial Unificado (EssUP) es un conjunto de prácticas que en conjunto forman el conocimiento esencial de un ciclo de vida de desarrollo de software. Las prácticas integran principios que se han mostrado efectivos en los campos del proceso unificado, del desarrollo ágil y la madurez de los procesos, haciendo énfasis en las capacidades que ofrecen: estructura, agilidad y mejora de procesos. &lt;br /&gt;
 &lt;br /&gt;
==Características==&lt;br /&gt;
 &lt;br /&gt;
Ess UP identifica prácticas como desarrollo en base a casos de uso, desarrollo iterativo, architecture driven development, practicas para el equipo y practicas para los procesos, que son tomados de RUP, CMMI, y desarrollo ágil. &lt;br /&gt;
== Essential Practicess==&lt;br /&gt;
La metodología denomina Essential Practicess al conjunto de prácticas, las cuales esta divididas en 6 prácticas técnicas y 4 prácticas transversales.&lt;br /&gt;
 &lt;br /&gt;
==Practicas Técnicas==&lt;br /&gt;
 &lt;br /&gt;
==Architecture Essentials==&lt;br /&gt;
Esta práctica está destinada a obtener una base firme para el desarrollo de sistemas de alta calidad y robustos. Permite a los equipos: &lt;br /&gt;
*Identificar de forma efectiva los riesgos técnicos del proyecto. &lt;br /&gt;
*Consensuar las decisiones principales sobre la estructura y organización del sistema implementado. &lt;br /&gt;
*Verificar que el sistema integra las características clave esperadas por el cliente. &lt;br /&gt;
*Probar de forma objetiva que el sistema elegido es adecuado a su propósito. &lt;br /&gt;
‘‘‘Qué produce’’’&lt;br /&gt;
*Documentación acerca de la arquitectura. &lt;br /&gt;
*Casos de prueba sobre la arquitectura. &lt;br /&gt;
*Vistas de la arquitectura. &lt;br /&gt;
*Verificación de la arquitectura de forma incremental. Se testea cada vez que se produce una nueva versión del sistema. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’&lt;br /&gt;
*Identificar y clarificar los requisitos relevantes para la arquitectura para establecer los objetivos de la misma. &lt;br /&gt;
*Determinar la arquitectura a implementar y especificar el conjunto de pruebas que se usarán para verificar y probar la implementación. &lt;br /&gt;
*Producir un sistema básico verificado y probado para cumplir los requisitos. &lt;br /&gt;
*Entrenar al equipo para usarlo. &lt;br /&gt;
A partir de aquí la arquitectura evoluciona en función de nuevos requisitos y resultados de las pruebas. Todos los sistemas construidos están sujetos al cumplimiento de los test para asegurar la validez de la implementación de la arquitectura. &lt;br /&gt;
&lt;br /&gt;
==Iterative Essentials==&lt;br /&gt;
 &lt;br /&gt;
Esta práctica reduce el riesgo del proyecto mediante el desarrollo incremental del sistema sobre un número de iteraciones. &lt;br /&gt;
El proyecto se descompone en trozos más pequeños o mini proyectos, independientes y limitados en el tiempo. Esta práctica permite al equipo: &lt;br /&gt;
*Planear de forma colaborativa y objetiva, ejecutar y seguir el proyecto. &lt;br /&gt;
*Una gestión del tiempo más eficaz y de más calidad. &lt;br /&gt;
*Demostrar la importancia de trabajar desde un primer momento en el software contando con los feedbacks de clientes y usuarios. &lt;br /&gt;
*Ser ágiles en respuesta a los cambios. &lt;br /&gt;
*Entregar más alta calidad, soluciones más apropiadas, más frecuentemente. &lt;br /&gt;
*Tener un sistema operacional disponible desde bien pronto en el proyecto, que incrementalmente crezca para convertirse finalmente en un sistema completo. &lt;br /&gt;
‘‘‘Qué produce’’’&lt;br /&gt;
Esta práctica implica la producción de un conjunto de elementos relacionados con la administración: &lt;br /&gt;
*El backlog (trabajo atrasado) se llena de cambios, cosas que no funcionan correctamente o fallos, y otras tareas que representan el trabajo por ser realizado. &lt;br /&gt;
*El plan de proyecto identifica el número y tipo de las iteraciones que serán llevadas a cabo. &lt;br /&gt;
*La planificación y las iteraciones son necesarias por los riesgos que implica el proyecto. &lt;br /&gt;
*La iteración de los planes y los ajustes son necesarias para conocer el propósito y el resultado de cada iteración. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’&lt;br /&gt;
*La práctica comienza adaptando los planes del proyecto existentes para integrar las iteraciones al ámbito del proyecto. &lt;br /&gt;
*Los objetivos, criterios de evaluación y trabajo para la primera iteración son aceptados. &lt;br /&gt;
*La práctica guía entonces al equipo a través de la iteración dónde tienen que aplicar otras prácticas para conseguir los objetivos de la iteración. &lt;br /&gt;
*Al final del periodo establecido para la iteración sus resultados serán evaluados y utilizados para ayudar a adaptar los planes a la realidad del proyecto y establecer la siguiente iteración. &lt;br /&gt;
*Esta secuencia se sigue para cada iteración de trabajo del proyecto hasta que, tras los resultados de la iteración final sean evaluados y el proyecto concluya. &lt;br /&gt;
==Use-Case Essentials==&lt;br /&gt;
Una forma ágil, sencilla de controlar y de seguir el desarrollo del proyecto software. &lt;br /&gt;
Esta práctica permite al equipo: &lt;br /&gt;
*Trabajar con los clientes para capturar los requerimientos verdaderamente esenciales. &lt;br /&gt;
*Trabajar juntos más eficientemente para desarrollar rápidamente una solución utilizable. &lt;br /&gt;
*Identificar y entregar el valor esperados del sistema. &lt;br /&gt;
*Establecer el nivel correcto de detalle de los requisitos para satisfacer nuestras necesidades y la de los clientes. &lt;br /&gt;
*Priorizar e identificar subconjuntos de requisitos de una solución mínima para usarla en el desarrollo iterativo. &lt;br /&gt;
*Utilizar un acercamiento sistemático al correcto diseño, implementación y verificación de requisitos. &lt;br /&gt;
‘‘‘Qué produce’’’&lt;br /&gt;
Esta práctica implica la producción de un conjunto de requisitos, así como el diseño y prueba de elementos: &lt;br /&gt;
*Un caso de uso basado en la especificación de los requisitos, escenarios y casos de prueba. &lt;br /&gt;
*La realización del caso de uso conduce al desarrollo del software. &lt;br /&gt;
*La generación de pruebas y los resultados de las pruebas sirven para probar el sistema y grabar los resultados de las pruebas. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’ &lt;br /&gt;
*La práctica comienza identificando los actores y los casos de uso, y eligiendo y priorizando los casos de uso a ser desarrollados. &lt;br /&gt;
*Sigue especificando los casos de uso y sus pruebas, e implementando el software que hallará las pruebas. &lt;br /&gt;
*Finaliza ejecutando las pruebas y siguiendo el progreso en términos de verificado. &lt;br /&gt;
&lt;br /&gt;
==Component Essentials==&lt;br /&gt;
&lt;br /&gt;
Esta práctica se utiliza para desarrollar complejos sistemas formados de componentes más pequeños y más simples. &lt;br /&gt;
Esta práctica permite al equipo: &lt;br /&gt;
*Gestionar la complejidad asociada con el desarrollo del sistema software. &lt;br /&gt;
*Desarrollar complejos sistemas de una forma extensible y mantenible. &lt;br /&gt;
*Desarrollar y verificar las partes separadas de un sistema independientemente y en paralelo. &lt;br /&gt;
*Identificar oportunidades para la reutilización y aprovechamiento de componentes reutilizables. &lt;br /&gt;
*Utilizar la tercera parte de los frameworks y los componentes de biblioteca. &lt;br /&gt;
‘‘‘Qué produce’’’ &lt;br /&gt;
Esta práctica implica la producción de un número de implementaciones y elementos de prueba: &lt;br /&gt;
*Un diseño modelado del sistema a implementar, identificando el conjunto de componentes requeridos. &lt;br /&gt;
*Una descripción de cada componente, incluyendo su comportamiento e interfaces. &lt;br /&gt;
*Código fuente y unidades de prueba para componente. &lt;br /&gt;
*Construcciones integradas del sistema del componente y las pruebas y los resultados para verificar las construcciones. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’&lt;br /&gt;
*La práctica comienza identificando el conjunto de componentes que son necesarios para hallar los requisitos del sistema, y plasmar esta práctica en la especificación del sistema. Esto incluye identificar un adecuado conjunto de pruebas para verificar el sistema. &lt;br /&gt;
*Se sigue definiendo los componentes, incluyendo sus interfaces y unidades de prueba, y desarrollando los componentes para implementar las interfaces y pasar estas pruebas. &lt;br /&gt;
*Finalizamos integrando el sistema, ejecutando las pruebas para verificar el sistema producido y entonces fomentando la utilización tal y cómo los componentes han sido concebidos. &lt;br /&gt;
&lt;br /&gt;
==Product Essentials==&lt;br /&gt;
 &lt;br /&gt;
Administrando versiones del producto Esta práctica se utiliza para administrar el desarrollo de sucesivas evoluciones de un sistema software como una serie de versiones del producto. &lt;br /&gt;
Esta práctica permite al equipo: &lt;br /&gt;
*Planear el proyecto como una serie de versiones de un producto superior estando cada entrega real en pos del beneficio empresarial. &lt;br /&gt;
*Involucrar a los stakeholders en la decisión de fabricación del proceso. &lt;br /&gt;
*Asegurar que el producto realizado cubrirá las necesidades reales de los stakeholders. &lt;br /&gt;
*Gestionar la evolución del software de forma controlada y enfocada al negocio. &lt;br /&gt;
‘‘‘Qué produce’’’ &lt;br /&gt;
Esta práctica implica la producción de un conjunto de elementos de negocio, de planeamientos y de requisitos:&lt;br /&gt;
*El caso de negocio para establecer el valor del producto. &lt;br /&gt;
*El análisis de los stakeholders para asegurar que ellos comprenden y están involucrados en el proyecto. &lt;br /&gt;
*La lista de capacidades, glosario y descripción de cada versión para definir el producto y sus versiones. &lt;br /&gt;
*El plan de proyecto para extraer cómo las series de versiones serán producidas. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’ &lt;br /&gt;
*Esta práctica comienza iniciando el proyecto y estableciendo el caso de negocio de producto. &lt;br /&gt;
*Continúa especificando y planificando las versiones del producto &lt;br /&gt;
*Concluye con el empaquetado de la versión y su aceptación por parte del cliente.&lt;br /&gt;
 &lt;br /&gt;
==Bussiness Use Case Essentials==&lt;br /&gt;
 &lt;br /&gt;
Caso de uso de negocio: gestionando tus requisitos de negocio. &lt;br /&gt;
Podremos captar y redefinir tal y como requieren tus procesos de negocio para que se llegue a una solución software más eficaz y que mejore las prestaciones y el valor que te aportará. &lt;br /&gt;
Con nuestra práctica de caso de uso de negocio esencial, tu equipo se enriquecerá al comprender las necesidades del negocio, y cómo involucrar al negocio para lograr cubrir las necesidades de la organización. &lt;br /&gt;
‘‘‘Qué produce’’’ &lt;br /&gt;
El caso de uso de negocio esencial te permitirá: &lt;br /&gt;
*Adaptar una solución tecnológica a los requisitos con las necesidades del negocio. &lt;br /&gt;
*Maximizar los beneficios generados por la introducción de soluciones automatizadas. &lt;br /&gt;
*Comprender el impacto de las soluciones propuestas al negocio. &lt;br /&gt;
*Incrementar el beneficio realizado por el software a partir del desarrollo de proyectos software. &lt;br /&gt;
&lt;br /&gt;
==Prácticas Transversales==&lt;br /&gt;
 &lt;br /&gt;
==Unified Process Lifecycle Essentials==&lt;br /&gt;
 &lt;br /&gt;
Esta práctica se utiliza para establecer un control sobre el ciclo de vida de un proyecto de desarrollo iterativo y permite a los equipos: &lt;br /&gt;
*Establecer un ciclo de vida del proyecto. &lt;br /&gt;
*Compartir un conjunto de hitos (milestones) comunes con otros proyectos y equipos. &lt;br /&gt;
*Identificar los objetivos a corto plazo para reducir los niveles de riesgo que se presentan. &lt;br /&gt;
*Estructurar los planes en una secuencia de fases bien comprendidas. &lt;br /&gt;
*Aprovechar al máximo los beneficios del desarrollo iterativo. &lt;br /&gt;
Patrones de ciclo de vida&lt;br /&gt;
Está práctica presenta un conjunto de &amp;quot;Patrones de ciclo de vida&amp;quot; que al ser aplicados en el proyecto permiten al equipo: &lt;br /&gt;
*Entender en que estado está el proyecto y como de correcta se está llevando a cabo la gestión de los riesgos. &lt;br /&gt;
*Adoptar un marco de control estándar para guiarlos en el establecimiento apropiado de objetivos y de hitos. &lt;br /&gt;
*Iterar de una manera controlada. &lt;br /&gt;
*Observar la evolución de la arquitectura y los requisitos junto con el desarrollo de una solución de software de alta calidad.&lt;br /&gt;
'''The Common Milestones''' &lt;br /&gt;
Este patrón define un conjunto de hitos o puntos de paso, apropiado para la planificación y el seguimiento de todas las variantes de desarrollo iterativo e incremental de los proyectos software. Los tres principales hitos se muestran a continuación: &lt;br /&gt;
*Objetivos del Ciclo de Vida (Lifecycle Objectives) - Se toman las decisiones clave sobre lo que será y no será en el producto/versión. Los requisitos operativos del software son acordados. &lt;br /&gt;
*Arquitectura del ciclo de vida (Lifecycle Architecture) - Se establece la arquitectura del software y se establece el plan para los riesgos principales asociados. &lt;br /&gt;
*Capacidad operativa inicial (Initial Operational Capability) - El software es totalmente funcional y se realizan los preparativos para la transición del software al cliente y/o el entorno de producción. &lt;br /&gt;
The Lifecycle Phases&lt;br /&gt;
Esta práctica perfecciona el patrón Common Milestones mediante la definición de cuatro fases para el adecuado progreso del proyecto hacia el éxito a través de los tres milestones anteriores. &lt;br /&gt;
El proyecto o ciclo de lanzamiento del producto/versión se divide en cuatro fases secuenciales, cada una de las cuales tiene objetivos bien definidos: &lt;br /&gt;
*Inicio (Inception) - Confirmación del alcance y objetivos y control de los riesgos asociados al negocio. &lt;br /&gt;
*Elaboración (Elaboration) - Concreción de los planes y control de los riesgos arquitectónicos y técnicos. &lt;br /&gt;
*Construcción (Construction) - Construcción del producto y control de los riesgos asociados a la ejecución del proyecto. &lt;br /&gt;
*Transición (Transition) - Entrega del producto y control de los riesgos de despliegue. &lt;br /&gt;
Estas cuatro fases son tomadas de RUP por lo que en dicha metodología se puede encontrar información ampliada y actividades concretas a realizar en cada fase. &lt;br /&gt;
&lt;br /&gt;
==Team Essentials==&lt;br /&gt;
&lt;br /&gt;
Esta práctica es utilizada para reunir un equipo de proyecto y establecer un ambiente de trabajo efectivo. Para ello el equipo debe: &lt;br /&gt;
*Adoptar las medidas de liderazgo y de organización. &lt;br /&gt;
*Establecer y adquirir las competencias necesarias para tener éxito. &lt;br /&gt;
*Desarrollar formas efectivas de colaborar y organizar su trabajo. &lt;br /&gt;
*Crear una ambiente en el que todos los miembros del equipo sean capaces de contribuir al máximo de su capacidad durante todo el proyecto. &lt;br /&gt;
‘‘‘Qué produce’’’&lt;br /&gt;
El objetivo es la creación de trabajo en equipo eficaz y la producción de elementos relacionados: &lt;br /&gt;
*En la carta del equipo se refleja la estructura del equipo y las responsabilidades. &lt;br /&gt;
*Los miembros integrados en el equipo deben evolucionar hacia maneras efectivas de colaborar. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’&lt;br /&gt;
*La práctica comienza con la formación del equipo inicial del proyecto como parte de la puesta en marcha del mismo. &lt;br /&gt;
*A lo largo del desarrollo, los planes de proyecto se adaptan para reflejar la dotación de personal y la eficacia del equipo, el equipo del proyecto está orientado a mejorar el trabajo del equipo y eliminar los obstáculos que impiden que el trabajo efectivo del equipo.&lt;br /&gt;
&lt;br /&gt;
==Process Essentials==&lt;br /&gt;
&lt;br /&gt;
Está práctica permite mejorar y adaptar la forma de trabajo del equipo, en concreto, permite al equipo: &lt;br /&gt;
*Identificar, preparar y reunir un conjunto de prácticas y herramientas adecuadas para conseguir los objetivos del proyecto. &lt;br /&gt;
*Introducir nuevas prácticas individual y gradualmente según sea necesario. &lt;br /&gt;
*Comparar e integrar prácticas estándar y particulares preservando los aspectos que el equipo ejecuta correctamente y señalando aquellos que no. &lt;br /&gt;
*Evolucionar las prácticas en base a la experiencia y las lecciones aprendidas. &lt;br /&gt;
‘‘‘Qué produce’’’&lt;br /&gt;
El objetivo es el establecimiento de una forma efectiva de trabajo y la producción de una serie de prácticas y herramientas: &lt;br /&gt;
*La forma de trabajar está compuesta de un número de prácticas. Cada práctica debe describirse en formato de cartas y guidelines. &lt;br /&gt;
*La forma de trabajar está soportada por un número de herramientas. Cada herramienta puede suministrar una descripción referente a la configuración así como realizar ciertas actividades definidas por las prácticas. &lt;br /&gt;
*La forma de trabajar se resume en el documento de aproximación. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’&lt;br /&gt;
*La práctica comienza estableciendo y lanzando un conjunto inicial de prácticas y herramientas como parte del lanzamiento del proyecto. &lt;br /&gt;
*Las mejoras fundamentalmente provienen de peticiones de cambio o por la adopción de nuevas prácticas y herramientas. El equipo es entrenado al inicio y vuelve a serlo con las nuevas prácticas y las mejoras. El resultado del uso de estás prácticas debe ser evaluado, uno de los indicadores son las peticiones de cambio. &lt;br /&gt;
*El ciclo de mejora, entrenamiento y evaluación posibilita una mejora continua de los procesos. Se pueden añadir tantas prácticas y herramientas como sean necesarias para hacer frente a los riesgos del proyecto. Aquellas prácticas que demuestren ser no efectivas pueden ser mejoradas o eliminadas. &lt;br /&gt;
&lt;br /&gt;
==Modeling Essentials==&lt;br /&gt;
&lt;br /&gt;
Esta práctica se utiliza para establecer un estilo y tipo apropiados para guiar las actividades de desarrollo. Con los modelos podremos: &lt;br /&gt;
*Comunicar los requisitos, estructura y comportamiento del sistema. &lt;br /&gt;
*Ver diferentes perspectivas del sistema y entender cómo se relacionan entre sí. &lt;br /&gt;
*Emplear los modelos adecuados que mejor se adaptan a cada necesidad. &lt;br /&gt;
*Ser ágil en la forma de abordar el modelado y documentación. &lt;br /&gt;
*Concentrarse en lo esencial para evitar la producción de documentación innecesaria. &lt;br /&gt;
‘‘‘Qué produce’’’&lt;br /&gt;
La clave para un modelado efectivo es establecer un conjunto ligero de Guías de Modelado detallando como los modelos se relacionan y como deberían ser usados. Estas guías influirán y tendrán en cuenta los distintos modelos introducidos en el proyecto por otras prácticas. &lt;br /&gt;
‘‘‘Qué hay que hacer’’’&lt;br /&gt;
El soporte al equipo en las actividades de modelado se inicia cuando se establece el proyecto y debe permanecer durante todo el desarrollo del mismo. &lt;br /&gt;
El equipo recibe entrenamiento en la aplicación de los modelos y estándares seleccionados. Los resultados del trabajo de modelado se evalúan y las formas de trabajar con modelos son mejoradas continuamente.&lt;br /&gt;
&lt;br /&gt;
==Fuente==&lt;br /&gt;
&lt;br /&gt;
*http://elbruno.com/2005/11/25/eup-essential-unified-process/&lt;br /&gt;
*https://sites.google.com/site/.../home/essential-unified-process-essup&lt;br /&gt;
*http://www.comunidadjava.org/?q=node/101&lt;br /&gt;
*http://www.cs.umss.edu.bo/doc/material/mat_gral_42/EssUP.doc&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Kent_Beck&amp;diff=1130411</id>
		<title>Kent Beck</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Kent_Beck&amp;diff=1130411"/>
		<updated>2011-11-08T13:14:10Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: Página creada con '  {{Ficha Persona |nombre       = Kent Beck |imagen       = Kent.jpg |tamaño       = 250 |lugar de nacimiento = Estados Unidos |nacionalidad = estadounidense }}   ==Kent Beck==...'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&lt;br /&gt;
{{Ficha Persona&lt;br /&gt;
|nombre       = Kent Beck&lt;br /&gt;
|imagen       = Kent.jpg&lt;br /&gt;
|tamaño       = 250&lt;br /&gt;
|lugar de nacimiento = Estados Unidos&lt;br /&gt;
|nacionalidad = estadounidense&lt;br /&gt;
}}&lt;br /&gt;
 &lt;br /&gt;
==Kent Beck==&lt;br /&gt;
       &lt;br /&gt;
Kent Beck es uno de los creadores de la [[Metodología ágil]] para el [[desarrollo de software]] conocida como [[programación extrema]]. También creó, junto con [[Erich Gamma]] el [[framework]] de pruebas unitarias para [[Java]], [[JUnit]].&lt;br /&gt;
 &lt;br /&gt;
==Libros==&lt;br /&gt;
*[[Smalltalk Best Practice Patterns]] (ISBN 0-13-476904-X)&lt;br /&gt;
*[[Una explicación de la programación extrema: aceptar el cambio]] (ISBN 84-7829-055-9)&lt;br /&gt;
*[[Test-Driven Development: By Example]] (ISBN 0-321-14653-0)&lt;br /&gt;
*[[Planning Extreme Programming]] (ISBN 0-201-71091-9), con Martin Fowler&lt;br /&gt;
&lt;br /&gt;
==Reflexiones==&lt;br /&gt;
“El problema (de los proyectos de [[desarrollo de software]]) no es el cambio porque el cambio se va a producir; el problema, más bien, es la incapacidad de afrontar el cambio cuando se produce”.&lt;br /&gt;
Ahí, se encuentra desde mi punto de vista, una de los grandes problemas de los proyectos de desarrollo de software y es el hecho de no enfocarse desde el punto de vista de que las especificaciones iniciales van a cambiar, ya sea porque el usuario no ha trasladado adecuadamente lo que quiere, porque el equipo de proyecto no ha interpretado correctamente lo que se le ha pedido o porque los requisitos y/o las prioridades han cambiado.&lt;br /&gt;
No es realista afrontar un proyecto de esa manera y sin embargo está a la orden del día encontrarnos con desarrollos que no tienen previsto un mantenimiento y eso es un error tanto aplicando metodologías ágiles como, sobre todo, aplicando [[metodologías clásicas]].&lt;br /&gt;
El [[software]] se tiene que desarrollar pensando en que va a cambiar y los medios puestos a disposición del sistema de información (o del conjunto de sistemas de información de una organización) deben poder dar respuesta a cuando esos cambios se produzcan, que a veces no sabremos cuando, pero sí sabemos que ocurrirán.&lt;br /&gt;
&lt;br /&gt;
==Lineamientos principales que Kent Beck desarrolla en su texto [[Kent Beck, Extreme Programming Explained]]==&lt;br /&gt;
&lt;br /&gt;
==Valores==&lt;br /&gt;
Son conceptos universales, idealmente se aplican en todos los ámbitos. Es el camino para conducir el propósito a la práctica.&lt;br /&gt;
&lt;br /&gt;
==Communicación==&lt;br /&gt;
Es un factor importante para crear sentido de equipo y lograr cooperación efectiva. Cuando surgen problemas sorpresivos puede ayudar a resolverlos.&lt;br /&gt;
La mayor parte de los problemas son causados por carencia de conocimiento o por carencia de comunicación.&lt;br /&gt;
Si el problema tiene origen en la falta de conocimiento, no hay nada que pueda hacerse de antemano.&lt;br /&gt;
Cuando nos encontremos con un problema, preguntémonos si puede ser causado por una carencia de comunicación. Si es así, analicemos ¿Qué tipo de comunicación necesitamos para abordar el problema? ¿Qué comunicación necesitamos para mantenernos fuera de esta situación en el futuro?&lt;br /&gt;
&lt;br /&gt;
==Simplicidad==&lt;br /&gt;
Es el valor más intensamente intelectual. Se trata de pensar las cosas de forma de eliminar toda complejidad innecesaria.&lt;br /&gt;
&lt;br /&gt;
==Retroalimentación==&lt;br /&gt;
Los cambios son inevitables y crean la necesidad del [[Feedback]]. Personalmente entiendo que es común el escenario en el cual la coyuntura nos condiciona a implementar funcionalidad de forma imperfecta en uno o varios aspectos. Esta situación crea una fuerte necesidad de [[Feedback]], de otra forma se asume el riesgo de perpetuar esa imperfección y quizá ya nadie recuerde su existencia.&lt;br /&gt;
Existen fundamentalmente tres motivos que dificultan hacer las cosas bien al primer intento:&lt;br /&gt;
*Al resolver un problema por primera vez, puede haber más de una solución que funcione o que la solución no sea totalmente clara,&lt;br /&gt;
*Lo que es bueno hoy puede no serlo mañana,&lt;br /&gt;
*Hacer algo con absoluta corrección podría insumir tanto tiempo que las circunstancias cambiantes futuras invaliden la solución de hoy, antes que se finalice.&lt;br /&gt;
Lograr satisfacción en un esquema de mejoras a cambio de, esperar la perfección al instante, es posible sólo acudiendo al [[Feedback]], que puede producirse de varias formas:&lt;br /&gt;
*Escuchar distintas opiniones sobre una idea,&lt;br /&gt;
*Como se ve el código una vez implementada la idea,&lt;br /&gt;
*Si los tests fueron fáciles de escribir,&lt;br /&gt;
*Si los tests ejecutaron,&lt;br /&gt;
*Cómo la idea funciona una vez que se hizo el [[deploy]].&lt;br /&gt;
Un equipo debe esforzarse en generar tanto [[Feedback]] como pueda, tan rápidamente como le sea posible. Tan pronto como se conoce la situación, tan pronto podremos adaptarnos.&lt;br /&gt;
&lt;br /&gt;
==Coraje==&lt;br /&gt;
Es la acción efectiva de enfrentar el temor.&lt;br /&gt;
A veces el coraje se manifiesta en forma de paciencia. Cuando uno sabe que existe un problema pero no lo conoce, se requiere coraje para esperar que se manifieste distintivamente.&lt;br /&gt;
Hay que tener en cuenta que el coraje como valor principal, sin valores que contrabalanceen, puede ser peligroso, incluso puede jugar contra el espíritu del equipo. Pero cuando el coraje juega en confluencia con los otros valores es una herramienta poderosa.&lt;br /&gt;
&lt;br /&gt;
==Respeto==&lt;br /&gt;
Este es el valor que subyace a los otros cuatro. [[XP]] funciona en un marco dónde cada integrante del equipo considera a cada otro y lo que está haciendo. La contribución de cada persona necesita respeto.&lt;br /&gt;
==Otros==&lt;br /&gt;
*Seguridad&lt;br /&gt;
*Predicción &lt;br /&gt;
*Calidad de vida&lt;br /&gt;
&lt;br /&gt;
==Las 4 reglas de Kent Beck para escribir código simple==&lt;br /&gt;
*Estar bien cubierto y satisfacer las aserciones de una buena batería de [[tests unitarios]].&lt;br /&gt;
*Expresar las ideas que nosotros como programadores queremos expresar [[código auto-documentado]].&lt;br /&gt;
*Decir cada cosa una única vez.&lt;br /&gt;
*Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro; y tener el mínimo número de clases y métodos teniendo en cuenta el [[Principio de Responsabilidad Única]].&lt;br /&gt;
&lt;br /&gt;
==Fuente==&lt;br /&gt;
*http://xprogramming.com/index.php&lt;br /&gt;
*http://www.extremeprogramming.org/&lt;br /&gt;
*http://alonsogarciapablo.com/blog/las-4-reglas-de-kent-beck-para-escribir-codigo-simple/&lt;br /&gt;
*http://booksforgeeks.com/author/kent-beck&lt;br /&gt;
*http://ptgmedia.pearsoncmg.com/images/9780321413093/samplechapter/BeckCh_0321413091.pdf&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Jeffrey_Zeldman&amp;diff=1112820</id>
		<title>Jeffrey Zeldman</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Jeffrey_Zeldman&amp;diff=1112820"/>
		<updated>2011-11-03T15:18:52Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Ficha Persona&lt;br /&gt;
|nombre       = Jeffrey Zeldman&lt;br /&gt;
|nombre completo = Jeffrey Zeldman&lt;br /&gt;
|imagen       = zeld.jpg&lt;br /&gt;
|tamaño       = 250&lt;br /&gt;
}}&lt;br /&gt;
 &lt;br /&gt;
==Jeffrey Zeldman==&lt;br /&gt;
 &lt;br /&gt;
Jeffrey Zeldman es fundador y director ejecutivo creativo del estudio de diseño Happy Cog, fundador de [[A List Apart]], una de las revistas más respetadas e influyentes sobre diseño y desarrollo web; autor de más de 10 libros sobre [[diseño]] y [[estándares web]], se le considera un referente en el diseño web que desde 1995 mantiene su blog [[Jeffrey Zeldman Presents The Daily Report]].&lt;br /&gt;
Zeldman es el cofundador de la [[Web Standards Project (WaSP)]], una página creada por un grupo de diseñadores web profesionales que buscan incentivar y fortalecer el uso de los estándares web recomendadas por el [[World Wide Web Consortium (W3C)]] y otras entidades normativas. &lt;br /&gt;
Jeffrey Zeldman es considerado uno de los primeros diseñadores web, ha tenido un impacto pronunciado en el medio y la profesión donde se le conoce como The King of Web Standards (El Rey de los Estándares Web), es un conferencista y autor de algunas obras que tratan el diseño web.&lt;br /&gt;
Zeldman promueve el uso de los estándares web porque los considera buenas soluciones  para problemas que se presentan a la hora de realizar diseño web, como en [[Adobe Flash]]. Él busca derribar el mito de que las páginas para ser accesibles no deben tener mucho diseño.  Sus libros han ayudado a mejorar cuestiones técnicas, visuales, de usabilidad y accesibilidad utilizando [[XHTML]] y [[CSS]]. Su coalición ha logrado persuadir a Microsoft  de hacer de sus navegadores un producto útil (dentro de lo que cabe, ya que en la actualidad Microsoft no ha logrado superar alternativas libres y mejores)&lt;br /&gt;
==Opinión de Zeldman sobre los web standards==&lt;br /&gt;
Zeldman explica que durante mucho tiempo, los navegadores se han desarrollado conforme a [[CSS2]], [[HTML]], [[XHTML]], [[JavaScript]] y [[ActionScript]], y que por lo tanto, en cierto sentido, el tiempo se ha parado desde 2000, pero cree que la aceptación de las normas ha ido en aumento durante este tiempo.  Últimamente ha habido una toma de conciencia entre muchos desarrolladores y diseñadores, ya que entienden que la web debe ser semántica, y que hay un creciente interés en los [[microformatos]] y la curiosidad acerca de [[HTML5]].&lt;br /&gt;
Zeldman, que co-fundó el [[Web Standards Project]], en 1998, admite que [[HTML5]] está rodeado de gran malestar. Muchos de los que utilizan web standards están preocupados por la dirección que el [[HTML5]] está tomando, pero él piensa que el panorama general no es realmente tan malo. Para él, la comunidad más grande, la gente que utiliza [[Dreamweaver]] o diseña en tablas está comenzando a pensar en la semántica y en la optimización de [[CSS]], y además, todos los frameworks que han salido están ayudando a conseguir la aceptación de [[CSS]]. &lt;br /&gt;
Todavía hay mucho por hacer para mejorar los estándares web, Zeldman cuenta que muchas veces la gente no entiende bien como aplicarlos, y piensa que un buen [[CSS]] es el que tiene muchos [[divs]] sin código semántico.  Por encima de todo, las cosas deben ser simples.&lt;br /&gt;
==Datos curiosos==&lt;br /&gt;
*En su estudio de Nueva York, Zeldman utiliza iMacs de 24? con Mac OS X 10.6 Snow Leopard, y su conexión a Internet tiene un download de 10Mb por segundo.&lt;br /&gt;
*Es fanático de Tweetie para iPhone.&lt;br /&gt;
*El libro más reciente de Zeldman es Diseñando con Web Standards.&lt;br /&gt;
*A la hora de editar en HTML usa Page Spinner y TextMate, y para diseñar en papel  o en código, Photoshop e Illustrator.&lt;br /&gt;
*Sus aplicaciones de iPhone preferidas son Dropbox, Mobile Me, Snapz Pro X, CoverScout y xScope.&lt;br /&gt;
==Véase también==&lt;br /&gt;
http://twitter.com/zeldman&lt;br /&gt;
http://www.flickr.com/photos/zeldman/&lt;br /&gt;
==Fuente== &lt;br /&gt;
*http://origenarts.com/jeffrey-zeldman-estandares-web-para-que/&lt;br /&gt;
*http://blog.iws.com.ve/2009/04/16/jeffrey-zeldman-nos-ayuda-a-llevar-nuestro-talento-al-web/ &lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Archivo:Jeffrey_Zeldman_(Nueva_York,_1955),_ingeniero_inform%C3%A1tico.jpg&amp;diff=1112775</id>
		<title>Archivo:Jeffrey Zeldman (Nueva York, 1955), ingeniero informático.jpg</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Archivo:Jeffrey_Zeldman_(Nueva_York,_1955),_ingeniero_inform%C3%A1tico.jpg&amp;diff=1112775"/>
		<updated>2011-11-03T15:13:38Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Sumario ==&lt;br /&gt;
&lt;br /&gt;
== Estado de copyright: ==&lt;br /&gt;
&lt;br /&gt;
== Fuente: ==&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Jeffrey_Zeldman&amp;diff=1112698</id>
		<title>Jeffrey Zeldman</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Jeffrey_Zeldman&amp;diff=1112698"/>
		<updated>2011-11-03T14:56:11Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: Página creada con '{{Ficha Persona |nombre       = Jeffrey Zeldman |nombre completo = Jeffrey Zeldman |imagen       = zeld.jpg |tamaño       = 250 }}   ==Jeffrey Zeldman==   Jeffrey Zeldman es fu...'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Ficha Persona&lt;br /&gt;
|nombre       = Jeffrey Zeldman&lt;br /&gt;
|nombre completo = Jeffrey Zeldman&lt;br /&gt;
|imagen       = zeld.jpg&lt;br /&gt;
|tamaño       = 250&lt;br /&gt;
}}&lt;br /&gt;
 &lt;br /&gt;
==Jeffrey Zeldman==&lt;br /&gt;
 &lt;br /&gt;
Jeffrey Zeldman es fundador y director ejecutivo creativo del estudio de diseño Happy Cog, fundador de [[A List Apart]], una de las revistas más respetadas e influyentes sobre diseño y desarrollo web; autor de más de 10 libros sobre [[diseño]] y [[estándares web]], se le considera un referente en el diseño web que desde 1995 mantiene su blog [[Jeffrey Zeldman Presents The Daily Report]].&lt;br /&gt;
Zeldman es el cofundador de la [[Web Standards Project (WaSP)]], una página creada por un grupo de diseñadores web profesionales que buscan incentivar y fortalecer el uso de los estándares web recomendadas por el [[World Wide Web Consortium (W3C)]] y otras entidades normativas. &lt;br /&gt;
Jeffrey Zeldman es considerado uno de los primeros diseñadores web, ha tenido un impacto pronunciado en el medio y la profesión donde se le conoce como The King of Web Standards (El Rey de los Estándares Web), es un conferencista y autor de algunas obras que tratan el diseño web.&lt;br /&gt;
Zeldman promueve el uso de los estándares web porque los considera buenas soluciones  para problemas que se presentan a la hora de realizar diseño web, como en [[Adobe Flash]]. Él busca derribar el mito de que las páginas para ser accesibles no deben tener mucho diseño.  Sus libros han ayudado a mejorar cuestiones técnicas, visuales, de usabilidad y accesibilidad utilizando [[XHTML]] y [[CSS]]. Su coalición ha logrado persuadir a Microsoft  de hacer de sus navegadores un producto útil (dentro de lo que cabe, ya que en la actualidad Microsoft no ha logrado superar alternativas libres y mejores)&lt;br /&gt;
==Opinión de Zeldman sobre los web standards==&lt;br /&gt;
Zeldman explica que durante mucho tiempo, los navegadores se han desarrollado conforme a [[CSS2]], [[HTML]], [[XHTML]], [[JavaScript]] y [[ActionScript]], y que por lo tanto, en cierto sentido, el tiempo se ha parado desde 2000, pero cree que la aceptación de las normas ha ido en aumento durante este tiempo.  Últimamente ha habido una toma de conciencia entre muchos desarrolladores y diseñadores, ya que entienden que la web debe ser semántica, y que hay un creciente interés en los [[microformatos]] y la curiosidad acerca de [[HTML5]].&lt;br /&gt;
Zeldman, que co-fundó el [[Web Standards Project]], en 1998, admite que [[HTML5]] está rodeado de gran malestar. Muchos de los que utilizan web standards están preocupados por la dirección que el [[HTML5]] está tomando, pero él piensa que el panorama general no es realmente tan malo. Para él, la comunidad más grande, la gente que utiliza [[Dreamweaver]] o diseña en tablas está comenzando a pensar en la semántica y en la optimización de [[CSS]], y además, todos los frameworks que han salido están ayudando a conseguir la aceptación de [[CSS]]. &lt;br /&gt;
Todavía hay mucho por hacer para mejorar los estándares web, Zeldman cuenta que muchas veces la gente no entiende bien como aplicarlos, y piensa que un buen [[CSS]] es el que tiene muchos [[divs]] sin código semántico.  Por encima de todo, las cosas deben ser simples.&lt;br /&gt;
==Datos curiosos==&lt;br /&gt;
*En su estudio de Nueva York, Zeldman utiliza iMacs de 24? con Mac OS X 10.6 Snow Leopard, y su conexión a Internet tiene un download de 10Mb por segundo.&lt;br /&gt;
*Es fanático de Tweetie para iPhone.&lt;br /&gt;
*El libro más reciente de Zeldman es Diseñando con Web Standards.&lt;br /&gt;
*A la hora de editar en HTML usa Page Spinner y TextMate, y para diseñar en papel  o en código, Photoshop e Illustrator.&lt;br /&gt;
*Sus aplicaciones de iPhone preferidas son Dropbox, Mobile Me, Snapz Pro X, CoverScout y xScope.&lt;br /&gt;
==Véase también==&lt;br /&gt;
http://twitter.com/zeldman&lt;br /&gt;
http://www.flickr.com/photos/zeldman/&lt;br /&gt;
El término Web 3.0 apareció por primera vez en 2006 en un artículo de Jeffrey Zeldman, crítico de la Web 2.0 y asociado a tecnologias como AJAX.&lt;br /&gt;
 &lt;br /&gt;
==Fuente==&lt;br /&gt;
 &lt;br /&gt;
*http://origenarts.com/jeffrey-zeldman-estandares-web-para-que/&lt;br /&gt;
*http://blog.iws.com.ve/2009/04/16/jeffrey-zeldman-nos-ayuda-a-llevar-nuestro-talento-al-web/&lt;br /&gt;
 &lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Archivo:Metagl.gif&amp;diff=1057807</id>
		<title>Archivo:Metagl.gif</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Archivo:Metagl.gif&amp;diff=1057807"/>
		<updated>2011-10-20T15:19:39Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Sumario ==&lt;br /&gt;
&lt;br /&gt;
== Estado de copyright: ==&lt;br /&gt;
&lt;br /&gt;
== Fuente: ==&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057758</id>
		<title>Metodología ágil</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057758"/>
		<updated>2011-10-20T15:15:53Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Metodología ágil&lt;br /&gt;
|imagen= metagl.gif&lt;br /&gt;
|tamaño= 250&lt;br /&gt;
|concepto= Método para el desarrollo de software que permite incorporar cambios con rapidez y en cualquier fase del proyecto.&lt;br /&gt;
}}&lt;br /&gt;
==Metodología ágil==&lt;br /&gt;
En muchas ocasiones, los modelos de gestión tradicionales no sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces ha ocurrido: cuando el proyecto se encuentra bastante avanzado y no va por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios obligan a desechar todo el trabajo realizado hasta entonces, lo que impide acabar en el plazo previsto.&lt;br /&gt;
Dado que los cambios nunca van a dejar de existir, es necesario ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses [[Takeuchi]] y [[Nonaka]] estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: [[Xerox]], [[Canon]], [[Honda]], [[NEC]], [[Epson]], [[Brother]], [[3M]] y [[Hewlett-Packard]]. De ahí extrajeron la base de la metodología ágil [[SCRUM]]  que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.&lt;br /&gt;
==Historia==&lt;br /&gt;
La definición moderna de metodología ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra las metodologías de &amp;quot;peso pesado&amp;quot;, muy estructuradas y estrictas, extraídas del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.&lt;br /&gt;
Las metodologías de desarrollo ágiles e iterativas pueden ser vistas como un retroceso a las prácticas observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías tradicionales). Inicialmente, las metodologías ágiles fueron llamadas metodologías de &amp;quot;peso liviano&amp;quot;.&lt;br /&gt;
En el año 2001, miembros prominentes de la comunidad se reunieron en [[Snowbird]], [[Utah]], y adoptaron el nombre de &amp;quot; metodologías ágiles&amp;quot;. Poco después, algunas de estas personas formaron la &amp;quot;alianza ágil&amp;quot;, una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchas metodologías similares a las ágiles fueron creadas antes del 2000. Entre los más notables se encuentran: Scrum (1986), [[Crystal Clear]] (cristal transparente), programación extrema (en inglés eXtreme Programming o [[XP]], 1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).&lt;br /&gt;
[[Kent Beck]] creó la metodología de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del [[Sistema exhaustivo de compensaciones de Chrysler (C3)]]. Mientras [[Chrysler]] cancelaba ese proyecto, la metodología fue refinada por [[Ron Jeffries]].&lt;br /&gt;
El punto de partida de esta reunión fue el Manifiesto Ágil, un documento que resume la filosofía ágil.&lt;br /&gt;
 &lt;br /&gt;
==Manifiesto Ágil==&lt;br /&gt;
 &lt;br /&gt;
Según el Manifiesto se valora:&lt;br /&gt;
 &lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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 una decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental.&lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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. &lt;br /&gt;
==Algunas Metodologías ágiles==&lt;br /&gt;
Algunas metodologías ágiles de desarrollo de software:&lt;br /&gt;
*[[Adaptive Software Development (ASD)]].&lt;br /&gt;
*[[Agile Unified Process (AUP)]].&lt;br /&gt;
*[[Crystal Clear]].&lt;br /&gt;
*[[Essential Unified Process (EssUP)]].&lt;br /&gt;
*[[Feature Driven Development (FDD)]].&lt;br /&gt;
*[[Lean Software Development (LSD)]].&lt;br /&gt;
*[[Kanban]].&lt;br /&gt;
*[[Open Unified Process (OpenUP)]].&lt;br /&gt;
*[[Programación Extrema (XP)]].&lt;br /&gt;
*[[Método de desarrollo de sistemas dinámicos (DSDM)]].&lt;br /&gt;
*[[Scrum]].&lt;br /&gt;
 &lt;br /&gt;
==Fuente==&lt;br /&gt;
*http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf&lt;br /&gt;
*http://pymecrunch.com/scrum-metodologia-agil-para-tus-proyectos&lt;br /&gt;
*http://www.fi.uba.ar/.../schenone-tesisdegradoingenieriainformatica.pdf&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057612</id>
		<title>Metodología ágil</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057612"/>
		<updated>2011-10-20T15:04:23Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Metodología ágil&lt;br /&gt;
|imagen= metagl.jpg&lt;br /&gt;
|tamaño= 250&lt;br /&gt;
|concepto= Método para el desarrollo de software que permite incorporar cambios con rapidez y en cualquier fase del proyecto.&lt;br /&gt;
}}&lt;br /&gt;
==Metodología ágil==&lt;br /&gt;
En muchas ocasiones, los modelos de gestión tradicionales no sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces ha ocurrido: cuando el proyecto se encuentra bastante avanzado y no va por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios obligan a desechar todo el trabajo realizado hasta entonces, lo que impide acabar en el plazo previsto.&lt;br /&gt;
Dado que los cambios nunca van a dejar de existir, es necesario ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses [[Takeuchi]] y [[Nonaka]] estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: [[Xerox]], [[Canon]], [[Honda]], [[NEC]], [[Epson]], [[Brother]], [[3M]] y [[Hewlett-Packard]]. De ahí extrajeron la base de la metodología ágil [[SCRUM]]  que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.&lt;br /&gt;
==Historia==&lt;br /&gt;
La definición moderna de metodología ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra las metodologías de &amp;quot;peso pesado&amp;quot;, muy estructuradas y estrictas, extraídas del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.&lt;br /&gt;
Las metodologías de desarrollo ágiles e iterativas pueden ser vistas como un retroceso a las prácticas observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías tradicionales). Inicialmente, las metodologías ágiles fueron llamadas metodologías de &amp;quot;peso liviano&amp;quot;.&lt;br /&gt;
En el año 2001, miembros prominentes de la comunidad se reunieron en [[Snowbird]], [[Utah]], y adoptaron el nombre de &amp;quot; metodologías ágiles&amp;quot;. Poco después, algunas de estas personas formaron la &amp;quot;alianza ágil&amp;quot;, una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchas metodologías similares a las ágiles fueron creadas antes del 2000. Entre los más notables se encuentran: Scrum (1986), [[Crystal Clear]] (cristal transparente), programación extrema (en inglés eXtreme Programming o [[XP]], 1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).&lt;br /&gt;
[[Kent Beck]] creó la metodología de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del [[Sistema exhaustivo de compensaciones de Chrysler (C3)]]. Mientras [[Chrysler]] cancelaba ese proyecto, la metodología fue refinada por [[Ron Jeffries]].&lt;br /&gt;
El punto de partida de esta reunión fue el Manifiesto Ágil, un documento que resume la filosofía ágil.&lt;br /&gt;
 &lt;br /&gt;
==Manifiesto Ágil==&lt;br /&gt;
 &lt;br /&gt;
Según el Manifiesto se valora:&lt;br /&gt;
 &lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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 una decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental.&lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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. &lt;br /&gt;
==Algunas Metodologías ágiles==&lt;br /&gt;
Algunas metodologías ágiles de desarrollo de software:&lt;br /&gt;
*[[Adaptive Software Development (ASD)]].&lt;br /&gt;
*[[Agile Unified Process (AUP)]].&lt;br /&gt;
*[[Crystal Clear]].&lt;br /&gt;
*[[Essential Unified Process (EssUP)]].&lt;br /&gt;
*[[Feature Driven Development (FDD)]].&lt;br /&gt;
*[[Lean Software Development (LSD)]].&lt;br /&gt;
*[[Kanban]].&lt;br /&gt;
*[[Open Unified Process (OpenUP)]].&lt;br /&gt;
*[[Programación Extrema (XP)]].&lt;br /&gt;
*[[Método de desarrollo de sistemas dinámicos (DSDM)]].&lt;br /&gt;
*[[Scrum]].&lt;br /&gt;
 &lt;br /&gt;
==Fuente==&lt;br /&gt;
*http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf&lt;br /&gt;
*http://pymecrunch.com/scrum-metodologia-agil-para-tus-proyectos&lt;br /&gt;
*http://www.fi.uba.ar/.../schenone-tesisdegradoingenieriainformatica.pdf&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057520</id>
		<title>Metodología ágil</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057520"/>
		<updated>2011-10-20T14:54:58Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Metodología ágil&lt;br /&gt;
|imagen= ma.jpg&lt;br /&gt;
|tamaño= 250&lt;br /&gt;
|concepto= Método para el desarrollo de software que permite incorporar cambios con rapidez y en cualquier fase del proyecto.&lt;br /&gt;
}}&lt;br /&gt;
==Metodología ágil==&lt;br /&gt;
En muchas ocasiones, los modelos de gestión tradicionales no sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces ha ocurrido: cuando el proyecto se encuentra bastante avanzado y no va por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios obligan a desechar todo el trabajo realizado hasta entonces, lo que impide acabar en el plazo previsto.&lt;br /&gt;
Dado que los cambios nunca van a dejar de existir, es necesario ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses [[Takeuchi]] y [[Nonaka]] estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: [[Xerox]], [[Canon]], [[Honda]], [[NEC]], [[Epson]], [[Brother]], [[3M]] y [[Hewlett-Packard]]. De ahí extrajeron la base de la metodología ágil [[SCRUM]]  que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.&lt;br /&gt;
==Historia==&lt;br /&gt;
La definición moderna de metodología ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra las metodologías de &amp;quot;peso pesado&amp;quot;, muy estructuradas y estrictas, extraídas del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.&lt;br /&gt;
Las metodologías de desarrollo ágiles e iterativas pueden ser vistas como un retroceso a las prácticas observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías tradicionales). Inicialmente, las metodologías ágiles fueron llamadas metodologías de &amp;quot;peso liviano&amp;quot;.&lt;br /&gt;
En el año 2001, miembros prominentes de la comunidad se reunieron en [[Snowbird]], [[Utah]], y adoptaron el nombre de &amp;quot; metodologías ágiles&amp;quot;. Poco después, algunas de estas personas formaron la &amp;quot;alianza ágil&amp;quot;, una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchas metodologías similares a las ágiles fueron creadas antes del 2000. Entre los más notables se encuentran: Scrum (1986), [[Crystal Clear]] (cristal transparente), programación extrema (en inglés eXtreme Programming o [[XP]], 1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).&lt;br /&gt;
[[Kent Beck]] creó la metodología de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del [[Sistema exhaustivo de compensaciones de Chrysler (C3)]]. Mientras [[Chrysler]] cancelaba ese proyecto, la metodología fue refinada por [[Ron Jeffries]].&lt;br /&gt;
El punto de partida de esta reunión fue el Manifiesto Ágil, un documento que resume la filosofía ágil.&lt;br /&gt;
 &lt;br /&gt;
==Manifiesto Ágil==&lt;br /&gt;
 &lt;br /&gt;
Según el Manifiesto se valora:&lt;br /&gt;
 &lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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 una decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental.&lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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. &lt;br /&gt;
==Algunas Metodologías ágiles==&lt;br /&gt;
Algunas metodologías ágiles de desarrollo de software:&lt;br /&gt;
*[[Adaptive Software Development (ASD)]].&lt;br /&gt;
*[[Agile Unified Process (AUP)]].&lt;br /&gt;
*[[Crystal Clear]].&lt;br /&gt;
*[[Essential Unified Process (EssUP)]].&lt;br /&gt;
*[[Feature Driven Development (FDD)]].&lt;br /&gt;
*[[Lean Software Development (LSD)]].&lt;br /&gt;
*[[Kanban]].&lt;br /&gt;
*[[Open Unified Process (OpenUP)]].&lt;br /&gt;
*[[Programación Extrema (XP)]].&lt;br /&gt;
*[[Método de desarrollo de sistemas dinámicos (DSDM)]].&lt;br /&gt;
*[[Scrum]].&lt;br /&gt;
 &lt;br /&gt;
==Fuente==&lt;br /&gt;
*http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf&lt;br /&gt;
*http://pymecrunch.com/scrum-metodologia-agil-para-tus-proyectos&lt;br /&gt;
*http:// libresoft.dat.escet.urjc.es/html/downloads/ferrer-20030312.pdf&lt;br /&gt;
*http://www.fi.uba.ar/.../schenone-tesisdegradoingenieriainformatica.pdf&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057553</id>
		<title>Metodología ágil</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057553"/>
		<updated>2011-10-20T14:53:44Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Metodología ágil&lt;br /&gt;
|imagen= ma.jpg&lt;br /&gt;
|tamaño= 250&lt;br /&gt;
|concepto= Método para el desarrollo de software que permite incorporar cambios con rapidez y en cualquier fase del proyecto.&lt;br /&gt;
}}&lt;br /&gt;
==Metodología ágil==&lt;br /&gt;
En muchas ocasiones, los modelos de gestión tradicionales no sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces ha ocurrido: cuando el proyecto se encuentra bastante avanzado y no va por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios obligan a desechar todo el trabajo realizado hasta entonces, lo que impide acabar en el plazo previsto.&lt;br /&gt;
Dado que los cambios nunca van a dejar de existir, es necesario ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses [[Takeuchi]] y [[Nonaka]] estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: [[Xerox]], [[Canon]], [[Honda]], [[NEC]], [[Epson]], [[Brother]], [[3M]] y [[Hewlett-Packard]]. De ahí extrajeron la base de la metodología ágil [[SCRUM]]  que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.&lt;br /&gt;
==Historia==&lt;br /&gt;
La definición moderna de metodología ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra las metodologías de &amp;quot;peso pesado&amp;quot;, muy estructuradas y estrictas, extraídas del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.&lt;br /&gt;
Las metodologías de desarrollo ágiles e iterativas pueden ser vistas como un retroceso a las prácticas observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías tradicionales). Inicialmente, las metodologías ágiles fueron llamadas metodologías de &amp;quot;peso liviano&amp;quot;.&lt;br /&gt;
En el año 2001, miembros prominentes de la comunidad se reunieron en [[Snowbird]], [[Utah]], y adoptaron el nombre de &amp;quot; metodologías ágiles&amp;quot;. Poco después, algunas de estas personas formaron la &amp;quot;alianza ágil&amp;quot;, una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchas metodologías similares a las ágiles fueron creadas antes del 2000. Entre los más notables se encuentran: Scrum (1986), [[Crystal Clear]] (cristal transparente), programación extrema (en inglés eXtreme Programming o [[XP]], 1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).&lt;br /&gt;
[[Kent Beck]] creó la metodología de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del [[Sistema exhaustivo de compensaciones de Chrysler (C3)]]. Mientras [[Chrysler]] cancelaba ese proyecto, la metodología fue refinada por [[Ron Jeffries]].&lt;br /&gt;
El punto de partida de esta reunión fue el Manifiesto Ágil, un documento que resume la filosofía ágil.&lt;br /&gt;
 &lt;br /&gt;
==Manifiesto Ágil==&lt;br /&gt;
 &lt;br /&gt;
Según el Manifiesto se valora:&lt;br /&gt;
 &lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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 una decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental.&lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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. &lt;br /&gt;
==Algunas Metodologías ágiles==&lt;br /&gt;
Algunas metodologías ágiles de desarrollo de software:&lt;br /&gt;
*[[Adaptive Software Development (ASD)]].&lt;br /&gt;
*[[Agile Unified Process (AUP)]].&lt;br /&gt;
*[[Crystal Clear]].&lt;br /&gt;
*[[Essential Unified Process (EssUP)]].&lt;br /&gt;
*[[Feature Driven Development (FDD)]].&lt;br /&gt;
*[[Lean Software Development (LSD)]].&lt;br /&gt;
*[[Kanban]].&lt;br /&gt;
*[[Open Unified Process (OpenUP)]].&lt;br /&gt;
*[[Programación Extrema (XP)]].&lt;br /&gt;
*[[Método de desarrollo de sistemas dinámicos (DSDM)]].&lt;br /&gt;
*[[Scrum]].&lt;br /&gt;
 &lt;br /&gt;
==Fuente==&lt;br /&gt;
*http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf&lt;br /&gt;
*http://pymecrunch.com/scrum-metodologia-agil-para-tus-proyectos&lt;br /&gt;
*http://www.fi.uba.ar/.../schenone-tesisdegradoingenieriainformatica.pdf&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057489</id>
		<title>Metodología ágil</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057489"/>
		<updated>2011-10-20T14:52:10Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: Página creada con '{{Definición |nombre= Metodología ágil |imagen= ma.jpg |tamaño= 250 |concepto= Método para el desarrollo de software que permite incorporar cambios con rapidez y en cualqui...'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Metodología ágil&lt;br /&gt;
|imagen= ma.jpg&lt;br /&gt;
|tamaño= 250&lt;br /&gt;
|concepto= Método para el desarrollo de software que permite incorporar cambios con rapidez y en cualquier fase del proyecto.&lt;br /&gt;
}}&lt;br /&gt;
==Metodología ágil==&lt;br /&gt;
En muchas ocasiones, los modelos de gestión tradicionales no sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces ha ocurrido: cuando el proyecto se encuentra bastante avanzado y no va por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios obligan a desechar todo el trabajo realizado hasta entonces, lo que impide acabar en el plazo previsto.&lt;br /&gt;
Dado que los cambios nunca van a dejar de existir, es necesario ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses [[Takeuchi]] y [[Nonaka]] estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: [[Xerox]], [[Canon]], [[Honda]], [[NEC]], [[Epson]], [[Brother]], [[3M]] y [[Hewlett-Packard]]. De ahí extrajeron la base de la metodología ágil [[SCRUM]]  que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.&lt;br /&gt;
==Historia==&lt;br /&gt;
La definición moderna de metodología ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra las metodologías de &amp;quot;peso pesado&amp;quot;, muy estructuradas y estrictas, extraídas del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.&lt;br /&gt;
Las metodologías de desarrollo ágiles e iterativas pueden ser vistas como un retroceso a las prácticas observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías tradicionales). Inicialmente, las metodologías ágiles fueron llamadas metodologías de &amp;quot;peso liviano&amp;quot;.&lt;br /&gt;
En el año 2001, miembros prominentes de la comunidad se reunieron en [[Snowbird]], [[Utah]], y adoptaron el nombre de &amp;quot; metodologías ágiles&amp;quot;. Poco después, algunas de estas personas formaron la &amp;quot;alianza ágil&amp;quot;, una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchas metodologías similares a las ágiles fueron creadas antes del 2000. Entre los más notables se encuentran: Scrum (1986), [[Crystal Clear]] (cristal transparente), programación extrema (en inglés eXtreme Programming o [[XP]], 1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).&lt;br /&gt;
[[Kent Beck]] creó la metodología de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del [[Sistema exhaustivo de compensaciones de Chrysler (C3)]]. Mientras [[Chrysler]] cancelaba ese proyecto, la metodología fue refinada por [[Ron Jeffries]].&lt;br /&gt;
El punto de partida de esta reunión fue el Manifiesto Ágil, un documento que resume la filosofía ágil.&lt;br /&gt;
 &lt;br /&gt;
==Manifiesto Ágil==&lt;br /&gt;
 &lt;br /&gt;
Según el Manifiesto se valora:&lt;br /&gt;
 &lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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 una decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental.&lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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. &lt;br /&gt;
==Algunas Metodologías ágiles==&lt;br /&gt;
Algunas metodologías ágiles de desarrollo de software:&lt;br /&gt;
*[[Adaptive Software Development (ASD)]].&lt;br /&gt;
*[[Agile Unified Process (AUP)]].&lt;br /&gt;
*[[Crystal Clear]].&lt;br /&gt;
*[[Essential Unified Process (EssUP)]].&lt;br /&gt;
*[[Feature Driven Development (FDD)]].&lt;br /&gt;
*[[Lean Software Development (LSD)]].&lt;br /&gt;
*[[Kanban]].&lt;br /&gt;
*[[Open Unified Process (OpenUP)]].&lt;br /&gt;
*[[Programación Extrema (XP)]].&lt;br /&gt;
*[[Método de desarrollo de sistemas dinámicos (DSDM)]].&lt;br /&gt;
*[[Scrum]].&lt;br /&gt;
 &lt;br /&gt;
==Fuente==&lt;br /&gt;
http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf&lt;br /&gt;
http://pymecrunch.com/scrum-metodologia-agil-para-tus-proyectos&lt;br /&gt;
http:// libresoft.dat.escet.urjc.es/html/downloads/ferrer-20030312.pdf&lt;br /&gt;
http://www.fi.uba.ar/.../schenone-tesisdegradoingenieriainformatica.pdf&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057532</id>
		<title>Metodología ágil</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Metodolog%C3%ADa_%C3%A1gil&amp;diff=1057532"/>
		<updated>2011-10-20T14:52:09Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Definición&lt;br /&gt;
|nombre= Metodología ágil&lt;br /&gt;
|imagen= ma.jpg&lt;br /&gt;
|tamaño= 250&lt;br /&gt;
|concepto= Método para el desarrollo de software que permite incorporar cambios con rapidez y en cualquier fase del proyecto.&lt;br /&gt;
}}&lt;br /&gt;
==Metodología ágil==&lt;br /&gt;
En muchas ocasiones, los modelos de gestión tradicionales no sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces ha ocurrido: cuando el proyecto se encuentra bastante avanzado y no va por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios obligan a desechar todo el trabajo realizado hasta entonces, lo que impide acabar en el plazo previsto.&lt;br /&gt;
Dado que los cambios nunca van a dejar de existir, es necesario ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses [[Takeuchi]] y [[Nonaka]] estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: [[Xerox]], [[Canon]], [[Honda]], [[NEC]], [[Epson]], [[Brother]], [[3M]] y [[Hewlett-Packard]]. De ahí extrajeron la base de la metodología ágil [[SCRUM]]  que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.&lt;br /&gt;
==Historia==&lt;br /&gt;
La definición moderna de metodología ágil de software evolucionó a mediados de los años 1990 como parte de una reacción contra las metodologías de &amp;quot;peso pesado&amp;quot;, muy estructuradas y estrictas, extraídas del modelo de desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento, degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo eficiente.&lt;br /&gt;
Las metodologías de desarrollo ágiles e iterativas pueden ser vistas como un retroceso a las prácticas observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había metodologías tradicionales). Inicialmente, las metodologías ágiles fueron llamadas metodologías de &amp;quot;peso liviano&amp;quot;.&lt;br /&gt;
En el año 2001, miembros prominentes de la comunidad se reunieron en [[Snowbird]], [[Utah]], y adoptaron el nombre de &amp;quot; metodologías ágiles&amp;quot;. Poco después, algunas de estas personas formaron la &amp;quot;alianza ágil&amp;quot;, una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones. Muchas metodologías similares a las ágiles fueron creadas antes del 2000. Entre los más notables se encuentran: Scrum (1986), [[Crystal Clear]] (cristal transparente), programación extrema (en inglés eXtreme Programming o [[XP]], 1996), desarrollo de software adaptativo, feature driven development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).&lt;br /&gt;
[[Kent Beck]] creó la metodología de Programación Extrema (usualmente conocida como XP) en 1996 como una forma de rescatar el proyecto del [[Sistema exhaustivo de compensaciones de Chrysler (C3)]]. Mientras [[Chrysler]] cancelaba ese proyecto, la metodología fue refinada por [[Ron Jeffries]].&lt;br /&gt;
El punto de partida de esta reunión fue el Manifiesto Ágil, un documento que resume la filosofía ágil.&lt;br /&gt;
 &lt;br /&gt;
==Manifiesto Ágil==&lt;br /&gt;
 &lt;br /&gt;
Según el Manifiesto se valora:&lt;br /&gt;
 &lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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 una decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental.&lt;br /&gt;
*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.&lt;br /&gt;
 &lt;br /&gt;
*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. &lt;br /&gt;
==Algunas Metodologías ágiles==&lt;br /&gt;
Algunas metodologías ágiles de desarrollo de software:&lt;br /&gt;
*[[Adaptive Software Development (ASD)]].&lt;br /&gt;
*[[Agile Unified Process (AUP)]].&lt;br /&gt;
*[[Crystal Clear]].&lt;br /&gt;
*[[Essential Unified Process (EssUP)]].&lt;br /&gt;
*[[Feature Driven Development (FDD)]].&lt;br /&gt;
*[[Lean Software Development (LSD)]].&lt;br /&gt;
*[[Kanban]].&lt;br /&gt;
*[[Open Unified Process (OpenUP)]].&lt;br /&gt;
*[[Programación Extrema (XP)]].&lt;br /&gt;
*[[Método de desarrollo de sistemas dinámicos (DSDM)]].&lt;br /&gt;
*[[Scrum]].&lt;br /&gt;
 &lt;br /&gt;
==Fuente==&lt;br /&gt;
*http://issi.dsic.upv.es/archives/f-1069167248521/actas.pdf&lt;br /&gt;
*http://pymecrunch.com/scrum-metodologia-agil-para-tus-proyectos&lt;br /&gt;
*http://libresoft.dat.escet.urjc.es/html/downloads/ferrer-20030312.pdf&lt;br /&gt;
*http://www.fi.uba.ar/.../schenone-tesisdegradoingenieriainformatica.pdf&lt;br /&gt;
&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Archivo:Sinergia.jpg&amp;diff=1018295</id>
		<title>Archivo:Sinergia.jpg</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Archivo:Sinergia.jpg&amp;diff=1018295"/>
		<updated>2011-10-11T16:01:33Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Sumario ==&lt;br /&gt;
&lt;br /&gt;
== Estado de copyright: ==&lt;br /&gt;
&lt;br /&gt;
== Fuente: ==&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
	<entry>
		<id>https://www.ecured.cu/index.php?title=Sinergia&amp;diff=1018164</id>
		<title>Sinergia</title>
		<link rel="alternate" type="text/html" href="https://www.ecured.cu/index.php?title=Sinergia&amp;diff=1018164"/>
		<updated>2011-10-11T15:38:49Z</updated>

		<summary type="html">&lt;p&gt;Pedroad100110jcvcl: Página creada con '  {{Definición |nombre= Sinergia |imagen= sinergia.jpg |tamaño= 250 |concepto= Una sinergia (del griego συνεργία,cooperación) es el resultado de la acción conjun...'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
&lt;br /&gt;
{{Definición&lt;br /&gt;
|nombre= Sinergia&lt;br /&gt;
|imagen= sinergia.jpg&lt;br /&gt;
|tamaño= 250&lt;br /&gt;
|concepto= Una sinergia (del griego συνεργία,[[cooperación]]) es el resultado de la acción conjunta de dos o más causas, pero caracterizado por tener un efecto superior al que resulta de la simple suma de dichas causas.&lt;br /&gt;
}}&lt;br /&gt;
==Etimología==&lt;br /&gt;
Del [[latín]] synergia [[cooperación]], a su vez del griego συνεργία&lt;br /&gt;
==En Farmacología==&lt;br /&gt;
Interacción entre fármacos por la cual potencian mutuamente sus efectos.&lt;br /&gt;
== En Física== &lt;br /&gt;
Concurrencia de energías o fuerzas.&lt;br /&gt;
==En Biología== &lt;br /&gt;
Organización de órganos que realizan una función. &lt;br /&gt;
&lt;br /&gt;
==En Teología== &lt;br /&gt;
Concertación del propósito humano con la gracia divina para alcanzar la salvación del alma. &lt;br /&gt;
==En Filosofía==&lt;br /&gt;
Característica de los sistemascomplejos descritos por la teoría general de sistemas, por la cual el comportamiento de los mismos no puede predecirse del de sus partes.&lt;br /&gt;
==Historia de la sinergia==&lt;br /&gt;
La historia de la Sinergia comienza curiosamente en el ámbito religioso, usado por ejemplo por San Pablo en sus epístolas, refiriéndose al resultado del trabajo conjunto entre el hombre y Dios. Solo comienza el término a ser utilizado en un contexto no [[teológico]] en 1925, con la teoría general de sistemas propuesta por el biólogo alemán, [[Ludwig Von Bertanlanffy]] en 1925. Un sistema consiste básicamente en un conjunto de componentes que se relacionan, intentando alcanzar uno o más objetivos. He aquí la relación existente entre la teoría general de los sistemas y el concepto de sinergia. Sin embargo, sólo se da la sinergia cuando el o los objetivos logrados por la organización o sistema son alcanzados con creces, considerándolos como un resultado obtenido en conjunto mayor o mejor que el posible de alcanzar producto de sus órganos o partes individualmente.&lt;br /&gt;
Una organización es considerada sinérgica cuando los órganos que lo componen no pueden realizar una función determinada sin depender del resto de los miembros que componen dicha organización. De aquí viene la afirmación aristotélica relacionada con este concepto: “el todo no es igual a la suma de las partes”, u otros lo argumentarían utilizando el siguiente razonamiento matemático: 2 + 2 = 5, lo cual es un absurdo en términos absolutos, pero tiene sentido desde el punto de vista sistémico. Por ende el total corresponde a la conservación del sistema teniendo en cuenta la acción en conjunto que realizan sus componentes.&lt;br /&gt;
La sinergia es un concepto importante en un sinnúmero de aplicaciones; por ejemplo en la computación, donde las máquinas son capaces de procesar números notablemente mejor que los seres humanos, pero carecen de sentido común, por lo que el trabajo en conjunto de computadoras y humanos da excelentes resultados, mejores que los posibles de lograr trabajando por separados. En el ámbito de la medicina encontramos el concepto en la [[toxicología]], donde los efectos de la suma de compuestos en un organismo puede ser muy diferente a la acción de los compuestos por separados. Pero la gran aplicación se da en el ámbito de las relaciones humanas en la empresa, y actualmente el concepto está orientado a crear un marco conceptual para todo lo que es el trabajo en equipo.&lt;br /&gt;
En la cotidianidad, la sinergia es posible ser vista fácilmente en los [[sistemas mecánicos]], no obstante en aquellos que contienen componentes sociales el concepto a veces puede hacerse algo ambiguo, por ejemplo la sinergia presentada en un grupo familiar, podría ser considerada como la vida. O también en el caso de un equipo de deportistas, la sinergia podrías ser el placer por la competencia junto con la amistad. En cuanto a estos sistemas sociales pueden existir dos tipos de sinergia; la positiva y la negativa. La primera dice relación con una integración entre los miembros que componen la organización y que por ende obtienen resultados fructíferos. Por el contrario si la organización contiene líderes que no contribuyen positivamente, y en consecuencia los resultados no son los esperados, se habla de una [[sinergia negativa]].&lt;br /&gt;
==Fuente==&lt;br /&gt;
*http://buscon.rae.es/draeI/SrvltGUIBusUsual?LEMA=sinergia&lt;br /&gt;
*http://www.misrespuestas.com/que-es-la-sinergia.html&lt;br /&gt;
*http://www.linkses.com/articulos/205/Sinergia&lt;br /&gt;
*Malinietski, G. G. (2008): Fundamentos matemáticos de la sinergética. Caos, estructuras y simulación por ordenador. Moscú (Rusia), 2008.&lt;br /&gt;
*http://www.wordreference.com/definicion/sinergia&lt;br /&gt;
[[Category: Informática]]&lt;/div&gt;</summary>
		<author><name>Pedroad100110jcvcl</name></author>
		
	</entry>
</feed>