Sunteți pe pagina 1din 166

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

TESIS
QUE PARA OBTENER EL GRADO DE LICENCIADO EN INGENIERA EN COMPUTACIN PRESENTA: OSCAR EMILIANO CECEA FUJIGAKI
ASESOR: M. C. IVAN JOS MRQUEZ LARIOS

MXICO, D. F.

NOVIEMBRE 2010

DEDICATORIA
Dedico 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.

AGRADECIMIENTOS
Es 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.

RESUMEN
Existen 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 .......................................................................................... 30


II.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................................................................................ 58
IV.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 .................................................... 63


IV.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 ...................................................................................... 68


V.1.1. Presentacin............................................................................................................ 68 V.1.2. El proceso creativo .................................................................................................. 69 V.1.3. Estructura ................................................................................................................ 71

V.2. MODELO DEL EQUIPO DE TRABAJO .......................................................................... 71


V.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 ........................................................ 77


V.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 ....................................................................... 82


V.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 ..................................................................................... 89


V.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 ........................................................................................................ 92


V.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 ....................................................................................... 102
VI.1.1. Definicin de estndares ...................................................................................... 102

VI.2. FASE CREATIVA................................................................................................... 107


VI.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 .......................................................................................... 112


VI.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......................................................................................... 117


VI.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 ..................................................................................... 126


VI.5.1. Pruebas de funcionalidad...................................................................................... 126 VI.5.2. Liberacin ............................................................................................................. 127

VI.6. REVISIN DE LAS ACTIVIDADES DE SOPORTE ......................................................... 127


VI.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 ......................................................... 128


VI.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 ............................................................... 143
Documento 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 FORMALIDAD
REQUERIDO .............................................................................................................. 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

INTRODUCCIN
Desde 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.

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.

ANTECEDENTES
A 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 SOFTWARE


Este 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.

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 METODOLGICA
La 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 HETERODOXIA
No 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

Reynoso, Carlos. Mtodos Heterodoxos en Desarrollo de Software.

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.

Verapndice

PLANTEAMIENTO DEL PROBLEMA


La 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?

OBJETIVO
El 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.

PROPSITO
Al 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

JUSTIFICACIN
La 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

ALCANCE
Al 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

METODOLOGA
La 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 SOFTWARE


La 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.

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

16

I.2. SISTEMA DE INFORMACIN


Se 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 VIDA


Es 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. SOFTWARE
Se 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 DATOS


En 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. UML
UML (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.

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

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 CASE


CASE (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 cascada


Uno 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 incremental


La 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 espiral


El 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:

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 GILES


Un 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

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

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 Programming


Aunque 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. Scrum
Esta 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 Clear


Las 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 DynamicSystemsDevelopmentMethod


De 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 FeatureDrivenDevelopment


Alrededor 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 Development


ASD 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 ECONMICO


Antes 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 SOFTWARE


La 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 encontramos uno de los procesos ms ocupados en la actualidad como es el RUP, en una forma completa, construyendo todos los artefactos especificados y realizando todas las actividades planteadas. En otras palabras, estos procesos pretenden definir todas las actividades, roles, entregables y dems aspectos del desarrollo de un proyecto de software, para generar resultados predecibles a lo largo del tiempo. Mediante la clara definicin de las cuestiones involucradas y la posibilidad de controlar el proceso para ajustarlo a posibles desvos, se llega a la Burocracia. 53

Modelo en Cascada

RUP Completo

RUP Agilizado

Codificar y Probar

RAD

Burocracia (Orden) Modelo en Espiral Modelo por Prototipos

Adhocracia (Caos)

Metodologas giles

Figura 10. Ubicacin de las metodologas en relacin al nivel de formalidad requerido

Si nos movemos un poco ms hacia la Adhocracia, nos encontramos con el tema central de esta tesis, las Metodologas giles, entre las que encontramos todas aquellas descritas anteriormente. stas metodologas reconocen la complejidad del software y el carcter emprico que debe tener el desarrollo del mismo; se prefiere sacrificar el proceso para dar libertad a las personas. Sin embargo, esto no quiere decir que termina en un proceso de Codificar y Probar, el cual es simplemente la ausencia de cualquier metodologa, incluyendo las metodologas giles.

III.3. METODOLOGAS ORIENTADAS A PROCESOS


Actualmente nos encontramos con una gran cantidad de empresas con una visin del desarrollo de software orientado a procesos en vez de estar orientado a las personas. Consideran que teniendo un proceso predecible, con etapas y tareas bien definidas, el xito est garantizado independientemente de las personas que cubren los roles. Es decir, en ningn momento existen consideraciones respecto a como la productividad se ve afectada por la gente que trabaja y por las condiciones laborales existentes. 54

Con la experiencia de varios proyectos a lo largo de las ltimas dcadas, AlistairCockburn demuestra que las personas son elementos de primera importancia en cualquier desarrollo. De esto surge uno de los principios fundamentales de todas las metodologas giles que se ve plasmado en uno de los primeros valores del Manifesto: Individuos e interacciones por sobre procesos y herramientas17. El nfasis de todas las metodologas giles est centrado en los individuos y sus interacciones, a diferencia de las metodologas tradicionales en las que impera el proceso y las herramientas como garanta de calidad.

III.4. CONTEXTO DE LA EMPRESA INCORPREA S.A.


Esta empresa se dedica al desarrollo de software especializado para diversas PyMes (Pequeas y medianas empresas). Para esto es indispensable el uso de un proceso de desarrollo con el que actualmente no se cuenta. Debido a que los sistemas creados son pequeos y no exigen una visin a largo plazo, la empresa trabaja con equipos de trabajo de una a tres personas por proyecto. El equipo entero hace un levantamiento de requerimientos y posteriormente dividen las tareas entre los integrantes. La mayor parte de sus desarrollos son realizados de una manera catica, Codificar y Probar. Este proceso se basa en el siguiente flujo de actividades: un programador trabajando en su computadora totalmente aislado del equipo de trabajo, genera cdigo

17

. Ver apndice

55

fuente; una vez que termina, lo compila, corrige los errores y lo vuelve a compilar; cuando ya no tiene ms errores, genera el ejecutable de la aplicacin y lo corre; es entonces cuando prueba el correcto funcionamiento del mismo, depura el cdigo en ese instante hasta corregir aquellos errores que detecta; cuando este proceso iterativo termina, contina con el siguiente componente, mdulo o programa. Las pruebas integrales se realizan hasta que todos los mdulos del sistema han sido codificados y probados individualmente, lo cual degenera en una entrega final que no satisface las expectativas del cliente y no cubre sus necesidades. Lo cual obliga a la empresa a corregir los mdulos de la misma manera en la que fueron creados, aplazando la fecha de entrega y consumiendo recursos por ms tiempo de lo previsto. Esta manera de trabajar vuelve completamente impredecible el proyecto, adems de limitar al equipo de trabajo por la carencia de la informacin necesaria para realizar cambios o modificaciones al desarrollo. Un mtodo diseado especficamente para equipos de trabajo pequeos, que logre resolver gradualmente las necesidades de la empresa, ayudar a recobrar la credibilidad de los clientes y dejar de perder dinero en desarrollos no redituables.

56

CAPTULO IV. PROCESO ACTUAL DE


DESARROLLO

El proceso de desarrollo actual de la empresa es prcticamente nulo, sin embargo el equipo de trabajo realiza algunas actividades previas y posteriores al desarrollo de un sistema, las cuales analizaremos a continuacin.

IV.1. EL PROCESO DE DESARROLLO


El principal problema en el proceso de desarrollo es que est estructurado de una manera muy catica, al inicio parece tener un control excesivo y se inclina un hacia el mtodo en cascada; sin embargo, conforme va avanzando, el desarrollo se va haca el otro extremo y termina siendo simplemente Codificar y Probar.

IV.1.1. Levantamiento de requerimientos


Para este momento, ya se cuenta con un cliente al cual se le vender el producto. El equipo de trabajo realiza una reunin con el cliente para conversar y definir las necesidades actuales, esta reunin no dura ms de una o dos horas. Posteriormente, con una idea de las necesidades del cliente, el equipo revisa lo platicado y genera un Documento de Requerimientos, explicando la base de las necesidades y separando los puntos especficos que debe contener el sistema.

58

Una vez creado este documento, el equipo se vuelve a reunir con el cliente para mostrarle el documento creado y aclarar dudas o agregar algn punto que haya hecho falta. Este proceso se repite varias veces hasta estar seguros que el documento contiene exactamente las necesidades del cliente.

Reunin inicial con el cliente

Revisin del equipo y creacin del documento

Revisin de requerimientos con el cliente

Documento final de requerimientos

Figura 11. Levantamiento de requerimientos actual

Cuando el equipo y el cliente estn seguros que el documento contiene todos los requerimientos del sistema, se da por terminada esta fase y se le entrega al cliente una copia del documento.

IV.1.2. Anlisis del sistema


Aqu es donde el proceso que pareca ser ordenado y metdico comienza a cambiar. El equipo se rene para definir las prioridades de los requerimientos, se define que es lo que debe realizarse primero y se encuentran aquellos componentes que pueden ser desarrollados independientemente del sistema sin afectar el desarrollo completo del mismo. El equipo se divide y a partir de este momento los integrantes comienzan a funcionar como elementos aislados del equipo de trabajo. Cada uno se encargar de una tarea diferente, dependiendo de los mdulos definidos en esta reunin.

59

No se general documento alguno para los procesos, simplemente cada programador se basa en el documento de requerimientos y en lo que entendi en las diversas juntas con el cliente para desarrollar la parte que le fue asignada.

Definicin de prioridades

Asignacin de procesos a los miembros del equipo

Programador

Programador

Programador

Figura 12. Proceso de anlisis actual

A partir de este momento cada programador es responsable de su parte del sistema y cada uno trabaja aislado de los dems miembros del equipo.

IV.1.3. Codificacin del sistema


Como se puede observar, no existe una etapa de diseo del sistema, por lo que muchas veces, funciones que se ocupan en ms de un mdulo suelen ser duplicadas. Ahora que el programador tiene una nocin de lo que debe hacer su mdulo comienza a codificarlo. No existe un estndar de codificacin que regule la manera en la que se realiza esta tarea, por lo que cada programador puede codificar de la forma que desee,

60

incluso utilizar diferentes lenguajes de programacin si la plataforma de desarrollo lo permite18. El programador inicia con la codificacin y pruebas simultneamente; codifica una parte del mdulo, compila el cdigo y lo prueba, corrige inmediatamente los errores que van surgiendo y realiza el mismo proceso una y otra vez hasta que el mdulo que le fue asignado est terminado.

Codifica y compila

Realiza las pruebas

Finaliza el desarrollo del mdulo

Figura 13. Proceso de codificacin actual

Cuando el programador ha terminado la codificacin del mdulo asignado, revisa el documento de requerimientos, consulta con los dems miembros del equipo para saber que mdulos no se han creado, escoge uno dependiendo de las prioridades y repite el mismo proceso de codificacin hasta que est terminado.

18

Plataformas como .Net permiten la utilizacin e interaccin entre distintos lenguajes de programacin,

como lo son Visual Basic y C#.

61

IV.1.4. Integracin y pruebas del sistema


Esta fase inicia cuando todos los mdulos del sistema han sido creados y lo que se hace es juntarlos todos para verificar la funcionalidad del sistema en conjunto. Uno de los problemas ms importantes en esta etapa es lograr que todos los mdulos del sistema sean capaces de interactuar entre si. Por lo que en la mayora de las veces es necesario crear un mdulo nuevo que integre a todos los que han sido creados anteriormente. Esta tarea la realiza slo un miembro del equipo de la misma manera en la que fueron codificados todos los mdulos del sistema, sin embargo, como cada mdulo ha sido codificado de una manera distinta, es necesario que todos los programadores del equipo de trabajo estn presentes para aclarar cualquier duda que pudiera surgir. Una vez logrado que todos los mdulos del sistema interacten en conjunto se da inicio a las pruebas. Estas pruebas consisten simplemente en revisar que cada mdulo funcione tal como lo haca cuando trabajaba independiente a los dems y que el sistema funcione.

IV.1.5. Pruebas del sistema con el cliente


En esta etapa se le entrega la versin final del sistema al cliente, cumpliendo con todos y cada uno de los requerimientos especificados al inicio del desarrollo.Esta etapa finaliza el proceso de desarrollo del sistema. Si se requieren cambios en el sistema es necesario redefinir el documento de requerimientos y realizar el proceso del desarrollo completo de nuevo. Lo cual hace que el proceso se parezca al modelo en cascada, sin embargo no cuenta con las etapas necesarias para serlo. 62

IV.2. OBSERVACIONES DEL PROCESO DE DESARROLLO


El proceso de desarrollo actual tiene bastantes deficiencias, no slo el hecho de carecer de un mtodo para realizar el proceso, sino que tambin con base en la experiencia se ha demostrado que los resultados no son los esperados. A continuacin se presentan algunas observaciones al proceso de desarrollo actual de la empresa Incorprea S.A.

IV.2.1. Levantamiento de requerimientos


La manera en la que los requerimientos son levantados requiere demasiado orden y claridad de las necesidades, lo cual es imposible tener en un desarrollo de software. El equipo de trabajo no inicia el desarrollo del sistema hasta que los requerimientos se encuentran perfectamente definidos, no da espacio a errores o desviaciones del sistema. Lo que degenera en una prolongacin de la fase de levantamiento de requerimientos demasiado grande y retrasa el desarrollo completo del sistema. Otro problema visible dentro de esta manera de trabajar, es que el documento ms importante para el desarrollo del sistema es el que se genera en este momento. Los requerimientos como tal son la base del desarrollo completo, que al ser tan estrictos limitan el alcance y la ampliacin del sistema a corto plazo.

63

IV.2.2. Anlisis del sistema


El principal problema de esta fase es que realmente no es un anlisis del sistema. Es, simplemente, una tarea de asignacin de procesos o mdulos a los distintos programadores del sistema. Cada programador es responsable de leer el requerimiento que corresponde a su mdulo y realizar una idea de cmo crearlo. Esta es la ltima fase en la que el equipo trabaja como tal, a partir de este momento el desarrollo de cada mdulo es realizado por programadores aislados. El principal problema de trabajar con programadores aislados es que los mdulos comienzan a repetir cdigo y funcionalidad, lo que provoca que se retrase aun ms el desarrollo del sistema. No tiene caso tener a dos o ms programadores creando mdulos separados que realicen la misma funcin.

IV.2.3. Codificacin del sistema


Esta etapa es la ms importante, ya que es cuando se comienzan a liberar mdulos terminados o entregables. Sin embargo, estos entregables, nunca llegan al usuario, se van almacenando poco a poco hasta tener el desarrollo completo del sistema. El principal problema de esta prctica, es que no hay manera de revisar y enriquecer o corregir un proceso hasta que se tiene el sistema completo. Aunado a que no existe un estndar de codificacin y cada mdulo se trabaja por separado, esto deriva en un retraso innecesario del proyecto y la calidad con la cual se realiza.

64

IV.2.4. Integracin y pruebas del sistema


Aqu nos enfrentamos con problemas ms graves que han sido arrastrados desde el inicio del proyecto. La codificacin de los mdulos por separado no permite una integracin slida y transparente para formar el sistema, por lo que es necesario recurrir a la prctica realizada en la etapa de la codificacin: Codificar y probar. Las pruebas del sistema realmente no arrojan informacin importante, slo se realizan pruebas para asegurar que el sistema funcione tal y como los programadores creyeron que funcionaba.

IV.2.5. Pruebas del sistema con el cliente


Esta fase final del desarrollo es la que pone al descubierto todas las carencias del proceso actual de la empresa Incorprea S.A. No slo el proyecto ha tomado ms tiempo del determinado, sino que para entonces las necesidades ya no son las mismas y es necesario realizar cambios al sistema. Cuando se analizan las modificaciones al sistema se deja al descubierto que es necesario cambiar una buena parte del desarrollo realizado, lo cual implica ms tiempo de lo estimado, ms recursos y, por lo tanto, una mayor inversin.

IV.2.6. Observaciones finales


El proceso de desarrollo no slo es complicado, sino que carece de un mtodo y se encuentra basado en el caos. Este tipo de trabajo es el que ha hecho que la empresa analizada tenga prdidas econmicas y se encuentre en un momento crtico ya que est perdiendo la credibilidad de sus clientes.

65

Es necesario reestructurar el proceso de desarrollo completamente, para esto analizaremos, en los captulos posteriores, el mtodo STASD aplicado a un caso de estudio.

66

CAPTULO V. MTODO STASD

Este captulo desarrolla completamente el tema central de esta tesis: un mtodo gil para el desarrollo de software para equipos de trabajo pequeos. La descripcin del mtodo consta de la definicin de roles dentro del desarrollo incluyendo los requisitos necesarios para cubrir completamente este papel, la explicacin de cada una de las fases del proceso, los roles responsables de cada una y los entregables necesarios para dar por terminada una etapa del desarrollo.

V.1. INTRODUCCIN A STASD


Esta seccin introduce el mtodo propuesta para equipos de trabajo pequeos. Con base en temas analizados previamente, podemos decir que tenemos una base slida en la cual comenzar a trabajar en una propuesta adecuada.

V.1.1. Presentacin
Como se ha mencionado anteriormente, esta tesis presenta un mtodo que rene las caractersticas ms convenientes de las metodologas existentes en la actualidad para resolver las necesidades especficas de los equipos de trabajo pequeos.

68

El nombre del mtodo es STASD, que significa en ingls Small Team Agile Software Development (Desarrollo gil de Software del Equipo Pequeo). La idea principal es crear un proceso de desarrollo gil que resulte sencillo de implementar y sea lo suficientemente simple para aplicarse a equipos de trabajo de no ms de cuatro personas. STASD es un mtodo creado pensando solamente en equipos pequeos, por lo que muchas prcticas que se pueden considerar importantes en el desarrollo han sido modificadas o excluidas si no pueden ser aplicadas dentro de este contexto. Por el hecho de ser un mtodo gil, uno de los propsitos es minimizar la burocracia y concentrarse ms en el caos.

V.1.2. El proceso creativo


Esta es la caracterstica ms importante de este mtodo, ya que en ella se basa todo el desarrollo de la misma. Es importante recalcar que esta idea fundamental de las metodologas giles se encuentra plasmada formalmente en el Manifestofor Agile Software Depelopement19. Es posible decir que la diferencia de un proceso creativo a uno mecnico consiste en lo siguiente, en el proceso mecnico se garantiza el xito estableciendo un proceso sistemtico que no requiere de un esfuerzo mental. Por otro lado, el proceso creativo exige un trabajo intelectual bastante fuerte y se basa totalmente en las habilidades del individuo.

19

Ver apndice

69

Este mtodo parte del hecho de que el desarrollo de software es un proceso creativo, no mecnico. Por lo mismo es necesario estudiar las habilidades de cada miembro del equipo y asignarle aquellas tareas que concuerden con su personalidad. El proceso creativo se puede dividir en las siguientes fases:  Fase de preparacin: En esta fase sucede la formulacin de la pregunta, la recopilacin de los datos relativos al problema y una primera bsqueda de soluciones.  Fase de incubacin: El problema vuelve a ser analizado y comienza una nueva etapa de incubacin de la solucin y una maduracin de las opciones.  Fase de iluminacin: Es aqu cuando se produce la iluminacin, es decir la manifestacin de la solucin. Aqu el individuo se entrega al anlisis del descubrimiento.  Fase de verificacin: Una vez teniendo un resultado, procede a la verificacin de la validez del mismo. A travs del pensamiento divergente, la creatividad puede plasmarse tanto en la invencin o descubrimiento de objetos y/o tcnicas, en la capacidad para encontrar nuevas soluciones modificando los habituales planteamientos o puntos de vista; o en la posibilidad de renovar antiguos esquemas o pautas.20. Esta es la base para la creacin de proyectos de software utilizando STASD.

20

lvarez, Elisa. Creatividad y Pensamiento Divergente

70

V.1.3. Estructura
Adems de la creatividad, el mtodo tiene una estructura bien definida, la cual se puede desglosar en los siguientes elementos:  Roles y habilidades: Los roles son los papeles que juega cada individuo en una fase determinada. Un rol puede ser cubierto por uno o ms elementos y, a su vez, un elemento puede tener asignados uno o ms roles. Es por eso que las habilidades que posee cada uno de los miembros del equipo son importantes, y el conocimiento de ellas facilita la asignacin de roles.  Actividades y entregables: Cada una de las actividades de los diferentes roles producen entregables que requieren ser entregados a una persona o equipo al trmino del desarrollo de una fase.  Equipos y asignacin de tareas: Los equipos representan la manera en la que se agrupan las personas durante las fases del desarrollo. Existe una manera en la que se reparten las tareas para cada uno de los roles y equipos.  Tcnicas y herramientas: Las tcnicas que se espera que el equipo de trabajo use a diario, as como las herramientas necesarias para producir los entregables necesarios.  Estndares: Es una especificacin de lo que est o no permitido en el diseo de los entregables. Esto incluye notacin, convenciones del proyecto y cuestiones de calidad.

V.2. MODELO DEL EQUIPO DE TRABAJO


El modelo del equipo STASD trabaja bajo una responsabilidad compartida. Cada uno de los elementos del equipo tiene como fin alcanzar la misma meta, y todos comparten una perspectiva nica del proyecto.

71

Este mtodo estructura a las personas y sus actividades en roles separados para garantizar el xito del proceso. Las funciones del proceso de desarrollo se encuentran agrupadas y dependiendo de sus caractersticas, cada una puede ser asignado a uno o ms individuos, incluso puede llegar a haber actividades que cumplan todos los elementos del equipo de trabajo. El equipo trabaja bajo un concepto de igualdad, cada rol mantiene la misma importancia que los dems y es capaz de comunicarse con los dems roles de una manera directa sin necesidad de depender de un intermediario. De esta manera se evitan las jerarquas laborales y se promueve la integracin del equipo. A continuacin se encuentran enlistados los distintos roles del mtodo:  Analista de negocio.  Lder de proyecto.  Desarrollador.  Tester.  Administrador del conocimiento. Por el hecho de que cada rol dentro del mtodo lleva acabo distintas tareas, es necesario un perfil diferente para cada uno. Sin embargo es necesario que todos los elementos del equipo compartan las siguientes caractersticas:  Creatividad.  Mantenerse gil (esperar cambios).  Asumir responsabilidades diversas.  Comunicacin abierta.  Voluntad para aprender.  Habilidad para trabajar en equipo.  Enfoque en el valor del trabajo.

72

Analista de Negocio

Administrador del conocimiento

Lder de proyecto

COMUNICACIN

Tester

Desarrollador

Figura 14. Modelo del equipo de trabajo STASD

Aunque este mtodo est basado en el individuo por encima del proceso, es importante tener en cuenta que muchas veces surgen eventualidades (enfermedad, vacaciones, etc.) que impiden tener al equipo de trabajo completo. En estas ocasiones es necesario tener la capacidad de cubrir un rol distinto sin problemas, por lo que todos los miembros del equipo deben estar preparados para delegar y aceptar responsabilidades conforme se vaya desarrollando el proyecto. A continuacin se encuentran detalladas cada una de las actividades de cada rol as como las habilidades especficas que debe poseer la persona encargada de desempearlo.

73

V.2.1. Analista de negocio


Lo ideal sera poder tener al cliente a nuestra completa disposicin durante todo el proceso de desarrollo, pero es imposible, por lo que el Analista de negocio toma el lugar del cliente en la mayor parte de los procesos. Debe trabajar de cerca con los usuarios para entender sus requerimientos y convertirse en un experto en las necesidades para as entender y comunicar a los dems roles del equipo de trabajo el concepto del sistema a desarrollar.  Meta: Usuarios satisfechos.  Responsabilidades: Tiene a su cargo el soporte general del proyecto.  Actividades: Es el encargado de proveer, comunicar y mantener actualizada la Visin del proyecto.  Importancia del rol: Radica en lograr que el proyecto desarrollado cumpla las necesidades para lo cual fue creado.  Aptitudes requeridas: Debe ser una persona con un amplio conocimiento del desarrollo de software para poder traducir los requerimientos del usuario. No es necesario que sea un experto en la operacin del negocio, sin embargo es importante que sea lo suficientemente humilde para reconocer que no tiene experiencia y pedir explicaciones exhaustivas cuando se requiera.

V.2.2. Lder de proyecto


Su principal objetivo es llevar el control del sistema dentro del tiempo acordado. Interacta con el Analista de negocio para planear los escenarios, con los Arquitectos y Desarrolladores para estimar el tiempo de desarrollo y con los Testers para evaluar y planear pruebas. Su labor, tambin, es manejar la liberacin del producto y garantizar el xito de la fase final mediante un plan de liberacin.

74

 Meta: Entregar la solucin dentro de las restricciones del proyecto.  Responsabilidades: Tiene a su cargo la planificacin del proyecto a lo largo de todo el ciclo de vida, incluyendo la planificacin a detalle de cada iteracin.  Actividades: Asigna recursos y delega responsabilidades en los mismos; fomenta el trabajo en equipo del grupo: organiza las reuniones y monitorea el progreso general del proyecto.  Importancia del rol: Es la cara del equipo de desarrollo y es el intermediario entre los requerimientos y la solucin.  Aptitudes requeridas: Es importante que este rol sea cubierto por una persona que explote las aptitudes individuales de los integrantes del equipo, que confe en el grupo de trabajo y delegue responsabilidades sin ningn temor. Debe conocer a grandes rasgos la plataforma en la cual se va a desarrollar el software as como el desarrollo de los procesos iterativos.

V.2.3. Desarrollador
Este rol debe asegurar el xito del proyecto basndose en la implementacin de un buen diseo estructural de la aplicacin. La arquitectura desarrollada debe estar abierta a mejoras y cambios requeridos en alguna otra iteracin.  Meta: Entregar el desarrollo del sistema adecuado a las necesidades y especificaciones tcnicas.  Responsabilidades: Tiene a su cargo el desarrollo completo del proyecto cumpliendo con la planificacin establecida por el Lder de proyecto.  Actividades: Definir la estructura que guiar el proceso de desarrollo y la continua refinacin de la misma en cada iteracin; codificar los componentes y realizar pruebas unitarias sobre el cdigo desarrollado; refactorizar el cdigo siempre que sea posible.

75

 Importancia del rol: Es el motor del equipo de trabajo y el que provee a los dems roles con una solucin tangible.  Aptitudes requeridas: Debe conocer plenamente la tecnologa bajo la cual se va a desarrollar el proyecto, los estndares de programacin y las herramientas utilizadas en el desarrollo; as como la notacin de UML para el desarrollo de los diagramas necesarios.

V.2.4. Tester
Su funcin es descubrir errores dentro del desarrollo mediante pruebas y especificar el nivel de impacto dentro del sistema. El Tester debe comprender el contexto del proyecto y ayudar a los dems a realizar decisiones adecuadas para la mejora del producto.  Meta: Aprobar y liberar el desarrollo una vez que los requerimientos y necesidades hayan sido cumplidos.  Responsabilidades: Tiene a su cargo la generacin de pruebas funcionales a partir de los requerimientos generados por el Analista de negocio.Una vez realizado esto, es el encargado de la liberacin.  Actividades: Generacin de pruebas tcnicas y funcionales; liberacin de la aplicacin con el usuario.  Importancia del rol: Es el que aprueba o no el desarrollo construido con base en las necesidades del usuario, por lo que en l radica la responsabilidad de liberar un software de calidad.  Aptitudes requeridas: Es necesario que la persona encargada de este rol cuente con el suficiente conocimiento de la tecnologa empleada y la notacin UML para entender la arquitectura del sistema. Tambin debe entender a la perfeccin los requerimientos del sistema para as poder indicar si el producto satisface las necesidades del usuario.

76

V.2.5. Administrador del conocimiento


El mtodo STASD se basa en el aprendizaje continuo del desarrollo de software, y el encargado de llevar a cabo la tarea de condensarlo y aplicarlo es el Administrador del conocimiento. La comunicacin es una parte esencial de este rol ya que es necesario entender y explicar los conocimientos adquiridos al equipo de trabajo.  Meta: Proveer al equipo de trabajo con los conocimientos adquiridos en la iteracin.  Responsabilidades: Llevar un control del aprendizaje de la iteracin.  Actividades: Refinamiento y transferencia del conocimiento adquirido en la iteracin.  Importancia del rol: Su importancia consiste en la capacidad del equipo de desarrollo de aprender de sus propias experiencias. El Administrador del conocimiento es uno de los pilares de STASD.  Aptitudes requeridas: Debe tener un amplio conocimiento en las distintas reas de la ingeniera de software de manera que condense el conocimiento estructuradamente. Tambin debe tener la capacidad de capturar el conocimiento generado por el equipo durante el desarrollo sin afectar la productividad del mismo.

V.3. FASES E HITOS DEL PROCESO DE DESARROLLO


Como todas las metodologas existentes, este mtodo se compone de diversas fases de desarrollo ligadas entre s que producen como resultado un sistema. Es importante aclarar que muchas veces las actividades abarcan ms de una fase, por ejemplo: la planeacin no slo se realiza al inicio, o las pruebas no slo se aplican al final. Las

77

fases se delimitan por los entregables que se generan, no por las actividades que se realizan. Las fases que componen el mtodo son las siguientes:  Fase de preparacin:Abarca todos los preparativos del proyecto y se termina cuando se da inicio al mismo.  Fase creativa: Termina una vez que la visin es aprobada para ser desarrollada.  Fase de planeacin: Finaliza cuando se aprueba la planeacin del proyecto.  Fase de desarrollo: Cuando se completa el alcance del proyecto se da por terminada esta fase.  Fase de estabilizacin: Finaliza una vez que el producto se encuentra listo para liberarse. Cada fase termina con un hito que indica el inicio de la fase que le sigue. El desarrollo se divide en dos perspectivas del proyecto, la primera ocurre en las primeras iteraciones, cuando se analiza la factibilidad del desarrollo y la segunda ocurre en las fases iterativas de construccin, donde se le da nfasis al cdigo del sistema. Esto significa que la creatividad necesaria en el proceso disminuye con el tiempo, convirtindose en un ciclo ms previsible. A continuacin se encuentran descritas las fases del proceso de desarrollo STASD.

78

Fase de preparacin Previo

Fase creativa Arquitectura Fase de planeacin Visin Inicio

Fase de desarrollo

Desarrollo

Iteracin Liberacin Fase de estabilizacin Iteracin Entrega

Figura 15. Fases de STASD

V.3.1. Fase de preparacin


Esta primera fase abarca todos los preparativos que deben ser considerados antes de iniciar con el desarrollo del proyecto. Muchas veces se omite esta fase y las actividades pertenecientes a la misma se van desarrollando conforme el proyecto avanza; esto es un error ya que es necesario contar con una base slida sobre la cual construir el proyecto.

79

Esta fase se realiza sin la intervencin del usuario y sirve principalmente para definir estndares de trabajo, como son el horario laboral, los estndares de programacin, los estndares de documentacin, los roles del equipo, el lugar de trabajo, entre otros. La fase de preparacin se hace slo una vez al inicio del proyecto y es posible que un proyecto no la requiera en caso de que sea muy similar a otro o que sea su continuacin, en esos casos se utilizar todo lo realizado en esta fase del proyecto anterior.

V.3.2. Fase creativa


Esta etapa consiste en la definicin del alcance y las caractersticas que tendr la aplicacin, as como la identificacin de los puntos crticos y la planificacin general del proyecto. Es aqu donde se establecen los cimientos sobre los cuales se construir la aplicacin. Es importante trabajar de cerca con el usuario para adquirir conocimiento del negocio y entender los requerimientos necesarios del sistema para satisfacer las necesidades del cliente. Tambin es necesario evaluar si los costos del desarrollo estarn justificados o si conviene ms adquirir una solucin desarrollada previamente. La fase creativa finaliza con un hito mayor llamado Visin; en esta se evala todo lo realizado en la etapa contra las expectativas del cliente y del equipo de desarrollo.

V.3.3. Fase de planeacin


La fase de planeacin se refiere bsicamente a la exploracin de los requerimientos ms crticos que involucra el proyecto.Con base en la Visin se realiza el plan del proyecto y las dems actividades necesarias para evaluar la factibilidad del proyecto. 80

En caso de una negativa concerniente a la factibilidad del proyecto, es un buen momento para detenerse. De lo contrario es necesario pasar a la siguiente fase. El objetivo de esta fase es asegurar la factibilidad tcnica del proyecto. A diferencia de la fase anterior, en la que se analiza la factibilidad general del desarrollo, en esta slo se trabaja en la parte tcnica. Tambin se desarrolla un plan general de trabajo para el proyecto, se crea una aproximacin del tiempo de desarrollo as como la definicin de roles y actividades.

V.3.4. Fase de desarrollo


Es a partir de aqu cuando se inician las iteraciones, abarca completamente la construccin del software con base en las iteraciones planeadas. Se terminan de definir los casos de uso correspondientes a las iteraciones, se disean conforme a la arquitectura definida en la fase anterior y se codifican los componentes necesarios respetando siempre las normas de estndares y la arquitectura. Esta etapa es el corazn del mtodo, ya que es aqu cuando inicia el proceso de aprendizaje. Cada iteracin genera informacin que permite el perfeccionamiento del mtodo y, probablemente, la modificacin del plan de trabajo o la arquitectura.

V.3.5. Fase de estabilizacin


Una vez que se terminen las iteraciones del desarrollo es necesario pasar los componentes creados a una etapa de estabilizacin. Este proceso consiste en evaluar mediante casos de prueba si la aplicacin satisface los requerimientos del usuario y si es enteramente estable y est lista para ser liberada. En caso de no cumplir con los

81

requisitos para ser liberado, los componentes deben regresar a una fase de desarrollo en la que se corrijan siguiendo las normas definidas previamente. Una vez que se tiene una aplicacin probada y lista para ser liberada se inicia el proceso de liberacin, el cual termina en un hito llamado Liberacin, que es el momento en el que se le entrega el sistema (o una parte de l) al cliente.

V.4. ACTIVIDADES DENTRO DE LAS FASES


Cada actividad forma parte de una o ms fases y producen uno o ms artefactos, los cuales sirven para dar un sustento y facilitar la siguiente actividad. Las actividades que conforman al mtodo son las siguientes:  Estudio de factibilidad: Esta actividad se realiza principalmente dentro de las fases creativa y de planeacin.  Anlisis de requerimientos: La fase de desarrollo contiene esta actividad, la cual se realiza una y otra vez para actualizar las necesidades en caso de que sean modificadas.  Diseo de la arquitectura: Al igual que el anlisis de requerimientos, esta actividad es iterativa y est contenida en la fase de desarrollo.  Desarrollo del sistema: Esta actividad se centra en la codificacin del sistema, la cual es iterativa y se realiza junto con el anlisis de requerimientos y el diseo de la arquitectura dentro de la fase de desarrollo.  Pruebas unitarias: Esta actividad es realizada dentro de la fase de desarrollo y se enfoca principalmente al cdigo.  Pruebas de funcionalidad: Dentro de la fase de estabilizacin se realizan pruebas para verificar que funcione correctamente.

82

 Liberacin: Esta actividad se realiza al terminar la fase de estabilizacin, la cual genera un resultado del sistema al usuario.

Estudio de factibilidad

Inicio

Diseo de la arquitectura

Desarrollo del sistema

Anlisis de requerimientos

Desarrollo

Pruebas unitarias Iteracin

Pruebas de funcionalidad

Liberacin Iteracin

Entrega

Figura 16. Actividades de STASD

Tal como se puede observar en el diagrama anterior, la mayora de las actividades son iterativas. A continuacin describiremos cada una de ellas.

V.4.1. Estudio de factibilidad


Durante esta actividad se produce el primer acercamiento entre el equipo de trabajo y el cliente. Esta actividad le permite al Analista de Negocio adquirir la mayor parte de conocimientos posible acerca del entorno, las necesidades del cliente y los objetivos del sistema.

83

Esta actividad permite analizar si es conveniente construir el sistema y si realmente resuelve las necesidades del cliente. Se plantean las posibles soluciones para el desarrollo y se selecciona una especfica; para la cual se deben definir varios estndares: el lenguaje de programacin que se va a usar, la utilizacin de una base de datos, el plan general del proyecto o un anlisis de riesgos de desarrollo. Al terminar esta actividad deben existir los siguientes artefactos:  Documento de estndares  Documento de visin  Plan del proyecto  Listado de riesgos El Analista de Negocio y el Lder de Proyecto son los encargados de esta actividad, as como de la creacin y el mantenimiento de los artefactos generados.

V.4.2. Anlisis de requerimientos


Una vez completado el estudio de factibilidad, se procede a dar inicio al desarrollo iterativo del sistema. La primera actividad con la que se inician las iteraciones es el anlisis de requerimientos. En esta actividad se capturan las necesidades concretas del usuario divididas por caractersticas y ordenadas mediante el siguiente criterio: 10. Caractersticas que debe tener el sistema:Estas caractersticas son esenciales para el desarrollo del proyecto. Dentro de este grupo se deben colocar todas aquellas caractersticas necesarias para el funcionamiento correcto del sistema.

84

11. Caractersticas que mejoran la funcionalidad del sistema: Cualquier caracterstica no necesaria para el funcionamiento del sistema pero que es posible que mejore la funcionalidad del mismo debe ser colocada en este grupo. 12. Caractersticas que mejoran la interaccin del usuario con el sistema: Estas caractersticas por lo general se centran en el diseo y en mejorar la experiencia del usuario al utilizar el sistema. Una vez que se tienen las caractersticas del sistema bien definidas y agrupadas es necesario comenzar con la definicin de los casos de uso. Cada caracterstica debe tener un caso de uso, el cual no debe demorarse ms de dos semanas en realizarse. El caso de uso consiste en la definicin detallada de la caracterstica a desarrollar. Se definen los actores principales y secundarios, las condiciones que deben existir para el desarrollo del mismo, la interaccin del usuario con el sistema y los flujos alternativos y excepciones (en caso de existir). Al trmino de esta actividad se deben tener el diagrama de Casos de Uso y el documento de Caso de Uso. Es preciso recordar que para cada iteracin se debe generar un caso de uso nuevo y enriquecer el diagrama de casos de uso en caso de ser necesario. El lder de Proyecto es el principal encargado de esta actividad, sin embargo es imprescindible que el Analista de Negocio y el Desarrollador participen en esta actividad para apoyar en la definicin de caractersticas. Es recomendable, ms no necesario, que se le muestren las caractersticas definidas al cliente. En caso de no poderse hacer, el Analista de Negocio debe tener los conocimientos suficientes para aprobar o rechazar los resultados de esta actividad.

85

V.4.3. Diseo de la arquitectura


Esta actividad consiste en plasmar la solucin al problema planteado como una arquitectura del sistema. La parte ms crtica de esta actividad se realiza al inicio de las iteraciones debido a que para poder trabajar es necesario poseer una infraestructura de la aplicacin. Conforme las iteraciones continan, esta actividad se va enriqueciendo y redefiniendo para poder satisfacer los requerimientos del sistema. La arquitectura del sistema es un modelo documentado que explica las propiedades, los mtodos y las interacciones de los componentes del sistema. Esta actividad es realizada tomando en cuenta las necesidades planteadas en el anlisis de requerimientos y es detallada en un diagrama de clases utilizando el lenguaje de programacin que haya sido elegido en la definicin de estndares. El principal responsable de esta fase es el Desarrollador, ya que es l quien debe definir la arquitectura completamente. Al finalizar esta fase se debe contar con el Diagrama de la Arquitectura del sistema.

V.4.4. Desarrollo del sistema


En esta actividad, el equipo de desarrollo se dedica a implementar la funcionalidad del sistema utilizando los estndares definidos previamente, as como la arquitectura realizada en la actividad anterior. El desarrollo del sistema no genera ningn artefacto, en vez de eso genera una parte del sistema. Esta actividad es responsabilidad del Desarrollador, y debe ser asistido por el Lder de Proyecto para la revisin de tiempos y por el Analista de Negocio para la resolucin de dudas acerca del funcionamiento de la caracterstica que se est desarrollando.

86

V.4.5. Pruebas unitarias


Durante la fase de desarrollo es necesario realizar pruebas unitarias a los componentes creados. Estas pruebas son realizadas al nivel de las clases y mtodos construidos para la aplicacin. Estas pruebas son implementadas por el Desarrollador para verificar el comportamiento correcto de los mtodos en una clase especfica. Las pruebas unitarias sirven para controlar la calidad del cdigo construido y para evaluar si es necesario regresar al anlisis de la caracterstica o ya es conveniente dejar la fase de desarrollo. En caso de que las pruebas no sean satisfactorias, es necesario regresar revisar el anlisis, diseo y codificacin de la caracterstica para ubicar el error y poder resolverlo. Una vez que las pruebas sean correctas se da por terminada esta actividad y con ella la fase de desarrollo. El Desarrollador es el responsable directo de esta fase.

V.4.6. Pruebas de funcionalidad


Estas pruebas verifican el flujo de la funcionalidad definida en los casos de uso. Esta funcionalidad debe ser especificada en pruebas automatizadas creadas por el Analista de Negocio (o el usuario si es posible) en conjuncin con el Tester durante cada iteracin. El objetivo de las pruebas es la verificacin de que el software construido en las iteraciones cumple con las caractersticas solicitadas por el usuario y est listo para ser utilizado en un ambiente de produccin.

87

Estas pruebas son relevantes ya que implican que el cliente (o en su defecto el Analista de Negocio) de conformidad respecto al sistema desarrollado. El Tester es el responsable de esta actividad junto con el Analista de Negocio en caso de que no se pueda tener al usuario para realizarlas. Una vez terminadas debe ser creado un Documento de Casos de Prueba.

V.4.7. Liberacin
Esta actividad permite que el sistema construido sea transferido al ambiente de produccin en el cual va a operar. Esto no significa que el software est terminado en su totalidad, ya que este mtodo permite con cada iteracin ir mejorando el sistema y agregando las caractersticas necesarias para su funcionamiento adecuado. El Tester es el encargado de esta actividad y de generar el Paquete de Liberacin. Dependiendo de los requerimientos iniciales plasmados en la visin del proyecto, es probable que sea necesario realizar diversas tareas para tener listo el paquete de instalacin, como son:  Redaccin de manuales: de usuario o de operacin, entre otros.  Realizar el paquete de componentes junto con scripts de instalacin para que el cliente instale la aplicacin en su entorno.  Capacitar a los usuarios que utilizarn el sistema.  Generar una nota de entrega con el concentrado de artefactos que se le entregan al cliente.

88

V.5. ACTIVIDADES DE SOPORTE


Las actividades de soporte son realizadas a lo largo de todo el ciclo de vida del proyecto y pretenden respaldar a las actividades relacionadas con la construccin del software. Estas son tan importantes como las actividades antes mencionadas, la diferencia es que sirven para propsitos organizacionales no directamente relacionados con la produccin de sistemas. Estas actividades son las siguientes:  Administracin del plan de trabajo.  Administracin del personal.  Administracin del conocimiento.

V.5.1. Administracin del plan de trabajo


Esta actividad permite garantizar el xito del proyecto mediante la organizacin del tiempo y la realizacin del mismo dentro de los costos presupuestados. El Lder de Proyecto es quien realiza la administracin del proyecto; no slo debe definir los tiempos de entrega y asegurarse de que se cumplan, sino que debe garantizarle al equipo de desarrollo un ambiente de trabajo cmodo y sin obstculos. Es necesario establecer una planificacin inicial del proyecto definiendo hitos para as poder obtener retroalimentacin del avance realizado por parte del usuario. Es importante recalcar que el plan de trabajo es armado consultado al equipo de desarrollo, la nica tarea especial del Lder de Proyecto es armarlo en un formato presentable al cliente dependiendo el nivel de formalidad requerido, por ejemplo en un diagrama de Gantt.

89

Debido a que el flujo de informacin e interaccin del equipo de trabajo debe ser frecuente, una de las tareas ms importantes que debe llevar a cabo el Lder de Proyecto es una reunin diaria de no ms de 15 minutos para reforzar la comunicacin dentro del equipo de trabajo, para as medir el avance realizado diariamente, resolviendo cualquier problemtica del equipo y eliminando obstculos.

V.5.2. Administracin del personal


Esta actividad abarca todos los aspectos humanos del desarrollo. El mtodo STASD y las diversas metodologas giles se basan en las personas por encima de los procesos, por lo que es necesario asegurar el xito del proyecto con base en el personal del equipo de trabajo. El responsable de esta actividad es el Lder de Proyecto. Una de las primeras tareas que se deben realizar en esta actividad es nivelar a todos los miembros del equipo de desarrollo. Es importante que cada uno tenga todos los conocimientos necesarios para encarar las actividades que le han sido asignadas. El Lder de Proyecto debe encargarse de la capacitacin hasta estar seguro que el personal haya aprendido. Otra de las tareas dentro de esta actividad es mantener una buena salud en el equipo de trabajo; es decir, tratar de mantener alta la motivacin del equipo, garantizar relaciones interpersonales positivas, minimizar las fricciones dentro del equipo y entender a cada individuo para poder aprovechar lo mejor de si mismo. La mayor parte de los problemas y conflictos en los equipos de trabajo se dan por malas interpretaciones, por lo que es importante mantener los canales de comunicacin abiertos y lo suficientemente informados para poder resolver las dificultades.

90

V.5.3. Administracin del conocimiento


La historia sigue siendo la mejor herramienta para predecir el futuro [Verzuh, 2008]. Para lograr uno de los puntos ms importantes de este mtodo, es necesario aprender en cada iteracin del desarrollo del sistema y en cada proyecto desarrollado. Para poder llegar al conocimiento es necesario definir tres niveles de refinamiento, los cuales son: datos, informacin y conocimiento. Comenzando del nivel inferior, los datos son valores objetivos generados por eventos, pero sin ningn contenido acerca de su importancia o relevancia; a partir de estos podemos generar informacin. La informacin son datos organizados de una forma en la que pueden ser utilizados por las personas para la toma de decisiones. Por ltimo, el conocimiento requiere la comprensin y el entendimiento de la informacin. Todo esto nos lleva a lo que llamamos experiencia, que es simplemente el conocimiento aplicado. Este mtodo define un rol especfico llamado Administrador del Conocimiento, el cual no ha participado dentro de ninguna actividad hasta ahora. Es recomendable que este rol sea tomado por los distintos miembros del equipo de trabajo de forma rotativa; su tarea consiste en documentar todo aquel conocimiento nuevo que haya sido generado durante el desarrollo del proyecto para que pueda ser reutilizado por diferentes personas dentro del equipo. Debido a que este proceso radica en la documentacin y nos manejamos en un contexto gil, es imprescindible evitar la burocracia en esta actividad. Por lo que es necesario enfocar el conocimiento a los aspectos funcionales ms importantes y capturarlos de una manera concisa y ordenada para que puedan ser recuperados y consumidos en el futuro. Tambin es recomendable capturar todas aquellas experiencias humanas positivas y negativas que se tuvieron en el proyecto, ya que

91

mucho del xito del proyecto radica en las experiencias humanas y no slo en el desarrollo del software.

V.6. ARTEFACTOS
El mtodo STASD intenta crear el menor nmero de artefactos para no caer en la documentacin excesiva de procesos y perder la agilidad sobre la cual est planteada. Sin embargo, es justo reconocer que la documentacin es necesaria. De lo contrario caeramos en el caos total y nuestro mtodo de trabajo se convertira en codificar y probar. La mayora de los artefactos se generan durante el desarrollo del proyecto, aunque hay algunos que son generados una sola vez y funcionan para varios proyectos. Los artefactos generados son los siguientes:  Documento de estndares.  Documento de evaluacin del personal.  Documento de visin.  Plan del proyecto.  Listado de riesgos.  Diagrama de casos de uso.  Documento de caso de uso.  Diagrama de la arquitectura.  Documento de casos de prueba.  Documento de aprendizaje.  Paquete de liberacin.

92

Documento de estndares

Documento de Evaluacin del Personal

Previo

Documento de Visin

Inicio

Plan del Proyecto

Listado de Riesgos

Planeacin

Diagrama de Casos de Uso

Diagrama de la Arquitectura

Documento de Caso de Uso Desarrollo

Documento de Casos de Prueba

Documento de aprendizaje

Iteracin

Paquete de Liberacin

Iteracin

Entrega

Figura 17. Documentos de STASD

La figura anterior nos muestra que la mayor parte de los artefactos pueden ser modificados a lo largo del proceso, dependiendo de la iteracin a la que pertenecen. Por ejemplo, el documento de estndares no se modifica durante todo el proceso de

93

desarrollo, sin embargo el diagrama de la arquitectura puede ser modificado con cada iteracin de cada caso de uso.

V.6.1. Documento de estndares


Este artefacto sirve para definir todo tipo de estndares de codificacin que se utilizarn en el proyecto. STASD utiliza la propiedad colectiva de cdigo, por lo que es necesario llevar un alto control de estndares de programacin. Cada uno de los miembros del equipo debe tener acceso permanente a este artefacto. El documento de estndares se crea previamente al desarrollo del proyecto, por lo que puede ser aplicado a ms de uno. Y debe ser creado uno distinto para cada lenguaje de programacin.

V.6.2. Documento de evaluacin del personal


Este documento es creado por el lder de proyecto, en l se describen las cualidades o defectos de los recursos que sern parte del proyecto. Cualquier tipo de caracterstica, ya sea positiva o negativa, puede influir en el desarrollo del software, por lo tanto es indispensable tomarlas en cuenta. Aunque este documento se crea al inicio del proyecto, es modificado en el transcurso del desarrollo o cuando se realiza la evaluacin final. Es importante tenerlo actualizado para saber quin debe integrarse al equipo de trabajo y de qu manera lo debe hacer.

94

V.6.3. Documento de visin


El documento de visin hace referencia a las necesidades y deseos del cliente, dejando claro el alcance del proyecto que se va a desarrollar.Este es creado por el Analista de Negocio y el Lder de Proyecto, y debe ser validado por el cliente En la visin deben ser identificados los puntos crticos del proyecto, as como las caractersticas y requerimientos suplementarios que van a ser desarrollados.

V.6.4. Plan del proyecto


Este es un documento creado y mantenido por el Lder de proyecto que contiene toda la informacin de gestin. Se puede utilizar un diagrama de Gantt con el cronograma y las tareas que involucra el proyecto. Aunque es creado al inicio del proyecto, este documento debe ser actualizado continuamente hasta la finalizacin del proyecto.

V.6.5. Listado de riesgos


La lista de riesgos se utiliza para capturar los riesgos ms relevantes que se presentan en el proyecto. Para poder tener un control sobre ellos y ser capaces de monitorearlos, asignarles prioridad, impacto y probabilidad de ocurrencia. El Lder de Proyecto es el responsable y el principal usuario de este documento, ya que con l puede planificar las iteraciones teniendo en cuenta aquellos riesgos que deban ser mitigados, transferidos, aceptados o ignorados, dependiendo de la magnitud del riesgo.

95

Los valores con los cuales se evalan los riesgos son Muy Alto, Alto, Medio, Bajo y Muy Bajo. Dependiendo de la aproximacin realizada entre la probabilidad de ocurrencia y el impacto se les asigna una prioridad. El listado de riesgos se crea al inicio pero debe mantenerse actualizado hasta el final del proyecto.

V.6.6. Diagrama de casos de uso


Este diagrama contiene todas las caractersticas requeridas del sistema planteadas como casos de uso utilizando la notacin de UML. Este diagrama permite ordenar las interacciones de las caractersticas del sistema y facilitar la comprensin del mismo mediante un enfoque visual. Algunas veces surgirn casos de uso conforme se desarrolla el proyecto, en estos casos ser necesario actualizar el diagrama y relacionar el nuevo caso de uso con los existentes para reorganizar las iteraciones y, en un caso extremo, el plan del proyecto. El Lder de Proyecto es el responsable de mantener este documento actualizado cada vez que se realiza una iteracin. Los Desarrolladores y el Analista de Negocio son usuarios del documento tambin.

V.6.7. Documento de caso de uso


Cada caso de uso debe tener su propio documento, en este se detalla la funcionalidad necesaria para cada uno. Explicando el flujo principal del caso de uso as como sus excepciones.

96

El Desarrollador es el principal responsable del mantenimiento y uso de este documento, cuando sea necesario el Lder de Proyecto y/o el Analista de Negocio apoyarn al anlisis.

V.6.8. Diagrama de la arquitectura


Este diagrama es responsabilidad total del Desarrollador, el Tester lo consultar para revisar que la estructura del sistema sea correcta al momento de realizar las pruebas y el control de calidad. La arquitectura se detalla a nivel de clases y componentes. Al inicio no es necesario definir todas las propiedades y los mtodos de cada clase, esas se irn definiendo conforme avance el proyecto.

V.6.9. Documento de casos de prueba


El caso de prueba se realiza para cada caso de uso, en este documento se hace una revisin para asegurar que el software realice lo estipulado por el caso de uso. En el documento de prueba se verifica la funcionalidad de la aplicacin desde el punto de vista de usuario, as como la arquitectura desde el punto de vista de desarrollo. El Tester es el responsable de este documento. El Analista de Negocio y el Desarrollador deben estar disponibles para apoyar al Tester en caso de que requiera.

V.6.10. Documento de aprendizaje


El mtodo STASD est basada en el aprendizaje, por lo que este documento es uno de los ms importantes dentro del proceso. El Administrador del Conocimiento es el 97

responsable del mantenimiento, este documento se genera al inicio del desarrollo y se va complementando con cada iteracin que se realiza. En cada junta el administrador es responsable de actualizarlo con la retroalimentacin que ofrecen los dems miembros del equipo.

V.6.11. Paquete de liberacin


El ltimo artefacto del mtodo es el paquete de liberacin, el cual dependiendo de la tecnologa ocupada puede ser un instalador, una serie de archivos comprimidos o scripts de bases de datos. Este paquete lo entrega el Tester al usuario con el asesoramiento del Analista de Negocio, para la implementacin en produccin. En caso de ser requerido un manual de usuario, se entrega en el paquete de liberacin.

V.7. INTEGRACIN DE STASD


En este apartado se muestra un diagrama del mtodo integrado; se muestran las interacciones entre fases y actividades al igual que los artefactos que se crean en cada etapa.

98

Definicin de Estndares

Documento de Estndares

Fase de Preparacin

Evaluacin del Personal

Asignacin de Roles

Visin del Proyecto

Documento de Visin

Fase Creativa

Plan del Proyecto

Anlisis de Riesgos

Estudio de Factibilidad Fase de Planeacin

Listado de Riesgos

Diseo de la arquitectura

Anlisis de requerimientos

Diagrama de Casos de Uso

Diagrama de la Arquitectura

Documento de Caso de Uso Fase de Desarrollo

Desarrollo del sistema

Pruebas unitarias

Documento de Casos de Prueba

Documento de Aprendizaje

Pruebas de Funcionalidad

Documento de Casos de Prueba Fase de Estabilizacin

Liberacin

Figura 18. Integracin del proceso completo de STASD

99

CAPTULO VI. CASO PRCTICO

Hasta este momento, el mtodo STASD ha sido fundamentado solamente con base en la teora. Pero para probar el funcionamiento es necesario realizar un caso prctico; esta actividad a realizar es el control de acceso de usuarios registrados a una aplicacin existente, asignando perfiles de usuario y restringiendo las aplicaciones dependiendo de los permisos del perfil.

VI.1. FASE DE PREPARACIN


Es necesario realizar los preparativos para el desarrollo de esta aplicacin, por lo que definiremos los estndares y asignaremos los roles dentro del modelo del equipo de trabajo.

VI.1.1. Definicin de estndares


Para realizar la definicin de estndares es necesario conocer la tecnologa utilizada para la aplicacin.  Tipo: Aplicacin web  Plataforma del servidor: Microsoft Windows Server 2003  Base de datos: Microsoft SQL 2005  Codificacin: Microsoft Visual Studio 2005 102

Con base en esta informacin podemos crear los estndares de programacin. Comenzaremos con la definicin de estndares de la base de datos.

Documento de estndares de base de datos


Tipo: Base de datos Microsoft SQL 2005 Versin: 1.0 Bases de datos Mantener las bases de datos lo ms genricas posibles y con los nombres en lenguaje natural (ej. RecursosHumanos). Colocar el nombre descriptivo con las siguientes caractersticas: Utilizar un mximo de cuatro palabras para el nombre. Cada palabra debe iniciar con mayscula. No utilizar palabras en plural.

Tablas Crear las tablas genricas con el nombre en lenguaje natural (ej. Empleado): Colocar el nombre descriptivo de la tabla con las siguientes caractersticas: Utilizar un mximo de cuatro palabras para el nombre. Cada palabra debe iniciar con mayscula. No utilizar verbos.

Para los nombres de los campos de las tablas se debe considerar lo siguiente: Utilizar dos palabras como mximo. Cada palabra debe iniciar con mayscula. No utilizar palabras en plural. Colocar el prefijo id en los campos llave.

Procedimientos almacenados

103

Describir en pocas palabras la accin que realiza el procedimiento (ej. ConsultarEmpleado): Colocar el nombre descriptivo del procedimiento con las siguientes caractersticas: Si slo realiza una accin en una tabla es recomendado utilizar el nombre de la tabla. Utilizar un mximo de cuatro palabras para el nombre. Cada palabra debe iniciar con mayscula. Utilizar verbos que indiquen la accin a realizar.

Cada procedimiento debe ir comentado al inicio de la siguiente manera: /********************************************************/ /* /* /* /* Fecha creacin: Fecha ltima modificacin: Descripcin: dd/mm/aaaa dd/mm/aaaa (Descripcin del procedimiento) */ */ */ */

Modificado por: (Nombre del programador)

/********************************************************/

Figura 19. Estndares de base de datos

Para esta aplicacin no utilizaremos triggers, vistas o funciones. Por lo que no es necesario definirlas en los estndares. Ahora que ya tenemos los estndares de bases de datos es necesario definir los estndares de programacin. Sabemos que adems de utilizar Visual Studio 2005, la aplicacin ser programada en Visual Basic, por lo tanto los estndares se adecuarn al lenguaje utilizado.

104

Documento de estndares
Tipo: Visual Basic (Visual Studio 2005) Versin: 1.0 Pginas Las pginas deben llevar el nombre que describa lo que realizan (ej. Acceso.aspx): Utilizar cuatro palabras como mximo para definir el nombre. Cada palabra debe comenzar con mayscula. No utilizar palabras en plural. No utilizar verbos.

Objetos de la interfaz El nombre de cada objeto de la interfaz debe llevar un prefijo dependiendo del tipo de objeto que sea: Button btn. Checkbox chb. Validator val. DataGrid dg. DropDownList ddl. Image img. Label lbl. Panel pnl. ListBox lb. RadioButton rbtn. TextBox txt.

Clases El nombre de las clases debe mantenerse lo ms sencillo posible, denotando en lenguaje natural su rea de trabajo (ej. Empleado). El nombre de la clase debe cumplir con lo siguiente: Utilizar cuatro palabras como mximo para definir el nombre. Cada palabra debe comenzar con mayscula.

105

Funciones El nombre de las funciones debe mantenerse como accin y en lenguaje natural (ej. Empleado.AsignarSesion): Utilizar cuatro palabras como mximo para definir el nombre. Cada palabra debe comenzar con mayscula. Utilizar verbos que describan la accin de la funcin.

Propiedades Las propiedades deben llevar el nombre descriptivo en lenguaje natural sin utilizar verbos (ej. Empleado.Nombre): Utilizar de preferencia slo una palabra que describa la propiedad. La palabra debe comenzar con mayscula. No utilizar verbos.

Variables Las variables deben llevar un prefijo dependiendo del tipo de dato: Boolean b. Byte byte. Char chr. DataSet ds. Decimal dec. Double dbl. Integer int. Long lng Object obj. String str.

Documentacin del cdigo Cada elemento del cdigo que realice alguna accin (funcin o clase) debe ser documentado al inicio de la siguiente manera:

106

******************************************************* * * * * Fecha creacin: Fecha ltima modificacin: Descripcin: dd/mm/aaaa dd/mm/aaaa (Descripcin de la accin)

Modificado por: (Nombre del programador)

*******************************************************

Figura 20. Estndares de codificacin

Ahora que se tienen los estndares definidos podemos continuar con la siguiente etapa de la fase de preparacin.

VI.2. FASE CREATIVA


Dentro de esta fase definiremos todo lo necesario para evaluar la factibilidad del desarrollo de la aplicacin. Desde la visin del proyecto hasta un breve anlisis de riesgos.

VI.2.1. Administracin del personal


Dentro de esta actividad complementaria evaluamos la aptitud y conocimiento de cada uno de los miembros del equipo de trabajo. Esta tarea se realizar constantemente durante el desarrollo del proyecto, sin embargo es bueno tener una idea de inicio acerca del equipo. Los miembros del equipo sern denominados por el puesto que desempean actualmente en la empresa.

107

Evaluacin del personal

Arquitecto de sistemas
Amplios conocimientos en el diseo de arquitecturas de sistemas, experto en el desarrollo de sistemas utilizando Visual Basic 2005, conocimiento intermedio en el desarrollo de bases de datos. Fecha de inicio y fin del recurso en el proyecto: 27 de agosto de 2007 al 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana) rea del recurso: Gerencia de sistemas

Administrador de Bases de Datos


Alta capacidad de anlisis lgico para bases de datos, experto en el diseo de bases de datos utilizando SQL 2005, conocimiento intermedio en el desarrollo de sistemas utilizando Visual Basic 2005. Fecha de inicio y fin del recurso en el proyecto: 27 de agosto de 2007 al 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana) rea del recurso: Gerencia de sistemas

108

Programador Senior
Experto en el desarrollo de sistemas utilizando Visual Basic 2005, conocimientos avanzados de diseo de bases de datos y arquitectura de sistemas. Fecha de inicio y fin del recurso en el proyecto: 27 de agosto de 2007 al 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana) rea del recurso: Gerencia de sistemas

Lder de Proyecto
Amplio conocimiento en la aplicacin a la cual se le va a desarrollar el mdulo de acceso de usuarios, experto en el diseo de bases de datos, conocimientos intermedios del desarrollo de sistemas utilizando Visual Basic 2005. Fecha de inicio y fin del recurso en el proyecto: 27 de agosto de 2007 al 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana) rea del recurso: Gerencia de sistemas

Figura 21. Documento de evaluacin del personal

Una vez que conocemos las habilidades de cada uno de los miembros del equipo podemos tomar la decisin de asignarlos a realizar distintos roles.

109

VI.2.2. Asignacin de roles dentro del equipo de trabajo


La asignacin de roles no es necesaria plasmarla en un documento ya que puede cambiar durante el transcurso del proyecto. Pero al inicio queda de la siguiente manera:  Analista(s) de Negocio: o Administrador de Bases de Datos  Lder(es) de Proyecto: o Lder de Proyecto  Desarrollador(es): o Arquitecto de Sistemas o Administrador de Bases de Datos o Programador Senior  Tester(s): o Programador Senior  Administrador(es) del conocimiento: o Lder de Proyecto o Arquitecto de Sistemas

VI.2.3. Visin del proyecto


Esta etapa est a cargo del Analista de Negocio y el Lder de Proyecto. Una vez terminada debe ser validada por el Cliente antes de poder continuar con el desarrollo del proyecto.

Visin del proyecto


Proyecto Control de Acceso de Usuarios Registrados

110

Necesidades Contar con una aplicacin para verificar los que los datos ingresados por los usuarios que utilizan la aplicacin sean correctos, as como permitir el registro de usuarios tanto empleados internos como empleados externos. Permitir tambin que se asignen perfiles a cada usuario y controlar el acceso a las aplicaciones dependiendo del perfil asignado. Impacto y beneficios Este proyecto permitir contar con un registro y control de acceso de usuarios de la aplicacin. El negocio se beneficiar con una mayor seguridad de la informacin. La asignacin de perfiles de usuario separados, permitir el control de la informacin mostrada a cada uno de los usuarios, manteniendo la confidencialidad y un registro del personal con acceso a cierta informacin.

Caractersticas Debe tener Recibir un nmero de empleado y una contrasea. La autenticacin de la contrasea debe ser realizada con encriptacin MD5. Restringir la longitud del nmero de empleado es de 6 caracteres exactamente. Permitir el alta de empleados internos como usuarios del sistema, verificando sus datos en la base de datos de Recursos Humanos. Permitir el alta de empleados externos como usuarios del sistema verificando sus datos por medio del jefe directo, siempre y cuando este sea un empleado interno y usuario del sistema. Permitir la creacin de perfiles de usuario y asignarles a cada uno de ellos distintas opciones dentro del men. Permitir la asignacin de un perfil a los usuarios registrados en el sistema.

Sera til tener Permitir el cambio de contrasea. Permitir la recuperacin de contrasea siempre y cuando se proporcione un nmero de empleado. No debe permitir que el usuario y la contrasea sean iguales.

111

Permitir la recuperacin del usuario asignado a los empleados externos por medio de la autorizacin del jefe directo.

Agregar si es posible Verificar que la contrasea sea alfanumrica y tenga una longitud mnima de nueve caracteres. Obligar el cambio de contrasea cada 30 das. Desactivar al usuario una vez que sucedan tres intentos fallidos de acceso al sistema en un lapso de 10 minutos. Bloquear la IP despus de diez intentos fallidos de acceso al sistema en un lapso de 10 minutos. Restringir el acceso de un usuario ya firmado en el sistema. Bloquear al usuario despus de un mes de inactividad.

A futuro Reporte de intentos de acceso al sistema. Autenticacin del usuario por medio de huella digital.

Figura 22. Documento de visin

VI.3. FASE DE PLANEACIN


En esta fase se definen entregas, tiempos y prioridades para iniciar con el desarrollo del proyecto.

112

VI.3.1. Plan del proyecto


Conociendo las habilidades de los miembros del equipo de trabajo y las caractersticas que debe llevar la aplicacin, se crea el plan del proyecto. Este plan est a cargo del Lder de Proyecto y se mantendr actualizado durante todo el desarrollo del proyecto. En un inicio el desarrollo est planteado para iniciar el 27 de Agosto de 2007 y se encuentra dividido en cuatro entregas semanales de la siguiente manera:  Primera entrega: o Administracin de perfiles. o Autenticacin de usuarios.  Segunda entrega: o Alta de empleados internos. o Alta de empleados externos.  Tercera entrega: o Cambio de contrasea. o Recuperacin de contrasea. o Obligar cambio de contrasea cada 30 das.  Cuarta entrega: o Bloquear usuarios despus de tres intentos fallidos de acceso o Bloquear IP despus de diez intentos fallidos de acceso. o Restringir acceso de usuarios ya firmados. o Bloquear usuarios despus de un mes de inactividad. o Verificar que la contrasea sea alfanumrica. Como se puede observar en la Figura 23, las caractersticas que se atacarn primero son las que se colocaron dentro de la prioridad debe tener, lo cual hace que la aplicacin funcione desde la primera entrega y las otras tres solamente sean mejoras a lo ya existente.

113

Figura 23. Plan del proyecto

114

VI.3.2. Anlisis de riesgos


Esta etapa es responsabilidad del Lder de proyecto. Con base en el anlisis previo se detect que los riesgos para esta aplicacin son mnimos, sin embargo existen y sern analizados dentro del documento de Listado de Riesgos a continuacin.

Listado de riesgos
Riesgos Riesgo:Restriccin por parte de Recursos Humanos para el acceso a la informacin de su sistema para efectos del desarrollo de la aplicacin. Severidad: 8 (Media) Probabilidad: 4 (Alta) Impacto:2 (Baja) Solucin: Uso de datos ficticios durante el desarrollo del proyecto. Riesgo: Actualizacin de datos fallida por parte del rea de Recursos Humanos. Severidad: 6 (Menor) Probabilidad de ocurrencia:2 (Baja) Impacto de la ocurrencia:2 (Bajo) Solucin: Este riesgo se ignorar ya que las actualizaciones son diarias y no vale la pena perder tiempo y recursos para obtener informacin que existir al da siguiente.

Figura 24. Listado de riesgos

Ahora ya se tienen todos los documentos necesarios para la realizacin del estudio de factibilidad.

115

VI.3.3. Estudio de factibilidad


Una vez que se tuvo todo lo necesario para decidir si la realizacin de este proyecto es factible, los encargados de la decisin son el Analista de Negocio y el Lder de Proyecto. El plan del proyecto est realizado en cuatro iteraciones, una por semana; cada viernes se entrega una liberacin funcional, esto quiere decir que desde la primera semana el usuario podr ocupar el sistema y las siguientes tres iteraciones entregarn mejoras al sistema base. Despus de una breve junta con el usuario en la que se plantearon los puntos analizados previamente, se acord que el tiempo del desarrollo del proyecto es aceptable. Sin embargo, para no descuidar el mantenimiento de los sistemas existentes es necesario que los miembros del equipo estn disponibles para atender los problemas que surjan, lo cual nos obliga a modificar el listado de riesgos y agregar lo siguiente:

Riesgo: Un miembro del equipo de desarrollo requiere atender otros sistemas y es necesario desprenderlo del proyecto. Severidad: 13 (Crtica) Probabilidad:3 (Media) Impacto:5 (Muy Alto) Solucin: Delegar actividades, solicitar un nuevo recurso y reprogramar las fechas del proyecto.

Figura 25. Actualizacin del listado de riesgos

116

VI.4. FASE DE DESARROLLO


Esta fase es iterativa, para efectos de este documento slo se detallar la primera iteracin, las siguientes se comentarn de una manera muy general.

VI.4.1. Anlisis de requerimientos


Dentro de esta etapa de requerimientos se hace referencia a la Visin y al Plan del proyecto, de ambas podemos obtener las caractersticas principales que se van a tratar en esta iteracin del desarrollo:  Administracin de perfiles  Autenticacin de usuarios. Para comenzar el anlisis de requerimientos se crea el Diagrama de Casos de Uso, en el cual usando UML es posible definir las etapas de esta iteracin.

Acceso al sistema Autenticacin de usuarios Usuario Definicin de perfiles de usuario

Relacin de usuario-perfil Administrador Asignacin de perfiles

Figura 26. Diagrama de casos de uso

117

Analizando los requerimientos obtuvimos cinco casos de uso, los cuales deben detallarse para obtener las interacciones entre el sistema y el usuario. A continuacin se detalla el caso de uso de Definicin de perfiles de usuario, para este documento los dems casos de uso slo se comentan.

CU01: Definicin de perfiles de usuario


Actor principal: Administrador del sistema Personal involucrado e intereses:Administrador, le interesa definir perfiles de usuario distintos para cada tipo de usuario del sistema, as como modificarlos y darlos de baja si es necesario. Precondiciones: Ninguna. Garanta de xito: El administrador da de alta un perfil. Escenario principal: Accin del actor 1. El administrador ingresa a la opcin de definicin de perfiles. 2. El sistema muestra los perfiles existentes. 3. El administrador selecciona la opcin de agregar un nuevo perfil. 4. El sistema muestra una pantalla parala captura de datos del perfil. 5. El administrador ingresa los datos requeridos por el sistema: Nombre del perfil. Descripcin del perfil. 6. El sistema agrega la fecha y hora decreacin del perfil y lo almacena en Accin del sisitema

118

labase de datos. El administrador repite los pasos 3-6 hasta haber agregado todos los perfiles deseados. Flujos alternativos: 3.a. El administrador selecciona la opcin de modificar un perfil: 1. El administrador selecciona el perfil a modificar 2. El sistema traslada al administrador a una pantalla en la que permite la modificacin del perfil. 3. El sistema almacena todos los datos de la modificacin en la base de datos. 3.b. El administrador selecciona la opcin de eliminar un perfil: 1. El administrador selecciona el perfil a eliminar. 2. El sistema lleva a cabo el proceso de eliminar el perfil de la base de datos. 5.a. El nombre del perfil ya existe en el catlogo: 1. El sistema notifica al administrador que el nombre seleccionado ya existe. 2. El sistema impide la creacin del perfil en el catlogo. Requisitos especiales:Ninguno. Frecuencia de uso: Ocasionalmente.

Figura 27. Caso de uso de Definicin de Perfiles

De esta misma manera se crean los dems documentos de casos de uso:  CU01: Definicin de perfiles de usuario.  CU02: Asignacin de perfiles.  CU03: Relacin usuario-perfil.  CU04: Acceso al sistema.  CU05: Autenticacin de usuarios.

119

La fase de desarrollo debe iterar al menos cinco veces, ya que son cinco casos de uso a desarrollar. Si durante el desarrollo de un caso de uso se evala que es necesario iterar de nuevo entonces se vuelve al anlisis de requerimientos.

VI.4.2. Diseo de la arquitectura


Una vez que conocemos los primeros casos de uso para trabajar es necesario disear la arquitectura de clases sobre la cual se va a desarrollar el sistema. Para el primer caso de uso definimos una clase llamada Perfil que nos permite el manejo de las propiedades y funciones requeridas para cada uno.

Perfil + id :integer + nombre : string + descripcion : string

AdminPerfil

+ Agregar (objeto Perfil) + Borrar (objeto Perfil) + Modificar (objeto Perfil)

Figura 28. Diagrama de clases inicial

Este diagrama de la arquitectura se ir modificando durante el proceso de desarrollo, por lo pronto estas dos son las nicas clases que nos interesan para este caso de uso. Dentro de la base de datos se define una tabla para guardar los datos del perfil. La tabla de relacin entre perfil y usuario no est definida ya que no trabajaremos con ella en esta iteracin, sin embargo es bueno saber que existe para prevenir cualquier riesgo que pueda presentarse en las siguientes iteraciones.

120

Perfil IdPerfil Nombre Descripcion IndBorrado Tabla de relacin entre perfil y usuario

Figura 29. Diagrama inicial de la base de datos

Estos dos diagramas (clases y base de datos) son los que conforman nuestra arquitectura inicial del sistema. Esta arquitectura se va a ir modificando con cada iteracin, pero al menos esto nos da una idea de cmo trabajar. Los diagramas se plasman en el documento de la arquitectura del sistema para poder continuar con las siguientes fases de desarrollo.

VI.4.3. Desarrollo del sistema


El desarrollo del sistema comienza con la codificacin de las clases analizadas en el caso de uso, as como de la pantalla que va a permitir la interaccin del usuario con las clases y la base de datos. La pgina desarrollada para este caso de uso abarca alta, modificacin y baja de un perfil. La Figura 30 muestra el prototipo de la pantalla que debe ser desarrollada para este caso de uso en especial. Durante el desarrollo nos dimos cuenta que la clase de administracin de perfiles ocupa un mtodo Agregar, otro Modificar y un tercero llamado Borrar. Estos tres mtodos se ocupan en esta clase pero se pueden ocupar en cualquier clase que administre un catlogo, por lo que aprendimos que podemos refactorizar el cdigo y agregar una clase Catlogo que herede la clase AdminPerfil y slo cree una instancia de la clase dentro de ella.

121

Figura 30. Prototipo de la pgina de definicin de perfiles

Este tipo de informacin se agrega al Documento de Aprendizaje de la siguiente manera:

Documento de aprendizaje
Fase: Desarrollo Fecha: 29 de agosto de 2007 Elemento de aprendizaje: Diseo y programacin de clases La clase AdminPerfil utiliza los mtodos Agregar, Modificar y Borrar que pueden ser agregados en una clase llamada Catlogo para as manejar cualquier tipo de movimiento en los catlogos desde una clase. Esto debe implementarse a partir de la siguiente iteracin en los desarrollos nuevos y refactorizando la Definicin de Perfiles.
Figura 31. Documento de aprendizaje

122

El desarrollo de la aplicacin se llev menos tiempo del esperado, lo cual nos da un da de sobra para el desarrollo. Ahora que se tiene la pgina para la definicin de perfiles de usuario es necesario continuar con las pruebas unitarias del sistema.

VI.4.4. Pruebas unitarias


Las pruebas unitarias estaban planeadas para realizarse los das jueves en la maana (durante el tiempo del proyecto), debido a que la codificacin de las clases y el desarrollo de la aplicacin fueron bastante rpidos tenemos, en la primera entrega, un da de sobra, lo cual permite realizar una ltima iteracin por el desarrollo en caso de ser necesario. Dentro de esta actividad se realizaron pruebas unitarias para garantizar la integridad de los datos, la eficiencia de los mtodos de las clases y el manejo de la interfaz con el usuario. Las pruebas fueron terminadas y el Lder de Proyecto evalu que era conveniente modificar la arquitectura del sistema con base en lo aprendido ya que todava se contaba con un da de sobra para la liberacin de la aplicacin.

VI.4.5. Modificacin de la arquitectura


Al iterar de nuevo regresamos a la etapa del Anlisis de Requerimientos, pero como no cambiaron durante la primera iteracin nos movemos directamente a la etapa del Diseo de la Arquitectura. Con base en lo aprendido en la iteracin anterior modificamos el diagrama para agregar la clase Catlogo y qued de la siguiente manera:

123

Catalogo

+ Agregar (objeto) + Borrar (objeto) + Modificar (objeto)

Perfil + id :integer + nombre : string + descripcion : string

AdminPerfil

+ Agregar (objeto Perfil) + Borrar (objeto Perfil) + Modificar (objeto Perfil)

Figura 32. Diagrama de clases modificado

La base de datos no requiere ningn cambio, por lo que se queda de la manera que se defini inicialmente.

VI.4.6. Refactorizacin de las clases modificadas


Debido a que la arquitectura de las clases cambi es necesario adecuar el cdigo del sistema al nuevo diagrama, esto se realiz con rapidez debido a que slo fue necesario crear la nueva clase Catalogo y modificar la clase AdminPerfil, lo dems del sistema no sufri cambio alguno. El documento de aprendizaje no se modifica, ya que aunque se realizaron los cambios propuestos ah es necesario llevar una bitcora de la informacin aprendida para poderla aplicar a las siguientes iteraciones del proyecto.

124

VI.4.7. Segunda etapa de pruebas


En esta etapa las pruebas se realizaron correctamente y no arrojaron ningn error pero tampoco un aprendizaje nuevo, por lo que no fue necesario complementar el documento de aprendizaje. Ahora es necesario crear el documento de casos de prueba para poder realizar las pruebas de funcionalidad con el usuario. El documento qued de la siguiente manera:

Casos de prueba: Definicin de perfiles


Agregar perfil: Ingresar nombre. Ingresar descripcin. Presionar el botn para guardar.

Modificar perfil: Seleccionar perfil de la lista presionando el botn para modificar. Modificar el nombre y/o la descripcin. Presionar el botn para guardar.

Eliminar perfil: Seleccionar el perfil de la lista presionando el botn para eliminar. Presionar Aceptar en el mensaje de confirmacin.

Figura 33. Documento de casos de prueba

La segunda iteracin se realiz en un da, por lo que la entrega de esta etapa del desarrollo se har en el tiempo indicado.

125

VI.5. FASE DE ESTABILIZACIN


Dentro de esta fase se realizan las pruebas con el usuario utilizando el documento de casos de prueba y evaluando si debe liberarse esta parte del sistema.

VI.5.1. Pruebas de funcionalidad


El da estipulado en el plan del proyecto se presentan las aplicaciones al usuario, en este caso slo detallamos el caso de uso de Definicin de Perfiles, pero a la par se fue haciendo el caso de uso de Autenticacin de Usuarios del sistema. Estos dos casos de uso son los que se pondrn a prueba este da con el usuario del sistema. Al usuario se le explican los puntos atacados conforme al caso de uso realizado en el anlisis de requerimientos, una vez que se le explica lo que debe hacer el sistema se le entrega el Documento de Casos de Prueba para que lo utilice a manera de guin y decida si en verdad esta parte del sistema cumple con las necesidades mencionadas al inicio del proyecto. En este momento el usuario puede proponer nuevos requerimientos o modificaciones a los casos de uso entregados. Sin embargo las observaciones que realiz el usuario ya se encuentran contempladas para los siguientes casos de uso y las siguientes iteraciones del sistema. El usuario autoriza la liberacin de la primera etapa del sistema y se contina con el proyecto conforme al plan de trabajo.

126

VI.5.2. Liberacin
La liberacin de la primera etapa del sistema se realiza con xito ya que se contaba por parte del usuario con un servidor configurado de igual manera que el servidor de desarrollo, por lo que el proceso ocurre sin errores.

VI.6. REVISIN DE LAS ACTIVIDADES DE SOPORTE


Este momento es ideal para que el Lder de Proyecto evale las actividades de soporte, despus de una semana de trabajo cada miembro del equipo debe tener una impresin acerca del desarrollo del proyecto.

VI.6.1. Administracin del plan de trabajo


El desarrollo del proyecto pareca holgado en un momento, pero gracias a eso se pudo invertir tiempo en la modificacin de la arquitectura y la refactorizacin del cdigo de las clases utilizadas. Las juntas diarias programadas a las 9:00 a.m. no pudieron ser realizadas conforme al horario debido a que dos das de los cinco de la semana algunos miembros del equipo llegaron tarde, por lo que la primera vez se inici la junta sin el equipo completo pero oblig a un retraso mayor ya que se le tuvieron que explicar los puntos tratados y las soluciones propuestas, por lo que la segunda vez la junta se realiz con 20 minutos de retraso pero implic una menor prdida de tiempo ya que cada miembro tena actividades fuera de la junta.

127

VI.6.2. Administracin del personal


Durante esta etapa del proyecto no se presentaron fricciones de carcter personal entre los miembros del equipo. Tampoco se detect a ningn miembro por debajo del nivel requerido para el desarrollo del proyecto, sin embargo el Arquitecto de Sistemas mostr inters en el desarrollo de las bases de datos, lo cual no es su habilidad ms fuerte, pero para la siguiente etapa del sistema estar trabajando ms de cerca con el Administrador de Bases de Datos para que fortalezca sus conocimientos acerca del tema.

VI.6.3. Administracin del conocimiento


El conocimiento adquirido en esta etapa fue bsicamente acerca de la arquitectura del sistema y la definicin de clases. Se tuvo tiempo para implementarlo desde el inicio por lo que las siguientes etapas estarn trabajando sobre este esquema y dejando la arquitectura abierta para mejoras.

VI.7. FASES DE DESARROLLO COMPLEMENTARIAS


Debido a que este mtodo es iterativo, las siguientes fases de desarrollo se enfocan en desarrollar los requerimientos analizados para sus respectivas entregas: Segunda entrega:  Alta de empleados internos.  Alta de empleados externos.

128

Tercera entrega:  Cambio de contrasea.  Recuperacin de contrasea.  Obligar cambio de contrasea cada 30 das. Cuarta entrega:  Bloquear usuarios despus de tres intentos.  Bloquear IP despus de diez intentos.  Restringir el acceso de usuarios ya firmados.  Bloquear usuarios despus de un mes de inactividad.  Verificar que la contrasea sea alfanumrica. Para efectos de este documento, slo se abarcarn las reas de Administracin del Plan de Trabajo, Administracin de Personal, Anlisis de Riesgos y Administracin de Conocimiento. Esto es debido a que el dems proceso de desarrollo es similar y no tiene caso repetirlo. A continuacin se detalla un breve resumen de lo que fueron las reas antes mencionadas dentro de las siguientes etapas de desarrollo.

VI.7.1. Plan de trabajo


Durante las siguientes tres fases de desarrollo se modific muy poco el plan de trabajo, la aplicacin sali en tiempo y de cierta manera un poco holgados. Lo cual nos permiti implementar mejoras que no se haban considerado.

129

Al trmino del desarrollo se contaba con dos das ms de sobra, lo cual habla de una subestimacin de la capacidad de los recursos o una sobreestimacin del problema a ser atacado. Esos dos das fueron ocupados para realizar tareas que originalmente se haban dejado a futuro en la visin inicial del proyecto, como lo son:  Autenticacin de usuarios por medio de huella digital.  Reporte de intentos de acceso al sistema. En la parte de la autenticacin de usuarios por huella digital, slo se gener el esqueleto de la clase que va a administrar el acceso por este medio, para que cuando se implemente el cambio a esta aplicacin sea lo ms transparente posible. En el caso del reporte de intentos de acceso al sistema, se ocuparon un par de das en definir un reporte de texto a ser desplegado dentro del sistema: incluye el usuario, la fecha y hora en la que trat de ingresar y el nmero de intentos. Este reporte fue implementado como un extra al sistema dentro de la cuarta liberacin. El plan de trabajo fue terminado en el calendario pactado, ms un reporte que no se haba contemplado inicialmente; sin embargo, el clculo del tiempo fue errneo. Esto se plasm dentro del documento de aprendizaje para prevenir los siguientes desarrollos y no caer en el mismo error, tal como se detallar posteriormente. Como puede observarse en la Figura 34, los cambios al plan de trabajo se fueron presentando a partir de la tercera entrega.

130

Figura 34. Plan de trabajo final

131

VI.7.2. Administracin del personal


Dentro de esta etapa se haba contemplado el riesgo de que alguno de los miembros del equipo fuera requerido para atender requerimientos o pendientes dentro de los sistemas existentes. Aunque estaba previsto, durante la segunda etapa de desarrollo se present la necesidad de prestar a un recurso por dos das, esto repercuti en el sentido del tiempo, la segunda entrega tuvo que entregarse con algunas deficiencias, las cuales no eran visibles para el usuario, sin embargo afectaban la arquitectura interna del sistema. Una vez que se recuperaron los recursos completos se trabaj para refactorizar el cdigo y reparar el diseo de la arquitectura del sistema. Al final del desarrollo, fue posible observar que algunos recursos demostraron que la evaluacin inicial del personal fue, en algunos casos, subestimada y en otros sobreestimada; por lo que fue necesario modificarla para mantenerla actualizada y qued de la siguiente manera:

Evaluacin del personal

Arquitecto de sistemas
Amplios conocimientos en el diseo de arquitecturas de sistemas, experto en el desarrollo de sistemas utilizando Visual Basic 2005 y C#, conocimiento bsico en el desarrollo de bases de datos. Fecha de inicio y fin del recurso en el proyecto: Proyecto finalizado el 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana)

132

rea del recurso: Gerencia de sistemas

Administrador de Bases de Datos


Alta capacidad de anlisis lgico para bases de datos, experto en el diseo de bases de datos utilizando SQL 2005, conocimiento bsico en el desarrollo de sistemas utilizando Visual Basic 2005. Fecha de inicio y fin del recurso en el proyecto: ltimo proyecto finalizado el 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana) rea del recurso: Gerencia de sistemas

Programador Senior
Nivel intermedio en el desarrollo de sistemas utilizando Visual Basic 2005, conocimientos intermedios de diseo de bases de datos. Amplio conocimiento de la aplicacin y alta capacidad de comprensin y anlisis de requerimientos. Fecha de inicio y fin del recurso en el proyecto: ltimo proyecto finalizado el 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana) rea del recurso: Gerencia de sistemas

133

Lder de Proyecto
Amplio conocimiento en la aplicacin a la cual se le va a desarrollar el mdulo de acceso de usuarios, experto en el diseo de bases de datos, conocimientos intermedios del desarrollo de sistemas utilizando Visual Basic 2005 y conocimientos bsicos en el uso de C#. Fecha de inicio y fin del recurso en el proyecto: ltimo proyecto finalizado el 21 de septiembre de 2007 Disponibilidad prevista: Jornada laboral completa (8 horas diarias, 5 das a la semana) rea del recurso: Gerencia de sistemas

Figura 35. Evaluacin del personal modificada

VI.7.3. Anlisis de riesgos


De los riesgos planteados al inicio, slo dos ocurrieron, y tal como se haba previsto, el nico que realmente repercuti en el desarrollo fue el hecho de perder a un elemento del equipo por un tiempo para dedicarse a la atencin de requerimientos y pendientes de los sistemas que existen actualmente en produccin. El otro riesgo que ocurri fue problema de acceso a los datos de recursos humanos, ya que fue lento y se logr concretar hasta la mitad de la tercera semana de desarrollo. Mientras tanto, el equipo trabaj con datos ficticios, lo cual no repercuti en un impacto considerable al proyecto.

134

VI.7.4. Administracin del conocimiento


Durante las tres etapas de desarrollo que siguieron se observaron algunas mejoras, las cuales se plantearon en el documento de aprendizaje de la siguiente manera

Fase: Previa al inicio Fecha: 24 de septiembre de 2007 Elemento de aprendizaje: Evaluacin del personal Al realizar la evaluacin inicial del personal es necesario basarse en experiencias previas ms que en suposiciones. En caso de no contar con una experiencia previa, es necesario evaluar los conocimientos y asignar no ms de un nivel intermedio en conocimiento para no caer en errores del clculo de tiempo. Fase: Planeacin Fecha: 24 de septiembre de 2007 Elemento de aprendizaje: Plan del proyecto El plan de trabajo debe ser calculado evaluando las cualidades y debilidades del equipo de trabajo en conjunto as como de cada uno de sus individuos. Es necesario que los recursos sean complementados con base en sus conocimientos.

Figura 36. Documento de aprendizaje final

VI.8. EVALUACIN FINAL DEL SISTEMA


Al trmino de las cuatro semanas de desarrollo, se cumpli con la meta estipulada inicialmente en la Visin del Proyecto as como dos mdulos extras que estaban contemplados a futuro. Los mdulos de la aplicacin realizados fueron desarrollados y probados completamente tanto por el equipo de desarrollo como por el usuario de la aplicacin. Toda la documentacin requerida fue realizada y almacenada para su consulta posterior.

135

CONCLUSIONES
Durante el desarrollo de este documento, hemos tenido la oportunidad de revisar las tendencias de las metodologas de desarrollo de software a lo largo de la historia. De esta manera, basndome en las lecciones aprendidas a lo largo de cinco dcadas, es que desarroll este mtodo de trabajo para equipos pequeos. Este mtodo de desarrollo de software se aplic a un equipo de trabajo de cuatro personas. De acuerdo a los resultados obtenidos, puedo concluir lo siguiente: 1. La comunicacin del equipo de trabajo mejor debido a la realizacin de reuniones diarias. La falta de comunicacin dentro del equipo de trabajo era una de las mayores causas de retrasos dentro del proyecto. Con la implementacin de STASD se consigui mejorar la comunicacin y reducir los retrasos de das a horas. 2. El usuario final del sistema (el cliente) perciba una aparente falta de inters del equipo de trabajo a su proyecto. Esto se deba a que durante das o, en ocasiones, semanas; el usuario del sistema no tena retroalimentacin del equipo de trabajo ni actualizaciones del proyecto. Esto se mejor con los entregables semanales (iteraciones) del proyecto. La percepcin del usuario con respecto al equipo de desarrollo mejor y se logr obtener una evaluacin de 4 en escala del 1 al 5 en servicio y atencin al cliente; as como lograr que el usuario se comprometiera (y cumpliera) con las fechas de realizacin de pruebas y validacin de la aplicacin. 3. La productividad del equipo de trabajo mejor en un 16.67%. De 12 Casos de Uso planeados en 4 entregas semanales; se entregaron 14 mdulos en el mismo tiempo. Y, aunque no se pudo reducir el tiempo de desarrollo de los sistemas, se logr entregar un producto por encima de la expectativa del cliente. 4. Antes de la aplicacin del mtodo, el proceso de asignacin del personal se realizaba empricamente, basndose en la premisa de que todos los miembros 137

del equipo tenan las mismas capacidades y conocimientos. Despus de aplicar el mtodo, se logr tener un registro actualizado de las capacidades y conocimientos de cada uno de los miembros del equipo de trabajo. De esta manera, al asignar un recurso a un nuevo proyecto, se podr revisar su historial y decidir con base en la historia quien es el recurso ms adecuado para determinada tarea. 5. El proceso emprico de levantar requerimientos y codificar dej de utilizarse al momento de aplicar el mtodo STASD. Esto permiti mantener el orden en el proceso de desarrollo, as como la documentacin correspondiente. 6. Las pruebas del sistema se realizaron ordenadamente, mediante una lista de Casos de Uso y su evaluacin. De esta manera se pudo definir si s o no se haba cumplido el requerimiento. En este caso de estudio tuve la fortuna de tener el 100% de entregables completos; pero de haber existido alguno incompleto, habra podido medirse mediante las pruebas del sistema cotejadas con los Casos de Uso. 7. Por ltimo, el desarrollo del sistema fue documentado y por primera vez se tiene una carpeta de los proyectos realizados por el equipo de desarrollo. Estos documentos incluyen la arquitectura y la definicin del sistema. De esta manera, en un futuro se podr acceder a la documentacin directamente sin tener la necesidad de analizar el cdigo de nuevo, ahorrando tiempo de anlisis. De esta manera, puedo concluir que STASD es un mtodo de desarrollo exitoso dentro de la empresa Incorprea. Su tendencia a realizar proyectos pequeos (de 2 a 24 semanas), indica que de seguirse ocupando, podr mejorar los tiempos de entrega y el control de actividades dentro del proyecto.

138

REFERENCIAS
LVAREZ, Elisa. Creatividad y Pensamiento Divergente. Obtenida el 28 de agosto de 2010 dehttp://www.interac.es/adjuntos/crea_pensa_diver.pdf AMARO CALDERN, giles. Sarah Dmaris, el Jorge 28 de Carlos agosto Valverde de Rebaza. 2010 de Metodologas Obtenida

http://www.seccperu.org/files/Metodologias%20Agiles.pdf ANACLETO, Valerio. Introduccin a UML 2.0. Obtenida el 26 de agosto de 2010 de http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId =15 BECK, Kent. Una explicacin de la programacin extrema. Aceptar el cambio. Addison Wesley, 2000. BECK, Kent.Manifesto for Agile Software Development.Agile Alliance.Obtenida el 17 de marzo 2007 dehttp://www.agilemanifesto.org/ BOOCH, Grady. El Lenguaje Unificado de Modelado. Pearson Educacin, 2006. BRAUN, David, Jeff Sivilis, Alex Shapiro, Jerry Versteegh. UnifiedModelingLanguage (UML) Tutorial.Obtenida el 26 de agosto de 2010 dehttp://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm CHARVAT, Jason. Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects.John Wiley & Sons, 2003. COAD, Peter, Eric Lefebvre, Jeff De Luca.Feature-Driven Development.Obtenida el 19 de junio de 2007 dehttp://www.cs.jhu.edu/~scott/oos/software/ togetherj/help/Users-Guide/Feature_Driven_Development.htm COCKBURN, Alistair. Writing Effective Use Cases.Addison-Wesley, 2000. COCKBURN, Alistair. Agile Software Development.Addison-Wesley. 2001. FOWLER, Martin. The New Methology.Thought Works.Obtenida el 24 de marzo 2007 dehttp://www.martinfowler.com/articles/newMethodology.html FOWLER, Martin. Continuous Integration.Thought Works.Obtenida el 24 de marzo 2007 dehttp://www.martinfowler.com/articles/continuousIntegration.html

139

HIGHSMITH, Jim. Agile Software Development Ecosystems.Addison-Wesley, 2002. IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.121990, 1990. KERZNER, Harold. Project Management, A Systems Approach to Planning, Scheduling and Controlling.7a Ed. John Wiley & Sons,, 2001. KRUCHTEN, Philippe. The Rational Unified Process: An Introduction, 2a Ed. Addison-Wesley, 2000. MARTIN, James. Rapid Application Development.Macmillan Inc., New York, 1991. MARTIN, James. Anlisis y Diseo Orientado a Objetos.Prentice Hall, 1994. MARTIN, Robert C. Agile Software Development, Principles, Patterns, and Practices.2a Ed. Prentice Hall, 2002. PALACIO, Juan. Presentacin de SCRUM,Navegapolis. Obtenida el 13 de Junio de 2007 dehttp://www.navegapolis.net/index.php?option=com_content &task=view PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK GUIDE) Fourth Edition.PMI, 2008. REYNOSO, Carlos. Mtodos el 24 Heterodoxos de mayo en Desarrollo de 2007 de de Software.MSDN.Obtenida

http://www.microsoft.com/spanish/msdn/ arquitectura/roadmap_arq/heterodox.asp ROYCE, Walker. Software Project Management, A Unified Framework.AddisonWesley, 1998. ROYCE, Winston. Managing the Development of Large Software Systems.Proceedings of IEEE Westcon, 1970. SCHWABER, Ken. Agile Project Management with Scrum.Microsoft Press, 2004. STAPLETON, Jennifer. DSDM Dynamic Systems Development Method.AddisonWesley, 1997. VERZUH, Eric. The Fast Forward MBA in Project Management.Willey, 2008. YOURDON, Edward. AnlisisEstructuradoModerno.Prentice Hall, 1993.

140

APNDICES

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT


We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Traducido al espaol, este manifiesto quiere decir: Estamos descubriendo mejores maneras de desarrollar software mediante su construccin y ayudando a otros a construirlo. A travs de este trabajo hemos llegado a valorar: Individuos e interacciones sobre procesos y herramientas Software trabajando sobre documentacin comprensiva Colaboracin del cliente sobre negociacin del contrato Responder al cambio sobre seguir un plan Esto es, mientras exista un valor en los trminos de la derecha, valoramos ms los trminos de la izquierda.

141

MAPA DE LOS ARTEFACTOS DEL MTODO


Inicio
y Documento de Estndares y Documento de Evaluacin del Personal y Documento de Visin

Planeacin
y Plan del Proyecto y Listado de Riesgos

Desarrollo
y Documento de Caso de Uso y Diagrama de Casos de Uso y Diagrama de la Arquitectura

Pruebas Aprendizaje
y Documento de Aprendizaje y Documento de Casos de Prueba

Entrega
y Paquete de Liberacin

142

PLANTILLAS DE LOS ARTEFACTOS UTILIZADOS


La manera de manejar los artefactos utilizados esta definida por plantillas, para algunos artefactos no es necesario definirlas dentro de los apndices ya que utilizan una notacin establecida. Los artefactos definidos dentro de este mtodo son:  Documento de estndares.  Documento de evaluacin del personal.  Documento de visin del proyecto.  Listado de riesgos.  Documento de casos de uso.  Documento de casos de prueba.  Documento de aprendizaje. Los siguientes artefactos ocupan alguna notacin ya establecida:  Plan del proyecto (Diagrama de Gantt).  Diagrama de casos de uso (UML).  Diagrama de la arquitectura (UML).

Documento de estndares
Plantilla de documento de estndares
Tipo: [Tipo de los estndares definidos] Versin: [Nmero de versin] [Elemento a ser estandarizado] [Descripcin de los estndares]

143

[Elemento a ser estandarizado] [Descripcin de los estndares]

Documento de evaluacin del personal


Evaluacin del personal
Nombre: [Nombre del recurso] [Cualidades y deficiencias que puedan beneficiar o afectar al proyecto] Fecha de inicio y fin del recurso en el proyecto: [Fechas planeadas para el inicio y fin del recurso en el proyecto] Disponibilidad prevista: [Descripcin de la disponibilidad del recurso para atender el proyecto] rea del recurso: [Nombre del rea a la que pertenece el recurso]

Documento de visin
Plantilla del documento de la visin del proyecto
Proyecto [Nombre y versin del proyecto]

144

Necesidades [Explicacin de las necesidades generales del proyecto] Impacto y beneficios [Explicacin del impacto del proyecto en el negocio, as como sus beneficios] Caractersticas Debe tener [Caractersticas]

Sera til tener [Caractersticas]

Agregar si es posible [Caractersticas]

A futuro [Caractersticas]

Listado de riesgos
Listado de riesgos
Riesgos Riesgo:[Descripcin del riesgo]

145

Severidad: [Severidad = Probabilidad + (Impacto * 2)] 1 a 7: Menor 8 a 11: Media 12 a 15: Crtica

Probabilidad: 1. Muy Baja: Sera sorpresa que sucediera 2. Baja: Es ms probable que no suceda a que suceda 3. Media: Igualmente probable que suceda a que no suceda 4. Alta: Es ms probable que suceda a que no 5. Muy Alta: Sera sorpresa que no sucediera

Impacto:[Muy alto (5) / Alto (4) / Medio (3) / Bajo (2) / Muy bajo (1)] 1. Muy Bajo: Retraso prcticamente insignificante 2. Bajo: Retraso del 5% o menos 3. Medio: Retraso de entre el 5% y el 10% 4. Alto: Retraso de entre el 10% y el 20% 5. Muy Alto: Retraso de ms del 20%

[Matriz de severidad] 5 4 Probabilidad 3 2 1 7 6 5 4 3 1 9 8 7 6 5 2 11 10 9 8 7 3 Impacto 13 12 11 10 9 4 15 14 13 12 11 5

146

Solucin: [Descripcin de la solucin]

Documento de casos de uso


[Clave]: [Descripcin]
Actor principal: [Rol del actor principal] Personal involucrado e intereses:[Descripcin del personal involucrado] Precondiciones: [Definir si existe alguna precondicin para este caso de uso] Garanta de xito: [Descripcin del resultado exitoso del caso de uso] Escenario principal: Accin del actor 1. [Descripcin] 2. [Descripcin] 3. 4. Flujos alternativos: 1.a. [Descripcin del flujo alterno] 1. [Pasos del flujo] 2. Requisitos especiales:[Describir si existe algn requisito no contemplado] Frecuencia de uso: [Continuo / Ocasionalmente / Rara vez] Accin del sistema

147

Documento de casos de prueba


Casos de prueba: [Nombre del caso de uso]
[Accin del sistema]: [Descripcin del procedimiento]

Documento de aprendizaje
Documento de aprendizaje
Fase: [Fase a la cual pertenece el aprendizaje] Fecha: [Fecha de registro] Elemento de aprendizaje: [Elemento al cual aplica el aprendizaje] [Descripcin del aprendizaje obtenido]

148

FORMATO DE REVISIN DE TESIS

Mxico, D.F. a 30 de noviembre de 2010.

Hacemos constar que el trabajo de Tesis que lleva como ttulo Mtodo de Desarrollo de Sistemas para Equipos de Trabajo Pequeos desarrollado por el alumno Oscar Emiliano Cecea Fujigakipara obtener el grado (ttulo) deLicenciado en Ingeniera en Computacin; ha sido revisado en los aspectos metodolgicos y de contenido quedando a nuestra entera conformidad, por lo que el trabajo mencin queda aprobado.

Miembros del Jurado

NOMBRE

FIRMA

1. Ivn Jos Mrquez Larios

2. Miguel Orozco Malo

3. Elvia Delgado Daz

149

S-ar putea să vă placă și