Análisis, Diseño y Mantenimiento del Software

Manuel Arias Calleja

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

Actualizada en Junio de 2007

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 especicació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

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: Octubre de 2006 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

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

Breve descripción:
Análisis y denició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 mantenimiento

de software de forma sistemática y productiva, asegurando su calidad, abilidad 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 integrales 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 Edu-
cación a Distancia (Resolución de 21 de marzo de 2001, BOE 10 de abril), se ha dividido
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 es-
tas dos asignaturas complementarias son Análisis, Diseño y Mantenimiento del software
(descrita como “Análisis y denició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 conguraciones. Planicación y gestión de proyectos infor-
má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 pro-
ceso de ingeniería.
El programa de la asignatura Análisis y Gestión del Desarrollo del Software está es-
tructurado 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 planicados, 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 denitiva, el objeto de la asignatura Análisis
y Gestión del Desarrollo del Software es mostrar cómo se evalúan las técnicas de inge-
nierí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 asignatura

Análisis, Diseño y Mantenimiento del Software. El haber cursado algunas de estas asig-
naturas (o bien las asignaturas equivalentes de carreras impartidas en otras universidades)
es requisito imprescindible para su adecuado seguimiento.

VI
ÍNDICE GENERAL ÍNDICE GENERAL

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 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 cuentan las
relacionadas con la teoría de la programación (Programación I, Programación II, Progra-
mació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 computabili-
dad (Teoría de autómatas I, Teoría de autómatas II). (Obviamente, la comprensión de las
mencionadas asignaturas a su vez ha exigido del alumno los conocimientos 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 algu-
nas asignaturas relacionadas con los temas anteriores pero de una orientación más práctica
y especíca. Es el caso de las optativas del tercer curso Programación Concurrente, Pro-
gramación Declarativa y Programación Orientada a la Inteligencia Articial (orientadas a
la programación), y Diseño y Evaluación de Conguraciones, y Conguració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 contenidos,

que el alumno disponga de conocimientos del campo de la Inteligencia Articial. En par-
ticular, 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 ex-
perto, coincidentes en lo esencial con las fases de desarrollo de los productos software
convencionales. Sin duda el alumno que haya estudiado esta asignatura dispondrá de una
visión más abierta, y la reexión sobre los paralelismos y discrepancias entre ambas dis-
ciplinas le ayudará a profundizar en la materia. De hecho, a medida que aumenta la com-
plejidad de las aplicaciones software en dominios no tradicionalmente abordados por la
Inteligencia articial, la ingeniería del conocimiento y la IS convencional han ido elim-
inando progresivamente sus difusas fronteras, y comenzado a beneciarse mutuamente
de sus respectivos avances. En concreto, el uso de las técnicas 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 Articial. El conocimiento de los principios
básicos de la Inteligencia Articial, que se estudian en la asignatura obligatoria del segun-

VII
ÍNDICE GENERAL ÍNDICE GENERAL

do curso Introducción a la Inteligencia Articial, es también sin duda de utilidad en este

contexto.
o
En el programa del 4 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 oportunas
conexiones. Es particularmente el caso de la asignatura obligatoria Lógica computacional,
donde se estudian los fundamentos de las técnicas formales de desarrollo software y de la
asignatura Inteligencia Articial 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 particular, 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, Diseño de Sistemas de Trabajo Cooperativo
(CSCW) y Calidad de Software; y sirven de introducción a las asignaturas optativas Sis-
temas en tiempo real, Seguridad en las comunicaciones 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á fundamental 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 nal incluye un conjunto de
metodologías donde se recopilan y organizan de diferentes formas las fases, junto con
algunas herramientas de desarrollo.

VIII
ÍNDICE GENERAL ÍNDICE GENERAL

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

• Necesidad de una metodología

• Ciclo de vida del software

• Notaciones de especicació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 conrmación del diseño

• Documentación: especicación del diseño

Tema 4: Fase de Implementación

• Guías de estilo de codicación

• Iteración de pruebas y depuración

• Manuales técnico y de usuario

Tema 5: Fases de Pruebas

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

• Técnicas y métodos de prueba

• Documentación de pruebas

IX
ÍNDICE GENERAL ÍNDICE GENERAL

Tema 6: Fase de Entrega y Mantenimiento

• Finalización del proyecto

• Planicación de revisiones y organización del mantenimiento

• Recopilación y organización de documentación

Tema 7: Metodologías de Desarrollo

• Proceso Unicado de Rational

• Método Extreme Programming

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

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 asig-
natura. 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 el libro [Pre05] (opcional-
mente se podrá seguir la asignatura con la edición anterior [Pre01], pero la referencia para
las preguntas de los exámenes es la sexta edición):

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

2005

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. Al nal de cada capítulo se incluye
en esta guía un “Tutorial posterior” que contiene ejercicios o actividades propuestas adi-
cionales a las que aparecen en el libro base, para que el alumno pueda comprobar si ha

X
ÍNDICE GENERAL ÍNDICE GENERAL

logrado los objetivos del capítulo, y también información adicional para la extensión de
conocimientos para los alumnos interesados en profundizar en el tema, junto con referen-
cias alternativas sobre los mismos contenidos. Al nal de esta guía didáctica se incluye en
un apéndice el glosario de términos habituales en la Ingeniería de Software que pueden
1
aparecer en el contenido , también se incluye una recopilación de referencias bibliográ-
cas (recomendadas o referidas en el material), más un indice alfabético de referencia para
conceptos y términos que aparecen en el material.

Medios Adicionales

Adicionalmente a esta guía, el alumno dispondrá de los medios de comunicación habit-

uales con su Profesor Tutor en el Centro Asociado o a través de las Tutorías Telemáticas (o
Cursos Virtuales) de la UNED http://virtual.uned.es/, y también con el Equipo Do-
cente 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 recopilación de informa-
ció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 actu-
alizando más frecuentemente. Se recomienda encarecidamente el seguimiento de los cur-
sos virtuales. Además del libro base (que contiene al nal de cada capítulo “otras lecturas
y fuentes de información”) y del material incluido 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 ocial 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

1
Además al nal del libro base [Pre05] o [Pre01] hay un apéndice que recopila todas las siglas en ingles
y castellano usadas profusamente en Ingeniería del Software.

XI
ÍNDICE GENERAL ÍNDICE GENERAL

relevantes del temario correspondiente, más posiblemente otra parte práctica compuesta
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 aspectos rela-
cionados con el temario correspondiente. La puntuación correspondiente a cada pregunta
se especicará en el enunciado. En la nota nal se tendrá en cuenta la compensación en-
tre preguntas dentro de un mismo examen parcial así como la compensació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 alum-
no, estas serán totalmente voluntarias (y que por tanto no podrán ser tenidas en cuenta para
la puntuación de la nota nal), pero se recomienda al alumno su realización para ayudarle
a una mejor comprensión de los temas.

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 planicar el uso de recursos y tempo-
rizar 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 Ingenierí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 nal, mantenibilidad y eciencia.
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: especicación,
diseño, codicación, pruebas y mantenimiento. Para dar soporte a las diferentes etapas, y
particularmente a las etapas de análisis y diseño, se han denido 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 desarrol-
lo 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 profundizará 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

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

código a partir de los diagramas de esta notación.

Relación con otros temas

Con este tema se pretende asegurar que el alumno dispone de base suciente para
abordar el estudio del resto de la asignatura. Es recomendable el repaso de las asignaturas
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 plani-
cació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 in-
convenientes 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 especicación y diseño
de sistemas.

Guía de estudio y esquema

Es conveniente realizar una lectura inicial del tema para identicar 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].

Los ciclos de vida. Se da una descripción de cada uno y una lista de ventajas e in-
convenientes. 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].

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

La notación de especicació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 se in-
cluye 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].De los apartados an-
teriores 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 reere a la primera versión del lenguaje. Hemos creído con-
veniente 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 convivan en el mundo
empresarial durante un tiempo signicativo. (Las novedades introducidas en la se-
gunda 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 especicació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 especicació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 especicació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 especicació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 nal o surgen nuevas necesidades a mitad del desarrollo. Este problema
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
especicació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 especicaciones es

un problema muy relacionado con la Ingeniería del Conocimiento, por tanto sería con-
veniente que el alumno repasara los temas correspondientes en las asignaturas previas
relacionadas. Es necesario ejercitar la capacidad de abstracción para poder expresar lo que

5
 CAPÍTULO 2. FASE DE ESPECIFICACIÓN

pide el cliente en una representación formal que responda a sus expectativas.

Objetivos del tema

Es necesario en esta fase separar y entender los conceptos propios de cómo especicar
un problema y cómo hacer útil esas especicaciones para posteriores fases del desarrollo.
El alumno debe ser capaz de extraer y representar un conjunto de requisitos 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 identicar

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].

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].

3. Modelado del análisis y de datos: el contenido se estudiará en [Pre05, secs. 8.1 a

8.3].

4. Análisis orientado a objetos: el contenido se estudiará en [Pre05, sec. 8.4].

5. Modelado basado en escenarios: el contenido se estudiará en [Pre05, sec. 8.5].

6. Modelado de clases: el contenido se estudiará en [Pre05, sec. 8.7].

7. Modelado del comportamiento: el contenido se estudiará en [Pre05, sec. 8.8].

8. Análisis estructurado (en el libro se denomina “Modelado orientado al ujo”): el

contenido se estudiará en [Pre05, sec. 8.6].

9. Validación de requisitos: en [Pre05, sec.7.8]junto con el apartado correspondiente

en esta guía.

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 identicado 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 identican 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 prob-
lema 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 comparació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 renando 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 identican 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 especicaciones 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 mode-
los 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 requisitos para
entender cuáles son los elementos de entrada en el diseño. Es necesario saber: descom-
poner un problema en otros más pequeños, identicar las estructuras de datos necesarias e
identicar ujos 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 uti-
lizadas, junto con la comprensión de las diferencias entre esas técnicas que permitan cono-
cer 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, utilizando
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].

Se incluye en la adenda una pequeña introducción a los patrones y al diseño orien-

tado a objetos.

Diseño arquitectónico. Este apartado se estudiará en [Pre05, cap. 10]. La sección

[Pre05, sec. 10.6] trata el diseño estructurado.

Diseño al nivel de componentes. Este apartado se estudiará en [Pre05, cap. 11].

Validación y conrmació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 es-
pecicaciones del diseño y transforma esas especicaciones, que pueden estar en formatos
mezclados formales, semiformales o manuales, en un programa o módulo que las efectúe.
Esta tarea de modicació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. Lo que sí se estudiarán son las técnicas o estilos de codicación formal.

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

"vicios" en el estilo de codicació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 Pro-
cess). 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áco 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

9
 CAPÍTULO 4. FASE DE IMPLEMENTACIÓN

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 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 enten-
der y generalizar la idea de los estilos de codicació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 suciente.

Objetivos del tema

Los objetivos de este tema son resaltar la importancia de que la codicació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 entregar
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-
icación con distintos estilos basándose en los mismos ejemplos mostrados, utilizando
el lenguaje de programación que mejor conozca o preera el alumno. En paralelo con el
estudio del tema podría ser de interés que se desarrollara un pequeño proyecto de progra-
mació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áti-
ca”, es decir, al nal lo que hay que hacer es seguir un manual de redacción de manuales.

10
CAPÍTULO 4. FASE DE IMPLEMENTACIÓN

Guías de estilo de codicación. Este apartado se estudia directamente en la adenda.

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

13.7].

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 especicaciones de entrada correspondientes. Las pruebas
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 codicación, sino también los relativos a la especicación o el
diseño, en este sentido se puede distinguir entre vericación y validación. La vericació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), especicación (prueba de validación), diseño (prueba de
integración) y codicació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

13
 CAPÍTULO 5. FASES DE 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 proporciona el
módulo probado se corresponden con lo esperado.

Objetivos del tema

Se debe extraer una idea clara de que los principios de ingeniería requieren la compro-
bación y vericació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 identicando

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].

Pruebas orientadas a objetos. Este apartado se debe estudiar en [Pre05, secs. 14.7 a
14.9].

Pruebas de entornos especializados. Este apartado se debe estudiar en [Pre05, sec.

14.10].

Patrones de prueba. Este apartado se debe estudiar en [Pre05, sec. 14.11].

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 nal en el ciclo de vida del software se debe realizar la entrega de la
primera versión al cliente y considerar las posibles modicaciones posteriores de manten-
imiento. Dentro del mantenimiento se deben incluir no sólo las correcciones de errores
detectados posteriormente por el cliente, sino también las modicaciones necesarias 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 man-
tenimiento, 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 gas-
ta en mantenimiento, para lo que también existen sus correspondientes métricas.
La documentación describe el sistema desde la especicació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 nales del ciclo de vida del software y está relaciona-
do con la planicació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 nalización del desarrollo del software y la extensión de la vi-

da del software desarrollado. Comprender la problemática asociada a mantener una apli-
cació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 reexió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].

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, organizar,
secuenciar y distribuir temporalmente las tareas estudiadas, según los detalles de diferentes
metodologías. Una metodología constituye, en denitiva, el manual o guía que realmente
se pone en práctica al abordar la construcción de un sistema. Las metodologías de desar-
rollo 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 especicació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 Unicado de Rational” por su amplia difusión y consideración de
metodología tradicional. A continuación se presenta una metodología alternativa muy re-
ciente, llamada “Extreme Programming”, que tiene características muy interesantes. A
continuación se presenta la metodología de planicación, desarrollo y mantenimiento
de sistemas de información del Ministerio de las Administraciones Públicas denomina-
da 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.

17
 CAPÍTULO 7. METODOLOGÍAS DE DESARROLLO

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
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 ilustrativas.
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 proyecto
donde se ponga en práctica alguna metodología. No se debe pensar que se domina real-
mente una metodología hasta que se ha puesto en práctica dentro de un grupo de desarrol-
lo. 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 unicado 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].

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 herramientas
CASE, posteriormente veremos una herramienta muy genérica para el desarrollo de ver-
siones de cheros de forma concurrente (CVS) y nalmente algunos entornos genéricos
de programación.
En el mercado hay varios tipos de herramientas CASE (Computer Aided Software En-
gineering) para múltiples propósitos: planicació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 cheros (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 conguració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 n. 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 reejarán la especicidad de las herramientas.

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

De la misma forma algunos entornos estarán inuidos 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 algu-
nas 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 apli-
caciones 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 ex-
istentes. 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ác-
tico, 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 conguración. El material de este apartado está incluido en la adenda.

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.

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

Hill, 2001.

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

Hill, 2005.

+
[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