(Documentación) Introducción A La Ingeniería de Software

Eduardo Gmez Snchez edugom@tel.uva.
es
Mara ngeles Prez Jurez mperez@tel.uva.es
I
IIN
NNT
TTR
RRO
OOD
DDU
UUC
CCC
CCI
II
N
NN A
AA L
LLA
AA
I
IIN
NNG
GGE
EEN
NNI
IIE
EER
RR
A
AA D
DDE
EE
S
SSO
OOF
FFT
TTW
WWA
AAR
RRE
EE
Introduccin a la Ingeniera de Software, pg. 2

I IN ND DI IC CE E
1 QU ES EL SOFTWARE ? ...................................................................................................... 3
2 CARACTERSTICAS DEL SOFTWARE VS HARDWARE ................................................................... 3
3 EVOLUCIN DEL SOFTWARE .................................................................................................... 6
4 LA INGENIERA DE SOFTWARE ................................................................................................. 6
5 EL PROCESO DEL SOFTWARE .................................................................................................. 9
6 MODELOS DE PROCESO DEL SOFTWARE ................................................................................ 12
6.1 MODELO DE PROCESO O CICLO DE VIDA DEL SOFTWARE .................................... 12
6.2 EL MODELO CLSICO O MODELO EN CASCADA ................................................... 12
6.3 EL MODELO EN ESPIRAL ................................................................................... 15
6.4 EL MARCO DE TRABAJO ITERATIVO E INCREMENTAL ............................................ 16
6.5 EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE ................................... 18
6.5.1 Fases del Proceso Unificado de Desarrollo de Software ................................................... 21
6.5.2 Actividades del Proceso Unificado de Desarrollo de Software .......................................... 24
7 EL LENGUAJE DE MODELADO UNIFICADO ............................................................................... 26
7.1 QU ES EL LENGUAJE DE MODELADO UNIFICADO ? .......................................... 26
7.2 HISTORIA DEL LENGUAJE DE MODELADO UNIFICADO ........................................... 29
8 HERRAMIENTAS CASE ........................................................................................................... 30
8.1 QU SON LAS HERRAMIENTAS CASE (UML) ? ................................................ 30
8.2 CRITERIOS DE SELECCIN O DE COMPARACIN PARA UNA HERRAMIENTA CASE
UML ...................................................................................................................... 31
8.3 EJEMPLOS DE HERRAMIENTAS CASE UML ........................................................ 35
8.4 ASTAH ............................................................................................................ 37
9 EN ESTA ASIGNATURA ....................................................................................................... 37
10 BIBLIOGRAFA ....................................................................................................................... 38
11 ANEXO I: EJEMPLOS DE DIAGRAMAS UML .............................................................................. 39
11.1 DIAGRAMA DE CASOS DE USO ........................................................................... 39
11.2 DIAGRAMA DE CLASES ...................................................................................... 40
11.3 DIAGRAMA DE OBJETOS .................................................................................... 41
11.4 DIAGRAMA DE COLABORACIN O COMUNICACIN ............................................... 42
11.5 DIAGRAMA DE SECUENCIA ................................................................................ 42
11.6 DIAGRAMA DE ESTADOS ................................................................................... 43
11.7 DIAGRAMA DE ACTIVIDAD .................................................................................. 44
12 ANEXO II: MITOS DEL DESARROLLO DE SOFTWARE ................................................................ 46
12.1 MITOS DE GESTIN .......................................................................................... 46
12.2 MITOS DEL CLIENTE ......................................................................................... 47
12.3 MITOS DE LOS DESARROLLADORES ................................................................... 49
12.4 REFLEXIN SOBRE LOS MITOS DEL SOFTWARE ................................................... 50

1 1 Q QU U E ES S E EL L S SO OF FT TW WA AR RE E ? ?
El software de computadora se ha convertido en el alma mater. Es la mquina que conduce a la
toma de decisiones comerciales. Sirve de base para la investigacin cientfica moderna y de resolucin
de problemas de ingeniera. Es el factor clave que diferencia los productos y servicios modernos. Est
inmerso en sistemas de todo tipo: de transportes, mdicos, de telecomunicaciones, militares, procesos
industriales, entretenimientos, productos de oficina, etc., la lista es casi interminable. El software es casi
ineludible en un mundo moderno. A medida que nos adentremos en el siglo XXI, ser el que nos
conduzca a nuevos avances en todo, desde la educacin elemental a la ingeniera gentica. (Pressman)

El prrafo anterior, casi proftico, que apareca ya en la primera pgina de la primera edicin del
libro de Roger S. Pressman: Ingeniera de Software. Un Enfoque Prctico de 1999, sirve para poner de
manifiesto la gran importancia del software en el mundo actual y, ms an, el hecho de que la
importancia del software crece a medida que el tiempo transcurre puesto que el papel del software en la
sociedad contina su expansin. El software se construye para que sea utilizado potencialmente por
cualquier persona en una sociedad del conocimiento como la nuestra. Su importancia radica en que
afecta a numerosos, o ms bien prcticamente todos, los aspectos de nuestra vida, incluidos los ms
cotidianos, ya que cada vez ms y ms sistemas estn controlados por software. Las economas de
buena parte de los pases son cada vez ms dependientes del software a la par que aumentan el gasto
en desarrollo de software como porcentaje de su Producto Interior Bruto (PIB). En resumen,
probablemente, a fecha de hoy, nadie sea capaz de imaginar una sociedad como la nuestra sin software.

Software es el sustantivo genrico que se utiliza para referirse a los programas e informacin o
datos asociados, as como a los medios necesarios para soportar su instalacin, operacin, reparacin y
mejora o segn la IEEE (Institute of Electrical and Electronic Engineers), el conjunto de los programas de
cmputo, procedimientos, reglas, documentacin y datos asociados que forman parte de las operaciones
de un sistema de computacin. Por tanto, el software no son solo programas, sino todos los datos
asociados y la configuracin de los mismos necesaria para hacer que estos programas operen de
manera correcta. As, un sistema de software consiste en diversos programas independientes, archivos
de configuracin que se utilizan para ejecutar estos programas, un sistema de documentacin que
describe la estructura del sistema, la documentacin para el usuario que explica cmo utilizar el sistema
y sitios web que permitan a los usuarios descargar la informacin de productos recientes. (Sommerville)

El software de computadora es el producto que los ingenieros de software construyen y despus
mantienen en el largo plazo. El software se forma con (1) las instrucciones (programas de computadora)
que al ejecutarse proporcionan las caractersticas, funciones y el grado de desempeo deseados; (2) las
estructuras de datos que permiten que los programas manipulen informacin de manera adecuada; y (3)
los documentos que describen la operacin y uso de los programas. (Pressman)
2 2 C CA AR RA AC CT TE ER R S ST TI IC CA AS S D DE EL L S SO OF FT TW WA AR RE E V VS S H HA AR RD DW WA AR RE E
Para poder comprender lo que es el software, y consecuentemente la Ingeniera de Software, es
importante examinar sus caractersticas diferenciadoras con respecto del hardware. Cuando se construye
hardware, el proceso de creacin (anlisis, diseo, construccin, prueba, etc.) se traduce finalmente en
una forma fsica. As, el boceto inicial, los diagramas formales de diseo y el prototipo de prueba,
evolucionan hacia un producto fsico (chips, tarjetas de circuitos impresos, etc.). Sin embargo, el
software es un elemento del sistema que es lgico, en lugar de fsico. Por tanto, el software tiene unas
caractersticas considerablemente distintas de las del hardware:

El software se desarrolla, no se fabrica en un sentido clsico. (Pressman)

Aunque existen similitudes entre el desarrollo del software y la fabricacin del hardware, ambas
actividades son intrnsecamente diferentes. En ambas actividades la buena calidad se adquiere mediante
un buen diseo, aunque la fase de construccin del hardware puede introducir problemas de calidad que
en el caso del software seran ms fcilmente corregibles. Ambas actividades dependen de las personas,
pero la relacin entre las personas dedicadas y el trabajo realizado es diferente en ambos casos, ya que
el desarrollo de software es un proceso ms intensivo en capital humano que la fabricacin de hardware.
En definitiva, ambas actividades estn orientadas a la construccin de un producto, pero los enfoques
son diferentes.

Un aspecto importante a tener en cuenta al contraponer el hardware frente al software es que el
hardware se fabrica, pero el software no. Esto supone que algunos chips fallan desde el principio y es
casi seguro que casi todos fallarn pasado un tiempo. Por el contrario, como el software no se fabrica,
sino que se desarrolla, si el software se desarrolla correctamente, su duracin en el tiempo estara, a
priori, garantizada, es decir, que se podra afirmar algo as como que si el software sale bien, est bien
siempre.

El software no se estropea, pero se deteriora. (Pressman)

La Figura 1 describe la proporcin de fallos como una funcin del tiempo para el hardware. Esa
relacin, denominada frecuentemente curva de baera, indica que el hardware exhibe relativamente
muchos fallos al principio de su vida atribuibles normalmente a defectos del diseo o de la fabricacin
que no han aflorado hasta el momento. Una vez corregidos estos defectos, la tasa de fallos cae hasta un
nivel estacionario generalmente bastante bajo, donde permanece durante un cierto periodo de tiempo.
Sin embargo, conforme pasa el tiempo, el hardware empieza a desgastarse y la tasa de fallos se
incrementa. El software, al no tener un carcter fsico, no es susceptible a las condiciones del entorno
que hacen que el hardware se estropee. Por tanto, en teora, la curva de fallos para el software tendra la
forma que se muestra en la Figura 2. Los defectos no detectados antes de entregar el software al
usuario, correspondientes tpicamente a un error en el diseo o en el proceso mediante el que se tradujo
el diseo a cdigo mquina ejecutable, harn que el programa falle durante su primera etapa de vida. Sin
embargo, una vez que dichos defectos se corrigen, y suponiendo que al hacerlo no se introducen nuevos
errores, la curva se aplanara tal y como se muestra.

No obstante, la curva idealizada es una simplificacin de los modelos reales de fallos del
software, ya que, debe tenerse en cuenta que aunque el software no se estropea en un sentido fsico, s
se deteriora. Esto que parece una contradiccin, puede comprenderse mejor considerando la curva real
mostrada en la Figura 2. Durante su vida, el software sufre cambios debido a las labores de
mantenimiento. Conforme se realizan los cambios, es probable que se introduzcan nuevos defectos,
haciendo que la curva de fallos tenga picos tal y como se observa en la Figura 2. Antes de que la curva
pueda volver al estado estacionario original, se solicita otro cambio, haciendo que de nuevo se genere
otro pico. Lentamente, el nivel mnimo de fallos comienza a crecer, ya que el software se va deteriorando
debido a los cambios. Los mtodos de Ingeniera de Software se esfuerzan en reducir la magnitud de los
picos as como la inclinacin de la curva.


Figura 1: Curva de Fallos del Hardware. (Pressman)

Figura 2: Curvas de Fallos real e idealizada del Software. (Pressman)
Otro aspecto de ese deterioro ilustra otra diferencia existente entre el hardware y el software.
As, cuando un componente de hardware se estropea se puede sustituir por una pieza de repuesto. Sin
embargo, no hay piezas de repuesto para el software. Por tanto, el mantenimiento del software tiene una
complejidad considerablemente superior al mantenimiento del hardware.

Aunque la industria del hardware tiende a ensamblar componentes, buena parte del software
se construye a medida. (Pressman)

Considrese la forma en la que se disea y se construye un determinado hardware de control.
El ingeniero de diseo construye un esquema de la circuitera digital, realiza un anlisis para asegurar
que se consigue la funcin adecuada y acude entonces a los catlogos de componentes digitales para

seleccionarlos y realizar el correspondiente pedido. Existen numerosos componentes estndar (circuitos
integrados, etc.) que utilizan ingenieros mecnicos, elctricos, etc., cuando disean nuevos sistemas. La
existencia de estos componentes reutilizables facilita el que los ingenieros puedan concentrarse en los
elementos verdaderamente innovadores o diferenciadores de sus diseos. En el mundo del hardware, la
reutilizacin de componentes es una parte natural del proceso de ingeniera.

Sin embargo, la reutilizacin no se realiza al mismo nivel en el mbito del software. Un
determinado mdulo de software debera disearse e implementarse para que pudiera volver a utilizarse
en diferentes sistemas. Un ejemplo de reutilizacin de componentes software son las interfaces grficas
de usuario que se construyen con frecuencia a partir de componentes reutilizables que permiten la
creacin de los elementos necesarios como mens desplegables, etc. A pesar de ello, en la prctica y
por diferentes motivos, buena parte del software sigue construyndose a medida.
3 3 E EV VO OL LU UC CI I N N D DE EL L S SO OF FT TW WA AR RE E
En los orgenes de las computadoras, el principal esfuerzo se inverta en la mejora del hardware,
considerndose el software como algo accesorio y estando ste muy limitado por el hardware. Adems,
el desarrollo de software era artesanal.

Posteriormente, en los aos 70, el coste del hardware se abarata enormemente. Se dispone de
hardware de alto rendimiento y gran capacidad de almacenamiento y memoria, nuevos sistemas de
entrada y salida, sistemas multiusuario, de tiempo real, etc., lo cual permite disponer de sistemas ms
sofisticados y complejos. Esto da lugar al problema de que se necesita desarrollar software ms
complejo pero se cuenta con las mismas tcnicas de desarrollo empleadas hasta el momento lo cual
tiene como consecuencia el hecho de que el coste de mantenimiento del software se dispare, as
aproximadamente del 50% al 70% del trabajo se hace despus de entregar el producto: corregir
errores, incorporar mejoras, etc.

Un crecimiento espectacular de los costes del software, un incumplimiento, muchas veces
sistemtico, de los plazos de entrega y un mar de dudas sobre la calidad de software construido, debido
todo ello al hecho de tener que desarrollar software ms complejo con tcnicas obsoletas, hacen que se
produzca una crisis profunda en la industria del software. La necesidad de desarrollar software ms
complejo hace que surja pareja la necesidad de contar con nuevas tcnicas para su desarrollo, se hace
necesario el paso de la artesana a la ingeniera.
4 4 L LA A I IN NG GE EN NI IE ER R A A D DE E S SO OF FT TW WA AR RE E
La ingeniera podra definirse como el anlisis, diseo, construccin, verificacin y gestin de
entidades tcnicas. Con independencia de la entidad a la que se vaya a aplicar ingeniera, se deben
plantear y responder una serie de preguntas:
- Cul es el problema a resolver?
- Cules son las caractersticas de la entidad que se utilizar para resolver el problema?
- Cmo se construir la entidad?
- Cmo se apoyar la entidad cuando los usuarios soliciten correcciones, adaptaciones y
mejoras de la misma?
- []

El profesional en este mbito recibe el nombre de ingeniero y su actividad se centra en la
concrecin de una idea en la realidad, puesto que, a travs de tcnicas, diseos y modelos, y con el
conocimiento proveniente de las ciencias, y en ocasiones una buena dosis de inventiva e ingenio, la
ingeniera pretende resolver problemas y satisfacer necesidades humanas.

En el caso de la Ingeniera de Software, la entidad a construir ser el software. La Ingeniera de
Software sera la rama de la ingeniera que ofrece mtodos y tcnicas orientadas a desarrollar y
mantener software de calidad. Algunas definiciones formales de Ingeniera de Software son las
siguientes:
- Estudio de los principios y metodologas para el desarrollo y mantenimiento de sistemas de
software. (Zelkovitz)
- Aplicacin prctica del conocimiento cientfico en el diseo y construccin de programas y
la documentacin asociada requerida para desarrollar y operar
1
y mantenerlos. Se conoce
tambin como desarrollo de software o produccin de software. (Boehm)
- Establecimiento y uso de principios slidos de la ingeniera para obtener de forma
econmicamente rentable un software confiable y que funcione de modo eficiente en
mquinas reales. (Bauer)
- Disciplina de la ingeniera que comprende todos los aspectos de la produccin de software
desde las etapas iniciales de la especificacin del sistema hasta el mantenimiento de ste
durante su utilizacin. (Sommerville)
- Disciplina que integra el proceso, las tcnicas, y las herramientas para el desarrollo de
software. (Pressman)
- Aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo,
operacin
2
y mantenimiento del software, es decir, la aplicacin de la ingeniera al software.
(IEEE)
3

La Ingeniera de Software es por tanto la disciplina que se ocupa del software, enfrentndose al
mismo como un producto de ingeniera que requiere planificacin, anlisis, diseo, implementacin,
pruebas y mantenimiento. La Ingeniera de Software tambin incluye las teoras, mtodos y herramientas
que los profesionales del desarrollo del software deben utilizar. La Ingeniera de Software no solo
comprende los procesos tcnicos del desarrollo, sino tambin, los principios ms relevantes de direccin
y control de dicho proceso, as como el desarrollo de nuevas teoras, mtodos y herramientas de apoyo a
la produccin del software. La Ingeniera de Software persigue mejorar la calidad del software, acortar los
tiempos de desarrollo y aumentar la productividad, para lo cual se hace necesario incrementar las
posibilidades de reutilizacin del software. Para lograr este objetivo, los ingenieros de software deben
adoptar un enfoque sistemtico y organizado en su trabajo y utilizar las herramientas y tcnicas ms
apropiadas dependiendo del problema a resolver, las restricciones del desarrollo y los recursos
disponibles.

1
En el sentido de funcionar.
2
En el sentido de funcionamiento.
3
Ntese que aunque la definicin de Ingeniera de Software propuesta por la IEEE fue enunciada en 1993,
la mayora de definiciones de dicha disciplina presentadas en esta seccin son cronolgicamente anteriores. En
concreto, se acuaron en la dcada de los 70, que fue precisamente cuando se produjo esa profunda crisis en la
industria del software que oblig a pasar de artesana a la ingeniera en el mbito del software.

En ocasiones el trmino Ingeniera de Software se intercambia con el de Ciencias de la
Computacin, sin embargo, esto no es correcto, puesto que las Ciencias de la Computacin tienen que
ver con teoras y fundamentos, mientras que la Ingeniera de Software estara ms vinculada a los
aspectos prcticos del proceso de desarrollo del software.

Otro trmino con el que a menudo se intercambia el de Ingeniera de Software es el de
Ingeniera de Sistemas, sin embargo, nuevamente es importante matizar esto, puesto que Ingeniera de
Sistemas e Ingeniera de Software son dos trminos ntimamente relacionados pero no intercambiables
[ver Figura 3].

Un sistema es una coleccin de componentes interrelacionados que trabajan conjuntamente
para cumplir algn objetivo. La Ingeniera de Sistemas consiste en la actividad de especificar, disear,
implementar, validar, distribuir y mantener sistemas como un todo. Por este motivo, los ingenieros de
sistemas no solo estn relacionados con el software, sino tambin con el hardware y con las
interacciones del sistema con los usuarios y su entorno. Es decir, que la Ingeniera de Sistemas es un
campo de trabajo ms amplio que la Ingeniera de Software ya que la Ingeniera de Sistemas tiene que
ver con todos los aspectos del desarrollo de sistemas basados en computadoras, incluyendo hardware y
software, mientras que la Ingeniera de Software se centrara nicamente en una parte de todo el
proceso.

Figura 3: Ingeniera de Sistemas vs Ingeniera de Software.
El trabajo que tpicamente se asocia a la Ingeniera de Software se puede dividir en tres fases
genricas: definicin, desarrollo y mantenimiento, con independencia del rea de aplicacin, tamao o
complejidad del proyecto.

Definicin. La fase de definicin se centra en el qu. As, durante esta fase se intenta identificar
qu informacin ha de ser procesada, qu comportamiento se espera del sistema, qu restricciones
existen, etc. En definitiva, las tareas principales sern la captura de informacin, la planificacin del
proyecto software y el anlisis de los requisitos.

Desarrollo. La fase de desarrollo se centra en el cmo. As, durante esta fase se intenta definir
cmo se disearn las estructuras de datos, cmo se traducir el diseo a cdigo, etc. En definitiva, las
tareas principales sern el diseo del software, la generacin de cdigo y las pruebas del software.

Mantenimiento. La fase de mantenimiento se centra en gestionar los cambios de diferentes
tipos que podr sufrir el software:

- Correccin. A pesar de llevar a cabo actividades para garantizar la calidad del software, es
muy probable que se descubran errores. El mantenimiento correctivo tendr por objetivo
cambiar el software para corregir sus defectos.
- Adaptacin. Con el paso del tiempo, es probable que cambie el entorno original para el que
se desarroll el software. El mantenimiento adaptativo modifica el software para acomodarlo
a los cambios de su entorno externo.
4

- Mejora. Conforme se utilice el software, el usuario puede descubrir funciones adicionales
que produciran beneficios. El mantenimiento perfectivo lleva al software ms all de sus
requisitos funcionales originales.
- Prevencin. El software se deteriora debido al cambio, por este motivo, el mantenimiento
preventivo tambin denominado reingeniera del software, intenta realizar cambios en el
software para que este se pueda corregir, adaptar y mejorar ms fcilmente.

Adems de estas actividades de mantenimiento, los usuarios de software requieren de una
asistencia continuada que se puede proporcionar mediante diversos mecanismos: ayuda en lnea, etc.
Ya que, cuando se emplea el trmino mantenimiento se entiende que es una actividad que va mucho
ms que una simple correccin de errores.

Las actividades descritas en las diferentes fases se complementan con un nmero de
actividades de carcter protector como el seguimiento y control del proyecto de software, la garanta de
calidad del software, la documentacin, la gestin de reutilizacin o la gestin de los riesgos potenciales.
5 5 E EL L P PR RO OC CE ES SO O D DE EL L S SO OF FT TW WA AR RE E
Al hablar de software puede hacerse hincapi tanto en el producto final (el software como un
producto) como en su proceso de desarrollo (el proceso del software). Esta seccin se centra en la
vertiente del software como proceso.

El proceso del software y la Ingeniera de Software son trminos ntimamente relacionados, as,
un proceso de software define el enfoque que se aplica cuando el software es tratado utilizando una
aproximacin ingenieril tal y como hace la Ingeniera de Software. Pero la Ingeniera de Software
necesita tambin de las tcnicas, incluyendo la notacin que estas emplean, y de las herramientas
vinculadas al proceso.

Podra decirse que la Ingeniera de Software necesita de un mtodo, puesto que se hace
necesario establecer un enfoque sistemtico y disciplinado para llevar a cabo un desarrollo software.
Definiciones posibles para el trmino mtodo en este contexto seran las siguientes:
- Una metodologa de Ingeniera de Software es un proceso para producir software de forma
organizada, empleando una coleccin de tcnicas y convenciones de notacin predefinidas.
(James Rumbaugh et al.)
- Conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a
los desarrolladores a realizar nuevo software. (Mario Piattini et al.)

4
Por ejemplo, cambios en el sistema operativo, cambios en las reglas del negocio, etc.

Figura 4: Qu necesita la Ingeniera de Software?
En resumen, las componentes del mtodo necesario en la Ingeniera de Software seran un
proceso, una serie de tcnicas con su notacin y un conjunto de herramientas. El proceso define el
marco de trabajo y permite un desarrollo racional de la Ingeniera de Software. Las tcnicas indican cmo
construir tcnicamente el software e incluyen tcnicas de modelado. Y las herramientas proporcionan el
soporte automtico o semiautomtico para el proceso y para las tcnicas. En definitiva, la Ingeniera de
Software requiere de un Proceso
5
, de una serie de tcnicas que hacen uso de una Notacin
6
y de una
serie de Herramientas
7
. [ver Figura 4]

Proceso:

Cuando se trabaja para construir un producto o un sistema software, es importante
seguir una serie de pasos predecibles, algo as como una hoja de ruta que ayude a obtener un
resultado con el nivel de calidad deseado. La hoja de ruta a seguir es lo que se denomina
proceso del software.

Los ingenieros de software y sus gestores adaptarn el proceso del software a las
necesidades de cada proyecto del que deban hacerse cargo. Adems, los clientes que hayan
solicitado el software debern, idealmente, colaborar en dicho proceso. Desde el punto de vista
del ingeniero de software, se podra decir que los productos obtenidos al finalizar el proceso
sern programas, documentos y datos que se producirn como consecuencia de las actividades
de Ingeniera de Software definidas por el proceso.

La Ingeniera de Software necesita de un proceso porque este proporciona una
aproximacin metdica, documentada y reproducible. El proceso del software es importante
porque proporciona estabilidad, control y organizacin a una actividad que, de otra forma, podra
volverse catica. El proceso facilita optimizar el desarrollo, acudiendo a la paralelizacin de
tareas y a la reutilizacin de resultados cuando resulte posible, as como minimizar los riesgos
que puedan presentarse. Adems, existen diversos mecanismos de evaluacin del proceso del

5
En esta asignatura el proceso que se seguir ser el Proceso Unificado (UP, Unified Process) de
Desarrollo de Software.
6
En esta asignatura la notacin a utilizar ser el Lenguaje de Modelado Unificado (UML, Unified Modelling
Language).
7
En esta asignatura la herramienta CASE UML a utilizar ser Astah.

software que permiten a las organizaciones determinar la madurez de su proceso del software.
Sin embargo, la calidad a largo plazo del producto que se est construyendo, y que ser
necesario mantener, es el mejor indicador de la eficiencia del proceso que se est utilizando.

El proceso del software se puede caracterizar estableciendo un marco de trabajo
comn que defina actividades aplicables a todos los proyectos de software, con independencia
de su tamao, complejidad o dominio de aplicacin. As como una serie de tareas propias de la
Ingeniera de Software vinculadas a cada actividad definida que permiten que el proceso se
adapte a las caractersticas concretas del proyecto de software que se desarrolle. Y, finalmente,
unas actividades de proteccin, tales como la garanta de calidad del software, que sean
independientes de cualquier actividad del marco de trabajo y que estarn presentes durante
todo el proceso.

Las actividades definidas en el marco del proceso del software se denominan, en
algunos textos, reas Clave de Proceso (ACPs), describen las funciones propias de la
Ingeniera de Software (planificacin del proyecto de software, gestin de requisitos, etc.),
forman la base del control de la gestin de proyectos de software y establecen el contexto en el
que se aplica la metodologa, se obtienen productos del trabajo (modelos, documentos, etc.), se
establecen hitos, etc. Cada ACP se describe identificando sus objetivos, los requisitos
impuestos junto a los objetivos, las capacidades o elementos de carcter organizativo y tcnico
necesarios y las tareas especficas que deben llevarse a cabo para cumplir los objetivos, los
mtodos para implementar dichas tareas y los mtodos para verificar su implementacin.

Tcnicas y Notacin:

Las tcnicas indican cmo construir tcnicamente el software. Las tcnicas de la
Ingeniera de Software incluyen actividades de modelado y otras tcnicas descriptivas en las
que se hace uso de una notacin. El lenguaje natural que el ser humano maneja habitualmente
es vago, ambiguo e interpretable segn intereses, y esto hace necesaria una notacin estndar
que resulte visual y adecuada para dialogar con el cliente, a la par que detallada y sin
ambigedades para intercambiar informacin con los ingenieros de software.

Herramientas:

Las herramientas proporcionan un enfoque automtico o semiautomtico para el proceso y
para las tcnicas, establecindose un sistema de soporte para el desarrollo del software denominado
Ingeniera de Software Asistida por Ordenador (CASE, Computer Aided Software Engineering). Las
herramientas son necesarias porque facilitan el seguir el proceso y el utilizar las tcnicas y su notacin,
ayudan a la gestin de versiones o reducen el trabajo de codificacin
8
. [ver Figura 5]

8
El trmino codificacin en este contexto, se refiere a la generacin o creacin del cdigo.

Figura 5: Vista de la herramienta CASE Astah.
6 6 M MO OD DE EL LO OS S D DE E P PR RO OC CE ES SO O D DE EL L S SO OF FT TW WA AR RE E
6 6. .1 1 M MO OD DE EL LO O D DE E P PR RO OC CE ES SO O O O C CI IC CL LO O D DE E V VI ID DA A D DE EL L S SO OF FT TW WA AR RE E
Para acometer los proyectos de software, los ingenieros de software deben incorporar una
estrategia de desarrollo que acompae a las tcnicas y herramientas y a las fases genricas del proceso
del software. Esta estrategia a menudo se denomina modelo de proceso o ciclo de vida del software o
paradigma de Ingeniera de Software. Se seleccionar un modelo de proceso u otro segn la naturaleza
del proyecto y de la aplicacin, las tcnicas y las herramientas a utilizar, y los controles y entregas que se
requieran. Un modelo de proceso proporciona una vista de las actividades que se llevan a cabo durante
su desarrollo, e intenta determinar el orden de las etapas involucradas y proporcionar unos criterios para
avanzar de unas a otras. Por tanto, definir un ciclo de vida permite llevar un mayor control sobre las
tareas, evitando que estas se vayan eligiendo y realizando de manera desordenada, segn parezca que
van surgiendo necesidades.
6 6. .2 2 E EL L M MO OD DE EL LO O C CL L S SI IC CO O O O M MO OD DE EL LO O E EN N C CA AS SC CA AD DA A
El Modelo Clsico, en ocasiones denominado Ciclo de Vida Bsico o Modelo en Cascada
9
[ver
Figura 6], es un modelo lineal que sugiere un enfoque sistemtico y secuencial para el desarrollo de

9
En los textos ingleses al Modelo Clsico o Modelo en Cascada se le denomina Waterfall Model.

software que progresa con el Anlisis, Diseo, Codificacin, Pruebas y Mantenimiento. En concreto, el
modelo lineal secuencial comprende las siguientes actividades:

Captura de Requisitos (Anlisis). Como el software por lo general siempre forma parte de un
sistema ms grande, el trabajo comienza estableciendo los requisitos del sistema y asignando al
software algn subconjunto de estos requisitos. Para comprender la naturaleza del software que debe
construirse, el ingeniero de software debe comprender el dominio al que pertenece dicha aplicacin
software, as como la funcin requerida, comportamiento, rendimiento e interconexin. En definitiva, la
etapa de Anlisis implica entender:
- El dominio de aplicacin del software.
- Qu debe hacer el software, es decir, su funcionalidad.
- Otras restricciones: eficiencia, uso de recursos, seguridad, conectividad, etc.

Diseo del Sistema. El diseo del software es un proceso que se centra en las estructuras de
datos, la arquitectura del software y el detalle procedimental (algoritmo). El proceso del diseo traduce
requisitos en una representacin del software donde se pueda evaluar su calidad antes de que comience
la codificacin. En definitiva, la etapa de Diseo implica pensar en cmo se va a hacer el software, lo cual
supone organizar la arquitectura del software y detallar cmo los mdulos implementarn la
funcionalidad.

Figura 6: Modelo Clsico o Modelo en Cascada lineal secuencial .
10

Codificacin y pruebas aisladas. El diseo se debe traducir en una forma legible por la
mquina. En la fase de Codificacin se lleva a cabo la generacin del cdigo. Si el diseo se lleva a cabo
de una forma detallada, la generacin de cdigo se podr realizar de una forma bastante mecnica. En
esta etapa se codifica cada mdulo y se prueba por separado.

10
En los textos ingleses las fases del Modelo Clsico o en Cascada se denominan Analysis,
Design, Implementation, Testing y Deployment.

Integracin y Pruebas de Sistema. Una vez que se ha generado todo el cdigo, comienzan las
pruebas del programa. El proceso de pruebas se centra tanto en los procesos lgicos internos del
software, asegurando que todas las sentencias se han comprobado, como en los procesos externos
funcionales, lo que supone realizar las pruebas necesarias para asegurar que las entradas producen
resultados reales de acuerdo con los planificados. En definitiva, esta etapa consiste en juntar todos los
mdulos y probarlos, para asegurarse de que el programa cumple con la funcionalidad para la cual se ha
diseado, y que, por tanto, se satisfacen los requisitos de partida.

Uso y Mantenimiento. El software probablemente sufrir cambios despus de ser entregado al
cliente. Se realizarn cambios porque se han encontrado errores, porque el software debe adaptarse a
los cambios de su entorno externo (cambio en el sistema operativo, etc.) o porque el cliente requiere
mejoras (funcionales, de rendimiento, etc.). En esta etapa se vuelve a aplicar cada una de las fases
precedentes a un programa ya existente y no a uno nuevo. En definitiva, en esta etapa se debe instalar el
software en las mquinas del cliente o en el servidor correspondiente y mantenerlo adecuadamente.

El modelo clsico es el paradigma ms antiguo y extensamente utilizado en la Ingeniera de
Software y resulta un enfoque razonable cuando los requisitos se han entendido correctamente y se trata
de un sistema simple. Como principales ventajas cabe sealar el hecho de que se trata de un proceso
muy bien definido y que consta de tareas repartibles a individuos o a grupos.

Sin embargo, es un modelo no exento de crticas y su eficacia ha sido puesta en duda. Entre los
problemas que se encuentran algunas veces en el modelo clsico se cuentan los siguientes:
- Los proyectos reales raras veces siguen el esquema secuencial que propone el modelo
11
. A
menudo es difcil que el cliente exponga explcitamente todos los requisitos. El modelo
lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre
natural existente al comienzo en muchos proyectos. As, por ejemplo, es casi imposible
conocer, en el instante inicial, un sistema complejo y de grandes dimensiones al detalle, y
este modelo requiere que esto sea as antes de poder avanzar desde la fase de Anlisis
hacia la fase de Diseo.
- El cliente debe tener paciencia. Una versin de trabajo del software no estar disponible
hasta que el proyecto est muy avanzado. Y en grandes proyectos, cada fase puede ser
considerablemente larga. Adems, un error grave puede ser desastroso si no se detecta
hasta que se revise el software. De hecho, este modelo hace que el riesgo se traslade a
etapas posteriores del proceso, ya que los problemas ms importantes se suelen identificar
en etapas avanzadas, especialmente durante la etapa de Integracin y pruebas del sistema,
cuando, irnicamente el coste de rectificar errores aumenta exponencialmente a medida
que el tiempo pasa. [ver Figura 7]

11
El modelo original en cascada propuesto por Winston Royce prevea bucles de realimentacin, no
obstante, la gran mayora de las organizaciones que aplican este modelo de proceso lo hacen como si fuera
estrictamente lineal, lo cual implica que cada etapa debe completarse totalmente antes de que la siguiente pueda
comenzar.

Figura 7: Representacin del Riesgo y del Coste de Rectificar Errores en el Modelo Clsico o Modelo en Cascada
lineal secuencial . (Ariadne)
En el Modelo Clsico o Modelo en Cascada, en cada etapa se pueden descubrir fallos de la
etapa anterior y, en esta situacin qu hacer?, se para todo el proceso y se vuelve al principio? o se
sigue con los fallos hasta el final? Adems, est el problema de cmo proceder si se descubren nuevos
requisitos o si los ya existentes cambian.

El paradigma del ciclo de vida clsico tiene un lugar importante en el mbito de la Ingeniera de
Software, porque, pese a sus puntos dbiles es significativamente mejor que un enfoque al azar para el
desarrollo del software. No obstante, falla cuando la complejidad y el tamao del proyecto al que
debemos enfrentarnos se incrementa. Es decir, este modelo de proceso se adecua a proyectos
suficientemente pequeos. La definicin de suficientemente pequeo es obviamente subjetiva, pero se
referira a proyectos que puedan ser abordados por equipos reducidos donde cada miembro del equipo
pueda conocer los diferentes aspectos del sistema y donde la duracin del ciclo de vida se mantenga en
unos lmites de tiempo razonables.
6 6. .3 3 E EL L M MO OD DE EL LO O E EN N E ES SP PI IR RA AL L
Un enfoque alternativo al Modelo en Cascada es el Modelo en Espiral
12
. Este modelo propone
abordar el proyecto de desarrollo software al que nos enfrentemos en una serie de ciclos de vida cortos
(Anlisis, Diseo, Codificacin y Pruebas)
13
, al final de cada uno de los cuales se debe producir una
versin ejecutable del software en cuestin. [ver Figura 8]

12
En los textos ingleses al Modelo en Espiral se le denomina Spiral Model.
13
En los textos ingleses las fases del Modelo en Espiral se denominan Analysis, Design, Code y
Test.

Este enfoque iterativo permite recibir retroalimentacin del cliente de forma ms frecuente, en
concreto, al final de cada ciclo, lo cual permite identificar y abordar problemas antes de haber llegado
demasiado lejos en el proyecto. El riesgo puede manejarse de forma ms adecuada ya que los ciclos
ms arriesgados, en los que, por ejemplo, haya que trabajar con una tecnologa nueva an no validada,
pueden abordarse primero. Este modelo tambin permite incorporar de forma ms sencilla los cambios
que pudieran tener lugar en los requisitos. Sin olvidar el hecho de que el producir versiones de software
tras cada ciclo, que no debera ser excesivamente largo, imprime moral al equipo de desarrolladores que
ven el fruto de su trabajo y satisface igualmente al cliente.

Figura 8: Representacin de un proceso espiral de desarrollo software en el que se ha dividido el proyecto en cinco
fases, cada una basada en la anterior y de forma que al final de cada fase se disponga de una versin de software
ejecutable. (Ariadne)
No obstante, este modelo tampoco est exento de crticas, ya que el proceso en este caso es
ms difcil de gestionar que en el Modelo en Cascada en el cual pueden utilizarse de manera sencilla
tcnicas de gestin de proyectos clsicas como los Diagramas de Gantt
14
.
6 6. .4 4 E EL L M MA AR RC CO O D DE E T TR RA AB BA AJ JO O I IT TE ER RA AT TI IV VO O E E I IN NC CR RE EM ME EN NT TA AL L
Para contrarrestar las desventajas del Modelo en Espiral se propone un enfoque similar, pero
ms formal, denominado Marco de Trabajo Iterativo e Incremental
15
. Este enfoque es por tanto una
extensin lgica del Modelo en Espiral pero ms rigurosa. Este marco de desarrollo divide el trabajo a
desarrollar en cuatro grandes fases: Arranque o Inicio, Elaboracin, Construccin y Transicin
16
[ver
Figura 9], que no deben confundirse con las fases del Modelo Clsico o Modelo en Cascada, aunque

14
Herramienta grfica cuyo objetivo es mostrar el tiempo de dedicacin previsto para diferentes tareas o
actividades a lo largo de un periodo determinado.
15
En los textos ingleses al Marco de Trabajo Iterativo e Incremental se le denomina Iterative
Incremental Framework.
16
En los textos ingleses las fases del Marco de Trabajo Iterativo e Incremental se denominan
Inception, Elaboration, Construction y Transition.

tambin se desarrollen de forma secuencial. La Fase de Construccin incorpora habitualmente una serie
de iteraciones
17
similares al proceso propuesto en el Modelo Clsico o Modelo en Cascada [ver Figura
10] y es, habitualmente, la de mayor duracin [ver Figura 11].

Figura 9: Fases del Marco de Trabajo Iterativo e Incremental. (Ariadne)

Figura 10: La Fase de Construccin del Marco de Trabajo Iterativo e Incremental comprende una serie de
iteraciones similares al proceso propuesto por el Modelo Clsico o Modelo en Cascada. (Ariadne)
El ejemplo ms famoso de un Ciclo de Vida Iterativo e Incremental es el Proceso Unificado de
Desarrollo de Software (Unified Software Development Process) que ser el que se aplique para el
trabajo en la presente asignatura por ser el Modelo de Proceso de Software dominante en la Ingeniera
de Software moderna.

17
En algunos textos, a las iteraciones del Marco de Trabajo Iterativo e Incremental se les denomina
incrementos.
El resto de fases podran incorporar interacciones, pero en la prctica es poco habitual.

Figura 11: Posible duracin de cada fase en el Marco de Trabajo Iterativo e Incremental para un proyecto de dos
aos de duracin. La Fase de Construccin que comprende una serie de iteraciones similares al proceso propuesto
por el Modelo Clsico o Modelo en Cascada ser tpicamente la de mayor duracin. (Ariadne)
6 6. .5 5 E EL L P PR RO OC CE ES SO O U UN NI IF FI IC CA AD DO O D DE E D DE ES SA AR RR RO OL LL LO O D DE E S SO OF FT TW WA AR RE E
El Proceso Unificado de Desarrollo de Software, que fue propuesto por Rumbaugh, Booch y
Jacobson, pretende ser un marco de proceso genrico y extensible que pueda ser adaptado a
organizaciones, equipos o proyectos especficos. Sus principales caractersticas son las siguientes:

Utiliza el Lenguaje de Modelado Unificado (UML, Unified Modelling Language) como
lenguaje de modelado. [ver seccin 7 El Lenguaje de Modelado Unificado]

Es un marco de desarrollo iterativo e incremental. Esto supone que es un marco de trabajo
que propone mltiples ciclos cada uno comprendiendo las fases de Arranque o Inicio, Elaboracin,
Construccin y Transicin. En este marco de desarrollo, cada una de las fases anteriores comprende a
su vez una serie de iteraciones que ofrecen como resultado un incremento del producto desarrollado, que
aade o mejora las funcionalidades del sistema en desarrollo.

Durante cada una de estas iteraciones se realizarn a su vez una serie de actividades que, tal
y como es sabido, recuerdan a las definidas en el Modelo Clsico o Modelo en Cascada: Requisitos,
Anlisis, Diseo, Implementacin y Pruebas (e Implantacin).
18

Aunque todas las iteraciones suelen incluir trabajo en casi todas estas actividades, el grado de
esfuerzo dedicado a cada una de ellas vara a lo largo del proyecto. As por ejemplo, la fase de Arranque
o Inicio se centrar ms en la definicin de Requisitos y en el Anlisis, actividades que durante la fase de

18
En definitiva, el Proceso Unificado comprende mltiples ciclos de cuatro fases (Arranque o Inicio,
Elaboracin, Construccin y Transicin), cada fase a su vez con mltiples iteraciones, y en cada iteracin se podrn
desarrollar cinco tipos de actividades (Requisitos, Anlisis, Diseo, Implementacin y Pruebas (e Implantacin)).
Ntese, no obstante, que algunos autores proponen que solo se incluyan iteraciones en la fase de Construccin, de
forma que las fases de Arranque o Inicio y Elaboracin se mantengan sencillas.

Construccin quedarn relegadas a favor, por ejemplo, de las actividades de Implementacin y Pruebas
[ver Figura 12].

Si una iteracin cumple sus metas, publicando una nueva versin del producto que implemente
ciertos Casos de Uso
19
, el desarrollo contina con la siguiente. Cuando no las cumple, los
desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.

El hecho de que sea un proceso iterativo e incremental reduce riesgos, ya que se puede
comenzar trabajando sobre los aspectos menos claros para volver sobre ellos hasta encontrar una
solucin adecuada, y permite acomodar requisitos cambiantes.

Est guiado por los Casos de Uso. Un sistema software se crea para dar respuesta a las
necesidades de sus usuarios por lo que, para construir un sistema exitoso, se debe conocer qu es lo
que realmente quieren y necesitan. El trmino usuario no se refiere solamente a los usuarios humanos
sino tambin a otros sistemas software, es decir, se refiere a algo o alguien que interacta con el sistema
a desarrollar.

En el Proceso Unificado de Desarrollo de Software, los Casos de Uso permiten capturar los
denominados Requisitos Funcionales
20
a la par que definir el objetivo y contenido de las iteraciones. La
idea es que cada iteracin tome un conjunto de Casos de Uso y desarrolle el camino de manera
completa a travs de las distintas actividades: Diseo, Implementacin, etc. En cada iteracin, los
desarrolladores identifican y especifican los Casos de Uso relevantes, crean el diseo, lo implementan en
componentes y verifican que los componentes satisfacen los Casos de Uso.

El que el Proceso Unificado de Desarrollo de Software sea un proceso guiado por Casos de Uso
permite capturar el valor aadido del sistema software para el cliente, es decir, especificar qu
proporciona el sistema software al cliente en un lenguaje que el cliente entienda.

Tambin se cuenta con una gua para todo el proceso, as los Casos de Uso inician el proceso y
son el nexo entre las actividades desarrolladas en las iteraciones ya que aparecen representados de
forma subyacente en todos los artefactos utilizados para el modelado. Adems la utilizacin de Casos de
Uso facilita el desarrollo iterativo, la realizacin de documentacin y constituyen el plan de pruebas.

Est Centrado en la Arquitectura. El concepto de arquitectura del software
21
involucra los
aspectos estticos y dinmicos ms significativos del sistema, dando una perspectiva completa y

19
Los Casos de Uso son una tcnica del Lenguaje de Modelado Unificado que permite capturar
informacin acerca de cmo trabaja un sistema actualmente y de cmo se desea que trabaje. Adems se trata de
una tcnica que pone nfasis en la relacin del sistema con el exterior. Permite la captura de requisitos (funcionales)
y sirve igual para un enfoque procedimental que para una filosofa orientada a objetos. Un Caso de Uso puede
definirse como una interaccin tpica entre el usuario y el sistema que captura una funcin visible al usuario y logra
un objetivo del usuario que puede ser grande o pequeo. Los Casos de Uso se pueden representar visualmente a
travs de los Diagramas de Casos de Uso, en los que adems de los Casos de Uso como tal, representados por un
valo con su nombre, aparecen los Actores de dichos Casos de Uso representados por un monigote con su nombre.
A travs del Diagrama de Casos de Uso del sistema se puede representar quines usan el sistema: roles de
personas, mquinas u otros sistemas software, y saber qu quieren del sistema, adems de determinar qu est
dentro del sistema y qu queda fuera. Vase ms informacin en el documento dedicado a este tema de forma
especfica.
20
Un Requisito Funcional es una caracterstica requerida del sistema que expresa una capacidad de
accin del mismo, es decir, una funcionalidad, generalmente expresada en una declaracin en forma verbal. Vase
ms informacin sobre el concepto de Requisito Funcional en el documento dedicado a este tema de forma
especfica.
21
El Proceso Unificado de Desarrollo de Software asume que no existe un diagrama nico que cubra todos
los aspectos del sistema. Por dicho motivo existen mltiples diagramas o vistas que definen la arquitectura de

describiendo los elementos ms importantes. La arquitectura surge de los propios Casos de Uso, sin
embargo, tambin est influenciada por muchos otros factores, como la plataforma en la que se
ejecutar, el uso de estndares o los Requisitos No Funcionales
22
. Los Casos de Uso debern poder
acomodarse en la arquitectura que debe ser lo bastante flexible para realizar todos los Casos de Uso,
hoy y en el futuro. De hecho, arquitectura y Casos de Uso deberan evolucionar en paralelo.

El Proceso Unificado de Desarrollo de Software es un proceso centrado en la arquitectura
porque los Casos de Uso no resultan suficiente. La arquitectura permite organizar cmo el software
cumplir los requisitos, decidiendo los subsistemas y sus interfaces, qu hace cada subsistema y si un
subsistema pueden construirse a partir de otros subsistemas.

Est Enfocado a los Riesgos. Para disminuir la posibilidad de fallo en las iteraciones o incluso
la posibilidad de cancelacin del proyecto, se deben llevar a cabo sucesivos anlisis de riesgos durante
todo el proceso. Los riesgos crticos deberan identificarse en una etapa temprana del ciclo de vida del
sistema software, en este sentido, los resultados de cada iteracin de las diferentes fases deberan
seleccionarse en un orden que asegure que dichos riesgos se considerarn en primer lugar.

Figura 12: Ciclo de Vida especificado por el Proceso Unificado de Desarrollo de Software: Fases, Iteraciones y
Actividades. El Proceso Unificado de Desarrollo de Software es iterativo e incremental. Es un proceso organizado en
mltiples ciclos de cuatro fases, cada una de ellas a su vez con mltiples iteraciones y cada iteracin con cinco
posibles actividades.
Como ya se ha comentado, el Proceso Unificado de Desarrollo de Software se organiza en una
serie de ciclos que constituyen la vida de un sistema. Cada ciclo se compone de cuatro fases: Arranque o
Inicio, Elaboracin, Construccin y Transicin, y dentro de cada una de ellas, los desarrolladores pueden
descomponer adicionalmente el trabajo en iteraciones, cada una de ellas con cinco posibles actividades:
Requisitos, Anlisis, Diseo, Implementacin y Pruebas (e Implantacin), con sus incrementos

software de un sistema, de igual forma que cuando se construye un edificio existen diversos planos que incluyen los
distintos servicios del mismo: electricidad, fontanera, etc.
22
Un Requisito no Funcional es una caracterstica requerida del sistema, del proceso de desarrollo o del
servicio prestado, que tpicamente seala una restriccin del mismo. Vase ms informacin sobre el concepto de
Requisito Funcional en el documento dedicado a este tema de forma especfica.

resultantes. Adems, peridicamente se alcanzan hitos en forma de la disponibilidad de un determinado
artefacto o diagrama de modelado
23
y/o documento de especificacin. [ver Figura 12]
6.5.1 Fases del Proceso Unificado de Desarrollo de Software
A continuacin se describe brevemente cada una de las Fases del Proceso Unificado de
Desarrollo de Software:

Fase de Arranque o Inicio. En esta fase, que terminar al alcanzar el hito de los objetivos del
desarrollo, se realizarn tpicamente las siguientes tareas:
- Desarrollar una descripcin del producto final
24
, as como un adecuado anlisis del
negocio al que este pertenece.
- Realizar una identificacin inicial de riesgos y estudiar la viabilidad, para poder determinar
si es factible o no llevar a cabo el proyecto.
- Capturar los Requisitos iniciales. Establecer las principales funciones del sistema para
los usuarios ms importantes.

Algunos de los entregables que podran producirse en esta fase son los siguientes
documentos
25
:
- Documento de Visin del sistema software que bsicamente incluye la Descripcin
Informal del sistema software, acompaada, de forma muy frecuente, por el diseo del
prototipo de la Interfaz de Usuario.
- Glosario del proyecto software con especial atencin a todo lo relativo a la lgica del
dominio o negocio abordado.
- Catlogo de Especificacin de Requisitos inicial del sistema software.
- Diagrama de Casos de Uso inicial.
- Documento de Evaluacin de Riesgos inicial del proyecto software. Incluir los riesgos
tcnicos, de recursos o del negocio vinculados al proyecto, y que formule asimismo un plan
con medidas preventivas y correctivas para abordar cada uno de los riesgos identificados
en caso de que estos se presenten. Es decir, no se trata de una simple identificacin de
riesgos potenciales sino de prever una adecuada gestin de los mismos en caso de que
estos tengan lugar.

23
El Lenguaje de Modelado Unificado es un lenguaje grfico de modelado que proporciona la sintaxis para
describir los elementos principales de un sistema software. Estos elementos principales de un sistema software,
modelados adecuadamente, es lo que en el contexto de UML se denominan artefactos, siendo artifacts el
trmino utilizado en los textos ingleses.
24
Si el sistema software bajo estudio es una evolucin de uno ya existente, o bien est fuertemente
vinculado con algn otro sistema ya existente con el que, por ejemplo, debe interactuar, sera necesario un buen
conocimiento de dichos sistemas preexistentes.
25
En documentos posteriores se describen con detalle aquellos entregables de esta fase que se utilizarn
en la presente asignatura como herramientas de trabajo. La descripcin de otros de los posibles entregables a
generar en la Fase de Arranque del Proceso Unificado de Desarrollo de Software como el Plan de Negocio exceden
los objetivos de la presente asignatura.

- Plan de Negocio que deber incluir la informacin relativa a los criterios de xito y a la
planificacin financiera del proyecto software.
- Plan del Proyecto que incluir una planificacin general del proyecto software a desarrollar.
- Plan de Fase que es una estimacin gruesa de la duracin y esfuerzo requeridos para la
Fase de Elaboracin subsiguiente.
- Plan de Iteracin que describe qu se har durante la primera iteracin de la Fase de
Elaboracin subsiguiente.
- Plan de Desarrollo que es la propuesta o seleccin de herramientas de desarrollo,
actividades de formacin y recursos adicionales que en este sentido pudieran resultar
necesarios.
- Marco de Desarrollo que es la descripcin de los pasos del Proceso Unificado de
Desarrollo de Software y de los artefactos UML a generar en cada momento considerados
ms adecuados para este proyecto software, es decir, la adaptacin del Proceso Unificado
de Desarrollo de Software para este proyecto software en particular.
- []

Siguiendo los principios del desarrollo iterativo, no es necesario desarrollar una versin final de
todos y cada uno de los documentos anteriores, sino que bastar con realizar el trabajo suficiente como
para cumplir el objetivo principal de esta fase que es entender lo suficiente el problema a abordar en el
proyecto software como para decidir su viabilidad, es decir, para decidir si el sistema software se puede
realizar con la tecnologa y recursos disponibles y en el plazo fijado y si podra integrarse con otros
sistemas existentes. Debe recordarse adems que cualquier documento de los mencionados es opcional
y que su utilidad depender del problema a abordar. Adems, en la prctica siempre es ms til
restringirse a unos pocos documentos, los imprescindibles como para poder desarrollar el trabajo en el
proyecto software concreto de forma satisfactoria, en vez de dispersar esfuerzos en demasiados
documentos que no se piense que resultarn de utilidad.

La duracin de esta etapa puede variar enormemente de unos casos a otros ya que el trabajo en
esta fase puede consistir en una breve conversacin con el cliente, o bien, dicho contacto con el cliente
puede prolongarse durante varias semanas e involucrar el uso de diferentes mecanismos como
formularios, etc., hasta lograr tener una idea clara de sus necesidades que permita confeccionar la
documentacin a generar durante esta fase. No obstante, esta fase suele ser corta e, idealmente, no
debera alargarse demasiado en el tiempo. En caso contrario, podra existir una excesiva especificacin
inicial, lo cual ira en contra del enfoque relativamente gil del Proceso Unificado de Desarrollo de
Software.

Durante esta fase, el trabajo estar ms centrado en la Captura de Requisitos
26
y en el Anlisis
que en el resto de Actividades a desarrollar en las iteraciones de las diferentes Fases del Proceso
Unificado de Desarrollo de Software: Diseo, Implementacin y Pruebas, aunque tambin se puede
abordar alguna de estas actividades, por ejemplo la de Diseo, a travs de la realizacin de prototipos de
la Interfaz de Usuario (UI, User Interface) durante esta fase que, tpicamente, se incluirn en el
Documento de Visin del Sistema.

26
En los textos ingleses la Captura de Requisitos se denomina Requirements Elicitation.
Vase ms informacin en el documento dedicado a este tema de forma especfica.

Fase de Elaboracin. Durante esta fase deberan capturarse la mayora de Requisitos del
sistema y elaborarse la mayora de Casos de Uso. En esta fase, que terminar al alcanzar el hito de la
arquitectura inicial del sistema, se realizan tpicamente las siguientes tareas:
- Definir de forma precisa los riesgos y las prioridades.
- Capturar la mayora de los Requisitos.
- Elaborar la mayora de los Casos de Uso.
- Crear un plan para la siguiente fase incluyendo asignacin de recursos humanos, tcnicos,
etc.

Al finalizar esta fase se deber haber alcanzado la comprensin general del proyecto completo.
No obstante, en este punto no es necesario alcanzar un conocimiento profundo de todos y cada uno de
los aspectos del sistema, ya que dicho conocimiento profundo se adquirir en fases posteriores y en
relacin a, nicamente, una parte del sistema en cada iteracin.

Fase de Construccin. Es la fase ms larga del ciclo de vida. Completa la implementacin del
sistema tomando como base el resultado obtenido durante la fase de Elaboracin. A partir del mismo, las
distintas funcionalidades se incluirn en distintas iteraciones, al final de cada una de las cuales se
obtendr una nueva versin ejecutable del producto. Por tanto, esta fase concluye con el hito de
obtencin de una funcionalidad completa, que capacite al producto para funcionar en un entorno de
produccin. En esta fase se realizan tpicamente las siguientes tareas:
- Completar la captura de Requisitos.
- Completar el Diseo.
- Llevar la Arquitectura a un sistema completo.
27

Fase de Transicin. En la fase final del proyecto se lleva a cabo el despliegue del producto en
el entorno de los usuarios, lo que incluye la formacin de los mismos en su uso y quizs en su
administracin. Por otra parte, en lo relativo al propio producto software:
- Evoluciona desde la fase beta a una versin final gracias a la retroalimentacin recogida
sobre las versiones preliminares.
- Se trata de resolver incidencias en lo relativo a la integracin y a la implantacin, y se
clasifican y documentan aquellas que podran justificar una nueva versin del producto.

Esta fase concluye con el hito de lanzamiento o publicacin del producto por lo que no debera
confundirse con la fase de Integracin y Pruebas del Sistema
28
del Modelo Clsico o Modelo en Cascada
puesto que al comienzo de la fase de Transicin del Proceso Unificado de Desarrollo de Software ya se
debera disponer de una versin ejecutable del producto que cubra de forma bastante completa las
necesidades del usuario. En esta fase se realizan tpicamente las siguientes tareas:
- Preparar la/s mquina/s receptora/s para el sistema software.
- Adaptar el sistema software a la/s mquina/s receptora/s.

27
Entendido como un producto.
28
La fase denominada Testing en los textos ingleses.

- Insercin inicial de datos en caso de ser necesario.
29

- Crear manuales de usuario.
- Formacin del usuario.
- Proporcionar consultora y soporte al usuario.
- Llevar a cabo la revisin post-proyecto.
6.5.2 Actividades del Proceso Unificado de Desarrollo de Software
A continuacin se describe brevemente cada una de las Actividades que se llevan a cabo en
cada una de las fases del Proceso Unificado de Desarrollo de Software:
30

- Actividad de Requisitos: Se trata de descubrir y acordar con el cliente qu debe hacer el
sistema. Se deben:
o Definir los Casos de Uso.
o Producir el Diagrama de Casos de Uso
31
inicial.
- Actividad de Anlisis: Se trata de producir un modelo de anlisis. Para ello se deben:
o Detallar los Casos de Uso.
o Encontrar los conceptos (clases)
32
que intervienen:
Diagrama de Clases.
33

Diagrama de Objetos.
34

- Actividad de Diseo: Se trata de producir un modelo de diseo. Para ello se deben:
o Disear las clases con detalle:
Diagrama de Clases.
o Encontrar cmo los objetos de estas clases colaboran entre s:
Diagrama de Secuencia.
35

Diagrama de Colaboracin o Comunicacin.
36

29
Esto podra incluir la conversin de bases de datos a los nuevos formatos, el importar datos
preexistentes, etc. Este proceso en los textos ingleses se denomina data takeon.
30
En negrita el trabajo a desarrollar vinculado a cada actividad relacionado con el modelado UML. Los
diferentes artefactos UML mencionados se describen brevemente en el Anexo I: Ejemplos de Diagramas UML.
31
En los textos ingleses el Diagrama de Casos de Uso se denomina Use Cases Diagram.
32
Los conceptos del negocio o del dominio o clases conceptuales representados en el Modelo de
Dominio o Modelo Conceptual, evolucionarn posteriormente a clases de diseo en el Diagrama de Clases del
Diseo. Ambos diagramas, es decir, el Modelo de Dominio o Modelo Conceptual y el Diagrama de Clases del
Diseo, se representan haciendo uso del mismo artefacto UML denominado Diagrama de Clases. Vase ms
informacin en los documentos dedicados a estos temas de forma especfica.
33
En los textos ingleses el Diagrama de Clases se denomina Class Diagram.
34
En los textos ingleses el Diagrama de Objetos se denomina Object Diagram.
35
En los textos ingleses el Diagrama de Secuencia se denomina Sequence Diagram. Los
Diagramas de Colaboracin o Comunicacin y los de Secuencia de UML se denominan Diagramas de Interaccin,
Interaction Diagrams en los textos ingleses, y deben ser equivalentes desde un punto de vista
semntico. Vase ms informacin en el documento dedicado a este tema de forma especfica.

Diagrama de Estados.
37

Diagrama de Actividad.
38

o Identificar los subsistemas.
o Disear las interfaces:
Diagrama de Componentes.
39

o Disear el despliegue:
Diagrama de Despliegue.
40

- Actividad de Implementacin:
o Implementacin de las clases y subsistemas.
o Pruebas unitarias.
o Integracin.
- Actividad de Pruebas de sistema y pruebas en la mquina receptora.

El Proceso Unificado de Desarrollo de Software posee todas las ventajas y desventajas de un
Marco de Trabajo Iterativo e Incremental y, por tanto, del Modelo en Espiral del que este deriva. De forma
resumida, dichas ventajas y desventajas son las siguientes:
- Ventajas:
o Retroalimentacin temprana y regular del cliente.
o Testeo temprano del proceso de desarrollo.
o Prototipos regulares.
o Tamao y complejidad del proyecto valorados desde el principio.
o Riesgos atacados cuanto antes.
- Inconvenientes:
o Ms difcil de entender e interiorizar.
o Ms difcil de gestionar que los procesos lineales.
o Su adopcin supone un cambio muy importante en la forma de trabajar de
muchas organizaciones y equipos de desarrollo.

Finalmente deben tenerse muy presente los siguientes errores tpicos al hacer uso del Proceso
Unificado de Desarrollo de Software para no cometerlos:
- Relacionarlo directamente con el Modelo en Cascada
41
:

36
En los textos ingleses el Diagrama de Colaboracin o Comunicacin se denomina Collaboration
o Communication Diagram. La denominacin preferida en la versin actual de UML es la de Diagrama de
Comunicacin que remplazara a la anterior denominacin de Diagrama de Colaboracin. Los Diagramas de
Colaboracin o Comunicacin y los de Secuencia de UML se denominan Diagramas de Interaccin,
Interaction Diagrams en los textos ingleses, y deben ser equivalentes desde un punto de vista
semntico. Vase ms informacin en el documento dedicado a este tema de forma especfica.
37
En los textos ingleses el Diagrama de Estados se denomina State Diagram.
38
En los textos ingleses el Diagrama de Actividad se denomina Activity Diagram.
39
En los textos ingleses el Diagrama de Componentes se denomina Component Diagram.
40
En los textos ingleses el Diagrama de Despliegue se denomina Deployment Diagram.
41
Tal y como ya se ha comentado, no debera confundirse, por ejemplo, la fase de Integracin y Pruebas
del Sistema del Modelo Clsico o Modelo en Cascada con la fase de Transicin del Proceso Unificado de Desarrollo

o Inicio Requisitos
o Elaboracin Diseo
o Construccin Codificacin
o Transicin Integracin y Pruebas de Sistema
- Escribir todos los Casos de Uso antes de empezar a programar: La filosofa de trabajo es,
por el contrario, el escoger unos pocos Casos de Uso inicialmente, tpicamente los ms
significativos o con un mayor riesgo, para realizar su modelado UML en lo que al anlisis y
diseo se refiere, y programar su funcionalidad bsica, de forma que la integracin de las
diferentes partes del sistema se vaya realizando de forma paulatina.
- Considerar una duracin fija para las iteraciones, de forma, que si no se llega a los plazos
de esa iteracin se opte por reducir la funcionalidad, es decir, los Casos de Uso, abordados.
7 7 E EL L L LE EN NG GU UA AJ JE E D DE E M MO OD DE EL LA AD DO O U UN NI IF FI IC CA AD DO O
7 7. .1 1 Q QU U E ES S E EL L L LE EN NG GU UA AJ JE E D DE E M MO OD DE EL LA AD DO O U UN NI IF FI IC CA AD DO O ? ?
Con anterioridad a UML existan diversos mtodos y tcnicas de modelado con algunos
aspectos en comn pero distintas notaciones. La falta de estandarizacin en la representacin visual del
modelo dificultaba el aprendizaje e impeda que los diagramas realizados se pudieran compartir
fcilmente, adems de existir pugnas entre los diferentes enfoques defendidos por los distintos gurs.

El Lenguaje de Modelado Unificado (UML, Unified Modeling Language) pretende dar solucin a
la situacin descrita. El Lenguaje de Modelado Unificado es el lenguaje de modelado de sistemas de
software ms conocido y utilizado en la actualidad y que cuenta adems con el respaldo del OMG
(Object Management Group)
42
, organizacin que lo define
43
como un lenguaje de modelado visual que
permite especificar, visualizar, construir y documentar un sistema de software proporcionando una
abstraccin del mismo y de sus componentes, por lo que se usa para entender, disear, configurar,
mantener y controlar la informacin sobre los sistemas software a construir.

Es un lenguaje de modelado y no una metodologa completa. Se puede utilizar, por tanto,
para dar soporte a un modelo de proceso de desarrollo de software tal y como lo es el Proceso Unificado
de Desarrollo Software, pero no est vinculado a un modelo de proceso de desarrollo de software
especfico.
44

de Software puesto que al comienzo de la fase de Transicin ya se debera disponer de una versin ejecutable del
producto que cubra de forma bastante completa las necesidades del usuario.
42
Puede consultarse http://www.omg.org para ms informacin. OMG es un consorcio creado
en 1989 responsable de la creacin, desarrollo y revisin de especificaciones para la industria del software. OMG
mantiene la web http://www.uml.org sobre el Lenguaje de Modelado Unificado.
43
Ms especficamente, la definicin proporcionada por la OMG es la siguiente: UML is a visual language
for specifying, constructing and documenting the artifacts of a system.
44
El hecho de que el Lenguaje de Modelado Unificado no defina un modelo de proceso de software
completo puede ser considerado por ciertos desarrolladores como un inconveniente, no as por otros que entienden
ambos elementos: Lenguaje de Modelado Unificado y Proceso Unificado de Desarrollo de Software, como
herramientas complementarias.

Tambin es importante resaltar que el Lenguaje de Modelado Unificado es un lenguaje de
modelado, o en otras palabras, el lenguaje en el que se describe el modelo. El modelado es la
especificacin que se hace de un software antes de su codificacin, es decir, la visualizacin de lo que
se quiere construir. De igual forma, es importante destacar que el Lenguaje de Modelado Unificado no es
un lenguaje de programacin. No obstante, las herramientas CASE UML pueden ofrecer la
funcionalidad de generacin de cdigo para diferentes lenguajes de programacin, as como la
posibilidad de construir modelos por ingeniera inversa a partir de cdigo existente.

El Lenguaje de Modelado Unificado es un lenguaje de propsito general para el modelado y,
como cualquier lenguaje de propsito general, pretende ser un lenguaje universal que busca ser tan
simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas software
que se necesita construir. Adems, necesita ser lo suficientemente expresivo para manejar todos los
conceptos que se originan en un sistema software moderno tales como el encapsulamiento.
45

El Lenguaje de Modelado Unificado permite definir tanto la estructura esttica como el
comportamiento dinmico del sistema:
- Estructura esttica: Cualquier modelo debe definir primero su universo, esto es, los
conceptos clave de la aplicacin, as como sus propiedades internas. Este conjunto de
construcciones es la estructura esttica. Los conceptos de la aplicacin se modelan como
clases,
46
cada una de las cuales se refiere un conjunto de objetos de un determinado tipo
que almacenan informacin modelada como atributos.
- Comportamiento dinmico: Existen dos formas de modelar el comportamiento, una es la
historia de la vida de un objeto y la forma en que el mismo interacta con el resto a lo largo
del tiempo y la otra es analizando los patrones de comunicacin de un conjunto de objetos
interconectados, es decir, la forma en que los mismos interactan entre s.
47
La visin de un
objeto aislado es una maquina de estados, muestra la forma en que el objeto responde a
los eventos en funcin de su estado actual. La visin de la interaccin de los objetos se
representa con los enlaces entre objetos junto con el flujo de mensajes intercambiados
entre los mismos.

El Lenguaje de Modelado Unificado capta la informacin tanto sobre la estructura esttica de un
sistema como sobre su comportamiento dinmico y lo modela representndolo a travs de una serie de
diagramas [ver Figura 13]:
48

- Diagramas de Estructura:
o Diagramas de Casos de Uso.
o Diagramas de Clases.

45
En el contexto del paradigma de programacin orientado a objetos, el Encapsulamiento consiste en la
propiedad que tienen los objetos de ocultar sus atributos, e incluso sus mtodos, a otros objetos con los que
interactan. Por este motivo, la forma natural de construir una clase es la de definir una serie de atributos que, en
general, no sern accesibles fuera del propio objeto, sino que nicamente podrn modificarse a travs de los
mtodos del objeto que sean definidos como accesibles desde el exterior de esa clase. Vase ms informacin en el
documento dedicado a este tema de forma especfica.
46
Recurdese que los conceptos de la aplicacin relativos al negocio o dominio de la misma, se
representan inicialmente como clases conceptuales en el Modelo de Dominio o Modelo Conceptual, y
posteriormente evolucionan a clases del diseo en el Diagrama de Clases del Diseo.
47
Es decir, como si se tomara una fotografa del sistema en un instante dado y se analizaran las
interacciones entre los objetos que lo componen.
48
Los diferentes artefactos UML mencionados se describen brevemente en el Anexo I: Ejemplos de
Diagramas UML. Algunos de ellos se utilizarn en la presente asignatura, mientras que el uso de otros no se
contempla.

o Diagramas de Objetos.
o Diagramas de Implementacin:
Diagramas de Componentes.
Diagramas de Despliegue.
- Diagramas de Comportamiento:
o Diagramas de Estados.
o Diagramas de Actividad.
o Diagramas de Interaccin:
Diagramas de Secuencia.
Diagramas de Colaboracin o Comunicacin.

Figura 13: Diagramas de UML.
Finalmente como inconvenientes del Lenguaje de Modelado Unificado, adems del que algunos
desarrolladores ven en el hecho de que no defina un proceso completo para el desarrollo de software, se
puede sealar que existe una falta de integracin con otros elementos como los Patrones de Diseo
49
y

49
Los desarrolladores de software que trabajan con el paradigma de Orientacin a Objetos con
experiencia acumulan un repertorio tanto de principios generales como de soluciones basadas en aplicar ciertos
estilos que les guan en la creacin de software. Estos principios y estilos, si se codifican con un formato
estructurado que describa tanto el problema como la solucin, y se les da un nombre, es a lo que se denomina
Patrones de Diseo. Por tanto, puede decirse que un Patrn de Diseo es un par problema/solucin que se identifica
con un determinado nombre, que se puede aplicar en nuevos contextos, con consejos acerca de cmo aplicarlo en
esas nuevas situaciones y discusiones sobre sus compromisos y contraindicaciones. Los Patrones de Diseo son
repetitivos y estn probados, y no es, por tanto, su objetivo el expresar nuevas ideas de diseo. Vase ms
informacin en el documento dedicado a este tema de forma especfica.

el hecho de que es extensible,
50
lo cual hace al Lenguaje de Modelado Unificado muy flexible, pero a
riesgo de perder la esencia del estndar como tal.
7 7. .2 2 H HI IS ST TO OR RI IA A D DE EL L L LE EN NG GU UA AJ JE E D DE E M MO OD DE EL LA AD DO O U UN NI IF FI IC CA AD DO O
El Lenguaje de Modelado Unificado comenz a gestarse en Octubre de 1994, cuando
Rumbaugh se uni a la compaa Rational Software
51
fundada por Booch
52
. Su objetivo era unificar dos
mtodos que haban desarrollado: el mtodo Booch y el OMT (Object Modelling Tool). El primer borrador
del Lenguaje de Modelado Unificado apareci en Octubre de 1995. En esa misma poca otro reputado
investigador, Jacobson, se uni a Rational y se incluyeron ideas suyas. Este equipo de trabajo pas a ser
conocido como los "tres amigos".
53
Al mismo tiempo, el trabajo que se estaba desarrollando se abri a la
colaboracin de otras empresas para que aportaran sus ideas.
54
Todas estas colaboraciones condujeron
a la definicin de la primera versin del Lenguaje de Modelado Unificado.

50
Esto supone que es ampliable mediante la incorporacin de nuevas caractersticas como puedan ser las
proporcionadas mediante los denominados Perfiles UML que permiten extender el Lenguaje de Modelado Unificado
para as construir modelos UML para dominios particulares.
51
Rational Software Corporation fue adquirida por IBM en 2003.
52
Ambos eran por aquel entonces reputados investigadores en el rea de la metodologa de desarrollo de
software.
53
En los textos ingleses el equipo formado por Rumbaugh, Booch y Jacobson se conoce como The
Three Amigos.
54
Los participantes en UML 1.0 fueron Rational Software (Booch, Rumbaugh y Jacobson), Digital
Equipment, Hewlett-Packard, i-Logix, IBM, ICON Computing, Intellicorp and James Martin & co., MCI Systemhouse,
Microsoft, ObjecTime, Oracle Corp., Platinium Technology, Sterling Software, Taskon, Texas Instruments y Unisys.

Figura 14: Surgimiento de UML.
Esta primera versin se ofreci a un grupo de trabajo para convertirlo en 1997 en un estndar
del OMG. Este grupo de trabajo del OMG que centra su trabajo en estndares relacionados con la
tecnologa orientada a objetos propuso una serie de modificaciones y una nueva versin del Lenguaje de
Modelado Unificado (la 1.1), que fue adoptada por el OMG como estndar en Noviembre de 1997.
Desde aquella versin ha habido una serie de revisiones que gestiona la OMG Revision Task Force. La
ltima versin aprobada es la UML 2.0
55
en 2005, aunque ya se est trabajando sobre
actualizaciones de esta versin, en concreto UML 2.5
56
se propuso en 2012. Sealar adems que la
Organizacin Internacional de Estandarizacin (ISO, International Standard Organization) aprob la
versin UML 1.0 como estndar de iure
57
en 2005. [ver Figura 14]
8 8 H HE ER RR RA AM MI IE EN NT TA AS S C CA AS SE E
8 8. .1 1 Q QU U S SO ON N L LA AS S H HE ER RR RA AM MI IE EN NT TA AS S C CA AS SE E ( (U UM ML L) ) ? ?
Como ya es sabido, la Ingeniera de Software necesita de un proceso, de una serie de tcnicas
con su notacin y de un conjunto de herramientas. En concreto, las herramientas proporcionan un
enfoque automtico o semi-automtico para el proceso y para las tcnicas, establecindose un sistema
de soporte para el desarrollo del software denominado Ingeniera de Software Asistida por Ordenador
(CASE, Computer Aided Software Engineering). Las herramientas son necesarias porque facilitan el
seguir el modelo de proceso, as como el utilizar las tcnicas y su notacin.

Las herramientas CASE son un conjunto de aplicaciones informticas cuyo objetivo es aumentar
la eficiencia en el desarrollo de software, disminuyendo, por tanto, el coste de dicho proceso en trminos
de recursos invertidos (tiempo, capital humano, etc.) y propiciando una mejora en la calidad del producto
software generado. Estas herramientas pretenden servir de ayuda, metdica y automatizada, en diversos
aspectos del ciclo de vida del desarrollo del software, en tareas que van desde la planificacin o el
clculo de costes hasta la creacin de documentacin, facilitando adems su estandarizacin, pasando
por la generacin automtica de parte del cdigo. Las herramientas CASE facilitan el uso de la
metodologa propia de la Ingeniera del Software, adems algunas de ellas permiten una gestin
integrada de todo el proceso de desarrollo del software, desde el anlisis y la captura de requisitos hasta
la implementacin.

Una herramienta CASE que utilice el Lenguaje de Modelado Unificado como notacin para
elaborar los modelos Herramienta CASE UML permitir comunicar de forma eficiente a todos los
agentes implicados en el proyecto de desarrollo software, todas aquellas decisiones que se vayan
tomando en el mismo. Por el contrario, el escoger una herramienta poco adecuada, o bien, un uso poco

55
Puede consultarse http://www.omg.org/spec/UML/2.0 para ms informacin.
56
Puede consultarse http://www.omg.org/spec/UML/2.5/Beta1/ para ms informacin.
57
Se explica el trmino estndar de iure como la anttesis del trmino estndar de facto. Un estndar de
facto es aquel patrn o norma que se caracteriza por no haber sido consensuada ni legitimada por un organismo de
estandarizacin al efecto. Por el contrario, se trata de una norma generalmente aceptada y ampliamente utilizada
por iniciativa propia de un gran nmero de interesados. Por el contrario, los estndares de iure son aquellos
generados por comits con status legal y avalados por gobiernos o instituciones como la ISO o la IEEE, y requieren
una elaboracin y proceso complejo. Los estndares de facto son la anttesis de los estndares de iure, no obstante,
algunos estndares de facto acaban convirtindose en estndares de iure.

apropiado de la herramienta escogida, puede acarrear un esfuerzo importante en la extraccin del
conocimiento de los modelos generados.

A travs de la notacin propuesta por el Lenguaje de Modelado Unificado y con el soporte de
una herramienta CASE deber cumplirse el objetivo de lograr comunicar y compartir de forma eficiente el
conocimiento de un determinado sistema software gracias a la combinacin simultnea de distintas
perspectivas. As, deber ser posible definir los diferentes conceptos y trazar sus lmites, mantener la
trazabilidad entre la concepcin de un problema y su solucin, usar un vocabulario comn o tomar
decisiones y evaluar su potencial impacto de manera sencilla y rpida para poder garantizar la
coherencia, completitud y usabilidad de los artefactos UML y otros entregables generados.
8 8. .2 2 C CR RI IT TE ER RI IO OS S D DE E S SE EL LE EC CC CI I N N O O D DE E C CO OM MP PA AR RA AC CI I N N P PA AR RA A U UN NA A
H HE ER RR RA AM MI IE EN NT TA A C CA AS SE E U UM ML L
Algunos de los criterios que se pueden utilizar como criterios de seleccin o de comparacin de
herramientas CASE son los siguientes:
- Notacin UML:
58

o Herramientas grficas.
59

o Herramientas sintcticas.
60

o Herramientas semnticas.
61

- Modelado Visual:
o Facilidades de dibujo.
o Convenciones de estilo.
o []
- Organizacin del Repositorio de artefactos UML:
o Compartir un nico repositorio.
o Control de acceso y versiones para mltiples usuarios.
o []
- Diagramas Soportados:

58
Clasificacin de las herramientas CASE UML propuesta por G. Gnova Fuster, J. M. Fuentes Torres y
M. C. Valiente Blzquez del departamento de Informtica de la Universidad Carlos III de Madrid en su artculo
"Evaluacin comparativa de herramientas CASE para UML desde el punto de vista notacional".
59
Proporcionan algn tipo de ayuda para dibujar diagramas UML (como plantillas de formas predefinidas,
etc.), de modo que resultan algo ms convenientes que las herramientas genricas de dibujo. Sin embargo, no
imponen prcticamente ningn tipo de restriccin en lo que el usuario puede dibujar, de modo que se facilita la
construccin de diagramas UML, pero no su correccin sintctica. As, por ejemplo, se podra utilizar un doble
subrayado para indicar una instancia nombrada, sin embargo, esto carece de significado en el Lenguaje de
Modelado Unificado. Una buena herramienta CASE UML no solo debera ayudar a dibujar diagramas, sino que
tambin debera ayudar a que dichos diagramas fueran correctos.
60
Facilitan el crear diagramas correctos segn las reglas notacionales del Lenguaje de Modelado
Unificado. Por tanto, suponen una ayuda mayor para el usuario con respecto a las herramientas meramente
grficas. No obstante, en general estas herramientas no construyen internamente un modelo a la vez que los
diagramas que lo expresan, por lo que no permiten comprobar la coherencia entre los distintos diagramas que
expresan un mismo modelo desde distintos puntos de vista.
61
Intentan garantizar la construccin de un modelo que est correctamente expresado en diagramas que
adems sean coherentes entre s.

o Revisin UML.
o Vista esttica.
62

o Vista dinmica.
63

o []
- Perfiles Extensiones UML:
64

o Modelado de procesos de negocio.
65

o Modelado de datos.
66

o Modelado de aplicaciones web (WAE, Web Application Extension).
67

o Modelado de la Experiencia del Usuario (UX, User eXperience).
68

o Modelado de sistemas de tiempo real.
o Modelado de DTDs
69
XML
70
.

62
Compuesta por diferentes diagramas UML como el Diagrama de Casos de Uso o el Diagrama de
Clases.
63
Compuesta por diferentes diagramas UML como el Diagrama de Secuencia o el Diagrama de
Colaboracin o Comunicacin.
64
Los Perfiles UML son una herramienta que permite extender el Lenguaje de Modelado Unificado y
construir as modelos UML para dominios particulares. Un perfil es una coleccin de extensiones que juntas
describen algn problema de modelado en particular, facilitando as la construccin de modelos en ese dominio. Por
ejemplo, el perfil UML para XML (Extensible Markup Language) fue definido por David Carlson en su libro "Modeling
XML Applications with UML" y el perfil UML para los procesos de negocio fue definido por Hans-Erik Eriksson y
Magnus Penker en su libro "Business Modeling with UML. Business Patterns at Work".
65
Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos
de negocio. Cada uno de ellos se caracteriza por una coleccin de datos que son producidos y/o manipulados
mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan
de acuerdo a un flujo de trabajo determinado. Adems, estos procesos se hallan sujetos a un conjunto de reglas de
negocio, que determinan las polticas y la estructura de la informacin de la empresa. Por tanto, la finalidad del
modelado del negocio es describir cada proceso del negocio, especificando sus datos, actividades (o tareas), roles
(o agentes) y reglas de negocio. Recurdese que, tal y como se ha comentado en la nota al pie anterior, el perfil
UML para los procesos de negocio fue definido por Hans-Erik Eriksson y Magnus Penker en su libro "Business
Modeling with UML. Business Patterns at Work".
66
El Diagrama de Clases UML se puede usar para modelar la estructura lgica de una base de datos,
independientemente de si es orientada a objetos o relacional, con las clases representando tablas, y los atributos de
la clase representando las columnas o campos de la tabla. No obstante, si se escoge la implementacin mediante
una base de datos relacional que, en el entorno de desarrollo actual, es el mtodo ms usado para implementar el
almacenamiento de datos, el Diagrama de Clases UML se puede usar para modelar algunos aspectos del diseo de
este tipo de bases de datos, pero sin llegar a cubrir toda la semntica involucrada en el modelado relacional
(atributos que actan como claves forneas para permitir relacionar entre s unas tablas con otras, etc.). Para
capturar esta informacin se recomienda utilizar el Diagrama Entidad - Relacin (ER diagram) como extensin del
Lenguaje de Modelado Unificado que es una herramienta de modelado que se concentra en los datos almacenados
en el sistema y en las relaciones existentes entre los mismos.
67
Es una extensin de UML para aplicaciones web creada por Jim Conallen (de Rational Software
Corporation, ahora propiedad de IBM). WAE extiende UML para permitir modelar elementos especficos de la Web
como parte del modelado de la aplicacin, permitiendo modelar, por ejemplo, pginas web, formularios, hiperenlaces
o enlaces entre pginas web, applets o pequeos programas desarrollados en el lenguaje de programacin Java y
embebidos en las pginas web, scripts o cdigos JavaScript, etc.
68
La Experiencia del Usuario, tal y como su propio nombre sugiere, se refiere a la experiencia de los
usuarios cuando estos manipulan las interfaces de usuario de las aplicaciones web: aspecto visual de las pginas
web, rutas de navegacin a travs de las pginas web, etc. Jim Conallen en su libro "Building Web Applications with
UML" aborda el modelado de UX mediante UML.
69
Una Definicin de Tipo de Documento (DTD, Document Type Definition) es el vnculo entre un Lenguaje
de Marcado (ML, Markup Language) y el metalenguaje a partir del cual est definido. El DTD define los elementos y
atributos que se podrn utilizar al especificar la estructura de un documento usando dicho Lenguaje de Marcado. As

o []
- Procesos de Ingeniera [ver Figura 15]:
o Ingeniera Directa.
71

o Ingeniera Inversa.
72

o Ingeniera Bidireccional.
73

o []

Figura 15: Ingeniera directa, inversa y bidireccional.
74

- Exportacin e Importacin de modelos:
o Lectura y escritura del formato XMI.
75

por ejemplo, el Lenguaje de Marcas de Hipertexto (HTML, Hypertext Markup Language) est basado en el
metalenguaje SGML (Standard Generalized Markup Language, Lenguaje de Marcado Estndar Generalizado) y en
su DTD se definen sus elementos y atributos como <P> elemento , ID atributo , etc.
70
El Lenguaje de Marcado Extensible (XML, Extensible Markup Language) es un metalenguaje ms
reciente y con una especificacin menos voluminosa que SGML (su especificacin es un subconjunto de la de
SGML) lo cual hace que resulte ms sencillo trabajar con l. Existe una reformulacin del Lenguaje de Marcado
HTML, denominada XHTML (extensible HTML), como una aplicacin de XML. A los Lenguajes de Marcado en
ocasiones se les denominada aplicaciones, puesto que se crean aplicando las normas de un determinado
metalenguaje.
71
En los textos ingleses a la Ingeniera Directa se le denomina Forward Engineering. Es el
proceso habitual, en nuestro caso supondra, la transformacin de un modelo UML en un cdigo correspondiente en
un determinado lenguaje de programacin.
72
En los textos ingleses a la Ingeniera Inversa se le denomina Reverse Engineering. De forma
amplia, la ingeniera inversa tienen por objetivo el obtener informacin a partir de un producto final con el fin de
determinar de qu est hecho, qu lo hace funcionar o cmo se fabric. En nuestro caso, supondra la
transformacin de un cdigo en un determinado lenguaje de programacin en su correspondiente modelo UML.
73
En los textos ingleses a la Ingeniera Bidireccional se le denomina Round Trip Engineering.
Incluye ambos procesos: el de la Ingeniera Directa y el de la Ingeniera Inversa.
74
El esqueleto de cdigo presentado est realizado en el lenguaje de programacin Java. Ntese que se
definen dos clases, la clase Circulo y la clase Rectangulo, ambas clases derivadas de la clase base o
superclase Figura tal y como se ha especificado en el modelo.
75
XMI (XML Metadata Interchange, XML para Intercambio de Metadatos) es un estndar que permite
expresar en forma de fichero XML cualquier modelo (o meta-modelo) definido en MOF (Meta Object Facility). De
esta forma XMI ofrece un formato adecuado para el intercambio entre diferentes herramientas de aquella
informacin cuya semntica se haya expresado en MOF. XMI permite, por tanto, compartir modelos UML entre
diferentes herramientas de modelado que soporten este estndar. XMI, al igual que MOF, ha sido creado por el

o []
- Soporte de Arquitectura Dirigida por Modelos (MDA, Model-Driven Architecture)
76
:
o Especificacin de modelos independientes de plataforma.
o []
- Soporte de Direccin de Proyectos:
o Organizacin de lotes de entregables por iteracin.
77

o Definicin de roles participantes en la elaboracin de los artefactos de
modelado.
o Imputacin de tiempo en la elaboracin de artefactos de modelado.
o Previsin y mtrica de los riesgos del proyecto.
o []
- Soporte del Ciclo de Vida de un Proyecto:
o Integracin con herramientas de trazabilidad de requisitos.
78

o Integracin con herramientas de control de versiones.
o Integracin con analizadores de carga y rendimiento.
o []
- Soporte de la Implementacin:
o Integracin de diferentes generadores de cdigo.
o []

OMG (Object Management Group, http://www.omg.org/index.htm) que es un consorcio responsable
de la creacin, desarrollo y revisin de especificaciones para la industria del software. Puede consultarse
http://www.omg.org/technology/xml/index.htm para ms informacin.
76
El OMG ha creado un marco conceptual para separar las decisiones orientadas-al-negocio de aquellas
orientadas-a-la-plataforma-de-desarrollo. Este marco y los estndares que ayudan a implementarlo es lo que OMG
denomina MDA. MDA separa, por tanto, la lgica de negocio de la aplicacin, de la plataforma tecnolgica
subyacente, permitiendo la realizacin de modelos para aplicaciones independientes de la plataforma tecnolgica
que se vaya a utilizar. Estos modelos independientes de la plataforma documentan el funcionamiento del negocio de
una aplicacin separndolo de la tecnologa especfica que lo implementar, aislando as el ncleo de la aplicacin
de la tecnologa. As, al no estar ligadas ambas componentes (negocio y tecnologa) pueden cada una evolucionar al
ritmo que se considere necesario. Puede consultarse http://www.omg.org/mda/ para ms informacin.
77
Hace referencia a las iteraciones del Proceso Unificado de Desarrollo de Software, que es el modelo de
proceso o ciclo de vida del software o paradigma de Ingeniera de Software ms frecuentemente utilizado en la
actualidad. Como ya es sabido, el Proceso Unificado de Desarrollo de Software es un marco de desarrollo iterativo e
incremental. Esto supone que es un marco de trabajo que propone mltiples ciclos cada uno comprendiendo las
fases de Arranque o Inicio, Elaboracin, Construccin y Transicin. En este marco de desarrollo, cada una de las
fases anteriores puede incluir a su vez una serie de iteraciones que ofrecen como resultado un incremento del
producto desarrollado, que aade o mejora las funcionalidades del sistema en desarrollo, aunque normalmente, en
la prctica, solo se planifican iteraciones para la fase de Construccin. Durante cada una de estas iteraciones se
realizarn a su vez una serie de posibles actividades: Requisitos, Anlisis, Diseo, Implementacin y Pruebas (e
Implantacin). Aunque todas las iteraciones pueden incluir trabajo en todas estas actividades, el grado de esfuerzo
dentro de cada una de ellas vara a lo largo del proyecto. As por ejemplo, la fase de Arranque o Inicio se centrar
ms en la definicin de Requisitos y en el Anlisis, actividades que durante la fase de Construccin quedarn
relegadas en favor de las actividades de Implementacin y Pruebas.
78
La trazabilidad de requisitos se define como la habilidad para describir y seguir la vida de un Requisito
en ambos sentidos, hacia sus orgenes o hacia su implementacin, a travs de todas las especificaciones generadas
durante el proceso de desarrollo de software.

- Generacin de Informes y Documentacin:
o Integracin con generadores de informes, diccionarios de datos, cuadernos de
proyecto, etc.
o Vincular artefactos de modelado con documentos de especificacin.
o Informes de validacin de sintaxis y reglas de notacin UML.
o Importacin de diagramas para confeccionar presentaciones.
o []
- Publicacin web:
o Generacin de documentacin en (X)HTML.
o []
- Soporte:
o Aprendizaje escalable.
o Muestrario de casos.
o Tutoriales de entrenamiento.
o Servicios de tutelaje para desarrollar proyectos piloto.
o []
- Escalabilidad de Costes y Prestaciones:
o Proyecto de cdigo abierto.
o Poltica de licencias para equipos de proyecto.
o Disponibilidad de versiones gratuitas para fines educativos.
o []
8 8. .3 3 E EJ JE EM MP PL LO OS S D DE E H HE ER RR RA AM MI IE EN NT TA AS S C CA AS SE E U UM ML L
A continuacin se proporciona una lista de diferentes herramientas CASE UML. No todas ellas
proporcionan una funcionalidad comparable. As, por ejemplo, en la citada lista hay herramientas CASE
UML que proporcionan una funcionalidad bastante completa como ArgoUML frente a otras ms limitadas
y probablemente sencillas como Violet, o incluso algunas como Use Case Maker que se centran en un
aspecto concreto, en este caso en el Modelo de Casos de Uso. Algunas de ellas son comerciales como
Rational y otras son proyectos de cdigo abierto como ArgoUML, tambin varias de ellas, aunque no son
gratuitas, cuentan con una versin bsica
79
que s es gratuita o tiene un precio ms asequible. Algunas
de las herramientas CASE UML propuestas estn expresamente diseadas para algn Entorno Integrado
de Desarrollo (IDE, (Integrated Development Enviroment)) como por ejemplo NetBeans IDE UML o
Eclipse UML2 Tools. La mayora son aplicaciones independientes que es posible instalar en la mquina
en la que se trabaje, no obstante, otros son servicios disponibles en lnea, en concreto,
WebSequenceDiagram o yUML.

Lista de herramientas CASE UML:
- AndroRMA
80

79
Versin denominada tpicamente con el calificativo de community.
80
Puede consultarse http://www.andromda.org/index.php para ms informacin.

- Apollo for Eclipse
81

- ArgoUML
82

- Astah Community
83

- BoUML
84

- Dia
85

- Eclipse Omondo
86

- Eclipse UML2 Tools
87

- Enterprise Arquitect
88

- NetBeans IDE UML
89

- Pacestar UML Diagrammer
90

- Poseidon
91

- Rational
92

- StarUML
93

- T4 Editor plus UML modeling Tools for Visual Studio
94

- Umbrello UML Modeller
95

- UMLet
96

- Use Case Maker
97

81
Puede consultarse http://www.gentleware.com/apollo.html para ms informacin.
82
Puede consultarse http://argouml.tigris.org/ para ms informacin.
83
Puede consultarse http://astah.net/editions/community para ms informacin.
84
Puede consultarse http://www.bouml.fr/ para ms informacin.
85
Puede consultarse http://projects.gnome.org/dia/ para ms informacin.
86
Puede consultarse http://www.omondo.com/ para ms informacin.
87
Puede consultarse http://wiki.eclipse.org/MDT-UML2Tools y
http://www.eclipse.org/modeling/ mdt /?project=uml2tools para ms informacin.
88
Puede consultarse http://www.sparxsystems.com/products/ea/index.html
para ms informacin.
89
Puede consultarse http://netbeans.org/features/uml/ para ms informacin.
90
Puede consultarse http://www.pacestar.com/uml/index.html para ms informacin.
91
Puede consultarse http://www.gentleware.com/new-poseidon-for-uml-8-
0.html para ms informacin.
92
Puede consultarse http://www-01.ibm.com/software/rational/ para ms
informacin.
93
Puede consultarse http://staruml.sourceforge.net/en/ para ms informacin.
94
Puede consultarse http://t4-editor.tangible-engineering.com/T4-
Editor-Visual-T4-Editing.html para ms informacin.
95
Puede consultarse http://uml.sourceforge.net/index.php para ms informacin.
96
Puede consultarse http://www.umlet.com/ para ms informacin.

- Violet UML Editor
98

- WebSequenceDiagram
99

- yUML
100

8 8. .4 4 A AS ST TA AH H
Como herramienta CASE UML para trabajar en el laboratorio durante el presente curso
acadmico se ha escogido Astah [ver Figura 16].
101

Figura 16: Vista de la herramienta CASE Astah.
9 9 E EN N E ES ST TA A A AS SI IG GN NA AT TU UR RA A
Finalmente, y volviendo al planteamiento realizado en la Figura 4: Qu necesita la Ingeniera
de Software?, sealar que, en esta asignatura [ver Error! No se encuentra el origen de la referencia.]:
- El proceso utilizado ser el Proceso Unificado de Desarrollo de Software.

97
Puede consultarse http://use-case-maker.sourceforge.net/ para ms informacin.
98
Puede consultarse http://alexdp.free.fr/violetumleditor/page.php para
ms informacin.
99
Puede consultarse http://www.websequencediagrams.com/ para ms informacin.
100
Puede consultarse http://yuml.me/diagram/scruffy/class/draw para ms
informacin.
101
Puede consultarse http:// http://astah.net/ para ms informacin.

- La notacin a utilizar ser el Lenguaje de Modelado Unificado.
- Y la herramienta CASE UML a utilizar ser Astah.
1 10 0 B BI IB BL LI IO OG GR RA AF F A A
Ariadne-1. (2001). UML Applied Object Oriented Analysis and Design. First Edition. Ariadne
Training.
Ariadne-2. (2005). UML Applied Object Oriented Analysis and Design. Second Edition. Ariadne
Training.
Bauer, F. L. (1972). Software engineering, Information Processing. Amsterdam: North-Holland
Publishing Co.
Bohem, B. (1976). Software Engineering. IEEE Transactions on Computers 25 (12) , 1226-1241.
Pressman, R. S. (2002). Ingeniera de Software. Un Enfoque Prctico (quinta edicin ed.).
Madrid: Mc Graw Hill.
Royce, W. (1970). Managing the Development of Large Software Systems: Concepts and
Techniques. Technical Papers of Western Electronic Show and Convention (WesCon). Los Angeles,
USA.
Rumbaugh, J., Jacobson, I., & Booch, G. (1999). El Proceso Unificado de Desarrollo de
Software. Addison Wesley.
Sommerville, I. (2005). Ingenieria de Software. Pearson Education.
Zelkovitz, M. V. (1978). Principles of Software Engineering and Design. Prentice Hall.

1 11 1 A AN NE EX XO O I I: : E EJ JE EM MP PL LO OS S D DE E D DI IA AG GR RA AM MA AS S U UM ML L
1 11 1. .1 1 D DI IA AG GR RA AM MA A D DE E C CA AS SO OS S D DE E U US SO O
El Diagrama de Casos de Uso permite capturar informacin acerca de cmo trabaja un sistema
actualmente y de cmo se desea que trabaje y, adems, pone nfasis en la relacin del sistema con el
exterior. En los Diagramas de Casos de Uso, se representan los Caso de Uso, mediante un valo con su
nombre, que son interacciones tpicas entre el usuario y el sistema que captan una funcin visible al
usuario y logran un objetivo del usuario que puede ser grande o pequeo. Tambin aparecen
representados los Actores de dichos Casos de Uso mediante un monigote con su nombre. A travs de un
Diagrama de Casos de Uso se puede representar quines usan el sistema: roles de personas, mquinas
u otros sistemas software y saber qu quieren del sistema, lo que permite hacer software pensando en el
cliente, adems de determinar qu est dentro del sistema y qu es lo que queda fuera. En definitiva, un
Diagrama de Casos de Uso Representa los roles mediante Actores, los Casos de Uso y las Asociaciones
entre ellos.

Figura 17: Ejemplo de Diagrama de Casos de Uso.
El Diagrama de Casos de Uso es deliberadamente simple para que su comprensin est al
alcance de cualquiera de los agentes implicados en el proceso de desarrollo software, incluyendo tanto a
los ingenieros de software como al propio cliente. Es importante no caer en la tentacin de considerar el
Diagrama de Casos de Uso demasiado simple como para preocuparse en exceso del mismo, puesto que
los Casos de Uso son la herramienta que permite conducir el proceso completo de desarrollo del
software desde la fase de Arranque al despliegue del software en la fase de Transicin.

1 11 1. .2 2 D DI IA AG GR RA AM MA A D DE E C CL LA AS SE ES S
El Diagrama de Clases representa las clases
102
y las relaciones entre ellas.

Inicialmente se utilizar un Diagrama de Clases para disear un modelo que contenga los
conceptos principales del dominio o negocio de una forma que resulte comprensible para el usuario y que
se denominar Modelo del Dominio o Modelo Conceptual. Dicho Modelo del Dominio o Modelo
Conceptual evolucionar ms adelante hacia el Diagrama de Clases del Diseo al transformarse los
conceptos o clases conceptuales en clases del diseo.

Figura 18: Ejemplo de Diagrama de Clases. (Ariadne-2)

102
En el contexto del paradigma de Orientado a Objetos, las clases son las plantillas o moldes que se
utilizan para la creacin de objetos. Por tanto, una clase podra definirse como una plantilla o molde que define los
atributos o variables (datos) y los mtodos (funciones) que son comunes para todos los objetos de un cierto tipo y
que, por tanto, permitira crear objetos de dicho tipo. Una clase tambin puede verse como una abstraccin de
aquello que tienen en comn todos los objetos de un determinado tipo. Vase ms informacin en el documento
dedicado a este tema de forma especfica.

1 11 1. .3 3 D DI IA AG GR RA AM MA A D DE E O OB BJ JE ET TO OS S
El Diagrama de Objetos representa las instancias especficas de las clases del sistema software
en un momento determinado.

El Diagrama de Objetos mostrado en la Figura 19 est vinculado a un Diagrama de Clases
tambin mostrado en la Figura 19 que representa una relacin de Agregacin
103
entre las clases
Coche Car y Rueda Wheel , en concreto la relacin modelada es que un Coche tiene
cero o ms Ruedas.

Figura 19: Ejemplo de Diagrama de Objetos vinculado a un Diagrama de Clases.

103
Existen dos posibilidades para modelar objetos complejos que son la Composicin y la Agregacin. La
utilizada en este caso, es decir, la Agregacin, es un tipo de relacin dinmica, en la que el tiempo de vida del objeto
incluido es independiente del tiempo de vida del objeto que lo incluye. En este tipo de relacin el vnculo entre
ambos objetos es tpicamente que el objeto base utiliza al incluido para su funcionamiento. As un Coche tiene
Ruedas, Limpia Lunetas, Espejos Retrovisores, etc., componentes todos ellos que utiliza para su funcionamiento.
Sin embargo, que un Coche se destruya no implica que todos sus componentes tambin lo hagan. Adems, tal y
como puede observarse, la relacin de Agregacin se representa mediante un rombo transparente junto al objeto
base, es decir, en aquel objeto que representa el todo y que incluye a los otros objetos involucrados en la asociacin
que, en este caso, es el objeto Coche. Vase ms informacin sobre el concepto de Agregacin en el documento
dedicado a este tema de forma especfica.

1 11 1. .4 4 D DI IA AG GR RA AM MA A D DE E C CO OL LA AB BO OR RA AC CI I N N O O C CO OM MU UN NI IC CA AC CI I N N
Representa las interacciones entre los objetos
104
a travs del intercambio de mensajes entre los
mismos. Es semnticamente equivalente al Diagrama de Secuencia ya que debe mostrar la misma
informacin que dicho diagrama. Los Diagramas de Colaboracin o Comunicacin y los Diagramas de
Secuencia son ambos Diagramas de Interaccin.

Figura 20: Ejemplo de Diagrama de Colaboracin. (Ariadne-1)
1 11 1. .5 5 D DI IA AG GR RA AM MA A D DE E S SE EC CU UE EN NC CI IA A
Representa las interacciones entre los objetos a travs del intercambio de mensajes entre los
mismos. Es semnticamente equivalente al Diagrama de Colaboracin o Comunicacin ya que debe

104
Los objetos software se utilizan para modelar objetos o entidades del mundo real, motivo por el que un
objeto software est dotado de estado y de comportamiento. El estado se almacena en variables denominadas
atributos. Y el comportamiento est representado por funciones que se denominan mtodos, es decir que un mtodo
es un procedimiento o una funcin perteneciente a un objeto. Por tanto, un objeto software es un conjunto de
atributos o variables (o datos) y mtodos (o funciones) relacionados entre s, o dicho de otra forma, es la
representacin en un programa de un concepto, y contiene toda la informacin necesaria para abstraerlo: datos que
describen sus caractersticas y operaciones que pueden realizarse sobre los mismos. Es importante sealar que un
objeto software est formado por una serie de caractersticas o datos (atributos) y una serie de operaciones
(mtodos) y no puede concebirse nicamente en funcin de los datos o de las operaciones sino en su conjunto.
Vase ms informacin sobre el concepto de Objeto Software en el documento dedicado a este tema de forma
especfica.

mostrar la misma informacin que dicho diagrama. Los Diagramas de Colaboracin o Comunicacin y los
Diagramas de Secuencia son ambos Diagramas de Interaccin.

Figura 21: Ejemplo de Diagrama de Secuencia. (Ariadne-1)
1 11 1. .6 6 D DI IA AG GR RA AM MA A D DE E E ES ST TA AD DO OS S
El Diagrama de Estados permite representar los estados, los eventos y las transiciones de un
sistema. As, el Diagrama de Estados muestra el conjunto de estados por los cuales pasa, bien un Caso
de Uso, bien un objeto durante su vida, o bien todo el sistema en respuesta a eventos como por ejemplo,
mensajes recibidos, tiempo rebasado o errores. Tambin ilustra qu eventos hacen que se pase de un
estado a otro y cules son las respuestas y acciones que generan.

En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos son estados y
cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un estado se
representa como una caja redondeada con el nombre del estado en su interior. Y una transicin se
representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener
1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo
compartimento es opcional, y en l pueden aparecer acciones de entrada, de salida y acciones internas.
Una accin de entrada se realiza al entrar en ese estado, es decir, que cada vez que se entra al estado
por medio de una transicin la accin de entrada se ejecuta. Una accin de salida se realiza al salir de
ese estado, es decir, que cada vez que se sale del estado por medio de una transicin la accin de
salida se ejecuta. Una accin interna es una accin que se ejecuta cuando se recibe un determinado
evento en ese estado, pero que no causa una transicin a otro estado.


Figura 22: Ejemplo de Diagrama de Estados. (Ariadne-2)
1 11 1. .7 7 D DI IA AG GR RA AM MA A D DE E A AC CT TI IV VI ID DA AD D
Representa el flujo entre operaciones a travs de transiciones. Puede considerarse una forma
especial de Diagrama de Estado usado para modelar una secuencia de acciones y condiciones que
ocurren dentro de un proceso en el que los estados representan operaciones y las transiciones ocurren
cuando la operacin se ha completado. Puede incluirse la toma de decisiones que d lugar a caminos
alternativos.


Figura 23: Ejemplo de Diagrama de Actividad. (Ariadne-2)

1 12 2 A AN NE EX XO O I II I: : M MI IT TO OS S D DE EL L D DE ES SA AR RR RO OL LL LO O D DE E S SO OF FT TW WA AR RE E
Durante los primeros aos del desarrollo del software surgi una mitologa que propag
informacin errnea y contribuy a crear confusin. Algunos de los mitos propagados se describen a
continuacin. Se invita al alumno a su lectura y a la reflexin sobre los mismos.
1 12 2. .1 1 M MI IT TO OS S D DE E G GE ES ST TI I N N
Los gestores con responsabilidad sobre el desarrollo de software, al igual que los gestores en la
mayora de campos estn normalmente bajo la presin que supone tener que cumplir un presupuesto, un
plazo de entrega y adems tratar de mejorar la calidad del producto resultante. [Figura 24]

Algunos mitos a los que en ocasiones recurren los gestores en el campo de desarrollo software,
aunque dichas creencias solo disminuyan la presin temporalmente, son los siguientes:

Mito. Mi equipo dispone de diferentes referencias bibliogrficas sobre desarrollo de software,
no le proporciona a mi equipo dicha bibliografa todo lo que necesita saber?

Realidad. Obviamente es positivo disponer de dicho fondo bibliogrfico, pero conocen los
miembros del equipo de su existencia?, se utiliza?, refleja las prcticas modernas del desarrollo de
software?, es completo? En muchos casos, la respuesta a todas estas preguntas es no.

Figura 24: Los Gestores de desarrollo de software.
Mito. Mi equipo dispone de las herramientas de desarrollo de software ms avanzadas, puesto
que se trabaja con las mquinas ms modernas y potentes.

Realidad. Se necesita ms que una mquina potente para poder desarrollar software de calidad.
Las herramientas de Ingeniera de Software Asistida por Ordenador (CASE, Computer Aided Software
Engineering) son ms importantes que el hardware del que se disponga para lograr una buena calidad y
productividad, aunque la mayora de los desarrolladores de software todava no las utilicen eficazmente.

Mito. Si se falla en la planificacin, se pueden aadir ms miembros al equipo de desarrollo de
software y recuperar el tiempo perdido.

Realidad. El desarrollo de software no es un proceso mecnico como la fabricacin y, en
general, aadir ms desarrolladores a un proyecto de software retrasado lo retrasa an ms. A priori,

esta declaracin puede parecer un contrasentido. Sin embargo, en la prctica, cuando se aaden nuevos
miembros al equipo, la necesidad de documentarse sobre el proyecto de estos nuevos miembros, puede
hacer que se reduzca la cantidad de tiempo que queda disponible para el desarrollo productivo. Por
supuesto, s es posible aadir nuevos miembros a un equipo de desarrollo software, pero solo de forma
bien planificada y coordinada.
1 12 2. .2 2 M MI IT TO OS S D DE EL L C CL LI IE EN NT TE E
Un cliente que solicita una aplicacin de software puede ser potencialmente cualquiera: otro
equipo del mismo departamento o de otro departamento de la misma empresa, una empresa diferente,
una institucin de algn tipo: ayuntamiento, hospital, etc. En muchos casos, el cliente cree en los mitos
que existen sobre el software, debido a que, en ocasiones, los gestores y desarrolladores de software
hacen poco para corregir la mala informacin que circula. Los mitos conducen a que el cliente se cree
una falsa expectativa y, finalmente, quede insatisfecho con los desarrolladores del software.

Mito. Una declaracin general de los objetivos es suficiente para comenzar a escribir cdigo, los
detalles se pueden proporcionar ms adelante. [ver Texto 1]

Realidad. Una mala definicin inicial es la principal causa del trabajo baldo en el campo de
desarrollo software. Es esencial una descripcin formal y detallada del software que el cliente demanda,
cuyas caractersticas deben determinarse despus de una exhaustiva comunicacin entre el cliente y el
desarrollador.
105

You've probably heard the saying, "If carpenters built buildings the way programmers write programs, the
first woodpecker
106
that came along would destroy civilization". Well, just imagine what the construction
industry would be like IF ARCHITECTS HAD TO WORK LIKE PROGRAMMERS...

Dear Mr. Architect:

Please design and build me a house. I am not quite sure of what I need, so you should use your
discretion.
My house should have between two and forty-five bedrooms. Just make sure the plans are such that the
bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final
decision of what I want. Also, bring me the cost breakdowns for each configuration so I can arbitrarily pick
one at a later time.
Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make
sure that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates
when I walk across it, and the walls don't have nearly enough insulation in them).
As you design, keep in mind that I want to keep yearly maintenance costs as low as possible. This should
mean the incorporation of extra-cost features like aluminium, vinyl, or composite siding. (If you choose not
to specify aluminium, be prepared to explain your decision in detail.)

105
En un marco de trabajo iterativo e incremental como el planteado por el Proceso Unificado de
Desarrollo de Software, no es imprescindible conocer en una fase inicial absolutamente todos los detalles relativos al
software a desarrollar. No obstante, s es necesario contar al menos con una descripcin formal y detallada, en la
medida de lo posible, del software que el cliente demanda.
106
El trmino ingls woodpecker significa pjaro carpintero.

Please take care that modern design practices and the latest materials are used in construction of the
house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however,
that the kitchen should be designed to accommodate my 1952 Gibson refrigerator.
To assure that you are building the correct house for our entire family, you will need to contact each of my
children, and also our in-laws. My mother-in-law will have very strong feelings about how the house
should be designed, since she visits us at least once a year. Make sure that you weigh all of these
options carefully and have come to the right decision. I retain the right to overrule any decisions that you
make.
Please don't bother me with small details right now. Your job is to develop the overall plans for the house
and get the big picture. At this time it is not appropriate to be choosing the colour of the carpeting, but
keep in mind that my wife likes blue.
Do not worry at this time about acquiring the resources to build the house itself. Your first priority is to
develop detailed plans and specifications. Once I approve these plans, I would expect the house to be
under roof within 48 hours.
While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell
it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make
sure that before you finalize the plans there is a consensus of the potential home buyers in my area that
they like the features this house has.
I advise you to run up and look at the house my neighbour built last year, as we like it a great deal. It has
many things that we feel we also need in our new home, particularly the 75-foot swimming pool. With
careful engineering, I believe that you can design this into our new house without impacting the
construction cost.
Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since
they will be used only for construction bids. Be advised that you will be held accountable for any increase
of construction costs as a result of later design changes.
You must be thrilled to be working on such an interesting project as this! To be able to use the latest
techniques and materials and to be given such freedom in your designs is something that can't happen
very often.
Contact me as soon as possible with your ideas and completed plans.

P.S. My wife just told me that she disagrees with many of the instructions I have given you in this letter.
As architect, it is your responsibility to resolve these differences. I have tried in the past and have been
unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.

P.P.S. Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as
possible if this is the case.
Texto 1: Qu es lo que quiere el cliente?
Mito. Si los requisitos del proyecto cambian, estos cambios pueden acomodarse fcilmente ya
que el software es flexible.

Realidad. Es verdad que los cambios en los requisitos del software pueden acomodarse, pero
cada cambio provocar un impacto que depender del momento en el que se introduzca dicho cambio.


La Figura 25 ilustra el impacto de los cambios. Los cambios que se solicitan al principio pueden
acomodarse fcilmente. El cliente puede revisar los requisitos y solicitar modificaciones con
relativamente poco impacto en el coste del proyecto. Cuando los cambios se solicitan durante el diseo,
el impacto en el coste se incrementa. Finalmente, los cambios en la funcionalidad u otras caractersticas,
durante la implementacin (codificacin y pruebas) pueden tener igualmente un impacto importante sobre
el coste y ms an cuando los cambios se realizan una vez que el software ya est en uso por sus
destinatarios. En definitiva, siempre es ms costoso realizar cambios durante el desarrollo que durante la
definicin del proyecto, y ms an cuando el producto ya se ha entregado al cliente. Adems, un mismo
cambio solicitado al final de un proyecto, tendr un coste ms elevado que si este se solicita al principio.

Figura 25. El impacto de los cambios solicitados en un proyecto software.
1 12 2. .3 3 M MI IT TO OS S D DE E L LO OS S D DE ES SA AR RR RO OL LL LA AD DO OR RE ES S
Los mitos en los que an creen muchos desarrolladores se han ido fomentando durante las
ltimas dcadas. Durante los primeros das del desarrollo del software, la programacin se vea como un
arte y las viejas formas y actitudes tardan en morir.

Mito. Una vez que se ha escrito el cdigo y se ha conseguido que funcione, el trabajo ha
terminado.

Realidad. Alguien dijo una vez cuanto ms pronto se comience a escribir cdigo, ms se
tardar en terminarlo. Diversas estadsticas apuntan a que escribir cdigo suele ser el 10% de todo el
proceso, y a que, entre el 50% y el 70% de todo el esfuerzo dedicado a desarrollar un software se
realizar despus de que ste se haya entregado al cliente por primera vez.

Mito. Lo nico que se debe entregar al terminar el proyecto es el cdigo funcionando
correctamente.


Realidad. Un programa que funciona es solo una parte de una configuracin del software, el cual
incluye otros muchos elementos. As, por ejemplo, una buena documentacin facilitar el realizar un
adecuado mantenimiento del software. En definitiva, tal y como se tendr oportunidad de comprobar a lo
largo del trabajo a realizar en la presente asignatura, hacer software es mucho ms que escribir cdigo.

Mito. Hasta que no se tiene el programa en ejecucin, no se tiene forma de comprobar su
calidad.

Realidad. Existen diferentes tcnicas cuyo objetivo es realizar una Gestin de Calidad del
Software (SQA, Software Quality Assurance) a lo largo de todo el proceso de desarrollo software. De
hecho, ciertos filtros de calidad aplicados se ha comprobado que son ms efectivos que las pruebas de
ejecucin, para encontrar ciertos tipos de defectos en el software.

Mito. Soy un (super)programador. Djame lo mo.

Realidad. Esta creencia es casi con toda seguridad garanta de fracaso, ya que los proyectos de
desarrollo software de cierta envergadura habitualmente se desarrollan en equipo.
1 12 2. .4 4 R RE EF FL LE EX XI I N N S SO OB BR RE E L LO OS S M MI IT TO OS S D DE EL L S SO OF FT TW WA AR RE E
Para animar al alumno a reflexionar sobre los mitos del software anteriormente expuestos y que
abordan los diferentes puntos de vista de gestores, desarrolladores y clientes, y sobre su veracidad o no,
as como sobre el resto de ideas presentadas sobre el software, le sugerimos intentar dar respuesta a las
siguientes preguntas:
- Cul es el proyecto de software ms grande en el que ha trabajado?:
o Cuntas lneas de cdigo se escribieron?
o Cuntas personas participaron?
o Cunto tiempo se emple?
o Cuntas personas lo usaron y durante cunto tiempo?
- Cul es el coste de entregar software con bugs?
o Cunto cuesta corregir cada uno de los bugs que se detectan en un
software?
- Por qu hay actualizaciones de un determinado software de forma peridica y con
bastante frecuencia y cul es el impacto de que se lancen dichas actualizaciones?
- Cul es el tamao del software? Algunos ejemplos del tamao de diverso software real
son los siguientes: Use Case Maker: 1,5 Mb
107
, Mozilla Firefox 3.6: 7,8 Mb
108
, Moodle 1.9:
15,8 Mb
109
, etc.
o Cuntas personas y tiempo cree que hicieron falta para escribir dicho
software?
- Por qu es tan costoso (en tiempo, en recursos, etc.) desarrollar software?

107
Vase http://use-case-maker.sourceforge.net. Herramienta CASE para el trabajo
con Casos de Uso.
108
Vase http://www.mozilla.org/es-ES/firefox/new. Navegador.
109
Vase http://moodle.org. Plataforma de e-learning.

- Qu hara si del funcionamiento correcto de un software:
o dependiese su nota en una determinada asignatura?
o dependiese el xito econmico de su empresa?
o dependiesen vidas?
- Cules son los aspectos ticos del desarrollo del software?
110
[ver Figura 26]

Figura 26: Aspectos ticos del desarrollo de software.

Nota de los profesores: Si detectas algn error, piensas que alguna informacin est presentada de
manera confusa, o que sobra o falta algn contenido, por favor, enva un mensaje a mperez@tel.uva.es.
Gracias por anticipado. Vuestras sugerencias se utilizarn para mejorar esta documentacin.

110
La Ingeniera de Software implica una serie de responsabilidades ms all de las habilidades
estrictamente tcnicas. Los ingenieros de software deben comportarse de modo honesto y tico, se trata de algo
ms que de cumplir la ley. Es importante respetar cdigos de conducta ticos establecidos para desarrolladores
profesionales como el Cdigo de tica y Prctica Profesional de la Ingeniera de Software (Software Engineering
Code of Ethics and Professional Practice) que tiene alcance internacional y ha sido propuesto por el Instituto de
Investigacin de tica en la Ingeniera de Software (SEERI, Software Engineering Ethics Research Institute)
http://seeri.etsu.edu , as como las recomendaciones de buenas prcticas o cdigos ticos de los
correspondientes colegios profesionales.

(Documentación) Introducción A La Ingeniería de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

(Documentación) Introducción A La Ingeniería de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Eduardo Gmez Snchez edugom@tel.uva.

Você também pode gostar