Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 1 de 1

Introduccin al PUDS(Proceso unificado de desarrollo de software)

Orientacin del aprendizaje
En nuestros das, dada la importancia de la informacin como recurso estratgico que ayuda a
generar ventajas competitivas para las empresas, se tiende a construir sistemas cada vez ms
grandes y complejos donde intervienen equipos de trabajo formados por numerosas personas
con distintas funciones y roles.
Tal situacin nos lleva a definir mecanismos que nos ayuden a administrar esos grandes
proyectos: programar las actividades en tiempo y forma, coordinar las actividades de cada
integrante del equipo y entre ellos, y ofrecer criterios para permitir un control y medicin de
estas actividades.
Un alto porcentaje de los sistemas fracasan por no contar con un adecuado proceso de
desarrollo, o por su utilizacin inapropiada. Muchos desarrolladores se equivocan porque
piensan que el desarrollo de software comienza con la programacin en un lenguaje
determinado, y ah caen en una de las causantes ms importantes de fracaso del sistema.
Sea cual fuese el tamao del sistema, es necesario que siempre nos apoyemos en un proceso
de anlisis y diseo como el que vemos a lo largo de la materia.
Esta unidad nos servir de introduccin al proceso de desarrollo de software que explotamos en
el resto de las unidades, vemos sus pilares y los principales conceptos en los que se apoya.

Los contenidos que trabajamos en esta unidad son:

1. Ingeniera del software
1.1 Qu es el ciclo de vida?
1.2 Aspectos del proceso de desarrollo
1.3 Tipos de modelo de ciclo de vida
1.4 Rol del cliente
2. Metodologa de desarrollo
3. El proceso unificado de desarrollo de software
3.1 PUDS dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental.
3.2 Fases y flujos de trabajo
4. Las cuatro P en el desarrollo del software
5. UML: lenguaje unificado de modelado
5.1 Modelos
5.2 Bloques bsicos de construccin de UML
El siguiente esquema conceptual le presenta los ejes temticos fundamentales y sus
relaciones, y a modo anticipatorio lo orienta y ayuda a la contextualizar cada uno de los
conceptos desarrollados.

Esquema conceptual

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 2 de 2

Bibliografa propuesta
JACOBSON, Ivar. El Proceso Unificado de Desarrollo. Editorial Addison Wesley. Espaa. 2000.
Captulos 1, 2, 3, 4, 5.
Bibliografa complementaria
DRUKER, Peter. Management: Tasks, Responsibilities, Practices. Editorial Harper & Row. New
York. 1973 .
JACOBSON, Ivar y otros. Object Oriented Software Engineering: A Use Case Driven Approach.
Editorial Addison Wesley. 1992.
KENDALL, Keneth E y KENDALL, Julie E. Anlisis y Diseo de Sistemas. Tercera Edicin.
Editorial Prentice Hall Hispanoamericana S.A. Mxico. 1997.
LARMAN, Craig. UML y Patrones. Primera Edicin. Editorial Prentice Hall, Inc. Mxico. 1999.
MC. MENAMIN, Steve y PALMER, John.. Essential Systems Analysis. Editorial Prentice Hall,
Yourdon Press. 1984.
1. Ingeniera del software
Cuando una empresa se plantea la construccin de un nuevo software aparecen en la cabeza
del lder del proyecto distintas consideraciones a tener en cuenta que sern crticas, pues de
stas depender el xito o el fracaso del proyecto de desarrollo:
construir un software que cumpla con los requisitos previos planteados,
construir un software que haga correctamente lo que se pidi,

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 3 de 3

lograr un software que pueda adaptarse a los continuos cambios de toda

organizacin actual,
cumplir con los tiempos pactados de finalizacin del proyecto,
respetar los costos estimados en principio.
No tener sto en mente desde un principio y no darle la importancia que
merece nos puede ocasionar innumerables conflictos en las distintas etapas del
desarrollo.
Cules son las causas que habitualmente generan este tipo de conflictos?
No hay tiempo de recoger datos histricos.
Los proyectos se llevan a cabo con descripciones vagas y con poca
comunicacin con los usuarios finales. De esta forma no se recogen realmente
las necesidades de
los mismos.
Muchas veces slo se analizan las necesidades de los usuarios finales, cayendo
as en sus vicios, y de esta forma nos desviamos del objetivo final de lograr
un software que cumpla con las necesidades de la organizacin.
Hay escaso tiempo y recursos dedicados a analizar los requerimientos y
necesidades, y a documentar las mismas para utilizarlas como gua a lo largo
de todo el proceso de desarrollo del software.
No se utiliza una metodologa de desarrollo adecuada que nos permita lograr
una aplicacin que en el futuro sea adaptable a los cambios y nuevas
necesidades organizacionales.
Hay veces que para adaptarse a los tiempos que se exigen para la entrega de
una solucin no se utiliza ninguna metodologa de desarrollo y se arranca
directamente con la programacin de la aplicacin.
Existe la dificultad que afrontan los desarrolladores para coordinar las mltiples
cadenas de trabajo de un gran proyecto de software.
La solucin de software obtenida posee una calidad cuestionable, funciona sin
importar si lo hace de la mejor manera, y no posee una definicin de
estndares de calidad, lo cual nos lleva a un software difcil de mantener.
Ahora veremos de qu forma nos podemos asegurar el logro de una solucin que no caiga en
todos estos problemas anteriores. Para eso veremos en primera instancia el significado de la
Ingeniera del Software, que va a ser nuestro salvavidas para no caer en todos estos errores
irreversibles mencionados.
La Ingeniera del Software es la aplicacin de principios cientficos al diseo, construccin y
mantenimiento del software.
Cules son los principios cientficos en los que se basa la ingeniera del software? De no existir
los principios cientficos la actividad de desarrollar software estara ms cerca a la artesana que
a la ingeniera, puesto que lo artesanal es en general algo nico y su utilidad depende de la
habilidad del artesano.
En qu ciencia se basa la actividad de construir software?
La necesidad de dar respuesta a esta pregunta se relaciona con que se pretende producir
software como producto industrial.
Necesidad: producir software como objeto ingenieril, con caractersticas finales de confiabilidad
y de reproducibilidad de los procedimientos utilizados para el desarrollo. Se pretende la
existencia de un proceso de desarrollo de software que nos permita cubrir la necesidad
planteada.

1.1 Qu es el ciclo de vida?

El trmino ciclo de vida se refiere a la idea de que un producto de software es el resultado de
un proceso de desarrollo que se divide en fases.
Podemos definir el trmino ciclo de vida como la actividad de producir y mantener Sistemas
Informticos.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 4 de 4

Sus funciones son las siguientes:

1- establecer un orden en el que se:
especifica
realiza un prototipo
disea
implementa
prueba
mantiene
2- determinar los criterios para pasar de una fase a otra.
El ciclo de vida est de acuerdo con la metodologa que se utilice. Hay metodologas en donde
el ciclo de vida tiene un comienzo, se pasa por las distintas etapas antes mencionadas y llega a
un fin.
En otras metodologas el ciclo de vida esta formado por diversas iteraciones, cada una recorre
todas las etapas y se van logrando versiones intermedias del producto. Luego se sigue con otra
iteracin que pasa nuevamente por todas las etapas y se sigue as avanzando hasta que se
logra el producto completo finalizado. En la definicin del plan del proyecto el modelo de ciclo
de vida seleccionado influye en el xito del proyecto como cualquier otra decisin de
planificacin que se tome.
El modelo de ciclo de vida puede orientar su proyecto y ayudarlo a asegurar que cada paso se
acerca ms a la consecucin del objetivo. Dependiendo del ciclo de vida que se seleccione se
puede:
Aumentar la velocidad del desarrollo
Mejorar la calidad
Mejorar el control
Mejorar el seguimiento del proyecto
Minimizar gastos
Minimizar riesgos
Mejorar las relaciones con el cliente
1.2 Aspectos del proceso de desarrollo
Para llevar a cabo un proceso de desarrollo necesitamos:
Modelo de proceso (ciclo de vida)
Orden de las fases en el desarrollo de software
Criterios de transicin entre las fases
Metodologa de software
La navegacin se hace a travs de cada fase
Notacin de software
Representacin de elementos utilizados en cada fase
Taxonoma de modelos de proceso
Enfoque secuencial
Nunca retorna a un paso completado.
Slo prctico para proyectos muy pequeos, no crticos.
Enfoque iterativo
Puede retornar a cualquier paso ya completado para introducir un cambio,
propagando su efecto hacia delante a lo largo del ciclo de vida.
La mayora de los modelos de ciclo de vida son iterativos.
Mecanismo recursivo
Todo el enfoque puede ser reaplicado a los productos finales.
Todos los enfoques recursivos del ciclo de vida son iterativos, pero no todos los
enfoques iterativos son recursivos.
Metodologa de software
Anlisis y diseo estructurados
Descomposicin funcional.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 5 de 5

Orientado a flujos de datos.

Modelo orientado a datos
Originado en la comunidad de bases de datos.
Se concentra en la informacin.
Orientacin a objetos
Sita el dominio de un problema y su solucin lgica dentro de la perspectiva
de los objetos (cosas, conceptos o entidades).
Notaciones de software
Diagrama de flujo de datos
Muestra relaciones funcionales.
Grficos cuyos nodos son procesos y las lneas son flujos de datos.
Diagrama de estado
Muestra aspectos dinmicos.
Grficos cuyos nodos son estados y sus lneas son transiciones entre ellos
causando eventos.
Diagramas de entidad-relacin
Muestra la estructura esttica de los componentes de sistema y sus relaciones.
Grficos cuyos nodos son entidades y sus lneas son relaciones entre ellas.
Diagrama de objetos
Grficos cuyos nodos son clases de objetos y sus arcos son relaciones entre las
clases.
Diagrama de clases
Indica las caractersticas relevantes de una clase singular.
Si est en condiciones de responder a las siguientes preguntas, contine con el prximo tema.
Cules son los problemas que presenta el software?
1.3 Tipos de modelo de ciclo de vida
Cascada pura
Sirve de base para otros modelos. Es una secuencia ordenada de pasos en la cual se realiza una
revisin al finalizar cada etapa para determinar si se pasa a la siguiente. Si no est listo
permanece en la etapa actual hasta que est completa.
El producto final de los trabajos que se pasan de una etapa a otra son documentos. Esta es una
de las metodologas ms tradicionales y utilizadas hace unos aos. Pregona que la mejor forma
de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su
entorno, independientemente de los objetos que interactan dentro del sistema para
proveerlos.
Es bueno cuando:
se tiene definicin estable del producto,
el proyecto de anlisis es relativamente pequeo.
Tiene varias desventajas, por lo cual poco a poco est empezando a dejar de utilizarse:
dificultad de especificar claramente los requerimientos al comienzo del proyecto, por lo cual
generalmente se debe volver atrs,
genera pocos signos visibles de progreso hasta el final,
los usuarios no pueden ir viendo el avance real del proyecto, recin cuando ste est
terminado pueden ver el proyecto funcionando, lo cual puede generar a esa altura
disconformismos que son muy difciles de corregir,
la vuelta atrs es posible pero complicada de realizar debido a que debemos cambiar muchas
cosas para lograrla.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 6 de 6

Incremental
Este modelo se basa en realizar entregas frecuentes de software operativo a los clientes. Al
realizar entregas semanales, quincenales o mensuales del producto, la comunicacin es ms
efectiva, se reduce el riesgo dividiendo el proyecto en una serie de subproyectos ms pequeos
aumentando la visibilidad del progreso, proporcionando mdulos terminados y operativos de un
sistema grande antes de tener operativo el sistema completo. Tenemos una mayor capacidad
para hacer modificaciones a mitad de camino porque el sistema est listo para ser entregado
muchas veces durante el desarrollo.
Cada incremento pas por las distintas fases del desarrollo de software, con lo cual en las
primeras etapas podemos hacer un anlisis y mitigacin de riesgos mucho ms efectiva que en
un ciclo en cascada, ya que no tenemos que esperar hasta las fases finales para encontrar, por
ejemplo, un problema de implementacin que requerira que hagamos gran cantidad de
modificaciones sobre lo que ya hemos realizado. Al ir avanzando de esta forma vamos primero
armando el esqueleto de la aplicacin y poco a poco lo vamos rellenando hasta lograr una
solucin completa.
Espiral
Se trata de un modelo que divide el proyecto en subproyectos ms pequeos o mini proyectos,
cada uno de los cuales se enfoca en controlar uno o ms riesgos determinados. Es un modelo
centrado en los riesgos, los que comprenden riesgos en los requerimientos, en la tecnologa, en
la arquitectura, etc..
Es un modelo ideal cuando:
existe poca identificacin de los requerimientos,
hay riesgos importantes que deben ser tenidos en cuenta desde el principio, ya que podran
poner en peligro el proyecto, tales como tecnologa poco conocida u obsoleta, polticas no
alineadas con los objetivos de la organizacin, etc..
Este modelo presenta inconvenientes que deben ser manejados:
necesita una planificacin adecuada,
se necesita tiempo considerable para la gestin del proyecto,
requiere suficiente preparacin de los recursos humanos para la gestin, ya que su
implementacin no es sencilla.
En el grfico que se encuentra a continuacin observamos que el trabajo se inicia con la
identificacin y anlisis de los riesgos y luego se crea un plan para controlarlos. Una vez hecho

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 7 de 7

sto se avanza a la prxima iteracin. El hito que permite el paso a la siguiente iteracin es el
manejo de los riesgos en un nivel que se considere aceptable para el proyecto.
Las primeras iteraciones son las menos costosas, a medida que nos alejamos del centro de la
espiral los costos aumentan y los riegos disminuyen, es decir, que mientras ms tiempo y
dinero se invierta en el desarrollo del proyecto, mayor cantidad de riesgos estarn controlados.
Cada iteracin implica realizar los siguientes pasos:
o
o
o
o
o
o

Definir objetivos, alternativas y lmites.

Identificar y controlar riesgos.
Evaluar alternativas.
Realizar las entregas de la iteracin.
Planificar la prxima iteracin.
Fijar el enfoque de la siguiente iteracin.

Prototipado evolutivo
Este modelo comienza por desarrollar los aspectos visibles del sistema, se presenta el prototipo
al cliente, se logra el acuerdo con el mismo y contina el desarrollo.
Es til cuando:
no es posible definir con claridad los requerimientos debido a que cambian reiteradamente o
no existe acuerdo con los usuarios,
el proyecto debe mostrar rpidamente y al poco tiempo signos visibles de avance,
se estima que se debern realizar modificaciones importantes en la mitad del camino de
desarrollo del proyecto.
Presenta inconvenientes tales como:
no se conoce el tiempo que tomar terminar el producto,
no se sabe cuntas iteraciones se debern realizar,
no est ligado a una planificacin rigurosa.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 8 de 8

1.4 Rol del cliente

Parte de nuestro trabajo como desarrolladores es educar a los clientes para que comprendan
mejor el desarrollo de software, sin olvidarnos de que el proceso de desarrollo debe estar
orientado al l.
En general, los clientes no entienden que un retraso de una semana para realizar la revisin de
un documento importante se puede traducir luego en un retraso de una semana en la entrega
del producto. En este sentido, uno de los errores ms costosos es el de desarrollar un software
que sea rechazado por el usuario a ltimo momento. En general, se suelen rechazar partes del
software, sto significa que se tiene que volver a disear e implementar. Entonces, el efecto
global es la entrega retrasada.
Usted debe evitar tener que repetir el trabajo ya realizado.
Factores que pueden generar riesgos en la planificacin:
Clientes que:
no saben lo que quieren,
no quieren comprometerse a tener un conjunto de requerimientos escritos,
insisten en establecer nuevos requerimientos una vez realizada la planificacin,
no participan en la revisin o se niegan a hacerla,
no estn preparados tcnicamente,
no dejan realizar el trabajo a la gente debido a que por algn motivo se oponen al nuevo
proyecto,
son nuevos desconocidos, por lo que no sabemos los riesgos que tenemos,
la comunicacin con los clientes es lenta.
Importancia del cliente en el desarrollo
Las tres razones principales para que los proyectos:
terminen tarde,
sobrepasan el presupuesto,
tengan menos funcionalidad a la deseada,
se debe a la:
deficiente comunicacin con el usuario,
falta de especificacin de requerimientos,
modificacin de requerimientos y especificaciones.
Hay dos razones principales por las que se debe prestar atencin a las relaciones con el cliente.
Primero, porque aumenta la velocidad del desarrollo al eliminar una fuente de errores e
ineficiencia en el desarrollo. Segundo, porque mejora la percepcin en el cliente de la velocidad
del desarrollo haciendo posible estructurar el proyecto de manera que el usuario pueda ver el
progreso y aumentar su confianza.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 9 de 9

Una vez que hemos hecho una introduccin a la ingeniera del software comenzamos a analizar
una metodologa de desarrollo de software que sigue los lineamientos de los ciclos de vida
incrementales.
2

Metodologa de desarrollo

Cabe aclarar que cuando hablamos de dominio hacemos referencia a una parte de la realidad
del cliente. El problema est en un dominio, mientras que el observador est fuera de dicho
dominio.
Se puede construir software para satisfacer un cliente o para investigar la realidad con un
modelo computacional. Para representar un dominio mediante un modelo computacional
disponemos de dos enfoques:
representar de forma lo ms completa posible un dominio y luego identificar aplicaciones (es
un proceso lento, dos aos aproximadamente),
construir aplicaciones directamente a partir de los requerimientos (es ms rpido y directo).
Deseamos modelar la realidad y para ello realizamos un modelo general y luego desarrollamos
aplicaciones particulares de acuerdo a las necesidades del cliente (requerimientos).
Si se piensa en el software como un producto, seguramente Ud. ya habr deducido que
necesitamos de un proceso de fabricacin. El proceso es la visin dinmica y la metodologa es
la visin esttica.
Un mtodo es una descripcin formal de un procedimiento, un conjunto de tareas realizadas en
un determinado orden para alcanzar un objetivo.
Una metodologa es un conjunto de mtodos a aplicar en un determinado procedimiento, es un
conjunto de tcnicas, mtodos, herramientas, productos y roles para obtener software.
Permite que se entienda el lenguaje usado.
Permite formar equipos con personas de diferentes niveles.
Est fuertemente asociada al desarrollo y al tipo de software.
As, el proceso es poner en funcionamiento una metodologa.

El proceso unificado de desarrollo de software

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 10 de 10

Como mencionbamos hace algunas lneas, encarar cualquier tipo de proyecto sin contar con
un proceso de desarrollo puede traer infinidad de problemas antes, durante o despus del
desarrollo del mismo. Contar con un proceso es contar con una herramienta que nos va
guiando y sirviendo de bastn de apoyo durante el ciclo de vida de un Sistema, desde sus
inicios hasta el mantenimiento del mismo.
Un alto porcentaje de los sistemas que fracasan es por no contar con un Proceso de Desarrollo,
o a la inapropiada utilizacin del mismo. Muchos desarrolladores piensan que el desarrollo de
software comienza con la programacin del mismo en un lenguaje determinado, y ah caen en
una de las causantes ms importantes de fracaso del Sistema.
Sea cual sea el tamao del Sistema es crtico que nos apoyemos en un proceso. Este proceso
nos va llevando paso a paso por cada etapa del desarrollo, y va guiando y coordinando la
intervencin de los distintos roles involucrados en el desarrollo del mismo.
De ahora en adelante veremos cmo apoyarnos en un proceso para encarar proyectos de
desarrollo de software. ste se denomina proceso unificado de desarrollo de software y abarca
el conjunto de actividades necesarias para transformar los requisitos de los distintos usuarios en
un Sistema Informtico.
El proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language UML) para representar todos los esquemas necesarios en las distintas fases del desarrollo de
software, los que veremos a medida que avancemos en el desarrollo de cada fase.
3.1 PUDS dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental.
Este proceso se apoya en tres pilares alrededor de los cuales gira la totalidad de la
metodologa. stos son los casos de uso, la arquitectura y el concepto de iterativo e
incremental.
Casos de uso
Las necesidades del cliente no son fciles de detectar. sto nos lleva a que utilicemos algn
modo de capturar estas necesidades de manera que posteriormente puedan comunicarse al
resto de los intervinientes en el proyecto. Existen entonces dos objetivos fundamentales:
encontrar los verdaderos requisitos y representar los mismos de un modo adecuado para los
usuarios, clientes y desarrolladores. Un sistema debe dar solucin a lo que el cliente espera, y
los casos de uso nos van a permitir analizar minuciosamente esos requerimientos. Ellos han
sido adoptados casi universalmente para la captura de requisitos de sistemas de informacin.
Debemos aclarar que dichos casos de uso son mucho ms que una simple herramienta de
captura de requisitos, ya que dirigen el proceso de desarrollo en su totalidad.
Los desarrolladores crean un modelo de anlisis que utiliza el modelo de casos de uso como
entrada y que es diferente del modelo de diseo porque es un modelo conceptual en lugar de
ser un esquema de la implementacin. Cada caso de uso en el modelo de casos de uso se
traduce en una realizacin de caso de uso en el modelo de anlisis.
Tomando los casos de uso uno a uno, los desarrolladores pueden identificar las clases que
participan en la realizacin de aquellos. As obtenemos un conjunto de clases que juntas
realizan los casos de uso. Luego los desarrolladores disean las clases y las realizaciones de
casos de uso para aprovechar al mximo las tecnologas y productos a utilizarse. A continuacin
se implementan las clases diseadas mediante un conjunto de archivos a partir de los cuales se
pueden generar (ejecutables, DLLs, JavaBeans, componentes ActiveX, pginas web, etc.).
Finalmente, durante el flujo de trabajo de prueba, los ingenieros corroboran que el sistema
implementa la funcionalidad descrita en los distintos casos de uso, y de esta forma se
satisfacen los requerimientos para los que fue construido.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 11 de 11

Hemos descrito de una manera muy simplificada cmo los casos de uso guan al proceso
unificado, lo hemos visto slo con una iteracin. Vemos cmo este mismo proceso se repite de
manera iterativa e incremental a medida que avanzamos en el proceso de desarrollo.

Anlisis, diseo e implementacin para realizar los casos de uso

Durante el anlisis y el diseo transformamos el modelo de casos de uso desde un modelo de
anlisis en un modelo de diseo. El modelo de anlisis va creciendo ms y ms en cada
iteracin. Por cada iteracin se seleccionan determinados casos de uso y se los refleja en el
modelo de anlisis, se comienzan a construir clases de anlisis y relaciones entre ellas.
Luego, es necesario complementar este modelo de anlisis con un modelo que permita plasmar
la forma en que interactan las distintas clases para llevar a cabo la realizacin del caso de uso.
Aparecen de esta forma los diagramas de colaboracin. El modelo de diseo se crea tomando
como entrada principal el modelo de anlisis y adaptndose al entorno de implementacin
elegido. Funciona como esquema para la implementacin. Con sto queremos indicar que el
modelo de diseo es ms fsico por naturaleza, mientras que el modelo de anlisis es ms
conceptual.
De igual forma que el modelo de anlisis, el modelo de diseo tambin define clasificadores
(clases, subsistemas e interfaces).
Es imposible pensar en un sistema de tamao sin incorporar la idea de subsistemas, a travs de
stos podemos hacer una organizacin de clases de acuerdo a funciones definidas que
desempeen las mismas. Por medio de los subsistemas podemos crear una organizacin de alto
nivel a travs de la cual podemos tener una comprensin global mucho ms clara.
Durante el modelo de implementacin procedemos a elaborar todo lo necesario para obtener un
sistema en ejecucin. Este modelo est constituido por componentes (archivos ejecutables,
componentes, pginas web, etc.). Estos componentes son la realizacin de un conjunto de
interfaces y pueden ser reemplazables, siempre y cuando el nuevo componente respete y se
adapte a estas interfaces previamente definidas. Estas interfaces representan la forma de
comunicacin con el exterior, en este caso con otros componentes (propiedades, mtodos).
En el caso en que se utilice un lenguaje de programacin orientado a objetos existir una
relacin directa entre clases de diseo y componentes de implementacin. Una vez que
implementamos estos componentes es necesario hacer pruebas de funcionamiento sobre los
mismos antes de proceder a comenzar con la realizacin de pruebas de la totalidad del sistema.
El objetivo de este punto es, no slo probar el correcto funcionamiento del sistema, sino
tambin controlar que el sistema desempee correctamente todas aquellas funcionalidades para
las que fue creado, es decir que debemos chequear contra los casos de uso. Se utiliza un
modelo compuesto por casos de prueba y procedimientos de prueba a partir del cual podemos
ir chequeando la funcionalidad plasmada en los casos de uso contra los requerimientos
esperados.
Centrado en la arquitectura

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 12 de 12

La arquitectura describe los cimientos del sistema que son necesarios como base para
comprenderlo, desarrollarlo y producirlo. El objetivo nmero uno de la fase de elaboracin es
construir una arquitectura slida para que a partir de la misma podamos arrancar con la
construccin de la totalidad del sistema sin tropiezos posteriores.
El rol del arquitecto es crear los aspectos ms significativos del sistema en su conjunto.
A la hora de ir pasando por las distintas fases del proyecto los desarrolladores utilizarn la
arquitectura como gua general para situarse correctamente en el lugar en donde estn parados
y usarn los distintos diagramas ms detallados para realizar su trabajo. Cuando hablamos de
arquitectura hablamos tambin del concepto de vista, ya que se generan vistas sobre los
distintos modelos que hemos estado viendo y que abarcan slo aquellos casos de uso
importantes en este contexto.
La descripcin de la arquitectura tiene cinco vistas, una para cada modelo:
1.
2.
3.
4.
5.

Casos de uso
Anlisis
Diseo
Despliegue
Implementacin

Usted en realidad se estar preguntando para qu se necesita tener definida una arquitectura.
Se necesita para:
comprender el sistema,
organizar el desarrollo,
permitir la reutilizacin,
hacer evolucionar el sistema.

Fuente: Jacobson, Ivar. Booch, Grady. Rumbaugh, James. El Proceso Unificado de Desarrollo
del Software. Ed. Addison Wesley. Madrid, 2000.
En la descripcin de la arquitectura no se pretende cubrir absolutamente todo, no debera
inundar a los participantes con detalles minuciosos. Hay mucha informacin que no es
necesaria tener en cuenta a la hora de describir la arquitectura.
Por ejemplo, la experiencia indica que slo el 10 % de las clases de un sistema son relevantes
para la arquitectura, el 90 % restante no es significativo porque no es visible a todo el sistema.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 13 de 13

As tambin es importante que usted comprenda que no todos los casos de uso son relevantes
a la hora de definir la arquitectura, hay ciertos casos de uso arquitectnicamente relevantes y
son slo stos los que guan la arquitectura y por lo tanto, los que se deben tener en cuenta a
la hora de describirla.
Ya vimos en puntos anteriores cun crtica es la relacin entre casos de uso y arquitectura,
unos condicionan lo otro y viceversa. Por eso es imprescindible utilizar un mecanismo que
permita ir avanzando poco a poco en el refinamiento de unos como de otros, es decir, vamos
avanzando por etapas.
sta es la clave del tercer pilar alrededor del cual gira el proceso unificado de desarrollo de
software: proceso iterativo e incremental.
El decir, basarnos en un proceso iterativo e incremental nos diferencia mucho con metodologas
de desarrollo tradicionales en las cuales el desarrollo tambin se realiza por etapas, pero las
mismas se van realizando en serie, una detrs de la otra sin posibilidad por ejemplo de recibir
retroalimentacin en alguna y volver para atrs para modificar funcionalidad.
Se cumplen las etapas, se van cerrando y se avanza a la siguiente. En nuestro caso la base es
que el proceso sea realmente iterativo e incremental, es decir:
planificar un poco,
especificar, disear e implementar un poco,
integrar, probar y ejecutar un poco cada iteracin.
Es decir, se divide el proyecto en un nmero de mini proyectos, siendo cada uno de ellos una
iteracin. Cada iteracin est compuesta por todas las fases de un proyecto de software, es
decir que cada una de ellas sera como un miniproyecto hecho con una metodologa tradicional,
como la de cascada.
Se debe manejar con mucho cuidado el hecho de poder avanzar y recibir retroalimentacin y
retroceder, ya que si tomamos sto como moneda corriente podemos caer en un terreno donde
nos mantengamos siempre en un mismo lugar sin percibir avance alguno.
Un prrafo del captulo 5 de la bibliografa propuesta resume muy bien el concepto de iteracin:
... la iteracin controlada est muy lejos de ser aleatoria.
Se planifica. Es una herramienta que pueden utilizar los directores para controlar el proyecto.
Reduce, al principio del ciclo de vida, los riesgos que pueden amenazar el progreso del
desarrollo.
Las versiones internas tras las iteraciones posibilitan la retroalimentacin de los usuarios y sto
lleva a su vez a una correccin temprana de la trayectoria del proyecto.
Para resumir, los principales objetivos de un desarrollo iterativo e incremental son:

Atenuar los riesgos.

Obtener una arquitectura robusta.
Gestionar requisitos cambiantes.
Permitir cambios tcticos.
Conseguir una integracin continua.
Conseguir un aprendizaje temprano.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 14 de 14

De qu forma usted relacionara estos puntos con los otros dos pilares alrededor de los cuales
gira este proceso unificado (casos de uso y arquitectura)?.
La reduccin de riesgos es uno de los puntos ms importantes a tener en cuenta. Esta
metodologa permite en las primeras fases de un proyecto, identificar, gestionar y reducir los
diferentes tipos de riesgos a los que se puede ver expuesto un proyecto.
A diferencia de metodologas como la de cascada, que debido a que el desarrollo
solo sentido por una serie de pasos: requisitos, anlisis, diseo, implementacin y
problemas pueden empezar a surgir en las etapas finales, cuando el sistema
implementando o testeando, lo cual genera grandes costos y perdidas de tiempo
atrs y cambiar funcionalidades que ya estaban listas, terminadas y cerradas.

pasa en un
prueba, los
ya se est
para volver

En el desarrollo iterativo, una vez que se han identificado los riesgos, se debe optar por una de
cuatro acciones posibles:

Evitarlo
Limitarlo
Atenuarlo
Controlarlo

3.2 Fases y flujos de trabajo

Podemos decir que un proyecto est compuesto por un gran numero de iteraciones. Cada una
es un pequeo proyecto en s mismo, y constituye una pasada por los flujos de trabajo
fundamentales.
Los flujos de trabajo fundamentales son:

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 15 de 15

Requisitos
Anlisis
Diseo
Implementacin
Prueba

En el proceso unificado tenemos flujos de trabajo fundamentales y flujos de trabajo de

iteracin. Los primeros nos ayudan a describir los segundos, ya que los de iteracin incluyen los
cinco flujos de trabajo y adems la planificacin que precede a los flujos de trabajo y la
evaluacin que va detrs de ellos.

Los flujos de trabajo fundamentales sern analizados en profundidad a lo largo de las siguientes
unidades.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 16 de 16

El primer paso hacia la divisin del proceso de desarrollo de software consiste en separar las
partes en cuatro fases atendiendo al momento en que se realizan:
Inicio
Elaboracin
Construccin
Transicin
En la fase de inicio se define el negocio y sus objetivos, as como la factibilidad del proyecto, se
delimita el mbito, se describe la arquitectura candidata posible y se identifican los riesgos
crticos. El nfasis recae en los requerimientos.
En la fase de elaboracin se capturan los requerimientos restantes (aproximadamente el 80 %
de los mismos), se establece la arquitectura base para la construccin y se monitorean los
riesgos. Se enfoca en los requerimientos, el anlisis y el diseo.
En la fase de construccin se realiza el sistema segn una arquitectura estable, se genera una
versin beta del mismo (operativa) y se crea material de usuario. El nfasis est en la
implementacin y la prueba.
En la fase de transicin se actualiza el entorno en el que va a funcionar el sistema (sistemas
operativos, hardware, etc..), se crean los manuales del sistema, se ajusta el software al entorno
de trabajo, se corrigen errores y deficiencias y se genera una versin formal del sistema.
Cada una de las fases se divide en una o ms iteraciones.
Cada una de las cuatro fases de un proyecto finaliza con un hito principal:
_
_
_
_

Inicio: objetivos del ciclo de vida

Elaboracin: arquitectura del ciclo de vida
Construccin: funcionalidad operativa inicial
Transicin: versin del producto

Realice un grfico donde pueda resumir cmo est estructurado un proyecto de desarrollo de
software. Incluya todo lo referido a flujos de trabajo fundamentales y de iteracin.
Para llegar a cada hito principal se van cumpliendo hitos secundarios, los cuales constituyen las
distintas iteraciones que tenemos dentro de las diferentes fases. stos van permitiendo alcanzar
nuevos incrementos sobre los flujos de trabajo fundamentales (requisitos, anlisis, diseo,
implementacin y prueba).
4

Las cuatro P en el desarrollo del software

Dentro de todo proyecto de desarrollo de software intervienen los siguientes conceptos que
sern claves para comprender el resto de los temas que tratamos en esta materia.

Personas
Proyecto
Producto
Proceso

En todo proyecto participan personas que se encargan de las tareas que van desde la
planificacin hasta la utilizacin del sistema, pasando por la gestin, desarrollo, prueba etc..
Estas personas reciben el nombre de trabajadores. O sea que un trabajador es un papel que
una persona o grupo de personas desempean en el desarrollo del software. Todo trabajador
realiza actividades especficas de acuerdo a su habilidad, a la vez que tiene responsabilidades
asignadas.
Durante el desarrollo del proyecto se construyen productos, que son los artefactos que se crean
durante la vida de dicho proyecto, puede tratarse de documentacin, modelos, ejecutables,
etc..

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 17 de 17

Antes de continuar aclaremos la nocin de artefacto, que es cualquier informacin empleada en

el proyecto, por ejemplo los modelos que UML permite construir y que posibilitan a los
trabajadores llevar adelante el proyecto. Un artefacto es creado, modificado y mantenido por
un trabajador.
En la definicin anterior se emple el concepto de modelo, un modelo es una abstraccin del
sistema que captura algunos elementos de dicho sistema y omite otros. Describe al sistema
desde algn punto de vista o segn algn aspecto. De acuerdo a sto podramos decir que un
sistema puede ser descrito por un conjunto de modelos, cada uno de los cuales permite
interpretar el sistema segn una perspectiva en particular. Ejemplos pueden ser el modelo de
casos de uso, el modelo de anlisis, etc.. que estudiaremos en las prximas unidades.
El proceso permite transformar los requerimientos recopilados en un conjunto de artefactos que
constituyen el sistema.
5

UML: lenguaje unificado de modelado

Veamos ahora por qu el PUDS emplea UML.

UML (Unified Modeling Languaje) es un lenguaje estndar que se utiliza para realizar modelos
de software. Se usa para visualizar, especificar, construir y documentar sistemas. UML es un
lenguaje que brinda un vocabulario particular y reglas especficas que se focalizan en la
representacin conceptual y fsica del sistema. Este vocabulario y estas reglas dicen cmo crear
y leer modelos, pero no dicen qu modelos se deben crear ni cundo. Esta tarea le corresponde
al proceso unificado de desarrollo.
Para representar un sistema se necesitan mltiples modelos, los cuales estn conectados unos
con otros para describir y comprender dicho sistema. Para sistemas software se requiere un
lenguaje que provea distintas vistas de la arquitectura del sistema y muestre cmo esa
arquitectura evoluciona a travs del ciclo de vida de desarrollo.
Un proceso bien definido dir qu artefactos producir, qu actividades realizar y qu personas
(trabajadores) los crean, usan y administran, y cmo emplear estos artefactos para medir y
controlar el proyecto como un todo.
UML es:
Lenguaje de visualizacin: facilita la comunicacin de los modelos conceptuales a otros y
disminuye errores al permitir hablar el mismo lenguaje. Permite interpretar los modelos sin
ambigedades, ya que UML tiene una semntica bien definida.
Lenguaje de especificacin: especificacin significa construir modelos precisos, no ambiguos y
completos.
UML especifica las decisiones de anlisis y diseo que deben llevarse a cabo, como as tambin
las de implementacin.
Lenguaje de construccin: no es un lenguaje de programacin, pero sus modelos pueden ser
conectados a una variedad de lenguajes de programacin, como Java, C++, Visual Basic. Se
puede generar cdigo a partir de un modelo UML y an hacer ingeniera reversa (se puede
construir un modelo a partir de una implementacin). UML permite ejecucin de modelos y
simulacin de sistemas.
Lenguaje de documentacin: documenta requerimientos, arquitectura, diseo, codificacin,
plan de proyecto, prueba, prototipo, versiones software.
5.1 Modelos

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 18 de 18

Los modelos son simplificaciones de la realidad. Construimos modelos para comprender mejor
los sistemas, porque debido a la complejidad de los mismos no es posible abordarlos en su
totalidad tal como son en la realidad. A travs del modelado se logran los siguientes objetivos:

ayudar a visualizar cmo es el sistema,

permitir especificar la estructura del sistema,
especificar el comportamiento del sistema,
proporcionar plantillas que guan la construccin del sistema,
documentar las decisiones adoptadas.

Un modelo tiene dos aspectos esenciales:

Semntica: se trata de la informacin o significado del modelo.
Presentacin visual: es la notacin que muestra el modelo de una forma comprensible.
Organiza la presentacin del modelo.
5.2 Bloques bsicos de construccin de UML
Mencionaremos a continuacin los elementos bsicos de UML y sus relaciones, que luego en las
prximas unidades utilizaremos en la construccin de artefactos.
1) Elementos:
a) Estructurales (estticos): son partes estticas de los modelos y representan cosas
conceptuales.
Existen siete tipos:
I) Clase: describe un conjunto de objetos.

II) Interfaz: es una coleccin de operaciones que especifican un servicio de na clase o

componente. Describe comportamiento visible. Define un onjunto de especificaciones (no
implementaciones).

III) Colaboracin: define una interaccin, roles y otros elementos que colaboran para llevar a
cabo un comportamiento colaborativo. Las colaboraciones tienen dimensin estructural y de
comportamiento.

IV) Caso de uso: expresa una interaccin entre un usuario externo y el sistema.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 19 de 19

V) Clase activa: sus objetos tienen uno o ms hitos de ejecucin y pueden riginar actividades
de
control.

VI) Componente: es una parte fsica y reemplazable del sistema.

VII) Nodo: elemento fsico que existe en tiempo de ejecucin y representa un recurso
computacional (memoria, capacidad de procesamiento, etc.). Un conjunto de componentes
puede residir en un nodo y migrar a otro.

b) De comportamiento (dinmicos): partes dinmicas de los modelos UML. Son los verbos de un
modelo y representan comportamiento en tiempo y espacio.
I)

Interaccin: conjunto de mensajes intercambiados entre un conjunto de objetos.

II) Mquina de estados: comportamiento que especifica la secuencia de estados por los
que pasa un objeto o una interaccin durante su vida en respuesta a eventos.

c) De agrupamiento: son las partes organizativas de los modelos UML. Son las capas en las que
puede descomponerse un modelo.
Paquete: es un mecanismo de propsito general para organizar elementos en grupos. Los
elementos estructurales, de comportamiento y de agrupacin se pueden incluir en un paquete.
Son puramente conceptuales, no existen en tiempo de desarrollo.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 20 de 20

d) De anotacin: son las parte explicativas de los modelos UML. Son comentarios que se
pueden aplicar para describir, clarificar y observar sobre cada elemento del modelo.

Nota: muestra restricciones y comentarios.

2) Relaciones
a) Dependencia: relacin semntica entre dos elementos. Un cambio en el elemento
independiente puede provocar un cambio en el elemento dependiente.

b) Asociacin: relacin estructural que describe un conjunto de enlaces, los cuales son
conexiones entre objetos. La agregacin es un tipo especial de asociacin que representa una
relacin
estructural entre el todo y sus partes.

c) Generalizacin: relacin especializacin/generalizacin.

d) Realizacin: relacin semntica entre clasificadores, en donde un clasificador especifica un

contrato que otro clasificador garantiza que cumplir.
Por ejemplo entre los casos de uso y las colaboraciones que los realizan.

3) Diagramas
- De clases
- De objetos del dominio
- De casos de uso
- De secuencia
- De colaboracin
- De estados
- De actividades
- De componentes
- De despliegue
Solucin a las actividades de proceso
1. La complejidad del dominio del problema se debe a:

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 21 de 21

gran cantidad de requerimientos funcionales,

requerimientos vagos,
falta de comunicacin con los desarrolladores,
cambio en los requerimientos durante el desarrollo,
expresar requerimientos con gran cantidad de texto,
los sistemas tienden a evolucionar en el tiempo.

2. El trmino ciclo de vida intenta captar la idea de que un producto de software es el resultado
de un proceso de desarrollo que puede dividirse en fases. Podemos definir el ciclo de vida como
la actividad de producir y mantener sistemas informticos.
Su funcin es:
establecer un orden en el que se:
- especifica
- realiza un prototipo
- disea
- implementa
- prueba
establecer los criterios para pasar de una fase a otra
3. La arquitectura est influenciada por aquellos casos de uso que queremos que el sistema
soporte. Los casos de uso conducen la arquitectura. Tambin utilizamos nuestro conocimiento
de la arquitectura para hacer mejor el trabajo de captura de requisitos para obtener casos de
uso. La arquitectura gua los casos de uso.
4. La mejor forma de resolver este conflicto es la iteracin. Primero construimos una
arquitectura bsica a partir de una buena comprensin del dominio, sin considerar los casos de
uso detallados. Luego escogemos algunos casos de uso y ampliamos la arquitectura
adaptndola para que soporte esos casos de uso. Despus tomamos otros casos de uso y
ampliamos todava ms la arquitectura,
y as sucesivamente. Cada iteracin nos va permitiendo mejorar la arquitectura. Los casos de
uso que son importantes analizar para la construccin de la arquitectura son aquellos que nos
ayudan a cubrir todas las funcionalidades y a mitigar los riesgos ms importantes, aquellos
fundamentales para los usuarios del sistema.
5. No es un desarrollo que se base en la prueba y error. Armamos y probamos, si funciona
seguimos, si no, retrocedemos y cambiamos.
La tercera clave del PUDS consiste en desarrollar un producto en pasos pequeos:
a. Planificar un poco.
b. Especificar, disear e implementar un poco.
c. Integrar, probar y ejecutar un poco cada iteracin.
Una iteracin no es una entidad independiente, es una etapa dentro de un proyecto, es un mini
proyecto. Cada mini proyecto se parece al antiguo ciclo de vida en cascada. Cada iteracin sera
una mini cascada. El ciclo iterativo produce resultados tangibles en forma de versiones
preliminares y cada una de ellas aporta un incremento.
6. Algunos riesgos pueden y deben evitarse quizs a travs de una replanificacin de requisitos.
Otros deberan limitarse para que afecten a una pequea parte del proyecto. Algunos riesgos
pueden atenuarse observando si aparecen o no, y si aparecen el equipo conoce mucho ya sobre
ellos y quizs podr evitarlos, limitarlos o controlarlos.
Hay riesgos que no pueden evitarse, en esos casos el equipo debe estar preparado cuando este
riesgo aparezca, para lo cual deberamos contar con un plan de contingencia.

Ctedra de Proyecto Ingeniera en Sistemas de la Informacin 2005

Pgina 22 de 22

7. Si nosotros contramos slo con los flujos de trabajo fundamentales estaramos en frente de
una metodologa de ciclo de vida en cascada, recordemos que la gran diferencia entre el PUDS
y metodologas estructuradas de ciclo de vida en cascada es el avance iterativo e incremental
que se asocia con los flujos de trabajo de iteracin. Cada iteracin constituye una pasada a
travs de los cinco flujos de trabajo fundamentales. Las distintas fases renen iteraciones que
dan como resultado los hitos principales.
8. No, durante la fase de inicio -establece la viabilidad- y elaboracin -se centra en la
factibilidad- la mayora del esfuerzo se dedica a la captura de requisitos y a un anlisis y diseo
preliminares. Durante la construccin -se construye el sistema- el nfasis pasa al diseo
detallado, la implementacin y la prueba. Y durante la fase de transicin nos metemos mucho
ms dentro del usuario, inicia con la entrega de una versin beta y culmina con la entrega final,
al medio tenemos preparacin de manuales, correccin de defectos encontrados en las pruebas
del beta, preparacin del entorno del usuario (hardware, Sistemas operativos, protocolos de
comunicaciones, etc.).
9. Al concepto de flujo de trabajo se lo asocia con el concepto de iteracin. Es un conjunto de
actividades, es una colaboracin entre trabajadores que utilizan y producen artefactos. Para
describir los flujos se utilizan los diagramas de actividad. En estos diagramas observamos los
distintos trabajadores relacionados con el flujo y las actividades que stos desarrollan.
Al ejecutar estas actividades crean y modifican artefactos.
Los flujos de trabajo son secuencias de actividades que estn ordenadas, una actividad produce
una salida que es entrada de otra actividad. En el proceso unificado tenemos flujos de trabajo
fundamentales y flujos de trabajo de iteracin. Los flujos de trabajo fundamentales nos ayudan
a describir los flujos de trabajo de iteracin, ya que los de iteracin incluyen los cinco flujos de
trabajo fundamentales, y adems la planificacin que precede a los flujos de trabajo y la
evaluacin que va detrs de ellos. El resultado de una iteracin es un incremento.