Análisis, Diseño y Mantenimiento del Software

Manuel Arias Calleja

Dpto. de Inteligencia Artificial - ETSI Informática - UNED

Actualizada en Noviembre de 2010

II
Índice general

Guía de estudio de la asignatura V

Presentación y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V
Contexto y conocimientos previos . . . . . . . . . . . . . . . . . . . . . . . VI
Esquema y resumen de contenidos . . . . . . . . . . . . . . . . . . . . . . . VIII
Material y medios de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . X

1. Contexto de la asignatura en la Ingeniería de Software 1

2. Fase de especificación 5

3. Fase de diseño 7

4. Fase de implementación 9

5. Fases de pruebas 13

6. Fase de entrega y mantenimiento 15

7. Metodologías de desarrollo 17

8. Herramientas de desarrollo y validación 19

Bibliografía 21

III
ÍNDICE GENERAL ÍNDICE GENERAL

IV
Guía de estudio de la asignatura
correspondiente al primer parcial

Autores: Manuel Arias Calleja. Basado en una versión del año 2003 por Manuel Arias
Calleja y José Ramón Álvarez Sánchez.

Revisado: Noviembre de 2010 por Manuel Arias Calleja y Ángeles Manjarrés Riesco

Revisión de los elementos del UML: Ángeles Manjarrés y Manuel Arias Calleja

Revisión de los principios de orientación a objetos: Manuel Arias

Asignatura: Análisis, Diseño y Mantenimiento de Software

Código: 55-402-4 (4o curso de la titulación: “Ingeniero Informático”)

Breve descripción:
Análisis y definición de requisitos. Diseño, propiedades y mantenimiento del soft-
ware.

Presentación y objetivos
El objetivo principal de la Ingeniería del software (IS) es el desarrollo y manten-
imiento de software de forma sistemática y productiva, asegurando su calidad, fiabilidad
y facilidad de uso. Los enfoques más comunes de la docencia de la IS, se centran en el
análisis de los procesos de desarrollo y mantenimiento, así como de las técnicas inte-
grales y de apoyo al servicio de la obtención de productos de alta calidad que satisfagan
al usuario.
Esta Guía didáctica está diseñada para conducir el estudio de la asignatura en sus
aspectos puramente técnicos, que serán los evaluados en las pruebas presenciales. En la
Guía de Curso se detallan objetivos docentes adicionales que serán cubiertos mediante
actividades NO obligatorias que los alumnos podrán seguir en los cursos virtuales a la
vez que estudian el temario convencional.

V
ÍNDICE GENERAL ÍNDICE GENERAL

Contexto y conocimientos previos

Contexto académico previo
Ingeniería del software es una materia troncal del segundo ciclo que en la titulación
de Ingeniero en Informática, impartida por la ETSII de la Universidad Nacional de Ed-
ucación a Distancia (Resolución de 21 de marzo de 2001, BOE 10 de abril), se ha divi-
dido en dos asignaturas obligatorias y anuales del cuarto curso, cada una de las cuales
tiene asignados 9 créditos (5 teóricos y 4 prácticos). Las denominaciones que se han
dado a estas dos asignaturas complementarias son Análisis, Diseño y Mantenimiento
del software (descrita como “Análisis y definición de requisitos. Diseño, propiedades y
mantenimiento del software”) y Análisis y Gestión del Desarrollo del Software (descrita
como “Análisis de aplicaciones. Gestión de configuraciones. Planificación y gestión de
proyectos informáticos”).
Ambas asignaturas se hayan fuertemente vinculadas, en tanto que se complementan
para proporcionar una visión general del proceso completo de la producción de software,
tanto desde un punto de vista técnico como humano, vertientes que caracterizan todo
proceso de ingeniería.
El programa de la asignatura Análisis y Gestión del Desarrollo del Software está
estructurado en dos cuatrimestres. El primer cuatrimestre se dedica al Proceso Software
Personal (PSP), cuyo objetivo es la adquisición de una correcta disciplina personal para
el desarrollo de un software de calidad en los plazos y costes comprometidos. El segun-
do cuatrimestre está dedicado a la gestión global del proceso de desarrollo software en el
que intervienen decenas o centenares de ingenieros. Su objetivo es también obtener un
software de calidad en los plazos y costes planificados, si bien en este caso se destacan
la problemática y las técnicas asociadas al trabajo en equipo. Las asignaturas de Inge-
niería del software deberían, idealmente, ser cursadas en paralelo por los alumnos, dado
su carácter mutuamente complementario. En definitiva, el objeto de la asignatura Análi-
sis y Gestión del Desarrollo del Software es mostrar cómo se evalúan las técnicas de
ingeniería estudiados en la asignatura Análisis, Diseño y Mantenimiento del software,
y cómo se aplican en un contexto profesional.

Otras asignaturas relacionadas

Son muchas y diversas las asignaturas de la titulación relacionadas con la asignatu-
ra Análisis, Diseño y Mantenimiento del Software. El haber cursado algunas de estas
asignaturas (o bien las asignaturas equivalentes de carreras impartidas en otras univer-
sidades) es requisito imprescindible para su adecuado seguimiento.
En concreto, es razonable esperar que el alumno matriculado en Ingeniería del soft-
ware haya seguido previamente las asignaturas obligatorias del primer ciclo Ingeniería
del software e Ingeniería del Software de Gestión, como iniciación a la materia objeto

VI
ÍNDICE GENERAL ÍNDICE GENERAL

de esta memoria (dada la extensión de los contenidos, es conveniente que el alumno

parta de una visión introductoria y general de la ingeniería de software, conozca los
modelos de ciclo de vida básicos y alguna metodología estructurada).
Por otro lado, el alumno sólo podrá dar pleno sentido al contenido de esta materia si
ha cursado las asignaturas que se encuadran en el componente que en la sección anterior
se ha etiquetado por Fundamentos de la computación. Entre tales asignaturas se cuen-
tan las relacionadas con la teoría de la programación (Programación I, Programación
II, Programación III, Estructura de Datos y Algoritmos y Lenguajes de Programación,
todas ellas asignaturas obligatorias del primer ciclo), y las que estudian la teoría de la
computabilidad (Teoría de autómatas I, Teoría de autómatas II). (Obviamente, la com-
prensión de las mencionadas asignaturas a su vez ha exigido del alumno los conocimien-
tos matemáticos que se proporcionan en las asignaturas Lógica matemática, Análisis
Matemático, Álgebra, Ampliación de Matemáticas y Matemática discreta.
Resulta asimismo altamente recomendable que el alumno haya cursado también al-
gunas asignaturas relacionadas con los temas anteriores pero de una orientación más
práctica y específica. Es el caso de las optativas del tercer curso Programación Concur-
rente, Programación Declarativa y Programación Orientada a la Inteligencia Artificial
(orientadas a la programación), y Diseño y Evaluación de Configuraciones, y Configu-
ración, Diseño y Gestión de Sistemas Informáticos.
Es también de interés, si bien no imprescindible para la asimilación de los con-
tenidos, que el alumno disponga de conocimientos del campo de la Inteligencia Artifi-
cial. En particular, la asignatura Sistemas basados en conocimiento I, asignatura optativa
del tercer curso, aborda el estudio de las diferentes fases del ciclo de desarrollo de un
sistema experto, coincidentes en lo esencial con las fases de desarrollo de los produc-
tos software convencionales. Sin duda el alumno que haya estudiado esta asignatura
dispondrá de una visión más abierta, y la reflexión sobre los paralelismos y discrepan-
cias entre ambas disciplinas le ayudará a profundizar en la materia. De hecho, a medida
que aumenta la complejidad de las aplicaciones software en dominios no tradicional-
mente abordados por la Inteligencia artificial, la ingeniería del conocimiento y la IS
convencional han ido eliminando progresivamente sus difusas fronteras, y comenzado
a beneficiarse mutuamente de sus respectivos avances. En concreto, el uso de las téc-
nicas OO se ha generalizado en todos los ámbitos, y las técnicas de formalización de
requisitos se ven enriquecidas por los interesantes resultados obtenidos en el campo del
procesamiento del lenguaje natural, tradicionalmente estudiado en la Inteligencia Ar-
tificial. El conocimiento de los principios básicos de la Inteligencia Artificial, que se
estudian en la asignatura obligatoria del segundo curso Introducción a la Inteligencia
Artificial, es también sin duda de utilidad en este contexto.
En el programa del 4o curso existe un grupo de asignaturas que guarda una evidente
relación con la Ingeniería del software, y que resulta interesante que el alumno estudie
en paralelo con las asignaturas de Ingeniería del software, tratando de establecer las

VII
ÍNDICE GENERAL ÍNDICE GENERAL

oportunas conexiones. Es particularmente el caso de la asignatura obligatoria Lógica

computacional, donde se estudian los fundamentos de las técnicas formales de desarrol-
lo software y de la asignatura Inteligencia Artificial e Ingeniería del Conocimiento, que
redunda en el estudio de las técnicas de la ingeniería del conocimiento. Finalmente, es
preciso destacar que los conocimientos adquiridos en estas asignaturas son esenciales
para el seguimiento de una buena parte de las asignaturas del quinto curso, en partic-
ular, de las obligatorias Sistemas Informáticos I, Sistemas Informáticos II y Sistemas
Informáticos III, más las optativas Aprendizaje y Personalización del Software, Dis-
eño de Sistemas de Trabajo Cooperativo (CSCW) y Calidad de Software; y sirven de
introducción a las asignaturas optativas Sistemas en tiempo real, Seguridad en las co-
municaciones y en la información y Sistemas de comunicación de datos. Asimismo son
obviamente indispensables para la realización del Proyecto de Fin de Carrera, ejercicio
de desarrollo de un proyecto informático que debe llevarse a cabo con el rigor de un
proyecto real, y que es obligatorio para la obtención del título. Por supuesto será funda-
mental para la formación posterior del alumno titulado y para el ejercicio de su práctica
profesional.

Esquema y resumen de contenidos

A continuación exponemos un resumen de los temas que componen el contenido
de la asignatura que se expandirá más adelante. Estos temas se podrían agrupar en tres
partes que se corresponden con los objetivos presentados anteriormente:

Parte I: Introducción. Tema 1.

Parte II: Fases de Construcción. Temas 2 al 6.
Parte III: Metodologías y Herramientas. Temas 7 y 8.

La primera parte es preparatoria e incluye la introducción y ubicación de los elementos

que van a conformar la asignatura. En la segunda parte se van describiendo las distintas
fases del desarrollo y mantenimiento del software. La parte final incluye un conjunto de
metodologías donde se recopilan y organizan de diferentes formas las fases, junto con
algunas herramientas de desarrollo.
Esta asignatura es anual y por lo tanto se divide en dos parciales. A los efectos de
exámenes parciales se considera que los temas del 1 al 4 pertenecen al primer parcial y
los temas del 5 al 8 pertenecen al segundo parcial.

Esquema:
Tema 1: Contexto de la Asignatura en la IS

VIII
ÍNDICE GENERAL ÍNDICE GENERAL

• Necesidad de una metodología

• Ciclo de vida del software
• Notaciones de especificación y diseño
Tema 2: Fase de Requisitos

• Obtención de requisitos
• Análisis de requisitos
• Representación de requisitos
• Validación de requisitos
• Bases de documentación
Tema 3: Fase de Diseño

• Conceptos y elementos del diseño

• Métodos de diseño
• Validación y confirmación del diseño
• Documentación: especificación del diseño
Tema 4: Fase de Implementación

• Iteración de pruebas y depuración

• Manuales técnico y de usuario
Tema 5: Fases de Pruebas

• Verificación y validación a lo largo del ciclo de vida

• Técnicas y métodos de prueba
• Documentación de pruebas
Tema 6: Fase de Entrega y Mantenimiento

• Finalización del proyecto

• Planificación de revisiones y organización del mantenimiento
• Recopilación y organización de documentación
Tema 7: Metodologías de Desarrollo

• Proceso Unificado de Rational

• Método Extreme Programming
• Métodos de software libre: “catedral” vs. “bazar”

IX
ÍNDICE GENERAL ÍNDICE GENERAL

Tema 8: Herramientas de Desarrollo y Validación

• Herramientas CASE
• CVS (Concurrent Versioning System)
• Entornos de desarrollo de interfaces

Material y medios de estudio

Estructura de esta Guía Didáctica y libro base
En los siguientes capítulos de esta guía de estudio se detallan los contenidos con
la información que el alumno de educación a distancia necesita para poder estudiar
la asignatura. Al principio de cada capítulo se incluye un “Tutorial previo” con los
elementos que describen el contexto, conocimiento previo, objetivos y guía de estudio
para ese capítulo. En esta asignatura se utilizará como material básico de estudio para
el curso 2010-2011 el libro [Pre05] o bien con la edición siguiente [Pre10]:

Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-Hill,

2005
Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-Hill,
2010

Este libro base cubre la mayor parte del temario. En esta guía los contenidos de cada
capítulo se sustituirán por la referencia (entre corchetes como [Pre05, sec. ... y cap ...]) a
los apartados del libro base, o bien se incluirán desarrollados directamente en esta guía
si no existe una correspondencia directa con el libro base. Se adjuntará la referencia a
los contenidos correspondientes a la séptima edición como [Pre10, sec. ... y cap ...]. Al
final de cada capítulo se incluye en esta guía un “Tutorial posterior” que contiene ejer-
cicios o actividades propuestas adicionales a las que aparecen en el libro base, para que
el alumno pueda comprobar si ha logrado los objetivos del capítulo, y también infor-
mación adicional para la extensión de conocimientos para los alumnos interesados en
profundizar en el tema, junto con referencias alternativas sobre los mismos contenidos.
Al final de esta guía didáctica se incluye en un apéndice el glosario de términos habit-
uales en la Ingeniería de Software que pueden aparecer en el contenido1 , también se
incluye una recopilación de referencias bibliográficas (recomendadas o referidas en el
material), más un indice alfabético de referencia para conceptos y términos que aparecen
en el material.
1 Además al final del libro base [Pre05] o [Pre10] hay un apéndice que recopila todas las siglas en
ingles y castellano usadas profusamente en Ingeniería del Software.

X
ÍNDICE GENERAL ÍNDICE GENERAL

Medios Adicionales
Adicionalmente a esta guía, el alumno dispondrá de los medios de comunicación ha-
bituales con su Profesor Tutor en el Centro Asociado o a través de las Tutorías Telemáti-
cas (o Cursos Virtuales) de la UNED http://virtual.uned.es/ , y también con el
Equipo Docente en la Sede Central (en las direcciones, teléfonos y horarios indicados
en la Guía de Curso). Esto se complementa con los canales de comunicación y recopi-
lación de información tanto en soporte físico (CDROM) como en línea a través de la
página de Internet de la asignatura en la UNED http://www.ii.uned.es/superior/
cuarto/ADMSoft.html . En todos estos medios se incluirá la información particular de
referencias y contenidos que se detallan en los capítulos de esta guía, con la ventaja
adicional de que en los medios en línea los enlaces de direcciones en Internet y otros
materiales se irán ampliando y actualizando más frecuentemente. Se recomienda encar-
ecidamente el seguimiento de los cursos virtuales. Además del libro base (que contiene
al final de cada capítulo “otras lecturas y fuentes de información”) y del material inclui-
do en esta guía, también se recomiendan como bibliografía complementaria general los
libros [Som98] (o la edición en inglés más reciente [Som01]) y [RBP+ 96]:

Ian Sommerville. Ingeniería de Software. Addison-Wesley Iberoamericana, 1998

James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William
Lorensen. Modelado y diseño orientado a objetos. Metodología OMT y OMT II.
Prentice Hall, 1996

Evaluación
La evaluación oficial de la asignatura se hará por medio de las pruebas presenciales
habituales de la UNED. Se harán dos pruebas parciales, una para cada cuatrimestre. Las
pruebas subjetivas consistirán en una parte de preguntas teóricas breves sobre aspectos
relevantes del temario correspondiente, más posiblemente otra parte práctica compues-
ta de ejercicios con supuestos prácticos que describirán parcialmente un problema de
diseño de software sobre el cual se pedirá al alumno completar o extender algunos as-
pectos relacionados con el temario correspondiente. La puntuación correspondiente a
cada pregunta se especificará en el enunciado. En la nota final se tendrá en cuenta la
compensación entre preguntas dentro de un mismo examen parcial así como la com-
pensación de ambos parciales. Los parciales compensan a partir de 4 y se guardan hasta
septiembre.
En algunos capítulos puede haber propuestas para realizar prácticas por el propio
alumno, estas serán totalmente voluntarias (y que por tanto no podrán ser tenidas en
cuenta para la puntuación de la nota final), pero se recomienda al alumno su realización
para ayudarle a una mejor comprensión de los temas.

XI
ÍNDICE GENERAL ÍNDICE GENERAL

XII
Capítulo 1

Contexto de la asignatura en la
Ingeniería de Software

Tutorial previo
Introducción
Al inicio de la asignatura es conveniente repasar algunos conceptos generales sobre
Ingeniería de Software e introducir los temas que se van a estudiar.
En el desarrollo de sistemas software es necesario planificar el uso de recursos
y temporizar adecuadamente las diferentes actividades para no sobrepasar los límites
económicos y de tiempo dedicados a un proyecto. Es principalmente con este objetivo
que se han ido desarrollando el conjunto de técnicas que reciben el nombre de Inge-
niería del Software. Gracias a estas técnicas el desarrollo del software se sistematiza
en la medida de lo posible, de modo que el resultado sea previsiblemente aceptable, es
decir, cumpla las expectativas planteadas en términos de tiempo de desarrollo, precio
final, mantenibilidad y eficiencia.
Una metodología de desarrollo reúne un conjunto de prácticas que se ejercen en
las diferentes fases del ciclo de vida de un producto software. Esas fases son: especifi-
cación, diseño, codificación, pruebas y mantenimiento. Para dar soporte a las diferentes
etapas, y particularmente a las etapas de análisis y diseño, se han definido notaciones de
modelado tales como el difundido estándar UML.
En este primer capítulo se muestra la utilidad de seguir una metodología en el de-
sarrollo de software. A continuación se presentan los aspectos más generales del ciclo
de vida del software y se introducen las distintas fases del desarrollo en que se profun-
dizará en los capítulos del bloque II (temas 2 al 6). Finalmente, se describe el lenguaje
UML, de uso extendido y soportado actualmente por varias herramientas CASE capaces
de generar código a partir de los diagramas de esta notación.

1
 CAPÍTULO 1. CONTEXTO DE LA ASIGNATURA EN LA INGENIERÍA DE
SOFTWARE
Relación con otros temas
Con este tema se pretende asegurar que el alumno dispone de base suficiente para
abordar el estudio del resto de la asignatura. Es recomendable el repaso de las asignat-
uras previas de la titulación en que se estudiaron las bases de la Ingeniería del Software
y el desarrollo de programas.
Al mismo tiempo este tema es importante por proporcionar una visión general de
las diferentes fases de un ciclo de desarrollo de software y de su coordinación en
metodologías.
Para hacerse una composición de lugar sobre lo que se habla en este capítulo y en la
asignatura en general es recomendable haber desarrollado algún proyecto en un lenguaje
de programación.

Objetivos del tema

Este tema es introductorio. El alumno debe comprobar que dispone de los conocimien-
tos básicos necesarios para afrontar el resto de la asignatura, entendiendo la estructura
general del desarrollo del software, así como las implicaciones y relaciones con la plan-
ificación y gestión de proyectos informáticos. Para ello debe: comprender la necesidad
de utilizar una metodología en el desarrollo de aplicaciones, comprender las ventajas e
inconvenientes de los diferentes ciclos de vida para discernir cuando es adecuado usar
uno u otro, y saber utilizar (en un nivel medio) la notación UML para la especificación
y diseño de sistemas.

Guía de estudio y esquema

Es conveniente realizar una lectura inicial del tema para identificar sus contenidos y
repasar los conceptos que considere necesarios, bien acudiendo a textos de asignaturas
ya cursadas, bien estudiando las referencias proporcionadas en el apartado de “extensión
de conocimientos”. El capítulo tiene tres partes:

La explicación acerca de la necesidad de una metodología se incluye directamente

en la adenda y, adicionalmente, se debe estudiar en el libro base [Pre05, cap. 1, y
secs. 2.1 y 2.2]. En la séptima edición [Pre10, cap. 1] excluyendo la sección 1.2 y
[Pre10, cap. 2, sec. 2.1 hasta 2.1.2] inclusive.
Los ciclos de vida. Se da una descripción de cada uno y una lista de ventajas e
inconvenientes. También este apartado está en la adenda y se debe extender su
estudio en el libro base [Pre05, secs. 3.1 a 3.5.3 y 3.7]. En la séptima edición
[Pre10, secs. 2.3, 2.4 y 2.9].
La notación de especificación y diseño UML. La mejor forma de asimilar esta
parte consiste en estudiar la teoría e ir haciendo pequeños ejemplos. En la adenda

2
CAPÍTULO 1. CONTEXTO DE LA ASIGNATURA EN LA INGENIERÍA DE
SOFTWARE

se incluye este apartado. Además de los ejemplos de la adenda se pueden consultar

los que aparecen en el libro base en [Pre05, secs. 7.5 y 8.3 a 8.8]. En la séptima
edición [Pre10, Apéndice 1].
De los apartados anteriores nos interesan fundamentalmente los ejemplos; la teoría
de dichos apartados se referencia en el siguiente capítulo de esta guía. Advertimos
que este material de estudio del UML se refiere a la primera versión del lenguaje.
Hemos creído conveniente formar al alumno en esta primera versión debido a que
aún la segunda es relativamente reciente y es de prever que ambas versiones con-
vivan en el mundo empresarial durante un tiempo significativo. (Las novedades
introducidas en la segunda versión se estudiarán en una adenda a esta guía que se
publicará el primero de noviembre en la Web de la asignatura).

3
CAPÍTULO 1. CONTEXTO DE LA ASIGNATURA EN LA INGENIERÍA DE
SOFTWARE

4
Capítulo 2

Fase de especificación

Tutorial previo
Introducción
Una vez que el proyecto ha superado tanto la decisión de desarrollarlo como su
estudio de viabilidad (estudiado en otras asignaturas) empieza la fase de especificación,
donde se emplean un conjunto de técnicas para captar requisitos y representarlos de un
modo útil para la fase posterior de diseño.
Se dice que la especificación es la fase importante mientras que el diseño es la difí-
cil. La importancia se debe al alto coste económico y de tiempo que supone un requisito
mal entendido. La realización de una buena especificación no es tan sencillo como se
puede pensar en un principio, pues muchas veces el propio cliente no tiene una imagen
clara del sistema final o surgen nuevas necesidades a mitad del desarrollo. Este prob-
lema puede afrontarse de varias formas: usando técnicas de comunicación efectivas,
estudiando el dominio del problema, creando modelos del problema real y, por último,
revisando la especificación creada.
Se deben documentar y registrar debidamente todas las actividades anteriores para
que en caso de que surja algún problema se pueda seguir su traza hasta los requisitos.

Relación con otros temas

La extracción, modelado, análisis y representación de requisitos o especificaciones
es un problema muy relacionado con la Ingeniería del Conocimiento, por tanto sería
conveniente que el alumno repasara los temas correspondientes en las asignaturas pre-
vias relacionadas. Es necesario ejercitar la capacidad de abstracción para poder expresar
lo que pide el cliente en una representación formal que responda a sus expectativas.

5
 CAPÍTULO 2. FASE DE ESPECIFICACIÓN

Objetivos del tema

Es necesario en esta fase separar y entender los conceptos propios de cómo especi-
ficar un problema y cómo hacer útil esas especificaciones para posteriores fases del
desarrollo. El alumno debe ser capaz de extraer y representar un conjunto de requisi-
tos expresados en lenguaje natural a una representación que sirva de entrada a la fase
siguiente de diseño.

Guía de estudio y esquema

En el tema se exponen los contenidos teóricos genéricos. El alumno debe identificar
cuáles son los elementos correspondientes a la obtención y el análisis de los requisitos
en esos ejemplos para generalizarlo a otros problemas.

1. Obtención de requisitos: se estudia directamente en el material en esta guía. Se

deben extender conocimientos en [Pre05, secs. 7.1 a 7.4]. En la séptima edición
[Pre10, secs. 5.1 a 5.3].
2. Construcción del modelo de análisis y negociación de requisitos: este apartado se
puede estudiar en [Pre05, secs. 7.6 y 7.7]. En la séptima edición [Pre10, secs. 5.5
y 5.6].
3. Modelado del análisis y de datos: el contenido se estudiará en [Pre05, secs. 8.1 a
8.3]. En la séptima edición [Pre10, secs. 6.1 y 6.4].
4. Análisis orientado a objetos: el contenido se estudiará en [Pre05, sec. 8.4]. En la
séptima edición no existe explícitamente, pero se puede consultar el punto 2.4 de
la adenda.
5. Modelado basado en escenarios: el contenido se estudiará en [Pre05, sec. 8.5]. En
la séptima edición [Pre10, secs. 6.2].
6. Modelado de clases: el contenido se estudiará en [Pre05, sec. 8.7]. En la séptima
edición [Pre10, sec. 6.5].
7. Modelado del comportamiento: el contenido se estudiará en [Pre05, sec. 8.8]. En
la séptima edición [Pre10, sec. 7.3].
8. Análisis estructurado (en el libro se denomina “Modelado orientado al flujo”): el
contenido se estudiará en [Pre05, sec. 8.6]. En la séptima edición [Pre10, sec. 7.1
y 7.2].
9. Validación de requisitos: en [Pre05, sec.7.8] junto con el apartado correspondiente
en esta guía. En la séptima edición [Pre10, sec. 5.7].
10. Bases de documentación: en el contenido del apartado correspondiente de esta
guía.

6
Capítulo 3

Fase de diseño

Tutorial Previo
Introducción
Una vez que se han identificado los requisitos para el problema, es necesario idear
y componer la forma de la solución para el problema. El diseño es la fase en la que
se estudia el problema, se identifican las características que tendría una solución y se
analiza a su vez cada una de esas características. En la fase de diseño es más efectivo
utilizar patrones y modelos conocidos para ir resolviendo partes del problema, es decir
modularizar el problema y proyectarlo en módulos en la solución. Aunque, el proceso
de diseño es en gran medida ad hoc, es decir, no está tan formalizado como las otras
fases y por tanto se apoya bastante en la experiencia e intuición de los diseñadores.
En este tema se van a proponer las formas de diseño convencionales, una compara-
ción de los más utilizados y la validación o comprobación de su adecuación, junto con
la parte correspondiente de documentación de todo el proceso. Principalmente hay dos
tipos de diseño:

Diseño funcional: parte de una vista de alto nivel que se va refinando progresiva-
mente. En este caso la atención se focaliza en la forma de procesar los datos.
Diseño orientado a objetos: se entiende el sistema como un conjunto de objetos.
Para distinguirlos se identifican los tipos de datos, sus operaciones y atributos
asociados. Los objetos se comunican entre ellos enviándose mensajes.

La validación del diseño comprueba si se siguen las especificaciones del diseño y se

cumplen requisitos de calidad. La mejor forma de redactar la documentación consiste
en seguir una plantilla de un documento estándar rellenando varias secciones.

7
 CAPÍTULO 3. FASE DE DISEÑO

Relación con otros temas

Para la comprensión de este tema es conveniente tener en mente los diferentes mod-
elos de programación que han ido estudiando en la carrera y que se utilizarán después
en la fase del tema siguiente. También es necesario haber preparado el tema de requisi-
tos para entender cuáles son los elementos de entrada en el diseño. Es necesario saber:
descomponer un problema en otros más pequeños, identificar las estructuras de datos
necesarias e identificar flujos de datos entre subsistemas y cuáles son las entradas y
salidas necesarias para cada subsistema.

Objetivos del tema

Se deben obtener los conocimientos sobre las técnicas de diseño más efectivas y
utilizadas, junto con la comprensión de las diferencias entre esas técnicas que permitan
conocer cuál es el método más apropiado en cada situación. Se pretende en este tema
introducir los dos tipos de métodos que existen de diseñar un sistema y proporcionar un
método genérico para redactar la documentación.

Guía de estudio y esquema

A la vez que se estudia el contenido teórico del tema es conveniente ir siguiendo los
ejemplos propuestos y realizar algunos ejercicios simples con otros problemas, utilizan-
do los problemas supuestos por el alumno como ejercicios en el tema 2.
Como se ha dicho antes, la tarea de diseño es en gran medida ad hoc y depende de
la experiencia de los diseñadores. El mejor método para aprender a diseñar es realizar
todos los ejercicios propuestos (tanto explícitos, en el tutorial posterior, como implícitos
o genéricos mencionados anteriormente).

Conceptos generales de diseño: este apartado se estudiará en [Pre05, cap. 9]. En la

séptima edición [Pre10, cap. 8], excluyendo las secciones 8.2.2 y 8.3.9. Se incluye
en la adenda una pequeña introducción a los patrones y al diseño orientado a
objetos, también se puede leer [Pre10, sec. 12.1 y 12.2], pero tan sólo por encima.
Diseño arquitectónico. Este apartado se estudiará en [Pre05, cap. 10]. En la sép-
tima edición [Pre10, cap 9]. La sección [Pre05, sec. 10.6] trata el diseño estruc-
turado. En la séptima edición [Pre10, sec. 9.6].
Diseño al nivel de componentes. Este apartado se estudiará en [Pre05, cap. 11].
En la séptima edición [Pre10, cap. 10], excluyendo [Pre10, secs. 10.4 y 10.6].
Validación y confirmación del diseño. Este apartado se incluye en la adenda.

8
Capítulo 4

Fase de implementación

Tutorial Previo
Introducción
Una vez que se dispone de un diseño para la solución del problema, incluso en una
fase temprana o provisional del diseño, ya se puede comenzar a plasmar ese diseño en
el código que permita realizarlo o implementarlo. En esta fase el programador recibe
las especificaciones del diseño y transforma esas especificaciones, que pueden estar en
formatos mezclados formales, semiformales o manuales, en un programa o módulo que
las efectúe. Esta tarea de modificación puede estar semi-automatizada en algunos casos
o realizarse de forma completamente manual. En cualquier caso se requiere que esa
transformación se haga de manera sistemática y coherente. Las particularidades propias
de lenguajes de programación concretos se estudian en otras asignaturas y por tanto no
se incluirán en este tema.

Durante la implementación se escribe el código de la aplicación. Existen una serie

de "vicios" en el estilo de codificación que pueden tener como consecuencia que el
código sea confuso para terceras personas o para uno mismo pasado un tiempo y en
consecuencia difícil de mantener; además, algunas prácticas pueden inducir errores.
Es especialmente recomendable para esta parte seguir las recomendaciones del PSP
(Personal Software Process). Para realizar el trabajo este debe ser dividido en pequeños
módulos que se reparte entre individuos o pequeños grupos atendiendo a un gráfico de
dependencias entre tareas y con la idea en mente de paralelizar tanto trabajo como sea
posible. A medida que se van haciendo los módulos hay que comprobar que cumplen
con una cierta calidad, para ello existen varios tipos de pruebas. En este capitulo se
estudia la necesidad de comprobar la ejecución correcta del módulo, por tanto interesan
las pruebas que se hacen a nivel de módulo, también llamadas pruebas unitarias. Además

9
 CAPÍTULO 4. FASE DE IMPLEMENTACIÓN

de todo ello hay dos tipos de manuales importantes que hay que producir en esta etapa:
el manual de usuario y el manual técnico.

Relación con otros temas

En este capítulo el alumno debe recordar los conocimientos sobre programación que
ha ido adquiriendo a lo largo del estudio de otras asignaturas en la carrera para entender
y generalizar la idea de los estilos de codificación y la depuración. Para comprender la
problemática asociada a la programación es necesario conocer muy bien al menos un
lenguaje de programación y tener alguna experiencia con él. Se puede considerar que
con las prácticas de programación de cursos pasados es suficiente.

Objetivos del tema

Los objetivos de este tema son resaltar la importancia de que la codificación de los
programas se haga de una forma ordenada, sistemática y documentada, así como de la
necesidad de realizar pruebas y depuración de errores propios de la implementación. Se
busca aprender algunas recomendaciones para producir código de calidad, poder entre-
gar el código en tiempo mínimo, poder dividir el trabajo resultante del diseño entre un
grupo de personas y tener una plantilla para redactar documentación para los manuales
de usuario y técnico.

Guía de estudio y esquema

Después del estudio del contenido teórico del tema, se deben realizar pruebas de cod-
ificación con distintos estilos basándose en los mismos ejemplos mostrados, utilizando
el lenguaje de programación que mejor conozca o prefiera el alumno. En paralelo con
el estudio del tema podría ser de interés que se desarrollara un pequeño proyecto de
programación donde se pusieran en práctica los conceptos desarrollados en el capítulo.

Para conseguir los objetivos es necesario no sólo memorizar el contenido del capítulo,
sino desarrollar hábitos que permitan utilizarlo en la práctica de la programación, lo cual
es una tarea que requiere constancia. La redacción de una documentación de calidad no
es trivial, son necesarias aptitudes pedagógicas, de estilo de escritura, etc. De todas
formas, aunque puede resultar difícil las primeras veces, se puede considerar una tarea
“burocrática”, es decir, al final lo que hay que hacer es seguir un manual de redacción
de manuales.

Técnicas de depuración. El contenido de este apartado se encuentra en [Pre05,

sec. 13.7]. En la séptima edición [Pre10, 17.8].

10
CAPÍTULO 4. FASE DE IMPLEMENTACIÓN

Documentación del código. El contenido se encuentra en la adenda.

11
CAPÍTULO 4. FASE DE IMPLEMENTACIÓN

12
Capítulo 5

Fases de pruebas

Tutorial Previo
Introducción
Este tema incluye en su denominación “Fases”, en plural, debido a que realmente no
hay una única fase de pruebas, sino que las pruebas se van realizado en todas las demás
fases. Las pruebas en este caso consisten en la comprobación de que la salida obtenida
en cada fase corresponde a las especificaciones de entrada correspondientes. Las prue-
bas consumen mucho tiempo, pero deben hacerse de un modo sistemático para asegurar
que el resultado cumple con el grado de calidad exigido (densidad de errores por KLDC,
etc). Para medir esta calidad existen algunas métricas. En esta parte del desarrollo se
trata de encontrar errores, no sólo de codificación, sino también los relativos a la especi-
ficación o el diseño, en este sentido se puede distinguir entre verificación y validación.
La verificación trata de comprobar si se está construyendo el producto correctamente,
la validación si es el producto correcto. Las pruebas que se van haciendo durante el
ciclo de vida son: ingeniería del sistema (prueba del sistema), especificación (prueba de
validación), diseño (prueba de integración) y codificación (prueba de unidad). Los tipos
de pruebas tienen naturaleza diferente y en consecuencia, las técnicas para cada una de
ellas son diferentes; también se hará un recorrido por cada una de ellas. Inevitablemente
también hay que añadir la correspondiente documentación de las pruebas realizadas.

Relación con otros temas

Este tema está muy relacionado con los anteriores temas 3 al 5 correspondientes a
las fases de requisitos, diseño e implementación, donde se deben distribuir las pruebas
correspondientes. Es recomendable, aunque no necesario, haber construido alguna vez
un módulo que pruebe a otro dando entradas y comprobando si las salidas que propor-
ciona el módulo probado se corresponden con lo esperado.

13
 CAPÍTULO 5. FASES DE PRUEBAS

Objetivos del tema

Se debe extraer una idea clara de que los principios de ingeniería requieren la com-
probación y verificación de todos los elementos intermedios en el proceso de desarrollo,
en este caso, del software. También se deben conocer técnicas que indiquen los errores
que se comenten, tanto de concepción de la tarea a realizar como de las funcionalidades
que se implementen y que esta detección ocurra lo antes posible.

Guía de estudio y esquema

Es conveniente recapitular y repasar los temas anteriores 3 al 5 para ir identificando
dentro de cada una de las fases cuáles son las pruebas necesarias para la validación que
se explican en este capítulo.

Estrategia, técnicas y métodos de prueba clásicos. Este apartado se debe estudiar

en [Pre05, secs. 13.1 a 13.6 y 14.1 a 14.6]. En la séptima edición [Pre10, secs.
17.1 a 17.7 y 18.1 a 18.6].
Pruebas orientadas a objetos. Este apartado se debe estudiar en [Pre05, secs. 14.7
a 14.9]. En la séptima edición [Pre10, cap. 19].
Pruebas de entornos especializados. Este apartado se debe estudiar en [Pre05, sec.
14.10]. En la séptima edición [Pre10, cap. 18.8].
Patrones de prueba. Este apartado se debe estudiar en [Pre05, sec. 14.11]. En la
séptima edición [Pre10, sec. 18.9].
Documentación de pruebas. El material está incluido directamente en la adenda.

14
Capítulo 6

Fase de entrega y mantenimiento

Tutorial Previo

Introducción
Como etapa final en el ciclo de vida del software se debe realizar la entrega de
la primera versión al cliente y considerar las posibles modificaciones posteriores de
mantenimiento. Dentro del mantenimiento se deben incluir no sólo las correcciones de
errores detectados posteriormente por el cliente, sino también las modificaciones nece-
sarias para la actualización, e incluso las peticiones de cambios por parte del cliente.
Una vez que se entrega el producto, no ha acabado el trabajo, en realidad, es cuando
empieza (y de hecho, existen organizaciones que viven de ello, por ejemplo las que dan
soporte para GNU/Linux y para otras aplicaciones de libre distribución). Existen varios
tipos de mantenimiento, corregir errores es uno de ellos, otros son adaptar el sistema a
nuevos entornos o para proporcionarle nuevas funcionalidades. Es interesante medir el
esfuerzo que se gasta en mantenimiento, para lo que también existen sus correspondi-
entes métricas.
La documentación describe el sistema desde la especificación de requisitos hasta la
aceptación por parte del usuario. Esta información debe estar estructurada y ser legible.
Existen herramientas CASE que automatizan esta parte (hasta donde es posible).

Relación con otros temas

Este tema presenta los elementos finales del ciclo de vida del software y está rela-
cionado con la planificación general del mismo que se presentó en el primer tema y con
las fases de desarrollo en los anteriores.

15
 CAPÍTULO 6. FASE DE ENTREGA Y MANTENIMIENTO

Objetivos del tema

Determinar cuál es la finalización del desarrollo del software y la extensión de la
vida del software desarrollado. Comprender la problemática asociada a mantener una
aplicación. Dar una guía de genérica de como realizar el mantenimiento y dar estrategias
viables para afrontarlo.

Guía de estudio y esquema

El contenido del tema es principalmente teórico por lo que la metodología está más
orientada al estudio de los contenidos y la reflexión sobre los ejemplos.

Finalización del proyecto. Este material se incluye directamente en la adenda.

Reingeniería. El material correspondiente a este apartado está en [Pre05, cap. 31].
En la séptima edición [Pre10, cap. 29] exceptuando las secciones 29.1 y 29.2.
Recopilación y organización de documentación. Este apartado está incluido en
esta guía didáctica.

16
Capítulo 7

Metodologías de desarrollo

Tutorial Previo
Introducción
Una vez que hemos visto las fases más habituales del proceso de análisis, diseño
y mantenimiento del software, es necesario estudiar algunas formas de agrupar, orga-
nizar, secuenciar y distribuir temporalmente las tareas estudiadas, según los detalles
de diferentes metodologías. Una metodología constituye, en definitiva, el manual o
guía que realmente se pone en práctica al abordar la construcción de un sistema. Las
metodologías de desarrollo puede decirse que consisten en “poner orden” en todo lo
que se ha ido viendo hasta ahora, es decir, utilizan un ciclo de vida determinado y
siguen las fases de especificación, diseño, etc. de un modo concreto; algunas incluso
están apoyadas por herramientas hechas a medida (por ejemplo el método Rational).
El tipo de metodologías que se van a ver están orientadas a objetos que son del tipo
que demanda el mercado actualmente y además dan buenos resultados. Se estudia en
primer lugar el “Proceso Unificado de Rational” por su amplia difusión y consideración
de metodología tradicional. A continuación se presenta una metodología alternativa muy
reciente, llamada “Extreme Programming”, que tiene características muy interesantes. A
continuación se presenta la metodología de planificación, desarrollo y mantenimiento de
sistemas de información del Ministerio de las Administraciones Públicas denominada
Métrica (versión 3). Finalmente se hace una aproximación hacia nuevos enfoques de
desarrollo de software surgidos a raíz del movimiento del Software Libre.

Relación con otros temas

Es necesario que el alumno haya estudiado previamente los temas 3 al 7, para que
comprenda cuáles son los elementos que conforman todo el proceso de desarrollo del

17
 CAPÍTULO 7. METODOLOGÍAS DE DESARROLLO

software. En este tema el alumno podrá retomar también los conceptos globales que se
dieron en el primer tema donde encajan las diferentes fases.

Objetivos del tema

Es necesario que el alumno entienda las relaciones y organizaciones posibles entre
las diferentes fases del desarrollo del software que dependen del tipo de entorno y de la
aplicación que se desarrolla. En este tema solamente se detallan unas cuantas ilustrati-
vas. Se trata de aprender métodos actuales, realistas y prácticos de como construir un
sistema desde su concepción hasta su mantenimiento.

Guía de estudio y esquema

Este capítulo es principalmente teórico, pero tiene una vertiente práctica (ver aparta-
do de actividades) que se recomienda realizar, al menos de forma simulada imaginando
los diferentes escenarios, ya que al igual que ocurría en el capítulo dedicado a la imple-
mentación, la única manera de asimilar realmente este capítulo es realizar un proyec-
to donde se ponga en práctica alguna metodología. No se debe pensar que se domina
realmente una metodología hasta que se ha puesto en práctica dentro de un grupo de
desarrollo. El problema que tiene el aprendizaje de una metodología es que no se puede
afrontar fácilmente como un esfuerzo individual (como con el PSP).

Proceso unificado de Rational. El material correspondiente es un resumen de esta

metodología en la adenda.
Método “Extreme Programming”. Incluido en la adenda. Adicionalmente se puede
leer [Pre05, cap. 4]. En la séptima edición [Pre10, cap. 3].
Métrica 3. El material correspondiente es un resumen de esta metodología en la
adenda.
Métodos de software libre: “catedral” vs. “bazar”. Incluido en la adenda.

18
Capítulo 8

Herramientas de desarrollo y
validación

Tutorial Previo
Introducción
Existen varias herramientas informáticas que facilitan las técnicas de la ingeniería
del software en diferentes aspectos. En este tema se estudian en primer lugar las her-
ramientas CASE, posteriormente veremos una herramienta muy genérica para el desar-
rollo de versiones de ficheros de forma concurrente (CVS) y finalmente algunos en-
tornos genéricos de programación.
En el mercado hay varios tipos de herramientas CASE (Computer Aided Software
Engineering) para múltiples propósitos: planificación de proyectos, herramientas de
análisis y diseño, de documentación, etc. Algunas sólo tratan de un tema concreto y
otras abarcan todas las fases de una metodología.
CVS es un sistema de almacén de ficheros (repository) centralizado en un servidor.
El propósito de introducir este apartado aquí es dar a conocer una herramienta que se
usa en el control de configuración. Veremos también la herramienta Subversion.
Por otra parte, hoy en día entre el 50 y el 60 por ciento de las líneas de código de una
aplicación son relativas a la interfaz de usuario, es lógico por tanto que existan algunas
herramientas dedicadas solo a este fin. Las herramientas de desarrollo de interfaces son
en realidad herramientas CASE especializadas.

Relación con otros temas

Aquí conviene recordar tanto las diferentes fases del desarrollo que se han estudiado
en los temas 3 al 7, puesto que esas fases reflejarán la especificidad de las herramientas.

19
 CAPÍTULO 8. HERRAMIENTAS DE DESARROLLO Y VALIDACIÓN

De la misma forma algunos entornos estarán influidos por alguna metodología concreta
de las estudiadas en el tema 8.
Para entender CVS es conveniente conocer un poco el sistema UNIX y tener algunas
nociones de teleinformática. Para manejar una herramientas CASE, sobre todo si está
pensada para una metodología concreta como por ejemplo Rational Rose, es necesario
conocer esa metodología y es imprescindible conocer el UML.

Objetivos del tema

Es necesario conocer los diferentes elementos y posibilidades que proporcionan los
entornos y herramientas informáticas para ayudar precisamente en la construcción de
aplicaciones informáticas. Se pretende poder manejar un conjunto básico de comandos
de CVS. Dar una introducción a las herramientas CASE y de construcción de interfaces.

Guía de estudio y esquema

En este tema se hace una revisión somera de algunas de los tipos de herramientas
existentes. Es conveniente hacer una primera lectura directa, para después hacer pruebas
con algunas de las herramientas que estén disponibles para el alumno, que de esta forma
se puede hacer una idea más clara de cuáles son las posibilidades que aporta y cuáles son
los ámbitos de aplicación de cada una. Al ser este capítulo de contenido eminentemente
práctico, es recomendable probar o “jugar” con las herramientas recomendadas en el
mismo para hacerse una idea de lo que se está hablando.

Herramientas CASE. El material de este apartado está incluido en la adenda.

Gestión de la configuración. El material de este apartado está incluido en la aden-
da.
Entornos de desarrollo de interfaces. Este apartado está incluido directamente en
la adenda y también procede mayormente de la documentación respectiva de los
entornos.

20
Bibliografía

[FW94] Neville J. Ford and Mark Woodroffe. Introducing Software Engineering.

Prentice-Hall, 1994.

[Pre05] Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-

Hill, 2005.

[Pre10] Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-

Hill, 2010.

[RBP+ 96] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and
William Lorensen. Modelado y diseño orientado a objetos. Metodología
OMT y OMT II. Prentice Hall, 1996.

[Sch01] Stephen R. Schach. Object oriented and classical software engineering. Mc

GrawHill, 2001.

[Som98] Ian Sommerville. Ingeniería de Software. Addison-Wesley Iberoamericana,

1998.

[Som01] Ian Sommerville. Software Engineering. Addison-Wesley, 2001.

21