El proceso unificado es iterativo e incremental
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

El Proceso Unificado es Iterativo e Incremental PowerPoint PPT Presentation


  • 75 Views
  • Uploaded on
  • Presentation posted in: General

El Proceso Unificado es Iterativo e Incremental. Índice. ¿Por qué un desarrollo iterativo e incremental? Atenuación de riesgos Obtención de una Arquitectura robusta Gestión de requisitos cambiantes Permitir cambios tácticos Conseguir una integración continua

Download Presentation

El Proceso Unificado es Iterativo e Incremental

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


El proceso unificado es iterativo e incremental

El Proceso Unificado es Iterativo e Incremental


Ndice

Índice

  • ¿Por qué un desarrollo iterativo e incremental?

  • Atenuación de riesgos

  • Obtención de una Arquitectura robusta

  • Gestión de requisitos cambiantes

  • Permitir cambios tácticos

  • Conseguir una integración continua

  • Conseguir un aprendizaje temprano


Por qu un desarrollo iterativo e incremental

¿Por qué un desarrollo iterativo e incremental?

  • En dos palabras: para obtener un “software mejor”.

  • Dicho con unas cuantas palabras más, para cumplir los hitos principales y secundarios con los cuales controlamos el desarrollo. Y dicho con algunas palabras más:

  • Para tomar las riendas de los riesgos críticos y significativos desde el principio.

  • Para poner en marcha una arquitectura que guíe el desarrollo del software.

  • Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos.

  • Para construir el sistema a lo largo del tiempo en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso.

  • Para proporcionar un proceso de desarrollo a través del cual el personal puede trabajar de manera más eficaz.

Regresar


Atenuaci n de riesgos

Atenuación de riesgos

  • El desarrollo de software se enfrenta con riesgos, al igual que cualquier otra actividad de ingeniería.

  • Según la visión del profeta de la dirección Peter F. Drucker: “El riesgo es inherente en el empleo de los recursos disponibles para las expectativas futuras.”

  • En el desarrollo de software, afrontamos esta realidad identificando los riesgos tan pronto como sea posible dentro del desarrollo y tratándolos rápidamente.

  • Un riesgo es una exposición que nos puede acarrear pérdidas o daños.

  • El riesgo es un factor, cosa, elemento o camino que constituye un peligro, cuyo grado es incierto.

  • En el desarrollo de software, podemos definir un riesgo como un asunto que tiene cierto grado de probabilidad de poner en peligro el éxito de un proyecto.


Atenuaci n de riesgos1

Atenuación de riesgos

Por ejemplo

  • El objectrequestbrokerque consideramos inicialmente, puede que no sea capaz de dar servicio a 1.000 búsquedas de objetos remotos, que representan cuentas de cliente, por segundo.

  • Un sistema de tiempo real puede tener que tomar un cierto número de entradas de datos que no se especificaron en la fase de inicio.

  • Puede que tenga que procesar los datos mediante cálculos intensivos que aún no se han definido con detalle, o puede que tenga que enviar una señal de control en un tiempo corto que aún no se ha especificado.

  • Un sistema de conmutación telefónica puede tener que responder a varias entradas en un número de milisegundos especificado por la empresa de operación de telecomunicaciones cliente.


Atenuaci n de riesgos2

Atenuación de riesgos

  • Lo que necesita la disciplina del software, como escribió Barry Boehm, es un modelo de proceso que “cree una aproximación al proceso de desarrollo de software dirigida por los riesgos en lugar de un proceso fundamentalmente dirigido por los documentos o dirigido por el código”.

  • El Proceso Unificado cumple con estos criterios porque trata los riesgos importantes en las dos primeras fases, inicio y elaboración, y cualquier riesgo restante al principio de la fase de construcción, por orden de importancia.

  • Identifica, gestiona, y reduce los riesgos en las primeras fases mediante las iteraciones.

  • En consecuencia, los riesgos no identificados o ignorados no emergen más tarde, poniendo en peligro el proyecto entero.


Atenuaci n de riesgos3

Atenuación de riesgos

  • La técnica iterativa para la reducción de los riesgos recuerda muy poco al método en cascada.

  • El modelo en cascada muestra el desarrollo pasando en un solo sentido por una serie de pasos: requisitos, análisis, diseño, implementación y prueba.

  • En este método, el proyecto debe implicar a todos sus desarrolladores cuando llega a la implementación, la integracióny la prueba.

  • Durante la integración y la prueba, los problemas pueden empezar a estallar a su alrededor.

  • El jefe de proyecto se verá entonces forzado a reasignar personas —habitualmente a los desarrolladores con más experiencia— para resolver esos problemas antes de que el trabajo pueda continuar.


Atenuaci n de riesgos4

Atenuación de riesgos

  • Sin embargo, como todos los desarrolladores ya están ocupados, los jefes de proyecto tendrán difícil el “liberar” a los pocos que estén más preparados para resolver los problemas que se acaban de descubrir.

  • Para tratar estas dificultades, la reasignación de los desarrolladores con más experiencia para “resolver los problemas” suele dejar a los desarrolladores con menos experiencia sentados esperando.

  • Los plazos pasan, y los costes se rebasan.

  • En el peor caso, nuestra competencia se hace con el mercado antes que nosotros.


El proceso unificado es iterativo e incremental

Figura 5.1. Los riesgos importantes se identifican y se reducen al principio del desarrollo iterativo, a diferencia a diferencia del desarrollo en cascada. En este último, los riesgos más importantes permanecen hasta que la integración y las pruebas del sistema se ocupan de ellos (como indica la línea discontinua). Las iteraciones indicadas en la parte inferior de la figura son, por supuesto, solamente relevantes para el enfoque iterativo e incremental.


Atenuaci n de riesgos5

Atenuación de riesgos

  • Si realizamos un gráfico del riesgo comparándolo con el tiempo de desarrollo, como en la Figura 5.1., el desarrollo iterativo empieza a reducir riesgos importantes en las primeras iteraciones.

  • En el momento en que el trabajo alcanza la fase de construcción, quedan pocos riesgos importantes, y el trabajo prosigue sin problemas.

  • En contraste, si utilizamos el modelo en cascada, los riesgos importantes no se tratan hasta la integración del código al estilo de un “bigbang”.

  • Cerca de las dos terceras partes de los proyectos software grandes fracasan en la realización de un análisis de riesgos adecuado, según Capers Jones, por tanto, ¡hay lugar para grandes mejoras! Atacar los riesgos al comienzo del proceso de desarrollo es el primer paso.

Regresar


Obtenci n de una arquitectura robusta

Obtención de una Arquitectura robusta

  • La consecución de una arquitectura robusta es en sí misma el resultado de las iteraciones en las primeras fases.

  • En la fase de inicio, por ejemplo, encontramos una arquitectura esencial que satisface los requisitos clave, evita los riesgos críticos, y resuelve los problemas de desarrollo principales.

  • En la fase de elaboración, establecemos la línea base de la arquitectura que guiará el resto del desarrollo.

  • Por un lado, la inversión en esas fases es todavía pequeña, y podemos permitirnos las iteraciones que garantizan que la arquitectura es robusta.

  • Por ejemplo, después de la primera iteración en la fase de elaboración, estamos en disposición de hacer una evaluación inicial de la arquitectura.

  • En este momento, aún podemos permitirnos cambiarla, si eso es lo que hemos decidido, para ajustaría a las necesidades de los casos de uso significativos y a los requisitos no funcionales.


Obtenci n de una arquitectura robusta1

Obtención de una Arquitectura robusta

  • Si seguimos el método en cascada, en el momento en que descubrimos la necesidad de un cambio en la arquitectura, ya hemos invertido tanto en el desarrollo que hacer un cambio en la arquitectura supone un revés económico importante.

  • Además, podríamos estar cerca de la fecha de entrega comprometida.

  • Atrapados entre los costes y el calendario, no tendremos la motivación necesaria para hacer un cambio en la arquitectura, podemos evitar este dilema centrándonos en la arquitectura en la fase de elaboración.

  • Estabilizamos la arquitectura hasta un nivel de línea base al principio del ciclo de vida, cuando los costes aún son bajos y el calendario todavía es generoso con nosotros.

Regresar


Gesti n de requisitos cambiantes

Gestión de requisitos cambiantes

  • Los usuarios pueden comprender más fácilmente un sistema en funcionamiento, aunque aún no funcione perfectamente, que un sistema que sólo existe en forma de cientos de páginas de documentos.

  • Además, tienen dificultades en reconocer el avance del proyecto si todo lo que existe son documentos.

  • Por tanto, desde la perspectiva de los usuarios y de otros interesados, es más productivo hacer evolucionar el producto a lo largo de una serie de versiones ejecutables, o “construcciones”, que presentar montañas de documentación difíciles de leer.

  • Una construcción es una versión operativa de parte de un sistema que demuestra un subconjunto de posibilidades del sistema.

  • Cada iteración debe progresar mediante una serie de construcciones hasta alcanzar el resultado esperado, es decir, el incremento.


Gesti n de requisitos cambiantes1

Gestión de requisitos cambiantes

  • El tener un sistema con un funcionamiento parcial en una fase inicial permite que los usuarios y otros interesados hagan sugerencias sobre él o señalen requisitos que se nos pueden haber escapado.

  • El plan —presupuesto y calendario— aún no es inamovible, de forma que los desarrolladores pueden incorporal” revisiones con más facilidad.

  • En el modelo unidireccional en cascada, los usuarios no ven un sistema funcionando hasta la integración y la prueba.

  • En ese momento, los cambios, incluso aquellos que son valiosos o parecen ser pequeños, introducen una desviación en el presupuesto o en el calendario de manera casi inevitable.

  • Por tanto, el ciclo de vida iterativo hace más sencillo a los clientes el observar la necesidad de requisitos adicionales o modificados pronto dentro del ciclo de desarrollo, y hace más sencillo también a los desarrolladores el trabajar en ellos.

  • No en vano, están construyendo el sistema mediante una serie de iteraciones, por lo que responder a una retroalimentación o incluir una revisión sólo significa un cambio incremental.

Regresar


Permitir cambios t cticos

Permitir cambios tácticos

  • Con el método iterativo e incrementa!, los desarrolladores pueden resolver los problemas y los aspectos no cubiertos por las primeras construcciones e incluir cambios para corregirlos casi a la vez.

  • Mediante esta técnica, los problemas se van descubriendo con un ritmo de goteo constante que los desarrolladores pueden tratar fácilmente.

  • La tromba de informes de fallo que aparece en la inte­gración en “bigbang” del ciclo en cascada a menudo rompe la marcha del proyecto.

  • Si la ruptura es grave, el proyecto puede llegar a pararse, con los desarrolladores aplastados por la presión, los jefes de proyecto dando vueltas en círculo, y con el pánico de otros directivos.

  • En contraste, una serie de construcciones funcionales ofrece a todos la sensación de que las cosas van bien.


Permitir cambios t cticos1

Permitir cambios tácticos

  • Los ingenieros de prueba, los escritores de manuales, los encargados de las herramientas, el personal de gestión de configuración, y los encargados del aseguramiento de la calidad pueden adaptar sus propios planes al calendario en evolución del proyecto.

  • Tienen conocimiento de la existencia de retrasos serios en las primeras fases del proyecto, cuando los desarrolladores encuentran por primera vez los problemas que los originan.

  • Tienen tiempo de adaptar sus propios calendarios.

  • Cuando los problemas descansan ocultos hasta la prueba, es demasiado tarde para que aquéllos puedan rehacer sus calendarios de forma eficaz.


Permitir cambios t cticos2

Permitir cambios tácticos

  • Cuando la iteración ha sido validada por el aseguramiento de la calidad, los jefes de proyecto, los arquitectos, y otros interesados pueden evaluarla según los criterios preestablecidos.

  • Pueden decidir si la iteración ha obtenido el incremento correcto y si los riesgos se han tratado adecuadamente.

  • Esta evaluación permite a los directores determinar si la iteración tuvo éxito.

  • Si fue así, pueden autorizar la siguiente.

  • Si la iteración sólo tuvo un éxito parcial, pueden ampliarla para cubrir aspectos no resueltos o para realizar las correcciones necesarias para la siguiente iteración.

  • En un caso extremo, cuando la evaluación sea totalmente negativa, pueden cancelar el proyecto entero.

Regresar


Conseguir una integraci n continua

Conseguir una integración continua

  • Al final de cada iteración, el equipo del proyecto demuestra que ha reducido algunos riesgos.

  • El equipo entrega nuevas funcionalidades en cada iteración, que se hacen evidentes para los usuarios, los cuales pueden observar el progreso del proyecto.

  • Las construcciones frecuentes fuerzan a los desarrolladores a concretar a intervalos regulares —concreción en forma de un fragmento de código ejecutable—.

  • La experiencia de las cons­trucciones les hace difícil a ellos o a cualquiera sostener la actitud del “90 por ciento completo”.

  • Esta actitud aparece cuando un número de fragmentos de código o de otros artefactos hace parecer que el producto está casi terminado.

  • Sin embargo, en ausencia de construcciones funcionales, es posible que la parte más difícil aún esté por venir.

  • Puede que aún no se hayan descubierto los problemas mediante intentos de integrar y probar el sistema.

  • En contraste, las sucesivas iteraciones, debido a que funcionan, producen una serie de resultados que nos indican exactamente el estado del proyecto.


Conseguir una integraci n continua1

Conseguir una integración continua

  • Incluso sí los desabolladores no consiguen obtener los resultados previstos en una de las primeras iteraciones, todavía tienen tiempo de intentarlo de nuevo y mejorar los modelos en las subsiguientes versiones internas.

  • Ya que primero trabajan sobre los aspectos más críticos, cuentan con varias oportunidades para mejorar sus resultados.

  • La línea gruesa de la Figura 5.2 muestra cómo funciona el desarrollo iterativo.

  • En puntos al comienzo del calendario, en este caso con sólo del 2 al 4 por ciento del proyecto codificado, se consigue un incremento (o construcción).

  • Este intento muestra algunos problemas, que se denotan en la figura por los pequeños descensos en la línea del avance, pero se resuelven rápidamente y el avance continúa.


Conseguir una integraci n continua2

Conseguir una integración continua

  • Después de ello, el proyecto realiza construcciones frecuentes.

  • Cada una de ellas puede llevar a una parada temporal del avance.

  • Debido a que los incrementos son relativamente pequeños, comparados con la integración final del producto entero (en la línea inferior), la recuperación se lleva a cabo rápidamente.


Conseguir una integraci n continua3

Conseguir una integración continua

  • Como sugiere el diagrama, en el método en cascada, una sola integración cercana a la fecha de entrega descubre una legión de problemas.

  • El gran volumen de problemas y la precipitación inevitable del momento tiene como resultado el que muchas de las correcciones no estén bien pensadas.

  • Apresurarse a corregir los problemas suele retrasar la entrega más allá de la fecha planificada.

  • En consecuencia, el desarrollo iterativo termina en mucho menos tiempo que el desarrollo en cascada.

  • Es más, el producto de un “proyecto en cascada” puede ser frágil, es decir, difícil de mantener.


El proceso unificado es iterativo e incremental

Figura 5.2. En el método en cascada (la línea fina), los desarrolladores no comienzan la implementación hasta haber terminado los requisitos, y el diseño. Informan de un buen progreso en la implementación porque no tienen construcciones intermedias que les indiquen otra cosa. Los problemas están aún ocultos bajo tierra hasta que la integración y las pruebas los descubran todos a la vez (Explosión del Diseño Tardío). En el desarrollo iterativo, la implementación comienza más al principio y las construcciones frecuentes no sólo descubren pronto los problemas, sino que también los solucionan en pequeños lotes más fáciles de manejar.


Conseguir un aprendizaje temprano

Conseguir un aprendizaje temprano

  • Después de un par de iteraciones, todas las personas del equipo tienen una buena comprensión de lo que significan los diferentes flujos de trabajo.

  • Saben lo que viene después de los requisitos y lo que viene después del análisis.

  • Se reduce en gran medida el riesgo de “parálisis del análisis” (demasiado tiempo gastado en el análisis).

  • Además, es fácil formar a gente nueva debido a que pueden formarse con el propio trabajo.

  • El proyecto no está forzado a diseñar proyectos piloto especiales sólo para que la gente entienda qué es el proceso.

  • Pueden comenzar directamente con el trabajo real.


Conseguir un aprendizaje temprano1

Conseguir un aprendizaje temprano

  • Dado que han recibido la formación adecuada y que trabajan con alguien que ya lo ha hecho antes, rápidamente se ajustan a la velocidad adecuada.

  • Si alguien nuevo no consigue entender algo o comete un error, su fallo no es crítico para el progreso a largo plazo del proyecto, debido a que se revela en el siguiente intento de hacer una construcción.

  • El método iterativo también ayuda al proyecto a tratar los riesgos de naturaleza no técnica, como los riesgos de la organización. Por ejemplo, puede que los desarrolladores no aprendan suficientemente rápido:

  • A construir aplicaciones utilizando un objectrequestbroker.

  • A utilizar las herramientas de prueba de gestión de la configuración (Apéndice C).

  • A trabajar de acuerdo al proceso de desarrollo de software.


Conseguir un aprendizaje temprano2

Conseguir un aprendizaje temprano

  • A medida que itera un proyecto, un grupo pequeño se pone al día con esas tecnologías, herramientas y procesos nuevos.

  • En las siguientes iteraciones, a medida que el grupo las utiliza más, adquiere más habilidad.

  • El equipo va creciendo gradualmente a medida que el proyecto pasa por las iteraciones, quizá empezando con unas 5 a 10 personas, pasando a 25, y finalmente a unas 100 personas.

  • A medida que el grupo va creciendo paso a paso, el equipo inicial está dis­ponible para tutelar a los nuevos miembros que suben a bordo.

  • El método iterativo permite al equipo inicial ajustar el proceso y las herramientas antes de que la mayoría de los desarrolladores se unan al equipo.


Conseguir un aprendizaje temprano3

Conseguir un aprendizaje temprano

  • Mediante el trabajo dividido en fases e iteraciones, los desarrolladores son más capaces de cumplir con las necesidades reales de los clientes y de reducir los riesgos.

  • Mediante la construcción por incrementos, todos los implicados pueden observar su nivel de progreso.

  • Mediante la reducción de los problemas de última hora, aceleran el tiempo de salida al mercado.

  • Es más, este método iterativo es beneficioso, no sólo para los desarrolladores, y fundamentalmente para los clientes, sino también para los directores.

  • Los directores pueden notar el verdadero avance fijándose en las iteraciones terminadas.

Regresar


  • Login