Ciclo Software - Jose Ramon

Anlisis, Diseo y Mantenimiento del Software
Jos Ramn lvarez Snchez y Manuel Arias Calleja Dpto. de Inteligencia Articial - ETSI Informtica - UNED
10 Diciembre 2002
II
ndice general
Gua de estudio de la asignatura Presentacin y objetivos . . . . . . Contexto y conocimientos previos Esquema y resumen de contenidos Material y medios de estudio . . .
VII
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
VII VII VIII IX
1. Contexto de la asignatura en la Ingeniera de Software 1.1. Necesidad de una metodologa . . . . . . . . . . . . 1.1.1. Sistemas . . . . . . . . . . . . . . . . . . . 1.1.2. La crisis del software . . . . . . . . . . . . . 1.1.3. Denicin de metodologa . . . . . . . . . . 1.1.4. Finalidad de una metodologa . . . . . . . . 1.1.5. Taxonoma de las metodologas . . . . . . . 1.2. Ciclo de vida del software . . . . . . . . . . . . . . 1.2.1. Ciclos de vida en cascada . . . . . . . . . . 1.2.2. Modelo de ciclo de vida en espiral . . . . . . 1.2.3. Ciclos de vida orientados a objetos . . . . . . 1.3. Notaciones de especicacin y diseo (UML) . . . . 1.3.1. Introduccin . . . . . . . . . . . . . . . . . 1.3.2. Elementos del lenguaje UML . . . . . . . . 1.3.3. Diagrama de clases . . . . . . . . . . . . . . 1.3.4. Diagrama de objetos . . . . . . . . . . . . . 1.3.5. Diagrama de casos de uso . . . . . . . . . . 1.3.6. Diagrama de estados . . . . . . . . . . . . . 1.3.7. Diagrama de secuencias . . . . . . . . . . . 1.3.8. Diagrama de actividades . . . . . . . . . . . 1.3.9. Diagrama de componentes . . . . . . . . . . 1.3.10. Diagrama de colaboracin . . . . . . . . . . 1.3.11. Diagrama de distribucin . . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
1 2 2 2 2 3 3 4 4 7 9 9 10 10 14 15 15 17 17 19 19 20 20 22 23 23 24 26 26 27 28 28 30 33 34 34 34 42 42 42 42 43 46
2. Descripcin de ejemplos gua 2.1. Ejemplo A: Aplicacin de comercio en Web . . . . . . . . . . . . . . . 2.2. Plantilla de solucin propuesta para el ejemplo A . . . . . . . . . . . . 2.3. Ejemplo B: Gestin de proceso en una fbrica de productos electrnicos 2.4. Plantilla de solucin propuesta para el ejemplo B . . . . . . . . . . . . 2.5. Ejemplo C: Agenda electrnica personal . . . . . . . . . . . . . . . . . 2.6. Plantilla de solucin propuesta para el ejemplo C . . . . . . . . . . . . 2.6.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Fase de requisitos 3.1. Obtencin de requisitos . . . . . . . . . . . 3.1.1. Introduccin . . . . . . . . . . . . 3.1.2. Tcnicas de obtencin de requisitos 3.2. Anlisis de requisitos . . . . . . . . . . . . 3.3. Representacin de requisitos . . . . . . . . 3.4. Anlisis orientado a objetos . . . . . . . . . 3.5. Validacin de requisitos . . . . . . . . . . . 3.6. Bases de documentacin . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
III
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
IV
ndice general
4. Fase de diseo 4.1. Conceptos y elementos del diseo . . . . 4.2. Diseo estructurado . . . . . . . . . . . . 4.3. Diseo orientado a objetos . . . . . . . . 4.4. Validacin y conrmacin del diseo . . . 4.4.1. Revisin del diseo . . . . . . . . 4.4.2. Vericacin del diseo . . . . . . 4.4.3. Validacin del diseo . . . . . . . 4.5. Documentacin: especicacin del diseo Ejercicios y actividades . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
47 48 48 48 48 48 48 49 49 50 51 52 52 55 57 59 65 67 68 68 68 69 71 71 72 72 73 75 75 76 76 76 77 77 77 78 78 79 80 82 83 85 86 86 86 88 88 89 89 90 94 96 97 98 99 99 100 100 101 101
5. Fase de implementacin 5.1. Guas de estilo de codicacin . . . . . . . . . . . 5.1.1. Traduccin del diseo a la implementacin 5.1.2. Estilo de programacin orientado a objetos 5.1.3. Normas para programadores en C . . . . . 5.1.4. Normas para programadores en C++ . . . . 5.1.5. Normas para programadores en Java . . . 5.2. Tcnicas de depuracin . . . . . . . . . . . . . . . 5.3. Documentacin del cdigo . . . . . . . . . . . . . 5.3.1. Tipos de comentarios . . . . . . . . . . . . 5.3.2. Consideraciones generales . . . . . . . . . Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . 6. Fases de pruebas 6.1. Vericacin y validacin a lo largo del ciclo de vida 6.2. Tcnicas y mtodos de prueba . . . . . . . . . . . 6.3. Documentacin de pruebas . . . . . . . . . . . . . Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
7. Fase de entrega y mantenimiento 7.1. Finalizacin del proyecto . . . . . . . . . . . . . . . . . . . . 7.1.1. Aceptacin . . . . . . . . . . . . . . . . . . . . . . . 7.1.2. Informe de cierre del proyecto . . . . . . . . . . . . . 7.1.3. Indicadores del proyecto . . . . . . . . . . . . . . . . 7.2. Planicacin de revisiones y organizacin del mantenimiento . 7.3. Recopilacin y organizacin de documentacin . . . . . . . . 7.3.1. Motivos de la documentacin . . . . . . . . . . . . . 7.3.2. Directrices a seguir para la redaccin de un documento 7.3.3. Tipos de documentos . . . . . . . . . . . . . . . . . . 7.3.4. Manual de usuario . . . . . . . . . . . . . . . . . . . 7.3.5. Manual del sistema . . . . . . . . . . . . . . . . . . . 7.3.6. Manual de mantenimiento . . . . . . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
8. Metodologas de desarrollo 8.1. Introduccin a las metodologas de desarrollo . . . . . . . . . . . . 8.2. Proceso unicado de Rational . . . . . . . . . . . . . . . . . . . . 8.2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2. Las cuatro P: Personas, Proyecto, Producto y Proceso . . 8.2.3. Proceso dirigido por casos de uso . . . . . . . . . . . . . . 8.2.4. Proceso centrado en la arquitectura . . . . . . . . . . . . . 8.2.5. Proceso iterativo e incremental . . . . . . . . . . . . . . . . 8.2.6. Captura de requisitos . . . . . . . . . . . . . . . . . . . . . 8.2.7. Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.8. Implementacin . . . . . . . . . . . . . . . . . . . . . . . . 8.2.9. Prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3. Mtodo extreme programming . . . . . . . . . . . . . . . . . . . . 8.3.1. Historias de usuario . . . . . . . . . . . . . . . . . . . . . . 8.3.2. Plan de publicacin de versiones . . . . . . . . . . . . . . 8.3.3. Tarjetas CRC: Clases, Responsabilidades y Colaboraciones 8.3.4. Planicacin de cada iteracin . . . . . . . . . . . . . . . . 8.3.5. Integracin . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.6. Codicacin de cada unidad . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
ndice general
8.3.7. Recomendaciones generales . . . . . . . . 8.4. Mtrica 3 . . . . . . . . . . . . . . . . . . . . . . 8.4.1. Introduccin . . . . . . . . . . . . . . . . 8.4.2. Objetivos . . . . . . . . . . . . . . . . . . 8.4.3. Estructura . . . . . . . . . . . . . . . . . . 8.4.4. Procesos . . . . . . . . . . . . . . . . . . 8.4.5. Interfaces . . . . . . . . . . . . . . . . . . 8.5. Mtodos de software libre: cathedral vs. bazaar 8.5.1. La catedral . . . . . . . . . . . . . . . . . 8.5.2. El bazar . . . . . . . . . . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102 103 103 103 103 104 112 117 117 117 119 121 122 122 122 122 122 124 124 125 125 127 127 128 128 128 129 129 130 130 130 131 131 133 139 141
9. Herramientas de desarrollo y validacin 9.1. Herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . 9.2. Gestin de la conguracin . . . . . . . . . . . . . . . . . . . 9.2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . 9.2.2. Objetivos de la gestin de conguracin . . . . . . . . 9.2.3. Terminologa . . . . . . . . . . . . . . . . . . . . . . 9.2.4. Control de cambios . . . . . . . . . . . . . . . . . . 9.2.5. Generacin de cambios de estado . . . . . . . . . . . 9.2.6. Plan de gestin de la conguracin . . . . . . . . . . 9.2.7. CVS (Concurrent Versioning System) . . . . . . . . . 9.2.8. Software libre . . . . . . . . . . . . . . . . . . . . . 9.2.9. Sourceforge: Un ejemplo de almacn de software libre 9.3. Entornos de desarrollo de interfaces . . . . . . . . . . . . . . 9.3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . 9.3.2. Componentes . . . . . . . . . . . . . . . . . . . . . 9.3.3. Creacin de interfaces de usuario . . . . . . . . . . . 9.3.4. Metodologa . . . . . . . . . . . . . . . . . . . . . . 9.3.5. Heursticas de usabilidad . . . . . . . . . . . . . . . 9.3.6. Glade . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.7. GTK+ . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.8. Anjuta . . . . . . . . . . . . . . . . . . . . . . . . . Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . A. Glosario de trminos Bibliografa ndice alfabtico
VI
ndice general
Gua de estudio de la asignatura

Equipo docente: Jos R. lvarez Snchez y Manuel Arias Calleja Asignatura: Anlisis, Diseo y Mantenimiento de Software Cdigo: 55-402-4 (4o curso de la titulacin: Ingeniero Informtico) Breve descripcin: Anlisis y denicin de requisitos. Diseo, propiedades y mantenimiento del software.
Presentacin y objetivos
En esta asignatura de Anlisis, Diseo y Mantenimiento del Software se van a estudiar los mtodos, herramientas y elementos que nos permiten analizar y denir los requisitos incluidos en las especicaciones para producir un programa o aplicacin informtica. Este proceso se realizar mediante la utilizacin de tcnicas, metodologas y herramientas que en general se componen de un conjunto de fases comunes: extraccin de requisitos, diseo, implementacin, pruebas y mantenimiento. Para entender cmo se aplican estas fases, se desarrollarn a lo largo del temario unos ejemplos de aplicacin que se utilizarn para ilustrar cmo se aplican y cul es el resultado de estas fases en casos particulares. Una vez que se conocen los elementos del desarrollo, es necesario aglutinar estas fases en forma de metodologas que las aplican con diferentes criterios de secuenciacin. Al mismo tiempo es conveniente conocer algunas de las herramientas disponibles que ayudan en la aplicacin de las tcnicas descritas. Esta asignatura est orientada en una doble vertiente: por un lado est la ingeniera del software clsica y por otro la orientada a objetos, hacindose ms incapi en esta ltima. A lo largo de todos los temas existe un doble tratamiento de estas dos vertientes.
Contexto y conocimientos previos

Contexto acadmico previo
La asignatura objeto de esta gua didctica est incluida en el segundo ciclo de la titulacin de Ingeniero en Informtica en la UNED. La mayor parte de los alumnos que cursen esta asignatura deben haber cursado previamente, en el primer ciclo de la titulacin de Ingeniero Tcnico en Informatica de la UNED (o su equivalente en otras universidades), otras asignaturas relacionadas con la Ingeniera de Software que constituyen una parte muy importante en el contexto de la asignatura. De una parte tenemos las asignaturas obligatorias Programacin I, Programacin II, Programacin III, Estructura de Datos y Algoritmos y Lenguajes de Programacin (junto con las optativas Programacin Concurrente, Programacin Declarativa y Programacin Orientada a la Inteligencia Articial), que deben proporcionar al alumno unas buenas bases sobre programacin en general y que afectan a gran parte de los temas que se tratan en esta asignatura. Esas asignaturas, por tanto, forman el conjunto de conocimiento previo bsico necesario para esta asignatura. Por otra parte, las asignaturas obligatorias Ingeniera del Software, Ingeniera del Software de Gestin ms la optativa Conguracin, Diseo y Gestin de Sistemas Informticos que estn relacionadas ms directamente con la Ingeniera de Software en s misma, y que introducen algunos de los temas de esta asignatura, tambin forman parte de los conocimientos previos que el alumno debe recordar antes de estudiar esta asignatura. Algunos aspectos relativos a las especicaciones funcionales afectan tambin a los temas tratados en esta asignatura. Estos aspectos ms relevantes son la imprecisin o ambigedad del lenguaje natural del que se extraen los requisitos, y los paralelismos que se pueden encontrar comparando las fases de desarrollo (modelado, anlisis, diseo, evaluacin, validacin, etc.) que tambin aparecen en los temas relacionados con la Ingeniera del Conocimiento dentro del rea de la Inteligencia Articial, dando lugar a una reexin sobre las fronteras difusas entre la Ingeniera de Software y la Ingeniera del Conocimiento. Por tanto las asignaturas cercanas a la Ingeniera del Conocimiento tambin estn relacionadas con esta asignatura y en concreto las que se estudian previamente como Introduccin a la Inteligencia Articial y Sistemas Basados en el Conocimiento I. Adicionalmente, y aunque no es estrictamente previa puesto que su estudio est programado tambin en 4 o curso, se debe considerar en este grupo la asignatura Inteligencia Articial e Ingeniera del Conocimiento.
Contexto acadmico simultneo

Simultneamente a esta asignatura se cursa en la titulacin otra asignatura complementaria dentro de la misma materia troncal. Se trata de la asignatura Anlisis y Gestin del Desarrollo del Software (cdigo 554039) que tambin es anual (con el mismo
VII
VIII
ndice general
nmero de crditos) y se estudia en el cuarto curso de la titulacin. Los descriptores generales de esta asignatura simultnea son: Anlisis de aplicaciones. Gestin de conguraciones. Planicacin y gestin de proyectos informticos.. Esa asignatura simultnea est estructurada por cuatrimestres. El primer cuatrimestre est dedicado al Proceso Software Personal (PSP). El objetivo del PSP es adquirir 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 gestin global del proceso de desarrollo software en el que intervienen decenas o centenares de ingenieros. Tambin es un objetivo obtener un software de calidad en los plazos y costes planicados. Sin embargo en este caso es muy importante la problemtica y las tcnicas de trabajo en equipo. Dicha asignatura y la asignatura objeto de esta gua se complementan para dar una visin general del proceso completo de la produccin de software (Ingeniera de Software), tanto desde el punto de vista tcnico del propio software como de su integracin con el equipo humano, igual que en cualquier proceso productivo industrial. Por tanto, es evidente que la relacin con esta asignatura ser muy importante en cuanto al estudio en paralelo de ambas. Ya que los conceptos estudiados en esa asignatura son aplicados o evaluados sobre los conceptos estudiados en la que es objeto de esta gua. Como ya se ha comentado en el apartado anterior, simultneamente se cursa tambin la asignatura Inteligencia Articial e Ingeniera del Conocimiento que est ms relacionada con esta por la va de la frontera entre la Ingeniera del Conocimiento y la Ingeniera del Software.
Contexto acadmico posterior

Los estudios de esta asignatura tienen inuencia sobre los temas tratados en otras asignaturas que se estudian en quinto curso. En particular con las obligatorias Sistemas Informticos I1 , Sistemas Informticos II y Sistemas Informticos III, ms las optativas Aprendizaje y Personalizacin del Software, Diseo de Sistemas de Trabajo Cooperativo (CSCW) y Calidad de Software. Es muy importante notar que, junto con la ltima mencionada antes y la otra asignatura de IS simultnea, esta asignatura tiene gran inuencia sobre el Proyecto de Fin de Carrera que es obligatorio para obtener la titulacin. Evidentemente el desarrollo de un proyecto informtico debe estar basado en un correcto anlisis, diseo y mantenimiento del software, as como de una gestin adecuada del proyecto en s mismo. Adicionalmente a la inuencia ms directa sobre las asignaturas posteriores en la titulacin, esta es una asignatura esencial en el desarrollo posterior de los conocimientos adquiridos por el alumnos durante la carrera y aplicados al ejercicio de la profesin informtica. El diseo y mantenimiento del software tiene un papel fundamental en cualquier desarrollo informtico aplicado en la industria o el comercio y estn en los fundamentos de la gestin de los proyectos informticos aplicados.
Esquema y resumen de contenidos

A continuacin exponemos un resumen de los temas que componen el contenido de la asignatura que se expandir ms adelante. Estos temas se podran agrupar en tres partes que se corresponden con los objetivos presentados anteriormente: Parte I: Introduccin. Temas 1 y 2. Parte II: Fases de Construccin. Temas 3 al 7. Parte III: Metodologas y Herramientas. Temas 8 y 9. La primera parte es preparatoria e incluye la introduccin y ubicacin de los elementos que van a conformar la asignatura, junto con la descripcin de los ejemplos prcticos que se podrn ir aplicando o desarrollando en las distintas fases. En la segunda parte se van describiendo las distintas fases del desarrollo y mantenimiento del software. La parte nal incluye un conjunto de metodologas 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 exmenes parciales se considera que los temas del 1 al 5 pertenecen al primer parcial y los temas del 6 al 9 pertenecen al segundo parcial.
Esquema:
Tema 1: Contexto de la Asignatura en la IS
Necesidad de una metodologa Ciclo de vida del software Notaciones de especicacin y diseo
Tema 2: Descripcin de Ejemplos Gua
Aplicacin de comercio en Web Gestin del control de proceso de una empresa Agenda electrnica personal
Tema 3: Fase de Requisitos

1
Sistemas Informticos I coincide parcialmente en el tiempo (2
cuatrimestre) con esta asignatura.
ndice general
IX
Obtencin de requisitos Anlisis de requisitos Representacin de requisitos Validacin de requisitos Bases de documentacin
Tema 4: Fase de Diseo
Conceptos y elementos del diseo Mtodos de diseo Validacin y conrmacin del diseo Documentacin: especicacin del diseo
Tema 5: Fase de Implementacin
Guas de estilo de codicacin Iteracin de pruebas y depuracin Manuales tcnico y de usuario
Tema 6: Fases de Pruebas
Vericacin y validacin a lo largo del ciclo de vida Tcnicas y mtodos de prueba Documentacin de pruebas
Tema 7: Fase de Entrega y Mantenimiento
Finalizacin del proyecto Planicacin de revisiones y organizacin del mantenimiento Recopilacin y organizacin de documentacin
Tema 8: Metodologas de Desarrollo
Proceso Unicado de Rational Mtodo Extreme Programming Mtodos de software libre: catedral vs. bazar
Tema 9: Herramientas de Desarrollo y Validacin
Herramientas CASE CVS (Concurrent Versioning System) Entornos de desarrollo de interfaces
Material y medios de estudio

Estructura de esta Gua Didctica y libro base
En los siguientes captulos de esta gua de estudio se detallan los contenidos con la informacin que el alumno de educacin a distancia necesita para poder estudiar la asignatura. Al principio de cada captulo se incluye un Tutorial previo con los elementos que describen el contexto, conocimiento previo, objetivos y gua de estudio para ese captulo. En esta asignatura se utilizar como material bsico de estudio el libro [Pre01]: Roger S. Pressman. Ingeniera de Software: un Enfoque Prctico. McGraw-Hill, 2001 Este libro base que cubre la mayor parte del temario2 . En esta gua los contenidos de cada captulo se sustituirn por la referencia (entre corchetes como [Pre01, sec. ... y cap ...]) a los apartados del libro base, o bien se incluirn desarrollados directamente en esta gua si no existe una correspondencia directa con el libro base. Al nal de cada captulo se incluye en esta gua 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 captulo, y tambin informacin adicional para la extensin de conocimientos para los alumnos interesados en profundizar en el tema, junto con referencias alternativas sobre los mismos contenidos. Al nal de esta gua didctica se incluye en un apndice el glosario de trminos habituales en la Ingeniera de Software que pueden aparecer en el contenido3, tambin se incluye una recopilacin de referencias bibliogracas (recomendadas o referidas en el material), ms un indice alfabtico de referencia para conceptos y trminos que aparecen en el material.
2 La 3
edicin anterior (4a ed. de 1997) tambin es utilizable, puesto que los cambios son pequeos. Adems al nal del libro base [Pre01] hay un apndice que recopila todas las siglas en ingles y castellano usadas profusamente en Ingeniera del Software.
ndice general
Medios Adicionales
Adicionalmente a esta gua, el alumno dispondr de los medios de comunicacin habituales con su Profesor Tutor en el Centro Asociado o a travs de las Tutoras Telemticas (o Cursos Virtuales) de la UNED http://virtualdb.uned.es/, y tambin con el Equipo Docente en la Sede Central (en las direcciones, telfonos y horarios indicados en la Gua de Curso). Esto se complementa con los canales de comunicacin y recopilacin de informacin tanto en soporte fsico (CDROM) como en lnea a travs de la pgina de Internet de la asignatura en la UNED http://www.ii.uned.es/superior/cuarto/ADMSoft.html. En todos estos medios se incluir la informacin particular de referencias y contenidos que se detallan en los captulos de esta gua, con la ventaja adicional de que en los medios en lnea los enlaces de direcciones en Internet y otros materiales se irn ampliando y actualizando ms frecuentemente. Adems del libro base (que contiene al nal de cada captulo otras lecturas y fuentes de informacin) y del material incluido en esta gua, tambin se recomiendan como bibliografa complementaria general los libros [Som98] (o la edicin en ingls ms reciente [Som01]) y [RBP 96]:
Ian Sommerville. Ingeniera de Software. Addison-Wesley Iberoamericana, 1998 James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Modelado y diseo orientado a objetos. Metodologa OMT y OMT II. Prentice Hall, 1996
Evaluacin
La evaluacin ocial de la asignatura se har por medio de las pruebas presenciales habituales de la UNED. Se harn dos pruebas parciales, una para cada cuatrimestre. Las pruebas subjetivas consistirn en una parte de preguntas (1 2) tericas breves sobre aspectos relevantes del temario correspondiente, ms otra parte prctica compuesta de 1 2 ejercicios con supuestos prcticos que describirn parcialmente un problema de diseo de software sobre el cual se pedir al alumno completar o extender algunos aspectos relacionados con el temario correspondiente. La puntuacin correspondiente a cada pregunta se especicar en el enunciado. En la nota nal se tendr en cuenta la compensacin entre preguntas dentro de un mismo examen parcial as como la compensacin de ambos parciales. En algunos captulos puede haber propuestas para realizar prcticas por el propio alumno, estas sern totalmente voluntarias (y que por tanto no podrn ser tenidas en cuenta para la puntuacin de la nota nal), pero se recomienda al alumno su realizacin para ayudarle a una mejor comprensin de los temas.
Captulo 1
Contexto de la asignatura en la Ingeniera de Software

Tutorial previo
Introduccin
Al inicio de la asignatura es conveniente repasar algunos conceptos generales sobre Ingeniera de Software y plantear la estructura de los temas que se van a estudiar. En este captulo se muestra la utilidad de seguir una metodologa en ese desarrollo preparando los temas siguientes. A continuacin se detallan los aspectos ms generales del ciclo de vida del software planteando las distintas fases del desarrollo que se extendern en los siguientes captulos de la parte II (temas 3 al 7). Finalmente, se presentan los aspectos de notacin y representacin a utilizar a lo largo de las distintas fases. En el desarrollo de un sistema informtico del tipo que sea es necesario hacer una planicacin de cara a rentabilizar el esfuerzo. Para ello algunas empresas y universidades han desarrollado a lo largo del tiempo varias metodologas. Todas ellas tienen en comn la intencin de automatizar el proceso de desarrollo para que el producto resultante cumpla una serie de requisitos (tiempo de desarrollo, calidad, eciencia, precio, mantenibilidad). Las metodologas dividen la realizacin de un proyecto en una serie de etapas que son: especicacin, diseo, codicacin, pruebas y mantenimiento. Las distintas formas de ordenar el esfuerzo a lo largo del tiempo son los ciclos de vida. Por otra parte, para realizar las etapas de anlisis y diseo se han desarrollado notaciones como el UML, muy usada actualmente y soportada por varias herramientas CASE capaces de generar cdigo a partir de los diagramas de esta notacin.
Relacin con otros temas

Este tema intenta garantizar que el alumno recuerda los elementos necesarios, que debe haber adquirido en asignaturas previas, relativos a la organizacin del desarrollo del software, para poder plantear una base comn sobre la que comenzar el desarrollo de la asignatura. Por lo tanto se debe acudir a las asignaturas previas de la titulacin en las cuales se comienzan a estudiar las bases de la Ingeniera del Software y el desarrollo de programas. En particular Al mismo tiempo este tema ser muy importante en el resto de la asignatura por su visin general de las diferentes fases y de su coordinacin en metodologas. Para hacerse una composicin de lugar sobre lo que se habla en este captulo y en la asignatura en general es recomendable haber desarrollado algn proyecto en un lenguaje de programacin.
Objetivos del tema

Este tema es preparatorio para el resto de la asignatura. El alumno debe comprobar que tiene los conocimientos previos necesarios para afrontar con garantas el resto de la asignatura, entendiendo la estructura general del desarrollo del software, as como las implicaciones y relaciones con la planicacin y gestin de los proyectos informticos. Para ello debe: comprender la necesidad de utilizar una metodologa 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 poder utilizar la notacin UML en la especicacin y diseo de un sistema.
Gua de estudio y esquema

Es conveniente realizar una lectura inicial del tema para comprobar cules son los aspectos que se deben conocer en el mismo. Posteriormente se debe acudir a repasar los conceptos previos necesarios en las referencias dadas en el apartado de extensin de conocimientos o en las de las asignaturas previas en las cuales se hayan estudiado. El captulo tiene tres partes: La explicacin acerca de la necesidad de una metodologa se puede considerar terica. Este apartado se incluye directamente en esta gua y, adicionalmente, se pueden estudiar en el libro base [Pre01, cap. 1, y secs. 2.1 y 2.2]. 1
Para los ciclos de vida se da una descripcin de en qu consiste cada uno y una lista de ventajas e inconvenientes. Tambin este apartado est en esta gua y, se puede aadir el estudio en el libro base [Pre01, secs. 2.3 a 2.12]. Notaciones de especicacin y diseo (UML): La mejor forma de asimilar esta parte consiste en ir haciendo ejemplos. En esta gua se incluye este apartado a estudiar junto con el apartado del libro base [Pre01, sec. 22.5]. Tambin puede ser conveniente una lectura somera del captulo 20 en el mismo [Pre01, cap. 20] (o bien [Pre97, cap. 19] en la 4 a edicin).
1.1. Necesidad de una metodologa

El proceso de construccin del software requiere, como cualquier otra ingeniera, identicar las las tareas que se han de realizar sobre el software y aplicar esas tareas de una forma ordenada y efectiva. Adicionalmente y aunque no es el objeto principal de esta asignatura, el desarrollo del software se debe realizar por un conjunto coordinado de personas simultneamente, y por lo tanto sus esfuerzos deben estar dirigidos por una misma metodologa que permita estructurar las diferentes fases del desarrollo. Por lo tanto, en temas posteriores, primero se explicarn en detalle esas fases y ms adelante las metodologas usuales que las organizan y aglutinan. En esta asignatura se har especial nfasis en los temas ms relacionados con el anlisis, diseo y mantenimiento del software, dejando de forma ms supercial los temas especcos de la organizacin, gestin del proyecto en cuanto a la distribucin de medios y tareas entre el grupo de personas a cargo del sistema completo, ya que estos ltimos temas son objeto de otras asignaturas en la misma titulacin.
1.1.1. Sistemas
La Ingeniera de Sistemas es el contexto genrico en el que se pueden situar las herramientas y metodologas usadas para crear sistemas. Un sistema puede estar formado por subsistemas de diferentes tipos. La ingeniera de sistemas es el primer paso que se da y proporciona una visin global del sistema en su conjunto, posteriormente, se analiza cada subsistema con la rama de la ingeniera adecuada. Una de esas ramas es la ingeniera del software. La Ingeniera del Software trata, segn Bauer [Bau72], del establecimiento de los principios y mtodos de la ingeniera, orientados a obtener software econmico, que sea able y funcione de manera eciente sobre mquinas reales. El sistema es un conjunto de elementos que cooperan entre s para proporcionar una funcionalidad. En el caso de un sistema informtico hay dos tipos de elementos: Hardware y Software.
1.1.2. La crisis del software

Desde el momento en el que se introdujeron computadores con capacidad para soportar aplicaciones de tamao considerable (aos 60) empez a ocurrir que las tcnicas de desarrollo para los hasta entonces pequeos sistemas dejaron progresivamente de ser vlidas. Estas tcnicas consistan bsicamente en codicar y corregir (code-and-x) que consiste en lo siguiente: No existe necesariamente una especicacin del producto nal, en su lugar se tienen algunas anotaciones sobre las caractersticas generales del programa. Inmediatamente se empieza la codicacin y simultneamente se va depurando. Cuando el programa cumple con las especicaciones y parece que no tiene errores se entrega. Las ventajas son que no se gasta tiempo en planicacin, gestin de los recursos, documentacin, etc. Si el proyecto es de pequeo tamao y lo realiza una sola persona no es un mal sistema para producir un resultado pronto. Hoy en da es un mtodo de desarrollo an muy en boga, sobre todo por parte de los alumnos de la carrera de informtica cuando realizan prcticas de programacin, que son de pequeo tamao. Las consecuencias fueron: 1. El costo era mucho mayor de lo originalmente previsto. 2. El tiempo de desarrollo tambin exceda lo proyectado. 3. La calidad del cdigo producido era imprevisible y en promedio baja. Aunque se han desarrollado tcnicas para paliar estos problemas, hoy en da an se considera normal que una aplicacin rebase sus proyecciones iniciales de tiempo y dinero y que se descubran bugs (errores informticos) en su ejecucin. Esto se debe a que todava no se aplica de un modo sistemtico la ingeniera del software durante el desarrollo.
1.1.3. Denicin de metodologa

En la literatura sobre este tema existen muchas deniciones sobre lo que es una metodologa. Ms o menos todas ellas coinciden en que debera tener al menos las siguientes caractersticas: 1. Dene como se divide un proyecto en fases y las tareas a realizar en cada una. 2. Para cada una de las fases est especicado cuales son las entradas que reciben y las salidas que producen. 3. Tienen alguna forma de gestionar el proyecto. Teniendo esto en cuenta establecemos la siguiente denicin: Metodologa es un modo sistemtico de producir software.
1.1 Necesidad de una metodologa
1.1.4. Finalidad de una metodologa

Los atributos deseables en el producto nal son: 1. Adecuacin: El sistema satisface las expectativas del usuario. 2. Mantenibilidad: Facilidad para realizar cambios una vez que el sistema est funcionando en la empresa del cliente. 3. Usabilidad: Es el grado de dicultad en aprender a manejar el sistema por parte de un usuario que no tiene por que ser programador. Irnicamente se puede decir que este atributo es inversamente proporcional a la resistencia al cambio. 4. Fiabilidad: Es la capacidad de un sistema de funcionar correctamente durante un tiempo dado. La diferencia con la correccin es que aqu interesa el tiempo, es decir, no se trata del nmero absoluto de defectos en el sistema sino de los que se maniestan en un intervalo de tiempo. Interesan sobre todo: a) MTBF: Mean Time Between Failures (Tiempo medio entre fallos) b) Disponibilidad: Probabilidad de que el sistema est funcionando en un instante dado. 5. Correccin: Densidad de defectos mnima. 6. Eciencia: El sistema es capaz de realizar su tarea con el mnimo consumo de recursos necesario.
1.1.5. Taxonoma de las metodologas

Existen dos grupos de metodologas en funcin de la mentalidad con la que se aborda el problema: metodologa estructurada o metodologa orientada a objetos. Metodologa estructurada Es la primera aproximacin al problema. Est orientada a procesos, es decir, se centra en especicar y descomponer la funcionalidad del sistema. Se utilizan varias herramientas: Diagramas de ujo de datos (DFD): Representan la forma en la que los datos se mueven y se transforman. Incluye:
Procesos Flujos de datos Almacenes de datos
Los procesos individuales se pueden a su vez descomponer en otros DFD de nivel superior. Especicaciones de procesos: Es lo que se escribe para uno de los procesos denidos en el DFD cuando no se puede descomponer ms. Puede hacerse en pseudocdigo, con tablas de decisin o en un lenguaje de programacin. Diccionario de datos: Son los nombres de todos los tipos de datos y almacenes de datos junto con sus deniciones. La informacin que se incluye en l se puede ver en [Pre01, sec. 12.7]. Diagramas de transicin de estados: Modelan procesos que dependen del tiempo Diagramas entidad-relacin: Los elementos del modelo E/R se corresponden con almacenes de datos en el DFD. En este diagrama se muestran las relaciones entre dichos elementos Los lenguajes de programacin tambin reejan esta dicotoma que existe entre la metodologas, as existen lenguajes para la programacin estructurada. Los ms famosos son: Cobol, Fortran, C, Pascal y Modula 2. Metodologa orientada a objetos Es una aproximacin posterior.La orientacin a objetos al ser ms reciente cuenta con mayor nmero de adeptos y es previsible que termine sustituyendo a la anterior. Adems cuenta con una serie de ventajas: 1. Estn basadas en componentes, lo que signica que es ms fcil reutilizar cdigo hecho por terceras personas. 2. Es fcil de mantener debido a que los cambios estn ms localizados. La mentalidad que subyace al diseo estructurado es: Cmo se puede dividir el sistema en partes ms pequeas que puedan ser resueltas por algoritmos sencillos y qu informacin se intercambian?. En el diseo orientado a objetos la idea es sin embargo: Cuales son los tipos de datos que hay que utilizar, que caractersticas tienen y como se relacionan?. La orientacin a objetos supone un paradigma distinto del tradicional (no necesariamente mejor o peor) que supone focalizar la atencin en las estructuras de datos. El concepto de objetos tuvo sus orgenes en la inteligencia articial como un modo de representacin del conocimiento. El primer lenguaje orientado a objetos fue Simula67, desarrollado por Kristen Nggaard y OleJohan Dahl en el centro de clculo noruego, pero el que se considera el primer lenguaje orientado a objetos puro fue Smaltalk, donde todos los elementos del lenguaje son objetos. El lenguaje C++ fue una ampliacin de C para que soportara objetos, result muy eciente y tambin muy complejo. Java es otro lenguaje orientado a objetos derivado del C++ pero con la idea de ser ms sencillo.
Objetos y clases Un objeto consta de una estructura de datos y de una coleccin de mtodos (antes llamados procedimientos o funciones) que manipulan esos datos. Los datos denidos dentro de un objeto son sus atributos. Un objeto solo puede ser manipulado a travs de su interfaz, esto es, una coleccin de funciones que implementa y que son visibles al exterior. Las clases y objetos tienen muchas caractersticas: 1. Herencia: Es una relacin de generalizacin, cuando varias clases comparten caractersticas comunes, estas se ponen en una clase antecesora. 2. Polimorsmo: Es la capacidad de un objeto de presentar varios comportamientos diferentes en funcin de como se utilice, por ejemplo, se pueden denir varios mtodos con el mismo nombre pero diferentes argumentos. Durante la etapa de anlisis se identican los objetos del dominio del problema. En el diseo se denen cuales son las caractersticas de los objetos.
1.2. Ciclo de vida del software

Al igual que en otros sistemas de ingeniera, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en funcin de cuales sean las caractersticas del proyecto, se congurar el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especicacin y anlisis de requisitos, diseo del sistema, implementacin del software, aplicacin y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentacin de todos los elementos y especicaciones en cada fase. Dado que esta tarea siempre estar inuida por la fase del desarrollo en curso, se explicar de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software. Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de vida son: 1. Anlisis: Construye un modelo de los requisitos 2. Diseo: A partir del modelo de anlisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario. 3. Codicacin: Construye el sistema. La salida de esta fase es cdigo ejecutable. 4. Pruebas: Se comprueba que se cumplen criterios de correccin y calidad. 5. Mantenimiento: En esta fase, que tiene lugar despus de la entrega se asegura que el sistema siga funcionando y adaptndose a nuevos requisitos. Las etapas constan de tareas. La documentacin es una tarea importante que se realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida segn se muestra en la gura 1.1.
Entrada
Etapa
Salida
Figura 1.1: Etapa genrica Algunos autores dividen la fase del diseo en dos partes: Diseo global o arquitectnico y diseo detallado. En el primero se transforman los requisitos en una arquitectura de alto nivel, se denen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la documentacin y se planica la integracin. En el detallado para cada mdulo se rena el diseo, se denen los requisitos del mdulo y su documentacin. Las formas de organizar y estructurar la secuencia de ejecucin de las tareas en las diferentes fases de cada uno de los mtodos puede dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuacin realizan estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.
1.2.1. Ciclos de vida en cascada

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniera. Es el primero de los propuestos y el ms ampliamente seguido por las organizaciones (se estima que el 90 % de los sistemas han sido desarrollados as). La estructura se muestra en la gura 1.2.
1.2 Ciclo de vida del software

Analisis
Diseo
Codificacion
Pruebas
Mantenimiento
Figura 1.2: Ciclo de vida en cascada Descripcin Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modicaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseo, lo cual signica que se harn los cambios necesarios en la codicacin y se tendrn que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Despus de cada etapa se realiza una revisin para comprobar si se puede pasar a la siguiente. Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento especco. Idealmente, cada fase podra hacerla un equipo diferente gracias a la documentacin generada entre las fases. Los documentos son: Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document). Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document) Codicacin: A partir del S.D.D. produce mdulos. En esta fase se hacen tambin pruebas de unidad. Pruebas: A partir de los mdulos probados se realiza la integracin y pruebas de todo el sistema. El resultado de las pruebas es el producto nal listo para entregar. Ventajas La planicacin es sencilla. La calidad del producto resultante es alta. Permite trabajar con personal poco cualicado. Inconvenientes Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente denidas las especicaciones del sistema, o puede ser que surjan necesidades imprevistas. Si se han cometido errores en una fase es difcil volver atrs. No se tiene el producto hasta el nal, esto quiere decir que:
Si se comete un error en la fase de anlisis no lo descubrimos hasta la entrega, con el consiguiente gasto intil de recursos. El cliente no ver resultados hasta el nal, con lo que puede impacientarse .
No se tienen indicadores ables del progreso del trabajo (sndrome del 90 %). 1 Es comparativamente ms lento que los dems y el coste es mayor tambin. Tipos de proyectos para los que es adecuado Aquellos para los que se dispone de todas las especicaciones desde el principio, por ejemplo, los de reingeniera. Se est desarrollando un tipo de producto que no es novedoso. Proyectos complejos que se entienden bien desde el principio.
1 Consiste en creer que ya se ha completado el 90 % del trabajo, pero en realidad queda mucho ms porque el 10 % del cdigo da la mayor parte de los problemas
Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahora veremos algunas. Ciclo de vida en V Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstraccin de cada una. Una fase adems de utilizarse como entrada para la siguiente, sirve para validar o vericar otras fases posteriores. Su estructura est representada en la gura 1.3.
Validacion
Analisis Nivel de abstraccion Diseo
Mantenimiento
Verficacion
Pruebas
Codificacion
Tiempo
Figura 1.3: Ciclo de vida en V
Ciclo de vida tipo sashimi Segn el modelo en cascada puro una fase solo puede empezar cuando ha terminado la anterior. En este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseo se comienza a implementar. El nombre sashimi deriva del modo del estilo de presentacin de rodajas de pescado crudo en Japn. Una ventaja de este modelo es que no necesita generar tanta documentacin como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los problemas planteados son: Es an ms difcil controlar el progreso del proyecto debido a que los nales de fase ya no son un punto de referencia claro. Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir inconsistencias. La fase de concepto consiste en denir los objetivos del proyecto, benecios, tipo de tecnologa y el tipo de ciclo de vida. El diseo arquitectnico es el de alto nivel, el detallado el de bajo nivel. En la gura 1.4 se ha representado la estructura del ciclo de vida sashimi.
Concepto Analisis Diseo arquitectonico Diseo detallado Codificacion Pruebas
Figura 1.4: Ciclo de vida sashimi
Ciclo de vida en cascada con subproyectos Si una vez que se ha llegado al diseo arquitectnico, se comprueba que el sistema se divide en varios subsistemas independientes entre s, sera razonable suponer que a partir de ese punto cada uno se puede desarrollar por separado y en consecuencia en paralelo con los dems. Cada uno tendr seguramente fechas de terminacin distintas. Una vez que han terminado todos se integran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a ms gente trabajando en paralelo de forma eciente. El riesgo es que existan interdependencias entre los subproyectos.
1.2 Ciclo de vida del software
Ciclo de vida en cascada incremental En este caso se va creando el sistema aadiendo pequeas funcionalidades. Cada uno de los pequeos incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. La ventaja de este mtodo es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la deteccin de requisitos se encuentran tarde. Hay dos partes en el ciclo de vida, similares al anterior. Por un lado est el anlisis y el diseo global. Por otra parte estn los pequeos incrementos, con las fases de diseo detallado, codicacin y mantenimiento. En la gura 1.5 se puede ver su estructura.
Analisis
Diseno preliminar
Iteracion 1
Iteracion n
Diseno detallado
Diseno detallado
Codificacion y pruebas
. . . .
Codificacion y pruebas
Mantenimiento
Mantenimiento
Figura 1.5: Cascada incremental
Ciclo de vida en cascada con reduccin de riesgos Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en cascada es que si se entienden mal los requisitos esto slo se descubrir cuando se entregue el producto. Para evitar este problema se puede hacer un desarrollo iterativo durante las fases de anlisis y diseo global. Esto consistira en: 1. Preguntar al usuario. 2. Hacer el diseo global que se desprende del punto 1. 3. Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y volver con ello al punto 1 para identicar ms requisitos o corregir malentendidos. El resto es igual al ciclo de vida en cascada.
1.2.2. Modelo de ciclo de vida en espiral

Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseo, errores en la implementacin, etc. Un representacin tpica de esta estructura se muestra en la gura 1.6. En cada iteracin Boehm recomienda recopilar la siguiente lista de informaciones: Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc. Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista
Caractersticas del producto.
Analisis de riesgos Analisis de riesgos Analisis de riesgos Analisis de riesgos Plan del ciclo de vida Plan de requisitos Prototipo 4 Prototipo 3
Prototipo 2 Prototipo 1 Simulaciones, Modelos, Benchmarks
Concepto de operacion Requisitos Sw. Validacion de requisitos Diseno Producto Sw. Diseno detallado Codigo Pruebas unitarias
Plan de desarrollo
Plan de integracion Verificacion y validacion y pruebas del diseno Planificar fases siguientes Imple mentacion
Prueba de aceptacion
Integracion y prueba
Figura 1.6: Ciclo de vida en espiral Formas de gestionar el proyecto.
Restricciones:
Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc. Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
Riesgos: Lista de riesgos identicados. Resolucin de riesgos: La tcnica ms usada es la construccin de prototipos. Resultados: Son lo que realmente ha ocurrido despus de la resolucin de riesgos. Planes: Lo que se va a hacer en la siguiente fase. Compromiso: Decisiones de gestin sobre como continuar. Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, tambin se verica que funciona correctamente. El propio cliente evala el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo. Ventajas No necesita una denicin completa de los requisitos para empezar a funcionar. Al entregar productos desde el nal de la primera iteracin es ms fcil validar los requisitos. El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn bien). El riesgo de sufrir retrasos es menor, ya que al identicar los problemas en etapas tempranas hay tiempo de subsanarlos. Inconvenientes Es difcil evaluar los riesgos. Necesita de la participacin continua por parte del cliente. Cuando se subcontrata hay que producir previamente una especicacin completa de lo que se necesita, y esto lleva tiempo.
1.3 Notaciones de especicacin y diseo (UML)
Dnde es adecuado Sistemas de gran tamao. Proyectos donde sea importante el factor riesgo. Cuando no sea posible denir al principio todos los requisitos.
1.2.3. Ciclos de vida orientados a objetos

Los tipos de ciclos de vida que se han visto hasta ahora son relativos al anlisis y diseo estructurados, pero los objetos tienen una particularidad, y es que estn basados en componentes que se relacionan entre ellos a travs de interfaces, o lo que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos. Adems, hoy en da la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida tpico en una metodologa de diseo orientado a objetos es iterativo e incremental. En este texto slo veremos un tipo de ciclo de vida orientado a objetos, que es adems el ms representativo, el modelo fuente. Modelo fuente Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientacin a objetos y posiblemente el ms seguido. Un proyecto se divide en las fases: 1. Planicacin del negocio 2. Construccin: Es la ms importante y se divide a su vez en otras cinco actividades Planicacin Investigacin Especicacin Implementacin Revisin 3. Entrega La primera y la tercera fase son independientes de la metodologa de desarrollo orientado a objetos. Adems de las tres fases, existen dos periodos: 1. Crecimiento: Es el tiempo durante el cual se construye el sistema 2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planica igual que el periodo anterior, es decir, con las fases de Planicacin del negocio, Construccin y Entrega. Cada clase puede tener un ciclo de vida slo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e iterativo. En la gura 1.7 se muestra un esquema de este tipo de ciclo de vida.
Madurez Periodos Crecimiento Mejora 1 Mejora 2
Fases
Planificacion ConstruccionLiberacion del negocio
Actividades
Planificacion Investigacion Especificacion Implement. Revision
Figura 1.7: Ciclo de vida fuente
1.3. Notaciones de especicacin y diseo (UML)

Una parte esencial de todas las tareas del desarrollo del software, y de las especicaciones de requisitos y diseo en particular, es la utilizacin de una notacin que permita representar los aspectos esenciales de las mismas y que al mismo tiempo permita una mecanizacin parcial del proceso de desarrollo. Dado que en la actualidad la fase de implementacin se suele realizar con tecnologas orientadas a objetos y que adicionalmente este tipo de enfoque tambin es aplicable en otras fases del desarrollo, es importante que el alumno conozca, al menos los principios bsicos, de las notaciones orientadas a objetos, y en especial la ms extendida ltimamente, como es el UML (Unied Modelling Language, Lenguaje Unicado de Modelado).
10
1.3.1. Introduccin
Modelos Cuando alguien intenta resolver un problema complejo lo primero que hace es estudiarlo: Ver cuales son sus componentes, establecer relaciones entre las partes, comprender sus propiedades e imaginar como funciona de un modo dinmico. Pero como la mente humana es perezosa, no estarn todos los detalles, slo los esenciales. Esto no es importante, con tal de que la representacin mental funcione igual que el problema real los detalles se pueden abstraer. El resultado de este proceso es un modelo. Por tanto, modelo es una representacin de la realidad donde se abstrae lo no esencial. Para un mismo sistema se puede establecer ms de un modelo diferente en funcin de que aspecto interese resaltar o del nivel de detalle que se quiera conseguir. UML son las siglas de Unied Modeling Language y como su nombre indica es un lenguaje de modelado, es decir, su utilidad est en que sirve para expresar modelos. No es nada ms que eso, no indica cmo se debe hacer el anlisis o el desarrollo orientados a objetos y en consecuencia, no es una metodologa de desarrollo, tan solo es una notacin, ahora bien, es la notacin que se ha convertido en el estndar de facto de la mayor parte de las metodologas de desarrollo orientado a objetos que existen hoy en da. Su utilidad est en la especicacin, visualizacin, construccin y documentacin. De esta frase, la palabra visualizacin es la ms importante; UML es un lenguaje basado en diagramas y est pensado para entrar por los ojos, tanto a los desarrolladores como a los clientes. Este captulo no pretende ser exhaustivo, debe entenderse ms bien como una introduccin inicial abreviada. Historia Grady Booch, Jim Rumbaugh e Ivar Jacobson (los tres amigos) desarrollaron las tres metodologas de desarrollo orientado a objetos ms seguidas de la industria. Rumbaugh con su OMT (Object Modeling Technique) y Booch unicaron sus mtodos, de ello naci la primera versin del UML en el ao 1994. Posteriormente, Jacobson, creador del mtodo OOSE (Object-Oriented Software Engineering) se uni al grupo. Actualmente el UML va por la versin 1.3 y la 2.0 est en preparacin.
1.3.2. Elementos del lenguaje UML

A continuacin se vern una serie de elementos notacionales pero sin entrar en detalle en la esencia de lo que es el concepto de cada cosa (que se da por supuesto), sino solo en la forma de dibujarlo en UML. Clase Es el grco ms importante. En la gura 1.8 podemos ver que tiene cuatro partes que se disponen de arriba a abajo en el orden siguiente:
Nombre de la clase Estereotipo Ascensor <<Info de identificacion>> marca:String = SYBSA modelo:String numeroSerie:String <<Info de posicionamiento>> pisoActual:integer estadoActual:String Clase abreviada Publico Alcance Protegido Privado Restriccion {estadoActual=subiendo, bajando, parado Valor por defecto
...
+ Mover(int,int) # CalcularRuta(integer) AlarmaExcesoPeso()
...
Mueve gente de un piso a otro Responsabilidades Calcula ruta que optimiza tiempo
Figura 1.8: Plantilla para una clase en UML 1. Nombre: Si aparece en cursiva la clase es abstracta. 2. Atributos: Pueden mostrar mucha informacin.
11
a) Tipo: Atributo:Tipo b) Valor predeterminado: Atributo:Tipo=Valor Atributo=Valor c) Restricciones: Las restricciones se pueden poner como se ha visto en el grco, pero UML cuenta con un mtodo an ms formal que es el lenguaje OCL. d) Alcance: Un atributo puede ser pblico(+), protegido(#) o privado(-). e) mbito: Hay dos tipos Instancia: Cada objeto tiene su propio valor. Archivador: Solo hay un valor en todas las instancias de una clase (como las variables static en Java). Estos atributos aparecen subrayados. Toda esta informacin es opcional, de hecho la mayora de las veces se pone slo el nombre del atributo. 3. Mtodos: Al igual que los atributos tambin pueden especicar su alcance o mbito. Adems pueden indicar el tipo de los argumentos que reciben y el tipo del valor devuelto. Tanto si tienen parmetros como si no deben llevar un parntesis abierto y otro cerrado al nal del nombre. 4. Responsabilidades: Es una descripcin de lo que hace la clase en su conjunto. Est informacin casi nunca est en los diagramas. La informacin que se ha puesto en la gura de ejemplo es mucho ms de la que se suele mostrar, una clase puede representarse con un simple rectngulo con su nombre, como se ve en la gura 1.9.
Nombre de la clase
Figura 1.9: La clase ms sencilla posible Adems se puede omitir parte de la informacin de un apartado. Los puntos suspensivos que hay en el ejemplo al nal de las secciones de atributos y mtodos indican que la clase est abreviada, o lo que es lo mismo, faltan atributos y mtodos. Slo se pone lo necesario para expresar la idea del diagrama. Los estereotipos son una forma de introducir nuevos trminos sobre el vocabulario propio de un dominio. Los paquetes son agrupaciones de clases relacionadas de alguna forma entre s (su representacin se ilustra en la gura 1.10). Las notas son un texto explicativo de algn elemento y se representa de la forma indicada en la gura 1.11.
AWT
Button
Canvas
Label
Checkbox
Figura 1.10: Un paquete que se puede encontrar en Java
Ascensor
No se tiene en cuenta el coeficiente de seguridad del cable
Figura 1.11: Una anotacin relativa a una clase
Objetos Los objetos son instancias de clases (sus atributos tienen valores especcos) y, como se indica en la gura 1.12, se representan poniendo el nombre de la instancia a la izquierda, dos puntos y el nombre de la clase de la que deriva a la derecha.
12
AscensorA : Ascensor
Figura 1.12: Smbolo en UML de un objeto Relaciones Las clases no estn aisladas, entre ellas pueden relacionarse de muchas maneras. La representacin bsica de las relaciones es una lnea (con otros elementos adicionales como echas, rombos, texto, etc.) entre las clases relacionadas. Asociaciones Es una relacin conceptual, que no es inherente a la naturaleza de las clases, sino al papel que juegan en el modelo y especica que las instancias de una clase estn conectadas con las de otra. No es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Como se puede ver en la gura 1.13, la relacin tiene un nombre que indica en que consiste y su direccin, indicada con un tringulo relleno. Se puede indicar adems (de forma opcional) cual es el papel (rol) que representa cada una de las partes en la relacin.
Nombre de la relacion
Empresa
Trabaja para Empleador Empleado
Programador
Papel de cada parte
Figura 1.13: Ejemplo de una asociacin Es posible que dos clases estn relacionadas entre s por ms de una relacin en ambos sentidos o que una clase est relacionada con muchas. Se dice que una relacin es reexiva cuando una clase est asociada consigo misma. Es posible que una instancia de una clase pueda estar relacionada con un nmero variable de instancias de otra. La notacin para expresar esa multiplicidad es exible: 1. Nmeros concretos. Un nmero exacto: A. Por ejemplo: 5 (signica exactamente 5). 2. Intervalos. Entre A y B, ambos incluidos: A..B. Por ejemplo: 2..6 (es entre 2 y 6). 3. Asterisco. El smbolo * signica muchos. Si est en un intervalo se pone en el extremo superior. A..* se lee: A o ms. Por ejemplo: 3..* (es 3 o ms). Si el * est solo signica que puede ser un nmero cualquiera, cero incluido. 4. Combinacin de los elementos anteriores: Por ejemplo: 1..4,6,9..* (que signica entre 1 y 4, 6, 9 ms de 9, es decir, los valores 0, 5, 7 u 8 no estaran permitidos); 2,4,6 (es los valores 2, 4 6 y ninguno ms). En el siguiente ejemplo, representado en la gura 1.14, se hacen las siguientes suposiciones:
1 Alumno * hace practicas con 1 matriculado en 1..* Asignatura
1..11
hace proyecto con
0,1
Profesor
Figura 1.14: Relaciones entre alumnos, asignaturas y profesores Un alumno puede estar matriculado como mnimo en una asignatura (si no est en ninguna no es alumno) y como mximo en 11. En una asignatura se pueden matricular un nmero ilimitado de alumnos pero tiene que haber al menos uno o de lo contrario la asignatura no existe. Un alumno puede estar haciendo o no el proyecto n de carrera. En caso armativo tendr un profesor asignado como coordinador. Existen asignaturas que tienen prcticas y algunas de ellas son entre varios. Un alumno puede estar asociado con un nmero variable de compaero para hacerlas, puede ser que con nadie, uno, dos, ...
13
Navegabilidad Es una propiedad del rol. Indica la posibilidad de ir desde el objeto fuente al objeto destino. Signica visibilidad, o sea que generalmente se ven los atributos. Por defecto la navegabilidad es bidireccional, pero a veces no ser posible viajar en ambas direcciones. Por ejemplo, en el caso de la gura 1.15 no es posible la bidireccionalidad debido a que dado un password no se puede conocer el usuario al que pertenece (al menos en principio).
Login * 1 Password
Figura 1.15: Navegabilidad
Calicacin Cuando se tiene una relacin uno a muchos existe el problema de la bsqueda, es decir, localizar la instancia correcta en el lado muchos. Para reducir el nmero de instancias a uno se utiliza un atributo de la relacin, representado como se ve en la gura 1.16.
1..* Cursa 1..11
Estudiante
Asignatura
1 Estudiante N. Matricula
Cursa
1..11
Asignatura
Figura 1.16: Calicacin
Agregacin Es un tipo de relacin del tipo todo/parte y se representa como se muestra en la gura 1.17. Sirve para modelar elementos que se relacionan utilizando expresiones como: es parte de, tiene un, consta de, etc. Todo lo que se ha dicho antes acerca de la multiplicidad es vlido aqu.
Continente 1 1..* Pais
Figura 1.17: Agregacin
Composicin Es un tipo de agregacin donde cada componente pertenece a un todo y slo a uno (en el ejemplo anterior no se cumple esto, por ejemplo, la antigua Unin Sovitica tena una parte europea y una parte asitica). En la gura 1.18 vemos un ejemplo de este tipo de relacin. Herencia y generalizacin Indica que una subclase o clase secundaria hereda los mtodos y atributos denidos en una superclase o clase principal. La superclase es ms genrica que la subclase. Este tipo de conexin se lee como es un tipo de. En UML se utiliza el trmino generalizacin en vez de herencia, pero es lo mismo. En la gura 1.19 se muestra un ejemplo de representacin. Dependencias Es un tipo de relacin en la que una clase usa a la otra. Por ejemplo: Una interfaz de un programa de dibujo tiene varios objetos en la pantalla. La clase Pantalla tiene el mtodo DibujarObjetoGrafico(o:OG) y dibujar una recta, un punto, etc en funcin de lo que sea ese objeto. Esta relacin se representa como en la gura 1.20. Interfaces Son un conjunto de operaciones que especican parte de la funcionalidad proporcionada por una clase. Una interfaz es como una clase pero sin atributos. Se representa de dos formas como se muestra en la gura 1.21. En una como una clase con el estereotipo interfaz y en otra abreviada, sin mostrar los mtodos. Entre los interfaces tambin existe herencia. Una clase puede implementar varios interfaces, y un interfaz puede ser implementado por ms de una clase. Todos los mtodos de un interfaz son pblicos.
14
1 Motor
1 Ascensor 1 1 Cabina
1 Cable
Figura 1.18: Composicin
Profesor
P.Asociado
P.Ayudante
P.Interino
P.Titular
Catedratico T.Completo T.Parcial

Figura 1.19: Herencia. Las clases abstractas van en cursiva
1.3.3. Diagrama de clases

Es el diagrama ms importante en UML. Es un modelo esttico del sistema que contiene los siguientes elementos: Clases Interfaces Colaboraciones: Conjunto de clases, interfaces y dems que exhiben un comportamiento. Relaciones de dependencia, colaboracin y asociacin. Se puede utilizar para modelizar tres cosas: 1. Los elementos del sistema. 2. Colaboraciones. 3. Esquema lgico de bases de datos. Veamos el modelado con diagrama de clases con el ejemplo de una estructura documental. Un objeto documental es, por ejemplo, un ejemplar de La divina comedia o la enciclopedia Espasa, que est compuesto por varios volmenes. Cada libro tiene una portada y un texto que se pueden ver. Los libros se pueden consultar, abrir, etc; tienen ttulo, autor y un nmero de pginas. Cada ejemplar puede haber sido editado por una editorial en una fecha determinada. Un libro puede haber sido traducido a varios idiomas y ser citado en algunos diccionarios, los cuales a su vez pueden ser de un nico tipo: multivolumen, que estn compuestos (como es lgico) por varios volmenes. Los tipos de libros que existen son: con anexo o hipermedia. Los de tipo hipermedia pueden tener sonido o enlaces. En la gura 1.22 vemos cmo se puede representar todo esto en un diagrama de clases.
Pantalla
DibujarObjeto
ObjetoGrafico
Figura 1.20: Dependencias
15
ObjetoGrafico
<<Interfaz>> Dibujable Dibujar()
Dibujable ObjetoGrafico
Figura 1.21: Interfaces

Fecha Portada Ver Texto Ver * referencia a Libro 1..1 Titulo Autor Paginas Idioma 1..1 Consultar Abrir Leer Cerrar * * * Editorial
1..1 1..1 > traducido en
Libro traducido
> citado en
Diccionario
Libro con anexo
Libro hipermedia
Diccionario multivolumen 1..1
Leer pagina * Anexo * Sonido Contenido

CDROM
1 . . 1000 * Enlace Pagina destino Activar hiperenlace Volumen Rango (AZ)
video Anexo
Escuchar
Anexo
Figura 1.22: Ejemplo completo de un diagrama de clases tomado de http://do.ole.com/personal6/biblioteconomie/ articulos/art8.html
1.3.4. Diagrama de objetos

Es un diagrama que contiene objetos y enlaces entre ellos. Pueden tambin agruparse en paquetes y se puede mostrar las clases si se considera oportuno para mostrar los objetos que vienen de una clase concreta. Sirve para tomar una instantnea del sistema en un momento dado del funcionamiento. Tambin es un modelo esttico porque no representa la evolucin a travs del tiempo, sino un momento concreto. Como se puede ver en el ejemplo de la gura 1.23, la notacin correspondiente es: 1. Se pone el objeto en un rectngulo. 2. El nombre es opcional pero se debe poner la clase a la que pertenece precedida por dos puntos, todo ello subrayado: NombreObjeto:Clase 3. Puede tener variables con su valor. 4. Al igual que las clases los objetos pueden estereotiparse. 5. Los objetos pueden estar relacionados por enlaces, que son instancias de las asociaciones denidas en el diagrama de clases.
1.3.5. Diagrama de casos de uso

Los casos de uso son una descripcin de una interaccin con el sistema por parte de algo externo al sistema que se llama actor. Por ejemplo: un usuario pulsa el botn de llamada de un ascensor. El nombre del caso de uso se pone en la elipse, como en el de la gura 1.24. Un caso de uso es un patrn o comportamiento que exhibe el sistema. Los casos de uso representan requisitos
16
: Motor miCoche : Coche matricula = WWW 1234 modelo = Citroen ZX 1.9 D color = verde
: AsientoDelantero
: Carroceria
: AsientoDelantero
: AsientoTrasero
: Salpicadero
Figura 1.23: Diagrama de objetos funcionales. Los casos de uso se escriben desde el punto de vista del actor, que es el usuario o sistema externo que interacta con el sistema.
LLamar ascensor
Figura 1.24: Caso de uso Relaciones que nos podemos encontrar en los casos de uso (ver gura 1.25):
Realizar venta pedido <<extend>> <<include>> Comprobar producto
Relizar venta producto
Figura 1.25: Relaciones entre casos de uso
1. Include: Es el concepto de subrutina. Si por ejemplo tenemos dos casos de uso A y B que tienen una serie de pasos en comn se ponen esos pasos en un tercer caso de uso C y A y B lo incluyen para usarlo. 2. Extends: Signica que un caso de uso B es igual al A al cual extiende aadiendo algunos pasos. 3. Comunicates: Comunica un actor con un caso de uso o con otro actor. Modelado del contexto Hay que modelar la relacin que tiene el sistema con los elementos externos. Los pasos a seguir son: 1. Identicar los actores que interactan con el sistema. 2. Organizar los actores. 3. Especicar las vas de comunicacin con el sistema. Modelado de requisitos Esto signica incorporar los casos de uso necesarios, tanto los que son visibles externamente como los que no. Para ello las actividades a seguir son: 1. Establecer su contexto. 2. Identicar las necesidades de los elementos del contexto. 3. Nombrar esas necesidades y darles nombre de casos de uso.
17
4. Identicar que casos de uso pueden ser especializaciones de otros y buscar especializaciones comunes para los casos de uso ya encontrados. Los casos de uso se vern con detalle ms adelante.
1.3.6. Diagrama de estados

Un sistema evoluciona en el tiempo pasando por una serie de estados. Parte de un estado inicial y llega a un estado nal. Un estado tiene: Nombre. Variables. Actividades, que pueden ser de dos tipos:
Acciones. Programadas por los desarrolladores Eventos: Sucesos a los que reacciona el sistema. Pueden ser de tres tipos:
Entry: Actividades que se realizan al entrar al estado. Exit: Eventos al abandonar el estado. Do: Actividades mientras se est en el estado.
Y constan de las siguientes partes: Signature: Nombre y lista de parmetros.
Guard condition: Expresin lgica que habilita o no la transicin. Accin: Accin interna a ser ejecutada. Mensaje: Evento enviado a otro objeto (o a varios).
Las transiciones entre estados pueden tener parmetros. Cada transicin tiene un evento asociado. Cuando se terminan las actividades de un estado hay una transicin. Por ejemplo, supongamos que tenemos un ascensor que cuando est en el stano (rea restringida a la que slo se puede acceder con llave) sube a los pocos segundos para evitar que si alguien se ha colado pueda acceder a las viviendas. Por otra parte el ascensor puede estar subiendo, bajando o parado. Cuando se est bajando al stano se considera como un estado especial y el hecho de estar en el stano tambin. Esto se puede representar como en la gura 1.26.
llegar Subiendo subir bajar_stano timeout Stano llegar Bajando al stano Parado llegar bajar Bajando
Figura 1.26: Diagrama de estados para un ascensor
1.3.7. Diagrama de secuencias

Muestra los objetos y los mensajes intercambiados entre ellos teniendo en cuenta la temporalidad con la que ocurren. Pueden mostrarse tambin los componentes porque son objetos reutilizables y los casos de uso porque se muestran como objetos que implementan el caso de uso. Sirven para documentar el diseo y validar los casos de uso. Gracias a estos diagramas se puede ver cuales don los cuellos de botella del sistema observando el tiempo que consume el mtodo invocado. Los conceptos a tener en cuenta son: 1. Lnea de vida de un objeto: Es una representacin de la actividad del objeto durante el tiempo que dura el escenario. El tiempo transcurre de arriba abajo. Se representa con una cabecera con un rectngulo con el nombre del objeto y una lnea vertical de puntos por debajo. Durante el tiempo en el cual el objeto tiene un mtodo funcionando la lnea de puntos se convierte en un rectngulo como se muestra en el ejemplo. 2. Activacin: Es el proceso por el que un objeto pasa a tener un mtodo en ejecucin. Esto puede ocurrir o bien porque otro objeto ha invocado alguno de sus mtodos o porque lo ha invocado el mismo (self -delegation). Cuando un objeto activa a otro siguen en actividad. 3. Mensaje: Un mensaje es un objeto que invoca el mtodo de otro. La notacin es una echa horizontal desde la lnea de vida de un objeto hasta otro. 4. Tiempos de transicin: Es el tiempo que hay entre un mensaje y otro. 5. Condicionales: Si se desea representar una alternativa o threads. El mensaje slo se enva si la condicin es verdadera. La condicin se escribe entre corchetes y puede referenciar a otro objeto (ver gura 1.27).
18
obj 1: Clase A [X] msg [no X] msg obj 2: Clase B

obj 3: Clase C
Figura 1.27: Diagrama de secuencias. Condicionales 6. Iteracin: Se pone el smbolo * previo a la condicin. Se repite la accin mientras la condicin es verdadera (ver gura 1.28).
:Agenda *[hayMasElementos()]siguiente():Elemento :Lista
Figura 1.28: Diagrama de secuencias. Iteracin 7. Creacin y destruccin de un objeto: La creacin de un objeto se representa con un mensaje de creacin sobre un rectngulo. La destruccin se representa con un aspa al nal de su lnea de vida (ver gura 1.29). 8. Mtodos recursivos: Se representan poniendo un rectngulo superpuesto al que est activo en el momento (ver gura 1.29).
obj1:Clase 1 obj2:Clase 1 obj3:Clase 2
mensaje 1 mensaje 2 mensaje self
create
obj4:Clase 3
destroy
Figura 1.29: Diagrama de secuencias. Mtodos recursivos y destruccin de objetos Las boundary classes, o clases de frontera, sirven para capturar y documentar los requisitos de interfaz. Muestran la interaccin con el usuario o con un sistema externo. Las clases de entidad son las inherentes al modelo del dominio y las de control son las que gestionan el caso de uso asociado al diagrama de secuencias. Reglas a seguir: La primera columna debe corresponder al actor que inicia el caso de uso. La segunda columna debe ser un objeto de frontera, que se comunica con el actor. La tercera columna debe ser un objeto de control que gestiona el caso de uso. Los objetos de control son creados por el objeto de frontera que inicia el caso de uso. Los objetos de frontera son creados por objetos de control. Los objetos de entidad son accedidos por objetos de control y frontera. Los objetos de entidad nunca tienen acceso a los objetos de frontera o control. De esta forma estos objetos pueden ser reutilizados en varios casos de uso distintos.
19
1.3.8. Diagrama de actividades

Son un caso especial de los diagramas de estados. Modela el comportamiento del sistema y la participacin de las clases en ese comportamiento. Describen el comportamiento interno de una clase en vez del comportamiento en funcin de los eventos. Para construirlos se puede seguir la siguiente estrategia: 1. Identicar una clase que participa en el comportamiento cuyas actividades de proceso deban ser especicadas. 2. Identicar las distintas actividades que se van a modelar. 3. Identicar: estados, ujos y objetos. Este diagrama es til para modelar el ujo de trabajo de un negocio a alto nivel (ver ejemplo en la gura 1.30) y consta de los siguientes elementos:
Ducha
Desayuno
Ver tele Cerrar puerta
Esperar 30 segundos [quiero andar] Ir andando [no quiero andar] Usar mando apertura garaje Abrir puerta
abrir(puerta)
abrir(puerta)
Conducir
Figura 1.30: Diagrama de actividades. Concurrencia, bifurcacin e indicacin
1. 2. 3. 4. 5.
Punto inicial. Se representa por un crculo negro. Punto nal. Es una diana. Actividades. Son rectngulos con bordes redondeados. Transiciones. Son el paso de una actividad a otra. Se representan con echas. Actividades concurrentes. Se representan por sus correspondientes actividades y una barra negra de la cual parten las echas que las inician. 6. Bifurcaciones: Se representan con un rombo o sencillamente con dos echas que salen de una actividad a otras dos. En cualquier caso, la condicin se indica en cada uno de los ramales entre corchetes. 7. Indicaciones: Se pueden enviar o recibir. El envo se representa con un rectngulo acabado en echa. El que las recibe con una gura complementaria de la anterior. Una indicacin modela el envo y recepcin de eventos.
1.3.9. Diagrama de componentes

Modelan la vista esttica del sistema. Ilustran la organizacin y las dependencias entre componentes software. Un componente puede ser: cdigo fuente, un programa ejecutable, tablas, o cualquier otro tipo de documento que forme parte del sistema. No tienen que estar presentes todos los componentes, suele mostrarse una parte. Un componente puede implementar una interfaz (ver gura 1.31). El estndar de UML dene cinco estereotipos: executable, library, table, le y document.
20
Componente
Interface
Figura 1.31: Diagrama de componentes

<<executable>> Agenda.exe <<library>> listas.dll
Figura 1.32: Ejecutable que usa una librera de manipulacin de listas Ejecutables Para modelarlos (ver ejemplo en la gura 1.32) los pasos a seguir son: 1. Identicar los componentes, particiones del sistema, cuales son factibles de ser reutilizadas, agruparlas por nodos y realizar un diagrama por cada nodo que se quiera modelar. 2. Identicar cada componente con su estereotipo correspondiente (executable, library, etc). 3. Relacionar los componentes entre s. Cdigo fuente Podemos usar estos diagramas (ver ejemplo en la gura 1.33) para expresar las dependencias que existen entre los mdulos para formar libreras o programas ejecutables.
<<file>> A.h <<file>> B.h
<<file>> Agenda.h
<<file>> Agenda.exe
Figura 1.33: Dependencias entre el cdigo
1.3.10. Diagrama de colaboracin

Dibuja las interacciones entre objetos organizadas a travs de los objetos y los enlaces que hay entre ellos. Este diagrama (ver ejemplo en la gura 1.34) es otra forma de ver la secuencia de eventos. Es lo mismo que los diagramas de secuencia (se puede generar de un modo automtico un tipo de diagrama a partir del otro).
1.3.11. Diagrama de distribucin

Reeja la organizacin del hardware. El elemento principal de este diagrama es el nodo. Hay dos tipos: los nodos con capacidad de ejecutar componentes y los que no pueden ejecutar. La informacin que hay en un nodo es: nombre del nodo y componentes del nodo (se puede poner slo sus nombres o un diagrama de componentes). Los nodos a su vez pueden estar fsicamente conectados con otros, lo que se representa con una lnea que los une. La utilidad principal de este tipo de diagramas es la modelizacin de una red (ver ejemplo en la gura 1.35).
Tutorial posterior
Resumen de contenidos
ste es el captulo introductorio donde se aborda cmo es la divisin en fases de un proyecto (ciclos de vida), las caractersticas de las metodologas que ordenan esas fases y una notacin muy habitual actualmente que se utiliza a lo largo de todo el ciclo de vida de un proyecto.

jugar() Jugador 1:r1:=lanzar() d1:Dado
21
2:r2:=lanzar()
d2:Dado
Figura 1.34: Diagrama de colaboracin
Servidor BD Oracle
Cliente Palencia Ap. Ventas
Cliente Madrid Ap. Ventas
Cliente Barcelona Ap. Ventas
Figura 1.35: Diagrama de distribucin 1. Metodologas: Es una justicacin del porqu de la ingeniera del software. Se dene lo que se entiende por sistema y por metodologa (una forma podra decirse burocrtica de producir un sistema con costes y tiempos controlados). Se establece tambin una clasicacin de las metodologas que, al igual que como se ver con los ciclos de vida, pertenecen a dos tipos principales: estructurada y orientada a objetos. 2. Ciclos de vida: Se explica lo que es un ciclo de vida, las fases de las que se compone y la forma en la que se ordenan estas fases. Hay una clasicacin de los distintos ciclos de vida que se pueden dar en un proyecto. Bsicamente, hay dos tipos principales que son: el ciclo de vida en cascada (el ms antiguo y preferido en la metodologa estructurada) y el ciclo de vida en espiral (el ms nuevo, preferido en la metodologa orientada a objetos) que se dividen a su vez en varios subtipos para cumplir diferente propsitos. Los ciclos de vida son: a) Ciclo de vida en cascada. Subtipos: ciclo de vida en V, Sashimi, cascada con subproyectos, cascada incremental y cascada con reduccin de riesgos. b) Ciclo de vida en espiral. Subtipos: Fuente y adems los subtipos cascada incremental y cascada con reduccin de riesgos que tambin se pueden considerar como ciclos de vida en espiral. 3. Notaciones de especicacin y diseo (UML): Se da una introduccin breve a la notacin UML. Existen libros muy completos al respecto, aqu solo se dan nociones bsicas para comprender un diagrama. El motivo de explicarlo en este tema es que se trata de una notacin que se puede seguir a lo largo de todas las fases del ciclo de vida. Previamente se denen los elementos de los que constan los diagramas. Despus se detallan los diagramas que lo componen. a) Diagrama de casos de uso: Es la forma en la que se lleva a cabo la especicacin, que puede servir tanto para metodologas clsicas (estructuradas) como orientadas a objetos. A partir de este diagrama se pueden sacar un esbozo de las clases de las que consta el sistema y las relaciones entre ellas. b) Diagrama de clases: Es el ms importante, muestra las clases en las que se divide el sistema o subsistema, informacin acerca de las mismas (atributos y mtodos), notas (comentarios) y las relaciones que existen entre ellas (herencia, asociacin, agregacin). El diagrama de clases junto con el de casos de uso es la piedra angular del resto de diagramas. c) Diagrama de estados: Bsicamente es un autmata nito como los que se estudiaron en la asignatura Teora de autmatas I y II. Consiste en una serie de estados y transiciones entre ellos. Usados para representar el cambio de estado de una clase en funcin de eventos. d) Diagrama de objetos: Muestra objetos (instancias de clases) en un momento concreto de la ejecucin de un programa, como si de una foto se tratara. e) Diagrama de secuencias: Muestra los objetos y los intercambios de mensajes entre ellos teniendo en cuenta la temporalidad con la que ocurren. f ) Diagrama de actividades: Modelan el comportamiento interno de una clase.
22
g) Diagrama de componentes: Un componente es algn tipo de documento del sistema, como por ejemplo cdigo fuente, una tabla, etc. Este diagrama modela la organizacin y dependencias entre ellos. h) Diagrama de colaboracin: Dibuja las interacciones entre objetos organizadas a travs de los objetos y los enlaces que hay entre ellos. Es equivalente a los diagramas de secuencia. i) Diagrama de distribucin: Reeja la organizacin del hardware. El elemento principal es el nodo. Uno nodo puede o no ejecutar componentes. Los enlaces entre nodos representan lneas de comunicaciones.
Ejercicios y actividades propuestas

1. Qu ciclos de vida elegira para cada una de estas aplicaciones? Desarrollar una biblioteca de clculo numrico para hacer operaciones con matrices de gran tamao. Desarrollar una agenda electrnica para guardar telfonos, direcciones, etc. Es ms que posible que se quiera ampliar. 2. Cmo representara la siguiente descripcin en UML?: Una casa est en una ciudad, las casas pueden estar en un edicio y varios edicios forman una manzana. Hay casas que son chals y los chals pueden estar solos o adosados. Los chals y los edicios estn en una calle, dentro de la cual tienen un nmero asignado, por otra parte, las casas que forman parte de edicios tienen un nmero que indica el piso y una letra. Una casa pertenece a una calle. Una zona es un conjunto de calles y cada una es conocida por un cdigo postal. Un conjunto de zonas es una ciudad, que tiene un nombre y pertenece a una provincia, la cual a su vez pertenece a un pas, el cual est en un continente o como mucho en dos (p. ej Rusia). En una casa viven personas y el nmero de personas que viven en una casa puede ser cualquier nmero. Una persona puede vivir en ms de una casa (por ejemplo, durante el verano en una y en el invierno en otra). Una casa es poseda por una o varias personas. 3. Represente la siguiente situacin en UML: Una persona pertenece a tres posibles grupos: Estudiante, Trabajador o Jubilado. Un trabajador puede tener empleo o no y puede cambiar entre cualquiera de estos casos siendo despedido si est trabajando o siendo contratado si est parado. Cuando llega a los 65 aos pasa a estar jubilado, a su vez, un estudiante pasa a ser un trabajador cuando acaba sus estudios. Un jubilado no cambia de estado (y si cambia, mal asunto). 4. En el ejercicio anterior con los tres grupos de personas, Cmo representara en un diagrama de clases a un estudiante que trabaja al mismo tiempo? 5. Represente la siguiente descripcin en UML: Un paracaidista se tira desde un avin, momento a partir del cual est cayendo deprisa. Pueden pasar dos cosas: el paracadas se abre o no se abre. Si no se abre existe un segundo paracadas de emergencia que se despliega tirando de una anilla. Nuevamente pueden pasar dos cosas. Si todo sale bien, tanto con el primero como con el segundo se pasa al estado de cayendo despacio. Se puede estar cayendo deprisa un mximo de 30 segundos y cayendo despacio un tiempo que oscila entre 0 y 5 minutos en funcin del momento en el que se abra uno de los paracadas. Al nal el paracaidista llega al suelo. 6. Represente esta situacin en UML: Un objeto A (cliente) hace una llamada a un objeto B (interfaz) que se encarga de crear un objeto C (servidor) si no existe ninguna instancia de C. En caso contrario no hace nada, es decir, slo puede existir una instancia de C. En cualquier caso devuelve a A una referencia al objeto C, entonces A invoca una funcin de C, tras lo cual A imprime un mensaje y se autodestruye.
Extensin de conocimientos
Este tema tambin se puede estudiar en [Som98, cap. 1], [Haw98, caps. 1 al 3] [Sch92, caps. 1 y 2]. Se pueden refrescar conocimientos previos en [CCEG00] y otros libros especcos de asignaturas previas o simultneas sobre Ingeniera del Software, por ejemplo en [Hum95] [Hum01]. La revista en lnea Software Development http://www.sdmagazine.com/, puede ser una buena fuente para encontrar artculos (en ingls) sobre temas de IS en general. Para una extensa coleccin clasicada y con buscador de bibliografas (mayoritariamente en ingls) sobre Ingeniera del Software en general, se puede consultar la pgina http://liinwww.ira.uka.de/ bibliography/SE/ dentro de The Collection of Computer Science Bibliographies. Tambin puede ser interesante la gua al SWEBOK (Software Engineering Body of Knowledge) en http://www.swebok.org/ que es una iniciativa conjunta del IEEE y la ACM para expresar el conjunto de conocimientos bsicos en Ingeniera del Software. Sobre el lenguaje UML se pueden extender conocimientos en varios libros especcos del tema como [JBR00a, JBR00b, Fow97] [Sch01b], o bien a travs de las pginas de Internet: http://www.omg.org/technology/uml/ del Object Managenemt Group (OMG). En la pgina http://usuarios.lycos..es/oopere/uml.htm se puede encontrar una introduccin a UML de Pere Martra muy interesante. Hay una herramienta de libre distribucin para la representacin mediante diversos mtodos (incluido UML) en http:// wwwhome.cs.utwente.nl/~tcm/ llamada TCM (Toolkit for Conceptual Modeling). En http://www.argouml.org/ se puede encontrar A RGO UML que es una herramienta libre (implementada en Java y licencia BSD) especca para la representacin en UML. Tambin se puede encontrar informacin en http://uml.sourceforge.net/index.php sobre el programa UML Object Modeller (para KDE en GNU/Linux) para dibujar diagramas de UML.
Captulo 2
Descripcin de ejemplos gua

Tutorial previo
Introduccin
Un forma de facilitar la comprensin de las diferentes fases en el desarrollo del software es utilizar ejemplos. Por este motivo en este captulo se describirn unos problemas supuestos, cuya solucin progresiva se podr ir utilizando en los temas 3 al 7 para ilustrar cada una de las fases y ayudar al alumno a focalizar las ideas en ejemplos concretos. Para que estos ejemplos sean efectivos el problema debe ser fcilmente reconocible por los alumnos (para que no se pierdan en el dominio del problema y se puedan centrar en el desarrollo de la solucin...) y sencillo, aunque no demasiado simple (como un mundo de bloques o similar) para que tenga suciente riqueza de detalles que jen los diferentes elementos del desarrollo del software. Estos ejemplos son una descripcin ms precisa de lo que un usuario suele ser capaz de proporcionar. Aunque en algn caso se haya dejado incompleta la descripcin a propsito, para poder utilizar el ejemplo en las fases de especicacin. No es normal tener tan claros los requisitos de una aplicacin desde el principio, por tanto, el lector no debe creer que esto es lo que se va a encontrar cuando tenga que construir una aplicacin, esto es la descripcin en lenguaje natural de lo que se puede deducir despus de las correspondientes entrevistas, cuestionarios, sesiones JAD, etc. Por otra parte, los enunciados han sido simplicados, de modo que sean tratables en un texto de este tamao, lo cual quiere decir que no son reales, aunque si realistas.

Este tema est dedicado exclusivamente a preparar los ejemplos que se podrn utilizar como ilustracin en los temas 3 al 7 al explicar las fases de desarrollo. Eventualmente podran utilizarse como ejemplos prcticos en la aplicacin de alguna de las metodologas planteadas en el tema 8 para las herramientas del tema 9.
Objetivos del tema

En este captulo el alumno debe entender los problemas planteados para hacerse una idea clara, posteriormente, de cules son los pasos que se dan para resolverlos.

Tras el estudio del contenido del tema, con especial nfasis en los apartados de descripcin y muy ligeramente en las plantillas de solucin propuestas (su contenido quedar ms claro en los siguientes temas), es conveniente que el alumno haga el esfuerzo de imaginar que l es el cliente que desea una aplicacin para ese problema, y plantear as cules pueden ser sus exigencias. Todo el material para el estudio de este tema est incluido directamente en esta gua didctica. Aplicacin de comercio en Web: Descripcin y plantilla propuesta. Gestin de proceso en una fbrica de productos electrnicos: Descripcin y plantilla propuesta. Agenda electrnica personal: Descripcin y plantilla propuesta.
2.1. Ejemplo A: Aplicacin de comercio en Web

En primer lugar se plantea un caso muy actual por la utilizacin comercial de Internet. Se trata de una aplicacin de compra/venta por Internet para una tienda o almacn de productos diversos. Bsicamente se desea poder controlar los pedidos realizados por Internet mediante pginas en HTML estndar. El comercio ya dispone en la actualidad de un servidor de HTTP instalado propio que utiliza solamente para hacer publicidad de la empresa, se desea extender su uso a la gestin de pedidos desde Internet en conexin con el resto de aplicaciones de gestin normales de la tienda. Se desea aadir al servidor una pgina web con productos ofertados y demandados (por mayoristas). Esto supone focalizar el problema en una parte del software de la 23
24
gestin comercial de la empresa para simplicar el problema, pero por otro lado aporta sucientes dicultades que se han de ir desentraando en cada una de las fases del desarrollo. Uno de los requisitos de la aplicacin es que sea segura, es decir, que no puedan existir terceras personas escuchando, para ello se puede utilizar el protocolo https. La aplicacin tiene dos partes: Oferta 1. Cada producto tiene: Foto, descripcin, Cdigo, PVP. 2. Ofertas (p. ej.: Lleve dos y pague tres, etc): Las ofertas son diferentes en funcin de que el cliente sea una persona o una empresa, y tambin dependiendo de si es o no un buen cliente, por tanto hay que guardar toda la informacin relativa a cada venta. 3. Forma de hacer pedidos: Se rellena un formulario. Si es la primera vez que se hace el pedido, el cliente rellena un formulario de datos personales y bancarios que se almacenan en una base de datos. Demanda 1. Hay una lista de artculos demandados con el mximo nmero de unidades que se admiten y que los mayoristas pueden consultar. 2. La oferta de un mayorista consiste en una lista de: a) Nombre de artculo. b) Precio unitario. c) Cantidad de artculos a partir de la cual se tiene ese precio unitario. (Cuantos ms artculos se compren menor es ese precio) 3. Una vez hecha una oferta se almacena en una base de datos. 4. Existe la posibilidad de que el mayorista ofrezca artculos que no estn en la base de datos (novedades). Cada una de estas ofertas es un lote de productos que el mayorista vende juntos. Un mayorista puede hacer mltiples ofertas. En funcin de las ofertas de los proveedores se toman las decisiones de seleccionar uno u otro. Las ofertas pueden ser complejas, pudiendo ofertar un mismo artculo a precios diferentes en funcin de la cantidad de artculos o en ofertas que consisten en un lote de productos.
2.2. Plantilla de solucin propuesta para el ejemplo A

Los casos de uso son: 1. Dando de alta cliente (ver tabla 2.1). Caso de uso: Dando de alta cliente Actor: Cliente Curso normal Alternativas 1) El cliente comunica sus datos 2) El sistema le asigna una 2.1) Si el cliente ya est contrasea al cliente registrado se informa del error 3) Si el cliente lo desea inicia por primera vez el caso de uso Recogiendo pedido de cliente Cuadro 2.1: Caso de uso para dar de alta un cliente. 2. Dando de alta proveedor (ver tabla 2.2). Caso de uso: Dando de alta proveedor Actor: Proveedor Curso normal Alternativas 1) El proveedor comunica sus datos 2) El sistema asigna una contrasea 2.1 El proveedor ya estaba registrado Se informa del error. Fin 3) Si el proveedor lo desea inicia el caso de uso Recogiendo oferta de proveedor Cuadro 2.2: Caso de uso para dar de alta un proveedor
2.2 Plantilla de solucin propuesta para el ejemplo A
25
Caso de uso: Recogiendo pedido de cliente Actor: Cliente Curso normal Alternativas 1) El cliente se identica correctamente 1.1) El cliente no est en la BD. Fin 2) El cliente selecciona de la lista de productos las cantidades que necesita. 3) El sistema registra el pedido 3.1) No hay suciente cantidad de algn producto . Se llama a Solicitando reposicin 4) El sistema informa de la fecha de entrega 5) El usuario conrma el pedido 5.1) El usuario rechaza el pedido Cuadro 2.3: Caso de uso para recoger pedido de cliente Caso de uso: Recogiendo oferta de proveedor Actor: Proveedor Curso normal Alternativas 1) El proveedor se identica correctamente 1.1) El proveedor no est en la BD. Fin 2) El proveedor escribe la lista de productos ofertados y precios 3) El sistema graba la informacin en la base de datos Cuadro 2.4: Caso de uso para recoger oferta de un proveedor 3. Recogiendo pedido de cliente (ver tabla 2.3). 4. Recogiendo oferta de proveedor (ver tabla 2.4). 5. Actualizando contenido de la pgina (ver tabla 2.5). . Caso de uso: Actualizando contenidos Actor: Gestor Curso normal Alternativas 1) El gestor se identica correctamente 1.1 ) El gestor no se identica correctamente. Se anota la incidencia. Fin 2) El gestor introduce nuevos elementos en la B.D. de productos con sus cantidades y precios de venta al pblico. Cambia las cantidades de algunos productos 3) El sistema actualiza la B.D. de productos y registra fecha, gestor, y cambios realizados Cuadro 2.5: Caso de uso para actualizar contenido de pgina 6. Solicitando reposicin (ver tabla 2.6). 7. Seleccionando proveedor (ver tabla 2.7). Clases Las clases necesarias para realizar el primer caso de uso Dando de alta cliente seran: 1. Objetos de entidad Cliente: Es un objeto del mundo real que el sistema tiene que tener en cuenta para almacenar sus datos. Sirve para almacenar los datos del cliente. TablaClientes: Proporciona un conjunto de accesos a la tabla de clientes de la base de datos. Sirve para saber si un objeto Cliente existe y para insertarlo. 2. Objetos de frontera FormularioAlta: Para preguntar los datos al cliente. MensajeError: Para mostrar si el cliente ya estaba registrado. PreguntaPeticin: Para preguntar si se inicia el caso de uso RecogiendoPedidoCliente. 3. Objetos de control ControlAltaCliente: Es el objeto que gestionar la comunicacin entre los diferentes objetos. El resto de los casos de uso tendran un proceso similar.
26
Cuadro 2.6: Caso de uso de solicitar reposicin Caso de uso: Solicitando reposicin Actor: Sistema Curso normal Alternativas 1) El nmero de items de algn producto baja de su umbral 2) El sistema selecciona un proveedor 2.1 No se encuentra proveedor. Se escribe la incidencia en la base de datos. Fin del caso de uso. 3) Se establece comunicacin con el proveedor 4) La aplicacin del proveedor est disponible 4.1 La aplicacin del proveedor no est disponible. Se elimina de la lista de proveedores y se vuelve al punto 2 5) El proveedor registra la peticin 6) El proveedor notica la entrega 7) El sistema inserta en la base de datos fecha, producto, cantidad, precio y proveedor Caso de uso: Seleccionando proveedor Actor: Gestor Curso normal Alternativas 1) El usuario introduce un tipo de producto y cantidad 2) El sistema busca el proveedor que 2.1 El sistema no encuentra un suministre el producto a menor precio y proveedor de ese producto lo comunica al usuario y lo comunica al usuario Cuadro 2.7: Caso de uso de seleccionar proveedor Diseo arquitectnico Las partes en las que se divide esta aplicacin son las siguientes: 1. 2. 3. 4. Base de datos Servidor Clientes Una aplicacin en el lado del proveedor que dialoga con la nuestra
En el cliente estaran todos los formularios y se mandara el contenido en la forma de los objetos adecuados al servidor.
2.3. Ejemplo B: Gestin de proceso en una fbrica de productos electrnicos

Como complemento al problema anterior se plantea, en una empresa de fabricacin de chips o cualquier otro tipo de productos electrnicos, el desarrollo de una aplicacin para la gestin integral del proceso de control de movimientos de entrada/salida y seguimiento de personas, materiales o documentos. Dado que la empresa maneja informacin delicada (secretos industriales) es necesario llevar un control riguroso de todos los elementos y personas que se mueven en la empresa. Esto se desea automatizar lo mximo posible para que los miembros del departamento de seguridad tengan plenas garantas del control. Para simplicar el problema se supone que los sistemas software de control de sensores, cmaras, etc estn ya plenamente implementados y con toda la documentacin necesaria disponible, por tanto solamente se debe desarrollar la parte correspondiente a la interfaz de manejo y las aplicaciones de gestin de los datos. Este ejemplo puede tener dos partes: gestin del almacn y gestin de personas. Un producto estar en el almacn y hay que tener informacin acerca de ese producto. Cada tipo de producto tendr en el almacn un stock mnimo y mximo, una serie de caractersticas (precio de fabricacin, consumo elctrico, voltaje, etc). Respecto a las personas, cada una tiene una serie de responsabilidades a las que est asociada, una serie de personas con las que colabora, un horario, un sueldo que se calcula en funcin de categora, productividad, etc. Se puede pensar en una reasignacin de tareas en dos situaciones: 1) Cuando una persona est enferma o tenga que desplazarse, para lo cual habr un proceso que seleccione alguien en funcin de aptitudes y disponibilidad dentro de la plantilla y reasigne tareas y 2) Cuando se realice un nuevo plan de produccin que afecte a toda la fbrica.
2.4. Plantilla de solucin propuesta para el ejemplo B

El DFD inicial (ver gura 2.1) se descompone en dos partes: Gestin del almacn y gestin de personas (ver gura 2.2).
2.5 Ejemplo C: Agenda electrnica personal
27
Personas
Aptitudes
Empresa chips
Productos Tareas
Produccion
Pedidos
Clientes
Figura 2.1: DFD 0
Produccion
Productos
Gestion Almacen 1
Pedidos
Clientes
Tareas
Gestion Personas 2
Aptitudes
Personas
Figura 2.2: DFD 1 La gestin del almacn se puede descomponer de este modo: 1. Gestin de entradas. Items que entran al almacn. No se tiene en cuenta cual es el proceso que causa la peticin a los proveedores de estos items. 2. Gestin de salidas. Items que salen al almacn como consecuencia de pedidos. Ambos procesos actualizarn la base de datos y dejarn un registro de cada entrada y salida. La gestin de personas se podra descomponer de esta forma: 1. Actualizar plantilla. En el caso de una persona que se ponga enferma o se desplace. 2. Asignacin de tareas. Se selecciona una persona para cubrir esa baja, que es un tipo de obrero cualicado para cubrir cualquiera de los puestos de una lnea de produccin. 3. Planicacin global. Este proceso se encarga de la replanicacin global en el caso de un nuevo plan de produccin.
2.5. Ejemplo C: Agenda electrnica personal

Uno de los programas prcticos, y relativamente asequible, que se puede hacer para uno mismo, es el de una agenda personal simple para llevar la informacin sobre personas, libros, msica, citas, etc. En nuestro ejemplo, queremos gestionar los datos siguientes: De cada persona: Nombre y Apellidos (obligatorio), NIF, Fecha de nacimiento (para recordatorio de cumpleaos, etc.), Domicilio (uno o ms), Direccin de correo electrnico (una o ms), Telfonos (pueden ser de cada uno de los domicilios, del mvil, del trabajo, etc.) y Comentarios (campo de texto de gran tamao para poner informacin no contemplada en los puntos anteriores). Para seleccionar en la lista de personas que salen en la interfaz de usuario los tipos de personas que se quieren ver, se podra tener en algn sitio (quizs una opcin de conguracin del men) un chekbox con las opciones de: Familiares, Amigos, Compaeros del trabajo, rea secreta, etc. De los libros: Ttulo (obligatorio), Autor(es), Editorial, Fecha de publicacin, ISBN, Localizacin y Categora (ensayo, novela, profesional, etc). De los discos de msica: Ttulo (obligatorio), Autor o grupo, Casa discogrca, Tipo de soporte, Tipo de msica (pop, rock, clsica, jazz, etc) y Localizacin. De los vdeos: Ttulo (obligatorio), Director, Actores principales, Gnero (drama, cine negro, ciencia ccin, etc), Ao de produccin, Duracin (en minutos) y Localizacin. Respecto a las tareas: Fecha y hora de comienzo (obligatorio), Duracin estimada y Descripcin.
28
Adems se va a dividir la informacin en dos tipos: Pblica y privada. La informacin pblica est a la vista de cualquier persona que utilice el programa. La informacin privada slo la puede recuperar la persona que la ha introducido, para lo cual ser necesario que cada persona tenga un login y un password (slo si esa persona quiere introducir o leer informacin en un rea privada). Esto signica que hay que hacer una gestin de usuarios. Se desea tambin que exista algn mecanismo para dividir los tipos de personas en categoras, de forma que se distinga entre compaeros del trabajo, amigos, familiares, etc. Esto puede implementarse como un atributo ms de los relativos a la persona, pero debe usarse tambin de algn modo en la interfaz de usuario de tal forma que sea fcil seleccionar entre los diferentes tipos de personas (el usuario no sabe SQL ni similares). Se cuenta tambin con la posibilidad de recuperar elementos borrados. Cada vez que se borra un elemento no queda borrado del todo, se almacena en un rea conocida como limbo, del cual se puede recuperar. Si un elemento es eliminado del limbo desaparece denitivamente. Los datos se pueden guardar de dos formas: en una base de datos o en cheros. Ambos mtodos tienen sus ventajas e inconvenientes. En cualquier caso los datos que se guarden como secretos deben ser cifrados (usando alguno de los algoritmos criptogrcos que hay publicados) con la clave que se pide al usuario para de esa forma evitar cualquier tipo de intrusin. En algn lugar de la interfaz de usuario hay que poner un reloj (no se especica si analgico o digital) y la fecha. El reloj tiene precisin de segundos.
2.6. Plantilla de solucin propuesta para el ejemplo C

2.6.1. Casos de uso
En general existen cuatro tipos de casos de uso en esta aplicacin: De insercin de elementos, de lectura, de borrado y de modicacin. Adems hay que tener en cuenta los casos de uso de acceso al rea secreta de datos y de acceso al limbo para recuperar o eliminar denitivamente la informacin. Caso de uso: Insertar persona. 1. 2. 3. 4. 5. 6. El usuario selecciona la opcin de personas en la pestaa adecuada. El sistema cambia la pantalla para mostrar ese tipo de elementos. El usuario pulsa el icono de insercin o la opcin de men de insercin. El sistema muestra una pantalla donde est toda la informacin relativa a una persona. El usuario rellena la informacin anterior. El sistema comprueba que la informacin es correcta. Si no es correcta puede ser por dos motivos: El nombre y apellidos estn repetidos. Se muestra el mensaje de error correspondiente y se permite editar este campo de nuevo. El nombre y apellidos no han sido escritos. Se muestra el mensaje de error correspondiente y se permite escribir esta informacin. 7. El sistema realiza la insercin. 8. El sistema borra la pantalla de insercin de datos y actualiza la ventana principal con la nueva informacin. Entre los puntos 4 y 6 el usuario tiene la opcin de cancelar la operacin de insercin. Los casos de uso de insercin de discos, tareas, vdeos y libros seran idnticos a este. Proceso de recuperar informacin. Se puede hacer de dos formas: Seleccionando la persona de una lista y se muestran sus datos o con una ventana en la que se pregunta el nombre y el sistema lo busca. Caso de uso: Buscar persona 1. 1. 2. 3. 4. El usuario selecciona la opcin de personas en la pestaa adecuada. El sistema cambia la pantalla para mostrar ese tipo de elementos. El usuario selecciona un nombre de una lista. El sistema muestra los datos de esa persona en esa misma pantalla.
Caso de uso: Buscar persona 2. 1. 2. 3. 4. El usuario selecciona la opcin de personas en la pestaa adecuada. El sistema cambia la pantalla para mostrar ese tipo de elementos. El usuario pulsa el icono de bsqueda o selecciona esa opcin del men. El sistema muestra una pantalla donde se pregunta el nombre y apellidos de la persona a buscar.
2.6 Plantilla de solucin propuesta para el ejemplo C
29
5. El usuario escribe la informacin. 6. Pueden ocurrir tres cosas: No existen personas con ese nombre. El sistema pone un mensaje. Fin del caso de uso. Slo existe una persona. Se resalta el nombre de esa persona en la lista de personas y se pone su informacin en las casillas correspondientes de la ventana. Fin del caso de uso. Existe ms de una persona que se corresponde con ese nombre (puede pasar porque si slo se ha escrito el nombre o parte de l puede haber varias personas distintas que se correspondan, aunque sea la clave de esta tabla). El sistema hace una lista de las personas mostradas y esa lista se recorre igual que en el caso de uso buscar persona 1. Fin del caso de uso. Al igual que antes, los casos de uso para libros, discos, etc seran idnticos a este. Borrado En este caso necesitamos hacer una bsqueda primero y luego un borrado. Veamos cmo se borrara una persona. Puede hacerse de dos formas, como en el buscar persona. Caso de uso: Borrar persona 1. 1. 2. 3. 4. 5. El usuario selecciona una persona con el caso de uso Buscar persona 1. El usuario pulsa el icono de borrado o selecciona esa opcin del men. El sistema pide conrmacin con la ventana correspondiente. El usuario conrma el borrado o lo rechaza, en cuyo caso termina el caso de uso. El sistema pone la informacin en el limbo.
Caso de uso: Borrar persona 2. 1. 2. 3. 4. 5. Se utiliza el caso de uso de buscar personas 2. El usuario pulsa el icono de borrado o selecciona esa opcin del men. El sistema pide conrmacin con la ventana correspondiente. El usuario conrma el borrado o lo rechaza, en cuyo caso termina el caso de uso. El sistema pone la informacin en el limbo.
Como estos dos casos de uso son prcticamente idnticos podramos pensar en utilizar la parte comn. Divisin del sistema Veamos cmo sera la divisin del sistema. Las entidades externas seran los usuarios (ver gura 2.3). Los procesos que hay que hacer son:
Insercion Consulta Borrado Modificacion Usuario Creacion Borrado Acceder como Agenda
Figura 2.3: DFD 0
Gestin de personas (telfonos y direcciones). Insercin, borrado, consulta y modicacin. Gestin de libros, msica y vdeos (dem que el anterior) Gestin de usuarios (login, password). Acceder como, Crear usuario, Borrar usuario. Adems cada uno de estos apartados denira un almacn propio para guardar cada uno de sus tipos de datos. Como se puede ver (gura 2.4), cada uno de los procesos es totalmente independiente de los dems, no necesitan comunicarse informacin, excepto en el caso de la gestin de usuarios, que dene el usuario actualmente conectado y correctamente identicado por el sistema. Esta informacin se deja en un almacn al cual pueden acceder el resto de los procesos.
30
Insercion Consulta Borrado Insercion
Gestion Libros
Consulta Borrado
Gestion Musica
Modificacion Nuevo Usuario
Modificacion
Borrar Usuario
Gestion Usuarios
Usuario
Acceder Como Insercion Insercion Consulta Borrado Borrado Modificacion Modificacion
Gestion Videos
Consulta
Gestion Personas
Figura 2.4: DFD 1
Diseo de la interfaz de usuario Puede hacerse de muchas formas perfectamente vlidas, la solucin propuesta es slo una de ellas. Las opciones que el usuario tiene que ver claramente son: Gestin usuarios, Personas, Libros, Msica y Vdeos. La interfaz puede hacerse de muchas formas: Men, Barra de iconos, o un componente con varias pestaas con cada opcin. Una barra de iconos quizs sea la mejor opcin desde el punto de vista de la vistosidad, pero hay que tener cuidado de que esos iconos sean realmente signicativos. Es aconsejable adems que exista algn tipo de ayuda, como los mensajes de ayuda emergentes que salen cuando se pasa el ratn por encima. Cada vez que se pulse una de las opciones, el diseo de la pantalla debera cambiar para mostrar un conjunto de elementos visuales relativos a la opcin seleccionada, por otra parte, cada una de las opciones del men, barra o componente, tendra que poder mostrar en cada una de ellas las opciones de Insercin, Borrado, etc. Si la opcin escogida es un men esto podra hacerse con submens. Si se escoge una barra de iconos, se puede poner en la pantalla un botn con cada una de las opciones, etc. Distribucin de la informacin dentro de la pantalla: El objetivo es que encontrar la informacin sea fcil y rpido. Una forma es tener una lista de Personas, Libros, etc a la izquierda y la lista de atributos de uno de ellos a la derecha y ocupando el resto de la pantalla. Cada vez que se selecciona una Persona, Libro, etc. cambia el contenido de los atributos mostrando el seleccionado.
Tutorial posterior
Este captulo consiste simplemente en un conjunto de tres ejemplos que se plantean, tanto en su descripcin, como en el diseo o preparacin de plantillas de su posible solucin. Estos ejemplos podrn ser utilizados a lo largo del resto de los temas para ilustrar algunos aspectos de los mismos. Los ejemplos elegidos son: una aplicacin de comercio en Web, la gestin de proceso en una fbrica de productos elctricos y una agenda electrnica personal.

1. Como paso para comprobar la comprensin de los problemas que van a plantear a lo largo de los prximos captulos sera conveniente que el alumno redactase las descripciones dadas por el cliente (o los posibles dilogos con los desarrolladores) para denir a partir de ellos de una manera grca o esquemtica los elementos, actores y tareas que pueda identicar. 2. El alumno puede elegir algn problema supuesto por s mismo, y denirlo aqu de manera similar a los propuestos, para poder utilizarlo como ejercicio para el resto de los temas donde se irn desarrollando los propuestos aqu.
2.6 Plantilla de solucin propuesta para el ejemplo C
31
En [Pre01, sec. 28.5] se encuentra una descripcin de un sistema de comercio electrnico, que puede usarse para extraer ms informacin y descripciones para el primer ejemplo de este captulo. En el apndice A.3 del libro [Som98], se puede encontrar un conjunto de ejemplos gua alternativos desarrollados en las diferentes fases que pueden resultar muy tiles. Hay una aplicacin para tienda electrnica de libre distribucin (fuentes incluidos), desarrollado en modo open source (licencia GPL) por O NRICA por encargo de BANESTO, en http://www.cibertienda.org/ que puede servir de gua para el ejemplo aqu presentado.
32
Captulo 3
Fase de requisitos
Tutorial previo
Introduccin
El primer paso para atacar un problema es conocer cul es el problema y por tanto se necesita saber cules son los requisitos del problema. La extraccin u obtencin de requisitos es el primer paso que va seguido del anlisis de esos requisitos en base a un modelo del problema. De ese anlisis obtendremos una especicacin de requisitos que debemos validar frente a las especicaciones iniciales. Esta fase es la primera que se acomete en el desarrollo del proyecto y es la ms importante, sobre todo, si se tienen en cuenta las consecuencias de una mala obtencin de requisitos: hacer un sistema que no hace lo que el cliente espera de l. Ocurre que no es tan sencillo como se puede pensar en un principio, pues muchas veces el propio cliente no tiene una imagen clara del sistema nal o surgen nuevas necesidades a mitad del desarrollo. Para hacer frente a estos problemas hay que: comunicarse de forma efectiva con el cliente para obtener los requisitos, comprender el problema a resolver, crear un modelo del problema real y, por ltimo, revisin de la especicacin. Todos estos pasos deben dejar un rastro que se pueda seguir en caso de problemas posteriores, por lo cual se debe empezar a guardar registro, documentar, ya desde el principio.

La extraccin, modelado, anlisis y representacin de requisitos o especicaciones es un problema muy relacionado con la Ingeniera del Conocimiento, por tanto sera conveniente que el alumno repasara los temas correspondientes en las asignaturas previas relacionadas. Es necesario ejercitar la capacidad de abstraccin para poder expresar lo que pide el cliente en una representacin formal que responda a sus expectativas.
Objetivos del tema

Es necesario en esta fase separar y entender los conceptos propios de cmo especicar un problema y cmo hacer til esas especicaciones para posteriores fases del desarrollo. El alumno debe ser capaz de extraer y representar un conjunto de requisitos expresados en lenguaje natural a una representacin que sirva de entrada a la fase siguiente de diseo.

En el tema se exponen los contenidos tericos genricos junto con las partes correspondientes de los ejemplos gua. El alumno debe identicar cules son los elementos correspondientes a la obtencin y el anlisis de los requisitos en esos ejemplos para generalizarlo a otros problemas. Tambin puede realizar los mismos procesos sobre los problemas supuestos por el alumno como ejercicios en el tema 2. 1. Obtencin de requisitos: se estudia directamente en el material en esta gua. 2. Anlisis de requisitos: este apartado se puede estudiar en [Pre01, secs. 11.1 a 11.3]. 3. Representacin de requisitos: el contenido se estudiar en [Pre01, sec. 11.5 y cap. 12] (aunque en este ltimo se denomina modelado del anlisis). 4. Anlisis orientado a objetos: en [Pre01, cap. 21] (o bien [Pre97, cap. 20] en la 4 a edicin). 5. Validacin de requisitos: en [Pre01, sec. 11.6] junto con el apartado correspondiente en esta gua. 6. Bases de documentacin: en el contenido del apartado correspondiente de esta gua. 33
34
Fase de requisitos
3.1. Obtencin de requisitos

Los mtodos tradicionales en cualquier ingeniera requieren como primer paso la obtencin de los requisitos en forma de especicaciones por parte del cliente. Este problema habitualmente tiene complicaciones debidas al paso entre el lenguaje natural y los lenguajes ms formales en ingeniera. Por lo tanto la obtencin de los requisitos es un paso complejo y que no tiene una solucin sencilla. Se suelen utilizar los mtodos de pregunta-respuesta o los de cuestionarios plantilla para perlar la versin inicial, pero se requieren sucesivas iteraciones (incluso con otras fases de desarrollo) antes de obtener unas especicaciones adecuadas.
3.1.1. Introduccin
Un requisito es una capacidad que el sistema debe tener porque el cliente lo ha pedido explcita o implcitamente, lgicamente, la determinacin del conjunto de requisitos es el primer paso a dar en la construccin de una aplicacin. Existen dos subtareas en la obtencin de los requisitos antes de pasar a la fase de diseo: Anlisis: El problema a resolver es la comprensin del problema del cliente y que caractersticas debe tener el producto. Especicacin: Traducir los requisitos a un documento con un formato concreto que pueda servir de entrada a la fase siguiente. La obtencin de requisitos es difcil por varias razones: La naturaleza de los requisitos es cambiante. Surgen nuevos requisitos en cualquier momento. El cliente puede no tenerlos claros. Pueden existir malos entendidos debidos a:
Falta de conocimientos por parte del equipo desarrollador sobre el problema. Falta de conocimientos tcnicos (informticos) por parte del cliente para expresarse con claridad.
Anlisis La clave es la comunicacin con el cliente. Para facilitar esta comunicacin se han desarrollado varias tcnicas: entrevistas, prototipos, desarrollo conjunto de aplicaciones (Joint Application Development, JAD), planicacin conjunta de requisitos (Joint Requirements Planning, JRP) y casos de uso del UML. Especicacin Lo que se consigue aqu es un documento que especica todos los requisitos, este documento tiene que tener estas propiedades: Completitud: Estn todos los requisitos. Concisin: Es importante no hacer una novela, hay que contar lo que hay pero pensando que quien se lea el documento cobra por horas. Legibilidad: Es similar al punto anterior, pero el sentido de este es la claridad. Consistencia: No existen contradicciones internas. Facilidades de prueba: De algn modo se debe poder comprobar cada uno de los requisitos. Facilidades de cambio: Es bastante probable que el documento cambie a lo largo del ciclo de vida. Facilidades de seguimiento: Debe ser posible comprobar si se van cumpliendo los objetivos. Factibilidad: Los objetivos denidos deben ser conseguibles a un coste razonable. Tipos de requisitos Requisitos funcionales: Dicen qu debe hacer el sistema, en el sentido de servicios proporcionados al usuario. Requisitos no funcionales: Hablan de caractersticas del sistema, como pueda ser la abilidad, mantenibilidad, sistema operativo, plataforma hardware, etc.
3.1.2. Tcnicas de obtencin de requisitos

En esta seccin veremos las tcnicas de comunicacin con el cliente.
3.1 Obtencin de requisitos
35
Entrevistas Todo el mundo pasa por una entrevista en algn momento de su vida ya sea para un proceso de seleccin de personal, un examen de oposicin o incluso una conversacin con el jefe se podra considerar como una entrevista. Aunque tambin existan otras tcnicas, esta siempre la tendremos, al menos al inicio del proyecto. Una entrevista tiene tres fases: Preparacin, Desarrollo y Anlisis. Preparacin Hay cuatro cuestiones que se han de tener en cuenta:
1. Documentacin: El entrevistador se informa acerca del tema a tratar. Puede hacerlo de varias formas: Estudiar la bibliografa sobre el tema. Estudiar documentos sobre proyectos similares. Inmersin dentro de la organizacin para la que se desarrolla el proyecto 2. Personal: Se seleccionan las personas a las que se va a entrevistar. Directivos: Dan una imagen de alto nivel de la empresa. Puede ser til para determinar la estructura arquitectnica de la aplicacin. Empleados: Dan una imagen de un grano ms no. Son los que pueden concretar las funciones a implementar. 3. Determinar el objetivo de la entrevista. Previamente a la entrevista se pueden distribuir a los entrevistados cuestionarios sobre el tema a tratar y una introduccin. 4. Logstica: Temas prcticos acerca de como discurre la entrevista: lugar, hora, minimizar interrupciones, encontrar un momento en el que todos puedan ir, etc. Desarrollo Hay tres etapas [PV96]: 1. Apertura: El entrevistador se presenta e informa al entrevistado de cuales van a ser los puntos tratados en la entrevista. 2. Desarrollo: No debe durar ms de dos horas. El entrevistado debera hablar el 80 % del tiempo. Tcnicas utilizadas: Preguntas abiertas, tambin conocidas como de contexto libre. No se pueden contestar con Si o No. Por ejemplo: Cul es la lista de pasos para dar de baja un producto?. Ms tarde se pasa a preguntas ms concretas. Forma de expresarse: Se deben evitar los tecnicismos que el entrevistado pueda no conocer. Psicologa: El problema fundamental de las entrevistas es que se trata con personas en vez de con mquinas, por eso la comunicacin es de peor calidad. Hay que tener en cuenta las siguientes reglas entre muchas otras de la comunicacin no verbal.
No insinuar que el entrevistado debera saber algo que no sabe para que no se ponga a la defensiva. Tambin hay que dejar claro que los intereses del entrevistador son nicamente la adquisicin de requisitos, no hacer un examen de conocimientos, y por tanto las lagunas que pueda tener no trascendern a sus superiores. Lenguaje del cuerpo: Dicen los psiclogos que el 90 % de la comunicacin es no verbal. Se debe estar atento a los signos que puedan denotar inseguridad en algunos temas para preguntar a otras personas. Usar tcnicas para mantener la atencin del entrevistado.
3. Terminacin: Se hace un resumen de la informacin recogida (para validar que es correcta) y, de ser necesario, se cita para la siguiente entrevista. En cualquier caso se debe poder contactar de nuevo con el interesado, por ejemplo para aclarar algunos puntos. Se agradece al entrevistado que nos haya dedicado su tiempo. Anlisis Se trata de ver como utilizar los conocimientos adquiridos. Para ello las actividades son:
1. Burocracia, como por ejemplo, pasar a limpio la entrevista. 2. Asimilacin de la informacin: Se contrasta con otras entrevistas, bibliografa, etc. Se llega a conclusiones. 3. Evaluacin de la entrevista: Qu se quera conseguir y qu se ha conseguido? Para validar una vez ms la entrevista se puede mandar la documentacin generada al entrevistado. Desarrollo conjunto de aplicaciones (JAD) En el apartado anterior se vio una somera introduccin a una entrevista clsica desde el punto de vista de que existe un entrevistador y un entrevistado. Ahora se contempla un tipo de entrevista desarrollada por IBM que se apoya en la dinmica de grupos. Consiste en un conjunto de reuniones en un periodo de entre dos y cuatro das. Se basa en cuatro principios: 1. Dinmica de grupo.
36
Fase de requisitos
2. Uso de ayudas audiovisuales: Diagramas, transparencias, pizarras, etc. 3. Modo de trabajo sistemtico. 4. Filosofa de documentacin WYSIWYG (What You See Is What You Get). Existen dos tipos de sesiones JAD: JAD/Plan, para obtencin de requisitos y JAD/Design, para el diseo. Veremos el primero. Ventajas del JAD: 1. La informacin obtenida se puede contrastar in situ porque estn todos los interesados. En las entrevistas individuales este es un proceso lento. Adems en esta contrastacin participan tanto los usuarios como los desarrolladores, esto quiere decir que los requisitos que se obtienen son los correctos. 2. Los clientes se sienten involucrados en el proceso de desarrollo porque ellos mismos participan en la exploracin de los problemas que se plantean, con lo cual la resistencia al cambio ser menor. Inconvenientes: 1. Al ser un grupo de personas es difcil encontrar un hueco en la agenda de todos para estas reuniones. 2. Es una tcnica difcil. Participantes: Participan de ocho a doce usuarios a parte de los analistas. Hay seis tipos: 1. Jefe del JAD: Debe tener las caractersticas clsicas de una persona que dirige una reunin: Dotes de comunicacin y liderazgo. Son deseables tambin conocimientos de psicologa para por ejemplo conseguir que todo el mundo participe o evitar conictos, pero sobre todo, para dirigir la sesin a sus objetivos. 2. Analista: La funcin realizada es la de secretario de la sesin. Es la persona encargada de poner por escrito la informacin. No es una tarea tan trivial como parece, tiene que ser alguien que haya comprendido el tema y lo pueda expresar bien con las herramientas que se empleen. 3. Patrocinador: A efectos prcticos es el jefe de la empresa contratante porque es quien toma la decisin de seguir o no con el desarrollo. Debe informar de cuales son las necesidades que cubrir el producto. 4. Representantes de los usuarios: En el JAD/Plan son directivos porque proporcionan una visin global del sistema. En el JAD/Design son usuarios. 5. Desarrolladores: Son las personas que pueden informar de las dicultades de implementacin de ciertas caractersticas. 6. Especialistas: Son la autoridad a consultar sobre aspectos puntuales tanto por parte de los usuarios como por parte de los desarrolladores. Fases: 1. Adaptacin: El jefe del JAD es quien debe adaptar la sesin a las caractersticas propias del proyecto en curso. Para ello debe: Documentarse sobre la organizacin y el proyecto. Decidir cuestiones organizativas sobre las sesiones JAD: Nmero y duracin, lugar (mejor si es fuera de la empresa para evitar interrupciones), fechas, etc. Seleccionar a los participantes adecuados para cada reunin. 2. Sesin JAD: Est dividida en una serie de pasos: Presentacin: Al igual que en la entrevista individual, el jefe del JAD y el patrocinador ejecutivo se presentan. El patrocinador explica los motivos del proyecto. El jefe del JAD explica la mecnica de la reunin. Denicin de requisitos de alto nivel: Esto ya es parte del trabajo productivo. El jefe del JAD hace preguntas del tipo: Qu benecios se esperan del sistema? Cules son los recursos disponibles? Estos requisitos se van escribiendo en algn medio que permita que todo el mundo lo pueda ver, por ejemplo transparencias. Delimitar el mbito del sistema: Cuando se ha reunido un conjunto de requisitos lo sucientemente grande se les puede organizar y decidir el mbito del sistemaDocumentar temas abiertos: Si un tema queda sin resolver se debe documentar para otra sesin y asignar una persona responsable de su solucin. Concluir la sesin: El jefe del JAD hace un repaso de la informacin obtenida con los participantes. Es el momento de hacer correcciones o aadidos. 3. Organizacin de la documentacin: Se trata de producir un documento con la informacin recabada en la fase anterior. Hay tres partes que se siguen secuencialmente. Compilar la documentacin: La documentacin recogida se redacta en un documento normalizado. Revisar la documentacin: Se enva la documentacin a los participantes para que efecten correcciones. Validar la documentacin: El patrocinador ejecutivo da su aprobacin.
37
Planicacin conjunta de requisitos (JRP) Es un subconjunto de las sesiones JAD. Se caracterizan por estar dirigidas a la alta direccin y en consecuencia los productos resultantes son los requisitos de alto nivel o estratgicos. La planicacin de una sesin consiste en tres pasos: 1. Iniciacin: Se delimita el alcance del plan de sistemas de informacin, unidades organizativas afectadas y perles necesarios para la reunin. 2. Bsqueda: Se identican objetivos, situacin actual e informacin al respecto. 3. Lugar: Es importante que al igual que en la sesin JAD sea fuera de la organizacin para evitar interrupciones. La sala de reuniones debe ser adems confortable y equipada con el mobiliario adecuado. Las ayudas audiovisuales pueden ser pizarras, proyectores, etc. Se debe contar adems con ordenadores equipados con herramientas CASE, procesadores de texto, hojas de clculo y herramientas de prototipado. 4. Seleccionar a los participantes, cuyos perles son los siguientes: Jefe JRP: Debe tener las mismas aptitudes que en el caso del JAD. Patrocinador: El que respalda econmicamente el proyecto. Director del proyecto Consultores: Traduce los requisitos de usuario a informacin estructurada inteligible por los usuarios. Especialista en modelizacin: Elabora los modelos en la reunin. Usuarios de alto nivel: Denen los procesos organizativos y los sistemas de informacin afectados por el plan de sistemas de informacin y las prioridades de implantacin. 5. Redactar la agenda de asuntos a tratar. Esta agenda debe ser planicada asignando tiempos para cada cuestin. 6. Realizacin: Discurre igual que la sesin JAD. Brainstorming Este es otro tipo de entrevista de grupo. A diferencia del JAD que est fuertemente estructurada, el brainstorming (tormenta de ideas) se caracteriza precisamente por lo contrario, porque aunque existe un jefe del grupo, su funcin es meramente anecdtica. El objetivo es la generacin de ideas novedosas para la resolucin de un problema. Su utilizacin es adecuada al principio del proyecto, pues puede explorar un problema desde muchos puntos de vista. Ventajas del brainstorming: 1. Es fcil (la nica norma es que vale todo y no se puede criticar a nadie). 2. No est tan formalizado como el JAD. Inconvenientes: 1. No proporciona resultados con mucho nivel de detalle. 2. Es difcil reunir a todo el mundo. Fases del Brainstorming: 1. Preparacin Se selecciona a las personas involucradas, es decir: Jefe de la reunin, usuarios y desarrolladores. Se les convoca a una hora y en un lugar determinados. 2. Desarrollo: El jefe expone el problema a resolver, entonces cada persona expone sus ideas para la solucin. El jefe da la palabra a una persona u otra. Cuando se han generado sucientes ideas se termina la reunin. Normas a seguir: No se permite la crtica a ningn participante, diga lo que diga. Se promueven las ideas ms creativas aunque no sean factibles para estimular la creatividad del resto del grupo. Cuantas ms ideas salgan mejor. Los participantes pueden aadir cosas de su cosecha a las ideas de otros. 3. Consolidacin: Es como la fase de anlisis en la entrevista individual o la fase de organizacin de la documentacin de JAD. Se divide en tres partes Clasicar ideas para agruparlas o fusionarlas. Descartar ideas peregrinas o poco factibles. Priorizar ideas en funcin de su importancia. 4. Documentacin: El jefe pone por escrito la informacin que sale de la fase de consolidacin.
38
Fase de requisitos
Prototipos Un prototipo es una versin reducida de la aplicacin nal. Se puede construir con dos losofas[Som98]: 1. Prototipos de desarrollo rpido. Sirven para obtener y validar requisitos. Cuando han cumplido esta nalidad se desechan. 2. Prototipo inicial: Se desarrolla el sistema de un modo incremental partiendo de una versin inicial. El segundo caso se ha discutido ya en el captulo dedicado a ciclos de vida. El primer caso sigue el proceso indicado en la gura 3.1.
Requisitos iniciales
Desarrollo prototipo
Evaluacion
Especificacion
Desarrollo sistema
Validacion
Figura 3.1: Obtencin y validacin de requisitos a partir de prototipos [Som98] Un prototipo no es utilizable como sistema nal porque se ha desarrollado con la mxima rapidez y en consecuencia: 1. Los requisitos no funcionales tales como rendimiento, seguridad, etc no se implementan. 2. No hay documentacin. 3. El sistema ser caro de mantener porque el prototipo habr sufrido muchos cambios a lo largo del desarrollo y su estructura estar en mal estado. 4. La calidad del cdigo es mala. Para el desarrollo rpido de prototipos [Som98] existen tres tcnicas de desarrollo rpido de prototipos que se pueden usar conjuntamente: Lenguajes de alto nivel, Programacin de bases de datos y Componentes reutilizables. Lenguajes de alto nivel Son lenguajes de gran nivel de abstraccin que necesitan menos lneas de cdigo para hacer lo mismo que en un lenguaje de bajo nivel como C. Ejemplos de lenguajes de alto nivel son: Lisp, Smaltalk, Prolog y Java. Los lenguajes de alto nivel tienen el handicap de cargar mucho al sistema, razn por la cual no estn ms extendidas, aunque este motivo es cada vez menos importante dada la potencia de las mquinas actuales. Cuando se desarrolla un prototipo hay que responder algunas cuestiones para escoger el lenguaje, tales como cual es el mejor lenguaje para el dominio del problema que se est abordando. Por ejemplo, Lisp y Prolog pueden ser adecuados para inteligencia articial, Java si se necesita un software multiplataforma, etc. Se deben tener en cuenta asimismo factores tales como las facilidades suministradas por la herramienta para la construccin automatizada de interfaces de usuario, la experiencia que tiene con dichas herramientas el personal con el que contamos, si se puede conectar o forma parte de una herramienta CASE, etc. Programacin de bases de datos Una base de datos tiene un lenguaje de programacin que permite manipularla y utilidades. Un lenguaje de cuarta generacin es el lenguaje de programacin de la base de datos y su entorno. Son interesantes las herramientas que permiten acceder a la base de datos a travs de un navegador ya que as se puede acceder desde cualquier punto. Componentes reutilizables El principio en el que descansan los componentes es que es ms rpido usar software hecho que hacerlo, por ejemplo, los beans de Java. Si adems existe algn mecanismo que permita que esos componentes se comuniquen y se integren fcilmente, mejor. Problemas que se pueden presentar:
39
1. No existen todos los componentes necesarios para el prototipo que se quiere desarrollar, con lo que hay que desarrollarlos. 2. Los componentes existen, pero no son exactamente lo que se necesita y hay que adaptarlos. El desarrollo de prototipos con reutilizacin se puede hacer a dos niveles: 1. Nivel de aplicacin: Los sistemas que componen la aplicacin pueden ser compartidos por otras aplicaciones, por ejemplo se puede insertar un grco desarrollado con una aplicacin en otra. Las aplicaciones actan como si estuvieran conectadas entre si al estilo de las tuberas de Unix. 2. Nivel de componente: Los componentes estn integrados en un armazn estndar, como puede ser un lenguaje de desarrollo de componentes, por ejemplo: P YTHON o P ERL o algo ms general como CORBA, DCOM o JAVA B EANS. JAVA B EANS es un ejemplo de componentes reutilizables. Son un tipo de componentes escritos en Java, que generalmente tienen algn tipo de interfaz grca (Enterprise-JavaBeans sin embargo no es as, pues se ocupa ms de la lgica de la aplicacin). Sus caractersticas son: 1. Tienen un constructor predeterminado sin parmetros (es decir, un bean es una clase que cumple una serie de restricciones) 2. Son persistentes. La persistencia es la capacidad de un objeto de convertirse en un ujo de bytes para por ejemplo poder ser escrito en disco o recuperado del mismo. 3. No son nunca clases abstractas, es decir, siempre se pueden crear instancias de ellos. 4. Para escuchar un evento se usan estas dos funciones: public void addEventListenerType(EventListenerType evento) public void removeEventListenerType(EventListenerType evento) 5. La forma de dar valor o conocer el valor de una propiedad es con mtodos de la forma: getX() y setX(Propiedad propiedad). Si la propiedad es booleana en vez de getX() se usa isX(). Si la propiedad es indexada se utiliza: getX(int index) getX() que devuelve un array y los mtodos para asignar valor seran: setX(int index, propiedad) setX(Propiedad[] propiedad). Casos de uso Son una forma de especicar los requisitos de un sistema, un caso de uso consiste en una interaccin de algo externo al sistema y el sistema. Fueron introducidos por Jacobson en 1992. Aunque es una tcnica denida dentro del ambiente del anlisis orientado a objetos no tiene que ver con objetos, se podra utilizar perfectamente dentro del anlisis estructurado. Ms adelante veremos la tcnica de los casos de uso con el ejemplo gua (ver tema 2) de la aplicacin web. Un caso de uso: Describe la interaccin entre un actor externo al sistema y el sistema con texto en lenguaje natural. Representa los requisitos funcionales desde el punto de vista del usuario y por lo tanto produce un resultado observable por l. Es iniciado por un nico actor. Realiza una funcionalidad concreta. Los objetivos de los casos de uso son: Comprender la funcionalidad del sistema. Discutir con el usuario nuestra visin de esa funcionalidad. Identicar conceptos del sistema, clases, atributos y operaciones. Validar el anlisis y el modelo del diseo. Proporcionar informacin para las pruebas del sistema y de aceptacin. Existen dos tipos de elementos: 1. Actores: El actor puede ser tanto una persona como otro sistema que juega un rol en la interaccin con el mismo. Un mismo rol puede ser desempeado por varias personas y una persona puede desempear ms de un rol. Un usuario no es un actor, sino que asume un rol cuando interacta con el sistema y por lo tanto funciona como un tipo de actor. 2. Caso de uso: Es la interaccin que se quiere modelar. Pueden agruparse en paquetes y tener relaciones entre ellos. Identicar actores Un caso de uso se compone de actores y de interacciones de esos actores sobre el sistema. por lo tanto, lo primero es buscar actores. Teniendo en cuenta lo que es un actor, hay que encontrar la siguiente informacin: 1. Identicar los usuarios del sistema. Para ello tener en cuenta para quien se est diseando o con que personas va a interactuar de un modo directo (actores principales) y quienes va a tener un papel de supervisin o mantenimiento del sistema (actores secundarios). 2. Identicar los roles que juegan esos usuarios desde el punto de vista del sistema. Hay varios tipos, gestores de alto nivel, gente que introduce datos, etc. 3. Identicar otros sistemas con los cuales exista comunicacin. Estos sistemas tambin se consideran como actores dado que son algo externo a nuestro sistema.
40
Fase de requisitos
Identicar operaciones Una vez que se tienen los actores se trata de encontrar los casos de uso, como lo que tenemos en este momento son los actores, partimos de esta base para encontrar la informacin que falta. Los actores interactuaran con el sistema realizando un conjunto de tareas que tendremos que enumerar y manejarn informacin, tanto la que suministren al sistema como la que el sistema les suministre a ellos. Una vez que se dispone de los actores y de los casos de uso hay que encontrar las relaciones que hay entre ellos. Las relaciones que hay entre casos de uso son de dos tipos: Aquellas en las que uno extiende a otro: Son muy parecidos (comparten muchos pasos) pero tienen ligeras diferencias adaptadas a la forma particular en la que se realiza una tarea. Aquellas en las que uno usa a otro: En esta situacin un caso de uso es similar a una funcin o subrutina que es llamada por otro. Otra forma de hallar casos de uso es hacer una lista de eventos. Un evento es una ocurrencia a la que el sistema tiene que responder. No supone un dilogo como un caso de uso porque ocurre de un modo atmico. Los pasos a seguir en este caso son por un lado identicar todos los eventos a los que el sistema tiene que responder y luego relacionarlos con los actores adecuados. Una vez identicados estos casos de uso podemos sacar otros nuevos de varias formas: 1. Por variaciones respecto a casos de uso existentes si: Existen diferentes actores que puedan utilizar un mismo caso de uso pero con variaciones signicativas. Existen diferentes versiones del mismo caso de uso con variaciones signicativas. 2. Buscando el caso de uso opuesto a uno dado, por ejemplo, si tengo dando de alta cliente podra existir el caso de uso dando de baja cliente 3. Preguntarnos que tiene que ocurrir para que se cumplan las precondiciones de un caso de uso, por ejemplo, para hacer un pedido es necesario que el cliente entre con su password, con lo que tiene que existir un caso de uso para dar de alta. Dar detalle a los casos de uso descritos Esto que se ha descrito hasta ahora es la forma de construir un armazn de casos de uso, veamos como se pueden concretar un poco ms. Para cada caso de uso hay que: Describir la informacin de entrada y de salida. La descripcin detallada del caso de uso contiene:
Una descripcin textual de su objetivo. Variantes posibles para realizar este caso de uso. Diagramas de interaccin de detalle (de secuencia o colaboracin). Errores y excepciones posibles.
Relacionar el caso de uso con la interfaz de usuario que lo representa. Especicar el dilogo que da solucin al caso de uso. La descripcin de un caso de uso consta de los siguientes elementos: Descripcin del escenario. Suposiciones acerca del escenario. Condiciones previas para el caso de uso. Se expresa en una tabla con la secuencia de interacciones. La tabla puede tener una columna con el curso normal de acontecimientos y otra con posibles alternativas. Cada alternativa representa un error o excepcin y no tienen suciente entidad como para ser un caso de uso al que se llegue con una relacin extiende. 5. El nombre del caso de uso se pone en gerundio. 6. Se pone el actor responsable. 7. Resultado una vez terminado el caso de uso. Aplicacin al Ejemplo A del captulo 2: Veamos primero el caso de uso Dando de alta cliente del ejemplo A en el captulo 2 (ver tabla 3.1). El cliente se relaciona con el sistema con un navegador y lo hace desde su empresa. Una vez terminado, el cliente queda registrado en la base de datos de la empresa propietaria de la pgina web. En este ejemplo vemos un caso de uso que opcionalmente puede utilizar a otro (Recogiendo pedido de cliente). En el ejemplo de la aplicacin web los casos de uso podran ser: Dando de alta cliente, Dando de alta proveedor, Recogiendo pedido de cliente, Recogiendo oferta de proveedor, Actualizando contenido de la pgina, Solicitando reposicin y Seleccionando proveedor. El caso de uso seleccionando proveedor puede ser utilizado por otro caso de uso o por el actor Gerente. En la gura 3.2 tenemos la representacin de las relaciones entre casos de uso. 1. 2. 3. 4.
41
Caso de uso: Dando de alta cliente Actor: Cliente Curso normal Alternativas 1) El cliente comunica sus datos 2) El sistema asigna una 2.1) Si e cliente ya est contrasea al cliente registrado se informa del error 3) Si el cliente lo desea inicia por primera vez el caso de uso Recogiendo pedido de cliente Cuadro 3.1: Caso de uso para dar de alta un cliente en el ejemplo gua A
Dando de alta proveedor Dando de alta cliente Extiende Recogiendo pedido de cliente Seleccionando proveedor Actualizando contenidos
Usa
Extiende Recogiendo oferta de proveedor
Proveedor
Cliente
Solicitando reposicion
Gestor
Figura 3.2: Casos de uso de la aplicacin web Actores y casos de uso abstractos Un caso de uso que slo exista para ser utilizado por otros casos de uso se dice que es abstracto. Como ese caso de uso no tiene un actor que lo utilice, nos inventamos un actor cticio (abstracto). En el ejemplo A del captulo 2 tenemos el caso de uso abstracto Seleccionando proveedor. El actor abstracto que creamos para este caso le damos el nombre: Seleccionador de proveedor. La manera en la que se relaciona este nuevo actor cticio con los de verdad es por medio de la herencia. Por lo tanto, todos los actores que utilicen un caso de uso que a su vez utiliza un caso de uso abstracto heredarn de l. En nuestro ejemplo, Proveedor hereda de Seleccionador de proveedor (ver gura 3.3). Un actor puede heredar de cualquier otro, tanto si es abstracto como si no, con lo que hereda tambin todas las funcionalidades a las que puede acceder.
Seleccionador de proveedor
Proveedor
Figura 3.3: Un actor hereda de otro
Otras clasicaciones de los casos de uso Casos de uso esenciales y de implementacin Cuando se est en la fase inicial de recopilar todos los casos de uso, no se ponen en detalle, se indica su nombre y poco ms (casos de uso esenciales, o de trazo grueso). Cuando se va a implementar el
42
Fase de requisitos
caso de uso hay que denirlo con ms detalle (caso de uso de implementacin o trazo no). Casos de uso temporales Son aquellos iniciados no por un actor, sino por un evento de reloj. Se debe indicar el momento en el que esto ocurre, p. ej.: cada 500 milisegundos. La notacin consiste en poner el caso de uso en un valo con lnea de puntos o con smbolo de reloj. Casos de uso primarios y secundarios Los casos de uso secundarios son aquellos que existen por que son necesarios para que el sistema funcione pero que no son inherentes a su funcionalidad.
3.2. Anlisis de requisitos

Una vez que hemos extrado los requisitos del problema es necesario convertir esos requisitos en un modelo del problema que distinga los elementos que forman parte de los requisitos y las relaciones entre ellos, as como las funcionalidades esperadas del conjunto. En este apartado se estudiarn las diferentes estrategias o patrones de modelado del problema. El contenido de este apartado se estudia en [Pre01, secs. 11.1 a 11.3].
3.3. Representacin de requisitos

Como resultado del anlisis de los requisitos especicados inicialmente, se obtiene un modelo del problema que es necesario representar de una manera formal que permita la aplicacin de tcnicas sistemticas para su resolucin. Existen diversos lenguajes y mtodos de especicaciones que tienen caractersticas diferentes segn el mtodo posterior del desarrollo. Por ejemplo diagramas entidad-relacin para modelado, diagramas contextuales, plantillas o marcos conceptuales, diagramas funcionales, etc. El mtodo ms extendido de representacin es mediante tcnicas orientadas a objetos y los lenguajes asociados a ellas. El contenido de este apartado se estudia en [Pre01, sec. 11.5 y cap. 12].
3.4. Anlisis orientado a objetos

El anlisis orientado a objetos representa el problema en trminos de clases, sus propiedades y sus relaciones. El modelo que resulta de este anlisis utiliza tcnicas muy diversas, algunas como la de los casos de uso son perfectamente aplicables tambin al anlisis estructurado. La ventaja del anlisis orientado a objetos es que la representacin que se logra del mundo es ms prxima a la realidad. La transformacin de los requisitos en trminos de usuario a la especicacin en trminos de sistema informtico es ms suave. El contenido de este apartado se estudia en [Pre01, cap. 21] (o bien [Pre97, cap. 20] en la 4 a edicin).
3.5. Validacin de requisitos

Es importante que antes de continuar el desarrollo del software a partir de los requisitos modelados y representados se haga la comprobacin de su validez, comparando la correspondencia con las descripciones iniciales y si el modelo responde a lo realmente deseado. Esta parte de la fase de requisitos se suele realizar comprobando que el modelo obtenido responde de la misma forma deseada que la que el cliente pide por un lado, y por otro a la inversa si otras respuestas del modelo convencen al cliente. En algunos casos ser necesario construir prototipos con una funcionalidad similar muy reducida para que el cliente se haga una idea aproximada del resultado.
Denicin
La validacin de los requisitos comprueba que estos son correctos. Esta fase debe realizarse o de lo contrario se corre el riesgo de implementar una mala especicacin, con el costo que eso conlleva. Los parmetros a comprobar por la especicacin son [Som01]: 1. Validez: No basta con preguntar a un usuario, todos los potenciales usuarios pueden tener puntos de vista distintos y necesitar otros requisitos. 2. Consistencia: No debe haber contradicciones entre unos requisitos y otros. 3. Completitud: Deben estar todos los requisitos. Esto es imposible en un desarrollo iterativo, pero, al menos, deben estar disponibles todos los requisitos de la iteracin en curso. 4. Realismo: Se pueden implementar con la tecnologa actual. 5. Vericabilidad: Tiene que existir alguna forma de comprobar que cada requisito se cumple. El contenido de este apartado se completa con [Pre01, sec. 11.6].
3.6 Bases de documentacin
43
3.6. Bases de documentacin

Ya desde los primeros pasos del desarrollo del software es necesario comenzar a organizar toda la documentacin. En primer lugar se han de gestionar los formatos en los que se va a escribir la documentacin. Preferiblemente se deben utilizar herramientas de ayuda que semi-automatizan la recopilacin de la documentacin durante el desarrollo. Evidentemente, tanto las especicaciones iniciales del problema (en lenguaje natural probablemente) como las especicaciones nales de los requisitos (en un lenguaje formal), pasando por los estados intermedios de anlisis y modelado y las diferentes pruebas de validacin se deben guardar como parte inicial de la documentacin. El documento de especicacin de requisitos SRS (Software Requirements Specication) es algo as como el contrato ocial que se establece entre los desarrolladores y los clientes. Incluye tanto los requisitos funcionales como los no funcionales. Una recoleccin correcta y completa es crucial para el desarrollo de un sistema de informacin exitoso. Para alcanzar el mayor grado de calidad es esencial que el SRS sea desarrollado de un modo sistemtico e inteligible, en cuyo caso reejar las necesidades del usuario y ser til para todos. Lo que sigue es una plantilla del SRS segn el estndar IEEE 830. En la portada se indican: Nombre de la empresa, Nombre del proyecto, Nmero de versin y Fecha. El ndice debe constar de las siguientes secciones: Introduccin, Descripcin general, Requisitos especcos, Gestin del cambio del proceso, Aprobacin del documento e Informacin de soporte. El desarrollo del ndice anterior debe contener la siguiente informacin: 1. Introduccin. Las siguientes subsecciones dan una visin general del documento. a) Propsito: Identica el propsito del documento y el perl de usuario al que est dirigido. b) Alcance. En esta subseccin: Se identica el nombre de los productos software que se van a desarrollar. Se explica lo que hacen los productos y lo que no hacen. Se describen las aplicaciones del software especicado, incluyendo benecios y objetivos. Se debe ser consistente con especicaciones similares de ms alto nivel si existen, es decir, en el caso de que estas sean las especicaciones de un subsistema. c) Deniciones, acrnimos y abreviaturas: Es un listado de las deniciones de todos los trminos, acrnimos y abreviaturas necesarios para interpretar correctamente el SRS. La informacin puede ser proporcionada con referencias a apndices. d) Referencias: Se da la lista completa de todos los documentos referenciados en cualquier lugar de la SRS. Se identica cada documento por ttulo, versin, fecha y responsable de su redaccin. Se especican las fuentes desde las que se pueden obtener las referencias. e) Visin de conjunto: Describe la organizacin general de la SRS. 2. Descripcin general: Describe los factores generales que afectan al producto y sus requisitos. No se denen requisitos especcos (seccin 3), slo su contexto. a) Perspectiva del producto: Relacin del producto con otros similares. Si el producto es independiente y autocontenido se debe decir aqu. Si es un componente de un sistema mayor aqu deben estar los requisitos para que el sistema mayor lo pueda utilizar e identica las interfaces entre el sistema y el software. Se puede poner un diagrama de bloques para mostrar las interconexiones del sistema con otros e interfaces externas. b) Interfaces del sistema: Identica la funcionalidad del software y la descripcin de la interfaz. Especica: Caractersticas lgicas de cada interfaz entre el producto y sus usuarios. Todos los aspectos relativos a la optimizacin de la interfaz con los usuarios. 1) Interfaces hardware: Se especican las caractersticas de cada interfaz entre el producto y los componentes hardware. Incluye la conguracin, dispositivos soportados, cmo son soportados y protocolos. 2) Interfaces software: Es una lista de otros productos software e interfaces con otras aplicaciones.
Para cada producto se debe incluir: Nombre, Mnemnico, Nmero de versin y Fabricante. Para cada interfaz se debe desarrollar en: Motivos para interactuar con el producto y Denicin de la interfaz acerca de contenido de los mensajes y formatos. 3) Interfaces de comunicaciones. Por ejemplo protocolos de comunicaciones.
a b
c) Restricciones de memoria. d) Operaciones normales y especcas tales como: 1) Modos de operacin en la empresa del usuario. 2) Operaciones interactivas y no interactivas.
44
Fase de requisitos
3) Funciones de proceso de datos. 4) Operaciones de backup. e) Requisitos de instalacin. Se denen: 1) Requisitos para datos y secuencias de inicializacin especcos para un emplazamiento, misin o modo de operacin. 2) Caractersticas necesarias para adaptar el software a un entorno concreto. f ) Funciones del producto: Es un resumen de las funciones que proporciona el software. A veces esta lista puede copiarse de las especicaciones de alto nivel. Este resumen: Debe ser inteligible por el cliente con una sola lectura. Se pueden utilizar elementos textuales o grcos para mostrar las diferentes funciones y sus relaciones. No es un grco del diseo, slo muestra relaciones lgicas entre funciones y variables. g) Caractersticas del usuario: Es una lista de aptitudes y motivos para ellas. h) Restricciones: Descripcin general de limitaciones que afectarn a los desarrolladores tales como: Polticas, Limitaciones de hardware, Interfaces con otras aplicaciones, Operaciones en paralelo, etc. i) Suposiciones y dependencias: Lista de cada uno de los factores que afectan a los requisitos. No son restricciones de diseo pero un cambio en ellos afectara a los requisitos. j) Requisitos no implementados: Lista de requisitos que se dejan para futuras versiones. 3. Requisitos especcos: Es una lista de los requisitos a un nivel de detalle lo sucientemente no que permita a los desarrolladores disear un sistema que los satisfaga. Deben incluir las entradas, las salidas y las funciones suministradas en respuesta a entradas o para suministrar una salida. a) Interfaces externos: Es una lista detallada de todas las entradas y salidas. Complementa las descripciones de interfaz en el apartado 2b pero sin repetir informacin. b) Requisitos funcionales: Denen las acciones que el software tiene que tomar para producir las salidas a partir de las entradas. Ejemplos: Comprobar la correccin de la entrada. Secuencia correcta de las operaciones. Respuestas a situaciones anormales. Relaciones entre entradas y salidas. c) Requisitos de rendimiento: Especica requisitos estticos y dinmicos. Un requisito esttico de rendimiento puede ser el nmero de usuarios conectados simultneamente. Un requisito dinmico sera por ejemplo el nmero de transacciones por minuto. Estos requisitos deben especicarse en unidades medibles. d) Requisitos relativos a bases de datos: Requisitos lgicos que tiene que tener la informacin que se deje en la base de datos. Por ejemplo: Tipos de informacin, frecuencia de uso, etc. e) Restricciones de diseo: Restricciones de diseo que pueden ser impuestas por otros estndares, limitaciones de hardware, etc. 1) Conformidad con los estndares: Requisitos derivados de la existencia de estndares. Por ejemplo: Formato de los informes, nombre de los datos, procedimientos de contabilidad o auditoras. f ) Atributos del sistema software: Son propiedades del sistema. El hecho de tenerlas constituye un requisito. Los ms importantes son: Fiabilidad, Disponibilidad, Seguridad, Mantenibilidad y Portabilidad. g) Organizacin de los requisitos. Los requisitos deben ser presentados de un modo jerrquico para que la cantidad de informacin no sea abrumadora para el lector y se puedan comprender con facilidad. No existe un modo ptimo para presentarlos. Esto es una lista de posibles criterios. Modo del sistema: Es el modo de operacin. Algunos sistemas se comportan de un modo muy distinto en funcin del modo en el que estn. Clases de usuario: En funcin de a quin est dirigido interesar resaltar unas funciones u otras. Objetos: Se pueden agrupar las funciones en trminos de las suministradas por jerarquas de objetos. Caractersticas: Son servicios observables externamente que puede requerir una secuencia de entradas y salidas en un orden concreto. Estmulo: Algunos sistemas se describen mejor en trminos de estmulo - respuesta. Respuesta: Clasicacin en funcin del tipo de respuesta que da el sistema. Jerarqua funcional: Se trata de organizar el sistema en trminos de funciones con entradas y salidas similares. h) Comentarios adicionales.
3.6 Bases de documentacin
45
4. Gestin del cambio del proceso: Seleccionar la gestin del proceso de cambio que deba ser usada para identicar, registrar, evaluar y actualizar el SRS para que reeje el alcance de los cambios en el proyecto y sus requisitos. 5. Aprobacin del documento: Identicar a las personas que deben dar su visto bueno. Deben constar su nombre, rma y fecha. 6. Informacin de soporte. Hace que este documento sea ms fcil de usar. Incluye ndice y apndices.
Tutorial posterior
En este captulo se ven las formas de captura de requisitos y de su representacin. La nalidad de esta fase es producir un documento que represente los requisitos y que sirva de entrada para la fase de diseo. El anlisis es la forma de conseguir los requisitos y la especicacin la forma de representarlos. Tcnicas de obtencin de requisitos 1. Entrevistas: Consiste en hablar con el cliente. Hay que tener sobre todo conocimientos de psicologa. 2. JAD: Consiste en un tipo de entrevista muy estructurada aplicable a grupos de personas. Cada persona juega un papel concreto y todo lo que se hace est reglamentado. 3. JRP: Es un subconjunto de JAD. 4. Brainstorming: Es un tipo de entrevista que se caracteriza precisamente por lo contrario que la anterior. No tiene ningn tipo de estructura. 5. Prototipos: Se trata de construir una mini-aplicacin inicial para claricar algunos puntos y luego tirarla o bien para usarla como base para aadir ms cosas. 6. Casos de uso: Es la tcnica denida en UML. No est necesariamente asociada a la programacin orientada a objetos, puede usarse tambin con metodologas ms clsicas. Anlisis de requisitos Caractersticas del anlisis antes de la existencia de tcnica alguna del tema: Monoltico, ambiguo, difcil de mantener y redundante. Posteriormente (aos 70 y 80) surge el anlisis estructurado moderno que es grco y soluciona algunos de los problemas anteriores. Su objetivo es modelar por separado los datos, procesos y el control usando como nexo comn el diccionario de datos. Tcnicas de representacin de requisitos 1. Diagramas de ujo de datos: Se describen los elementos de los que consta, lo que es el diagrama de contexto y heursticas para desarrollarlo. 2. Diagramas de ujo de control: Es similar a los DFD. 3. Diagramas de estados: Son un tipo de modelizacin matemtica usada tambin en diseo de circuitos, compiladores, etc. 4. Modelo Entidad / Relacin: Usado para representar los datos y la forma en la que se relacionan entre ellos. 5. Diccionario de datos: Se puede denir como el pegamento que mantiene unido a todo lo anterior. Es una descripcin detallada de los datos. Anlisis orientado a objetos Es la otra forma de ver el problema. Se representa el mundo en funcin sobre todo de los datos, caractersticas e interrelaciones entre ellos en vez de en funcin de los algoritmos o funciones. Propiedades de un sistema orientado a objetos: Abstraccin, Encapsulamiento, Modularidad, Jerarqua, Polimorsmo, Persistencia. Conceptos importantes: Clase, Objeto y Atributos. Sesin CRC: Es una simulacin hecha por personas del funcionamiento dinmico de un sistema orientado a objetos. Se basa en que cada persona representa una clase y su interaccin con las dems. Cada clase tiene escritas sus propiedades en una tarjeta. Identicacin de clases, atributos y relaciones entre clases. Renamiento del modelo: Consiste en otro conjunto de heursticas para eliminar elementos sobrantes o identicar otros nuevos en el modelo anterior.
46
Fase de requisitos
Validacin de requisitos Es la comprobacin de que todo el trabajo anterior se ha realizado bien. Bases de documentacin Es el documento que resulta de todo lo anterior pero orientado al cliente, es decir, a las obligaciones contradas con l, la idea no consiste en usar este documento como entrada para otra fase. Se ha tomado la plantilla de documento denida por el estndar IEEE 830.

1. Compare los diagramas del anlisis estructurado y los del UML. Existen similitudes? 1. Qu diferencia existe entre los requisitos que se obtienen en una sesin JAD y una sesin JRP? 2. Si se tiene que construir un sistema novedoso en el que los requisitos estn claros pero se tienen dudas tcnicas acerca de la mejor solucin discuta que tipos de sesiones seran las ms adecuadas. 3. Un videoclub tiene diferentes tipos de precios para sus pelculas en funcin de su categora. Cada pelcula tiene un cdigo y aunque haya varias pelculas con el mismo ttulo el cdigo es distinto para cada una. Los datos que interesa guardar de cada pelcula son: Ttulo, Director, Actores principales, Localizacin, Categora y Cdigo. Los clientes tienen asignado un Cdigo de cliente y se conoce tambin su Nombre, Direccin, Telfono. El videoclub hace prstamos a sus clientes por dos das y se podr sancionar a quien se retrase segn el nmero de das. Desarrolle los DFD que sea posible. Desarrolle la especicacin de los procesos.
Sobre la obtencin, anlisis y representacin de requisitos tambin se puede estudiar en [Som98, cap. 2 y 3], [Haw98, caps. 5 al 10] [Sch92, caps. 3 y 4]. Sobre el anlisis orientado a objetos tambin se puede ver [RBP 96]. El libro [GW89] completo es especco sobre requisitos. O UTREACH P ROJECT T OOL es una plataforma de libre distribucin para gestin de proyectos a travs de Web muy orientada al manejo de los requisitos y la comunicacin entre desarrolladores y clientes. Ver en http://outreach.sourceforge.net/ (hay enlace a una demo interactiva).
Captulo 4
Fase de diseo
Tutorial Previo
Introduccin
Una vez que se han identicado los requisitos para el problema, es necesario idear y componer la forma de la solucin para el problema. El diseo es la fase en la que se estudia el problema, se identican las caractersticas que tendra una solucin y se analiza a su vez cada una de esas caractersticas. En la fase de diseo es ms efectivo utilizar patrones y modelos conocidos para ir resolviendo partes del problema, es decir modularizar el problema y proyectarlo en mdulos en la solucin. Aunque, el proceso de diseo 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 intuicin de los diseadores. En este tema se van a proponer las formas de diseo convencionales, una comparacin de los ms utilizados y la validacin o comprobacin de su adecuacin, junto con la parte correspondiente de documentacin de todo el proceso. Principalmente hay dos tipos de diseo: Diseo funcional: Parte de una vista de alto nivel que se va renando progresivamente. En este caso la atencin se focaliza en la forma de procesar los datos. Diseo orientado a objetos: Se entiende el sistema como un conjunto de objetos. Para distinguirlos se identican los tipos de datos, sus operaciones y atributos asociados. Los objetos se comunican entre ellos envindose mensajes. La validacin del diseo comprueba si se siguen las especicaciones del diseo y se cumplen requisitos de calidad. La mejor forma de redactar la documentacin consiste en seguir una plantilla de un documento estndar rellenando varias secciones.

Para la comprensin de este tema es conveniente tener en mente los diferentes modelos de programacin que han ido estudiando en la carrera y que se utilizarn despus en la fase del tema siguiente. Tambin es necesario haber preparado el tema de requisitos para entender cules son los elementos de entrada en el diseo. Es necesario saber: descomponer un problema en otros ms pequeos, identicar las estructuras de datos necesarias e identicar ujos de datos entre subsistemas y cules son las entradas y salidas necesarias para cada subsistema.
Objetivos del tema

Se deben obtener los conocimientos sobre las tcnicas de diseo ms efectivas y utilizadas, junto con la comprensin de las diferencias entre esas tcnicas que permitan conocer cul es el mtodo ms apropiado en cada situacin. Se pretende en este tema introducir los dos tipos de mtodos que existen de disear un sistema y proporcionar un mtodo genrico para redactar la documentacin.

A la vez que se estudia el contenido terico 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 diseo es en gran medida ad hoc y depende de la experiencia de los diseadores. El mejor mtodo para aprender a disear es realizar todos los ejercicios propuestos (tanto explcitos, en el tutorial posterior, como implcitos o genricos mencionados anteriormente). Conceptos y elementos del diseo. El contenido de este apartado corresponde con [Pre01, cap. 13]. Diseo estructurado. Este apartado se estudiar en [Pre01, caps. 14 y 16] (o bien [Pre97, secs. 14.1 a 14.7 y 14.11] en la 4a edicin). Diseo orientado a objetos. Este apartado se estudiar principalmente [Pre01, cap. 22] (o bien [Pre97, cap. 21] en la 4 a edicin). 47
48
Fase de diseo
Validacin y conrmacin del diseo. Este apartado se incluye en esta misma gua. Documentacin: especicacin del diseo. Este apartado est contenido en [Pre97, sec. 13.8].
4.1. Conceptos y elementos del diseo

Partiendo de los requisitos para el problema, es necesario decidir cmo se va a realizar la solucin para el problema. Existen unos cuantos principios de diseo bsicos y elementos que se deben considerar antes de ponerse a decidir un diseo en particular. En primer lugar el principio de modularidad est presente en casi todos los aspectos del diseo al igual que en muchas otras reas de ingeniera. Junto con las especicaciones funcionales y de datos hay que considerar tambin el diseo de la interfaz y el acoplamiento de las diferentes partes. El contenido de este apartado se estudia en [Pre01, cap. 13].
4.2. Diseo estructurado

Para realizar el diseo de una solucin a un problema concreto se pueden utilizar diferentes enfoques, segn se basen en los datos en la funcionalidad o en la interaccin. En este tema se describen los dos mtodos ms utilizados: estructurado y orientado a objetos. El diseo estructurado con estilo procedimental (o funcional) descendente, en el cual se van renando y dividiendo los mdulos funcionales de la solucin, se basa en la utilizacin de los elementos: secuencia, condicin y repeticin. El contenido de este apartado se estudia en [Pre01, caps. 14 y 16] (o bien [Pre97, secs. 14.1 a 14.7 y 14.11] en la 4 a edicin).
4.3. Diseo orientado a objetos

El otro tipo de mtodos de diseo es el diseo orientado a objetos, que se basa en dividir jerrquicamente los elementos del diseo (objetos) y encapsular conjuntamente los datos con sus funciones de acceso, de forma que la interaccin se realiza por paso de mensajes entre los objetos. El contenido de este apartado se estudia en [Pre01, cap. 22] (o bien [Pre97, cap. 21] en la 4 a edicin).
4.4. Validacin y conrmacin del diseo

Para cerrar un paso en la fase de diseo es necesario hacer la validacin de los resultados obtenidos y comprobar si cumplen con las especicaciones de requisitos que eran la entrada a esta fase. Se trata de un conjunto de actividades para garantizar que se esta construyendo el producto correcto de la manera adecuada. Cada una de las actividades del diseo deben estar reejadas en los planes del mismo, estos planes se actualizaran cuando sea necesario para adaptarse a los cambios que vayan surgiendo pero cada cambio deber ser revisado y aprobado. Debe existir un procedimiento de control de diseo que especique cmo se planica y desarrolla. Por otra parte, la informacin de entrada al diseo, que es la resultante de la fase anterior debe incluir adems de los requisitos del usuario cosas tales como requisitos legales y regulaciones que se apliquen al proyecto. Las entradas al diseo deben tener en cuenta cualquier modicacin del contrato. Los resultados del diseo deben ser documentados de forma que se pueda hacer una vericacin y validacin de los mismos.
4.4.1. Revisin del diseo

Durante el proceso de diseo se deben planicar algunas revisiones formales del trabajo que se va realizando. Los participantes son todas aquellas personas involucradas en el diseo que se est revisando, as como representantes del cliente. Cuando nalice la revisin se debe redactar un documento con el resultado de la revisin y las partes afectadas. La forma de revisar el diseo estar documentada en el procedimiento de control del diseo.
4.4.2. Vericacin del diseo

Las actividades que se realizan son: Realizacin de clculos alternativos. Comparacin con diseos preliminares si es aplicable. Pruebas y demostraciones Revisin del diseo.
4.5 Documentacin: especicacin del diseo
49
4.4.3. Validacin del diseo

Garantiza que el producto cumple con los requisitos denidos por el cliente. Se realiza despus de la vericacin si esta fue satisfactoria. Una validacin se realiza en un entorno operativo normal. Tambin esto se realizar conforme al procedimiento de control del diseo.
4.5. Documentacin: especicacin del diseo

Evidentemente uno de los puntos ms importantes en la documentacin es la especicacin del diseo. Dado que el diseo tiene una gran componente de invencin, es necesario dejar muy claramente documentadas las decisiones y elementos utilizados en el diseo. Adems el diseo ser el elemento clave para la fase siguiente de implementacin que debe seguir elmente los dictados del diseo. Para dejar constancia de los diseos se deben utilizar lenguajes lo ms formales posible, como tablas, diagramas y pseudocdigo, que en algunos casos pueden permitir incluso la utilizacin de herramientas para automatizar parcialmente el proceso de construccin del cdigo en la siguiente fase de implementacin. El contenido de este apartado est incluido en [Pre01, sec. 13.8].
Tutorial posterior
El diseo es la fase que sigue a la especicacin y el anlisis. Consiste en aadir a la representacin anterior los detalle necesarios para pasar a la implementacin. Al igual que en el captulo anterior, existen 2 tipos de diseo: orientado a objetos y estructurado. Tambin existen diferentes formas de realizarlo en funcin de caractersticas del sistema (tiempo real, distribuido, etc.) Diseo arquitectnico: Independientemente del tipo de diseo (estructurado u orientado a objetos) hay una primera fase que consiste en la divisin del sistema en subsistemas. Los apartados a tener en cuenta son: 1. Descomposicin estructural: Descomposicin en subsistemas 2. Intercambio de informacin entre subsistemas: Hay dos opciones: con una base de datos central o por medio de mensajes. 3. Forma de realizar el control: Centralizado o basado en eventos. Sistemas distribuidos: Son un tipo especial de sistema que merece un tratamiento aparte debido a que parece ser la tendencia actual. Hay varios tipos de arquitecturas: 1. Arquitectura cliente-servidor: Puede ser de dos o de tres capas. 2. CORBA: Es un sistema de objetos distribuidos. Utiliza IDL como lenguaje de denicin de interfaces. {ATENCIN: CORBA No se trata en este curso, ver en [Pre01, cap. 28]} Diseo estructurado Es el anlisis clsico. Esta basado en el ujo de los datos a travs del sistema. En una primera fase se hace un diseo preliminar y posteriormente un diseo detallado. Objetivos: Comprensin, mantenibilidad, facilidad de pruebas e integracin con otras aplicaciones. Principios: Abstraccin, modularizacin, independencia, arquitectura, ocultamiento de la informacin y renamiento paso a paso. Sus elementos importantes son: 1. 2. 3. 4. 5. Mdulo: El rbol de mdulos dene las relaciones entre los mismos. Tabla de interfaz: Especica como son las comunicaciones inter-mdulos. Cohesin: Un mdulo es cohesivo si sus tareas se realizan con independencia del sistema pero relacionadas entre s. Acoplamiento: Media de la complejidad de las interfaces de un mdulo. Diagrama de estructuras: Es un mtodo de descomposicin funcional donde el bloque bsico es el mdulo. Es un rbol o diagrama jerrquico. Se denen en l: bucles, alternativas y subrutinas. 6. Heursticas de diseo: Consejos a aplicar. 7. Tipos de ujos de informacin: Flujos de transformacin y de transaccin.
Diseo detallado: Es una especicacin con mayor nivel de detalle de las estructuras de datos y algoritmos. Otras notaciones que forman parte de metodologas pensadas en torno al diseo estructurado son: 1. Diagramas HIPO: Muestran entradas, salidas y funciones. Muestran lo que hace el sistema pero no el cmo. {ATENCIN: los diagramas HIPO No se tratan en este curso}
50
Fase de diseo
2. Diagramas de Warnier-Orr: Son una representacin jerrquica de los programas, sistemas y estructuras de datos. Puede representar iteraciones, secuencias y alternativas. 3. Diagramas de Jackson: Produce un programa a partir de su especicacin. Las entradas y salidas son secuenciales al igual que el proceso. Diseo orientado a objetos Como se ha dicho antes, es la otra forma de hacer el diseo. Se incluye tambin en este resumen el diseo arquitectnico por ser parte integrante de la metodologa, aunque lo dicho en el apartado anterior dedicado al tema es igualmente vlido. Hay dos partes: 1. Diseo del sistema = (Diseo arquitectnico) 2. Diseo de objetos = (Diseo detallado) Patrones: Consisten en la identicacin de problemas usuales en el anlisis, diseo, codicacin, etc e incluir una plantilla de solucin. Frameworks: Son otro mecanismo de reutilizacin pero un framework se puede componer de varios patrones. Generan aplicaciones para un dominio. Validacin y conrmacin del diseo Son un conjunto de actividades que garantizan que el producto se est construyendo de la forma adecuada. Se compone de la revisin, la vericacin y la validacin del diseo. Documentacin Se incluye una plantilla para redactar el documento correspondiente al igual que en la fase anterior.

1. 2. 3. 4. Cules son las principales diferencias entre el diseo estructurado y el orientado a objetos? Por qu el diseo arquitectnico es el primer paso? Cules son los tipos de modelos cliente-servidor de tres capas? {Este ejercicio no se tratar en este curso} Qu es necesario para que un objeto pueda invocar los servicios de otro en CORBA? 5. {Este ejercicio no se tratar en este curso} Cul es la secuencia de pasos que ocurre cuando un cliente utiliza los servicios de un servidor en CORBA? Podra el servidor ser cliente de su cliente? 6. Qu nivel de acoplamiento hay entre dos mdulos A y B donde A utiliza una funcin de B pero ambos manipulan el mismo conjunto de variables globales?
Los contenidos de este tema tambin pueden estudiarse en [Som98, cap. 4], [Haw98, caps. 11 al 14] [Sch92, caps. 5 al 8]. Se puede profundizar en el diseo orientado a objetos, por ejemplo, en los libros [RBP 96, Mey98, Boo94, Jac92, WBWW90]. En http://www.nist.gov/dads/ se puede encontrar una recopilacin en forma de diccionario (en ingls) de descripciones y enlaces sobre algoritmos, estructuras de datos y problemas. Se puede encontrar informacin sobre CORBA (Arquitectura comn de distribucin de objetos) en [Pre01, sec. 28.9.5] y tambin en un curso (muy completo) en la pgina web http://www.openresources.com/es/magazine/tutoriales/corba/, aparte, por supuesto, de la pgina propia de CORBA http://www.corba.org/.
Captulo 5
Fase de implementacin
Tutorial Previo
Introduccin
Una vez que se dispone de un diseo para la solucin del problema, incluso en una fase temprana o provisional del diseo, ya se puede comenzar a plasmar ese diseo en el cdigo que permita realizarlo o implementarlo. En esta fase el programador recibe las especicaciones del diseo y transforma esas especicaciones, que pueden estar en formatos mezclados formales, semiformales o manuales, en un programa o mdulo que las efecte. Esta tarea de modicacin puede estar semi-automatizada en algunos casos o realizarse de forma completamente manual. En cualquiera de los casos se requiere que esa transformacin se haga de manera sistemtica y coherente. Las particularidades propias de lenguajes de programacin concretos se estudian en otras asignaturas y por tanto no se incluirn en este tema. Lo que s se estudiarn son las tcnicas o estilos de codicacin formal. Durante la implementacin se escribe el cdigo de la aplicacin. Existen una serie de "vicios" en el estilo de codicacin que pueden hacer que el cdigo sea confuso para terceras personas y en consecuencia difcil de mantener; adems, algunas prcticas 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 pequeos mdulos que se reparte entre individuos o pequeos grupos atendiendo a un grco de dependencias entre tareas y con la idea en mente de paralelizar tanto trabajo como sea posible. A medida que se van haciendo los mdulos 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 ejecucin correcta del mdulo, por tanto interesan las pruebas que se hacen a nivel de mdulo, tambin llamadas pruebas unitarias. Adems de todo ello hay dos tipos de manuales importantes que hay que producir en esta etapa: el manual de usuario y el manual tcnico.

En este captulo el alumno debe recordar los conocimientos sobre programacin 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 codicacin y la depuracin. Para comprender la problemtica asociada a la programacin es necesario conocer muy bien al menos un lenguaje de programacin y tener alguna experiencia con l. Se puede considerar que con las prcticas de programacin de cursos pasados es suciente.
Objetivos del tema

Los objetivos de este tema son resaltar la importancia de que la codicacin de los programas se haga de una forma ordenada, sistemtica y documentada, as como de la necesidad de realizar pruebas y depuracin de errores propios de la implementacin. Se busca aprender algunas recomendaciones para producir cdigo de calidad, poder entregar el cdigo en tiempo mnimo, poder dividir el trabajo resultante del diseo entre un grupo de personas y tener una plantilla para redactar documentacin para los manuales de usuario y tcnico.

Despus del estudio del contenido terico del tema, se deben realizar pruebas de codicacin con distintos estilos basndose en los mismos ejemplos mostrados, utilizando el lenguaje de programacin que mejor conozca o preera el alumno. En paralelo con el estudio del tema podra ser de inters que se desarrollara un pequeo proyecto de programacin donde se pusieran en prctica los conceptos desarrollados en el captulo. Para conseguir los objetivos es necesario no slo memorizar el contenido del captulo, sino asimilarlo hasta el punto de utilizarlo en la prctica habitual de la programacin. Sera ingenuo pensar que se puede conseguir esto en dos das, mas bien piense que tendr que poner en prctica los consejos propuestos durante un largo periodo de tiempo. La tarea de redactar una documentacin de calidad no es trivial, son necesarias aptitudes pedaggicas, de estilo de escritura, etc. De todas formas, aunque difcil, se puede considerar una tarea burocrtica, es decir, al nal lo que hay que hacer es seguir un manual de redaccin de manuales. Guas de estilo de codicacin. Este apartado se estudia directamente en esta gua. 51
52
Tcnicas de depuracin. El contenido de este apartado se encuentra en [Pre01, cap. 17] (o bien [Pre97, cap. 16] en la 4 a edicin). Documentacin del cdigo. El contenido se encuentra en esta gua.
5.1. Guas de estilo de codicacin

Dentro de los proyectos en los que trabajan varias personas debe haber una coherencia entre los programas escritos por diferentes programadores para facilitar la interaccin y la modicacin de los mismos. Por tanto desde el principio del proyecto debe estar claro el conjunto de normas y estilos que se utilizarn en la programacin: indentado (sangrado), nombres de variables, eleccin de estructuras, contenido de comentarios, distribucin de los fuentes, etc. Existen herramientas propias de la codicacin que incorporan automticamente la reescritura del cdigo segn determinadas normas estndar. La mayor parte del tiempo un programador lo pasa manteniendo cdigo. Si ese cdigo lo ha escrito l mismo puede tener serios problemas para ello, si lo han escrito terceras personas casi seguro que ser ms prctico rehacer todo ese cdigo porque tardar menos. El problema es que todos los que hemos escrito alguna vez un programa hemos adquirido una serie de malos hbitos. En este captulo se vern una serie de normas de escritura de cdigo fuente que dan un formato ms homogneo y por tanto ms fcilmente mantenible. Hay muchas propuestas sobre normas de estilo para diversos lenguajes, sobre todo para C y C++. Las empresas tienen sus propias normas, que suelen ser variantes de estndares publicados, por ejemplo, en este captulo se ver un resumen de las normas de Ellemtel Telecommunications Systems Laboratories para C++. Tambin veremos una recomendaciones de estilo de programacin en C y las normas denidas por S UN acerca de Java. Estas normas tampoco son las ordenanzas a seguir por todo aquel que quiera hacer un programa en alguno de estos lenguajes, pueden infringirse si se considera necesario pero explicando la razn. Por eso denimos esta primera regla: Cada vez que se rompa una norma se deber documentar el motivo.
5.1.1. Traduccin del diseo a la implementacin

Una vez terminado el diseo, la traduccin de ste a un lenguaje orientado a objetos no debe suponer mayores problemas porque las estructuras de estos lenguajes soportan los conceptos del diseo. La traduccin del diseo a la implementacin se llama ingeniera directa y puede ser parcialmente automatizada. La ingeniera inversa es el paso contrario, pasar de la implementacin al diseo y tambin puede ser automatizada. Lo expuesto en este apartado est bastante aceptado en general y se puede encontrar tambin en otros sitios (p. ej. [RBP 96, JBR00a]).
Casos de uso Los casos de uso son una descripcin del funcionamiento de un sistema. No se les puede aplicar la ingeniera directa o inversa para generar cdigo o para obtener casos de uso a partir del cdigo como al resto de diagramas en UML, pero veremos un conjunto de instrucciones para averiguar cules son los casos de uso de un sistema a partir de su comportamiento (ingeniera inversa). Se identican los actores que interactan con el sistema. Se investiga la forma en la que el actor interacta con el sistema. Puede cambiar su estado o el de su entorno o responde a un evento. Se traza el ujo de eventos de un sistema relativos a cada actor. Primero se consideran los ujos principales y luego los alternativos. Identicar casos de uso que se puedan fusionar y los que tengan relaciones de uso o de extensin entre ellos. Se representan los actores y casos de uso identicados en un diagrama. Deniciones de clases Es el primer paso para implementar el diseo. En general, para convertir un diagrama de clases en su equivalente en un lenguaje, lo primero es identicar las reglas de correspondencia al lenguaje de programacin. Puede ocurrir que no exista una forma de hacer la correspondencia, por ejemplo, en Java no existe la herencia mltiple, con lo que, o bien se prohibe a los diseadores usarla, o bien se busca algn subterfugio para poder implementar esa caracterstica, lo que aadir complejidad. Los atributos y operaciones que se han denido en el diseo se tienen que denir dentro de la clase correspondiente como pblicos, privados o protegidos, aunque este aspecto es probable que se haya denido en el diseo. Hay que denir tambin su tipo. Denicin de clases en C++ Una ejemplo de clase en C++:
class Punto { private: // Aqu se definen las variables y mtodos privados.
5.1 Guas de estilo de codicacin
53
// Ninguna otra clase puede acceder a ellos. int x; // Variables privadas int y; protected: // Variables y mtodos protegidos. Solo la propia clase // y las que hereden de ella pueden acceder a ellos. public: // Variables y mtodos pblicos. Accesibles por todos. Punto() { ... } // constructor Punto(int x,int y) // otro constructor ~Punto() { ... } // destructor } No puede haber atributos o mtodos con el mismo nombre. Los atributos y mtodos de un tipo (privado, protegido o pblico) se declaran juntos en su bloque correspondiente. Existe un mtodo pblico sin valor de retorno llamado constructor que tiene el mismo nombre de la clase y debe ser denido obligatoriamente. Denicin de clases en Java Una clase en Java: class Punto { private int x; // Variables privadas private int y; public Punto(int x,int y);// Constructor public Punto(); // Otro constructor } Creacin y destruccin de objetos Un objeto es una instancia de una clase y cuando se crea una se reserva espacio de memoria. Cuando el objeto deja de existir, o bien se programa explcitamente la secuencia de acciones que hay que realizar, lo cual es una actividad propensa a errores, o bien existe un mecanismo automtico que va eliminando los objetos que no estn referenciados por ningn otro. Creacin y destruccin de objetos en C++ Los constructores son los mtodos que inicializan un objeto una vez que se ha reservado memoria para l. Puede haber varios que reciben diferente nmero y tipo de parmetros. La asignacin de memoria se puede hacer de tres formas: Preasignados en memoria global ja (static), en la pila (automatic) y en el cmulo o heap (dynamic). Ejemplo: Punto *p=new Punto(100,30); // Memoria dinmica Punto p(100,30); // Memoria de pila static int j; // Memoria global fija Puede existir un mtodo antagnico al constructor llamado destructor, tambin con el mismo nombre que el constructor pero precedido de ~ y que es invocado de forma automtica antes de liberar la memoria que ocupa el objeto. Creacin y destruccin de objetos en java Hay pocas diferencias respecto a C++; los constructores siguen las mismas reglas y para destruir un objeto se invoca un recolector de basura cuando no queda memoria para liberar la de los objetos que ya no estn referenciados por ningn otro objeto. Tambin se puede implementar un destructor utilizando la palabra finalize, que se invoca justo antes de ser destruido por el recolector de basura (garbage collector). Ejemplos: Un objeto se crea del siguiente modo: Punto p = new Punto(100,30); Un destructor en Java: protected void finalize() { System.out.println(Este objeto ser procesado por el garbage collector); }; Invocacin de mtodos Para llamar a un mtodo se indica al menos el nombre del objeto y el del mtodo, que puede tener parmetros o no.
54
Invocacin de mtodos en C++
Ejemplo: Tenemos el mtodo DesplazarHorizontalmente de la clase Punto.
Punto *p1, p2; ... // Invocacin de los mtodos p1->DesplazarHorizontalmente(10); p2.DesplazarHorizontalmente(25); Existe un puntero this que hace referencia al propio objeto. Si se recibe un parmetro con el mismo nombre que una variable denida en el objeto, se puede acceder a la variable del objeto utilizando ese puntero this: void Punto::DesplazarHorizontalmente(int x) { this->x = this->x + x; } Invocacin de mtodos en Java La notacin en java es igual pero sin la versin con punteros.
p.DesplazarHorizontalmente(10); Uso de la herencia La herencia es esttica si se determina en el momento de la compilacin, como ocurre en la mayora de los lenguajes, es implcita si el comportamiento de un objeto depende de su clase y no se puede cambiar y es por grupos si las caractersticas de herencia se especican para una clase, no para objetos concretos. Herencia en C++ Una clase puede heredar de varias clases que se especican en la declaracin. La subclase se llama derivada. La forma de heredar puede ser privada, protegida o pblica. El resultado de esto es que los mtodos y variables de la clase antecesora se heredan con el tipo de acceso de menor grado, por ejemplo, una variable pblica que pertenece a una clase que se hereda de modo protected se convierte en protected. Ejemplo de la sintaxis: class Punto: public ObjetoGrafico { ... } Herencia en Java Est mucho ms limitada. Slo existe herencia simple, aunque una clase puede implementar mltiples interfaces y las interfaces pueden heredar de mltiples interfaces. Ejemplo: class Punto extends ObjetoGrafico { ... } Implementacin de asociaciones Existen dos formas: punteros y objetos de asociacin. Lo normal es que el lenguaje no tenga denida esta ltima opcin. Ejemplo: Supongamos que tenemos denido un objeto Recta, que se forma a partir de dos objetos Punto que dene el usuario pinchando en la pantalla, y queremos asociar los dos puntos a la recta. El objeto recibe los dos puntos en su constructor (ver gura 5.1).
Recta Consta de 1 2 Punto
Figura 5.1: Asociacin entre recta y punto
Implementacin en C++ objetos Punto recibidos:
En la implementacin del constructor se copian a los dos punteros de la clase las direcciones de los
class Recta { private: Punto *p1,*p2; public: Recta(Punto *p1,Punto *p2) {this->p1=p1; this->p2=p2; }; ... }
55
Implementacin en java El puntero est en el lado de la asociacin que necesita acceder a la otra clase, es decir, si es navegable en ambos sentidos estar en ambas clases: class Recta { Punto p1,p2; Recta(Punto p1,Punto p2) this->p1=p1; this->p2=p2; } ... } El problema ahora es: Qu se hace si se tiene una relacin con una cardinalidad indeterminada, o lo que es lo mismo, puede haber muchos objetos en el otro lado relacionados con una clase dada?. La respuesta es que si la cardinalidad es alta pero est acotada se puede implementar con un array de punteros. Si no est acotada se puede tener un conjunto de punteros en una clase contenedora que puede crecer de forma arbitraria.
5.1.2. Estilo de programacin orientado a objetos

Veremos las directrices generales a seguir para que el cdigo sea reutilizable, extensible, robusto y utilizable en grandes sistemas [RBP 96, cap. 14].
Reusabilidad La ventaja de la reutilizacin es que la cantidad de cdigo se reduce por lo que la comprensin del mismo tambin es ms sencilla. Es ms sencillo reutilizar cdigo en lenguajes orientados a objetos debido a que los mdulos son ms cohesivos y menos acoplados. El inconveniente es que escribir cdigo reutilizable es ms difcil y siempre va a requerir un esfuerzo adicional. Existen dos tipos de reutilizacin: Dentro de un mismo proyecto pueden existir partes redundantes, se trata de descubrirlas y compartirlas por los mdulos que las usen. Reutilizar cdigo de un proyecto antiguo en proyectos nuevos. Es ms complicado que el punto anterior, requiere que el cdigo haya sido escrito siguiendo una pautas que ahora veremos. Reglas generales de estilo para escribir cdigo reutilizable: Construir mtodos cohesivos. Un mtodo es cohesivo si realiza una nica funcin o varias ntimamente relacionadas. En caso contrario hay que dividirlo. Mtodos pequeos. Un mtodo es grande si sobrepasa una o dos pginas, en cuyo caso habr que dividirlo, con lo que adems de hacerlo ms sencillo puede que uno de los trozos sea reutilizable. Mantener la congruencia de los mtodos. Un mtodo se dice que es congruente si tiene un nombre similar a mtodos similares, condiciones, orden de argumentos, valor proporcionado y condiciones de error. Separar la poltica de la implementacin. Los mtodos de poltica son los de alto nivel y toman decisiones de control. Son dependientes de la aplicacin, se entienden y se escriben fcilmente. Son los mdulos que deben comprobar el estado y los errores. Los mtodos de implementacin son los que hacen el trabajo sucio, es decir, son los que tienen denidos los algoritmos, pero no son los que toman la decisin de ejecutar o no esos algoritmos. Si encuentran un error durante la ejecucin deben dar un informe a los mdulos superiores, pero no deben tomar acciones por su cuenta, como son mtodos autocontenidos son fcilmente reutilizables. Proporcionar una cobertura uniforme. Consiste en redactar mtodos que sean capaces de tratar todas las combinaciones de las posibles entradas que se puedan dar, y no slo las actuales. Generalizar los mtodos. Es similar al punto anterior pero en referencia al modo de funcionamiento y al contexto. Cuando los valores estn vacos o sean extremos o estn un poco ms all del lmite. Evitar el acoplamiento. Por ejemplo, el que se da cuando se accede a objetos globales y hay que tener conocimiento de los mismos para poder utilizarlos. Evitar los modos. Una operacin con modos tiene una forma de funcionamiento segn el modo en el que est. Lo aconsejable es tener un mtodo distinto para cada modo. Herencia Otra forma de reutilizar es escribir cdigo de forma que se pueda heredar. Las reglas de estilo en este sentido son: Mtodos comunes: Se pone el cdigo comn en un mtodo al que invocan los diferentes mtodos. Si ese cdigo comn est en varias clases se pone en un mtodo de una clase antecesora. Factorizacin. Cuando tenemos dos mtodos muy parecidos de clases diferentes se puede utilizar otra aproximacin: El cdigo comn se pone en un mtodo distinto de una clase antecesora, y es ese mtodo el que, en funcin de la clase en la que estemos llama a un mtodo u otro. Es corriente utilizar la factorizacin con clases abstractas. En el siguiente ejemplo de C++, los mtodos A y C son comunes, pero el B es propio de cada clase:
56
class Comun { public: A() { ... } C() { ... } virtual B() { ... } MetodoComun() { A(); B(); C(); } } class X:public Comun { B() { ... } } class Y:public Comun { B() { ... } } Delegacin. Si se tiene que ejecutar un mtodo en una clase A que ya est implementado en la clase B, heredar de B slo para poder utilizar su mtodo es un error, en vez de eso se delega enviando la operacin a B desde A. Cdigo externo encapsulado. Si se utiliza cdigo de otra aplicacin con una interfaz diferente, en vez de hacer llamadas directas a ese cdigo es mejor hacer un mtodo o una clase que se encargue de ello. De esta forma, si hay que hacer modicaciones, estas estarn ms localizadas. Extensibilidad Consiste en aadir nuevas funcionalidades al cdigo. Veamos un conjunto de normas a seguir para facilitarla. Encapsular las clases. Esto signica que slo una clase puede acceder a sus propios datos e implementacin. Ocultar las estructuras de datos. El motivo es que las estructuras de datos son propias de los algoritmos. Si se hacen pblicas ser ms difcil cambiar el algoritmo ms adelante. Ley de Demeter : Evitar recorrer mltiples enlaces o mtodos. Si a travs de las asociaciones un mtodo llega a una clase vecina, no deben utilizar los enlaces de sta para acceder a una tercera clase, ms bien debera utilizar un mtodo de su clase vecina para esta operacin, de esta forma no es necesario que el mtodo tenga conocimiento de todas las asociaciones del modelo, slo de las clases relacionadas con la propia. Evitar sentencias case basadas en el tipo de objeto. En su lugar se pueden utilizar mtodos. Solo se deben usar esas sentencias si van a tener en cuenta los atributos de cada objeto. Distinguir los mtodos pblicos de los privados. Se debe minimizar el nmero de mtodos pblicos para disminuir la complejidad de la interfaz y porque si se modican esto afectar a las clases que los utilicen, por eso deben ser diseados con ms cuidado. Los mtodos privados aaden modularidad, dependen de la implementacin de la clase y pueden modicarse sin que cause efectos secundarios fuera de la clase. Robustez Un mtodo es robusto si no falla incluso ante parmetros incorrectos. Directrices para construir programas robustos: Proteccin contra errores. Debe tenerse en cuenta que el usuario puede producir entradas incorrectas. El sistema debera dar un mensaje de error y no colgarse. El sistema operativo, el hardware u otra librera pueden contener errores tambin, para lo cual se deben instalar comprobaciones internas. Las comprobaciones de errores aumentan el tamao y la lentitud del cdigo. Las relativas al usuario deberan estar siempre, las dems pueden eliminarse en la versin nal que se entregue. Optimizar despus de que funcione el programa. Evitar los lmites predenidos. Es decir, utilizar memoria dinmica en vez de estructuras de datos de tamao jo. Esto da ms exibilidad (y algn que otro error). Disponer el programa para la depuracin y la monitorizacin del rendimiento. En funcin de las facilidades suministradas por la herramienta de programacin, tendremos que aadir sentencias de depuracin, que se ejecutan en funcin de una variable que indique el nivel de depuracin. Tambin es posible aadir cdigo que recoja estadsticas sobre por ejemplo el nmero de invocaciones a una funcin. Grandes sistemas No es lo mismo trabajar solo que en un grupo, hay que pensar en que son otras personas las que van a utilizar, depurar, modicar o mantener el cdigo. Las directrices que se indican son aplicables tambin para un proyecto unipersonal. No empezar a programar de forma prematura. Es decir, antes de empezar el proceso de implementacin hay otras cosas como la especicacin o el diseo.
57
Crear mtodos comprensibles. Un mtodo es comprensible si terceras personas pueden entender lo que hace. Hacer que los mtodos sean legibles. Esto signica:
Que los nombres de las variables sean signicativos (mejor no utilizar abreviaturas). Evitar un nivel de anidamiento excesivo. No utilizar una misma variable temporal para diferentes propsitos en lugares diferentes. Comprobar la ortografa de los nombres.
Utilizar los mismos nombres que en el modelo de objetos Seleccionar cuidadosamente los nombres. Deben ser descriptivos y no ambiguos para no llevar a confusin. No se debe asignar nombres iguales a mtodos semnticamente distintos. Para los mtodos se puede tomar como procedimiento de asignacin de nombres el formato nombre_objeto, por ejemplo, borrar_pantalla. Dos clases que tengan mtodos con el mismo nombre deberan tener un mismo ancestro y los mtodos la misma signatura, es decir, el mismo nmero y tipo de parmetros. Utilizar normas comunes de programacin. En referencia a cosas tales como la indentacin de prrafos, forma de hacer los comentarios, poner todos los nombres en minsculas, etc. Documentar las clases y mtodos. Deben existir comentarios en la cabecera de cada clase o mtodo para explicar su cometido, precondiciones y postcondiciones. As mismo debe haber aclaraciones dentro de cada mtodo acerca de los pasos seguidos en los algoritmos. En los apartados siguientes se presentan una serie de normas de estilo para lenguajes concretos.
5.1.3. Normas para programadores en C

Organizacin de cheros En general un chero no debe tener ms de 1000 lneas y las lneas no deben ser demasiado largas (80 caracteres o ms). Nombres de cheros Tienen un nombre base y una extensin, .c para el C, .o para cdigo objeto, etc. Hay cheros con nombres reservados como README Makele (en sistemas UNIX). Organizacin de los cheros de cdigo fuente (.c) Este es el orden sugerido de secciones para un mdulo: 1. Un prlogo que indique: Descripcin del propsito de los objetos en los cheros. Informacin de gestin, p. ej. informacin del control de la revisin o fecha de la ltima modicacin. (Esta informacin es opcional) Autor. (Opcional) 2. Ficheros .h. Si la razn de que se incluya un chero no es obvia debe explicarse. En ocasiones cheros como stdio.h deben incluirse antes que los del usuario. 3. Denes (macros de constantes, macros de funciones), typedef y enum, por este orden. 4. Declaraciones de datos (externas) en este orden: extern, globales no estticos, globales estticos. Si un conjunto de #dene se aplica sobre unas lneas de cdigo, esos #dene deben estar justo antes de esas lneas de cdigo o embebidas en la declaracin de estructuras y correctamente indentados (sangrados). 5. Las funciones van la nal en algn orden lgico. Por ejemplo: se ponen juntas las funciones con un grado similar de abstraccin. Organizacin de los cheros de cabecera (.h) Son cheros que se incluyen dentro de otros antes de la compilacin por el preprocesador. Contienen declaraciones de datos y denes necesarios para ms de un chero. 1. Organizacin: Tienen que estar organizados de un modo funcional, es decir, las declaraciones para subsistemas diferentes deben estar en cheros de cabecera distintos. Si un conjunto de declaraciones va a ser cambiado cuando se porte el sistema a otra plataforma, debera tambin en este caso estar en un .h aparte. 2. Los nombres deben ser distintos de los de las libreras del sistema, como math.h. No se deben usar nombres de ruta completas, es mejor utilizar las opciones del compilador para indicar el directorio especco o la opcin -I (para indicar el directorio de las cabeceras en algunos compiladores).
58
3. Las cabeceras que denen funciones o variables externas deben ser incluidas en los cheros que las denen para de esta forma hacer comprobacin de tipos y que las variables externas siempre sean consistentes con la denicin. 4. No se deben denir variables en un chero de cabecera. 5. No debera haber cheros de cabecera anidados. Si es as, se debe poner en el prlogo que cheros de cabecera son necesarios. 6. Para evitar incluir la misma cabecera ms de una vez se debe usar la siguiente estructura: #ifndef EJEMPLO_H #define EJEMPLO_H /* Cuerpo de EJEMPLO.H */ #endif Otros cheros El chero README debe tener una descripcin del proyecto completo. Puede tambin explicar detalles tcnicos acerca del Makele, una lista de cheros dependientes del hardware especco de la mquina, etc. Comentarios Cuando el cdigo y los datos se contradicen probablemente ambos estn mal - Norm Schryer 1. Los comentarios deben describir qu est pasando, cmo se est haciendo, qu signican los parmetros, qu variables globales se estn usando y cualquier restriccin o error. Los comentarios cortos (una lnea) son para expresar el qu. El cmo se escribe en unas cuantas lneas que preceden al algoritmo. 2. Los comentarios deben justicar el cdigo que parezca errneo o poco razonable. 3. Las descripciones de estructuras de datos o algoritmos deben hacerse en bloques de comentario de esta forma: /* * Comentario */ 4. Los comentarios dentro de una funcin deben estar correctamente indentados con el cdigo que comentan. Pueden usarse tanto comentarios de una lnea como de varias. Si el comentario es muy corto se puede poner seguido a una lnea de cdigo, y si aparecen varios comentarios de este tipo deben estar a la misma altura. Declaracin de variables 1. Las declaraciones globales se ponen en la primera columna. Las declaraciones externas de datos deben ir precedidas por la palabra extern. Los lmites de los arrays hay que repetirlos en la declaracin extern. 2. El * de la declaracin de punteros debe estar junto a la variable y no en el tipo. Mal: char* s,t,v; Bien: char *s, *t, *v; 3. Las declaraciones de cosas que no tengan que ver entre s deben hacerse por separado. 4. Las llaves para abrir { deben ir en la misma lnea que en los struct typedef y la llave para cerrar } en la lnea siguiente. Ejemplo: struct complejo { real a, b; }; 5. Las variables que deban tener un valor inicial se deben inicializar todas de forma explcita. 6. Cuando un chero es parte de un todo en vez de ser un programa autocontenido se debe utilizar la palabra static para hacer las funciones y las variables locales a los cheros. Una variable debe poder ser accedida desde otro chero slo cuando sea realmente muy necesario y se deber comentar. 7. Los tipos ms importantes deben ser remarcados usando typedef. 8. El tipo de retorno se debe declarar siempre. Declaracin de funciones Cada funcin debe llevar un prlogo que indique lo que hace la funcin y cmo usarla. Tambin es conveniente aclarar decisiones de diseo no triviales. Se debe poner un tipo de retorno para cada funcin. No usar el tipo int por defecto. Si hay que explicar ese tipo, se hace en el prlogo.
59
Los diez mandamientos para los programadores en C Estas son una serie de normas para no cometer (demasiados) errores. 1. Se debe utilizar alguna herramienta como lint 1 de vez en cuando. 2. Comprobar siempre si un puntero es NULL. 3. Siempre se debe hacer un casting de los argumentos de las funciones a los tipos esperados, incluso cuando creas que no es necesario. 4. Se debe declarar con mucho cuidado los tipos de retorno de las funciones en los cheros .h. 5. Comprobar que el tamao de las cadenas es lo sucientemente grande como para que quepa cualquier cosa (si se prueba una cadena con hola ten la seguridad que llegar el da en el que alguien escribir supercalifragilisticoespialidoso. 6. Si una funcin puede devolver un cdigo de error, lo comprobars cada vez que llames a esa funcin, aunque tripliques el tamao del cdigo. 7. Estudiars las libreras para asegurarte de no inventar nada que ya exista, as tu cdigo ser corto y legible. 8. Indentars (sangrars) correctamente tus programas para que su estructura sea clara. 9. Los identicadores externos debern ser nicos desde sus primeros seis caracteres. 10. Escribirs cdigo independiente del hardware de la mquina especca en la que programes, porque los das de esa mquina llegarn a su n antes que los de tu programa.
5.1.4. Normas para programadores en C++

A continuacin veremos un conjunto de reglas y recomendaciones para escribir cdigo en C++. Estas normas son las denidas por Ellmentel Telecomunications Systems Laboratories. La nalidad de este apartado es que el cdigo sea correcto y fcil de mantener. Para conseguir estos objetivos el programa debera: Tener un estilo consistente. Ser fcil de leer y comprender. Ser portable a otras arquitecturas. No tener algunos tipos de errores comunes. Ser mantenible por gente diferente. Las normas tienen dos partes: Las reglas, que no deberan ser infringidas mas que por motivos muy serios y las recomendaciones, que pueden tomarse como consejos. Ficheros de cdigo fuente Estructura del cdigo Reglas: Las extensiones de los mismos tipos de cheros sern siempre las mismas. Ejemplo: Include: .h .hh, fuente: .cc, cheros inline: .icc. Excepcin: Cuando se utilicen mdulos de C, que no tienen las mismas extensiones. Los cheros de implementacin tienen la extensin .cc. Excepcin: Hay compiladores que slo aceptan la extensin .c. Los cheros de denicin inline tienen la extensin .icc. La nalidad es dar una visin uniforme de los nombres de chero y distinguir entre los diferentes tipos, entre los de C y los de C++ y entre los de denicin y los de implementacin. Recomendaciones: Un chero include no debe contener ms de una denicin de clase. Dividir la denicin de las funciones miembro entre tantos cheros como sea posible. Colocar el cdigo dependiente de la mquina en un mdulo aparte. Nombre de los cheros Se trata de evitar las colisiones de nombres. Recomendaciones:
Dar siempre nombre de cheros que sean nicos en un contexto tan grande como sea posible. El nombre de un chero include de una clase debera ser: NombreClase + extensin. Respetar las maysculas y minsculas del nombre de la clase en el nombre del chero.
1 Utilidad para programadores en C en UNIX que permite detectar declaraciones no usadas, inconsistencias entre tipos, uso de variables antes de su denicin, cdigo no alcanzable, caminos de ejecucin sin retorno, etc
60
Comentarios
Reglas:
Cada chero con cdigo fuente debe tener una introduccin con informacin sobre el contenido de ese mdulo. Todos los cheros deben tener copyright. Todos los comentarios se deben escribir en Espaol. Recomendaciones: Escribir un breve comentario antes de cada funcin. Es mejor usar // para los comentarios. Hay que tener en cuenta que los comentarios de los cheros include van dirigidos a los usuarios de las funciones o clases, y los de los cheros de implementacin a los que mantienen el cdigo. Ficheros include Reglas:
Todos los cheros include tienen que contar con algn medio que impida mltiples inclusiones de ese archivo. Los siguientes tipos de deniciones deben estar en cheros include separados:
Clases que se usan como clases base. Clases que se usan como variables miembro. Clases que aparecen como tipos de retorno o como tipos de argumento en prototipos de funciones o funciones miembro. Prototipos de funciones para funciones o funciones miembro usados en funciones inline miembro que estn denidas en el chero.
Las deniciones de clases a las que slo se accede va puntero (*) o referencia (&) no sern incluidas como include. Nunca especicar las rutas completas en las directivas #include. Cada chero de implementacin deber incluir:
Declaraciones de tipos y funciones usados en las funciones que se implementen en el chero. Declaraciones de variables y funciones miembro usados en las funciones que se implementen en el chero.
Recomendaciones: Usar la directiva #include nombre_de_fichero.hh para los include denidos por el usuario. Usar la directiva #include <nombre_de_fichero.hh> para los include de las libreras. Cada chero de implementacin debera declarar una constante con una variable de cadena que describa el chero, as, en un sistema UNIX el comando what podr ser usado para obtener informacin del chero. Nunca incluir otros cheros en un chero inline. Asignacin de nombres Un identicador consta de: Prejo, Nombre y Sujo. El prejo y el sujo son opcionales. El sujo suele ser utilizado por herramientas que generan cdigo. Reglas: El identicador de cada clase, tipo enumerado, funcin, constante o variable globales en una librera de clases debe empezar con un prejo que sea nico para cada librera. Los nombres de las variables, constantes y funciones deben empezar en minsculas. Los nombres de los tipos abstractos de datos, estructuras, typedef y tipos enumerados deben empezar en maysculas Los nombres que consistan en ms de una palabra, las palabras deben ir juntas y la inicial de cada palabra debe ir en maysculas. No usar identicadores que comienzan con _. Si un nombre comienza por mayscula aparece despus de un prejo. Si un nombre no empieza por mayscula estar separado de su prejo por _. Recomendaciones: No usar nombres que slo dieran en que una letra sea mayscula o minscula. Los nombres no deben incluir abreviaturas que no sean aceptadas por todo el mundo. Una variable visible en un trozo grande de cdigo debe tener un nombre largo. Los nombres de las variables deberan recordar para qu sirven. Se debe escribir el cdigo de forma que sea fcil cambiar los prejos de los identicadores globales. Encapsular en una clase: las variables y constantes globales, tipos enumerados y typedef.
61
Estilo Clases Reglas:
Las partes de una clase de declaran en este orden: Pblico, protegido y privado. Este es adems el orden que interesa a la gente. La parte privada la va a leer cualquiera que use la clase, la parte protegida quien quiera heredar y la privada en general nadie. No se denen funciones miembro dentro de la denicin de la clase. Funciones Recomendaciones:
Dar siempre explcitamente el tipo de retorno de cada funcin. El primer parmetro de la funcin va en la misma lnea que el nombre y si todos los dems caben en esa lnea se ponen, en caso contrario se escribe uno por lnea. Escribir el tipo de retorno de cada funcin en una lnea aparte. Escribir el parntesis izquierdo despus del nombre de la funcin, es decir, que no haya un carcter en blanco. Ejemplo: int buscarLista(int intElementos, cadena *cadenaPunteroLista, cadena cadenaBuscada); Bloques Recomendacin: Los corchetes que delimitan el comienzo ({) o el nal (}) de un bloque deben ir en lneas aparte.
Sentencias de control de ujo Recomendacin: Todas las sentencias de control de ujo (if, else, while, for) deben ir seguidas de un bloque incluso aunque sea vaco. Ejemplo: for (char *c=charCadena; *c!=A && *c; c++) { } Punteros y referencias Recomendacin: Los operadores * y & deben estar conectados directamente con el tipo de la variable y no con la variable misma. Ntese que la recomendacin para el lenguaje C es justamente la contraria. Miscelnea Recomendacin: No usar espacios alrededor de . -> ni entre operadores u operandos unarios. Clases Derechos de acceso Regla: No especicar nunca un dato como pblico o protegido. Los motivos son que: Slo la propia clase podr manipular esa variable (encapsulacin). Cualquier funcin del programa podra cambiar ese valor provocando errores. Evitando que se modique externamente una variable, se evita tambin que quien modique esa variable deba tener en cuenta la implementacin de la clase. Funciones inline Una funcin inline es aquella cuyo cdigo compilado se sita donde se utiliza, de esta forma no se hace la llamada y se consigue ms eciencia. Recomendaciones: Las funciones de acceso deben ser inline. (Una funcin de acceso slo devuelve un valor de un dato miembro). Las funciones que slo llaman a otra funcin deben ser inline. Los constructores y destructores no deben ser inline. Funciones friend de la clase. Recomendacin: Las funciones amigas estn para proporcionar funciones adicionales que estn mejor fuera
Funciones miembro const Reglas: Una funcin miembro que no cambie las variables de instancia de un objeto se debe declarar const. Si el comportamiento de un objeto depende de datos externos al objeto, estos datos no deben ser modicados por funciones miembro const.
62
Constructores y destructores
Reglas:
Una clase que use new para crear instancias gestionadas por la clase debe denir un constructor de copia. Excepciones: Si una clase tiene un rea de datos compartida no es necesario tener un constructor de copia, tan slo hay asegurarse de que no se destruya el rea mientras haya punteros que la referencien. Todas las clases que sean usadas como clase base y que tengan funciones virtuales deben denir un destructor virtual. No usar objetos globales en constructores y destructores. Operadores de asignacin Reglas:
Una clase que usa new para crear instancias gestionadas por la clase debe denir un operador de asignacin. Excepcin: Si los objetos de una clase tienen un rea de datos compartida no es necesario denir un operador de asignacin. Hay que asegurarse de que el rea de datos no se destruye mientras haya punteros que la referencien. Un operador de asignacin que hace una operacin destructiva debe protegerse de realizar esta accin en el objeto en el que est operando. Recomendacin: Un operador de asignacin debe devolver una referencia const al objeto que est siendo asignado. Sobrecarga de operadores Recomendaciones:
Usar la sobrecarga de operadores de un modo uniforme a lo largo de todo el programa. Cuando se dene un operador y tambin se usa la funcin opuesta es conveniente denir ambos (por ejemplo, == y !=). Tipos de retorno de las funciones miembro Reglas: Una funcin pblica miembro no debe devolver nunca una referencia no constante o un puntero a datos miembro. Una funcin pblica miembro nunca debe devolver una referencia no constante o punteros a datos fuera del objeto a menos que el objeto comparta datos con otros objetos. Herencia Recomendaciones: Si un objeto se compone de otros, no utilizar la herencia para reejar este tipo de relaciones. Dar acceso a las clases derivadas a los tipos de datos miembro con funciones protected de acceso. Clases plantillas Recomendaciones: Hay clases plantilla que no pueden ser creadas usando un tipo determinado por incompatibilidades con la implementacin de los mtodos. Como el compilador no detecta este tipo de cosas, hay que tener cuidado. Hay que tener cuidado con las deniciones mltiples de funciones sobrecargadas junto con la instanciacin de clases plantilla. Por ejemplo, si denimos una funcin con un tipo determinado y esa misma funcin la sobrecargamos con el tipo denido en la plantilla podramos tener dos funciones idnticas. Funciones Estas reglas son aplicables a las funciones miembro. Argumentos de las funciones Recomendaciones: Regla: No usar argumentos sin especicar (elipsis).
Evitar funciones con muchos argumentos. Si una funcin almacena un puntero a un objeto que es accedido a travs de un argumento, dejar que el argumento sea del tipo del puntero. Usar referencias constantes (const &) en vez de llamadas por valor a menos que se estn usando tipos de datos predenidos o punteros Sobrecarga de funciones Recomendacin: Cuando se sobrecargan funciones, todas las variaciones deben tener la misma semntica (son usadas para el mismo propsito). Argumentos formales en la declaracin. Regla: Los nombres de los argumentos de las funciones tienen que ser los mismos en la denicin y
63
Tipos de retorno y valores Reglas: Especicar siempre el tipo de retorno de una funcin explcitamente. Una funcin pblica nunca debe devolver una referencia o un puntero a una variable local. Funciones Inline Regla: No usar la directiva del preprocesador #define para obtener cdigo ms eciente. En lugar de eso usar funciones inline. Recomendacin: Usar funciones inline slo cuando sean realmente necesarias. Objetos temporales Recomendacin: Minimizar el nmero de objetos temporales que son creados como valores de retorno de funciones o como argumentos a funciones. General Recomendacin: Evitar funciones largas y complejas. Constantes Reglas: Las constantes deben ser denidas con const o enum. Nunca usando #dene En lugar de utilizar valores numricos en el cdigo usar valores simblicos. La excepcin seran los valores numricos comnmente utilizados y con signicado claro tales como 0, 1, true false. Variables Reglas: Las variables deben ser declaradas con el mnimo alcance posible. Cada variable debe ser declarada en una sentencia distinta. Se debe dar un valor a cada variable que sea declarada antes de usarla. Si es posible usar siempre la inicializacin en vez de la asignacin. Excepcin: Cuando se asigna a una variable el valor de una expresin complicada puede no ser necesario dar un valor inicial. Punteros y referencias Reglas: No comparar un puntero con NULL o asignar NULL a un puntero. Usar 0 en su lugar. Deben evitarse en la medida de lo posible los punteros a punteros. Usar typedef para simplicar la sintaxis cuando se declaren punteros a funciones. Conversiones de tipos Reglas: Nunca usar conversiones explcitas de tipo (cast). Excepciones:
Una conversin explcita es preferible a una conversin implcita. Para convertir un puntero a una clase base a un puntero a una clase derivada en un contenedor implementado en una clase contenedora heterognea. Se debe usar para convertir una corriente de bits a un objeto. Ocurre cuando se desempaqueta un mensaje en un buffer. Como regla general la generacin explcita de tipos es necesaria para leer la representacin externa de un objeto.
No escribir cdigo que dependa de funciones que usen conversiones implcitas de tipos. Nunca convertir punteros a objetos de una clase derivada a punteros a objetos de una clase base virtual. Excepcin: Si una clase base virtual contiene una funcin virtual pura que convierte un puntero a clase base virtual a un puntero a clase derivada, esto puede funcionar deniendo la funcin en la clase derivada. Esto signica que todas las clases derivadas deben ser conocidas en la clase base virtual. Nunca convertir un const a un no const.
64
Estructuras de control de ujo Reglas: El cdigo que va despus de un case siempre debe terminar con un break. Las sentencias switch siempre deben tener una rama default para tratar casos inesperados. Nunca usar goto. Recomendaciones: La eleccin del tipo de bucle (for, while, do-while) debe depender de las siguientes consideraciones:
for: Se usa cuando hay una variable que se incrementa en una cantidad constante cada iteracin y la terminacin depende de una expresin constante. while: Cuando la condicin de terminacin se evala al principio de la iteracin. do-while: Si la condicin de terminacin es mejor evaluarla al nal.
Usar siempre unsigned para las variables que no pueden tener valores negativos. Usar lmites inferiores incluyentes (>=) y lmites superiores excluyentes (<). Evitar el uso de continue. Usar break para salir de un bucle si esto evita usar ags. No usar expresiones lgicas del tipo if(test) if(!test) cuando test es un puntero. Expresiones Recomendacin: Usar parntesis para claricar el orden de evaluacin de los operadores en las expresiones. Reserva de memoria Reglas: No usar malloc, realloc o free. Usar siempre corchetes ([ ]) cuando se liberan arrays con delete. Recomendaciones: Evitar usar datos globales. No liberar memoria, esperar que algn otro lo libere ms tarde. Asignar siempre un nuevo valor a un puntero que apunte a memoria liberada. Manejo de errores Recomendaciones: Asegurarse de que el manejo de fallos se ha hecho de tal modo que sea fcil convertirlo al manejo de excepciones. Comprobar los cdigos de fallo que se pueden recibir de funciones de librera incluso si esas funciones parecen seguras. Cdigo portable (multiplataforma) Abstracciones de datos Recomendacin: No usar directamente los tipos de datos predenidos en las declaraciones. Tamao de los tipos Recomendaciones: No suponer que un int y un long tienen el mismo tamao. No suponer que un int tiene 32 bits (quizs tiene slo 16). No suponer que un char es signed o unsigned. Poner siempre unsigned char si se usa ASCII de 8 bits. Conversiones de tipo Recomendaciones: Sea cuidadoso cuando haga conversiones de tipo desde uno corto a uno ms largo. No suponer que los punteros y los enteros tienen el mismo tamao. Usar conversiones explcitas de tipo para operaciones aritmticas usando valores con signo y sin signo.
65
Representacin de datos Recomendaciones: No suponer que se conoce como se representa en memoria la instancia de un objeto. No suponer que los tipos long, oat, double o long double van a comenzar en direcciones de memoria arbitrarias o ajustadas. Underow / Overow Recomendacin: No depender del funcionamiento del underow u overow de ningn modo.
Orden de ejecucin Recomendaciones: No suponer que los operandos de una expresin van a ser evaluados en un orden denido. No suponer que se conoce como han sido implementados los mecanismos de invocacin de una funcin. No asumir que un objeto es inicializado en un orden concreto en los constructores. No asumir que los objetos estticos son inicializados en ningn orden concreto. Objetos temporales Recomendacin: No escribir cdigo que dependa del tiempo de vida de un objeto temporal. Aritmtica de punteros Recomendaciones: Evitar usar las operaciones de desplazamiento en lugar de la aritmtica de punteros. Evitar la aritmtica de punteros.
5.1.5. Normas para programadores en Java

Java, al igual que C++, es un lenguaje orientado a objetos. La mayor parte de las normas que son aplicables a C++ son igualmente vlidas para Java, no obstante, S UN ha denido una serie de normas en la pgina http://java.sun.com/docs/ codeconv/html/CodeConvTOC.doc.html que exponemos resumidas a continuacin. Ficheros La extensin para los archivos de cdigo fuente es .java y para los archivos compilados .class. Organizacin de cheros Cada chero debera contener una sola clase. Si hay clases privadas e interfaces asociados con esa clase se pueden poner en el mismo chero despus de la clase pblica. Las secciones en las que se divide el chero son: Comentarios de tipo directorio de todo el mdulo. Sentencias del tipo package e import. Clases y declaraciones de interfaz. Consta de las siguientes partes:
Comentarios generales acerca de la clase o interfaz (comentarios de documentacin). Sentencia class o interface. Comentarios acerca de la implementacin de las clases (comentarios de implementacin). Variables estticas. Variables de instancia. Tanto las variables estticas como las de instancia se agrupan por su alcance, es decir, por este orden: pblicas, protegidas y privadas. Constructores. Mtodos. Se agrupan por su funcionalidad, no por su alcance.
Formato del texto S UN dene una serie de principios generales: El sangrado determinado para un bloque es de cuatro espacios. La longitud de las lneas de cdigo no debe ser superior a 80 caracteres. La longitud de las lneas de comentarios no debe ser superior a 70 caracteres. Normas para partir lneas demasiado grandes:
Partir despus de una coma. Partir despus de un operador.
66
Es preferible romper a alto nivel que a bajo nivel. Ejemplo: Bien: x = MetodoLargo (Par1, Par2, MetodoBajoNivel(Par31,Par32,Par33) Mal: x = MetodoLargo (Par1, Par2, MetodoBajoNivel(Par31, Par32,Par33)
Alinear la nueva lnea al comienzo de la anterior. Si esto pudiera causar confusin indentar (sangrar) con 8 espacios.
Comentarios En Java hay dos tipos de comentarios: De documentacin y de implementacin. Los comentarios de documentacin tienen la forma: /* ... */. Existe una herramienta llamada Javadoc que genera pginas HTML partiendo de este tipo de comentarios. El tema de los comentarios se trata en profundidad en el tercer apartado de este captulo. Declaraciones La recomendacin en este sentido es que no se declare ms de una variable por lnea, poniendo el nombre de la variable indentada y con un comentario. Deben estar localizadas al principio del bloque. Ejemplo: int numPuntos = 3; // Puntos que definen la figura Es conveniente inicializar las variables en el lugar en el que se declaran, a menos que esta inicializacin dependa de un clculo posterior. Las clases e interfaces deben usar la siguiente convencin: No se ponen espacios entre el nombre de los mtodos y el parntesis (. La llave de apertura { aparece en la misma lnea que el nombre del mtodo o clase. La llave de cierre de bloque } aparece en una lnea a parte del bloque, excepto cuando el bloque est vaco. Los mtodos se separan por una lnea en blanco. Ejemplo: class Punto extends ObjetoGrafico { int x; int y; Punto(a,b) { x=a; y=b; } Sentencias Debe haber una y slo una sentencia por lnea. Si hay un bloque de sentencias, ste debe ser sangrado con respecto a la sentencia que lo genera y debe estar entre llaves aunque slo tenga una sentencia para de este modo evitar errores cuando se aaden otras sentencias al bloque. Ejemplo: if (x>1) { y++; z=CalcularZ(x,y); } else { y=y-2; } Sentencias if-else, if else-if else. A los bloques denidos por estas sentencias se les aplican las normas denidas en puntos anteriores. Todos los bloques tienen el mismo nivel de sangrado. Bucles. Denen un bloque, que sigue las normas anteriores. Si el bucle es vaco (no tiene sentencias) no se abren ni se cierran llaves. Las sentencias return no deben usar parntesis.
5.2 Tcnicas de depuracin
67
Separaciones Incrementan la legibilidad del cdigo. La regla general es que cuanto ms importante sean las partes a separar tanto mayor debe ser la separacin. En este sentido el criterio es: Dos lneas: Entre clases e interfaces. Una lnea: Entre mtodos, declaraciones de variables y la primera instruccin, secciones lgicas diferentes de un mtodo y antes de un comentario de lnea o de bloque. Un carcter en blanco: Entre una palabra y un parntesis, despus de una coma, los operadores binarios menos el ., las expresiones del for, y entre un cast y la variable. Ejemplo: class X { ... } class Y extends X{ /* Declaraciones */ int x; int y; /** Desplaza la figura pixel a pixel horizontalmente */ int desplazarHorizontal(int h) { int inc; if (h<0) { h = -h; inc = -1; } else { inc = 1; } for (int i=0; i<h; i++) { x = x + inc; if (!Dibujar()) { return -1; } } return 0; } /** Desplaza la figura pixel a pixel verticalmente */ int desplazarVertical(int h) { ... Nombres Las normas de asignacin de nombres son: Paquetes: Nombres en minsculas separados por puntos. Ejemplo: java.io. Clases e interfaces: Dos o tres nombres con la primera letra en maysculas, sin usar abreviaturas. Ejemplo: ObjetoGrafico. Mtodos: La primera palabra debera ser un verbo y en minsculas. Ejemplo: desplazarHorizontal. Variables: Deben ser cortas (pueden ser de una letra) y signicativas. Si son varias palabras la primera en minscula. Ejemplos: i, j, k, unTriangulo. Constantes: Se escriben en maysculas y si son varias palabras van unidas por un carcter de subrayado. Ejemplo: MAX_LONG = 1000
5.2. Tcnicas de depuracin

Durante el desarrollo de la fase de implementacin se deben realizar dos tipos de labores relacionadas con la comprobacin del cdigo obtenido. La primera consiste en elaborar los conjuntos de prueba para los diferentes mdulos que se programan. La segunda consiste en comprobar si los mdulos cumplen las especicaciones de diseo con esos conjuntos de prueba. Tambin se puede incluir dentro de este proceso la comprobacin de correccin en la ejecucin de los mdulos y evitar posteriormente la aparicin de errores frecuentes como prdidas de memoria, comportamientos extraos ante entradas de datos imprevistas, etc. El contenido de este apartado se estudia en [Pre01, cap. 17] (o bien [Pre97, cap. 16] en la 4 a edicin).
68
5.3. Documentacin del cdigo

Adems de la documentacin incluida dentro del cdigo fuente correspondiente, es necesario generar los manuales tcnicos y de referencia adecuados, as como la parte inicial correspondiente del manual de usuario (que se nalizar en la fase de entrega). Estos manuales se deben ir escribiendo simultneamente al cdigo y se deben actualizar en concordancia con los cambios en el mismo. Esta documentacin es esencial para las fases de pruebas y de mantenimiento, as como para la entrega nal del producto. Por tanto se deben mantener actualizadas y funcionales desde el primer momento. Adems de las recomendaciones que se han dado para lenguajes especcos vamos a ver de que modo se puede hacer la documentacin interna de un programa (comentarios). Esta documentacin es importante de cara al mantenimiento futuro del programa, tanto si lo hacen terceras personas como si lo hace el encargado de programar el cdigo fuente del mdulo. Adems de estos comentarios en el cdigo se extraen los esbozos para los manuales tcnicos y de referencia.
5.3.1. Tipos de comentarios

Distinguiremos tres tipos de comentarios desde el punto de vista de la parte que comentan y dnde se localizan. Directorio: Son los situados al principio de cada mdulo. La informacin que contiene es: Lista de funciones o clases implementadas en el mdulo, Versin, Fecha, Programador, Copyright e Interfaces con otros mdulos. Prlogo: Cumple la misma funcin que el directorio pero para cada funcin o mtodo. Indica la siguiente informacin: Finalidad, Comentarios acerca de las variables signicativas, Descripcin general del funcionamiento e Informacin para la reutilizacin (efectos colaterales, variables globales que utiliza, etc.) Explicativo: Aclaraciones acerca de partes del cdigo. Hay dos tipos: de lnea y de bloque. Las ventajas de los comentarios de bloque es que estn localizados en un punto concreto y no dispersos por varias lneas entre el cdigo, con lo que adems son fciles de modicar. Los comentarios de una lnea deben ponerse en la misma lnea del cdigo que se esta comentando y se usan para explicar sentencias complicadas. Los tipos de comentarios segn cmo estn redactados son estos cinco (de peor a mejor): Repetir el cdigo: Consiste en expresar el cdigo de otra forma pero sin aadir informacin signicativa. Este tipo de comentarios son innecesarios. Explicacin del cdigo: Ayudan a comprender el cdigo. Es mejor reescribir el cdigo de modo que sea ms inteligible que utilizar este tipo de comentarios. Marcadores: Son notas temporales para la gente que trabaja en el proyecto. Se eliminan cuando el proyecto naliza. Resumen del cdigo: Explica en pocas palabras la funcin de un trozo de cdigo. Descripcin de la nalidad: Explica el por qu. Es el ms fcil de entender.
5.3.2. Consideraciones generales

Los comentarios deben ser entre el 25 % y el 33 % de las lneas de un mdulo. No se deben comentar cosas evidentes. Ejemplo: if (x<5) i+=2; // Suma 2 a i cuando x es menor que 5 Se debe comentar ms el cmo y no el qu. Los datos se deben comentar cuando el nombre no sea suciente como para que se entienda. Si un dato se compone de otros ms pequeos aplicar esta misma regla recursivamente caso de ser necesario.
Tutorial posterior
La implementacin en teora se puede hacer de un modo totalmente automatizado a partir del diseo. Pero como esto en realidad no es as, se dan una serie de consejos para pasar el diseo a cdigo y como redactar este cdigo en un conjunto de lenguajes. Traduccin del diseo a la implementacin Ingeniera inversa: Consiste en averiguar las especicaciones de un sistema a partir de su funcionamiento. Se dan algunas heursticas para averiguar los casos de uso de un sistema: deniciones de clases, creacin y destruccin de objetos, invocacin de mtodos, herencia e implementacin de asociaciones.
5.3 Documentacin del cdigo
69
Estilo de programacin orientado a objetos: Son un conjunto de consejos para conseguir: reusabilidad, reconocer la herencia, construir mtodos extensibles, cdigo robusto y trabajo en grupo ecaz. Normas para programadores en C: Son un conjunto de normas que cubren todos los apartados de la codicacin, tanto del tamao de los cheros, como de la eleccin de nombres (quizs lo ms importante), indentacin, etc. Normas para programadores en C++: Es una recopilacin similar para el lenguaje C++. Es ms extenso debido a la complejidad del lenguaje. Estas normas fueron compiladas por Ellmentel Telecomunications System Laboratories. Normas para programadores en Java: Es un resumen de las normas publicadas por S UN para el lenguaje Java. Tcnicas de depuracin Consiste en un conjunto de tcnicas para descubrir errores de codicacin. Incluye tambin un pequeo apartado para procesos concurrentes. Documentacin del cdigo Al igual que el diseo el anlisis producen documentos segn una plantilla estndar, el cdigo tiene que tener una documentacin interna. Se distinguen los tipos de comentarios (Directorio, prlogo y explicativo), donde se colocan, que informacin se incluye en cada uno de ellos y la forma de redaccin de la informacin.

1. Suponga que tiene este cdigo: char *posicion(char *cad,char *cad2) { for (char *c1=cad,char *c2=cad2; *c1; c1++) { for (char *c3=c1,char *c4=c2; *c3 && *c4 && (*c3==*c4); c3++, c4++) if (!*c4) return c1; } } a) Qu propsito tiene? b) Es correcto?. Si no es as, a qu se debe? c) Redacte de nuevo el cdigo de modo que se pueda entender su propsito y funcionamiento de un vistazo. Asigne nombres signicativos a las variables y a la funcin. Escriba comentarios. Ponga la indentacin correcta. Si es necesario cambie la estructura de la funcin. 2. Suponga que tiene un programa en C++ que calcula un fractal y lo dibuja como una imagen en la pantalla. Para estas funciones utiliza un mdulo con una estructura de datos que dene los nmeros complejos y las operaciones relativas a ellos: Producto, Suma, Resta, Potencia. A cada punto de la pantalla se le aplica un algoritmo, lo cual estara en otro mdulo. Se tendra otro mdulo con las funciones relativas a los grcos: Dibujar matriz de puntos, Zoom, etc. Redacte la documentacin de cada mdulo del programa: prlogo y comentarios antes de cada funcin (haga las suposiciones que considere oportunas sobre que funciones existiran).
Tambin se puede estudiar parte de los contenidos de este tema en [Som98, caps. 5 y 6], [RBP 96], [BMP87, caps. 10 al 15] [Sch92, caps. 9 y 10]. En la pgina http://www.bagley.org/~doug/shootout/ se puede encontrar una recopilacin comparativa de ejemplos de implementacin (con fuentes) para varias funciones sencillas conocidas en muchos lenguajes de programacin diferentes. Como curiosidad anecdtica, otro tipo de pgina similar, aunque menos formal, es http://internet.ls-la.net/mirrors/ 99bottles/, que recopila el mismo programa ilustrativo simple en ms de 400 lenguajes distintos. Usando cualquier buscador estndar de Internet (como p. ej. http://google.com/) se pueden encontrar innidad de pginas relacionadas con cualquier lenguaje de programacin. La herramienta de anlisis y modelado de software A LMA http://www.memoire.com/ guillaume-desnoix/alma/, permite el anlisis de cdigo fuente orientado a objetos para su representacin y modelado o su transformacin a otros lenguajes. Esta herramienta, A LMA, es muy interesante y al estar implementada en Java es fcilmente instalable en cualquier entorno. Es interesante hacer notar que existen ciertos lenguajes de programacin que facilitan y promueven con su sintaxis una codicacin ms clara, ordenada, sistemtica y autodocumentada. Tal es el caso, por ejemplo, del lenguaje P YTHON que, normalmente, es interpretado pero que auto-precompila cada chero fuente ejecutado y reutiliza esa versin precompilada
70
(preanalizada) si no cambia el fuente. Este lenguaje es muy til para hacer prototipos rpidos, pero tambin para aplicaciones ms grandes (por ejemplo vase Z OPE http://www.zope.org/). Prcticamente todas las implementaciones de P YTHON son de libre distribucin. Se puede ver ms informacin en las siguientes pginas Web: http://www.python.org/, http://www.freenetpages.co.uk/hp/alan.gauld/spanish/ es una traduccin al espaol del libro [Gau01] (un tutorial bsico), el libro de libre distribucin (licencia FDL) [DEM02] en http://www.ibiblio.org/obp/thinkCSpy/ o un libro en lnea http://diveintopython.org/es/ (traduccin al castellano de Dive into Python) con varias referencias a otra informacin en espaol, aparte de la pgina http://users.servicios.retecal.es/tjavier/python/Un_poco_de_Python.html sobre P YTHON de Toms Javier Robles Prado. Existe una tcnica de escribir la documentacin incluida dentro del cdigo fuente, conocida por el nombre en ingls de Literate Programming. Se puede encontrar extensa informacin sobre este tema en la FAQ especca: http://shelob.ce. ttu.edu/daves/lpfaq/faq.html. Adems hay algunas otras herramientas de ayuda en la generacin de referencias cruzadas y documentacin a partir del cdigo fuente, como por ejemplo C XREF http://www.gedanken.demon.co.uk/cxref/, la ms reciente y completa D OXYGEN http://www.doxygen.org/ (que se puede utilizar para otros lenguajes adems de C). Tambin es interesante ver el ejemplo de cmo un proyecto enorme, como es el kernel del sistema operativo Linux, tiene un sistema de referencias cruzadas: http://lxr.linux.no/.
Captulo 6
Fases de pruebas
Tutorial Previo
Introduccin
Este tema incluye en su denominacin Fases, en plural, debido a que realmente no hay una nica fase de pruebas, sino que las pruebas se van realizado en todas las dems fases. Las pruebas en este caso consisten en la comprobacin de que la salida obtenida en cada fase corresponde a las especicaciones de entrada correspondientes. Las pruebas consumen mucho tiempo, pero deben hacerse de un modo sistemtico para asegurar que el resultado cumple con el grado de calidad exigido (densidad de errores por KLDC, etc). Para medir esta calidad existen algunas mtricas. En esta parte del desarrollo se trata de encontrar errores, no slo de codicacin, sino tambin los relativos a la especicacin o el diseo, en este sentido se puede distinguir entre vericacin y validacin. La vericacin trata de comprobar si se est construyendo el producto correctamente, la validacin si es el producto correcto. Las pruebas que se van haciendo durante el ciclo de vida son: ingeniera del sistema (prueba del sistema), especicacin (prueba de validacin), diseo (prueba de integracin) y codicacin (prueba de unidad). Los tipos de pruebas tienen naturaleza diferente y en consecuencia, las tcnicas para cada una de ellas son diferentes; tambin se har un recorrido por cada una de ellas. Inevitablemente tambin hay que aadir la correspondiente documentacin de las pruebas realizadas.

Este tema est muy relacionado con los anteriores temas 3 al 5 correspondientes a las fases de requisitos, diseo e implementacin, donde se deben distribuir las pruebas correspondientes. Es recomendable, aunque no necesario, haber construido alguna vez un mdulo que pruebe a otro dando entradas y comprobando si las salidas que proporciona el mdulo probado se corresponden con lo esperado.
Objetivos del tema

Se debe extraer una idea clara de que los principios de ingeniera requieren la comprobacin y vericacin de todos los elementos intermedios en el proceso de desarrollo, en este caso, del software. Tambin se deben conocer tcnicas que indiquen los errores que se comenten, tanto de concepcin de la tarea a realizar como de las funcionalidades que se implementen y que esta deteccin ocurra lo antes posible.

Es conveniente recapitular y repasar los temas anteriores 3 al 5 para ir identicando dentro de cada una de las fases cules son las pruebas necesarias para la validacin que se explican en este captulo. Debido a que este captulo est orientado a las pruebas formales realizadas en un sistema relativamente grande (pruebas de integracin, de especicacin) no es factible hacer un ejercicio de pequeo tamao que ilustre el tema, por tanto, se debe considerar de contenido terico. Vericacin y validacin a lo largo del ciclo de vida. El material correspondiente a este apartado se encuentra en [Pre01, cap. 18] (o bien [Pre97, cap. 17] en la 4a edicin). Tcnicas y mtodos de prueba. Este apartado se debe estudiar en [Pre01, cap. 23] (o bien [Pre97, cap. 22] en la 4 a edicin). Documentacin de pruebas. El material est incluido directamente en esta gua.
6.1. Vericacin y validacin a lo largo del ciclo de vida

Uno de los elementos esenciales de todo proceso de ingeniera en general es la vericacin y validacin de los pasos dados durante el desarrollo. Por tanto es necesario hacer las comprobaciones parciales cuanto antes para realimentar el proceso de desarrollo segn los resultados de las pruebas. 71
72
Fases de pruebas
El contenido de este apartado se estudia en [Pre01, cap. 18] (o bien [Pre97, cap. 17] en la 4 a edicin).
6.2. Tcnicas y mtodos de prueba

Existen diferentes tcnicas para realizar las pruebas de vericacin del software en diferentes fases. La mayora hacen uso de las caractersticas de modularidad en el diseo e implementacin para ir integrando de forma ascendente o descendente los mdulos de diferentes niveles. El contenido de este apartado se estudia en [Pre01, cap. 23] (o bien [Pre97, cap. 22] en la 4 a edicin).
6.3. Documentacin de pruebas

Como una fase ms, todos los elementos preparados para las pruebas y los resultados de las mismas deben ser documentados y adjuntados a cada versin correspondiente de los productos de las fases anteriores. Esta forma de proceder evitar la repeticin de pruebas y facilitar la preparacin de nuevas pruebas a partir de otras anteriores.
Plan de pruebas
Son un conjunto de actividades que pretenden demostrar que el producto cumple con lo estipulado en el contrato. En el plan de pruebas se especica: 1. Identicador del plan: Debera ser una palabra que lo identicase con su alcance. Hay que incluir adems la versin y fecha. 2. Alcance: Tipo de prueba y propiedades del software a ser probado. 3. Items a probar: Conguracin a probar y condiciones que se deben satisfacer para ello. 4. Estrategia: Tcnica y herramientas a utilizar. Hay que indicar el nmero mnimo de casos de prueba a realizar y el grado de automatizacin tanto en la generacin de casos de prueba como en la ejecucin 5. Categorizacin de la conguracin: Condiciones bajo las cuales el plan debe ser: Suspendido: Si se presentan demasiados defectos o fallos. Repetido. Dado por terminado: Si se cumple el nmero mnimo de casos de prueba. 6. Documentacin: Segn el estndar IEEE 829-1983 hay que producir los siguientes documentos: Plan de prueba. Especicacin de los requerimientos para el diseo de los casos de prueba. Casos de prueba. Para cada uno se especican: Descripcin del procedimiento de prueba y Descripcin del tem a probar. Bitcora de pruebas. Informe de incidentes de prueba. Resumen de pruebas. 7. Procedimientos especiales: Grafo de las tareas necesarias para preparar y ejecutar las pruebas, as como habilidades necesarias. 8. Recursos: Pueden ser muy variados Caractersticas de hardware y software. Software necesario para hacer las pruebas. El software a ser probado. Conguracin del software de apoyo. Recursos humanos necesarios para el proceso. Requerimientos especiales: Actualizacin de licencias, espacio de ocina, tiempo de mquina, seguridad, etc. 9. Calendario: Hitos del proceso y grafo de dependencias. 10. Riesgos: Riesgos del plan, acciones para mitigarlos y planes de contingencia. 11. Responsables: Lista de personas y tareas asignadas. Existen cuatro tipos de pruebas que deben superarse Pruebas funcionales: Se realizan con los datos de entrada normales en el uso diario del sistema. Se comprueban sobre todo valores en los lmites de las variables y un poco ms all de los lmites. Tambin algunos valores especiales.
6.3 Documentacin de pruebas
73
Pruebas de desempeo: Miden el rendimiento del sistema. Tiempos de respuesta, utilizacin de la memoria, trco generado en las comunicaciones, etc. Estas pruebas nos van a indicar donde estn los cuellos de botella del sistema. Pruebas de tensin: Se trata de sobrepasar los lmites de tolerancia del sistema de varias maneras: Conectar ms usuarios al sistema de los permitidos, si tiene que gestionar x mega-bits por segundo de una lnea de comunicaciones probar a aumentar ese ancho de banda, etc. Pruebas estructurales: Es un anlisis de la lgica interna de un programa.
Tutorial posterior
Vericacin y validacin La Vericacin y validacin se debe llevar a cabo a lo largo de todo el ciclo de vida. Vericacin es comprobar si el producto se est construyendo correctamente. Validacin es comprobar si estamos construyendo el producto que se nos ha pedido. Se abordan un conjunto de actividades y tareas para garantizar que se da una respuesta positiva a esas dos cuestiones. Uno de los puntos importantes es que la V&V debe ser independiente, es decir, no pueden hacerlo las mismas personas que estn construyendo el producto. Esta independencia se debe dar tanto en la gestin como en la nanciacin. Las tareas de V&V se contemplan desde tres perspectivas: sistemas genricos, sistemas expertos y software reutilizado, y en todas y cada una de las etapas del ciclo de vida. Tcnicas y mtodos de prueba Se trata en esta seccin de realizar las pruebas que den una garanta acerca del cdigo. Se introducen los conceptos de Error, Defecto y Fallo. Se denen un conjunto de principios que debe seguir toda prueba: Casos de prueba: Es un conjunto de entradas y salidas esperadas para ellas. Existen dos tipos de pruebas: de caja blanca y de caja negra. Existe un mtodo para crear casos de prueba para casos de uso. Pruebas de caja blanca. Tcnicas y medidas: grafo de ujo, complejidad ciclomtica y criterios de cobertura del grafo. Pruebas de caja negra. Tcnicas: particiones o clases de equivalencia y anlisis de valores lmite. Cleanroom: Es una metodologa de desarrollo pensada para producir software muy able. Revisiones sin ejecucin de cdigo: wallthroughs, inspecciones y auditoras, Calidad del software: El modelo de McCall tiene en cuenta una serie de factores de calidad. Documentacin de pruebas Como en los dems captulos este es el apartado donde se pone sobre el papel el trabajo realizado con un documento llamado plan de pruebas que es un documento que pretende demostrar que el producto cumple con lo estipulado en el contrato.
Ejercicios
1. Cules son los motivos por los que es conveniente que las actividades de V&V sean realizadas por un equipo independiente? 2. Cundo es mejor hacer la V&V, despus de construir el producto, antes, despus de una etapa concreta, ...? 3. En el programa de la gura 6.1: Represntelo en algn lenguaje de programacin. Halle los valores de a y b para cobertura de sentencias, decisiones, condiciones y decisin/condicin. Hay algn bucle? De qu tipo? Cuntas veces conviene ejecutarlo?
Este tema tambin se puede consultar en [Som98, cap. 7] [BMP87, cap. 16 y 17]. Sobre calidad, pruebas y evaluacin del software, el NIST en Estados Unidos mantiene una pgina muy interesante: http: //hissa.nist.gov/.
74
Fases de pruebas
a=a3*b si a>1000 no a<100 no b<3 si no si msg="a es pequeo y b da igual"
msg="b es pequeo y a grande"
msg="b es grande y a tambien"
Write(msg)
Figura 6.1: Programa
Captulo 7
Fase de entrega y mantenimiento

Tutorial Previo
Introduccin
Como etapa nal en el ciclo de vida del software se debe realizar la entrega de la primera versin al cliente y considerar las posibles posteriores modicaciones de mantenimiento. Dentro del mantenimiento se deben incluir no solamente las correcciones de errores detectados posteriormente por el cliente, sino tambin las modicaciones necesarias para actualizacin, e incluso las peticiones de cambios por parte del cliente. Una vez que se entrega el producto, no slo 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 distribucin). Existen varios tipos de mantenimiento, no slo para corregir errores, sino tambin para adaptar el sistema a nuevos entornos o para proporcionarle nuevas funcionalidades. Es interesante medir el esfuerzo que se gasta en mantenimiento, para lo que tambin existen sus correspondientes mtricas. La documentacin describe el sistema desde la especicacin de requisitos hasta la aceptacin por parte del usuario. Esta informacin debe estar estructurada y ser legible. Existen herramientas CASE que automatizan esta parte (hasta donde es posible).

Este tema presenta los elementos nales del ciclo de vida del software y est relacionado con la planicacin general del mismo que se present en el primer tema y con las fases de desarrollo en los anteriores.
Objetivos del tema

Determinar cul es la nalizacin del desarrollo del software y la extensin de la vida del software desarrollado. Comprender la problemtica asociada a mantener una aplicacin. Dar una gua de genrica de como realizar el mantenimiento y dar estrategias viables para afrontarlo.

El contenido del tema es principalmente terico por lo que la metodologa de est ms orientada al estudio de los contenidos y la reexin sobre los ejemplos. Finalizacin del proyecto. Este material se incluye directamente en esta gua didctica. Planicacin de revisiones y organizacin del mantenimiento. El material correspondiente a este apartado est en [Pre01, caps. 9 y 30] (o bien [Pre97, caps. 9 y 27] en la 4a edicin). Recopilacin y organizacin de documentacin. Este apartado est incluido en esta gua didctica.
7.1. Finalizacin del proyecto

Dentro del ciclo de vida del software, y como en cualquier actividad de ingeniera, es necesario tener presente la nalidad del desarrollo y la obligacin de entrega del producto acabado al cliente. Una vez que el sistema ha pasado las pruebas se trata de entregrselo al cliente y ponerlo en condiciones de empezar a funcionar. La estrategia de implantacin se decide desde la fase de especicacin y se tiene en cuenta tanto la cobertura global como la geogrca. Es recomendable hacer las siguientes consideraciones: 1. Nmero de copias de cada parte del software que se va a entregar. 2. Tipo de medios para cada parte del software, incluyendo formato y versin en un lenguaje humano. 3. Documentacin de requerimientos estipulados (manuales de usuario). 75
76
4. 5. 6. 7.
Derechos de propiedad y asuntos de licencia, sealamientos y acuerdos. Custodia de los programas del sistema, incluyendo planes de recuperacin y de contingencia por desastres. Instalacin. Las responsabilidades y obligaciones del personal encargado de informtica y de los usuarios nales deben denirse teniendo en cuenta lo siguiente: Acceso a las instalaciones del nuevo usuario. Disponibilidad y acceso a los sistemas y equipo del usuario nal. Disponibilidad de personal experto en las reas correspondientes. La necesidad de validacin como parte de cada instalacin debe ser determinada. Se debe validar el funcionamiento de todo el sistema despus de cada instalacin. Un procedimiento formal para aprobar cada instalacin al complementarla.
7.1.1. Aceptacin
Se dice que el proyecto ha nalizado cuando todas las actividades tcnicas han terminado o se ha agotado su plazo y se han facturado todos los conceptos al cliente (se hayan cobrado o no). Para evitar problemas en el momento en el que se pide que al cliente su aceptacin se debe redactar un documento que especique claramente los requisitos (lgicamente este documento se redacta en la fase de especicacin). Una vez que el cliente lo rma acepta que est conforme.
7.1.2. Informe de cierre del proyecto

Es un resumen de lo sucedido, de si se han conseguido los objetivos y en caso negativo de las razones para ello. Documentacin generada: Balance de ingresos y gastos.
Valores positivos: Gastos superiores ->Menos benecio. Valores negativos: Ahorro ->Ms benecio.
Informes de situacin nales.
Informe econmico. Informe de situacin nal. Se redacta en lenguaje no tcnico. Incluye:
Datos del proyecto: Nombre, duracin, etc. Resumen de las incidencias: Modicaciones, problemas, soluciones, sugerencias futuras, etc.
Lista de documentacin generada. Lista de productos generados. La documentacin es tambin un modo de preservar el conocimiento de la empresa independientemente de la permanencia de los empleados, asimismo detecta tendencias en el tipo de requisitos demandados, tipos de errores ms comunes, etc.
7.1.3. Indicadores del proyecto

Son un conjunto de medidas para evaluar de un modo objetivo los resultados. 1. Indicadores econmicos. Facturacin del proyecto. Margen del proyecto: Diferencia entre ingresos y costes, en valor absoluto y en porcentaje. Benecio del proyecto. Coste por hora trabajada. Precio de venta de la hora trabajada. Componentes del coste del proyecto. Son los porcentajes del coste total del proyecto dedicados a cada uno de estos apartados.
Valor relativo del esfuerzo propio. Valor relativo de las subcontrataciones. Valor relativo de los suministros.
2. Indicadores nancieros
7.2 Planicacin de revisiones y organizacin del mantenimiento
77
Porcentaje de endeudamiento externo (ajeno): Es el montante que hay que afrontar en caso de impago. Es el porcentaje dedicado a subcontrataciones, suministros, viajes y gastos varios. Porcentaje de endeudamiento interno (propio): Son los gastos que en caso de impago la empresa debera satisfacerse a si misma. Es el complementario del anterior. Porcentaje de endeudamiento externo + Porcentaje de endeudamiento propio = 1. Valor actual neto del proyecto: n Fi (7.1) VA 1 r n i 1

Donde: Fi son los ujos monetarios del proyecto, n es el nmero de aos o meses desde que se produjo el ujo monetario y r es la inacin anual o mensual acumulada desde entonces. Tasa de rendimiento (R) interno del proyecto. R
Ingresos Costes Costes Tiempo

Margen Tiempo
(7.2)
3. Indicadores de ocupacin laboral. Indican la cantidad de personal para cada proyecto, su tasa de ocupacin y como consecuencia si sobra o falta gente. Carga de trabajo: Nmero de horas para realizar un trabajo. Nmero de personas necesarias para el proyecto. ndice de ocupacin. 4. Indicadores de gestin. Hay cuatro indicadores de la calidad de este apartado: Plazo de ejecucin. Coste (global y por partidas) Margen. Contingencias.
7.2. Planicacin de revisiones y organizacin del mantenimiento

Adicionalmente a las revisiones durante el proceso de desarrollo inicial del software, tambin hay que considerar las posibles modicaciones y revisiones como consecuencia del mantenimiento y actualizacin del mismo. Tambin hay que considerar la posibilidad de que el cliente solicite cambios posteriores no previstos inicialmente y por tanto es necesario que se tenga en cuenta esta posibilidad. El contenido de este apartado se estudia en [Pre01, caps. 9 y 30] (o bien [Pre97, caps. 9 y 27] en la 4 a edicin).
7.3. Recopilacin y organizacin de documentacin

Como nalizacin de la parte de documentacin de todo el desarrollo, hay que hacer entrega de la documentacin apropiada como una parte integral del producto resultante. En esta fase es necesario reunir todos los documentos generados y clasicarlos segn el nivel tcnico de sus descripciones. Es muy importante distinguir entre la documentacin orientada a futuros desarrollos o modicaciones de mantenimiento (documentacin de diseo, implementacin y pruebas, manual tcnico, manual de referencia), frente a la documentacin de uso y aplicacin (introduccin de uso rpido, manual de conguracin, manual de usuario, manual de interfaz). Una vez que se ha nalizado el proyecto se debe tener una documentacin til para el mantenimiento posterior y para la operacin normal por parte de los usuarios. Esta seccin es una enumeracin bastante exhaustiva de esta documentacin que se puede tambin consultar en: http://www.mendoza.gov.ar/imagenes/comip/metodologia.pdf.
7.3.1. Motivos de la documentacin

Hay dos motivos para contar con una buena documentacin: 1. Facilita el mantenimiento porque: Ayuda a localizar donde hay que modicar o aadir cdigo. Los mantenedores necesitarn menos tiempo para comprender cada mdulo. Supone una forma de comunicacin entre profesionales, sobre todo si la forma en la que se ha realizado sigue un estndar, por ejemplo, todo el mundo sabe interpretar un diagrama de clases de UML. Una buena documentacin facilita que el mantenimiento lo puedan realizar terceras empresas o personas. 2. Facilita la auditora. Una auditora es un examen del sistema que se puede hacer desde varios puntos de vista. Por ejemplo, aqu nos interesa saber si se estn cumpliendo plazos o las normas de la empresa en la redaccin del cdigo.
78
7.3.2. Directrices a seguir para la redaccin de un documento

Muchas organizaciones tienen un programa de documentacin, que es un procedimiento estandarizado de redactar los manuales tcnico y de usuario. Los procedimientos de documentacin deben ser estandarizados para que de esta forma la comunicacin sea rpida, no ambigua y reduzca costes de personal, es decir, se debe huir de las orituras lingsticas propias de la literatura haciendo nfasis en la claridad y la concisin. En general todos los tipos de documentos deben tener un estilo homogneo, para ello se debe seguir un formato que tenga estos elementos: 1. Un prembulo con: Autor(es) del manual, fecha, versin y revisores. 2. Un ndice con secciones y subsecciones. A la hora de empezar a redactar un documento se hace un primer esbozo de las secciones a cubrir. Posteriormente, a medida que se van escribiendo se pueden hacer cambios, aadir o quitar subsecciones, pero no en los puntos principales. 3. Se debe seguir un conjunto de normas respecto a dos cosas: Respecto a la forma. P. ej: Tipo de letra Times new roman 11pt, los prrafos se indentarn con cuatro espacios, etc. Respecto al contenido. P. ej: Se pondrn ejemplos explicativos, se tender a la brevedad, etc. 4. Se deberan usar las mismas herramientas de proceso de textos para todos los documentos, preferiblemente de alguna que AT X, porque nunca se sabe cuanto durar el mantenimiento haya demostrado su continuidad en el tiempo, por ejemplo, L E (quizs dcadas). 5. Se cuidar en especial la claridad de expresin, los manuales deben tener ejemplos. 6. Los diagramas deben tener distribuidos los ejemplos de un modo lgico, no se deben poner demasiados en un nico diagrama. 7. Al nal debe existir un glosario de trminos. 8. Consistencia interna: No debe haber contradicciones. 9. Completitud: Se documentarn todas las partes del sistema. 10. Actualizacin con los cambios: Cada cambio en el sistema debe corresponderse con un cambio en las partes involucradas de la documentacin.
7.3.3. Tipos de documentos

Existen tres tipos de documentos: La dirigida a usuarios, que se centra en la operacin del sistema. La dirigida al mantenimiento. La dirigida al desarrollo. Veremos ahora una lista de documentos. En un proyecto no es necesario que estn todos, sobre todo en proyectos pequeos donde posiblemente no se haga un anlisis de riesgo o un anlisis costo-benecio. La informacin que se recoge en estos documentos deber ser actualizada durante el mantenimiento o cuando se hagan cambios en los requisitos durante el desarrollo para conservar la consistencia entre lo que dice la documentacin y la realidad. 1. Estudio de viabilidad: Es una evaluacin de un proyecto, requisitos y objetivos y sus posibles alternativas. 2. Anlisis de riesgo: Identica puntos vulnerables, sus posibles consecuencia, su importancia, causas y posibles soluciones. Este documento ser actualizado en cada fase de desarrollo. 3. Anlisis costo-benecio: Es una evaluacin de lo que va a costar el sistema y los benecios esperados. Uno de los usos de este anlisis es la seleccin de proyectos a desarrollar. Cada modicacin que se proponga al sistema tendr un impacto en este anlisis, con lo que ser necesario revisarlo. 4. Informe de decisin de sistemas: Es el lugar donde est la informacin para la toma de decisiones de desarrollo. Incluye: Necesidades a cubrir, Objetivos de cada uno de los hitos, Riesgos, Alternativas, Coste-benecio y Planes de administracin o justicacin de decisiones. 5. Plan de proyecto: Dene los objetivos y actividades para cada fase. Incluye estimaciones de recursos y objetivos de los hitos a lo largo de todo el ciclo de vida. Es donde estn denidos los procedimientos para diseo, documentacin, noticacin de problemas y control del cambio. Se detallan las herramientas y tcnicas seguidas. 6. Requisitos funcionales: Son una lista de los servicios que suministra el sistema a los usuarios, que estarn denidos en trminos cualitativos y cuantitativos. Tambin estn los requisitos de seguridad y control interno. 7. Requisitos de datos: Enumeracin de los tipos de datos, su descripcin y modo de captura. Deben identicarse especialmente los datos crticos para tener localizados los riesgos que de ellos se deriven y poder idear mecanismos de recuperacin y seguridad. 8. Especicaciones de sistema/subsistema: Es un documento para los analistas de sistemas y programadores. Son los requisitos, entorno operativo, caractersticas de diseo y especicaciones de seguridad y control para el sistema o subsistemas.
7.3 Recopilacin y organizacin de documentacin
79
9. Especicaciones del programa: Es otro documento dirigido a los desarrolladores. Son los requisitos, entorno operativo y caractersticas de diseo de cada uno de los ejecutables. 10. Especicaciones de la base de datos: Descripcin fsica y lgica de la base de datos junto a las especicaciones de seguridad y control. 11. Pruebas: Estrategia de pruebas del sistema, con especicaciones detalladas, descripciones y procedimientos, as como datos de prueba y criterios de evaluacin. 12. Manual de usuario: Describe las funciones del sistema. No debe usar jerga tcnica. 13. Manual de operacin: Descripcin del software y del entorno operativo para que pueda funcionar el software. 14. Manual de mantenimiento: Informacin acerca del cdigo fuente, sistemas y subsistemas para que el equipo de mantenimiento pueda entender el funcionamiento del programa y hacer cambios. 15. Plan de instalacin: Una vez que el sistema haya superado todas las pruebas est listo para ser instalado. Este manual describe como se realiza el proceso en diferentes entornos. 16. Anlisis de la prueba e informe de evaluacin de seguridad: Son el resultado de las pruebas. Se muestran las fortalezas y debilidades del sistema. Debe incluir un informe de evaluacin de seguridad para certicar el sistema.
7.3.4. Manual de usuario

La importancia de la documentacin de usuario estriba en que los usuarios no aceptarn un sistema que no puedan operar por tener un manejo poco claro; un porcentaje alto de la culpa del fracaso en la aceptacin de los sistemas recae en una documentacin pobre. Por otra parte, cuando se mantiene un sistema es deseable tener a mano la informacin de cmo estn hechas las cosas, de otro modo puede ser ms fcil tirarlo todo y rehacer el sistema de nuevo. Desde el punto de vista de los usuarios la opinin generalizada es que la documentacin: 1. No se entiende por usar tecno-jerga con la que el usuario no est familiarizado. 2. No se entiende porque el estilo de redaccin es oscuro y presupone conocimientos tanto tcnicos como del sistema que el usuario no tiene por que tener. 3. No es completa. 4. Est mal estructurada y como consecuencia es difcil encontrar la informacin. 5. O lo que es peor: No existe o es escasa. Recursos Cunto esfuerzo se debera dedicar a la documentacin? En la empresa desarrolladora en total (anlisis, diseo, implementacin, pruebas y manuales tcnico y de usuario) entre un 20 y un 30 %. Durante el mantenimiento: para estudiar la documentacin 6 % y para actualizar la documentacin 6 %. Objetivos del manual de usuario 1. 2. 3. 4. Que el usuario sepa introducir los datos de entrada y obtener los de salida. Que el usuario pueda interpretar correctamente los mensajes de error. Es deseable que una parte del mismo pueda servir como tutorial del sistema. Una parte debe ser un manual de referencia.
Es importante tener en cuenta a qu personas va dirigido el manual, no se redacta igual para un directivo, que probablemente est ms interesado en una visin general del sistema que no va a usar directamente que a un empleado de base que se dedica a introducir algunos datos o que un miembro administrativo que usar el sistema para por ejemplo sacar estadsticas de ventas. Como existen diferentes perles de utilizacin el manual de usuario deber reejar esto estructurndose en mdulos dirigidos a tipos diferentes de personas. Dentro de cada uno de los mdulos deberan existir procedimientos especcos para funcionalidades concretas. Un procedimiento sera una lista ordenada de acciones para conseguir algo. Las posibles bifurcaciones de cada procedimiento respecto al camino principal debern documentarse igualmente. Existen estndares de documentacin que especican el ndice del manual (y algunos como el de GNU incluso el formato, que debe ser T EXINFO para as poder ser traducido automticamente a otros formatos). En cualquier caso, el ndice deber contener los siguientes puntos: 1. Instalacin del producto. Se indicarn los requisitos, tanto software como hardware. 2. Conguraciones posibles, teniendo en cuenta los diferentes perles de usuario. 3. Si el manual tiene varios mdulos en funcin de los perles de usuario, para cada uno de ellos: Se indica un procedimiento para obtener cada funcionalidad. Debe indicarse la secuencia en la que se ejecutan las acciones y las posibles bifurcaciones. Cada procedimiento se entiende mucho mejor si tiene ejemplos.
80
Es deseable que exista un tutorial, ya sea en la aplicacin o en el manual. Si se manejan documentos de entrada y/o salida se dar si ha lugar una breve explicacin sobre su nombre, formato, origen, localizacin, usuarios que lo manejan y procesos de backup. 4. Manual de referencia: Es el documento que contiene toda la informacin en detalle. 5. Lista de errores con su signicado y posible solucin, el usuario no tendr que recurrir a esta parte del manual si esta informacin est disponible en la propia aplicacin. Esta parte puede estar en el manual de referencia. 6. Glosario de trminos. Procedimientos y tutoriales Formularios de entrada/salida: Especica las normas para rellenar los formularios de entrada/salida (si es que existen). Pantallas y mensajes: Contiene las instrucciones de operacin para los procesos on-line, incluyendo el ujo de pantalla para cada uno de ellos, los mensajes del sistema y las asignaciones de las teclas de funcin. Confeccionar un glosario, preferentemente on-line, con todos los mensajes de error que puede generar el sistema. Informes del sistema: Presenta el inventario, el ejemplo y la descripcin detallada de los informes del sistema, incluyendo su ordenamiento, cortes de control, frecuencia de emisin, nmero de copias y forma de distribucin. Dividirlos en categoras de acuerdo al nivel de los usuarios a quienes estn orientados. Procedimientos de control: Describe la estructura general de los controles del sistema y dene su relacin con los controles manuales. Incluye la descripcin de los mecanismos para efectuar controles cualitativos y cuantitativos sobre los datos que ingresan al sistema, los que se transeren entre los distintos programas y sobre la informacin de salida, asegurando su integridad y conabilidad. Procedimientos de usuario: Son los procedimientos requeridos para el uso del sistema. Deben quedar reejadas las responsabilidades de cada sector usuario, en cuanto al envo y/o carga de informacin (tiempos y oportunidad de proceso), como tambin sus responsabilidades en cuanto al control y aprobacin de las salidas del sistema. Procedimientos de reabastecimiento: Son los procedimientos requeridos para la provisin de los insumos para utilizar el sistema, como: formularios preimpresos, etiquetas, recargas para impresoras, diskettes, cintas, etc. Soporte a usuarios: Son los procedimientos disponibles para obtener ayuda sobre el uso del sistema. Deben quedar reejadas las opciones que tiene el usuario para solucionar una duda identicando el o los sectores responsables del servicio. Material de capacitacin: Inventario de cada una de las opciones disponibles para capacitacin, ya sea autoasistida o a travs de cursos, tutoriales, etc.
7.3.5. Manual del sistema

Desde el punto de vista de las personas que hacen el mantenimiento los problemas que se encuentran es que la documentacin: 1. 2. 3. 4. 5. Nunca existi o se ha perdido! Es incompleta o escasa. No est actualizada con los cambios que se han ido haciendo al sistema. Tiene contradicciones con el contenido real del cdigo. No es clara.
Objetivos Documentar en forma detallada las caractersticas de cada componente de la arquitectura tcnica del sistema. Servir como base para el mantenimiento futuro de los procesos y programas del sistema. Contenidos 1. Descripcin general del sistema Identicacin del sistema: Nombre y siglas que lo identican. Objetivos: Descripcin breve del objetivo general del nuevo sistema, incluyendo referencia a las funciones del negocio (planicacin, gestin, etc) qu cubre y cmo lo hace. Alcance: Diagrama de contexto que muestre la interaccin del sistema con el resto de los sistemas de la organizacin. Caractersticas generales. Descripcin breve de las siguientes especicaciones funcionales y/o tcnicas:
Enfoque de desarrollo (a medida, paquete de software, etc). Herramientas de desarrollo. Tipo de procesos. Tecnologa de implementacin (hardware, software, comunicaciones, etc).
81
Polticas relacionadas con su uso. Siguiendo las polticas, normas y estndares vigentes, se debern adjuntar:
Identicacin del responsable de los datos. Identicacin de informacin condencial y pblica para su tratamiento. Principales sectores usuarios. Perles de usuarios y esquema general de seguridad. Plan de contingencia que explique los mtodos de trabajo alternativos ante fallas. Plan de recuperacin que explique los procesos de recuperacin y reinicio ante los casos eventuales de destruccin o desastre.
Principales funciones: Narrativa breve que describa las principales funciones del sistema. Se podr acompaar de un esquema donde se identiquen las actividades del negocio cubiertas por el sistema y sus necesidades de informacin. Observaciones: Cualquier informacin que no haya sido especicada antes y que se considere de inters. 2. Arquitectura general del sistema Requisitos funcionales: Expresar los requisitos funcionales que debe satisfacer el sistema Eventos del sistema: Extraer del modelo de eventos una lista conteniendo todas aquellas funciones ejecutadas por los distintos usuarios que originan una entrada al sistema. Indicando: a) b) c) d) e) Nmero de evento. Descripcin. Origen de la informacin. Destino de la informacin. Flujo de datos.
Procesos del sistema: Contiene el inventario y la descripcin general de cada una de las opciones de la aplicacin, incluyendo imgenes de las pantallas utilizadas. Dilogo del sistema: Muestra la comunicacin entre las distintas pantallas de la aplicacin identicando las condiciones que provocan la navegacin entre las mismas. Modelo de procesadores: Muestra de manera grca los distintos dispositivos fsicos requeridos, la asignacin de tareas y la conectividad entre ellos. Esquema de mdulos:Esquema donde se visualice el sistema como un conjunto de bloques, cada uno de los cuales representa un mdulo o subsistema del mismo. 3. Especicaciones de los mdulos. Por cada mdulo deber tenerse la siguiente informacin: Nombre del mdulo. Descripcin detallada del mdulo y sus funciones. Diagrama general del mdulo. Flujo de pantallas (si corresponde) Lista de componentes que lo implementan. Lista de bases de datos. Lista de archivos y tablas que utiliza. Lista de las vistas lgicas de los datos. Lista de los informes que genera. 4. Especicaciones de los procesos Inventario general de procesos del sistema: Es una lista de todos los procesos, la cual contendr los siguientes datos: Nombre del proceso, Descripcin breve y Mdulo al que pertenece mdulos que incluye. Dejar documentado que para obtener informacin particular de cada proceso se deber relacionar este manual con el manual de operaciones. 5. Especicaciones de programacin: Para cada componente de programacin del sistema (dependiendo del lenguaje a utilizar: programa, subrutina, procedimiento o funcin), deber incluirse la siguiente informacin: Nombre del componente. Descripcin y objetivos. Diagrama general del componente. 6. Especicaciones de los datos
82
Modelo conceptual de datos: Permite visualizar las entidades de datos requeridas por el sistema y sus relaciones. Se debern adjuntar:
Diagrama general. Diagrama de las distintas vistas (si fuese necesario). Denicin de las entidades. Diccionario de datos.
Diseo lgico de base de datos: Documenta la base de datos segn la perspectiva de los desarrolladores de aplicaciones y los usuarios nales, sin preocuparse por su implementacin fsica en un DBMS (Database Management System) particular. Se debern adjuntar:
Diagrama de tablas y sus relaciones. Diagrama de las distintas vistas (si fuese necesario). Denicin de atributos y dominios.
Diseo fsico de base de datos: Contiene las deniciones detalladas de todos los archivos y/o bases de datos del sistema y cada uno de sus componentes (tablas, columnas, claves, ndices, integridad referencial, triggers, etc). Adjuntar la forma en que cada programa los accede y procesa sus datos, su localizacin fsica y la descripcin de su sistema de backup. Para aquellos que tengan proceso de mantenimiento independiente del sistema, se deber adjuntar la forma de acceso al men correspondiente y las instrucciones para su uso.
7.3.6. Manual de mantenimiento

Objetivos Contener los procedimientos requeridos para asegurar el mantenimiento del sistema despus de su instalacin. Identicar los materiales necesarios para el proceso de mantenimiento. Documentar la ubicacin de cada componente del sistema susceptible de ser modicado. Contenidos 1. Documentacin del sistema: Contiene el inventario y una breve descripcin del contenido de cada uno de los manuales que conforman la documentacin del sistema, as como el nmero de copias emitidas, su distribucin y las ubicaciones fsicas en las que se encuentran almacenadas. Esta informacin permite asegurar que todas las modicaciones que se efecten sobre el sistema despus de su instalacin se reejen en la documentacin existente. 2. Libreras del sistema: Presenta el inventario de todas las libreras fuente y objeto del sistema, detallando para cada una de ellas los siguientes datos: Nombre, versin, fecha, ubicacin, tipo y uso (de test, produccin, etc.) Contenido (directorio de cada librera). Instrucciones de uso. Lista de autorizaciones de acceso. 3. Modelo de pruebas del sistema: Contiene toda la informacin generada para la ejecucin de las pruebas del sistema (pruebas unitarias, prueba de integracin, pruebas de usuario y prueba de aceptacin del usuario). 4. Material de capacitacin: Incluye el inventario y la descripcin del material de capacitacin disponible (manual del instructor, guas de participante, casos prcticos, etc.) incluyendo su ubicacin, nmero de copias existentes y la audiencia a las que se encuentran orientados. 5. Instrucciones de soporte a usuarios: Dene los procedimientos de servicio al usuario para dar respuesta a las llamadas de emergencias, los requisitos de mejoras o absorber consultas especcas acerca del sistema. Asimismo especica los procedimientos para registrar las fallas o problemas que se presenten durante la operacin diaria del sistema.
Tutorial posterior
Finalizacin del proyecto El objetivo llegados a este punto consiste en entregar el producto al cliente y ponerlo en condiciones de funcionar. La aceptacin ocurre cuando han terminado todas las actividades. Se adjunta una plantilla para el informe de cierre del proyecto. Los indicadores del proyecto son un conjunto de medidas para evaluar de un modo objetivo los resultados. Son de varios tipos: econmicos, nancieros, de ocupacin laboral y de gestin.
83
Planicacin de revisiones y organizacin del mantenimiento Se denen los 4 tipos de mantenimiento (perfectivo, correctivo, adaptativo y preventivo) y la problemtica asociada. Se dene el concepto de cdigo heredado (legacy code) y se da una descripcin de como se debe gestionar el mantenimiento. Se dene a su vez una plantilla de documento para esta tarea. El objetivo de la planicacin del mantenimiento es asignar recursos lo antes posible para que estn disponibles en su momento, para ello se dene un plan de mantenimiento. Las tcnicas de mantenimiento son: ingeniera inversa, identicacin de componentes funcionales, reestructuracin y reingeniera. Recopilacin y organizacin de la documentacin Se exponen los motivos para documentar, directrices genricas a seguir para la redaccin de un documento, una clasicacin de los documentos y una plantilla a seguir para los ms importantes. El tipo de documentos que se contemplan aqu son los dirigidos a usuarios o mantenedores. Se hace hincapi en el manual de usuario, el manual del sistema y el manual de mantenimiento.

1. Qu es la barrera del mantenimiento? Hay alguna solucin? 2. Qu cosas debe tener en cuenta el plan de mantenimiento? 3. Las pruebas de regresin son las mismas pruebas que se han aplicado antes pero que vuelven a pasarse cada vez que se hace un cambio. Es razonable pasar las pruebas de regresin de los mdulos que no se cambian?. 4. Cules son los objetivos del manual de usuario? 5. En qu manuales situara la siguiente documentacin? Arquitectura general del sistema Lista de mensajes de error Tutorial Diseo lgico de la base de datos Diseo fsico de la base de datos Informacin acerca de las pruebas Especicacin de los procesos
Los contenidos de este tema tambin se puede estudiar en [Som98, cap. 8], [Haw98, cap. 19] [Sch92, cap. 11].
84
Captulo 8
Metodologas de desarrollo
Tutorial Previo
Introduccin
Una vez que hemos visto las fases ms habituales del proceso de anlisis, diseo y mantenimiento del software, es necesario estudiar algunas formas de agrupar, organizar, secuenciar y distribuir temporalmente las tareas estudiadas, segn los detalles de diferentes metodologas. Una metodologa constituye, en denitiva, el manual o gua que realmente se pone en prctica al abordar la construccin de un sistema. Las metodologas 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 especicacin, diseo, etc. de un modo concreto; algunas incluso estn apoyadas por herramientas hechas a medida (por ejemplo el mtodo Rational). El tipo de metodologas que se van a ver estn orientadas a objetos que son del tipo que demanda el mercado actualmente y adems dan buenos resultados. Se estudia en primer lugar el Proceso Unicado de Rational por su amplia difusin y consideracin de metodologa tradicional. A continuacin se presenta una metodologa alternativa muy reciente, llamada Extreme Programming, que tiene caractersticas muy interesantes. A continuacin se presenta la metodologa de planicacin, desarrollo y mantenimiento de sistemas de informacin del Ministerio de las Administraciones Pblicas denominada Mtrica (versin 3). Finalmente se hace una aproximacin hacia nuevos enfoques de desarrollo de software surgidos a raz del movimiento del Software Libre.

Es necesario que el alumno haya estudiado previamente los temas 3 al 7, para que comprenda cules son los elementos que conforman todo el proceso de desarrollo del software. En este tema el alumno podr retomar tambin 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 aplicacin que se desarrolla. En este tema solamente se detallan unas cuantas ilustrativas. Se trata de aprender mtodos actuales, realistas y prcticos de como construir un sistema desde su concepcin hasta su mantenimiento.

Este captulo es principalmente terico, pero tiene una vertiente prctica (ver apartado de actividades) que se recomienda realizar, al menos de forma simulada imaginando los diferentes escenarios, ya que al igual que ocurra en el captulo dedicado a la implementacin, la nica manera de asimilar realmente este captulo es realizar un proyecto donde se ponga en prctica alguna metodologa. No se debe pensar que se domina realmente una metodologa hasta que se ha puesto en prctica dentro de un grupo de desarrollo. La razn de que la palabra grupo aparezca en negrita es que esto no se puede afrontar fcilmente como un esfuerzo individual (como con el PSP). Proceso unicado de Rational. El material correspondiente principal est en esta gua didctica. Adicionalmente se puede repasar [Pre01, secs. 21.1 a 21.4]. Mtodo Extreme Programming. Incluido en esta gua didctica. Mtrica 3. Incluido en esta gua didctica. Mtodos de software libre: catedral vs. bazar. Incluido en esta gua didctica.
85
86
8.1. Introduccin a las metodologas de desarrollo

En los captulos precedentes hemos visto las fases del ciclo de vida del desarrollo de aplicaciones. Estas fases son relativamente independientes del tipo de metodologa que se siga. Una metodologa consiste en concretar el tipo de ciclo de vida que se va a seguir y la forma en la que se realizan las actividades dentro de cada etapa, ahora bien, las etapas tienen que seguir siendo las mismas sea cual sea la metodologa; es necesario tener una fase de especicacin porque se trabaja con los requisitos que proporciona el cliente. Que una metodologa utilice el ciclo de vida en cascada y que esto se haga solo al principio o que sea iterativa y haya varias mini-fases de este tipo es lo que distingue una de otra, pero esta actividad hay que realizarla de todas formas. El diseo es otra fase que es necesaria sea cual sea la metodologa por los mismos motivos. La especicacin es relativamente independiente de la metodologa porque las tcnicas de comunicacin con el cliente son siempre las mismas, pero en el caso del diseo es donde las cosas empiezan a divergir. Existen dos tipos de diseo: estructurado y orientado a objetos. Una metodologa se decanta entre uno de los dos. En este captulo hemos decidido dar como botn de muestra dos metodologas de diseo orientadas a objetos actuales: Extreme Programming y el Proceso Unicado de Rational. El anlisis y diseo estructurados, que son mtodos bastante formalizados, han sido cubiertos en captulos anteriores.
8.2. Proceso unicado de Rational

Es una de las metodologas ms extendidas y conocidas por su amplia difusin comercial. Se puede estudiar como una metodologa representativa de tipo clsico. Fue denido por los creadores del UML unicando los mtodos de Jacobson, Booch y Rumbaugh. El hecho de que la empresa R ATIONAL tambin distribuya herramientas especcas basadas en el mismo mtodo, que facilitan el desarrollo, ha contribuido a su gran expansin. Este proceso se maneja por casos de uso (correspondientes a los modos uso por los actores o agentes usuarios) para la extraccin de requisitos y la identicacin de las partes funcionales en las que se divide la solucin. La arquitectura del proceso se modela con orientacin a objetos.
8.2.1. Introduccin
Toda esta seccin es un resumen de los 11 primeros captulos del libro [JBR00c]. El Proceso Unicado de Rational es una metodologa de desarrollo de software orientada a objetos creada por Rational Software Corporation. Los creadores de la metodologa son los mismos que los del UML: Ivar Jacobson, Grady Booch y James Rumbaugh, que respectivamente eran autores de las metodologas: Process Objectory, el mtodo Booch y la metodologa OMT. Como toda metodologa de desarrollo software su nalidad es convertir las especicaciones que da el cliente en un sistema software. Las caractersticas que tiene el R.U.P. son: 1. 2. 3. 4. 5. Est basado en componentes. Estos componentes a su vez estn conectados entre s a travs de interfaces. Utiliza el UML como notacin bsica. Dirigido por casos de uso. Centrado en la arquitectura. Ciclo de vida iterativo e incremental.
El proceso unicado est dirigido por casos de uso Los casos de uso se vieron en el apartado dedicado a UML. Lo importante acerca de ellos son dos cosas: 1. Representan los requisitos funcionales del sistema desde el punto de vista del usuario. 2. Se usan como gua para el proceso de diseo, implementacin y pruebas, por eso se dice que el RUP est dirigido por casos de uso. El proceso unicado es iterativo e incremental El proyecto se divide en una serie de partes o mini-proyectos. Cada uno de esos mini-proyectos va a ser una iteracin. En cada iteracin se trata: un conjunto de casos de uso y los riesgos ms importantes. La vida del proceso unicado El proceso unicado consiste en una serie de ciclos. Al nal de cada ciclo se tiene una versin del producto. Las fases de cada ciclo son: Inicio, Elaboracin, Construccin y Transicin. Cada fase termina con un hito (ver gura 8.1), que se determina por la disponibilidad de un conjunto de artefactos (modelos o documentos desarrollados hasta cierto punto). 1. Inicio: Se describe el producto nal. Se responde a las preguntas: Cules son las principales funciones del sistema para sus usuarios ms importantes?. La respuesta est en el modelo de casos de uso simplicado. Cmo podra ser la arquitectura del sistema?
8.2 Proceso unicado de Rational
87
Version 1 Ciclo 1 Ciclo 2
Version 2
Version n Ciclo n
. . .
Inicio Requisitos Analisis Diseno Implementacion Prueba Iter. 1 Iter. 2
Elaboracion
Construccion
Transicion
. . .
. . .
. . .
. . .
. . .
Iter. n
Figura 8.1: La vida del proceso unicado Cul es el plan del proyecto y cunto costar desarrollar el producto? 2. Elaboracin: Se especican en detalle la mayora de los casos de uso y se disea la arquitectura del sistema. La arquitectura se especica en forma de vistas de todos los modelos del sistema y todas ellas especican el sistema entero. 3. Construccin: Se construye el producto. Se utilizan la mayor parte de los recursos. Al nalizar se cubren todos los casos de uso. La pregunta es: Cubre el producto las necesidades de los usuarios como para hacer una primera entrega? 4. Transicin: El producto existe en versin Beta. Unos pocos usuarios experimentados prueban el producto. Tipos de defectos: a) Los que tienen importancia como para justicar una versin incremental (versin delta) b) Los que se pueden corregir en la siguiente versin. A su vez, cada fase puede tener varias iteraciones, cada una con cinco ujos de trabajo: Requisitos, Anlisis, Diseo, Implementacin y Prueba. El producto El producto terminado debe incluir ms cosas que el cdigo ejecutable: Requisitos, casos de uso, especicaciones no funcionales y casos de prueba. Para llevar a cabo un ciclo se necesitan todas las representaciones del producto software: 1. Modelo de casos de uso. 2. Modelo de anlisis para: a) Renar los casos de uso b) Establecer la asignacin inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento. 3. Modelo de diseo, que dene: a) Estructura esttica del sistema en la forma de subsistemas, clases e interfaces. b) Casos de uso reejados como colaboraciones.
88
4. Modelo de implementacin, que incluye: a) Componentes (que representan al cdigo fuente). b) Correspondencia de las clases con los componentes. 5. Modelo de despliegue, que dene: a) Nodos fsicos (ordenadores). b) La correspondencia de los componentes con esos nodos. 6. Modelo de prueba, que describe los casos de prueba que denen los casos de uso. 7. Una representacin de la arquitectura.
8.2.2. Las cuatro P: Personas, Proyecto, Producto y Proceso

1. Personas: Existen una serie de factores motivacionales que pueden mejorar o empeorar la eciencia. Es conveniente que: El proceso parezca viable, se gestione el riesgo, la gente est estructurada en pequeos equipos (de seis a ocho personas), hacer una planicacin realista del proyecto, el proyecto debe ser comprensible y es mejor tener sensacin de cumplimiento de objetivos. Debe existir un proceso de desarrollo estandarizado que todo el mundo siga. Una persona asume uno o varios papeles como trabajador en el proceso de desarrollo en funcin de sus aptitudes, que deben ser consideradas cuidadosamente. 2. Proyectos: Los equipos de proyecto tienen que tener en cuenta: Un proyecto es una sucesin de cambios, que pasa por iteraciones, que son en si mismas miniproyectos y se debe tener un patrn organizativo. 3. Producto Un sistema software no es solo los binarios (cdigo ejecutable), es todos los artefactos que se necesitan para representarlo en forma comprensible para mquinas y personas (trabajadores y usuarios) Artefactos: Son la informacin que crean y manejan los trabajadores, como los diagramas UML, prototipos, etc. Hay dos tipos: de ingeniera (los que nos ocupan) y de gestin. Coleccin de modelos: Un sistema se construye utilizando distintos modelos por cada posible perspectiva del sistema. La eleccin de los modelos correctos es uno de los factores crticos para una correcta comprensin del sistema. Un modelo:
Es una abstraccin semnticamente cerrada del sistema, es decir, para poder interpretarlo no se necesita informacin de otros modelos. Siempre identica al sistema que est modelando. El sistema est formado a parte de sus modelos por las inter-relaciones que se establecen entre estos.
4. Proceso: Un proceso es una plantilla que sirve para hacer proyectos igual que de una clase se derivan instancias. Las actividades relacionadas conforman ujos de trabajo, en UML se representan como estereotipos de colaboracin en el cual los trabajadores y los artefactos son los participantes. El proceso unicado se adapta en funcin de las necesidades del proyecto segn factores: organizativos, de dominio, del ciclo de vida y tcnicos. Las herramientas: El RUP est soportado por herramientas CASE. Es mejor esto al proceso manual para evitar trabajo repetitivo. La herramienta escogida deber dar soporte a todo el ciclo de vida y usar UML. Las herramientas son importantes porque inuyen en el proceso, el cual a su vez dirige a las herramientas.
8.2.3. Proceso dirigido por casos de uso

Los casos de uso son los encargados de la captura de requisitos. Con ellos se identican y especican clases, subsistemas, interfaces, casos de prueba y se planican las iteraciones del desarrollo y de la integracin. En una iteracin nos guan a travs del conjunto completo de ujos de trabajo. Los objetivos de la captura de requisitos son dos: 1. Encontrar los verdaderos requisitos 2. Representarlos de un modo adecuado para los usuarios, clientes y desarrolladores. Veamos ahora lo que es un caso de uso. Un actor es una persona o proceso externo al sistema que interacta con l. Un caso de uso es una secuencia de acciones que el sistema lleva a cabo para ofrecer un resultado de valor para un actor, es decir, un caso de uso proporciona un resultado observable para el usuario. Dentro de una interaccin con el sistema puede haber muchas
89
variantes, muchas de ellas pueden ser recogidas en un nico caso de uso. Durante el anlisis y el diseo el modelo de casos de uso se transforma en un modelo de diseo a travs de un modelo de anlisis. Motivacin de los casos de uso: 1. Proporcionan un medio sistemtico de capturar requisitos funcionales centrndose en el valor aadido para el usuario. 2. Dirigen el proceso de desarrollo porque el anlisis, diseo y prueba se planican en trminos de casos de uso. 3. Para idear la arquitectura (cada iteracin implementa un conjunto de casos de uso proporcionando un incremento).
8.2.4. Proceso centrado en la arquitectura

La arquitectura es un conjunto de representaciones de un sistema tomadas cada una desde diferentes perspectivas. Cada una de estas representaciones se llaman vistas. La informacin que contiene es: 1. Organizacin del sistema software. 2. Elementos estructurales del sistema, sus interfaces y sus comportamientos. 3. Composicin de los elementos estructurales y del sistema en subsistemas progresivamente ms grandes. Las vistas que se incluyen son: los casos de uso, modelo de anlisis, modelo del diseo, etc. La arquitectura es necesaria para: Comprender el sistema, Organizar el desarrollo, Fomentar la reutilizacin y Hacer evolucionar el sistema. Casos de uso y arquitectura Se construye la arquitectura de forma que permita implementar los casos de uso actuales y previsibles en el futuro. Otros factores que inuyen en la arquitectura son: 1. 2. 3. 4. 5. 6. Tipo de producto software que queremos desarrollar. Qu tipo de middleware (capa intermedia) queremos utilizar. Qu sistemas heredados queremos utilizar. A qu estndares y polticas corporativas debemos ajustarnos. Requisitos no funcionales generales. Necesidades de distribucin.
Para integrar todas estas necesidades primero se hace un diseo de alto nivel para la arquitectura, a modo de arquitectura de capas (una capa es una parte bien denida de un sistema a partir de paquetes o subsistemas). Despus formamos la arquitectura en un par de construcciones (Versin ejecutable del sistema o de una parte del mismo). Todo esto dentro de la primera iteracin. Al principio se trabaja con las partes generales de la aplicacin y requisitos generales no funcionales. En esta primera pasada se trata de tener una visin general. Segunda construccin: Se trabaja con requisitos especcos a base de escoger unos cuantos casos de uso relevantes. Se implementan subsistemas a travs de una serie de iteraciones. Al nal de debera conseguir una arquitectura estable. Con una arquitectura estable se implementan los casos de uso que quedan para proporcionar toda la funcionalidad.
8.2.5. Proceso iterativo e incremental

El proceso de desarrollo consta de una serie de hitos que dan el criterio a seguir por los diseadores para dar el paso de una fase a la siguiente. En una fase se pasan por una serie de iteraciones e incrementos que nos llevan hasta esos hitos. Los criterios a seguir en las fases son: Inicio: Viabilidad. Elaboracin: Capacidad de construir el sistema con un presupuesto limitado. Construccin: Sistema capaz de una operatividad inicial en el entorno del usuario. Transicin: Sistema que alcanza operatividad nal. Un proceso iterativo e incremental signica llevar a cabo un desarrollo en pequeos pasos. Para ello: 1. Se escoge una pequea parte del sistema y se sigue con el todo el ciclo de vida clsico en cascada (planicacin, especicacin, diseo ... ). 2. Si estamos satisfechos con el paso anterior damos otro. Cada uno proporciona retroalimentacin. 3. Las iteraciones son distintas. Al principio del proyecto proporcionan una comprensin de los requisitos, del problema, de los riesgos y el dominio de la solucin; las ltimas nos proporcionan la visin externa (producto para el cliente). Motivos para adoptar un ciclo de vida iterativo e incremental: 1. Para identicar riesgos. Esto ocurre en las dos primeras fases: Inicio y Elaboracin, en vez de en la etapa de integracin como con el modelo en cascada.
90
2. La arquitectura se establece en la fase de elaboracin y eso permite cambiarla si se considera necesario en una etapa temprana del desarrollo, por tanto con pocos costes. En el ciclo de vida en cascada esto se descubre ms tarde. 3. Gestin de requisitos cambiantes: Gracias a que se hace una integracin continua los usuarios disponen desde las primeras iteraciones de versiones ejecutables que permiten un cambio de impresiones en este sentido. 4. Fallos: Al igual que en los puntos anteriores, la ventaja de este ciclo de vida es que los fallos se van descubriendo a medida que se implementan nuevas funcionalidades; esto signica que no hay una avalancha de problemas al nal. 5. Aprendizaje: Con un par de iteraciones es suciente para que todo el mundo comprenda los diferentes ujos de trabajo. Gestin de riesgos Un riesgo es cualquier cosa que pone en peligro el xito del proyecto. Las iteraciones se organizan para reducir riesgos. Tipos de riesgos: 1. Tcnicos: a) Relacionados con nuevas tecnologas: Distribuir procesos en muchos nodos Tcnicas an incompletas como reconocimiento de lenguaje natural. b) Relativos a la arquitectura. Una arquitectura robusta se adapta a los cambios y muestra donde encajan los componentes reutilizables. c) Identicar los requisitos correctos. d) Mal rendimiento. 2. No tcnicos: La direccin es responsable de ellos. Tratamiento de los riesgos Para cada riesgo hay cuatro alternativas, a saber: Evitarlo: Replanicando o cambiando los requisitos. Limitarlo: Que solo afecte a una parte del proyecto. Atenuarlo: Mediante pruebas se aisla y se aprende sobre l. Controlarlo: Si no se puede evitar se disea un plan de contingencia. Iteraciones Cuando una iteracin termina se analiza para ver si han aparecido nuevos requisitos. Se examinan tambin los riesgos que quedan. Las pruebas de regresin comprueban que no se han introducido errores sobre partes anteriores a las de la iteracin en curso. La planicacin de cada iteracin solo se puede hacer en detalle para la prxima iteracin a la actual y con menos detalle para las siguientes. Secuenciacin: Los casos de uso establecen una meta y la arquitectura un patrn. Con esto en mente se planica la secuencia de iteraciones. Las primeras se centran en los requisitos, problemas y riesgos y las siguientes en la visin externa. Es posible que las iteraciones se solapen un poco en el tiempo. El orden de las iteraciones es el que permita que las decisiones importantes se tomen antes. El conjunto de modelos que representa al sistema en un momento dado se llama lnea base. En la fase de elaboracin se identican los casos de uso que tienen un impacto sobre la arquitectura y se representan como colaboraciones. De esta forma se construye la lnea base. El resultado de una iteracin es un incremento, y consiste en la diferencia entre dos lneas base sucesivas. Cada fase termina con un hito, el desarrollo iterativo supone un cambio de actitud: Es necesario dejar de valorar tanto las lineas de cdigo y valorar ms la reduccin de riesgos y la lnea base.
8.2.6. Captura de requisitos

Cada tipo de proyecto es diferente y tendr una aproximacin diferente pero se puede decir que un ujo de trabajo arquetpico tendr que cubrir los siguientes puntos: 1. Enumerar los requisitos candidatos: Es una lista de caractersticas provisional que se van convirtiendo en requisitos o en artefactos. Sirve para la planicacin del trabajo. Se indica: su nombre, una descripcin, su estado, su coste estimado, prioridad y nivel de riesgo. 2. Comprender el contexto del sistema. Hay dos forma de entender este contexto:
91
a) Modelado del dominio: Describir los objetos importantes del contexto como objetos del dominio (clases) y enlazarlos. Se modela en UML. Estos objetos se pueden educir gracias a reuniones con expertos del dominio. Los productos son: Un glosario de trminos y los objetos. Tipos de objetos: Objetos del negocio (p. ej: pedidos, cuentas, contratos), Objetos del mundo real y Sucesos. El glosario y los objetos se usarn al descubrir casos de uso y describir la interfaz de usuario y para sugerir clases internas del sistema en desarrollo. b) Modelado del negocio: Describir los objetos para comprenderlos. No es exclusivo de los negocios, es una forma de llamar a este tipo de modelado. Est soportado en UML por el modelo de casos de uso y el modelo de objetos (modelo interno). Lo que hace es describir los procesos en trminos de casos de uso y actores del negocio. Se desarrolla en dos pasos: 1) Se crea un modelo de casos de uso que identique a los actores. 2) Se desarrolla un modelo de objetos del negocio que realiza los casos de uso anteriores compuesto por trabajadores, entidades del negocio y unidades de trabajo. Bsqueda de casos de uso a partir de un modelo del negocio: Un actor es un trabajador o cliente del negocio. Cada trabajador cumple un papel en cada caso de uso. Despus se buscan los casos de uso de los actores del sistema. 3. Capturar requisitos funcionales: Se hace con casos de uso. Aparte de esto hay que especicar como ser la interfaz de usuario. 4. Capturar requisitos no funcionales. Por ejemplo: Requisito de interfaz: Especica como se relaciona con un elemento externo. Requisito fsico: Caractersticas como forma, tamao, peso, etc. Restriccin de diseo: Extensibilidad, mantenibilidad o reutilizacin. Restriccin de implementacin: Normas de codicacin, lenguaje, etc. En la fase de inicio se capturan los casos de uso para delimitar el sistema y el alcance del proyecto. En la fase de elaboracin se capturan los requisitos para delimitar el esfuerzo. Al nalizar esta fase se deben haber capturado el 80 %.
Artefactos Veamos los artefactos utilizados en la captura de requisitos. 1. Modelo de casos de uso: Es un modelo con actores, casos de uso y relaciones entre ellos. Pueden agruparse en paquetes y se puede ver desde distintos puntos de vista. 2. Actor: Un actor es cualquier cosa externa al sistema, desde un usuario hasta otro sistema. El conjunto de actores delimitan todo lo externo. Puede jugar varios roles y para cada uno de ellos tendr un caso de uso. 3. Caso de uso: Cada uno es una especicacin, una secuencia de acciones que el sistema lleva a cabo para realizar una funcionalidad. Puede incluir diagramas de estados, diagramas de actividad, colaboraciones y diagramas de secuencia. Cada caso de uso tiene atributos. Una instancia de caso de uso es la ejecucin de un caso de uso, que estar desencadenada por un evento o por la instancia de un actor. El ujo de sucesos de un caso de uso especica cmo interacta el sistema con los actores. Consta de secuencias de acciones. 4. Descripcin de la arquitectura: Es una vista de los casos de uso signicativos para la arquitectura. Usada para decidir que casos de uso se implementan en cada iteracin. 5. Glosario: Conjunto de trminos comunes en el sistema. Sirve para evitar confusiones. Sale del modelo de negocio o del modelo del dominio. 6. Prototipo de interfaz de usuario: tiles para depurar los casos de uso.
Trabajadores Entendemos por trabajador como una persona real que desempea una funcin dentro del proyecto. Una misma persona puede ser varios trabajadores. Tipos de trabajadores: 1. Analista de sistemas: Modela los casos de uso, encuentra los actores y redacta el glosario. Tambin es la persona que se encarga de capturar los requisitos. 2. Especicador de casos de uso: Es un asistente del anterior. Realiza cada caso de uso en detalle trabajando con el usuario. 3. Diseador de interfaz de usuario: Se suelen usar prototipos, uno por cada actor. 4. Arquitecto
92
Flujo de trabajo Se representa mediante un diagrama (ver gura 8.2). El diagrama tiene calles, en la cabecera se sitan los actores y en las calles las actividades. Cuando un trabajador ejecuta una actividad crea y modica artefactos. Se representa el ujo lgico, pero las actividades reales no tienen porque ser secuenciales. Veamos las actividades una a una.
Analista de sistemas
Encontrar actores y casos de uso
Estructurar el modelo de casos de uso
Arquitecto
Priorizar los casos de uso
Especificador de casos de uso
Detallar un caso de uso
Diseador de interfaces de usuario
Prototipar la interfaz de usuario
Figura 8.2: Flujo de trabajo: Captura de requisitos
1. Encontrar actores y casos de uso: Se realiza por un equipo de analistas y usuarios. La actividad consta de cuatro pasos: a) Encontrar los actores. Hay dos estrategias para ello: Encontrar un usuario que represente al actor. Encontrar roles iguales y fusionarlos en un nico actor. b) Encontrar los casos de uso: Si se parte del modelo del negocio cada rol de cada trabajador se corresponder con un caso de uso. En otro caso se identican hablando con los usuarios. Por otra parte, los casos de uso se caracterizan por proporcionar algn servicio de utilidad al actor y es mejor que el actor sea una persona real. c) Describir brevemente cada caso de uso: Una vez identicados los casos de uso se les da una descripcin breve o con los pasos a seguir. d) Describir el modelo de casos de uso completo: Se trata de dar una visin general de los casos de uso. Se puede utilizar cualquier conjunto de diagramas que se consideren oportunos. 2. Priorizar casos de uso: Se trata de ver qu casos de uso se hacen en qu iteraciones, para ello hay que tener en cuenta consideraciones econmicas y en general no tcnicas. El resultado se pone en la vista del modelo de casos de uso. 3. Detallar un caso de uso. Para ello hay tres actividades a realizar: Estructuracin de la descripcin de casos de uso: Un caso de uso incluye estados y transiciones entre ellos y el grco resultante puede ser complicado. Se puede describir primero el camino bsico (el ms normal) de principio a n y luego el resto de caminos alternativos. La descripcin debe incluir: Estado inicial como precondicin, posibles estados nales como postcondicin, la primera accin a ejecutar, orden (si existe) numerada de la acciones, caminos de ejecucin no permitidos, descripcin de caminos alternativos, la interaccin con los actores, utilizacin de recursos y acciones ejecutadas. Formalizacin de la descripcin: Un caso de uso se puede representar como una mquina de estados y si es demasiado complejo se puede utilizar alguno de los diagramas de UML: diagramas de estados, de actividad o de interaccin. 4. Prototipar la interfaz de usuario: Se trata de crear una interfaz que permita la interaccin del usuario para poder realizar los casos de uso. Se hace en dos pasos: Crear el diseo lgico: Se identican todos los elementos de la interfaz con los que va a interactuar el usuario. Cada elemento puede jugar varios roles porque puede estar en varios casos de uso. Crear el diseo y prototipo fsico: Se identican los elementos necesarios y su conguracin. 5. Estructurar el modelo de casos de uso: La nalidad es extraer descripciones de funcionalidad de dos tipos:
93
Generales y compartidas: Se buscan funcionalidades de casos de uso compartidas. La reutilizacin en los casos de uso supone un tipo de herencia, porque es necesario que exista una instancia tanto del caso que reutiliza como del que es reutilizado Adicionales y opcionales: La relacin de extensin entre casos de uso consiste en que un caso de uso A aade una secuencia de acciones a un caso de uso B. La extensin se ejecuta en funcin de que se cumpla una condicin. Anlisis Durante el anlisis se estructura el conocimiento que se ha conseguido de los usuarios por clases y paquetes en vez de casos de uso, de modo que no contenga inconsistencias. El anlisis est pensado para dar la visin interna del sistema (en vez de la externa de los casos de uso) a los desarrolladores y por eso est descrito con su lenguaje. Es una primera aproximacin al diseo y dene realizaciones de casos de uso. El resultado del anlisis es el modelo de anlisis. Se debe hacer anlisis cuando: 1. 2. 3. 4. Se quiere planicar cada una de las iteraciones. Para dar una visin general del sistema. Si se tienen varias opciones de diseo, el anlisis da una visin unicadora de todas ellas. Se utiliza un sistema heredado complicado.
El modelo de anlisis describe los resultados del anlisis y mantiene la consistencia de este modelo durante el ciclo de vida. En las primeras iteraciones se hace nfasis en este modelo, ms adelante se deja de actualizar. Artefactos 1. Modelo del anlisis: Consiste en una jerarqua de paquetes, que son abstracciones de subsistemas o capas de diseo. Los paquetes contienen clases del anlisis y realizaciones de casos de uso. 2. Clase del anlisis: Es una abstraccin de una o varias clases y/o subsistemas del diseo del sistema. Se centra en los requisitos funcionales. Su comportamiento en vez de con interfaces se dene con responsabilidades, que son una descripcin textual. Estas clases tienen atributos del dominio del problema, que en el diseo pueden pasar a ser clases. Se pueden corresponder con tres estereotipos: de interfaz, de control o de entidad. 3. Realizacin de caso de uso-anlisis: Explica como se lleva a cabo un caso de uso. Utiliza para ello diagramas de clases, diagramas de interaccin y una descripcin textual del ujo de sucesos. 4. Paquete del anlisis: Incluye clases del anlisis, realizaciones de casos de uso y posiblemente otros paquetes de anlisis. Los paquetes deben tener cohesin fuerte y acoplamiento dbil. Cada paquete representa cosas distintas, reconocibles por los conocedores del dominio. 5. Paquete de servicio: Es un tipo de paquete de anlisis, pero indivisible. Un servicio es un paquete de funcionalidad que puede ser utilizado en varios casos de uso y los casos de uso funcionan utilizando varios servicios. Un paquete de servicio puede contener una o ms clases relacionadas funcionalmente. 6. Descripcin de la arquitectura: Es la vista del modelo de anlisis. Contiene la descomposicin del modelo y sus dependencias, las clases de entidad, de interfaz, de control y las de anlisis. Tambin las realizaciones de casos de uso. Trabajadores 1. Arquitecto: Es el responsable de la integridad del modelo de anlisis y de la descripcin de la arquitectura. Un modelo de anlisis es correcto si realiza la funcionalidad de los casos de uso. 2. Ingeniero de casos de uso: Es responsable de que cada caso de uso responda a la funcionalidad requerida, tanto en el anlisis como en el diseo. 3. Ingeniero de componentes: Comprueba que cada clase del anlisis cumpla los requisitos que se esperan de ella. Mantiene la integridad de los paquetes del anlisis. El ingeniero de componentes de un paquete lo es tambin de las clases del anlisis contenidas en l. Flujo de trabajo Diagrama del ujo de trabajo en el anlisis (ver gura 8.3) que muestra las actividades, los artefactos y los participantes. Veamos las actividades: 1. Anlisis de la arquitectura: Para esbozar la arquitectura se realizan tres tareas: a) Identicar los paquetes de anlisis. Una forma es asignar casos de uso a un paquete y realizar esa funcionalidad en el paquete. Si hay clases comunes entre diferentes paquetes se pueden sacar a otro paquete o fuera de cualquier paquete. Los paquetes de servicio se identican cuando el anlisis ya est avanzado. La forma de identicarlos es: Hay uno por cada servicio opcional. Por cada servicio que pueda hacerse opcional o por clases que estn relacionadas funcionalmente.
94
Arquitecto
Analisis de la arquitectura
Ingeniero de casos de uso
Analizar un caso de uso
Ingeniero de componentes
Analizar una clase
Analizar un paquete
Figura 8.3: Flujo de trabajo del anlisis b) Identicar clases de entidad obvias. Se trata de identicar las clases necesarias para esbozar la arquitectura y no ms. Las agregaciones y asociaciones entre clases del dominio pueden identicar asociaciones entre las clases de entidad. c) Identicacin de requisitos especiales comunes. Los requisitos especiales son los que aparecen durante el anlisis. 2. Analizar un caso de uso. Se analiza un caso de uso con tres nalidades: Identicacin de clases de anlisis. Descripcin de interacciones entre objetos del anlisis. Captura de requisitos especiales. 3. Analizar una clase. Los objetivos son: Identicar y mantener las responsabilidades de una clase del anlisis. Identicar y mantener los atributos y relaciones de la clase de anlisis. Capturar requisitos especiales sobre la realizacin de la clase de anlisis. 4. Analizar un paquete: Cada paquete debe realizar algunas clases del dominio o casos de uso, adems, se trata de que cada paquete sea tan independiente de los dems como sea posible y deben documentarse las dependencias entre paquetes para el mantenimiento. Las normas que se deben seguir con los paquetes respecto a cohesin y acoplamiento son las mismas que con los mdulos en la programacin estructurada, es deseable que el paquete sea cohesivo, es decir, que solo tenga clases relacionadas funcionalmente.
8.2.7. Diseo
La entrada del diseo es la salida de la fase anterior y la salida del diseo es un modelo directamente implementable. Debido a esta proximidad con la implementacin hay que comprender aspectos no funcionales como lenguajes de programacin, sistema operativo, etc. Tambin es necesario tener el sistema dividido en trozos manejables por equipos de trabajo. Los interfaces entre los diferentes subsistemas deberan estar claros. La implementacin debera seguir la misma estructura que el diseo y de esta forma se podra hacer un camino de ida y vuelta automatizado. Papel del diseo en el ciclo de vida Se realiza sobre todo en las fases de elaboracin y de construccin. Los artefactos son: 1. Modelo de diseo: Es un modelo de objetos que describe como los casos de uso inuyen en el sistema. Es tambin una abstraccin de la implementacin. Cada subsistema o clase del diseo representa una abstraccin con una correspondencia con la implementacin. Los casos de uso se realizan por clases de diseo, lo cual se representa por colaboraciones en el modelo del diseo. 2. Clase del diseo: Tiene una correspondencia directa con una clase en la implementacin. Se utilizan caractersticas del lenguaje de programacin para describirlas. 3. Realizacin de caso de uso-diseo: Es una colaboracin que describe como se realiza un caso de uso del diseo, el cual tiene una relacin directa con un caso de uso del anlisis. Se compone de: Descripcin textual del ujo de eventos, diagrama de clases de diseo, diagramas de interaccin y requisitos de implementacin. 4. Subsistema de diseo: Representa una parte del sistema. Debe tener alta cohesin y bajo acoplamiento. Consta de clases del diseo, realizaciones de casos de uso, interfaces y posiblemente otros subsistemas. Un subsistema de servicio se corresponde con un paquete de servicio del anlisis que ofrece sus servicios en trminos de interfaces y tiene en cuenta requisitos no funcionales.
95
5. Interfaz: Una interfaz separa la especicacin de la funcionalidad en trminos de sus implementaciones. Son importantes porque describen las interacciones entre subsistemas. 6. Vista de la arquitectura del modelo de diseo. Consta de los siguientes elementos: Descomposicin del modelo de diseo en subsistemas, interfaces e interdependencias. Clases importantes del diseo. Realizaciones de caso-de-uso-diseo importantes. 7. Modelo de despliegue: Describe como se reparte la funcionalidad entre los nodos fsicos. Tiene nodos, que son procesadores o recursos hardware, relaciones entre ellos que son los modos de comunicacin (intranet, bus, etc). Describe la conguracin de la red. La funcionalidad de un nodo depende de los componentes que estn en l. 8. Vista de la arquitectura del modelo de despliegue: Muestra los artefactos relevantes para la arquitectura, como la correspondencia entre los componentes y los nodos. Trabajadores 1. Arquitecto: Es responsable de la integridad y de la arquitectura de los modelos de diseo y de despliegue. Un modelo es correcto si realiza la funcionalidad descrita en los casos de uso y nada ms. La arquitectura es correcta si estn presentes sus partes signicativas. 2. Ingeniero de casos de uso: Responsable de la integridad de las realizaciones de casos de uso-diseo y su comportamiento. Tambin es responsable de las descripciones textuales de los casos de uso. 3. Ingeniero de componentes: Garantiza que las clases del diseo estn correctamente denidas, as como el los subsistemas y sus interrelaciones. Flujo de trabajo Las actividades y sus relaciones de precedencia temporal estn reejadas en el grco de la gura 8.4:
Arquitecto
Diseo de la arquitectura
Ingeniero de casos de uso
Disear un caso de uso
Disear una clase
Disear un subsistema
Figura 8.4: Flujo de trabajo del diseo 1. Diseo de la arquitectura: Se trata de esbozar los modelos de diseo y despliegue y su arquitectura identicando los elementos necesarios para estos modelos: Nodos y conguraciones de red. Subsistemas e interfaces. Clases de diseo relevantes para la arquitectura. Identicacin de mecanismos genricos de diseo. 2. Diseo de un caso de uso. Los objetivos son: Identicar las clases del diseo y subsistemas necesarios para el ujo de sucesos. Distribuir el comportamiento entre los objetos del diseo y los subsistemas. Denir los requisitos sobre las operaciones de las clases del diseo, subsistemas e interfaces. Capturar requisitos de implementacin del caso de uso. 3. Diseo de una clase. Las actividades a realizar son: Esbozar la clase del diseo. Una clase puede ser de interfaz, de entidad o de control.
96
Identicar operaciones. Identicar atributos. Identicar asociaciones y agregaciones. Identicar las generalizaciones. Describir los mtodos. Describir estados. Tratar requisitos especiales. 4. Diseo de un subsistema. Las actividades para ello son: Mantener las dependencias entre subsistemas. Mantener interfaces proporcionadas por el subsistema. Mantener los contenidos de los subsistemas.
8.2.8. Implementacin
La implementacin tiene como nalidades: Planicar las integraciones. Se sigue un enfoque incremental. Distribuir el sistema entre los nodos. Implementar clases y subsistemas del diseo. Probar los componentes individuales hasta donde sea posible. Artefactos 1. Modelo de implementacin: Describe la implementacin de las clases y la organizacin de los componentes. Se compone de un sistema de implementacin, que a su vez consta de varios subsistemas. Cada sistema o subsistema consta de interfaces y componentes. 2. Componente: Es el empaquetamiento fsico de los elementos de un modelo. Algunos estereotipos son: < <executable> >, < <file> >, < <library> >, < <table> >, < <document> >. Un stub es el esqueleto de un componente de propsito especial utilizado para desarrollar o probar otro componente. 3. Subsistema de implementacin: Es una forma de organizar los artefactos del modelo de implementacin. El mecanismo de empaquetamiento depende de la herramienta de implementacin. Cada subsistema de implementacin se puede trazar hasta un subsistema de diseo (dependencias, interfaces, clases de diseo y subsistemas de diseo). 4. Interfaz: Los componentes y subsistemas de implementacin pueden utilizar las mismas interfaces y tener dependencias de uso sobre ellas. Cuando un componente proporciona una interfaz debe implementar todas sus operaciones. 5. Vista de la arquitectura del modelo de implementacin. Consta de los siguientes elementos: Descomposicin del modelo de implementacin, subsistemas e interfaces. Componentes clave. 6. Plan de integracin de construcciones: La forma de hacer la integracin es incremental. El plan describe la funcionalidad implementada en cada construccin y las partes del modelo de implementacin que estn afectadas por la construccin. Trabajadores 1. Arquitecto: Responsable de la integridad del modelo de implementacin, que es correcto si implementa la funcionalidad descrita en el modelo de diseo. Tambin es responsable de la arquitectura del modelo de implementacin y de la asignacin de componentes a nodos. 2. Ingeniero de componentes: Se encarga del cdigo fuente de uno o varios componentes y de uno o varios subsistemas de implementacin y de los elementos del modelo contenidos en l. 3. Integrador de sistemas: Planica la secuencia de construcciones necesarias en cada implementacin y la integracin de cada construccin. Flujo de trabajo La gura 8.5 es una representacin dinmica de las actividades con sus respectivos trabajadores. Vemoslas una a una. 1. Implementacin de la arquitectura: Esboza el modelo de implementacin identicando componentes signicativos y asignndolos a nodos 2. Integrar el sistema: Se crea un plan de integracin de construcciones y se integra cada construccin antes de que sea sometida a pruebas de integracin.
97
Arquitecto
Implementacion de la arquitectura
Integrador de sistema
Integrar sistemas
Implementar una clase Ingeniero de componentes Implementar un subsistema Realizar prueba de unidad
Figura 8.5: Flujo de trabajo de la implementacin 3. Implementar un subsistema. Se trata de asegurar que los requisitos implementados en la construccin y los que afectan al subsistema son implementados correctamente. 4. Implementar una clase. Para ello es necesario: Esbozar un componente chero que contiene la clase. Generar el cdigo fuente a partir de la clase de diseo y sus relaciones. Implementar sus operaciones. Comprobar que el componente proporciona las mismas interfaces que la clase de diseo. 5. Realizar prueba de unidad. Hay dos tipos de pruebas: Prueba de especicacin (caja negra) Prueba de estructura (caja blanca)
8.2.9. Prueba
La nalidad de esta fase es planicar, disear, implementar las pruebas de cada iteracin. Artefactos 1. Modelo de pruebas: Especica cmo son las pruebas de integracin y de sistema para los ejecutables. Pueden probarse tambin componentes como manuales de usuario o interfaces. 2. Caso de prueba: Especica la prueba que se hace sobre un requisito o conjunto de requisitos de un caso de uso o de una realizacin de un caso de uso-diseo. 3. Procedimiento de prueba: Especica cmo se lleva a cabo una realizacin de un conjunto de casos de prueba. 4. Componente de prueba: Es la automatizacin de un caso de prueba. 5. Plan de prueba 6. Defecto 7. Evaluacin de prueba Trabajadores 1. Diseador de pruebas: Responsable de la integridad del modelo de pruebas, de los objetivos y la planicacin de las pruebas. 2. Ingeniero de componentes: Responsable de la automatizacin de algunos procedimientos de prueba. 3. Ingeniero de pruebas de integracin: Las pruebas de integracin verican que los componentes integrados funcionan bien juntos. 4. Ingeniero de pruebas de sistema: Realiza las pruebas sobre el resultado de una iteracin y documenta los defectos encontrados.
98
Flujos de trabajo En la gura 8.6 se representa el diagrama de actividades:
Ingeniero de pruebas
Planificar prueba
Disear prueba
Evaluar prueba
Ingeniero de pruebas de integracion
Realizar prueba de integracion
Ingeniero de pruebas de sistema
Realizar prueba de sistema
Implementar pruebas
Figura 8.6: Flujo de trabajo de las pruebas 1. Planicar prueba: Para esta planicacin se describe primero una estrategia de prueba, se estiman los recursos necesarios y entonces se planica el esfuerzo de la prueba. 2. Disear prueba. Las actividades son: Identicar y denir los casos de prueba para cada construccin, que se subdivide en:
Diseo de los casos de prueba de integracin. Diseo de los casos de prueba del sistema. Diseo de los casos de prueba de regresin.
Identicacin y estructuracin de los casos de prueba. 3. Implementar prueba: Se trata de automatizar los procedimientos de prueba en la medida de lo posible creando procedimientos de prueba. 4. Realizar pruebas de integracin. Consta de los siguientes pasos: Realizar los procedimientos de prueba para cada caso de prueba. Contrastar los resultados con lo esperado. Informar de los defectos a los responsables de los componentes involucrados. Informar de los defectos a los diseadores de pruebas. 5. Realizar prueba de sistema. Se realiza despus de la anterior y de un modo similar. 6. Evaluar prueba: Se comparan los resultados obtenidos con los objetivos del plan de prueba. Se tienen en cuenta dos factores: Terminacin de la prueba: Nmero de casos de prueba y cantidad de cdigo comprobado. Fiabilidad: Anlisis de las tendencias de las pruebas y defectos observados.
8.3. Mtodo extreme programming

Este mtodo reciente de desarrollo orientado a objetos fue descrito originalmente por Kent Beck en su libro [Bec99]. En la actualidad est ganando muchos adeptos a travs de Internet y tiene cada vez una mayor presencia como un mtodo alternativo de desarrollo frente a los mtodos ms clsicos. Se basa principalmente en la simplicidad, la comunicacin e interaccin permanente con el cliente (comprobacin de requisitos constante) y en el pair-programming, que es la tcnica de programacin por parejas donde uno de los programadores escribe cdigo y el otro lo prueba y despus se cambian los papeles. De esta forma ya desde el principio se van probando los programas en cuanto a cumplimiento de requisitos como a funcionalidad. La simplicacin de los protocolos de comunicacin entre las diferentes fases (ver gura 8.7) y la inmediatez del desarrollo lo convierten en una metodologa muy rpida de desarrollo. Sus caractersticas son:
8.3 Mtodo extreme programming

Escenarios de test
99
Historias de usuario
Requisitos Metafora del sistema
Nueva historia de usuario Velocidad del proyecto
Errores Ultima version
Prototipo arquitectonico
Plan de entrega de versiones
Plan de liberacion
Iteracion
Test de aceptacion
Aprobacion del usuario
Pequenas entregas
Estimacion mala
Estimacion mejor
Proxima iteracion
Ptototipo
Figura 8.7: Etapas de extreme programming Permite introducir nuevos requisitos o cambiar los anteriores de un modo dinmico. Publica pronto versiones que implementan parte de los requisitos. Es adecuado para proyectos pequeos y medianos. Tambin es adecuado para proyectos con alto riesgo. Su ciclo de vida es iterativo e incremental. Cada iteracin dura entre una y tres semanas. Un defecto de extreme programming es que necesita una continua interaccin con el usuario, y no con cualquiera, sino con alguien que conozca la empresa y sus necesidades. Otra crtica que se ha hecho a esta metodologa es que no produce demasiada documentacin acerca del diseo o la planicacin.
8.3.1. Historias de usuario

Es la forma de hacer la especicacin en Extreme Programming. Consisten en una serie de documentos cortos escritos por los usuarios. Caractersticas: Son parecidas a los casos de uso de UML, pero las escriben los usuarios. Son cortas (unas tres lneas) y sin vocabulario tcnico. Cada una especica un requisito del sistema. Pueden usarse para:
Estimar el tiempo de desarrollo. Se puede hacer un test de aceptacin partiendo de una historia de usuario.
Los desarrolladores estiman cuanto tiempo es necesario para implementar cada una. Si ese tiempo supera en alguna las tres semanas se debe desglosar en otras ms pequeas. Si es inferior a una semana, la historia de usuario ha descendido a un nivel de detalle excesivo y habr que combinarla con otra. Una historia de usuario debe durar idealmente entre una y tres semanas. Idealmente signica no tener distracciones, saber exactamente lo que hay que implementar y sin otras asignaciones. Diferencias entre las historias de usuario y la especicacin tradicional: Nivel de detalle: En principio, el usuario solo cuenta lo necesario para poder hacer una estimacin del tiempo que va a tomar la implementacin. Cuando llega el momento de implementar se vuelve a preguntar. La atencin se centra en las necesidades del usuario, no se usa tecno-jerga.
8.3.2. Plan de publicacin de versiones

Lo primero que se hace al abordar un proyecto es una reunin para decidir un esquema del proyecto global, entonces se usa este esquema para decidir como va a ser cada una de las iteraciones. Cada iteracin se planica en detalle justo antes de empezar. Una de las cosas que se hace en esta reunin preliminar es estimar el tiempo de desarrollo para cada una de las historias de usuario. En este plan se descubren las funcionalidades que se pueden ir implementando en las sucesivas versiones. Esto es til para que el cliente vaya probando el producto e intercambie impresiones con el equipo. El cliente es el que va a decidir en que orden quiere que se vayan implementando. Es importante que las decisiones tcnicas las tome el equipo de desarrollo y las decisiones de negocio el cliente. Las historias de usuario se imprimen en tarjetas, entonces el equipo de desarrollo las pone en una mesa para crear un conjunto de historias que sern implementadas para la primera versin. Es deseable empezar a publicar versiones cuanto antes. La planicacin se puede hacer por tiempo o por alcance. Tiempo: No de historias que se pueden implementar antes de una fecha dada. Alcance: Cuanto tiempo se tardar en implementar un conjunto de historias.
100
Los proyectos estn condicionados por cuatro variables: 1. 2. 3. 4. Alcance: Lo que hay que hacer Recursos: Gente disponible Tiempo: Fecha de entrega Calidad: Cantidad de errores
La cuarta est condicionada por las tres primeras y es inversamente proporcional al coste del proyecto.
8.3.3. Tarjetas CRC: Clases, Responsabilidades y Colaboraciones

Suponen una forma de pensar propia de la orientacin a objetos que rompe con el diseo tradicional. Cada tarjeta representa un objeto. En la cabecera se pone el nombre de la clase a la que pertenece. Las responsabilidades se ponen en la parte izquierda y las clases con las que colabora a la parte derecha de cada responsabilidad. Lo que se hace en una sesin es simular el funcionamiento del sistema a mano. Por ejemplo: Una persona coge una tarjeta que es un objeto, manda un mensaje a otro objeto, entonces alguien se levanta y coge la tarjeta correspondiente a ese objeto, hace lo que sea, etc. Utilizando este sistema se pueden explorar con rapidez las diferentes alternativas de diseo. Problema: No queda constancia escrita del diseo, aunque se puede escribir el resultado de la sesin de simulacin con una copia de cada tarjeta. El criterio que se debe seguir con el diseo es que sea tan simple como sea posible. Una forma de explorar alternativas de diseo es crear miniprototipos. Un miniprototipo es una programa pequeo hecho para explorar soluciones potenciales y luego tirarlo. Tambin pueden servir para reducir riesgos o para mejorar la estimacin del tiempo que tarda en ser implementada una historia de usuario.
8.3.4. Planicacin de cada iteracin

Cada iteracin (ver gura 8.8) slo se planica en detalle al comienzo de la misma y se hace en una reunin que se convoca al efecto. Lo que se hace es:
Nueva historia de usuario Velocidad del proyecto Plan de entrega Aprender y comunicar Nueva funcionalidad Desarrollo Correccion de errores Dia a dia
Historias de usuario Velocidad del proyecto
Tareas no terminadas Plan de iteracion
Proxima iteracion
Plan de iteraciones
Ultima version
Errores
Test de aceptacion fallidos
Figura 8.8: Planicacin de iteracin Lo primero es decidir cuales son las historias de usuario que hay que implementar en esta iteracin. Esta decisin le corresponde en su mayor parte al usuario. En total la iteracin dura entre una y tres semanas. Se escriben los tests de aceptacin que tendrn que ser satisfechos por cada historia de usuario. Las historias de usuario y los tests se traducen en tareas, que se escriben en tarjetas. Cada una debera durar entre uno y tres das. El plan detallado para cada iteracin consiste en ese conjunto de tareas. Al igual que ocurre con las historias de usuario, las tareas ms cortas de un da se agrupan con otras, y las ms largas que tres das se dividen en otras ms pequeas. Las tareas se asignan a programadores concretos y son estos los que estiman el tiempo que puede tardar la implementacin de la tarea que se compromete a hacer. Si la iteracin va retrasada con respecto a lo proyectado se escogen algunas historias de usuario y se dejar para la siguiente iteracin. Igualmente, si va adelantado se escoge historias de usuario y se introducen en la iteracin actual. La velocidad a la que va el proyecto se estima en funcin del tiempo que han tardado en implementarse las historias de usuario que ya estn hechas. Cada tres a cinco iteraciones habr que reestimar el tiempo de las historias que quedan. Es importante que no se planique en detalle ms que lo que se va a hacer en la iteracin en curso. Motivo: Es perder el tiempo, el proyecto cambiar. No se deben aadir funcionalidades extras antes de tiempo, es decir, no implementar funcionalidades que no son necesarias en el momento. Motivo: El 90 % no sern usadas.
8.3 Mtodo extreme programming
101
8.3.5. Integracin
En la integracin se juntan los pequeos mdulos de software que tenemos y que parece que funcionan, pero resulta que esos pequeos trozos solo han superado pruebas de unidad donde no han tenido que interactuar con otros mdulos. El problema es que existen errores que solo surgen en esa interaccin, y ese es precisamente el problema de la integracin. Formas de afrontarlo: 1. Cada desarrollador es propietario de algunas clases y se responsabiliza de corregir los errores que surjan en la integracin. 2. Tener un equipo que se dedique a eso. Adems lo tpico es hacer la integracin una sola vez al nal. En extreme programming se hace una integracin secuencial. En un mismo momento slo puede existir una pareja de programadores integrando su cdigo. Para que otra pareja pueda hacer lo mismo le tienen que pasar el testigo. El cdigo est todo l en el almacn (repository) y la pareja que est integrando es la que puede hacer test y publicar los cambios al almacn. Tambin es posible que una pareja pueda integrar su trabajo en la ltima versin en el momento que quiera con tal de que exista un mecanismo de bloqueo (p.ej. un token que se pasen de unos a otros). La integracin debe hacerse cada poco tiempo, idealmente, cada pocas horas hay que dejar cdigo nuevo en el almacn. Todo el mundo debe hacer integraciones con la ltima versin disponible, de esta forma se evita trabajar con cdigo obsoleto. Haciendo muchas mini-integraciones los problemas que surgan al nal cuando se haca la nica integracin se van resolviendo sobre la marcha.
8.3.6. Codicacin de cada unidad

En esta seccin tambin veremos algunas diferencias chocantes con la forma de trabajar tradicional (ver gura 8.9).
Tarjetas CRC Diseo sencillo Problema complejo Asignar pareja Crear una prueba de unidad Mover a la gente Cambiar pareja Test de unidad fallido Test de unidad pasado Se necesita ayuda Nuevos test de unidad Nueva funcionalidad Se pasan el 100% de las pruebas de unidad
Correr todos los test de unidad Integracion continua
Proxima tarea o Test de aceptacion fallido
Programacion por parejas
Correr los test de aceptacion fallidos Test de aceptacion pasado
Codigo sencillo
Codigo complicado
Rehacer sin piedad
Figura 8.9: Pruebas
Codicacin de la prueba de unidad Lo primero que se hace antes programar un mdulo es la preparar la prueba de unidad. Esto indica al programador que es lo que tiene que hacer cuando codica. Los requisitos aparecen en forma de pruebas de unidad. Se sabe cuando se ha terminado porque se superan todos los tests de unidad. El benecio que tiene de ello el diseo, es que en los tests de unidad se pone aquello que es importante para el cliente. Una forma de hacer esto es a base de pequeos incrementos: 1. 2. 3. 4. 5. Se crea una prueba de unidad pequea que reeja parte de los requisitos. Se hace el cdigo que satisface ese test. Se crea una segunda prueba. Se aade el cdigo correspondiente. ...
Prueba de unidad Veamos ahora como se hace una prueba de unidad. Hay tres pasos a seguir: 1. Se crea un armazn o patrn para poder hacer partiendo de l las pruebas de unidad de un modo automatizado. 2. Se hace un test de todas las clases del sistema. 3. Se debe escribir el test antes de codicar el mdulo. La idea de hacer el test antes del cdigo es importante, porque si se deja para el nal, es posible que se encuentren problemas inesperados y se necesite ms tiempo del inicialmente previsto. Adems, en realidad el test no se hace antes sino durante porque se construye de forma incremental, pero siempre el test antes del cdigo. Cuando se publica un mdulo al almacn debe ir obligatoriamente acompaado del test correspondiente, y no se puede publicar cdigo que no haya pasado todos los tests. Como el cdigo no tiene un propietario jo y todo el mundo puede hacer modicaciones, esta norma es bastante razonable, cualquiera puede modicar una lnea de cdigo que haya escrito otra persona, ahora bien, la modicacin tiene que pasar todos los tests asociados a la unidad.
102
Los tests de unidad permiten tambin rehacer el cdigo porque pueden comprobar si un cambio en la estructura supone un cambio en la funcionalidad. Un pequeo problema es que los tests en si mismos pueden tener errores. Por otra parte, una de las cosas deseables es poder hacer frecuentemente integraciones de todo el cdigo. Si se construye un conjunto de tests globales para comprobar el producto nal, ser posible comprobar rpidamente si los cambios hechos en una unidad se integran bien y de esta forma no dejarlo todo para el nal. Test de aceptacin El test de aceptacin tambin se conoce como test funcional en otros sitios. Los tests de aceptacin son cajas negras que comprueban el funcionamiento del sistema. Son escritos por el cliente, y es el cliente el responsable de que sea correcto. Tambin es el cliente el que decide la prioridad de cada test fallido. Tambin se usan como test de regresin. Para que se pueda comprobar con rapidez y muchas veces si las historias de usuario cumplen con los tests de aceptacin, estos deberan estar automatizados. Los resultados se comunican al grupo, que debe gestionar el tiempo para corregir errores. A partir de las historias de usuario se hacen los tests de aceptacin y a cada una le puede corresponder uno o varios. No se considera que una historia ha sido completada hasta que no pase todos sus tests de aceptacin. Al igual que con los tests de unidad, los tests de aceptacin deben hacerse antes de empezar a depurar. La diferencia entre un test de aceptacin y un test de unidad est clara: un test de aceptacin comprueba los requisitos expresados en las historias de usuario y un test de unidad comprueba que el cdigo de una unidad es correcto. Errores Si se encuentra un error lo que se hace es crear un test de aceptacin para ese error. De esta forma es fcil para el equipo saber cuando se ha corregido. Un error en un test de aceptacin puede verse en varios mdulos diferentes en sus tests de unidad. Cuando todos los tests de unidad funcionan perfectamente se puede correr otra vez el test de aceptacin para comprobar si el error ha sido realmente corregido.
8.3.7. Recomendaciones generales

Disponibilidad del cliente Este es uno de los problemas de la metodologa Extreme Programming, es necesario tener disponible de principio a n a los clientes hasta el punto de formar parte del equipo de desarrollo. Los clientes: 1. 2. 3. 4. 5. 6. Escriben las historias de usuario. Asignan prioridades a las mismas y se negocia con ellos cules incluir en cada iteracin. Una vez dentro de una iteracin se les preguntan ms detalles acerca de las historias de usuario. Ayudan a estimar el tiempo de desarrollo. Se negocian con ellos las fechas de entrega. No podemos tener a cualquiera en el equipo, debe ser alguien con capacidad de tomar decisiones en la empresa, o al menos que pueda aconsejar, y que la conozca bien. 7. Van probando las versiones que se van publicando y pueden de esta forma proporcionar realimentacin al equipo de desarrollo. 8. Ayudan a determinar cules son las pruebas que el sistema tiene que superar para considerarse apto (test funcional). 9. Si hay varios clientes pueden no estar de acuerdo con una solucin, la forma de solucionarlo es hacer una reunin donde se llegue a un acuerdo.
Acerca del cdigo 1. Rehacer lo viejo: A veces mantener cdigo antiguo no solo no supone un ahorro de tiempo, sino un serio inconveniente. Si es necesario se debe eliminar la redundancia, las funcionalidades que no se usan ya o cambiar diseos antiguos. 2. Optimizaciones: No se debe optimizar el cdigo hasta que est funcionando todo. Esto se deja para el nal. 3. Nomenclatura: La nomenclatura es la forma en la que se escoge el nombre de las cosas. De cara a comprender bien el diseo general del sistema y poder reutilizar el cdigo hay que escoger una forma de dar nombre a las clases y mtodos de forma que todo el mundo lo pueda comprender fcilmente y que sea consistente. 4. Estndares de codicacin: Hay publicadas algunas normas sobre como se debe codicar en un lenguaje. Es conveniente seguir alguno de esos estndares por todos los miembros del equipo para que el cdigo sea luego fcil de comprender y de mantener por todos. Personal Este es posiblemente el factor ms importante. Los proyectos informticos funcionan a base de mano de obra, todo lo que se ha dicho hasta ahora consiste en realidad en buscar formas de trabajar que sean adecuadas para que el componente humano funcione bien. Ahora veremos cuatro caractersticas propias de la metodologa extreme programming a este respecto.
8.4 Mtrica 3
103
1. Reuniones diarias: Todos los das por la maana se hace una reunin de 15 minutos en la que se da cita todo el personal desarrollador. Lo que se busca es promover la comunicacin entre todos los miembros del grupo. La gente cuenta los problemas que se han encontrado y cualquiera puede proponer soluciones. Este tipo de reuniones tiene algunas ventajas: a) Como todo el mundo asiste es ms fcil encontrar soluciones. b) Se pueden evitar otras reuniones. 2. Propiedad compartida del cdigo: Cualquiera puede corregir errores, aadir funcionalidades, etc de cualquier parte del proyecto (no slo de su cdigo, sino tambin del de los dems). Lo que se pretende es que cualquiera pueda aportar algo. Esto signica que la arquitectura del sistema en cierto modo la decide el equipo en su conjunto, lo cual resulta chocante para la mentalidad de la programacin estructurada. Ventajas: a) El cdigo es ms able. b) Si una persona se atasca en un problema, se le ayuda y su parte no se convierte en un problema para otros. 3. Programacin por parejas (pair programming): Est basado en el principio de que dos personas trabajando juntas pueden hacer ms que por separado. El resultado de esto es una mejora en la calidad del cdigo, adems no supone tardar ms tiempo. La forma de ponerla en prctica es: Dos personas se sientan juntas ante el mismo ordenador. Una teclea y piensa en el problema desde el punto de vista tctico. La otra piensa desde el punto de vista estratgico. 4. Mover a la gente: No se puede permitir que todo el equipo dependa de que la nica persona que conoce algo est disponible o no. Puede ocurrir que esa persona deje la empresa o que est sobrecargada en un momento dado. Lo que se hace es que la gente trabaje en una parte del sistema distinta en cada iteracin (o en parte de ella). Esto en combinacin con la programacin en parejas permite que no se pierda productividad en la parte que se deja. Ventajas: a) Se evitan las islas de conocimiento b) El equipo es ms exible c) Si una parte del proyecto tiene problemas es posible reasignar gente a esa parte.
8.4. Mtrica 3
8.4.1. Introduccin
Mtrica 3 es la metodologa ocial de desarrollo de aplicaciones informticas en la administracin. Caractersticas 1 : 1. 2. 3. 4. 5. Su punto de partida es la versin anterior (la 2.1). La redaccin comenz en 1996. Cubre los dos tipos de desarrollo, tanto el estructurado como el orientado a objetos, luego es una metodologa mixta. Sigue el ciclo de vida denido en la norma ISO-2.207. Incluye los procesos que no forman parte de lo que se entiende como ciclo de vida a los que llama interfaces. Tiene en cuenta la tecnologa cliente/servidor y el desarrollo de interfaces grcas de usuario (IGU).
8.4.2. Objetivos
Como toda metodologa lo que se hace es sistematizar todas las actividades del ciclo de vida y las que no son parte del ciclo de vida pero inuyen de algn modo en ste (como puede ser la planicacin) para de esa forma conseguir los siguientes objetivos: 1. Dar un marco estratgico para el desarrollo de los sistemas de informacin dentro de las organizaciones. 2. Enfatizar el anlisis de requisitos para que de esta forma los productos satisfagan las necesidades de los usuarios. 3. Mejorar la productividad del departamento de sistemas de informacin permitiendo una mayor adaptabilidad a los cambios y reutilizacin. 4. Que los procesos que permitan una comunicacin ms uida entre todos los miembros involucrados en la produccin de software. 5. Facilitar la operacin y mantenimiento de los productos obtenidos.
8.4.3. Estructura
Mtrica 3 se divide por una parte en procesos principales, que son los relativos a la planicacin, desarrollo y mantenimiento e interfaces, que son procesos asociados al desarrollo (gestin de la conguracin, de proyectos y aseguramiento de la calidad). Cada proceso se divide en actividades y cada actividad tiene una descripcin y una tabla de tareas propias de la actividad. Cada tarea tiene la correspondiente descripcin y dene los productos que necesita de entrada, los que produce de salida, las prcticas necesarias para llevar a cabo la tarea y los participantes. Mtrica 3 es exible en su estructura (ver gura 8.10) porque no es obligatorio seguir todos los procesos o actividades, se adapta en funcin de las necesidades de cada proyecto. Tampoco es necesario seguir las actividades secuencialmente, en
1
Para una descripcin completa de Mtrica 3 se recomienda visitar la pgina: http://www.map.es/csi/metrica3/
104

Procesos

Metrica V3

Interfaces

Plancacion (PSI) Estudio de viabilidad (EVS) Analisis del S.I. (ASI) Desarrollo Diseo del S.I. (DSI) Construccion del S.I. (CSI) Implant. y acept. del sistema (IAS) Mantenimiento (MSI) Gestion de la conguracion (GC) Gestion de proyectos (GP) Aseguramiento de la calidad (CAL) Seguridad (SEG)

Figura 8.10: Estructura general de Mtrica 3.

Requisitos del PSI Arquitectura de informacion
Entradas externas
Solicitud formal del PSI Estructura organizativa Informacion relevante Entorno tecnologico actual y estandar
P.S.I.
* Modulo de sistemas de informacion * Modulo de informacion *Arquitectura tecnologica
Plan de accion
* Plan de proyectos * Plan de mantenimiento
Figura 8.11: Planicacin de sistemas de informacin ocasiones ser factible su ejecucin en paralelo. Los procesos correspondientes al desarrollo son los contemplados por el ciclo de vida ISO 12.207.
8.4.4. Procesos
Planicacin de sistemas de informacin (PSI) El objetivo es obtener un marco de referencia para desarrollar el sistema de informacin (ver gura 8.11). El marco de referencia consta de: 1. Descripcin de la situacin actual, que incluye: Un anlisis tcnico de puntos fuertes y riesgos. Un anlisis de servicio a los objetivos de la organizacin. 2. Un conjunto de modelos que constituyen la arquitectura de informacin. 3. Una propuesta de proyectos a realizar en los prximos aos con: Sus prioridades. Un calendario. Estimacin de los recursos necesarios para cada proyecto, que ser ms detallada cuanto ms cercano en el tiempo. Un plan de seguimiento de los proyectos. El plan de sistemas de informacin se disea a partir de consideraciones de tipo estratgico, y no tcnico. Debido a esto es necesario la implicacin de la alta direccin en el proceso. El plan se elabora en funcin de las necesidades de informacin de los procesos afectados, con estas necesidades se elaboran modelos conceptuales de informacin. El PSI se divide en las siguientes actividades y tareas: 1. Inicio del plan de sistemas de informacin. Anlisis de la necesidad del PSI. Identicacin del alcance del PSI. Determinacin de responsabilidades. 2. Denicin y organizacin del PSI. Especicacin del mbito y alcance. Organizacin del PSI.
8.4 Mtrica 3
105
Denicin del plan de trabajo. Comunicacin del plan de trabajo. 3. Estudio de la organizacin relevante. Seleccin y anlisis de antecedentes. Valoracin de antecedentes 4. Identicacin de requisitos. Estudio de los procesos del PSI. Anlisis de las necesidades de la informacin. Catalogacin de requisitos. 5. Estudio de los sistemas de informacin actuales. Alcance y objetivos del estudio de los sistemas de informacin actuales. Anlisis de los sistemas de informacin actuales. Valoracin de los sistemas de informacin actuales. 6. Diseo del modelo de sistemas de informacin. Diagnstico de la situacin actual. Denicin del modelo de sistemas de informacin. 7. Denicin de la arquitectura tecnolgica. Identicacin de las necesidades de infraestructura tecnolgica. Seleccin de la arquitectura tecnolgica. 8. Denicin del plan de accin. Denicin de proyectos a realizar. Elaboracin del plan de mantenimiento del PSI. 9. Revisin y aprobacin del PSI. Convocatoria de la presentacin. Evaluacin y mejora de la propuesta. Aprobacin del PSI. Estudio de la viabilidad del sistema (EVS) La nalidad es proponer una solucin a las necesidades que tenga en cuenta restricciones tcnicas, econmicas, legales y operativas. Los proyectos que se propongan como solucin pueden afectar a los sistemas en funcionamiento. Para la denicin de esos proyectos se identican los requisitos a satisfacer y se estudia la situacin actual. A partir del estado inicial, la situacin actual y los requisitos se estudian las alternativas de solucin y se describen indicando sus requisitos. Para seleccionar la mejor se tienen en cuenta varios factores: Inversin, riesgos, impacto en la organizacin. Actividades y tareas en las que se divide: 1. Establecimiento del alcance del sistema. Estudio de la solucin. Identicacin del alcance del sistema. Especicacin del alcance del EVS. 2. Estudio de la situacin actual. Valoracin del estudio de la situacin actual. Identicacin de los usuarios participantes en el estudio de la situacin actual. Descripcin de los sistemas de informacin existentes. Realizacin del diagnstico de la situacin actual. 3. Denicin de requisitos del sistema. Identicacin de las directrices y tcnicas de gestin. Identicacin de requisitos. Catalogacin de requisitos.
106
4. Estudio de alternativas de solucin. Preseleccin de alternativas de solucin. Descripcin de las alternativas de solucin. 5. Valoracin de las alternativas. Estudio de la inversin. Estudio de los riesgos. Planicacin de alternativas. 6. Seleccin de la solucin. Convocatoria de presentacin. Evaluacin de alternativas y seleccin. Aprobacin de la solucin. Anlisis de sistemas de informacin (ASI) El objetivo es obtener una especicacin que responda a las necesidades de los usuarios y se pueda emplear como entrada para el diseo. La denicin del sistema (ASI 1) se lleva a cabo a partir de los productos generados en el estudio de viabilidad del sistema (EVS). Se delimita el alcance del sistema, se genera un catlogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. Tambin se identica a los usuarios que formarn parte del equipo de anlisis deniendo sus responsabilidades. Se elabora el plan de trabajo a seguir. En el establecimiento de requisitos (ASI 2) se dene un catlogo de requisitos que permite describir el sistema de informacin y sirve para comprobar la completitud de la especicacin de los modelos obtenidos por otras tcnicas del anlisis. Como consecuencia se puede actualizar el catlogo. Para la obtencin de requisitos: 1. Se toma como punto de partida el catlogo de requisitos y los modelos elaborados en la actividad de denicin del sistema (ASI 1), que se complementarn mediante sesiones de trabajo con los usuarios. 2. Las sesiones de trabajo tienen como objetivo obtener la informacin necesaria para la especicacin detallada del sistema. Las tcnicas son las que se vieron en el captulo de especicacin. 3. Se identican tambin los requisitos no funcionales del sistema, es decir, restricciones de rendimiento, seguridad, etc. Esto forma parte tambin del catlogo de requisitos. En la actividad la identicacin de subsistemas de anlisis (ASI 3) el sistema de informacin se estructura en subsistemas de anlisis para facilitar la especicacin de los distintos modelos y la traza de requisitos. Simultneamente se crean los modelos que sirven de base para el diseo. Se elabora la descripcin detallada del modelo de datos y el de procesos. Se especican las interfaces entre el sistema y el usuario. En la actividad de anlisis de consistencia y especicacin de requisitos (ASI 9) se realiza una vericacin y validacin de los modelos para asegurar que son completos, consistentes y correctos. La especicacin del plan de pruebas se inicia en la actividad (ASI 10) y se termina en el proceso de diseo de sistemas de informacin (DSI). Actividades y tareas: 1. Denicin de sistema. Determinacin del alcance del sistema. Identicacin del entorno tecnolgico. Especicacin de estndares y normas. Identicacin de usuarios participantes y nales. 2. Establecimiento de requisitos. Obtencin de requisitos. Especicacin de casos de uso. Anlisis de requisitos. Validacin de requisitos. 3. Identicacin de subsistemas de anlisis. Determinacin de subsistemas de anlisis. Integracin de subsistemas de anlisis. 4. Anlisis de los casos de uso (anlisis orientado a objetos). Identicacin de clases asociadas a un caso de uso.
8.4 Mtrica 3
107
Descripcin de la interaccin de objetos. 5. Anlisis de clases (anlisis orientado a objetos). Identicacin de responsabilidades y atributos. Identicacin de asociaciones y agregaciones. Identicacin de generalizaciones. 6. Elaboracin del modelo de datos (anlisis estructurado). Elaboracin del modelo conceptual de datos. Elaboracin del modelo lgico de datos. Normalizacin del modelo lgico de datos. Especicacin de necesidades de migracin de datos y carga inicial. 7. Elaboracin del modelo de procesos (anlisis estructurado). Obtencin del modelo de procesos del sistema. Especicaciones de interfaces con otros sistemas. 8. Denicin de interfaces de usuario. Especicacin de principios generales de la interfaz. Identicacin de perles y dilogos (slo para anlisis estructurado) Especicacin de formatos individuales de la interfaz de pantalla. Especicacin del comportamiento dinmico de la interfaz. Especicacin del formatos de impresin. 9. Anlisis de consistencia y especicacin de requisitos. Vericacin de los modelos. Anlisis de consistencia de los modelos. Validacin de los modelos. Elaboracin de la especicacin de requisitos software (ERS). 10. Especicacin del plan de pruebas. Denicin del alcance de las pruebas. Denicin de requisitos del entorno de pruebas. Denicin de las pruebas de aceptacin del sistema. 11. Presentacin y especicacin del anlisis del sistema de informacin. Presentacin y aprobacin del anlisis del sistema de informacin. Proceso de diseo de sistemas de informacin (DSI) Los objetivos del diseo son denir: 1. Denir la arquitectura. 2. Denir el entorno tecnolgico. 3. Especicar los componentes del sistema de informacin. Hay dos bloques de actividades: 1. Diseo de detalle: Esta parte necesita realimentacin. Establece el particionamiento fsico del sistema de informacin (DSI 1) y su organizacin en subsistemas de diseo. Los subsistemas pueden ser de dos tipos: De soporte: Elementos o servicios comunes al sistema. Especcos: Elementos propios del sistema de informacin. Otras actividades que se llevan a cabo en paralelo a la denicin de la arquitectura del sistema son: Diseo de la arquitectura de soporte (DSI 2). Diseo de la arquitectura de mdulos del sistema (DSI 5). Diseo fsico de datos (DSI 6).
108
En el diseo orientado a objetos el diseo detallado se realiza en paralelo con la actividad de diseo de la arquitectura de soporte (DSI 2). Las actividades que lo realizan son: Diseo de casos de uso reales (DSI 3). Diseo de clases (DSI 4) Cuando se tiene el modelo de clases se comienza el diseo fsico de datos (DSI 6) segn el enfoque del diseo estructurado. El ltimo paso de este bloque es la actividad de vericacin y aceptacin de la arquitectura del sistema (DSI 7). 2. Completar el proceso de diseo. Se generan las siguientes especicaciones: Generacin de especicaciones de construccin (DSI 8). Diseo de migracin y carga inicial de datos (DSI 9). Especicacin tcnica del plan de pruebas (DSI 10). Establecimiento de requisitos de implantacin (DSI 11). El proceso de diseo puede parecer un tanto catico con la mezcla de procesos orientados a objetos y estructurados y con la divisin en las dos fases. El grco de actividades en la gura 8.12 puede que aclare un poco esta estructura. Actividades y tareas relacionadas:
DSI 1 Definicion de la Arquitectura del sistema Actividad comun Actividad solo orientada a objetos Actividad solo estructurado
DSI 2 Diseo de la Arquitectura de Soporte
DSI 8 Generacion de especificaciones de construccion
DSI 3 Diseo de casos de uso reales
DSI 4 Diseo de clases
DSI 7 Verificacion y aceptacion de la arquitectura del sistema
DSI 9 Diseo de migracion y carga inicial de datos
DSI 12 Aprobacion del diseo
DSI 5 Diseo de la arquitectura de modulos del sistema
DSI 10 Especificacion tecnica del plan de pruebas
DSI 6 Diseo fisico de datos
DSI 11 Establecimiento de requisitos de implantacion
Figura 8.12: Grco de actividades
1. Denicin de la arquitectura del sistema: Se establecen las particiones fsicas, la descomposicin lgica en subsistemas de diseo y la ubicacin de cada subsistema en cada particin, as como la especicacin detallada de la infraestructura tecnolgica. Las tareas a realizar son: Denicin de niveles de arquitectura. Identicacin de requisitos de diseo y construccin. Especicacin de excepciones. Especicacin de estndares y normas de diseo y construccin. Identicacin de subsistemas de diseo. Especicacin del entorno tecnolgico. Especicacin de requisitos de operacin y seguridad. 2. Diseo de la arquitectura de soporte. Diseo de subsistemas de soporte. Identicacin de mecanismos genricos de diseo. 3. Diseo de casos de uso reales (diseo orientado a objetos). Identicacin de clases asociadas a un caso de uso. Diseo de la realizacin de los casos de uso. Revisin de la interfaz de usuario.
8.4 Mtrica 3
109
Revisin de subsistemas de diseo e interfaces. 4. Diseo de clases (diseo orientado a objetos). Identicacin de clases adicionales. Diseo de asociaciones y agregaciones. Identicacin de atributos de las clases. Identicacin de operaciones de las clases. Diseo de la jerarqua. Descripcin de mtodos de las operaciones. 5. Diseo de la arquitectura de mdulos del sistema (desarrollo estructurado). Diseo de mdulos del sistema. Diseo de comunicaciones entre mdulos. Revisin de la interfaz de usuario. 6. Diseo fsico del sistema (desarrollo estructurado). Diseo del modelo fsico de datos. Especicacin de los caminos de acceso a los datos. Optimizacin del modelo fsico de datos. Especicacin de la distribucin de datos. 7. Vericacin y aceptacin de la arquitectura del sistema (desarrollo estructurado). Vericacin de las especicaciones de diseo. Anlisis de consistencia de las especicaciones de diseo. Aceptacin de la arquitectura del sistema. 8. Generacin de especicaciones de construccin. Especicacin del entorno de construccin. Denicin de componentes y subsistemas de construccin. Elaboracin de especicaciones de construccin. Elaboracin de especicaciones del modelo fsico de datos. 9. Diseo de la migracin y carga inicial de datos. Especicacin del entorno de migracin. Diseo de procedimientos de migracin y carga inicial. Diseo detallado de componentes de migracin y carga inicial. Revisin de la planicacin de la migracin. 10. Especicacin tcnica del plan de pruebas. Especicacin del entorno de pruebas. Especicacin tcnica de niveles de prueba. Revisin de la planicacin de pruebas. 11. Establecimiento de requisitos de implantacin. Especicacin de requisitos de documentacin de usuario. Especicacin de requisitos de implantacin. 12. Aprobacin del diseo del sistema de informacin. Presentacin y aprobacin del diseo del sistema de informacin. Proceso de construccin de sistemas de informacin (CSI) Este es el proceso a seguir: 1. Se escribe el cdigo del sistema. 2. Se desarrollan los procedimientos de operacin y seguridad. 3. Se escriben los manuales de usuario y de explotacin.
110
4. Se realizan las pruebas: Unitarias, de integracin y de sistema. 5. Se dene la formacin del usuario. 6. Se construyen los procedimientos de migracin y de carga de datos. La base para la construccin del sistema est en la salida producida por la actividad Generacin de especicaciones de construccin (DSI 8). Por otra parte, la actividad de preparacin del entorno de generacin y construccin (CSI 1) es necesaria para asegurar que se tiene el entorno de programacin adecuado. La codicacin y pruebas se realizan en las actividades: Generacin del cdigo de los componentes y procedimientos (CSI 2). Ejecucin de las pruebas unitarias (CSI 3). Ejecucin de las pruebas de integracin (CSI 4). Ejecucin de las pruebas del sistema (CSI 5). Los manuales de usuario y la formacin necesaria se denen respectivamente en las actividades Elaboracin de manuales de usuario (CSI 6) y Denicin de la formacin de usuarios nales (CSI 7). La lista de actividades con sus tareas es: 1. Preparacin del entorno de generacin y construccin. Implantacin de las base de datos fsica o cheros. Preparacin del entorno de construccin. 2. Generacin del cdigo de los componentes y procedimientos. Generacin del cdigo de componentes. Generacin del cdigo de los procedimientos de operacin y seguridad. 3. Ejecucin de las pruebas unitarias. Preparacin del entorno de las pruebas unitarias. Realizacin y evaluacin de las pruebas unitarias. 4. Ejecucin de las pruebas de integracin. Preparacin del entorno de las pruebas de integracin. Realizacin de las pruebas de integracin. Evaluacin del resultado de las pruebas de integracin. 5. Ejecucin de las pruebas del sistema. Preparacin del entorno de las pruebas del sistema. Realizacin de las pruebas del sistema. Evaluacin del resultado de las pruebas del sistema. 6. Elaboracin de los manuales de usuario. Elaboracin de los manuales de usuario. 7. Denicin de la formacin de usuarios nales. Denicin del esquema de formacin. Especicacin de los recursos y entornos de formacin. 8. Construccin de los componentes y procedimientos de migracin y carga inicial de datos. Preparacin del entorno de migracin y carga inicial de datos. Generacin del cdigo de los componentes y procedimientos de migracin y carga inicial de datos. Realizacin y evaluacin de las pruebas de migracin y carga inicial de datos. 9. Aprobacin del sistema de informacin. Presentacin y aprobacin del sistema de informacin. Proceso de implantacin de sistemas de informacin (CSI) El objetivo es que el sistema sea aceptado por el cliente y que empiece a funcionar. 1. Establecimiento del plan de implantacin.
8.4 Mtrica 3
111
Denicin del plan de implantacin. Especicacin del equipo de implantacin. 2. Formacin necesaria de la implantacin. Preparacin de la formacin del equipo de implantacin. Formacin del equipo de implantacin. Preparacin de la formacin a usuarios nales. Seguimiento de la informacin a usuarios nales. 3. Incorporacin del sistema al entorno de operacin. Preparacin de la instalacin. Realizacin de la instalacin. 4. Carga de datos al entorno de operacin. Migracin y carga inicial de datos. 5. Pruebas de implantacin del sistema. Preparacin de las pruebas de implantacin. Realizacin de las pruebas de implantacin. Evaluacin del resultado de las pruebas de implantacin. 6. Pruebas de aceptacin del sistema. Preparacin de las pruebas de aceptacin. Realizacin de las pruebas de aceptacin. Evaluacin del resultado de las pruebas de aceptacin. 7. Preparacin del mantenimiento del sistema. Establecimiento de la infraestructura para el mantenimiento. Formalizacin del plan de mantenimiento. 8. Establecimiento del acuerdo de nivel de servicio. Identicacin de los servicios. Descripcin de las propiedades de cada servicio. Determinacin del acuerdo de nivel de servicio. 9. Presentacin y aprobacin del sistema. Convocatoria de la presentacin del sistema. Aprobacin del sistema. 10. Paso a produccin. Preparacin del entorno de produccin. Activacin del sistema en produccin. Proceso de mantenimiento de sistemas de informacin (IAS) 1. Registro de la peticin. Registro de la peticin. Asignacin de la peticin. 2. Anlisis de la peticin. Vericacin y estudio de la peticin. Estudio de la propuesta de solucin. 3. Preparacin de la implementacin de la modicacin. Identicacin de elementos afectados. Establecimiento del plan de accin.
112
Especicacin del plan de pruebas de regresin. 4. Seguimiento y evaluacin de los cambios hasta la aceptacin. Seguimiento de los cambios. Realizacin de las pruebas de regresin. Aprobacin y cierre de la peticin.
8.4.5. Interfaces
Gestin de proyectos (GP) El objetivo de la gestin de proyectos es el control de recursos humanos y materiales. Existen tres grupos de actividades: de inicio del proyecto, de seguimiento y control y de nalizacin del proyecto. Actividades de inicio del proyecto Tienen dos objetivos: Estimar el esfuerzo identicando los elementos a desarrollar y planicar las actividades (recursos, planicacin de tareas y calendario). Lista de tareas: 1. Estimacin de esfuerzo. Tareas: Identicacin de elementos a desarrollar. Clculo del esfuerzo. 2. Planicacin. Tareas: Seleccin de la estrategia de desarrollo. Seleccin de la estructura de actividades, tareas y productos. Establecimiento del calendario de hitos y entregas. Planicacin detallada de actividades y recursos necesarios. Presentacin y aceptacin de la planicacin general del proyecto. Actividades de seguimiento y control El objetivo es vigilar todas las actividades de desarrollo. El jefe de proyecto vigila cada tarea, centrndose en las que estn retrasadas, caso de que esto ocurra se averiguan las causas. Estas actividades de seguimiento se llevan a cabo a lo largo de todo el ciclo de vida. Actividades: 1. Asignacin detallada de tareas. Asignacin de tarea. 2. Comunicacin al equipo del proyecto. Informar al equipo de proyecto. 3. Seguimiento de tareas. Seguimiento de tareas. Gestin de incidencias: Es un grupo de actividades de seguimiento y control. Una incidencia es un hecho inesperado que produce desviaciones respecto a lo planicado. Un caso especial son los cambios de requisitos. 4. Anlisis y registro de la incidencia. Tarea: Analizar impacto. Propuesta de solucin de la incidencia. Registrar la incidencia. Gestin de cambios en los requisitos: Es mejor que estos cambios no ocurren, pero si as es, se plantean al comit de seguimiento. El impacto del cambio del requisito en trminos de plazos y presupuestos se debe pactar con el cliente. Deber existir un registro de cambios que reeje para cada cambio: Formulario de peticin de cambio. Catlogo de necesidades. Anlisis funcional del cambio. Estimacin de esfuerzo. Variaciones en coste y plazos. El control y seguimiento de los cambios forma parte de las actividades de seguimiento y control de todo el proyecto.
8.4 Mtrica 3
113
5. Peticin de cambio de requisitos. Tarea: Registro de la peticin de cambio de requisitos. 6. Anlisis de la peticin de cambio de requisitos. Tareas: Estudio de la peticin de cambio de requisitos. Impacto de la peticin de cambio de requisitos. Estudio de alternativas y propuesta de solucin. 7. Aprobacin de la solucin. Tarea: Aprobacin de la solucin. 8. Estimacin del esfuerzo y planicacin de la solucin. Tarea: Estimacin de esfuerzo para el cambio. Planicacin de los cambios. 9. Registro del cambio de requisitos. Tarea: Registro del cambio de requisitos. 10. Finalizacin de la tarea. Tareas: Comprobacin de la tarea. 11. Actualizacin de la planicacin. Tareas: Actualizacin de tareas. Obtencin de la extrapolacin. Elaboracin del informe de seguimiento. 12. Reuniones de seguimiento. Tarea: Reunin interna de seguimiento. 13. Aceptacin. Tarea: Vericacin de aceptacin interna. Actividades de nalizacin La nalizacin ocurre cuando el cliente expresa su conformidad. 14. Cierre del proyecto. Tareas: Inclusin en histrico de proyectos. Archivo de la documentacin de gestin del proyecto. Aseguramiento de la calidad (CAL) El objetivo es garantizar que el sistema resultante cumpla con unos requisitos mnimos de calidad. Se llega a este objetivo haciendo revisiones exhaustivas de todos los documentos producidos. El equipo que participa en el aseguramiento de la calidad es independiente al de desarrollo. Sus funciones son: 1. Identicar desviaciones respecto a los estndares aplicados, de los requisitos y de los procedimientos especicados. 2. Comprobar que se han llevado a cabo las medidas preventivas o correctoras necesarias. El aseguramiento de la calidad est dividido en seis reas, cada una de ellas cuenta con sus actividades y cada actividad con sus tareas. Estas reas se corresponden con las etapas del desarrollo, es decir, el aseguramiento de la calidad se lleva a cabo durante todos los procesos del ciclo de vida. Veamos cada una de estas reas una a una. Estudio de viabilidad del sistema Se analizan las condiciones de desarrollo de cada una de las alternativas propuestas y las caractersticas que deben cumplir. Los riesgos especcos de los sistemas a desarrollar pueden inuir en la forma concreta en la que se aplique el plan de calidad, que puede estar denido en alguna norma de la propia empresa o seguir un estndar publicado. Actividades: 1. Identicacin de las propiedades de calidad para el sistema. Constitucin del equipo de aseguramiento de la calidad.
114
Determinacin de los sistemas de informacin objeto de aseguramiento de calidad. Identicacin de las propuestas de calidad. 2. Establecimiento del plan de aseguramiento de calidad. Necesidad del plan de aseguramiento de calidad para las alternativas propuestas. Alcance del plan de aseguramiento de calidad. Impacto en el coste del sistema. 3. Adecuacin del plan de aseguramiento de calidad. Ajuste del plan de aseguramiento de calidad. Aprobacin del plan de aseguramiento de calidad. Anlisis del sistema de informacin Se detalla el plan de calidad y los estndares o normas a seguir. El grupo encargado de esta tarea revisa: catlogo de requisitos, modelos resultantes del anlisis y plan de pruebas. Actividades: 1. Especicacin inicial del plan de aseguramiento de la calidad. Denicin del plan de aseguramiento de calidad para el sistema de informacin. 2. Especicacin detallada del plan de aseguramiento de calidad. Contenido del plan de aseguramiento de calidad para el sistema de informacin. 3. Revisin del anlisis de consistencia. Revisin del catlogo de requisitos. Revisin de la consistencia entre productos. 4. Revisin del plan de pruebas. Revisin del plan de pruebas. 5. Registro de la aprobacin del anlisis del sistema. Registro de la aprobacin del anlisis del sistema de informacin. Diseo del sistema de informacin Se revisan los siguientes conjuntos de requisitos: los especicados en el anlisis, los de las pruebas y los no funcionales. Actividades: 1. Revisin de la vericacin de la arquitectura del sistema. Revisin de la consistencia entre productos del diseo. Registro de la aceptacin de la arquitectura del sistema. 2. Revisin de la especicacin tcnica del plan de pruebas. Revisin del diseo de las pruebas unitarias, de integracin y del sistema. Revisin del plan de pruebas. 3. Revisin de los requisitos de implantacin. Revisin de los requisitos de documentacin de usuario. Revisin de los requisitos de implantacin. 4. Registro de la aprobacin del diseo del sistema de informacin. Registro de la aprobacin del diseo del sistema de informacin. Construccin del sistema de informacin Se revisan los estndares de codicacin, de evaluacin de las pruebas, manuales de usuario y formacin. Se comprueba que las pruebas se han llevado a cabo segn los criterios del plan de aseguramiento de la calidad. 1. Revisin del cdigo de componentes y procedimientos. Revisin de normas de construccin. 2. Revisin de las pruebas unitarias, de integracin y del sistema.
8.4 Mtrica 3
115
Revisin de la realizacin de las pruebas unitarias. Revisin de la realizacin de las pruebas de integracin. Revisin de la realizacin de las pruebas del sistema. 3. Revisin de los manuales de usuario. Revisin de los manuales de usuario. 4. Revisin de la formalizacin a usuarios nales. Revisin de la formalizacin a usuarios nales. 5. Registro de la aprobacin del sistema de informacin. Registro de la aprobacin del sistema de informacin. Implantacin y aceptacin del sistema Hay que comprobar que efectivamente existe un plan de implantacin y que se han realizado las pruebas de implantacin y de aceptacin del estudio de viabilidad y la normalizacin del plan de aseguramiento de la calidad. Se debe vericar que se entrega el sistema a los responsables del mantenimiento en condiciones para que ste se pueda realizar. Lista de actividades y tareas: 1. Revisin del plan de implantacin del sistema. Revisin del plan de implantacin del sistema. 2. Revisin de las pruebas de implantacin del sistema. Revisin de la realizacin de las pruebas de implantacin del sistema. Registro de la aprobacin de las pruebas de implantacin del sistema. 3. Revisin de las pruebas de aceptacin del sistema. Revisin de la realizacin de las pruebas de aceptacin del sistema. Revisin de la aprobacin de las pruebas de aceptacin del sistema. 4. Revisin del plan de mantenimiento del sistema. Revisin del plan de mantenimiento del sistema. 5. Registro de la aprobacin de la implantacin del sistema. Registro de la aprobacin de la implantacin del sistema. Mantenimiento del sistema de informacin Se realizan revisiones peridicas para constatar que el mantenimiento se lleva a cabo del modo correcto. Puede ser necesario revisar: El contenido del plan de pruebas de regresin. La ejecucin de las pruebas de regresin. En este caso se registra la aprobacin de las pruebas. Las vericaciones y casos de prueba del plan de pruebas correspondientes a un cambio. Las incidencias. Lista de actividades y tareas: 1. Revisin del mantenimiento del sistema de informacin. Revisin del mantenimiento. 2. Revisin del plan de pruebas de regresin. Comprobacin de la existencia del plan de pruebas de la regresin. 3. Revisin de la realizacin de las pruebas de regresin. Revisin de la realizacin de las pruebas de regresin. Gestin de la conguracin (GC) La gestin de la conguracin se ve en el captulo de Herramientas de desarrollo y validacin y sera redundante incluirlo aqu.
116
Seguridad (SEG) La palabra seguridad hace referencia a la gestin de riesgos. Esta interfaz pretende dotar a Mtrica 3 de mecanismos de seguridad adicionales a los que tiene de por si la metodologa. Hay dos tipos de actividades diferenciadas: 1. Actividades relacionadas con la seguridad intrnseca del sistema de informacin. 2. Actividades relacionadas con la seguridad del proceso de desarrollo. Planicacin de sistemas de informacin Si la organizacin no tiene denida una poltica en materia de seguridad habr que hacerlo. Esa poltica inuir en las decisiones adoptadas en el proceso de planicacin de sistemas de informacin. 1. 2. 3. 4. Planicacin de la seguridad requerida en el proceso planicacin de sistemas de informacin. Evaluacin del riesgo para la arquitectura tecnolgica. Determinacin de la seguridad en el plan de accin. Catalogacin de los productos generados durante el proceso de planicacin de sistemas de informacin.
Estudio de viabilidad del sistema En funcin de la seguridad requerida se selecciona el equipo de seguridad, que se basar en la poltica de seguridad de la organizacin. 1. 2. 3. 4. 5. 6. Estudio de la seguridad requerida en el proceso estudio de viabilidad del sistema. Seleccin del equipo de seguridad. Recomendaciones adicionales de seguridad para el sistema de informacin. Evaluacin de la seguridad de las alternativas de solucin. Evaluacin detallada de la seguridad de la solucin propuesta. Catalogacin de los productos generados durante el proceso de estudio de viabilidad del sistema.
Anlisis del sistema de informacin Las funciones de seguridad son un servicio que garantiza la seguridad del sistema de informacin. Un mecanismo de seguridad el la lgica o algoritmo que lo implementa. Actividades: 1. 2. 3. 4. Estudio de la seguridad requerida en el proceso de anlisis del sistema de informacin. Descripcin de las funciones y mecanismos de seguridad. Denicin de los criterios de aceptacin de la seguridad. Catalogacin de los productos generados durante el proceso de diseo del sistema de informacin.
Diseo del sistema de informacin Se minimizan los riesgos intrnsecos al sistema de informacin. Determinar el entorno tecnolgico es importante porque sobre el se implementan las medidas de seguridad. 1. 2. 3. 4. 5. Estudio de la seguridad requerida en el proceso de diseo del sistema de informacin. Especicacin de requisitos de seguridad del entorno tecnolgico. Requisitos de seguridad del entorno de construccin. Diseo de pruebas de seguridad. Catalogacin de los productos generados durante el proceso de construccin del sistema de informacin.
Construccin del sistema de informacin Se debe evitar que se ltren datos relativos al sistema de informacin. Se verica el resultado de las pruebas de las funciones y mecanismos adicionales de seguridad. Tambin se completa la denicin de formacin a usuarios nales. Actividades: 1. 2. 3. 4. Estudio de la seguridad requerida durante el proceso de construccin del sistema de informacin. Evaluacin de los resultados de pruebas de seguridad. Elaboracin del plan de formacin de seguridad. Catalogacin de los productos generados durante el proceso de construccin del sistema de informacin.
Implantacin y aceptacin del sistema Se especican las actividades que tienen que ver con la seguridad del sistema construido, tanto intrnseca como las que tienen que ver con la seguridad del proceso. Asegura que se cubran los requisitos de seguridad a travs de las pruebas de implantacin. Lista de actividades: 1. 2. 3. 4. 5. Estudio de la seguridad requerida en el proceso de implantacin y aceptacin del sistema. Revisin de medidas de seguridad del entorno de operacin. Evaluacin de resultados de pruebas de seguridad de implantacin del sistema. Catalogacin de los productos generados durante el proceso de implantacin y aceptacin del sistema. Revisin de medidas de seguridad en el entorno de produccin.
8.5 Mtodos de software libre: cathedral vs. bazaar
117
Mantenimiento de sistemas de informacin Actividades: 1. Estudio de la seguridad requerida en el proceso de mantenimiento de sistemas de informacin. 2. Especicacin e identicacin de las funciones y mecanismos de seguridad. 3. Catalogacin de los productos generados durante el proceso de mantenimiento de sistemas de informacin.
8.5. Mtodos de software libre: cathedral vs. bazaar

Internet ha supuesto una revolucin, no slo en el mundo de la informtica, sino en todos los campos del conocimiento. Nunca antes la informacin haba estado disponible como lo est ahora para todos. Internet es algo as como el sistema nervioso del mundo. Una de las consecuencias es que hay formas nuevas de trabajar, por ejemplo, ahora una persona puede colaborar con otras que no conoce en un proyecto. La informacin compartida se puede dejar en un almacn comn y se denen polticas poco o nada restrictivas acerca de quien puede leer esa informacin o a quien se acepta como colaborador. El inicio del movimiento del desarrollo de Software Libre a travs de Internet ha supuesto tambin la aparicin de nuevos mtodos y la adaptacin de otros a esta nueva forma de desarrollo. Las metodologas tradicionales presuponen una organizacin del reparto de tareas gestionado mediante responsables que distribuyen y supervisan el trabajo. Cuando se trata de trabajo cooperativo voluntario a travs de la Red ese esquema ya no es vlido y se plantean nuevas formas de coordinacin distribuida del trabajo. Los trminos catedral y bazar hacen referencia a una metfora de ambos enfoques que propuso Eric S. Raymond en su famoso libro titulado precisamente as, The Cathedral & the Bazaar [Ray99]. Donde comparaba las metodologas tradicionales de desarrollo con la construccin y desarrollo de una catedral, en contraposicin de la forma de crecimiento y expansin aparentemente catica de un bazar. Los mtodos de desarrollo de software libre, realizados por programadores muy variados y con distintas formas de codicar, funcionan en la prctica porque todo el producto est disponible desde el primer momento pblicamente para su revisin y comprobacin. Se logran resultados extensos a base de pequeas contribuciones individuales pero muy numerosas. Para poder aportar alguna contribucin es necesario haber visto y comprendido el trabajo que ya est realizado y por tanto se produce una sinergia con los programadores predecesores que resulta en un desarrollo armonioso. Evidentemente en estos proyectos es necesario algn tipo de coordinacin mnima que es llevada a cabo por el desarrollador ms reconocido que habitualmente es el que ms ha contribuido. Nos extenderemos ms en el mtodo bazar por ser la parte novedosa.
8.5.1. La catedral
Es el mtodo tradicional y seguido por la mayor parte de los fabricantes de software hoy en da. Caractersticas: 1. El software de gran tamao se construye como las catedrales, es decir, cuidadosamente planicado por equipos de expertos que se comunican lo justo entre s. 2. Hay poco personal y bien escogido. Aumentar mucho el nmero de personas es caro y pasado cierto punto no acelera el desarrollo, sino que lo ralentiza. 3. No se publican versiones beta hasta poco antes de terminar. 4. El motivo de que las versiones se publiquen tarde en este modelo es que de lo contrario estaran plagadas de errores. 5. Los errores son difciles de encontrar, requieren una fase de pruebas que se hace al nal. 6. El cdigo fuente se guarda a cal y canto. 7. Subyace a l una estructura organizativa piramidal. 8. El jefe de proyecto debe tener gran talento para el diseo.
8.5.2. El bazar
Es diferente al anterior en todos los puntos anteriores: 1. 2. 3. 4. En un principio hay una idea, pero no se tiene una imagen clara de en que se convertir al nal. Existe una ingente cantidad de personas en su elaboracin y cuantos ms mejor. En el momento en el que se puede publicar una versin se hace, aunque est muy incompleta. Los errores se encuentran con facilidad porque hay muchas personas trabajando simultneamente en ello. Su descubrimiento se pone en marcha desde el principio. 5. El cdigo es abierto, o lo que es lo mismo, cualquiera puede leerlo y modicarlo. 6. La estructura organizativa es difusa, hay una serie de normas para participar pero no una jerarqua claramente denida. Una persona puede contribuir durante toda la vida del proyecto o de un modo fugaz. 7. El coordinador del proyecto ms que tener talento tiene que tener olfato para ver cuando una idea de otro es buena e incorporarla.
El kernel de Linux es el paradigma nmero uno que sigue la losofa del bazar. Es un software de gran tamao y complejidad, iniciado en principio como un pequeo proyecto por Linus Torvalds tomando como base el sistema operativo Minix (un antiguo
118
UNIX para clnicos de IBM-PC). El proyecto sigue en la actualidad mas vivo que nunca y cada da va ganando cuota de mercado a sus competidores (a algunos los ha dejado atrs ya, p. ej: SCO-Unix. Segn Eric S. Raymond en su libro [Ray99]: La Catedral y el Bazar, las conclusiones que se sacan del mtodo bazar son: 1. Todo trabajo de software comienza a partir de las necesidades personales del programador. No es lo mismo trabajar para un proyecto a cambio de un salario que trabajar gratis en algo en lo que se encuentra una satisfaccin personal o se cubre una necesidad. Lo segundo motiva ms. 2. Los buenos programadores saben que escribir. Los mejores que reescribir (y reutilizar). Es ms fcil partir de una solucin aunque sea incompleta y mala que de cero. Linus lo que hizo no fue construir un sistema operativo desde la primera lnea de cdigo hasta el nal (probablemente an estara en ello), en lugar de eso, tom como punto de partida Minix. Por tanto, una forma de iniciar un proyecto puede ser buscar un proyecto similar ya hecho y tomarlo como gua. 3. Contemple desecharlo, de todas formas tendr que hacerlo. Al nal todo el cdigo de Minix fue reemplazado, pero mientras existi fue un armazn a partir del cual pudo ir cambiando partes. El cdigo de partida no es importante, de hecho seguro que tiene un montn de errores y no es adecuado a nuestras necesidades, solo sirve para comprender el problema. 4. Si tienes la actitud adecuada, encontrars problemas interesantes. 5. Cuando se pierde el inters en un programa, el ltimo deber es dejarlo en herencia a un sucesor competente. 6. Tratar a los usuarios como colaboradores es la forma ms apropiada de mejorar el cdigo, y la ms efectiva de depurarlo. 7. Publique rpido y a menudo, y escuche a sus clientes. 8. Dada una base suciente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rpidamente, y su solucin ser obvia al menos para alguien. 9. Las estructuras de datos inteligentes y el cdigo burdo funcionan mucho mejor que en el caso inverso. 10. Si usted trata a sus analistas (beta-testers) como si fueran su recurso ms valioso, ellos le respondern convirtindose en su recurso ms valioso. 11. Lo ms grande despus de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto ltimo es a veces lo mejor. 12. Frecuentemente, las soluciones ms innovadoras y espectaculares provienen de comprender que la concepcin del problema era errnea. 13. La perfeccin (en diseo) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar. 14. Toda herramienta es til emplendose de la forma prevista, pero una gran herramienta es la que se presta a ser utilizada de la manera menos esperada. 15. Cuando se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaucin de alterar el ujo de datos lo menos posible, y nunca eliminar informacin a menos que los receptores obliguen a hacerlo. 16. Cuando su lenguaje est lejos de uno Turing-completo, entonces las ayudas sintcticas pueden ser su mejor amigo. 17. Un sistema de seguridad es tan seguro como secreto. Cudese de los secretos a medias. 18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.
Tutorial posterior
Una metodologa es una forma de concretar todo lo que se ha visto hasta ahora, que es ms que nada una enumeracin ordenada de tcnicas. Las metodologas tienen un ciclo de vida concreto, son o bien orientadas a objetos o estructuradas, realizan las pruebas de un modo, etc.
Proceso Unicado de Rational (RUP) Es una metodologa desarrollada por las personas que han creado el UML, por lo tanto este se usa a lo largo de todas las etapas. La documentacin recomendada es el libro [JBR00c].
Extreme Programming Es otra metodologa de desarrollo orientado a objetos pensada para proyectos de tamao pequeo o mediano donde se tiene contacto muy directo con el cliente. Contiene conceptos muy interesantes: la programacin por parejas, la publicacin de versiones cada muy poco tiempo, la codicacin de las pruebas para cada unidad antes que la propia unidad, breves reuniones diarias, la integracin secuencial prcticamente a diario, la propiedad compartida del cdigo (todo el mundo puede modicar cualquier parte del cdigo).
8.5 Mtodos de software libre: cathedral vs. bazaar
119
Mtrica 3 Es la metodologa denida ocialmente en este pas por el Ministerio de Administraciones Pblicas, por lo tanto, es especialmente recomendada para aquellas personas que tengan pensado hacer oposiciones. Su punto de partida es la versin anterior (2.1). Es en parte orientada a objetos y en parte estructurada. Su ciclo de vida es el denido en la norma ISO-12.207. Incluye un conjunto de procesos que no forman parte del ciclo de vida a los que llama interfaces. Tiene en cuenta la tecnologa cliente servidor y el desarrollo de interfaces grcas de usuario (IGU). Mtodos de software libre: Cathedral vs. Bazaar Este apartado es ms que nada una comparacin entre las metodologas de desarrollo seguidas por empresas que ocultan el cdigo fuente (cathedral) y el fenmeno del software libre (bazaar) donde el cdigo est a la vista de todos (open source) y puede contribuir mucha gente.

Como actividad general y dado que en este captulo se han presentado metodologas de desarrollo de software, sera conveniente que el alumno realizara pruebas con los ejemplos desarrollados en a lo largo de los temas anteriores para entender cmo se aplicaran estas tcnicas sobre ellos, imaginando diferentes escenarios de desarrollo donde se aplicaran las metodologas aqu explicadas u otras similares. 1. 2. 3. 4. 5. 6. Qu informacin contiene una vista en el RUP? Cules son los defectos principales de Extreme Programming? Cules son los pasos a seguir para crear una prueba de unidad en Extreme Programming? En qu consiste la programacin por parejas? Caractersticas principales de catedral Qu tipo de producto es Microsoft Windows: Catedral o Bazar? y GNU/Linux?. Compare Microsoft Windows y GNU/Linux desde los siguientes puntos de vista: Facilidad de instalacin, conguracin y uso. Documentacin existente. Soporte al usuario. Nmero de errores. Eciencia en la gestin de recursos.
Uno de los libros ms recomendables sobre el Proceso Unicado de Rational es el de los autores originales [JBR00c]. Tambin se puede acceder a otra informacin adicional a travs de las pginas de R ATIONAL en http://www.rational.com/ products/rup/. El proyecto sobre la metodologa Extreme-Programming tiene una pgina muy didctica en http://www.c2.com/cgi/ wiki?ExtremeProgramming, y otra con bastantes descripciones en http://www.extremeprogramming.org/. Tambin se puede encontrar mucha informacin y enlaces relativos al mismo tema en http://www.xprogramming.com/, desde donde adems se puede descargar el libro [JAH00] en formato PDF (de la seccin publications). Tambin se pueden consultar, adems del primero [Bec99], otro libro ms reciente [BF00]. El Ministerio de las Administraciones Pblicas mantiene la informacin relativa a la metodologa Mtrica 3 para la planicacin, desarrollo y mantenimiento de los sistemas de informacin en la pgina http://www.map.es/csi/metrica3/. La direccin donde se pueden encontrar los textos originales y traducciones sobre el libro The Cathedral & the Bazaar es http://tuxedo.org/~esr/writings/cathedral-bazaar/ que corresponde con el libro de Eric S. Raymond del mismo ttulo [Ray99]. Adicionalmente se pueden visitar algunos centros de desarrollo de software libre como: http://www. gnu.org/, http://savannah.gnu.org/,http://sourceforge.net/, http://www.gnome.org/, http://www.kde.org/ http://www.mozilla.org/ donde se puede conseguir una visin de los mtodos usados en el desarrollo del software de libre distribucin y de cdigo abierto.
120
Captulo 9
Herramientas de desarrollo y validacin

Tutorial Previo
Introduccin
Existen varias herramientas informticas que facilitan las tcnicas de la ingeniera del software en diferentes aspectos. En este tema se estudian en primer lugar las herramientas CASE, posteriormente veremos una herramienta muy genrica para el desarrollo de versiones de cheros de forma concurrente (CVS) y nalmente algunos entornos genricos de programacin. En el mercado hay varios tipos de herramientas CASE (Computer Aided Software Engineering) para mltiples propsitos: planicacin de proyectos, herramientas de anlisis y diseo, de documentacin, etc. Algunas slo tratan de un tema concreto y otras abarcan todas las fases de una metodologa. CVS es un sistema de almacn de cheros (repository) centralizado en un servidor. El propsito de introducir este apartado aqu es dar a conocer una herramienta que se usa en el control de conguracin. Por otra parte, hoy en da entre el 50 y el 60 por ciento de las lneas de cdigo de una aplicacin son relativas a la interfaz de usuario, es lgico por tanto que existan algunas herramientas dedicadas solo a este n. Las herramientas de desarrollo de interfaces son en realidad herramientas CASE especializadas.

Aqu conviene recordar tanto las diferentes fases del desarrollo que se han estudiado en los temas 3 al 7, puesto que esas fases reejarn la especicidad de las herramientas. De la misma forma algunos entornos estarn inuidos por alguna metodologa concreta de las estudiadas en el tema 8. Para entender CVS es conveniente conocer un poco el sistema UNIX y tener algunas nociones de teleinformtica. Para manejar una herramientas CASE, sobre todo si est pensada para una metodologa concreta como por ejemplo Rational Rose, es necesario conocer esa metodologa y es imprescindible conocer el UML.
Objetivos del tema

Es necesario conocer los diferentes elementos y posibilidades que proporcionan los entornos y herramientas informticas para ayudar precisamente en la construccin de aplicaciones informticas. Se pretende poder manejar un conjunto bsico de comandos de CVS. Dar una introduccin a las herramientas CASE y de construccin de interfaces.

En este tema se hace una revisin somera de algunas de los tipos de herramientas existentes. Es conveniente hacer una primera lectura directa, para despus hacer pruebas con algunas de las herramientas que estn disponibles para el alumno, que de esta forma se puede hacer una idea ms clara de cules son las posibilidades que aporta y cules son los mbitos de aplicacin de cada una. Al ser este captulo de contenido eminentemente prctico, es recomendable probar o jugar con las herramientas recomendadas en el mismo para hacerse una idea de lo que se est hablando. Herramientas CASE. Este apartado se debe estudiar en [Pre01, cap. 31] (o bien [Pre97, cap. 29] en la 4 a edicin). Gestin de la conguracin. El material de este apartado est incluido en esta guia. Entornos de desarrollo de interfaces. Este apartado est incluido directamente en esta guia y tambin procede mayormente de la documentacin respectiva de los entornos.
121
122
9.1. Herramientas CASE

Para el desarrollo en Ingeniera de Software es conveniente utilizar herramientas informticas que nos permitan gestionar y controlar todos los aspectos en las fases de desarrollo. Herramientas CASE (Computer Assisted Software Engineering, o de Ingeniera de de Software asistida por computador) es la denominacin genrica de este tipo de aplicaciones que han aparecido recientemente. Existen diversas herramientas que apoyan los procesos de desarrollo en las diferentes fases, incluyendo las de gestin del software y el proyecto, e incluso agrupaciones organizadas que forman los entornos CASE integrados. El contenido de este apartado se estudia en [Pre01, cap. 31] (o bien [Pre97, cap. 29] en la 4 a edicin).
9.2. Gestin de la conguracin

La gestin de la conguracin del software es una de las partes ms delicadas en el desarrollo del software durante la implementacin, donde un conjunto de programadores estn escribiendo simultneamente el cdigo, y se precisa de alguna herramienta que ayude a organizar y gestionar ese conjunto de cheros. El sistema de versiones concurrentes (CVS) es una herramienta que permite y facilita que diferentes programadores compartan la edicin y modicacin simultnea de los cheros de un proyecto. Una ventaja muy interesante que proporciona esta herramienta es la posibilidad de mantener guardadas todas las versiones anteriores de cada documento.
9.2.1. Introduccin
Suponga que tiene un proyecto de 1.000.000 de horas donde trabajan 1.000 ingenieros en distintos pases. La pregunta es: Cmo se puede gestionar esto?. Pueden surgir muchos problemas, por ejemplo: un equipo necesita un mdulo que otro equipo est haciendo pero que an no ha terminado, y lo necesita para probar el suyo. Como no lo tienen todava lo simulan, pero puede ocurrir que esta simulacin no se comporte igual al mdulo del otro equipo. Pueden surgir tambin inconsistencias entre los diferentes subsistemas debidas a malos entendidos acerca de los servicios que ofrecen unos a otros, etc. La gestin de la conguracin se realiza desde que comienza el proyecto hasta que termina e involucra la recoleccin y el mantenimiento de toda la informacin sobre hardware y software de los sistemas que se usen. Forma parte de un proceso ms general de gestin de la calidad del software, de hecho, la misma persona o grupo que se encarga de la calidad del software puede encargarse tambin de este apartado. La nalidad de todo esto es tener controlados todos los cambios que se hacen sobre el software y tener toda la informacin necesaria en el momento del mantenimiento. Es conveniente que la gestin de conguracin est basada en algn estndar como el IEEE 828-1983. El problema que plantean la mayora de los estndares publicados es que estn pensados para gestionar un sistema que siga el ciclo de vida en cascada. Para realizar esta gestin existen en el mercado varias herramientas especcas y en muchas herramientas CASE esta actividad tambin est soportada. La primera parte de esta seccin es un resumen del documento de Gestin de conguracin por Anglica de Antonio, que se encuentra en http://www.ls.fi.upm.es/udis/docencia/plani/G_Configuracion.pdf.
9.2.2. Objetivos de la gestin de conguracin

Como resumen de lo anterior, los objetivos son los siguientes: 1. Evaluar y mantener la integridad de los productos. 2. Evaluar y controlar los cambios. 3. Facilitar la visibilidad sobre el producto. La integridad en este contexto es: Satisfacer los requisitos implcitos y explcitos. Cumplir requisitos de rendimiento. Se puede trazar su evolucin. Las actividades a realizar para conseguir los objetivos son: Identicacin de la conguracin. Control de cambios de la conguracin. Generacin de informes de estado. Auditora de la conguracin.
9.2.3. Terminologa
Conguracin del software es el conjunto de elementos de conguracin software (ECS) controlados. Cada uno puede tener varias versiones que se suceden en el tiempo.
9.2 Gestin de la conguracin
123
Lnea base es un conjunto de puntos de referencia o hitos que quedan marcados por la aprobacin de uno o varios elementos de conguracin del software mediante una revisin tcnica formal. Versin es un elemento de conguracin en un instante dado. Revisiones son las distintas versiones que van apareciendo. Si una versin y sus revisiones se representan con un grafo, forman una cadena de revisin (ver gura 9.1).
3.0.0
3.0.1
3.0.2
Cadena de revision
3.1.0
3.1.1
Variante
Figura 9.1: Revisiones y variantes Variante es una versin que coexiste con otra y que se diferencia de ella en algunos aspectos. Tipos de variantes: Temporal: Su destino nal es fusionarse con la rama principal. El motivo de su existencia es tener a gente trabajando en paralelo sin que ocurran conictos. La fusin debe hacerse pronto para evitar divergencias. Experimentales: Son prototipos para explorar vas. Nos quedamos con el mejor y tiramos los dems. Pruebas: Se construyen para realizar pruebas. Permanentes: No se mezclan, sirven para distintos tipos de requisitos. Hay dos tipos.
Variantes de requisitos de usuario: Cada variante sirve a un tipo de requisito de usuario. Variantes de plataforma: Por ejemplo para distinto sistema operativo.
Conguracin alternativa es la que compone de un conjunto diferente de elementos de conguracin. Release es una conguracin del sistema que se va a entregar al cliente. Almacenamiento de versiones Hay dos opciones: Guardar la ltima versin de cada ECS. Ventaja: Simplicidad. Inconveniente: No se puede volver atrs despus de un cambio. Guardar las versiones antiguas. Ventaja: Se puede volver atrs. Inconveniente: Es ms complicado de gestionar. Hay que resolver el problema del espacio que ocupa cada cadena de revisin. Interesa minimizar el nmero de revisiones, por eso no se debe crear una nueva con cada mnima modicacin, sino despus de unas cuantas. En un momento dado se congela la versin actual. No se guarda una copia de cada versin, se guarda una copia de una y cada vez que se hace un ckeckout se guardan solo las diferencias entre versiones consecutivas. El conjunto de operaciones que se calcula esas diferencias se llama delta. Hay dos tipos: Delta directo: Cambios para pasar de una versin a la siguiente. Aqu se guarda la primera versin y se van calculando los cambios respecto a la ltima. Delta inverso: Pasa de una versin a la anterior. Se guarda la ltima versin y para recuperar las anteriores hay que calcular su delta. Esta opcin es menos intuitiva que la anterior pero es la ms interesante porque por regla general estaremos interesados en recuperar la ltima versin y as es ms rpido porque no hay que hacer clculos. Los deltas pueden ir mezclados con el chero original o separados. Identicacin de la conguracin No todo lo que se maneja a lo largo del ciclo de vida del sistema se va a incluir entre los documentos a gestionar porque esto generara una cantidad inmanejable de informacin. Hay que hacer una seleccin de las categoras de documentos que se van a incluir. Por ejemplo: los planes del proyecto, las especicaciones, los diseos, el cdigo y las pruebas deben incluirse. Pasos a seguir para la identicacin de elementos: 1. Establecimiento de una jerarqua preliminar. Es un bosquejo de la estructura jerrquica de los elementos de conguracin. Servir como gua para actividades posteriores. 2. Seleccin de los elementos de conguracin. No pueden ser todos porque sera inmanejable ni pocos porque se perdera visibilidad. Criterios para denir elementos de conguracin:
124
Cada funcionalidad del producto debera tener al menos un elemento de conguracin. Si el componente es crtico. Nmero de personas que lo mantienen. Complejidad de la interfaz. Se prev reutilizar en el futuro o es un componente que est siendo reutilizado. Tipo de tecnologa. 3. Relaciones entre ECS. Los tipos de relaciones entre elementos de conguracin son: Equivalencia, composicin, dependencia, sucesin y variante. Se pueden representar mediante un lenguaje de interconexin de mdulos. 4. Denicin de un esquema de identicacin. La informacin de cada elemento de conguracin es: Nmero o cdigo (si es un cdigo puede ser signicativo, en cuyo caso se puede identicar el elemento leyendo su cdigo, escoger un buen sistema de cdigos es complicado), Nombre, Descripcin, Autores, Fecha de creacin, Identicacin del proyecto, Identicacin de lnea base, Fase y subfase de creacin, Tipo de clase, Localizacin, Nmero y fecha de versin. 5. Denicin y establecimiento de lneas base. Una lnea base es un conjunto de hitos denidos a lo largo del proceso de desarrollo. Los objetivos son: Identicar los resultados de las tareas. Asegurar que se ha completado la fase. Formas de denir una lnea base: Fsicamente: Etiquetando cada elemento de conguracin y almacenndolo. Lgicamente: Con un documento que identica el estado del producto en un punto del proceso de desarrollo. 6. Denicin y establecimiento de bibliotecas de software. Una biblioteca es software y documentacin relacionada. Debe existir un miembro del equipo de gestin de conguracin con la funcin de bibliotecario. Se debe poner por escrito (y respetar) los procedimientos para establecer la biblioteca, introducir elementos y acceder a ella. Tipos de bibliotecas: Biblioteca de trabajo: Es una biblioteca de tipo borrador. Contiene documentos del proyecto, codicacin y pruebas unitarias. Posteriormente los elementos se pasan a la biblioteca de Soporte (esta ltima es ms formal). Biblioteca de integracin: Es donde los elementos de conguracin se integran en elementos de nivel superior. Biblioteca de soporte al proyecto. Es la biblioteca ocial. Los elementos aqu introducidos desde las dos anteriores estn sujetos a un control de cambios. Biblioteca de produccin: Es una composicin de las tres anteriores. Biblioteca maestra: Es donde se almacenan las releases. Est sujeta a un estricto control de cambios que restringe mucho las escrituras pero no las lecturas. Repositorio de software: Son todos los documentos que es necesario guardar despus del cierre del proyecto. Biblioteca de backup: Sus elementos no estn sometidos a gestin de conguracin.
9.2.4. Control de cambios

El motivo de que exista la gestin de la conguracin es precisamente controlar los cambios. Lo que es un cambio y los pasos a seguir para realizarlo por los miembros del equipo se han visto ya en el captulo dedicado a ello, por lo que respecta a su gestin se debe denir una poltica que dena qu. cundo, cmo y quin, es decir: Responsabilidades, Contenido de las lneas base, Tipos de cambios que se van a controlar, Funciones del comit de control de cambios, Documentacin necesaria para quien solicita un cambio, etc. La gura del bibliotecario denida en el punto anterior debe encargarse de controlar las versiones y hacer las transferencias adecuadas de documentos desde la biblioteca de soporte a la biblioteca de trabajo. La biblioteca maestra se modica cuando el cambio haya sido incorporado ocialmente. Por lo que respecta a la biblioteca del proyecto hay que tener en cuenta dos elementos: Control de acceso: Posibilidades de hacer cambios por parte de los miembros del equipo. Control de sincronizacin: Coordinacin de los cambios que se realicen en paralelo sobre un mismo ECS.
9.2.5. Generacin de cambios de estado

Esta actividad consiste en mantener a la gente informada respecto a qu y cundo ocurren las cosas. Consta de tres actividades que se realizan secuencialmente: Captura de la informacin. Almacenamiento de la informacin. Generacin de informes.
125
Los productos son registros e informes. Motivos: Mantener la continuidad del proyecto si por ejemplo hay cambios en la plantilla. Evitar la duplicidad del trabajo. No caer en los mismos errores y poder repetir lo que sali bien. Encontrar causas de fallos. La informacin para esta tarea viene de las otras tres actividades de la gestin de conguracin. El plan de gestin de conguracin debe indicar entre otras cosas la cantidad mnima de informacin a guardar. El mejor sitio para almacenar esta informacin es una base de datos, que puede servir para estimaciones de proyectos futuros o para un anlisis post-mortem. Registros Un registro mantiene la informacin relativa a un producto. Se pueden tener registros de varios tipos: Elementos de conguracin. Lneas base, Solicitudes de cambios, Cambios, Incidencias, Modicaciones del cdigo, Modicaciones de base de datos, Modicaciones sobre documentacin, Releases y variantes, Instalaciones y Actas de las reuniones del comit de control de cambios. Informes Existen dos tipos: Planicados y bajo demanda. Ejemplos: Informe de estado de los cambios, Inventario de los elementos de conguracin, etc.
9.2.6. Plan de gestin de la conguracin

Es un documento que se debe producir al principio del proyecto. Dene la poltica a seguir. Segn el estndar IEEE tiene que tener los siguientes apartados: 1. Introduccin a) b) c) d) e) Propsito del plan. Alcance. Deniciones y acrnimos. Referencias. Denicin de alto nivel del proceso de GCS.
2. Especicaciones de gestin a) b) c) d) Organizacin. Responsabilidades. Implantacin del plan de gestin de conguracin. Polticas, directivas y procedimientos aplicables.
3. Actividades de gestin de conguracin a) b) c) d) Identicacin de la conguracin. Control de la conguracin. Contabilidad de estado de la conguracin. Auditora de la conguracin.
4. Control de suministradores 5. Recogida y retencin de registros
9.2.7. CVS (Concurrent Versioning System)

CVS es un almacn de cheros donde se puede trazar la historia de los cheros fuente que en l se depositan. Esto quiere decir que se pueden recuperar las versiones anteriores a la actual para, por ejemplo, poder saber cuando se ha introducido un error. Tambin es capaz de mezclar las modicaciones que dos personas han hecho sobre un mismo mdulo para evitar que una sobreescriba a la otra. Todo esto est soportado en un almacn centralizado (ver gura 9.2). Cuando alguien quiere trabajar con un conjunto de cheros, se hace copias de las copias maestras que estn en el almacn centralizado. Cuando termina, las descarga en el almacn. Se puede recuperar cada una de las versiones que un chero ha tenido a lo largo de toda su historia, pero como guardar cada una de estas copias supondra mucho espacio de disco, CVS slo guarda las diferencias entre sucesivas versiones en un nico chero de un modo inteligente.
126
Repositorio CVS
Red
Figura 9.2: CVS Un punto importante es que CVS no es por s mismo la herramienta que sirve para hacer la gestin de conguracin, tan slo gestiona el almacn de cheros. Es decir, cubre buena parte de la gestin de conguracin, pero eso es todo. El problema ms importante que plantea CVS es la gestin de permisos. Hay que tener cuidado acerca de a quin se permite escribir y dnde. El tipo de proyectos sobre los que se puede usar CVS son los de pequeo y mediano tamao, para proyectos grandes existen otras herramientas ms avanzadas como Subversion, Aegis, e incluso otras gratuitas (aunque no de libre distribucin) como BitKeeper (usado para gestionar los fuentes del kernel de Linux), o incluso comerciales como ClearCase. Trminos bsicos Repositorio: Almacn central donde estn las copias maestras. El repositorio central es un rbol de directorios. Mdulo: Un directorio o rbol de directorios del repositorio maestro. RCS (Revision Control System): Conjunto de utilidades de bajo nivel. Check out: Hacer una copia de un chero. Revision: Etiqueta numrica que identica la versin de un chero. Conjunto de comandos La mayora deben ser ejecutados en el directorio en el que est la informacin. cvs checkout (= cvs co): Crea una copia local de los cheros de un mdulo. cvs update: Actualiza las copias con los cambios que se hayan hecho en el repositorio. Los actualizados aparecen con una U. Los modicados en la copia con una M. Aquellos cheros modicados tanto en la copia particular como en la maestra aparecen con una C. cvs commit: Actualiza el repositorio con los cambios hechos en la copia. Si no se ha hecho un update de la versin ms reciente lo hace notar. cvs add y cvs remove: Aade o borra cheros del repositorio. Remove deja los cheros borrados en un limbo del que se pueden rescatar (algo as como la papelera en los entornos de escritorio). cvs release: Sirve para borrar la copia local. Ejemplo: cvs release modulo. Para que esto funcione hay que estar bajo el mdulo. Primero hay que hacer un commit. Para borrar tambin los subdirectorios del mdulo y la copia local: cvs release -d modulo. cvs log: Sirve para ver el historial de comandos aplicados sobre un chero y quien los ha hecho. Ejemplo: cvs log fichero. cvs tag: Se pueden marcar todos los cheros de un mdulo con un nombre simblico. Afecta a las copias. Ejemplo: cvs tag etiqueta [ficheros].
127
cvs rtag: Es lo mismo que el punto anterior pero sobre las copias maestras (las que estn en el repositorio). Ejemplo: cvs rtag ETIQ fuentes. Recorre de forma recursiva los directorios del repositorio bajo fuentes y aade el tag ETIQ a cada chero. cvs history: Da informacin sobre los repositorios CVS. Por defecto slo da toda la informacin que corresponda al usuario. Con la opcin -a da informacin sobre todos los usuarios. cvs -H: Sistema de ayuda. Con cvs -H comando se obtiene la informacin sobre un comando especco.
9.2.8. Software libre

Las caractersticas bsicas del software libre son ms o menos estas: Cdigo fuente abierto: Todos los cheros fuente estn disponibles de modo tal que los usuarios (programadores) pueden si quieren leerlos y modicarlos para aadir mejoras o corregir defectos. El software modicado tambin es libre, es decir, los derechos de los usuarios son irrevocables. Permiso de distribucin: Cualquiera tiene permiso para distribuir tantas copias como desee. En algunos casos la nica restriccin es que no se puede cobrar ms del coste del soporte en el que est almacenado y los gastos de envo. Licencias libres: El programador inicial retiene los derechos de autor, pero permite a los usuarios normalmente ms cosas que las licencias cerradas. Otorga a los posibles receptores de la distribucin por parte de terceras personas los mismos derechos de quienes distribuyen. El motivo de que las caractersticas sean ms o menos estas es que existen muchos tipos distintos de licencias libres, pero los tres puntos anteriores son el comn denominador principal. Licencia GPL Es una de las licencias ms importantes. GPL (GNU General Public License, Licencia Pblica General de GNU). Es la licencia bajo la que se distribuye el proyecto GNU, que surgi en 1984 para desarrollar un sistema operativo de tipo Unix gratuito. La licencia GPL est pensada para que no se pueda hacer uso de partes de software libre en programas no libres, tambin obliga a distribuir el cdigo fuente junto con los binarios.
9.2.9. Sourceforge: Un ejemplo de almacn de software libre

SourceForge http://www.sourceforge.net/ es un sitio web de desarrollo open source. Denicin de Open Source En la pgina http://www.opensource.org/docs/definition.html se encuentra la denicin ms precisas de lo que se considera Open Source (denominacin ms genrica del software libre) desde el punto de vista de Sourceforge para permitir que un proyecto se aloje en sus servidores. Como su nombre indica Open Source signica que el cdigo fuente est disponible para el pblico en general. Existen una serie de condiciones que se deben cumplir: 1. Distribucin libre: No se exige el pago de derechos de patente (royalties) por el cdigo. Motivo: Eliminar la tentacin de tirar por la borda ganancias a largo plazo por ganancias a corto plazo. En caso contrario, los colaboradores se podran ir. 2. Cdigo fuente: Debe estar disponible el cdigo fuente y deber ser gratis. No se pueden utilizar ofuscadores de cdigo (programas que reescriben el cdigo fuente dejando la misma funcionalidad pero hacindolos ilegibles para humanos). Motivo: No se puede hacer evolucionar una aplicacin si no se dispone de cdigo fuente. 3. Modicacin del cdigo: La licencia permite la modicacin del cdigo fuente y el resultado deber ser distribuido en los mismos trminos que el original. Motivo: Es necesario hacer modicaciones y distribuirlas para que exista un desarrollo evolutivo rpido. 4. Integridad del cdigo fuente del autor: Se puede restringir que se modique el cdigo fuente slo si se permite la distribucin de parches que modiquen el programa. Las modicaciones deben llevar un nombre o un nmero de versin diferente del software original. Motivo: Los autores tienen derecho a que se sepa lo que ha hecho cada uno y los usuarios quien ha hecho el software que usan. 5. No se discriminar a personas o grupos: La licencia no debe excluir a nadie. Motivo: Cuanta ms diversidad, mejor. 6. No se discriminarn tipos de actividades. Por ejemplo: Empresas, Investigacin, etc. Motivo: Se intenta evitar trucos legales que permita que el cdigo abierto sea usado comercialmente. 7. Distribucin de la licencia: Los derechos asociados a la licencia se aplican a todos aquellos a los que se redistribuya la aplicacin sin que se tenga que aplicar una licencia adicional. Motivo: Se trata de que no se pueda restringir el acceso al software por medios indirectos. 8. La licencia no ser especca de un producto: A cualquier parte de una aplicacin se la aplican los mismos derechos que a toda la aplicacin.
128
9. La licencia no establece restricciones para otro software: El resto del software que se distribuya no ser afectado por las restricciones del GPL. Los servicios gratuitos que proporciona SourceForge son: repositorio CVS, listas de correo, seguimiento de errores, foros, gestin de tareas software, backups y administracin basada en web.
9.3. Entornos de desarrollo de interfaces

En este apartado se estudiarn algunos de los entornos de programacin orientados al desarrollo de interfaces existentes actualmente. Se har especial nfasis en los de libre distribucin para que el alumno pueda experimentar con ellos. Los entornos que en la actualidad tienen ms mpetu de desarrollo y mayores capacidades son: G NOME /G TK + y K DE /Q T. En los ejemplos incluidos aqu nos centraremos en uno de ellos (GTK+), ya que ambos son muy similares y tienen herramientas equivalentes.
9.3.1. Introduccin
A continuacin se describen algunas herramientas freeware de creacin de interfaces. El contenido de esta seccin ser familiar para aquellas personas que hayan desarrollado algn proyecto con compiladores con nombre ms comercial como Visual Basic, Delphi o C++ Builder. La razn por la que se incluye este apartado es que las interfaces constituyen el 50 % de las lneas de cdigo de muchos proyectos (la presentacin es importante) y al ser un tipo de actividad susceptible de reutilizar cdigo y al ser bastante mecnica existen herramientas pensadas para acelerar su desarrollo. La idea en la que se basan estos entornos es muy parecida: 1. Se tiene una librera extensa de componentes grcos (etiquetas, editores, botones, etc) que se muestran en una ventana. En cualquier caso, si se necesita un componente que no est es casi seguro que se puede encontrar en algn lugar de internet. 2. Se tiene otra ventana que representa la interfaz grca que se est construyendo donde se depositan los componentes del punto anterior. El modo de hacerlo puede ser arrastrar y soltar. 3. Los componentes tienen variables que se manipulan en tiempo de diseo en la ventana correspondiente. 4. El entorno genera el cdigo que produce la interfaz con un aspecto como el que se est diseando, encargndose de manipular los componentes de forma adecuada pero sin que el programador tenga que escribir el cdigo. 5. El entorno puede ir solo o integrado en un entorno de desarrollo con editor, compilador, etc.
9.3.2. Componentes
Un componente es un objeto, que como todo objeto consta de cdigo y datos. De ellos nos importan tres cosas: 1. Propiedades: Son los valores de las variables pblicas. Son un conjunto de variables que se pueden manipular en tiempo de diseo y de ejecucin y que controlan el aspecto externo de dicho componente. 2. Eventos: Son sucesos como puede ser la pulsacin de una tecla o el movimiento del ratn. Existe un gestor de eventos que captura estos sucesos y manda una seal al objeto adecuado, por ejemplo, si se pulsa el ratn sobre un botn el gestor de eventos invoca el mtodo OnClick de ese botn. 3. Mtodos: Son las funciones del objeto. Se pueden escribir en el diseo, es decir, el desarrollador escribe lo que quiere que ocurra cuando se invoca el mtodo, por ejemplo, que cuando se pulsa un botn (se invoca OnClick) el ttulo del botn cambie. Los componentes estn estructurados en jerarquas, de modo tal que cuando hay que crear un nuevo componente lo mejor es derivarlo de uno antiguo reutilizando tanta funcionalidad como sea posible. Tipos de componentes. La forma de escribir componentes, la forma en la que se comunican con el resto del software e incluso el sitio donde pueden ejecutarse denen una taxonoma muy interesante al respecto. 1. ActiveX: Es un tipo de componente que se distribuye como binario, as que puede estar escrito en cualquier lenguaje de programacin. El objeto tiene una interfaz estndar para que otros objetos se comuniquen con l. Los programas que usan controles ActiveX se llaman contenedores. El contenedor de un control es una aplicacin capacitada para el manejo de ActiveX que acta como soporte de interfaz de usuario para dicho control. Se puede por ejemplo, presentar un botn que, una vez pulsado, enve un mensaje al control. O tambin responder a diversos sucesos o mensajes especiales que se manden desde el control al contenedor. Un ejemplo de contenedor es un navegador, que puede mostrar controles ActiveX en una pgina web incluso aunque el control provenga de un ordenador remoto. 2. VCL (Visual Component Library): Son componentes grcos para la interfaz de usuario. Constan de propiedades, mtodos y eventos. El cdigo que maneja cada evento es escrito en un mtodo. Las propiedades se pueden editar en modo de diseo, de modo que no es necesario escribir lneas de cdigo para inicializar cada componente. Las propiedades y mtodos pueden tener los siguientes tipos de acceso: Privado: El cdigo que no pertenece al componente no puede acceder a esta parte. Protegido: Slo pueden acceder a esta parte los componentes que hereden de este.
9.3 Entornos de desarrollo de interfaces
129
Publico: Se puede acceder libremente a estos mtodos y propiedades pero no para depuracin. Publicado: Se puede acceder tanto para manipulacin como para depuracin.
9.3.3. Creacin de interfaces de usuario

Esto podra denirse como el apartado artstico. No debe ser despreciado por ello, es quizs lo ms importante. Una interfaz es la parte externa del programa, lo que el usuario ve. Si est mal diseada sacar una pobre impresin de ella aunque funcione perfectamente. El usuario ha de comprender la mecnica y la operativa que le ofrece el interfaz (sintaxis, rdenes, cdigos, abreviaciones e iconos ... ), todo esto supone un trabajo de memorizacin. Una buena interfaz minimiza el esfuerzo mental que se demanda al usuario. Con el n de que esa dicultad se minimice es importante establecer un sistema de ayudas adecuado. Estas ayudas se centrarn en la operativa y la aclaracin de funciones de los elementos visuales o acsticos. Por otra parte, el diseo de la interfaz supone que el usuario hace un modelo mental. Es importante la coherencia entre las distintas partes para que ese modelo se mantenga. Por tanto, el objetivo de una interfaz es que tenga las siguientes propiedades: 1. 2. 3. 4. 5. 6. 7. 8. Facilidad de aprendizaje y uso. El objeto de inters ha de ser de fcil identicacin. Diseo ergonmico, por ejemplo: barra de acciones o iconos preferentemente a la derecha. Las interacciones se basarn preferiblemente en acciones fsicas sobre elementos de cdigo visual o auditivo (iconos, imgenes, mensajes ... ) antes que en selecciones tipo men con sintaxis y rdenes. Las operaciones sern rpidas, incrementales y reversibles con efectos inmediatos (de ser posible). Los mensajes de error ser adecuado a los conocimientos que tiene el usuario, debern ser tiles y descriptivos. Como el elemento fundamental es la pantalla del ordenador, se cuidar especialmente la organizacin, combinando informacin y elementos de interaccin. El tratamiento del color debe contar con una serie de normas tales como luminosidad, saturacin, tono, etc. Es mejor tener una profundidad de color lo mayor posible (8 bits dan 256 colores, 16 bits 65536 colores, etc). Los iconos deben ser descriptivos. Tipografa: Se procurar combinar letras maysculas y minsculas, procurando no mezclar en pantalla ms de dos tipos y tres medidas diferentes de letra. Multimedia: Los grcos mviles o las grabaciones pueden aportar dinamismo a la interfaz, pero no es bueno abusar de ellos.
9. 10.
9.3.4. Metodologa
Se puede entender una interfaz como una aplicacin en s misma, y por tanto, es razonable que sigamos los mismos pasos que en la construccin de cualquier sistema, esto es, denir una serie de etapas para su construccin. Esas etapas son las de siempre: Especicacin, diseo, codicacin y en lugar de pruebas lo llamaremos test de usabilidad, porque es eso lo que se pretende comprobar. El test de usabilidad valida el diseo de la interfaz de usuario. La forma de realizarlo es sentar a un usuario delante de la mquina con una lista de tareas y pedirle que exprese verbalmente lo que va pensando mientras tanto. De esta forma se puede ver cuales son los problemas que se encuentra la gente La forma de denir una interfaz del sistema para un sistema basado en casos de uso tiene una serie de pasos y subpasos: 1. Dibujar las pantallas de interaccin para los distintos actores-usuarios. Para ello: Copiar el modelo mental del usuario. Revisar los elementos del modelo del mundo interesantes para el actor-usuario. Visualizacin tpica de los elementos del modelo del mundo. Informacin relevante para el actor. Metforas de interaccin vlidas. 2. Especicar el dilogo que da solucin a cada caso de uso que se soluciona con la interaccin con esta interfaz. Puede especicarse este dilogo de varias maneras, dependiendo de la complejidad de la interfaz denida (en esta etapa se sugiere escoger el mnimo nivel de detalle posible, para dar ms libertad de diseo en las etapas posteriores): Por medio de una descripcin textual de su funcionamiento Por medio de diagramas de interaccin que muestren la secuencia de operaciones entre los objetos de interfaz y los actores involucrados. Por medio de diagramas de estados, donde se muestre claramente los estados de la interfaz. Por medio de un prototipo funcional, en trminos de la interaccin con el usuario. 3. Denir restricciones para la comunicacin con actores y sistemas.
130
Describir en el detalle del actor o de la relacin con el caso de uso particular.
9.3.5. Heursticas de usabilidad

Son el declogo a seguir para conseguir un buen resultado en este parmetro. Estas normas fueron compiladas por R. Molich y J. Nielsen en 1990. 1. Visibilidad del estado del sistema: El sistema debe mantener informado al usuario de lo que est pasando para obtener de l una realimentacin adecuada. 2. Correspondencia entre el sistema y el mundo real: El sistema se debe expresar en los trminos del usuario en lugar de en jerga tcnica. La informacin debe aparecer en el orden en el que ocurre en el mundo real. 3. Control del usuario y libertad: Los usuarios de vez en cuando cometen errores y deben tener alguna forma sencilla de salir del estado provocado. Se debe soportar deshacer y rehacer (undo y redo). 4. Consistencia y estndares: No se deben emplear diferentes palabras para expresar lo mismo en diferentes partes del sistema. Seguir alguna convencin. 5. Prevencin de errores: Es mejor tener un diseo cuidadoso para prevenir los errores que mensajes de error. 6. Instrucciones accesibles: La informacin acerca de cmo usar el sistema debe estar visible para el usuario cuando lo necesite. 7. Flexibilidad y eciencia de uso: Debe existir alguna forma de que las acciones ms comunes se puedan realizar rpidamente, por ejemplo con combinaciones de teclas. 8. Diseo minimalista: No deben existir ms elementos grcos de los necesarios pues el exceso de informacin enturbia la comprensin. 9. Ayudar a los usuarios con los errores: Los mensajes de error deben estar expresados en lenguaje sencillo (sin cdigos de error), indicando el problema y vas de solucin. 10. Ayuda y documentacin: Debe ser fcil buscar informacin en la documentacin, debe estar centrada en las tareas de usuario (por ejemplo con una lista de pasos a seguir) y no debe ser demasiado larga.
9.3.6. Glade
Glade es un programa gratuito de desarrollo de interfaces. Usa las libreras de GTK+ y de GNOME. Genera el cdigo que crea la interfaz en varios lenguajes: C, C++ Ada, Perl y Eiffel (con lo que puede considerarse como una herramienta CASE). Tambin es capaz de crear interfaces dinmicas usando libglade. La herramienta se compone de tres ventanas: 1. Ventana principal: Barra de men, la barra de herramientas y una lista de ventanas de alto nivel. 2. El editor de propiedades. 3. La paleta: En ella estn desplegados los elementos que se pueden poner en la interfaz de usuario. Estn divididos en tres categoras: GTK+ Bsico, GTK+ Avanzado y Gnome. La forma de utilizar la herramienta es: Primero se escoge el elemento ventana y entonces se pueden poner otros elementos sobre ella. Para organizar los elementos Glade utiliza cajas. Para poner ms de un elemento en la ventana hay que poner primero cajas. Las hay de seis tipos: caja horizontal, caja vertical, tabla, posiciones ajustables, caja de botones horizontal, caja de botones vertical y las cajas a su vez se pueden anidar. Cuando se crean cajas horizontales y verticales hay que especicar el nmero de las y columnas. Cuando se selecciona un componente la ventana de propiedades muestra sus propiedades. Existe un rbol de componentes que se puede ver seleccionando: View y Show widget tree. Tambin hay un editor de mens, tanto los normales como los emergentes, que pueden ser anidados. El editor tambin crea manejadores de seales para cada opcin, que son las funciones invocadas cuando una opcin de men es seleccionada. Un evento es un tipo de suceso, como puede ser presionar seleccionar una opcin de men o pulsar un botn. Cuando ocurre un evento el sistema llama a una funcin que lo trata y es en esa funcin donde se escribe el cdigo con las instrucciones que se deben ejecutar para responder al evento. Por ejemplo, si se pulsa una opcin de men File->Save en un editor de texto, habr que guardar el texto en un chero. Glade genera automticamente los nombres de las funciones que responden a los eventos y al menos cada elemento tiene uno.
9.3.7. GTK+
GTK+ (GIMP ToolKit) es una librera en lenguaje C para crear interfaces grcas de usuario. Tiene licencia GPL, lo cual signica que es open source y de libre distribucin. Fue diseado originalmente como una herramienta de desarrollo del GIMP (General Image Manipulation Program) y est construido sobre GDK (GIMP Drawing Kit) que es un aadido de las libreras Xlib. GTK+ es un interfaz de programacin de aplicaciones orientadas a objetos (API). Aunque est escrito en lenguaje C, fue pensado con la idea de las clases y los punteros a funciones. Al igual que el anterior permite usar gran variedad de componentes (botones, cajas, etc), pero tiene una exibilidad mayor en el sentido de que los componentes estn formados a su vez partiendo de otros componentes, que lgicamente pueden ser
9.3 Entornos de desarrollo de interfaces
131
reemplazados. Por ejemplo, un botn puede tener como hijo un componente etiqueta para representar el texto, pero se puede sustituir por un bitmap. Por ltimo, GTK+ dene un conjunto de tipos dinmico propio con reglas nuevas acerca de como gestionarlos.
9.3.8. Anjuta
Es un entorno de desarrollo escrito por un estudiante de informtica de ltimo curso llamado Kh. Nabakumar Singh (Anjuta es el nombre de su novia). Esta pensado para proyectos en C/C++ para GTK+/GNOME, es decir, para GNU/Linux. Anjuta es libre y su cdigo fuente est disponible en la red. Proporciona una IGU (interfaz grca de usuario) dividida en tres partes: Editor: Muestra el texto coloreado. Tiene las funciones estndar de Crear, Salvar, Buscar, etc. Proyecto. Mensajes. Las funcionalidades ofrecidas son accedidas a travs de un sistema de mens que se pueden desmontar de su lugar original. Las funciones ms comunes pueden encontrarse en las cuatro barras de herramientas. Desde el entorno se puede compilar y ejecutar el programa. Puede asimismo congurarse para especicar rutas de cheros include, rutas de libreras, libreras para enlazar, macros, tipos de alertas del compilador, optimizaciones del cdigo, etc. El entorno consta asimismo de algunas utilidades para gestionar proyectos. Existe tambin la posibilidad de depurar el programa, o lo que es lo mismo, de ejecutarlo paso a paso, poner puntos de ruptura, evaluar expresiones, ver los registros de la CPU, etc.
Tutorial posterior
En captulo se han colocado todos aquellos temas que no tienen entidad suciente como para ser un captulo por s mismos, es decir, el captulo es una recopilacin de conceptos interesantes y prcticos acerca de la ingeniera del software. Herramientas CASE Una herramienta CASE es una aplicacin diseada para facilitar tareas mecnicas que se realizan en las diferentes etapas del ciclo de vida. Hay varios tipos y las mejores son las que cubren todas las etapas del ciclo de vida y pensadas adems para una metodologa concreta. Se incluye una clasicacin de herramientas CASE. Gestin de la conguracin Es el conjunto de prcticas y tcnicas que ayudan a gestionar todos los documentos (cdigo, manuales, etc.) que se generan a lo largo del ciclo de vida del proyecto. Existen herramientas que lo soportan, como CVS del que se hace una pequea descripcin. Los temas que importan en la gestin de la conguracin son: cules son los documentos que hay que guardar, cmo se almacenan, cmo se relacionan entre s y cmo se gestionan los cambios. El plan de gestin de la conguracin es un documento que dene la poltica a seguir. Se da una plantilla de dicho documento. CVS es una herramienta de libre distribucin para la gestin de la conguracin que se puede encontrar en cualquier sistema de tipo UNIX GNU/Linux. Se describe brevemente por estar muy extendida. Sourceforge http://sourceforge.net/ es un ejemplo de almacn centralizado en Internet para el desarrollo de software de libre distribucin. Se hace un listado de sus caractersticas ms relevantes y se dene lo que se entiende por software libre. Entornos de desarrollo de interfaces El desarrollo de interfaces es importante por el porcentaje tan elevado de lneas de cdigo que suponen en un proyecto (en torno al 50 %). Para este n se han desarrollado herramientas CASE concretas que facilitan el trabajo mecnico. Los componentes son mdulos de software reutilizable, sobre todo en interfaces grcas. Tipos de componentes: ActiveX y VCL. En la creacin de interfaces de usuario se dene un conjunto de objetivos que tiene que cumplir toda interfaz, todos ellos estn orientados a usuarios, una metodologa para el desarrollo de interfaces y heursticas de usabilidad. Se ve una somera descripcin de algunas herramientas de libre distribucin para desarrollo de interfaces: Glade, Gtk y Anjuta.

1. 2. 3. 4. 5. Qu es mejor en principio, una herramienta I-CASE una U-CASE? Cules son los objetivos de la gestin de la conguracin? En la gestin de la conguracin, cmo se llama lo que se entrega al usuario? Qu es y cmo se dene una lnea base? Qu criterios se emplean para decir que una interfaz de usuario es usable?
132
La mayor fuente alternativa para extender conocimientos en este tema es Internet. Todas las herramientas y entornos explicados tienen pginas Web propias. En particular sobre herramientas CASE se recomiendan las direcciones: http://www.cs.queensu.ca/FAQs/SE/ que contiene enlaces a un extenssimo catlogo con herramientas CASE clasicadas y que forma parte de la FAQ del grupo de foros USENET news://comp.software-eng, hay una copia en http://www.faqs.org/faqs/software-eng/, y ver tambin en http://sdt.cern.ch/ la pgina del Software Development Tool Service del CERN. Sobre el sistema CVS se puede consultar directamente el manual en lnea http://www.cvshome.org/docs/manual/ en el propio dominio del proyecto, o bien la parte en linea de libre distribucin del libro [FB00] en http://cvsbook.red-bean. com/cvsbook.html. Actualmente est en desarrollo (bastante avanzado) una nueva herramienta de gestin de versiones con el objetivo de sustituir a CVS, se trata de S UBVERSION cuya pgina de desarrollo es: http://subversion.tigris.org/. Tambin podemos incluir en este apartado A EGIS que es un entorno de gestin de desarrollo para proyectos y utiliza una interfaz Web (aparte de lnea de comandos), con ms informacin en la pgina http://aegis.sourceforge.net/. Para las diferentes herramientas de desarrollo propuestas se pueden visitar directamente las paginas correspondientes: http: //glade.gnome.org/ sobre G LADE (y tambin de A NJUTA http://anjuta.sourceforge.net/ que utiliza G LADE), http: //www.wxwindows.org/ sobre WX W INDOWS, http://www.kdevelop.org/ sobre K DEVELOP.
Apndice A
Glosario de trminos
Abstraccin: Separar las caractersticas que interesan para un modelo de las irrelevantes. Acoplamiento: Medida de la complejidad de los interfaces de los mdulos. ActiveX: Tipo de componente distribuido como binario. Actividad: Cada una de las partes en las que se divide una fase. Actividades, diagrama: Grco de UML que modela el comportamiento interno de una clase. Actividades, diagrama de: Grco UML que muestra el comportamiento y la participacin de las clases en el mismo. til para ujos de trabajo. Actor: Persona o sistema que juega un papel en la interaccin con un sistema. Agregacin: Relacin entre dos clases en la que una es parte de la otra. Alcance: Visibilidad de un atributo. Puede ser pblico, protegido o privado. Almacn: Es un conjunto de datos esttico. Puede ser un archivo o una base de datos. Alto nivel, lenguajes: Son lenguajes con alto nivel de abstraccin. Hacen lo mismo que un lenguaje de bajo nivel pero con menos lneas. mbito: Nmero de veces que existe el objeto. De instancia: Una por cada instancia de la clase. Archivador: Una nica vez, como las variables static de Java. Anlisis: Etapa donde el problema es la comprensin de las necesidades. Anlisis crtico: Actividad que se realiza desde el principio del proyecto para localizar los problemas de alto riesgo. Anlisis de valores lmite: Tcnica de generacin de casos de prueba conjunta con particiones de equivalencia que genera casos de prueba cercanos al mximo o mnimo tamao de un array o al mximo o mnimo nmero de iteraciones de un bucle. rboles de decisin: Grco en forma de rbol para escribir una especicacin de procesos cuando se tiene un conjunto de unas pocas variables y se toman decisiones en funcin de los valores que tomen. Asociaciones: Relacin que se establece entre dos o ms clases. Atributo: Variable de una clase. Auditora: Examen del sistema preferiblemente por parte de una organizacin no involucrada en el proceso de desarrollo. Tipos: regulares, especiales, sorpresa, de seguimiento, nanciera, operacional, de gestin e informtica. Brainstorming: Tcnica poco estructurada de obtencin de requisitos en una reunin. Caja blanca, pruebas: Pruebas que tienen en cuenta la estructura lgica del programa. Caja de cristal, pruebas: Ver caja blanca. Caja negra, pruebas: Pruebas que tienen en cuenta las especicaciones. Calicacin: Atributo que rebaja la cardinalidad de una parte de la asociacin entre dos clases. Cardinalidad: Nmero de entidades que estn asociadas con otra(s) en una relacin. Cascada: Ciclo de vida lineal. 133
134
Glosario de trminos
CASE: (Computer Aided Software Engineering) Herramienta para automatizar o facilitar parte o todo el trabajo mecnico (no creativo) de parte o todo el ciclo de vida. Casos de prueba: Conjunto de entradas y de salidas esperadas para esas entradas. Casos de uso: Mtodo de anlisis para una interaccin del sistema con el usuario u otro sistema. Ciclo de vida: Conjunto de etapas por las que pasa un sistema informtico desde su concepcin hasta su retirada. Clase: Estructura de datos con las operaciones relativas a esos datos. Clases, diagrama: Principal tipo de diagrama en UML que muestra las clases y las relaciones que tienen. Clases de equivalencia: Agrupaciones de las entradas iguales a efectos de las pruebas. Cleanroom: Tcnica de generacin de software basada en mtodos formales para minimizar el nmero de errores. Cliente-servidor: Arquitectura de sistemas distribuidos con una parte que funciona como interfaz (cliente) y otra que gestiona recursos y realiza el trabajo (servidor). Codicacin: Etapa del ciclo de vida en la que se escribe el cdigo fuente. Cdigo heredado: (legacy code) Cdigo de aplicaciones antiguas posiblemente muy remendado y sin documentacin. Cohesin: Caracterstica de un mdulo. Un mdulo tiene cohesin si sus tareas son independientes del resto del sistema pero estn relacionadas entre s. Colaboracin, diagrama: Indica interacciones entre objetos a travs de los enlaces que hay entre ellos. Similar al diagrama de secuencia. Complejidad ciclomtica: Medida de la complejidad de un programa, igual al nmero de caminos independientes que tiene. Componentes: Software pensado para ser reutilizable. Consta de cdigo y datos. Componentes, diagrama: Grco de UML que muestra la organizacin y dependencias entre componentes. Composicin: Es un tipo de agregacin en la que cada componente pertenece a un todo y slo a ese. Congruencia: Un mtodo es congruente si tiene un nombre similar a mtodos similares, condiciones, orden de argumentos, valor proporcionado y condiciones de error. Contexto, diagrama: Representacin del sistema y entidades externas que interaccionan con l. CORBA: (Common Object Request Broquer Architecture) Sistema distribuido multiplataforma basado en objetos. Cada uno puede ser cliente y servidor. CRC: Mecanismo para representar clases e interacciones entre ellas. Crisis del software: La consecuencia de escribir cdigo sin plantear seriamente metodologas para el anlisis, diseo y mantenimiento. CVS: (Concurrent Versioning System) Almacenamiento de cheros con capacidad de trazar las aportaciones de cada persona y la historia de cada archivo. Defecto: El sistema hace algo de forma equivocada. Es la consecuencia de un error y se maniesta a travs de un fallo. DFD: (Diagrama de Flujo de Datos) Herramienta del diseo estructurado para modelar la transformacin o transaccin de la informacin. Diccionario de datos: Descripcin detallada de los ujos de datos Diseo: Etapa del ciclo de vida en la que se divide el sistema en subsistemas y posteriormente se decide cmo sern las estructuras de datos y algoritmos. Distribucin, diagrama: Grco de UML que reeja la organizacin del hardware. Encapsulamiento: Propiedad por la que un objeto o mdulo proporciona al exterior las funciones necesarias para su manejo y no los detalles internos. Entidad-Relacin: Modelo de datos del diseo estructurado. Entidades externas: Personas o sistemas que interaccionan con el sistema. Entrada/Salida, pruebas: Ver caja negra.
135
Entrevistas: Tcnica de obtencin de requisitos que consiste en hablar con un usuario. Error: Equivocacin de un desarrollador en cualquiera de las fases. Produce uno o ms defectos. Especicacin: Traduccin de los requisitos del anlisis a un documento que sirva para empezar el diseo. Especicacin de control: Muestran como a partir de seales de control se activan o desactivan procesos del diagrama de ujo de control asociado. Especicacin de procesos: Concretar en pseudocdigo o en algn lenguaje de programacin cmo es un mdulo que ya no se puede descomponer ms. Espiral, ciclo de vida: Ciclo de vida con varias iteraciones. Hace nfasis en el control del riesgo. Tpico en la orientacin a objetos. Estados, diagrama: Representacin del comportamiento interno de un sistema. Estereotipos: Forma de dar nombre a un elemento que no forma parte del estandar de UML. Estructurales, pruebas: Ver pruebas de caja blanca. Estructuras, diagrama: Mtodo de descomposicin funcional donde el bloque bsico es el mdulo. Etapa: Cada una de las partes de las que se compone el ciclo de vida. Factor de calidad: Forma de determinar la calidad de un software. Estn divididos en funcin de criterios de operacin, revisin y transicin. Cada uno se obtiene a partir de varias mtricas. Fallo: Manifestacin de un defecto. Flujo de datos: Representacin de datos que se mueven entre procesos o entidades externas. Flujo de control: Diagrama que informa sobre cuando y en que orden ocurren los sucesos. Framework: Conjunto integrado de componentes que colaboran para proporcionar una arquitectura reutilizable para una familia de aplicaciones. Fuente, ciclo de vida: Ciclo de vida para sistemas orientados a objetos. Funcionales, pruebas: Ver caja negra. Generalizacin: Ver herencia. Grafo de ujo: Representacin de un programa usada para el diseo de casos de prueba estructurales. Herencia: Mecanismo por el que unas clases mantienen los mismos mtodos y propiedades de otras a las cuales amplian. HIPO, diagramas: (Hierarchy Input Process Output) Diagrama de diseo que muestra entradas, salidas y funciones. IDL: (Interface Denition Languaje) Lenguaje formal para expresar interfaces. Incremental: Ciclo de vida derivado del de cascada pero con iteraciones para implementar distintas partes del sistema. Ingeniera inversa: Anlisis de un producto construido para comprender sus principios de diseo. Indicador: Medida numrica para comprobar algo de un modo objetivo. Los hay econmicos, nancieros, de ocupacin laboral y de gestin. Inspecciones: Revisin del cdigo sin ejecutarlo. Muy estructurada y realizada por un equipo. Interfaz: Conjunto de servicios proporcionados por una clase. JAD: (Joint Application Design) Tcnica muy estructurada de obtencin de requisitos en una reunin. Java Beans: Componentes escritos en java. Jackson, diagramas: Produce una especicacin del programa a partir de una especicacin de las entradas y las salidas, que deben ser secuenciales. JRP: (Joint Requirements Planning) Subconjunto del JAD para obtencin de requisitos de alto nivel. Lenguaje estructrado: Pseudocdigo para escribir las especicaciones de proceso. Lnea base: Puntos de referencia en la gestin de conguracin. Mantenimiento: Etapa nal del ciclo de vida. Consume la mayor parte de los recursos.
136
Glosario de trminos
Mantenibilidad: Cualidad de una aplicacin que hace que el mantenimiento sea ms fcil. Metodologa: Modo sistemtico de fabricar un producto. Mtricas: Medidas numricas sobre alguna cualidad de un programa. Modelo: Abstraccin de la realidad donde se omite lo no esencial. Mdulo: Cada una de las partes con entidad propia en las que se divide un sistema. Modularidad: Propiedad del software. Un programa es modular si est dividido en partes con tareas denidas. Multiplicidad: Nmero de elementos que estn en los lados de una relacin. Navegabilidad: Posibilidad de moverse de una clase a otra utilizando las relaciones que hay entre ellas. Normalizacin: Algoritmos que convierten una base de datos en otra equivalente pero sin anomalias de insercin, borrado y modicacin, ms eciente y menos redundante. Notas: Explicaciones de los elementos de notacin de UML. Objeto: Instancia de una clase. OCL: (Object Constraint Languaje) Lenguaje formal para expresar restricciones. Paquetes: Conjunto de clases relacionadas entre si. Patrones: Prototipos de soluciones para problemas conocidos. Los hay de anlisis, arquitectnicos, de diseo, de codicacin y de organizacin. Persistencia: Caracterstica de un objeto que se puede escribir en disco para posteriormente ser recuperado. Polimorsmo: Capacidad de un conjunto de objetos de responder a un mensaje con el mismo nombre o a un objeto de poder responder a un mismo mensaje con distintos parmetros. Privado: Tipo de alcance ms restrictivo posible. Una propiedad de este tipo solo puede ser accedida dentro de la clase en la que est declarada. Proceso: Subsistemas o funciones en las que se divie el sistema. Protegido: Tipo de alcance que restringe el acceso a la clase en la que se ha declarado y a sus descendientes. Prototipo: Versin reducida de la aplicacin nal. Se construye para obtener requisitos o para partiendo de l hacer incrementos hasta el sistema nal. Pruebas: Batera de test que el sistema tiene que superar para ser considerado operativo. Pblico: Tipo de alcance que permite el acceso a cualquier otra clase. Reduccin de riesgos, cascada con: Ciclo de vida cascada con iteraciones en el anlisis y diseo global. Reingeniera: Reconstruccin completa de una aplicacin antigua utilizando tcnicas modernas. Requisitos funcionales: Lo que el sistema hace para el usuario. Requisitos no funcionales: Caractersticas del sistema (abilidad, mantenibilidad, etc). Se tienen en cuenta en la fase de diseo. Responsabilidades: Descripcin de lo que hace una clase. Revisin: Las distintas versiones de un elementos software que van surgiendo. Sashimi, ciclo: Ciclo de vida en cascada con solapamiento entre las fases. Secuencias, diagrama: Grco de UML que muestra los mensajes intercambiados entre objetos teniendo en cuenta el tiempo. Sistema: Conjunto de elementos que cooperan entre si para proporcionar servicios. Sistemas, ingeniera de: Herramientas y metodologas para crear sistemas. Software, ingeniera del: Herramientas y metodologas para crear software. Tarea: Una etapa (p.ej. el diseo) se descompone en tareas. Una tarea puede realizarse a lo largo de varias etapas, por ejemplo la documentacin. Tablas de decisin: Forma de escribir una especicacin de procesos cuando hay muchas variables y en funcin de su valor se toman decisiones.
137
Transicin de estados: Diagrama de UML que reeja los cambios que esperimenta una clase como si fuera un autmata nito. UML: (Unied modeling languaje) Notacin de facto para el modelado de sistemas orientados a objetos. V, ciclo de vida en: Ciclo de vida similar al de cascada pero que toma en consideracin el nivel de abstraccin de cada una. El anlisis valida el mantenimiento y el diseo verica las pruebas. Validacin: Comprobacin de que el sistema cumple con las especicaciones funcionales y no funcionales. Variante: Versin de un elemento software que cohexiste con otra con algunas diferencias. VCL: (Visual Component Library) Componente grco. Vericacin: Comprobacin de que el sistema funciona correctamente. Versin: Un elemento software en un momento dado. Walkthrough: Revisin del cdigo sin ejecutarlo. Realizado por un equipo. Warnier, diagramas: Representacin jerrquica de la estructura de los programas y estructuras de datos.
138
Glosario de trminos
Bibliografa
[Bau72] [Bec99] [BF00] [BMP87] [Boo94] [CCEG00] [DEM02] [FB00] [Fow97] [FW94] [Gau01] [GW89] [Haw98] [Hum95] [Hum01] [Jac92] [JAH00] [JBR00a] [JBR00b] [JBR00c] [Mey98] [Pre97] [Pre01] [PV96] [Ray99]
F. L. Bauer. Software Engineering. Information Processing, (71), 1972. Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999. Kent Beck and Martin Fowler. Planning Extreme Programming. Addison-Wesley, 2000. Doug Bell, Ian Morrey, and John Pugh. Software Engineering: A Programming Approach. Prentice Hall, 1987. Grady Booch. Object-Oriented Analysis and Design. Benjamin Cummings, 1994. J. A. Cerrada, M. Collado, J. F. Estvaliz, and S. R. Gmez. Introduccin a la Ingeniera de Software. Ceura, 2000. Allen Downey, Jeff Elkner, and Chris Meyers. How to Think Like a Computer Scientist: Learning with Python. Green Tea Press, 2002. http://thinkpython.com. Karl Fogel and Moshe Bar. Open Source Development With CVS. The Coriolis Group, 2000. Martin Fowler. UML Distilled. Addison Wesley, 1997. Neville J. Ford and Mark Woodroffe. Introducing Software Engineering. Prentice-Hall, 1994. Alan Gauld. Learn to Program Using Python. Addison-Wesley, 2001. Donald A. Gause and Gerald M. Weinberg. Exploring Requirements: Quality Before Design. Sei Series in Software Engineering. Dorset House, 1989. I. T. Hawryszkiewycz. Introduccin al anlisis y diseo de sistemas. Anaya, 1998. Watts S. Humphrey. A Discipline for Software Engineering. Addison-Wesley, 1995. Watts S. Humphrey. Introduccin al Proceso Software Personal SM . Addison-Wesley, 2001. Ivar Jacobson. Object Oriented Software Engineering. Addison Wesley, 1992. Ron Jeffries, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed. Addison-Wesley, 2000. ftp://ftp.xprogramming.com/ftp/xpinstall.pdf. Ivar Jacobson, Grady Booch, and James Rumbaugh. El lenguaje unicado de modelado. Addison Wesley, 2000. Ivar Jacobson, Grady Booch, and James Rumbaugh. El lenguaje unicado de modelado. Manual de referencia. Addison Wesley, 2000. Ivar Jacobson, Grady Booch, and James Rumbaugh. El proceso unicado de desarrollo de software. Addison Wesley, 2000. Bertrand Meyer. Construccin de Software O-O. Prentice Hall Iberia, 1998. Roger S. Pressman. Ingeniera de Software: un Enfoque Prctico. McGraw-Hill, 1997. Roger S. Pressman. Ingeniera de Software: un Enfoque Prctico. McGraw-Hill, 2001. Mario G. Piattini Velthuis. Anlisis y diseo detallado de aplicaciones informticas de gestin. RAMA, 1996. Eric S. Raymond. The Cathedral & the Bazaar. http://tuxedo.org/esr/writings/cathedral-bazaar/. OReilly & Associates, Inc., October 1999.
[RBP 96] [Sch92] [Sch01a]
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Modelado y diseo orientado a objetos. Metodologa OMT y OMT II. Prentice Hall, 1996. Stephen R. Schach. Practical Software Engineering. Aksen Associates, 1992. Stephen R. Schach. Object oriented and classical software engineering. Mc GrawHill, 2001. 139
140
Bibliografa
[Sch01b] [Som98] [Som01]
Joseph Schmuller. Aprendiendo UML en 24 horas. Prentice Hall, 2001. Ian Sommerville. Ingeniera de Software. Addison-Wesley Iberoamericana, 1998. Ian Sommerville. Software Engineering. Addison-Wesley, 2001.
[WBWW90] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. Designing Object-Oriented Software. Prentice Hall, 1990.
ndice alfabtico
Aceptacin, 76 ActiveX, 128 Actividades, 103 Actor, 91 Adecuacin, 3 Almacn, 117 Anlisis, 34, 116 Clase, 93 Modelo, 93 Paquete, 93 Paquete de servicio, 93 RUP, 93 Anlisis costo-benecio, 78 Anlisis de riesgo, 78 Anlisis de sistema de informacin, 114 Anlisis de sistemas de informacin, 106 Anjuta, 131 Argumentos, 62 Arquitecto, 96 Arquitectura Anlisis, 93 Descripcin, 91, 93 Diseo, 95 Implementacin, 96 Arquitectura de capas, 89 Arquitectura de mdulos Diseo, 107 Arquitectura de soporte Diseo, 107 Arquitectura del sistema Denicin, 108 Artefactos, 93, 96 Aseguramiento de la calidad, 113 Asignacin, 62 Asociaciones, 54 C++, 54 Java, 55 Ayuda, 130 Bazaar, 117 Biblioteca de software, 124 Biblioteca de backup, 124 Biblioteca de integracin, 124 Biblioteca de produccin, 124 Biblioteca de soporte, 124 Biblioteca de trabajo, 124 Biblioteca maestra, 124 Repositorio de software, 124 Bibliotecario, 124 Bloques, 61 Brainstorming, 37 C++, 3 Cdigo Propiedad compartida, 103 Cdigo externo, 56 Cambios de estado, 124 Capa intermedia, 89 Carga inicial, 108 Caso de prueba, 97 Caso de uso, 91 Anlisis, 94 Diseo, 95 Instancia, 91 Realizacin, 94 Casos de uso, 39, 40, 52, 86 Actor, 39 Rol, 39 Actores abstractos, 41 Casos de uso abstractos, 41 Casos de uso de implementacin, 41 Casos de uso esenciales, 41 Casos de uso primarios, 42 Casos de uso secundarios, 42 Casos de uso temporales, 42 Comunicates, 16 Detallar, 92 Diseo, 108 Estructura, 92 Extends, 16 Include, 16 Priorizar, 92 Realizacin, 93 Cast, 63 Cathedral, 117 Check out, 126 Ciclo de vida, 4 Cascada con reduccin de riesgos, 7 Cascada con subproyectos, 6 Cascada incremental, 7 Ciclo de vida en cascada, 4 Ciclo de vida en V, 6 Diseo, 94 Espiral, 7 Fuente, 9 Sashimi, 6 Cierre, 76 Clase, 10 Abreviada, 11 Abstracta, 10 Anlisis, 94 Asociacin, 12 Agragacin, 13 Calicacin, 13 Composicin, 13 Dependencia, 13 Herencia y generalizacin, 13 Interfaces, 13 Multiplicidad, 12
141
142
ndice alfabtico
Navegabilidad, 13 Reexiva, 12 Rol, 12 Atributos, 10 Diseo, 95 Estereotipo, 11 Implementacin, 97 Mtodos, 11 Nombre, 10 Notas, 11 Objeto, 11 Paquete, 11 Responsabilidades, 11 Clase del diseo, 94 Clases, 61 Diseo, 108 Java, 67 ClearCase, 126 Cliente, 102 Cliente/Servidor, 103 code-and-x, 2 Codicacin Estndares, 102 Prueba de unidad, 101 Unidad, 101 Comentarios, 58, 60 Java, 66 Componente, 96 Componente de prueba, 97 Componentes, 128 Conguracin del software, 122 Congelar, 123 Const, 61 Constantes Java, 67 Construccin, 116 Construccin de sistemas de informacin, 109 Constructores, 62 Control de cambios, 124 Control de ujo, 61, 64 Contruccin del sistema de informacin, 114 Correccin, 3 Creacin de objetos, 53 C++, 53 Java, 53 CVS, 125 Declaracin, 58 Funciones, 58 Variables, 58 Declaraciones Java, 66 Defecto, 97 Denicin de clases, 52 C++, 52 Java, 53 Delegacin, 56 Delta, 123 Delta directo, 123 Delta inverso, 123 Demeter, 56 Destruccin de objetos, 53 C++, 53 Java, 53
Destructores, 62 DFD, 3 Diagrama de actividades, 19 Actividades, 19 Actividades concurrentes, 19 Bifurcaciones, 19 Indicaciones, 19 Punto nal, 19 Punto inicial, 19 Transiciones, 19 Diagrama de casos de uso, 15 Diagrama de clases, 14 Diagrama de colaboracin, 20 Diagrama de componentes, 19 Diagrama de distribucin, 20 Nodo, 20 Diagrama de estados, 17 Do, 17 Entry, 17 Exit, 17 Diagrama de objetos, 15 Diagrama de secuencias, 17 Activacin, 17 Boundary classes, 18 Condicionales, 17 Creacin, 18 Destruccin, 18 Iteracin, 18 Lnea de vida, 17 Mtodos recursivos, 18 Mensaje, 17 Tiempos de transicin, 17 Diccionario de datos, 3 Directorio, 68 Diseador de pruebas, 97 Disear prueba, 98 Diseo, 116 Revisin, 48 RUP, 94 Subsistema, 94 Validacin, 49 Vericacin, 48 Diseo de detalle, 107 Diseo de sistemas de informacin, 107 Diseo del sistema de informacin, 114 Diseo fsico de datos, 107 Disponibilidad, 3 Documentacin, 68, 130 Eciencia, 3 Entrevistas, 35 Fases, 35 Errores, 64, 102, 130 Especicacin, 34 Especicacin de procesos, 3 Especicaciones de construccin, 108 Especicaciones de la base de datos, 79 Especicaciones de sistema, 78 Especicaciones de subsistema, 78 Especicaciones del programa, 79 Estudio de la viabilidad, 105 Estudio de viabilidad, 78, 113, 116 Etapas ciclo de vida, 4 Anlisis, 4
ndice alfabtico
143
Codicacin, 4 Diseo, 4 Mantenimiento, 4 Pruebas, 4 Evaluacin de prueba, 97 Evaluar prueba, 98 Eventos, 128 Excepciones, 64 Explicativo, 68 Expresiones, 64 Extensibilidad, 56 Extreme programming, 98 Fiabilidad, 3 Finalizacin, 75, 113 Flujo de sucesos, 91 Flujo de trabajo, 92, 93, 95, 96 Flujos de trabajo, 98 Friend, 61 Funciones, 61 Generacin de especicaciones de construccin, 110 Gestin de cambios, 112 Gestin de la conguracin, 115, 122 Gestin de proyectos, 112 Gestor de eventos, 128 Glade, 130 Glosario, 91 GNU, 127 GPL, 127 GTK+, 130 Herencia, 54, 62 C++, 54 Esttica, 54 Implcita, 54 Java, 54 Por grupos, 54 Heursticas de usabilidad, 130 Historias de usuario, 99 IGU, 103 Implantacin de sistemas de informacin, 110 Implantacin y aceptacin, 115 Implantacin y aceptacin del sistema, 116 Implementacin, 96 Implementar prueba, 98 Include, 60 Indicadores, 76 Informes, 125 Ingeniera de sistemas, 2 Ingeniera del software, 2 Ingeniera directa, 52 Ingeniera inversa, 52 Ingeniero de componentes, 96, 97 Ingeniero de pruebas de integracin, 97 Ingeniero de pruebas de sistema, 97 Inicio de proyecto, 112 Inline, 61, 63 Instrucciones de soporte, 82 Integracin, 96, 101 Secuencial, 101 Integrador de sistemas, 96 Integridad, 122 Interfaces, 103, 112
Java, 67 Interfaz, 95, 96 Interfaz de usuario Diseador, 91 Prototipo, 91, 92 Invocacin de mtodos, 53 C++, 54 Java, 54 Islas de conocimiento, 103 Iteracin Planicacin, 90, 100 Iteraciones, 90 JAD, 35 Java, 3 JRP, 37 Lnea base, 123, 124 La crisis del software, 2 Libreras del sistema, 82 Licencia, 127 Linux, 117 Mtodos Java, 67 Mdulo, 126 Mantenibilidad, 3 Mantenimiento, 117 Mantenimiento de sistemas de informacin, 111 Mantenimiento del sistema de informacin, 115 Manual de explotacin, 109 Manual de mantenimiento, 79 Manual de operacin, 79 Manual de pruebas, 82 Manual de usuario, 79, 109 Material de capacitacin, 82 Memoria, 64 Metodologa, 2, 129 Estructurada, 3 Orientada a objetos, 3 Migracin, 108 Minimalista, 130 Miniprototipo, 100 Modelado del dominio, 91 Modelado del negocio, 91 Modelo, 10 Modelo de casos de uso, 91 Modelo de despliegue, 95 Arquitectura, 95 Modelo de diseo, 94 Arquitectura, 95 Modelo de implementacin, 96 Modelo de implementacion Vista de la arquitectura, 96 MTBF, 3 Multiplataforma, 64 Nombre, 59 Nombres, 60 Java, 67 Nomenclatura, 102 Normas, 57 C, 57 C++, 59 Java, 65
144
ndice alfabtico
OMT, 10 OOSE, 10 Optimizaciones, 102 Overow, 65 Pblico, 129 Pair programming, 103 Paquete Anlisis, 94 Paquetes Java, 67 Personal, 102 Plan de instalacin, 79 Plan de integracin de construcciones, 96 Plan de proyecto, 78 Plan de prueba, 97 Plan de pruebas, 72 Especicacin tcnica, 108 Plan de publicacin, 99 Plan de sistemas de informacin, 104 Planicacin, 104, 116 Planicar prueba, 98 Prcticas, 103 Prlogo, 68 Privado, 128 Procedimiento de prueba, 97 Procedimientos, 80 Procedimientos de migracin y carga de datos, 110 Procedimientos de operacin, 109 Procedimientos de seguridad, 109 Procesos, 103, 104 Protegido, 128 Prototipos, 38 Componentes reutilizables, 38 Nivel de aplicacin, 39 Nivel de componente, 39 Desarrollo rpido de prototipos, 38 Lenguajes de alto nivel, 38 Programacin de bases de datos, 38 Prueba, 97 Prueba de integracin, 98 Prueba de sistema, 98 Prueba de unidad, 97, 101 Pruebas, 79 Modelo, 97 Pruebas de desempeo, 73 Pruebas de tensin, 73 Pruebas estructurales, 73 Pruebas funcionales, 72 Pruebas de integracin, 110 Pruebas de regresin, 90 Pruebas de sistema, 110 Pruebas unitarias, 110 Publicado, 129 Punteros, 61, 63 RCS, 126 Registros, 125 Rehacer, 102 Release, 123 Repositorio, 126 Requisito, 34 Requisitos Requisitos funcionales, 91
Requisitos no funcionales, 91 Requisitos cambiantes, 90 Requisitos de datos, 78 Requisitos de implantacin, 108 Requisitos funcionales, 34, 78, 89 Requisitos no funcionales, 34 Reuniones, 103 Reusabilidad, 55 Revisin, 123, 126 Riesgos, 89 Gestin, 90 Tratamiento, 90 Robustez, 56 RUP, 86 Construccin, 87 Elaboracin, 87 Inicio, 86 Transicin, 87 SCO-Unix, 118 Secuenciacin, 90 Seguimiento y control, 112 Gestin de inicidencias, 112 Sentencias Java, 66 Separaciones Java, 67 Simula67, 3 Sistema, 2 Smaltalk, 3 Sobrecarga, 62 Funciones, 62 Operadores, 62 Software libre, 127 Sourceforge, 127 SRS, 43 Subsistema Diseo, 96 Implementacin, 97 Subsistema de implementacin, 96 Subsistemas, 107 Tabla de tareas, 103 Tarjetas CRC, 100 Templates, 62 Test de aceptacin, 102 Test de unidad, 102 Trabajadores, 91, 93, 9597 Analista de sistemas, 91 Arquitecto, 91, 93, 95 Diseador de interfaz de usuario, 91 Especicador de casos de uso, 91 Ingeniero de casos de uso, 93, 95 Ingeniero de componentes, 93 Tutoriales, 80 UML, 10, 52, 86 Underow, 65 Unix, 118 Usabilidad, 3 Variables, 63 Java, 67 Variante, 123 Experimental, 123
ndice alfabtico
145
Permanente, 123 Pruebas, 123 Temporar, 123 Variantes de plataforma, 123 Variantes de requisitos de usuario, 123 VCL, 128 Versin, 123 versin delta, 87 Visibilidad, 130 Vistas, 89

Ciclo Software - Jose Ramon

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ciclo Software - Jose Ramon

Загружено:

Авторское право:

Доступные форматы

Anlisis, Diseo y Mantenimiento del Software

VII VII VIII IX

47 48 48 48 48 48 48 49 49 50 51 52 52 55 57 59 65 67 68 68 68 69 71 71 72 72 73 75 75 76 76 76 77 77 77 78 78 79 80 82 83 85 86 86 86 88 88 89 89 90 94 96 97 98 99 99 100 100 101 101

Gua de estudio de la asignatura

Contexto y conocimientos previos

Contexto acadmico simultneo

Contexto acadmico posterior

Esquema y resumen de contenidos

Tema 2: Descripcin de Ejemplos Gua

Tema 3: Fase de Requisitos

Sistemas Informticos I coincide parcialmente en el tiempo (2

cuatrimestre) con esta asignatura.

Tema 4: Fase de Diseo

Tema 5: Fase de Implementacin

Guas de estilo de codicacin Iteracin de pruebas y depuracin Manuales tcnico y de usuario

Tema 6: Fases de Pruebas

Tema 7: Fase de Entrega y Mantenimiento

Tema 8: Metodologas de Desarrollo

Tema 9: Herramientas de Desarrollo y Validacin

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

Material y medios de estudio

Contexto de la asignatura en la Ingeniera de Software

Relacin con otros temas

Objetivos del tema

Gua de estudio y esquema

Contexto de la asignatura en la Ingeniera de Software

1.1. Necesidad de una metodologa

1.1.2. La crisis del software

1.1.3. Denicin de metodologa

1.1 Necesidad de una metodologa

1.1.4. Finalidad de una metodologa

1.1.5. Taxonoma de las metodologas

Procesos Flujos de datos Almacenes de datos

Contexto de la asignatura en la Ingeniera de Software

1.2. Ciclo de vida del software

1.2.1. Ciclos de vida en cascada

1.2 Ciclo de vida del software

Contexto de la asignatura en la Ingeniera de Software

Analisis Nivel de abstraccion Diseo

Figura 1.3: Ciclo de vida en V

Figura 1.4: Ciclo de vida sashimi

1.2 Ciclo de vida del software

Figura 1.5: Cascada incremental

1.2.2. Modelo de ciclo de vida en espiral

Caractersticas del producto.

Contexto de la asignatura en la Ingeniera de Software

Prototipo 2 Prototipo 1 Simulaciones, Modelos, Benchmarks

Figura 1.6: Ciclo de vida en espiral Formas de gestionar el proyecto.

1.3 Notaciones de especicacin y diseo (UML)

1.2.3. Ciclos de vida orientados a objetos

Planificacion ConstruccionLiberacion del negocio

Planificacion ConstruccionLiberacion del negocio

Planificacion ConstruccionLiberacion del negocio

Planificacion Investigacion Especificacion Implement. Revision

Figura 1.7: Ciclo de vida fuente

1.3. Notaciones de especicacin y diseo (UML)

Contexto de la asignatura en la Ingeniera de Software

1.3.2. Elementos del lenguaje UML

1.3 Notaciones de especicacin y diseo (UML)

Figura 1.10: Un paquete que se puede encontrar en Java

No se tiene en cuenta el coeficiente de seguridad del cable

Figura 1.11: Una anotacin relativa a una clase

Contexto de la asignatura en la Ingeniera de Software

Trabaja para Empleador Empleado