top of page
1- Nombre de la metodología: Proceso unificado de desarrollo de software

2- Link fuente o matriz de la misma

3- Descripción somera de la metodología

El proceso unificado de Desarrollo de Software (PUD) fue creado por Jacobson, Booch y Rumbaugh.

​

El PUD es un proceso evolutivo y se desarrolla a través de una serie de ciclos que constituyen la vida de un sistema y se concluyen con una versión del producto, desde su inicio hasta su muerte.

​

Es un proceso orientado a objetos guiado por casos de uso, centrado en la arquitectura con un ciclo de vida iterativo e incremental. Basado en el leguaje unificado modelado(UML).

​

Este proceso puede organizarse en cuatro fases: inicio, elaboración, construcción y transición.

​

Las fases se dividen en sus conjuntos de iteraciones, en las que se desarrollan los flujos de trabajo: requerimientos, análisis, diseño, complementación y pruebas.

​

4- creadores

El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh

 

Conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado .

​

​

Características:

​

Iterativo e Incremental

​

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición.

 

Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes).

 

Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.

​

Dirigido por los casos de uso

​

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones.

 

La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas.

​

Centrado en la arquitectura

​

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema.

 

Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema.

​

Enfocado en los riesgos

​

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida.

 

Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

5- Etapas que cubre

Es un proceso que cubre la etapa de desarrollo en la ingeniería del software: “conjunto de  actividades necesarias para transformar los requisitos del usuario en un  sistema software”.

 

PUDS se basa en los siguientes principios de desarrollo:

 

–Desarrollo Iterativo del Software,

–Administración de Requerimientos,

–Uso de Arquitecturas Basadas en Componentes,

–Modelado Visual del Software,

–Verificación de la Calidad del Software,

–Control de Cambios.

 

 

Desarrollo Iterativo del software:

 

El software moderno es complejo y novedoso, así que no es realista usar un modelo lineal de desarrollo como el de cascada.

 

Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema.

 

PUD sigue un modelo iterativo que aborda las tareas más arriesgadas primero.

 

Así se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.

 

Administración de Requerimientos:

 

PUD describe cómo:

–obtener los requerimientos,

–organizarlos,

–documentar requerimientos de funcionalidad y restricciones,

–rastrear y documentar decisiones,

–captar y comunicar requerimientos del negocio,

–Detectar más fácilmente las inconsistencias.

 

Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas.

 

Uso de Arquitecturas Basadas en Componentes:

 

 El proceso se basa en diseñar tempranamente una arquitectura base ejecutable.

 

La arquitectura debe ser:

​

–flexible,

–fácil de modificar,

–intuitivamente comprensible,

–promueve la reutilización de componentes.

 

Apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.

 

Componente: un elemento del software con función y límites claros.

 

Modelado Visual del Software:

 

Modelado visual de la estructura y el comportamiento de la arquitectura y los componentes.

 

Las herramientas de modelado visual permiten:

–ocultar detalles,

–la comunicación en el equipo de desarrollo,

–analizar la consistencia:

                •entre las componentes,

                •entre diseño e implementación.

 

UML es la base del modelado visual del PUD.

 

 

Verificación de Calidad del software:

 

No sólo la funcionalidad es esencial, también el rendimiento y la confiabilidad.

 

PUD ayuda a planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades.

 

La prueba es vital para detectar errores antes de la implementación.

 

El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.

 

 

Control de Cambios:

 

El control es esencial en el desarrollo de software para evitar caos.

 

Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y investigar su impacto.

 

PUD indica cómo controlar, investigar y monitorizar los cambios dentro del proceso iterativo de desarrollo.

6- Clasificación de  la metodología

En las metodologías de tipo PUD se clasifican como un ciclo de vida iterativo e incremental.

​

Esto se repite a lo largo del tiempo donde tras cada ciclo de vida se obtiene una versión nueva  del producto dividiéndose en fases, donde cada fase se divide en iteraciones y en cada iteración se realizan flujos de trabajo.

​

Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes más pequeñas o mini proyectos.

 

Beneficios del enfoque iterativo

​

  •  Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo.

​

  •  Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse completamente al principio.

​

  • Reduce el riesgo de retrasos en el calendario atacando los riesgos más importantes primero.

​

  • La iteración controlada reduce el riesgo a los costes de un solo incremento (Se puede perder solo lo realizado en esa iteración).

 

Su objetivo está centrado principalmente en el Conjunto  de actividades necesarias para transformar los requisitos de un cliente en un conjunto consistente de artefactos que representan un producto software y en punto posterior en el tiempo para transformar cambios en dichos requisitos en nuevas versiones del producto.

​

​

​

7- objetivos

Centrado principalmente en el Conjunto  de actividades necesarias para transformar los requisitos de un cliente en un conjunto consistente de artefactos que representan un producto software y en punto posterior en el tiempo para transformar cambios en dichos requisitos en nuevas versiones del producto.

​

8- Etapas, fases y/o procesos  que propone la misma

Cada ciclo constas de cuatro fases: Inicio, Elaboración, Construcción, y Transición

​

  1. Fase de Inicio: Primera fase del ciclo de vida del software, en la que la idea inicial para el desarrollo es refinada hasta el punto de quedar lo suficientemente bien establecida como para garantizar la entrada en la base de elaboración.

​

​

  •    -DESCRIBIR PRODUCTO FINAL / ANÁLISIS DEL NEGOCIO

  •    -IDENTIFICAR RIESGOS MÁS IMPORTANTES

  •    -ESTABLECER PLANIFICACIÓN INICIAL DEL PROYECTO

  •    -DECIDIR SI SE CONTINÚA

​

​

  1. Fase de Elaboración: Segunda fase del ciclo de vida, en la que se define la arquitectura.

 

  1. Fase de Construcción: Tercera fase del ciclo de vida del software, en la que el software es desarrollado a partir de una línea base de la arquitectura ejecutable, hasta el punto en el que se está listo para ser transmitido a las comunidades de usuarios.

 

  1. Fase de Transición: Cuarta fase del ciclo de vida del software es puesto en manos de la comunidad de usuarios.

 

 

ITERACIONES:

​

CADA FASE SE DIVIDE EN ITERACIONES, CADA ITERACIÓN  ES UN MINIPROYECTO (EN CASCADA) QUE EJECUTA FLUJOS DE TRABAJO yPRODUCE UN INCREMENTO EN PRODUCTOTAL Y COMO ESTABA.

​

FLUJOS DE TRABAJO:

​

1-Requisitos: 

 

Flujo de trabajo fundamental cuyo propósito esencial es orientado al desarrollado hacia el sistema correcto.

 

Esto se lleva a cabo mediante la descripción de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre el cliente (incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que no.

 

            a) IDENTIFICAR REQUISITOS DEL SISTEMA


            b) CONSTRUIR UN MODELO DEL MISMO

​

                i) MODELO DE CASOS DE USO


                ii) MODELO DEL DOMINIO (o NEGOCIO)

          

 

2- Análisis: 

 

Flujos de trabajo fundamental cuyo propósito principal es analizar los requisitos descriptos en la captura de requisitos, mediante su refinamiento y estructuración.

 

El objetivo de esto es (1) lograr una comprensión más precisa de los requisitos, y (2) obtener una descripción de los requisitos que sea fácil de mantener y que nos ayude a dar estructura al sistema en su conjunto incluyendo su arquitectura.

​

          a) ESPECIFICAR REQUISITOS

​

          b) CONSTRUIR MODELO DEL ANÁLISIS

 

3- Diseño: 

 

Flujo de trabajo fundamental cuyo propósito principal es la de formular modelos que se centran en los requisitos no funcionales y el dominio de la solución y que prepara para la implementación y pruebas del sistema.

​

           a) ENCONTRAR LA FORMA DEL SISTEMA (SOLUCIÓN)

​

           b) CONSTRUIR MODELO DEL DISEÑO

​

4- Implementación: 

​

Flujo de trabajo fundamental cuyo propósito esencial es implementar el sistema en términos de componentes, es decir código fuente guiones, ficheros binarios, ejecutables, etc.

​

           a) CODIFICAR EL DISEÑO (SOLUCIÓN)

​

           b) CONSTRUIR MODELO DE IMPLEMENTACIÓN

 

5- Prueba: 

 

Flujo de trabajo fundamental cuyo propósito esencial es comprobar el resultado de la implementación mediante las pruebas de cada construcción, incluyendo tanto construcciones internas como intermedias, así como las versiones finales del sistema que van a ser entregadas a terceras personas.

​

           a) VERIFICAR LA IMPLEMENTACIÓN

​

           bCONSTRUIR MODELO DE PRUEBAS

​

​

9- Roles y/o intervinientes

Flujo de trabajo


Un flujo de trabajo describe la secuencia en que se realizan las actividades en una
disciplina, quienes la realizan (trabajadores) y que artefactos producen.


Trabajador (Rol)


Un trabajador o rol, define un comportamiento o responsabilidades de un individuo o
grupo de individuos trabajando en equipo, en el contexto de una organización de
ingeniería de software.

​

Actividad


Los trabajadores realizan actividades. Una actividad es algo que realiza un trabajador
para proveer un resultado de valor en el contexto de un proyecto.


Pasos (steps)


Las actividades son descompuestas en pasos. Podemos distinguir tres categorías de
pasos:


         · Pasos de análisis: donde el trabajador comprende la naturaleza de la tarea,
           examina los artefactos de entrada, y formula las salidas.
         · Pasos de acción: donde los trabajadores crean o actualizan algunos artefactos.
         · Pasos de revisión: donde los trabajadores inspeccionan los resultados según
           determinados criterios.


Artefactos


Las actividades tienen artefactos de entrada y de salida. Un artefacto es un producto
de trabajo en un proceso:

 

los trabajadores utilizan artefactos para realizar actividades y producen artefactos como resultado de sus actividades.

 

Los artefactos son responsabilidad de un único trabajador y promueven la idea de que toda pieza de información en el proceso debe ser responsabilidad de un rol específico.

​

Un trabajador es el “propietario” de un artefacto, pero otros trabajadores pueden usarlo y tal vez modificarlo si tienen permiso para ello.

​

​

TRABAJADORES, según la actividad que realizan

​

Requisitos
Análisis
Diseño
Implementación
Pruebas
10- Ventajas y Desventajas

 

 

 

Beneficios del enfoque iterativo.

​

  • La iteración controlada reduce el riesgo a los costes de un solo incremento.

​

  • Reduce el riesgo de retrasos en el calendario atacando los riesgos más importantes primero.

​

  • Acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo.

​

  • Tiene un enfoque más realista al reconocer que los requisitos no pueden definirse completamente al principio.

​

Fortalezas:

​

  • Rumbaugh: método fuerte para producción modelos de dominio,

​

  • Jacobson: método fuerte para producción orientada al usuario,

​

  • Booch: método fuerte para producción detallada modelos de diseño orientados a objetos,

​

Debilidades:

​

  • Rumbaugh: Simplista para el espacio de soluciones posibles,

​

  • Jacobson: No trata detalladamente el diseño orientado a objetos al nivel de Booch,

​

  • Booch: Se centra en el diseño y no en el análisis.

​

​

​

​

11- Herramientas (software) que soportan dicha metodología.

Enterprise Architect - Herramienta de diseño UML

Brindando herramientas de modelado avanzadas de UML 2.1 para todo el equipo.

​

Existen dos versiones de esta herramienta una demo "gratis" y la completa "versión paga".

​

Enterprise Architect combina el poder de la última especificación UML 2.1 con alto rendimiento, interfaz intuitiva, para traer modelado avanzado al escritorio, y para el equipo completo de desarrollo e implementación.

 

Con un gran conjunto de características y un valor sin igual para el dinero, EA puede equipar a su equipo entero, incluyendo analistas, evaluadores, administradores de proyectos, personal del control de calidad, equipo de desarrollo y más, por una fracción del costo de algunos productos competitivos.

​

Alta capacidad 

​

Enterprise Architect es una herramientas comprensible de diseño y análisis UML, cubriendo el desarrollo de software desde el paso de los requerimientos a través de las etapas del análisis, modelos de diseño, pruebas y mantenimiento.

 

EA es una herramienta multi-usuario, basada en Windows, diseñada para ayudar a construir software robusto y fácil de mantener. Ofrece salida de documentación flexible y de alta calidad. El manual de usuario está disponible en línea.

​

Velocidad, estabilidad y buen rendimiento 


El Lenguaje Unificado de Modelado provee beneficios significativos para ayudar a construir modelos de sistemas de software rigurosos y donde es posible mantener la trazabilidad de manera consistente.

 

Enterprise Architect soporta este proceso en un ambiente fácil de usar, rápido y flexible. Para una mirada rápida al modelado UML en Enterprise Architect vea nuestro tutorial UML  y documentos.

​

Construido sobre las bases de UML 2.1 


Las bases de Enterprise Architect están construidas sobre la especificación de UML 2.0 - pero no se detiene ahí! Usa Perfiles UML para extender el dominio de modelado, mientras que la Validación del Modelo asegura integridad. Combina Procesos de Negocio, Información y Flujos de trabajo en un modelo usando nuestras extensiones gratuitas para BPMN y el perfil Eriksson-Penker.

​

Soporte para los 13 diagramas de UML 2

​

UML es un lenguaje de modelado estándar de la industria con una rica notación gráfica, y un extenso conjunto de diagramas y elementos. Una herramienta de modelado UML amplia como Enterprise Architect es la forma ideal de tomar control de su software o proyecto de negocio.

​

Con Enterprise Architect y UML puede:

​

​

  • Administrar la complejidad del proyecto.

​

  • Realizar ingeniería reversa de código legacy y esquema de base de datos.

​

  • Producir reportes de gran apariencia.

​

  • Rastrear cambios.

​

  • Involucrar a todo el equipo.

​

UML 2 defines 13 diagramas (todos soportados por Enterprise Architect)

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Diagrama de clases
Diagrama de despliegue
State Chart
Prueba

El lenguaje unificado de modelado (UML) apareció primero en 1990 como un esfuerzo para seleccionar los mejores elementos de los sistemas de modelado propuestos en ese tiempo, y combinarlos en una sola notación coherente. Desde entonces se ha convertido en el estándar de la industria para el diseño y modelado de software., así como también el modelado de otros procesos en el mundo de los negocios y la ciencia. Enterprise Architect soporta la último UML 2.1 estándar, como ha sido definido por el OMG. Esto le proporciona acceso a los 13 tipos de diagramas, las Tecnologías MDA,y un generador de documentación amplio, para ayudarlo a comunicarse y compartir sus modelos eficientemente.

​

El UML es una herramienta para especificar los sistemas de software. Los tipos de diagramas estandarizados para ayudarlo a describir y mapear visualmente la estructura y diseño del sistema de software. Usando UML, es posible modelar casi cualquier tipo de aplicación, tanto específica e independientemente de una plataforma de salida. Aunque UML está naturalmente orientado hacia los programas orientados a objetos, es tan fácil como modelar lenguajes de procedimientos como C, Visual Basic, Fortran etc.

​

El uso de UML como una herramienta para definir la estructura de un sistema es una forma útil de administrar sistemas complejos y grandes. Tener una estructura claramente visible hace fácil introducir nuevas personas a un proyecto existente.

​

Construir librerías de Patrones UML simplifica volver a usar modelos y códigos. Los Patrones UML son grupos de objetos/clases que colaboran y que pueden ser abstraídos de escenarios de modelado general. Mientras que los patrones se descubren en un nuevo proyecto, las plantillas de los patrones se pueden volver a usar y modificar por el diseñador para ajustarse al nuevo proyecto. Los Perfiles UML son extensiones personalizadas en UML que lo ajustan a tareas de modelado específicas, por ejemplo Sparx Systems tiene disponible perfiles UML para modelar Procesos de negocios, procesos Web, esquemas XSD, y más.

​

​


12. Planteo y presentación de un ejercicio práctico sencillo

Caso de uso “Sacar dinero”
Flujo de eventos


CAMINOS ALTERNATIVOS


• Línea 5: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación.


• Línea 5: La cantidad solicitada supera el límite diario. Se indica el error y se vuelve a pedir otra cantidad.


• Línea 5: En el cajero no hay dinero.

Podríamos definir diagramas de estados


Requisito no funcional asociado al caso de uso Sacar dinero:


El tiempo de respuesta para un cliente debe ser <30 sg en el 90% de los casos

​

​

13- Citación de empresas que las utilizan. Link.

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

​

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

​

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

​

Una de las empresas que utiliza PUD es IBM, a continuación el link:

​

​

​

14- Conclusión del grupo

En resumidas cuentas, podemos decir que el Proceso Unificado es un importante marco de referencia en Ingeniería de Software con el que definir, implementar y distribuir aplicaciones de software.

Presenta un modelo dividido en 4 fases:

​

  • Concepcion: Sobretodo define el alcance del proyecto

​

  • Elaboración: Especificación formal, análisis y diseño

​

  • Construcción: Implementación

​

  • Transición: Cierre del proyecto y paso a producción

​

Las ventajas de este modelo son la reducción de riesgos en el proyecto, la garantía de calidad, y la integración entre lo que es propiamente desarrollo con mantenimiento de software (a base de ir iterando en cada fase, combinando actividades de uno y otro tipo).

​

Como desventajas, podemos señalar que requiere una gran previsión sobre lo que va a ocurrir (para poder controlarlo) y que genera abundante trabajo adicional (y costes asociados) de documentación y comunicación, con lo que no suele resultar práctico para proyectos pequeños.

 

Bibliografía

​

“El proceso unificado de desarrollo de software”. Ivar Jacobson, Grady Booch y James Rumbaugh. Ed. Addison Wesley

​

“El lenguaje Unificado de Modelado” Ivar Jacobson, Grady Booch y James Rumbaugh. Ed. Addison Wesley

​

“Modelado y diseño orientado a objetos”. James Rumbaugh y otros. Ed. Prentice-Hall

​

https://es.wikiversity.org/wiki/Proceso_Unificado_de_Desarrollo

​

https://es.wikipedia.org/wiki/Proceso_unificado

​

http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase8.pdf

​

​

​

​

​

SOCIALS 

SUBSCRIBE 

I'm a paragraph. Click here to add your own text and edit me. It’s easy.

© 2023 by FEEDs & GRIDs. Proudly created with Wix.com

ABOUT FEEDs & GRIDs

I'm a paragraph. Click here to add your own text and edit me. It’s easy. Just click “Edit Text” or double click me to add your own content and make changes to the font. I’m a great place for you to tell a story and let your users know a little more about you.

bottom of page