Análisis, Diseño y Mantenimiento del Software - ia.uned… · Dpto. de Inteligencia Artiﬁcial -...

Análisis, Diseño y Mantenimiento del Software

Manuel Arias CallejaDpto. de Inteligencia Artificial - ETSI Informática - UNED

Actualizada en Noviembre de 2010

Índice general

Guía de estudio de la asignatura VPresentació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 asignaturacorrespondiente al primer parcial

Autores: Manuel Arias Calleja. Basado en una versión del año 2003 por Manuel AriasCalleja 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 objetivosEl 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, fiabilidady facilidad de uso. Los enfoques más comunes de la docencia de la IS, se centran en elaná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 satisfaganal usuario.

Esta Guía didáctica está diseñada para conducir el estudio de la asignatura en susaspectos puramente técnicos, que serán los evaluados en las pruebas presenciales. En laGuía de Curso se detallan objetivos docentes adicionales que serán cubiertos medianteactividades NO obligatorias que los alumnos podrán seguir en los cursos virtuales a lavez que estudian el temario convencional.

V


Contexto y conocimientos previos

Contexto académico previoIngenierí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 cualestiene asignados 9 créditos (5 teóricos y 4 prácticos). Las denominaciones que se handado a estas dos asignaturas complementarias son Análisis, Diseño y Mantenimientodel software (descrita como “Análisis y definición de requisitos. Diseño, propiedades ymantenimiento del software”) y Análisis y Gestión del Desarrollo del Software (descritacomo “Análisis de aplicaciones. Gestión de configuraciones. Planificación y gestión deproyectos informáticos”).

Ambas asignaturas se hayan fuertemente vinculadas, en tanto que se complementanpara 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 todoproceso 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 SoftwarePersonal (PSP), cuyo objetivo es la adquisición de una correcta disciplina personal parael 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 elque intervienen decenas o centenares de ingenieros. Su objetivo es también obtener unsoftware de calidad en los plazos y costes planificados, si bien en este caso se destacanla 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, dadosu 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 deingeniería estudiados en la asignatura Análisis, Diseño y Mantenimiento del software,y cómo se aplican en un contexto profesional.

Otras asignaturas relacionadasSon 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 estasasignaturas (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íadel software e Ingeniería del Software de Gestión, como iniciación a la materia objeto

VI


de esta memoria (dada la extensión de los contenidos, es conveniente que el alumnoparta de una visión introductoria y general de la ingeniería de software, conozca losmodelos 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 siha cursado las asignaturas que se encuadran en el componente que en la sección anteriorse 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ónII, 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 lacomputabilidad (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álisisMatemá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ásprá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 optativadel tercer curso, aborda el estudio de las diferentes fases del ciclo de desarrollo de unsistema experto, coincidentes en lo esencial con las fases de desarrollo de los produc-tos software convencionales. Sin duda el alumno que haya estudiado esta asignaturadispondrá 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 medidaque aumenta la complejidad de las aplicaciones software en dominios no tradicional-mente abordados por la Inteligencia artificial, la ingeniería del conocimiento y la ISconvencional han ido eliminando progresivamente sus difusas fronteras, y comenzadoa 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 derequisitos se ven enriquecidas por los interesantes resultados obtenidos en el campo delprocesamiento del lenguaje natural, tradicionalmente estudiado en la Inteligencia Ar-tificial. El conocimiento de los principios básicos de la Inteligencia Artificial, que seestudian en la asignatura obligatoria del segundo curso Introducción a la InteligenciaArtificial, es también sin duda de utilidad en este contexto.

En el programa del 4o curso existe un grupo de asignaturas que guarda una evidenterelación con la Ingeniería del software, y que resulta interesante que el alumno estudieen paralelo con las asignaturas de Ingeniería del software, tratando de establecer las

VII


oportunas conexiones. Es particularmente el caso de la asignatura obligatoria Lógicacomputacional, 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, queredunda en el estudio de las técnicas de la ingeniería del conocimiento. Finalmente, espreciso destacar que los conocimientos adquiridos en estas asignaturas son esencialespara 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 SistemasInformá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 deintroducció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 sonobviamente indispensables para la realización del Proyecto de Fin de Carrera, ejerciciode desarrollo de un proyecto informático que debe llevarse a cabo con el rigor de unproyecto 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ácticaprofesional.

Esquema y resumen de contenidosA 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 trespartes 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 elementosque van a conformar la asignatura. En la segunda parte se van describiendo las distintasfases del desarrollo y mantenimiento del software. La parte final incluye un conjunto demetodologías donde se recopilan y organizan de diferentes formas las fases, junto conalgunas herramientas de desarrollo.

Esta asignatura es anual y por lo tanto se divide en dos parciales. A los efectos deexámenes parciales se considera que los temas del 1 al 4 pertenecen al primer parcial ylos temas del 5 al 8 pertenecen al segundo parcial.

Esquema:

Tema 1: Contexto de la Asignatura en la IS

VIII


• 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


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 conla información que el alumno de educación a distancia necesita para poder estudiarla asignatura. Al principio de cada capítulo se incluye un “Tutorial previo” con loselementos que describen el contexto, conocimiento previo, objetivos y guía de estudiopara ese capítulo. En esta asignatura se utilizará como material básico de estudio parael 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,2005Roger 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 cadacapítulo se sustituirán por la referencia (entre corchetes como [Pre05, sec. ... y cap ...]) alos apartados del libro base, o bien se incluirán desarrollados directamente en esta guíasi no existe una correspondencia directa con el libro base. Se adjuntará la referencia alos contenidos correspondientes a la séptima edición como [Pre10, sec. ... y cap ...]. Alfinal 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 queel 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 enprofundizar 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 seincluye una recopilación de referencias bibliográficas (recomendadas o referidas en elmaterial), más un indice alfabético de referencia para conceptos y términos que aparecenen el material.

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

X


Medios AdicionalesAdicionalmente 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 elEquipo Docente en la Sede Central (en las direcciones, teléfonos y horarios indicadosen 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 lapá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 dereferencias y contenidos que se detallan en los capítulos de esta guía, con la ventajaadicional de que en los medios en línea los enlaces de direcciones en Internet y otrosmateriales 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 contieneal 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 loslibros [Som98] (o la edición en inglés más reciente [Som01]) y [RBP+96]:

Ian Sommerville. Ingeniería de Software. Addison-Wesley Iberoamericana, 1998James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and WilliamLorensen. Modelado y diseño orientado a objetos. Metodología OMT y OMT II.Prentice Hall, 1996

EvaluaciónLa 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. Laspruebas subjetivas consistirán en una parte de preguntas teóricas breves sobre aspectosrelevantes del temario correspondiente, más posiblemente otra parte práctica compues-ta de ejercicios con supuestos prácticos que describirán parcialmente un problema dediseñ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 acada pregunta se especificará en el enunciado. En la nota final se tendrá en cuenta lacompensació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 hastaseptiembre.

En algunos capítulos puede haber propuestas para realizar prácticas por el propioalumno, estas serán totalmente voluntarias (y que por tanto no podrán ser tenidas encuenta para la puntuación de la nota final), pero se recomienda al alumno su realizaciónpara ayudarle a una mejor comprensión de los temas.

XI


XII

Capítulo 1

Contexto de la asignatura en laIngeniería de Software

Tutorial previo

Introducción

Al inicio de la asignatura es conveniente repasar algunos conceptos generales sobreIngeniería de Software e introducir los temas que se van a estudiar.

En el desarrollo de sistemas software es necesario planificar el uso de recursosy temporizar adecuadamente las diferentes actividades para no sobrepasar los límiteseconómicos y de tiempo dedicados a un proyecto. Es principalmente con este objetivoque 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 sistematizaen la medida de lo posible, de modo que el resultado sea previsiblemente aceptable, esdecir, cumpla las expectativas planteadas en términos de tiempo de desarrollo, preciofinal, mantenibilidad y eficiencia.

Una metodología de desarrollo reúne un conjunto de prácticas que se ejercen enlas 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 diferentesetapas, y particularmente a las etapas de análisis y diseño, se han definido notaciones demodelado 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 ciclode 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 lenguajeUML, de uso extendido y soportado actualmente por varias herramientas CASE capacesde generar código a partir de los diagramas de esta notación.

1

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

Relación con otros temasCon 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 Softwarey el desarrollo de programas.

Al mismo tiempo este tema es importante por proporcionar una visión general delas diferentes fases de un ciclo de desarrollo de software y de su coordinación enmetodologías.

Para hacerse una composición de lugar sobre lo que se habla en este capítulo y en laasignatura en general es recomendable haber desarrollado algún proyecto en un lenguajede programación.

Objetivos del temaEste 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 estructurageneral 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 necesidadde utilizar una metodología en el desarrollo de aplicaciones, comprender las ventajas einconvenientes de los diferentes ciclos de vida para discernir cuando es adecuado usaruno u otro, y saber utilizar (en un nivel medio) la notación UML para la especificacióny diseño de sistemas.

Guía de estudio y esquemaEs conveniente realizar una lectura inicial del tema para identificar sus contenidos y

repasar los conceptos que considere necesarios, bien acudiendo a textos de asignaturasya cursadas, bien estudiando las referencias proporcionadas en el apartado de “extensiónde conocimientos”. El capítulo tiene tres partes:

La explicación acerca de la necesidad de una metodología se incluye directamenteen la adenda y, adicionalmente, se debe estudiar en el libro base [Pre05, cap. 1, ysecs. 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 einconvenientes. También este apartado está en la adenda y se debe extender suestudio 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 estaparte consiste en estudiar la teoría e ir haciendo pequeños ejemplos. En la adenda

2


se incluye este apartado. Además de los ejemplos de la adenda se pueden consultarlos que aparecen en el libro base en [Pre05, secs. 7.5 y 8.3 a 8.8]. En la séptimaedición [Pre10, Apéndice 1].

De los apartados anteriores nos interesan fundamentalmente los ejemplos; la teoríade dichos apartados se referencia en el siguiente capítulo de esta guía. Advertimosque 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 queaún la segunda es relativamente reciente y es de prever que ambas versiones con-vivan en el mundo empresarial durante un tiempo significativo. (Las novedadesintroducidas en la segunda versión se estudiarán en una adenda a esta guía que sepublicará el primero de noviembre en la Web de la asignatura).

3


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 suestudio 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 unmodo ú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 requisitomal entendido. La realización de una buena especificación no es tan sencillo como sepuede pensar en un principio, pues muchas veces el propio cliente no tiene una imagenclara 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 paraque 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 especificacioneses un problema muy relacionado con la Ingeniería del Conocimiento, por tanto seríaconveniente que el alumno repasara los temas correspondientes en las asignaturas pre-vias relacionadas. Es necesario ejercitar la capacidad de abstracción para poder expresarlo que pide el cliente en una representación formal que responda a sus expectativas.

5

CAPÍTULO 2. FASE DE ESPECIFICACIÓN

Objetivos del temaEs 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 deldesarrollo. 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 fasesiguiente de diseño.

Guía de estudio y esquemaEn 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 requisitosen esos ejemplos para generalizarlo a otros problemas.

1. Obtención de requisitos: se estudia directamente en el material en esta guía. Sedeben 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 sepuede estudiar en [Pre05, secs. 7.6 y 7.7]. En la séptima edición [Pre10, secs. 5.5y 5.6].

3. Modelado del análisis y de datos: el contenido se estudiará en [Pre05, secs. 8.1 a8.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 laséptima edición no existe explícitamente, pero se puede consultar el punto 2.4 dela adenda.

5. Modelado basado en escenarios: el contenido se estudiará en [Pre05, sec. 8.5]. Enla séptima edición [Pre10, secs. 6.2].

6. Modelado de clases: el contenido se estudiará en [Pre05, sec. 8.7]. En la séptimaedición [Pre10, sec. 6.5].

7. Modelado del comportamiento: el contenido se estudiará en [Pre05, sec. 8.8]. Enla séptima edición [Pre10, sec. 7.3].

8. Análisis estructurado (en el libro se denomina “Modelado orientado al flujo”): elcontenido se estudiará en [Pre05, sec. 8.6]. En la séptima edición [Pre10, sec. 7.1y 7.2].

9. Validación de requisitos: en [Pre05, sec.7.8] junto con el apartado correspondienteen 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 estaguí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 ideary componer la forma de la solución para el problema. El diseño es la fase en la quese estudia el problema, se identifican las características que tendría una solución y seanaliza a su vez cada una de esas características. En la fase de diseño es más efectivoutilizar patrones y modelos conocidos para ir resolviendo partes del problema, es decirmodularizar el problema y proyectarlo en módulos en la solución. Aunque, el procesode diseño es en gran medida ad hoc, es decir, no está tan formalizado como las otrasfases 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 conla parte correspondiente de documentación de todo el proceso. Principalmente hay dostipos 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 atributosasociados. 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 secumplen requisitos de calidad. La mejor forma de redactar la documentación consisteen seguir una plantilla de un documento estándar rellenando varias secciones.

7

CAPÍTULO 3. FASE DE DISEÑO

Relación con otros temasPara 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ésen 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 datosnecesarias e identificar flujos de datos entre subsistemas y cuáles son las entradas ysalidas necesarias para cada subsistema.

Objetivos del temaSe 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 permitanconocer cuál es el método más apropiado en cada situación. Se pretende en este temaintroducir los dos tipos de métodos que existen de diseñar un sistema y proporcionar unmétodo genérico para redactar la documentación.

Guía de estudio y esquemaA 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 dela experiencia de los diseñadores. El mejor método para aprender a diseñar es realizartodos los ejercicios propuestos (tanto explícitos, en el tutorial posterior, como implícitoso genéricos mencionados anteriormente).

Conceptos generales de diseño: este apartado se estudiará en [Pre05, cap. 9]. En laséptima edición [Pre10, cap. 8], excluyendo las secciones 8.2.2 y 8.3.9. Se incluyeen la adenda una pequeña introducción a los patrones y al diseño orientado aobjetos, 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 unafase temprana o provisional del diseño, ya se puede comenzar a plasmar ese diseño enel código que permita realizarlo o implementarlo. En esta fase el programador recibelas especificaciones del diseño y transforma esas especificaciones, que pueden estar enformatos mezclados formales, semiformales o manuales, en un programa o módulo quelas efectúe. Esta tarea de modificación puede estar semi-automatizada en algunos casoso realizarse de forma completamente manual. En cualquier caso se requiere que esatransformación se haga de manera sistemática y coherente. Las particularidades propiasde lenguajes de programación concretos se estudian en otras asignaturas y por tanto nose incluirán en este tema.

Durante la implementación se escribe el código de la aplicación. Existen una seriede "vicios" en el estilo de codificación que pueden tener como consecuencia que elcódigo sea confuso para terceras personas o para uno mismo pasado un tiempo y enconsecuencia 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ñosmódulos que se reparte entre individuos o pequeños grupos atendiendo a un gráfico dedependencias entre tareas y con la idea en mente de paralelizar tanto trabajo como seaposible. A medida que se van haciendo los módulos hay que comprobar que cumplencon una cierta calidad, para ello existen varios tipos de pruebas. En este capitulo seestudia la necesidad de comprobar la ejecución correcta del módulo, por tanto interesanlas 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 temasEn 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 entendery generalizar la idea de los estilos de codificación y la depuración. Para comprender laproblemática asociada a la programación es necesario conocer muy bien al menos unlenguaje de programación y tener alguna experiencia con él. Se puede considerar quecon las prácticas de programación de cursos pasados es suficiente.

Objetivos del temaLos 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 lanecesidad de realizar pruebas y depuración de errores propios de la implementación. Sebusca 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 ungrupo de personas y tener una plantilla para redactar documentación para los manualesde usuario y técnico.

Guía de estudio y esquemaDespué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, utilizandoel lenguaje de programación que mejor conozca o prefiera el alumno. En paralelo conel estudio del tema podría ser de interés que se desarrollara un pequeño proyecto deprogramació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 cuales una tarea que requiere constancia. La redacción de una documentación de calidad noes trivial, son necesarias aptitudes pedagógicas, de estilo de escritura, etc. De todasformas, 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ónde 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


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

11


12

Capítulo 5

Fases de pruebas

Tutorial Previo

IntroducciónEste 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ásfases. Las pruebas en este caso consisten en la comprobación de que la salida obtenidaen cada fase corresponde a las especificaciones de entrada correspondientes. Las prue-bas consumen mucho tiempo, pero deben hacerse de un modo sistemático para asegurarque 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 setrata 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 elciclo de vida son: ingeniería del sistema (prueba del sistema), especificación (prueba devalidación), diseño (prueba de integración) y codificación (prueba de unidad). Los tiposde pruebas tienen naturaleza diferente y en consecuencia, las técnicas para cada una deellas son diferentes; también se hará un recorrido por cada una de ellas. Inevitablementetambién hay que añadir la correspondiente documentación de las pruebas realizadas.

Relación con otros temasEste 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 pruebascorrespondientes. Es recomendable, aunque no necesario, haber construido alguna vezun 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 temaSe 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 erroresque se comenten, tanto de concepción de la tarea a realizar como de las funcionalidadesque se implementen y que esta detección ocurra lo antes posible.

Guía de estudio y esquemaEs 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 quese explican en este capítulo.

Estrategia, técnicas y métodos de prueba clásicos. Este apartado se debe estudiaren [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.7a 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 lasé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 dela primera versión al cliente y considerar las posibles modificaciones posteriores demantenimiento. Dentro del mantenimiento se deben incluir no sólo las correcciones deerrores 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 cuandoempieza (y de hecho, existen organizaciones que viven de ello, por ejemplo las que dansoporte para GNU/Linux y para otras aplicaciones de libre distribución). Existen variostipos de mantenimiento, corregir errores es uno de ellos, otros son adaptar el sistema anuevos entornos o para proporcionarle nuevas funcionalidades. Es interesante medir elesfuerzo 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 laaceptació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).


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 conlas fases de desarrollo en los anteriores.

15

CAPÍTULO 6. FASE DE ENTREGA Y MANTENIMIENTO

Objetivos del temaDeterminar 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 unaaplicación. Dar una guía de genérica de como realizar el mantenimiento y dar estrategiasviables para afrontarlo.

Guía de estudio y esquemaEl 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 enesta 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ñoy mantenimiento del software, es necesario estudiar algunas formas de agrupar, orga-nizar, secuenciar y distribuir temporalmente las tareas estudiadas, según los detallesde diferentes metodologías. Una metodología constituye, en definitiva, el manual oguía que realmente se pone en práctica al abordar la construcción de un sistema. Lasmetodologías de desarrollo puede decirse que consisten en “poner orden” en todo loque se ha ido viendo hasta ahora, es decir, utilizan un ciclo de vida determinado ysiguen las fases de especificación, diseño, etc. de un modo concreto; algunas inclusoestá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 tipoque demanda el mercado actualmente y además dan buenos resultados. Se estudia enprimer lugar el “Proceso Unificado de Rational” por su amplia difusión y consideraciónde metodología tradicional. A continuación se presenta una metodología alternativa muyreciente, llamada “Extreme Programming”, que tiene características muy interesantes. Acontinuación se presenta la metodología de planificación, desarrollo y mantenimiento desistemas de información del Ministerio de las Administraciones Públicas denominadaMétrica (versión 3). Finalmente se hace una aproximación hacia nuevos enfoques dedesarrollo de software surgidos a raíz del movimiento del Software Libre.


Es necesario que el alumno haya estudiado previamente los temas 3 al 7, para quecomprenda 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 sedieron en el primer tema donde encajan las diferentes fases.

Objetivos del temaEs 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 laaplicació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 unsistema desde su concepción hasta su mantenimiento.

Guía de estudio y esquemaEste 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 imaginandolos 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 dominarealmente una metodología hasta que se ha puesto en práctica dentro de un grupo dedesarrollo. El problema que tiene el aprendizaje de una metodología es que no se puedeafrontar fácilmente como un esfuerzo individual (como con el PSP).

Proceso unificado de Rational. El material correspondiente es un resumen de estametodología en la adenda.Método “Extreme Programming”. Incluido en la adenda. Adicionalmente se puedeleer [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 laadenda.Métodos de software libre: “catedral” vs. “bazar”. Incluido en la adenda.

18

Capítulo 8

Herramientas de desarrollo yvalidación

Tutorial Previo

Introducción

Existen varias herramientas informáticas que facilitan las técnicas de la ingenieríadel 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 SoftwareEngineering) para múltiples propósitos: planificación de proyectos, herramientas deanálisis y diseño, de documentación, etc. Algunas sólo tratan de un tema concreto yotras 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 seusa 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 unaaplicación son relativas a la interfaz de usuario, es lógico por tanto que existan algunasherramientas dedicadas solo a este fin. Las herramientas de desarrollo de interfaces sonen realidad herramientas CASE especializadas.


Aquí conviene recordar tanto las diferentes fases del desarrollo que se han estudiadoen 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 concretade las estudiadas en el tema 8.

Para entender CVS es conveniente conocer un poco el sistema UNIX y tener algunasnociones de teleinformática. Para manejar una herramientas CASE, sobre todo si estápensada para una metodología concreta como por ejemplo Rational Rose, es necesarioconocer esa metodología y es imprescindible conocer el UML.

Objetivos del temaEs necesario conocer los diferentes elementos y posibilidades que proporcionan los

entornos y herramientas informáticas para ayudar precisamente en la construcción deaplicaciones informáticas. Se pretende poder manejar un conjunto básico de comandosde CVS. Dar una introducción a las herramientas CASE y de construcción de interfaces.

Guía de estudio y esquemaEn 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 pruebascon algunas de las herramientas que estén disponibles para el alumno, que de esta formase puede hacer una idea más clara de cuáles son las posibilidades que aporta y cuáles sonlos ámbitos de aplicación de cada una. Al ser este capítulo de contenido eminentementepráctico, es recomendable probar o “jugar” con las herramientas recomendadas en elmismo 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 enla adenda y también procede mayormente de la documentación respectiva de losentornos.

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, andWilliam Lorensen. Modelado y diseño orientado a objetos. MetodologíaOMT y OMT II. Prentice Hall, 1996.

[Sch01] Stephen R. Schach. Object oriented and classical software engineering. McGrawHill, 2001.

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

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

21

Análisis, Diseño y Mantenimiento del Software - ia.uned… · Dpto. de Inteligencia Artiﬁcial -...

Documents

Transcript of Análisis, Diseño y Mantenimiento del Software - ia.uned… · Dpto. de Inteligencia Artiﬁcial -...