Beruflich Dokumente
Kultur Dokumente
OAXACA
FUNDAMENTOS DE INGENIERA DE SOFTWARE
RUP
EQUIPO:
Grupo: ISA
Fecha: 2014 - Noviembre 04
ndice
1. PROCESO UNIFICADO DE RATIONAL
2.1.
2.2.
FASE DE INICIO
. . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1.
FASE DE ELABORACIN . . . . . . . . . . . . . . . . .
2.1.2.
FASE DE CONSTRUCCIN . . . . . . . . . . . . . . . .
2.1.3.
FASE DE TRANSICIN
. . . . . . . . . . . . . . . . . .
ITERACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.
ROLES
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.
ACTIVIDADES
. . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.3.
ARTEFACTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4.
FLUJOS DE TRABAJO . . . . . . . . . . . . . . . . . . . . . . .
12
4.2.
10
13
Esenciales: reglas del negocio, requisitos, diseo y analisis, implementacion, pruebas y distribucion . . . . . . . . . . . . . . . . . .
13
4.1.1.
. . . . . . . . . . . . . . . . . . . . . .
13
4.1.2.
Requerimientos o requisitos . . . . . . . . . . . . . . . . .
14
4.1.3.
Diseo y anlisis
. . . . . . . . . . . . . . . . . . . . . . .
14
4.1.4.
Implementacin
. . . . . . . . . . . . . . . . . . . . . . .
15
4.1.5.
Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.1.6.
Distribucin . . . . . . . . . . . . . . . . . . . . . . . . . .
16
17
4.2.1.
. . . . . . . . . . . . . . . .
17
4.2.2.
Administracin de cambios
. . . . . . . . . . . . . . . . .
17
4.2.3.
Ambiente
. . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5. HISTORIA
19
6. REFERENCIAS
20
1.
Balancear Prioridades:
cuales se les realizara el proyecto pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos
de todos.
nica persona sino mltiples equipos. Debe haber una comunicacin uida para
coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
de conceptos reutilizables tales como patrn del software, lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se pueden acompaar de las
representaciones visuales de la arquitectura, por ejemplo UML.
Enfocarse en la Calidad:
de mtodos giles. Una de las mayores ventajas del RUP es que tiene explcito
todo lo que se debe hacer dentro del proceso de desarrollo de software, a diferencia de muchos procesos que se encuentran en el mercado, tanto libres como
propietarios, que hablan slo de ciertas partes de las disciplinas de desarrollo.
Esta es la razn por la que algunas personas creen que el RUP es un proceso
pesado o slo para proyectos grandes. Realmente el RUP es explcito en lo que
hay que hacer en el desarrollo, y lo que se debe hacer es asignar adecuadamente
las tareas de acuerdo con el tamao del software y el equipo disponible.
2.
nueva generacin del producto. RUP divide un ciclo de desarrollo en cuatro fases
consecutivas, donde cada una tiene un objetivo especco. [1]
Fase de inicio.
Fase de elaboracin.
Fase de construccin.
Fase de transicin.
Cada fase termina con un punto lmite especco en el cual deben tomarse
decisiones crticas y alcanzarse los objetivos determinados.
2.1.
FASE DE INICIO
En esta fase se realiza una visin general del proyecto y se delimitan los
alcances del proyecto, para completar esta fase se deben identicar las entidades con las que interacta el sistema y los actores principales. De esta manera
se identican los casos de uso ms signicativos. La visin general incluye los
requisitos necesarios, la evaluacin de riesgos, un estimado de los recursos necesarios y una planeacin de las dems fases en la que se establecen los tiempos y
los puntos lmites.
Los resultados de la fase de inicio son:
Una visin general del proyecto que incluya los requisitos principales, funcionalidades clave y restricciones.
Un diagrama general de caso de uso.
Diagramas particulares de casos de uso crticos.
Un glosario general del proyecto.
Un pronstico nanciero de gastos y ganancias
Anlisis del mercado
El contexto.
Una evaluacin inicial de riesgos.
Un plan de trabajo, mostrando las fases y las iteraciones.
Es
2.1.1.
FASE DE ELABORACIN
Esta fase tiene el objetivo de lograr una visin general, completa y funcional
del proyecto, si bien no a profundidad, s abarcando ampliamente los requisitos
para preveer los problemas que puedan presentarse. Es una fase crtica, de vital
importancia porque en ella se determina la viabilidad de la continuacin del
proyecto, el replanteamiento del mismo o la denitiva cancelacin. Esta etapa
debe arrojar un prototipo (o varios elaborados cclicamente) funcional que pueda servir de demostracin para el usuario nal, posibles inversionistas o clientes.
Est claro que el diseo tiene una gran importancia aqu, pues estableceremos
la arquitectura base del sistema, tal arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluacin del
riesgo. Podra decirse que esta etapa es difcil, pues requiere anlisis de riesgos.
Las decisiones aqu deben ser estables, ya que sern parte de la construccin,
tambin se deben minimizar los riesgos previstos en la etapa de inicio, aparte
que todos los casos de uso deben ser identicados as como la interacciones del
sistema.
El resultado de esta fase debe ser:
2.1.2.
FASE DE CONSTRUCCIN
2.1.3.
FASE DE TRANSICIN
2.2.
ITERACIONES
En RUP cada fase se divide en iteraciones. Cada iteracin es un ciclo completo de desarrollo de software cuyo resultado es una versin, ya sea interna o
externa, del sistema. Con cada una de ellas la complejidad del sistema se va
incrementando y alcanzando su funcionalidad completa.[2]
3.
RUP dene cuatro elementos los roles, que responden a la pregunta Quin?, las
actividades que responden a la pregunta Cmo?, los productos, que responden
a la pregunta Qu? y los ujos de trabajo de las disciplinas que responde a la
pregunta Cundo?.
3.1.
ROLES
10
Analista de sistema.
Especicador de requisitos.
Desarrolladores:
Arquitecto de software.
Diseador
Diseador de interfaz de usuario
Diseador de cpsulas.
Diseador de base de datos.
Implementador.
Integrador.
Gestores:
Jefe de proyecto
Jefe de control de cambios.
Jefe de conguracin.
Jefe de pruebas
Jefe de despliegue
Ingeniero de procesos
Revisor de gestin del proyecto
Gestor de pruebas.
Apoyo:
Documentador tcnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista grco
Especialista en pruebas:
Otros roles:
3.2.
Revisor
Coordinacin de revisiones
Revisor tcnico
Cualquier rol
ACTIVIDADES
Una actividad en concreto es una unidad de trabajo que una persona que
desempee un rol puede ser solicitado a que realice. Las actividades tienen un
11
3.3.
ARTEFACTOS
Un producto o artefacto es un trozo de informacin que es producido, modicado o usado durante el proceso de desarrollo de software. Los productos son
los resultados tangibles del proyecto, las cosas que va creando y usando hasta
obtener el producto nal.
Un artefacto puede ser cualquiera de los siguientes:
3.4.
FLUJOS DE TRABAJO
administracin de proyecto
administracin de cambios
ambiente o entorno
12
4.
4.1.
4.1.1.
Prcticamente hay que documentar todos los casos del negocio, tales casos
son analizados pues es difcil entenderse con los clientes [2], ya que al no
ser desarrolladores de software no hablamos el mismo idioma y eso conlleva a
confusiones.
Con este ujo de trabajo pretendemos llegar a un mejor entendimiento de
la organizacin donde se va a implantar el producto.
Los objetivos del modelado de negocio son:
13
4.1.2.
Requerimientos o requisitos
Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos
de Uso. Los requisitos no funcionales representan aquellos atributos que debe
exhibir el sistema, pero que no son una funcionalidad especca. Por ejemplo
requisitos de facilidad de uso, abilidad, eciencia, portabilidad, etc.
4.1.3.
Diseo y anlisis
Hay muchas formas de llevar esta parte, lo ideal es usar UML para establecer
las bases, pues el diseo entra mucho en la etapa de elaboracin. As, podemos
disear una buena arquitectura que tendr el software y llevarla despus a la
implementacin.
Los objetivos del anlisis y diseo son:
14
El anlisis consiste en obtener una visin del sistema que se preocupa de ver
qu hace, de modo que slo se interesa por los requisitos funcionales. Por otro
lado el diseo es un renamiento del anlisis que tiene en cuenta los requisitos no
funcionales, en denitiva cmo cumple el sistema sus objetivos. Pero el resultado
nal ms importante de este ujo de trabajo ser el modelo de diseo. Consiste
en colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas.
4.1.4.
Implementacin
4.1.5.
Pruebas
El propsito aqu es la revisin del software, debe tener una correcta integracin, no que sea el clsico cdigo espagueti, hay que identicar posibles defectos
y las mejoras que podran caber antes de distribuirlo.
Este ujo de trabajo es el encargado de evaluar la calidad del producto que
estamos desarrollando, pero no para aceptar o rechazar el producto al nal del
proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validacin de los supuestos realizados en el diseo y especicacin
de requisitos por medio de demostraciones concretas.
15
4.1.6.
Distribucin
Tal como en la cuarta etapa el usuario nal nos dar retroalimentacin para
pulir nuestro programa, adems, aqu se trata como llegar nuestro software
al usuario nal, en caso de ser software a la medida, pues no habr mucho
problema, sencillamente podemos grabarlo en un CD-ROM, pero en caso se
ser software empaquetado podemos distribuirlo por internet. Tambin hay que
incluir ayuda al usuario nal. El objetivo de este ujo de trabajo es producir con
xito distribuciones del producto y distribuirlo a los usuarios. Las actividades
implicadas incluyen:
Este ujo de trabajo se desarrolla con mayor intensidad en la fase de transicin, ya que el propsito del ujo es asegurar una aceptacin y adaptacin sin
complicaciones del software por parte de los usuarios. Su ejecucin inicia en fases
anteriores, para preparar el camino, sobre todo con actividades de planicacin,
en la elaboracin del manual de usuario y tutoriales.
16
4.2.
4.2.1.
Un software siempre requiere de mantenimiento, es por eso que la retroalimentacin del usuario nal es importante, pues nos dar una visin para libe
-rar y/o desarrollar una nueva versin, quitar elementos innecesarios o agregar
nuevas funciones.
4.2.2.
Administracin de cambios
Es la forma en que se valoran las modicaciones al proyecto planteado inicialmente y se ajustan los tiempos, costos y las funcionalidades en algunos casos,
busca optimizar.
La Gestin del proyecto es el arte de lograr un balance al gestionar objetivos, riesgos y restricciones para desarrollar un producto que sea acorde a los
requisitos de los clientes y los usuarios.
Los objetivos de este ujo de trabajo son:
intensivos.
monitorear el proyecto.
4.2.3.
Ambiente
Esta parte provee elementos necesarios para que quien use nuestro software
se sienta conectado con l. La nalidad de este ujo de trabajo es dar soporte
al proyecto con las adecuadas herramientas, procesos y mtodos. Brinda una
especicacin de las herramientas que se van a necesitar en cada momento, as
como denir la instancia concreta del proceso que se va a seguir.
En concreto las responsabilidades de este ujo de trabajo incluyen:
Seleccin y adquisicin de herramientas
Establecer y congurar las herramientas para que se ajusten a la organizacin.
Conguracin del proceso.
17
El principal artefacto que se usa en este ujo de trabajo es el caso de desarrollo que especca para el proyecto actual en concreto, como se aplicar el
proceso, que productos se van a utilizar y cmo van a ser utilizados. Adems se
tendrn que denir las guas para los distintos aspectos del proceso, como pueden ser el modelado del negocio y los Casos de Uso, para la interfaz de usuario,
el diseo, la programacin, el manual de usuario.
18
5.
HISTORIA
La metodologa RUP fue creado por Grady Booch, Ivan Jacobson y James
Jacobson.
Su predecesor fue el mtodo Ericsson implementado en 1967 el cual utilizaba
la compaa del mismo nombre para la creacin de sus productos, e introduca
el empleo de caso de uso. Despus se complement con la tcnica de modelado
de objetos de James Jacobson.
En 1995 la metodologa RUP se complementa con el enfoque de RATIONAL
SOFTWARE su empresa creadora; permitiendo el lanzamiento de la versin 4
de RUP y optando por UML como el lenguaje de modelado ocial.
En 1996 se agregan a RUP las actividades SQA (Software de control de
calidad) lo que permite al mtodo la produccin de software de calidad sin
importar los objetivos buscados por el cliente, adaptndose a sus necesidades.
En 1998 se lanza al mercado una fase de prueba del modelo RUP optimizado
con los enfoques de la ingeniera de negocios y la ingeniera de datos.
En 1999 se lanza la versin denitiva de lo que conocemos como RUP en la
actualidad.
19
6.
[1]
REFERENCIAS
Rational, Best Practices for software development teams- IBM, pp.
4-7. [fecha de consulta 26 de Septiembre de 2014]. Disponible en:
<https://www.ibm.com/ developerworks /rational /library/ content/
03July/ 1000/ 1251/ 1251_bestpractices_TP026B.pdf>
[2]
[3]
http://softwarerecopilation.wordpress.com/modelo-rup/ consultada
26 de septiembre 2014
[4]
[5]
Belloso Cecilia, Claudia Ivonne. Trabajo de graduacin para optar al grado de ingeniero en ciencias de la computacin [en linea].
UNIVERSIDAD DON BOSCO.2009 [fecha de consulta: 26 septiembre 2014]. Disponible en: <http:// rd.udb.edu.sv:8080/ jspui/ bitstream/ 123456789/ 257/ 1/ 47400_tesis.pdf >
20