Mejores Prcticas de Desarrollo de Software

3. MEJORES PRCTICAS PARA EL DESARROLLO DE SOFTWARE Las mejores prcticas para el desarrollo de un software determinado, depender de la finalidad de su posterior uso. La organizacin que requiera de un sistema de software tendr que acoplar sus necesidades hacia el modelo ms adecuado para optimizar su funcionamiento y rendimiento. Se considerar de igual manera las caractersticas del modelo del proceso de software, para que de esa manera se pueda tener una visin clara respecto a su calidad y de su posterior funcionamiento. Es decir, por lo anteriormente argumentado, no existe un modelo de proceso de software estndar que se adecue para cualquier tipo de requerimiento. Pero se puede denotar las ms populares con respecto a su uso en la actualidad. 3.1 EXTREM PROGRAMING (XP) Las siglas XP significan (extreme programing) que traducido al castellano significa (programacin extrema), es una metodologa que se utiliza para desarrollar un software de alta calidad de la manera ms rpida posible, cualidad a la cual se deriva el nombre de dicha metodologa. Caracterizada tambin por brindarle un mayor beneficio al cliente. Segn Borrero (2004), se caracteriza por tener ciclos de desarrollo extremadamente breves, integracin constante, retroalimentacin contina por parte del cliente, pruebas automatizadas regulares y enfoque de equipo. En sntesis, XP se va a caracterizar principalmente por tener en cuenta al factor humano como componente clave en su desarrollo. Segn Gmez y Ania (2008), XP tambin se caracteriza por tomar en cuenta todas las posibles desventajas en el desarrollo de software y genera prcticas para vencerlas o disminuir sus consecuencias. 3.1.1 LAS VARIABLES DE XP Las variables que existen dentro de la metodologa XP tienen un valor muy importante durante su ciclo de vida, ya que la interaccin entre estas variables y el control de las mismas son indispensables para el xito del proyecto. Segn Gmez y Ania (2008), XP es un modelo de desarrollo de software en la que hay cuatro variables que juegan un papel fundamental: costo, tiempo, calidad y alcance. *+ El control de estas variables es llevado a cabo por los programadores, administradores y clientes. 3.1.2 PRINCIPIOS BSICOS DE XP Segn Gmez y Ania (2008), Los principios bsicos que ofrecen medios ms concretos para aplicarlos son: retroalimentacin rpida, simplicidad, cambios incrementales, cambios sin alterar lo ya desarrollado y trabajo de calidad.

3.1.2.1 RETROALIMENTACIN RPIDA Se aplica una retroalimentacin en relacin al mismo sistema. Todo lo aprendido respecto con la experiencia del sistema se debe aplicar dicho sistema cuanto antes. 3.1.2.2 SIMPLICIDAD XP promueve soluciones simples que se adecuen hacia necesidades actuales, eso en vez de dedicar empeo en tratar de buscar una solucin estndar. 3.1.2.3 CAMBIOS INCREMENTALES Consiste en hacer mnimos cambios, que en conjunto sirvan para dar solucin a un problema. 3.1.2.4 CAMBIOS SIN ALTERAR LO YA DESARROLLADO Cada cambio realizado servir para aumentar las funcionalidades que se encuentran resueltas, ms no para remplazarlas. 3.1.2.5 TRABAJO DE CALIDAD Sirve esencialmente para evitar el fracaso en el proyecto. Se basa en que todos los miembros del equipo comparten el mismo objetivo para un desarrollo ptimo. 3.1.3 LAS PRCTICAS DE XP Considerando los principios bsicos anteriormente presentados, se plantean las prcticas requeridas para usar una metodologa XP en el desarrollo de software de alta calidad. 3.1.3.1 PLANEACIN Se debe de considerar las prioridades del negocio como al igual que las estimaciones tcnicas. 3.1.3.2 ALCANZE PEQUEO XP plantea que se realicen planes para periodos cortos como pudieran ser uno o dos meses aproximadamente. 3.1.3.3 METFORA Permitir identificar los elementos ms relevantes del sistema y la relacin existente entre ellos. 3.1.3.4 DISEO SENCILLO El diseo hacia la solucin de problemas deber de incluir solamente los elementos que sean necesarios para resguardar los requerimientos actuales. 3.1.3.5 PRUEBAS Segn Gmez y Ania (2008), XP lleva este concepto al extremo, por lo que sostiene que cualquier funcin de un programa que no sea probada no existe. 3.1.2.6 REESTRUCTURACIN Se buscar simplificar el programa despus de habrsele agregado nuevas funcionalidades. 3.1.3.7 PROGRAMACIN DE PARES La programacin se asigna hacia dos personas. Segn Gmez y Ania (2008), uno se concentra en buscar la mejor manera de implementar el mtodo, mientras que el otro analiza el problema ms globalmente. 3.1.3.8 PROPIEDAD COLECTIVA Todos los integrantes del equipo son propietarios del sistema, por ello todos tienen la posibilidad de modificar la codificacin en indeterminado instante. 3.1.3.9 INTEGRACIN CONTINA

Segn Gmez y Ania (2008), se debe ir integrando y probando el cdigo de manera continua. *+ El cdigo integrado deber pasar todas las pruebas definidas.

3.1.3.10 CODIFICACIN ESTANDAR Segn Gmez y Ania (2008), Se requiere establecer un estilo comn de codificacin. *+ XP propone que el estndar sea lo ms sencillo posible. En sntesis, la metodologa XP (programacin extrema) es actualmente una de las ms populares por su fcil accesibilidad de uso. Sus propiedades se adecuan ms hacia un modelo estndar. El factor humano que interviene en el desarrollo de esta metodologa es una pieza clave para la evolucin del proyecto. Considera conceptos bsicos de un sistema dentro de sus prcticas. Pues la constante evolucin de su sistema garantiza un mejoramiento seguro de l.

3.2 METODOLOGA RUP 3.2.1 INTRODUCCIN A LA METODOLOGA RUP Consideramos a la metodologa RUP como una de las ms importantes o grandes prcticas que hay en el mundo del software; esto debido a los ciclos iterativos, a su vez divididas en grandes fases o etapas, se pueden adaptar al contexto o cualquier necesidad de una empresa. Las caractersticas principales de esta metodologa son, bsicamente, la de ser un proceso cclico, iterativo e incremental; adems de estar dirigidos a los Casos de Uso y arquitectura del software requerido. La metodologa RUP, tambin consta de 4 grandes fases para lograr un ptimo desarrollo del software; entre las cuales se tiene a la fase de inicio, elaboracin, construccin y transicin. Una de las causas del porqu elegir la metodologa RUP, se inicia cuando una institucin o empresa piensa en grande; es ah donde se toma como modelo de referencia a esta metodologa. Teniendo como base la idea de que cada fase es una iteracin larga, constante y dinmica. Esto explica el largo tiempo de vida del software una vez adaptado a esta metodologa. Como gran consecuencia de un rato de espera se obtiene un ptimo resultado. 3.2.2 DEFINICIN DE METODOLOGA RUP Segn Fowler (2002), el Proceso Unificado Racional (Rational Unified Process en ingls, conocido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. Est basada en una integracin de forma unificada, cohesiva y adaptable del desarrollo de sistemas de software. Por tal razn es que este sistema no est del todo definido; sino que, como ya se mencion, se adaptan al contexto y necesidad de cada organizacin.

3.2.3 CARACTERSTICAS FUNDAMENTALES Se destaca que el proceso de software en esta metodologa tiene 3 caractersticas fundamentales las cuales son: Casos de Uso, Arquitectura e Iteracin e Incremento. 3.2.3.1 CASOS DE USO Segn Kruchten (2002), los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que sera [sic] bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos funcionales del sistema. Los Casos de Uso, entonces, se refiere a las necesidades que el software requiere como parte para su posterior desarrollo. El encargado de verificar estos requisitos es el usuario quien se dispone a pensar qu es lo fundamental para que el software pueda tener todo lo indispensable. Todo lo que tiene ver con la implementacin, prueba y gua del diseo del producto del software tambin es verificada por los Casos de Uso. No son slo los que inician el proceso de desarrollo sino que proporcionan una secuencia organizada, estableciendo as el diseo entre las fases que son producidas en las distintas realizaciones del proceso de desarrollo del software. En sntesis, se puede decir que implantar los Casos de Uso en esta metodologa RUP constituir en el proceso, un elemento conciliador o integrador y una gran gua del trabajo para la elaboracin del software. 3.2.3.2 ARQUITECTURA La metodologa RUP adems de utilizar los Casos de Uso para guiar el proceso, tambin da especial atencin al temprano establecimiento de una buena arquitectura para que no se vea muy impactada ante posteriores cambios durante la construccin y el mantenimiento del software. El proceso busca entender los aspectos estticos y dinmicos ms resaltantes en trminos de arquitectura de software. La arquitectura va a depender de las necesidades de los usuarios y se precisa a partir de los Casos de Uso. La arquitectura de un sistema es la organizacin o estructura de sus partes ms importantes, permite tener una visin usual entre todos los desarrolladores y usuarios; y una perspectiva notable del sistema completo, necesaria para controlar el desarrollo. Debe tomar en cuenta elementos de calidad del sistema, reutilizacin, rendimiento y capacidad de evolucin por lo que debe ser flexible durante todo el proceso. Existe una interaccin entre la arquitectura y los Casos de Uso, estos ltimos deben ajustarse en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso necesarios, actuales y posteriores. En pocas palabras, tanto la arquitectura como los Casos de Uso deben evolucionar en paralelo durante todo el proceso de desarrollo de software. 3.2.3.3 ITERATIVO E INCREMENTAL Segn Jacaboson, Booch y Rumbaugh (2000), la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes ms pequeas o

mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin del cual se obtiene un incremento que produce un crecimiento en el producto. Esto quiere decirnos que, el proceso reconoce que es conveniente dividir grandes proyectos en otros ms pequeos o mini-proyectos. Cada mini-proyecto alcanza una iteracin que resulta en un incremento. Las iteraciones son planeadas en base a los Casos de Uso. Una iteracin puede darse por medio de una cascada a menor escala. Se pasa por los flujos fundamentales: Requisitos, Anlisis, Diseo, Implementacin y Pruebas. Tambin existe una planificacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores. CONCLUSIONES

1. En conclusin con el primer captulo, es importante tener en cuenta el concepto claro de software y de sus objetivos como herramienta. 2. Los objetivos del software nos permitirn tener una visin clara respecto a su posterior funcionamiento para una determinada finalidad, por ello es importante tenerlos en cuenta. 3. Para desarrollar un producto de software se requiere de todo un proceso. El cual esta predefinido por una diversidad de modelos. Es elemental tener en cuenta los modelos que se adapten para un proyecto requerido, para obtener como producto de ello una funcionalidad ptima del producto. 4. Existen diversos modelos dentro del proceso del software, as mismo, existen diversas metodologas y tipos de modelos para desarrollar un software. Producto de ello cada metodologa tendr un modelo de proceso para su desarrollo, el cual se adecua respecto con las necesidades de un proyecto. 5. Las mejores prcticas para un desarrollo de software se encontraran ligadas hacia la finalidad del proyecto que requiera de dicho producto. 6. En sntesis, se puede derivar por lo anteriormente argumentado, que no existe un modelo estndar que se adecue ante la diversidad de finalidades que en la actualidad se exige. 7. La metodologa RUP, cuya caracterstica principal es la de ser iterativa e incremental consta de varias fases; cada fase es una iteracin comprendida. Todas las actividades realizadas en estas etapas tienen una complejidad enorme que al pasar del tiempo, el desarrollo del software tendr un final ptimo. 8. En conclusin, esta metodologa se adapta mejor para proyectos grandes, ya que para cada iteracin en la elaboracin de software depender de la economa que est a nuestro alcance. Es por ello que al final del producto se logran grandes resultados. De lo contrario, con ausencia de economa, el tiempo de vida del software no durar y terminar siendo un total fracaso. REFERENCIAS BIBLIOGRFICAS

-BECK, Kent y ANDRES, Cynthia. Extreme Programming Explained: Embrace Change. 2a. ed. EE.UU: Paperback, 2004. 224 p. ISBN: 0321278658 -BOEHM, Barry y TURNER, Richard. Metodologa RUP. En su: Balancing agility and discipline: a guide for the perplexed. Boston: Pearson Education, 2004. pp 179-180. ISBN: 0321186125 -BORRERO, Luca. Tecnologas de la informacin en internet: gua de las mejores direcciones en la web. Colombia, norma: 2004. 19 p. ISBN: 9580471975 -CAMPDERRICH Falgueras, Benet. Ingeniera de software. Madrid: UOC, 2005. 260 p. ISBN: 8483189976 -CERRADA, Jos, COLLADO, Manuel, GMEZ, Sebastian y ESTVIARIS Lpez, Jos Flix. Fundamentos de programacin. Madrid: Centro de estudios Ramn Areces, 2004. 466p. ISBN: 8480045152 -CORTS Morales, Roberto. Introduccin al anlisis de sistemas y la ingeniera de software. 2006. 102 p. ISBN: 9977649618 -GMEZ, Andrs y ANIA Briseo, Ignacio de Jess. Introduccin a la computacin. Mxico: Coordinadores editoriales, 2008. 552 p. ISBN: 139789706867681 -MINGUET y Hernndez, Juan Francisco. La calidad del software y su medida. Madrid: Centro de estudios Ramn Cceres, 2004. 42 p. ISBN: 8480046112 -ROGER, Pressman. Ingeniera del software: un enfoque prctico 6a ed. Madrid: Concepcin Fernndez, 2004. 640 p. ISBN: 8448132149 -SOMERVILLE, Ian. Ingeniera del software 7a ed. Madrid: Rivera de Loira, 2005. 165 p. ISBN: 8478290745 -TUYA, Javier, RAMOS, Isabel y DOLADO Cosn Javier. Tcnicas cuantitativas para la

gestin en la ingeniera del software. Madrid: Mara Martnez, 2007. 367 p. ISBN: 9788497452045 -WEITZENFELD, Alfredo. Ingeniera de software orientada a objetos con UML, Java e Internet. 1ra ed. Mxico, Publimex: 2005. 704 p. ISBN: 9706861904