Monografias.com > Uncategorized
Descargar Imprimir Comentar Ver trabajos relacionados

Metodologías de desarrollo de software. ¿Cuál es el camino? (página 2)



Partes: 1, 2

Beneficios que aporta RUP

  • Permite desarrollar aplicaciones sacando el máximo
    provecho de las nuevas
    tecnologías, mejorando la calidad, le
    rendimiento, la reutilización, la seguridad y
    el mantenimiento del software
    mediante una gestión sistemática de los
    riesgos.
    [ANO05, 1].
  • Permite la producción de software que cumpla con las
    necesidades de los usuarios, a través de la
    especificación de los requisitos, con una agenda y
    costo
    predecible. [ANO05,1].
  • Enriquece la productividad
    en equipo y proporciona prácticas óptimas de
    software a todos sus miembros. [ANO05, 2].
  • Permite llevar a cabo el proceso de
    desarrollo
    práctico, brindando amplias guías, plantillas y
    ejemplos para todas las actividades críticas. [ANO05,
    2].
  • Proporciona guías explicitas para áreas tales
    como modelado de negocios,
    arquitectura
    Web, pruebas y
    calidad. También se proporciona guías 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 características de los
    productos
    Rational, el Lenguaje
    de Modelado Unificado (UML) y otras
    prácticas óptimas de la industria.
    [ANO05, 2].
  • Unifica todo el equipo de desarrollo de software y mejora
    la
    comunicación al brindar a cada miembro del mismo una
    base de conocimientos, un lenguaje de
    modelado y un punto de vista de cómo 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 líderes de la industria.
  • No solo garantiza que los proyectos abordados serán
    ejecutados íntegramente sino que además evita
    desviaciones importantes respecto a los plazos. [ANO05,
    3].
  • Permite una definición acertada del sistema en un
    inicio para hacer innecesarias las reconstrucciones parciales
    posteriores. [ANO05, 3].

Metodologías ágiles.

XP

La Programación Extrema surge ideada por Kent
Beck, como proceso de creación de software diferente al
convencional. En palabras de Beck: "XP es una metodología ligera, eficiente, con bajo
riesgo,
flexible, predecible y divertida para desarrollar software".

Objetivos de XP:

Los objetivos de
XP son muy simples: la satisfacción del cliente.
Esta metodología trata de dar al cliente el
software que él necesita y cuando lo necesita. Por tanto,
debemos responder muy rápido a las necesidades del
cliente, incluso cuando los cambios sean al final de ciclo de la
programación.

El segundo objetivo es
potenciar al máximo el trabajo en
grupo
. Tanto los jefes de proyecto, los
clientes y
desarrolladores, son parte del equipo y están involucrados
en el desarrollo del software.

Bases de XP

La programación extrema se basa en la simplicidad, la
comunicación y el reciclado continuo de
código,
para algunos no es más que aplicar una pura lógica.
Lo que buscan en definitiva es la reducción 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, cambiarán los requisitos, las reglas de negocio,
el personal, la
tecnología, 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:

  • Comunicación
  • Sencillez
  • Retroalimentación
  • Valentía

Variables XP

XP define cuatro variables para
proyectos de software:

  • Coste
  • Tiempo
  • Calidad
  • Ámbito.

Actividades básicas 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 código fuente no hay programa, aunque
hay gente que cuenta que existe software en producción del
que se perdió el código fuente. Por tanto
necesitamos codificar y plasmar nuestras ideas a través
del código. En una programación en XP en pareja el
código expresa tu interpretación del problema, así
podemos utilizar el código para comunicar, para hacer
mías tus ideas, y por tanto para aprender y mejorar.

Hacer pruebas

Las características 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 había 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 código, con el tiempo
llegarás a conclusiones sobre las pruebas y podrás
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 más rápido que sólo
programar. Puedes ganar media hora de productividad sin hacer
pruebas, pero perderás mucho tiempo en la
depuración. Tendrás menos errores, tendrás
que volver menos veces sobre el código, te costará
menos localizar los errores, perderás 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 querrían ?.

Si vamos a hacer pruebas tenemos que preguntar si lo obtenido
es lo deseado, y tenemos que preguntar a quien necesita la
información. Tenemos que escuchar a
nuestros clientes cuales son los problemas de
su negocio, debemos de tener una escucha activa explicando lo que
es fácil y difícil de obtener, y la
realimentación entre ambos nos ayudan a todos a entender
los problemas.

Diseñar

El diseño
crea una estructura que
organiza la lógica del sistema, un buen diseño
permite que el sistema crezca con cambios en un solo lugar. Los
diseños deben de ser sencillos, si alguna parte del
sistema es de desarrollo complejo, divídela en varias. Si
hay fallos en el diseño o malos diseños, estos
deben de ser corregidos cuanto antes.

Tenemos que codificar porque sin código 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
diseñar para poder
codificar, probar y escuchar indefinidamente.

Prácticas Básicas de XP

El juego de la
planificación.

Hay una comunicación frecuente el cliente y los
programadores. El equipo técnico realiza una
estimación del esfuerzo requerido para la
implementación de las historias de usuario y los clientes
deciden sobre el ámbito y tiempo de las entregas y de cada
iteración.

Pequeñas versiones.

Cada versión debe de ser tan pequeña como fuera
posible, conteniendo los requisitos de negocios más
importantes, las versiones tiene que tener sentido como un todo,
me explico no puedes implementar media característica y
lanzar la versión.

Es mucho mejor planificar para 1 mes o 2 que para seis meses y
un año, las compañías que entregan software
muy voluminoso no son capaces de hacerlo con mucha
frecuencia.

Metáfora.

Una metáfora es una historia que todo el mundo
puede contar a cerca de cómo funciona el sistema. Algunas
veces podremos encontrar metáforas sencillas "Programa de
gestión de compras, ventas, con
gestión de cartera y almacén".
Las metáforas ayudan a cualquier persona a
entender el objeto del programa.

Diseño sencillo.

El diseño adecuado par el software es aquel que:

1. Funciona con todas las pruebas.

2. No tiene lógica duplicada.

3. Manifiesta cada intención importante para los
programadores

4. Tiene el menor número de clases y métodos.

Haz el diseño lo más 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, diseña para
mañana", no es del todo correcto si piensas que el futuro
es incierto.

Hacer pruebas.

No debe existir ninguna característica 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.

Recodificación.

Cuando implementamos nuevas características en nuestros
programas nos planteamos la manera de hacerlo lo mas simple
posible, después de implementar esta
característica, 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 características. No
debemos de recodificar ante especulaciones si no solo
cuándo el sistema te lo pida.

Programación por parejas.

Todo el código de producción lo escriben dos
personas frente al ordenador, con un sólo ratón y
un sólo teclado. Cada
miembro de la pareja juega su papel: uno codifica en el ordenador
y piensa la mejor manera de hacerlo, el otro piensa más
estratégicamente, ¿Va a funcionar?, ¿Puede
haber pruebas donde no funcione?, ¿Hay forma de
simplificar el sistema global para que el problema
desaparezca?

El emparejamiento es dinámico, puedo estar emparejado
por la mañana 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
código en cualquier parcela puede hacerlo, ningún
miembro del equipo es propietario del código. Si alguien
quiere hacer cambios en el código puede hacerlo. Si
hacemos el código propietario, y necesitamos de su autor
para que lo cambie entonces estaremos alejándonos cada vez
mas de la comprensión del problema, si necesitamos un
cambio sobre una parte del código lo hacemos y punto. XP
propone un propiedad
colectiva sobre el código nadie conoce cada parte igual de
bien pero todos conoce algo sobre cada parte, esto nos
preparará para la sustitución no traumática
de cada miembro del equipo.

Integración continúa.

El código se debe integrar como mínimo una vez
al día, y realizar las pruebas sobre la totalidad del
sistema. Una pareja de programadores se encargara de integrar
todo el código en una maquina y realizar todas las pruebas
hasta que estas funcionen al 100%.

40 Horas semanales.

Si queremos estar frescos y motivados cada mañana y
cansado y satisfecho cada noche. El viernes quiero estar cansado
y satisfecho para sentir que tengo dos días para pensar en
algo distinto y volver el lunes lleno de pasión e ideas.
Esto requiere que trabajemos 40 horas a la semana, mucha gente no
puede estar más 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 síntoma 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 difícil 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.

Estándares de codificación.

Si los programadores van a estar tocando partes distintas del
sistema, intercambiando compañeros, haciendo refactoring,
debemos de establecer un estándar de codificación
aceptado e implantado por todo el equipo.

Características esenciales de XP

  • Roles.
  • Programador: Produce el código del
    sistema.
  • Cliente: Escribe las HU y las pruebas
    funcionales para validar su implementación, así
    como asigna la prioridad de la HU y decide cuál se
    implementara en cada iteración.
  • Encargado de pruebas: Ayuda al cliente a
    escribir las pruebas funcionales, ejecuta las pruebas y difunde
    resultados además es responsable de las herramientas de
    soporte para prueba.
  • Rastreador (Tracker):también conocido como
    "Metric Man", observa sin molestar y mantiene los datos
    históricos.
  • Consultor: Es un miembro externo del equipo con
    conocimiento
    especifico de algún tema necesario para el proyecto.
    Guía al equipo para resolver un problema
    específico.
  • Gestor (Big Boss): Es el vínculo entre
    clientes y programadores, ayuda a que el equipo trabaje
    efectivamente creando las condiciones adecuadas. Su labor
    esencial es de coordinación.
  • Artefactos esenciales.
  • Historias de Usuario.
  • Tareas de Ingeniería.
  • Pruebas de Aceptación.
  • Procesos.
  • Ciclo de desarrollo.
  • Ciclo de vida(Fases)
    1. Exploración
    2. Planificación.
    3. Iteraciones.
    4. Producción.
    5. Mantenimiento.
    6. Muerte Proyecto.
    • Prácticas.

    3P [ECH08].

    Paradigma 3P es una metodología de desarrollo
    de software nacida al calor de
    la experiencia acumulada del grupo de
    investigación y desarrollo Atis debido
    a la insuficiente capacidad de respuesta a los clientes
    utilizando las metodologías tradicionales.

    Principios que sustentan el
    modelo

    1. Los individuos y sus interacciones son más
      importantes que los procesos
      y las herramientas: El PERSONAL.
    2. La comunicación con el cliente evita
      construir una elegante solución para un problema
      equivocado: El PROBLEMA.
    3. El software que funciona es más importante
      que la documentación exhaustiva. El
      PROCESO.

    Valores 3P

    1. Comunicación: Sin comunicación todo
      proyecto estaría 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
      demás 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. Retroalimentación: Saber cuándo 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 más complejas, encararla con
      esmero y con alegría hará que crezca nuestro
      prestigio entre los demás miembros, la
      convicción y el deseo del triunfo debe
      prevalecer.
    5. Optimismo: Ser realista pero tener siempre el
      pensamiento orientado hacia el éxito.

    Actividades básicas

    1. Codificar.
    2. Probar.
    3. Comunicar
    4. Idear
    5. Escuchar.
    6. Diseñar.

    Roles del proyecto

    1. Jefe del Proyecto
    2. Cliente
    3. Consultor
    4. Analista-Programador
    5. Programador
    6. Diseñador de Interfaces

    Principios que sustentan la
    metodología

    1. EL Personal: Gestión de
      Proyecto
    2. El Problema: Gestión del
      Cliente
    3. El Proceso: Ciclo de Vida de
      Desarrollo

    Ciclo de vida de desarrollo

    1. Definición del problema.
    2. Identificación de los procesos
      unitarios.
    3. Diseño del prototipo.
    4. Desarrollo del prototipo.
    5. Prueba del prototipo.
    6. Si <no prueba de Prototipo>ir a Paso
      3.
    7. Si <Prototipo difiere Sistema Deseado>ir a
      Paso 2.
    8. Si <no Necesidades satisfechas>ir a Paso
      2.
    9. Implantación.
    10. 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 documentación

    3P

    • Ágil
    • Cercano al desarrollo, pero sin olvidar el
      diseño.
    • Se basa en 3 principios:
      Personal, Problema, Proceso.
    • Gran interacción con el
      cliente.
    • Pruebas de funcionalidad y calidad.
    • Logra alcanzar un control
      y organización del proceso.
    • Logra un equilibrio en cuanto a la generación
      de documentación

    XP

    • Ligero
    • Cercano al desarrollo
    • Se basa en UserStories
    • Fuerte comunicación con el
      cliente
    • El código fuente pertenece a
      todos
    • Programación por parejas
    • Tests como base de la funcionalidad
    • Solo el mínimo de
      organización
    • Pobre en cuanto a
      documentación

    3.
    Conclusiones

    ¿Qué debemos esperar entonces de un
    proceso de desarrollo?

    ¿Qué criterios debe cumplir para que
    aporte algo a la
    empresa?

    Básicamente 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 ningún proceso
    estándar, y como dice el refrán (aunque no se
    cumple exactamente en el mundo de la informática) 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]. Anónimo. Seminario sobre RUP
      en un entorno empresarial de desarrollo
      .

      http://www-5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES
      .
      (2/5/08)
    • [ANO08,2]. Anónimo. Rational Unified
      Process
      . .
      (2/5/08)
    • [ANO05,3]. Anónimo. Proceso Unificado
      de Rational para el desarrollo de software
      .
      http://www.dybox.cl/metodologia/rup.html.
      (2/5/08)
    • [BAR08]. Barrientos Enríquez, Aleida
      Mirian. El desarrollo de sistemas de
      información empleando el lenguaje de modelado
      unificado UML.
    • [JAC08]. Jacobson, Ivar; Booch, Grady; Rumbaugh,
      James. El Proceso Unificado de Desarrollo de
      Software.
    • [ECH08]. Echevarría Cossío,
      Yanelis. Modelo Ágil de Desarrollo de Proyectos
      de Software:Paradigma 3P.

    Bibliografía

     

     

    Autor:

    Erly Delgado Expósito

Partes: 1, 2
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión 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 disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter