ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL SEP NMERO 972142 DE FECHA 10 DE JUNIO DE 1997

MTODO DE DESARROLLO DE SISTEMAS PARA EQUIPOS DE TRABAJO PEQUEOS

TESISQUE PARA OBTENER EL GRADO DE LICENCIADO EN INGENIERA EN COMPUTACIN PRESENTA: OSCAR EMILIANO CECEA FUJIGAKIASESOR: M. C. IVAN JOS MRQUEZ LARIOS

MXICO, D. F.

NOVIEMBRE 2010

DEDICATORIADedico este trabajo a mi abuelo Augusto (q. e. p. d.); de quien aprend que lo importante en esta vida es lo que dejas cuando te vas. A mi esposa Marcela por su amor incondicional, por su apoyo y compaa aun en los momentos ms difciles, por creer siempre en m y por darme los mejores das de mi vida. A mi hermana Tania por ensearme que siempre se puede un poco ms, y que no hay mayor orgullo que levantarse con la frente en alto despus de haber cado. A mi madre por darme las bases para ser quien soy y por la confianza que siempre ha tenido en m. A mi padre por su apoyo y por ensearme a rer aun cuando todo est en contra. A mi ta Mara por ser como una segunda madre y apoyarme en todo momento. A mi abuela Esperanza, a mis tos Esperanza, Leticia, Aida, Jos Luis, Beatriz, y a mis primos Harumy, Mariana, Pepe y Augusto, por toda una vida de aprendizaje y cario. A Jos, por ser un gran amigo y apoyo durante 20 aos. A mis amigos: Ana, Astrid, Christian, Dan Jacob, Julio, Manuel y Pascual, por su amistad y por los grandes momentos que hemos pasado juntos.

AGRADECIMIENTOSEs raro el proyecto que no requiere un equipo y aunque esta tesis lleva solamente mi nombre como autor, es el fruto de mi trabajo y colaboracin con muchas otras personas. Este proyecto de tesis comenz en la universidad y culmin al aplicarlo formalmente en un equipo de desarrollo de sistemas existente. A estas personas que durante todo este tiempo me compartieron generosamente sus conocimientos y experiencia, les ofrezco mi agradecimiento. A mis compaeros de la universidad: Lizzette, Christian, Josu, Rodrigo y Nacho por los momentos que pasamos en la universidad, y el aprendizaje que adquirimos juntos. A Mario, Dan Jacob y Christian por su colaboracin a la aplicacin de este mtodo de trabajo. A Vctor por darme la oportunidad de crear y aplicar este mtodo dentro de su gerencia y bajo su supervisin. AIvn, por su asesora, contribucin y apoyo para la realizacin de este trabajo tan importante.

RESUMENExisten varios mtodos de desarrollo de software, algunos ya probados y otros apenas experimentales. El mtodo propuesto en este documento est enfocado completamente a equipos de desarrollo de software en Mxico. Cada pas tiene su propia cultura, y sta se refleja al momento de realizar las actividades cotidianas, entre ellas: el trabajo. Las metodologas giles tomadas como referencia han sido desarrolladas en pases de primer mundo, Estados Unidos por ejemplo; el cual tiene una cultura muy diferente y, por lo tanto, una manera de trabajar distinta a la de nuestro pas. En mi experiencia de trabajo, nunca me he topado con un proyecto que mantenga el alcance y los requerimientos fijos de inicio a fin; al menos un cambio al alcance inicial es realizado durante el desarrollo. Por esta razn es necesario contar con un mtodo de trabajo abierto a las necesidades cambiantes de los usuarios de los sistemas. El estudio y la evolucin de las metodologas de desarrollo de software a lo largo de su historia, que se remonta apenas 50 aos atrs, sirve como base terica para esta tesis; y el contexto actual de la empresa, una consultora de software pequea, funge como la parte prctica. La combinacin de ambas permite llegar al desarrollo del mtodo STASD y su aplicacin en un proyecto de desarrollo de software real. Aplicar este mtodo de trabajo a un equipo de desarrollo fue una tarea que hizo posible monitorear la efectividad del mismo y compararlo con la forma en la cual se haca el proceso anteriormente. Debido a esto es posible concluir que, de seguirse utilizando, mejorar los tiempos de entrega y el control de las actividades del proyecto.

TABLA DE CONTENIDO

INTRODUCCIN ............................................................................................................. 1 ANTECEDENTES ........................................................................................................... 4 LA CRISIS DEL SOFTWARE ................................................................................................ 4 ORTODOXIA METODOLGICA............................................................................................ 5 INICIOS DE LA HETERODOXIA ............................................................................................ 6 PLANTEAMIENTO DEL PROBLEMA ............................................................................ 8 OBJETIVO....................................................................................................................... 9 PROPSITO ................................................................................................................. 10 JUSTIFICACIN ........................................................................................................... 11 ALCANCE ..................................................................................................................... 12 METODOLOGA............................................................................................................ 14 CAPTULO I. MARCO CONCEPTUAL ..................................................................... 15 I.1. INGENIERA DE SOFTWARE ....................................................................................... 16 I.2. SISTEMA DE INFORMACIN ....................................................................................... 17 I.3. CICLO DE VIDA ........................................................................................................ 18 I.4. SOFTWARE ............................................................................................................. 19 I.5. BASE DE DATOS ...................................................................................................... 19 I.6. UML ...................................................................................................................... 20 I.7. HERRAMIENTAS CASE ............................................................................................ 21 CAPTULO II. MARCO TERICO ............................................................................ 23 II.1. MODELOS DE CICLOS DE VIDA ................................................................................. 24

II.1.1. Modelo en cascada ..................................................................................................24 II.1.2. Modelo iterativo e incremental..................................................................................26 II.1.3. Modelo en espiral .....................................................................................................27 II.1.4. RUP (Rational Unified Process) ...............................................................................29

II.2. METODOLOGAS GILES .......................................................................................... 30II.2.1. XP Extreme Programming .....................................................................................33 II.2.2. Scrum ......................................................................................................................36 II.2.3. Crystal Clear ............................................................................................................39 II.2.4. DSDM Dynamic Systems Development Method....................................................39 II.2.5. FDD Feature Driven Development ........................................................................42 II.2.6. ASD Adaptive Software Development ...................................................................44

CAPTULO III. MARCO CONTEXTUAL .................................................................. 49 III.1. CONTEXTO ECONMICO ......................................................................................... 51 III.2. PROCESOS DE DESARROLLO DE SOFTWARE ............................................................. 52 III.3. METODOLOGAS ORIENTADAS A PROCESOS.............................................................. 54 III.4. CONTEXTO DE LA EMPRESA INCORPREA S.A. ........................................................ 55 CAPTULO IV. PROCESO ACTUAL DE DESARROLLO ......................................... 57 IV.1. EL PROCESO DE DESARROLLO................................................................................ 58IV.1.1. Levantamiento de requerimientos ...........................................................................58 IV.1.2. Anlisis del sistema ................................................................................................59 IV.1.3. Codificacin del sistema .........................................................................................60 IV.1.4. Integracin y pruebas del sistema...........................................................................62 IV.1.5. Pruebas del sistema con el cliente ..........................................................................62

IV.2. OBSERVACIONES DEL PROCESO DE DESARROLLO .................................................... 63IV.2.1. Levantamiento de requerimientos ...........................................................................63 IV.2.2. Anlisis del sistema ................................................................................................64 IV.2.3. Codificacin del sistema .........................................................................................64 IV.2.4. Integracin y pruebas del sistema...........................................................................65 IV.2.5. Pruebas del sistema con el cliente ..........................................................................65 IV.2.6. Observaciones finales.............................................................................................65

CAPTULO V. MTODO STASD ............................................................................... 67 V.1. INTRODUCCIN A STASD ...................................................................................... 68V.1.1. Presentacin............................................................................................................ 68 V.1.2. El proceso creativo .................................................................................................. 69 V.1.3. Estructura ................................................................................................................ 71

V.2. MODELO DEL EQUIPO DE TRABAJO .......................................................................... 71V.2.1. Analista de negocio ................................................................................................. 74 V.2.2. Lder de proyecto ..................................................................................................... 74 V.2.3. Desarrollador ........................................................................................................... 75 V.2.4. Tester ...................................................................................................................... 76 V.2.5. Administrador del conocimiento ............................................................................... 77

V.3. FASES E HITOS DEL PROCESO DE DESARROLLO ........................................................ 77V.3.1. Fase de preparacin ................................................................................................ 79 V.3.2. Fase creativa ........................................................................................................... 80 V.3.3. Fase de planeacin ................................................................................................. 80 V.3.4. Fase de desarrollo ................................................................................................... 81 V.3.5. Fase de estabilizacin ............................................................................................. 81

V.4. ACTIVIDADES DENTRO DE LAS FASES ....................................................................... 82V.4.1. Estudio de factibilidad .............................................................................................. 83 V.4.2. Anlisis de requerimientos ....................................................................................... 84 V.4.3. Diseo de la arquitectura ......................................................................................... 86 V.4.4. Desarrollo del sistema ............................................................................................. 86 V.4.5. Pruebas unitarias ..................................................................................................... 87 V.4.6. Pruebas de funcionalidad ........................................................................................ 87 V.4.7. Liberacin ................................................................................................................ 88

V.5. ACTIVIDADES DE SOPORTE ..................................................................................... 89V.5.1. Administracin del plan de trabajo ........................................................................... 89 V.5.2. Administracin del personal ..................................................................................... 90 V.5.3. Administracin del conocimiento.............................................................................. 91

V.6. ARTEFACTOS ........................................................................................................ 92V.6.1. Documento de estndares ....................................................................................... 94 V.6.2. Documento de evaluacin del personal ................................................................... 94

V.6.3. Documento de visin ...............................................................................................95 V.6.4. Plan del proyecto .....................................................................................................95 V.6.5. Listado de riesgos....................................................................................................95 V.6.6. Diagrama de casos de uso ......................................................................................96 V.6.7. Documento de caso de uso .....................................................................................96 V.6.8. Diagrama de la arquitectura .....................................................................................97 V.6.9. Documento de casos de prueba ..............................................................................97 V.6.10. Documento de aprendizaje ....................................................................................97 V.6.11. Paquete de liberacin ............................................................................................98

V.7. INTEGRACIN DE STASD ....................................................................................... 98 CAPTULO VI. CASO PRCTICO .......................................................................... 101 VI.1. FASE DE PREPARACIN ....................................................................................... 102VI.1.1. Definicin de estndares ...................................................................................... 102

VI.2. FASE CREATIVA................................................................................................... 107VI.2.1. Administracin del personal .................................................................................. 107 VI.2.2. Asignacin de roles dentro del equipo de trabajo .................................................. 110 VI.2.3. Visin del proyecto................................................................................................ 110

VI.3. FASE DE PLANEACIN .......................................................................................... 112VI.3.1. Plan del proyecto .................................................................................................. 113 VI.3.2. Anlisis de riesgos ................................................................................................ 115 VI.3.3. Estudio de factibilidad ........................................................................................... 116

VI.4. FASE DE DESARROLLO......................................................................................... 117VI.4.1. Anlisis de requerimientos .................................................................................... 117 VI.4.2. Diseo de la arquitectura ...................................................................................... 120 VI.4.3. Desarrollo del sistema .......................................................................................... 121 VI.4.4. Pruebas unitarias .................................................................................................. 123 VI.4.5. Modificacin de la arquitectura ............................................................................. 123 VI.4.6. Refactorizacin de las clases modificadas ............................................................ 124 VI.4.7. Segunda etapa de pruebas ................................................................................... 125

VI.5. FASE DE ESTABILIZACIN ..................................................................................... 126VI.5.1. Pruebas de funcionalidad...................................................................................... 126 VI.5.2. Liberacin ............................................................................................................. 127

VI.6. REVISIN DE LAS ACTIVIDADES DE SOPORTE ......................................................... 127VI.6.1. Administracin del plan de trabajo ........................................................................ 127 VI.6.2. Administracin del personal .................................................................................. 128 VI.6.3. Administracin del conocimiento ........................................................................... 128

VI.7. FASES DE DESARROLLO COMPLEMENTARIAS ......................................................... 128VI.7.1. Plan de trabajo...................................................................................................... 129 VI.7.2. Administracin del personal .................................................................................. 132 VI.7.3. Anlisis de riesgos ................................................................................................ 134 VI.7.4. Administracin del conocimiento ........................................................................... 135

VI.8. EVALUACIN FINAL DEL SISTEMA .......................................................................... 135 CONCLUSIONES ........................................................................................................ 137 REFERENCIAS ........................................................................................................... 139 APNDICES ................................................................................................................ 141 MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT........................................................ 141 MAPA DE LOS ARTEFACTOS DEL MTODO ...................................................................... 142 PLANTILLAS DE LOS ARTEFACTOS UTILIZADOS ............................................................... 143Documento de estndares ............................................................................................... 143 Documento de evaluacin del personal ........................................................................... 144 Documento de visin ....................................................................................................... 144 Listado de riesgos ............................................................................................................ 145 Documento de casos de uso ............................................................................................ 147 Documento de casos de prueba ...................................................................................... 148 Documento de aprendizaje .............................................................................................. 148

NDICE DE TABLAS Y FIGURAS

FIGURA 1. REPRESENTACIN GENERAL DE UN SISTEMA DE INFORMACIN.............................. 18 FIGURA 2. MODELO EN CASCADA ....................................................................................... 25 FIGURA 3. MODELO ITERATIVO E INCREMENTAL................................................................... 26 FIGURA 4. MODELO EN ESPIRAL......................................................................................... 28 FIGURA 5. PRCTICAS DE XP ............................................................................................ 35 FIGURA 6. DISPOSICIN FSICA DE UNA OFICINA BAJO LA DISTRIBUCIN "CAVERNAS Y COMN" 36 FIGURA 7. PROCESO DE DESARROLLO SCRUM .................................................................... 38 FIGURA 8. PROCESO FDD ................................................................................................ 43 FIGURA 9. FASES DEL CICLO DE VIDA DE ASD .................................................................... 47 FIGURA 10. UBICACIN DE LAS METODOLOGAS EN RELACIN AL NIVEL DE FORMALIDADREQUERIDO .............................................................................................................. 54

FIGURA 11. LEVANTAMIENTO DE REQUERIMIENTOS ACTUAL ................................................. 59 FIGURA 12. PROCESO DE ANLISIS ACTUAL ........................................................................ 60 FIGURA 13. PROCESO DE CODIFICACIN ACTUAL ................................................................ 61 FIGURA 14. MODELO DEL EQUIPO DE TRABAJO STASD ....................................................... 73 FIGURA 15. FASES DE STASD .......................................................................................... 79 FIGURA 16. ACTIVIDADES DE STASD ................................................................................ 83 FIGURA 17. DOCUMENTOS DE STASD............................................................................... 93 FIGURA 18. INTEGRACIN DEL PROCESO COMPLETO DE STASD .......................................... 99

FIGURA 19. ESTNDARES DE BASE DE DATOS ................................................................... 104 FIGURA 20. ESTNDARES DE CODIFICACIN...................................................................... 107 FIGURA 21. DOCUMENTO DE EVALUACIN DEL PERSONAL .................................................. 109 FIGURA 22. DOCUMENTO DE VISIN ................................................................................. 112 FIGURA 23. PLAN DEL PROYECTO..................................................................................... 114 FIGURA 24. LISTADO DE RIESGOS .................................................................................... 115 FIGURA 25. ACTUALIZACIN DEL LISTADO DE RIESGOS....................................................... 116 FIGURA 26. DIAGRAMA DE CASOS DE USO ......................................................................... 117 FIGURA 27. CASO DE USO DE DEFINICIN DE PERFILES ..................................................... 119 FIGURA 28. DIAGRAMA DE CLASES INICIAL ........................................................................ 120 FIGURA 29. DIAGRAMA INICIAL DE LA BASE DE DATOS......................................................... 121 FIGURA 30. PROTOTIPO DE LA PGINA DE DEFINICIN DE PERFILES ..................................... 122 FIGURA 31. DOCUMENTO DE APRENDIZAJE ....................................................................... 122 FIGURA 32. DIAGRAMA DE CLASES MODIFICADO ................................................................ 124 FIGURA 33. DOCUMENTO DE CASOS DE PRUEBA ................................................................ 125 FIGURA 34. PLAN DE TRABAJO FINAL ................................................................................ 131 FIGURA 35. EVALUACIN DEL PERSONAL MODIFICADA........................................................ 134 FIGURA 36. DOCUMENTO DE APRENDIZAJE FINAL............................................................... 135

INTRODUCCINDesde mediados del siglo XX que inici la computacin se han buscado diferentes metodologas para desarrollar productos de software pero seguimos sin encontrar el mtodo ideal para realizarlo. Esta bsqueda de tantos aos no ha sido intil, al contrario, cada una de las metodologas desarrolladas ha servido para resolver un problema especfico. Sin embargo en ocasiones es complicado aplicarla tal cual aunque se intente resolver un problema similar. Un ingeniero civil nos puede explicar claramente que no es lo mismo construir un edificio de cinco pisos que uno de cincuenta. Cimientos, materiales, personal, maquinaria y planos deben ser distintos porque se estn atacando problemas similares ms no idnticos. Si le preguntamos a un arquitecto que le hace falta considerar al ingeniero nos podra decir que es necesario analizar la luz del sol y el entorno en el que se va a construir porque una construccin no slo debe ser funcional, sino que tambin debe convivir en armona con su entorno. Como podemos ver, problemas similares deben ser atacados de formas distintas pero siguiendo algunos principios bsicos. Esto es lo que se plantea en las metodologas de desarrollo de software, lineamientos bsicos que nos sirven para atacar el problema analizando tanto su magnitud, como su entorno y los riesgos que implica. Por todo esto es que no ha sido posible encontrar un mtodo ideal para el desarrollo de un proyecto de software. La mayor parte de las metodologas han sido creadas para equipos de trabajo grandes y medianos, y aunque es posible adecuarlas al desarrollo de proyectos para equipos de trabajo pequeos no estn diseadas especficamente para ellos.

En la actualidad el software en las empresas es imprescindible, la mayora de ellas cuentan con algn tipo de sistema adquirido para automatizar sus procesos. De ese conjunto de empresas, algunas cuentan con un rea de sistemas dedicada a desarrollar software especfico para cubrir las necesidades de la empresa, mientras que otras, la gran mayora, trabajan con equipos pequeos de desarrollo de software que muchas veces se encargan de crear sistemas para varias empresas. Cuando un sistema es diseado, programado y probado por un equipo de trabajo pequeo, es muy comn que no se siga un mtodo de desarrollo, lo cual lleva a la creacin de un producto que no satisface completamente las necesidades del cliente y es difcil de modificar. Este documento pretende hacer un anlisis de las diversas metodologas que se han utilizado en la historia del software, enfocando principalmente la atencin en las metodologas giles y realizar una propuesta integral de un mtodo enfocado al trabajo de los equipos de trabajo pequeos. El documento se estructura en diversos captulos, al inicio hablamos de los antecedentes, enfocndonos en los problemas que han surgido desde los inicios de la computacin alrededor del desarrollo de software. Posteriormente analizamos brevemente el problema actual, la meta a la que se quiere llegar, el motivo por el cual se quiere llegar, la definicin del alcance general del proyecto y la metodologa ocupada para realizar el trabajo. Inmediatamente despus inicia el primer captulo, en el cual introducimos al lector en los conceptos bsicos de la computacin. Hablamos de algunas definiciones importantes para la mejor comprensin de la tesis, como son qu es la ingeniera de software? o qu es un ciclo de vida? As como explicar brevemente algunos de los lenguajes que utilizaremos en el desarrollo del trabajo.

2

El captulo dos explica detalladamente la evolucin de las metodologas de desarrollo de sistemas desde principios de los aos 60s hasta nuestros das, enfocndonos principalmente en las metodologas giles surgidas en la dcada de los 90s. A continuacin, el captulo tres, abarca el contexto en el cual se desarrolla este trabajo. Explica principalmente la manera en la que se desarrollan los sistemas en la actualidad, enfocndose tambin en el contexto econmico del pas y el contexto de trabajo de la empresa a la cual se le aplicar posteriormente el resultado de la tesis. Para poder entender los beneficios que pretende ofrecer este mtodo, es necesario analizar el proceso actual de desarrollo de software de la empresa citada. Esto se realiza dentro del captulo cuatro, en el cual se hace nfasis en explicar detenidamente la manera en la cual se trabaja actualmente, seguido de algunas observaciones acerca de errores o defectos encontrados en el proceso, las cuales intentaremos resolver mediante la aplicacin del mtodo. Finalmente llegamos al captulo cinco, en este se desarrolla todo el planteamiento del mtodo de trabajo creado pensando en equipos de trabajo de pocos integrantes. Este captulo es el resultado de toda una investigacin basada en el contexto descrito en el captulo tres y tomando las mejores ideas de las metodologas analizadas en el captulo dos; enfocando todo al desarrollo de sistemas en la actualidad. Por ltimo, el captulo seis explica un caso prctico de desarrollo de sistemas usando el mtodo propuesto para demostrar la funcionalidad del mismo en la prctica. Las conclusiones del trabajo y los documentos anexos al mismo continan despus, con lo que se da por terminada esta tesis.

3

ANTECEDENTESA lo largo de este captulo se analizan los antecedentes del desarrollo de software. Tambin se tocan algunos eventos histricos clave que promovieron la creacin de diversas metodologas giles de desarrollo, lo que se llama heterodoxia.

LA CRISIS DEL SOFTWAREEste trmino se entiende como el hecho de que el software construido no slo no satisface los requerimientos ni las necesidades del cliente, sino que adems excede los presupuestos y tiempos planeados. Para entender por qu no satisface las necesidades tenemos que partir del punto de que el software es algo vivo, que cambia constantemente porque los requerimientos se van modificando. La complejidad del software producido se incrementa constantemente. El trmino crisis de software fue acuado por F. L. Bauer en la primera conferencia de ingeniera de software de la OTAN en 1968 en Garmisch, Alemania. Las causas de esta crisis son: Tiempo y presupuesto excedido. Baja calidad del software. Confiabilidad cuestionable. Altos requerimientos de personal para el desarrollo y mantenimiento de los productos. Los proyectos no son manejables y el cdigo difcil de mantener. El software no satisface los requerimientos.

4

En las ltimas dcadas se han desarrollado varios procesos y mtodos para manejar esta crisis. Aun as, los proyectos de software siguen siendo vulnerables porque el software est en una crisis permanente de la que no ha logrado salir. En respuesta a esta crisis, en la dcada de los 90s surgen las metodologas giles, las cuales buscan apartarse del orden y centrar el desarrollo de los proyectos de software ms cerca del caos, sin llegar al extremo. Es decir, evitar documentacin innecesaria y basar el xito del proyecto en la habilidad de las personas, no en el proceso a seguir.

ORTODOXIA METODOLGICALa creacin de las metodologas giles fue motivada por varios factores, entre ellos la antes mencionada crisis del software, la responsabilidad que se le adjudica a las metodologas tradicionales en la gestacin de esta crisis y por la idea de encontrar soluciones alternativas. Desde el nacimiento de la ingeniera de software, los organismos y corporaciones han creado un sin fin de estndares que han poblado los textos de metodologas para la ingeniera de software. De estos, slo algunos son verdaderamente mtodos de trabajo, otros son una coleccin de estndares, otros son marcos de trabajo similares que no aportan nada nuevo, simplemente la herramienta para trabajar una metodologa. Cabe destacar que existe un gran nmero de disciplinas, pero lo importante no es la proliferacin de variedades, sino la sujecin de todos los ejemplares a unas pocas configuraciones o flujos posibles. Estas configuraciones son las que llamamos mtodos. Estos modelos parten del anlisis completo de los requerimientos del usuario. Despus de un largo periodo de interaccin entre los usuarios y los ingenieros, se establece un conjunto de rasgos funcionales y no funcionales del sistema, y toda esta informacin se documenta para ser utilizada en las siguientes etapas, como lo son anlisis, diseo, 5

desarrollo y pruebas. Esto resalta una planeacin bien definida y regulada, como lo dice Carlos Reynoso, Los modelos de los mtodos clsicos difieren bastante en su conformacin y en su naturaleza, pero exaltan casi siempre las virtudes del planeamiento y poseen un espritu normativo1. A finales del siglo XX exista una gran variedad de tipos de procesos o modelos disponibles, el ms convencional era el modelo en cascada o lineal-secuencial, pero a su lado haba muchos ms que convivan apaciblemente entre ellos. Aunque cada uno de ellos se generaba en la crtica o en la percepcin de las limitaciones de algn otro, algunos de los modelos incluan iteraciones, incrementos, recursiones o ciclos de retroalimentacin. Lo importante de la ortodoxia metodolgica es que toda la diversidad existente se ha visto agrupada en un solo conjunto. Por diversas razones todo comenz a verse bajo una nueva luz, en la que se desecha la idea de una documentacin extrema y se cambia por procesos de codificacin ms rpida. Cuando este tipo de cosas suceden, no es posible hablar de otra cosa ms que del cambio.

INICIOS DE LA HETERODOXIANo hace falta analizar todas las metodologas giles de desarrollo de software para encontrar aspectos cuestionables en todos y cada uno de los modelos tradicionales. Se les objeta su rigidez, su necesidad de exigir una estipulacin previa y completa de los

1

Reynoso, Carlos. Mtodos Heterodoxos en Desarrollo de Software.

6

requerimientos, su modelo inapropiado de correcciones, su progresivo distanciamiento de las necesidades del cliente y su lentitud para liberar piezas ejecutables del sistema. En los ltimos aos de la dcada de los 90s, las crticas a las metodologas convencionales aumentaron con gran intensidad y detonaron por todas partes. Durante esta revolucin, muchos de los mtodos tradicionales se tornaron inadmisibles en el desarrollo de software. Evaluaciones a sistemas regidos por ellas revelaron serias fallas y se refresc la idea de la crisis del software, que, como se mencion anteriormente, es un asunto que la historia arrastra desde el nacimiento del software. Las metodologas giles2nacen como una propuesta para eliminar los procesos rgidos y se basan en el cambio. Todas ellas difieren en sus particularidades, pero coinciden en adoptar un modelo iterativo. Este mtodo iterativo se plante desde algunas de las metodologas tradicionales, sin embargo, el exceso de documentacin lo haca complicado y tedioso.

2

Verapndice

7

PLANTEAMIENTO DEL PROBLEMALa utilizacin de software en las empresas es indispensable, sin embargo la mayor parte del desarrollo de aplicaciones se realiza en un tiempo de desarrollo muy limitado y careciendo de las herramientas necesarias, lo cual por lo general lleva a realizar soluciones improvisadas cuando se requieren cambios en las aplicaciones. Actualmente la productividad en el desarrollo de aplicaciones en equipos pequeos es baja y puede mejorarse considerablemente. No existe documentacin para llevar a cabo un preciso control de cambios y mejoras dentro del sistema. Existe tambin mucha resistencia ante la documentacin, se relaciona inmediatamente con prdida de tiempo, lo cual puede ser cierto si se realiza sin un mtodo de aprendizaje. Cada desarrollo de un sistema trae consigo nuevas circunstancias y soluciones, al documentarlas y aprender de ellas se logra refinar el proceso de trabajo. El mtodo de trabajo busca como meta principal, incrementar la productividad y reducir los tiempos y costos en el desarrollo de los sistemas. Lo cual nos lleva al planteamiento del problema en forma de pregunta: La implementacin del mtodode trabajo STASD incrementar la productividad de equipos pequeos en el desarrollo de sistemas?

8

OBJETIVOEl objetivo general de este trabajo es crear un mtodo adecuado a las necesidades especficas de equipos de trabajo pequeos para incrementar la productividad en el desarrollo de las aplicaciones. La productividad en el desarrollo puede medirse mediante los tiempos de desarrollo en los mdulos. Este mtodo, basado en iteraciones y aprendizaje, debe liberar entregables para el usuario en un tiempo mximo de dos semanas. Los objetivos especficos del proyecto son los siguientes: Implementar un mtodo de desarrollo de software que se adecue a las necesidades de los equipos de trabajo pequeos. Reducir el tiempo de desarrollo de los sistemas. Ordenar los procesos. Documentar el desarrollo del sistema.

9

PROPSITOAl terminar el desarrollo de esta tesis, se plantear un mtodo gil de trabajo especficamente diseado para equipos de trabajo pequeos, el cual trabajar mediante un conjunto de procesos creados, tomando en cuenta el tamao del equipo. Este mtodo estar basado en el concepto de una necesidad cambiante, por lo que estar enfocado en iteraciones y aprendizaje principalmente, lo cual permitir que al trmino de cada iteracin se evalen los errores y desviaciones para aprender de ellos y aplicar las soluciones al siguiente ciclo. Esto permitir que cada desviacin en el desarrollo pueda ser analizada y evaluada como una alternativa del sistema, para as lograr satisfacer completamente la necesidad del cliente.

10

JUSTIFICACINLa aplicacin del mtodo de desarrollo servir para imponer orden en el trabajo de desarrollo y evitar la prdida de documentacin. As mismo, para mantener respaldos controlados y actualizados del desarrollo que se encuentra en produccin. El desarrollo de un mtodo de desarrollo gil, especfico para equipos pequeos, permitir a las empresas de desarrollo de software aproximarse a una solucin de una manera distinta en la creacin de sistemas, la cual dejar abierta la posibilidad de cambio. Esto, a su vez, reducir el tiempo de desarrollo y por lo tanto el costo de las aplicaciones.

11

ALCANCEAl finalizar este trabajo, se habr creado un mtodo gil de desarrollo de software enfocado al trabajo en los equipos pequeos. Los pasos definidos dentro del mismo servirn como gua para el desarrollo de sistemas. Estos pasos recorrern el ciclo de vida completo de un sistema, desde el levantamiento de requerimientos hasta la implementacin del mismo, pasando por el anlisis, diseo, codificacin y pruebas. Tambin se generarn plantillas para la documentacin del desarrollo, de esta manera ser posible garantizar un estndar en el trabajo del equipo, lo cual permitir eliminar la dependencia del personal y la rotacin del mismo en diversos roles sin consecuencias. El mtodo producir los siguientes entregables: Un proceso que contemple el sistema como un conjunto y permita realizar la gestin completa del proyecto. Un proceso para cada uno de los elementos del conjunto anterior, que abarque cada fase del desarrollo por iteraciones. Un documento de estndares de codificacin para definir desde un inicio como debe estructurarse el cdigo dentro del sistema. De esta manera los cambios pueden ser realizados por cualquier elemento del equipo, fomentando la propiedad colectiva del cdigo respetando siempre los estndares. Un documento de visin que contiene los requerimientos del usuario, ste ser sometido a revisin cada vez que termine una iteracin. Un documento de anlisis y aprendizaje que ser complementado cada que termine una iteracin, abarcando los puntos ms importantes del ciclo anterior y analizando las vertientes importantes que puedan ayudar a la mejora de la siguiente iteracin. Un documento de diseo, el cual contiene la arquitectura del sistema.

12

Un documento de pruebas creado para que tanto el programador como el usuario pueda realizar las pruebas necesarias y verificar que el sistema est funcionando tal y como es necesario. Es importante recalcar que todos estos documentos, excepto el proceso del desarrollo del proyecto en conjunto y el proceso para cada una de sus iteraciones, ser creado al inicio del proyecto. Los estndares de codificacin por lo general sern definidos una sola vez por lenguaje y equipo de trabajo, el requerimiento inicial slo se har una vez por proyecto, los dems documentos de anlisis, diseo y pruebas debern ser creados una vez por iteracin.

13

METODOLOGALa metodologa de investigacin se basa en el anlisis de los procesos tal cual se encuentran actualmente dentro de los equipos de trabajo pequeos, de esta manera podr proponer mejoras a los puntos dbiles y solidificar los puntos fuertes. Anlisis de procesos actuales. Investigacin de soluciones a problemas similares. Investigacin de alternativas de desarrollo de sistemas. Compilacin de metodologas de desarrollo existentes. Creacin de un mtodo especfico para solucionar los problemas actuales.

14

CAPTULO I. MARCO CONCEPTUAL

En este captulo se explican conceptos bsicos importantes para entender el desarrollo del trabajo en general.

I.1. INGENIERA DE SOFTWARELa IEEE ComputerSociety define la ingeniera de software como: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).3 Lo cual se traduce como la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software; esto es, la aplicacin de la ingeniera al software, as como el estudio de los enfoques que lo abarcan.

3

IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.

16

I.2. SISTEMA DE INFORMACINSe puede definir un sistema de informacin como un conjunto de elementos que interactan entre s para apoyar las decisiones y actividades de un organismo. Para que un sistema de este tipo pueda operar es necesario un recurso humano que interacte con l. Las cuatro actividades bsicas de un sistema de informacin son: entrada, almacenamiento, procesamiento y salida de informacin. Entrada de informacin: Es el proceso mediante el cual el sistema toma los datos que requiere para procesar la informacin. Almacenamiento de informacin: Esta es una de las actividades ms importantes, debido a que el sistema puede recordar informacin guardada anteriormente. Procesamiento de informacin: Es la capacidad del sistema para realizar clculos de acuerdo a una secuencia de operaciones establecida previamente. Estos clculos pueden realizarse con base en datos recin recopilados por el sistema o con datos almacenados. Esta caracterstica de los sistemas de informacin permite el manejo y la transformacin de los datos fuente en informacin utilizada para la toma de decisiones. Salida de informacin: Esta actividad devuelve la informacin procesada al exterior. Es importante aclarar que la salida de informacin puede ser en forma de entrada de datos para otro sistema de informacin.

17

Almacenamiento de informacin Entrada de informacin Procesamiento de informacin Salida de informacin

Figura 1. Representacin general de un sistema de informacin

I.3. CICLO DE VIDAEs un modelo conceptual utilizado en el manejo de proyectos que describe las etapas del desarrollo de un sistema de informacin partiendo de un estudio de viabilidad, hasta el anlisis del mantenimiento de la aplicacin terminada. Dentro de este documento analizaremos varios modelos de ciclos de vida, entre ellos el modelo en cascada, que fue el modelo de ciclo de vida original. Por lo general un modelo de ciclo de vida contiene los siguientes puntos: 1. Evaluacin del problema. 2. Definicin de los requerimientos. 3. Anlisis y diseo de la solucin. 4. Desarrollo del sistema. 5. Implementacin. 6. Mantenimiento.

18

I.4. SOFTWARESe denomina software a todos los elementos intangibles de una computadora. Todos aquellos que hacen posible la realizacin de una tarea especfica. La definicin de la IEEE en su estndar 729 dice que el software es la suma total de los programas de cmputo, procedimientos, reglas, documentacin y datos asociados que forman parte de las operaciones de un sistema de cmputo. Este trmino fue utilizado por primera vez por John W. Tukey para referirse a toda la informacin procesada por los sistemas informticos, programas y datos.

I.5. BASE DE DATOSEn computacin, una base de datos se puede definir como un conjunto estructurado de datos almacenados en una computadora a los cuales se tiene acceso mediante un sistema para resolver consultas. El uso de bases de datos en sistemas es casi imprescindible, la mayor parte de los sistemas que existen ocupan bases de datos para el manejo de su informacin as como para su propia configuracin. Para la explotacin de las bases de datos, existen los sistemas denominados Database Management System (DBMS), este tipo software est diseado para el manejo y gestin de las bases de datos. Los DBMS ms comunes son Oracle, DB2, Microsoft SQL Server, MySQL, entre otros.

19

I.6. UMLUML (UnifiedModelingLanguage) significa Lenguaje Unificado de Modelado;es un lenguaje estndar para especificar, visualizar, construir y documentar los artefactos de los sistemas de software4. El modelado es una parte esencial en el proceso de desarrollo de software, A modelplaystheanalogous role in software developmentthatblueprints and otherplans (sitemaps, elevations, physicalmodels) play in thebuilding of a skyscraper.5, lo que significa que un modelo, en el desarrollo de software, juega un papel anlogo al que juegan los planos en la construccin de un rascacielos. UML se ha vuelto el estndar de facto (impuesto por la industria y los usuarios) para el modelado de aplicaciones de software6, ya que ofrece un estndar para describir un modelo, incluyendo aspectos conceptuales como son los procesos de negocios o funciones del sistema, as como aspectos concretos como expresiones de lenguajes de programacin y esquemas de bases de datos. UML es un lenguaje, no es un mtodo ni un proceso, y se utiliza solamente como apoyo para definir un sistema. Por lo que se puede aplicar de distintas formas para servir de soporte a una metodologa de desarrollo de software. En la versin 2.0 de UML se tienen 13 diagramas divididos en tres categoras.

4

Braun, Davis. Unified Modeling Language (UML) Tutorial Object Management Group, Introduction to OMGs Unified Modeling Language (UML)

5

6

Anacleto, Valerio. Introduccin a UML 2.0

20

Diagramas de estructura: Hacen nfasis en los elementos que deben existir en el sistema modelado. o Diagrama de clases o Diagrama de componentes o Diagrama de objetos o Diagrama de estructura compuesta o Diagrama de despliegue o Diagrama de paquetes Diagramas de comportamiento: Hacen nfasis en lo que debe suceder en el sistema modelado. o Diagrama de actividades o Diagrama de casos de uso o Diagrama de estados Diagramas de interaccin: Es un subtipo de diagramas de comportamiento que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado. o Diagrama de secuencia o Diagrama de comunicacin o Diagrama de tiempos o Diagrama de vista de interaccin

I.7. HERRAMIENTAS CASECASE (Computer-adided software engineering) es el uso de herramientas de software para asistir en el desarrollo y mantenimiento de software. Las herramientas usadas para ayudar de esta manera son conocidas como Herramientas CASE.

21

Todos los aspectos del ciclo de vida del desarrollo de software pueden ser apoyados por este tipo de herramientas. Muchas de estas herramientas incluyen la generacin automtica de cdigo o el modelado de bases de datos. Algunas veces, las herramientas CASE son separadas en tres tipos: Upper CASE: Son herramientas que se enfocan a la fase de anlisis (en ocasiones tambin a la fase de diseo) del ciclo de vida del desarrollo de software. Lower CASE: Este tipo de herramientas sirven para apoyar la generacin de esquemas de bases de datos, codificacin de programas, implementacin y pruebas. I-CASE: Las herramientas de este tipo integran el tipo Upper CASE y Lower CASE en una sola herramienta.

22

CAPTULO II. MARCO TERICO

Desde la dcada de los 60s se han ocupado diversos mtodos de desarrollo de software, conforme ha avanzado la industria se han ido modificando para cubrir, en su mayor parte, las necesidades de la poca. Dentro de este captulo se desarrolla una breve explicacin de modelos de ciclo de vida ms importantes.

II.1. MODELOS DE CICLOS DE VIDA

II.1.1. Modelo en cascadaUno de los pasos ms importantes para el desarrollo de software fue aquel que se plasm en el denominado modelo en cascada. Dicho modelo sirvi para sentar las bases del anlisis estructurado, el cual fue uno de los precursores del camino hacia la aplicacin de prcticas estandarizadas dentro de la ingeniera de software. Este mtodo fue propuesto por Winston Royce en un documento llamado ManagingtheDevelopment of Large Software Systems [Royce, 1970], este modelo intentaba proponer una analoga de lnea de ensamblaje de manufactura para el proceso de desarrollo de software. El modelo propuesto por Royce surge como respuesta al modelo codificar y probar que predominaba en la dcada de los 60s. En esta poca existan ya modelos iterativos

24

e incrementales pero no estaban formalizados dentro de una metodologa. Debido a esto, la idea de tener un modelo que ordenara el proceso de desarrollo de una manera sencilla y fcil de llevar a la prctica hizo que el modelo en cascada tuviera una gran promocin. Este modelo se basaba en una serie de etapas que tenan una entrada y una salida predefinida. El proceso era desarrollado en forma de cascada, ya que se requera la terminacin del proceso anterior para poder iniciar con el siguiente. Esto haca que la definicin de los requerimientos se congelara en una fase temprana del desarrollo, lo cual haca que cualquier cambio en ella requiriera un gran esfuerzo. Otra opcin era no permitir cambio alguno en los requerimientos una vez que se iniciara el desarrollo.

Anlisis

Diseo

Implementacin

Pruebas

Liberacin

Figura 2. Modelo en cascada

25

II.1.2. Modelo iterativo e incrementalLa rigidez del modelo en cascada hizo que fueran surgiendo diversos procesos iterativos que pretendan manejar de una manera ms eficaz lo impredecible del desarrollo de software mitigando los riesgos en forma temprana. Procesos de los cuales se desprenden diversas instancias, como es el modelo iterativo e incremental. La idea de este modelo es basar el desarrollo del software en iteraciones e ir construyendo la aplicacin de forma progresiva, agregando funcionalidad sucesivamente. Cada iteracin representa un proyecto ms pequeo, el cual est compuesto por cada una de las fases de desarrollo (requerimientos, anlisis, diseo, implementacin, pruebas). Los incrementos estn dados por la funcionalidad que se va agregando al software de forma iterativa. Gracias a estas iteraciones, se va obteniendo la retroalimentacin necesaria que era frenada en el momento en el que terminaba la fase de requerimientos en el modelo en cascada. La ventaja de los modelos iterativos, es que fomentan el cambio en forma temprana y proponen un control de cambios definido y estructurado que permite al usuario el ajuste de requerimientos.

Diseo

Implementacin

Anlisis

Pruebas

Liberacin

Figura 3. Modelo iterativo e incremental

26

II.1.3. Modelo en espiralEl modelo en espiral fue desarrollado por Boehm en 1988, surge de la idea de adoptar un modelo iterativo con un temprano anlisis de riesgos.El modelo en espiral, de carcter iterativo en sus primeras fases, plantea la necesidad de realizar al principio diversas iteraciones dirigidas a mitigar los riesgos ms crticos relevados en el proyecto mediante la realizacin de prototipos o simulaciones de tipo desechables tendientes a probar algn concepto7. Cuando los prototipos son verificados, inicia una serie de iteraciones como: determinar objetivos, evaluar, desarrollar y planear. Por medio de stas, se procura tener la retroalimentacin de manera temprana. Con el modelo de cascada, se implementaba el software al momento que se tena el diseo detallado y validado; lo cual consista una falla importante del mismo, ya que no permita la posibilidad de cambios despus de iniciar la construccin. Barry Boehm describe en su artculo Anchoringthe Software Process, publicado en 1995, tres hitos crticos usados en cualquier proyecto para planificar y controlar el progreso del mismo. Estos hitos del ciclo de vida son: Objetivos. Arquitectura. Capacidad operacional inicial. En el modelo en espiral se manejan las siguientes fases:

7

Amaro Caldern, et. al. Metodologas giles, p. 5.

27

Primera fase (Anlisis):Abarca la definicin del alcance del software y la construccin el plan de desarrollo del sistema. Segunda fase (Diseo): Incluye la definicin de la arquitectura del sistema, el refinamiento de los objetivos y el alcance del sistema. Tercera fase (Implementacin): Consiste en la implementacin del software. Cuarta fase (Pruebas): Abarca las pruebas de la aplicacin. Quinta fase (Liberacin): Liberacin del primer entregable del sistema. Estas fases funcionan independientemente del proceso de desarrollo elegido y permiten una estandarizacin de entregas del proyecto.

Diseo

Anlisis

Implementacin

Prototipo #1 Prototipo #2

Producto Final Pruebas Liberacin

Figura 4. Modelo en espiral

28

II.1.4. RUP (RationalUnifiedProcess)RUP es un marco de trabajo que engloba un proceso iterativo de desarrollo de software junto con el lenguaje de modelado UML. Fue creado por Rational Software Corporation, una divisin de IBM, y es uno de los primeros procesos vendidos como productos. Realmente RUP no es un proceso de desarrollo, es ms que nada un marco de trabajo adaptable para que las organizaciones de desarrollo seleccionen los elementos que sean apropiados para sus necesidades. El ciclo de vida de RUP se divide en cuatro fases llamadas Incepcin, Elaboracin, Construccin y Transicin. Estas fases se dividen en iteraciones, cada una de las cuales produce una pieza de software demostrable. La duracin de cada iteracin puede extenderse de dos semanas hasta seis meses. Las fases son: Incepcin: Significa comienzo. Se especifican los objetivos del ciclo de vida del proyecto y las necesidades de cada participante. Se identifican los casos de uso que orientarn la funcionalidad. Se disean arquitecturas candidatas y se estima la duracin y presupuesto de todo el proyecto. Elaboracin: Se analiza el dominio del problema y se define el plan del proyecto. Se describen a detalle la infraestructura y el ambiente de desarrollo, as como el soporte de herramientas de automatizacin. Al cabo de esta fase debe estar identificada la mayora de los casos de uso y los actores, debe quedar descrita la arquitectura del software y se debe crear un prototipo de ella. Al final de la fase se realiza un anlisis para determinar los riesgos y se evalan los gastos hechos contra los planeados. Construccin: Se desarrollan, integran y verifican todos los componentes y rasgos de la aplicacin. Se considera esta fase como un proceso de manufactura, en el que se debe enfatizar en la administracin de los recursos y el control de costos, agenda y calidad. Los resultados de esta fase deben ser

29

creados tan rpido como sea posible y se debe compilar tambin una versin de entrega. Esta fase es la ms prolongada de todas. Transicin: Comienza cuando el proyecto est lo suficientemente maduro para ser entregado. Se corrigen los ltimos errores y se agregan los rasgos propuestos. La fase consiste en pruebas, capacitacin y liberacin del producto, se produce tambin la documentacin del mismo. A travs de las fases, se desarrollan paralelamente nueve workflows o disciplinas: Modelado de Negocios, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue, Gestin de Configuracin y Cambio, Gestin de Proyecto y Gestin del Entorno.

II.2. METODOLOGAS GILESUn enfoque para el desarrollo de software bastante revolucionario naci al inicio de la dcada de los 90s; iba en contra de la creencia de que mediante procesos altamente definidos y detallados se lograra obtener el desarrollo de software en tiempo, por debajo del presupuesto y con la calidad requerida. El enfoque diseccionado hacia las metodologas giles fue planteado por primera vez por James Martin en 1991 y se dio a conocer con el mismo nombre que su libro, RAD o Rapid ApplicationDevelopment [Martin, 1991]. Esta visin consiste en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que

30

generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo.8 Es necesario mencionar que las metodologas giles no inventaron los procesos iterativos e incrementales, ya que estos se utilizaban en las metodologas tradicionales. En 1996, Kent Beck es llamado como asesor de proyecto Chrysler

ComprehensiveCompensationpayrollsystem.Dada la poca calidad del sistema que se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de cero utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema, que administra la liquidacin de aproximadamente 10.000 empleados, el cual consiste de 2.000 clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi respetando el calendario propuesto.9 Gracias al xito obtenido, Beck da origen a la metodologa XP (eXtremeProgramming); iniciando el movimiento de metodologas giles. En febrero 11 a 13 de 2001, diecisiete personas se encontraron en el SnowbirdSki Resort de las montaas Wasatch de Utah. Haba representantes de las diversas metodologas giles de desarrollo buscando lo mismo, una alternativa al desarrollo de

8

Amaro Caldern, et.al.Metodologas giles, p. 6. Op. cit., p. 7.

9

31

software actual. Lo que surgi de esa reunin fue el Manifestofor Agile Software Development (Manifiesto para el Desarrollo gil de Software)10. Este manifiesto es de suma importancia dentro del movimiento de las metodologas giles. Representa una iniciativa conjunta de los principales responsables de los procesos giles existentes para lograr unificar principios propios compartidos por las diversas metodologas y poder crear un marco de trabajo que contribuya al mejoramiento del desarrollo gil de software. Uno de los principales objetivos del encuentro en el que se gener dicho manifiesto fue el de extraer un factor comn de los principios esenciales que serviran de base para cualquier metodologa gil. Con base en este manifiesto podemos entender que lo principal en las metodologas giles es la respuesta al cambio. Porque todos los procesos evolucionan de una manera u otra, lo cual nos obliga a modificar los sistemas que los administran de la misma manera, de lo contrario se quedaran rezagados y dejaran de ser tiles. Podemos nombrar algunas de las metodologas giles ms destacadas en la actualidad: XP Extreme Programming Scrum Crystal Clear DSDM DynamicSystemsDevelopmentMethod FDD FeatureDrivenDevelopment ASD Adaptive Software Development

10

Ver apndice

32

A continuacin explicar brevemente dichas metodologas ya que posteriormente haremos referencia a ellas.

II.2.1. XP Extreme ProgrammingAunque esta no fue la primera metodologa, si fue la iniciadora del movimiento de metodologas giles de desarrollo. Extreme ProgrammingExplained fue el primer libro publicado para esta metodologa y fue escrito por su creador, Kent Beck. La imagen mental de Beck al crear XP era de perillas en un tablero de control. Cada perilla representaba una prctica que,por su experiencia, saba que trabajaba bien. Entonces decidi girar las perillas al mximo para ver que ocurra, as fue cmo surgi XP. Los principios de XP definidos por Beck son: El Juego de Planeamiento: Rpidamente determinar el alcance de la siguiente liberacin mediante la combinacin de prioridades del negocio y estimaciones tcnicas. A medida que la realidad va cambiando el plan debe actualizarse. Entregas pequeas y frecuentes: Colocar un sistema simple en produccin rpidamente, luego liberar nuevas versiones en ciclos muy cortos. Metforas del sistema: Llevar a cabo todo el desarrollo con una historia simple y compartida de cmo funciona el sistema en conjunto. Diseo Simple: El sistema deber ser diseado lo ms simple posible, con base en la idea de que el software sencillo y elegante es mucho ms rentable que el complejo y difcil de mantener. Prueba continua: Los programadores escriben pruebas unitarias continuamente, las cuales deben ser ejecutadas sin problemas para que el desarrollo contine.

33

Programacin en pares: Todo el cdigo debe ser escrito por dos personas en una sola mquina. Cada uno realiza la actividad que el otro no est realizando: Mientras uno escribe las pruebas necesarias, el otro piensa en la clase que realizar las pruebas. Propiedad colectiva del cdigo: Cualquiera puede cambiar cdigo en cualquier parte del sistema en cualquier momento. Integracin continua: Integrar y compilar el sistema varias veces por da, cada vez que una tarea se completa. Ritmo sostenible, trabajando un mximo de ocho horas por da: Dado que el desarrollo de software se considera un ejercicio creativo, se estima que hay que estar fresco y descansado para poder hacerlo eficientemente; con ello se motiva a los participantes, se evita la rotacin del personal y se mejora la calidad del producto. Refactorizacin11 continua: Los programadores refactorizan el sistema eliminando duplicacin, mejorando la comunicacin y agregando flexibilidad sin cambiar su funcionalidad. El proceso consiste en una serie de pequeas transformaciones que modifican la estructura interna preservando su conducta aparente. La prctica tambin se conoce como Mejora Continua de Cdigo o Refactorizacin implacable. Todo el equipo en el mismo lugar: El cliente debe estar presente y disponible todo el tiempo para el equipo de desarrollo. Estndares de codificacin: Los programadores escriben todo el cdigo basados en reglas que enfatizan la comunicacin a travs del mismo.

11

. El trmino refactoring fue introducido por W.F. Opdyke y se refiere al proceso de cambiar un sistema

de software [orientado a objetos] de tal manera que no se altere el comportamiento exterior del cdigo, pero que mejore su estructura interna. Para efecto de este documento, hago referencia a l como refactorizacin.

34

Espacio abierto: Es preferible una sala grande con pequeos cubculos o sin divisiones. Reglas justas: El equipo tiene sus propias reglas a seguir, las cuales pueden cambiar en cualquier momento. En XP se piensa que no existe un proceso que sirva para todos los proyectos.Equipo completo

Propiedad colectiva

Desarrollo basado en pruebas

Estndares de codificacin

Pruebas del cliente

Programacin en pares Diseo simple

Reestructuracin

El juego del planeamiento

Integracin continua

Paso sustentable

Metfora

Pequeas liberaciones

Figura 5. Prcticas de XP

Se puede observar que muchas de las prcticas propuestas contribuyen a maximizar la comunicacin entre las personas, permitiendo una mayor transferencia de conocimiento entre los desarrolladores y con el cliente, quien tambin es parte del equipo. La idea es reunir a todas las personas que integran el equipo en una misma oficina manteniendo los escritorios al centro, con una computadora y dos sillas colocadas de manera que permita la programacin en pares. Es as como se logra el objetivo de maximizar la comunicacin y la transferencia de informacin. Esta distribucin del espacio se conoce como cavernas y comn. 35

Figura 6. Disposicin fsica de una oficina bajo la distribucin "cavernas y comn"

Extreme Programming impone un alto nivel de disciplina entre los programadores, lo que permite mantener un mnimo nivel de documentacin que a su vez se refleja en una gran velocidad de desarrollo. Sin embargo, esto es tambin una desventaja, ya que debido a la falta de documentacin es imposible hacer persistir una arquitectura y dems cuestiones de anlisis, diseo e implementacin, aun despus de haber concluido el proyecto.

II.2.2. ScrumEsta metodologa se define como un proceso de desarrollo iterativo, incremental y emprico que intenta obtener ventajas en comparacin con los procesos definidos,por medio de la aceptacin de la naturaleza catica del desarrollo de software. El mismo surge e n 1986 , de un artculo de la Harvard Business Review titulado The New NewProductDevelopmentGame de HirotakaTakeuchi e IkujiroNonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente

36

innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995.12 Scrumhace nfasis en prcticas y valores de la administracin de proyectos por encima de las dems disciplinas de desarrollo. Durante el proceso se generan diversos entregables. Al inicio del proyecto se define el ProductBacklog, que contiene los requerimientos funcionales y los no funcionales que debe contener el sistema. Estos deben estar especificados de acuerdo a las convenciones de la organizacin y a partir de ah se definen las iteraciones conocidas como Sprint. Caractersticas del Sprint: Duracin:La duracin aproximada de un Sprint es de un mes. Sprint Backlog: Es un subconjunto del ProductBacklog, que abarca los requerimientos especficos por cumplir en el Sprint correspondiente. Scrum Master:Este rol se asigna a un miembro del equipo y puede variar con respecto a cada Sprint. Su labor es llevar a cabo la administracin de la iteracin. ScrumDaily Meeting:Es una reunin diaria de no ms de 15 minutos que tiene como finalidad tener retroalimentacin sobre las tareas y obstculos del da anterior. Sprint Review: ste se realiza al final de cada Sprint para evaluar los artefactos construidos y comenzar el planteamiento del siguiente Sprint.

12

Amaro Caldern, et. al. Metodologas giles, p. 18

37

ScrumDai ly Meeting

Iteracin Sprint Backlog Sprint Review

Seleccin del ProductBacklog

Reunin retrospectiva

ProductBacklog

Visin

Figura 7. Proceso de desarrollo Scrum

Ken Schwaberdefine la base de Scrum de la siguientemanera The heart of Scrum lies in the iteration. The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the heart of Scrum's productivity.13,lo cual se traduce como: El corazn de scrum radica en la iteracin. El

13

Schwaber, Ken. Agile Project Management with Scrump. 6.

38

equipo analiza los requerimientos, considera la tecnologa disponible y evala sus habilidades y capacidades propias. Entonces, colectivamente determina como construir la funcionalidad, modificar su enfoque diariamente conforme encuentra complejidades, dificultades y sorpresas nuevas. La intencin de Scrum es la de maximizar la retroalimentacin sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Es necesario mencionar que aunque su uso se est extendiendo cada vez ms dentro de las metodologas giles, Scrum no propone el uso de ninguna prctica de desarrollo en particular, sin embargo, es comn su uso como marco gil de administracin de proyectos combinado con cualquier otra metodologa gil de desarrollo.

II.2.3. Crystal ClearLas metodologas Crystal han sido impulsadas por AlistairCockburn. Las cuales representan un enfoque gil, enfatizndose en la comunicacin y con cierta tolerancia que la hace ideal en los casos en los que la disciplina exigida por XP sea inaplicable. Crystal Clear es el mtodo ms gil de la serie y de la que ms documentacin se tiene. Crystal maneja iteraciones cortas con una retroalimentacin frecuente por parte del cliente, minimizando de esta manera la necesidad de productos intermedios. Por esto, al igual que con XP, es necesario involucrar al cliente como parte del equipo para realizar validaciones y para participar en la definicin de los requerimientos del software.

II.2.4. DSDM DynamicSystemsDevelopmentMethodDe las metodologas aqu planteadas, sta es la nica surgida de un consorcio formado originalmente por 17 miembros fundadores en enero de 1994. El objetivo principal era 39

producir una metodologa de dominio pblico que fuera independiente de las herramientas y pudiera ser utilizado en proyectos de tipo RAD (Rapid ApplicationDevelpment). Tomando las mejores prcticas que se conocan en la industria en ese momento junto con la experiencia de sus fundadores, liber la primera versin de de DSDM a principios de 1995. A partir de ah, este mtodo fue bien recibido por la industria, que empez a utilizarlo y a capacitar al personal en las prcticas y valores del DSDM. Debido al gran xito, el consorcio comision al Presidente del Comit Tcnico, Jennifer Stapleton, la creacin de un libro que explorara la realidad al implementar el mtodo. El libro, titulado DSDM: DynamicSystemsDevelopmentMethod, es usado como gua para el anlisis posterior de DSDM. Dado el enfoque hacia proyectos de caractersticas RAD esta metodologa encuadra perfectamente el movimiento de las metodologas giles. Su estructura fue guiada por estos nueve principios: 1. Involucrar al usuario es imperativo. 2. Los equipos de DSDM deben tener el poder para tomar decisiones. 3. El foco est puesto en la entrega frecuente de productos. 4. La conformidad con los propsitos del negocio es el criterio esencial para la aceptacin de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos estn especificados en un alto nivel. 8. Las pruebas son integradas a travs del ciclo de vida. 9. Un enfoque cooperativo entre todos los interesados es esencial. DSDM define cinco fases en la construccin de un sistema, las cuales son:

40

Estudio de factibilidad: Es una pequea fase que propone DSDM para determinar si la metodologa se ajusta al proyecto. Estudio del negocio: Durante esta etapa se involucra al cliente de forma temprana para tratar de entender la operacin que sistema deber automatizar. Este estudio sienta las bases para comenzar el desarrollo, definiendo las caractersticas de alto nivel que deber contener el software. Iteracin del modelo funcional: En esta etapa se baja a detalle las caractersticas identificadas previamente. Iteracin del diseo y construccin: Una vez que se tiene el detalle de las caractersticas, se inicia el diseo y la construccin de los componentes de software. Implantacin: Se implementa el sistema en produccin con la previa aceptacin del cliente. Descontando la primera fase que es realizada slo una vez al inicio del proyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo, las dems fases presentan las caractersticas del modelo iterativo e incremental. Sin embargo, lo que diferencia a DSDM de dicho modelo son los principios alrededor de los cuales se estructura y que hacen nfasis en los equipos de desarrollo, en la retroalimentacin con el cliente y en las entregas frecuentes de productos. Para conocer si es aplicable la metodologa DSDM a un proyecto es necesario plantear varias preguntas. Estas se deben referir a las caractersticas que, al cumplirse, permitirn utilizar el enfoque RAD de construccin en un proyecto. Si se califica con estas preguntas, se tendrn las siguientes caractersticas que refieren a la aplicacin de DSDM: Son proyectos interactivos con la funcionalidad visible en la interfaz del usuario. De media o baja complejidad de desarrollo. Pueden ser divididos en componentes de funcionalidad ms pequeos si la aplicacin grande. 41

Acotados en el tiempo. Con flexibilidad en los requerimientos. Con un grupo de usuarios bien definido y comprometido con el desarrollo. Podemos observar que DSDM deja las bases sentadas para el anlisis sobre la aplicacin de la metodologa a un espectro bien definido de proyectos de software. Sin embargo, este mtodo de trabajo no tiene ninguna prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico y funciona tanto para el modelo de programacin orientado a objetos como para el modelo de programacin estructurada. Lo nico que si sugiere el mtodo es la generacin de un conjunto mnimo de modelos necesarios para la progresin de la entrega del software y la facilidad de mantenimiento. Estos modelos se definen antes de iniciar el desarrollo y deben ser revisados en las iteraciones siguientes para validar su contenido. Algo importante acerca de DSDM es su aceptacin en la industria y su refinamiento continuo, lo que indica que las metodologas giles no son slo utilizadas por pequeos grupos de desarrollo, sino que tambin estn siendo utilizadas por las grandes corporaciones.

II.2.5. FDD FeatureDrivenDevelopmentAlrededor de 1998, Peter Coad junto con Jeff De Luca participaran en la creacin de FDD, una metodologa que presenta las caractersticas de un proceso gil [Coad, 1998]. FDD se estructura alrededor de de la definicin de caractersticas o rasgos (features) que representan la funcionalidad que debe contener el sistema. A diferencia de otros mtodos, ste no cubre todo el proceso de desarrollo del software, se centra solamente en las fases de diseo y construccin.

42

El ciclo de vida propuesto por FDD est compuesto por cinco procesos, dos de los cuales se realizan tantas veces como iteraciones se planifiquen en el desarrollo.

Desarrollar modelo general

Construir lista de rasgos

Planear por rasgo

Disear por rasgo

Construir por rasgo

Figura 8. Proceso FDD

La primera actividad consiste el en desarrollo de un modelo general, que es algo similar a la construccin de la arquitectura de software. En la creacin de este modelo participan tanto los usuarios como los desarrolladores. Mediante el esfuerzo de ambas partes se pretende lograr lo que el modelo en espiral propona en sus primeras iteraciones: un conocimiento global de la aplicacin a construir, el entendimiento del negocio, un primer bosquejo de los rasgos del sistema y la definicin de restricciones. La segunda actividad, construir una lista de rasgos, comienza tomando el bosquejo de rasgos generado en la primera actividad para refinar las funcionalidades incluidas. Una vez que se han identificado, se agrupa jerrquicamente para poder estructurar el trabajo de desarrollo. La tercera actividad, planear por rasgo, toma como entrada la lista generada en la actividad anterior y establece los tiempos de las futuras iteraciones. En esta actividad participan el lder de proyecto, el lder de desarrollo y el programador jefe. Parte de este proceso tambin incluye la delegacin de responsabilidades a los programadores jefe que sern dueos de las features.

43

Las ltimas dos actividades, disear por rasgo y construir por rasgo, estn relacionadas con la parte productiva del proceso en el que se construye la aplicacin de manera incremental. Empezando por el diseo que toma los rasgos correspondientes a la iteracin, el equipo de desarrollo liderado por el programador jefe identifica las clases, atributos y mtodos que realizan la funcionalidad requerida. Mediante la utilizacin de diagramas de secuencia de UML, se verifica que el diseo pueda ser implementado. Posteriormente, en la fase de construir por rasgo, se procede a crear las clases definidas en la actividad anterior. En relacin a las actividades de manejo de proyectos en FDD se recomienda una reunin semanal entre el lder de proyecto y los programadores jefe; la cual debe ser breve, no ms de 30 minutos, y en la cual se reporta el estatus de los features que estn siendo construidos por cada grupo. Una de las ventajas de FDD es que no requiere un modelo especfico de proceso y se complementa con otras metodologas. Adems de ser un proceso gil orientado a la funcionalidad del software por sobre las tareas.

II.2.6. ASD Adaptive Software DevelopmentASD fue creada por JimHighsmitha finales de la dcada de los 90s. Entones se crea que la optimizacin era la mejor solucin para problemas de complejidad creciente; esta metodologa pretende ofrecer una alternativa a esta idea.

44

Este mtodo gil pretende abrir una tercera va entre el desarrollo monumental de software y el desarrollo accidental, o entre la burocracia y la adhocracia14.Para ello hay que situarse un poco fuera del caos y ejercer menos control que el que se cree necesario. La estrategia se basa en el concepto de emergencia, el cual Highsmithtoma de John Holland, creador del algoritmo gentico e importante investigador en la materia de procesos emergentes. Holland se pregunta, entre otras cosas, cmo hace un macrosistema extremadamente complejo, no controlado de arriba hacia abajo en todas las variables intervinientes (como por ejemplo la ciudad de Nueva York o la Web) para mantenerse funcionando en un aparente equilibrio sin colapsar.15 La respuesta tiene que ver con tres factores: La auto-organizacin. La adaptacin al cambio. El orden que emerge de la interaccin entre las partes. Estos factoreshacen referencia a analogas con los organismos vivientes; los sistemas adaptativos complejos por excelencia. Highsmith usa este anlisis en los proyectos de desarrollo de software y los plantea como sistemas adaptativos complejos; llevando ms lejos esta analoga, interpreta la organizacin empresarial que emprende el desarrollo como un ambiente, sus miembros

14

Amaro Caldern, et. al. Metodologas giles. p. 32. Amaro Caldern, et. al. Metodologas giles. p. 33.

15

45

como agentes y el producto como resultado emergente de relaciones de convivencia y cooperacin. En los sistemas complejos, no es aplicable el anlisis, ya que no puede deducirse el comportamiento del todo a partir de la conducta de las partes, ni sumarse las propiedades individuales para determinar las caractersticas del conjunto. Para la metodologa ASD, las necesidades del cliente son siempre cambiantes. Al iniciar un proyecto, se debe definir una misin para l, determinar las caractersticas y los hitos, y descomponer el proyecto en pasos individuales, de entre cuatro y ocho semanas cada uno. Los pasos iniciales abarcan el alcance del proyecto, mientras que los finales se enfocan en el diseo de una arquitectura, la construccin del cdigo, la ejecucin de las pruebas finales y la implementacin. Los procesos medibles, repetibles y visibles se denominan procesos rigurosos, los cuales proporcionan una estabilidad en un entorno complejo. Sin embargo, procesos como el diseo de del proyecto deberan ser flexibles. La clave para mantener el control radica en los estados de trabajo y no en el flujo de trabajo. ASD propone utilizar el ciclo de vida Especular-Colaborar-Aprender. El proyecto comienza con una fase de especulacin en la cual se lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas que se irn realizando. El uso del verbo Especular demuestra el inters de Highsmith en demostrar la naturaleza impredecible de los procesos complejos. En esta etapa se fija un rumbo determinado para ser seguido en el desarrollo, sabiendo desde entonces que no ser el punto en el que terminar. En cada iteracin se aprendern nuevas funcionalidades y se entendern viejas cuestiones, lo cual cambiar los requerimientos iniciales. Gracias a su enfoque en la especulacin, ASD permite administrar proyectos de alto cambio y rpido desarrollo que se encuentran en el borde del caos.

46

Highsmith sugiere que cada ciclo se componga de una mezcla entre funcionalidades crticas, tiles y opcionales, previniendo los posibles retrasos que puedan existir mediante el movimiento de las funcionalidades de menor prioridad a futuros ciclos. La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se constituye la funcionalidad definida durante la especulacin. ASD define un Componente como un grupo de funcionalidades o entregables a ser realizadas durante un ciclo iterativo. Durante cada iteracin existe la posibilidad de explorar nuevas alternativas, pudiendo alterar eventualmente el rumbo del proyecto.

Bucle de aprendizaje

Iniciacin del proyecto

Plan adaptativo de ciclo

Ingeniera concurrente de componentes

Revisin de calidad

QA final y entrega

Especular

Colaborar

Aprender

Figura 9. Fases del ciclo de vida de ASD

La fase final de ASD, Aprender, consiste en la revisin de calidad que se realiza al final de cada ciclo. En la misma se analizan cuatro categoras de cosas para aprender [Highsmith, 2002]: Calidad del resultado desde la perspectiva del cliente. Calidad del resultado desde la perspectiva tcnica. El funcionamiento del equipo de desarrollo y la calidad de las tcnicas que este utiliza. El estatus del proyecto. 47

Las revisiones al diseo, al cdigo o a las pruebas permitirn aprender sobre la calidad de los mismos. Se debe hacer nfasis en aprender sobre los errores o desvos para as poder resolverlos, no en encontrar culpables. Asimismo, esta es la etapa en la que se evaluarn las exploraciones realizadas dando la capacidad de poder modificar la arquitectura del sistema si es que se ha encontrado un camino que se ajusta mejor a las necesidades del usuario o si han cambiado los requerimientos. En las metodologas tradicionales las diferencias entre lo planificado y lo obtenido eran vistas como errores que deban ser corregidos para que cumplieran lo pautado. ASD y las metodologas giles plantean la necesidad de que la retroalimentacin sea para aprender, lo cual nos da un mayor entendimiento respecto al dominio y as poder construir una aplicacin que satisfaga las necesidades del cliente. Por lo que en ambientes complejos, el seguir un plan al pie de la letra produce el producto que pretendamos, ms no el producto que necesitamos. ASD es un marco filosfico basado en la teora de Sistemas Adaptativos Complejos que nos permite aproximarnos a la construccin de software en forma gil utilizando las prcticas que nos resulten convenientes en cada caso.

48

CAPTULO III. MARCO CONTEXTUAL

En la actualidad existe un sinfn de metodologas giles para el desarrollo de software, las cuales han sido creadas en distintas pocas y contextos. Pero por lo general se han desarrollado para resolver un problema en particular, y con base en lo aprendido se han ido solidificando hasta convertirse en metodologas reconocidas. Cada proyecto de desarrollo de software es nico, por ms que las especificaciones sean idnticas a algn otro que se haya hecho antes. Los proyectos y la direccin de proyectos se llevan a cabo en un ambiente ms amplio que el proyecto mismo. Entender este contexto contribuye a asegurar que el trabajo se lleve a cabo de acuerdo con los objetivos de la empresa y se gestione de conformidad con las metodologas de prcticas establecidas de la organizacin.16 El mtodo de desarrollo STASD no es la excepcin y ha sido creado para resolver los problemas actuales que encontramos en el pas en empresas dedicadas al desarrollo de software que trabajan con equipos de trabajo pequeos. Este captulo pretende analizar el contexto actual para el que se desarrolla este mtodo en particular.

16

PMBOK (Cuarta Edicin). p 15.

50

III.1. CONTEXTO ECONMICOAntes que nada debemos situarnos en el contexto econmico actual del pas, el ndice de desempleo es cada vez mayor y para muchas empresas resulta difcil pagar un desarrollo de software adecuado especficamente a sus necesidades, por lo que prefieren adquirir un software comercial y adaptar sus necesidades al sistema o en algunos casos continuar con procesos manuales. Esto afecta directamente a las empresas desarrolladoras de software, ya que por lo mismo es necesario reducir costos para poder ofrecer soluciones a precios ms accesibles. Esto deriva por lo general en la extensin de las jornadas laborales, que llegan a ser de ms de 12 horas diarias en casos extremos; otras empresas optan por la reduccin de los equipos de trabajo, lo cual obliga a la extensin de la jornada laboral para los miembros del equipo restante. El derecho laboral estipula que es parte del compromiso del trabajador ocupar sus energas por el tiempo estipulado en beneficio del empleador; pero tambin la medicina del trabajo repite, con insistencia, que el trabajo continuo, tanto fsico como intelectual, puede ser perjudicial para la salud del trabajador, puede ocasionar agotamiento de sus energas fsicas e intelectuales y, con ello, un menor rendimiento y disminucin de la produccin, siendo el rendimiento inversamente proporcional a la duracin de la jornada laboral. Aunque desde 1919, en la Conferencia Internacional de Washington, se limit la duracin del trabajo a jornadas de ocho horas diarias y esta convencin fue ratificada por los principales pases de Amrica y Europa; es una realidad que las jornadas laborales en las empresas de desarrollo de sistemas distan mucho de ser de ocho horas.

51

Todo esto nos lleva a pensar que la solucin que se ha venido ocupando no es la correcta, ya que los costos del software siguen siendo elevados y el tiempo de desarrollo muy extenso. Por lo tanto es imprescindible pensar en una solucin distinta. Son relativamente pocas las empresas que cuentan con equipos de desarrollo realmente grandes; por lo general aunque se cuente con una amplia plantilla de desarrolladores, estos se encuentran distribuidos en equipos pequeos que se dedican a atender las necesidades de un sistema o un rea de la empresa en especfico. La forma de trabajo y la propia cultura del pas, afecta el proceso de desarrollo de software. Por esto mismo, planteo STASD como un mtodo gil de desarrollo de software alternativo, basado en las prcticas que considero se adecan ms a la manera en la que se desarrolla software en Mxico; con el fin de ser una solucin para las empresas que trabajan con equipos de trabajo pequeos y tienen este tipo de problemas.

III.2. PROCESOS DE DESARROLLO DE SOFTWARELa eleccin de usar o no un proceso depende del grado de predictibilidad que se desee tener en el desarrollo, y actualmente las empresas no se permiten correr riesgos en el desarrollo de proyectos de desarrollo de software. Por un lado encontramos a empresas que poseen manuales de procedimientos para cada una de las tareas relacionadas con el desarrollo de software. Cada actividad realizada por cada persona se encuentra descrita detalladamente de forma escrita y en cualquier momento esta documentacin puede ser consultada si se tienen dudas en algn punto del proceso.

52

Por otro lado tenemos a las empresas en las que la aleatoriedad en cada proyecto es una caracterstica. Se realizan planificaciones a muy corto plazo ya que no existe visibilidad para las personas externas al equipo de desarrollo. Como podremos ver adelante, la mayor parte de las empresas, por ms organizadas que sean, terminan eligiendo la segunda opcin del manejo de procesos sin ser plenamente conciente de la eleccin y de los resultados que sta acarrea. Analizando ambos enfoques de desarrollo de software nos encontramos con dos extremos bien definidos por Highsmith, que son el de Burocracia, representados por las organizaciones con procesos rgidos y bien definidos hasta el ms mnimo nivel de detalles, y el de Adhocracia, que representa el desarrollo catico sin ningn proceso ni visibilidad sobre el estado y el rumbo de los proyectos. En un extremo estamos en un proceso tan pautado que termina por no satisfacer las necesidades del cliente, mientras que en el otro extremo estamos ante la aleatoriedad total que permite slo resultados a corto plazo, ya sean beneficios o prdidas. Si trazamos una lnea uniendo a la Burocracia con la Adhocracia podramos utilizarla para ubicar el grado de formalidad dado por las metodologas que ya fueron tratadas anteriormente. En la Figura 10 Podemos observar que el modelo en cascada es el que ms contribuye al rgimen burocrtico, fomenta el orden de la organizacin mediante una clara divisin en etapas con sus entradas y salidas correspondientes. De igual manera encont