22/4/2014

Metodologas de desarrollo de software. Cul es el camino? (pgina 2) - Monografias.com

Agregar a favoritos Ayuda Portugus Ingles Regstrese! | Iniciar sesin

Desarrollo de software
agillabs.cl Metodologas giles Descuentos para socios ASECH
Busqueda avanzada

Monografas

Nuevas

Publicar

Blogs

Foros
Descargar Volver al principio del trabajo Imprimir Comentar

Buscar
Ver trabajos relacionados Pgina siguiente

Monografias.com > Computacion > Programacion Pgina anterior

Metodologas de desarrollo de software. Cul es el camino? (pgina 2)

Enviado por Erly Delgado Expsito
Tw ittear 1 Me gusta 1

PNL - Diplomado Online

scpnl.cl Escuela de PNL ms prestigiosa en mundo de habla hispana ahora Online

Partes: 1, 2

Beneficios que aporta RUP Permite desarrollar aplicaciones sacando el mximo provecho de las nuevas tecnologas, mejorando la calidad, le rendimiento, la reutilizacin, la seguridad y el mantenimiento del software mediante una gestin sistemtica de los riesgos. [ANO05, 1]. Permite la produccin de software que cumpla con las necesidades de los usuarios, a travs de la especificacin de los requisitos, con una agenda y costo predecible. [ANO05,1]. Enriquece la productividad en equipo y proporciona prcticas ptimas de software a todos sus miembros. [ANO05, 2]. Permite llevar a cabo el proceso de desarrollo prctico, brindando amplias guas, plantillas y ejemplos para todas las actividades crticas. [ANO05, 2]. Proporciona guas explicitas para reas tales como modelado de negocios, arquitectura Web, pruebas y calidad. Tambin se proporciona guas para desarrollar en plataformas IBM WebSphere y Microsoft Web Solution para acelerar el desarrollo de los proyectos. [ANO05, 2]. Se integra estrechamente con herramientas Rational, permitiendo a los equipos de desarrollo aprovechar todas las ventajas de las caractersticas de los productos Rational, el Lenguaje de Modelado Unificado (UML) y otras prcticas ptimas de la industria. [ANO05, 2]. Unifica todo el equipo de desarrollo de software y mejora la comunicacin al brindar a cada miembro del mismo una base de conocimientos, un lenguaje de modelado y un punto de vista de cmo desarrollar software. [ANO05, 2]. Optimiza la productividad de cada miembro del equipo al poner al alcance la experiencia derivada de miles de proyectos y muchos lderes de la industria. No solo garantiza que los proyectos abordados sern ejecutados ntegramente sino que adems evita desviaciones importantes respecto a los plazos. [ANO05, 3]. Permite una definicin acertada del sistema en un inicio para hacer innecesarias las reconstrucciones parciales posteriores. [ANO05, 3]. Metodologas giles. XP La Programacin Extrema surge ideada por Kent Beck, como proceso de creacin de software diferente al convencional. En palabras de Beck: "XP es una metodologa ligera, eficiente, con bajo riesgo, flexible, predecible y divertida para desarrollar software". Objetivos de XP: Los objetivos de XP son muy simples: la satisfaccin del cliente. Esta metodologa trata de dar al cliente el software que l necesita y cuando lo necesita. Por tanto, debemos responder muy rpido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programacin. El segundo objetivo es potenciar al mximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estn involucrados en el desarrollo del software. Bases de XP La programacin extrema se basa en la simplicidad, la comunicacin y el reciclado continuo de cdigo, para algunos no es ms que aplicar una pura lgica. Lo que buscan en definitiva es la reduccin de costes. Valores XP Una de las cosas que a los programadores nos tiene que quedar muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarn los requisitos, las reglas de negocio, el personal, la tecnologa, todo va a cambiar. Por tanto el problema no es el cambio en si, ya que este va a suceder sino la incapacidad de enfrentarnos a estos cambios. Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos iniciales. Estos cuatro valores son: Comunicacin Sencillez Retroalimentacin Valenta

http://www.monografias.com/trabajos60/metodologias-desarrollo-software/metodologias-desarrollo-software2.shtml

1/5

22/4/2014
Variables XP

Metodologas de desarrollo de software. Cul es el camino? (pgina 2) - Monografias.com

XP define cuatro variables para proyectos de software: Coste Tiempo Calidad mbito. Actividades bsicas XP Ahora que tenemos nuestros cuatro valores estamos preparados para construir una disciplina de desarrollo de software. Qu tareas debemos de llevar a cabo para desarrollar un buen software? Codificar Es la nica actividad de la que no podremos prescindir. Sin cdigo fuente no hay programa, aunque hay gente que cuenta que existe software en produccin del que se perdi el cdigo fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a travs del cdigo. En una programacin en XP en pareja el cdigo expresa tu interpretacin del problema, as podemos utilizar el cdigo para comunicar, para hacer mas tus ideas, y por tanto para aprender y mejorar. Hacer pruebas Las caractersticas del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que implement es lo que en realidad yo pensaba que haba implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo. No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro cdigo, con el tiempo llegars a conclusiones sobre las pruebas y podrs pensar que si dos de tus pruebas ya funcionan la tercera prueba no ser necesaria escribirla, sin caer en demasiada confianza. Programar y probar es ms rpido que slo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perders mucho tiempo en la depuracin. Tendrs menos errores, tendrs que volver menos veces sobre el cdigo, te costar menos localizar los errores, perders menos tiempo escuchado como tus clientes te dicen que no funciona. Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por all y volveremos a caer dentro. Escuchar Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software para que nos querran ?. Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la informacin. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fcil y difcil de obtener, y la realimentacin entre ambos nos ayudan a todos a entender los problemas. Disear El diseo crea una estructura que organiza la lgica del sistema, un buen diseo permite que el sistema crezca con cambios en un solo lugar. Los diseos deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divdela en varias. Si hay fallos en el diseo o malos diseos, estos deben de ser corregidos cuanto antes. Tenemos que codificar porque sin cdigo no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que disear para poder codificar, probar y escuchar indefinidamente. Prcticas Bsicas de XP El juego de la planificacin. Hay una comunicacin frecuente el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Pequeas versiones. Cada versin debe de ser tan pequea como fuera posible, conteniendo los requisitos de negocios ms importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media caracterstica y lanzar la versin. Es mucho mejor planificar para 1 mes o 2 que para seis meses y un ao, las compaas que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia. Metfora. Una metfora es una historia que todo el mundo puede contar a cerca de cmo funciona el sistema. Algunas veces podremos encontrar metforas sencillas "Programa de gestin de compras, ventas, con gestin de cartera y almacn". Las metforas ayudan a cualquier persona a entender el objeto del programa. Diseo sencillo. El diseo adecuado par el software es aquel que: 1. Funciona con todas las pruebas. 2. No tiene lgica duplicada. 3. Manifiesta cada intencin importante para los programadores 4. Tiene el menor nmero de clases y mtodos. Haz el diseo lo ms simple posible borra todo lo que puedas sin violar las reglas 1,2 y 3. Contrariamente a lo que se pensaba el "Implementa para hoy, disea para maana", no es del todo correcto si piensas que el futuro es incierto. Hacer pruebas. No debe existir ninguna caracterstica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.

http://www.monografias.com/trabajos60/metodologias-desarrollo-software/metodologias-desarrollo-software2.shtml

2/5

22/4/2014

Metodologas de desarrollo de software. Cul es el camino? (pgina 2) - Monografias.com

Recodificacin. Cuando implementamos nuevas caractersticas en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, despus de implementar esta caracterstica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas caractersticas. No debemos de recodificar ante especulaciones si no solo cundo el sistema te lo pida. Programacin por parejas. Todo el cdigo de produccin lo escriben dos personas frente al ordenador, con un slo ratn y un slo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa ms estratgicamente, Va a funcionar?, Puede haber pruebas donde no funcione?, Hay forma de simplificar el sistema global para que el problema desaparezca? El emparejamiento es dinmico, puedo estar emparejado por la maana con una persona y por la tarde con otra, si tienes un trabajo sobre un rea que no conoces muy bien puedes emparejarte con otra persona que si conozca ese rea. Cualquier miembro del equipo se puede emparejar con cualquiera. Propiedad colectiva. Cualquiera que crea que puede aportar valor al cdigo en cualquier parcela puede hacerlo, ningn miembro del equipo es propietario del cdigo. Si alguien quiere hacer cambios en el cdigo puede hacerlo. Si hacemos el cdigo propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejndonos cada vez mas de la comprensin del problema, si necesitamos un cambio sobre una parte del cdigo lo hacemos y punto. XP propone un propiedad colectiva sobre el cdigo nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparar para la sustitucin no traumtica de cada miembro del equipo. Integracin contina. El cdigo se debe integrar como mnimo una vez al da, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el cdigo en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%. 40 Horas semanales. Si queremos estar frescos y motivados cada maana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos das para pensar en algo distinto y volver el lunes lleno de pasin e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar ms de 35 horas concentrados a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son sntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras. Cliente In-situ. Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difcil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que ser mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo. Estndares de codificacin. Si los programadores van a estar tocando partes distintas del sistema, intercambiando compaeros, haciendo refactoring, debemos de establecer un estndar de codificacin aceptado e implantado por todo el equipo. Caractersticas esenciales de XP Roles. Programador: Produce el cdigo del sistema. Cliente: Escribe las HU y las pruebas funcionales para validar su implementacin, as como asigna la prioridad de la HU y decide cul se implementara en cada iteracin. Encargado de pruebas: Ayuda al cliente a escribir las pruebas funcionales, ejecuta las pruebas y difunde resultados adems es responsable de las herramientas de soporte para prueba. Rastreador (T racker):tambin conocido como "Metric Man", observa sin molestar y mantiene los datos histricos. Consultor: Es un miembro externo del equipo con conocimiento especifico de algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico. Gestor (Big Boss): Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. Artefactos esenciales. Historias de Usuario. T areas de Ingeniera. Pruebas de Aceptacin. Procesos. Ciclo de desarrollo. Ciclo de vida(Fases) 2. 3. 4. 5. 6. 7. Exploracin Planificacin. Iteraciones. Produccin. Mantenimiento. Muerte Proyecto. Prcticas. 3P [ECH08]. Paradigma 3P es una metodologa de desarrollo de software nacida al calor de la experiencia acumulada del grupo de investigacin y desarrollo Atis debido a la insuficiente capacidad de respuesta a los clientes utilizando las metodologas tradicionales. Principios que sustentan el modelo 1. Los individuos y sus interacciones son ms importantes que los procesos y las herramientas: El PERSONAL. 2. La comunicacin con el cliente evita construir una elegante solucin para un problema equivocado: El PROBLEMA. 3. El software que funciona es ms importante que la documentacin exhaustiva. El PROCESO.

http://www.monografias.com/trabajos60/metodologias-desarrollo-software/metodologias-desarrollo-software2.shtml

3/5

22/4/2014

Metodologas de desarrollo de software. Cul es el camino? (pgina 2) - Monografias.com

Valores 3P 1. Comunicacin: Sin comunicacin todo proyecto estara destinado a fracasar , comunicar no es escribir o hablar muchas palabras sino utilizar solo las palabras necesarias para trasmitir una idea. 2. Sencillez: Nadie es mejor o peor que los dems miembros del grupo de desarrollo , todos tenemos fortalezas y debilidades, conocerlas har que nuestras relaciones con los miembros del grupo sean mejores en el orden profesional y personal. 3. Retroalimentacin: Saber cundo se debe rehacer algo que no funciona, equivocarse es de humanos, encarar nuevamente la tarea con emprendimiento y optimismo. 4. Emprendimiento: estar dispuesto siempre a acometer las tareas ms complejas, encararla con esmero y con alegra har que crezca nuestro prestigio entre los dems miembros, la conviccin y el deseo del triunfo debe prevalecer. 5. Optimismo: Ser realista pero tener siempre el pensamiento orientado hacia el xito. Actividades bsicas 1. 2. 3. 4. 5. 6. Codificar. Probar. Comunicar Idear Escuchar. Disear.

Roles del proyecto 2. 3. 4. 5. 6. 7. Jefe del Proyecto Cliente Consultor Analista-Programador Programador Diseador de Interfaces

Principios que sustentan la metodologa 1. EL Personal: Gestin de Proyecto 2. El Problema: Gestin del Cliente 3. El Proceso: Ciclo de Vida de Desarrollo Ciclo de vida de desarrollo 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Definicin del problema. Identificacin de los procesos unitarios. Diseo del prototipo. Desarrollo del prototipo. Prueba del prototipo. Si <no prueba de Prototipo>ir a Paso 3. Si <Prototipo difiere Sistema Deseado>ir a Paso 2. Si <no Necesidades satisfechas>ir a Paso 2. Implantacin. Mantenimiento.

Resumen puntos clave RUP Pesado Dividido en cuatro fases, que se dividen en iteraciones El discurrir del proyecto se define en Workflows Los artefactos son el objetivo de cada actividad Se basa en roles UML Muy organizativo Mucha documentacin 3P gil Cercano al desarrollo, pero sin olvidar el diseo. Se basa en 3 principios: Personal, Problema, Proceso. Gran interaccin con el cliente. Pruebas de funcionalidad y calidad. Logra alcanzar un control y organizacin del proceso. Logra un equilibrio en cuanto a la generacin de documentacin XP Ligero Cercano al desarrollo Se basa en UserStories Fuerte comunicacin con el cliente El cdigo fuente pertenece a todos Programacin por parejas Tests como base de la funcionalidad Solo el mnimo de organizacin Pobre en cuanto a documentacin

3. Conclusiones
Qu debemos esperar entonces de un proceso de desarrollo?

http://www.monografias.com/trabajos60/metodologias-desarrollo-software/metodologias-desarrollo-software2.shtml

4/5

22/4/2014

Metodologas de desarrollo de software. Cul es el camino? (pgina 2) - Monografias.com

Qu criterios debe cumplir para que aporte algo a la empresa? Bsicamente el proceso de desarrollo tiene que ayudarnos a escribir software, tiene que poner las reglas necesarias para alcanzar el xito en nuestro proyecto pero dejando la libertad suficiente para no sentirnos agobiados. Esto no nos lo va a ofrecer ningn proceso estndar, y como dice el refrn (aunque no se cumple exactamente en el mundo de la informtica) todos los caminos conducen a Roma. De forma que es tarea de cada empresa, casi para cada proyecto, decidir cual es el mejor modo de llegar a nuestra meta.

Referencias
[ANO08,1]. Annimo. Seminario sobre RUP en un entorno empresarial de desarrollo . http://www5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES. (2/5/08) [ANO08,2]. Annimo . Rational Unified Process. . (2/5/08) [ANO05,3]. Annimo. Proceso Unificado de Rational para el desarrollo de software. http://www.dybox.cl/metodologia/rup.html. (2/5/08) [BAR08]. Barrientos Enrquez, Aleida Mirian. El desarrollo de sistemas de informacin empleando el lenguaje de modelado unificado UML. [JAC08]. Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado de Desarrollo de Software. [ECH08]. Echevarra Cosso, Yanelis. Modelo gil de Desarrollo de Proyectos de Software:Paradigma 3P.

Bibliografa
Alianza gil, http://www.agilealliance.org Patricio Letelier, Departamento de Sistemas Informticos y Computacin, Universidad Politcnica de Valencia, letelier[arroba]dsic.upv.es Manifiesto para el Desarrollo de Software gil, http://www.agilemanifesto.org Martn Fowler, La Nueva Metodologa, http://www.programacion.net Alistair, Desarrollo de Software gil, http://www.amazon.com/exec/obidos/ASIN/0201699699/programacione-20 Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado de Desarrollo de Software. Echevarra Cosso, Yanelis. Modelo gil de Desarrollo de Proyectos de Software:Paradigma 3P. Annimo. Proceso Unificado de Rational para el desarrollo de software. http://www.dybox.cl/metodologia/rup.html. (2/5/05) Annimo. Rational Unified Process. http://www.itera.com.mx/itera/productos/fundamentos.asp. (2/5/05) Annimo. Seminario sobre RUP en un entorno empresarial de desarrollo . http://www5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES. (2/5/05) Barrientos Enrquez, Aleida Mirian. El desarrollo de sistemas de informacin empleando el lenguaje de modelado unificado UML.

Autor: Erly Delgado Expsito Partes: 1, 2

Pgina anterior

Volver al principio del trabajo

Pgina siguiente

Comentarios
Para dejar un comentario, regstrese gratis o si ya est registrado, inicie sesin.

Trabajos relacionados
Estudio sobre los lenguajes de programacin para la robtica
Origen de la palabra robot y su significado. Propiedades caractersticas de los robots. El robot y su funcionamiento. Cl... Estructura de un objeto. Encapsulamiento y ocultacin. Organizacin de los objetos. Actualmente una de las reas ms ca...

Sistemas de Procesamiento de Datos Programacin Orientada a Objetos Rupturas de InformeDefinicin de una Ruptura de Informe.
Especificacin de Opciones de Proceso. Una Ruptura de Informe se usa para dividir... Ver mas trabajos de Programacion
Nota al lector: es posible que esta pgina no contenga todos los componentes del trabajo original (pies de pgina, avanzadas formulas matemticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versin original completa, puede descargarlo desde el men superior. Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposicin de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta informacin. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de informacin.

El Centro de Tesis, Documentos, Publicaciones y Recursos Educativos ms amplio de la Red. Trminos y Condiciones | Haga publicidad en Monografas.com | Contctenos | Blog Institucional Monografias.com S.A.

http://www.monografias.com/trabajos60/metodologias-desarrollo-software/metodologias-desarrollo-software2.shtml

5/5