Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

CAPITULO I METODOLOGIA RUP

No description
by

Susan Oliva

on 7 February 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of CAPITULO I METODOLOGIA RUP

METODOLOGIA RUP.
OBJETIVOS.
CARACTERISTICAS.
DESVENTAJAS.
VENTAJAS.
FASES
Es una metodología de desarrollo de software formal, orientadas a objetos, con un
ciclo de vida espiral.

Este proceso de desarrollo de software utiliza el lenguaje unificado de modelado
UML, y constituye una de las mejores y más utilizadas; 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.
1. Genera demaciados costos.

2. No recomendable para proyectos pequeños.

3. Maneja un alto grado de complejidad.

4. Requiere conocimientos de proceso y de UML
1. Proporcionar una guiadel orden de las actividades de los equipos.

2. Especificar cuales artefactos deben ser desarrollados y cuando deben ser desarrollados.

3. Dirigir las tareas de desarrolladores individaluales y equipos como una sola.
1. Reduce riesgos del proyecto.

2. Integra desarrollo con mantenimiento.

3. Alto progreso en las primeras etapas.

4. Temprana retroalimentacion que se ajuste a las necesidades reales.
RUP (Proceso Racional Unificado)
METODOLOGIA
RUP

1. Dirigido por Casos de Uso. 2. Forma disciplinada de asignar tareas.

3. Desarrollo Iterativo. 4. Enfoque orientado a objetos.

5. Permite mediciones. 6. Administracion de requisitos.

7. Es adaptable. 8. Conceptualmente amplio y diverso.

9. Utiliza el UML como lenguaje de representación visual.
Esta fase tiene como funciòn hacer el levantamientro del proyecto definir y acordar el alcance de este con los patrocinadores e identificar los riesgos asociados al proyecto.
En la fase de elaboraciòn se diseña la soluciòn Preliminar, se seleccionan los casos de uso que permitiran definir la arquitectura base del sistema base, se realizan sus respectivas especificaciones y luego se desarrollan.
El propósito de esta fase es completar
la funcionalidad del sistema, para ello
se deben clarificar los requisitos pendientes,
administrar los cambios de acuerdo
a las evaluaciones realizados por los usuarios
y se realizan las mejoras para el proyecto.
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
INICIO
ELABORACIÓN
CONSTRUCCIÓN
TRANSCICIÓN
Analista.
Procesos de negocios.
Diseñador.
Del negocio.
De interfaz de usuario.
De capsulas.
De base de datos.
Sistemas.
- Implementador.
- Especificador de requisitos.
- Arquitecto de software.
- Implementador.
- Integrador.
- Gestor de pruebas.
- Administrador del sistema.
De pruebas.
Jefes.
De proyecto.
De control de cambios.
De configuración.
De pruebas.
De despliegues.
- Ingeniero de procesos.
- Documentador tecnico.
- Especialista en herramientas.
- Desarrollador de cursos.
- Artista grafico.
- Revisor tecnico.
- Revisor de gestion del proyecto.
Especialista
De herramientas.
De pruebas
ROLES
PRINCIPIOS.
COSTEO DE SOFTWARE
Para realizar estimaciones seguras de costos se tienen varias opciones.
1.



2.


3.
Utilizar técnicas de descomposición relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto. “divide y vencerás”.
Desarrollar un modelo empirico para el calculo de costos y esfuerzos del software.
Utilizar la medida COCOMO.
FUENTES.
http://www.slideshare.net/cortesalvarez/metodologa-rup

http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm

http://nuyoo.utm.mx/~caff/doc/El%20Proceso%20Unificado%20Rational.pdf

http://softwarerecopilation.wordpress.com/modelo-rup/

http://www.ecured.cu/index.php/Proceso_Unificado_de_Desarrollo

http://es.scribd.com/doc/297224/RUP

http://rupuml.blogspot.com/2009/06/caracteristicas.html
MODELO COCOMO.
MODELO CONSTRUCTIVO DE COSTOS.
Es una jerarquía de modelos de estimación de costes de software que incluye submodelos básico , intermedio y avanzado.
SUBMODELO BASICO.
Calcula el esfuerzo y el coste del desarrollo en función del tamaño estimado del programa (LDC). Se utiliza para una aproximación rápida al principio del ciclo de vida.
calcula el esfuerzo y el coste en función del tamaño estimado del programa y de un conjunto de “guías de coste” que incluyen una evaluación subjetiva del producto, hardware, personal y atributos del producto
SUBMODELO INTERMEDIO.
SUBMODELO AVANZADO.
incorpora las características del sobmodelo 2 "Intermedio" y evalúa el impacto de los FAE en cada fase del desarrollo.
TIPOS DE PROYECTOS
El RUP está basado en 5 principios clave que son los siguientes:
1. Adaptar el proceso
2. Equilibrar prioridades
3.Demostrar valor iterativamente
4. Colaboración entre equipos
5. Enfocarse en la calidad

Existen tres tipos los cuales son.
ORGANICOS.


SEMIOPATICOS.


EMPOTRADOS.
Relativamente pequeños y sencillos , en los que trabajan pequeños equipos con experiencia, sobre un conjunto de requisitos poco rígidos.
Proyectos intermedios (en tamaño y complejidad ) en los que participan equipos con variados niveles de experiencia, y que deben satisfacer requisitos poco o medio rígidos.
Proyectos que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidos.
PRINCIPIOS
ADAPTAR EL PROCESO
Aqui el proceso de debera adaptar a las necesidades del cliente ya que va a ser de suma importancia interactuar con el. Aqui se tiene en cuenta el alcanze del proyecto.
EQUILIBRAR
PRIORIDADES
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados .Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
DEMOSTRAR VALOR ITERATIVAMENTE
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.
COLABORACIÒN ENTRE EQUIPOS
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos desarrollo, evaluaciones, planes, resultados, etc.
ELEVAR EL NIVEL DE ABSTRACCIÒN
Este principio describe cómo mejorar
la productividad y disminuir la
complejidad del software.
Esto permite
ESTO PERMITE
Reutilizar los activos existentes.
Elaborar una arquitectura dirigida a la elasticidad, la calidad, la inteligibilidad y el control de la complejidad.
Utilizar herramientas y lenguajes de alto nivel para reducir la cantidad de documentación que se produce.
Centrarse primero en la arquitectura.
1.

2.

3.

4.
ENFOCARSE EN
LA CALIDAD
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subnormal.
EJEMPLO DEL MODELO RUP
CASOS DE USO
Un caso de uso es una descripción de los pasos o actividades que deben hacerse para realizar algún proceso. Los personajes o entidades que participarán en un caso de uso son “actores”.

Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Los diagramas de casos de especifican la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas (ejemplo de caso de uso: imagen de arriba)
Full transcript