Introducción A La Ingeniería Del Software OO

Introducción Introducción
a la ingeniería a la ingeniería
del software OO del software OO
Benet Campderrich Falgueras Benet Campderrich Falgueras
P01/75007/00565 P01/75007/00565
 FUOC • P01/75007/00565 2 Introducción a la ingeniería del software OO  FUOC • P01/75007/00565 2 Introducción a la ingeniería del software OO
 FUOC • P01/75007/00565 Introducción a la ingeniería del software OO  FUOC • P01/75007/00565 Introducción a la ingeniería del software OO
Índice Índice
Introducción............................................................................................... 5 Introducción............................................................................................... 5
Objetivos ...................................................................................................... 6 Objetivos ...................................................................................................... 6
1. Qué es la ingeniería del software...................................................... 7 1. Qué es la ingeniería del software...................................................... 7

1.1. Qué es el software ............................................................................... 7 1.1. Qué es el software ............................................................................... 7
1.2. El software como producto industrial ................................................ 7 1.2. El software como producto industrial ................................................ 7
1.3. La ingeniería del software................................................................... 8 1.3. La ingeniería del software................................................................... 8
1.4. Los grandes problemas de la ingeniería del software: la calidad 1.4. Los grandes problemas de la ingeniería del software: la calidad
y la productividad.............................................................................. 8 y la productividad.............................................................................. 8
2. El ciclo de vida del software .............................................................. 10 2. El ciclo de vida del software .............................................................. 10
2.1. El ciclo de vida clásico ....................................................................... 10 2.1. El ciclo de vida clásico ....................................................................... 10
2.1.1. Etapas ..................................................................................... 11 2.1.1. Etapas ..................................................................................... 11
2.1.2. El caso de lenguajes de cuarta generación ............................. 13 2.1.2. El caso de lenguajes de cuarta generación ............................. 13
2.2. Los ciclos de vida iterativos e incrementales..................................... 13 2.2. Los ciclos de vida iterativos e incrementales..................................... 13
2.2.1. Inconvenientes del modelo de ciclo de vida en cascada ....... 13 2.2.1. Inconvenientes del modelo de ciclo de vida en cascada ....... 13
2.2.2. El ciclo de vida con prototipos .............................................. 15 2.2.2. El ciclo de vida con prototipos .............................................. 15
2.2.3. La programación exploratoria................................................ 16 2.2.3. La programación exploratoria................................................ 16
2.2.4. El ciclo de vida del Rational Unified Process ......................... 16 2.2.4. El ciclo de vida del Rational Unified Process ......................... 16
3. Desarrollo estructurado y desarrollo orientado a objetos ........ 18 3. Desarrollo estructurado y desarrollo orientado a objetos ........ 18
3.1. Los métodos estructurados ................................................................ 18 3.1. Los métodos estructurados ................................................................ 18
3.2. Los métodos orientados a objetos ..................................................... 18 3.2. Los métodos orientados a objetos ..................................................... 18
3.3. Los métodos formales ........................................................................ 19 3.3. Los métodos formales ........................................................................ 19
4. Las herramientas CASE ....................................................................... 21 4. Las herramientas CASE ....................................................................... 21
5. El OMG y el UML ................................................................................... 23 5. El OMG y el UML ................................................................................... 23

5.1. El Object Management Group (OMG) .................................................. 23 5.1. El Object Management Group (OMG) .................................................. 23
5.2. Unified Modeling Language (UML) ...................................................... 23 5.2. Unified Modeling Language (UML) ...................................................... 23
Resumen....................................................................................................... 25 Resumen....................................................................................................... 25
Ejercicios de autoevaluación .................................................................. 27 Ejercicios de autoevaluación .................................................................. 27
Solucionario................................................................................................ 28 Solucionario................................................................................................ 28
Glosario ........................................................................................................ 28 Glosario ........................................................................................................ 28
Bibliografía................................................................................................. 29 Bibliografía................................................................................................. 29
Introducción Introducción
En este módulo se empieza a introducir el concepto de ingeniería de software y En este módulo se empieza a introducir el concepto de ingeniería de software y
a presentar su problemática. Después, se describe con detalle el ciclo de vida a presentar su problemática. Después, se describe con detalle el ciclo de vida
clásico o en cascada, y se presentan también modelos de ciclo de vida alterna- clásico o en cascada, y se presentan también modelos de ciclo de vida alterna-
tivos, en especial los conocidos como modelos iterativos e incrementales, entre tivos, en especial los conocidos como modelos iterativos e incrementales, entre
los cuales se describe el ciclo de vida del Rational Unified Process. los cuales se describe el ciclo de vida del Rational Unified Process.
A continuación, se definen las dos grandes líneas tecnológicas actuales en el A continuación, se definen las dos grandes líneas tecnológicas actuales en el
desarrollo de software: el desarrollo estructurado y el desarrollo orientado a ob- desarrollo de software: el desarrollo estructurado y el desarrollo orientado a ob-
jetos, y se introduce el concepto de herramienta CASE. El módulo termina con jetos, y se introduce el concepto de herramienta CASE. El módulo termina con
la presentación del origen y estatus del modelo estándar UML, el modelo la presentación del origen y estatus del modelo estándar UML, el modelo
orientado a objetos que se utiliza en esta asignatura, y del OMG, la organiza- orientado a objetos que se utiliza en esta asignatura, y del OMG, la organiza-
ción responsable del mismo. ción responsable del mismo.
Objetivos Objetivos
A partir de los conocimientos previos que el estudiante tiene sobre programa- A partir de los conocimientos previos que el estudiante tiene sobre programa-
ción en general y sobre programación orientada a objetos, el objetivo principal ción en general y sobre programación orientada a objetos, el objetivo principal
de este módulo es aprender qué se entiende por ingeniería de software orientado a de este módulo es aprender qué se entiende por ingeniería de software orientado a
objetos y cuáles son sus bases. Este objetivo general se descompone en los obje- objetos y cuáles son sus bases. Este objetivo general se descompone en los obje-
tivos parciales siguientes: tivos parciales siguientes:
1. Entender qué es la ingeniería de software y qué la diferencia de otras inge- 1. Entender qué es la ingeniería de software y qué la diferencia de otras inge-
nierías. nierías.
2. Hacerse una primera idea de los problemas principales de la ingeniería del 2. Hacerse una primera idea de los problemas principales de la ingeniería del
software actualmente: la calidad y la productividad. software actualmente: la calidad y la productividad.
3. Conocer el modelo de ciclo de vida que ha tenido más impacto hasta la lle- 3. Conocer el modelo de ciclo de vida que ha tenido más impacto hasta la lle-
gada de la orientación a objetos y también los principales modelos poste- gada de la orientación a objetos y también los principales modelos poste-
riores. riores.
4. Adquirir el concepto de herramienta CASE en general y, especialmente, en 4. Adquirir el concepto de herramienta CASE en general y, especialmente, en
entornos orientados a objetos. entornos orientados a objetos.
5. Conocer un poco el origen de UML, el modelo orientado a objetos que ha 5. Conocer un poco el origen de UML, el modelo orientado a objetos que ha
llegado a ser un estándar mundial. llegado a ser un estándar mundial.
1. Qué es la ingeniería del software 1. Qué es la ingeniería del software
1.1. Qué es el software 1.1. Qué es el software
Un sistema de software, denominado también aplicación o simplemente Un sistema de software, denominado también aplicación o simplemente
software, es un conjunto integrado de programas que en su forma definitiva software, es un conjunto integrado de programas que en su forma definitiva
se pueden ejecutar, pero comprende también las definiciones de estructuras de se pueden ejecutar, pero comprende también las definiciones de estructuras de
datos (por ejemplo, definiciones de bases de datos) que utilizan estos programas datos (por ejemplo, definiciones de bases de datos) que utilizan estos programas
y también la documentación referente a todo ello (tanto la documentación de y también la documentación referente a todo ello (tanto la documentación de
ayuda en el uso del software para sus usuarios como la documentación generada ayuda en el uso del software para sus usuarios como la documentación generada
durante su construcción, parte de la cual también servirá para su mantenimiento durante su construcción, parte de la cual también servirá para su mantenimiento
posterior). posterior).
1.2. El software como producto industrial 1.2. El software como producto industrial
Un software no es una obra de arte, sino un producto de consumo utilitario y Por ejemplo,…
Un software no es una obra de arte, sino un producto de consumo utilitario y Por ejemplo,…
masivo; para una empresa o trabajador autónomo, el software es un medio masivo; para una empresa o trabajador autónomo, el software es un medio
… los bancos, las industrias de … los bancos, las industrias de
auxiliar que interviene de manera más o menos indirecta, pero a menudo im- fabricación en serie, las empre- auxiliar que interviene de manera más o menos indirecta, pero a menudo im- fabricación en serie, las empre-
sas de comercio electrónico, sas de comercio electrónico,
prescindible, en su gestión y cada vez más en su proceso productivo; también etc., actualmente no podrían prescindible, en su gestión y cada vez más en su proceso productivo; también etc., actualmente no podrían
existe, como todos sabemos, un consumo privado de software. Por tanto, se funcionar sin software. existe, como todos sabemos, un consumo privado de software. Por tanto, se funcionar sin software.
puede considerar plenamente como un producto industrial. puede considerar plenamente como un producto industrial.
Sin embargo, es un producto industrial con algunas características especiales. Sin embargo, es un producto industrial con algunas características especiales.
En primer lugar, es mucho más un producto singular que un producto que se En primer lugar, es mucho más un producto singular que un producto que se
fabrique en serie (aunque hay softwares que tienen muchos miles de usuarios fabrique en serie (aunque hay softwares que tienen muchos miles de usuarios
e, incluso, millones), ya que, si bien existe –y no siempre– producción en serie e, incluso, millones), ya que, si bien existe –y no siempre– producción en serie
de copias del software, ésta es una actividad muy poco importante dentro del de copias del software, ésta es una actividad muy poco importante dentro del
conjunto del proceso productivo del software y relativamente sencilla. conjunto del proceso productivo del software y relativamente sencilla.
¡La producción de software se parece ¡La producción de software se parece

a la construcción! a la construcción!
Desde cierto punto de vista, la producción de Desde cierto punto de vista, la producción de
software se parece a la construcción de viviendas software se parece a la construcción de viviendas
o edificios industriales, por ejemplo, en el hecho o edificios industriales, por ejemplo, en el hecho
de que cada producto es diferente y su elaboración de que cada producto es diferente y su elaboración
se basa en un proyecto específico (en el caso de pro- se basa en un proyecto específico (en el caso de pro-
ducción en serie, lo que se proyecta es un prototipo ducción en serie, lo que se proyecta es un prototipo
del producto, y no cada unidad que se produce). del producto, y no cada unidad que se produce).
Otras características del software son, como Otras características del software son, como
señala Pressman, que no se estropea por el señala Pressman, que no se estropea por el
uso ni por el paso del tiempo –si finalmente se tiene que sustituir es porque uso ni por el paso del tiempo –si finalmente se tiene que sustituir es porque
se ha quedado tecnológicamente anticuado o inadaptado a nuevas necesi- se ha quedado tecnológicamente anticuado o inadaptado a nuevas necesi-
dades o porque ha llegado a resultar demasiado caro mantenerlo. dades o porque ha llegado a resultar demasiado caro mantenerlo.
1.3. La ingeniería del software 1.3. La ingeniería del software
En general, a cada tipo de producto industrial corresponde un tipo de ingenie- En general, a cada tipo de producto industrial corresponde un tipo de ingenie-
ría, entendida como el conjunto de métodos, técnicas y herramientas que se ría, entendida como el conjunto de métodos, técnicas y herramientas que se
utilizan tanto para desarrollar el producto (es decir, elaborar el proyecto o pro- utilizan tanto para desarrollar el producto (es decir, elaborar el proyecto o pro-
totipo) como para fabricarlo (afinando más se puede decir que existen, pues, totipo) como para fabricarlo (afinando más se puede decir que existen, pues,
dos ingenierías para cada tipo de productos: la del producto y la del proceso). dos ingenierías para cada tipo de productos: la del producto y la del proceso).
En esta asignatura... En esta asignatura...

Una técnica es la manera preestablecida en la que se lleva a término un Una técnica es la manera preestablecida en la que se lleva a término un
... preferimos método en lugar ... preferimos método en lugar
paso en la elaboración del producto, un método es una manera deter- de metodología, aunque sólo
paso en la elaboración del producto, un método es una manera deter- de metodología, aunque sólo
minada de aplicar varias técnicas sucesivamente y una herramienta es sea por simplicidad. minada de aplicar varias técnicas sucesivamente y una herramienta es sea por simplicidad.
un instrumento de cualquier tipo que se utiliza en la aplicación de una un instrumento de cualquier tipo que se utiliza en la aplicación de una
técnica. técnica.
El software no es ninguna excepción a esta regla, y, por tanto, hay una inge- El software no es ninguna excepción a esta regla, y, por tanto, hay una inge-
niería del software. niería del software.
La ingeniería del software comprende las técnicas, métodos y herra- La ingeniería del software comprende las técnicas, métodos y herra-
mientas que se utilizan para producirlo. mientas que se utilizan para producirlo.
En el caso de la ingeniería del software no se suele hablar de ingeniería de pro- En el caso de la ingeniería del software no se suele hablar de ingeniería de pro-
ceso; quizá se podría pensar que es la que hace referencia a la programación ceso; quizá se podría pensar que es la que hace referencia a la programación
en sentido estricto, pero cada vez es menos nítida la distinción entre la pro- en sentido estricto, pero cada vez es menos nítida la distinción entre la pro-
gramación y las fases anteriores en el desarrollo de software. gramación y las fases anteriores en el desarrollo de software.
1.4. Los grandes problemas de la ingeniería del software: 1.4. Los grandes problemas de la ingeniería del software:
la calidad y la productividad la calidad y la productividad
A pesar de los grandes adelantos que ha habido en las técnicas de desarrollo A pesar de los grandes adelantos que ha habido en las técnicas de desarrollo
de software durante los últimos treinta años, tanto la calidad del software como de software durante los últimos treinta años, tanto la calidad del software como
la productividad de su proceso de elaboración todavía no han alcanzado nive- la productividad de su proceso de elaboración todavía no han alcanzado nive-
les plenamente comparables con los de otras tecnologías más antiguas. Todo les plenamente comparables con los de otras tecnologías más antiguas. Todo
esto, combinado con un aumento realmente espectacular de la demanda de esto, combinado con un aumento realmente espectacular de la demanda de
software, ha provocado lo que se ha denominado la crisis del software. software, ha provocado lo que se ha denominado la crisis del software.
En cuanto a la calidad, la causa principal de dificultades es la gran compleji- En cuanto a la calidad, la causa principal de dificultades es la gran compleji-
dad del software comparado con otros tipos de productos, que provoca, por dad del software comparado con otros tipos de productos, que provoca, por
ejemplo, que no sea posible, ni mucho menos, probar el funcionamento de un ejemplo, que no sea posible, ni mucho menos, probar el funcionamento de un
software en todas las combinaciones de condiciones que se pueden dar. Y eso software en todas las combinaciones de condiciones que se pueden dar. Y eso
ocurre en una época en la que se da cada vez más importancia a la calidad en ocurre en una época en la que se da cada vez más importancia a la calidad en
todos los ámbitos, al considerarla un factor de competitividad dentro de unos todos los ámbitos, al considerarla un factor de competitividad dentro de unos
mercados cada vez más saturados y, por tanto, más exigentes. No es extraño, mercados cada vez más saturados y, por tanto, más exigentes. No es extraño,
pues, que el tema de la calidad (y dentro de éste, cuestiones como la garantía pues, que el tema de la calidad (y dentro de éste, cuestiones como la garantía
de calidad y las certificaciones oficiales de calidad) adquiera una importancia de calidad y las certificaciones oficiales de calidad) adquiera una importancia
creciente dentro de la ingeniería del software. creciente dentro de la ingeniería del software.
Por lo que respecta a la productividad, cabe decir para empezar que cualquier Por lo que respecta a la productividad, cabe decir para empezar que cualquier
fabricación en serie tiene necesariamente una productividad mucho más ele- fabricación en serie tiene necesariamente una productividad mucho más ele-
vada que la fabricación de un producto singular; pero, incluso, si la compara- vada que la fabricación de un producto singular; pero, incluso, si la compara-
mos con otras ingenierías de producto singular, la productividad es claramente mos con otras ingenierías de producto singular, la productividad es claramente
inferior. La complejidad del producto también puede ser una causa de este he- inferior. La complejidad del producto también puede ser una causa de este he-
cho, pero ciertamente no es la única. Un factor que tiene un peso realmente cho, pero ciertamente no es la única. Un factor que tiene un peso realmente
importante en la baja productividad es el hecho de que, a diferencia de las importante en la baja productividad es el hecho de que, a diferencia de las
otras tecnologías, en un proyecto de software el desarrollo empieza tradicional- otras tecnologías, en un proyecto de software el desarrollo empieza tradicional-
mente de cero (sólo recientemente se utilizan fragmentos de software mente de cero (sólo recientemente se utilizan fragmentos de software
“prefabricados”). “prefabricados”).
El aprovechamiento de elementos en la fabricación en serie El aprovechamiento de elementos en la fabricación en serie

Cuando se diseña un nuevo modelo de coche, se incluyen desde el principio mu- Cuando se diseña un nuevo modelo de coche, se incluyen desde el principio mu-
chísimos elementos que ya existían y que, por tanto, no es necesario diseñar; no chísimos elementos que ya existían y que, por tanto, no es necesario diseñar; no
sólo elementos normalizados como tornillos y tuercas, sino también elementos sólo elementos normalizados como tornillos y tuercas, sino también elementos
más complejos como baterías e, incluso, motores o cajas de cambio completos. más complejos como baterías e, incluso, motores o cajas de cambio completos.
También en la construcción de edificios –una actividad que tiene más semejanzas También en la construcción de edificios –una actividad que tiene más semejanzas
con la producción de software, como se ha indicado– se utilizan muchos elemen- con la producción de software, como se ha indicado– se utilizan muchos elemen-
tos estándares o prefabricados: tejas, vigas, ventanas, persianas, grifos, etc. tos estándares o prefabricados: tejas, vigas, ventanas, persianas, grifos, etc.
Por tanto, no es extraño que uno de los grandes retos, por el momento, de la Por tanto, no es extraño que uno de los grandes retos, por el momento, de la
ingeniería del software sea conseguir desarrollar fragmentos de software (deno- ingeniería del software sea conseguir desarrollar fragmentos de software (deno-
minados componentes) que sean reutilizables, por un lado, y, por el otro, desa- minados componentes) que sean reutilizables, por un lado, y, por el otro, desa-
rrollar software y reutilizar sus fragmentos (que seguramente estarán mejor rrollar software y reutilizar sus fragmentos (que seguramente estarán mejor
probados que si se hicieran de nuevo, lo cual además mejoraría la calidad del probados que si se hicieran de nuevo, lo cual además mejoraría la calidad del
software producido). software producido).
Una de las vías mediante las cuales se pretende conseguir una cierta reutilización Una de las vías mediante las cuales se pretende conseguir una cierta reutilización
en el desarrollo orientado a objetos es especialmente con componentes; otras son en el desarrollo orientado a objetos es especialmente con componentes; otras son
los patrones de diseño (reutilización, si no de fragmentos de software, por lo me- los patrones de diseño (reutilización, si no de fragmentos de software, por lo me-
nos de ideas o “recetas” para hacerlos) y los marcos o frameworks, que son estruc- nos de ideas o “recetas” para hacerlos) y los marcos o frameworks, que son estruc-
Llegados a este punto, conviene Llegados a este punto, conviene
turas formadas por sistemas de software a los cuales se pueden acoplar otros que respondáis a los ejercicios
de autoevaluación 1, 2 y 3.
turas formadas por sistemas de software a los cuales se pueden acoplar otros que respondáis a los ejercicios
de autoevaluación 1, 2 y 3.
sistemas de software, sustituibles, para hacer funciones concretas. sistemas de software, sustituibles, para hacer funciones concretas.
2. El ciclo de vida del software 2. El ciclo de vida del software
La producción de software es algo más que la programación; hay etapas que la La producción de software es algo más que la programación; hay etapas que la
preceden y otras que la siguen. preceden y otras que la siguen.
El ciclo de vida del software está constituido por el conjunto de todas El ciclo de vida del software está constituido por el conjunto de todas
estas etapas. Los métodos y técnicas de la ingeniería del software se ins- estas etapas. Los métodos y técnicas de la ingeniería del software se ins-
criben dentro del marco delimitado por el ciclo de vida del software, y, criben dentro del marco delimitado por el ciclo de vida del software, y,
más concretamente, por las diferentes etapas que se distinguen. más concretamente, por las diferentes etapas que se distinguen.
La misma existencia de distintos modelos del ciclo de vida del software hace La misma existencia de distintos modelos del ciclo de vida del software hace
comprender que no hay ninguno que sea ideal o que no tenga grandes limita- comprender que no hay ninguno que sea ideal o que no tenga grandes limita-
ciones. Sin embargo, es indispensable que todo proyecto se desarrolle dentro del ciones. Sin embargo, es indispensable que todo proyecto se desarrolle dentro del
marco de un ciclo de vida claramente definido, si se quiere tener una mínima marco de un ciclo de vida claramente definido, si se quiere tener una mínima
garantía de cumplimiento de los plazos, y respetar los límites de los recursos garantía de cumplimiento de los plazos, y respetar los límites de los recursos
asignados; y también la garantía de calidad y las certificaciones de calidad* pre- asignados; y también la garantía de calidad y las certificaciones de calidad* pre-
* ISO, por ejemplo. * ISO, por ejemplo.
suponen que el proceso de producción de software se desarrolle según ciclo de suponen que el proceso de producción de software se desarrolle según ciclo de
vida con etapas bien definidas. vida con etapas bien definidas.
2.1. El ciclo de vida clásico 2.1. El ciclo de vida clásico
La figura siguiente nos muestra las etapas previstas en una cierta versión del La figura siguiente nos muestra las etapas previstas en una cierta versión del
ciclo de vida clásico. ciclo de vida clásico.
A veces, el ciclo de la vida clásico también se denomina ciclo de vida en cascada, A veces, el ciclo de la vida clásico también se denomina ciclo de vida en cascada,
lo cual quiere decir que en cada etapa se obtienen unos documentos (en inglés, lo cual quiere decir que en cada etapa se obtienen unos documentos (en inglés,
deliverables) que son las bases de partida de la etapa siguiente –que, por tanto, no deliverables) que son las bases de partida de la etapa siguiente –que, por tanto, no
puede comenzar antes de que haya terminado la anterior– y nunca se regresa a puede comenzar antes de que haya terminado la anterior– y nunca se regresa a
etapas pasadas. etapas pasadas.
2.1.1. Etapas 2.1.1. Etapas
La primera etapa se denomina análisis previo y también análisis de La primera etapa se denomina análisis previo y también análisis de
sistemas o ingeniería de sistemas. En esta etapa se definen los grandes sistemas o ingeniería de sistemas. En esta etapa se definen los grandes
rasgos del sistema de software que tendrá que dar soporte informático a rasgos del sistema de software que tendrá que dar soporte informático a
unas actividades determinadas de unos ciertos usuarios dentro del mar- unas actividades determinadas de unos ciertos usuarios dentro del mar-
co más general de la actividad de la empresa u organización. co más general de la actividad de la empresa u organización.
Además, este sistema tendrá que funcionar en un entorno de hardware y red Además, este sistema tendrá que funcionar en un entorno de hardware y red
determinado, que será necesario indicar, y quizá también tendrá que inter- determinado, que será necesario indicar, y quizá también tendrá que inter-
cambiar información con otro software o compartir una base de datos. Estos cambiar información con otro software o compartir una base de datos. Estos
hechos constituyen otros aspectos del entorno del futuro software de los cuales hechos constituyen otros aspectos del entorno del futuro software de los cuales
se tendrá que dejar constancia. se tendrá que dejar constancia.
Hay que tener en cuenta los recursos necesarios para el desarrollo del software Hay que tener en cuenta los recursos necesarios para el desarrollo del software
y los condicionamientos temporales, especialmente los plazos impuestos des- y los condicionamientos temporales, especialmente los plazos impuestos des-
de fuera del proyecto, que a menudo están determinados por los hechos que de fuera del proyecto, que a menudo están determinados por los hechos que
han causado las necesidades de información que tiene que satisfacer dicho han causado las necesidades de información que tiene que satisfacer dicho
software, y también restricciones eventuales y condiciones adicionales que sea software, y también restricciones eventuales y condiciones adicionales que sea
necesario respetar; y, en función de todo esto, se evalúa la viabilidad técnica, necesario respetar; y, en función de todo esto, se evalúa la viabilidad técnica,
económica y legal del proyecto de desarrollo de dicho software. económica y legal del proyecto de desarrollo de dicho software.
El documento que resulta de esta etapa se denomina “Especificación del siste- El documento que resulta de esta etapa se denomina “Especificación del siste-
ma”, y sirve de base para tomar la decisión definitiva sobre la continuación del ma”, y sirve de base para tomar la decisión definitiva sobre la continuación del
proyecto. proyecto.
La segunda etapa es el análisis de requisitos o simplemente análisis. La segunda etapa es el análisis de requisitos o simplemente análisis.
Su objetivo es definir con detalle las necesidades de información que Su objetivo es definir con detalle las necesidades de información que
tendrá que resolver el software, sin tener en cuenta, por el momento, los tendrá que resolver el software, sin tener en cuenta, por el momento, los
medios técnicos* con los que se tendrá que llevar a término el desarrollo * Como el lenguaje medios técnicos* con los que se tendrá que llevar a término el desarrollo * Como el lenguaje
de programación, de programación,
el gestor de bases de datos, el gestor de bases de datos,
del software. los componentes que se pueden del software. los componentes que se pueden
reutilizar, etc. reutilizar, etc.
En esta etapa detallamos los requisitos de la etapa anterior; ahora sólo pen- En esta etapa detallamos los requisitos de la etapa anterior; ahora sólo pen-
samos en el software que es necesario desarrollar y sus interfaces con el en- samos en el software que es necesario desarrollar y sus interfaces con el en-
torno. torno.
La figura responsable del análisis –el analista, que puede ser un informático o La figura responsable del análisis –el analista, que puede ser un informático o
un usuario– debe tener o adquirir conocimientos generales sobre el dominio un usuario– debe tener o adquirir conocimientos generales sobre el dominio
de la aplicación y obtener información de los usuarios y de otras fuentes* que de la aplicación y obtener información de los usuarios y de otras fuentes* que
* Por ejemplo, software que se debe * Por ejemplo, software que se debe
le permita hacerse una idea precisa de las funciones, y de los requisitos en ge- sustituir, software que desempeña le permita hacerse una idea precisa de las funciones, y de los requisitos en ge- sustituir, software que desempeña
una función parecida, etc. una función parecida, etc.
neral, del futuro software. Con esta información se redacta el documento que neral, del futuro software. Con esta información se redacta el documento que
llamaremos “Especificación de requisitos”, que tiene una doble función: espe- llamaremos “Especificación de requisitos”, que tiene una doble función: espe-
cificar qué debe hacer el software, con la suficiente precisión para que se pueda cificar qué debe hacer el software, con la suficiente precisión para que se pueda
desarrollar, y servir de base para un contrato, explícito o no, entre el equipo desarrollar, y servir de base para un contrato, explícito o no, entre el equipo
de desarrollo del software y sus futuros usuarios. de desarrollo del software y sus futuros usuarios.
El diseño es la etapa siguiente. Si el análisis especifica el problema o El diseño es la etapa siguiente. Si el análisis especifica el problema o
“qué tiene que hacer el software”, el diseño especifica una solución a “qué tiene que hacer el software”, el diseño especifica una solución a
este problema o “cómo el software tiene que hacer su función”. este problema o “cómo el software tiene que hacer su función”.
Del software, hay que diseñar varios aspectos diferenciados: su arquitectura ge- Del software, hay que diseñar varios aspectos diferenciados: su arquitectura ge-
neral, las estructuras de datos (base de datos, etc.), la especificación de cada neral, las estructuras de datos (base de datos, etc.), la especificación de cada
programa y las interfaces con el usuario*, y se tiene que llevar a cabo de ma- * Por ejemplo, menús, diseños programa y las interfaces con el usuario*, y se tiene que llevar a cabo de ma- * Por ejemplo, menús, diseños
de pantalla, listados, etc. de pantalla, listados, etc.
nera que, a partir de todo esto, se pueda codificar el software, de una manera nera que, a partir de todo esto, se pueda codificar el software, de una manera
parecida a la construcción de un edificio o de una máquina a partir de unos parecida a la construcción de un edificio o de una máquina a partir de unos
planos. planos.
El documento resultante es la “Especificación del diseño”. La etapa de diseño El documento resultante es la “Especificación del diseño”. La etapa de diseño
es el mejor momento para elaborar la “Especificación de la prueba”, que des- es el mejor momento para elaborar la “Especificación de la prueba”, que des-
cribe con qué datos se tiene que probar cada programa o grupo de programas cribe con qué datos se tiene que probar cada programa o grupo de programas
y cuáles son los resultados esperados en cada caso. y cuáles son los resultados esperados en cada caso.
La programación o codificación, que es la cuarta etapa, consiste en La programación o codificación, que es la cuarta etapa, consiste en
traducir el diseño a código procesable por el ordenador. traducir el diseño a código procesable por el ordenador.
La prueba es la última etapa del desarrollo del software y la penúltima del mo- La prueba es la última etapa del desarrollo del software y la penúltima del mo-
delo de ciclo de vida del software que hemos considerado. delo de ciclo de vida del software que hemos considerado.
La etapa de prueba consiste en probar el software desde distintos puntos La etapa de prueba consiste en probar el software desde distintos puntos
de vista de una manera planificada y, naturalmente, localizar y corregir de vista de una manera planificada y, naturalmente, localizar y corregir
dentro del software y su documentación los errores que se detecten. dentro del software y su documentación los errores que se detecten.
La prueba se lleva a término en las dos fases siguientes: La prueba se lleva a término en las dos fases siguientes:
• En la primera se hacen pruebas, primero para cada uno de los programas • En la primera se hacen pruebas, primero para cada uno de los programas
por separado y, después, por grupos de programas directamente relaciona- por separado y, después, por grupos de programas directamente relaciona-
dos, y se aplica la especificación de la prueba que hemos mencionado con dos, y se aplica la especificación de la prueba que hemos mencionado con
anterioridad. anterioridad.
• En la segunda fase se comprueba que el conjunto de programas dé los re- • En la segunda fase se comprueba que el conjunto de programas dé los re-
sultados que se esperan y que lo haga con el rendimiento deseado. sultados que se esperan y que lo haga con el rendimiento deseado.
El primer equipo de desarrollo hace la última fase de la prueba y, si los resul- El primer equipo de desarrollo hace la última fase de la prueba y, si los resul-
tados son satisfactorios, se entrega el software al cliente, el cual puede hacer tados son satisfactorios, se entrega el software al cliente, el cual puede hacer
una prueba parecida por su cuenta y con sus datos, con la finalidad de decidir una prueba parecida por su cuenta y con sus datos, con la finalidad de decidir
si acepta el software. Con la aceptación por parte del cliente se da por termina- si acepta el software. Con la aceptación por parte del cliente se da por termina-
do el desarrollo. do el desarrollo.
La última etapa del ciclo de vida es el mantenimiento o, si se prefiere, La última etapa del ciclo de vida es el mantenimiento o, si se prefiere,
explotación, del software, ya que siempre que se utilice el software habrá explotación, del software, ya que siempre que se utilice el software habrá
que mantenerlo, es decir, hacer cambios –pequeños o grandes– para que mantenerlo, es decir, hacer cambios –pequeños o grandes– para
corregir errores, mejorar las funciones o la eficiencia, o adaptarlo a un corregir errores, mejorar las funciones o la eficiencia, o adaptarlo a un
nuevo hardware o a cambios en las necesidades de información. nuevo hardware o a cambios en las necesidades de información.
Puesto que un software puede estar en explotación diez años o más, a menudo Puesto que un software puede estar en explotación diez años o más, a menudo
el coste total del mantenimiento durante la vida del software es de dos a cinco el coste total del mantenimiento durante la vida del software es de dos a cinco
veces mayor que el coste de desarrollo. veces mayor que el coste de desarrollo.
2.1.2. El caso de lenguajes de cuarta generación 2.1.2. El caso de lenguajes de cuarta generación
Los lenguajes –o más bien entornos de programación– de cuarta generación, Los lenguajes –o más bien entornos de programación– de cuarta generación,
son de muy alto nivel (en el sentido de que a menudo una sola de sus instruc- son de muy alto nivel (en el sentido de que a menudo una sola de sus instruc-
ciones equivale a muchas instrucciones del lenguaje ensamblador) y en gran ciones equivale a muchas instrucciones del lenguaje ensamblador) y en gran
parte son no procedimentales y están integrados en un gestor de bases de da- parte son no procedimentales y están integrados en un gestor de bases de da-
tos relacionales; incluyen herramientas de dibujo de pantallas, generación de tos relacionales; incluyen herramientas de dibujo de pantallas, generación de
listados y en ocasiones salidas gráficas y hoja de cálculo. Algunos pueden ge- listados y en ocasiones salidas gráficas y hoja de cálculo. Algunos pueden ge-
nerar código en un lenguaje de tercera generación. nerar código en un lenguaje de tercera generación.
Para aplicaciones sencillas, se puede pasar directamente de los requisitos a la Para aplicaciones sencillas, se puede pasar directamente de los requisitos a la
codificación, pero en proyectos complejos es necesario llevar a cabo una etapa codificación, pero en proyectos complejos es necesario llevar a cabo una etapa
de diseño, aunque simplificada. de diseño, aunque simplificada.
2.2. Los ciclos de vida iterativos e incrementales 2.2. Los ciclos de vida iterativos e incrementales
El ciclo de la vida en cascada ha sido muy criticado y se han propuesto algunos El ciclo de la vida en cascada ha sido muy criticado y se han propuesto algunos
modelos alternativos. modelos alternativos.
2.2.1. Inconvenientes del modelo de ciclo de vida en cascada 2.2.1. Inconvenientes del modelo de ciclo de vida en cascada
El inconveniente del modelo de ciclo de vida en cascada es que no es realista. El inconveniente del modelo de ciclo de vida en cascada es que no es realista.
Como se ha visto, el modelo de ciclo de vida en cascada comporta que las su- Como se ha visto, el modelo de ciclo de vida en cascada comporta que las su-
Consultad el ciclo de vida en Consultad el ciclo de vida en
cesivas etapas del desarrollo se hacen de manera lineal, de forma que una fase cascada en el apartado 2.1 cesivas etapas del desarrollo se hacen de manera lineal, de forma que una fase cascada en el apartado 2.1
de este módulo didáctico. de este módulo didáctico.
no comienza mientras no se haya acabado la anterior y no se vuelve nunca no comienza mientras no se haya acabado la anterior y no se vuelve nunca
atrás. También queda implícito en el modelo que, cuando se acaba una fase, atrás. También queda implícito en el modelo que, cuando se acaba una fase,
se sabe al menos aproximadamente qué porcentaje del proyecto queda por ha- se sabe al menos aproximadamente qué porcentaje del proyecto queda por ha-
cer, ya que si el análisis se ha completado y su resultado es cien por cien fijo, cer, ya que si el análisis se ha completado y su resultado es cien por cien fijo,
ciertamente se puede saber con cierta precisión la duración del diseño e, inclu- ciertamente se puede saber con cierta precisión la duración del diseño e, inclu-
so, de la programación. so, de la programación.
Ahora bien, en la realidad es posible que la especificación del sistema sea fia- Ahora bien, en la realidad es posible que la especificación del sistema sea fia-
ble por lo que respecta a las funciones, ya que no se espera que se describan ble por lo que respecta a las funciones, ya que no se espera que se describan
punto por punto; sin embargo, precisamente por esto último, el coste y la punto por punto; sin embargo, precisamente por esto último, el coste y la
duración del proyecto se han calculado sobre una base muy poco sólida y tie- duración del proyecto se han calculado sobre una base muy poco sólida y tie-
nen un gran margen de error. nen un gran margen de error.
No obstante, el problema más grave se presenta en el análisis de requisitos, por el No obstante, el problema más grave se presenta en el análisis de requisitos, por el
hecho de que éstos casi siempre son incompletos al principio o cambian antes de hecho de que éstos casi siempre son incompletos al principio o cambian antes de
que se haya acabado de construir el software, y a menudo suceden ambas cosas a que se haya acabado de construir el software, y a menudo suceden ambas cosas a
la vez. Y si la especificación de requisitos es incompleta e insegura, es obvio que la vez. Y si la especificación de requisitos es incompleta e insegura, es obvio que
el diseño y la programación tendrán problemas y, sobre todo, retrasos y aumentos el diseño y la programación tendrán problemas y, sobre todo, retrasos y aumentos
de coste importantes para el trabajo no previsto que se deberá hacer y también de coste importantes para el trabajo no previsto que se deberá hacer y también
para el que será necesario rehacer. para el que será necesario rehacer.
Existen dos razones por las cuales es prácticamente imposible elaborar unos Existen dos razones por las cuales es prácticamente imposible elaborar unos
requisitos completos y estables en el primer intento: requisitos completos y estables en el primer intento:
a) En primer lugar, es difícil encontrar un conjunto de futuros usuarios que co- a) En primer lugar, es difícil encontrar un conjunto de futuros usuarios que co-
nozcan lo suficiente el entorno en el que se tiene que utilizar el software, que ha- nozcan lo suficiente el entorno en el que se tiene que utilizar el software, que ha-
yan reflexionado lo suficiente sobre lo que quieren conseguir y que, además, se yan reflexionado lo suficiente sobre lo que quieren conseguir y que, además, se
pongan de acuerdo. pongan de acuerdo.
b) En segundo lugar, porque el trabajo de consolidación de las peticiones de b) En segundo lugar, porque el trabajo de consolidación de las peticiones de
estos usuarios nunca será perfecto. estos usuarios nunca será perfecto.
En qualquier caso, tenemos que contar con el hecho de que, una vez termina- En qualquier caso, tenemos que contar con el hecho de que, una vez termina-
da oficialmente la etapa de análisis y comenzada la de diseño, todavía surgirán da oficialmente la etapa de análisis y comenzada la de diseño, todavía surgirán
requisitos nuevos y cambios en los ya existentes. requisitos nuevos y cambios en los ya existentes.
¿Qué se puede hacer, entonces? Parece que la opción más razonable sea estu- ¿Qué se puede hacer, entonces? Parece que la opción más razonable sea estu-
diar a fondo una pequeña parte de los requisitos que tenga una cierta autono- diar a fondo una pequeña parte de los requisitos que tenga una cierta autono-
mía, y diseñarla, programarla y probarla, y una vez que el cliente la haya dado mía, y diseñarla, programarla y probarla, y una vez que el cliente la haya dado
por buena, hacer lo mismo con otra parte, y otra; si partimos de un software ya por buena, hacer lo mismo con otra parte, y otra; si partimos de un software ya
construido en parte, se puede esperar que la idea que nos hacemos de los re- construido en parte, se puede esperar que la idea que nos hacemos de los re-
quisitos restantes pueda ser cada vez más precisa y que también obtengamos quisitos restantes pueda ser cada vez más precisa y que también obtengamos
una estimación cada vez más segura del coste y de la duración del proyecto una estimación cada vez más segura del coste y de la duración del proyecto
completo; esto es lo que denominamos ciclo de vida iterativo e incremental completo; esto es lo que denominamos ciclo de vida iterativo e incremental
(iterativo porque se repite dentro de un mismo proyecto e incremental porque (iterativo porque se repite dentro de un mismo proyecto e incremental porque
procede por partes). Y se tendrá que considerar normal que, a veces, cuando procede por partes). Y se tendrá que considerar normal que, a veces, cuando
se construya una parte, se vea que es necesario modificar una hecha con ante- se construya una parte, se vea que es necesario modificar una hecha con ante-
rioridad. rioridad.
La necesidad de estimar el coste y los plazos La necesidad de estimar el coste y los plazos
Los inconvenientes del modelo del ciclo de vida clásico mencionados en este subapar- Los inconvenientes del modelo del ciclo de vida clásico mencionados en este subapar-
tado no quieren decir que no pueda haber plazo o límite de coste para un proyecto tado no quieren decir que no pueda haber plazo o límite de coste para un proyecto
de desarrollo de software; simplemente, se tiene que reconocer que no es realista creer de desarrollo de software; simplemente, se tiene que reconocer que no es realista creer
que se pueda fijar exactamente la funcionalidad, el coste y la duración del proyecto, que se pueda fijar exactamente la funcionalidad, el coste y la duración del proyecto,
todo a la vez. Si el software tiene que funcionar en una fecha determinada y no se pue- todo a la vez. Si el software tiene que funcionar en una fecha determinada y no se pue-
de aumentar el gasto en personal, será necesario estar dispuesto a aceptar que el software de aumentar el gasto en personal, será necesario estar dispuesto a aceptar que el software
no realice todas las funciones deseadas; si la funcionalidad y la fecha de entrega del progra- no realice todas las funciones deseadas; si la funcionalidad y la fecha de entrega del progra-
ma son innegociables, se tendrá que aumentar el número de programadores o analistas. Y ma son innegociables, se tendrá que aumentar el número de programadores o analistas. Y
esto no supone ninguna renuncia en relación con los resultados que se alcanzaban hasta esto no supone ninguna renuncia en relación con los resultados que se alcanzaban hasta
ahora, porque en la práctica bien pocos eran los proyectos en los que no se producían ahora, porque en la práctica bien pocos eran los proyectos en los que no se producían
desviaciones en cuanto a la funcionalidad, presupuesto o plazo, sino en varias de es- desviaciones en cuanto a la funcionalidad, presupuesto o plazo, sino en varias de es-
tas cosas al mismo tiempo. tas cosas al mismo tiempo.
Por tanto, el modelo de ciclo de vida en cascada puede ser válido si se Por tanto, el modelo de ciclo de vida en cascada puede ser válido si se
aplica de manera que cada etapa, del análisis de requisitos a la prueba, aplica de manera que cada etapa, del análisis de requisitos a la prueba,
no prevea todo el conjunto del software, sino sólo una parte cada vez; no prevea todo el conjunto del software, sino sólo una parte cada vez;
entonces tendríamos un ciclo de vida iterativo e incremental basado en entonces tendríamos un ciclo de vida iterativo e incremental basado en
el ciclo de vida en cascada. el ciclo de vida en cascada.
2.2.2. El ciclo de vida con prototipos 2.2.2. El ciclo de vida con prototipos
Para ayudar a concretar los requisitos, se puede recurrir a construir un proto- Para ayudar a concretar los requisitos, se puede recurrir a construir un proto-
tipo del software. tipo del software.
Un prototipo es un software provisional, construido con herramientas Un prototipo es un software provisional, construido con herramientas
y técnicas que dan prioridad a la rapidez y a la facilidad de modificación y técnicas que dan prioridad a la rapidez y a la facilidad de modificación
antes que a la eficiencia en el funcionamiento, que sólo tiene que servir antes que a la eficiencia en el funcionamiento, que sólo tiene que servir
para que los usuarios puedan ver cómo sería el contenido o la apariencia para que los usuarios puedan ver cómo sería el contenido o la apariencia
de los resultados de algunas de las funciones del futuro software. de los resultados de algunas de las funciones del futuro software.
Un prototipo sirve para que los usuarios puedan confirmar que lo que se les mues- Un prototipo sirve para que los usuarios puedan confirmar que lo que se les mues-
tra, efectivamente, es lo que necesitan o bien lo puedan pedir por comparación, tra, efectivamente, es lo que necesitan o bien lo puedan pedir por comparación,
y entonces se prepara una nueva versión del prototipo teniendo en cuenta las in- y entonces se prepara una nueva versión del prototipo teniendo en cuenta las in-
dicaciones de los usuarios y se les enseña otra vez. Una vez que el prototipo ha dicaciones de los usuarios y se les enseña otra vez. Una vez que el prototipo ha
permitido concretar y confirmar los requisitos, se puede comenzar un desarrollo permitido concretar y confirmar los requisitos, se puede comenzar un desarrollo
según el ciclo de vida en cascada, en este caso, no obstante, partiendo de una base según el ciclo de vida en cascada, en este caso, no obstante, partiendo de una base
mucho más sólida. mucho más sólida.
Características del ciclo de vida con prototipos Características del ciclo de vida con prototipos
El ciclo de vida con prototipos no se puede considerar plenamente un ciclo de vida iterativo El ciclo de vida con prototipos no se puede considerar plenamente un ciclo de vida iterativo
e incremental, ya que sólo el prototipo se elabora de manera iterativa, y no necesariamente e incremental, ya que sólo el prototipo se elabora de manera iterativa, y no necesariamente
incremental; sin embargo, es un modelo de ciclo de vida que puede ser adecuado en algunos incremental; sin embargo, es un modelo de ciclo de vida que puede ser adecuado en algunos
casos, especialmente cuando basta con prototipar un número reducido de funciones para casos, especialmente cuando basta con prototipar un número reducido de funciones para
que las otras sean bastante parecidas a éstas de forma que las conclusiones a las que se llegue que las otras sean bastante parecidas a éstas de forma que las conclusiones a las que se llegue
con el prototipo también les sean aplicables. con el prototipo también les sean aplicables.
2.2.3. La programación exploratoria 2.2.3. La programación exploratoria
La programación exploratoria consiste en elaborar una primera versión La programación exploratoria consiste en elaborar una primera versión
del software, o de una parte de éste, enseñarla a los usuarios para que del software, o de una parte de éste, enseñarla a los usuarios para que
la critiquen y, a continuación, hacerle los cambios que éstos sugieran, la critiquen y, a continuación, hacerle los cambios que éstos sugieran,
proceso que se repetirá tantas veces como sea necesario. proceso que se repetirá tantas veces como sea necesario.
La diferencia principal con respecto a los prototipos es que aquí el software es La diferencia principal con respecto a los prototipos es que aquí el software es
real desde el principio. real desde el principio.
Características de la programación exploratoria Características de la programación exploratoria

La programación exploratoria se puede considerar un ciclo de vida iterativo, pero no incre- La programación exploratoria se puede considerar un ciclo de vida iterativo, pero no incre-
mental, ya que el software está completo desde la primera versión. Como consecuencia de las mental, ya que el software está completo desde la primera versión. Como consecuencia de las
numerosas modificaciones que sufre, la calidad del software desarrollado de esta manera y de numerosas modificaciones que sufre, la calidad del software desarrollado de esta manera y de
su documentación tiende a ser deficiente, como la de un software que haya experimentado su documentación tiende a ser deficiente, como la de un software que haya experimentado
un mantenimiento largo e intenso. un mantenimiento largo e intenso.
2.2.4. El ciclo de vida del Rational Unified Process 2.2.4. El ciclo de vida del Rational Unified Process
La empresa Rational Software ha propuesto este ciclo de vida como marco para La empresa Rational Software ha propuesto este ciclo de vida como marco para
el desarrollo de software que utiliza sus herramientas. Es claramente un ciclo el desarrollo de software que utiliza sus herramientas. Es claramente un ciclo
de vida iterativo e incremental. de vida iterativo e incremental.
Se distinguen estas cuatro etapas (denominadas fases): Se distinguen estas cuatro etapas (denominadas fases):
1) Inicio (inception), en la que se establece la justificación económica del software 1) Inicio (inception), en la que se establece la justificación económica del software
y se delimita el alcance del proyecto. y se delimita el alcance del proyecto.
2) Elaboración, en la cual se estudia el dominio del problema, o simplemente 2) Elaboración, en la cual se estudia el dominio del problema, o simplemente
dominio (parte de la actividad de la empresa dentro de la cual se utilizará el dominio (parte de la actividad de la empresa dentro de la cual se utilizará el
software) y se tienen en cuenta muchas de las necesidades de información y software) y se tienen en cuenta muchas de las necesidades de información y
eventuales requisitos no funcionales y restricciones, se establece la arquitectu- eventuales requisitos no funcionales y restricciones, se establece la arquitectu-
ra general del software y se realiza una planificación del proyecto. ra general del software y se realiza una planificación del proyecto.
3) Construcción, en la que se desarrolla todo el producto de forma iterativa 3) Construcción, en la que se desarrolla todo el producto de forma iterativa
e incremental, tiene en cuenta todas las necesidades de información que debe e incremental, tiene en cuenta todas las necesidades de información que debe
satisfacer y desarrolla la arquitectura obtenida en la fase anterior. satisfacer y desarrolla la arquitectura obtenida en la fase anterior.
4) Transición, que comprende la entrega del producto al cliente y el comien- 4) Transición, que comprende la entrega del producto al cliente y el comien-
zo de su utilización; aunque es posible que sea necesario hacer retoques en el zo de su utilización; aunque es posible que sea necesario hacer retoques en el
software y añadir nuevas funciones como consecuencia de errores detectados software y añadir nuevas funciones como consecuencia de errores detectados
o de requisitos que se habían pasado por alto hasta el momento. o de requisitos que se habían pasado por alto hasta el momento.
En cada una de estas fases se llevan a término (en diferentes proporciones) los En cada una de estas fases se llevan a término (en diferentes proporciones) los
siguientes componentes de proceso: siguientes componentes de proceso:
• recogida de requisitos (requirement capture), • recogida de requisitos (requirement capture),

• análisis y diseño, • análisis y diseño,
• realización (implementation), • realización (implementation),
• prueba (test). • prueba (test).
Cada unidad en la que se ejecutan pocos o muchos de los componentes de Cada unidad en la que se ejecutan pocos o muchos de los componentes de
proceso es una iteración, y se aplica a un nuevo fragmento de software. Todas Ahora conviene que realicéis los proceso es una iteración, y se aplica a un nuevo fragmento de software. Todas Ahora conviene que realicéis los
ejercicios de autoavaluación del 4 ejercicios de autoavaluación del 4
al 10 de este módulo didáctico. al 10 de este módulo didáctico.
las fases tienen iteraciones. las fases tienen iteraciones.
3. Desarrollo estructurado y desarrollo orientado 3. Desarrollo estructurado y desarrollo orientado

a objetos a objetos
Los métodos de desarrollo de software más utilizados hasta ahora pertenecen Los métodos de desarrollo de software más utilizados hasta ahora pertenecen
a dos grandes grupos: los métodos estructurados y los métodos orientados a a dos grandes grupos: los métodos estructurados y los métodos orientados a
objetos. objetos.
3.1. Los métodos estructurados 3.1. Los métodos estructurados
Técnicas utilizadas para Técnicas utilizadas para

Los métodos estructurados provienen de la programación estructurada los métodos estructurados Los métodos estructurados provienen de la programación estructurada los métodos estructurados
y se utilizan técnicas no muy integradas entre sí. Las técnicas más usadas
y se utilizan técnicas no muy integradas entre sí. Las técnicas más usadas
en los métodos estructurados en los métodos estructurados
son seguramente los dia- son seguramente los dia-
gramas de entidad-relación y gramas de entidad-relación y
de flujo de datos, con sus va- de flujo de datos, con sus va-
Los métodos estructurados tienen, asimismo, estas características: riantes. El primero se refiere a
Los métodos estructurados tienen, asimismo, estas características: riantes. El primero se refiere a
los datos y el segundo, a los los datos y el segundo, a los
procesos. procesos.
• La especificación de los procesos y la de las estructuras de datos general- • La especificación de los procesos y la de las estructuras de datos general-
mente quedan bastante diferenciadas, y hay métodos que ponen más én- mente quedan bastante diferenciadas, y hay métodos que ponen más én-
fasis en aquéllos o en éstos. fasis en aquéllos o en éstos.
• Muchas de sus técnicas o bien pasan de lo general a lo particular (técnicas • Muchas de sus técnicas o bien pasan de lo general a lo particular (técnicas
top-down) o bien a la inversa (técnicas bottom-up). top-down) o bien a la inversa (técnicas bottom-up).
3.2. Los métodos orientados a objetos 3.2. Los métodos orientados a objetos
Si bien los métodos estructurados continúan siendo muy utilizados, los deno- Si bien los métodos estructurados continúan siendo muy utilizados, los deno-
minados métodos orientados a objetos ganan terreno rápidamente. minados métodos orientados a objetos ganan terreno rápidamente.
Si los métodos estructurados de desarrollo de software tienen su origen Si los métodos estructurados de desarrollo de software tienen su origen
en la programación estructurada, los métodos orientados a objetos tie- en la programación estructurada, los métodos orientados a objetos tie-
nen sus raíces en la programación orientada a objetos. nen sus raíces en la programación orientada a objetos.
Es lógico que haya sucedido así en los dos casos, ya que una nueva técnica de Es lógico que haya sucedido así en los dos casos, ya que una nueva técnica de
programar exige una nueva manera de diseñar los programas adaptada a las programar exige una nueva manera de diseñar los programas adaptada a las
características de la programación, y un nuevo método de diseño hace desea- características de la programación, y un nuevo método de diseño hace desea-
ble un nuevo método de análisis de requisitos que tenga la misma orientación ble un nuevo método de análisis de requisitos que tenga la misma orientación
que el diseño, con la finalidad de evitar que el paso del análisis de requisitos que el diseño, con la finalidad de evitar que el paso del análisis de requisitos
al diseño implique un cambio de modelo que inevitablemente comportaría un al diseño implique un cambio de modelo que inevitablemente comportaría un
trabajo adicional y un mayor riesgo de errores. trabajo adicional y un mayor riesgo de errores.
De la misma manera que la programación orientada a objetos gira en torno al De la misma manera que la programación orientada a objetos gira en torno al
concepto de clase, también lo hacen el análisis de requisitos y el diseño. Por concepto de clase, también lo hacen el análisis de requisitos y el diseño. Por
esta razón, el diagrama básico de estos métodos, el diagrama de clases y ob- esta razón, el diagrama básico de estos métodos, el diagrama de clases y ob-
jetos, se utiliza tanto en el análisis como en el diseño; además, muchas de las jetos, se utiliza tanto en el análisis como en el diseño; además, muchas de las
clases descritas en el análisis de requisitos se implementan en los programas clases descritas en el análisis de requisitos se implementan en los programas
pasando por el diseño, lo cual hace que el paso del análisis de requisitos al di- pasando por el diseño, lo cual hace que el paso del análisis de requisitos al di-
seño sea más suave que en los métodos estructurados y también más sencillo seño sea más suave que en los métodos estructurados y también más sencillo
y rápido. y rápido.
Puesto que dentro de una clase hay a la vez atributos y operaciones, es decir, datos Puesto que dentro de una clase hay a la vez atributos y operaciones, es decir, datos
y procesos, en el desarrollo orientado a objetos a medida que se definen e imple- y procesos, en el desarrollo orientado a objetos a medida que se definen e imple-
mentan clases se avanza al mismo tiempo en estas dos dimensiones. El desarrollo mentan clases se avanza al mismo tiempo en estas dos dimensiones. El desarrollo
no procede ni de manera top-down ni bottom-up, sino que, más bien, se construyen no procede ni de manera top-down ni bottom-up, sino que, más bien, se construyen
grupos de clases interrelacionadas, a menudo por niveles: clases que gestionan la grupos de clases interrelacionadas, a menudo por niveles: clases que gestionan la
presentación de la información, o bien las entradas por pantalla, o bien las lectu- presentación de la información, o bien las entradas por pantalla, o bien las lectu-
ras y grabaciones de la base de datos, o bien los algoritmos principales del software; ras y grabaciones de la base de datos, o bien los algoritmos principales del software;
o bien proceden según un ciclo de vida incremental, tal como hemos visto. o bien proceden según un ciclo de vida incremental, tal como hemos visto.
Cabe añadir que el desarrollo orientado a objetos, además de introducir técnicas Cabe añadir que el desarrollo orientado a objetos, además de introducir técnicas
nuevas, también aprovecha algunas técnicas y conceptos del desarrollo estruc- nuevas, también aprovecha algunas técnicas y conceptos del desarrollo estruc-
turado, como el diagrama de estados y transiciones, según veremos. turado, como el diagrama de estados y transiciones, según veremos.
Hay dos características del desarrollo orientado a objetos que probablemen- Hay dos características del desarrollo orientado a objetos que probablemen-
te han favorecido de manera decisiva su expansión hasta ahora y probable- te han favorecido de manera decisiva su expansión hasta ahora y probable-
mente la continuarán favoreciendo: mente la continuarán favoreciendo:
• Parece que permite –por primera vez en la historia de la tecnología del • Parece que permite –por primera vez en la historia de la tecnología del
software– la reutilización de software en un grado significativo, en forma software– la reutilización de software en un grado significativo, en forma
de clases implementadas, lo cual podría significar una vía para solucionar, de clases implementadas, lo cual podría significar una vía para solucionar,
aunque sólo sea en parte, los problemas de productividad y calidad descri- aunque sólo sea en parte, los problemas de productividad y calidad descri-
tos en apartados anteriores. tos en apartados anteriores.
• Su relativa simplicidad facilita el desarrollo de herramientas informáti- • Su relativa simplicidad facilita el desarrollo de herramientas informáti-
cas de ayuda al desarrollo; este factor podría ser potenciado por el hecho cas de ayuda al desarrollo; este factor podría ser potenciado por el hecho
de que en estos últimos años ha aparecido una notación orientada a obje- de que en estos últimos años ha aparecido una notación orientada a obje-
tos muy ampliamente aceptada, UML. tos muy ampliamente aceptada, UML.
3.3. Los métodos formales 3.3. Los métodos formales
Los denominados métodos formales parten de una especificación de las Los denominados métodos formales parten de una especificación de las
necesidades de información en términos de un modelo matemático ri- necesidades de información en términos de un modelo matemático ri-
guroso, del cual se podría deducir el programa que les satisfaga; también guroso, del cual se podría deducir el programa que les satisfaga; también
permitían demostrar matemáticamente que un programa es correcto en permitían demostrar matemáticamente que un programa es correcto en
el sentido de que se ajusta a aquellas necesidades. el sentido de que se ajusta a aquellas necesidades.
Aunque tendrían que permitir eliminar las ambigüedades y carencias de los Aunque tendrían que permitir eliminar las ambigüedades y carencias de los
métodos no tan rigurosos, su utilización directa en el desarrollo de software métodos no tan rigurosos, su utilización directa en el desarrollo de software
para usos reales es poco frecuente en la actualidad, sin duda debido a la gran Algunos de los lenguajes para usos reales es poco frecuente en la actualidad, sin duda debido a la gran Algunos de los lenguajes
de especificación formal más de especificación formal más
complejidad que tendría un modelado tan detallado y formalizado en casos conocidos son Z, VDM, CSP complejidad que tendría un modelado tan detallado y formalizado en casos conocidos son Z, VDM, CSP
y LARCH. y LARCH.
reales. reales.
4. Las herramientas CASE 4. Las herramientas CASE
CASE significa Computer-Aided Software Engineering. Las herramientas CASE CASE significa Computer-Aided Software Engineering. Las herramientas CASE
son software de apoyo al desarrollo, mantenimiento y documentación in- son software de apoyo al desarrollo, mantenimiento y documentación in-
formatizados de software. formatizados de software.
De esta definición generalmente se excluyen las herramientas que tienen una De esta definición generalmente se excluyen las herramientas que tienen una
de las funciones siguientes: de las funciones siguientes:
1) o bien no tienen sólo esta finalidad (herramientas de tratamiento de texto, 1) o bien no tienen sólo esta finalidad (herramientas de tratamiento de texto,
de hoja de cálculo, de dibujo en general, de planificación de proyectos de cual- de hoja de cálculo, de dibujo en general, de planificación de proyectos de cual-
quier ingeniería), ya que propiamente pertenecen a otros ámbitos; quier ingeniería), ya que propiamente pertenecen a otros ámbitos;
2) o bien se utilizan para codificar el software (compiladores, entornos de cuarta 2) o bien se utilizan para codificar el software (compiladores, entornos de cuarta
generación, editores ordinarios de programas, etc.), ya que siempre están pre- generación, editores ordinarios de programas, etc.), ya que siempre están pre-
sentes, incluso cuando el desarrollo de software se hace de la manera más ma- sentes, incluso cuando el desarrollo de software se hace de la manera más ma-
nual posible. nual posible.
Quedan, pues, principalmente las herramientas que ayudan a aplicar técnicas Quedan, pues, principalmente las herramientas que ayudan a aplicar técnicas
Herramientas UpperCASE Herramientas UpperCASE
concretas de desarrollo y mantenimiento de software y por eso gestionan in- y LowerCASE concretas de desarrollo y mantenimiento de software y por eso gestionan in- y LowerCASE
formación sobre los elementos y conceptos que se utilizan en los métodos de A veces se distingue entre he- formación sobre los elementos y conceptos que se utilizan en los métodos de A veces se distingue entre he-
rramientas UpperCASE, que son rramientas UpperCASE, que son
desarrollo, como las siguientes: las de análisis y diseño, y Lo-
desarrollo, como las siguientes: las de análisis y diseño, y Lo-
werCASE, que se usan durante werCASE, que se usan durante
la programación y la prueba. la programación y la prueba.
• Las herramientas diagramáticas, las cuales, a diferencia de las de dibujo, re- • Las herramientas diagramáticas, las cuales, a diferencia de las de dibujo, re-
conocen que un determinado símbolo es una clase y no simplemente un rec- conocen que un determinado símbolo es una clase y no simplemente un rec-
tángulo. Estas herramientas también acostumbran a aceptar documentación tángulo. Estas herramientas también acostumbran a aceptar documentación
textual sobre aquellos elementos. textual sobre aquellos elementos.
• Las herramientas de gestión de la prueba y de gestión de la calidad en ge- • Las herramientas de gestión de la prueba y de gestión de la calidad en ge-
neral. neral.
• Las herramientas de gestión de cambios, etc. • Las herramientas de gestión de cambios, etc.
La importancia de la integración de las herramientas La importancia de la integración de las herramientas

Es conveniente que las herramientas que dan soporte a diferentes técnicas utilizadas dentro Es conveniente que las herramientas que dan soporte a diferentes técnicas utilizadas dentro
del mismo método estén integradas, en el sentido de que si hay un tipo de elemento que es del mismo método estén integradas, en el sentido de que si hay un tipo de elemento que es
común a dos técnicas, sea compartido por las dos herramientas respectivas, de manera que común a dos técnicas, sea compartido por las dos herramientas respectivas, de manera que
sólo sea necesario describirlo una vez y que todos los cambios que se realicen después en esta sólo sea necesario describirlo una vez y que todos los cambios que se realicen después en esta
descripción lleguen a las dos. descripción lleguen a las dos.
La expansión del uso de herramientas CASE en el método estructurado se fre- La expansión del uso de herramientas CASE en el método estructurado se fre-
nó a causa de la diversidad y de la falta de estandarización de las técnicas que nó a causa de la diversidad y de la falta de estandarización de las técnicas que
Podéis consultar los métodos Podéis consultar los métodos
se utilizan; en los métodos orientados a objetos, en cambio, actualmente la si- orientados a objetos en el se utilizan; en los métodos orientados a objetos, en cambio, actualmente la si- orientados a objetos en el
subapartado 3.2 de este módulo subapartado 3.2 de este módulo
tuación es la contraria: por un lado, algunos diagramas sirven tanto para el didáctico. tuación es la contraria: por un lado, algunos diagramas sirven tanto para el didáctico.
análisis como para el diseño, y por el otro, se ha producido una estandariza- análisis como para el diseño, y por el otro, se ha producido una estandariza-
ción de las técnicas y notaciones en el modelo conocido como UML que ha ción de las técnicas y notaciones en el modelo conocido como UML que ha
hecho que en el poco tiempo transcurrido desde su publicación hayan apare- hecho que en el poco tiempo transcurrido desde su publicación hayan apare-
cido un número importante de conjuntos integrados de herramientas CASE cido un número importante de conjuntos integrados de herramientas CASE
basadas en él; este soporte informatizado, amplio y creciente, en el desarrollo basadas en él; este soporte informatizado, amplio y creciente, en el desarrollo
de software orientado a objetos sin duda reforzará la mejora de la calidad y la de software orientado a objetos sin duda reforzará la mejora de la calidad y la
productividad en el desarrollo de software que, tal como hemos visto, la tecno- productividad en el desarrollo de software que, tal como hemos visto, la tecno-
logía orientada a objetos tiene que fomentar. logía orientada a objetos tiene que fomentar.
5. El OMG y el UML 5. El OMG y el UML
Para el desarrollo orientado a objetos utilizaremos el modelo denominado Para el desarrollo orientado a objetos utilizaremos el modelo denominado
UML, del cual actualmente es responsable la organización llamada OMG. UML, del cual actualmente es responsable la organización llamada OMG.
5.1. El Object Management Group (OMG) 5.1. El Object Management Group (OMG)
El otro estándar del OMG El otro estándar del OMG

El Object Management Group (OMG), creado en 1989, es una organización El Object Management Group (OMG), creado en 1989, es una organización
Además de UML, otro estándar Además de UML, otro estándar
no lucrativa en la que participan más de ochocientas grandes empresas que ha elaborado el OMG es no lucrativa en la que participan más de ochocientas grandes empresas que ha elaborado el OMG es
CORBA, sobre objetos distri- CORBA, sobre objetos distri-
de software, de hardware, usuarias y consultoras, y tiene la finalidad de fo- de software, de hardware, usuarias y consultoras, y tiene la finalidad de fo-
buidos, cuyas implementacio- buidos, cuyas implementacio-
mentar el uso de la tecnología de objetos e impulsar la introducción de nes tienen una expansión mentar el uso de la tecnología de objetos e impulsar la introducción de nes tienen una expansión
rápida. rápida.
software orientado a objetos que ofrezca reusabilidad, portabilidad e inte- software orientado a objetos que ofrezca reusabilidad, portabilidad e inte-
roperabilidad en entornos distribuidos heterogéneos. roperabilidad en entornos distribuidos heterogéneos.
El medio con el que el OMG intenta conseguir sus objetivos es la elaboración de El medio con el que el OMG intenta conseguir sus objetivos es la elaboración de
estándares, para los cuales acepta propuestas; en cambio, no produce software ni estándares, para los cuales acepta propuestas; en cambio, no produce software ni
elabora especificaciones de implementación o funcionalidad. elabora especificaciones de implementación o funcionalidad.
5.2. Unified Modeling Language (UML) 5.2. Unified Modeling Language (UML)
El Unified Modeling Language (UML) es un modelo para la construcción El Unified Modeling Language (UML) es un modelo para la construcción
de software orientado a objetos que ha sido propuesto como estándar de de software orientado a objetos que ha sido propuesto como estándar de
ISO por el OMG. Consta de un conjunto de tipos de diagramas interre- ISO por el OMG. Consta de un conjunto de tipos de diagramas interre-
lacionados, dentro de los cuales se utilizan elementos del modelo, que lacionados, dentro de los cuales se utilizan elementos del modelo, que
sirven parar describir distintos aspectos de la estructura y la dinámica del sirven parar describir distintos aspectos de la estructura y la dinámica del
software. software.
UML es el resultado de una cierta unificación de los modelos utilizados en tres UML es el resultado de una cierta unificación de los modelos utilizados en tres
métodos preexistentes de desarrollo de software orientado a objetos hechos métodos preexistentes de desarrollo de software orientado a objetos hechos
por sus autores en colaboración. Estos métodos son los siguientes: por sus autores en colaboración. Estos métodos son los siguientes:
• el método de Grady Booch; • el método de Grady Booch;

• el OMT, de Jim Rumbaugh y otros; • el OMT, de Jim Rumbaugh y otros;
• el OOSE, de Ivar Jacobson. • el OOSE, de Ivar Jacobson.
Además, se encuentran conceptos aportados por bastantes otros autores, entre Además, se encuentran conceptos aportados por bastantes otros autores, entre
ellos Peter Coad, Edward Yourdon, James Odell y Bertrand Meyer. ellos Peter Coad, Edward Yourdon, James Odell y Bertrand Meyer.
Evolución del modelo UML Evolución del modelo UML

Los primeros pasos hacia el modelo unificado se dieron en el año 1994, cuando Booch Los primeros pasos hacia el modelo unificado se dieron en el año 1994, cuando Booch
y Rumbaugh, trabajando en Rational Software Corporation, comenzaron la unificación y Rumbaugh, trabajando en Rational Software Corporation, comenzaron la unificación
de los modelos respectivos, y en octubre de 1995 se publicó la versión provisional 0.8 de los modelos respectivos, y en octubre de 1995 se publicó la versión provisional 0.8
del entonces denominado Unified Method. del entonces denominado Unified Method.
El mismo año, Jacobson se incorporó con su empresa al equipo mencionado y a Rational y, El mismo año, Jacobson se incorporó con su empresa al equipo mencionado y a Rational y,
como resultado del trabajo de los tres autores, en 1996 salieron las versiones 0.9 y 0.91 de como resultado del trabajo de los tres autores, en 1996 salieron las versiones 0.9 y 0.91 de
UML. El OMG emitió en aquella época una Request For Proposal, para un modelo de este tipo, UML. El OMG emitió en aquella época una Request For Proposal, para un modelo de este tipo,
y entonces Rational, para responderle, constituyó un consorcio con otras organizaciones, y entonces Rational, para responderle, constituyó un consorcio con otras organizaciones,
con el resultado de que en enero de 1997 se presentó en la OMG la versión 1.0 de UML. con el resultado de que en enero de 1997 se presentó en la OMG la versión 1.0 de UML.
Otras empresas que habían presentado también respuestas de manera independiente se aña- Otras empresas que habían presentado también respuestas de manera independiente se aña-
dieron al consorcio y se publicó la versión 1.1, que fue aceptada por el OMG en noviembre dieron al consorcio y se publicó la versión 1.1, que fue aceptada por el OMG en noviembre
de 1997 (hubo otra propuesta, la del modelo OML, que tenía y todavía tiene un número im- de 1997 (hubo otra propuesta, la del modelo OML, que tenía y todavía tiene un número im-
portante de partidarios). El OMG encargó una revisión, cuyo resultado fue una versión 1.2, portante de partidarios). El OMG encargó una revisión, cuyo resultado fue una versión 1.2,
no publicada, y la versión 1.3, ya publicada como estándar. La versión 1.4 se publicó oficial- no publicada, y la versión 1.3, ya publicada como estándar. La versión 1.4 se publicó oficial-
mente en septiembre de 2001. mente en septiembre de 2001.
Con UML se ha llegado a un modelo orientado a objetos único como modelo Consultad el subapartado 1.4 Con UML se ha llegado a un modelo orientado a objetos único como modelo Consultad el subapartado 1.4
de este módulo didáctico. de este módulo didáctico.
oficial, pero eso no quiere decir que se haya alcanzado un método único de oficial, pero eso no quiere decir que se haya alcanzado un método único de
desarrollo orientado a objetos; la verdad es que por el momento parece que fal- desarrollo orientado a objetos; la verdad es que por el momento parece que fal-
ta bastante para llegar al mismo, si es que alguna vez se consigue. Es decir, que ta bastante para llegar al mismo, si es que alguna vez se consigue. Es decir, que
lo que se ha conseguido es que haya unos diagramas que todos los desarrolla- lo que se ha conseguido es que haya unos diagramas que todos los desarrolla-
dores de software orientado a objetos entenderán y harán de la misma manera, dores de software orientado a objetos entenderán y harán de la misma manera,
lo cual supone un adelanto realmente importante con respecto a la situación lo cual supone un adelanto realmente importante con respecto a la situación
anterior en la que cada método tenía su notación gráfica; pero, incluso así, anterior en la que cada método tenía su notación gráfica; pero, incluso así,
continúa siendo posible que existan métodos diferentes que utilicen UML y continúa siendo posible que existan métodos diferentes que utilicen UML y
Llegados a este punto, conviene Llegados a este punto, conviene
que, por ejemplo, se valgan de los mismos diagramas en orden diferente o que respondáis a los ejercicios de
autoavaluación del 11 al 13 de este
que, por ejemplo, se valgan de los mismos diagramas en orden diferente o que respondáis a los ejercicios de
autoavaluación del 11 al 13 de este
módulo didáctico. módulo didáctico.
dentro de modelos de ciclo de vida distintos. dentro de modelos de ciclo de vida distintos.
Resumen Resumen
Se ha concretado qué se entiende por software en esta asignatura, se ha indica- Se ha concretado qué se entiende por software en esta asignatura, se ha indica-
do por qué se puede considerar un producto industrial y, como consecuencia, do por qué se puede considerar un producto industrial y, como consecuencia,
por qué tiene sentido hablar de una ingeniería del software, y también hemos por qué tiene sentido hablar de una ingeniería del software, y también hemos
entrado en contacto con los dos grandes problemas que han afectado tradicio- entrado en contacto con los dos grandes problemas que han afectado tradicio-
nalmente al desarrollo de software: las carencias referidas a la productividad y nalmente al desarrollo de software: las carencias referidas a la productividad y
calidad. calidad.
Si entramos dentro del proceso de elaboración del software, hemos visto el con- Si entramos dentro del proceso de elaboración del software, hemos visto el con-
cepto de ciclo de vida y sus dos grandes modelos –el ciclo de vida en cascada o cepto de ciclo de vida y sus dos grandes modelos –el ciclo de vida en cascada o
clásico y los ciclos de vida iterativos e incrementales–, más dos modalidades in- clásico y los ciclos de vida iterativos e incrementales–, más dos modalidades in-
termedias –el desarrollo con prototipos y la programación exploratoria. Como termedias –el desarrollo con prototipos y la programación exploratoria. Como
ciclos concretos, hemos estudiado de una manera más o menos detallada el ci- ciclos concretos, hemos estudiado de una manera más o menos detallada el ci-
clo de vida del Rational Unified Process, como representante de las tendencias ac- clo de vida del Rational Unified Process, como representante de las tendencias ac-
tuales en lo que se refiere a ciclos iterativos e incrementales, y el ciclo de vida tuales en lo que se refiere a ciclos iterativos e incrementales, y el ciclo de vida
clásico, cuyo interés radica, además de en su importancia histórica, en el hecho clásico, cuyo interés radica, además de en su importancia histórica, en el hecho
de que algunos de sus conceptos continúan siendo válidos todavía. de que algunos de sus conceptos continúan siendo válidos todavía.
A continuación, se han presentado las tres grandes familias de métodos de de- A continuación, se han presentado las tres grandes familias de métodos de de-
sarrollo de software: las dos más utilizadas en entornos reales, que son los mé- sarrollo de software: las dos más utilizadas en entornos reales, que son los mé-
todos estructurados –más tradicionales– y los métodos orientados a objetos –en todos estructurados –más tradicionales– y los métodos orientados a objetos –en
plena expansión–, sin menospreciar los métodos formales, interesantes por su plena expansión–, sin menospreciar los métodos formales, interesantes por su
gran rigor teórico. gran rigor teórico.
Después de hablar de técnicas, es lógico referirse a las herramientas que éstas Después de hablar de técnicas, es lógico referirse a las herramientas que éstas
emplean; por eso hemos visto el concepto de herramientas CASE y nos hemos emplean; por eso hemos visto el concepto de herramientas CASE y nos hemos
informado de su situación actual y de la evolución previsible de su papel. informado de su situación actual y de la evolución previsible de su papel.
Puesto que para estudiar el análisis y diseño orientados a objetos –tema esencial Puesto que para estudiar el análisis y diseño orientados a objetos –tema esencial
de esta asignatura– utilizaremos los conceptos y la notación de UML, se ha ex- de esta asignatura– utilizaremos los conceptos y la notación de UML, se ha ex-
puesto el origen de este modelo y el cometido de la organización que se respon- puesto el origen de este modelo y el cometido de la organización que se respon-
sabiliza de éste, la OMG. sabiliza de éste, la OMG.
Ejercicios de autoevaluación Ejercicios de autoevaluación
1. ¿Tiene sentido distinguir entre ingeniería del producto e ingeniería del proceso en el caso 1. ¿Tiene sentido distinguir entre ingeniería del producto e ingeniería del proceso en el caso
de la ingeniería del software? de la ingeniería del software?
2. ¿Por qué otras ingenierías no pasan, actualmente, una crisis análoga a la crisis del software? 2. ¿Por qué otras ingenierías no pasan, actualmente, una crisis análoga a la crisis del software?
3. Comentad la afirmación “software es igual a conjunto de programas”. 3. Comentad la afirmación “software es igual a conjunto de programas”.
4. ¿Qué relación existe entre el ciclo de vida del software y la ingeniería del software? 4. ¿Qué relación existe entre el ciclo de vida del software y la ingeniería del software?
5. ¿Por qué el ciclo de vida clásico también se denomina ciclo de vida en cascada? 5. ¿Por qué el ciclo de vida clásico también se denomina ciclo de vida en cascada?
6. ¿Cuáles son las fases del ciclo de vida clásico? 6. ¿Cuáles son las fases del ciclo de vida clásico?
7. ¿Por qué hay un modelo de ciclo de vida especial cuando las herramientas del software 7. ¿Por qué hay un modelo de ciclo de vida especial cuando las herramientas del software
son de cuarta generación? son de cuarta generación?
8. ¿Por qué se afirma que el ciclo en cascada no es realista? 8. ¿Por qué se afirma que el ciclo en cascada no es realista?
9. El ciclo de vida con prototipos, ¿es iterativo? ¿Es incremental? Justificad la respuesta. 9. El ciclo de vida con prototipos, ¿es iterativo? ¿Es incremental? Justificad la respuesta.
10. ¿Cuáles son las fases del Rational Unified Process? 10. ¿Cuáles son las fases del Rational Unified Process?
11. Un compilador, ¿es una herramienta CASE? 11. Un compilador, ¿es una herramienta CASE?
12. ¿Por qué son más viables las herramientas CASE para el desarrollo orientado a objetos 12. ¿Por qué son más viables las herramientas CASE para el desarrollo orientado a objetos
que para el desarrollo estructurado? que para el desarrollo estructurado?
13. Resumid la finalidad del OMG. 13. Resumid la finalidad del OMG.
Solucionario Solucionario
Ejercicios de autoevaluación Ejercicios de autoevaluación
1. Puesto que la ingeniería de proceso considera la producción en serie de copias idénticas Consultad el subapartado 1.3.
1. Puesto que la ingeniería de proceso considera la producción en serie de copias idénticas Consultad el subapartado 1.3.
(o toneladas, litros, etc.) del producto una vez desarrollado, no hay propiamente ingeniería (o toneladas, litros, etc.) del producto una vez desarrollado, no hay propiamente ingeniería
de proceso del software. de proceso del software.
2. Porque las ingenierías más antiguas han alcanzado, en términos generales, una tecnolo- 2. Porque las ingenierías más antiguas han alcanzado, en términos generales, una tecnolo-
gía bastante satisfactoria en lo que a la calidad y la productividad se refiere; la utilización de gía bastante satisfactoria en lo que a la calidad y la productividad se refiere; la utilización de
elementos reusables o estandarizados es un factor importante. elementos reusables o estandarizados es un factor importante.
3. Un software es más que un simple conjunto de programas: es necesario que sus programas Consultad el subapartado 1.1. 3. Un software es más que un simple conjunto de programas: es necesario que sus programas Consultad el subapartado 1.1.
trabajen interrelacionados y, además, también incluye las estructuras de datos y la documen- trabajen interrelacionados y, además, también incluye las estructuras de datos y la documen-
tación relativos a estos programas. tación relativos a estos programas.
4. La ingeniería del software comprende los métodos para el desarrollo del software y un mé- Consultad el comienzo del apartado 2 .
4. La ingeniería del software comprende los métodos para el desarrollo del software y un mé- Consultad el comienzo del apartado 2 .
todo necesariamente se compone de etapas, es decir, tiene un ciclo de vida. todo necesariamente se compone de etapas, es decir, tiene un ciclo de vida.
5. Por dos razones: porque cada etapa comienza donde acabó la anterior, y porque teórica- Consultad el subapartado 2.1. 5. Por dos razones: porque cada etapa comienza donde acabó la anterior, y porque teórica- Consultad el subapartado 2.1.
mente no se repite nunca ninguna. mente no se repite nunca ninguna.
6. Análisis previo, análisis de requisitos, diseño, programación, prueba y mantenimiento. Consultad el subapartado 2.1.1. 6. Análisis previo, análisis de requisitos, diseño, programación, prueba y mantenimiento. Consultad el subapartado 2.1.1.
7. Porque en proyectos de informática de gestión pequeños y medianos el ciclo de vida clá- 7. Porque en proyectos de informática de gestión pequeños y medianos el ciclo de vida clá-
sico se puede simplificar si se utilizan herramientas de cuarta generación, ya que se puede sico se puede simplificar si se utilizan herramientas de cuarta generación, ya que se puede
Consultad el subapartado 2.1.2. Consultad el subapartado 2.1.2.
saltar la etapa de diseño. saltar la etapa de diseño.
8. Porque presupone que, una vez terminada una etapa, ya no se vuelve más a ella, y en la Consultad el subapartado 2.2.1.
8. Porque presupone que, una vez terminada una etapa, ya no se vuelve más a ella, y en la Consultad el subapartado 2.2.1.
práctica generalmente se continúan descubriendo o modificando requisitos cuando ya se práctica generalmente se continúan descubriendo o modificando requisitos cuando ya se
está en las etapas de diseño y programación. está en las etapas de diseño y programación.
9. Se puede considerar iterativo porque el prototipo se puede modificar tantas veces como Consultad el subapartado 2.2.2.
9. Se puede considerar iterativo porque el prototipo se puede modificar tantas veces como Consultad el subapartado 2.2.2.
sea necesario hasta que corresponda a lo que los usuarios quieren. No es incremental porque sea necesario hasta que corresponda a lo que los usuarios quieren. No es incremental porque
ni el prototipo ni el software definitivo se construyen por partes. ni el prototipo ni el software definitivo se construyen por partes.
10. Inicio, elaboración, construcción y transición. Consultad el subapartado 2.2.4. 10. Inicio, elaboración, construcción y transición. Consultad el subapartado 2.2.4.
11. No, porque se considera que las herramientras CASE sirven para conseguir un desarrollo 11. No, porque se considera que las herramientras CASE sirven para conseguir un desarrollo
más o menos informatizado y, siempre que se utilice el lenguaje de programación en cues- Consultad el apartado 4. más o menos informatizado y, siempre que se utilice el lenguaje de programación en cues- Consultad el apartado 4.
tión debe haber un compilador, aunque el desarrollo sea totalmente manual. tión debe haber un compilador, aunque el desarrollo sea totalmente manual.
12. Porque en el desarrollo orientado objetos hay mucha menos diversidad de conceptos y Consultad el apartado 4. 12. Porque en el desarrollo orientado objetos hay mucha menos diversidad de conceptos y Consultad el apartado 4.
herramientas que es necesario soportar que en el desarrollo estructurado; además, desde que herramientas que es necesario soportar que en el desarrollo estructurado; además, desde que
el modelo UML ha llegado a ser estándar para estos conceptos hay una sola representación el modelo UML ha llegado a ser estándar para estos conceptos hay una sola representación
gráfica. gráfica.
13. El OMG tiene como finalidad el fomento de la tecnología orientada a objetos por medio Consultad el apartado 5. 13. El OMG tiene como finalidad el fomento de la tecnología orientada a objetos por medio Consultad el apartado 5.
del establecimiento de estándares. del establecimiento de estándares.
Glosario Glosario
CASE CASE
sigla: Computer-Aided Software Engineering. sigla: Computer-Aided Software Engineering.
ciclo de vida ciclo de vida

Conjunto de etapas del desarrollo de software por las cuales se pasa en el orden previamente Conjunto de etapas del desarrollo de software por las cuales se pasa en el orden previamente
establecido. establecido.
ciclo de vida clásico ciclo de vida clásico

Ciclo de vida en el que se supone que cada etapa se basa en los productos de la anterior y no Ciclo de vida en el que se supone que cada etapa se basa en los productos de la anterior y no
se vuelve nunca a etapas anteriores. se vuelve nunca a etapas anteriores.
sin: ciclo de vida en cascada. sin: ciclo de vida en cascada.
ciclo de vida en cascada ciclo de vida en cascada

sinónimo: ciclo de vida clásico. sinónimo: ciclo de vida clásico.
ciclo de vida iterativo e incremental ciclo de vida iterativo e incremental

Todo ciclo de vida en el que se pasa de manera repetida por las mismas fases desarrollando Todo ciclo de vida en el que se pasa de manera repetida por las mismas fases desarrollando
cada vez un fragmento más de software. cada vez un fragmento más de software.
Computer-Aided Software Computer-Aided Software

Ved Case. Ved Case.
desarrollo de software orientado a objetos desarrollo de software orientado a objetos

Desarrollo de software con métodos centrados en el concepto de objeto derivados de la pro- Desarrollo de software con métodos centrados en el concepto de objeto derivados de la pro-
gramación orientada a objetos. gramación orientada a objetos.
desarrollo estructurado de software desarrollo estructurado de software

Desarrollo de software con métodos derivados de la programación estructurada e histórica- Desarrollo de software con métodos derivados de la programación estructurada e histórica-
mente anteriores a los orientados a objetos. mente anteriores a los orientados a objetos.
herramientas CASE herramientas CASE

Software de apoyo al desarrollo, mantenimiento y documentación informatizados de software. Software de apoyo al desarrollo, mantenimiento y documentación informatizados de software.
ingeniería del software ingeniería del software

Conjunto de las técnicas, métodos y herramientas que se utilizan para producir software. Conjunto de las técnicas, métodos y herramientas que se utilizan para producir software.
métodos formales de desarrollo de software métodos formales de desarrollo de software

Métodos de desarrollo que se basan en la especificación de los requisitos en términos de un Métodos de desarrollo que se basan en la especificación de los requisitos en términos de un
formalismo matemático riguroso. formalismo matemático riguroso.
OMG OMG
Organización no lucrativa de empresas productoras y consumidoras de bienes y servicios in- Organización no lucrativa de empresas productoras y consumidoras de bienes y servicios in-
formáticos que tiene la finalidad de fomentar el uso de la tecnología de objetos, y el medio formáticos que tiene la finalidad de fomentar el uso de la tecnología de objetos, y el medio
con el que intenta conseguirlo es la elaboración de estándares. con el que intenta conseguirlo es la elaboración de estándares.
sigla: Object Management Group. sigla: Object Management Group.
prototipo prototipo
El prototipo de un sistema de software es una versión provisional del sistema, que sólo tiene lo El prototipo de un sistema de software es una versión provisional del sistema, que sólo tiene lo
imprescindible para que el usuario pueda comprobar si se han entendido bien sus requisitos. imprescindible para que el usuario pueda comprobar si se han entendido bien sus requisitos.
UML UML
Modelo estándar para la construcción de software orientado a objetos. Modelo estándar para la construcción de software orientado a objetos.
sigla: Unified Modeling Language. sigla: Unified Modeling Language.
Unified Modeling Lenguage Unified Modeling Lenguage

Ved UML. Ved UML.
Bibliografía Bibliografía
Pressman, R.S. (1997). Ingeniería del software. Un enfoque práctico (4.ª ed.). Madrid: McGraw-Hill. Pressman, R.S. (1997). Ingeniería del software. Un enfoque práctico (4.ª ed.). Madrid: McGraw-Hill.
Sommerville, I. (1995). Software Engineering (5.ª ed.). Harlow: Addison-Wesley. Sommerville, I. (1995). Software Engineering (5.ª ed.). Harlow: Addison-Wesley.
Kruchten, P. (2000). The Rational Unified Process. An Introduction (2.ª ed.). Addison-Wesley. Kruchten, P. (2000). The Rational Unified Process. An Introduction (2.ª ed.). Addison-Wesley.

Introducción A La Ingeniería Del Software OO

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introducción A La Ingeniería Del Software OO

Cargado por

Copyright:

Formatos disponibles

Introducción Introducción

Objetivos ...................................................................................................... 6 Objetivos ...................................................................................................... 6

1. Qué es la ingeniería del software...................................................... 7 1. Qué es la ingeniería del software...................................................... 7

4. Las herramientas CASE ....................................................................... 21 4. Las herramientas CASE ....................................................................... 21

5. El OMG y el UML ................................................................................... 23 5. El OMG y el UML ................................................................................... 23

Ejercicios de autoevaluación .................................................................. 27 Ejercicios de autoevaluación .................................................................. 27

Glosario ........................................................................................................ 28 Glosario ........................................................................................................ 28

1. Qué es la ingeniería del software 1. Qué es la ingeniería del software

1.1. Qué es el software 1.1. Qué es el software

¡La producción de software se parece ¡La producción de software se parece

1.3. La ingeniería del software 1.3. La ingeniería del software

En esta asignatura... En esta asignatura...

El aprovechamiento de elementos en la fabricación en serie El aprovechamiento de elementos en la fabricación en serie

2. El ciclo de vida del software 2. El ciclo de vida del software

2.1. El ciclo de vida clásico 2.1. El ciclo de vida clásico

2.1.1. Etapas 2.1.1. Etapas

2.2.3. La programación exploratoria 2.2.3. La programación exploratoria

Características de la programación exploratoria Características de la programación exploratoria

• recogida de requisitos (requirement capture), • recogida de requisitos (requirement capture),

3. Desarrollo estructurado y desarrollo orientado 3. Desarrollo estructurado y desarrollo orientado

3.1. Los métodos estructurados 3.1. Los métodos estructurados

Técnicas utilizadas para Técnicas utilizadas para

3.3. Los métodos formales 3.3. Los métodos formales

4. Las herramientas CASE 4. Las herramientas CASE

La importancia de la integración de las herramientas La importancia de la integración de las herramientas

5. El OMG y el UML 5. El OMG y el UML

El otro estándar del OMG El otro estándar del OMG

• el método de Grady Booch; • el método de Grady Booch;

Evolución del modelo UML Evolución del modelo UML

Ejercicios de autoevaluación Ejercicios de autoevaluación

Ejercicios de autoevaluación Ejercicios de autoevaluación

ciclo de vida ciclo de vida

ciclo de vida clásico ciclo de vida clásico

ciclo de vida en cascada ciclo de vida en cascada

ciclo de vida iterativo e incremental ciclo de vida iterativo e incremental

Computer-Aided Software Computer-Aided Software

desarrollo de software orientado a objetos desarrollo de software orientado a objetos

desarrollo estructurado de software desarrollo estructurado de software

herramientas CASE herramientas CASE

ingeniería del software ingeniería del software

métodos formales de desarrollo de software métodos formales de desarrollo de software

Unified Modeling Lenguage Unified Modeling Lenguage

También podría gustarte