SlideShare una empresa de Scribd logo
1 de 10
[ESCRIBA EL NOMBRE DE LA COMPAÑÍA]




    Open UP
Ingenieria en Software
  Mario Esteban Machado Valenzuela
        RubenUrutia Contreras
       David Marquez Alvarado


            19/02/2013
¿Qué es OpenUP?
OpenUp es un método y un proceso de desarrollo de software propuesto por un
conjunto de empresas de tecnología, quienes lo donaron en el año 2007 a la
Fundación Eclipse. La fundación lo ha publicado bajo una licencia libre y lo
mantiene como método de ejemplo dentro del proyecto Eclipse Process
Framework.

Descripción
El OpenUP es un proceso mínimo y suficiente, lo que significa que solo el
contenido fundamental y necesario es incluido. Por lo tanto no provee lineamientos
para todos los elementos que se manejan en un proyecto pero tiene los
componentes básicos que pueden servir de base a procesos específicos. La
mayoría de los elementos de OpenUP están declarados para fomentar el
intercambio de información entre los equipos de desarrollo y mantener un
entendimiento compartido del proyecto, sus objetivos, alcance y avances.


Principios del OpenUP

   Colaborar para sincronizar intereses y compartir conocimiento. Este principio
   promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la
   colaboración y desarrollan un conocimiento compartido del proyecto.
   Equilibrar las prioridades para maximizar el beneficio obtenido por los
   interesados en el proyecto. Este principio promueve prácticas que permiten a
   los participantes de los proyectos desarrollar una solución que maximice
   los beneficios obtenidos por los participantes y que cumple con los requisitos y
   restricciones del proyecto.
   Centrarse en la arquitectura de forma temprana para minimizar el riesgo y
   organizar el desarrollo.
   Desarrollo evolutivo para obtener retroalimentación y mejoramiento continuo.
   Este principio promueve prácticas que permiten a los equipos de desarrollo
   obtener retroalimentación temprana y continua de los participantes del
   proyecto, permitiendo demostrarles incrementos progresivos en la
   funcionalidad.
Organización de los componentes del OpenUP
El OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas:
el método y el proceso. El contenido del método es donde los elementos del
método (roles, tareas, artefactos y lineamientos) son definidos, sin tener en cuenta
como son utilizados en el ciclo de vida del proyecto. El proceso es donde los
elementos del método son aplicados de forma ordenada en el tiempo. Muchos
ciclos de vida para diferentes proyectos pueden ser creados a partir del mismo
conjunto de elementos del método.


Áreas de interés
Los elementos del OpenUP dirigen la organización del trabajo en los niveles
personal, de equipo y de interesados.
A nivel personal, los integrantes de un proyecto contribuyen con su trabajo con
pequeños incrementos en funcionalidad, denominados micro incrementos, los
cuales representan los resultados obtenidos en pocas horas o pocos días de
trabajo. La solución evoluciona basada en dichos micro incrementos de tal forma
que el progreso puede ser visualizado efectivamente cada día. Los integrantes del
equipo de desarrollo de forma abierta comparten su progreso diario el cual
incrementa la visibilidad en el trabajo, la confianza y el trabajo en equipo.
El proyecto en general se divide en iteraciones, las cuales son planificadas en un
intervalo definido de tiempo que no superan las pocas semanas. El OpenUP tiene
elementos que ayudan a los equipos de trabajo a enfocar los esfuerzos a través
del ciclo de vida de cada iteración de tal forma que se puedan distribuir
funcionalidades incrementales de una manera predecible, una versión totalmente
probada y funcional al final de cada iteración.
El OpenUP estructura el ciclo de vida de un proyecto en cuatro fases: concepción,
elaboración, construcción y transición. El ciclo de vida del proyecto provee a los
interesados un mecanismo de supervisión y dirección para controlar los
fundamentos del proyecto, su ámbito, la exposición a los riesgos, el aumento de
valor y otros aspectos.


OpenUP/Basic
      OpenUP/Basic está diseñado para equipos pequeños, trabajando juntos en
      la misma localidad.
      El equipo tiene que participar plenamente en la interacción diaria de manera
      presencial.
      Los miembros del equipo participan en una colaboración significativa,
      tomando sus propias decisiones en cuanto a lo que se necesita trabajar,
      cuales son las prioridades, y la mejor manera de abordar las necesidades
      de los stakeholders.
Los miembros del equipo colaboran ampliamente. La presencia de los
stakeholders como miembros del equipo es crítica para realizar exitosamente
OpenUP/Basic.
Los miembros del equipo participan a diario en las reuniones stand-up para
comunicar el estado y sus asuntos. Los problemas se abordan fuera de las
reuniones diarias.
OpenUP/Basic se enfoca en reducir significativamente el riesgo de manera
temprana en el ciclo de vida. Esto requiere unas reuniones regulares de revisión
de los riesgos y una implementación rigurosa de las estrategias de mitigación.
Todo el trabajo será listado, seguido y asignado a través de la "lista de ítems de
trabajo". Los miembros del equipo están en un único repositorio para todas las
tareas que necesitan ser registradas y seguidas. Esto incluye todos los
requerimientos de cambio, errores y requerimientos de los stakeholder.
Los casos de uso son utilizados para obtener y describir los requisitos. Los
miembros del equipo deben desarrollar habilidades para escribir buenos casos de
uso. Los Stakeholders son responsables de revisar y certificar que los
requerimientos son correctos. Los casos de uso son desarrollados de manera
colaborativa.
Los requisitos arquitectónicamente más importantes deben ser identificados y
estabilizados dentro de la fase de Elaboración de tal forma que sea creada una
arquitectura robusta, la cual es el corazón del sistema. Un cambio de un requisito
arquitectónicamente significativo puede surgir posteriormente en el desarrollo, el
cual debe ser abordado, pero el riesgo de que esto ocurra es reducido
significativamente dentro de la iteración de Elaboración.


Beneficios en el uso del OpenUP
      Ya que es apropiado para proyectos pequeños y de bajos recursos permite disminuir las
      probabilidades de fracaso en los proyectos pequeños e incrementar las probabilidades de
      éxito.
      Permite detectar errores tempranos a través de un ciclo iterativo.
      Evita la elaboración de documentación, diagramas e iteraciones innecesarios requeridos
      en la metodología RUP.
      Por ser una metodología ágil tiene un enfoque centrado al cliente y con iteraciones cortas.
Ciclo de vida
Cada fase consiste de una o más iteraciones, donde se trabaja por versiones
estables del software que son desarrolladas y liberadas, el completar cada
iteración representa un avance menos para el proyecto y una contribución al éxito
arquitectónico del hito mayor de la Fase donde los objetivos de la fase son
alcanzados.
1. Concepción
Primera de las 4 fases en el proyecto del ciclo de vida, acerca del entendimiento
del propósito y objetivos y obteniendo suficiente información para confirmar que el
proyecto debe hacer. El objetivo de ésta fase es capturar las necesidades de los
stakeholder en los objetivos del ciclo de vida para el proyecto.

2. Elaboración

Es el segundo de las 4 fases del ciclo de vida del OpenUP donde se trata los
riesgos significativos para la arquitectura. El propósito de esta fase es establecer
la base la elaboración de la arquitectura del sistema.

3. Construcción

Esta fase está enfocada al diseño, implementación y prueba de las
funcionalidades para desarrollar un sistema completo. El propósito de esta fase es
completar el desarrollo del sistema basado en la Arquitectura definida.

4. Transición

Es la última fase, cuyo propósito es asegurar que el sistema es entregado a los
usuarios, y evalúa la funcionalidad y performance del último entregable de la fase
de construcción.

El siguiente diagrama muestra el Ciclo de vida de OpenUP/Basic.




Cada fase podrá tener tantas iteraciones como se requiera dependiendo del grado
de novedad del dominio de negocio, de la tecnología a ser utilizada, de la
complejidad de la arquitectura de la solución y del tamaño del proyecto, entre otros
factores.
Las iteraciones pueden tener duraciones variables dependiente de las
características del proyecto. Iteraciones de un mes son las recomendables, ya que
este periodo de tiempo proporciona:
Una cantidad de tiempo razonable para que los proyectos entreguen
      incrementos considerables en funcionalidad.
      Retro alimentación temprana y frecuente por parte de los usuarios.
      Administración a tiempo de los riesgos y problemas encontrados durante el
      curso del proyecto.

Roles
Analista
El analista es el que representa al cliente y el usuario final, se refiere a la
obtención de requerimientos de los interesados, por medio de comprender el
problema a resolver, capturando y creando las prioridades de los requerimientos




Arquitecto
El arquitecto es el responsable del diseño de arquitectura del software. Tomando
las decisiones técnicas claves, las cuales limitaran el conjunto de diseño y la
implementación del proyecto.




Desarrollador
Es quien tiene la responsabilidad del desarrollo de una parte del sistema o el
sistema completo dependiendo de la magnitud del mismo, se encarga del diseño
ajustándolo a la arquitectura y de la implementación de pruebas unitarias y de
integración para los componentes desarrollados.
Lider del proyecto
Dirige la planificación del proyecto en colaboración con las partes interesadas y el
equipo, coordina las interacciones de los interesados, manteniendo al equipo del
proyecto enfocado en los objetivos del mismo




Takeholder
Representan al grupo que está interesado en el proyecto, quienes necesariamente
deberán de ser satisfechos por el mismo. Este papel lo puede jugar cualquier
persona que es afectada por los objetivos del proyecto.




Tester
Es el responsable de las actividades básicas y de realizar las pruebas, se encarga
de la identificación, definición, implementación y conducción de las pruebas
necesarias. Así como el ingreso de pruebas y el análisis de resultados.
Otro rol
Representa a cualquier otra persona en el equipo que puede realizar tareas
generales.




Conclusión
El OpenUp es un proceso modelo y extensible, dirigido a gestión y desarrollo de
proyectos de software basados en desarrollo iterativo, ágil e incremental apropiado
para proyectos pequeños y de bajos recursos; y es aplicable a un conjunto amplio
de plataformas y aplicaciones de desarrollo.
Referencias:
SÁBADO, 27 DE SEPTIEMBRE DE 2008. Gestión de Proyectos. Recuperado
el16 DE FEBRERO DE 2013. (http://kasyles.blogspot.mx/2008/09/openup-como-
alternativa-metodolgica.html).



Diego García Arriaza,Mario Rivas Sánchez. 16 DE NOVIEMBRE DE 2010-
wikiCE.Recuperado el 16 de Febrero de
2013.( http://osl2.uca.es/wikiCE/index.php/Open_Unified_Process).

Más contenido relacionado

La actualidad más candente

GSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLO
GSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLOGSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLO
GSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLOpedrobustillo
 
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...Joel Fernandez
 
Metodologías agiles del desarrollo software
Metodologías agiles del desarrollo softwareMetodologías agiles del desarrollo software
Metodologías agiles del desarrollo softwareRicardo Mateus
 
Metodologias de desarrollo del software
Metodologias de desarrollo del softwareMetodologias de desarrollo del software
Metodologias de desarrollo del softwaregeurquizo
 
Metodología tradicional
Metodología tradicionalMetodología tradicional
Metodología tradicionalJesenia Escobar
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rupmireya2022
 
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa CondeProceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa CondeSam Espinosa
 

La actualidad más candente (16)

GSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLO
GSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLOGSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLO
GSI AUP_BEGOÑAOJEDA_JACOBOPORTILLO_PEDROBUSTILLO
 
Rup
RupRup
Rup
 
Is.exp.329704
Is.exp.329704Is.exp.329704
Is.exp.329704
 
Semana 1 2-3 (3)
Semana 1 2-3 (3)Semana 1 2-3 (3)
Semana 1 2-3 (3)
 
rup
ruprup
rup
 
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...Metodologías Ágiles  para el Desarrollo de Software y Metodologias Para el de...
Metodologías Ágiles para el Desarrollo de Software y Metodologias Para el de...
 
Metodologías agiles del desarrollo software
Metodologías agiles del desarrollo softwareMetodologías agiles del desarrollo software
Metodologías agiles del desarrollo software
 
Disciplina de desarrollo rup
Disciplina de desarrollo rupDisciplina de desarrollo rup
Disciplina de desarrollo rup
 
Rup presentacion
Rup presentacionRup presentacion
Rup presentacion
 
Metodologias de desarrollo del software
Metodologias de desarrollo del softwareMetodologias de desarrollo del software
Metodologias de desarrollo del software
 
Metodología tradicional
Metodología tradicionalMetodología tradicional
Metodología tradicional
 
Comprendiendo RUP
Comprendiendo   RUPComprendiendo   RUP
Comprendiendo RUP
 
Metodologías agiles
Metodologías agiles Metodologías agiles
Metodologías agiles
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
METODOLOGIA RUP
METODOLOGIA RUPMETODOLOGIA RUP
METODOLOGIA RUP
 
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa CondeProceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
 

Destacado

ассоль
ассольассоль
ассольens2014
 
The Yin and Yang of IP Law
The Yin and Yang of IP LawThe Yin and Yang of IP Law
The Yin and Yang of IP LawKlemchuk LLP
 
Puntodis planos de evacuación accesibles 2014
Puntodis planos de evacuación accesibles 2014Puntodis planos de evacuación accesibles 2014
Puntodis planos de evacuación accesibles 2014OPEN GROUP TECHONOLOGY
 
diccionario-ilustrado de la biblia
diccionario-ilustrado de la bibliadiccionario-ilustrado de la biblia
diccionario-ilustrado de la bibliaJOSE GARCIA PERALTA
 
Les tests rapides de la dengue, une opportunité de renforcement des capacités...
Les tests rapides de la dengue, une opportunité de renforcement des capacités...Les tests rapides de la dengue, une opportunité de renforcement des capacités...
Les tests rapides de la dengue, une opportunité de renforcement des capacités...valéry ridde
 
N 1 10
N 1 10N 1 10
N 1 10budzma
 
Excellent jobs profile
Excellent jobs profileExcellent jobs profile
Excellent jobs profileAnnu Gupta
 
THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...
THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...
THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...IFG Network marcus evans
 
Goodwill - June 2014 Social Enterprise Presentation
Goodwill - June 2014 Social Enterprise PresentationGoodwill - June 2014 Social Enterprise Presentation
Goodwill - June 2014 Social Enterprise PresentationStepUpSiliconValley
 
Egipto 1º eso
Egipto 1º esoEgipto 1º eso
Egipto 1º esogermantres
 

Destacado (20)

Trabajo en equipo
Trabajo en equipoTrabajo en equipo
Trabajo en equipo
 
ассоль
ассольассоль
ассоль
 
The Yin and Yang of IP Law
The Yin and Yang of IP LawThe Yin and Yang of IP Law
The Yin and Yang of IP Law
 
Puntodis planos de evacuación accesibles 2014
Puntodis planos de evacuación accesibles 2014Puntodis planos de evacuación accesibles 2014
Puntodis planos de evacuación accesibles 2014
 
diccionario-ilustrado de la biblia
diccionario-ilustrado de la bibliadiccionario-ilustrado de la biblia
diccionario-ilustrado de la biblia
 
Is.exp.329704
Is.exp.329704Is.exp.329704
Is.exp.329704
 
Membrana celular
Membrana celularMembrana celular
Membrana celular
 
DEUS PODE - Melk Villar - SLIDES
DEUS PODE - Melk Villar - SLIDESDEUS PODE - Melk Villar - SLIDES
DEUS PODE - Melk Villar - SLIDES
 
Les tests rapides de la dengue, une opportunité de renforcement des capacités...
Les tests rapides de la dengue, une opportunité de renforcement des capacités...Les tests rapides de la dengue, une opportunité de renforcement des capacités...
Les tests rapides de la dengue, une opportunité de renforcement des capacités...
 
N 1 10
N 1 10N 1 10
N 1 10
 
Presentacion certificando 2.0 - lucar
Presentacion   certificando 2.0 - lucarPresentacion   certificando 2.0 - lucar
Presentacion certificando 2.0 - lucar
 
Excellent jobs profile
Excellent jobs profileExcellent jobs profile
Excellent jobs profile
 
THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...
THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...
THE WIGMORE ASSOCIATION – A NEW AGE OF GLOBAL INTERDEPENDENCE-Harold Pitcairn...
 
The shutout
The shutoutThe shutout
The shutout
 
Goodwill - June 2014 Social Enterprise Presentation
Goodwill - June 2014 Social Enterprise PresentationGoodwill - June 2014 Social Enterprise Presentation
Goodwill - June 2014 Social Enterprise Presentation
 
Egipto 1º eso
Egipto 1º esoEgipto 1º eso
Egipto 1º eso
 
Segunda guerra mundial
Segunda guerra mundialSegunda guerra mundial
Segunda guerra mundial
 
Acuerdo liberatorio Gobierno Mahuad
Acuerdo liberatorio Gobierno MahuadAcuerdo liberatorio Gobierno Mahuad
Acuerdo liberatorio Gobierno Mahuad
 
Tempo_do_crime
Tempo_do_crimeTempo_do_crime
Tempo_do_crime
 
Untitled Presentation
Untitled PresentationUntitled Presentation
Untitled Presentation
 

Similar a OpenUP: Un método ágil para el desarrollo de software

Metodología open up ágil y tradicional
Metodología open up ágil y tradicionalMetodología open up ágil y tradicional
Metodología open up ágil y tradicionalCarmelo Hernandez
 
Metodologias
MetodologiasMetodologias
MetodologiasNorerod
 
Metodologia upen up
Metodologia upen upMetodologia upen up
Metodologia upen upunimag
 
Proceso Unificado De Rational
Proceso Unificado De RationalProceso Unificado De Rational
Proceso Unificado De RationalJulio Pari
 
Documentacion rational
Documentacion rationalDocumentacion rational
Documentacion rationalMila Pascual
 
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptxSEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptxJ Martin Luzon
 
4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De RationalJulio Pari
 
Metodologias de desarrollo
Metodologias de desarrolloMetodologias de desarrollo
Metodologias de desarrolloHermes Romero
 
Breve explicacion del Rup
Breve explicacion del RupBreve explicacion del Rup
Breve explicacion del Rupluisitoman
 
Metodologías de desarrollo de software
Metodologías de desarrollo de softwareMetodologías de desarrollo de software
Metodologías de desarrollo de softwareWilfredo Mogollón
 
Las metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el PerúLas metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el PerúPagina web Peru - F5mas
 
Desarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptx
Desarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptxDesarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptx
Desarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptxefren abdon
 
Methodologies in Software Development and IT
Methodologies in Software Development and ITMethodologies in Software Development and IT
Methodologies in Software Development and ITsebastianperezgonzal3
 
Wagneher franck mallma nuñez
Wagneher franck mallma nuñezWagneher franck mallma nuñez
Wagneher franck mallma nuñezhenryedo
 
Wagneher franck mallma nuñez
Wagneher franck mallma nuñezWagneher franck mallma nuñez
Wagneher franck mallma nuñezhenryedo
 
Metodologias rup
Metodologias rupMetodologias rup
Metodologias rupElvisAR
 

Similar a OpenUP: Un método ágil para el desarrollo de software (20)

Metodología open up ágil y tradicional
Metodología open up ágil y tradicionalMetodología open up ágil y tradicional
Metodología open up ágil y tradicional
 
Ingenieria de Software (Openup)
Ingenieria de Software (Openup)Ingenieria de Software (Openup)
Ingenieria de Software (Openup)
 
ISO - OpenUp
ISO - OpenUpISO - OpenUp
ISO - OpenUp
 
ASD.pptx
ASD.pptxASD.pptx
ASD.pptx
 
Metodologias
MetodologiasMetodologias
Metodologias
 
Metodologia upen up
Metodologia upen upMetodologia upen up
Metodologia upen up
 
Proceso Unificado De Rational
Proceso Unificado De RationalProceso Unificado De Rational
Proceso Unificado De Rational
 
Documentacion rational
Documentacion rationalDocumentacion rational
Documentacion rational
 
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptxSEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
SEMANA 1-2-3- METODOLOGIAS TRADICIONALES [Autoguardado].pptx
 
4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational4.1 Proceso Unificado De Rational
4.1 Proceso Unificado De Rational
 
Metodologias de desarrollo
Metodologias de desarrolloMetodologias de desarrollo
Metodologias de desarrollo
 
Breve explicacion del Rup
Breve explicacion del RupBreve explicacion del Rup
Breve explicacion del Rup
 
Metodologías de desarrollo de software
Metodologías de desarrollo de softwareMetodologías de desarrollo de software
Metodologías de desarrollo de software
 
Las metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el PerúLas metodologías usadas en el Desarrollo de SW en el Perú
Las metodologías usadas en el Desarrollo de SW en el Perú
 
Desarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptx
Desarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptxDesarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptx
Desarrollo de Software Adaptativo Abdon Marquez Efren 8CV12.pptx
 
Methodologies in Software Development and IT
Methodologies in Software Development and ITMethodologies in Software Development and IT
Methodologies in Software Development and IT
 
Is.exp.329704
Is.exp.329704Is.exp.329704
Is.exp.329704
 
Wagneher franck mallma nuñez
Wagneher franck mallma nuñezWagneher franck mallma nuñez
Wagneher franck mallma nuñez
 
Wagneher franck mallma nuñez
Wagneher franck mallma nuñezWagneher franck mallma nuñez
Wagneher franck mallma nuñez
 
Metodologias rup
Metodologias rupMetodologias rup
Metodologias rup
 

OpenUP: Un método ágil para el desarrollo de software

  • 1. [ESCRIBA EL NOMBRE DE LA COMPAÑÍA] Open UP Ingenieria en Software Mario Esteban Machado Valenzuela RubenUrutia Contreras David Marquez Alvarado 19/02/2013
  • 2. ¿Qué es OpenUP? OpenUp es un método y un proceso de desarrollo de software propuesto por un conjunto de empresas de tecnología, quienes lo donaron en el año 2007 a la Fundación Eclipse. La fundación lo ha publicado bajo una licencia libre y lo mantiene como método de ejemplo dentro del proyecto Eclipse Process Framework. Descripción El OpenUP es un proceso mínimo y suficiente, lo que significa que solo el contenido fundamental y necesario es incluido. Por lo tanto no provee lineamientos para todos los elementos que se manejan en un proyecto pero tiene los componentes básicos que pueden servir de base a procesos específicos. La mayoría de los elementos de OpenUP están declarados para fomentar el intercambio de información entre los equipos de desarrollo y mantener un entendimiento compartido del proyecto, sus objetivos, alcance y avances. Principios del OpenUP Colaborar para sincronizar intereses y compartir conocimiento. Este principio promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la colaboración y desarrollan un conocimiento compartido del proyecto. Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el proyecto. Este principio promueve prácticas que permiten a los participantes de los proyectos desarrollar una solución que maximice los beneficios obtenidos por los participantes y que cumple con los requisitos y restricciones del proyecto. Centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo. Desarrollo evolutivo para obtener retroalimentación y mejoramiento continuo. Este principio promueve prácticas que permiten a los equipos de desarrollo obtener retroalimentación temprana y continua de los participantes del proyecto, permitiendo demostrarles incrementos progresivos en la funcionalidad.
  • 3. Organización de los componentes del OpenUP El OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas: el método y el proceso. El contenido del método es donde los elementos del método (roles, tareas, artefactos y lineamientos) son definidos, sin tener en cuenta como son utilizados en el ciclo de vida del proyecto. El proceso es donde los elementos del método son aplicados de forma ordenada en el tiempo. Muchos ciclos de vida para diferentes proyectos pueden ser creados a partir del mismo conjunto de elementos del método. Áreas de interés Los elementos del OpenUP dirigen la organización del trabajo en los niveles personal, de equipo y de interesados. A nivel personal, los integrantes de un proyecto contribuyen con su trabajo con pequeños incrementos en funcionalidad, denominados micro incrementos, los cuales representan los resultados obtenidos en pocas horas o pocos días de trabajo. La solución evoluciona basada en dichos micro incrementos de tal forma que el progreso puede ser visualizado efectivamente cada día. Los integrantes del equipo de desarrollo de forma abierta comparten su progreso diario el cual incrementa la visibilidad en el trabajo, la confianza y el trabajo en equipo. El proyecto en general se divide en iteraciones, las cuales son planificadas en un intervalo definido de tiempo que no superan las pocas semanas. El OpenUP tiene elementos que ayudan a los equipos de trabajo a enfocar los esfuerzos a través del ciclo de vida de cada iteración de tal forma que se puedan distribuir funcionalidades incrementales de una manera predecible, una versión totalmente probada y funcional al final de cada iteración. El OpenUP estructura el ciclo de vida de un proyecto en cuatro fases: concepción, elaboración, construcción y transición. El ciclo de vida del proyecto provee a los interesados un mecanismo de supervisión y dirección para controlar los fundamentos del proyecto, su ámbito, la exposición a los riesgos, el aumento de valor y otros aspectos. OpenUP/Basic OpenUP/Basic está diseñado para equipos pequeños, trabajando juntos en la misma localidad. El equipo tiene que participar plenamente en la interacción diaria de manera presencial. Los miembros del equipo participan en una colaboración significativa, tomando sus propias decisiones en cuanto a lo que se necesita trabajar, cuales son las prioridades, y la mejor manera de abordar las necesidades de los stakeholders.
  • 4. Los miembros del equipo colaboran ampliamente. La presencia de los stakeholders como miembros del equipo es crítica para realizar exitosamente OpenUP/Basic. Los miembros del equipo participan a diario en las reuniones stand-up para comunicar el estado y sus asuntos. Los problemas se abordan fuera de las reuniones diarias. OpenUP/Basic se enfoca en reducir significativamente el riesgo de manera temprana en el ciclo de vida. Esto requiere unas reuniones regulares de revisión de los riesgos y una implementación rigurosa de las estrategias de mitigación. Todo el trabajo será listado, seguido y asignado a través de la "lista de ítems de trabajo". Los miembros del equipo están en un único repositorio para todas las tareas que necesitan ser registradas y seguidas. Esto incluye todos los requerimientos de cambio, errores y requerimientos de los stakeholder. Los casos de uso son utilizados para obtener y describir los requisitos. Los miembros del equipo deben desarrollar habilidades para escribir buenos casos de uso. Los Stakeholders son responsables de revisar y certificar que los requerimientos son correctos. Los casos de uso son desarrollados de manera colaborativa. Los requisitos arquitectónicamente más importantes deben ser identificados y estabilizados dentro de la fase de Elaboración de tal forma que sea creada una arquitectura robusta, la cual es el corazón del sistema. Un cambio de un requisito arquitectónicamente significativo puede surgir posteriormente en el desarrollo, el cual debe ser abordado, pero el riesgo de que esto ocurra es reducido significativamente dentro de la iteración de Elaboración. Beneficios en el uso del OpenUP Ya que es apropiado para proyectos pequeños y de bajos recursos permite disminuir las probabilidades de fracaso en los proyectos pequeños e incrementar las probabilidades de éxito. Permite detectar errores tempranos a través de un ciclo iterativo. Evita la elaboración de documentación, diagramas e iteraciones innecesarios requeridos en la metodología RUP. Por ser una metodología ágil tiene un enfoque centrado al cliente y con iteraciones cortas.
  • 5. Ciclo de vida Cada fase consiste de una o más iteraciones, donde se trabaja por versiones estables del software que son desarrolladas y liberadas, el completar cada iteración representa un avance menos para el proyecto y una contribución al éxito arquitectónico del hito mayor de la Fase donde los objetivos de la fase son alcanzados.
  • 6. 1. Concepción Primera de las 4 fases en el proyecto del ciclo de vida, acerca del entendimiento del propósito y objetivos y obteniendo suficiente información para confirmar que el proyecto debe hacer. El objetivo de ésta fase es capturar las necesidades de los stakeholder en los objetivos del ciclo de vida para el proyecto. 2. Elaboración Es el segundo de las 4 fases del ciclo de vida del OpenUP donde se trata los riesgos significativos para la arquitectura. El propósito de esta fase es establecer la base la elaboración de la arquitectura del sistema. 3. Construcción Esta fase está enfocada al diseño, implementación y prueba de las funcionalidades para desarrollar un sistema completo. El propósito de esta fase es completar el desarrollo del sistema basado en la Arquitectura definida. 4. Transición Es la última fase, cuyo propósito es asegurar que el sistema es entregado a los usuarios, y evalúa la funcionalidad y performance del último entregable de la fase de construcción. El siguiente diagrama muestra el Ciclo de vida de OpenUP/Basic. Cada fase podrá tener tantas iteraciones como se requiera dependiendo del grado de novedad del dominio de negocio, de la tecnología a ser utilizada, de la complejidad de la arquitectura de la solución y del tamaño del proyecto, entre otros factores. Las iteraciones pueden tener duraciones variables dependiente de las características del proyecto. Iteraciones de un mes son las recomendables, ya que este periodo de tiempo proporciona:
  • 7. Una cantidad de tiempo razonable para que los proyectos entreguen incrementos considerables en funcionalidad. Retro alimentación temprana y frecuente por parte de los usuarios. Administración a tiempo de los riesgos y problemas encontrados durante el curso del proyecto. Roles Analista El analista es el que representa al cliente y el usuario final, se refiere a la obtención de requerimientos de los interesados, por medio de comprender el problema a resolver, capturando y creando las prioridades de los requerimientos Arquitecto El arquitecto es el responsable del diseño de arquitectura del software. Tomando las decisiones técnicas claves, las cuales limitaran el conjunto de diseño y la implementación del proyecto. Desarrollador Es quien tiene la responsabilidad del desarrollo de una parte del sistema o el sistema completo dependiendo de la magnitud del mismo, se encarga del diseño ajustándolo a la arquitectura y de la implementación de pruebas unitarias y de integración para los componentes desarrollados.
  • 8. Lider del proyecto Dirige la planificación del proyecto en colaboración con las partes interesadas y el equipo, coordina las interacciones de los interesados, manteniendo al equipo del proyecto enfocado en los objetivos del mismo Takeholder Representan al grupo que está interesado en el proyecto, quienes necesariamente deberán de ser satisfechos por el mismo. Este papel lo puede jugar cualquier persona que es afectada por los objetivos del proyecto. Tester Es el responsable de las actividades básicas y de realizar las pruebas, se encarga de la identificación, definición, implementación y conducción de las pruebas necesarias. Así como el ingreso de pruebas y el análisis de resultados.
  • 9. Otro rol Representa a cualquier otra persona en el equipo que puede realizar tareas generales. Conclusión El OpenUp es un proceso modelo y extensible, dirigido a gestión y desarrollo de proyectos de software basados en desarrollo iterativo, ágil e incremental apropiado para proyectos pequeños y de bajos recursos; y es aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo.
  • 10. Referencias: SÁBADO, 27 DE SEPTIEMBRE DE 2008. Gestión de Proyectos. Recuperado el16 DE FEBRERO DE 2013. (http://kasyles.blogspot.mx/2008/09/openup-como- alternativa-metodolgica.html). Diego García Arriaza,Mario Rivas Sánchez. 16 DE NOVIEMBRE DE 2010- wikiCE.Recuperado el 16 de Febrero de 2013.( http://osl2.uca.es/wikiCE/index.php/Open_Unified_Process).