SEGUIDAMENTE DETALLAREMOS LAS SIGUIENTES METODOLOGÍAS PARA DESARROLLO
DE
·
Rational
Unified Process (RUP)
·
Extreme
Programming (XP)
·
SCRUM
Consiste en un ciclo de
desarrollo corto basado en 3 fases (diseño-requisitos-construcción) con un
plazo de entrega ideal de 90 a 120 días como máximo.
Metodología Scrum
Scrum
es una metodología ágil y flexible para gestionar el desarrollo de software,
cuyo principal objetivo es maximizar el retorno de la inversión para su empresa
(ROI). Se basa en construir primero la funcionalidad de mayor valor para el
cliente y en los principios de inspección continua, adaptación, auto-gestión e
innovación.
Con
la metodología Scrum el cliente se entusiasma y se compromete con el proyecto
dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier
momento realinear el software con los objetivos de negocio de su empresa, ya
que puede introducir cambios funcionales o de prioridad en el inicio de cada
nueva iteración sin ningún problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del
equipo que forma parte del proyecto, por lo que los profesionales encuentran un
ámbito propicio para desarrollar sus capacidades.
Beneficios
·
Cumplimento
de expectativas: El
cliente establece sus expectativas indicando el valor que le aporta cada
requisito /historia del
proyecto, el equipo los estima y con esta información el Product Owner establece
su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba
que efectivamente los requisitos se han cumplido y transmite se feedback al
equipo.
·
Flexibilidad
a cambios: Alta
capacidad de reacción ante los cambios de requerimientos generados por
necesidades del cliente o evoluciones del mercado. La metodología está diseñada
para adaptarse a los cambios de requerimientos que conllevan los proyectos
complejos.
·
Reducción
del Time to Market: El cliente puede
empezar a utilizar las funcionalidades más importantes del proyecto antes de
que esté finalizado por completo.
·
Mayor
calidad del software: La metódica de
trabajo y la necesidad de obtener una versión funcional después de cada
iteración, ayuda a la obtención de un software de calidad superior.
·
Mayor
productividad: Se consigue
entre otras razones, gracias a la eliminación de la burocracia y a la
motivación del equipo que proporciona el hecho de que sean autónomos para
organizarse.
·
Maximiza
el retorno de la inversión (ROI): Producción de
software únicamente con las prestaciones que aportan mayor valor de negocio
gracias a la priorización por retorno de inversión.
·
Predicciones
de tiempos: Mediante
esta metodología se conoce la velocidad media del equipo por sprint (los
llamados puntos historia), con lo que consecuentemente, es posible estimar
fácilmente para cuando se dispondrá de una determinada funcionalidad que
todavía está en el Backlog.
·
Reducción
de riesgos: El
hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de
conocer la velocidad con que el equipo avanza en el proyecto, permite despejar
riesgos eficazmente de manera anticipada.
Ventajas y desventajas de SCRUM (I)
Si
estás considerando SCRUM como método de trabajo pero no sabes muy bien de qué
va todo esto. Has oído a un montón de gente hablándote de las bondades de este
sistema pero ¿cuántas tecnologías y técnicas no han aparecido rápidamente y
desaparecido a mayor velocidad aún? Todas prometían ser revolucionarias así que
cuando oímos tanto bombo sobre alguna arqueamos una ceja en actitud crítica.
Hace algunas semanas publiqué un prezi en el que explicaba las ventajas
y inconvenientes de implantar SCRUM en una organización.
Las comentaré ahora en esta entrada, esta vez con palabras en lugar de
imágenes, comenzando por sus inconvenientes (trataré de ser parcial, pero no lo
prometo)
El equipo
puede estar tentado de tomar el camino más corto
Cuando
cada dos semanas hay cosas que entregar, en las últimas entregas no se
completaron todas las funcionalidades previstas y la velocidad del equipo no
predice que vayamos a terminar en plazo tenemos un problema: puede surgir la
tentación de resolver las tareas pendientes de cualquier manera y dejar
'deudas' técnicas en el trabajo. Aparentemente todo va bien, más
funcionalidades hechas, empezamos otras nuevas y el cliente está contento
porque se están cumpliendo los plazos.
Pero siempre que se deja un borrón ahí atrás puedo asegurarte que volverás a
tropezar con él. Si nuevas cosas han sido construidas sobre este borrón, la
'deuda' comenzará a multiplicarse. Antes o después tendrás que parar todo y devolver
la deuda comprometida (con intereses de demora) El proyecto no termina de
cerrarse cuando parecía que ya quedaba poco por acabar: la gráfica burndown
parece tener una asíntota horizontal en 0 (lo siento, deformación
profesional/educacional, Cálculo I)
¿Necesitas
con mucha antelación fechas exactas de entrega?
Esta
es una de las críticas más habituales a SCRUM. En cierta forma es lógico, al
inicio del proyecto no puedes predecir cuando lo vas a acabar si estás
facilitando que lo que se va a construir cambie y varíe en el tiempo. ¿Se
prefiere un producto que se sabe con
certeza que va a finalizar en
10 meses pero que está construido sobre las ideas y opiniones que se tenían
cuando se comenzó? Quizás se prefiera un producto que podría acabar en el plazo
similar pero que hemos podido evolucionar hacia nuestras necesidades reales y
que hemos podido usar y probar antes de la entrega final.
¡Stress!
No
nos podemos pasar la vida esprintando. Hacemos una entrega y ya nos
comprometemos para la siguiente que está solo a un par de semanas vista. Luego
otra y otra. Si tenemos que recorrer muchos kilómetros así comenzaremos con un
rápido sprint para llegar a la primera meta pero llegaremos caminando a la
última, eso con suerte.
¿El
equipo es autoorganizado?
Una de los principios
de SCRUM es que el equipo debe tomar sus propias decisiones y autogestionarse.
Además, se requiere que no haya miembros especializados en tareas concretas
como análisis, tests, diseño, documentación, etc. sino que todos los integrantes
del equipo sepan hacer de todo y puedan intercambiarse entre sí. ¿Siempre
contamos con un equipo así? ¿Qué pasa si no lo tenemos?
Desde luego es un
problema pero ¿no lo sería también con cualquier otra forma de trabajo? ¿Hay
alguna que permita llevar proyectos a buen puerto con equipos con poca
experiencia?
En otra entrada hablaré
sobre las ventajas de SCRUM (seguro que no es tan popular)
Si te interesa saber más sobre la certificación Professional Scrum Master I,
estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de
forma ágil quizás te interese mi libro: Gestión
práctica de proyectos con Scrum.
METODOLOGÍA RUP.
Es una metodología cuyo fin es entregar un producto de software. Se estructura
todos los procesos y se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado
de modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
El RUP es un conjunto de metodologías adaptables al contexto y necesidades de
cada organización.
Describe como aplicar enfoques para el desarrollo del software, llevando a cabo
unos pasos para su realización.
Se centra en la producción y mantenimiento de modelos del sistema.
Principales
características
·
Forma
disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y
cómo)
·
Pretende
implementar las mejores prácticas en Ingeniería de Software
·
Desarrollo
iterativo
·
Administración
de requisitos
·
Uso
de arquitectura basada en componentes
·
Control
de cambios
·
Modelado
visual del software
·
Verificación
de la calidad del software
El
RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de uso.
Incluye artefactos (que son los productos tangibles del proceso como por
ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que
desempeña una persona en un determinado momento, una persona puede desempeñar
distintos roles a lo largo del proceso).
CICLO DE VIDA
Esfuerzo en actividades según fase del proyecto
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue
creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida
organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor
o menor hincapié en las distintas actividades.
Fases del ciclo de vida del RUP:
1. Fase
de Inicio: Esta fase
tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una
visión muy general de la arquitectura de software y producir el plan de las
fases y el de iteraciones posteriores.
2. Fase
de elaboración: En la
fase de elaboración se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificación de los casos de uso seleccionados y el primer análisis del
dominio del problema, se diseña la solución preliminar.
3. Fase
de Desarrollo: El
propósito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requerimientos pendientes, administrar los cambios de
acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
4. Fase
de Cierre: El propósito
de esta fase es asegurar que el software esté disponible para los usuarios
finales, ajustar los errores y defectos encontrados en las pruebas de
aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por
las personas involucradas en el proyecto.
La metodología RUP tiene 6 principios clave:
1. Adaptación
del proceso: El
proceso debe adaptarse a las características de la organización para la que se
está desarrollando el software.
2. Balancear
prioridades: Debe
encontrarse un balance que satisfaga a todos los inversores
del
proyecto.
3. Colaboración
entre equipos: Debe
haber una comunicación fluida para coordinar requerimientos, desarrollo,
evaluaciones, planes, resultados, entre otros.
4. Demostrar
valor iterativamente: Los
proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En
cada iteración se evaluará la calidad y estabilidad del producto y analizará la
opinión y sugerencias de los inversores.
5. Elevar
el nivel de abstracción: Motivar
el uso de de conceptos reutilizables.
6. Enfocarse
en la calidad: La
calidad del producto debe verificarse en cada aspecto de la producción.
Disciplina de desarrollo de RUP
Determina las etapas a realizar durante el proyecto de creación del software.
·
Ingeniería
o modelado del negocio: Analizar y
entender las necesidades del negocio para el cual se está desarrollando el
software.
·
Requisitos: Proveer una base
para estimar los costos y tiempo de desarrollo del sistema.
·
Análisis
y diseño: Trasladar los
requisitos analizados anteriormente a un sistema automatizado y desarrollar una
arquitectura para el sistema.
·
Implementación: Crear software
que se ajuste a la arquitectura diseñada y que tenga el comportamiento deseado.
·
Pruebas: Asegurarse de
que el comportamiento requerido es correcto y que todo lo solicitado está
presente.
·
Despliegue: Producir
distribuciones del producto y distribuirlo a los usuariosDisciplina de
soporte RUP
Determina la documentación que es necesaria realizar durante el proyecto.
·
Configuración
y administración del cambio: Guardar todas las versiones del
proyecto.
·
Administración
del proyecto:
Administrar los horarios y recursos que se deben de emplear.
·
Ambiente: Administrar el
ambiente de desarrollo del software.
·
Distribución: Hacer todo lo
necesario para la salida del proyecto..
¿Cuáles son las ventajas y desventajas?
Ventajas
·
Requiere
conocimientos del proceso y de UML.
·
Progreso
visible en las etapas tempranas.
·
El
uso de iteraciones (actividades).
·
Facilita
la reutilizacion del código teniendo en cuenta que se realizan
revisiones en las primeras iteraciones lo cual ademas permite que se aprecien
oportunidades de mejoras en el diseño.
Desventajas
·
Por
el grado de complejidad puede no resultar muy adecuado.
·
RUP es generalmente
mal aplicado en el estilo cascada.
Entregas pequeñas: colocan un
sistema sencillo en producción rápidamente que se actualiza de forma rápida y
constante permitiendo que el verdadero valor de negocio del producto sea
evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas
como máximo.
Entendimiento
1. Diseño
simple: se basa en la filosofía de que el mayor valor de negocio es
entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema
que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso
permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma
sencilla.
2. Metáfora:
desarrollada por los programadores al inicio del proyecto, define una historia
de cómo funciona el sistema completo. XP estimula historias, que son breves
descripciones de un trabajo de un sistema en lugar de los tradicionales
diagramas y modelos UML (Unified Modeling Language). La metáfora
expresa la visión evolutiva del proyecto que define el alcance y propósito del
sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también
ayudarán al equipo a definir actividades durante el diseño del sistema. Cada
tarjeta representa una clase en la programación orientada a objetos y define
sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras
clases (cómo se comunica con ellas).
3. Propiedad
colectiva del código: un código con propiedad compartida. Nadie es el
propietario de nada, todos son el propietario de todo. Este método difiere en
mucho a los métodos tradicionales en los que un simple programador posee un
conjunto de código. Los defensores de XP argumentan que mientras haya más gente
trabajando en una pieza, menos errores aparecerán.
4. Estándar
de codificación: define la propiedad del código compartido así como
las reglas para escribir y documentar el código y la comunicación entre
diferentes piezas de código desarrolladas por diferentes equipos. Los
programadores las han de seguir de tal manera que el código en el sistema se
vea como si hubiera estado escrito por una sola persona.
Bienestar del programador.
1. La
semana de 40 horas: la programación extrema sostiene que los
programadores cansados escriben código de menor cualidad. Minimizar las horas
extras y mantener los programadores frescos, generará código de mayor calidad.
Como dice Beck, está
bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante
dos semanas seguidas.
PROCESO DE DESARROLLO
La programación extrema parte del caso habitual de una compañía que desarrolla
software normalmente a medida, en la que hay diferentes roles: un equipo de
gestión (o diseño), uno de desarrollo y los clientes finales. La relación entre
el equipo de diseño, los que desarrollan el software y clientes es totalmente
diferente al que se ha producido en las metodologías tradicionales, que se
basaba en una fase de captura de los requisitos previa al desarrollo, y de una
fase de validación posterior al mismo.
1. Interacción con el
cliente.
En este tipo de programación el cliente pasa a ser parte implicada en el equipo
de desarrollo. Su importancia es máxima en el momento de tratar con los
usuarios y en efectuar las reuniones de planificación. Tiene un papel
importante de interacción con el equipo de programadores, sobre todo después de
cada cambio, y de cada posible problema localizado, mostrando las prioridades,
expresando sus sensaciones... En este tipo de programación existirán pruebas de
aceptación de la programación que ayudarán a que su labor sea lo más provechosa
posible.
Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo.
Se elimina la fase inicial de recopilación de requerimientos, y se permite que
éstos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De
esta forma se posibilita que el cliente pueda ir cambiando de opinión sobre la
marcha, pero a cambio han de estar siempre disponibles para solucionar las
dudas del equipo de desarrollo.
En XP aparece un nuevo concepto llamado “Historia de usuario”. Se
trata de una lista de características que el cliente necesita que existan en el
producto final. Estas constan de dos fases:
o En la primera fase, el cliente describe con sus propias palabras las
características y, es el responsable del equipo, el encargado de informarlo de
las dificultades técnicas de cada una de ellas y de su coste. A consecuencia de
este diálogo, el cliente deja por escrito un conjunto de historias y las ordena
en función de la prioridad que tienen pera él. De esta manera ya es posible
definir unas fechas aproximadas para ellos.
o En la segunda fase, el cliente cogerá las primeras historias a implementar y
las dividirá en trabajos a realizar. El cliente también participa, pero hay más
peso por parte del equipo de desarrolladores, esto dará como resultado una
planificación más exacta. Este método se repetirá para cada historia.
A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige
que sea el cliente el encargado de escribir los documentos con las
especificaciones de lo que realmente quiere, como un documento de requisitos de
usuario.
En esta fase, el equipo técnico será el 'encargado de catalogar las historias
del cliente y asignarles una duración. La norma es que cada historia de usuario
tiene que poder ser realizable en un espacio entre una y tres semanas de
programación. Las que requieran menos tiempo serán agrupadas, y las que
necesiten más serán modificadas o divididas.
Finalmente decir que las historias de los usuarios serán escritas en tarjetas,
lo que facilitará que el cliente pueda especificar la importancia relativa
entre las diferentes historias de usuario, así como el trabajo de los
programadores que podrán catalogarlas correctamente. Este formato también es
muy útil en el momento de las pruebas de aceptación.
PLANIFICACIÓN DEL PROYECTO
En este punto se tendrá que elaborar la planificación por etapas, donde se
aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de
reglas que se han de seguir por las partes implicadas en el proyecto para que
todas las partes tengan voz y se sientan realmente partícipes de la decisión tomada.
Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el
cliente ha de recibir una nueva versión. Cuanto más tiempo se tarde en
introducir una parte esencial, menos tiempo se tendrá para trabajar con ella
después. Se aconseja muchas entregas y muy frecuentes. De esta manera un error
en la parte inicial del sistema tiene más posibilidades de detectarse
rápidamente.
Una de las máximas a aplicar es, los cambios, no han de suponer más horas de
programación para el programador, ya que el que no se termina en un día, se
deja para el día siguiente.
Se ha de tener asumido que en el proceso de planificación habrán errores, es
más, serán comunes, y por esto esta metodología ya los tiene previstos, por lo
tanto se establecerán mecanismos de revisión. Cada tres o cinco iteraciones es
normal revisar las historias de los usuarios, y renegociar la planificación.
Cada iteración necesita también ser planificada, es lo que se llama planificación iterativa, en
la que se anotarán las historias de usuarios que se consideren esenciales y las
que no han pasado las pruebas de aceptación. Estas planificaciones también se
harán en tarjetas, en las que se escribirán los trabajos que durarán entre uno
y tres días.
Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al
proceso de desarrollo y evita que se mire demasiado hacia delante,
desarrollando trabajos que aún no han estado programados.
Este tipo de planificación en iteraciones y el diseño iterativo, hace que
aparezca una práctica que no existía en la programación tradicional. Se trata
de las discusiones diarias informales, para fomentar la comunicación, y para
hacer que los desarrolladores tengan tiempo de hablar de los problemas a los
que se enfrentan y de ver cómo van con sus trabajos.
DISEÑO, DESARROLLO Y PRUEBAS
El desarrollo es la parte más importante en el proceso de la programación
extrema. Todos los trabajos tienen como objetivo que se programen lo más
rápidamente posible, sin interrupciones y en dirección correcta.
También es muy importante el diseño, y se establecen los mecanismos, para que
éste sea revisado y mejorado de manera continuada a lo largo del proyecto,
según se van añadiendo funcionalidades al mismo.
La clave del proceso de desarrollar XP es la comunicación. La mayoría de los
problemas en los proyectos son por falta de comunicación en el equipo.
En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es
mejorar la comunicación entre todos los integrantes del equipo, al crear una
visión global y común de lo que se quiere desarrollar. La metáfora tiene que
ser expresada en términos conocidos por los integrantes del equipo, por ejemplo
comparando el sistema que se desarrollará con alguna cosa de la vida real.
Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir:
Cada vez que se quiere implementar una parte de código, en XP, se tiene que
escribir una prueba sencilla, y después escribir el código para que la pase.
Una vez pasada se amplía y se continúa. En XP hay una máxima que dice
"Todo el código que puede fallar tiene que tener una prueba".
Con estas normas se obtiene un código simple y funcional de manera bastante
rápida. Por esto es importante pasar las pruebas al 100%.
Respecto a la integración del soft, en XP se ha de hacer una integración
continua, es decir, cada vez se tienen que ir integrando pequeños fragmentos de
código, para evitar que al finalizar el proyecto se tenga que invertir grandes
esfuerzos en la integración final. En todo buen proyecto de XP, tendría que
existir una versión al día integrada, de manera que los cambios siempre se
realicen en esta última versión.
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier
parte del programa.
De esta manera se evita que haya partes "propietarias de cada
programador". Por esto es tan importante la integración diaria.
Para terminar, otra peculiaridad que tiene la XP. La de fomentar la
programación en parejas, es decir, hacer que los programadores no trabajen en
solitario, sino que siempre estarán con otra persona. Una pareja de
programadores ha de compartir el teclado, el monitor y el ratón. El principio
fundamental de este hecho es realizar de manera continua y sin parar el
desarrollo de código. Las parejas tienen que ir cambiando de manera periódica,
para hacer que el conocimiento se difunda en el grupo. Está demostrado que de
esta manera el trabajo es más eficaz y también se consigue más y mejor código.
PROGRAMACION
EXTREMA XP
HISTORIA
La programación extrema o
eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado
por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de
desarrollo de software. Al igual que éstos, la programación extrema se
diferencia de las metodologías tradicionales principalmente en que pone más
énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP
consideran que los cambios de requisitos sobre la marcha son un aspecto natural,
inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz
de adaptarse a los cambios de requisitos en cualquier punto de la vida del
proyecto es una aproximación mejor y más realista que intentar definir todos
los requisitos al comienzo del proyecto e invertir esfuerzos después en
controlar los cambios en los requisitos.
INTRODUCCION
Es una metodología ágil centrada en potenciar las
relaciones interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los
desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentación continua entre el cliente y el equipo de desarrollo,
comunicación fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy
cambiantes, y donde existe un alto riesgo técnico.
VENTAJAS
Y DESVENTAJAS
Ventajas:
Programación organizada.
Menor taza de errores.
Satisfacción del
programador.
Desventajas:
Es recomendable emplearlo
solo en proyectos a corto plazo.
Altas comisiones en caso
de fallar.
COMPARACION ENTRE
XP Y RUP
Comparación entre RU
Comparación entre RUP y SCRUM:
1.
¿Que es RUP?
Forma disciplinada o metodología de asignar tareas y
responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y
cómo). Esta metodología, llamada así por sus siglas en inglés Rational
Unified Process, divide en 4 fases el desarrollo del software:
o
· Inicio, El
Objetivo en esta etapa es determinar la visión del proyecto.
o
· Elaboración, En esta
etapa el objetivo es determinar la arquitectura óptima.
o
· Construcción, En esta
etapa el objetivo es llevar a obtener la capacidad operacional inicial.
o
· Transmisión, El
objetivo es llegar a obtener el release del proyecto.
2.
DISCIPLINA DE DESARROLLO
La metodología RUP, llamada así por sus
siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del
software:
o
· Inicio, El
Objetivo en esta etapa es determinar la visión del proyecto.
o
· Elaboración, En esta
etapa el objetivo es determinar la arquitectura óptima.
o
· Construcción, En esta
etapa el objetivo es llevar a obtener la capacidad operacional inicial.
o
· Transmisión, El
objetivo es llegar a obtener el release del proyecto.
|
|
|
Metodología de
Desarrollo de Software, María A. Sánchez Mendoza (Junio 7, 2003)
|
3.
DISCIPLINA DE SOPORTE
· Configuración y
administración del cambio: Guardando todas las versiones del proyecto.
· Administrando el
proyecto: Administrando horarios y recursos.
· Ambiente:
Administrando el ambiente de desarrollo.
· Distribución:
Hacer todo lo necesario para la salida del proyecto
-
5.
ELEMENTOS DE RUP
· Actividades, Son los procesos que se llegan a determinar en cada iteración.
· Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.
· Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de
modelo.
2.
3.
¿QUE ES XP?
La Programación Extrema es una metodología ligera de desarrollo de
software que se basa en la simplicidad, la comunicación y la realimentación
o reutilización del código desarrollado. Se requiere un grupo pequeño de
programadores para trabajar con esta metodología entre 2 – 15 personas y
estas irán aumentando conforme sea necesario.
|
|
|
Metodologia Extreme
Programing
|
4.
CARACTERÍSTICAS XP
· Pruebas
Unitarias: se basa en las pruebas realizadas a los
principales procesos, de tal manera que adelantándonos en algo hacia el
futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si
nos adelantáramos a obtener los posibles errores.
· Refabricación: se basa en la reutilización de código, para lo cual se crean
patrones o modelos estándares, siendo más flexible al cambio.
· Programación en pares: una
particularidad de esta metodología es que propone la programación en pares, la
cual consiste en que dos desarrolladores participen en un proyecto en una misma
estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está
haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce,
el otro consulta el mapa.
5.
¿QUE ES LO QUE PROPONE XP?
· Empieza en
pequeño y añade funcionalidad con retroalimentación continua
· El manejo del
cambio se convierte en parte sustantiva del proceso
· El costo del
cambio no depende de la fase o etapa
· No introduce
funcionalidades antes que sean necesarias
· El cliente o el
usuario se convierte en miembro
1.
¿QUE ES?
Es una metodología ágil y flexible para gestionar el desarrollo de
software. Se basa en construir primero la funcionalidad de mayor valor para el
cliente y en los principios de inspección continua, adaptación,
auto-gestión e innovación.
2.
CARACTERÍSTICAS
·
Solo abarca practicas de gestión sin entrar en las practicas de
desarrollo como puede hacer XP
· Delega
completamente en el equipo la responsabilidad de decidir la mejor manera de
trabajar para ser lo más productivo posibles y, le dan gran protagonismo a las
reuniones que realicen a lo largo del proyecto.
· Sus raíces
teóricas están en las teorías de la auto-organización.
3.
ROLES
I. Prorduct Owner
(Dueño del producto)
· Representa a
todos los interesados en el producto final.
· Marca las
prioridades del producto.
· Lleva el control
de las estimaciones.
· Retorno de
Inversión (ROI.)
II. Scrum Master
· Responsables del
proceso de Scrum
· Incorporación de
Scrum en la cultura de la organización.
· Asegura el
cumplimiento de los roles y responsabilidades
· Formación y
entrenamiento en el proceso.
III. Scrum Team
· Debe trasformar
las tareas del Sprint Backlog en un incremento de funcionalidad en el software.
· Desarrollar el
producto con calidad
· Auto-gestionado
· Auto-organizado
· Multi-funcional
· No mayor a ocho elementos
Scrum hace una clara diferencia entre
gallinas y cerdos, para garantizar quienes tienen la responsabilidad, la
autoridad necesaria para poder lograr el éxito del proceso y que quienes no la
tienen y no puedan o producen interferencias innecesarias.
- METODOLOGÍA DE
TRABAJO
· Equipos de 6 y
10 personas revisan los requisitos, tecnología disponible y otras funciones
para determinar cómo incrementar la funcionalidad.
· Reuniones
diarias, antes de empezar a trabajar, con una duración máxima de 4 horas.
· En cada reunión
las preguntas claves a contestar son: ¿Qué es lo que hizo desde la última
reunión?, ¿Qué es lo que se va a hacer hasta la siguiente reunión? y
¿Cómo se va a llevar a cabo?
|
|
|
Proceso ágil de
desarrollo iterativo e incremental. Origen: articulo "Ther New New
Product Develepment Game" (Takeuchi y Nonaka, 1986)
|
