Adaptive Software Development Tutorial - En.es

Desarrollo de software adaptativo
Acerca del Tutorial
Adaptativa de desarrollo de software es un movimiento hacia prcticas de adaptacin, dejando las prcticas deterministas en el contexto de
los sistemas complejos y entornos complejos. Adaptativa de desarrollo de software se centra en la colaboracin y el aprendizaje como una
tcnica para construir sistemas complejos. Se desarroll a partir de las mejores prcticas de desarrollo rpido de aplicaciones (RAD) y ciclos
de vida evolutivo.
Audiencia
Adaptativa de desarrollo de software est escrito para equipos de proyectos que han estado luchando con alta velocidad, proyectos de gran
cambio y estn buscando maneras de mejorar el rendimiento y el desgaste a moderado, sobre todo porque los proyectos que emprenden se
hacen ms grandes y los equipos se vuelven ms distribuidos.
Requisitos previos
Antes de empezar a continuar con este tutorial, estamos asumiendo que usted ya sabe acerca de los fundamentos de Ciclo de Vida de
Desarrollo de Software. Si no est al tanto de estos conceptos, a continuacin, vamos a sugerimos que vaya a travs de nuestros cortos
tutoriales sobre SDLC.
Copyright y Descargo de responsabilidad
Derechos de autor 2016 por tutoriales Punto Pvt (I). Limitado.
Todo el contenido y los grficos publicados en este libro electrnico son propiedad de tutoriales Point (I) Pvt. Ltd. El usuario de este libro
electrnico est prohibido volver a utilizar, retener, copiar, distribuir o publicar cualquier contenido o parte del contenido de este libro
electrnico en cualquier forma sin el consentimiento por escrito del editor.
Nos esforzamos para actualizar los contenidos de nuestra pgina web y tutoriales como oportuna y lo ms exactamente posible, sin embargo,
el contenido puede contener imprecisiones o errores. Tutoriales Point (I) Pvt. Ltd. ofrece ninguna garanta respecto a la exactitud, puntualidad
o integridad de nuestro sitio web o su contenido incluyendo este tutorial. Si descubre algn error en nuestra pgina web o en este tutorial, por
favor hganoslo saber a travs contact@tutorialspoint.com
yo
Tabla de contenido
Sobre el Tutorial ............................................... .................................................. ........................................... i audiencia .....

.................................................. .................................................. .................................................. Requisitos previos i
................................................ .................................................. .................................................. . i copyright y exencin de responsabilidad
............................................. .................................................. ...................................... i Contenido ........ ..................................................
.................................................. ................................ ii
1. TEA - Introduccin ............................................... .................................................. ................................... 1

Cul es gil? .................................................. .................................................. .............................................. 1
Manifiesto gil ................................................ .................................................. .............................................. 1
Cul es adaptativa de desarrollo de software? .................................................. .................................................. . 2
2. Modelos SDLC - Evolucin .............................................. .................................................. ........................... 3
3. SDLC Cascada Modelo .............................................. .................................................. ............................ 5

Modelo Cascada - Fortalezas .............................................. .................................................. ........................... 5
Modelo Cascada - Debilidades .............................................. .................................................. ....................... 6
Cundo utilizar la cascada Modelo? .................................................. .................................................. ................... 6
Evolutiva Modelo de prototipos ............................................... .................................................. .................... 6
Evolutiva de prototipos de modelos - Fortalezas ............................................. .................................................. ... 7
Evolutiva de prototipos de modelos - Debilidades ............................................. ................................................. 8
Cundo utilizar evolutiva de prototipos de modelos? ........................................... .................................................. . 8
4. SDLC iterativo incremental Modelo ............................................. .................................................. ........... 9

Iterativo incremental Modelo - Fortalezas ............................................. .................................................. ......... 9
Iterativo incremental Modelo - Debilidades ............................................. .................................................. ... 10
Cundo utilizar iterativo incremental Modelo? .................................................. ................................................ 10
5. SDLC El rpido desarrollo de aplicaciones Modelo ............................................ ........................................... 11

El rpido desarrollo de aplicaciones Modelo - Fortalezas ............................................ ......................................... 11
El rpido desarrollo de aplicaciones Modelo - Debilidades ............................................ ..................................... 12
Cundo utilizar Rpido modelo de desarrollo de aplicaciones? .................................................. ............................... 12
6. SDLC espiral Modelo .............................................. .................................................. ................................ 13

Modelo espiral - Fortalezas .............................................. .................................................. ............................... 14
Modelo espiral - Debilidades .............................................. .................................................. ........................... 14
Cundo utilizar Espiral Modelo? .................................................. .................................................. ....................... 15
7. SDLC mtodos giles .............................................. .................................................. ............................. diecisis

Mtodos giles - Fortalezas .............................................. .................................................. ............................ diecisis
Mtodos giles - Debilidades .............................................. .................................................. ........................ diecisis
Cundo utilizar mtodos giles? .................................................. .................................................. .................... 17
8. ASD Evolucin ............................................... .................................................. ..................................... 18

El Ciclo de Vida de adaptacin .............................................. .................................................. .................................. 19
9. TEA - Conceptos ............................................... .................................................. ...................................... 20

Adaptativo Sistemas (CAS) Teora Complex ........................................... .................................................. ......... 20
Desarrollo de software complejo ............................................... .................................................. .................. 20
Sistemas adaptativos complejos (CAS) Conceptos ........................................... .................................................. ..... 21
Prcticas de desarrollo de software de adaptacin .............................................. .................................................. ... 22
ii
10. TEA - Ciclo de Vida .............................................. .................................................. ....................................... 23

Fases de ................................................ .................................................. .................................................. ... 23
ASD del Ciclo de Vida ............................................... .................................................. ............................................... 23
11. ASD del ciclo de vida - Caractersticas .............................................. .................................................. ................ 26
12. TEA - Prcticas ............................................... .................................................. ...................................... 28

Adaptativo SDLC ................................................ .................................................. ............................................. 28
especular Iniciacin y Planificacin ............................................. .................................................. ................ 29
Colaborar Desarrollo Concurrente Caracterstica ............................................. ............................................. 31
Aprender - Revisin de Calidad .............................................. .................................................. ................................... 32
13. TEA - Manejo Adaptativo .............................................. .................................................. ................. 34

Manejo Adaptativo ................................................ .................................................. ................................ 34
Manejo Adaptativo pasiva ............................................... .................................................. .................... 35
Manejo Adaptativo activa ............................................... .................................................. ...................... 35
Liderazgo-Colaboracin .............................................. .................................................. ........ 36
iii
1. TEA - Introduccin
Cul es gil?
En trminos literarios, la palabra gil significa alguien que puede moverse rpida y fcilmente o alguien que pueda pensar y actuar con
rapidez y claridad. En los negocios, gil se utiliza para describir formas de planificacin y haciendo el trabajo en el que se entiende que hacer
los cambios necesarios es una parte importante de la trabajo. Negocio agilidad significa que una empresa est siempre en una condiciones de
tomar en cuenta los cambios del mercado.
En el desarrollo de software, el trmino gil se adapta a significar la capacidad de responder a los cambios - los cambios de los requisitos, la
tecnologa y las personas.
Manifiesto gil
El manifiesto gil fue publicado por un equipo de desarrolladores de software en 2001, poniendo de relieve la importancia del equipo de
desarrollo, con capacidad cambiantes requerimientos y la implicacin del cliente.
El manifiesto gil es:
Estamos descubriendo mejores formas de desarrollar software hacindolo y ayudando a que otros lo hagan. A travs de este trabajo, hemos
llegado a con valor
Individuos e interacciones sobre procesos y herramientas.
software que trabaja sobre una amplia documentacin.
Colaboracin con el cliente durante la negociacin del contrato.
En respuesta a cambiar con el seguimiento de un plan.
Es decir, mientras hay valor en los elementos de la derecha, valoramos los elementos de la izquierda ms.
Caractersticas de agilidad
Los siguientes son las caractersticas de Agility-
Agilidad en el desarrollo gil de software se centra en la cultura de todo el equipo con muchas disciplinas, por equipos
multi-funcionales que se faculta y auto-organizados.
Se fomenta la responsabilidad compartida y la responsabilidad.
Facilita la comunicacin efectiva y la colaboracin continua.
El enfoque de todo el equipo evita retrasos y tiempos de espera.
entregas frecuentes y continuos aseguran una rpida retroalimentacin que a su vez permite que el equipo se alinean con los
requisitos.
1
La colaboracin facilita la combinacin de diferentes perspectivas en la implementacin oportuna, reparaciones de defectos y

cambios con capacidad.
El progreso es constante, sostenible y predecible transparencia haciendo hincapi.
Metodologas giles
Las primeras implementaciones de mtodos giles incluyen Rational Unified Process, Scrum, Crystal Clear, la programacin extrema,
adaptativa de desarrollo de software, Feature Driven Development, y Sistemas de Desarrollo Mtodo Dinmico (DSDM). Estos ahora se
denominan colectivamente como las metodologas giles, despus de que el manifiesto gil se public en 2001.
En este tutorial, vamos a aprender la metodologa gil - Desarrollo de software adaptativo.
Cul es adaptativa de desarrollo de software?
Adaptativa de desarrollo de software es un movimiento hacia prcticas de adaptacin, dejando las prcticas deterministas en el contexto de
los sistemas complejos y entornos complejos. Adaptativa de desarrollo de software se centra en la colaboracin y el aprendizaje como una
tcnica para construir sistemas complejos. Se desarroll a partir de las mejores prcticas de desarrollo rpido de aplicaciones (RAD) y ciclos
de vida evolutivo. entonces adaptativa de desarrollo de software se ampli para incluir enfoques de adaptacin para la gestin, la especulacin
con la sustitucin de Planificacin.
Jim Highsmith public un libro sobre desarrollo de software adaptativo en 2000. En palabras de Highsmith -
Adaptive Software Development es cclico como el modelo evolutivo, con los nombres de las fases Especular, colaborar, aprender
lo que refleja el reino impredecible de sistemas cada vez ms complejos. desarrollo de adaptacin va ms all de su herencia
evolutiva de dos maneras principales. En primer lugar, al que sustituye de forma explcita el determinismo con la emergencia. En
segundo lugar, que va ms all de un cambio en el ciclo de vida de un cambio profundo en el estilo de gestin.
2
2. Modelos SDLC - Evolucin
Un modelo de ciclo de vida del software de desarrollo (SDLC) es un marco que describe las actividades realizadas en cada etapa de un
proyecto de desarrollo de software.
En un ciclo de vida del software de desarrollo, las actividades se llevan a cabo en cinco fases:
Recopilacin de requisitos: Requisitos para un software que se desarrollarn estn reunidos. Estos requisitos sern en un idioma
que se entiende por el cliente / usuario. Se recomienda la terminologa especfica de dominio.
Anlisis: Los requisitos recogidos se analizan desde el punto de vista de la implementacin y las especificaciones del software
estn escritos para cubrir tanto, los requisitos funcionales y los requisitos no funcionales.
Diseo: Esta fase consiste en llegar a la arquitectura de software e implementacin especficos basados en la tecnologa elegida
para el desarrollo.
Construccin: En esta fase, el cdigo est desarrollado, probado probado unidad, integrada, la integracin y se produce la
acumulacin.
Pruebas: Las pruebas funcionales del software incorporado se realiza en esta fase. Esto tambin incluye la comprobacin de
requisitos no funcionales.
Hay dos enfoques para la realizacin de estas actividades-
Preceptivo: Los modelos SDLC que le proporcionar formas de realizar las actividades de una manera prescrita segn lo definido
por el marco.
Adaptado: Los modelos SDLC que le dar la flexibilidad en la realizacin de las actividades, con ciertas reglas que deben ser
seguidas. Los mtodos giles en su mayora siguen este enfoque, cada uno con sus reglas. Sin embargo, siguiendo un enfoque
adaptativo o gil no significa que el software se desarrolla sin seguir cualquier disciplina. Esto llevara a un caos.
Es necesario comprender que no podemos decir que un modelo especfico SDLC es bueno o malo. Cada uno de ellos tiene sus propias
fortalezas y debilidades y por lo tanto son adecuados en ciertos contextos.
Cuando se elige un modelo SDLC para su proyecto, es necesario entender:
Su Organizacin Contexto
Su Contexto Tecnologa
Su equipo de Composicin
Su Contexto Cliente
Por ejemplo, si el desarrollo de software es predecible, se puede utilizar un enfoque prescriptivo. Por otro lado, si el desarrollo de software es
impredecible, es decir, los requisitos no se conoce del todo, o el equipo de desarrollo no tiene previa
3
la exposicin al dominio o la tecnologa actual, etc, entonces el enfoque de adaptacin es la mejor opcin.
En las siguientes secciones, se entiende por los modelos ms prevalentes SDLC que se desprenden durante la ejecucin de proyectos de
desarrollo de software en la industria. Tambin se llega a conocer las fortalezas y debilidades de cada uno de ellos y en qu contextos son
adecuados.
4
3. Modelo SDLC Cascada
El modelo de la cascada es un modelo clsico SDLC que es ampliamente conocido, comprendido y utilizado comnmente. Fue introducido por
Royce en 1970 y todava est siendo seguido como un enfoque comn para el desarrollo de software en diversas organizaciones en toda la
industria.
En el modelo de cascada, cada fase del ciclo de vida puede comenzar slo despus de la fase del ciclo de vida anterior se ha completado. Por lo tanto, se
trata de un modelo lineal sin bucles de retroalimentacin.
Modelo Cascada - Fortalezas
Los puntos fuertes del modelo cascada son-
Fcil de entender, fcil de usar.
Proporciona la estructura de equipo de desarrollo sin experiencia.
Los hitos se conocen bien.
Establece requisitos de estabilidad.
Ideal para el control de gestin (planificacin, supervisin, presentacin de informes).
Funciona bien cuando la calidad es ms importante que el costo o cronograma.
5
Modelo Cascada - Debilidades

Las debilidades o las desventajas del modelo son-Cascada
Idealizado - No coincide con la realidad as.
Realista - no puede esperar que los requisitos precisos al principio del proyecto.
No refleja la naturaleza iterativa del desarrollo exploratorio que es ms comn.
Difcil y costoso hacer cambios.
El software se suministra slo al final del proyecto. Debido a esto -

o Los retrasos descubrimiento de defectos graves.
o Posibilidad de entrega de requisitos obsoletos.
Significativa sobrecarga de administracin, que puede ser costoso para los equipos y proyectos pequeos.
Requiere recursos con experiencia en todas las fases - analistas, diseadores, desarrolladores, probadores.
Las pruebas se inicia slo despus de que el desarrollo se ha completado y los tcnicos no estn involucrados en ninguna de las
fases anteriores.
La experticia de los equipos multi-funcionales no se comparte, ya que cada fase se ejecuta en silos.
Cundo utilizar la cascada Modelo?
Se puede utilizar el modelo de cascada si -
Requisitos son muy bien conocidos.
Definicin del producto es estable.
La tecnologa est bien entendido.
Nueva versin de un producto existente.
Portar un producto existente a una nueva plataforma.
organizacin grande con equipos multi-funcionales estructurados.
Los canales de comunicacin estn bien establecidos dentro de la organizacin y con el cliente tambin.
Evolutiva Modelo de prototipos

En el desarrollo de software utilizando el modelo de prototipos evolutiva, los desarrolladores a construir un prototipo durante la fase de
requisitos. Los usuarios finales y luego evaluar el prototipo y dar retroalimentacin. La retroalimentacin puede ser correcciones al prototipo o
una funcionalidad adicional. Basndose en la informacin, los desarrolladores de refinar an ms el prototipo.
6
Por lo tanto, el producto evoluciona a travs del Prototipo -> Comentarios -> Ciclos Prototype refinado y de ah el nombre evolutiva de
prototipos. Cuando el usuario est satisfecho con la funcionalidad, y el trabajo del producto, el cdigo del prototipo se lleva hasta los
estndares requeridos para la entrega del producto final.
Evolutiva Modelo de prototipos - Fortalezas

Los puntos fuertes o las ventajas de un modelo evolutivo de prototipos son-
usuarios de los clientes / finales pueden visualizar los requisitos del sistema, ya que estn reunidos buscando en el prototipo.
Los desarrolladores aprenden de los clientes y por lo tanto no hay ambigedades en relacin de dominio o entorno de produccin.
Permite el diseo y desarrollo flexible.
La interaccin con el prototipo estimula la conciencia de la funcionalidad adicional necesaria.
Requisitos y requerimientos inesperados cambios se acomodan fcilmente.
signos Steady y visibles de progreso se producen.
La entrega de un producto final preciso y fcil de mantener.
7
Evolutiva Modelo de prototipos - Debilidades

Las debilidades o desventajas del modelo evolutivo de prototipos son los siguientes-
Tendencia a abandonar el desarrollo estructurado en el desarrollo de codificacin y correccin, aunque no es lo que se prescribe
por el modelo.
Este modelo recibi mala reputacin de los mtodos rpida y sucia.
mantenimiento general, posiblemente, puede ser pasado por alto.
El cliente posiblemente puede pedir la entrega del prototipo como el final, no dando la oportunidad a los desarrolladores para
ejecutar el ltimo paso es decir, la estandarizacin del producto final.
Proyecto puede continuar para siempre (con la corrupcin del alcance continua) y la direccin no puede apreciarlo.
Cundo utilizar evolutiva de prototipos de modelos?
Se puede utilizar el Evolutiva Prototipos modelo-
Cuando los requisitos son inestables o tienen que ser aclarado
Como la etapa de clarificacin de los requisitos de un modelo de cascada
Para desarrollar interfaces de usuario
Para las demostraciones de corta duracin
Para el desarrollo de nuevos u originales
Para la implementacin de una nueva tecnologa
8
4. SDLC modelo incremental iterativo
En un modelo de Incremental iterativo, inicialmente, una implementacin parcial de un sistema total se construye de modo que estar en un
estado de entrega. se aade mayor funcionalidad. Los defectos, en su caso, a partir de la entrega antes son fijos y el producto de trabajo se
entrega. El proceso se repite hasta que se haya completado todo el desarrollo de productos. Las repeticiones de estos procesos se
denominan iteraciones. Al final de cada iteracin, se entrega un incremento del producto.
Iterativo modelo incremental - Fortalezas
Las ventajas o fortalezas del modelo iterativo incremental son-
Puede desarrollar requisitos priorizados en primer lugar.
la entrega del producto inicial es ms rpida.
Los clientes obtiene funcionalidad importante al principio.
Reduce el coste de entrega inicial.
Cada versin es un incremento del producto, de manera que el cliente tendr un producto de trabajo a la mano todo el tiempo.
El cliente puede proporcionar informacin a cada incremento del producto, evitando as sorpresas al final del desarrollo.
Requisitos cambios se pueden acomodar fcilmente.
9
Iterativo modelo incremental - Debilidades

Las desventajas del modelo Iterativo Incremental son-
Requiere una planificacin eficaz de iteraciones.
Requiere diseo eficiente para asegurar la inclusin de la funcionalidad requerida y la previsin de los cambios ms adelante.
Requiere temprana definicin de un sistema completo y totalmente funcional para permitir la definicin de incrementos.
Se requieren interfaces de mdulos bien definidos, ya que algunos se desarrollan mucho antes de que otros se desarrollaron.
El costo total del sistema completo no es menor.
Cundo utilizar iterativo incremental Modelo?
Modelo incremental iterativo se puede utilizar cuando-
La mayor parte de los requisitos se conocen por adelantado, pero se espera que evolucionar con el tiempo.
Los requisitos son priorizados.
Existe la necesidad de conseguir la funcionalidad bsica entregado rpidamente.
Un proyecto de desarrollo tiene horarios muy largos.
Un proyecto tiene la nueva tecnologa.
El dominio es nuevo en el equipo.
10
5. Modelo de desarrollo rpido de aplicaciones SDLC
Modelo de desarrollo rpido de aplicaciones (RAD) tiene la siguiente fases:
Fase de planificacin requisitos - En la fase de planificacin de necesidades, un taller debe llevarse a cabo para discutir los
problemas de negocio de una manera estructurada.
Usuario Descripcin fase - En la descripcin en esta fase, las herramientas automatizadas se utilizan para capturar informacin de
los usuarios.
Fase de construccin - En la fase de construccin, herramientas de productividad, tales como generadores de cdigo, generadores de
pantalla, etc. se utilizan dentro de un recuadro temporal, con un enfoque de hacer hasta que est hecho.
Durante la fase cortar - En el corte sobre la fase, la instalacin del sistema, se realizan pruebas de aceptacin del usuario y la
formacin de los usuarios.
El rpido desarrollo de aplicaciones Modelo - Fortalezas
Las ventajas o fortalezas del modelo de desarrollo rpido de aplicaciones son los siguientes-
menor tiempo de ciclo y la mejora de la productividad con un menor nmero de miembros del equipo significara costos ms bajos.
la participacin del cliente en todo el ciclo completo minimiza el riesgo de no lograr la satisfaccin del cliente y el valor del negocio.
La seleccin se mueve al cdigo en un modo de lo que se ve-es-lo-que-hay (WYSIWYG). Esto trae claridad sobre lo que se est
construyendo es lo correcto.
11
Utiliza conceptos de modelado para capturar informacin sobre negocios, datos y procesos.
El rpido desarrollo de aplicaciones Modelo - Debilidades
Las desventajas o puntos fuertes del modelo de desarrollo rpido de aplicaciones son los siguientes-
acelerado proceso de desarrollo debe dar respuestas rpidas a los usuarios.
Riesgo de no lograr el cierre.
Difcil de utilizar con los sistemas heredados.
Los desarrolladores y los clientes deben estar comprometidos con las actividades de tiro rpido en un marco de tiempo abreviado.
Cundo utilizar Rpido modelo de desarrollo de aplicaciones?
Modelo de desarrollo rpido de aplicaciones se puede utilizar cuando-
El usuario puede estar involucrado en todo el ciclo de vida.
Proyecto puede llevar mucho tiempo en caja.
Funcionalidad se puede entregar en incrementos.
Aunque el fortalezas del modelo de desarrollo rpido de aplicaciones son apreciados, se utiliza con moderacin en la industria.
12
6. SDLC Modelo Espiral
modelo en espiral agrega Anlisis de Riesgos y RAD prototipos para el modelo de cascada. Cada ciclo consiste en la misma secuencia de
pasos como el modelo de la cascada.
modelo en espiral tiene cuatro cuadrantes. Vamos a discutir en detalle.
Cuadrante 1: Determinar los objetivos, alternativas y limitaciones

objetivos: La funcionalidad, el rendimiento, la interfaz de hardware / software, factores crticos de xito, etc.
Alternativas: Construir, reutilizacin, comprar, subcontratar, etc.
limitaciones: Costos, plazos, interfaz, etc.
Cuadrante 2: Evaluar alternativas, identificar y resolver los riesgos
Estudiar alternativas relativas a los objetivos y limitaciones que se determinen.
Identificar los riesgos, tales como la falta de experiencia, la nueva tecnologa, horarios apretados, etc.
13
Resolver los riesgos identificados evaluando su impacto en el proyecto, la identificacin de los planes de mitigacin y contingencia
necesarios y ponerlos en prctica. Los riesgos siempre deben ser supervisados.
Cuadrante 3: Desarrollo de producto del siguiente nivel
Las actividades tpicas incluyen -
Crear un diseo
Design Review
desarrollar cdigo
inspeccionar el cdigo
producto de prueba
Cuadrante 4: Planificar siguiente fase
Las actividades tpicas incluyen -
Desarrollar un plan de proyecto
Desarrollar un plan de gestin de la configuracin
Desarrollar un plan de pruebas
Desarrollar un plan de instalacin
Modelo espiral - Fortalezas
Las ventajas o puntos fuertes del mtodo son-Espiral
Proporciona una indicacin temprana de los riesgos, sin que ello suponga mucho coste.
Los usuarios pueden ver el sistema temprana debido a las herramientas de prototipado rpido.
Las funciones crticas de alto riesgo se desarrollaron por primera vez.
El diseo no tiene que ser perfecto.
Los usuarios pueden participar estrechamente en todas las etapas del ciclo de vida.
retroalimentacin temprana y frecuente de los usuarios.
costos acumulados evaluados con frecuencia.
Modelo espiral - Debilidades

Las desventajas o debilidades del mtodo de espiral son-
Puede ser difcil de definir objetivos, hitos verificables que indican disposicin para proceder a travs de la siguiente iteracin.
El tiempo empleado en la planificacin, al restablecer los objetivos, haciendo anlisis de riesgos y la creacin de prototipos puede ser una
sobrecarga.
El tiempo empleado para la evaluacin de riesgos puede ser demasiado grande para proyectos de bajo riesgo pequeo o.
14
modelo espiral es complejo de entender para los nuevos miembros del equipo.
Se requiere experiencia en la evaluacin de riesgos.
Espiral puede continuar indefinidamente.
Los desarrolladores deben ser reasignados durante las actividades de fase no-desarrollo.
Cundo utilizar Espiral Modelo?
El modelo de espiral se puede utilizar cuando-
Creacin de un prototipo es apropiado.
La evaluacin del riesgo es importante.
Un proyecto es de mediano a alto riesgo.
Los usuarios no estn seguros de sus necesidades.
Requisitos son complejos.
La lnea de productos es nueva.
Se espera que los cambios significativos durante la exploracin.
compromiso de proyecto a largo plazo prudente debido a los cambios potenciales de negocios.
15
7. SDLC mtodos giles
Mtodos giles se basan en el manifiesto gil y son adaptativos en la naturaleza. Los mtodos giles asegurar-
Colaboracin en equipo.
Colaboracin con el cliente.
La comunicacin constante y continua.
Respuesta a los cambios.
Preparacin de un producto de trabajo.
Varios mtodos giles entraron en existencia, la promocin del desarrollo iterativo e incremental con iteraciones encajadas en tiempo. Aunque
los mtodos giles son adaptativos, reglas del mtodo especfico no puede ser pasado por alto y por lo tanto requiere la implementacin
disciplinada.
Mtodos giles - Fortalezas
Las ventajas o puntos fuertes de mtodo gil son-
Las primeras versiones y frecuentes.
El alojamiento para la evolucin de las necesidades.
La comunicacin diaria entre el cliente y los desarrolladores.
Proyectos construidos en torno a individuos motivados.
equipos auto-organizados.
Simplicidad, centrndose en lo que se requiere de inmediato.
Ningn edificio para el futuro o sobrecargar el cdigo.
reflexin regular para ajustar el comportamiento para mejorar la eficacia.
Mtodos giles - Debilidades

Las desventajas o debilidades del mtodo de espiral son-
la disponibilidad del cliente puede no ser posible.
Los equipos deben ser experimentados a seguir las reglas del mtodo.
Se requiere una planificacin adecuada para decidir rpidamente sobre la funcionalidad que necesita ser entregado en una
iteracin.
Se espera que el equipo para tener destrezas de clculo y capacidad de negociacin.
Equipo debe tener habilidades de comunicacin efectiva.
Los nuevos equipos pueden no ser capaces de organizarse.
Requiere disciplina para desarrollar y entregar en las iteraciones encajadas en tiempo.
diecisis
El diseo necesita ser simple y fcil de mantener, por lo que requiere habilidades de diseo eficaces.
Cundo utilizar mtodos giles?
Los mtodos giles se pueden utilizar cuando-
La aplicacin es crtica en el tiempo.
El alcance es limitado y menos formal (escalamiento mtodos giles para proyectos ms grandes est en marcha, con ciertas
extensiones a algunos de los mtodos giles).
Organizacin emplea mtodos disciplinados.
17
8. ASD Evolucin
Los modelos anteriores SDLC estn ms orientados a las prcticas de la estabilidad, la previsibilidad y rendimientos decrecientes. La
industria, tales como las plataformas de Internet se ha estado moviendo para aumentar los entornos de retorno, impredecible, no lineal, y se
acerca rpidamente.
Adaptativa de desarrollo de software (ASD) ha evolucionado para abordar estas cuestiones. Se centra en el surgimiento como el factor ms
importante desde la perspectiva de la gestin, para mejorar la capacidad de gestionar el desarrollo de productos.
En palabras de Jim Highsmith, marco de desarrollo de software adaptativo se basa en aos de experiencia con metodologas de desarrollo de
software tradicionales, consultora en, ejercicio, y escriben sobre desarrollo rpido de aplicaciones (RAD) tcnicas y trabajar con las
compaas de software de alta tecnologa en la gestin de su desarrollo de productos prcticas.
modelo de cascada se encuentra a caracterizarse por la linealidad y la previsibilidad, con escasa retroalimentacin. Puede ser visto como una
secuencia de Plan -> Build -> Ejecutar.
Los modelos de ciclo de vida evolutivas tales como el modelo espiral movieron el enfoque determinista de la adaptacin, la Plan -> Build ->
Ciclos Revisar.
Sin embargo, la mentalidad de los practicantes se mantuvo determinstico y previsibilidad a largo plazo de pasar a la previsibilidad a corto
plazo. Las prcticas de los modelos de ciclo de vida evolutivas tales como RAD se encuentran para ser menos determinista.
18
El Ciclo de Vida de adaptacin
El modelo adaptativo se construye desde un punto de vista diferente. Aunque cclico como el modelo evolutivo, los nombres de la fase reflejan
la naturaleza impredecible de los sistemas cada vez ms complejos.
Desarrollo de adaptacin va ms all de su herencia evolutiva de dos maneras: clave
Sustituye explcitamente determinismo con la emergencia.
Va ms all de un cambio en el ciclo de vida de un cambio profundo en el estilo de gestin.
Las tres fases en el desarrollo del ciclo de vida del software adaptativo son-
Especular: Especular sustituye a la planificacin de la palabra determinista, la planificacin de las especificaciones o la

planificacin de las tareas de gestin de proyectos de productos.
Colaborar: Colaborar representa un equilibrio entre el dibujo

o La gestin en el sentido tradicional de la gestin de proyectos, y
o Crear y mantener el entorno de colaboracin necesaria para
aparicin.
Las actividades de colaboracin construir productos, manteniendo el ritmo de los cambios en el medio ambiente.
Aprender: Aprender objetivos tanto, los desarrolladores y los clientes, para utilizar los resultados de cada ciclo de desarrollo para
aprender la direccin de la siguiente.
19
9. ASD - Conceptos
En este captulo, vamos a comprender los diversos conceptos de desarrollo de software adaptativo.
Sistemas adaptativos complejos (CAS) Teora
Brian Arthur y sus colegas en el Instituto de Santa Fe, utilizan la teora complejo adaptativo Sistemas (CAS) para revolucionar la comprensin
de la fsica, biologa, evolucin, y Economa.
Brian Arthur culmin sus ms de dos dcadas de tratar de convencer a los economistas de la corriente que su punto de vista, dominado por
los supuestos fundamentales de rendimientos decrecientes, el equilibrio y dinmica determinista, ya no era suficiente para comprender la
realidad. El nuevo mundo es uno de los rendimientos crecientes, la inestabilidad y la imposibilidad de determinar la causa y efecto.
Los dos mundos diferentes en el comportamiento, el estilo y la cultura. Se llaman a para-
Diferentes Tcnicas de Gestin
diferentes estrategias
La comprensin diferente
Desarrollo de software complejos
Con el alcance de las aplicaciones de software que se explot, incluso las organizaciones de desarrollo de software se estn incrementando a
contradicciones similares como se mencion anteriormente.
Un mundo, est representado por el desarrollo determinista, derivado de las prcticas de gestin sustentados con los fundamentos
de la estabilidad y la previsibilidad (que en trminos de Arthur significa rendimientos decrecientes)
En segundo lugar mundial est representado por las industrias que se mueven de disminuir a aumentar los entornos de retorno
que son impredecibles, no lineal y rpido.
Para hacer frente a los problemas de este segundo mundo, Jig Highsmith ofreci un marco, desarrollo de software adaptativo que es diferente
de la de desarrollo de software determinstico.
El desarrollo de software de adaptacin se centra en abordar el complejo de Sistemas
Desarrollo de software adaptativo para el ciclo de vida de desarrollo.
Tcnicas de manejo adaptativo que piden una mentalidad diferente a la de las prcticas tradicionales de gestin de proyectos.
En este tutorial, se puede entender estas dos implementaciones.
20
Desarrollo de software adaptativo (TEA) se basa en dos perspectivas:
perspectiva conceptual basada en la teora Complex adaptativa Sistemas (CAS), como se da en la primera seccin de este
captulo.
Punto de vista prctico basado en
o Aos de experiencia con metodologas de desarrollo de software determinista.
o Consultar, practicar y escribir sobre el Desarrollo rpido de aplicaciones

(RAD) tcnicas; y trabajar con las compaas de software de alta tecnologa en la gestin de desarrollo de sus
productos.
En este captulo, se entiende por la perspectiva conceptual de desarrollo de software adaptativo.
Sistemas adaptativos complejos (CAS) Conceptos
teora compleja adaptativa Sistemas (CAS) tiene muchos conceptos. Desarrollo de software de adaptacin se basa en dos de estos
conceptos-
Aparicin
Complejidad
Aparicin
En los proyectos de desarrollo de productos de software complejos, los resultados son inherentemente impredecible. Sin embargo, los
productos de xito surgen de tales ambientes todo el tiempo.
Esto puede suceder por Aparicin, como se ilustra en la teora Complex adaptativa Sistemas (CAS). Se puede entender por un simple
ejemplo, el comportamiento de las aves flocado.
Cuando se observa una bandada de pjaros, se da cuenta que-
Cada ave intenta

o Mantener una distancia mnima de otros objetos en el ambiente,
incluyendo otras aves.
o Partido velocidades con las aves en su vecindad.
o Avanzar hacia el centro percibido de masa de aves en su vecindad.
No hay reglas de comportamiento para el grupo. Las nicas reglas son sobre el comportamiento de las aves individuales.
Sin embargo, existe un comportamiento emergente, el flocado de las aves. Cuando las aves errantes se apresuran a ponerse al
da, el rebao se divide alrededor de los obstculos y las reformas en el otro lado.
Esto demuestra la exigencia de los ms difciles cambios de modelo mental en el desarrollo adaptativo A partir de formas de gestin y
organizacin que la libertad individual a la idea de que un nuevo orden creativa surge de forma impredecible de autoorganizacin espontnea.
21
Adems del desarrollo, la emergencia es el concepto ms importante desde la perspectiva de gestin tambin.
Complejidad
En el contexto de desarrollo de software, la complejidad es sobre-
Los individuos de un equipo como los desarrolladores, clientes, proveedores, competidores y accionistas, sus nmeros y su
velocidad.
El tamao y la complejidad tecnolgica.
Prcticas de desarrollo de software de adaptacin
Adaptativa de desarrollo de software ofrece una perspectiva diferente de las prcticas de gestin de software. En las siguientes secciones, se
puede entender las dos prcticas importantes - Calidad y RAD, los cuales tienen ramificaciones para recopilar los requisitos.
Puede encontrar los detalles de todas las prcticas en el captulo, prcticas de desarrollo de software de adaptacin en este tutorial.
Calidad
En un entorno complejo, la antigua prctica de "hacerlo bien la primera vez" no funciona, ya que no se puede predecir lo que es justo al
principio. Es necesario tener un objetivo para producir el valor correcto. Sin embargo, en medio complejo, las combinaciones y permutaciones
de los componentes de valor como campo de aplicacin (caractersticas, el rendimiento, los niveles de defectos), calendario, y los recursos es
tan grande que no puede haber un valor ptimo. Por lo tanto, el objetivo es cambiar a ofrecer el mejor valor en el mercado competitivo.
Prcticas de RAD
Prcticas de RAD generalmente implican una combinacin de la siguiente-
Ciclo de vida evolutiva
Cliente grupos de enfoque, JAD Sesiones, estudios tcnicos
Gestin de Proyectos Tiempo en caja
Ingeniera de Software continua
Los equipos dedicados con salas de guerra
Los proyectos tienen un RAD adaptativo, el sabor inherente emergente. Muchas organizaciones de TI estn en contra de RAD. Sin embargo,
Microsoft y otros han producido software increblemente grande y compleja usando tcnicas comparables a RAD porque plantea preguntas
acerca de su punto de vista fundamental mundo.
RAD prcticas y procedimientos Microsoft son dos ejemplos de Desarrollo de adaptacin en accin. Dndoles una etiqueta (es decir, Adaptive
Development) y darse cuenta de que hay un creciente cuerpo de conocimiento cientfico (es decir, la teora CAS) explica por qu funcionan.
Esto debera proporcionar una base para un uso ms amplio de estas prcticas.
22
10.
TEA - Ciclo de Vida
Adaptativa de desarrollo de software ha evolucionado a partir de las prcticas de RAD. Los aspectos del equipo tambin se han aadido a
estas prcticas. Las empresas de Nueva Zelanda a Canad, para una amplia gama de tipos de proyectos y productos, han utilizado de
desarrollo de software adaptativo.
Jim Highsmith public desarrollo de software adaptativo en 2000.
prcticas de desarrollo de software de adaptacin proporcionan capacidad de adaptarse a los cambios y son adaptables en entornos
turbulentos con productos que evolucionan con poca planificacin y el aprendizaje.
Fases del Ciclo de Vida TEA
Adaptativa de desarrollo de software es cclico como el modelo evolutivo, con los nombres de las fases que reflejan el carcter impredecible
de los sistemas complejos. Las fases del ciclo de vida del software adaptativo desarrollo son-
Especular
Colaborar
Aprender
Estas tres fases reflejan la naturaleza dinmica de desarrollo de software adaptativo. El desarrollo adaptativo reemplaza explcitamente
determinismo con la emergencia. Va ms all de un simple cambio en el ciclo de vida de un cambio profundo en el estilo de gestin.
Adaptativa de desarrollo de software tiene una dinmica especular-Colaborar-Learn ciclo de vida.
El Ciclo de Vida de Desarrollo de Software Adaptable centra en los resultados, no las tareas, y los resultados se identifica como funciones de
la aplicacin.
23
Especular
El plan a largo plazo es demasiado determinista e indica un razonablemente alto grado de certeza sobre el resultado deseado. La meta
implcita y explcita de la conformidad para planificar, restringe la capacidad del gestor para dirigir el proyecto en direcciones innovadoras.
En desarrollo de software adaptativo, el plan a largo plazo se sustituye por el trmino especular. Mientras que especular, el equipo no
abandona la planificacin, pero reconoce la realidad de la incertidumbre en problemas complejos. Especular fomenta la exploracin y la
experimentacin. Se anima iteraciones con ciclos cortos.
Colaborar
Las aplicaciones complejas no se construyen, que evolucionan. Las aplicaciones complejas requieren que se recoge un gran volumen de
informacin, analizada, y se aplica al problema. entornos turbulentos tienen altas tasas de flujo de informacin. Por lo tanto, las aplicaciones
complejas requieren que se recoge un gran volumen de informacin, analizada, y se aplica al problema. Esto da lugar a diversas necesidades
de conocimiento que slo pueden ser manejados por la colaboracin en equipo.
Colaborar requerira la capacidad de trabajar de forma conjunta para producir resultados, compartir conocimientos o tomar decisiones.
En el contexto de la gestin de proyectos, colaboracin representa un equilibrio entre la gestin con las tcnicas tradicionales de gestin y
crear y mantener el entorno de colaboracin necesaria para la emergencia.
Aprender
Aprender la parte del ciclo de vida es vital para el xito del proyecto. Equipo tiene que mejorar sus conocimientos constantemente, utilizando
prcticas tales como-
Comentarios tcnicos
Retrospectivas de proyectos
Grupos de Enfoque del cliente
Los comentarios deben hacerse despus de cada iteracin. Ambos, los desarrolladores y clientes a examinar sus supuestos y utilizar los
resultados de cada ciclo de desarrollo para aprender la direccin de la siguiente. El equipo de learns-
Acerca de los cambios de productos
Ms cambios fundamentales en las suposiciones subyacentes acerca de cmo se estn desarrollando los productos
Las iteraciones deben ser breves, por lo que el equipo pueda aprender desde pequeos en lugar de grandes errores.
24
Especular - Colaborar - ciclo de aprendizaje como un todo
Como se observa a partir del ciclo Especular-Colaborar-Learn, teniendo en cuenta lo anterior, es evidente que las tres fases son no lineales y
la superposicin.
Observamos lo siguiente de un marco de adaptacin.
Es difcil colaborar sin tener que aprender o aprender sin Colaboracin.
Es difcil especular sin tener que aprender o para aprender sin especular.
Es difcil especular sin Colaborando o para colaborar sin especular.
25
11.
ASD del ciclo de vida - Caractersticas
Adaptativo del ciclo de vida de desarrollo de software tiene seis caractersticas- bsica
La misin se centr
funcin basada
Iterativo
Tiempo en caja
riesgo impulsada
cambiar tolerantes
En este captulo, se entiende por estas seis caractersticas de desarrollo de software adaptativo.
Enfocado en la misin
Para muchos proyectos, la misin general que gua el equipo est bien articulado, aunque los requisitos pueden ser incierto al comienzo del
proyecto. Las declaraciones de misin actan como guas que fomentan la exploracin en el comienzo, pero que tienen un enfoque estrecho
en el transcurso de un proyecto. Una misin ofrece lmites ms que un destino fijo. Las declaraciones de misin y las discusiones que dan
lugar a esos estados proporcionan la direccin y los criterios para la toma de las decisiones de equilibrio del proyecto crtico.
Sin una misin clara y una prctica constante refinamiento de la misin, los ciclos de vida iterativos se convierten en los ciclos de vida de
oscilacin, balanceo hacia atrs y adelante sin avances en el desarrollo.
Caracterstica de base
El ciclo de vida de desarrollo de software adaptativo se basa en las caractersticas de aplicacin y no en tareas. Las caractersticas son las
funciones que se desarrollan durante una iteracin sobre la base de las prioridades del cliente.
Las caractersticas pueden evolucionar a lo largo de varias iteraciones cuando los clientes proporcionan retroalimentacin.
Las caractersticas de las aplicaciones que proporcionan resultados directos para el cliente despus de la implementacin son primarios. Un
documento orientado al cliente, tal como un manual de usuario tambin se considera como una caracterstica. Los otros documentos, tales
como el modelo de datos, incluso si se definen como entregables son siempre secundarios.
Iterativo
El ciclo de vida de desarrollo de software de adaptacin es iterativo y se centra en las liberaciones frecuentes con el fin de obtener
retroalimentacin, asimilar el aprendizaje resultante y establecer la direccin correcta para un mayor desarrollo.
Tiempo en caja
En Adaptive de desarrollo de software de ciclo de vida, las iteraciones son encajadas en tiempo. Sin embargo, hay que recordar que el tiempo
de boxeo en el desarrollo de software adaptativo no es hora
26
plazos. No debe ser utilizado para hacer el trabajo en equipo durante largas horas desafiantes un entorno de colaboracin o para
comprometer la calidad de los entregables.
En desarrollo de software adaptativo, el tiempo-boxeo se considera como una direccin para enfocar y obligando a las decisiones de equilibrio
duras como y cuando sea necesario. En un entorno de incertidumbre, en el que las tasas de cambio son altos, es necesario que haya una
funcin de fuerza peridica, como una caja de tiempo para hacer el trabajo terminado.
Riesgo impulsada
En desarrollo de software adaptativo, las iteraciones son impulsados por identificar y evaluar los riesgos crticos.
Cambio tolerantes
Adaptativa de desarrollo de software es el cambio tolerante, ver el cambio como la capacidad de incorporar una ventaja competitiva, pero no
como un problema para el desarrollo.
27
12. ASD - Prcticas
Las prcticas de desarrollo de software adaptativo son impulsados por la creencia en la adaptacin continua, con el ciclo de vida equipado
para aceptar el cambio continuo como la norma.
Adaptativo del ciclo de vida de desarrollo de software se dedica a-
Aprendizaje continuo
cambio de orientacin
Reevaluacin
Mirando en un futuro incierto
la colaboracin intensa entre los desarrolladores, la gestin y los clientes
SDLC adaptativo
Adaptativa de desarrollo de software combina con RAD Ingeniera de Software Mejores prcticas, tales como-
Iniciacin del proyecto.
planificacin del ciclo de adaptacin.
ingeniera de componentes concurrente.
Revisin de calidad.
Control de calidad final y liberacin.
prcticas de desarrollo de software de adaptacin pueden ilustrarse como sigue-
28
Como se ilustra anteriormente, las prcticas de desarrollo de software adaptativo se distribuyen en las tres fases de los siguientes-
especular - Iniciacin y planificacin
o Iniciacin del proyecto
o El establecimiento de recuadros para todo el proyecto
o Decidir sobre el nmero de iteraciones y asignar un tiempo de cuadro a cada uno
o Desarrollar un tema u objetivo para cada una de las iteraciones
o Asignar funciones a cada iteracin
Colaborar - el desarrollo de funciones Concurrente
o La colaboracin de los equipos distribuidos
o Colaboracin para proyectos ms pequeos
o Colaboracin para proyectos ms grandes
Aprender - Revisin de calidad
o la calidad del resultado de la perspectiva del cliente
o calidad de los resultados desde una perspectiva tcnica
o El funcionamiento del equipo de entrega y los miembros del equipo son prcticas
la utilizacin de
o El estado del proyecto
especular Iniciacin y Planificacin
En desarrollo de software adaptativo, el especular fase tiene dos actividades-
Iniciacin
Planificacin
Especular tiene cinco prcticas que se pueden ejecutar de forma repetitiva durante la fase de iniciacin y planificacin. Son-
Iniciacin del proyecto
El establecimiento de recuadros para todo el proyecto
Decidir sobre el nmero de iteraciones y asignar un tiempo de cuadro a cada uno
Desarrollar un tema u objetivo para cada una de las iteraciones
Asignar funciones a cada iteracin
29
Iniciacin del proyecto
involucra-Inicio del Proyecto
Ajuste de la misin y los objetivos del proyecto
restricciones comprensin
El establecimiento de la organizacin del proyecto
Identificar y delinear los requisitos
Hacer estimaciones iniciales tamao y alcance
La identificacin de los principales riesgos del proyecto
Los datos de la iniciacin del proyecto deben ser reunidos en una sesin de JAD preliminar, teniendo en cuenta la velocidad como el aspecto
principal. La iniciacin se puede completar en un esfuerzo concentrado cuatro y cincuenta y ocho das para un pequeo a proyectos de tamao
mediano, o dos o tres semanas esfuerzo para proyectos ms grandes.
Durante las sesiones de JAD, los requisitos se recogen con suficiente detalle para identificar las caractersticas y establecer una visin general
del objeto, datos, u otro modelo arquitectnico.
El establecimiento de Time-caja para el todo el proyecto
La caja de tiempo para todo el proyecto se debe establecer, en funcin del alcance, requerimientos conjunto de caractersticas, las
estimaciones, y la disponibilidad de recursos que resultan del trabajo de iniciacin del proyecto.
Como ya saben, Especular no abandona la estimacin, pero simplemente significa aceptar que las estimaciones pueden ir mal.
Iteraciones y tiempo-box
Decidir sobre el nmero de iteraciones y las longitudes de iteracin individuales basados en el alcance general del proyecto y el grado de
incertidumbre.
Para un pequeo a aplicacin- tamao mediano
Iteraciones por lo general varan de cuatro a ocho semanas.
Algunos proyectos funcionan mejor con iteraciones de dos semanas.
Algunos proyectos pueden requerir ms de ocho semanas.
Elegir el momento, sobre la base de lo que funciona para usted. Una vez que decida sobre el nmero de iteraciones y la longitud de cada una
de las iteraciones, asignar un horario para cada una de las iteraciones.
Desarrollar un tema u objetivo

Los miembros del equipo deben desarrollar un tema u objetivo para cada iteracin. Esto es algo similar a la Meta Sprint en Scrum. Cada
iteracin debe entregar un conjunto de caractersticas que puedan demostrar la funcionalidad del producto haciendo que el producto visible
para el cliente para permitir la revisin y retroalimentacin.
Dentro de las iteraciones, las compilaciones deben ofrecer las caractersticas de trabajo sobre una base diaria, preferentemente permitiendo
proceso de integracin y la elaboracin del producto visible para el equipo de desarrollo.
30
La prueba debe ser una parte permanente e integral del desarrollo de funciones. No debe retrasarse hasta el final del proyecto.
asignar funciones
Desarrolladores y clientes juntos deben asignar funciones a cada iteracin. Los criterios ms importantes para esta asignacin caracterstica
es que cada iteracin debe entregar un conjunto de caractersticas visibles con funcionalidad considerable para el cliente.
Durante la asignacin de funciones a la iterations-
equipo de desarrollo debe llegar a las estimaciones de caractersticas, riesgos y dependencias y proporcionarles a los clientes.
Los clientes deben decidir sobre el establecimiento de prioridades funcin, utilizando la informacin proporcionada por el equipo de
desarrollo.
Por lo tanto la planificacin de iteracin se basa-FUNCIN y hace como un equipo con los desarrolladores y clientes. La experiencia ha
demostrado que este tipo de planificacin proporciona una mejor comprensin del proyecto que una planificacin basada en la tarea por el
director del proyecto. Adems, la planificacin basada en funcin refleja la singularidad de cada proyecto.
Colaborar Desarrollo Concurrente Caracterstica
Durante la fase de Colaboracin, la atencin se centra en el desarrollo. La fase Colaborar tiene dos actividades-
El equipo de desarrollo de colaborar y entregar software que trabaja.
Los gestores de proyectos facilitan las actividades de desarrollo concurrentes y la colaboracin.
La colaboracin es un acto de creacin compartida que abarca el equipo de desarrollo, los clientes y los gerentes. creacin compartida es
fomentada por la confianza y el respeto.
Los equipos deben colaborar situ
Problemas tcnicos
Los requisitos de negocio
rpida toma de decisiones
A continuacin se presentan las prcticas correspondientes a la fase de Colaboracin en Software Adaptable Desarrollo-
La colaboracin de los equipos distribuidos
Colaboracin para proyectos ms pequeos
Colaboracin para proyectos ms grandes
31
La colaboracin de los equipos distribuidos
En los proyectos relacionados con los equipos distribuidos, lo siguiente debe ser considered-
La variacin de socios de la alianza
el conocimiento de base amplia
La forma en que las personas interactan
La forma de gestionar las interdependencias
Colaboracin para proyectos ms pequeos
En los proyectos ms pequeos, cuando los miembros del equipo estn trabajando en la proximidad fsica, la colaboracin con charlas de
pasillo informales y garabatos pizarra debe fomentarse, ya que este se encuentra para ser eficaz.
Colaboracin para proyectos ms grandes
Los proyectos ms grandes requieren prcticas adicionales, herramientas de colaboracin e interaccin director del proyecto y deben ser
dispuestos en la base contextual.
Aprender - Revisin de Calidad
Desarrollo de software adaptativo fomenta el concepto de 'experimentar y aprender'.
Aprender de los errores y la experimentacin requiere que los miembros del equipo comparten parcialmente completado de cdigo y
artefactos temprana, con el fin a-
Encuentra errores
Aprende de ellos
Reducir el trabajo redundante mediante la bsqueda de pequeos problemas antes de que se conviertan en grandes
Al final de cada iteracin de desarrollo, hay cuatro categoras generales de las cosas a aprender-
la calidad del resultado de la perspectiva del cliente
calidad de los resultados desde una perspectiva tcnica
El funcionamiento del equipo de entrega y el equipo de prcticas
El estado del proyecto
Calidad resultado de la perspectiva del cliente

En los proyectos de desarrollo de software de adaptacin, conocer la opinin de los clientes es la primera prioridad. La prctica recomendada
para este grupo es un enfoque en el cliente. Estas sesiones estn diseadas para explorar un modelo de trabajo de las solicitudes de cambio
al cliente aplicacin despus de registrar.
sesiones de grupos de enfoque en el cliente son sesiones facilitadas, similar a jad sesiones, pero en vez de generar requisitos o la definicin
de planes de proyectos, que estn diseados para revisar la
32
propia aplicacin. Los clientes brindan informacin sobre el software de trabajo resultante de una iteracin.
Calidad resultado desde una perspectiva tcnica
En los proyectos de desarrollo de software de adaptacin, revisin peridica de los artefactos tcnicos se debe dar importancia. Revisiones de
cdigo se debe hacer sobre una base continua. Los comentarios de otros artefactos tcnicos, como la arquitectura tcnica pueden llevar a
cabo semanal o al final de una iteracin.
En los proyectos de desarrollo de software de adaptacin, el equipo debe supervisar peridicamente su propio desempeo. Retrospectivas
animan a los equipos a aprender sobre s mismos y su trabajo, juntos como un equipo.
retrospectivas de iteracin de fin de facilitar peridicamente el desempeo del equipo de auto-revisin tales como-
Determinar lo que no funciona.
Lo que el equipo tiene que hacer ms.
Lo que el equipo tiene que hacer menos.
El Estado del proyecto
La revisin del estado del proyecto ayuda a la hora de planificar el trabajo futuro. En los proyectos de desarrollo de software de adaptacin,
para determinar el estado del proyecto es el enfoque basado en funciones, al final de cada iteracin marcado por caractersticas resultantes
terminados en el software de trabajo.
La revisin debe incluir: Estado del proyecto
Dnde est el proyecto?
Dnde est el proyecto en comparacin con los planes?
Dnde debera estar el proyecto?
A medida que los planes en los proyectos de desarrollo de software adaptativo son especulativas, ms que la pregunta 2, pregunta 3 es
importante. Es decir, el equipo del proyecto y los clientes tienen que pedir continuamente a s mismos, "Qu hemos aprendido hasta ahora, y
lo hace cambiar nuestra perspectiva sobre dnde tenemos que ir?"
33
13. Manejo Adaptativo - TEA
Un diagrama de flujo del software de gestin tradicional se muestra a continuacin.
gestin de software tradicional se ha caracterizado por el trmino de control y mando.
Muchas organizaciones estn inmersos en una tradicin de optimizacin, eficiencia, previsibilidad, el control, el rigor y la mejora de procesos.
Sin embargo, la economa era de la informacin emergente requiere capacidad de adaptacin, la velocidad, la colaboracin, la improvisacin,
la flexibilidad, la innovacin y la flexibilidad.
revisin del negocio de Harvard y libros de gestin han llegado con los trminos tales como la potenciacin, la gestin participativa,
organizacin de aprendizaje, centrado en el ser humano
gestin, etc., pero ninguno de ellos se estn poniendo en la gestin de las organizaciones modernas.
En el contexto de desarrollo de software adaptativo, la brecha se ve mucho ms amplio y hay una necesidad de considerar las tcnicas de
gestin adaptativa que han sido probados con xito en otros campos.
Manejo adaptativo
La gestin adaptativa ha demostrado su eficacia en los entornos en los que los gestores de recursos trabajaron juntos con los interesados y
los cientficos como un equipo, con la siguiente goals-
Para aprender cmo los sistemas administrados responden a las intervenciones humanas.
Para mejorar las polticas y prcticas de recursos en el futuro.
El principio detrs de gestin adaptativa es que muchas de las actividades de gestin de recursos son experimentos que sus resultados no se
pueden predecir de forma fiable de antemano. Estos experimentos se utilizan como oportunidades de aprendizaje para las mejoras en el
futuro.
El manejo adaptativo est destinado a aumentar la capacidad de respuesta oportuna frente a la nueva informacin y en un marco de objetivos
de los interesados variados y preferencias. Se anima a los interesados a los conflictos consolidados y discutirlos de una manera ordenada,
mientras que las incertidumbres medioambientales estn siendo investigados y mejor entendidas.
La gestin adaptativa ayuda a las partes interesadas, los administradores y dems responsables reconocen los lmites del conocimiento y la
necesidad de actuar sobre la informacin imperfecta.
34
La gestin adaptativa ayuda a cambiar las decisiones tomadas por lo que es claro que-
Las decisiones son provisionales.
La decisin de una gestin no siempre tiene por qu ser la derecha.
Se espera que las modificaciones.
Hay dos tipos de gestin adaptativa approaches-
Manejo Adaptativo pasiva.
Manejo Adaptativo activo.
Manejo Adaptativo pasiva

El manejo adaptativo tiene como objetivo mejorar el conocimiento cientfico y con ello reducir las incertidumbres.
Dentro de la gestin pasiva de adaptacin, un solo curso de accin preferido, sobre la base de informacin y conocimiento existente, se
selecciona. Los resultados de las acciones de gestin se controlan, y las decisiones subsiguientes se ajustan en base a los resultados.
Este enfoque contribuye al aprendizaje y la gestin eficaz. Sin embargo, est limitado en su capacidad para mejorar la capacidad cientfica y
de gestin para las condiciones que van ms all de la lnea de accin seleccionado.
Manejo Adaptativo Activo

Un enfoque de manejo adaptativo activo revisa la informacin antes de tomar las medidas de gestin.
Una gama de competencia, modelos de sistema alternativo de las respuestas del ecosistema y relacionados (por ejemplo, cambios
demogrficos; usos recreativos), en lugar de un nico modelo, es entonces
desarrollado. Las opciones de manejo se eligen basndose en las evaluaciones de estos modelos alternativos.
35
Liderazgo-Colaboracin
El manejo adaptativo es lo que es el ms adecuado para desarrollo de software adaptativo. El enfoque requiere que los administradores de
recursos, es decir, los gerentes que pueden trabajar con la gente, permitirn humanos-intervenciones, y crear un ambiente amistoso.
En el desarrollo de software, los lderes a menudo ocupan estas responsabilidades. Necesitamos lderes ms que los comandantes. Los
lderes son colaboradores y trabajar junto con el equipo. Colaboracin-liderazgo es el ms buscado despus de la prctica en el desarrollo
adaptativo.
Los lderes tienen las siguientes cualidades:
Agarre y establecer la direccin.
Influir en las personas involucradas y proporcionar orientacin.
Colaborar, facilitar y macro-manejar el equipo.
Proveer direccion.
Crear ambientes donde la gente con talento puede ser innovador, creativo, y tomar decisiones eficaces.
Entender que en ocasiones tienen que mandar, pero que no es su estilo predominante.
36

Adaptive Software Development Tutorial - En.es

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Adaptive Software Development Tutorial - En.es

Uploaded by

Copyright:

Available Formats

Desarrollo de software adaptativo

Acerca del Tutorial

Copyright y Descargo de responsabilidad

Derechos de autor 2016 por tutoriales Punto Pvt (I). Limitado.

Sobre el Tutorial ............................................... .................................................. ........................................... i audiencia .....

1. TEA - Introduccin ............................................... .................................................. ................................... 1

2. Modelos SDLC - Evolucin .............................................. .................................................. ........................... 3

3. SDLC Cascada Modelo .............................................. .................................................. ............................ 5

4. SDLC iterativo incremental Modelo ............................................. .................................................. ........... 9

5. SDLC El rpido desarrollo de aplicaciones Modelo ............................................ ........................................... 11

6. SDLC espiral Modelo .............................................. .................................................. ................................ 13

7. SDLC mtodos giles .............................................. .................................................. ............................. diecisis

8. ASD Evolucin ............................................... .................................................. ..................................... 18

9. TEA - Conceptos ............................................... .................................................. ...................................... 20

10. TEA - Ciclo de Vida .............................................. .................................................. ....................................... 23

11. ASD del ciclo de vida - Caractersticas .............................................. .................................................. ................ 26

12. TEA - Prcticas ............................................... .................................................. ...................................... 28

13. TEA - Manejo Adaptativo .............................................. .................................................. ................. 34

El manifiesto gil es:

Individuos e interacciones sobre procesos y herramientas.

software que trabaja sobre una amplia documentacin.

Colaboracin con el cliente durante la negociacin del contrato.

En respuesta a cambiar con el seguimiento de un plan.

Se fomenta la responsabilidad compartida y la responsabilidad.

Facilita la comunicacin efectiva y la colaboracin continua.

El enfoque de todo el equipo evita retrasos y tiempos de espera.

La colaboracin facilita la combinacin de diferentes perspectivas en la implementacin oportuna, reparaciones de defectos y

El progreso es constante, sostenible y predecible transparencia haciendo hincapi.

En este tutorial, vamos a aprender la metodologa gil - Desarrollo de software adaptativo.

Cul es adaptativa de desarrollo de software?

Hay dos enfoques para la realizacin de estas actividades-

Cuando se elige un modelo SDLC para su proyecto, es necesario entender:

trata de un modelo lineal sin bucles de retroalimentacin.

Modelo Cascada - Fortalezas

Los puntos fuertes del modelo cascada son-

Fcil de entender, fcil de usar.

Proporciona la estructura de equipo de desarrollo sin experiencia.

Los hitos se conocen bien.

Establece requisitos de estabilidad.

Ideal para el control de gestin (planificacin, supervisin, presentacin de informes).

Funciona bien cuando la calidad es ms importante que el costo o cronograma.

Modelo Cascada - Debilidades

Idealizado - No coincide con la realidad as.

No refleja la naturaleza iterativa del desarrollo exploratorio que es ms comn.

Difcil y costoso hacer cambios.

El software se suministra slo al final del proyecto. Debido a esto -

Cundo utilizar la cascada Modelo?

Se puede utilizar el modelo de cascada si -

Requisitos son muy bien conocidos.

Definicin del producto es estable.

La tecnologa est bien entendido.

Nueva versin de un producto existente.

Portar un producto existente a una nueva plataforma.

organizacin grande con equipos multi-funcionales estructurados.

Evolutiva Modelo de prototipos

Evolutiva Modelo de prototipos - Fortalezas

Permite el diseo y desarrollo flexible.

La interaccin con el prototipo estimula la conciencia de la funcionalidad adicional necesaria.

Requisitos y requerimientos inesperados cambios se acomodan fcilmente.

signos Steady y visibles de progreso se producen.

La entrega de un producto final preciso y fcil de mantener.

Evolutiva Modelo de prototipos - Debilidades

Este modelo recibi mala reputacin de los mtodos rpida y sucia.