Guiadesupervivencia desarrollodesoftware

GUIA DE SUPERVIVENCIA PARA ELDESARROLLO DE SOFTWARE

Cinco pasos para ir del Caos al Control

Por Paul ContePicante Software

Traducido por

Eduardo Pulido Rodríguezcon aprobación de SOFTLANDING SYSTEMS

DESARROLLO DE SOFTWARE GUÍA DE SUPERVIVENCIA

Cinco Pasos para ir del Caos al ControlPor Paul ContePicante SoftwareTraducido por Eduardo Pulido

of 14

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............................................................................... 8PASO 2: ADOPTAR UN PROCESO DE ADMINISTRACIÒN DE CAMBIOS Y HERRAMIENTAS........................ 9PASO 3: ADOPTAR UN PROCESO DE CONTROL DE CALIDAD Y HERRAMIENTAS ..................................... 10PASO 4: ADOPTE UN PROCESO PROGRESIVO E ITERATIVO DE DESARROLLO ........................................... 10PASO 5: EVALUACIONES CONTINUAS Y REFINAMIENTO DE PROCESOS ..................................................... 11

SUMARIO............................................................................................................................................................................ 12

DONDE APRENDER MÀS................................................................................................................................................ 13



of 14

INTRODUCCIÓN

AA pesar de los avances alcanzados en la tecnología informática – o quizás debido a ello- el desarrollo desoftware continùa siendo un gran desafío, así como tambièn un proceso frecuentemente impredecible. Aùnlos equipos de ingenieros màs talentosos, frecuentemente se embarcan en el mantenimientos o en lacreaciòn de nuevos proyectos de desarrollo, al parecer “ùnicos en su gènero”, con resultados que sondifíciles de predecir.

Como resultado de esto, los proyectos – de mantenimiento o desarrollo de software – usualmente toman mástiempo, cuestan mucho más, o no proveen lo que el usuario desea o necesita. Teniendo como resultadofinal, sistemas que son costosos de sustentar y mantener. Por supuesto, diferentes grupos visualizan eldesarrollo de software de diferentes formas, y el resultado de sus proyectos varía de acuerdo a ello. Paraalgunos grupos de desarrolladores, el caos caracteriza la mayoría de sus proyectos, mientras que otrosmantienen un control efectivo durante todo el proceso de desarrollo. Este documento provee una guíaconcisa para evaluar como lo está hacienda Ud. Y ademàs expone cinco pasos básicos para alcanzar unmejor control sobre sus proyectos de desarrollo de software.

¿QUÈ TAN BIEN VAN LAS COSAS PARA UD?

EEl proceso de desarrollo de software ha sido estudiado extensamente por dècadas. Esta investigación haproducido un modelo ampliamente aceptado que usted puede utilizar para evaluar còmo su propiaorganización lo está haciendo.

La figura No. 1 sumariza el “Modelo de Capacidad de Madurez” (CMM por sus siglas en inglés “CapabilityMaturity Model”) desarrollado por el Software Engineering Institue (www.sei.cmu.edu), una organizaciónfinanciada 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 vidaes caótica para los desarrolladores, los gerentes de Tecnología Informatica (TI), y el resto de la organizaciónque 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



of 14

4 y 5. El Nivel 3, es un objetivo apropiado para la mayoría de los grupos de desarrolladores internos y es aquienes se dirige este documento. La Figura 1 lista algunas de las prácticas claves para los niveles 2 y 3. Sisu proceso de desarrollo no incorpora la mayoría de los puntos indicados, usted probablemente tiene unagran 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 estosincluyen resultados de cuantificaciòn e incorporan cambios progresivos en el proceso general para reducir lavariabilidad y mejorar el rendimiento organizacional en forma continua. Estos niveles requieren disciplinaefectiva, automatizaciòn de procesos, y recursos. No se abrume pensando que usted tiene que alcanzarcualquiera de estos niveles para obtener un beneficio substancial. (Por otro lado, con el paso del tiempoquizàs usted decida incorporar algunas de las pràcticas de los Niveles 4 y 5 dentro de su propio proceso dedesarrollo). La pàgina web del SEI explica el “Modelo de Capacidad de Madurez” (CMM) en màs detalle y esun buen lugar para continuar su travesìa hacia un mejor control de desarrollo.

Figura 1NIVELES 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 implementaday 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)



of 14

3. Definido . El proceso de software, tanto para la administración como para la ingeniería son actividadesdocumentadas, estandarizadas, e integradas dentro de un proceso estandar de software para laorganización. Todos los proyectos cuentan con una versiòn aprobada y hecha a la medida de losestandares del proceso de software de la organización, los cuales regulan el desarrollo y mantenimientode 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 sonrecolectadas. Ambos, el proceso de desarrollo y el producto son cuantitativamente entendidos ycontrolados.

5. Optimo. Mejoramiento contìnuo del proceso es facilitado por la retro-alimentación cuantitativa obtenidadel proceso mismo, y por la implementaciòn de ideas innovadoras y las nuevas tecnologías disponibles.

METAS DE LA ADMINISTRACIÓN DE SOFTWARE

AAntes 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 mejorproducto”, “el menor tiempo” o “el menor costo”. La administración efectiva del software es el acto deestablecer y obtener expectativas claramente definidas, lo cual require de un proceso de desarrollo desoftware 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 ycuales serán los entregables?, sea que estèn manejando una simple correcciòn de programaciòn, unconjunto de cambios, o la creacion de una aplicación completamente nueva. Algo que es importanterecalcar, es que los usuarios tambièn ven resultados consistentes por parte de los proyectos de TI cuandoestos se adhieren a estas reglas de juego.

Un proceso predecible de desarrollo de software inevitablemente requiere que tiempo (y dinero) seainvertido en software para la administración de cambios (CM) y control de calidad (QA), antes de implementarotras prácticas y herramientas importantes. A pesar de toda la evidencia en contra, algunos desarrolladoresrepetidamente aseguran que reduciendo las prácticas de desarrollo de software, ellos pueden entregar unaaplicación más rapidamente y a menor costo. En mi experiencia, tal juego rara vez da resultado, y losproyectos 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 staffdel trabajo productivo.



of 14

REDUCCIÓN DE RIESGOS

AAlgunas veces los resultados de un proyecto fuera de control pueden ser desastrosos, terminandopor la entrega de un producto inutilizable. Mayormente, una organización de TI que no cuenta con unadecuado control sobre sus proyectos, siempre se encuentra con retrazos en su plan de trabajo y por encimadel presupuesto asignado, en general, con resultados que son costosos aún cuando no son un completodesastre.

El incumplimiento en la entrega de nueva funcionalidad o nuevos sistemas de computo en el tiempodeseado, pueden significar oportunidades de negocio perdidas o reducida competitividad en el mercado. Unproyecto inconsistente en sus costos o fechas de entrega puede poner en riesgo el negocio completo de unacompañìa y sus planes financieros.

Proyectos que incluyen la entrega de nuevos tipos de funcionalidad, o que utilizan nuevastecnologìas, son los que suelen entrar en problemas serios. El mundo de la Tecnologìa Informatica seencuentra actualmente en un perìodo de cambios ràpidos y constantes. Muchos programas nuevos utilizantecnologìas emergentes tales como WebSphere y otros servidores de aplicaciòn Web, Java o lenguajescomo C#, dispositivos inalàmbricos, servicios Web, bases de datos distribuìdas y otros. El predominio deproyectos 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 enforma significativa, y las voy a tratar en màs detalle en un momento. El punto de ènfasis, aquì, es que unaadministraciòn predecible para el desarrollo de software es escencial en la reducciòn de riesgo. Si la maneraen que usted emprende el desarrolo de software no le brinda un control adequado, que le permita fijar ylograr sus objetivos, luego entonces su organizaciòn corre el riesgo de terminar con proyectos que sontardios en su cumplimiento, quizà por meses, sobrepasan su presupuesto, y de que estos proyectos sevengan a bajo antes de su culminaciòn.

PROCESO DE MEJORA CONTINUA

AAdministrar los riesgos por medio de un proceso de desarrollo de software predecible provee un fundamentosobre el cual usted podrà desarrollar en forma consistente mejor software, màs ràpidamente y a un menorcosto. Empezando con esta base, usted podrà adoptar tècnicas y herramientas en adiciòn para lograr quesus desarrolladores sean màs productivos, para elevar la calidad del software, y para automatizar muchos delos procesos de administraciòn del software, liberando de esta manera màs tiempo para el desarrollo de lasaplicaciones mismas.

Quiero enfatizar la ineficiencia de tratar de hacer un mejor trabajo de desarrollo de software, a largoplazo, sin contar con un proceso bien definido. Sin tal proceso, las buenas ideas no podràn ser integradasefectivamente 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 quedeberì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. Conformegane experiencia y se familiarice con tecnologìas cambiantes, usted deberà adaptar su proceso de desarrollopara alcanzar metas màs elevadas, no sòlamente de forma predecible y la disminuciòn del riesgo, sinotambièn: mejorar el software producido, mejorar el soporte otorgado, y reducir los costos de operaciòn ymantenimiento. 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.



of 14

LISTA DE VERIFICACIÒN DE LA ADMINISTRACIÒN DE SOFTWARE

SSi usted desea mejorar los resultados de sus proyectos de software, usted tiene que mejorar el proceso. Nohay “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 completodel desarrollo. La Figura 2 lista ocho de las àreas principales que requieren pràcticas bien definidas. Amanera de auto-evaluaciòn, un gerente de IT puede hacerse las siguientes preguntas para cada uno de estospuntos:

Si asigno a un desarrollador para trabajar en una tarea en esta àrea, ¿ tiene nuestra organizaciònclaramente definida una descripciòn de lo que èl o ella deberà hacer?. Directivas verbales dadasinformalmente pueden funcionar en forma adecuada para tareas pequeñas que pueden ser completadas poruna sola persona en algunos dìas. Cualquier otra tarea màs significativa o necesarias por màs de una veznecesita una mejor definiciòn.

Este consejo no significa que todas las organizaciònes necesitan volùmenes tras volùmenes dedescripciones de procesos personalizados. Muchas organizaciones exitosas tienen documentos breves quedefinen pasos claves en cada àrea y hacen referencia a libros o manuales de productos que proveen màsdetalles.

Si usted aùn no cuenta con nada definido para las ocho àreas claves en la Figura 2, aquì tiene unamanera 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 queusted y su equipo puedan captar las pràcticas màs importantes a seguir durante un proyecto de desarrollo desoftware.

El dar este paso no quiere decir que su organizaciòn serà elevada al nivel 3 en la escala de madurez delproceso. 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 desarrollotambiè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 tiposde aplicaciòn y/o ambientes computacionales, usted puede apoyarse en la experiencia de expertos y colegasforaneos 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 contestarestas 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)



of 14

Figura 2AREAS CENTRALES DE ADMINISTRACIÒN DE SOFTWARE

CINCO PASOS DEL CAOS AL CONTROL

UUna vez que tenga claro donde se encuentra y donde quiere estar, los siguientes cinco pasos lepermitiràn avanzar en forma significativa en direcciòn al Nivel 3 de madurez y a un mejor control desus 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 paranadie, incluyendo desarrolladores y gerentes poco tècnicos. Los desarrolladores se caracterizan porser muy optimistas respecto de los resultados de los proyectos y poco entusiastas sobre actividadesque 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, demodo que necesitaremos invertir tiempo y dinero para evaluar lo que tomarà llevarlo a cabo.” En lamayorìa de organizaciones, tendrà que justificar la adopciòn de metodologìas sòlidas para eldesarrollo de software.

Para los desarrolladores, he encontrado que el argumento fundamental es que la buenaadministraciòn del software reduce dramàticamente el esfuerzo. Aquì estàn algunos de losbeneficios 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



of 14

• Menor nivel de interrupciones en el trabajo (o en el tiempo personal) para solucionarfallas crìticas en el software.

Los desarrolladores que trabajan en organizaciones con una efectiva administraciòn deldesarrollo de software son los mejores “evangelizadores” porque ellos pueden dar cuenta a suscompañeros que la vida es mucho mejor bajo control que en caos. Como un beneficio adicional, unbuen proceso de desarrollo de software provee màs tiempo para las partes verdaderamente creativasdel desarrollo de software.

Para la gerencia, hay un argumento altamento exitoso que puede usar: La buenaadministracion del desarrollo de software reduce substancialmente los riesgos. Una de las cosas quelos gerentes universalmente temen es un proyecto de envergadura que se viene abajo ante suspropios ojos. Me he dado cuenta de que en general, los gerentes que no pertenecen al campo deTecnologìa Informàtica son usualmente los màs inclinados a dar respaldo a los requerimientos paralograr un mejor control de los proyectos de software, aùn cuando esto requiera inversiones deantemano para capacitaciòn y herramientas, y aùn cuando el proceso rebaje las expectativas (pocorealistas, por lo general). Asì como sucede con los desarrolladores, la mejor referencia entre gerentesson sus colegas – especialmente gerentes que han visto a una organizaciòn de TecnologìaInformàtica mejorar sus practicas y productividad gracias a una buena administraciòn del desarrollode 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, SCMpor sus siglas en inglès), es absolutamente escencial para un proceso efectivo de desarrollo desoftware. 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 paradesarrollar 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 deCambios (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, entreotras funciones.

La automatizaciòn reduce substancialmente el tiempo requerido para realizar tareas de CM talescomo check-in/check-out (estos tèrminos denotan exclusividad para la modificaciòn o creaciòn decòdigo fuente asì como la liberaciòn del mismo respectivamente), ubicar objetos relacionadospara archivarlos cuando una nueva versiòn es creada, mover todos los objetos relacionados conla 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ònde errores y la perdida de tiempo originada por equivocación humana en la construcciòn de la versiònde producciòn. CM tambièn evita que multiples desarrolladores trabajen sobre el mismo componentey sobreescriban cambios originando resultados conflictivos en el accionar de los mòdulos. Pero elmayor beneficio del CM es que provee la infraestructura de trabajo para planear y realizarseguimientos tangibles de los componentes durante todo el proceso de desarrollo de la aplicaciòn.



of 14

Algunos sistemas automatizados de CM tambièn facilitan la recolecciòn de mediciones deproductividad 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 demòdulos relacionados al proyecto de TI, incluyendo fuentes y objetos de varios lenguajes (ej. ILERPG, 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 dearchivos, etc. El utilizar multiples sistemas de CM para diferentes tipos de componentes esinconveniente y no permite la incorporacion de modulos interrelacionados con dependencias mutuasy estrechas.

Un buen sistema de CM tambièn se debe integrar con otras herramientas de desarrollo yadministraciò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 deCM va màs allà de simplemente “check-in/check-out” del còdigo fuente, sino tambien provee la basepara el desarrollo de aplicaciones completas de TI, la puesta en producciòn y el soporte para el flujode trabajo. Estandarizaciòn y automatizaciòn de estos flujos de procesos puede reducir el tiempoque toma realizar una correcciòn o desarrollar un proyecto nuevo, tambièn puede reducirsignificativamente 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 unproducto. Esto incluye la reducciòn de defectos y la entrega de software que alcanza los nivelesespecificados de funcionalidad y rendimiento. La pràctica mas importante de QA que puede seguires registrar todos los defectos y otros tipos de problemas. Usted no puede reducir problemas sinhacerles seguimiento.

CM y QA dependen el uno del otro. Un efectivo sistema de QA requiere CM para asociar losdefectos y sus correcciones con versiones y componentes especìficos (Esto puede ser manejadoeficientemente 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 esesencial para que un sistema de CM no sea usado tan frecuentemente en forma innecesaria, en cilosde 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òdigoactualmente en funcionamiento que pueda o no haber sido modificado.Asì como CM, productos disponibles de software de QA son usualmente recomendados paracualquier proyecto de gran embergadura que sobrepasen la capacidad de grupos pequeños dedesarrolladores y proyectos sencillos.

Dependiendo de los equipos de desarrolladores en el proyecto y el tipo de proyecto aemprenderse, sus pràcticas de QA pueden beneficiarse al hacer uso del diseño inicial, la revisiòn decòdigo, “programaciòn en pares”, y otras tècnicas especìficas. La clave principal de QA es identificarlas medidas de calidad (por ejemplo, nùmero de defectos) para luego validar el progreso y ver cualesprà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 vidareal, esta teorìa funciona solamente con proyectos simples. Un proceso progresivo y e iterativoresulta 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 elproducto completo de cualquier fase en desarrollo. Por ejemplo, usted puede identificar una serie deversiones de una aplicaciòn con funciones adicionales agregadas a cada versiòn en forma



of 14

progresiva. Sin embargo, los incrementos pueden ser màs pequeños que una versiòn final y puedenestar 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 dela 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 progresoincremental. Ciclos de trabajo que son repetitivos en diferentes fases del proyecto es lo que hace aun proceso iterativo. Una iteraciòn puede producir un nuevo incremento (resultado) o puede darsesimplemente para modificar un logro producido.

El desarrollo incremental e iterativo provee, en forma temprana y continua, la necesaria retro-alimentaciòn de información que permite aprender lo que la aplicaciòn realmente requiere y lo quetomarà finalizarla para su entrega. Juntas, estas pràcticas lo protejeràn contra el riesgo màs grandeen 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 deproyecto tambièn) conforme aprenda de su experiencia.

Al entregar partes de la aplicaciòn a tiempo y regularmente, el equipo de desarrollo tambièngana y establece credibilidad en su entorno, y crea auto-estima. A la vez, una estrategia incrementalse enfoca màs en las necesidades de los usuarios, instándolos a identificar sus prioridades en cadaetapa 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 dedesarrollo, su organizaciòn de desarrolladores tiene la base necesaria para evaluar que tan buenosprocesos especìficos del proyecto estàn trabajando o no, y si se necesita revisar otros a medida queavanza el proyecto.

Los procesos iterativos proveen una manera natural de llevar a cabo correcciones simples a lo largode todo el proyecto. Pero lo màs importante de esta metodologìa, es que usted puede incorporarpuntos de control explìcitos al final de cada ciclo de iteración. Si existen problemas, usted puederevisar y corregir partes del proceso para la siguiente iteraciòn. Otro beneficio de la evaluaciòn delproceso en forma continua es que usted puede descontinuar pràcticas no efectivas al final decualquier iteraciòn.

Con el tiempo, el proceso continuo de mejoras es la transiciòn mas fàcil y efectiva para salirdel caos y establecer un verdadero control de desarrollo. En lugar de realizar cambios radicales enla manera como desarrolla e implementa software, usted puede adaptarse gradualmente a lasnecesidades 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 deadministraciòn. Si su organizaciòn se compromete al continuo mejoramiento de procesos dedesarrollo, usted prodrìa finalmente alcanzar los Niveles de Madurez 4 y 5.



of 14

SUMARIOEEl desarrollo de software nunca serà un proceso mecànico en su totalidad. Sinembargo, hoy en dìa estamos màs allà de la era cuando el proceso de desarrollo eraconsiderado como “magia negra”. Muchas organizaciones exitosas, hoy en día,utilizan una combinación de metodologías formales e informales de desarrollo, y unamezcla de herramientas compradas y/o desarrolladas en casa, para conducirproyectos de manera predecible, que aceleren el desarrollo y reduzcan el riesgoinnatos en estos.La adopciòn de sistemas de CM y QA son la base integral para la administraciòn deldesarrollo de software. El desarrollo incremental, iterativo, y la evaluaciòn/mejoracontinua del proceso son piezas claves para lograr el control completo de unproyecto.

Paul Conte es presidente de Picante Software, una firma consultora en Eugene,Oregon, y es editor senior para e-Pro Magazine e iSeries NEWS Paul ha publicadonumerosos artìculos sobre pràcticas de desarrollo de software y es una autoridadampliamente reconocida en tecnologìa de base de datos. El es autor o co-autor decinco libros, incluyendo SQL/400 Guìa del Desarrollador y SQL Server 2000 Guìa deldesarrollador. Paul tiene un Bachillerato en Sicologìa de la Universidad del Estado deGeorgia y una maestrìa en Ingeniería de Sistemas de la Universidad de Oregon.



of 14

DONDE APRENDER MÀS• “14 Ways to Succeed at Project Management”

Paul Conte IT Financial Managementhttp://www.businesstechnology.com/BT/Content/Index.cfm/fuseaction/viewArticle/ContentID/9

En este artìculo, elabore una variedad de pràcticas especìficas que lo ayudaràn aser exitoso con proyectos de desarrollo de software

• Cockburn, Alistair Surviving Object-Oriented ProjectsReading, MA: Addison-Wesley Publishing Company, 1997

Este libro es bastante corto pero provee una excelente explicaciòn de los riesgosadministrativos y las tècnicas incrementales e iterativas del desarrollo

• McConnell, Steve. Software Project Survival Guide. Redmond, WA: MicrosoftPress, 1997

Una buena introducciòn a muchos principios del desarrollo de software. Porejemplo McConnell nos ilustra con el siguiente pensamiento: “Proyectosefectivos, controlan los cambios; mientras que proyectos inefectivos se dejancontrolar por ellos”

• Software Engineering Institue Web site: http://www.sei.cmu.edu

Aquì usted podrà aprender màs sobre el Modelo de Capacidad de Madurezreferenciado en la Figura 1. Para una descripciòn detallada de los niveles decapacidad 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; losdocumentos 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 desoftware

• Softlanding System Web Site:http://www.softlanding.com/swmanagement/index.htm

Una fuente especìfica sobre informaciòn de administraciòn de software en unaplataforma iSeries y links a otros articulos y Web sites de mucha utilidad.



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-0925Copyright 2003, SoftLanding Systems, Inc. Email: [email protected]

Guiadesupervivencia desarrollodesoftware

Technology

Transcript of Guiadesupervivencia desarrollodesoftware