MODELOS DE PROCESO DE

SOFTWARE
Integrantes: Miguel A. Pacosillo Limachi
Gabriela Quispe Apaza
Marco A. Sanchez Acarapi
Materia: Ingeniera de Software
EXTREME PROGRAMMING (XP)
Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el
xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos
los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios.

CARACTERISTICAS:
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresin Se aconseja escribir el cdigo de la prueba
antes de la codificacin.
Programacin por parejas: se recomienda que las tareas de desarrollo se lleven
a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad
del cdigo escrito de esta manera: el cdigo es revisado y discutido mientras se
escribe, es ms importante que la posible prdida de productividad inmediata.
Frecuente interaccin del equipo de programacin con el cliente o usuario. Se
recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer
entregas frecuentes.
FASES DE XP
1 Fase: Planificacin del proyecto. 3 Fase: Codificacin.
Historias de usuario. 4 Fase: Pruebas.
Release planning. El uso de los test en X.P es el siguiente.
Test de aceptacin.
Iteraciones:
Velocidad del proyecto.
Programacin en pareja.
Reuniones diarias. Ventajas:
Programacin organizada.
2 Fase: Diseo.
Menor taza de errores.
Diseos simples.
Satisfaccin del programador.
Glosarios de trminos.
Desventajas:
Riesgos. Es recomendable emplearlo solo en proyectos a
corto plazo.
Funcionalidad extra.
Altas comisiones en caso de fallar.
Tarjetas C.R.C. (Class,
Responsabilities and Collaboration)
METODOLOGIA RUP
Rational Unified Process El Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y otros de
la Rational como el proceso complementario al UML. El RUP es un armazn de proceso y como tal puede
acomodar una gran variedad de procesos.
El RUP puede usarse en un estilo muy tradicional de cascada o de una manera gil. Como resultado se puede
usar el RUP como un proceso gil o como un proceso pesado - todo depende de cmo lo adapte a su ambiente.
CARACTERISTICAS:
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software.
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software
FASES DE RUP
1 Fase: Incepcin.
Significa comienzo, Se especifican
los objetivos del ciclo de vida del
proyecto y las necesidades de cada
participante, Establecer el alcance y
las condiciones de lmite y los
criterios de aceptabilidad. Se
identifican los casos de uso que
orientarn la funcionalidad.
2 Fase: Elaboracin.
Se analiza el dominio del problema y
se define el plan del proyecto. RUP
presupone que la fase de elaboracin
brinda una arquitectura
suficientemente slida junto con
requerimientos y planes bastante
estables. Se describen en detalle la
infraestructura y el ambiente de
desarrollo, as como el soporte de
herramientas de automatizacin.
3 Fase: Construccin.
Se desarrollan, integran y verifican todos los
componentes y rasgos de la aplicacin. RUP
considera que esta fase es un proceso de
manufactura, en el que se debe poner nfasis en la
administracin de los recursos y el control de
costos, agenda y calidad.
4 Fase: Transicin.
Comienza cuando el producto est suficientemente
maduro para ser entregado. Se corrigen los ltimos
errores y se agregan los rasgos pospuestos. La fase
consiste en prueba beta, piloto, entrenamiento a
usuarios y despacho del producto a mercadeo,
distribucin y ventas. Se produce tambin la
documentacin.
Ventajas:
Requiere de conocimientos del proceso y de UML
Progreso visible en las etapas tempranas
El uso de iteraciones
Evaluacin de riesgos en lugar de descubrir en la integracin final del sistema
Facilita la reutilizacin del cdigo
Desventajas:
Por el grado de complejidad puede no resultar no muy adecuado
Mal aplicado en el estilo cascada
METODOLOGA SCRUM
Scrum es una metodologa gil de desarrollo, aunque surgi como modelo para el desarrollo de
productos tecnolgicos, tambin se emplea en entornos que trabajan con requisitos inestables y que
requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de
software.
Es una metodologa de desarrollo muy simple, que requiere trabajo duro porque no se basa en el
seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin del
proyecto.

CARACTERISTICAS:
Equipos autodirigidos
Utiliza reglas para crear un entorno gil de administracin de proyectos
No prescribe prcticas especficas de ingeniera
Los requerimientos se capturan como tems de la lista Product Backlog.
El producto se construye en una serie de Sprints de un mes de duracin.
FASES DE SCRUM
1.- Pre-juego
Planificacin: Definicin de una nueva versin basada en la pila actual, junto
con una estimacin de coste y agenda. Si se trata de un nuevo sistema, esta
fase abarca tanto la visin como el anlisis. Si se trata de la mejora de un
sistema existente comprende un anlisis de alcance ms limitado.
Arquitectura: Diseo de la implementacin de las funcionalidades de la pila.
Esta fase incluye la modificacin de la arquitectura y diseo generales.
2.- Juego
Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versin con
respeto continuo a las variables de tiempo, requisitos, costo y competencia.
La interaccin con estas variables define el final de esta fase. El sistema va
evolucionando a travs de mltiples iteraciones de desarrollo o sprints.
3.- Post-juego
Preparacin para el lanzamiento de la versin, incluyendo la documentacin
final y pruebas antes del lanzamiento de la versin.
VENTAJAS
Evaluacin en cada fase que permite cambios de objetivos.
Funciona bien en proyectos de innovacin.
Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de
desarrollar el software.
Seguimiento detallado en cada una de las fases.
DESVENTAJAS
La evaluacin de riesgos es compleja
Excesiva flexibilidad para algunos proyectos
Se pone al cliente en una situacin que puede ser muy incmoda .
El cliente deber ser capaz de describir y entender a un gran nivel de detalle
para poder acordar un alcance del proyecto con l.
METODOLOGIA AUP (AGIL UNIFIED PROCESS)
El AUP es un acercamiento aerodinmico a desarrollo del software basado en el
Proceso Unificado Rational de IBM (RUP), basado en disciplinas y entregables
incrementales con el tiempo. El ciclo de vida en proyectos grandes es serial
mientras que en los pequeos es iterativo. Las disciplinas de Aup son:
Modelado, Implementacin, Prueba, Despliegue, Administracin de la
configuracin, Administracin o gerencia del Proyecto, Entorno .

Caractersticas:
Iterativo e Incremental.
Descomposicin de un proyecto grande en mini-
proyectos
Cada mini-proyecto es una iteracin
Las iteraciones deben estar controladas
Cada iteracin trata un conjunto de casos de uso
Ventajas del enfoque iterativo
Deteccin temprana de riesgos
Administracin adecuada del cambio
Mayor grado de reutilizacin
Mayor experiencia para el grupo de desarrollo
Dirigido por Casos de Uso
Se centra en la funcionalidad que el sistema debe poseer para satisfacer las
necesidades de un usuario (persona, sistema externo, dispositivo) que interacta con l

Casos de uso como el hilo conductor que orienta las actividades de

Desarrollo
Centrado en la Arquitectura

Concepto similar a la arquitectura de un edificio

Varios planos con diferentes aspectos del edificio
Tener una imagen completa del edificio antes que comience la
construccin

Arquitectura en software
Diferentes vistas del sistema: estructural, funcional, dinmico, etc.
plataforma en la que va a operar
Determina la forma del sistema

Arquitectura: determina la forma del sistema

Casos de uso: determinan la funcin del sistema

1ra fase Iniciacin.
El objetivo de esta fase es identificar el alcance inicial del proyecto, una
arquitectura potencial para el sistema y obtener, si procede, financiacin
para el proyecto y la aceptacin por parte de los promotores del sistema.
2da fase Elaboracin.
Mediante esta fase se pretende identificar y validar la arquitectura del
sistema.
3ra fase Construccin.
El objetivo de esta fase consiste en construir software desde un punto de
vista incremental basado en las prioridades de los participantes.
4ta fase Transicin.
En esta fase se valida y despliega el sistema en el entorno de produccin.
VENTAJAS:
El personal sabe lo que esta haciendo: no obliga a conocer detalles.

Simplicidad: apuntes concisos.

Agilidad: procesos simplificados del RUP

Centrarse en actividades de alto valor: esenciales para el desarrollo.

Herramientas independientes: a disposicin del usuario.

Fcil adaptacin de este producto: de fcil acomodo (HTML)

DESVENTAJAS:
El AUP es un producto muy pesado en relacin al RUP.

Como es un proceso simplificado, muchos desarrolladores eligen trabajar con el RUP,

por tener a disposicin mas detalles en el proceso.
METODOLOGIA RAD
El desarrollo rpido de aplicaciones o RAD ( rapid application development) es un
proceso de desarrollo de software, desarrollado inicialmente por James Martin
en1980. El mtodo comprende el desarrollo interactivo, la construccin de prototipos
y el uso de utilidades CASE (Computer Aided Software Engineering).
Tradicionalmente, el desarrollo rpido de aplicaciones tiende a englobar tambin la
usabilidad, utilidad y la rapidez de ejecucin.

CARACTERISTICAS:
Equipos Hbridos
Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y
usuarios de tiempo completo del sistema as como aquellas personas
involucradas con los requisitos.
Los desarrolladores de RAD deben ser "renacentistas": analistas, diseadores y
programadores en uno.
Herramientas Especializadas
Desarrollo "visual"
Creacin de prototipos falsos (simulacin pura)
Creacin de prototipos funcionales
Mltiples lenguajes
Calendario grupal
Herramientas colaborativas y de trabajo en equipo
Componentes reusables
Interfaces estndares (API)
"Timeboxing

Las funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.

Prototipos Iterativos y Evolucionarios.

Reunin JAD (Joint Application Development):

Se reunen los usuarios finales y los desarrolladores.
Lluvia de ideas para obtener un borrador inicial de los requisitos.
Iterar hasta acabar:
Los desarrolladores construyen y depuran el prototipo basado en los requisitos
actuales.
Los diseadores revisan el prototipo.
Los clientes prueban el prototipo, depuran los requisitos.
Los clientes y desarrolladores se renen para revisar juntos el producto,
refinar los requisitos y generar solicitudes de cambios.
Los cambios para los que no hay tiempo no se realizan. Los requisitos
secundarios se eliminan si es necesario para cumplir el calendario.

FASES DE RAD
1ra fase Modelado de gestin: el flujo de informacin entre las funciones
de gestin se modela de forma que responda a las siguientes preguntas:
Qu informacin conduce el proceso de gestin? Qu informacin se
genera? Quin la genera? A dnde va la informacin? Quin la
proceso?
2da fase Modelado de datos: el flujo de informacin definido como parte de la fase de
modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar
la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las
relaciones entre estos objetos.

3ra fase Modelado de proceso: los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de informacin necesario para implementar
una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar,
suprimir, o recuperar un objeto de datos. Es la comunicacin entre los objetos.

4ta fase Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta

generacin. En lugar de crear software con lenguajes de programacin de tercera generacin,
el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando
es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se
utilizan herramientas automticas para facilitar la construccin del software.

5ta fase Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas.
Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las
interfaces a fondo.
VENTAJAS:
Comprar puede ahorrar dinero en comparacin con construir.
Los entregables pueden ser fcilmente trasladados a otra plataforma.
El desarrollo se realiza a un nivel de abstraccin mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificacin manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
Posiblemente menor costo.
Ciclos de desarrollo ms pequeos.
Interfaz grfica estndar.
DESVENTAJAS:
Comprar puede ser ms caro que construir.
Costo de herramientas integradas y equipo necesario.
Progreso ms difcil de medir.
Menos eficiente.
Menor precisin cientfica.
Riesgo de revertirse a las prcticas sin control de antao.
Ms fallas (por sndrome de codificar a lo bestia).
Prototipos pueden no escalar, un problema maysculo.
Funciones reducidas (por timeboxing).
Dependencia en componentes de terceros: funcionalidad de ms o
de menos, problemas legales.