UNIDAD III. IMPLEMENTACIN

3.1. Elaboracin de un programa de implementacin.

Despus del diseo detallado del proyecto, el paso siguiente es elaborar un plan de implementacin del mismo. Algunos clientes solicitan esto como parte del contrato del proyecto, y entregan una planilla para ello. Independientemente si es o no solicitado por el cliente, la elaboracin de un plan de implementacin es un paso importante en la gestin de un proyecto.

3.1.1. Objetivo.

Son las metas o fines que se desean alcanzar con la realizacin del programa, los objetivos que se establezcan deben ser determinados como resultado de la adecuada estimacin de problemas y recursos, y deben ser precisos, cuantificables y alcanzables. Los objetivos se dividen en medios e mediatos segn la posibilidad de alcanzarse a largo o corto plazo. Unos y otros deben estar ligados entre s y para el logro de los mediatos es menester haber logrado los inmediatos.

3.2. Desarrollo del software basado en procesos giles.El ciclo o proceso de desarrollo de sistemas de informacin a lo largo de los aos ha madurado considerablemente, aprendiendo de los errores del pasado e incorporando cada da mejores prcticas y herramientas en pro de la satisfaccin del cliente, que es el objetivo final de cualquier proyecto.Dentro de esta lnea de crecimiento y madurez existe como punta de lanza dentro de las metodologas usadas, las metodologas llamadas giles. Por lo cual se entiende como Desarrollo gil de Software a un paradigma de Desarrollo de Software basado en procesos giles. Los procesos giles de desarrollo de software, conocidos anteriormente como metodologas livianas, intentan evitar los tortuosos y burocrticos caminos de las metodologas tradicionales enfocndose en la gente y los resultados.Existen mltiples tendencias, filosofas, metodologas, herramientas y dems aspectos que pretenden ofrecer una gua para el desarrollo de proyectos de tecnologa de informacin, sin embargo cada uno se puede o no aplicar dependiendo del contexto del proyecto, la empresa y en definitiva de todos los stakeholders (interesados) y las circunstancias del producto; es por ello que es imprescindible conocer y manejar los conceptos asociados con las herramientas giles del rea de TI.

3.2.1. Definicin de procesos giles.

Las Metodologas giles o ligeras constituyen un nuevo enfoque en el desarrollo de software, mejor aceptado por los desarrolladores de e-projects que las metodologas convencionales (ISO-9000, CMM, etc) debido a la simplicidad de sus reglas y prcticas, su orientacin a equipos de desarrollo de pequeo tamao, su flexibilidad ante los cambios y su ideologa de colaboracin.

3.2.2. Modelos giles de procesos.

La diferencia inmediata de las metodologas agiles y las ingenieriles consiste en que estas son menos orientados al documento, exigiendo una cantidad ms pequea de documentacin para una tarea dada. De muchas maneras son ms bien orientados al cdigo: siguiendo un camino que dice que la parte importante de la documentacin es el cdigo fuente.Predictivo versus AdaptableSeparacin de Diseo y Construccin

Para empezar a reconocer el diseo de la construccin debemos saber Qu forma toma este plan? Para muchos, ste es el papel de notaciones de diseo como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construccin y entonces podemos dar planes a los programadores como una actividad de construccin.Pero aqu surgen preguntas cruciales. Es posible armar un plan que sea capaz de convertir el cdigo en una actividad de construccin predecible? Y en tal caso, es la construccin suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?Todo esto trae a la mente ms preguntas. La primera es la cuestin de cun difcil es conseguir un diseo UML en un estado que pueda entregarse a los programadores. El problema con un diseo tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programacin. Los modelos que los ingenieros civiles usan est basado en muchos aos de prctica guardados en cdigos ingenieriles. Adems los problemas importantes, como el modo en que juegan las fuerzas, son dciles al anlisis matemtico. La nica verificacin que podemos hacer con los diagramas UML es la revisin cuidadosa. Mientras esto es til trae errores al diseo que slo se descubren durante la codificacin y pruebas. Incluso los diseadores experimentados, se sorprenden a menudo cuando convierten dichos diseos en software.Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construccin. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Steve McConnell [2] sugiere que para un proyecto grande, slo 15% del proyecto son cdigo y pruebas unitarias, una inversin casi perfecta de las proporciones de la construccin del puente. Aun cuando se consideren las pruebas parte de la construccin, el plan es todava 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseo en software comparado con su papel en otras ramas de la ingeniera.Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el cdigo fuente es un documento de diseo y que la fase de construccin est en realidad en la compilacin y el ligado. De hecho cualquier cosa que pueda tratarse como construccin puede y debe automatizarse.Estas ideas llevan a algunas conclusiones importantes: En software la construccin es tan barata que es casi gratis. En software todo el esfuerzo est en el diseo, de modo que requiere de personas creativas y talentosas. Los procesos creativos no se planean fcilmente, de modo que la previsibilidad bien puede ser una meta imposible. Debemos ser muy cautos al usar la metfora de la ingeniera tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente.

La Impredecibilidad de los Requisitos

Hay un dicho que se oye en cada proyecto problemtico. Los desarrolladores vienen y me dicen "el problema con este proyecto es que los requisitos cambian todo el tiempo". Lo sorprendente de esta situacin es que sorprenda a cualquiera. En el negocio de construccin de software los cambios en los requisitos son la norma, la pregunta es qu hacemos al respecto.Una forma es tratar los requisitos cambiantes como el resultado de una pobre ingeniera de requisitos. La idea detrs de la ingeniera de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software, conseguir la firma del cliente sobre estos requisitos, y entonces preparar procedimientos que limiten los cambios de requisitos despus de la firma.Un problema con esto es que simplemente tratar de entender las opciones para los requisitos es duro. Es aun ms duro porque la organizacin del desarrollo normalmente no proporciona la informacin del costo en los requisitos. El cliente termina solicitando algo que el vendedor no puede cotizar con exactitud. Sin una buena idea del costo, cmo puede el cliente decidir si quiere pagar por ese pedido?La estimacin es difcil por muchas razones. En parte porque el desarrollo de software es una actividad de diseo, difcil de planear y costear. En parte porque los materiales bsicos cambian rpidamente. En parte por lo mucho que depende de los individuos involucrados, y los individuos son difciles de predecir y cuantificar.La naturaleza intangible del software tambin afecta. Es muy difcil saber qu valor aporta un rasgo de software hasta que se usa en realidad. Slo cuando se usa realmente una versin temprana de algn software se empieza a entender cules rasgos son valiosos y cules no.Esto lleva al punto irnico de que es de esperarse que los requisitos sean cambiables. Despus de todo se supone que el software es "suave". As no slo son cambiables los requisitos, sino que deben de serlo. Toma mucha energa conseguir que los clientes de software corrijan los requisitos. Es aun peor si ellos han estado alguna vez en desarrollo de software, porque entonces "saben" que el software es fcil de cambiar.Pero aun cuando se pudiera controlar todo esto y realmente se pudiera conseguir un conjunto exacto y estable de requisitos, probablemente an no estamos a salvo. En la economa de hoy las fuerzas de negocios fundamentales cambian el valor de los rasgos de software demasiado rpidamente. El que podra ser un buen conjunto de requisitos ahora, no ser tan bueno en seis meses. An cuando el cliente pueda corregir sus requisitos, el mundo de negocios no va a detenerse por l. Y muchos cambios en el mundo de negocios son completamente imprevisibles: cualquiera que diga otra cosa est mintiendo, o ya ha hecho mil millones en la bolsa de valores.Casi todo en el desarrollo de software depende de los requisitos. Si no se pueden obtener requisitos estables no se puede obtener un plan predecible.

Es Imposible la Previsibilidad?

En general, no. Uno de los grandes peligros es pretender que se puede seguir un proceso predecible cuando no se puede. La gente que trabaja en metodologas no es buena en identificar condiciones lmite: los lugares donde la metodologa pasa de apropiada en inapropiada. La mayora de los metodologistas quieren que sus metodologas sean usadas por todos, de modo que no entienden ni publican sus condiciones lmite. Esto lleva a la gente a usar una metodologa en malas circunstancias, como usar una metodologa predictiva en una situacin imprevisible.Hay una tentacin fuerte para hacer eso. La previsibilidad es una propiedad muy deseable. No obstante creer que se puede ser predecible cuando no se puede, lleva a situaciones en donde las personas construyen un plan temprano, y entonces no pueden manejar la situacin cuando el plan se cae en pedazos. Usted acaba viendo el plan y la realidad flotando aparte. Durante algn tiempo usted podr pretender que el plan es vlido. Pero en algn punto la deriva es demasiada y el plan se cae en pedazos. Normalmente la cada es dolorosa.As si usted est en una situacin impredecible no puede usar una metodologa predictiva. se es un golpe duro. Significa que tantos modelos para controlar proyectos, y muchos de los modelos para llevar la relacin con el cliente, ya no son ciertos. Los beneficios de la previsibilidad son tan grandes, que es difcil dejarlos ir. Como en tantos problemas la parte ms difcil est simplemente en comprender que el problema existe.De cualquier modo dejar ir la previsibilidad no significa que hay que volver al caos ingobernable. Ms bien hace falta un proceso que pueda dar control sobre la imprevisibilidad. De eso se trata la adaptabilidad.

Controlando un Proceso Imprevisible Iteraciones

As que cmo nos controlamos en un mundo imprevisible? La parte ms importante y difcil, es saber con precisin dnde estamos. Necesitamos un mecanismo honesto de retroalimentacin que pueda decirnos con precisin cul es la situacin a intervalos frecuentes.La llave para obtener esta retroalimentacin es el desarrollo iterativo. Esta no es una idea nueva. El desarrollo iterativo ha estado durante algn tiempo bajo muchos nombres: incremental, evolutivo, escenificado, espiral... muchos nombres. La clave del desarrollo iterativo es producir frecuentemente versiones que funcionen del sistema final que tengan un subconjunto de los rasgos requeridos. stos sistemas son cortos en funcionalidad, pero por otra parte deben ser fieles a las demandas del sistema final. Deben ser totalmente integrados y tan cuidadosamente probados como una entrega final.El punto es que no hay nada como un sistema probado, integrado para traer una dosis poderosa de realidad en cualquier proyecto. Los documentos pueden esconder toda clase de fallas. El cdigo no probado puede esconder bastantes defectos. Pero cuando las personas realmente se sientan delante de un sistema y trabajan con l, entonces las fallas se vuelven aparentes: tanto las relativas a defectos como las relativas a los requisitos mal entendidos.El desarrollo iterativo tambin tiene sentido en los procesos predictivos. Pero es esencial en los procesos adaptables porque un proceso adaptable necesita poder tratar con los cambios en los rasgos requeridos. Esto lleva a un estilo de planear donde los planes a largo plazo son muy fluidos, y los nicos planes estables son a corto plazo hechos para una sola iteracin. El desarrollo iterativo da un fundamento firme en cada iteracin que puede usarse para basar los planes posteriores.Una pregunta importante es cunto debe durar una iteracin. Diferentes personas dan respuestas diferentes. XP sugiere iteraciones de entre una y tres semanas. SCRUM sugiere un mes. Crystal estira aun ms. La tendencia, de cualquier modo, es hacer cada iteracin tan corta como se pueda manejar. Esto proporciona la retroalimentacin ms frecuente, as que usted sabe ms a menudo donde se encuentra.

El Cliente Adaptable

Este tipo de proceso adaptable requiere un tipo diferente de relacin con el cliente que las que se consideran a menudo, particularmente cuando el desarrollo es hecho por otra empresa. Cuando contrate una empresa separada para hacer el desarrollo del software, la mayora de los clientes preferirn un contrato a precio fijo. Dgale a los desarrolladores lo que quieren, negocie, acepte una oferta, y entonces la carga queda en la empresa de desarrollo para construir el software.Un contrato a precio fijo requiere requisitos estables y por tanto procesos predictivos. Los procesos adaptables y los requisitos inestables implican que no se puede trabajar con la nocin usual de precio fijo. Tratar de encajar un modelo de precio fijo a un proceso adaptable acaba en una explosin muy dolorosa. La parte sucia de esta explosin es que el cliente queda herido tanto como la compaa de desarrollo de software. Despus de todo el cliente no querra un software a menos que su negocio lo necesitara. Si no lo consigue su negocio sufre. As aun cuando no pague nada a la compaa de desarrollo, todava pierde. De hecho pierde ms de lo que pagara por el software (por qu habra de pagar el software si el valor comercial de ese software fuera menor?).De modo que hay peligro para ambos lados al firmar un contrato a precio fijo en condiciones donde un proceso predictivo no puede usarse. Esto significa que el cliente tiene que trabajar de otro modo.Esto no significa que no se pueda fijar un presupuesto para software por adelantado. Lo que significa es que no se puede fijar el tiempo, precio y alcance. La manera gil usual es fijar tiempo y precio y permitir que el alcance vare de manera controlada.En un proceso adaptable el cliente tiene mucho control a escala fina sobre el proceso de desarrollo de software. A cada iteracin puede tanto verificar el progreso como alterar la direccin del desarrollo de software. Esto lleva a una relacin mucho ms ntima con los desarrolladores de software, una verdadera sociedad de trabajo. Este nivel de compromiso no es para cualquier organizacin cliente, ni para cualquier desarrollador de software; pero es esencial para lograr que un proceso adaptable funcione apropiadamente.El beneficio importante para el cliente es un desarrollo de software mucho ms sensible. Un sistema usable, aunque mnimo, puede entrar en produccin pronto. El cliente puede cambiar sus capacidades de acuerdo a los cambios en el negocio, y tambin aprender cmo se usa el sistema en realidad.Una pieza tan importante como sta es una visibilidad mayor sobre el verdadero estado del proyecto. El problema con los procesos predictivos es que la calidad del proyecto se mide por la conformidad con el plan. Esto dificulta a la gente sealar cundo la realidad y el plan divergen. El resultado comn es un gran resbaln ms tarde en el calendario del proyecto. En un proyecto gil hay un constante rehacer del plan con cada iteracin. Si las malas noticias estn al acecho, tienden a aparecer ms temprano, cuando aun se puede hacer algo al respecto. De hecho este control del riesgo es una ventaja clave del desarrollo iterativo. Los mtodos giles van ms all manteniendo corta la duracin de la iteracin, pero tambin viendo estas variaciones como oportunidades.Hay un aspecto importante en lo que constituye un proyecto exitoso. Un proyecto predictivo se mide a menudo por lo bien que coincide con el plan. Un proyecto que est a tiempo y en costo es un xito. Esta medida no tiene sentido en un ambiente gil. Para el agilista la cuestin es el valor de negocio (beneficio) que el cliente consiga, es decir, un software ms valioso que el costo que puso en l. Un buen proyecto predictivo ir de acuerdo al plan, un buen proyecto gil construir algo diferente y mejor que lo que se esperaba en el plan original.

Poniendo a la Gente Primero

No es fcil ejecutar un proceso adaptable. En particular requiere un equipo muy eficaz de desarrolladores. El equipo necesita ser eficaz tanto en la calidad de los individuos como en la manera en que funcionan juntos en equipo. Hay tambin una sinergia interesante: no slo la adaptabilidad requiere un equipo fuerte, la mayora de los buenos desarrolladores prefieren un proceso adaptable.

Juntar Unidades de Programacin Compatibles

Uno de los objetivos de las metodologas tradicionales es desarrollar un proceso donde las personas involucradas sean partes reemplazables. Con tal proceso se puede tratar a las personas como recursos que estn disponibles en varios tipos. Se tienen un analista, algunos programadores, algunos verificadores, un gerente. Los individuos no son tan importantes, slo los roles lo son. De esa manera si usted planea un proyecto no importa qu analista y qu verificadores consiga, slo hay que saber cuntos son para saber cmo afecta su plan el nmero de recursos.Pero esto plantea una pregunta clave: son las personas involucradas en el desarrollo de software partes reemplazables? Uno de los rasgos importantes de los mtodos giles es el rechazo a esta afirmacin.Quizs el rechazo ms explcito a las personas como recursos lo hace Alistair Cockburn. En su artculo Caracterizacin de las Personas como Componentes No Lineales de Primer Orden en el Desarrollo de Software [3], apunta a que los procesos predecibles requieren componentes que se comporten de manera predecible. Sin embargo las personas no son componentes predecibles. Adems sus estudios de proyectos de software lo han llevado a concluir que la gente es el factor ms importante en el desarrollo de software.En el ttulo de su artculo se refiere a las personas como "componentes". As es como se trata a la gente en la literatura de diseo de procesos / metodologas. El error de este enfoque es que las "personas" son altamente inconstantes y no lineales, con modos nicos de xito y fracaso. Esos factores son de primer orden, factores no despreciables. El fracaso de los diseadores de procesos y metodologas para responder a esto contribuye a la clase de trayectorias de proyectos no planeados que vemos a menudo.Uno se pregunta si la naturaleza del desarrollo de software funciona contra uno aqu. Cuando programamos una computadora, controlamos un dispositivo inherentemente predecible. Como estamos en este negocio porque somos buenos en hacerlo, estamos idealmente hechos para perturbarnos cuando nos enfrentamos con seres humanos.Aunque Alistair Cockburn es el ms explcito en su visin centrada en la gente del desarrollo de software, la nocin de que la gente es primero es un tema comn para muchos pensadores del software. El problema, demasiado a menudo, es que la metodologa se ha opuesto a la nocin de las personas como el factor de primer orden en el xito del proyecto.Esto crea un fuerte efecto de retroalimentacin positiva. Si usted espera que todos sus desarrolladores se junten en unidades de programacin compatibles, no intentar tratarlos como individuos. Esto baja la moral (y la productividad). Las personas capaces se buscarn un lugar mejor donde estar, y usted acabar con lo que usted deseaba: unidades de programacin compatibles.Decidir que las personas son primero es una gran decisin, que requiere mucha determinacin. La nocin de la gente como recursos es profundamente inculcado en el pensamiento de negocios, teniendo sus races en el impacto del enfoque de La Direccin Cientfica de Frederick Taylor. En la administracin de una fbrica, este enfoque Taylorista tiene sentido. Pero para un trabajo altamente creativo y profesional, como creo es el desarrollo de software, esto no se sostiene. (Y de hecho la fabricacin moderna tambin se est saliendo del modelo Taylorista).

Los Programadores son Profesionales Responsables

Una parte clave de la nocin Taylorista es que la gente que hace el trabajo no es la mejor gente para entender la mejor manera de hacer el trabajo. En una fbrica esto puede ser verdad por varias razones. En parte porque la mayora de los obreros no son las personas ms inteligentes o creativas, en parte porque hay una tensin entre la gerencia y los obreros en que la gerencia gana ms dinero y los obreros menos.La historia reciente nos demuestra cada vez ms lo falso que es esto en el desarrollo de software. A las personas brillantes y capaces les atrae cada vez ms el desarrollo de software, tanto por su ostentacin como por ganancias potencialmente mayores. (Ambas razones me tentaron a salir de la ingeniera electrnica). Cosas tales como opciones accionarias afirman el inters de los programadores en la compaa.Aqu bien puede haber un efecto generacional. Una evidencia anecdtica me hace preguntarme si ms gente brillante se han aventurado en el desarrollo de software en los ltimos diez aos. En ese caso sta sera una razn para ese culto a la juventud en el negocio de la computacin, como en la mayora de los cultos se necesita un grano de verdad en l.Cuando se quiere contratar y retener a gente capaz, hay que reconocer que son profesionales competentes. Como tales son los mejores para decidir cmo dirigir su trabajo tcnico. La nocin Taylorista de un departamento de planificacin separado que decide cmo hacer las cosas slo funciona si los planificadores entienden mejor cmo hacer bien el trabajo que aquellos que lo hacen. Si usted tiene personas brillantes, motivadas que hacen bien el trabajo entonces eso no se sostiene.

Manejando un Proceso Orientado a la Gente

La orientacin a la gente se manifiesta de varias maneras diferentes en los procesos giles, lo que lleva a efectos diferentes, no todos consistentes.Uno de los elementos clave es la aceptacin de un proceso en lugar de la imposicin de un proceso. A menudo los procesos de software se imponen desde la gerencia. Como tales se les resiste a menudo, particularmente cuando la gerencia ha estado fuera del desarrollo activo un buen tiempo. Aceptar un proceso requiere compromiso, y como tal se necesita el involucramiento activo de todo el equipo.Esto termina con el resultado interesante de que slo los desarrolladores pueden escoger seguir un proceso adaptable. Esto es particularmente cierto para la XP, que requiere mucha disciplina para ejecutarse. Aqu es donde Crystal es un complemento efectivo ya que apunta a una disciplina mnima.Otro punto es que los desarrolladores deben poder tomar todas las decisiones tcnicas. XP llega al corazn de esto cuando en su proceso de planeacin establece que slo los desarrolladores pueden estimar cunto tiempo tomar hacer un trabajo.Tal liderazgo tcnico es un gran cambio para muchas personas en posiciones gerenciales. Tal acercamiento requiere compartir una responsabilidad donde desarrolladores y gerencia tienen un mismo lugar en la direccin del proyecto. Ntese que dije igual. La gerencia aun juega un papel, pero reconoce la pericia de los desarrolladores.Una razn importante para esto es el ritmo del cambio de tecnologa en nuestra industria. Despus de unos aos el conocimiento tcnico se vuelve obsoleto. Esta vida media de habilidades tcnicas no tiene parangn en cualquier otra industria. Incluso los tcnicos tienen que reconocer que entrar a la gerencia significa que sus habilidades tcnicas se marchitarn rpidamente. Los exdesarrolladores necesitan reconocer que sus habilidades tcnicas desaparecern rpidamente y necesitan confiar y depender en los desarrolladores actuales.

La Dificultad de Medir

Si usted tiene un proceso donde las personas que dicen cmo hacer el trabajo son distintas de las personas que realmente lo hacen, los lderes necesitan alguna manera de medir cun eficaces son los que lo hacen. En la Direccin Cientfica haba un impulso fuerte a desarrollar formas objetivas de medir el rendimiento de las personas.Esto es particularmente pertinente al software debido a la dificultad de aplicar medidas al software. A pesar de nuestros mejores esfuerzos somos incapaces de medir las cosas ms simples sobre el software, como la productividad. Sin buenas medidas para estas cosas, cualquier clase de control externo est condenado.La introduccin de gestin medida sin buenas medidas tiene sus propios problemas. Robert Austin [4] hizo una discusin excelente sobre esto. l seala que cuando se mide el rendimiento usted tienen que conseguir todos los factores importantes bajo medida. Cualquier cosa que se olvide tiene el resultado inevitable que los hacedores alterarn lo que hacen para producir las mejores medidas, incluso si eso claramente reduce la verdadera efectividad de lo que hacen. Este trastorno de la medida es el taln de Aquiles de la gestin basada en medidas.La conclusin de Robert Austin es que usted tiene que escoger entre la gestin basada en mtricas y la gestin delegatoria (donde los hacedores deciden cmo hacer el trabajo). La gestin basada en mtricas es ms adecuada para el trabajo simple repetitivo, con bajos requisitos de conocimiento y rendimientos fcilmente medibles - exactamente lo contrario al desarrollo de software.El punto de todo esto es que los mtodos tradicionales han operado bajo la asuncin de que la gestin basada en mtricas es la manera ms eficaz de administrar. La comunidad gil reconoce que las caractersticas del desarrollo de software son tales que la gestin basada en mtricas lleva el trastorno de la medida a niveles muy altos. Es realmente ms eficaz usar un estilo delegatorio de administracin, que es el tipo de acercamiento central del punto de vista agilista.

El Papel del Liderazgo de Negocio

Pero los tcnicos no pueden hacer el proceso entero ellos solos. Necesitan una gua en las necesidades del negocio. Esto lleva a otro aspecto importante de los procesos adaptables: necesitan un contacto muy ntimo con los expertos del negocio.Esto va ms all del compromiso de negocios en la mayora de los proyectos. Los equipos giles no pueden existir con una comunicacin ocasional. Necesitan un acceso continuo a los expertos del negocio. Adems este acceso no es algo que se maneje a nivel gerencial, es algo que est presente para cada desarrollador. Como los desarrolladores son profesionales capaces en su propia disciplina, pueden trabajar como iguales con otros profesionales de otras disciplinas.Gran parte de esto, claro est, se debe a la naturaleza del desarrollo adaptable. Como la premisa entera del desarrollo adaptable es que las cosas cambian rpidamente, se necesita un contacto constante para avisar a todos de los cambios.No hay nada ms frustrante para un desarrollador que ver desperdiciarse su duro trabajo. As que es importante asegurar que hay pericia de negocios de buena calidad que est disponible al desarrollador y de calidad suficiente para que el desarrollador pueda confiar en ella.

El Proceso Auto-Adaptable

Hasta ahora he hablado sobre la adaptabilidad en el contexto de un proyecto adaptando frecuentemente su software para enfrentarse a los requisitos cambiantes de sus clientes. No obstante hay otro ngulo de la adaptabilidad: el del proceso que cambia con el tiempo. Un proyecto que empieza usando un proceso adaptable no tendr el mismo proceso un ao despus. Con el tiempo, el equipo encontrar lo que funciona mejor para ellos, y alterar el proceso a su medida.La primera parte de la auto adaptabilidad son las revisiones regulares del proceso. Normalmente se hacen con cada iteracin. Al final de cada iteracin, haga una reunin corta y hgase las siguientes preguntas (escogidas de Norm Kerth [5]) Qu hicimos bien? Qu hemos aprendido? Qu podemos hacer mejor? Qu es lo que nos confunde? Estas preguntas traern ideas para cambiar el proceso en la siguiente iteracin. De esta manera un proceso que empieza con problemas puede mejorar conforme el proyecto avanza, adaptndose mejor al equipo que lo usa.Si la auto adaptabilidad ocurre dentro de un proyecto, es aun ms marcada en una organizacin. Para ahondar el proceso de la auto adaptabilidad sugiero que los equipos hagan una revisin ms formal e hitos del proyecto mayores siguiendo las sesiones retrospectivas del proyecto esbozadas por Norm Kerth. Estas retrospectivas involucran reuniones de 2-3 das y un facilitador entrenado. Ellas no solo dan aprendizaje al equipo, tambin dan aprendizaje a la organizacin entera.Una consecuencia de la auto adaptabilidad es que nunca se debe esperar encontrar una metodologa corporativa nica. En cambio cada equipo debe no simplemente escoger su propio proceso, debe tambin afinar activamente su proceso conforme avanza el proyecto. Mientras que tanto los procesos publicados como la experiencia de otros proyectos pueden actuar como una inspiracin y una lnea de fondo, la responsabilidad profesional de los desarrolladores es adaptar el proceso a la tarea en mano.Esta auto adaptabilidad es muy marcada en ASD y Crystal. Las reglas rgidas de la XP parecen desaprobarla, pero sa es slo una impresin superficial ya que la XP anima a la gente a afinar el proceso. La diferencia principal de la XP es que sus promotores sugieren hacer XP al pie de la letra por varias iteraciones antes de adaptarlo. Adems las revisiones no son enfatizadas, ni parte del proceso, aunque hay sugerencias de que las revisiones deberan ser una de las prcticas de la XP.

Las Metodologas giles valoran:

En la Alianza gil [6] establecen como valores de los MA:1. Al individuo y las interacciones en el equipo de desarrollo ms que a las actividades y las herramientas.2. Desarrollar software que funciona ms que conseguir una buena documentacin, implica minimalismo respecto del modelado y la documentacin del sistema.3. La colaboracin con el cliente ms que la negociacin de un contrato.4. Responder a los cambios ms que seguir estrictamente una planificacin.

Por qu surgen las Metodologas giles?

En [7] se destacan los siguientes puntos como los principales motivos de surgimiento de los MA:1. Dificultad para implantar metodologas tradicionales. Sofisticadas herramientas CASE y notaciones (UML)2. Una solucin a medida para un segmento importante de proyectos de desarrollo de software 3. Pugna entre comunidades / gures4. Aceptar el cambio

Costo de los Cambios en la Construccin de SW

costo del cambiotiempometodologa tradicionalsuposicinmetodologa gilDe [7] se pudo extraer la Figura 1 que se muestra a continuacin. En la misma se muestra el costo de producir cambios en el software que se desarrolla mediante una metodologa tradicional versus el costo de producir cambios en el software que se desarrolla mediante alguna de las metodologas giles. Como se puede apreciar, a medida que avanza el tiempo, el costo es exponencial en el caso de la construccin mediante una metodologa tradicional.

Figura 1: Funcin de costos de cambio en el software desarrollado

Manifiesto de las Metodologas giles

El manifiesto fue slo eso, una publicacin que actu como un punto de partida para aquellos que compartan estas ideas bsicas. Uno de los frutos del esfuerzo fue la creacin de un cuerpo ms longevo, la Alianza gil [6]. La Alianza gil es una organizacin sin fines de lucro que busca promover el conocimiento y la discusin de todos los mtodos giles. Muchos de los lderes de metodologas de desarrollo de software giles son miembros y lderes de la Alianza gil.Los principios que se establecieron en el manifiesto son:1. La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor.2. Dar la bienvenida a los cambios. Los MA capturan los cambios para que el cliente tenga una ventaja competitiva.3. Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente.4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.5. Construir el proyecto entorno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir el trabajo.6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo.7. El software que funciona es la medida principal de progreso.8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante.9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.10. La simplicidad es esencial.11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos.12. En intervalos regulares, el equipo reflexiona respecto de cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

Comparacin gil no gil

Metodologa gilMetodologa No gil (Tradicional)

Pocos artefactosMs artefactos

Pocos rolesMs roles

No existe un contrato tradicional o al menos es bastante flexibleExiste un contrato prefijado

El cliente es parte del equipo de desarrollo (adems in-situ)El cliente interacta con el equipo de desarrollo mediante reuniones

Grupos pequeos (< 10 integrantes) y trabajando en el mismo sitioGrupos grandes

Menos nfasis en la arquitecturaLa arquitectura es esencial

Las Metodologas1. Programacin Extrema (XP)

De todas las metodologas giles, sta es la que ha recibido ms atencin. Esto se debe en parte a la notable habilidad de los lderes XP, en particular Kent Beck, para llamar la atencin. Tambin se debe a la habilidad de Kent Beck de atraer a las personas a este acercamiento, y tomar un papel principal en l. De algunas maneras, sin embargo, la popularidad de XP se ha vuelto un problema, pues ha acaparado la atencin fuera de las otras metodologas y sus valiosas ideas.Las races de XP yacen en la comunidad de Smalltalk, y en particular la colaboracin cercana de Kent Beck y Ward Cunningham a finales de los 80. Ambos refinaron sus prcticas en numerosos proyectos a principios de los 90, extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente.El paso crucial de la prctica informal a una metodologa ocurri en la primavera de 1996. A Kent Beck se le pidi revisar el progreso del proyecto de nmina C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por una compaa contratista, y estaba en problemas. Debido a la baja calidad de la base del cdigo, Kent Beck recomend tirar la base del cdigo en su totalidad y empezar desde el principio. El proyecto entonces reinici bajo su direccin y subsecuentemente se volvi el buque insignia temprano y el campo de entrenamiento de XP.La primera fase del C3 fue muy exitosa y comenz a principios de 1997. El proyecto continu desde entonces y despus se encontr con dificultades, lo que result en la cancelacin del desarrollo en 1999. (Lo cual prueba, sin ninguna otra cosa, que XP no es garanta de xito.)La metodologa XP empieza con cuatro valores [10]: Comunicacin, Retroalimentacin, Simplicidad, y Coraje. Construye sobre ellos una docena de prcticas que los proyectos XP deben seguir. Muchas de estas prcticas son tcnicas antiguas, tratadas y probadas, aunque a menudo olvidadas por muchos, incluyendo la mayora de los procesos planeados. Adems de resucitar estas tcnicas, XP las teje en un todo sinrgico donde cada una refuerza a las dems.Una de las ms llamativas, as como inicialmente atractiva, es su fuerte nfasis en las pruebas. Mientras todos los procesos mencionan la comprobacin, la mayora lo hace con muy poco nfasis. Sin embargo XP pone la comprobacin como el fundamento del desarrollo, con cada programador escribiendo pruebas cuando escriben su cdigo de produccin. Las pruebas se integran en el proceso de integracin continua y construccin lo que rinde una plataforma altamente estable para el desarrollo futuro.En esta plataforma XP construye un proceso de diseo evolutivo que se basa en refactorizar un sistema simple en cada iteracin. Todo el diseo se centra en la iteracin actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseo disciplinado, es ms, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la ms desarrollada de entre todas las metodologas adaptables.XP ha desarrollado un liderazgo amplio, muchos de ellos provenientes del proyecto fundamental C3. Como resultado hay muchas fuentes para ms informacin. Kent Beck escribi Extreme Programming Explained, el manifiesto clave de XP que explica las razones detrs de la metodologa y es bastante amplia como para que la gente pueda saber si se interesan en seguirla. En el ltimo par de aos ha habido una epidemia de libros sobre XP brillantemente coloreados la mayora de los cuales son bastante similares en que describen el proceso entero desde el punto de vista de varios seguidores tempranos.2. La Familia de Crystal de Cockburn

Alistair Cockburn [18] ha estado trabajando en metodologas desde que la IBM le encarg escribir sobre metodologas a inicios de los 90. No obstante, su acercamiento no es como la mayora de los metodologistas. En lugar de partir solamente de su experiencia personal para construir una teora de cmo deben hacerse las cosas, l complementa su experiencia directa con la bsqueda activa de proyectos y ver cmo trabajan. Adems l no teme alterar sus puntos de vista con base en sus descubrimientos.Crystal es una familia porque l cree que los tipos diferentes de proyectos requieren tipos diferentes de metodologas. l mira esta variacin a lo largo de dos ejes: el nmero de personas en el proyecto, y las consecuencias de los errores. Cada metodologa encaja en una parte diferente de la reja, de modo que para un proyecto de 40 personas que puede perder dinero discrecionalmente tiene una metodologa diferente a la de un proyecto vital de seis personas.Crystal comparte con XP una orientacin humana, pero esta centralizacin en la gente se hace de una manera diferente. Alistair Cockburn considera que las personas encuentran difcil seguir un proceso disciplinado, as que ms que seguir la alta disciplina de XP, Alistair Cockburn explora la metodologa menos disciplinada que aun podra tener xito, intercambiando conscientemente productividad por facilidad de ejecucin. l considera que aunque Crystal es menos productivo que XP, ms personas sern capaces de seguirlo.Alistair Cockburn tambin pone mucho peso en las revisiones al final de la iteracin, animando al proceso a ser auto mejorante. Su asercin es que el desarrollo iterativo est para encontrar los problemas temprano, y entonces permitir corregirlos. Esto pone ms nfasis en la gente supervisando su proceso y afinndolo conforme desarrollan.

3. Software de Cdigo Abierto (OSS)

La mayora de los proyectos de cdigo abierto tienen uno o ms mantenedores. Un mantenedor es la nica persona a la que se le permite integrar un cambio en el almacn de cdigo fuente. Sin embargo otras personas pueden hacer cambios a la base del cdigo. La diferencia importante es que estas otras personas necesitan enviar su cambio al mantenedor que entonces lo revisa y lo aplica a la base del cdigo. Normalmente estos cambios son hechos en forma de archivos de parches que hacen este proceso ms fcil. As, el mantenedor es responsable de coordinar los parches y mantener la cohesin en el diseo del software.Proyectos diferentes manejan el papel del mantenedor de diferentes maneras. Algunos tienen un mantenedor para el proyecto entero, algunos lo dividen en mdulos y tiene un mantenedor por mdulo, algunos rolan el mantenedor, algunos tienen mltiples mantenedores sobre el mismo cdigo, otros tienen una combinacin de estas ideas. La mayor parte de la gente de cdigo abierto son de tiempo parcial, as que hay una duda en qu tan bien se coordina un equipo as para un proyecto de tiempo completo.Un rasgo particular del desarrollo de cdigo abierto es que la depuracin es altamente paralelizable. Muchas personas pueden involucrarse en el depurado. Cuando encuentran un defecto pueden enviar el parche al mantenedor. Esto es un buen papel para los no mantenedores ya que la mayor parte del tiempo se gasta en encontrar bugs. Tambin es bueno para gente sin mucha destreza en programacin.El proceso para el cdigo abierto aun no se ha documentado bien. Sin embargo, se trata de una herramienta muy potente que facilita: Registrar todos los cambios efectuados sobre los archivos de un proyecto. Recuperar versiones anteriores del cdigo de un proyecto. Conocer qu cambios se han efectuado sobre un archivo determinado, quin los ha realizado y cundo. Gestionar los conflictos que pueden producirse en entornos en los que los desarrolladores se encuentran distribuidos geogrficamente. El CVS (Concurrent Versions System) es especialmente til cundo ms de una persona trabaja sobre un archivo especfico. En tales situaciones, es posible que un desarrollador sobreescriba accidentalmente los cambios que ha realizado otro desarrollador. CVS resuelve este problema haciendo que cada desarrollador trabaje sobre su propia copia del cdigo (lo que se denomina workspace o espacio de trabajo) y permitiendo posteriormente unir los cambios de todos los desarrolladores en un repositorio comn [24].

4. El Desarrollo de Software Adaptable (ASD) de Highsmith

Jim Highsmith [25] ha pasado muchos aos trabajando con metodologas predictivas. l las desarroll, instal, ense, y concluy que son profundamente defectuosas: particularmente para los negocios modernos.En el corazn del ASD hay tres fases solapadas, no lineales: especulacin, colaboracin, y aprendizaje.Jim Highsmith ve la planificacin como una paradoja en un ambiente adaptable, ya que los resultados son naturalmente imprevisibles. En la planificacin tradicional, las desviaciones del plan son errores que deben corregirse. En un ambiente adaptable, en cambio, las desviaciones nos guan hacia la solucin correcta.En este ambiente imprevisible se necesita que las personas colaboren de la mejor manera para tratar con la incertidumbre. La atencin de la gerencia es menor en lo que tiene que hacer la gente, y mayor sobre la comunicacin alentadora para que las personas puedan proponer las respuestas creativas ellos mismos.En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se ponen de antemano y entonces se sigue ese diseo.En un ambiente adaptable, aprender desafa a todos - desarrolladores y sus clientes - a examinar sus presunciones y usar los resultados de cada ciclo de desarrollo para adaptar el siguiente. El aprendizaje como tal es un rasgo continuo e importante, que asume que los planes y los diseos deben cambiar conforme avanza el desarrollo.El beneficio atropellado, poderoso, indivisible y predominante del Ciclo de Vida de Desarrollo Adaptable es que obliga a confrontar los modelos mentales que estn en la raz del autoengao de las personas. Obliga a las personas a estimar con realismo su habilidad. Con este nfasis, el trabajo de Jim Highsmith se enfoca directamente en fomentar las partes difciles del desarrollo adaptable, en particular cmo fomentar la colaboracin y el aprendizaje dentro del proyecto. Como tal, su libro ayuda a dar ideas para fomentar estas reas "suaves" que hacen un buen complemento a los acercamientos basados en una prctica aterrizada como XP, FDD y Crystal.5. Scrum

Scrum se enfoca en el hecho de que procesos definidos y repetibles slo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles.Scrum divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 das. Antes de que comience una carrera se define la funcionalidad requerida para esa carrera y entonces se deja al equipo para que la entregue. El punto es estabilizar los requisitos durante la carrera.Sin embargo la gerencia no se desentiende durante la carrera corta. Todos los das el equipo sostiene una reunin corta (quince minutos), llamada scrum, dnde el equipo discurre lo que har al da siguiente. En particular muestran a los bloques de la gerencia: los impedimentos para progresar que se atraviesan y que la gerencia debe resolver. Tambin informan lo que se ha hecho para que la gerencia tenga una actualizacin diaria de dnde va el proyecto.La literatura de Scrum se enfoca principalmente en la planeacin iterativa y el seguimiento del proceso. Es muy cercana a las otras metodologas giles en muchos aspectos y debe funcionar bien con las prcticas de cdigo de XP.6. Desarrollo Manejado por Rasgos (FDD)

El Desarrollo Manejado por Rasgos (FDD por su sigla en ingls de Feature-Driven Development) fue desarrollado por Jeff De Luca y el viejo gur de la Orientacin a Objetos Peter Coad. Como las otras metodologas adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran dos semanas.El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto. Desarrollar un Modelo Global Construir una Lista de los Rasgos Planear por Rasgo Disear por Rasgo Construir por Rasgo Los ltimos dos se hacen en cada iteracin. Cada proceso se divide en tareas y se da un criterio de comprobacin.Los desarrolladores entran en dos tipos: dueos de clases, y programadores jefe. Los programadores jefe son los desarrolladores ms experimentados. A ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen solos. Slo identifican qu clases se involucran en la implantacin de un rasgo y juntan a los dueos de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe acta como el coordinador, diseador lder y mentor, mientras los dueos de clases hacen gran parte de la codificacin del rasgo.7. DSDM (Mtodo de Desarrollo de Sistema Dinmico)

El DSDM (Dynamic Systems Development Method) [36] empez en Gran Bretaa en 1994 como un consorcio de compaas del Reino Unido que queran construir sobre RAD (Rapid Applications Development) Desarrollo Rpido de Aplicaciones y desarrollo iterativo. Habiendo empezado con 17 fundadores ahora tiene ms de mil miembros y ha crecido fuera de sus races britnicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros mtodos giles. Tiene una organizacin de tiempo completo que lo apoya con manuales, cursos de entrenamiento, programas de certificacin y dems. Pero, tambin lleva una etiqueta de precio, lo cual ha limitado la investigacin popular sobre su metodologa. Sin embargo, Jennifer Stapleton ha escrito el libro DSDM [37] que da una apreciacin global de la metodologa.El mtodo empieza con un estudio de viabilidad y negocio. El estudio de viabilidad considera si DSDM es apropiado para el proyecto. El estudio de negocio es una serie corta de talleres para entender el rea de negocio donde tiene lugar el desarrollo. Tambin propone esbozos de arquitecturas del sistema y un plan del proyecto.El resto del proceso forma tres ciclos entretejidos: el ciclo del modelo funcional produce documentacin de anlisis y prototipos, el ciclo de diseo del modelo disea el sistema para uso operacional, y el ciclo de implantacin se ocupa del despliegue al uso operacional.DSDM tiene principios subyacentes que incluyen una interaccin activa del usuario, entregas frecuentes, equipos autorizados, pruebas a lo largo del ciclo. Igual que otros mtodos giles, usan ciclos de plazos cortos de entre dos y seis semanas. Hay un nfasis en la alta calidad y adaptabilidad hacia requisitos cambiantes.

8. Es RUP un mtodo gil?

Siempre que se discuten mtodos OO, inevitablemente se llega a Rational Unified Process [38]. El Proceso Unificado fue desarrollado como el proceso complementario al UML. El RUP es un armazn de proceso y como tal puede acomodar una gran variedad de procesos. De hecho sta es la crtica principal al RUP por parte de algunos autores: como puede ser cualquier cosa acaba siendo nada. Prefieren un proceso que diga qu hacer en lugar de dar opciones infinitas.Como resultado de esta mentalidad de armazn de procesos, el RUP puede usarse en un estilo muy tradicional de cascada o de una manera gil. Como resultado se puede usar el RUP como un proceso gil, o como un proceso pesado - todo depende de cmo lo adapte a su ambiente.Craig Larman es un fuerte defensor de usar el RUP de una manera gil. Su libro Applying UML and Patterns [39] sobre desarrollo OO contiene un proceso que est muy basado en su pensamiento ligero del RUP. Su visin es que mucho del reciente empujn hacia los mtodos giles no es nada ms que aceptar desarrollo OO de la corriente principal que ha sido capturada como RUP. Una de las cosas que hace Craig Larman es pasarse los primeros dos o tres das de una iteracin mensual con todo el equipo usando el UML para perfilar el diseo del trabajo a hacerse durante la iteracin. Esto no es una norma de la que no pueda desviarse, sino un boceto que da una perspectiva sobre cmo pueden hacerse las cosas en la iteracin.Otra punta en el RUP gil es el proceso dX de Robert Martin [40]. El proceso dX es una versin totalmente dcil del RUP que simplemente es idntico a XP (girar dX ciento ochenta grados para ver la broma). El dX est diseado para gente que tiene que usar el RUP pero quiere usar XP. Como tal es a la vez XP y RUP y por tanto un buen ejemplo del uso gil del RUP.Segn los crticos, una de las cosas claves que necesita el RUP es que los lderes del RUP en la industria enfaticen su acercamiento al desarrollo de software. Ms de una vez se oye a la gente que usa el RUP hablando que estn usando un proceso de desarrollo estilo cascada. Philippe Kruchten y su equipo son firmes creyentes en el desarrollo iterativo. Clarificando estos principios y animando las versiones giles del RUP tales como los trabajos de Craig Larman y de Robert Martin tendr un efecto importante.

9. Lean Development (LD) y Lean Software Development (LSD)

Lean Development (LD) es el mtodo menos divulgado entre los reconocidamente importantes. La palabra lean significa magro, enjuto; este proceso tiene como precepto la eliminacin de residuos a travs de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo ms perfecto posible. Los presentes conceptos han sido extrados de Carlos Reynoso [43].Los procesos a la manera americana corran con sus mquinas al 100% de capacidad y mantenan inventarios gigantescos de productos y suministros; Toyota, en contra de la intuicin, resultaba ms eficiente manteniendo suministros en planta para un solo da, y produciendo slo lo necesario para cubrir las rdenes pendientes. Esto es lo que se llama Just in Time Production. Con JIT se evita adems que el inventario degrade o se torne obsoleto, o empiece a actuar como un freno para el cambio. Toyota implementaba adems las tcnicas innovadoras del Total Quality Management de Edward Deming, que slo algunos matemticos y empresarios de avanzada conocan en Estados Unidos. Hasta el da de hoy la foto de Deming en Toyota es ms grande y esplendorosa que la del fundador, Toyoda Sakichi.Otros aspectos esenciales de Lean Manufacturing son la relacin participativa con el empleado y el trato que le brinda la compaa, as como una especificacin de principios, disciplinas y mtodos iterativos, adaptativos, auto-organizativos e interdependientes en un patrn de ciclos de corta duracin que tiene algo ms que un aire de familia con el patrn de procesos de los Mtodos giles. Existe unanimidad de intereses, consistencia de discurso y complementariedad entre las comunidades Lean de manufactura y desarrollo de software.Mientras que otros MA se concentran en el proceso de desarrollo, Bob Charette sostena que para ser verdaderamente gil se deba conocer adems el negocio de punta a punta. LD se inspira en doce valores centrados en estrategias de gestin [44]:1. Satisfacer al cliente es la mxima prioridad.2. Proporcionar siempre el mejor valor por la inversin.3. El xito depende de la activa participacin del cliente.4. Cada proyecto LD es un esfuerzo de equipo.5. Todo se puede cambiar.6. Soluciones de dominio, no puntos.7. Completar, no construir.8. Una solucin al 80% hoy, en vez de una al 100% maana.9. El minimalismo es esencial.10. La necesidad determina la tecnologa.11. El crecimiento del producto es el incremento de sus prestaciones, no de su tamao.12. Nunca empujes LD ms all de sus lmites.Dado que LD es ms una filosofa de management que un proceso de desarrollo no hay mucho que decir del tamao del equipo, la duracin de las iteraciones, los roles o la naturaleza de sus etapas. ltimamente LD ha evolucionado como Lean Software Development (LSD); su figura de referencia es Mary Poppendieck [45]. Igual que Agile Modeling (AM), que cubra sobre todo aspectos de modelado y documentacin, LD y LSD han sido pensados como complemento de otros mtodos, y no como una metodologa excluyente a implementar en la empresa. LD prefiere concentrarse en las premisas y modelos derivados de Lean Production, que hoy constituyen lo que se conoce como el canon de la Escuela de Negocios de Harvard. Para las tcnicas concretas de programacin, LD promueve el uso de otros MA que sean consistentes con su visin, como XP o sobre todo Scrum.Aunque la formulacin del mtodo es relativamente reciente, la familiaridad de muchas empresas con los principios de Lean Production & Lean Manufacturing ha facilitado la penetracin en el mercado de su anlogo en ingeniera de software.

10. Agile Modeling

Agile Modeling (AM) fue propuesto por Scott Ambler [46] no tanto como un mtodo gil cerrado en s mismo, sino como complemento de otras metodologas, sean stas giles o convencionales. En el caso de XP los practicantes podran definir mejor los procesos de modelado que en ellos faltan, y en el caso de RUP el modelado gil permite hacer ms ligeros los procesos que ya usan. AM es una estrategia de modelado (de clases, de datos, de procesos) pensada para contrarrestar la sospecha de que los mtodos giles no modelan y no documentan. Se lo podra definir como un proceso de software basado en prcticas cuyo objetivo es orientar el modelado de una manera efectiva y gil.Los principales objetivos de AM son:1. Definir y mostrar de qu manera se debe poner en prctica una coleccin de valores, principios y prcticas que conducen al modelado de peso ligero.2. Enfrentar el problema de la aplicacin de tcnicas de modelado en procesos de desarrollo giles.3. Enfrentar el problema de la aplicacin de las tcnicas de modelado independientemente del proceso de software que se utilice.

Los valores de AM incluyen a los de XP: comunicacin, simplicidad, feedback y coraje, aadiendo humildad. Una de las mejores caracterizaciones de los principios subyacentes a AM est en la definicin de sus alcances:1. AM es una actitud, no un proceso prescriptivo. Comprende una coleccin de valores a los que los modeladores giles adhieren, principios en los que creen y prcticas que aplican. Describe un estilo de modelado; no es un recetario de cocina. 2. AM es suplemento de otros mtodos. El primer foco es el modelado y el segundo la documentacin.3. AM es una tarea de conjunto de los participantes. No hay yo en AM.4. La prioridad es la efectividad. AM ayuda a crear un modelo o proceso cuando se tiene un propsito claro y se comprenden las necesidades de la audiencia; contribuye a aplicar los artefactos correctos para afrontar la situacin inmediata y a crear los modelos ms simples que sea posible.5. AM es algo que funciona en la prctica, no una teora acadmica. Las prcticas han sido discutidas desde 2001 en comunidad (http://www.agilemodeling.com/feedback.htm).6. AM no es una bala de plata.7. AM es para el programador promedio, pero no reemplaza a la gente competente.8. AM no es un ataque a la documentacin. La documentacin debe ser mnima y relevante.9. AM no es un ataque a las herramientas CASE.10. AM no es para cualquiera.

Los principios de AM especificados por Scott Ambler incluyen:1. Presuponer simplicidad. La solucin ms simple es la mejor.2. El contenido es ms importante que la representacin. Pueden ser notas, pizarras o documentos formales. Lo que importa no es el soporte fsico o la tcnica de representacin, sino el contenido.3. Abrazar el cambio. Aceptar que los requerimientos cambian.4. Habilitar el esfuerzo siguiente. Garantizar que el sistema es suficientemente robusto para admitir mejoras ulteriores; debe ser un objetivo, pero no el primordial.5. Todo el mundo puede aprender de algn otro. Reconocer que nunca se domina realmente algo.6. Cambio incremental. No esperar hacerlo bien la primera vez.7. Conocer tus modelos. Saber cules son sus fuerzas y sus debilidades.8. Adaptacin local. Producir slo el modelo que resulte suficiente para el propsito.9. Maximizar la inversin del cliente.10. Modelar con un propsito. Si no se puede identificar para qu se est haciendo algo para qu molestarse?11. Modelos mltiples. Mltiples paradigmas en convivencia, segn se requiera.12. Comunicacin abierta y honesta.13. Trabajo de calidad.14. Realimentacin rpida. No esperar que sea demasiado tarde.15. El software es el objetivo primario. Debe ser de alta calidad y coincidir con lo que el usuario espera.16. Viajar ligero de equipaje. No crear ms modelos de los necesarios.17. Trabajar con los instintos de la gente.

Lo ms concreto de AM es su rico conjunto de prcticas [47], cada una de las cuales se asocia a lineamientos decididamente narrativos, articulados con minuciosidad, pero muy lejos de los rigores cuantitativos:1. Colaboracin activa de los participantes.2. Aplicacin de estndares de modelado.3. Aplicacin adecuada de patrones de modelado.4. Aplicacin de los artefactos correctos.5. Propiedad colectiva de todos los elementos.6. Considerar la verificabilidad.7. Crear diversos modelos en paralelo.8. Crear contenido simple.9. Disear modelos de manera simple.10. Descartar los modelos temporarios.11. Exhibir pblicamente los modelos.12. Formalizar modelos de contrato.13. Iterar sobre otro artefacto.14. Modelo en incrementos pequeos.15. Modelar para comunicar.16. Modelar para comprender.17. Modelar con otros.18. Poner a prueba con cdigo.19. Reutilizar los recursos existentes.20. Actualizar slo cuando duele.21. Utilizar las herramientas ms simples (CASE, o mejor pizarras, tarjetas, post-its).Como AM se debe usar como complemento de otras metodologas, nada se especifica sobre mtodos de desarrollo, tamao del equipo, roles, duracin de iteraciones, trabajo distribuido y criticidad, todo lo cual depender del mtodo que se utilice. Los diagramas de UML y los artefactos del Proceso Unificado, por ejemplo, han sido explorados en extremo detalle describiendo cmo debera ser su tratamiento en un proceso gil EUP. EUP es simplemente UP+AM.

11. Pragmatic Programming (PP)

El ttulo en realidad no es totalmente cierto, ya que no hay un mtodo llamado programacin pragmtica, sino que existe un conjunto muy interesante de las mejores prcticas de programacin publicadas en el libro The Pragmatic Programmer [48], pero por practicidad se lo llama Programacin Pragmtica [49].La PP no tiene proceso, fases, roles distintos productos de trabajo. Este MA cubre, sin embargo, la mayora de las mejores prcticas de programacin. Hay un total de 70 recomendaciones que se enfocan en los problemas del da a da, pero la filosofa por detrs de esto es que son universales y pueden ser aplicadas a cualquier fase del desarrollo de software.La filosofa est definida en 6 puntos:1. Tome las responsabilidades para Ud., piense en soluciones en lugar de estar pensando en excusas.2. No disee o codifique mal, arregle las inconsistencias o planee arreglarlas tan pronto como sea posible.3. Tome un rol activo para introducir cambios donde Ud. vea que son necesarios.4. Haga software que satisfaga a su cliente, pero sepa cundo parar.5. Constantemente ample su conocimiento.6. Mejore sus habilidades de comunicacin.Desde un punto de vista gil, la mayora de las prcticas ms interesantes se enfocan sobre el desarrollo iterativo, incremental, testing riguroso y diseo centrado en el usuario. El enfoque tiene un punto de vista muy prctico, y la mayora de las prcticas son ilustradas con ejemplos positivos y negativos, a menudo complementados con preguntas y trocitos de cdigo. Es un esfuerzo considerable explicar cmo disear e implementar software tal que pueda resistir cambios. Una de las soluciones que se plantean para mantener software a travs de los cambios es la refactorizacin.El enfoque de la Programacin Pragmtica respecto del testing consiste en testear el cdigo que est siendo implementado sobre el cdigo real, y todos los testeos deben ser hechos en forma automtica. La idea es que si cada bug corregido no es agregado dentro de la biblioteca del test y si los tests de regresin no se corren peridicamente, el tiempo y el esfuerzo se gastan en encontrar los mismos bugs repetidamente, y los efectos adversos de cambios en el cdigo no pueden detectarse suficientemente temprano.La automatizacin se encuentra en la PP en algunas otras tareas tambin. De hecho llega a sugerir No use procedimientos manuales. Por ejemplo, en la creacin de la primera documentacin de cdigo fuente y en la creacin de cdigo de las definiciones de la base de datos.Recomienda conservar las especificaciones a un nivel razonable de detalle. La PP demuestra prcticas de software simples, responsables y disciplinadas. La prcticas sugeridas en PP son escritas desde el punto de vista de un programador, independientemente de los mtodos o procesos que se utilicen, para evitar errores tpicos en la codificacin y en el diseo y errores de comunicacin en el grupo de trabajo.

Testing Dirigido por el Contexto

Desde el principio han sido los desarrolladores de software quienes han conducido a la comunidad gil. Sin embargo muchas otras personas envueltas en el desarrollo de software son afectadas por este nuevo movimiento. Un grupo obvio es el de los verificadores, que a menudo viven en un mundo dominado por el pensamiento de cascada. Con pautas comunes que declaran que el papel del testing es asegurar la conformidad del software con las especificaciones escritas de antemano, el papel de los verificadores en el mundo gil est lejos de ser claro.Varias personas en la comunidad de verificadores han estado cuestionando mucho la corriente principal del pensamiento en testing desde hace un tiempo.Esto ha llevado a formar un grupo conocido como testing conducido por el contexto.

Debe usted ir a lo gil?

Los prrafos siguientes son extractados de [9].El uso de un mtodo gil no es para todos. Hay que tener en cuenta varias cosas si se decide a seguir por este camino. Sin embargo yo creo ciertamente que estas nuevas metodologas son extensamente aplicables y deben ser usadas por ms personas de las que actualmente lo consideran.En el ambiente actual, la metodologa ms comn es codifica y corrige. Aplicar ms disciplina que caos casi seguramente ayudar, y el acercamiento gil tiene la ventaja de que es mucho menos de un paso que un mtodo pesado. Mucha de la ventaja de los mtodos giles es de hecho su peso ligero. Los procesos ms simples son ms probables de ser seguidos cuando uno no est acostumbrado a ningn proceso en absoluto.Una de las limitaciones ms grandes de estas nuevas metodologas es cmo manejan equipos ms grandes. Como muchas nuevas tendencias, ellos tienden a ser usados primero a escala pequea antes que a gran escala. Tambin a menudo se han creado con nfasis en equipos pequeos. La XP explcitamente dice que est diseada para equipos de no ms de veinte personas. Hay que recordar que muchos equipos de software pueden reducirse en tamao sin reducir su productividad total.Otras tendencias giles estn destinadas a equipos ms grandes. La FDD fue diseada originalmente para un proyecto de cincuenta personas. ThoughtWorks ha usado proyectos influidos por la XP con equipos de cerca de 100 en tres continentes. Scrum se ha usado para manejar tamaos similares.Esperanzadoramente un mensaje que queda claro en este artculo es que los acercamientos adaptables son buenos cuando sus requisitos son inciertos o voltiles. Si usted no tiene requisitos estables, entonces no est en la posicin tener un plan estable y seguir un proceso planeado. En stas situaciones un proceso adaptable puede ser menos cmodo, pero ser ms eficaz. A menudo la barrera ms grande aqu es el cliente. Como yo lo veo es importante para el cliente entender que seguir un proceso predictivo cuando los requisitos cambian es arriesgado tanto para ellos como para el desarrollo.Si usted va a tomar la ruta adaptable, necesita confiar en sus desarrolladores e involucrarlos en la decisin. Los procesos adaptables cuentan en que usted confa en sus desarrolladores, de modo que si usted considera a sus desarrolladores de baja calidad y motivacin, usted debe usar un acercamiento predictivo.

Para resumir. Los siguientes factores sugieren un proceso adaptable Requisitos inciertos o voltiles Desarrolladores responsables y motivados Clientes que entienden y se involucrarn.

Estos factores sugieren un proceso predictivo Un equipo de ms de cien Un precio fijo, o ms correctamente un alcance o contrato fijo

3.3. Reutilizacin del software.

Mientras hoy, el software se hace cada vez ms esencial en la vida cada da; los procesos de desarrollo de software actuales no apoyan este rpido crecimiento de las necesidades. Los procesos de desarrollo de software actuales principalmente se dirigen al desarrollo nuevo de software, y no hacen caso de todos los sistemas existentes, antes activos de desarrollo. Los productores de software necesitan satisfacer los requisitos crecientes del cliente rpidamente para nuevos productos y servicios. Este crecimiento rpido causa cada vez ms nuevo software, que requiere cada vez ms esfuerzos de desarrollo.Mientras por una parte, las organizaciones tratan de controlar gastos crecientes de software; por otra parte, ellos deben responder rpidamente al cambio de necesidades comerciales y nuevas tecnologas y deben producir sistemas de software cada vez ms complejos ms rpidamente y ms barato a fin de permanecer competitivos.Es obvio que la reutilizacin de software sistemtica puede reducir enormemente gastos de desarrollo en aplicacin de software, acortar elementos de desarrollo, y reducir el riesgo de fracaso con la nueva tecnologa, as como enormemente mejorar la calidad y la fiabilidad de productos de software.As en los gastos de desarrollo de software de hoy, la reutilizacin de software es un deber para cada productor de software, a fin de ser capaz de proporcionar mejores productos, ms rpido y ms barato que antes.

3.3.1. Usos de reutilizacin.

La reutilizacin es una estrategia a largo plazo en la que una organizacin construye una biblioteca de componentes usados con frecuencia.La reutilizacin tambin puede realizarse a corto plazo, recuperando cdigo de programas ya existentes. Cuando est respaldada por un compromiso a largo plazo, la reutilizacin puede producir mayores ahorros de planificacin y esfuerzo que cualquier otra tcnica de desarrollo rpido.

La reutilizacin planificada tiene que implementarse sobre los cimientos de los fundamentos del desarrollo del software (metodologa). La reutilizacin debe de estar coordinada con el uso de herramientas para aumentar su productividad (herramientas).La reutilizacin debe abarcar: cdigo, diseo, datos, documentacin, materiales de prueba, especificaciones y planes.Utilizar personal que ya haya trabajado en proyectos similares es una de las formas ms fciles de reutilizacin.

Reutilizacin Oportunista

Podemos hacer una reutilizacin oportunista cuando descubrimos que un sistema existente tiene algo en comn con un sistema que estamos a punto de construir.Adaptar o recuperar? Ponemos adaptar el sistema viejo para el nuevo uso o disear uno nuevo y recuperar partes del sistema ya existentes

El mayor problema de la reutilizacin oportunista consiste en que es fcil sobreestimar los posibles ahorros de tiempo y esfuerzo. En sistemas que podamos estimar que se va a reutilizar un 80 por cien del cdigo, el esfuerzo slo se reducir un 20 por cienCuando se reutilizan partes del antiguo sistema de forma no prevista en el diseo o implementacin del antiguo sistema, nuevos errores emergen. Y nos encontraremos depurando y arreglando cdigo extrao.

Experiencias con la reutilizacin oportunista.

El Ejrcito francs tuvo una mejora del 37% de la productividad al recuperar cdigo de un sistema existente. El xito del proyecto se debi al uso de la modularidad y encapsulamiento del primer sistema.La NASA hizo un estudio de 10 proyectos que buscaban reutilizacin agresiva. Los proyectos inciales no pudieron sacar mucho provecho de proyectos anteriores. Sin embargo en proyectos siguientes, los proyectos que usaron diseo funcional reutilizaron el 35% del cdigo y los basados en objetos un 70%.A menudo los desarrolladores individuales reutilizan su cdigo, lo que puede suponer un ahorro de un 15%.

Reutilizacin planificada.

Es una estrategia a largo plazo que no le ayudar en el primer proyecto.Para comenzar un programa de reutilizacin, primero deberemos de investigar el software existente en nuestra organizacin e identificar los componentes que aparecen frecuentemente. Entonces, debe planificar hacer reutilizacin de estos componentes a largo plazo, bien comprndolos o desarrollando versiones reutilizables propias.

Gestin de la reutilizacin planificada

Implica que diferentes proyectos tendrn que estandarizar sus procesos software, lenguajes y herramientas. Requiere una inversin a largo plazo en formacin, plan multiproyecto para la construccin y mantenimiento de componentes reusables.

Las tareas de gestin son:

Designar un responsable de la directiva (No son vlidos directivos de primer nivel). Asegurar un compromiso a largo plazo con el programa. Hacer que la reutilizacin sea una parte integral y explicita del proceso de desarrollo. Transformar los programas de medida de productividad del software de la organizacin (software entregado en lugar de software desarrollado). Establecer un grupo de reutilizacin separado para encargarse de las tareas relativas a los componentes reusables. Proporcionar formacin al grupo de reutilizacin y a los posibles clientes del grupo. Difundir en la organizacin la existencia de la iniciativa. Crear y mantener una lista formal de las personas que estn reutilizando componentes. Preparar un sistema de control de coste y/o compensacin para el uso de componentes de la biblioteca.

Las tareas tcnicas son:

Evaluar si las arquitecturas actuales del software de la organizacin soportan la reutilizacin. Definir estndares de lenguajes de programacin e interfaces que soporten la reutilizacin. Definir procesos que soporten la reutilizacin. Crear una biblioteca formal de componentes reutilizables.

Sin embargo hay que ver la gestin de riesgo y observar los siguente:

Esfuerzo desperdiciado. Esfuerzos mal dirigidos. Cambios en la tecnologa. Sobreestimacin del ahorro

Componentes externos

Generalmente el uso de componentes EXTERNOS no se ve como reutilizacin; suele verse como una decisin de comprar o construir. Desde el punto de vista tcnico, es posible que el vendedor externo pueda poner ms recursos en un componente prefabricado que los que podamos disponer internamente y con un costo menor.Los vendedores llevan mucho tiempo ofreciendo bibliotecas comerciales para interfaces de usuario, bases de datos, funciones matemticas, etc.En la plataforma PC empieza a imponerse esta tecnologa con componentes VBX, OCX, COM, DCOM, CORBA y JAVA Beans.

Si decidimos comprar componentes para su reutilizacin a largo plazo deberemos de tener en cuenta diferentes aspectos (cdigo fuente, documentacin, solidez del proveedor, etc.) Pero hay una razn importante para no comprar determinados componentes: Desear controlar una tecnologa que es crtica para su empresa.

3.3.2. Patrones de diseo.

Que es un patron?

Cada Patrn es una regla de tres partes, la cual expresa una relacin entre un cierto contexto, un problema y una solucin.

Caractersticas de los Patrones

Proporcionan Soluciones concretas Proporcionan soluciones tcnicas Se utilizan en situaciones frecuentes Favorece la reutilizacin de cdigo El uso de un patrn no se refleja en el cdigo Es difcil reutilizar la Implementacin de un patrn

Clasificacin de Patrones

Segn su etapa de desarrollo: Anlisis Arquitectura Diseo

Patrones de Diseo

Los patrones de diseo, ayudan a disear soluciones de software, definiendo comportamientos comunes que suelen encontrarse en distintos componentes de software

Clasificacin de patrones de diseo

Segn su propsito: Fundamentales creacin Descomposicin Estructurales Comportamiento Concurrencia

Patrones fundamentalesPatrones de diseo bsicos, ya que son muy usados para la representacin de otros patrones.Delegacin - Delegation (1) Indica cuando no usar herencia. Es una forma de extender la funcionalidad de una clase, pero no se desea tener una jerarqua del tipo es un.

Ejemplo de delegacin

Interfaz

Permite a una clase usar datos y servicios provistos por otras clases independientes proveyendo un acceso uniforme.

Ejemplo de Interfaz (1)

Ejemplo de Interfaz (2)

Inmutable Inmutable

Evita que se modifique el estado de la clase. Es un patrn fundamental de concurrencia. Reduce el costo de los accesos concurrentes Evita la necesidad de sincronizar threads.Ejemplo:

Proxy Se requiere que las llamadas a mtodos de un objeto ocurran indirectamente a travs de un objeto sustituto del objeto original, delegando luego las llamadas a los mtodos de los objetos respectivos. El objeto proxy, comparte la misma interfaz o superclase que el objeto delegado.

Ejemplo de Proxy (1)

Patrones de creacin

Abstraen comportamientos referentes a la forma como se deben crear los objetos.

Fabrica Abstracta

Proporciona un Interfaz para crear familias de objetos sin especificar su clase de forma concreta. Si deseamos que nuestro software funcione sobre distintos recursos debemos abstraer las libreras utilizadas proporcionando una Interfaz comn.

Ejemplo de Fabrica Abstracta -Abstract Factory (1)

Singular - Singleton Este patrn asegura que slo una instancia de la clase sea creada. Todos los objetos que usan una instancia de esa clase, usan la misma instancia.

Ejemplo de Singular

Patrones de descomposicin

Los patrones de descomposicin proveen ayuda para descomponer actores y conceptos complejos en mltiples clases.

Compuesto - Composite

Tambin conocido como composicin recursiva. Permite construir objetos complejos mediante composicin recursiva de objetos similares, en forma de rbol. Tambin permite manipular consistentemente los objetos en el rbol, pidiendo que todos los objetos en el rbol tengan una superclase o interfaz comn.

Ejemplo de Compuesto - Composite (1)

Ejemplo de Compuesto - Composite (2)

Patrones Estructurales

Describen las formas comunes en que distintos tipos de objetos pueden ser organizados para trabajar y colaborar entre ellos.

Adaptador - Adapter

INTENCION Convierte la interfaz de una clase en otra ms compatible con nuestras necesidades. CONOCIDO COMO Class Adapter, Object Adapter, Wrapper MOTIVO Reduce la dependencia entre clases. APLICACIONES Para utilizar la interfaz de una librera que no coincide con la que se requiere. Para extender la funcionalidad de una librera existente.

PARTICIPANTES: Cliente Clase que hace uso de otras clases a travs de un interfaz que no se tiene por que corresponder con el implementado en dichas clases. InterfazObjetivo Clase que declara el interfaz al que llama la clase cliente. Adaptador Clase que implementa el enlace entre el interfaz desdeado (u objetivo) y el que realmente existe (ofrecido por la ClaseExistente) ClaseExistente Tambien llamada adaptada o adaptee, el la clase original de que se dispone.

Ejemplo de Adaptador de clases

Ejemplo de Adaptador de Objeto

Iterador - Iterator

INTENCION Permite acceder secuencialmente a los elementos de estructura de datos u objetos preservando su estructura interna. CONOCIDO COMO Iterator PARTICIPANTES IIterator: Interfaz que define los mtodos de acceso a los elementos. Iterator: Clase que implementa el acceso secuencial. ICollection: Interfaz de la clase Collection. La clase Collection ofrece sus propios objetos Iterator especializados.

Ejemplo de Iterador - Iterator

Patrones de comportamiento

Se utilizan para administrar y combinar ciertos comportamientos.

Comando-Command

Encapsula los comandos para permitir su administracin si se quere: Ejecutar asncronamente. Definir secuencias de ejecucin Hacer y Deshacer.

Ejemplo Comando-Command

Observador-Observer

Genera dependencias entre obetos, para que un componente dado (modelo) pueda informar a otros (observadores) de que su estado ha cambiado.

Ejemplo de Observador-Observer

Patrones de procesos

Definen patrones para la definicin de procesos.

Es un conjunto de tecnica, acciones y/o tareas (actividades) generales para desarrollar software orientado a objetos [Scott W. Ambler].Los patrones de actividad, dentro de una organizacin (y dentro de un proyecto) es llamado un proceso. [Coplien]

Clasificacin de los Patrones de Procesos

Patrones de Procesos Tareas (Task process patterns). Define pasos detallados para realizar una tarea. Patrones de procesos de etapa (Stage process patterns). Pasos repetitivos para una simple etapa de desarrollo. Patrones de procesos de fases (phase process patterns). Define las interaccione sentre los patrones de etapas para una simple etapa de desarrollo.

3.3.3. Basada en generadores.

3.3.4. Marcos de trabajo.

El framework o marco de trabajo obedece a un conjunto de componentes fsicos y lgicos estructurados de manera que permiten ser reutilizados en el diseo y desarrollo de nuevos sistemas de informacin (Minneto, 2007).

Caractersticas de los frameworks

La tabla 1 muestra las principales caractersticas que se pueden encontrar en la mayora de los framework o marco de trabajo.

3.3.5. Sistemas de aplicaciones.

3.4. Documentacin.

3.4.1. Objetivo e importancia.

3.4.2. Tipos.