Está en la página 1de 16

© Editorial UOC 186 Escaneando la Informática

ven para definir estados incorrectos de los datos del software. Podemos ver las
restricciones como una condición booleana que tiene que ser cierta siempre.
Cuando una de estas condiciones se convierte en falsa quiere decir que hay un
error en los datos del sistema. Un ejemplo de restricción sería “todos los produc-
tos tendrán un precio >5”. En este caso, cada vez que damos de alta (o actuali-
zamos) un producto de forma que su nuevo precio sea inferior a cinco el soft-
ware tiene que detectarlo y avisar al usuario del error. Fijaos en que la multipli-
cidad de las asociaciones es también un tipo de restricción (por ej. definen el
número máximo y mínimo de relaciones entre clientes y ventas). En general,
sin embargo, las restricciones no se pueden definir gráficamente sino que hay
que hacerlo textualmente, ya sea en lenguaje natural o en OCL.

4.2.3 Diagrama de secuencia

El diagrama de secuencia es uno de los diagramas que permiten modelar el


comportamiento dinámico del sistema. En concreto, permite definir cómo
interactúan y colaboran los diferentes elementos del software que se tiene que
desarrollar con el fin de llevar a cabo las funcionalidades requeridas.
En concreto, el diagrama de secuencia muestra el conjunto de mensajes
(interacciones) que se generan desde el momento en que el actor empieza la eje-
cución de la funcionalidad hasta que ésta se acaba. El diagrama hace hincapié
en mostrar fácilmente la ordenación temporal de los mensajes (la ordenación se
muestra verticalmente, si un mensaje se encuentra más abajo que otro en el dia-
grama quiere decir que el primer mensaje es posterior al segundo).
La figura 5 muestra un posible diagrama de secuencia para el caso de uso
Copyright © 2013. Editorial UOC. All rights reserved.

entrar una nueva venta del diagrama de casos de uso.


En la figura se ve que el actor (el tendero) interactúa con la clase formulario
nueva venta (que representa el formulario de la interfaz gráfica donde el tende-
ro entra los datos de la venta) con el fin de crear la nueva venta. Después se
busca el cliente al que pertenece la venta con la ayuda del formulario búsqueda
del cliente. Por último, se asigna la nueva venta al cliente recuperado por el for-
mulario con el fin de asociar al cliente con la nueva venta. Aunque, por simpli-
cidad, no se ha contemplado dentro del diagrama, también habría que asociar
la venta con los productos que forman parte de ésta.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 187 Ingeniería del software

Figura 5. Ejemplo de diagrama de secuencia

Puede suceder que a la hora de dibujar el diagrama de secuencia nos encon-


tremos con que necesitamos definir clases que todavía no habíamos especifica-
do dentro del diagrama de clases. Así pues, en este caso, habría que hacer una
Copyright © 2013. Editorial UOC. All rights reserved.

nueva iteración sobre el diagrama de clases anterior con el fin de incluir las nue-
vas clases.
Además, para cada mensaje que aparezca en este diagrama hay que definir
una nueva operación dentro de la clase correspondiente (es decir, la que recibe
el mensaje). Esta operación sería la encargada de procesar la petición del men-
saje. Se tiene que especificar el comportamiento de todas las operaciones (es
decir, “qué” tiene que hacer la operación). Eso podemos definirlo descriptiva-
mente en lenguaje natural, especificarlo formalmente con contractos en OCL o
escribiendo directamente cómo tendría que ser el código de la operación.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 188 Escaneando la Informática

4.2.4 Diagrama de estados

El diagrama de estados muestra el comportamiento dinámico de un elemen-


to en concreto. Más específicamente, permite ver los diferentes estados por los
que pasa un objeto (un cliente, una venta...) a lo largo de su ciclo de vida. Por
ejemplo, el diagrama de estados de la figura 6 permite modelar cuando un clien-
te pasa de ser un cliente normal a un cliente moroso y al revés.

Figura 6. Ejemplo de diagrama de estados.


Copyright © 2013. Editorial UOC. All rights reserved.

En el ejemplo de la figura 6 se ve que inicialmente un cliente se encuentra


en el estado “buen cliente” (el círculo negro marca cuál es el estado inicial).
Cuando se crea una nueva venta por parte del cliente y la venta queda pendien-
te de pago, el cliente pasa al estado de “cliente moroso”. Posteriormente, cuan-
do el cliente paga la venta puede devolver al estado de “buen cliente” (siempre
que con este cobro el importe pendiente del cliente quede a cero, es decir, cuan-
do no haya otras ventas todavía pendientes).

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 189 Ingeniería del software

5. Tendencias

Para acabar el capítulo presentamos una serie de técnicas y métodos que


todavía no tienen un uso generalizado en la industria de desarrollo del software
pero que, en nuestra opinión, adquirirán cada vez un mayor protagonismo en
los próximos años. El horizonte temporal varía para cada propuesta; algunas
propuestas están ya lo bastante maduras mientras que otras todavía están
actualmente en fase de investigación.
En concreto presentaremos las propuestas siguientes: desarrollo de software
dirigido por modelos, ingeniería web, reutilización, verificación y validación de
modelos y métodos ágiles. Las diferentes propuestas se pueden combinar entre
sí, lo cual maximiza sus ventajas. Por ejemplo, se podría partir de un modelo
UML verificado y validado a la hora de seguir un proceso de desarrollo dirigido
por modelos con vistas a generar un software basado en web.

5.1. Ingeniería web

La ingeniería web se puede definir como la especialización de la IS para el


caso específico del desarrollo de software basado en tecnologías web. Por lo
tanto, la ingeniería web no es un nuevo paradigma o un nuevo tipo de ingenie-
ría. Los métodos de desarrollo web toman (y especializan) aquellas técnicas de
la IS más útiles para el caso concreto del software web.12
Por ejemplo, aparte de otros diagramas (como el diagrama de clases, el de
casos de uso, etc., vistos en el punto anterior), todos estos métodos utilizan lo
Copyright © 2013. Editorial UOC. All rights reserved.

que denominamos modelo de navegación. Este modelo permite representar las


diferentes páginas webs que forman el software web, el contenido de cada pági-
na (qué datos muestra y cómo los muestra), los enlaces entre ellas, así como (en
algunos de los métodos) las operaciones que se tienen que “ejecutar” cuando el
usuario navega de una página a otra. La figura 7 muestra una parte del posible
modelo de navegación (especificado usando el lenguaje WebML) para el softwa-

12. En el año 2000 un grupo de expertos se reunió en la 22 International Conference on software


Engineering para plantear los temas de futuro de la ingeniería del software. Sus trabajos se pueden
encontrar en: http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/future.html (visitada en noviembre
de 2006). Muchos de ellos todavía son plenamente vigentes hoy día. Ejemplos de métodos web son:
WebML, OO-Method, OOH, UWE, OOHDM o Strudel.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 190 Escaneando la Informática

re de la tienda VamosAComprar si el tendero pidiera la opción de permitir com-


pras por Internet. La página login permite a los clientes registrarse en el sistema.
A partir de ahí el cliente puede ir a la página NuevaVenta. Una vez entrados los
datos necesarios para dar de alta la venta (por ejemplo el código y la fecha,
suponiendo que no se generen automáticamente), el usuario navega hasta la
página AñadirProducto. Durante la navegación se crea el nuevo objeto venta
(operación InsertVenta) y la relación entre esta venta y el cliente
(InsertHaComprado). Desde la página AñadirProducto el cliente puede ir indican-
do los productos que quiere comprar (cada vez que añade uno, se crea el víncu-
lo entre la venta y el producto, operación InsertIncluye, y se vuelve a la misma
página para añadir otra nuevo si es necesario). Cuando todos los productos han
sido añadidos el cliente ya puede dirigirse a la página Checkout.
Algunos de estos métodos utilizan la notación UML (con algunas extensio-
nes) mientras que otros utilizan su propia notación.

Figura 7. Ejemplo de modelo de navegación


Copyright © 2013. Editorial UOC. All rights reserved.

5.2. Desarrollo de software dirigido por modelos

El desarrollo de software dirigido por modelos13 pretende utilizar la informa-


ción contenida en los modelos especificados durante las fases de análisis (espe-
cialmente) y de diseño con el fin de automatizar todo lo posible la fase de codi-

13. Model-driven development (MDD), en inglés.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 191 Ingeniería del software

ficación del software, evitando así la necesidad de invertir esfuerzos en su pro-


gramación final (con lo que además se evitan posibles errores introducidos
involuntariamente por los programadores en esta fase). Imaginad las ventajas
de poder generar automáticamente el software de la tienda VamosAComprar a
partir de diagramas UML como los vistos en la sección anterior.
Esta posibilidad es ampliamente utilizada dentro de la comunidad de bases
de datos con el fin de generar automáticamente las tablas de la base de datos a
partir de, por ejemplo, un diagrama de clases UML, pero no ha sido hasta los
últimos años cuando este tema ha tomado vuelo dentro de la IS. A modo de
ejemplo, actualmente todas las herramientas CASE se anuncian mencionando
sus avanzadas capacidades de generación automática de código. Incluso el OMG
ha presentado el estándar MDA (Model-Driven Architecture) como marco general
para estos tipos de métodos. El MDA propone que a partir de los modelos de la
fase de análisis se generen (semiautomáticamente) los modelos de la fase de
diseño y que a partir de éstos se genere directamente la implementación de la
aplicación.
Aunque en la parte estática del software (los datos), el mecanismo de genera-
ción automática está más o menos establecido (es fácil imaginar qué clases Java
serían necesarias para implementar el diagrama de clases del punto 3.2.2, sobre
todo si obviamos la parte textual del diagrama), en la parte dinámica (el com-
portamiento) todavía no está del todo claro cómo se tiene que llevar a cabo y/o
hasta qué punto es posible hacerlo.

5.3. Reutilización
Copyright © 2013. Editorial UOC. All rights reserved.

Una de las supuestas ventajas de la programación orientada a objetos (el


paradigma imperante en la actualidad) es la facilidad de reutilización del códi-
go, con el ahorro de tiempo (¡y de dinero!) que eso comporta. Sin embargo,
todavía no se ha conseguido que la reutilización funcione a gran escala. Con el
incremento de madurez del área de IS están surgiendo una serie de propuestas
que pretenden mejorar el porcentaje de reutilización en el desarrollo de nuevos
proyectos.
Por una parte hay propuestas para la reutilización del conocimiento median-
te el uso de patrones. Los patrones son soluciones genéricas a problemas habi-
tuales en el desarrollo de software. Por lo tanto, una vez nos encontramos el
problema, en vez de intentar solucionarlo nosotros mismos, podemos ver si

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 192 Escaneando la Informática

alguien que se ha encontrado con él anteriormente ya ha propuesto cómo solu-


cionarlo (y si se puede adaptar su solución a nuestro contexto). Hay patrones
para cualquiera de las actividades (y fases) del proceso de desarrollo.
Otra opción es usar métodos de desarrollo basados en componentes. Una
vez hecho el análisis de requisitos del sistema, estos métodos proponen mirar si
alguna de las partes del sistema puede estar ya desarrollada (por ejemplo, por
alguna empresa externa). La idea es ir hacia la creación de mercados de compo-
nentes, en los que una empresa pueda ir a buscar el componente que necesite.
Este tipo de componentes se llaman componentes COTS (commercial off-the-
shelf). Con el fin de generalizar este tipo de mercados, todavía hay que trabajar
en temas como por ejemplo asegurar la calidad de los componentes, cómo bus-
car los componentes adecuados y cómo integrarlos fácilmente con el resto del
sistema.

5.4. Verificación y validación

Debido a la creciente importancia de los diferentes modelos de análisis y


diseño en el desarrollo de software (por ejemplo, pueden servir para la genera-
ción automática de la implementación del sistema, como hemos comentado en
el punto 4.2), es cada vez más importante verificar y validar estos modelos.
La verificación de un modelo hace referencia al proceso por el cual se com-
prueba que el modelo cumple una serie de propiedades que permiten conside-
rarlo correcto. Un modelo es correcto si está especificado de forma coherente
con la notación que usa, si no tiene redundancias, si es consistente (no hay dos
partes del modelo que definen cosas contrarias), etc. Por ejemplo, un diagrama
Copyright © 2013. Editorial UOC. All rights reserved.

de clases especificado en UML tiene que ser ante todo sintácticamente correcto.
Eso quiere decir que tiene que cumplir con las reglas de “escritura” que define
el lenguaje UML, tanto con respecto a los símbolos utilizados como con respec-
to a las relaciones entre estos símbolos (a modo de ejemplo, una de las reglas
prohíbe que una clase sea subclase de ella misma).
Sin embargo, eso no es suficiente para asegurar que el modelo es correcto;
hay que hacer otros tipos de comprobaciones. Por ejemplo, el diagrama de la
figura 8 es perfecto sintácticamente hablando, pero no es correcto. La clase
Persona tiene una relación consigo misma, donde dice que toda persona tiene
como mínimo un padre/madre y que puede tener cero o más hijos. ¿Cuál es el
problema? Fijaos qué pasa si intentamos dar de alta a la persona “Georgina”.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 193 Ingeniería del software

Como toda persona tiene como mínimo un padre/madre, nos vemos obligados
a entrar también a Julia que es la madre de la Georgina. Pero, claro, al entrar a
Julia nos vemos obligados a entrar también a la madre de Julia... Para evitar este
elemento recursivo infinito tenemos que cambiar el diagrama de clases con el
fin de permitir que dentro de nuestro sistema haya personas sin padre (es decir,
personas de quienes, por el motivo que sea, no nos interesa saber quiénes son
sus padres). Hay que tener en cuenta también estos posibles errores a la hora de
verificar un modelo, de lo contrario cuando lo hayamos implementado y empe-
cemos a ejecutar el software resultante nos podemos encontrar con sorpresas
desagradables (y entonces ya será más costoso arreglar los errores).

Figura 8. Ejemplo de modelo incorrecto

Muchas veces la verificación se lleva a cabo transformando el modelo UML


en un lenguaje formal y comprobando la corrección del modelo resultante de
Copyright © 2013. Editorial UOC. All rights reserved.

la transformación utilizando técnicas (matemáticas y/o lógicas) propias del len-


guaje formal.
La validación consiste en comprobar que el modelo expresa realmente lo
que el cliente nos ha pedido (es decir, que realmente refleja sus necesidades).
Desgraciadamente, no hay una forma automática de validar un modelo ya que
es el cliente quien tiene que dar el visto bueno. Además, como el cliente proba-
blemente no será capaz de leer los modelos tampoco los puede validar directa-
mente. Las técnicas de validación más habituales incluyen algún tipo de simu-
lación o animación de los modelos, de manera que el cliente pueda hacerse una
idea de cómo se comportará el sistema una vez esté implementado. El cliente
valida indirectamente el modelo cuando valida la simulación.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 194 Escaneando la Informática

5.5. Métodos de desarrollo ágiles

Para determinados proyectos, la rigidez y la meticulosidad impuesta por los


métodos de desarrollo actuales (como el UP) puede ser excesiva; es posible que
no sea realmente necesario hacer todas las actividades propuestas y/o con el
nivel de detalle requerido por el método.
Como reacción a estos métodos estrictos han surgido los métodos ágiles. Los
métodos ágiles14 se basan en los valores expresados en el Agile Manifesto:15 Se
valoran más 1. los individuos y sus interacciones que el proceso de desarrollo y
las herramientas; 2. el desarrollo de un software que realmente funcione que una
buena documentación; 3. la colaboración con el cliente que la elaboración de
un contrato; y 4. la capacidad de responder a los cambios que el seguimiento de
una planificación. Como veis, estos principios intentan romper con la rigidez
de los métodos “tradicionales” y dar una respuesta más rápida (más “ágil”) a las
necesidades cambiantes del entorno.
De acuerdo con estos principios, cada método ágil propone una serie de téc-
nicas que se pueden aplicar. Por ejemplo, el XP (eXtreme Programming), sin duda
el método ágil más popular, propone la aplicación, entre otras, de las siguientes
técnicas:
– Diseño simple. Hay que utilizar el diseño más simple posible mientras solu-
cione el problema.
– Pruebas intensivas. Las pruebas se escriben antes del propio código. Eso
obliga a los programadores a pensar en lo que puede fallar antes de escri-
bir el código. Además, se verifica continua y automáticamente que el códi-
go supera todas las pruebas definidas hasta después de cada cambio.
– Refactorización. Mejora continua del código. Incluso el código que ya se ha
Copyright © 2013. Editorial UOC. All rights reserved.

considerado bueno se tiene que mejorar si vemos la oportunidad de ello. A


la larga eso mejora la calidad de todo el sistema de software.
– Programación por parejas. Se consigue una mejor calidad si siempre se traba-
ja por parejas (uno de los miembros de la pareja escribe el código y el otro revi-
sa lo que se va escribiendo; los papeles se intercambian al cabo de un rato).

14. Ejemplos de métodos ágiles, aparte de XP, son: SCRUM, Dyanmic Systems Development
Method, Crystal Methodologies, Feature- Driven Development y Adaptive software Development.
15. El Agile Manifesto es un conjunto de principios y valores que tienen que cumplir todos los
métodos “ágiles” y que surgieron a raíz de una reunión que tuvieron los principales representantes
de cada método en el año 2001.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 195 Ingeniería del software

Otro aspecto importante del XP es que defiende que de las cuatro variables
que pueden definir un proyecto (coste en inversión y recursos, tiempo, calidad
y conjunto de funcionalidades) sólo tres las puede escoger el cliente y/o el jefe
de proyectos. La cuarta es responsabilidad del equipo de desarrollo (si se mar-
can los recursos, la calidad y las funcionalidades, el equipo de desarrollo indica-
rá el tiempo que tardará en desarrollar aquellas funcionalidades con los recur-
sos y los plazos previstos).

5.6 Lenguajes específicos de dominio

El UML es un lenguaje generalista, es decir, está pensado para ser útil inde-
pendientemente de cuál sea el dominio del sistema de software que tenemos que
construir (comercios, bancos, asseguradores,…). Precisamente por éstos motivo,
como ya hemos comentado anteriormente, el UML es el lenguaje de modeliza-
ción más usado, con diferencia, hoy en día. De todos modos, esta misma voca-
ción generalista hace del UML un lenguaje muy amplio y complejo de dominar
en la su totalidad. Eso ha hecho que ciertas comunidades que desarrollan soft-
ware para dominios muy concretos, como por ejemplo el sector de la automo-
ción, prefieran desarrollar y utilizar lenguajes de modelización más pequeños y
mejor adaptados a los conceptos y semántica de aquel dominio.16 Este tipo de
lenguajes son los que denominamos lenguajes específicos de dominio (domain-
specific languages en inglés).
La ventaja de este tipo de lenguajes es que permiten modelar utilizando direc-
tamente la terminología y los conceptos utilizados en aquel dominio concreto
cosa que facilita el trabajo de los analistas y diseñadores y también la compren-
Copyright © 2013. Editorial UOC. All rights reserved.

sión de los modelos por parte del cliente. El inconveniente es, obviamente, el
coste de crear estos nuevos lenguajes (y las herramientas por manipularlos) ya
que en la gran mayoría de los casos estos lenguajes no están estandarizados sino
que se tienen que diseñar partiendo de cero. Por suerte, tecnologías actuales
como EMF (Eclipse Modeling Framework) y GMF (Graphical Modeling Framework)
facilitan la definición de lenguajes específicos de dominio y la creación automá-
tica de entornos de modelización para los mismos.

16. El propio UML también ofrece la posibilidad de adaptar su semántica a dominios específicos
mediante el uso de profilas pero sólo de una forma limitada.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 196 Escaneando la Informática

No hay ninguna regla de oro que permita decidir cuándo es mejor utilizar un
lenguaje reconocido pero generalista como el UML y cuándo es mejor crearse un
mismo un lenguaje más adaptado a nuestras propias necesidades. Aconsejaría
utilizar el UML siempre que sea posible y sólo cuando realmente el UML no se
adapte bien al dominio para el cual tenemos que desarrollar el software en cues-
tión tomar la decisión de adoptar un lenguaje específico de dominio.

6. Salidas profesionales

Las perspectivas laborales de los expertos en IS son mucho buenas.17 Los dife-
rentes perfiles profesionales coinciden básicamente con las diferentes fases del
ciclo de vida del desarrollo del software (programador, analista, jefe de proyec-
tos...). La evolución laboral de un/a ingeniero/a de software dentro de la empre-
sa se acostumbra a producir en el sentido inverso al orden de las correspondien-
tes etapas dentro del ciclo de vida del desarrollo del software.
Así pues, se acostumbra a empezar trabajando como programador. Dada una
especificación parcial del sistema que tiene que desarrollarse, el programador es
el encargado de implementar aquella parte del sistema utilizando el lenguaje de
programación y el tipo de plataforma escogido.
El responsable de definir esta especificación se llama analista. A partir de un
conjunto de requisitos dados por el cliente, el analista define qué tiene que
hacer el sistema (qué funcionalidad tiene que ofrecer, qué información tiene
Copyright © 2013. Editorial UOC. All rights reserved.

que gestionar...) con el fin de dar respuesta a estos requisitos. Esta especifica-


ción se define usando el método y la notación escogidos (por ejemplo, UP
como método y UML como notación).
Es importante subrayar que la figura del diseñador no acostumbra a existir
como tal. Las tareas propias de la fase de diseño (adaptar el análisis a las capa-
cidades del lenguaje y la plataforma tecnológica con la que se quiere implemen-
tar el sistema) se asignan o bien al programador o bien al analista (o bien al
administrador de la base de datos para la parte que tiene que ver con la gestión

17. El ingeniero de software es la profesión más valorada en los Estados Unidos, según la revista
Money. http://money.cnn.com/magazines/moneymag/bestjobs/. Visitada en noviembre de 2006.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 197 Ingeniería del software

de los datos del sistema). En muchos casos, se opta también por buscar directa-
mente a un profesional con el perfil de analista/programador. En estos casos
se espera que la misma persona sea capaz de realizar las tareas de analista y de
programador. Normalmente, en estos casos se indica ya explícitamente cuál es
el lenguaje con el que se implementará el sistema, por ej: “Analista/programa-
dor en Java EE”, ya que conocer el lenguaje de implementación elegido es un
requisito indispensable para poder ocupar este perfil.
Para concluir, la última opción es ser jefe de proyectos. El trabajo principal
de un jefe de proyectos es planificar el proyecto de desarrollo y gestionar el
grupo humano que tiene a sus órdenes con el fin de asegurar que el desarrollo
cumple los plazos establecidos con la máxima calidad posible. Es el responsable
de calcular y fijar estos plazos18 en función de la complejidad de los requisitos
expresados por el cliente y de los recursos de que disponga.
Cada paso en la evolución laboral nos aleja más de las tareas puramente tec-
nológicas. Una alternativa es evolucionar hacia la especialización máxima en
una tecnología determinada. Por ejemplo, se podría ser un experto en tecnolo-
gías Java EE, de forma que cualquier proyecto de desarrollo que tuviera que uti-
lizar Java EE pudiera requerir nuestro conocimiento a la hora de decidir qué
arquitectura sería la mejor para el proyecto, qué tecnologías Java EE
Copyright © 2013. Editorial UOC. All rights reserved.

18. Desgraciadamente, es frecuente que esta decisión se vea parcialmente condicionada por otras
áreas de la misma empresa, que quieren asegurar que el cliente acabe aceptando la propuesta, a ries-
go de tener dificultades posteriores para poder cumplir los plazos.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
Copyright © 2013. Editorial UOC. All rights reserved.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 253 Bibliografía

Bibliografía

Capítulo VI. Ingeniería del software

El abanico de libros que tratan aspectos de EP es anchísimo. Dicho esto, se


propone la selección de libros siguiente (en la medida del posible se recomien-
da consultar la versión inglesa, siempre más actualizada):

Beck, K. Extreme Programming Explained: Embrace Change. Boston: Addison-


Wesley.

Booch, G.; Rumbaugh J.; Jacobson, I. El lenguaje unificado de modelado.


Addison Wesely

Jacobson, I.; Booch, G.; Rumbaugh J. El proceso unificado de desarrollo de


software. Addison Wesely

Larman, C. UML y patrones, introducción al análisis y diseño orientado a objetos.


Prentice Hall.

Pressman, R. Ingeniería del sofware, un enfoque práctico. McGraw Hill.


Copyright © 2013. Editorial UOC. All rights reserved.

Sommerville, I. Ingeniería del software. Pearson Education.

Warmer, J.; Kleppe, A. The Object Constraint Language: Getting Your Models
Ready for MDA, Addison-Wesley

Igualmente destacar que este capítulo no se habría podido elaborar sin la


consulta de los materiales didácticos de la UOC siguientes:

Campderrich, B.; Recerca Informàtica SL. (2003). Enginyeria del


Programari. Fundació per a la Universitat Oberta de Catalunya.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
© Editorial UOC 254 Escaneando la Informática

Cabot, J.; Guitart, I. (coordinadores); Fernández, J.; Pradel, J.; Raya, J.A.
(autors) (2005). Enginyeria del programari orientat a l'objecte. Fundació per a la
Universitat Oberta de Catalunya.

Cabot, J. (coordinador); Camps, J.M.; Ceballos, J.; Durán, F.J.; Moreno,


N.; Romero, J.R.; Vallecillo, A. (autors) (2006). Enginyeria del programari de
components i sistemes distribuïts. Fundació per a la Universitat Oberta de
Catalunya.
Copyright © 2013. Editorial UOC. All rights reserved.

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.
Copyright © 2013. Editorial UOC. All rights reserved.

6LOHKDJXVWDGRHVWHFDStWXORSXHGHDGTXLULUHOUHVWRGHODREUD
HQODVSODWDIRUPDVKDELWXDOHV JRRJOH3OD\&DVDGHO/LEUR&DVDOLQL
/LEHUGUDFH/LEUR'DZVRQHUDHQXQIXWXURSUy[LPR$PD]RQHWF

Cabot, S. J. (2013). Ingeniería del software. Retrieved from http://ebookcentral.proquest.com


Created from uguayaquilsp on 2018-05-28 05:45:15.