Análisis, Diseño y Mantenimiento del Software. Manuel Arias Calleja Dpto. de Inteligencia Artificial - ETSI Informática - UNED

Transcripción

1 Análisis, Diseño y Mantenimiento del Software Manuel Arias Calleja Dpto. de Inteligencia Artificial - ETSI Informática - UNED Actualizada en Noviembre de 2010

2 II

3 Índice general Guía de estudio de la asignatura V Presentación y objetivos V Contexto y conocimientos previos VI Esquema y resumen de contenidos VIII Material y medios de estudio X 1. Contexto de la asignatura en la Ingeniería de Software 1 2. Fase de especificación 5 3. Fase de diseño 7 4. Fase de implementación 9 5. Fases de pruebas Fase de entrega y mantenimiento Metodologías de desarrollo Herramientas de desarrollo y validación 19 Bibliografía 21 III

4 ÍNDICE GENERAL ÍNDICE GENERAL IV

5 Guía de estudio de la asignatura correspondiente al primer parcial Autores: Manuel Arias Calleja. Basado en una versión del año 2003 por Manuel Arias Calleja y José Ramón Álvarez Sánchez. Revisado: Noviembre de 2010 por Manuel Arias Calleja y Ángeles Manjarrés Riesco Revisión de los elementos del UML: Ángeles Manjarrés y Manuel Arias Calleja Revisión de los principios de orientación a objetos: Manuel Arias Asignatura: Análisis, Diseño y Mantenimiento de Software Código: (4 o curso de la titulación: Ingeniero Informático ) Breve descripción: Análisis y definición de requisitos. Diseño, propiedades y mantenimiento del software. 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, fiabilidad y facilidad de uso. Los enfoques más comunes de la docencia de la IS, se centran en el análisis de los procesos de desarrollo y mantenimiento, así como de las técnicas 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

6 Í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 Educació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 estas dos asignaturas complementarias son Análisis, Diseño y Mantenimiento del software (descrita como Análisis y definición de requisitos. Diseño, propiedades y mantenimiento del software ) y Análisis y Gestión del Desarrollo del Software (descrita como Análisis de aplicaciones. Gestión de configuraciones. Planificación y gestión de proyectos informáticos ). Ambas asignaturas se hayan fuertemente vinculadas, en tanto que se complementan para proporcionar una visión general del proceso completo de la producción de software, tanto desde un punto de vista técnico como humano, vertientes que caracterizan todo proceso de ingeniería. El programa de la asignatura Análisis y Gestión del Desarrollo del Software está estructurado en dos cuatrimestres. El primer cuatrimestre se dedica al Proceso Software Personal (PSP), cuyo objetivo es la adquisición de una correcta disciplina personal para el desarrollo de un software de calidad en los plazos y costes comprometidos. El segundo cuatrimestre está dedicado a la gestión global del proceso de desarrollo software en el que intervienen decenas o centenares de ingenieros. Su objetivo es también obtener un software de calidad en los plazos y costes planificados, si bien en este caso se destacan la problemática y las técnicas asociadas al trabajo en equipo. Las asignaturas de Ingeniería del software deberían, idealmente, ser cursadas en paralelo por los alumnos, dado su carácter mutuamente complementario. En definitiva, el objeto de la asignatura Análisis y Gestión del Desarrollo del Software es mostrar cómo se evalúan las técnicas de ingeniería estudiados en la asignatura Análisis, Diseño y Mantenimiento del software, y cómo se aplican en un contexto profesional. Otras asignaturas relacionadas Son muchas y diversas las asignaturas de la titulación relacionadas con la asignatura Análisis, Diseño y Mantenimiento del Software. El haber cursado algunas de estas asignaturas (o bien las asignaturas equivalentes de carreras impartidas en otras universidades) es requisito imprescindible para su adecuado seguimiento. En concreto, es razonable esperar que el alumno matriculado en Ingeniería del software haya seguido previamente las asignaturas obligatorias del primer ciclo Ingeniería del software e Ingeniería del Software de Gestión, como iniciación a la materia objeto VI

7 ÍNDICE GENERAL ÍNDICE GENERAL de esta memoria (dada la extensión de los contenidos, es conveniente que el alumno parta de una visión introductoria y general de la ingeniería de software, conozca los modelos de ciclo de vida básicos y alguna metodología estructurada). Por otro lado, el alumno sólo podrá dar pleno sentido al contenido de esta materia si ha cursado las asignaturas que se encuadran en el componente que en la sección anterior se ha etiquetado por Fundamentos de la computación. Entre tales asignaturas se cuentan las relacionadas con la teoría de la programación (Programación I, Programación II, Programación III, Estructura de Datos y Algoritmos y Lenguajes de Programación, todas ellas asignaturas obligatorias del primer ciclo), y las que estudian la teoría de la computabilidad (Teoría de autómatas I, Teoría de autómatas II). (Obviamente, la 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 algunas asignaturas relacionadas con los temas anteriores pero de una orientación más práctica y específica. Es el caso de las optativas del tercer curso Programación Concurrente, 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 Configuració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 Artificial. En particular, la asignatura Sistemas basados en conocimiento I, asignatura optativa del tercer curso, aborda el estudio de las diferentes fases del ciclo de desarrollo de un sistema experto, coincidentes en lo esencial con las fases de desarrollo de los productos software convencionales. Sin duda el alumno que haya estudiado esta asignatura dispondrá de una visión más abierta, y la reflexión sobre los paralelismos y discrepancias entre ambas disciplinas le ayudará a profundizar en la materia. De hecho, a medida que aumenta la complejidad de las aplicaciones software en dominios no tradicionalmente abordados por la Inteligencia artificial, la ingeniería del conocimiento y la IS convencional han ido eliminando progresivamente sus difusas fronteras, y comenzado a beneficiarse mutuamente de sus respectivos avances. En concreto, el uso de las té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 Artificial. El conocimiento de los principios básicos de la Inteligencia Artificial, que se estudian en la asignatura obligatoria del segundo curso Introducción a la Inteligencia Artificial, es también sin duda de utilidad en este contexto. En el programa del 4 o curso existe un grupo de asignaturas que guarda una evidente relación con la Ingeniería del software, y que resulta interesante que el alumno estudie en paralelo con las asignaturas de Ingeniería del software, tratando de establecer las VII

8 ÍNDICE GENERAL ÍNDICE GENERAL oportunas conexiones. Es particularmente el caso de la asignatura obligatoria Lógica computacional, donde se estudian los fundamentos de las técnicas formales de desarrollo software y de la asignatura Inteligencia Artificial e Ingeniería del Conocimiento, que redunda en el estudio de las técnicas de la ingeniería del conocimiento. Finalmente, es preciso destacar que los conocimientos adquiridos en estas asignaturas son esenciales para el seguimiento de una buena parte de las asignaturas del quinto curso, en 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 Sistemas 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 final incluye un conjunto de metodologías donde se recopilan y organizan de diferentes formas las fases, junto con algunas herramientas de desarrollo. Esta asignatura es anual y por lo tanto se divide en dos parciales. A los efectos de exámenes parciales se considera que los temas del 1 al 4 pertenecen al primer parcial y los temas del 5 al 8 pertenecen al segundo parcial. Esquema: Tema 1: Contexto de la Asignatura en la IS VIII

9 ÍNDICE GENERAL ÍNDICE GENERAL Necesidad de una metodología Ciclo de vida del software Notaciones de especificación y diseño Tema 2: Fase de Requisitos Obtención de requisitos Análisis de requisitos Representación de requisitos Validación de requisitos Bases de documentación Tema 3: Fase de Diseño Conceptos y elementos del diseño Métodos de diseño Validación y confirmación del diseño Documentación: especificación del diseño Tema 4: Fase de Implementación Iteración de pruebas y depuración Manuales técnico y de usuario Tema 5: Fases de Pruebas Verificación y validación a lo largo del ciclo de vida Técnicas y métodos de prueba Documentación de pruebas Tema 6: Fase de Entrega y Mantenimiento Finalización del proyecto Planificación de revisiones y organización del mantenimiento Recopilación y organización de documentación Tema 7: Metodologías de Desarrollo Proceso Unificado de Rational Método Extreme Programming Métodos de software libre: catedral vs. bazar IX

10 ÍNDICE GENERAL ÍNDICE GENERAL Tema 8: Herramientas de Desarrollo y Validación Herramientas CASE CVS (Concurrent Versioning System) Entornos de desarrollo de interfaces Material y medios de estudio Estructura de esta Guía Didáctica y libro base En los siguientes capítulos de esta guía de estudio se detallan los contenidos con la información que el alumno de educación a distancia necesita para poder estudiar la asignatura. Al principio de cada capítulo se incluye un Tutorial previo con los elementos que describen el contexto, conocimiento previo, objetivos y guía de estudio para ese capítulo. En esta asignatura se utilizará como material básico de estudio para el curso el libro [Pre05] o bien con la edición siguiente [Pre10]: Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-Hill, 2005 Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw-Hill, 2010 Este libro base cubre la mayor parte del temario. En esta guía los contenidos de cada capítulo se sustituirán por la referencia (entre corchetes como [Pre05, sec.... y cap...]) a los apartados del libro base, o bien se incluirán desarrollados directamente en esta guía si no existe una correspondencia directa con el libro base. Se adjuntará la referencia a los contenidos correspondientes a la séptima edición como [Pre10, sec.... y cap...]. Al final de cada capítulo se incluye en esta guía un Tutorial posterior que contiene ejercicios o actividades propuestas adicionales a las que aparecen en el libro base, para que el alumno pueda comprobar si ha logrado los objetivos del capítulo, y también información adicional para la extensión de conocimientos para los alumnos interesados en profundizar en el tema, junto con referencias alternativas sobre los mismos contenidos. Al final de esta guía didáctica se incluye en un apéndice el glosario de términos habituales en la Ingeniería de Software que pueden aparecer en el contenido 1, también se incluye una recopilación de referencias bibliográficas (recomendadas o referidas en el material), más un indice alfabético de referencia para conceptos y términos que aparecen en el material. 1 Además al final del libro base [Pre05] o [Pre10] hay un apéndice que recopila todas las siglas en ingles y castellano usadas profusamente en Ingeniería del Software. X

11 ÍNDICE GENERAL ÍNDICE GENERAL Medios Adicionales Adicionalmente a esta guía, el alumno dispondrá de los medios de comunicación habituales con su Profesor Tutor en el Centro Asociado o a través de las Tutorías Telemáticas (o Cursos Virtuales) de la UNED y también con el Equipo Docente en la Sede Central (en las direcciones, teléfonos y horarios indicados en la Guía de Curso). Esto se complementa con los canales de comunicación y recopilación de información tanto en soporte físico (CDROM) como en línea a través de la página de Internet de la asignatura en la UNED cuarto/admsoft.html. En todos estos medios se incluirá la información particular de referencias y contenidos que se detallan en los capítulos de esta guía, con la ventaja adicional de que en los medios en línea los enlaces de direcciones en Internet y otros materiales se irán ampliando y actualizando más frecuentemente. Se recomienda encarecidamente el seguimiento de los cursos virtuales. Además del libro base (que contiene al final de cada capítulo otras lecturas y fuentes de información ) y del material 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 oficial de la asignatura se hará por medio de las pruebas presenciales habituales de la UNED. Se harán dos pruebas parciales, una para cada cuatrimestre. Las pruebas subjetivas consistirán en una parte de preguntas teóricas breves sobre aspectos relevantes del temario correspondiente, más posiblemente otra parte práctica 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 relacionados con el temario correspondiente. La puntuación correspondiente a cada pregunta se especificará en el enunciado. En la nota final se tendrá en cuenta la compensación entre preguntas dentro de un mismo examen parcial así como la 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 alumno, estas serán totalmente voluntarias (y que por tanto no podrán ser tenidas en cuenta para la puntuación de la nota final), pero se recomienda al alumno su realización para ayudarle a una mejor comprensión de los temas. XI

12 ÍNDICE GENERAL ÍNDICE GENERAL XII

13 Capítulo 1 Contexto de la asignatura en la Ingeniería de Software Tutorial previo Introducción Al inicio de la asignatura es conveniente repasar algunos conceptos generales sobre Ingeniería de Software e introducir los temas que se van a estudiar. En el desarrollo de sistemas software es necesario planificar el uso de recursos y temporizar adecuadamente las diferentes actividades para no sobrepasar los límites económicos y de tiempo dedicados a un proyecto. Es principalmente con este objetivo que se han ido desarrollando el conjunto de técnicas que reciben el nombre de 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 final, mantenibilidad y eficiencia. Una metodología de desarrollo reúne un conjunto de prácticas que se ejercen en las diferentes fases del ciclo de vida de un producto software. Esas fases son: especificación, diseño, codificación, pruebas y mantenimiento. Para dar soporte a las diferentes etapas, y particularmente a las etapas de análisis y diseño, se han definido notaciones de modelado tales como el difundido estándar UML. En este primer capítulo se muestra la utilidad de seguir una metodología en el desarrollo 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 código a partir de los diagramas de esta notación. 1

14 CAPÍTULO 1. CONTEXTO DE LA ASIGNATURA EN LA INGENIERÍA DE SOFTWARE Relación con otros temas Con este tema se pretende asegurar que el alumno dispone de base suficiente para abordar el estudio del resto de la asignatura. Es recomendable el repaso de las 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 conocimientos 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 planificación y gestión de proyectos informáticos. Para ello debe: comprender la necesidad de utilizar una metodología en el desarrollo de aplicaciones, comprender las ventajas e inconvenientes de los diferentes ciclos de vida para discernir cuando es adecuado usar uno u otro, y saber utilizar (en un nivel medio) la notación UML para la especificación y diseño de sistemas. Guía de estudio y esquema Es conveniente realizar una lectura inicial del tema para identificar sus contenidos y repasar los conceptos que considere necesarios, bien acudiendo a textos de asignaturas ya cursadas, bien estudiando las referencias proporcionadas en el apartado de extensión de conocimientos. El capítulo tiene tres partes: La explicación acerca de la necesidad de una metodología se incluye directamente en la adenda y, adicionalmente, se debe estudiar en el libro base [Pre05, cap. 1, y secs. 2.1 y 2.2]. En la séptima edición [Pre10, cap. 1] excluyendo la sección 1.2 y [Pre10, cap. 2, sec. 2.1 hasta 2.1.2] inclusive. Los ciclos de vida. Se da una descripción de cada uno y una lista de ventajas e inconvenientes. También este apartado está en la adenda y se debe extender su estudio en el libro base [Pre05, secs. 3.1 a y 3.7]. En la séptima edición [Pre10, secs. 2.3, 2.4 y 2.9]. La notación de especificación y diseño UML. La mejor forma de asimilar esta parte consiste en estudiar la teoría e ir haciendo pequeños ejemplos. En la adenda 2

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

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

17 Capítulo 2 Fase de especificación Tutorial previo Introducción Una vez que el proyecto ha superado tanto la decisión de desarrollarlo como su estudio de viabilidad (estudiado en otras asignaturas) empieza la fase de especificación, donde se emplean un conjunto de técnicas para captar requisitos y representarlos de un modo útil para la fase posterior de diseño. Se dice que la especificación es la fase importante mientras que el diseño es la difícil. La importancia se debe al alto coste económico y de tiempo que supone un requisito mal entendido. La realización de una buena especificación no es tan sencillo como se puede pensar en un principio, pues muchas veces el propio cliente no tiene una imagen clara del sistema final o surgen nuevas necesidades a mitad del desarrollo. Este 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 especificación creada. Se deben documentar y registrar debidamente todas las actividades anteriores para que en caso de que surja algún problema se pueda seguir su traza hasta los requisitos. Relación con otros temas La extracción, modelado, análisis y representación de requisitos o especificaciones es un problema muy relacionado con la Ingeniería del Conocimiento, por tanto sería conveniente que el alumno repasara los temas correspondientes en las asignaturas previas relacionadas. Es necesario ejercitar la capacidad de abstracción para poder expresar lo que pide el cliente en una representación formal que responda a sus expectativas. 5

18 CAPÍTULO 2. FASE DE ESPECIFICACIÓN Objetivos del tema Es necesario en esta fase separar y entender los conceptos propios de cómo especificar un problema y cómo hacer útil esas especificaciones para posteriores fases del desarrollo. El alumno debe ser capaz de extraer y representar un conjunto de 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 identificar cuáles son los elementos correspondientes a la obtención y el análisis de los requisitos en esos ejemplos para generalizarlo a otros problemas. 1. Obtención de requisitos: se estudia directamente en el material en esta guía. Se deben extender conocimientos en [Pre05, secs. 7.1 a 7.4]. En la séptima edición [Pre10, secs. 5.1 a 5.3]. 2. Construcción del modelo de análisis y negociación de requisitos: este apartado se puede estudiar en [Pre05, secs. 7.6 y 7.7]. En la séptima edición [Pre10, secs. 5.5 y 5.6]. 3. Modelado del análisis y de datos: el contenido se estudiará en [Pre05, secs. 8.1 a 8.3]. En la séptima edición [Pre10, secs. 6.1 y 6.4]. 4. Análisis orientado a objetos: el contenido se estudiará en [Pre05, sec. 8.4]. En la séptima edición no existe explícitamente, pero se puede consultar el punto 2.4 de la adenda. 5. Modelado basado en escenarios: el contenido se estudiará en [Pre05, sec. 8.5]. En la séptima edición [Pre10, secs. 6.2]. 6. Modelado de clases: el contenido se estudiará en [Pre05, sec. 8.7]. En la séptima edición [Pre10, sec. 6.5]. 7. Modelado del comportamiento: el contenido se estudiará en [Pre05, sec. 8.8]. En la séptima edición [Pre10, sec. 7.3]. 8. Análisis estructurado (en el libro se denomina Modelado orientado al flujo ): el contenido se estudiará en [Pre05, sec. 8.6]. En la séptima edición [Pre10, sec. 7.1 y 7.2]. 9. Validación de requisitos: en [Pre05, sec.7.8] junto con el apartado correspondiente en esta guía. En la séptima edición [Pre10, sec. 5.7]. 10. Bases de documentación: en el contenido del apartado correspondiente de esta guía. 6

19 Capítulo 3 Fase de diseño Tutorial Previo Introducción Una vez que se han identificado los requisitos para el problema, es necesario idear y componer la forma de la solución para el problema. El diseño es la fase en la que se estudia el problema, se identifican las características que tendría una solución y se analiza a su vez cada una de esas características. En la fase de diseño es más efectivo utilizar patrones y modelos conocidos para ir resolviendo partes del problema, es decir modularizar el problema y proyectarlo en módulos en la solución. Aunque, el proceso de diseño es en gran medida ad hoc, es decir, no está tan formalizado como las otras fases y por tanto se apoya bastante en la experiencia e intuición de los diseñadores. En este tema se van a proponer las formas de diseño convencionales, una 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 refinando progresivamente. En este caso la atención se focaliza en la forma de procesar los datos. Diseño orientado a objetos: se entiende el sistema como un conjunto de objetos. Para distinguirlos se identifican los tipos de datos, sus operaciones y atributos asociados. Los objetos se comunican entre ellos enviándose mensajes. La validación del diseño comprueba si se siguen las especificaciones del diseño y se cumplen requisitos de calidad. La mejor forma de redactar la documentación consiste en seguir una plantilla de un documento estándar rellenando varias secciones. 7

20 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 modelos 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: descomponer un problema en otros más pequeños, identificar las estructuras de datos necesarias e identificar flujos de datos entre subsistemas y cuáles son las entradas y salidas necesarias para cada subsistema. Objetivos del tema Se deben obtener los conocimientos sobre las técnicas de diseño más efectivas y utilizadas, junto con la comprensión de las diferencias entre esas técnicas que permitan conocer cuál es el método más apropiado en cada situación. Se pretende en este tema introducir los dos tipos de métodos que existen de diseñar un sistema y proporcionar un método genérico para redactar la documentación. Guía de estudio y esquema A la vez que se estudia el contenido teórico del tema es conveniente ir siguiendo los ejemplos propuestos y realizar algunos ejercicios simples con otros problemas, 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]. En la séptima edición [Pre10, cap. 8], excluyendo las secciones y Se incluye en la adenda una pequeña introducción a los patrones y al diseño orientado a objetos, también se puede leer [Pre10, sec y 12.2], pero tan sólo por encima. Diseño arquitectónico. Este apartado se estudiará en [Pre05, cap. 10]. En la séptima edición [Pre10, cap 9]. La sección [Pre05, sec. 10.6] trata el diseño estructurado. 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 y 10.6]. Validación y confirmación del diseño. Este apartado se incluye en la adenda. 8

21 Capítulo 4 Fase de implementación Tutorial Previo Introducción Una vez que se dispone de un diseño para la solución del problema, incluso en una fase temprana o provisional del diseño, ya se puede comenzar a plasmar ese diseño en el código que permita realizarlo o implementarlo. En esta fase el programador recibe las especificaciones del diseño y transforma esas especificaciones, que pueden estar en formatos mezclados formales, semiformales o manuales, en un programa o módulo que las efectúe. Esta tarea de modificación puede estar semi-automatizada en algunos casos o realizarse de forma completamente manual. En cualquier caso se requiere que esa transformación se haga de manera sistemática y coherente. Las particularidades propias de lenguajes de programación concretos se estudian en otras asignaturas y por tanto no se incluirán en este tema. Durante la implementación se escribe el código de la aplicación. Existen una serie de "vicios" en el estilo de codificación que pueden tener como consecuencia que el código sea confuso para terceras personas o para uno mismo pasado un tiempo y en consecuencia difícil de mantener; además, algunas prácticas pueden inducir errores. Es especialmente recomendable para esta parte seguir las recomendaciones del PSP (Personal Software Process). Para realizar el trabajo este debe ser dividido en pequeños módulos que se reparte entre individuos o pequeños grupos atendiendo a un gráfico de dependencias entre tareas y con la idea en mente de paralelizar tanto trabajo como sea posible. A medida que se van haciendo los módulos hay que comprobar que cumplen con una cierta calidad, para ello existen varios tipos de pruebas. En este capitulo se estudia la necesidad de comprobar la ejecución correcta del módulo, por tanto interesan las pruebas que se hacen a nivel de módulo, también llamadas pruebas unitarias. Además 9

22 CAPÍTULO 4. FASE DE IMPLEMENTACIÓN de todo ello hay dos tipos de manuales importantes que hay que producir en esta etapa: el manual de usuario y el manual técnico. Relación con otros temas En este capítulo el alumno debe recordar los conocimientos sobre programación que ha ido adquiriendo a lo largo del estudio de otras asignaturas en la carrera para entender y generalizar la idea de los estilos de codificación y la depuración. Para comprender la problemática asociada a la programación es necesario conocer muy bien al menos un lenguaje de programación y tener alguna experiencia con él. Se puede considerar que con las prácticas de programación de cursos pasados es suficiente. Objetivos del tema Los objetivos de este tema son resaltar la importancia de que la codificación de los programas se haga de una forma ordenada, sistemática y documentada, así como de la necesidad de realizar pruebas y depuración de errores propios de la implementación. Se busca aprender algunas recomendaciones para producir código de calidad, poder 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 codificación con distintos estilos basándose en los mismos ejemplos mostrados, utilizando el lenguaje de programación que mejor conozca o prefiera el alumno. En paralelo con el estudio del tema podría ser de interés que se desarrollara un pequeño proyecto de programación donde se pusieran en práctica los conceptos desarrollados en el capítulo. Para conseguir los objetivos es necesario no sólo memorizar el contenido del capítulo, sino desarrollar hábitos que permitan utilizarlo en la práctica de la programación, lo cual es una tarea que requiere constancia. La redacción de una documentación de calidad no es trivial, son necesarias aptitudes pedagógicas, de estilo de escritura, etc. De todas formas, aunque puede resultar difícil las primeras veces, se puede considerar una tarea burocrática, es decir, al final lo que hay que hacer es seguir un manual de redacción de manuales. Técnicas de depuración. El contenido de este apartado se encuentra en [Pre05, sec. 13.7]. En la séptima edición [Pre10, 17.8]. 10

23 CAPÍTULO 4. FASE DE IMPLEMENTACIÓN Documentación del código. El contenido se encuentra en la adenda. 11

24 CAPÍTULO 4. FASE DE IMPLEMENTACIÓN 12

25 Capítulo 5 Fases de pruebas Tutorial Previo Introducción Este tema incluye en su denominación Fases, en plural, debido a que realmente no hay una única fase de pruebas, sino que las pruebas se van realizado en todas las demás fases. Las pruebas en este caso consisten en la comprobación de que la salida obtenida en cada fase corresponde a las especificaciones de entrada correspondientes. Las 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 codificación, sino también los relativos a la especificación o el diseño, en este sentido se puede distinguir entre verificación y validación. La verificación trata de comprobar si se está construyendo el producto correctamente, la validación si es el producto correcto. Las pruebas que se van haciendo durante el ciclo de vida son: ingeniería del sistema (prueba del sistema), especificación (prueba de validación), diseño (prueba de integración) y codificación (prueba de unidad). Los tipos de pruebas tienen naturaleza diferente y en consecuencia, las técnicas para cada una de ellas son diferentes; también se hará un recorrido por cada una de ellas. Inevitablemente también hay que añadir la correspondiente documentación de las pruebas realizadas. Relación con otros temas Este tema está muy relacionado con los anteriores temas 3 al 5 correspondientes a las fases de requisitos, diseño e implementación, donde se deben distribuir las pruebas correspondientes. Es recomendable, aunque no necesario, haber construido alguna vez un módulo que pruebe a otro dando entradas y comprobando si las salidas que proporciona el módulo probado se corresponden con lo esperado. 13

26 CAPÍTULO 5. FASES DE PRUEBAS Objetivos del tema Se debe extraer una idea clara de que los principios de ingeniería requieren la comprobación y verificación de todos los elementos intermedios en el proceso de desarrollo, en este caso, del software. También se deben conocer técnicas que indiquen los errores que se comenten, tanto de concepción de la tarea a realizar como de las funcionalidades que se implementen y que esta detección ocurra lo antes posible. Guía de estudio y esquema Es conveniente recapitular y repasar los temas anteriores 3 al 5 para ir identificando dentro de cada una de las fases cuáles son las pruebas necesarias para la validación que se explican en este capítulo. Estrategia, técnicas y métodos de prueba clásicos. Este apartado se debe estudiar en [Pre05, secs a 13.6 y 14.1 a 14.6]. En la séptima edición [Pre10, secs a 17.7 y 18.1 a 18.6]. Pruebas orientadas a objetos. Este apartado se debe estudiar en [Pre05, secs a 14.9]. En la séptima edición [Pre10, cap. 19]. Pruebas de entornos especializados. Este apartado se debe estudiar en [Pre05, sec ]. En la séptima edición [Pre10, cap. 18.8]. Patrones de prueba. Este apartado se debe estudiar en [Pre05, sec ]. En la séptima edición [Pre10, sec. 18.9]. Documentación de pruebas. El material está incluido directamente en la adenda. 14

27 Capítulo 6 Fase de entrega y mantenimiento Tutorial Previo Introducción Como etapa final en el ciclo de vida del software se debe realizar la entrega de la primera versión al cliente y considerar las posibles modificaciones posteriores de mantenimiento. Dentro del mantenimiento se deben incluir no sólo las correcciones de errores detectados posteriormente por el cliente, sino también las modificaciones 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 mantenimiento, corregir errores es uno de ellos, otros son adaptar el sistema a nuevos entornos o para proporcionarle nuevas funcionalidades. Es interesante medir el esfuerzo que se gasta en mantenimiento, para lo que también existen sus correspondientes métricas. La documentación describe el sistema desde la especificación de requisitos hasta la aceptación por parte del usuario. Esta información debe estar estructurada y ser legible. Existen herramientas CASE que automatizan esta parte (hasta donde es posible). Relación con otros temas Este tema presenta los elementos finales del ciclo de vida del software y está relacionado con la planificación general del mismo que se presentó en el primer tema y con las fases de desarrollo en los anteriores. 15

28 CAPÍTULO 6. FASE DE ENTREGA Y MANTENIMIENTO Objetivos del tema Determinar cuál es la finalización del desarrollo del software y la extensión de la vida del software desarrollado. Comprender la problemática asociada a mantener una aplicación. Dar una guía de genérica de como realizar el mantenimiento y dar estrategias viables para afrontarlo. Guía de estudio y esquema El contenido del tema es principalmente teórico por lo que la metodología está más orientada al estudio de los contenidos y la reflexión sobre los ejemplos. Finalización del proyecto. Este material se incluye directamente en la adenda. Reingeniería. El material correspondiente a este apartado está en [Pre05, cap. 31]. En la séptima edición [Pre10, cap. 29] exceptuando las secciones 29.1 y Recopilación y organización de documentación. Este apartado está incluido en esta guía didáctica. 16

29 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 definitiva, el manual o guía que realmente se pone en práctica al abordar la construcción de un sistema. Las metodologías de desarrollo puede decirse que consisten en poner orden en todo lo que se ha ido viendo hasta ahora, es decir, utilizan un ciclo de vida determinado y siguen las fases de especificación, diseño, etc. de un modo concreto; algunas incluso están apoyadas por herramientas hechas a medida (por ejemplo el método Rational). El tipo de metodologías que se van a ver están orientadas a objetos que son del tipo que demanda el mercado actualmente y además dan buenos resultados. Se estudia en primer lugar el Proceso Unificado de Rational por su amplia difusión y consideración de metodología tradicional. A continuación se presenta una metodología alternativa muy reciente, llamada Extreme Programming, que tiene características muy interesantes. A continuación se presenta la metodología de planificación, desarrollo y mantenimiento de sistemas de información del Ministerio de las Administraciones Públicas denominada Métrica (versión 3). Finalmente se hace una aproximación hacia nuevos enfoques de desarrollo de software surgidos a raíz del movimiento del Software Libre. Relación con otros temas Es necesario que el alumno haya estudiado previamente los temas 3 al 7, para que comprenda cuáles son los elementos que conforman todo el proceso de desarrollo del 17

30 CAPÍTULO 7. METODOLOGÍAS DE DESARROLLO software. En este tema el alumno podrá retomar también los conceptos globales que se dieron en el primer tema donde encajan las diferentes fases. Objetivos del tema Es necesario que el alumno entienda las relaciones y organizaciones posibles entre las diferentes fases del desarrollo del software que dependen del tipo de entorno y de la aplicación que se desarrolla. En este tema solamente se detallan unas cuantas 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 apartado 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 implementació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 realmente una metodología hasta que se ha puesto en práctica dentro de un grupo de desarrollo. El problema que tiene el aprendizaje de una metodología es que no se puede afrontar fácilmente como un esfuerzo individual (como con el PSP). Proceso unificado de Rational. El material correspondiente es un resumen de esta metodología en la adenda. Método Extreme Programming. Incluido en la adenda. Adicionalmente se puede leer [Pre05, cap. 4]. En la séptima edición [Pre10, cap. 3]. Métrica 3. El material correspondiente es un resumen de esta metodología en la adenda. Métodos de software libre: catedral vs. bazar. Incluido en la adenda. 18

31 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 versiones de ficheros de forma concurrente (CVS) y finalmente algunos entornos genéricos de programación. En el mercado hay varios tipos de herramientas CASE (Computer Aided Software Engineering) para múltiples propósitos: planificación de proyectos, herramientas de análisis y diseño, de documentación, etc. Algunas sólo tratan de un tema concreto y otras abarcan todas las fases de una metodología. CVS es un sistema de almacén de ficheros (repository) centralizado en un servidor. El propósito de introducir este apartado aquí es dar a conocer una herramienta que se usa en el control de configuración. Veremos también la herramienta Subversion. Por otra parte, hoy en día entre el 50 y el 60 por ciento de las líneas de código de una aplicación son relativas a la interfaz de usuario, es lógico por tanto que existan algunas herramientas dedicadas solo a este fin. Las herramientas de desarrollo de interfaces son en realidad herramientas CASE especializadas. Relación con otros temas Aquí conviene recordar tanto las diferentes fases del desarrollo que se han estudiado en los temas 3 al 7, puesto que esas fases reflejarán la especificidad de las herramientas. 19

32 CAPÍTULO 8. HERRAMIENTAS DE DESARROLLO Y VALIDACIÓN De la misma forma algunos entornos estarán influidos por alguna metodología concreta de las estudiadas en el tema 8. Para entender CVS es conveniente conocer un poco el sistema UNIX y tener algunas nociones de teleinformática. Para manejar una herramientas CASE, sobre todo si está pensada para una metodología concreta como por ejemplo Rational Rose, es necesario conocer esa metodología y es imprescindible conocer el UML. Objetivos del tema Es necesario conocer los diferentes elementos y posibilidades que proporcionan los entornos y herramientas informáticas para ayudar precisamente en la construcción de aplicaciones informáticas. Se pretende poder manejar un conjunto básico de comandos de CVS. Dar una introducción a las herramientas CASE y de construcción de interfaces. Guía de estudio y esquema En este tema se hace una revisión somera de algunas de los tipos de herramientas existentes. Es conveniente hacer una primera lectura directa, para después hacer pruebas con algunas de las herramientas que estén disponibles para el alumno, que de esta forma se puede hacer una idea más clara de cuáles son las posibilidades que aporta y cuáles son los ámbitos de aplicación de cada una. Al ser este capítulo de contenido eminentemente práctico, es recomendable probar o jugar con las herramientas recomendadas en el mismo para hacerse una idea de lo que se está hablando. Herramientas CASE. El material de este apartado está incluido en la adenda. Gestión de la configuración. El material de este apartado está incluido en la 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

33 Bibliografía [FW94] [Pre05] [Pre10] Neville J. Ford and Mark Woodroffe. Introducing Software Engineering. Prentice-Hall, Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw- Hill, Roger S. Pressman. Ingeniería de Software: un Enfoque Práctico. McGraw- Hill, [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, [Sch01] [Som98] Stephen R. Schach. Object oriented and classical software engineering. Mc GrawHill, Ian Sommerville. Ingeniería de Software. Addison-Wesley Iberoamericana, [Som01] Ian Sommerville. Software Engineering. Addison-Wesley,