GUIA DE SUPERVIVENCIA PARA EL DESARROLLO DE SOFTWARE

GUIA DE SUPERVIVENCIA PARA EL DESARROLLO DE SOFTWARE Cinco pasos para ir del Caos al Control Traducido por Eduardo Pulido Rodríguez con aprobación de SOFTLANDING SYSTEMS

Contenido INTRODUCCIÓN... 3 QUE TAN BIEN VAN LAS COSAS PARA UD?... 3 METAS DE LA ADMINISTRACIÓN DE SOFTWARE... 5 REDUCCIÓN DE RIESGOS... 6 PROCESO DE MEJORA CONTINUA... 6 LISTA DE VERIFICACIÒN DE LA ADMINISTRACIÒN DE SOFTWARE... 7 CINCO PASOS DEL CAOS AL CONTROL... 8 PASO 1: JUSTIFICAR ACCIONES A LA GERENCIA Y EQUIPO... 8 PASO 2: ADOPTAR UN PROCESO DE ADMINISTRACIÒN DE CAMBIOS Y HERRAMIENTAS... 9 PASO 3: ADOPTAR UN PROCESO DE CONTROL DE CALIDAD Y HERRAMIENTAS... 10 PASO 4: ADOPTE UN PROCESO PROGRESIVO E ITERATIVO DE DESARROLLO... 10 PASO 5: EVALUACIONES CONTINUAS Y REFINAMIENTO DE PROCESOS... 11 SUMARIO... 12 DONDE APRENDER MÀS... 13 Page 2 of 14

INTRODUCCIÓN A pesar de los avances alcanzados en la tecnología informática o quizás debido a ello- el desarrollo de software continùa siendo un gran desafío, así como tambièn un proceso frecuentemente impredecible. Aùn los equipos de ingenieros màs talentosos, frecuentemente se embarcan en el mantenimientos o en la creaciòn de nuevos proyectos de desarrollo, al parecer ùnicos en su gènero, con resultados que son difíciles de predecir. Como resultado de esto, los proyectos de mantenimiento o desarrollo de software usualmente toman más tiempo, cuestan mucho más, o no proveen lo que el usuario desea o necesita. Teniendo como resultado final, sistemas que son costosos de sustentar y mantener. Por supuesto, diferentes grupos visualizan el desarrollo de software de diferentes formas, y el resultado de sus proyectos varía de acuerdo a ello. Para algunos grupos de desarrolladores, el caos caracteriza la mayoría de sus proyectos, mientras que otros mantienen un control efectivo durante todo el proceso de desarrollo. Este documento provee una guía concisa para evaluar como lo está hacienda Ud. Y ademàs expone cinco pasos básicos para alcanzar un mejor control sobre sus proyectos de desarrollo de software. QUÈ TAN BIEN VAN LAS COSAS PARA UD? El proceso de desarrollo de software ha sido estudiado extensamente por dècadas. Esta investigación ha producido un modelo ampliamente aceptado que usted puede utilizar para evaluar còmo su propia organización lo está haciendo. La figura No. 1 sumariza el Modelo de Capacidad de Madurez (CMM por sus siglas en inglés Capability Maturity Model ) desarrollado por el Software Engineering Institue (www.sei.cmu.edu), una organización financiada por el gobierno de Los Estados Unidos. Las organizaciones operando al Nivel 1 de este modelo, enfrentan muchos de los problemas causados por un proceso pobre en su definición. En este nivel, la vida es caótica para los desarrolladores, los gerentes de Tecnología Informatica (TI), y el resto de la organización que depende del área de TI. Conforme una organización mejora su proceso de desarrollo y se mueve hacia un nivel más alto de madurez, los proyectos se tornan más predecibles y exitosos. Como regla general, los pasos para alcanzar el Nivel 3 (Definido), son significativamente más fáciles de implementar que aquellos requeridos para alcanzar el Nivel Page 3 of 14

4 y 5. El Nivel 3, es un objetivo apropiado para la mayoría de los grupos de desarrolladores internos y es a quienes se dirige este documento. La Figura 1 lista algunas de las prácticas claves para los niveles 2 y 3. Si su proceso de desarrollo no incorpora la mayoría de los puntos indicados, usted probablemente tiene una gran oportunidad de mejorar el proceso y ganar más control sobre sus proyectos. Los niveles 4 y 5 pueden ser llamados los niveles Empìricos y de Perfeccionamiento porque estos incluyen resultados de cuantificaciòn e incorporan cambios progresivos en el proceso general para reducir la variabilidad y mejorar el rendimiento organizacional en forma continua. Estos niveles requieren disciplina efectiva, automatizaciòn de procesos, y recursos. No se abrume pensando que usted tiene que alcanzar cualquiera de estos niveles para obtener un beneficio substancial. (Por otro lado, con el paso del tiempo quizàs usted decida incorporar algunas de las pràcticas de los Niveles 4 y 5 dentro de su propio proceso de desarrollo). La pàgina web del SEI explica el Modelo de Capacidad de Madurez (CMM) en màs detalle y es un buen lugar para continuar su travesìa hacia un mejor control de desarrollo. Figura 1 NIVELES DE MADUREZ EN EL PROCESO DE DESARROLLO DE SOFTWARE Del Instituto de Ingenierìa de Software Modelo de Capacidad de Madurez (CMM). 1. Inicial. El proceso de software se caracteriza como ad-hoc (como salga), y ocasionalmente caòtico. Pocos procesos son definidos, y el èxito depende de esfuerzos individuales y heroicos. 2. Repetitivos. Establecimiento de procesos administrativos bàsicos para el seguimiento de costos, planes de trabajo y funcionalidad. La disciplina necesaria para los procesos se encuentra implementada y permite repetir èxitos anteriores en proyectos con aplicaciones similares. Algunos de los procesos claves son: Administración de requerimientos Planeamiento y seguimiento de proyectos Uso de Software de Administración de Cambios (SCM) Implementación de Software de Control de Calidad (SQA) Page 4 of 14

3. Definido. El proceso de software, tanto para la administración como para la ingeniería son actividades documentadas, estandarizadas, e integradas dentro de un proceso estandar de software para la organización. Todos los proyectos cuentan con una versiòn aprobada y hecha a la medida de los estandares del proceso de software de la organización, los cuales regulan el desarrollo y mantenimiento de software en general. Algunos de estos procesos claves son: Definir y seguir un proceso de desarrollo Conducir capacitaciones regulares Implementar software de administración integral Revisiòn del trabajo desarrollado por colegas no para criticar sino mejorar 4. Administrado. Medidas, en detalle, del proceso de desarrollo y la calidad del producto elaborado son recolectadas. Ambos, el proceso de desarrollo y el producto son cuantitativamente entendidos y controlados. 5. Optimo. Mejoramiento contìnuo del proceso es facilitado por la retro-alimentación cuantitativa obtenida del proceso mismo, y por la implementaciòn de ideas innovadoras y las nuevas tecnologías disponibles. METAS DE LA ADMINISTRACIÓN DE SOFTWARE Antes de tratar los pasos que puede dar para alcanzar mayor control sobre los proyectos de desarrollo, veamos las metas de la administración de software: Entregar productos con la funcionalidad y calidad preveida Entrega en los plazos acordados Entrega a los costos preveidos Alcanzar niveles de servicio preveidos, durante el uso del software Note como enfatizo estas metas en tèrminos de una característica preveida en lugar de utilizar el mejor producto, el menor tiempo o el menor costo. La administración efectiva del software es el acto de establecer y obtener expectativas claramente definidas, lo cual require de un proceso de desarrollo de software que es predecible y que obtiene resultados consistentes. Con un proceso predescible, el staff de TI, sabe razonablemente bien Qué es lo que necesitan hacer y cuales serán los entregables?, sea que estèn manejando una simple correcciòn de programaciòn, un conjunto de cambios, o la creacion de una aplicación completamente nueva. Algo que es importante recalcar, es que los usuarios tambièn ven resultados consistentes por parte de los proyectos de TI cuando estos se adhieren a estas reglas de juego. Un proceso predecible de desarrollo de software inevitablemente requiere que tiempo (y dinero) sea invertido en software para la administración de cambios (CM) y control de calidad (QA), antes de implementar otras prácticas y herramientas importantes. A pesar de toda la evidencia en contra, algunos desarrolladores repetidamente aseguran que reduciendo las prácticas de desarrollo de software, ellos pueden entregar una aplicación más rapidamente y a menor costo. En mi experiencia, tal juego rara vez da resultado, y los proyectos sin CM y QA casi nunca alcanzan las expectativas de tiempo, dinero o capacidad. En contraste, las pràcticas sòlidas de administración de software evitan interrupciones en los proyectos que desvían al staff del trabajo productivo. Page 5 of 14

REDUCCIÓN DE RIESGOS Algunas veces los resultados de un proyecto fuera de control pueden ser desastrosos, terminando por la entrega de un producto inutilizable. Mayormente, una organización de TI que no cuenta con un adecuado control sobre sus proyectos, siempre se encuentra con retrazos en su plan de trabajo y por encima del presupuesto asignado, en general, con resultados que son costosos aún cuando no son un completo desastre. El incumplimiento en la entrega de nueva funcionalidad o nuevos sistemas de computo en el tiempo deseado, pueden significar oportunidades de negocio perdidas o reducida competitividad en el mercado. Un proyecto inconsistente en sus costos o fechas de entrega puede poner en riesgo el negocio completo de una compañìa y sus planes financieros. Proyectos que incluyen la entrega de nuevos tipos de funcionalidad, o que utilizan nuevas tecnologìas, son los que suelen entrar en problemas serios. El mundo de la Tecnologìa Informatica se encuentra actualmente en un perìodo de cambios ràpidos y constantes. Muchos programas nuevos utilizan tecnologìas emergentes tales como WebSphere y otros servidores de aplicaciòn Web, Java o lenguajes como C#, dispositivos inalàmbricos, servicios Web, bases de datos distribuìdas y otros. El predominio de proyectos que incluyen tecnologia de punta eleva la importancia de reducir los riesgos. Varias pràcticas especìficas a la administraciòn de software pueden ayudar a reducir los riesgos en forma significativa, y las voy a tratar en màs detalle en un momento. El punto de ènfasis, aquì, es que una administraciòn predecible para el desarrollo de software es escencial en la reducciòn de riesgo. Si la manera en que usted emprende el desarrolo de software no le brinda un control adequado, que le permita fijar y lograr sus objetivos, luego entonces su organizaciòn corre el riesgo de terminar con proyectos que son tardios en su cumplimiento, quizà por meses, sobrepasan su presupuesto, y de que estos proyectos se vengan a bajo antes de su culminaciòn. PROCESO DE MEJORA CONTINUA Administrar los riesgos por medio de un proceso de desarrollo de software predecible provee un fundamento sobre el cual usted podrà desarrollar en forma consistente mejor software, màs ràpidamente y a un menor costo. Empezando con esta base, usted podrà adoptar tècnicas y herramientas en adiciòn para lograr que sus desarrolladores sean màs productivos, para elevar la calidad del software, y para automatizar muchos de los procesos de administraciòn del software, liberando de esta manera màs tiempo para el desarrollo de las aplicaciones mismas. Quiero enfatizar la ineficiencia de tratar de hacer un mejor trabajo de desarrollo de software, a largo plazo, sin contar con un proceso bien definido. Sin tal proceso, las buenas ideas no podràn ser integradas efectivamente dentro de las pràcticas en ejecuciòn al interior de la organizaciòn de desarrolladores. Es màs, el tratar de apagar incendios (resolver multiples problemas) desperdicia demasiado tiempo y atencion que deberìan estar enfocados a la mejora en el desarrollo mismo del software. Pero obviamente, establecer un proceso predecible de desarrollo, no es el objetivo final. Conforme gane experiencia y se familiarice con tecnologìas cambiantes, usted deberà adaptar su proceso de desarrollo para alcanzar metas màs elevadas, no sòlamente de forma predecible y la disminuciòn del riesgo, sino tambièn: mejorar el software producido, mejorar el soporte otorgado, y reducir los costos de operaciòn y mantenimiento. La mejora continua del proceso de desarrollo le permiten a usted, afrontar nuevos desafìos, establecer y lograr expectativas màs altas de capacidad, calidad, cronogramas, y costos. Page 6 of 14

LISTA DE VERIFICACIÒN DE LA ADMINISTRACIÒN DE SOFTWARE Si usted desea mejorar los resultados de sus proyectos de software, usted tiene que mejorar el proceso. No hay balas de plata o una soluciòn inmediata al problema. La administraciòn de software involucra una variedad de tareas que cubren el ciclo de vida completo del desarrollo. La Figura 2 lista ocho de las àreas principales que requieren pràcticas bien definidas. A manera de auto-evaluaciòn, un gerente de IT puede hacerse las siguientes preguntas para cada uno de estos puntos: Si asigno a un desarrollador para trabajar en una tarea en esta àrea, tiene nuestra organizaciòn claramente definida una descripciòn de lo que èl o ella deberà hacer?. Directivas verbales dadas informalmente pueden funcionar en forma adecuada para tareas pequeñas que pueden ser completadas por una sola persona en algunos dìas. Cualquier otra tarea màs significativa o necesarias por màs de una vez necesita una mejor definiciòn. Este consejo no significa que todas las organizaciònes necesitan volùmenes tras volùmenes de descripciones de procesos personalizados. Muchas organizaciones exitosas tienen documentos breves que definen pasos claves en cada àrea y hacen referencia a libros o manuales de productos que proveen màs detalles. Si usted aùn no cuenta con nada definido para las ocho àreas claves en la Figura 2, aquì tiene una manera sencilla de empezar: Cree un documento (ej. En Word) con una secciòn para cada uno de los ocho items indicados Inicie cada secciòn escribiendo un pàrrafo titulado: Lo que hacemos hoy en dia Añada otro pàrrafo titulado: Lo que necesitamos hacer Inicie una lista titulada Recursos y adicione los nombres de libros, productos, Webs y URLs, y otros recursos de competencia. Inicie una serie de listas de verificaciòn sencilla de las cosas que un desarrollador deberìa hacer cuando se le asigne una tarea en particular. Su primera experiencia en este punto no tiene que ser comprensiva. Pero tome su tiempo de manera que usted y su equipo puedan captar las pràcticas màs importantes a seguir durante un proyecto de desarrollo de software. El dar este paso no quiere decir que su organizaciòn serà elevada al nivel 3 en la escala de madurez del proceso. Pero usted contarà con una guìa inicial para lideres de proyectos y su equipo de trabajo, y obtendrà un lugar tangible para expandir y mejorar la descripciòn de sus procesos. Su lista de pràcticas de desarrollo tambièn proveerà la base para decidir que tareas podrìan verse beneficiadas por la automatizaciòn. Debido a que los principios bàsicos de administraciòn de software se extienden a industrias diversas, o tipos de aplicaciòn y/o ambientes computacionales, usted puede apoyarse en la experiencia de expertos y colegas foraneos a su propia organizaciòn para iniciar el proceso. Conforme vaya creando su lista de verificaciòn, usted podrà determinar si està creando una guìa ùtil para el desarrollador, siempre y cuando pueda contestar estas cuatro preguntas: Què hago en esta tarea? (Esto establece el propòsito y actividades de la tarea) Cuando estarè listo para ir a la siguiente tarea? (Esto puede indicar los entregables que se produzcan) Cuàl es la siguiente tarea? (Esto describe el orden de las tareas dentro de cada fase del proyecto) Còmo avanzo de la tarea actual a la siguiente tarea? (Esto cubre còmo los resultados de una tarea seràn utilizados en las actividades de la tarea siguiente) Page 7 of 14

Figura 2 AREAS CENTRALES DE ADMINISTRACIÒN DE SOFTWARE CINCO PASOS DEL CAOS AL CONTROL Una vez que tenga claro donde se encuentra y donde quiere estar, los siguientes cinco pasos le permitiràn avanzar en forma significativa en direcciòn al Nivel 3 de madurez y a un mejor control de sus proyectos. PASO 1: JUSTIFICAR ACCIONES A LA GERENCIA Y EQUIPO Por varias razones, la buena administraciòn de software no parece ser una pràctica intuitiva para nadie, incluyendo desarrolladores y gerentes poco tècnicos. Los desarrolladores se caracterizan por ser muy optimistas respecto de los resultados de los proyectos y poco entusiastas sobre actividades que no sean las de diseño y la codificaciòn inmediata. A los gerentes poco tècnicos tìpicamente no les gusta escuchar sobre estimaciones realistas, especialmente aquellas como Nosotros no hemos hecho este tipo de proyecto anteriormente, de modo que necesitaremos invertir tiempo y dinero para evaluar lo que tomarà llevarlo a cabo. En la mayorìa de organizaciones, tendrà que justificar la adopciòn de metodologìas sòlidas para el desarrollo de software. Para los desarrolladores, he encontrado que el argumento fundamental es que la buena administraciòn del software reduce dramàticamente el esfuerzo. Aquì estàn algunos de los beneficios directos para los desarrolladores: Gran satisfacciòn y estima de los usuarios finales Menos aburrimiento y frustraciòn en la recodificaciòn para arreglar defectos y deficiencias Page 8 of 14

Menor nivel de interrupciones en el trabajo (o en el tiempo personal) para solucionar fallas crìticas en el software. Los desarrolladores que trabajan en organizaciones con una efectiva administraciòn del desarrollo de software son los mejores evangelizadores porque ellos pueden dar cuenta a sus compañeros que la vida es mucho mejor bajo control que en caos. Como un beneficio adicional, un buen proceso de desarrollo de software provee màs tiempo para las partes verdaderamente creativas del desarrollo de software. Para la gerencia, hay un argumento altamento exitoso que puede usar: La buena administracion del desarrollo de software reduce substancialmente los riesgos. Una de las cosas que los gerentes universalmente temen es un proyecto de envergadura que se viene abajo ante sus propios ojos. Me he dado cuenta de que en general, los gerentes que no pertenecen al campo de Tecnologìa Informàtica son usualmente los màs inclinados a dar respaldo a los requerimientos para lograr un mejor control de los proyectos de software, aùn cuando esto requiera inversiones de antemano para capacitaciòn y herramientas, y aùn cuando el proceso rebaje las expectativas (poco realistas, por lo general). Asì como sucede con los desarrolladores, la mejor referencia entre gerentes son sus colegas especialmente gerentes que han visto a una organizaciòn de Tecnologìa Informàtica mejorar sus practicas y productividad gracias a una buena administraciòn del desarrollo de software. PASO 2: ADOPTAR UN PROCESO DE ADMINISTRACIÒN DE CAMBIOS Y HERRAMIENTAS La administraciòn de cambios (algunas veces llamado gerencia de configuraciòn de software, SCM por sus siglas en inglès), es absolutamente escencial para un proceso efectivo de desarrollo de software. Algunas pràcticas bàsicas del control de cambios incluyen: Herramientas para el seguimientos de cambios de una aplicaciòn, tales como el fuente y sus archivos ejecutables Identificar versiones internas/comunes y de prueba/producciòn de todos los componentes Control de acceso a componentes (fuentes, reserva para cambios y liberaciòn) Control del movimiento de versiones (ej. Promociòn de pruebas a producciòn) Identificaciòn y creaciòn de versiones (relaciòn de versiones) Registro historico de cambios (ej. Correcciòn de defectos, adiciòn de funcionalidades, etc.) Proveer comparaciònes relativas de diferentes versiones de un componente. Grupos pequeños de desarrolladores(ej. Uno o dos personas), con aplicaciones simples para desarrollar pueden usar documentaciòn y procesos manuales, sin automatizacion. Sin embargo, la mayorìa de organizaciones tendràn mejores resultados con sistemas de Administraciòn de Cambios (CM por sus siglas en inglès) que proveen herramientas automàticas para promociòn, archivamiento, administraciòn de versiones, comparaciones, distribuciòn de aplicaciones, entre otras funciones. La automatizaciòn reduce substancialmente el tiempo requerido para realizar tareas de CM tales como check-in/check-out (estos tèrminos denotan exclusividad para la modificaciòn o creaciòn de còdigo fuente asì como la liberaciòn del mismo respectivamente), ubicar objetos relacionados para archivarlos cuando una nueva versiòn es creada, mover todos los objetos relacionados con la aplicaciòn cuando la aplicaciòn es promovida, etc. El primer beneficio tangible de un sistema de automatizaciòn CM, se puede ver en la reducciòn de errores y la perdida de tiempo originada por equivocación humana en la construcciòn de la versiòn de producciòn. CM tambièn evita que multiples desarrolladores trabajen sobre el mismo componente y sobreescriban cambios originando resultados conflictivos en el accionar de los mòdulos. Pero el mayor beneficio del CM es que provee la infraestructura de trabajo para planear y realizar seguimientos tangibles de los componentes durante todo el proceso de desarrollo de la aplicaciòn. Page 9 of 14

Algunos sistemas automatizados de CM tambièn facilitan la recolecciòn de mediciones de productividad y calidad que usted puede utilizar para evaluar y administrar el proceso de desarrollo. Idealmente, una sola herramienta automatizada de CM deberìa englobar todos los tipos de mòdulos relacionados al proyecto de TI, incluyendo fuentes y objetos de varios lenguajes (ej. ILE RPG, Java, CL); tablas para bases de datos, vistas, e indices; elementos de pàginas Web (ej. HTML, scripts, y archivos de imàgenes); documentaciòn; archivos de configuraciòn XML; propietarios de archivos, etc. El utilizar multiples sistemas de CM para diferentes tipos de componentes es inconveniente y no permite la incorporacion de modulos interrelacionados con dependencias mutuas y estrechas. Un buen sistema de CM tambièn se debe integrar con otras herramientas de desarrollo y administraciòn tales como Ambientes Integrados de Desarrollo (IDEs por sus siglas en inglès), herramientas de pruebas, y utilitarios para el seguimientos de problemas. El valor de un sistema de CM va màs allà de simplemente check-in/check-out del còdigo fuente, sino tambien provee la base para el desarrollo de aplicaciones completas de TI, la puesta en producciòn y el soporte para el flujo de trabajo. Estandarizaciòn y automatizaciòn de estos flujos de procesos puede reducir el tiempo que toma realizar una correcciòn o desarrollar un proyecto nuevo, tambièn puede reducir significativamente problemas de puesta en producciòn. PASO 3: ADOPTAR UN PROCESO DE CONTROL DE CALIDAD Y HERRAMIENTAS Control de Calidad es un conjunto de pràcticas que permiten medir y mejorar la calidad de un producto. Esto incluye la reducciòn de defectos y la entrega de software que alcanza los niveles especificados de funcionalidad y rendimiento. La pràctica mas importante de QA que puede seguir es registrar todos los defectos y otros tipos de problemas. Usted no puede reducir problemas sin hacerles seguimiento. CM y QA dependen el uno del otro. Un efectivo sistema de QA requiere CM para asociar los defectos y sus correcciones con versiones y componentes especìficos (Esto puede ser manejado eficientemente con sistemas automatizados de QA y CM que estàn bien integrados). De manera inversa, incorporando QA para reducir defectos y el doble trabajo que estos causan es esencial para que un sistema de CM no sea usado tan frecuentemente en forma innecesaria, en cilos de che-out/recodificaciòn/check-in/pruebas/promociòn. QA tambièn incluye pruebas de unidad, integraciòn, y componentes a nivel de sistemas, incluyendo pruebas de regresiòn para estar seguro que la nueva versiòn no fallarà con el còdigo actualmente en funcionamiento que pueda o no haber sido modificado. Asì como CM, productos disponibles de software de QA son usualmente recomendados para cualquier proyecto de gran embergadura que sobrepasen la capacidad de grupos pequeños de desarrolladores y proyectos sencillos. Dependiendo de los equipos de desarrolladores en el proyecto y el tipo de proyecto a emprenderse, sus pràcticas de QA pueden beneficiarse al hacer uso del diseño inicial, la revisiòn de còdigo, programaciòn en pares, y otras tècnicas especìficas. La clave principal de QA es identificar las medidas de calidad (por ejemplo, nùmero de defectos) para luego validar el progreso y ver cuales pràcticas proveen beneficios reales. PASO 4: ADOPTE UN PROCESO PROGRESIVO E ITERATIVO DE DESARROLLO En teorìa, usted puede aplicar la practica del Big Bang para emprender proyectos: haga el anàlisis, el diseño, la implementaciòn y las pruebas, finalmente, entregue el software a producciòn. En la vida real, esta teorìa funciona solamente con proyectos simples. Un proceso progresivo y e iterativo resulta en menos riesgo y mejores resultados para la mayorìa de proyectos. Una estrategia progresiva identifica entregables concretos que son màs pequeños que el producto completo de cualquier fase en desarrollo. Por ejemplo, usted puede identificar una serie de versiones de una aplicaciòn con funciones adicionales agregadas a cada versiòn en forma Page 10 of 14

progresiva. Sin embargo, los incrementos pueden ser màs pequeños que una versiòn final y pueden estar asociados con objetivos tales como criterios de performance, facilidad de uso, etc., Con una estrategia iterativa, usted planea repetir y re-tocar una o màs fases del desarrollo (ej. anàlisis, diseño, implementaciòn, etc.) varias veces. El desarrollo incremental e iterativo, van de la mano; sin embargo, describen difererentes aspectos del flujo en un proyecto. Producir piezas claramente identificada (ej. especificaciones o còdigo) da al proyecto una estructura de progreso incremental. Ciclos de trabajo que son repetitivos en diferentes fases del proyecto es lo que hace a un proceso iterativo. Una iteraciòn puede producir un nuevo incremento (resultado) o puede darse simplemente para modificar un logro producido. El desarrollo incremental e iterativo provee, en forma temprana y continua, la necesaria retroalimentaciòn de información que permite aprender lo que la aplicaciòn realmente requiere y lo que tomarà finalizarla para su entrega. Juntas, estas pràcticas lo protejeràn contra el riesgo màs grande en cualquier proyecto: Lo que no se sabe, no importa. Con el desarrollo incremental e iterativo, usted podrà ajustar los entregables planeados y sus agendas (y otros aspectos de su plan de proyecto tambièn) conforme aprenda de su experiencia. Al entregar partes de la aplicaciòn a tiempo y regularmente, el equipo de desarrollo tambièn gana y establece credibilidad en su entorno, y crea auto-estima. A la vez, una estrategia incremental se enfoca màs en las necesidades de los usuarios, instándolos a identificar sus prioridades en cada etapa del proyecto. PASO 5: EVALUACIONES CONTINUAS Y REFINAMIENTO DE PROCESOS Teniendo un sistema de CM y QA establecidos, y siguiendo un curso incremental e iterativo de desarrollo, su organizaciòn de desarrolladores tiene la base necesaria para evaluar que tan buenos procesos especìficos del proyecto estàn trabajando o no, y si se necesita revisar otros a medida que avanza el proyecto. Los procesos iterativos proveen una manera natural de llevar a cabo correcciones simples a lo largo de todo el proyecto. Pero lo màs importante de esta metodologìa, es que usted puede incorporar puntos de control explìcitos al final de cada ciclo de iteración. Si existen problemas, usted puede revisar y corregir partes del proceso para la siguiente iteraciòn. Otro beneficio de la evaluaciòn del proceso en forma continua es que usted puede descontinuar pràcticas no efectivas al final de cualquier iteraciòn. Con el tiempo, el proceso continuo de mejoras es la transiciòn mas fàcil y efectiva para salir del caos y establecer un verdadero control de desarrollo. En lugar de realizar cambios radicales en la manera como desarrolla e implementa software, usted puede adaptarse gradualmente a las necesidades de su organizaciòn, al estilo de su equipo de trabajo, y a cambios en la tecnologìa. Usted tambièn puede controlar el ritmo en que incorpora desarrollos adicionales y herramientas de administraciòn. Si su organizaciòn se compromete al continuo mejoramiento de procesos de desarrollo, usted prodrìa finalmente alcanzar los Niveles de Madurez 4 y 5. Page 11 of 14

SUMARIO El desarrollo de software nunca serà un proceso mecànico en su totalidad. Sin embargo, hoy en dìa estamos màs allà de la era cuando el proceso de desarrollo era considerado como magia negra. Muchas organizaciones exitosas, hoy en día, utilizan una combinación de metodologías formales e informales de desarrollo, y una mezcla de herramientas compradas y/o desarrolladas en casa, para conducir proyectos de manera predecible, que aceleren el desarrollo y reduzcan el riesgo innatos en estos. La adopciòn de sistemas de CM y QA son la base integral para la administraciòn del desarrollo de software. El desarrollo incremental, iterativo, y la evaluaciòn/mejora continua del proceso son piezas claves para lograr el control completo de un proyecto. Paul Conte es presidente de, una firma consultora en Eugene, Oregon, y es editor senior para e-pro Magazine e iseries NEWS Paul ha publicado numerosos artìculos sobre pràcticas de desarrollo de software y es una autoridad ampliamente reconocida en tecnologìa de base de datos. El es autor o co-autor de cinco libros, incluyendo SQL/400 Guìa del Desarrollador y SQL Server 2000 Guìa del desarrollador. Paul tiene un Bachillerato en Sicologìa de la Universidad del Estado de Georgia y una maestrìa en Ingeniería de Sistemas de la Universidad de Oregon. Page 12 of 14

DONDE APRENDER MÀS 14 Ways to Succeed at Project Management Paul Conte IT Financial Management http://www.businesstechnology.com/bt/content/index.cfm/fuseaction/viewarti cle/contentid/9 En este artìculo, elabore una variedad de pràcticas especìficas que lo ayudaràn a ser exitoso con proyectos de desarrollo de software Cockburn, Alistair Surviving Object-Oriented Projects Reading, MA: Addison-Wesley Publishing Company, 1997 Este libro es bastante corto pero provee una excelente explicaciòn de los riesgos administrativos y las tècnicas incrementales e iterativas del desarrollo McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1997 Una buena introducciòn a muchos principios del desarrollo de software. Por ejemplo McConnell nos ilustra con el siguiente pensamiento: Proyectos efectivos, controlan los cambios; mientras que proyectos inefectivos se dejan controlar por ellos Software Engineering Institue Web site: http://www.sei.cmu.edu Aquì usted podrà aprender màs sobre el Modelo de Capacidad de Madurez referenciado en la Figura 1. Para una descripciòn detallada de los niveles de capacidad vea el capìtulo 4 en el Capability Maturity Model Integration, Version 1.1 documento en PDF disponible en: http://www.sei.cmu.edu/cmmi/products/v1.1se-sw-cont.pdf El site SEI tiene una variedad amplia de documentos en lìnea, sin embargo; los documentos tienden a estar escritos en un estìlo acadèmico. NASA Software Engineering Laboratory Web site: http://sel.gsfc.nasa.gov Otra fuente de investigaciòn documentada y guìa sobre la administraciòn de software Softlanding System Web Site: http://www.softlanding.com/swmanagement/index.htm Una fuente especìfica sobre informaciòn de administraciòn de software en una plataforma iseries y links a otros articulos y Web sites de mucha utilidad. Page 13 of 14

SoftLanding Systems, Inc. 84 Elm Street, Peterborough, SISRED S.A.C., Canaval y Moreyra 350 Of. F NH 03458. 800-545-9485, 603-924-8818. Email: Webmaster San Isidro Lima Perú Tel. 511-421-0925 Copyright 2003, SoftLanding Systems, Inc. Email: webmaster@sisred.com Page 14 of 14