Documente Academic
Documente Profesional
Documente Cultură
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
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
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.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
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.
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
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
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
En este captulo se explican conceptos bsicos importantes para entender el desarrollo del trabajo en general.
IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
16
17
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.
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)
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
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
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.
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
25
Diseo
Implementacin
Anlisis
Pruebas
Liberacin
26
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
28
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.
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
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.
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
Estndares de codificacin
Reestructuracin
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
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
37
ScrumDai ly Meeting
Reunin retrospectiva
ProductBacklog
Visin
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
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.
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.
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.
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.
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
Revisin de calidad
QA final y entrega
Especular
Colaborar
Aprender
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
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
50
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.
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
Adhocracia (Caos)
Metodologas giles
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.
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.
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
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.
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.
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.
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
Programador
Programador
Programador
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.
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
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,
61
63
64
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
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.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.
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
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.
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
Lder de proyecto
COMUNICACIN
Tester
Desarrollador
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
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
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 desarrollo
Desarrollo
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.
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.
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.
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
Anlisis de requerimientos
Desarrollo
Pruebas de funcionalidad
Liberacin Iteracin
Entrega
Tal como se puede observar en el diagrama anterior, la mayora de las actividades son iterativas. A continuacin describiremos cada una de ellas.
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.
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
86
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
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.
90
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
Previo
Documento de Visin
Inicio
Listado de Riesgos
Planeacin
Diagrama de la Arquitectura
Documento de aprendizaje
Iteracin
Paquete de Liberacin
Iteracin
Entrega
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.
94
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.
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.
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.
98
Definicin de Estndares
Documento de Estndares
Fase de Preparacin
Asignacin de Roles
Documento de Visin
Fase Creativa
Anlisis de Riesgos
Listado de Riesgos
Diseo de la arquitectura
Anlisis de requerimientos
Diagrama de la Arquitectura
Pruebas unitarias
Documento de Aprendizaje
Pruebas de Funcionalidad
Liberacin
99
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.
Con base en esta informacin podemos crear los estndares de programacin. Comenzaremos con la definicin de estndares de la base de datos.
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) */ */ */ */
/********************************************************/
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)
*******************************************************
Ahora que se tienen los estndares definidos podemos continuar con la siguiente etapa de la fase de preparacin.
107
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
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
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
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.
112
113
114
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.
Ahora ya se tienen todos los documentos necesarios para la realizacin del estudio de factibilidad.
115
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.
116
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.
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.
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.
AdminPerfil
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
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.
121
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.
123
Catalogo
AdminPerfil
La base de datos no requiere ningn cambio, por lo que se queda de la manera que se defini inicialmente.
124
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.
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
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.
127
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.
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
131
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
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
134
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.
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
141
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
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
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]
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%
146
147
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
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.
NOMBRE
FIRMA
149