Segundo Ejercicio.

Cosecha propia
Criptografa. Definiciones Confusin, Difusin, Cifrador de flujo, Cifrador de bloque, Criptografa simtrica, asimtrica, Sobre digital y Huella digital? Confusin: Tcnica de criptografa por la cual existe una relacin lo ms compleja posible entre la clave y el texto cifrado Difusin: Tcnica de criptografa basada en la distribucin estadstica de caracteres por la cual cada caracter del texto cifrado depende del mayor nmero posible de caracteres del texto original Cifrador de flujo: Cifran caracter a caracter. Son muy rpidos y basados slo en tcnicas de confusin. Ejemplos son RC4, RC5, A52. Uso mayoritario en Wifi sobre WEP y GSM. Cifrador de bloque: Cifran descomponiendo el texto original en bloques de igual longitud. Son lentos y basados en tcnicas de confusin y difusin. Los sistemas actuales usan cifrado en bloque. Ejemplos son DES, TDES, AES. Uso mayoritario en WIMAX y Wifi sobre WPA Criptografa simtrica: Utilizan la misma clave para cifrar y descifrar. La distribucin de claves exige un canal seguro. El nmero de claves implicadas es muy grande segn aumenta el nmero de participantes. Ejemplos, los nombrados en cifrador de flujo y bloque. Criptografa asimtrica: Cada participante usa una clave privada y una clave pblica. El emisor cifra el mensaje con la clave pblica del receptor. El receptor descifra con su clave privada. Tambin se usa como medio de autenticacin cuando el emisor cifra un resumen del mensaje con su clave privada. Esto se conoce como firma digital cuando se aade al mensaje original. Ejemplos son RSA y DSA. Sobre digital: Es la combinacin de criptografa simtrica para cifrar un mensaje y criptografa asimtrica para transmitir la clave simtrica que descifra el mensaje. Esta tcnica es utilizada en SSL. Huella digital: Dependiendo de los autores se asocia a la firma electrnica (con criptografa asimtrica o simtrica) y al hash resumen de un mensaje.? Mtrica3. Perfil Jefe de Proyecto En Mtrica v3 se definen 5 perfiles de participantes: Directivo, Jefe de Proyecto, Consultor, Analista y Programador. El Jefe de Proyecto es el encargado de dirigir y coordinar a los recursos humanos que se encargan del desarrollo del SW. Adems es responsable de alcanzar los objetivos de costes, plazos y especificaciones de calidad del producto software. En esta tarea, el jefe de Proyecto realiza funciones como la eleccin del modelo de ciclo de vida, determinar las procesos, fases y tareas de que consta el proyecto, realizar la estimacin de esfuerzo, elaborar la planificacin del proyecto, tareas de seguimiento y control y coordinar la documentacin final del proyecto. Este perfil se divide en los siguientes participantes: Jefe de Proyecto, Responsable de operacin, Responsable de implantacin, Responsable de mantenimiento, Responsable de sistemas, Responsable de calidad y Responsable de seguridad. Mtrica3. Interfaz de Gestin de la Configuracin Es una de las 4 interfaces de Mtrica 3. Su objetivo es triple: 1. Mantener la integridad del producto a lo largo de todo el proceso de desarrollo 2. Asegurar que no se producen cambios incontrolados sobre el producto 3. Garantizar que cada integrante del equipo de desarrollo est en disposicin de obtener una versin actualizada de los productos que manejan La interfaz de Gestin de la Configuracin abarca tanto a productos ejecutables como a modelos de anlisis y diseo, documentacin, etc. La interfaz de Gestin de la Configuracin facilita el mantenimiento y permite tener una visin global de los cambios producidos en el producto y las diferentes versiones por las que pasa. Todo ello se traduce en un incremento de calidad sobre el desarrollo del software. La interfaz de Gestin de la Configuracin se realiza en paralelo sobre los procesos de desarrollo del Software (EVS-MSI)

Mtrica3. Interfaz de Gestin del proyecto Es una de las 4 interfaces de Mtrica 3. Su objetivo es la planificacin del proyecto, estimacin de recursos y seguimiento y control del proyecto. Mtrica tiene como referencia el EUROMTODO. La gestin del proyecto mantiene 3 procesos: 1. Inicio del Proyecto: Incluye las tareas de estimacin de esfuerzo y planificacin. Utiliza tcnicas de estimacin como Albretch, Mark2 o Staffing Size. Adems hace uso de WBS (Work Breakdown Structure), PERT, GANTT y diagramas de extrapolacin. El inicio del proyecto se realiza al concluir el proceso EVS y antes de comenzar ASI. 2. Seguimiento del Proyecto: En este proceso se realiza desde la asignacin de recursos a las tareas, hasta su aceptacin. Adems se ocupa de la gestin de incidencias que surgen durante el desarrollo, as como la peticin de cambios de requisitos del cliente. El seguimiento del proyecto usa tcnicas como diagramas de GANTT, Historial de Recursos y patrn de lmites. 3. Finalizacin del Proyecto. Tras la fase de MSI, la finalizacin del proyecto se ocupa de recopilar la documentacin final del proyecto y cerrar el proyecto.

Mtrica3. Caminos y Clculos de acceso Ambos son prcticas de Mtrica 3 que se usan en los procesos de Anlisis y Diseo del Sistema de Informacin. Los caminos de acceso se usan para determinar las secuencias de acceso a datos que realizan los mdulos funcionales sobre el modelo de datos. Tambin puede usarse esta prctica sobre estructuras de ficheros. Cuando se usa en el Anlisis permiten verificar que el modelo lgico normalizado cumple los requisitos. Cuando se usa en el Diseo, permite verificar el modelo fsico en cuanto a actualizaciones y consultas. El proceso que se sigue es identificar las tablas que deben ser accedidas por los mdulos y crear vistas con ellas. Se indica el tipo de acceso a cada una de las vistas y se detectan posibles accesos redundantes o excesivamente complejos. Los clculos de acceso tienen por objetivo estimar el nmero de accesos sobre el modelo de datos al realizar una consulta determinada. Hacen uso de los resultados del camino de accesos. Cuando se usa en el anlisis permite determinar en el acceso lgico, la viabilidad de las consultas. Cuando se usa en el diseo, permite optimizar del modelo fsico de datos. En esta prctica se usa notacin matricial. Mtrica3. JAD y JRP Ambas son prcticas de Mtrica 3 sobre sesiones de trabajo. El objetivo de JAD (Joint Application Design) es minimizar el tiempo de desarrollo manteniendo la calidad del producto. El objetivo de JRP (Joint Requirements Planning) es obtener los mejores resultados, en el menor tiempo posible e incrementando la calidad. Para ello potencian la participacin activa de los altos cargos. En ambos casos se realizan pocas reuniones de larga duracin. Se diferencian en los participantes y en los productos finales. En las reuniones de ambas prcticas existir un moderador, el promotor del proyecto y un modelador de diagramas. Adems en una sesin JAD participan el equipo de desarrollo, jefe de proyecto y usuarios. Mientras, en una sesin JRP participan consultores, director de proyecto y usuarios de alto nivel. Los productos de salida en una sesin JAD son diagramas realizados con herramientas CASE y validados por los integrantes de la sesin. En una sesin JRP, el resultado son modelos de procesos de la organizacin, modelos de sistemas de informacin, etc

Mtrica3. Anlisis de impacto e Impacto en la sociedad Ambos son prcticas de Mtrica 3, pero son bastante diferentes. El anlisis de impacto se usa en fases tardas del desarrollo, como el Mantenimiento de Sistemas de Informacin. Su objetivo es determinar de manera cuantitativa qu elemntos estn realmente implicados en la peticin de cambio propuesta por el usuario y su viabilidad. Se realiza sobre sistemas que se encuentran en produccin. Se realiza sobre un inventario de componentes en el que se localizarn los componentes afectados. En ese momento, se aplicarn indicadores sobre cada componente y se cuantifica el coste. Gracias a esta prctica se puede evaluar la viabilidad del cambio, su correcta planificacin y recursos necesarios para abordarla. El impacto en la sociedad se usa en fases tempranas del desarrollo como la Planificacin y el Estudio de Viabilidad del Sistema. Consiste en analizar, anticipadamente, las consecuencias para la organizacin de una accin relacionada con un cambio de los Sistemas y Tecnologas de la Informacin y Comunicaciones. Se analizarn factores como la dificultad de la nueva tecnologa, el rechazo cultural, coste de la adquisicin, tiempo de adaptacin, etc.

Sistemas Operativos. Diferencias entre estructura monoltica y microkernel Sistemas monolticos. El sistema operativo funciona como un nico programa cargado en memoria. Esto implica un gran acoplamiento entre sus mdulos. La estructura monoltica tiene como ventajas la robustez del sistema ya que est hecho a medida y la velocidad de ejecucin. Como inconvenientes tiene la falta de flexibilidad, ausencia de controles de proteccin y privilegio al acceder a rutinas que manejan distintos recursos. Para pasar de modo usuario a modo kernel se ejecutan los llamados TRAPS. UNIX adopta esta estructura, sin embargo versiones posteriores y los sistemas Linux implementan una estructura monoltica modular ms flexible y manejable. Sistemas microkernel. Tambin llamados Cliente/Servidor. Estn basados en un kernel que implementa las funcionalidades mnimas y fundamentales de un Sistema Operativo. Las dems funcionalidades como sistema de archivos, entrada salida, etc. se implementan por separado como procesos servidores. El kernel se encarga de comunicar los procesos entre ellos. Los procesos clientes y servidores se ejecutan en modo usuario, mientras que el microkernel lo hace en modo protegido. Sus principales ventajas son la flexibilidad, pudiendo cambiar y elegir los procesos servidores, bajo acoplamiento, microkernel ligero y seguridad. Sistemas Operativos. Memoria virtual. Paginacin por demanda Tradicionalmente, para ejecutar un programa en memoria principal (RAM), ste deba cargarse ntegramente en memoria. Esto no es viable en sistemas multiprogramados y programas cuyo tamao es superior al de la memoria real. La paginacin es la tcnica que divide los programas en bloques indivisibles de memoria llamados pginas, generalmente del tamao de bloque de disco para optimizar las operaciones de lectura y escritura. A su vez, la memoria se divide en bloques de idntico tamao llamados marcos. Algunos sistemas, para optimizar ms el uso de la paginacin, reservan reas de memoria diferentes paginadas con tamaos de marco distintos, eso s, cada rea de memoria respeta el mismo tamao de marco entre si. De cualquier manera, con la paginacin se evita la fragmentacin externa, ya que las pginas siempre caben en los marcos de memoria. Sin embargo no se puede evitar la fragmentacin interna en la ltima pgina que puede ocupar menos de una pgina. La paginacin maneja dos tipos de direcciones: las direcciones fsicas del marco correspondiente de la memoria real y las direcciones lgicas o virtuales de la memoria virtual. Una direccin virtual estar formada por la direccin de pgina ms el offset o desplazamiento que ocupa la misma. El Gestor de memoria del Sistema Operativo se encarga de manejar estas pginas haciendo uso de : Una tabla de pginas en que se divide un programa Una tabla de correspondencia de direcciones de pgina con direcciones de marcos en memoria Una tabla de pginas cargadas en memoria con los marcos libres y ocupados La paginacin por demanda se ayuda de un espacio de 'memoria virtual' establecido sobre memoria secundaria. En sistemas como Linux el rea de Swap o intercambio se reserva explcitamente al instalar el sistema. La paginacin por demanda provoca fallos de pgina cuando la CPU va a buscar la pgina en la memoria y no se encuentra cargada. Cuando se produce un fallo de pgina, sta se carga en memoria principal utilizando para ello una poltica de reemplazo de pginas (FRU, LRU, FNU, LNU o FIFO). Para facilitar esta tarea, en la tabla de pginas cargadas en memoria se guarda informacin sobre si ha sido recientemente usada o si ha sido modificada. Tambin se da en este sistema el principio de localidad, que dice que las pginas ms recientemente utilizadas deben ser las ltimas en sustituirse porque tienen un alto ndice de ser utilizadas de

nuevo. Algunos sistemas como Windows, aprovechan ste fenmeno y realizan carga anticipada de pginas para evitar el trasiego de swapping constante. Actualmente, Linux y Windows manejas paginacin pura con direccionamiento mltiple.

Sistemas Operativos. Memoria virtual. Segmentacin Tradicionalmente, para ejecutar un programa en memoria principal (RAM), ste deba cargarse ntegramente en memoria. Esto no es viable en sistemas multiprogramados y programas cuyo tamao es superior al de la memoria real. La paginacin fu la primera tcnica en solucionar este problema. Un intento de evitar la fragmentacin interna de la paginacin y el trasiego de swapping provocado por los fallos de pgina fu la segmentacin. La segmentacin es la tcnica que propone cargar los programas en memoria divididos en segmentos de tamao variable. La segmentacin evita los fallos de pgina, puesto que el programa completo o subprogramas se corresponden con un segmento que est cargado en memoria real. El gestor de memoria asigna dinmicamente porciones de memoria de igual tamao que un segmento. Esta tcnica provoca fragmentacin externa, ya que no siempre es posible localizar un segmento lo suficientemente grande en memoria de posiciones contiguas libres. Esto hace necesario recompactar la memoria cada cierto tiempo. Posteriormente, para evitar fragmentacin externa, se combin la segmentacin de los programas con paginacin dentro de cada segmento. A su vez, la memoria reserva marcos del tamao de las pginas permitiendo que todas las pginas de un segmento encuentren huecos de memoria adyacentes o no. Sin embargo, esto no evita la fragmentacin interna que tenemos en la ltima pgina de cada segmento. El Gestor de memoria del Sistema Operativo se encarga de manejar estos segmentos haciendo uso de : Una tabla de segmentos en que se divide un programa (cada segmento puede corresponderse con un subprograma) Una tabla de correspondencia de segmentos con su direccin en memoria principal y tamao Actualmente, UNIX usa segmentacin paginada. Sistemas Operativos. Planificacin de procesos Los procesos, tambin llamados programas en ejecucin, es la forma que el SO tiene para realizar varias tareas concurrentemente. A su vez, los subprocesos es la forma que tienen los procesos de dividir sus tareas en subtareas que pueden realizarse en paralelo. Todos los procesos necesitan ejecutarse en la CPU para cumplir su cometido. Esto requiere una planificacin por parte del SO. La planificacin se realiza principalmente a dos niveles: La seleccin de un proceso para pasar a estado 'preparado' la realiza el Scheduler, tambin llamado planificador a largo plazo. Por otro lado, el paso de un proceso de estado 'preparado' a estado 'en ejecucin' la realiza el Dispatcher, tambin llamdo planificador a corto plazo. Por ejemplo en sistemas Windows, el dispatcher planifica slo los hilos o subprocesos, mientras que el dispatcher de Linux no distinque entre procesos y subprocesos a la hora de planificar. Los objetivos de la planificacin son los siguientes: Justicia e imparcialidad para que todos lo procesos reciban su tiempo de ejecucin Maximizar la produccin o Throughput para que la CPU est continuamente trabajando Minimizar el tiempo de respuesta o Turnaround para que el usuario o proceso tenga la sensacin de trabajo continuo Evitar el aplazamiento indefinido de los procesos y que estos puedan terminar

Sobre estos objetivos clasificamos los planificadores como apropiativos, en los que el planificador realiza su trabajo peridicamente y no apropiativos, cuando a un proceso no se le puede arrebatar la CPU. Ejemplos de los primeros, llamados preemptive, son Round Robin o el de 'menor tiempo restante', denominado SRT. Otros algoritmos, de tipo non-preemptive son FCFS o FIFO, la planificacin de 'el ms corto primero', denominado JSF, SPN o SPF, el de 'la tasa de respuesta ms alta', por polticas y multi-colas o colas de mltiples niveles. Tambin es necesario llevar un buen control de concurrencia entre procesos ya que si no podemos derivar en problemas de concurrencia como la espera circular, la no apropiacin, exclusin mutua y la condicin de ocupar y esperar que provocan deadlock.

Sistemas Operativos. Sistemas de Ficheros en UNIX/LINUX Para hacer frente al surtido nmero de sistemas de ficheros existentes, el sistema operativo implementa, en una capa por encima del sistema de ficheros el llamado Sistema de Ficheros Virtual. El VFS de LINUX y por extensin, UNIX, permite ms de 20 sistemas de ficheros diferentes. El sistema de ficheros por excelencia de estos sistemas operativos es ext2 (NOTA: Ya van por el ext 5) y su estructura es la siguiente: Comineza con un bloque de arranque, que no se usa, el bloque 0. Seguidamente, se repiten varios grupos de bloques con el siguiente contenido: 1. Superbloque: se repite en cada grupo de bloques, contiene informacin crucial sobre el sistema de archivos como: nmero de i-nodos, nmero de bloques, comienzo de listado de bloques libres... 2. Descriptores del sistema de ficheros: Tambin se repite en cada grupo de bloques, cada descriptor del sistema de ficheros contiene punteros a los mapas de bits de los i-nodos. 3. Mapa de bits de bloques, Mapa de bits de i-nodos, i-nodos, Bloques: Cada grupo de bloques contiene estos cuatro elementos correspondientes al grupo. Los i-nodos describen un archivo y dependiendo de los sistemas suelen tener entre 64 bytes en UNIX, 128 bytes en LINUX o incluso ms. En la descripcin del archivo entran campos como el tipo de archivo, el tamao, propietario, permisos, fechas de acceso y modificacin y otros campos ms especficos como el nmero de links del archivo o la tabla de direcciones con los bloques directos e indirectos. Hasta completar el tamao de un fichero, el i-nodo apuntar a 12 bloques directos (10 en el caso de UNIX), 1 bloque indirecto simple, 1 bloque indirecto doble y 1 bloque indirecto triple. Los directorios en ext2 se representan como una coleccin no ordenada de entradas de 16 bytes. Cada entrada contiene el nmero de i-nodo del archivo de 2 bytes y el nombre de archivo de 14 bytes. Tambin hay otras implementaciones con longitudes variables donde adms se especifica el tipo de archivo, tamao y longitud del nombre. Tecnologa de Computadores. Sistemas Multiprocesador La taxonoma de Flynn es una clasificacin de computadores en funcin del nmero de buses de instruccin que procesan y el nmero de buses de datos que manejan: SISD: Single Data, Single Instruction (Arquitectura Von Newman) MISD: Simple Data, Multiple Instruction (Arquitecturas sitlicas o desacopladas) SIMD: Multiple Data, Simple Instructin (Sistemas vectoriales. Las instrucciones de INTEL SSE lo utilizan. SSE son las siglas de SIMD Single Extensin) MIMD: Mltilpe Data, Mltiple Instruction Sobre ste ltimo modelo se sustentan los sistemas de memoria compartida o sistemas de multiprocesamiento simtrico (MMC y SMP) y los sistemas de memoria distribuida o sistemas de multiprocesamiento paralelo (MMD y MMP). Adems existe una tercera combinacin de ambos que son los sistemas con memoria compartida y distribuida (SDM) Los sistemas de memoria compartida se clasifican segn sea el acceso a memoria principal en UMA (Acceso a Memoria Uniforme) y NUMA (Acceso No Uniforme a Memoria). En los primeros, UMA, todos los procesos acceden a memoria de forma uniforme pudiendo utilizar memoria cache cada procesador. Estos, Sistemas de Memoria Compartida con acceso Uniforme a Memoria son el modelo de arquitectura de los microprocesadores multincleo actuales con caches de nivel 1 y nivel 2. Hay que matizar que el acceso es realizado sobre el mismo bus de comunicaciones por lo que para ms de 10 CPUs, el sistema puede llegar a saturarse. Para evitar esto, las arquitecturas NUMA reservan parcelas de memoria para cada CPU (o grupos de CPUs llamados NODOS) y adems se utilizan diferentes buses de alta velocidad. A NUMA se le puede aadir memorias caches de nivel 3 para cada nodo (es decir, que se comparten entre varias CPUs) pasando a denominarse esta arquitectura Cached Coherent NUMA o ccNUMA. Adems, dentro de NUMA hay un modelo llamado COMA (Cache Only Memory Access). Los sistemas de memoria distribuida se suelen utilizar en aplicaciones cluster y sistemas gridcomputing. Los sistemas cluster son una serie de pcs, estaciones de trabajo, multiprocesadores... llamados nodos heterogneos, interconexionados en una red de altas prestaciones y un SSI de Cluster (Single System Image) que coordina el cluster. El SSI puede ser HW o SW y ofrece al usuario una visin unificada de todos los recursos del sistema. Un SSI se puede implementar a tres niveles: nivel Kernel, a travs del SO, nivel SW de planificacin y nivel HW o balanceo de carga, ste ltimo es el ms utilizado en las granjas de servidores. Actualmente, los cluster ms destacados son los sistemas Blade de Sun.

Tecnologa de Computadores. Sistemas Multicomputador Son un tipo especial de sistemas con mltiples procesadores. Se llaman sistemas escalables ya que pueden aumentar sus recursos para alcanzar un alto grado de computacin en conjunto. Sus principales caractersticas son: Memoria privada para cada procesador Los procesadores se comunican mediante la red de comunicaciones Cada nodo del sistema es una mquina independiente que tiene autonoma propia

Los grandes sistemas multicomputador son el clustering y el grid computing. Las principales caractersticas del clustering son: 1. Los nodos son mquinas dedicadas, conectadas normalmente en una LAN, que realizan una tarea como si de una nica mquina se tratase. 2. Uniformes en cuanto a su arquitectura lgico-fsica para cada nodo 3. Balanceo de carga 4. Procesamiento paralelo 5. Tolerancia a fallos 6. Estn gobernadas por un administrador comn que se encarga de repartir la carga y de mostrar al usuario la visin unificada de los recursos del sistema. Este administrador, llamado SSI (Single System Image) puede ser implementado por Hardware, Software o desde el kernel del Sistema Operativo. 7. Usadas para servidores de aplicaciones y bases de datos. Los sistemas grig-computing se caracterizan por: 1. Los nodos son mquinas independientes, repartidas geogrficamente, que se comunican para lograr una tarea comn. 2. Heterogeneidad en cuanto a su arquitectura lgico-fsica para cada nodo 3. Uso de ciclos de computacin no usados por los nodos, para el procesamiento comn u objetivo. 4. Requiere de un software instalado en el sistema, que se encarga de las tareas comunes de grid computing. 5. Usados para resolver grandes problemas de computacin

Tecnologa de Computadores. Pipeling El pipeling o segmentacin de instrucciones es un tcnica que permite simular el paralelismo de instrucciones ejecutadas por la CPU. Para realizar esto, se ayuda de una caracterstica de las instrucciones. stas estan formadas por fases independientes que realizan funciones diferenciadas y atmicas. Una instruccin se puede dividir en, al menos 5 de estas microinstrucciones, que son: 1. 2. 3. 4. 5. Lectura de instruccin Decodificacin de la instruccin Generacin de la direccin Ejecucin de la instruccin Obtencin del resultado

Una ejecucin secuencia de 4 instrucciones requieren 20 ciclos de reloj, en cualquier caso, para ejecutar todas las fases de cada una de las 4 instrucciones. Con pipeling, solapamos las microinstrucciones de manera que el resultado de la ejecucin es de 8 ciclos de reloj en el mejor de los casos. Las ventajas son el incremento del throughput de las instrucciones y la velocidad de ejecucin de todas las instrucciones. El inconveniente que tiene pipeling es que requiere la organizacin de las microinstrucciones y que se puede dar el caso de que varias instrucciones compartan variables. Esto puede provocar inconsistencia de datos.

Base de datos. Modelo relacional El modelo relacional es uno de los modelos de representacin de datos ms extendidos. A partir de los aos 60, las bases de datos se expandieron gracias a los modelos de red (basados en grafos) y el modelo jerrquico (basado en rboles). En 1975, Codd enunci el modelo relacional que poco a poco a desbancado a sus antecesores. Es un modelo matemtico est basado en la teora de conjuntos y el lgebra relacional. Se fundamenta en dos conceptos principales: Esquemas relacionales y reglas de integridad. Esquemas relacionales o intensin de relacin. Define una relacin como un conjunto de atributos. Para ello crea los conceptos de dominio (conjunto de valores homogneos que puede tomar un atributo con existencia propia), grado (nmero de atributos de una relacin) y cardinalidad (nmero de tuplas recuperables de una relacin). El segundo concepto son las reglas de integridad. Integridad de entidad (basada en el concepto de clave primaria, bsicamente enuncia que una clave privada identifica de modo nico las tuplas y no puede ser nula) e Integridad referencial (basada en el concepto de clave fornea, que dice que una clave fornea hace referencia a otra entidad mediante un atributo con un valor de dominio perteneciente en la entidad referenciada o un valor nulo) El modelo relacional puede ser manipulado a travs de dos lenguajes: lgebra relacional y Clculo relacional lgebra relacional: Basado en la teora de conjuntos. Es un lenguaje procedural, es decir, que indica al sistema cmo manipular los datos. Sus operadores fundamentales son seleccin, proyeccin, unin, diferencia y producto cartesiano. Clculo relacional: Basado en la lgica de predicados. Es un lenguaje no procedural del que surge entre otros SQL. Sus operadores fundamentales son existe, para todo, and, or y not. Base de datos. Drivers de conectividad Para comunicar aplicaciones con diferentes bases de datos y as, hacerlas ms portables se utilizan los drivers de conectividad. Los ms utilizados son ODBC y JDBC (Las aplicaciones .NET utilizan ADO.NET que est integrado en el framework de .NET) ODBC (Open Database Connectivity): Es un estndar abierto cuyas caractersticas ms ventajosas son que es independiente del lenguaje y de la base de datos a utilizar. Est basado en el estndar CLI (Call Level Interface) de X/Open, hoy en da Open Group. Como desventajas podemos citar que, al ser tan independiente, no consigue aprovechar al 100% los motores de bases de datos y lenguajes de programacin. Adems el uso de ODBC requiere de una capa ms tipo Middleware de comunicacin entre la base de datos y la aplicacin, el administrador de drivers ODBC que suele estar integrado en el propio sistema operativo. Los componentes implicados en esta tecnologa son la propia aplicacin y base de datos, el gestor de DataSource, el driver ODBC y el citado administrador de drivers ODBC. JDBC (Java Database Connectivity): Es una API de Java y como tal, hace que su uso dependa del lenguaje Java. Como ventaja tenemos la velocidad de trabajo. JDBC puede trabajar en cuatro niveles diferentes: Tipo 1. Puente JDBC-ODBC. El resultado es que tras la aplicacin y su gestor de DataSource nos encontramos con un mdulo puente que traduce las instrucciones Java a ODBC. Tras este mdulo tenemos el driver ODBC que se comunicara con las Bases de datos. No hay driver JDBC aqu. Tipo 2. Driver JDBC con llamadas a la API nativa de Base de datos. El resultado es que tras la aplicacin y su gestor de DataSource nos encontramos con el driver JDBC que hace llamadas directas a la API de la Base de Datos correspondiente. El driver JDBC tiene parte escrita en Java y parte nativa de la Base de Datos correspondiente. Tipo 3. Driver puro Java que accede al Middleware. El resultado es que tras la aplicacin y su gestor de DataSource nos encontramos con el driver JDBC. Este se comunica con un mdulo middleware que se encarga de traducir las llamadas del driver en llamadas al API de la Base de Datos correspondiente. El driver JDBC es genrico para cualquier Base de datos y nativo Java. Tipo 4. Driver puro Java directo a Base de datos. El resultado es que tras la aplicacin y su gestor de DataSource nos encontramos con un driver nativo Java escrito para una base de datos concreta. El driver se comunica directamente con la Base de Datos optimizando el acceso. Necesita un driver para cada Base de Datos diferente.

Bases de datos. Normalizacin La normalizacin es un proceso que permite reducir las inconsistencias y redundancias en las relaciones de un modelo de datos. Adems facilita el mantenimiento y previene los errores en las operaciones de manipulacin de datos. En el proceso de Normalizacin Boyce Codd enunci 3 Formas Normales que deben aplicarse en orden para conseguir un modelo normalizado. Adems de estas 3 formas normales existen, opcionalmente, la Forma Normal de Boyce Codd, la cuarta forma normal y la quinta forma normal. Para entender el proceso de normalizacin hay que definir 3 conceptos: 1. Dependencia funcional. Sea una relacin R{A,B,C}, se dice que B depende funcionalmente de A o A determina funcionalmente a B (A->B) si para cada valor de A, existe un nico valor de B. 2. Dependencia funcional completa. Sea una relacin R{A,B,C}, se dice que B tiene dependencia funcional completa de A, si B depende funcionalmente de A, pero no de ningn subconjunto de A. 3. Dependencia funcional transitiva. Sea una relacin R{A,B,C}, si B depende funcionalmente de A (A->B), C depende funcionalmente de B (B->C) y A no depende funcionalmente de B, entonces, C depende funcionalmente de A (A->C) Normalizacin: 1. Primera forma normal. Una relacin est en 1FN si no existen conjuntos repetitivos y todos los atributos dependen funcionalmente de la clave. 2. Segunda forma normal. Una relacin est en 2FN si, est en 1FN, y los atributos que no pertenecen a la clave tienen dependencia funcional completa de la clave. 3. Tercera forma normal. Una relacin est en 3FN si, est en 2FN, y los atributos que no forman parte de la clave no tienen dependencia funcional transitiva de la clave. 4. Forma Normal de BoyceCodd. Una relacin est en FNBC si cada atributo determinante es clave candidata.

Bases de datos. 12 reglas de Cood Codd enuncia 12 reglas que debe cumplir todo sistema gestor de bases de datos para que se considere relacional. Al menos deben cumplirse 6: Regla 0: Un SGBDR debe ser capaz de manejar la informacin con capacidades exclusivamente relacionales Regla de la informacin Regla del acceso garantizado Regla del tratamiento de los valores nulos Regla de la independencia lgica de datos Regla de la independencia fsica de datos Regla de la actualizacin de vistas Regla de la independencia de distribucin Regla de la independencia de integridad Regla de la no subversin o la no inversin Catlogo en lnea dinmico basado en el modelo relacional Regla del sublenguaje completo de datos Regla de actualizacin, supresin e insercin de alto nivel

Bases de datos. Tcnicas de Minera de datos En la Minera de datos, a la hora de realizar la bsqueda de patrones se utilizan tcnicas basadas en algortmos de inteligencia artificial y estadstica como: 1. 2. 3. 4. 5. Redes neuronales: Conexiones de elementos de aprendizaje mediante entradas y salidas. Modelos estadsticos rboles de decisin: Representan la jerarqua de condiciones para alcanzar una respuesta Regresin lineal o reglas de induccin: Relaciones entre dos variables. Agrupamiento o clustering: Basado en vectores de distancia y el vecino ms prximo.

Estas tcnicas se clasifican, segn el objetivo, en aprendizajes supervisados (modelo predictivo y de verificacin) y no supervisados (modelo de descubrimiento) Bases de datos. Problemas de concurrencia en las transacciones Las transacciones son conjunto de rdenes que se ejecutan de forma atmica, como una unidad. Las transacciones deben cumplir las propiedades ACID (Atomicidad, Consistencia, Isolatin o Aislamiento y Durabilidad). El problema de las transacciones surge cuando stas se realizan concurrentemente en los sistemas gestores de bases de datos. Los problemas que se pueden dar en la concurrencia de transacciones son: 1. Lectura sucia. Cuando una transaccin lee datos que no han sido comprometidos. 2. Lectura no repetible. Cuando la repeticin de la misma transaccin devuelve resultados diferentes. 3. Lectura fantasma. Cuando una transaccin lee datos que antes de iniciarse la misma, no existan. Los problemas de concurrencia de transacciones se solucionan con el aislamiento de las transacciones. Los diferentes niveles de aislamientos son: 1. Transacciones no comprometidas o Lectura no comprometida. Se pueden dar los tres problemas de concurrencia mencionados. 2. Transacciones comprometidas o Lectura comprometida. Al hacer COMMIT sobre la transaccin evitamos el problema de la lectura sucia. 3. Transacciones repetibles o Lectura repetible. Soluciona el problema de la lectura sucia y de la lectura no repetible. 4. Transacciones secuenciables o serializables. Es el mayor nivel de aislamiento, soluciona los tres problemas de concurrencia. Tenemos un control total sobre el sistema transaccional mediante la reorganizacin de las operaciones indivisibles que forman parte de las transacciones concurrentes. SQL Server permite todos estos niveles, Oracle slo permite la lectura comprometida y secuenciable La serializacin de transacciones puede provocar exclusin mtua (tambin llamado interbloqueo o deadlock), por lo que la transaccin entra en un bucle de espera infinito, del que ninguna otra transaccin podr liberar. Este problema slo puede solucionarse, una vez detectado y puede dejar la base de datos inconsistente.

Bases de datos. Clasificacin de BD en las organizaciones 1. Nivel operacional o transaccional. OLTP (OnLine Transactional Processing) o TPS (Transaccional Processing System) es el nivel en que se organizan las herramientas cuyo nico objetivo es la insercin y actualizacin de la informacin diaria. Estos sistemas no estn orientados a la toma de decisiones pero sirven de apoyo y de provisin de datos a los sistemas posteriores. Son sistemas rpidos en las transacciones y lentos y poco eficientes en la interaccin con el usuario. En este nivel tambin se encuentran herramientas como CRM, ERP o SCM. 2. Nivel de conocimiento. MIS (Management Information Sistems) son sistemas que se encargan de recopilar la informacin de diferentes fuentes y generar informes para la direccin. Este nivel es gerencial medio y es un complemento a la toma de decisiones. 3. Nivel tctico. DSS (Decision Suport System) es un nivel gerencial que recopila la informacin en sistemas especializados como Bases de datos de conocimiento o Datawarehose y mediante herramientas tipo OLAP (OnLine Analitics Processing) obtienen evidencias difciles de encontrar, mediante la bsqueda de patrones. 4. Nivel estratgico. EIS (Excecutive Information System) o ESS (Executive Support System) es el nivel ms alto de la organizacin quien toma las decisiones relativas a la misma en funcin de herramientas de inteligencia artificial y sistemas expertos como cuadros de mando. Utilizan los niveles anteriores para recopilar informacin valiosa. El objetivo es obtener la visin de futuro necesaria para crecer.

Bases de datos. Sistemas Multidimensionales. Los sistemas multidimensionales son sistemas de informacin basados en dimensiones, jerarquas y series temporales. Mientras que los sistemas relacionales estn pensados para la optimizacin de los datos, consultas sobre datos concretos y operaciones de insercin o actualizacin, los sistemas multidimensionales son ideados para obtener resultados totales, sumatorios, series temporales y para navegar entre distintos niveles de granularidad (dimensiones y jerarquas). Las bases de datos multidimensionales o cubos estn formados por: Dimensiones. Colecciones de datos que guardan relacin. Podemos presentar vistas con Slice-Dice o reorganizar las dimensiones con Pivoting. No es recomendable hace ms de 10 dimensiones. Jerarquas. Sobre una dimensin, las jerarquas permiten aumentar el grado de especializacin. Las operaciones de escavacin sobre jerarqua son Drill-down y Roll-up. Series temporales. El tiempo es un factor fundamental en los sistemas multidimensionales, ya que la informacin almacenada es no volatil. El tiempo se puede implementar como una dimensin, como una jerarqua o dejar que lo adminsitre el propio sistema gestos de bases de datos.

La explotacin de sistemas multidimensionales se hace mediante herramientas tipo OLAP (OnLine Analitics Processing) Los sistemas multidimensionales pueden realizarse sobre sistemas relacionales ROLAP, sistemas hbridos HOLAP, va web WOLAP.

Bases de Datos. Definiciones. Business Intelligence: Combinacin de tcnicas de almacenamiento y tratamiento de la informacin orientadas a la toma de decisiones sobre el negocio. Business Intelligence se aprovecha de la informacin estratgica repartida en cualquier punto de la organizacin. Business Intelligence utiliza tecnologas y tcnicas como OLTP, TPS, OLAP, Sistemas de Soporte a la Decisin, Minera de datos, Bases de datos relacionales, sistemas Datawarehouse, etc.. DataWarehouse: Conjunto de datos orientados al negocio, integrados, no voltiles, dependientes del tiempo, que provienen de fuentes heterogneas cuyo objetivo es el soporte a la toma de decisiones. Sus caractersticas ms importantes son: 1. 2. 3. 4. 5. Orientados a la consulta, con carencia en las operaciones de insercin y actualizacin Construidos sobre sistemas multidimensionales optimizados a las consultas Se construyen segn las fases de extraccin, transformacin y carga Se hace necesario un buen diccionario de datos Son buenos para trabajar con datos agregados, totales, subtotales y series temporales

DataMart: Son un tipo especial de Datawarehouse orientados a componentes departamentales especficos. En ocasiones se provisionan de datos almacenados en grandes Datawarehouse. DataMining: La minera de datos es una tcnica cuyo objetivo es obtener informacin no explcita de un sistema de almacenamiento de datos mediante la bsqueda de patrones y evaluacin de sus resultados. Se realiza principalmente en tres fases: 1. Seleccin y preprocesado de datos. Se recogen los datos de fuentes heterogneas y se almacenan en base a una estructura definida. No es necesaria si contamos con un sistema Datawarehouse. 2. Bsqueda de patrones. Mediante tcnicas basadas en la estadstica, inteligencia artificial, procesamiento OLAP, se interroga al sistema para extraer informacin til. 3. Interpretacin y Evaluacin de los resultados. Estudio de los resultados y traduccin en informacin til para el negocio. Indices Bitmap: ndices utilizados mayormente en sistemas multidimensionales para acelerar las consultas. Se definen sobre atributos cuyo dominio es muy pequeo. Hipercubos: Sistema multidimensional de ms de 3 dimensiones. Estructura de datos. Complejidades de los algoritmos Mayor complejidad O(n) -> Algoritmos de ordenacin clsicos de intercambio, seleccin e insercin Complejidad O(n*log(n)) -> Algoritmos de ordenacin Mergesort y Quicksort (divide y vencers) Complejidad media O(n) -> Algoritmos de bsqueda secuencial y rboles binarios Complejidad O(log(n)) -> Algoritmos de bsqueda binaria (divide y vencers) y rboles binarios de bsqueda Mejor complejidad O(log (log (n))) -> Algoritmos de bsqueda por interpolacin Estructura de datos. Organizacin de ficheros Un fichero est formado por una serie de registros que contienen informacin. Segn como estn organizados estos registros tenemos organizacin secuencial, directa e indexada. Organizacin secuencial: La secuencia fsica de los registros coincide con la secuencia lgica. Para acceder a un registro hay que pasar por los anteriores. Optimiza la lectura del fichero completo, y el aprovechamiento de memoria del fichero. Es ineficiente a la hora de buscar un registro concreto y de modificar el fichero (borrar e insertar registros) Organizacin directa: Podemos acceder directamente a un registro. Mediante claves, o hashing. El uso de claves hace que la secuencia fsica de los registros sea igual a la secuencia lgica. El uso de hashing requiere de un algoritmo de transformacin de clave y hace que la secuencia fsica de los registros no sea igual a la secuencia lgica. Optimiza las modificaciones del fichero y la bsqueda de un registro concreto. Penaliza la lectura completa del mismo y el aprovechamiento de memoria del fichero. Justo al revs que la organizacin secuencial. Organizacin indexada: Es una variante de la organizacin secuencial que aprovecha lo mejor de las organizaciones anteriores. La secuencia fsica de los registros no coincide con la secuencia lgica. Hay dos variantes:

ISAM (Mtodo de acceso secuencial indexado): Existe una tabla de ndices con la secuencia de registros y la clave de registro. C-ISAM (Mtodo de acceso secuencial indexado encadenado) : Es igual que el secuencial puro, aadiendo a cada registro un puntero sealando el siguiente registro y un puntero sealando el registro anterior.

Software Libre. Libertades del Software Son 4: Libertad 1. La libertad de usar el programa, con cualquier propsito Libertad 2. La libertad de estudiar cmo funciona el programa, y adaptarlo a sus necesidades. Libertad 3. Distribuir copias Libertad 4. La libertad de mejorar el programa y hacer pblicas las mejoras a los dems. Software Libre. Licencias libres Debemos distinguir entre software libre (FSF, Free Software Foundation y GPL, General Public License) y software de cdigo abierto (OSI, Open Software Iniciative, BSD o Apache License). Copyleft en contraposicin con las licencias propietarias aseguran las cuatro libertades mientras protege la reputacin del autor. Hay dos tipos de Copyleft: Copyleft robusto o licencias persistentes (GPL y LGPL). Sus caractersticas son: - Distribucin de las fuentes durante 3 aos - Cobro slo por los gastos de distribucin - Avisar de los cambios a los destinatarios (no siendo necesario avisar a los autores originales) - Acompaar las obras de autoria y licencia - Exenccin de garantas y responsabililidades (se pueden ofrecer a cambio de un cobro) - Aceptacin de la licencia slo si se quiere modificar el SW Copyleft no robusto o licencia no persistente (BSD 1.1). Sus caractersticas son: - Mencionar al autor en obras derivadas si no se modifica el cdigo - No es necesario proveer fuentes - Exenccin de garantas y responsabililidades (se pueden ofrecer a cambio de un cobro) - Permite mezclar con SW propietario Licencias sin Copyleft (BSD 1.0, Apache, MPL Mozilla Public License, NPL Netscape Public License) Licencia recomendada en el esquema nacional de interoperabilidad EUPL (European Union Public License), con copyleft robusto. Sus caractersticas son: - Cesin de los derechos morales y patrimoniales siempre que la ley lo permita. - Poner a disposicin de manera indeterminada, fcil y gratuita las fuentes y la licencia (Incluir la licencia en un archivo LICENSE o COPYING) - Reconocimiento del autor - Compatibilidad con licencias GPL2, OSL, CPL, EPL y Cecill (en estos casos prevalecer la licencia compatible) - Exenccin de garantas y responsabililidades (se pueden ofrecer a cambio de un cobro) - Aceptacin de manera inequvoca de la licencia (pinchando Aceptar o de alguna manera similar) Software Libre. Proteccin de los programas de ordenador Segn la ley refundida 1/1996, Libro 1, Ttulo 7 un programa de ordenador es una secuencia de instrucciones destinada a ser utilizadas, directa o indirectamente, en un sistema informtico para realizar una tarea. Tambin entra en esta definicin la documentacin preparatoria (documentacin tcnica y manuales) y un programa objeto. Sern protegidos, si son originales, los programas de ordenador y las versiones sucesivas o programas derivados, salvo que sean destinadas a provocar efectos nocivos. La ley no proteger las ideas y principios. Al hablar de derechos de autor podemos distinguir entre derechos morales y derechos patrimoniales. Los derechos morales son irrenunciables, inalienables, no pueden ser cedidos y tienen, en general, carcter perpetuo. Estos derechos son el reconocimiento del autor, la divulgacin y la integridad de la obra. Los derechos patrimoniales son los relativos a la reproduccin, distribucin y transformacin. Las obras se clasifican en obras colectivas (donde el autor es el que la edita y publica), obras unitarias o en colaboracin (todos los participantes son autores) y obras creadas por trabajador asalariado (en las que los derechos patrimoniales son del empresario).

La duracin de los derechos de autor es de toda la vida y 70 aos tras la muerte del autor (para personas fsicas) o 70 aos desde la publicacin (para personas jurdicas). Siempre a contar desde el 1 de enero del ao siguiente. Los derechos de explotacin de un programa de ordenador son, EL TITULAR PODR REALIZAR O AUTORIZAR: La reproduccin, total o parcial, incluso para uso personal La traduccin, adaptacin, arreglo y cualquier transformacin del programa Cualquier forma de distribucin pblica

Los lmites de los derechos de explotacin son NO ES NECESARIA LA AUTORIZACIN DEL TITULAR AL USUARIO PARA: Copia privada (slo se permite una) Estudiar, observar o verificar su funcionamiento con objeto de determinar las ideas y principios en que se basa Reproduccin y transformacin cuando dicho cambio sea necesario para la utilizacin del mismo u obtener interoperabilidad, salvo disposicin contractual en contrario Realizar versiones sucesivas, salvo pacto en contrario Reproduccin del cdigo o traduccin del programa cuando sea necesario para alcanzar su interoperabilidad con otros sistemas

Software Libre. DRM (Digital Rights Management) Los sistemas DRM (Digital Right Management) son la agrupacin de tecnologas, procesos y herramientas destinados a proteger la propiedad intelectual en las operaciones comerciales realizadas con contenidos digitales. Permiten la distribucin controlada de contenidos y evitan el uso fraudulento del mismo. Ciclo de vida: 1. Empaquetado (realizado por los autores). Los autores deciden los derechos y condiciones de la obra o contenido. 2. Proteccin y venta (realizado por los proveedores). Los proveedores empaquetan el contenido con tcnicas que restringen el consumo del producto. 3. Consumo (realizado por el usuario). Los usuarios adquieren la licencia de uso y realizan el consumo controlado. Hay dos modelos, el modelo Servidor y el modelo Cliente/Servidor. En el modelo Cliente/Servidor el agente DRM se instala en el cliente y utiliza tcnicas criptogrficas para recuperar y transferir el contenido digital del servidor. ste empaqueta los contenidos con sus licencias y restricciones correspondientes. En el modelo Servidor se usan marcas de agua en los contenidos y firmas digitales que son reproducidas al mismo tiempo que el contenido. El lenguaje de expresin de contenidos ms utilizado es XrML (eXtensible Rights Markup Language). XrML pertenece a la compaia ContentGuard y ha sido estandarizado por la ISO como MPEG REL (MPEG Right Expresion Language). Este lenguaje estructura los elementos en Principal, Right, Resource y Condition. MPEG REL es usado, entre otros, con MPEG 21 y Windows Media Player. Otros lenguajes REL (Right Expresion Language) son: ODRL (Usada por la Open Movile Alliance). ODRL estructura los elementos en Asset, Rights y Parties. XMCL (que usa Real Player) ccREL (Creative Commons Right Expresion Language). Para proteger contenidos bajo licencia Creative Commons.

Ejemplos de uso de DRM son los sistemas anticopia de algunos discos de msica, la proteccin de la msica adquirida con iTunes, las copias digitales de pelculas y el alquiler de pelculas bajo demanda, los libros que se consumen en eBooks.

Estudio de viabilidad de sistemas. Decisin Multicriterio Discreta La Decisin Multicriterio Discreta es un mtodo de seleccin de alternativas multicriterio que sustituye al tradicional mtodo de Anlisis de Coste Beneficio. El mtodo multicriterio aporta la posibilidad de valorar mltiples caractersticas distintas entre las diferentes alternativas al mismo tiempo. En la Administracin pblica, la antigua CIABSI patrocina la herramienta SSD-AAPP para realizar la decisin multicriterio discreta. La DMD consta de 5 fases secuenciales: 1. Identificacin de alternativas de seleccin y criterios a valorar. 2. Asignacin de pesos a los criterios. 3. Puntuacin de los criterios para cada alternativa. Ajustando por abajo con niveles de satisfaccin y por arriba con el umbral de saciedad. 4. Normalizacin de las puntuaciones. A travs de los mtodos de la fraccin del ideal, fraccin del mximo y fraccin de la suma. Tras finalizar la fase obtenemos la Matriz de Decisin. 5. Decisin entre alternativas. Utilizando la Matriz de Decisin obtenida en la fase anterior. En la fase de asignacin de pesos se utilizan los mtodos de asignacin directa como Delphi o mtodos de asignacin indirecta donde encontramos los basados en comparaciones binarias de criterios como son el mtodo de las utilidades relativas, en el que se comparan grupos de criterios y el mtodo SAATY tambin llamado mtodo AHP donde se comparan criterios uno a uno utilizando para ello una escala verbal de 1 a 9. Otro mtodo de asignacin indirecta es el mtodo de la entropa que complementa a los anteriores mencionados y que se realiza a posteriori de la normalizacin por la fraccin de la suma. En la fase de decisin entre alternativas se puede utilizar el Mtodo lexicogrfico, de poco valor, ya que se basa en elegir la alternativa cuyo criterio de mayor peso ha obtenido mejor puntuacin, los mtodos basados en relaciones de superacin como ELECTRE o PROMETHEE. Tambin tenemos mtodos de ponderacin lineal y utilidad multiatributo ms fciles de usar y que exigen una buena precisin a la hora de valorar los criterios. Los mtodos de ponderacin lineal favorecen a las medianas ya que se produce como el sumatorio de las puntuaciones por el valor de su criterio. Por ltimo, el mtodo de decisin entre alternativas TOPSIS se basa en la distancia ms corta de la solucin ideal y ms lejos de la solucin negativa. Anlisis de requisitos. Caractersticas de los requisitos Un requisito debe ser: Completo: Debe expresarse en su totalidad y por s mismo Medible, Probable, Verificable: Que se puede probar Correcto: Lo contrario sera un absurdo No ambiguo: Evitando trminos del tipo mucho, poco... De bajo riesgo: Que se puede implementar con xito Clasificable: Se puede categorizar y clasificar Consistente: No entra en conflictos con otros requisitos Sencillo, Conciso, Comprensible: Que se entiende Trazable, Referenciable: Puede ir de delante hacia atrs y viceversa

Anlisis de requisitos. Modelo SWEBOK o Fases de establecimiento de requisitos SW El anlisis de requisitos es una parte de la ingeniera del software cuyo objetivo es elaborar un catlogo de requisitos validados por los usuarios, que sern la base del software a elaborar. Tradicionalmente el anlisis de requisitos se puede ver como un ciclo de vida iterativo con cuatro fases secuenciales principales (tambin llamado Modelo Swebok): 1. Educcin de los requisitos (Reuniones, entrevistas o sesiones de trabajo, anlisis factores crticos de xito) 2. Anlisis y negociacin (Diagramas E/R, Casos de Uso, DFD's, Diagramas de estado) 3. Documentacin de requisitos 4. Validacin de los requisitos (vuelta a la fase 3) En cada fase se realizan una serie de prcticas y tcnicas, y se obtienen diferentes productos. En la educcin de requisitos, mediante una serie de reuniones, entrevistas o sesiones de trabajo entre usuarios, clientes, consultores y equipo de desarrollo se deber elaborar un catlogo de requisitos funcionales y no funcionales. En la fase de anlisis y negociacin se deber refinar el catlogo anterior mediante nuevas sesiones

de trabajo y tcnicas de modelado o diagramas. Se indexan los requisitos, se clasifican y se verifica su interaccin con los dems requisitos. Adems, en la negociacin se deber buscar un equilibrio entre lo que el cliente pida y lo que el cliente necesite. Posteriormente, se realiza la documentacin de los requisitos elaborando el documento Especificacin de Requisitos del Sistema, basado en la norma IEEE 830:1993. Este documento formal puede contener otros como la Diseo Funcional del Sistema o el Documento de Requisitos de Usuario. Finalmente, la validacin de los requisitos ser la fase que permita al usuario confirmar sus requisitos inciales con los modelos, rectificar, cambiar o eliminar requisitos. Esto hace que volvamos a la fase inicial para mejorar el documento de especificacin de requisitos. Estas iteraciones realizadas en distintas fases del ciclo de vida del desarrollo permiten consolidar los requisitos y realizar un documento ERS consistente y robusto.

Anlisis estructurado. Modelo conceptual de procesos El modelo conceptual de procesos (o modelo esencial) en el anlisis estructurado lo podemos dividir en el Modelo ambiental y el Modelo de comportamiento. Modelo ambiental: Est formado por el Diagrama de Contexto, el Diccionario de datos y la Lista de Eventos. Comenzamos con la declaracin de propsitos que, en unas lneas, describe los objetivos del sistema. El Diagrama de Contexto pretende modelizar el universo del sistema y est formado por las entidades externas, los flujos de entrada y salida y por el proceso principal del sistema. Con el Diccionario de Datos describimos los flujos de procesos y los datos de los almacenes. Pero ser en el modelo de comportamiento cuando se complete el DD. Por ltimo, en el Modelo Ambiental tenemos un listado de eventos que se producen en el entorno (no en el sistema a modelar) y a los cuales debe responder el sistema. Los eventos que podemos describir sern eventos de flujos de datos, eventos de control y eventos temporales. Modelo de comportamiento o modelo de procesos: Est formado por el DFD (incluyendo el modelo de subsistemas) y la especificacin de pocesos primitivos. Para realizar el Diagrama de Flujo de Datos lo primero que haremos ser identificar los Subsistemas y su relacin con las entidades descritas en el Diagrama de Contexto. El diagrama de subsistemas compondr el nivel 1 de un DFD y cada subsistema deber realizar funciones definidas e independientes. Para identificar los subsistemas utilizaremos las tcnicas Matriciales elaborando una matriz de Procesos-Entidad. Esta Matriz relaciona cada proceso con las entidades, en las operaciones de creacin y utilizacin de datos. Despus reorganizamos la matriz de tal forma que podamos extraer los subsistemas independientes. Con los subsistemas definidos iremos explotando los mismos para crear los diferentes niveles del DFD. Por ltimo en los niveles del DFD donde no sea posible ms explotacin, se definen los procesos primitivos para los que se pueden emplear lenguajes de pseudocdigo o descripciones no formales. Anlisis estructurado. Diccionario de datos Es un conjunto de METADATOS que describen los almacenes de datos, flujos de datos, valores o detalles en las relaciones entre entidades de un sistema. Se utiliza en las fases de anlisis y diseo para describir el modelo conceptual de datos. A nivel de arquitectura, el DD almacena los esquemas y las reglas de correspondencia entre un esquema y otro (Esquema externo, conceptual e interno o fsico). A nivel conceptual, con el diccionario de datos podemos describir flujos de datos, procesos y contenido de los almacenes de datos. Es importante que la descripcin sea suficiente y no ambigua. Suele acompaarse en diagramas de flujos de datos (DFD) y diagramas entidad/relacin. Esta prctica es imprescindible en desarrollos Datawarehouse. La definicin debe incluir: El significado del dato en el contexto de la aplicacin. Esto se documenta en forma de comentario. La composicin del dato, si es que est compuesto de otros elementos significativos. Los valores que el dato puede tomar, si se trata de un dato elemental que ya no puede ser descompuesto.

Anlisis estructurado. Reglas de consistencia de los DFD Las reglas de consistencia de los DFD son tres: 1. No deben faltar flujos de entrada ni de salida en un diagrama resultado de una explosin que correspondan a entradas o salidas de un diagrama de nivel superior. 2. No deben sobrar flujos de entrada ni de salida en un diagrama resultado de una explosin que NO APAREZCAN EN EL nivel superior. 3. Todos los elementos del diagrama de flujo de datos estarn conectados directa o indirectamente con los flujos del proceso origen y diagrama de contexto. Adems segn Yourdon: 1. Evitar los llamados agujeros negros o procesos con flujos slo de entrada. 2. Evitar procesos de generacin espontnea o procesos con slo flujos de salida (slo justificado en el caso de generador de nmeros aleatorios). 3. Justificar bien la presencia de almacenes de slo lectura o slo escritura.

Diseo estructurado. Propiedades del diseo estructurado Modularidad (Atomicidad): El sistema a desarrollar se podr separar en mdulos independientes y con diferente jerarqua hasta conseguir mdulos indivisibles o atmicos que realicen una operacin concreta. Esto facilita el mantenimiento, minimiza la duplicidad de cdigo y favorece la comprensin. Jerarqua entre mdulos: Los mdulos se organizan siguiendo una jerarqua de forma que los mdulos superiores coordinen a los inferiores. Esto permite controlar la interaccin entre mdulos. Independencia modular: Los mdulos debern ser diseados de forma cumplan una funcin bien definida y que no dependan de otros en la medida de lo posible. De forma que podemos garantizar la reutilizacin de los mdulos. Modelizacin conceptual: La descomposicin modular debe atender a criterios que reflejen conceptualmente el problema de la organizacin. No debemos descomponer sin criterios conceptuales por el hecho de descomponer. Principio de caja negra: Los mdulos ocultarn su implementacin y los detalles de la misma. De esta forma, los trataremos como una caja negra de la que slo conocemos las entradas y salidas. Esto favorece la abstraccin y el mantenimiento. Diseo estructurado. Tipos de cohesin La cohesin es el grado de relacin de los elementos de un mdulo. Los tipos son: Funcional: Todos los elementos del mdulo cumplen una nica funcin Secuencial: El modulo es una secuencia de mdulos con cohesin funcional. De comunicacin: Los elementos utilizan los mimos datos de entrada y salida. Procedimiental: Los elementos estn relacionados siguiendo un orden determinado. Temporal: Todos los elementos se realizan en el mismo intervalo de tiempo. Lgica: Existe una relacin lgica entre los mdulos. Casual: Los elementos realizan funciones que no tienen nada que ver entre s. Diseo estructurado. Patrones arquitectnicos Un sistema completo puede mezclar diferentes tipos de arquitectura. Segn Pressman, los ms comunes son: Arquitectura centrada en los datos: Donde todo gira en torno a un almacn de datos. Por ejemplo sistemas Datawarehouse Arquitectura de flujos de datos: Los datos se transforman al pasar de unos componentes a otros. Arquitectura de llamada y retorno: Aquellos programas en que el sistema principal realiza llamadas a subsistemas. Aplicaciones escritorio y webs Arquitectura de componentes principales: Comunicacin entre mensajes. Arquitectura orientada a objetos: Los elementos del sistema son objetos que encapsulan propiedades y operaciones. Arquitecturas de tiempo real: Cuando las necesidades del sistema son crticas.

Documtica. Sistemas de Gestin Documental, Sistemas de Gestin de Contenidos y Portales de Contenidos Un portal de contenidos es un sistema integrado que combina la gestin de usuarios y la gestin de contenidos. El portal mantendr una continua relacin con los sistemas ERP, CRM y los dispositivos de almacenamiento de la organizacin. Un Sistema de Gestin Documental es un sistema que facilita la gestin de documentos entendida como un proceso de captura, indexacin, distribucin y archivado. La captura comprende la digitalizacin de contenidos, es decir el escaneado de imgenes o de documentos haciendo uso de OCR. Tambin se puede entender la captura como la importacin de documentos al sistema y su posterior transformacin a un formato que preserve su contenido, como PDF o TIFF. El proceso de indexacin puede realizarse en tres niveles: a nivel de texto completo del documento, aadiendo palabras clave de bsqueda o indexando la estructura del documento. Este proceso ser clave para su posterior recuperacin empleando sistemas de recuperacin y bsqueda. La publicacin de documentos se encarga de que stos estn disponibles en la organizacin garantizando un cierto nivel de seguridad en cuando a su acceso, por ejemplo con niveles de privilegio. El archivado de documentos deber realizarse en medios y con formatos que preserven su disponibilidad con el paso del tiempo, garanticen su integridad y autenticidad. Se recomienda el uso de estndares abiertos y compatibles. Recuperacin de contenidos mediante sistemas de bsqueda.

Un Sistema de Gestin de Contenidos es un sistema que ampla las funcionalidades de gestin de contenidos con capacidades como: Acceso on-line va web a los servicios Edicin de contenidos (nuevos contenidos y modificaciones) Control y gestin de versiones Incorporacin de metadatos Catalogacin de los contenidos Publicacin mediante sindicacin de contenidos, XML o WebServices. Gestin de procesos mediante workflow Relaciones entre documentos y contenidos del sistema Personalizacin de perfiles de usuarios

Ejemplos de CMS populares son Vignette, Microsoft Sharepoint y Coldfusin como sistemas privativos y Alfresco, Liferay, Nuxeo, Drupal, Joomla, OpenCMS como sistemas de fuentes abiertas. Hacen uso de tecnologas como la especificacin JSR-168 (portlets de Java), SMB/CIFS (protocolos de comparticin de ficheros en red) o WebDav (presentacin y edicin de documentos via web) entre otros. Documtica. Web Semntica La web semntica, o como algunos autores denominan, la web 2.0, es un modelo de internet en el que los contenidos estn relacionados siguiendo una taxonoma basada en el significado de las palabras. En la web semntica, los contenidos de las pginas web se relacionan a travs de metadatos. Estos metadatos siguen reglas ontolgicas que permiten a los buscadores entender el objetivo de la bsqueda y se traducira en una recuperacin ptima de resultados, reduciendo el nivel de ruido an ms. Esto se llevara a cabo a travs de los llamados agentes inteligentes, programas que buscan informacin sin la intervencin humana. Los lenguajes que se usan en la web semntica basados en XML son: RDF: Resource Description Framework. Proporciona informacin descriptiva sobre los recursos que se encuentran en la Web. OIL: Ontology Inference Language. Lenguaje de representacin de ontologas. OWL: Ontology Web Language. Lenguaje de definicin de ontologas sobre web

Para construir la web semntica, segn la ide Tim Berners-Lee, hay que empezar por separar en cada web el contenido de la presentacin e incorporar al contenido metadatos sobre el significado del mismo. Documtica. Recuperacin de informacin Es un campo multidisciplinario relacionado con los Sistemas Gestores de Bases de Datos y la Inteligencia Artificial. Los sistemas de recuperacin de la informacin trabajan con informacin vasta y no estructurada, basada en fuentes heterogneas. La recuperacin de la informacin es probabilstica y sus medidas son: ndice de retorno. Porcentaje de documentos relevantes que han sido recuperados. ndice de pertinencia. Porcentaje de documentos recuperados que son relevantes. ruido. Porcentaje de documentos no relevantes recuperados silencio. Porcentaje de documentos relevantes que no han sido recuperados

La recuperacin de la informacin utiliza tcnicas de inteligencia artificial como modelos booleanos, vectoriales, sistemas expertos, ndices invertidos, sistemas de lgica borrosa, normas gamma, etc Adems se utilizan operaciones como el truncamiento de palabras, stemming, tesauros, etc Su operacin inversa es la indexacin de la informacin. La indexacin de la informacin se realiza mediante metadatos asociados a los documentos que son ledos por robots y posteriormente almacenados en una base de datos. Los robots o spiders de la web recorren los documentos a travs de sus enlaces localizando los metadatos y recopilando la informacin en las bases de datos de los buscadores. Documtica. Legislacin y normas aplicables La ley 11/2007 de acceso electrnico de los ciudadanos a los Servicios pblicos recoge como uno de los pilares del Ttulo 2. Rgimen Jurdico de la Administracin Electrnica, la gestin de los Documentos electrnicos y su archivado. Hace referencia a: Documento administrativo electrnico Archivo electrnico Expediente electrnico Copias electrnicas

El RD 1671/2009 que desarrolla parcialmente la Ley 11/2007, en su ttulo 6 hace referencia a Documentos electrnicos y sus copias

El RD 3/2010 que desarrolla el Esquema Nacional de Seguridad junto con la Ley Orgnica de Proteccin de Datos y su normativa, el RD 1720/2007, hacen referencia a Garantizar la calidad, el acceso, disponibilidad, conservacin, integridad, autenticidad y confidencialidad de los datos en el archivado de documentos electrnicos

El RD 4/2010 que desarrolla el Esquema Nacional de Interoperabilidad, hace referencia en el captulo 10 a las Condiciones para la recuperacin y conservacin de documentos electrnicos A travs de una serie de medidas organizativas y tcnicas o Polticas de gestin de documentos (NTI) o Inclusin de un ndice electrnico en los expedientes (NTI) o Identificacin nica e inequvoca de cada documento o Asociacin de metadatos mnimos obligatorios (NTI) o Clasificacin de documentos o Periodo de conservacin del documento o Acceso a los documentos a travs de mtodos de consulta online, descarga de documentos e impresin de documentos o Procedimientos de borrado y destruccin fsica de documentos

o Documentacin de los procedimientos Creacin de repositorios electrnicos para la gestin del contenido Medidas de seguridad (garantizadas mediante los citados ENS y LOPD junto con la Ley 59/2003 de Firma Electrnica) Formatos de los documentos (NTI) o Estandar abierto o Cuando exista riesgo de obsolencia en el formato, realizar copiado autntico con cambio de formato Digitalizacin de los documentos (NTI) o Resolucin del escaneado o Formato de salida o Metadatos a incluir en el documento electrnico Normas tcnicas de interoperabilidad (NTI) sobre los aspectos mencionados

Normas ATRIO (Almacenamiento, Transformacin, Recuperacin de informacin en las ofcinas) que se compone de SICRES y ESTROFA SICRES (Sistema de Informacin Comn para Registros de Entrada y Salida) ESTROFA (Especificaciones para el Tratamientos de los Flujos Administrativos Automtizados) Documtica. Sindicacin de contenidos Sus principales caractersticas son la recuperacin de informacin, recopilacin de noticias, actualizacin automtica. Los contenidos son publicados de fuentes heterogneas siguiendo un estndar para su formato. Mediante suscriptores o agregadores (que pueden ser aplicaciones de escritorio, pluggins en el navegador o webs), los contenidos son suscritos por el cliente y actualizados automticamente de forma peridica. RSS (Rich Site Summary o RDF Site Summary o Really Simple Syndication) y ATOM, ambos basados en XML son la tecnologa ms utilizada para escribir los contenidos y realizar las suscripciones. El estndar que utilizan los agregadores para realizar las suscripciones y listar las fuentes RSS se denomina OPML. Accesibilidad. Legislacin y obligaciones de las AAPP La Constitucin. Art.9 y Art.49 (participacin de todos los ciudadanos en las tecnologas, incluidos los disminuidos) La primera Ley que recoge la obligacin de cumplir medidas de accesibilidad fue la Ley 34/2002, que en su disposicin adicional quinta obligaba a adaptarse a las pginas Web oficiales pero sin especificar niveles ni normativas. Esta disposicin se modific con la entrada en vigor de la Ley 56/2007 de medidas de impulso de la Sociedad de la Informacin, concretando que las pginas web de la Administracin o con financiacin pblica deberan ser razonablemente accesibles, y para ello, antes del 31 de diciembre safisfacer, como mnimo el nivel medio de los criterios de accesibilidad reconocidos. Finalmente, el RD 1494/2007 establece que las citadas Webs debern cumplir la prioridad 2 de la norma UNE 139.803 de AENOR a partir del 31 de diciembre del 2008. Adems este Real Decreto tambin establece las condiciones bsicas en las aplicaciones software y los equipos informticos con las normas UNE 139.801 y UNE 139.802 de AENOR. Adems se hace mencin a la accesibilidad en otras leyes como: Ley 51/2003 (LIONDAU) RD 209/2003 de registros y notificaciones telemticas Ley 59/2003 de firma electrnica Ley 27/2007. Lengua de signos en pginas de internet. Ley 11/2007 de acceso a los ciudadanos a la administracin electrnica Accesibilidad. Pautas de accesibilidad web WAI (Iniciativa de Accesibilidad Web) es la inicialtiva del W3C en materia de accesibilidad web. Sus 5 lneas de trabajo son: 1. Aseguramiento de la accesibilidad web 2. Guias de accesibilidad (ATAG, UAAG, WCAG) 3. Herramientas libres (TAW y HERA)

4. Material de educacin 5. Coordinacin I+D WCAG 1.0. Las pautas de accesibilidad WEB son WCAG 1.0 formado 14 pautas (agrupadas en 11 pautas de transformacin y 3 pautas relacionadas con el contenido y navegacin). Cada una de estas pautas se evaluan en un total de 65 puntos de verificacin cuyo objetivo es alcanzar un determinado nivel de conformidad. Se manejan 3 prioridades P1, P2, P3. El cumplimiento de las 3 prioridades se certifican con los equivalentes niveles de conformidad A, AA, AAA. WCAG 2.0. Recientemente, el 11 de diciembre de 2008 aparece WCAG 2.0 con 4 principios (perceptible, operable, comprensible y robusto). Cada uno de estos principios est formado por un total de 12 pautas (4 en el primero y segundo, 3 en el tercero y una en el cuarto). Cada una de estas pautas se evaluan con un total de 61 criterios de xito que permiten definir los distintos niveles de conformidad. Las pautas por s solas no son verificables, para ello estn los criterios de xito. Como novedad en la guia WCAG 2.0, han sido documentadas para cada criterio de xito una serie de tcnicas que se puden catalogar en tcnicas suficientes y tcnicas aconsejables o consultivas. Son tres los documentos no normativos que ha publicado el W3C para WCAG 2.0: Comprender las Pautas 2.0, Tcnicas para las Pautas 2.0 y Gua rpida de las Pautas 2.0. En cuanto a la conformidad, las pautas 2.0 definen 4 requisitos de conformidad obligados: Nivel de conformidad (como en las WCAG 1.0) A, AA, AAA, y adems Pginas completas: El nivel de conformidad debe alcanzarse de la pgina completa. Procesos completos: Si varias pginas forman parte de un proceso secuencial, la totalidad del proceso debe cumplir el nivel de conformidad. Empleo de tecnologas accesibles: Si la pgina emplea tecnologas distintas, estas debern cumplir el mismo nivel de conformidad.

Accesibilidad. Norma UNE 139.803 de AENOR. 10 Requisitos de cada prioridad Prioridad 1, debe satisfacer: 1. 2. 3. 4. 5. 6. 7. 8. Conservar el significado sin el uso de hojas de estilo ni colores. Las pginas deben poder utilizarse an con los objetos scripts deshabilitados. Scripts con funcionalidad importante sern accesibles con ayudas tcnicas. Evitar parpadeos en la pantalla (epilepsia). Los marcos deben tener nombres significativos (no incluir ms de 3). Utilizar tablas correctamente (marcas de encabezado th). Sincronizacin de contenido dinmico y sus equivalentes. Presentar los equivalentes alternativos de una presentacin multimedia (audio-descripcin y subttulos sincronizados). 9. Utilizar lenguaje claro y sencillo. 10. Identificar el idioma principal de la pgina (<html lang=es>). 11. Proporcionar texto a todo contenido no textual. 12. Cuidar lo mapas de imagen proporcionando texto redundante como alternativa. 13. El texto de los enlaces debe indicar claramente su destino. 14. Si no se consigue la pgina accesible, proporcionar una alternativa a otra web. Prioridad 2. debera satisfacer: 1. DOCTYPE al principio del documento. 2. Correcta utilizacin de XHTML, rechazando elementos desaconsejados por W3C. 3. Incluir METADATOS en la web para facilitar los motores de bsqueda y la web semntica (title, meta, link, address, del, ins). 4. Usar unidades relativas en lugar de las medidas absolutas. 5. Usar elementos de encabezado o ttulo (h1, h2, h3, h6). 6. Describir el contenido de los marcos si no resulta claro con los nombres (longdesc). 7. Uso correcto de las listas y elementos de listas y citas (ol, li, blockquote). 8. Utilizar resmenes de tablas (summary). 9. CSS para disposicin (no usar tablas, con excepciones) y apariencia de los elementos.

10. Utilizar marcadores o tags y css en lugar de imgenes cuando sea posible. 11. El color de fondo y primer plano de imgenes deben contrastar (un valor de 125 para brillo y 500 para color). 12. Los elementos no deben parpadear (para evitar dificultades en la navegacin). 13. Posibilidad de detener los elementos con movimiento. 14. En las pginas con auto-refresco, proporcionar al usuario la forma de evitarlo. 15. Evitar pop-up sin aviso previo. 16. Evitar las redirecciones mediante marcadores. 17. Contenidos dinmicos accesibles. 18. Asociacin (explcita e implcita) de las etiquetas a los controles de formularios (uso de label). 19. Proporcionar mapa del sitio y mantener la coherencia de la navegacin (tabindex). 20. Scripts con funcionalidad no importante sern accesibles con ayudas tcnicas. 21. La ejecucin de los scripts debe ser independiente del dispositivo utilizado. Prioridad 3, puede satisfacer: 1. 2. 3. 4. Estilo de presentacin homogneo en todo el sitio. Proporcionar barras de navegacin y buscadores del sitio. Organizar los enlaces y proporcionar atajos de teclado (accesskey). El color de fondo y primer plano de texto deben contrastar (un valor de 125 para brillo y 500 para color). 5. Utilizar abreviaturas de encabezados de tablas (abbr). 6. Uso de marcadores adecuados para acrnimos y abreviaturas (acronym, abbr). 7. No usar presentaciones grficas y sonoras innecesarias. 8. Proporcionar alternativas a las tablas cuyo texto sea muy grande. 9. Incluir valores por omisin campos vacos para los formularios. 10. Proporcionar informacin para que los usuarios reciban los documentos segn preferencias (doc, rtf, pdf). 11. Proporcionar informacin sobre los elementos que pertenecen a una coleccin.

Accesibilidad. WCAG 2.0. Principios y Pautas La gua WCAG 2.0 est formada por cuatro principios fundamentales que albergan un total de 12 pautas de accesibilidad. A su vez, las pautas de accesibilidad se componen de un total de 61 criterios de xito, independientes de cualquier tecnologa, que debern cumplirse para alcanzar el grado de conformidad de cada prioridad. Los principios y las pautas son los siguientes: Principio Perceptible: Relativo al contenido de la web. Contiene 4 pautas: Alternativas textuales al contenido no textual Contenido multimedia dependiente del tiempo, presentando alternativas no visuales sincronizadas Adaptable al entorno, presentando el contenido de formas diferentes Contenido principal distinguible del contenido secundario

Principio Operable: Relativo a la interaccin de los elementos en la web. Contiene 4 pautas: Funcionalidad accesible a travs del teclado Tiempo suficiente para leer y usar el contenido Prevencin de ataques epilpticos Contenido navegable

Principio Comprensible: Relativo al contenido y los controles de la web. Contiene 3 pautas: Contenido legible Contenido perceptible Ayuda a la entrada de datos

Principio Robusto. Relativo a la compatibilidad con tecnologa futura. Contiene 1 pauta: Compatible con agentes actuales y futuros

Accesibilidad. Normas AENOR UNE de Accesibilidad Son normas creadas entre los aos 2003 y 2004 por AENOR para dar respuesta a los requisitos de la legislacin en materia de Accesibilidad de aplicaciones informticas. UNE 139.801: Aplicaciones informticas para personas con discapacidad. Requisitos de Accesibilidad al ordenador. Soporte fsico. UNE 139.802: Aplicaciones informticas para personas con discapacidad. Requisitos de Accesibilidad al ordenador. Software. UNE 139.803: Aplicaciones informticas para personas con discapacidad. Requisitos de Accesibilidad para contenidos Web. Las normas UNE 139.803 estn basadas en WCAG 1.0 y se describen 7 apartados: Principios generales, Presentacin, Estructura, Contenido, Navegacin, Scripts y objetos de programacin y Situaciones excepcionales. A su vez, mediante un sistema de prioridades podemos clasificar las pginas web de: Inaccesibles, cuando no cumplen prioridad 1, Su acceso presenta muchas dificultades, cuando no cumple la prioridad 2, Su acceso presenta alguna dificultad, cuando no cumple la prioridad 3, Accesible, cuando cumple todas las prioridades

Existen unas tablas de correspondecnia entre estos 7 apartados y las 14 pautas de WCAG 1.0 AENOR certifica slo para prioridades 1,2 y 1,2,3 mediante dos tipos de certificado: Certificado de conformidad Web y Certificado de accesibilidad TIC (este ltimo con control de auditorias). La primera Ley que recoge la obligacin de cumplir medidas de accesibilidad fue la Ley 34/2002, que en su disposicin adicional quinta obligaba a adaptarse a las pginas Web oficiales pero sin especificar niveles ni normativas. Esta disposicin se modific con la entrada en vigor de la Ley 56/2007 de medidas de impulso de la Sociedad de la Informacin, concretando que las pginas web de la Administracin o con financiacin pblica deberan ser razonablemente accesibles, y para ello, antes del 31 de diciembre safisfacer, como mnimo el nivel medio de los criterios de accesibilidad reconocidos. Finalmente, el RD 1494/2007 establece que las citadas Webs debern cumplir la prioridad 2 de la norma UNE 139.803 de AENOR a partir del 31 de diciembre del 2008. Adems este Real Decreto tambin establece las condiciones bsicas en las aplicaciones software y los equipos informticos con las normas UNE 139.801 y UNE 139.802 de AENOR. Cliente/Servidor. Caractersticas La arquitectura cliente servidor o sistemas distribuidos se basa en un conjunto de ordenadores autnomos enlazados en una red de comunicacin. Los elementos bsicos de los sistemas distribuidos son la red, los clientes y los servidores. Las caractersticas son las siguientes: Comparticin: Los servidores exponen recursos y los clientes solicitan recursos. Concurrencia: No slo de usuarios, tambin de recursos. Arquitectura abierta: Medida en que pueden aadirse servicios de comparticin de recursos sin que ello afecte a la integridad del sistema distribuido y sus usuarios. Hay que destacar el estndar de facto, la DCE (Distributed Computing Enviroment) del Open Group con servicios como directorio distribuido (DDS y LDAP), llamada a procedimientos (RPC), Call Level Interface, esto es, llamadas a gestores de bases de datos mediante SQL (CLI), sincronizacin horaria (NTP) y autenticacin Kerberos. Escalabilidad: Vertical, migracin a servidores mayores y Horizontal, aadiendo y suprimiendo servidores. Tolerancia a fallos: Redundancia de equipos y disponibilidad. Transparencia de red: Percepcin de usuario como un todo, no como un conjunto de nodos. Hay dos tipos de transparencia: o Transparencia de acceso: Se pueden realizar el mismo acceso a operaciones tanto locales como remotas. Un ejemplo de esto son los servicios web y SOA o Transparencia de ubicacin: Se pueden realizar accesos a un recurso sin conocer en qu parte de la red est el mismo. Un ejemplo de esto el el protocolo SMB (Server Message Block) y CIFS (Common Internet File System)

Cliente/Servidor. Definiciones ESB: Enterprise Service Bus o Bus SOA es la infraestructura que permite la comunicacin y gestin de los servicios en una arquitectura BPM-SOA. Surge como alternativa a la anterior EAI (Enterprise Application Integration). En la antigua integracin de aplicaciones de empresa, los datos y objetos estn distribuidos y requieren tantas conexiones como nodos quieran comunicarse, adems de sincronizacin entre nodos. ESB, por su parte requiere una sola conexin de cada nodo y se encarga de la sincronizacin. ESB proporciona gestin, encolado de mensajes, encaminamiento. Aporta orquestacin y coreografa. Aporta monitorizacin de los servicios. Aporta seguridad y confidencialidad a los servicios. BPM-SOA se puede implantar sin ESB, pero es recomendable su uso. En el mercado existen alternativas libres como la de Sun y propietarias de IBM, Oracle, BEA. Coreografa: Es un mtodo de colaboracin entre servicios que se implementa en arquitecturas BPM-SOA. En la coreografa cada nodo realiza parte de una 'visin global del sistema' de manera independiente pero coordinada con los dems servicios. No existe un mdulo centralizado que dirija la actividad, es un sistema distribuido en que cada servicio debe conocer qu hacer en cada momento para bien comn y global de la arquitectura. Existen implementaciones de coreografa como WSCDL. Orquestacin: Es un mtodo de colaboracin entre servicios que se implementa en arquitecturas BPM-SOA. Los servicios estn dirigidos por un mdulo director que toma la decisiones sobre el orden en que colaboran los servicios en un determinado proceso. Es un sistema centralizado orientado a la vista de un participante en particular, no tiene la visin global del sistema. Implementaciones de orquestacin son Biztalk de Microsoft o WS-BPEL de OASIS. Lenguajes como BPMN, notacin estandar para gestin de procesos de negocios, podemos representar WS-BPEL. Cliente/Servidor. Deficionones 2 COMET: Tambin llamado AJAX inverso o tecnologa Push. Es una tecnologa, adaptada de AJAX, que consiste en el mantenimiento de una conexin permanente entre cliente y servidor sobre la cual: - El cliente no realiza peticiones al servidor. En su lugar, el cliente manda mensajes al servidor - El servidor no responde a peticiones del cliente. En su lugar, el servidor enva mensajes al cliente en base a eventos ocurridos en el propio servidor. Esta tecnologa es hoy da utilizada en aplicaciones web como Google Talk, Facebook Mashup: Mashup es un concepto de desarrollo de sitios web, cuyo contenido est formado por aplicaciones o servicios de terceros. Estos servicios se incrustan en la web por medio de API's o agregadores RSS de sindicacin de forma que enriquecen al sitio web. Un sitio web puede estar compuesto enteramente de estos 'mashup'. Mashup es una aplicacin de la reutilizacin de servicios y arquitectura SOA. Estos sitios web hacen uso intensivo de AJAX y COMET. Cliente/Servidor. Middleware El las arquitecturas cliente/servidor hay 3 elementos (red, cliente y servidor). El middleware sera un cuarto elemento. Este componente permite la interoperabilidad de las aplicaciones distribuidas aislando al desarrollador de la complejidad de las interconexiones en el sistema de comunicacin y permitiendo acceso transparente a los recursos. Est entre la aplicacin y la red (como un pegamento) Ejemplos de ellos son: - MoM (Middleware orientado a Mensajes). Asncrono. Requiere que el sistema servidor mantenga una cola de mensajes. - P2P (Peer to peer). Conversacin. Establecimiento de conexin nico. - RPC (Remote Procedure Call). Sncrono, Stub en el cliente y servidor. Open Group tiene DCERPC. Tambin existe el XML-RPC. - RMI (Remote Method Invocation). Sncrono o asncrono. Entorno Java. Stub en el cliente y en el servidor - DCOM/COM+ (Distributed Component Object Model). Entorno Microsoft. Est en desuso en favor del Framework .NET - CORBA (Common Object Request Broker Architecture). Sncrono o asncrono. Es multilenguaje. Pertenece al Open Management Group. Necesita IDL en cliente y servidor - SOAP (Simple Object Access Protocol). Sncrono o asncrono. Alto nivel de abstraccin. Pertenece a W3C y OASIS (Open Source). Es una evolucin del XML-RPC

Cliente/Servidor. RMI, CORBA y SOAP RMI (Remote Method Invocation): Invocacin Remota de mtodos slo bajo tecnologa Java. Es orientado a objetos y est formado por la interfaz de los mtodos que se exportan, la capa stubskeleton de interaccin con la aplicacin y el transporte. Es incompatible con CORBA (sin embargo existe la interfaz RMI sobre IIOP, Internet Inter-ORB Protocol, que permite hacerlos trabajar juntos). Sncrono o asncrono. Las principales ventajas son la facilidad de implementacin (JAVA) y la eficacia debido al bajo nivel en que se implementa. Las desventajas son que dependen de puertos de comunicaciones que deben ser abiertos por los routers. CORBA (Common Object Request Broker Architecture): Del Open Management Group. Estndar orientado a objetos que permite interoperar entre sistemas heterogneos con independencia del lenguaje utilizado en ambos extremos. Envuelve el cdigo en un objeto ORB que puede ser invocado mediante IDL (Interface Definition Languaje). IDL es un lenguaje comn que genera el cdigo necesario para realizar la comunicacin entre ORB's; esto es, que describe las interfaces para que ambos objetos puedan comunicarse. La comunicacin entre los ORB's se realiza a travs del protocolo abstracto GIOP (General Inter-ORB Protocol) o IIOP (Internet Inter-ORB Protocol), la implementacin sobre TCP-IP de GIOP. Aporta seguridad en las comunicaciones basada en encriptacin. Sncrono o asncrono. Las principales ventajas son el multilenguaje y la eficacia debido al bajo nivel en que se implementa. Las desventajas son que dependen de puertos de comunicaciones que deben abrirse por los routers. SOAP (Simple Object Access Protocol) (1.2): Evolucin de XML-RPC. Pertenece a W3C. Es un protocolo de alto nivel basado en XML para realizar servicios web. Puede ser transportado por HTTP, SMTP, ... Su estructura es [Envelope(Header+Body)]. Se usa junto a WSDL, el lenguaje para describir el servicio y UDDI para publicar los servicios web. Sncrono o asncrono. Las ventajas son la facilidad de implementacin, multilenguaje (XML) y que trabaja sobre puertos estndares de comunicacin. Las desventajas son que es menos eficiente que RMI o CORBA por que trabaja a un nivel ms alto en la pila de protocolos. Cliente/Servidor. SOA o WebServices Las Arquitecturas Orientadas a Servicios son un modelo orientado a la reutilizacin de los servicios en entornos de sistemas distribuidos. SOA es una evolucin de la Programacin Orientada a Objetos en las arquitecturas cliente/servidor que 've' las aplicaciones como un conjunto de servicios sin estado, independientes y atmicos. Describe la utilizacin de servicios web debilmente acoplados y altamente interoperables. SOA puede implementarse con SOAP y WSDL pero no es la nica forma de hacerlo. Utiliza protocolos de transporte transparente (p.ej HTTP) Se basa en estndares abiertos y tecnologa de fcil adopcin (HTTP, XML). Los servicios deben ser independientes de los sistemas y lenguajes de programacin. La colaboracin entre los servicios se realiza siguiendo el concepto de orquestacin, mecanismo centralizado que dirige las interacciones entre los elementos y, coreografa, que describe el comportamiento de cada una de las actividades. Los elementos son: - Proveedor de servicios. Ofrece los servicios, y los publica junto con el contrato de interfaz (Ej. mediante SOAP y WSDL). - Consumidor de servicios. Sistema que utiliza los servicios de acuerdo a un contrato de interfaz (Ej. mediante SOAP y WSDL). - Servicio de publicacin. Sistema que recopila y publica los diferentes servicios disponibles y sus interfaces. Hace posible el descubrimiento de los servicios. (Ej. UDDI) Calidad. Definiciones Calidad: Grado en que un conjunto de caractersticas inherentes satisface unos requisitos establecidos. Calidad Total: Modelo de gestin empresarial orientado a la calidad, que persigue alcanzar la satisfaccin de todos aquellos entes (personal, clientes, sociedad) relacionados con la empresa u organizacin. El objetivo ltimo es alcanzar la excelencia a travs de un proceso de mejora continua. Gestin de Calidad del SW: ? Conjunto de actividades paralelas al desarrollo orientadas a garantizar la adecuacin del desarrollo a estndares y normas establecidas por la organizacin. Control de Calidad del SW: Conjunto de actividades destinadas a comprobar si un producto posee determinadas caractersticas de calidad. Ejemplo: Pruebas, Revisiones y Auditoras. Garanta de Calidad del SW: Conjunto de actividades paralelas al desarrollo que es necesario realizar para asegurar que un producto responde a las necesidades del usuario.

Calidad. Diferencia entre Revisiones Formales y Revisiones Tcnicas Las revisiones formales son una prctica de Mtrica 3 cuyo objetivo es detectar y registrar defectos en un producto intermedio y sus posibles desviaciones con respecto a las especificaciones y estndares establecidos. Las revisiones formales son un proceso riguroso y poco flexible realizado por el equipo de desarrollo, el grupo de aseguramiento de calidad y, en ocasiones, los usuarios. Las revisiones formales se realizan sobre los productos intermedios de especial importancia. Las revisiones formales dan como resultado un informe de revisin y lista de acciones correctoras con caracter formal y vinculante. Las revisiones tcnicas son una prctica de Mtrica 3 cuyo objetivo es evaluar un producto intermedio para verificar que satisface una serie de normas, estndares y guas establecidos en el proyecto con el fin de asegurar la calidad del producto final. Las revisiones tcnicas son realizadas por el Jefe de Proyecto y el Responsable de Aseguramiento de calidad. Las revisiones tcnicas dan como resultado un informe que formar parte de la documentacin final del proyecto. Calidad. Interfaz de Aseguramiento de Calidad La Interfaz de Aseguramiento de calidad (IAC) es una de las 4 interfaces definidas en Mtrica v3. Su objetivo es verificar la calidad de los productos desarrollados a travs de una serie de Revisiones realizadas en paralelo a las diferentes actividades de los procesos de Mtrica v3. Estas actividades permiten reducir, eliminar y prevenir las deficiencias del producto y aumentar la confianza esperada por el cliente. La IAC define y pone en marcha un Plan especfico para cada proyecto concreto. La IAC cubre los procesos desde Estudio de Viabilidad del Sistema al Mantenimiento del Sistema y es realizada por el Grupo de Aseguramiento de Calidad, independiente del equipo de desarrollo y supervisadas por el Responsable de Calidad. La IAC se basa en los estndares de calidad ISO 9000:2000, ISO 9001:2000 e ISO 15504/SPICE. El Plan de Aseguramiento de la Calidad se establece en la actividad paralela al Estudio de Viabilidad del Sistema y se especifica en la actividad paralela al Anlisis de Sistemas de Informacin. Este plan es especfico para cada proyecto concreto y se realizar de acuerdo a los estndares aplicables a la organizacin si existen, o a normas ISO 9000:2000 e ISO 9001:2000, en su defecto. El Plan de Aseguramiento de calidad refleja actividades de calidad (como revisiones, pruebas, auditorias), establece los estndares a aplicar, los productos a revisar, procedimientos a seguir, normativa para informar de defectos detectados y mtodo para realizar el seguimiento del proyecto hasta su mantenimiento. Calidad. Modelos de calidad actuales (evaluacin de procesos) Podemos definir la calidad total como el modelo de gestin enfocado a los procesos, basado en sistemas empresariales cuyo objetivo es la satisfaccin de todos los entes implicados. Se caracteriza por la bsqueda de la excelencia a travs de la mejora contina. Hay varios modelos: Modelo de calidad de la norma ISO/IEC 9126. Es un estndar certificable. Clasifica la calidad del software en un modelo estructurado de seis caractersticas (parecido a los factores del modelo de McCall) y subcaractersticas (como los criterios del modelo de McCall). Las seis caractersticas son Funcionalidad, Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad. CCM (Capability Maturity Model). Es un modelo de evaluacin de los procesos que permite definir el grado de madurez de las organizaciones. Hay 5 niveles de madurez (INICIAL, REPETIBLE, DEFINIDO, GESTIONADO y OPTIMIZADO). Para cada nivel se definen un conjunto de reas clave de proceso organizadas en 5 caractersticas comunes que contienen prcticas clave. Para pasar al siguiente nivel se deben realizar todas las reas clave de proceso. El nivel 3 es el objetivo de la mayora de las organizaciones. CMMI 1.2. Sucesor de SW-CMM. Cumple con la Norma SPICE. Integra varios modelos de evaluacin de procesos en un slo marco. Estos modelos son el desarrollo, la adquisicin y los servicios. Hay dos formas de representarlo: Primero, el modelo escalonado, para software, con los cinco niveles de madurez tradicionales de CMM. Segundo, el modelo continuo, para sistemas, con 6 niveles (INCOMPLETO, INICIAL, GESTIONADO, DEFINIDO, CUANTITATIVAMENTE GESTIONADO y OPTIMIZADO) que se pueden corresponder con los niveles del estndar 15504. EFQM. Modelo de autoevaluacin europeo. El objetivo es el Resultado del negocio dividido en Satisfaccin del cliente, Satisfaccin del personal e Impacto en la sociedad. Para conseguirlo necesitamos revisar los 5 agentes facilitadores de xito (Polticas y Estrategias, Procesos, Gestin de

personal, Alianza y Recursos, Liderazgo). Cada uno de estos 9 criterios se punta hasta conseguir un total de 1000 puntos. El modelo de excelencia de EFQM est regido por un proceso de mejora continua basado en PDCA y en las ltimas versiones se viene usando el mtodo REDER (Resultado, Enfoque, Despliegue, Evaluacin y Revisin) de mejora continua. Otros modelos usados en las Administraciones, a raz del RD 951/2005, marco general para la mejora de calidad en la AGE y basados en EFQM son EVAM y CAF. Calidad. Estndares de calidad (procesos) ISO/IEC 9126. Estndar internacional para la evaluacin del Software. Consta de un Modelo de calidad, Mtricas externas e internas y calidad en mtricas de uso. El modelo de calidad que propone es un estndar certificable. Define la usabilidad como la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones especficas de uso. ISO 9000 (2000). Son las llamadas normas para Sistemas de gestin de la calidad. El trmino Aseguramiento de la Calidad utilizado en las antiguas normas ISO 9000 da paso al trmino Gestin de la Calidad orientados a la Calidad Total. Adems se describen 8 principios en que se basan las normas. Algunos de estos principios son Satisfaccin del cliente, Mejora continua, Identificacin de procesos o responsabilidad de la direccin. Esta formado por tres normas bsicas ISO 9000:2000, conceptos y vocabulario de los Sistemas de Gestin de Calidad. ISO 9001:2000 (hoy da 9001:2008), Requisitos de los Sistemas de Gestin de Calidad. ISO 9004:2000 Gua para llevar a cabo los Sistemas de Gestin de Calidad. Los dos primeros son referencias de Mtrica 3. En cuanto a la ISO 9004 define 5 niveles de madurez y la evaluacin de los criterios que miden cada nivel camino a la excelencia. ... sobre procesos SW: ISO/IEC 15504 Spice. Estndar internacional de dominio pblico para evaluacin, determinacin de la capacidad y mejora continua de los procesos software. Mediante un modelo de referencia de dos dimensiones (proceso y capacidad) se evaluan los procesos. En cuanto a los procesos, SPICE adopta la norma ISO 12207 de Ingeniera del Software para determinar los procesos de evaluacin. A efectos de estudio de la capacidad se describen 6 niveles (0-5): Incompleto, Realizado, Gestionado, Establecido, Predecible y Optimizado. Mediante una serie de atributos de cada nivel se miden los procesos. ste es un estandar ligado a las normas 9000:2000 y junto con ellas forma parte de las referencias de Mtrica 3. ...sobre servicios IT: ISO/IEC 20000. Estndar internacional de gestin de servicios en las Tecnologas de la Informacin. Basados en las BS 15000. Est formada por dos documentos. El primero es la especificacin que define los requerimientos de las organizaciones, un total de 217, y es certificable. El segundo es el cdigo de prcticas y est basado en el estndar de facto ITIL. ITIL. No es un estndar(, es un estndar de facto). Biblioteca de infraestructuras para las Tecnologas de la informacin. Marco de buenas prcticas, de dominio pblico, para la entrega de servicios IT. Entre sus libros destaca la Entrega o Provisin de Servicio, basado en la garanta de disponibilidad de los servicios y Soporte de Servicio, centrado en la resolucin de incidencias. Otros libros como Gestin de las aplicaciones, Gestin de la infraestructura, Gestin del negocio, Gestin de la seguridad. Calidad. Usabilidad La usabilidad es un concepto que guarda relacin con la calidad y con la accesibilidad de los sistemas y productos. Est definida en el estndar ISO 9126 y en el ISO 9241 como la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones especficas de uso. Bajo esta definicin extraemos las siguientes conclusiones. La usabilidad es una medida emprica y relativa. Es una medida emprica porque se puede verificar mediante test de laboratorios u observadas mediante trabajo de campo. Sin embargo la usabilidad es relativa porque el resultado de esta medida viene condicionado por factores como el usuario a quin va dirigido el sistema o la comparacin con otros sistemas similares. En materia de calidad, la usabilidad va ligada a otros factores de calidad como la facilidad de uso, la flexibilidad o la robustez. Modelos de ciclo de vida Un modelo de ciclo de vida es un conjunto de etapas por las que pasa el desarrollo de un proyecto software y que abarca desde la concepcin del mismo hasta su retirada de servicio. Se diferencia de la metodologa en que el modelo de ciclo de vida no se ocupa de cmo realizar el desarrollo (participantes del mismo, tcnicas y prcticas a emplear...) En este caso se tiene en cuenta qu

actividades realizar y en que orden o secuencia, hitos a cumplir en cada etapa, objetivos para pasar de una etapa a la siguiente. Entre los modelos de ciclo de vida clsicos podemos citar: Modelo clsico o en cascada: Se definen fases secuenciales y debern realizarse en el orden estricto de secuencia. Se rige por la documentacin en cada fase y un estricto cumplimiento de los requisitos iniciales. Hay una variante con realimentacin que permite volver a la fase inmediatamente anterior. Las fses ms tpicas son anlisis, diseo, construccin y pruebas aunque no es relevante el nmero de ellas. Modelo de prototipos. Surge como reclamo para solucionar el problema de los requisitos inamovibles del modelo en cascada. Hay tres variantes: Prototipo clsico, Prototipo evolutivo y Prototipo incremental. En el Prototipo clsico se crea una maqueta desechable para confirmar los requisitos que no estn del todo claros. El prototipo evolutivo va desarrollando las partes del sistema que tienen claramente definidos sus requisitos. De este modelo ha surgido el Desarrollo Rpido de Aplicaciones (RAD) utilizando lenguajes 4GL. El prototipado incremental realiza versiones sucesivas cerradas con requisitos claros para cada versin. En cada versin se aade a la anterior un conjunto de funcionalidades distinguidas. Los modelos de ciclo de vida modernos son, entre otros: Modelo en espiral. Creado por Boehm, este modelo iterativo e incremental se diferencia de los dems en que aade el anlisis y gestin de riesgos al modelo, lo que le caracteriza como un modelo basado en la calidad y de difcil implementacin. Se representa como una espiral con cuatro cuadrantes que reflejan actividades por las que deber pasar cada fase. Estas son Planificacin, Anlisis y Gestin de Riesgos, Ingeniera y Evaluacin. Una fase se define con un ciclo completo de la espiral. El nmero de fases es irrelevante y se define al inicio de la aplicacin del modelo. En este modelo se puede medir en cada momento la evolucin del desarrollo con el valor del radio de la espiral y el coste con el valor del ngulo de la espiral. PUDS: Es, en realidad una metodologa que impone un ciclo de vida. El Proceso Unificado de Desarrollo del Software nace desde la perspectiva del desarrollo orientado a objetos de Booch, Roumbaugh y Jacobson. Es un modelo basado en la arquitectura y guiado por los casos de uso y los modelos. Este es un modelo iterativo e incremental en que se definen cuatro grandes fases (Concepcin, Elaboracin, Construccin y Transicin) y para cada una de ellas, el desarrollo deber realizar una o varias iteracciones que se vern afectadas por las siguientes actividades o disciplinas: Modelado de Negocio, Gestin de requisitos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue, Gestin de la configuracin, gestin del proyecto y el entorno de desarrollo. La primera iteracin de las cuatro fases se llama desarrollo inicial y da como resultado un producto beta. Las siguientes iteracciones se llaman desarrollo evolutivo. Modelos de ciclo de vida. Metodologas giles Las metodologas giles son un modelo de ingeniera del software que surge a principios del ao 2000 y basado en las directrices de su manifiesto: Un desarrollo gil se fundamenta en hacer prevalecer: 1. 2. 3. 4. Personas sobre los Procesos y Herramientas Software que funcione sobre la documentacin exhaustiva Colaboracin con el cliente sobre la negociacin contractual Respuesta al cambio sobre la planificacin rgida

Adems de estas cuatro directrices, los mtodos giles proponen 12 principios que se pueden resumir en: Satisfaccin del cliente aumentando su competitividad mediante entrega continua, y en breves intervalos de tiempo, de software funcional. El software ser la medida del progreso del proyecto. Son bienvenidos los requisitos cambiantes en cualquier fase del desarrollo. Bsqueda de la excelencia y el buen diseo. La simplicidad (el arte de maximizar la cantidad de trabajo no realizado) es esencial. Comunicacin entre el cliente y los desarrolladores a diario, cara a cara formando parte del mismo equipo de trabajo. Motivacin del personal y aumento de confianza mediante la auto-organizacin del equipo de desarrollo.

Mantener un paso constante de productividad, manteniendo, a intervalos regulares, reuniones de autoevaluacin y mejora continua para ajustar los parmetros de trabajo y del proyecto.

Esta metodologa contrasta en muchos aspectos con metodologas tradicionales. Como ejemplos podemos citar que su objetivo es realizar entregas continuas de software funcional al cliente pudiendo ste realizar cambios en los requisitos en cualquier momento del desarrollo. Para atender eficazmente las necesidades del cliente y no desmotivar a los analistas y desarrolladores, la metodologa gil propone tcnicas como la implicacin directa del cliente, trabajando mano a mano y cara a cara con el desarrollador, no afrontar tareas pesadas y largas en el tiempo, primando las pequeas soluciones rpidas a estos cambios. Es esencial el modelo iterativo de trabajo, realizando frecuentes reuniones para valorar los cambios y el desarrollo entregado y estudiar cmo mejorar la eficiencia. Ejemplos de metodologas giles son Scrum, XP, FDD, ASD, Cristal, RUP o PUDS (no en todas las bibliografias considerado como tal) XML. DTD y Esquemas XML DTD (Document Type Definition) es un documento de texto que delimita todas las partes de un documento XML: Elementos, nmero de elementos, orden, relaciones, atributos. SchemaXML es un documento XML que realiza las mismas funciones que un DTD y ampla sus funcionalidades. Ambas tecnologas permiten validar un documento XML pero presentan bastantes diferencias. Las diferencias son las siguientes: Un DTD valida un documento completo, mientras que un SchemaXML puede validar partes de un documento. El uso del DTD est ms extendido que el de los esquemas por lo que se pueden encontrar ms facilidades para su implementacin. Un DTD es ms sencillo de escribir pero su sintaxis no es XML como el esquema. La validacin del DTD requiere menos capacidad de computacin por su sintaxis ms sencilla. Los elementos de un DTD son globales, esto es que no pueden repetirse, mientras que el esquema s lo permite mediante espacios de nombres. Un SchemaXML permite describir tipos de datos predefinidos como fechas, enteros, cadenas de texto... mientras que un DTD no. Un DTD solo usa datos #PCDATA. Un SchemaXML permite crear tipos de datos a medida a travs de las restricciones mientras que un DTD solo usa datos #PCDATA. Un SchemaXML permite describir elementos complejos como elementos con subelementos y datos de texto a la vez. Un SchemaXML puede hacer referencia a otros esquemas mientras que un DTD no.

XML. parsers XML Para poder trabajar con documentos XML en los entornos de desarrollo actuales como J2EE y .NET se hace necesario una serie de libreras o API que nos faciliten la labor de leer los documentos de texto (que al fin y al cabo son los XML). Los parser se encargan, no slo de validar los documentos si no de proporcionar una serie de operaciones para manipular su informacin. Los principales parsers son los siguientes: DOM. Estndar de la W3C, el Document Object Model es un parser cuya caracterstica principal es que mantiene todo el rbol del documento XML en memoria. Esto permite leer la informacin de los nodos, aadir, eliminar y posteriormente salvar los cambios en el mismo XML. El sobreesfuerzo que supone cargar todo el contenido en memoria se compensa con la velocidad de respuesta y la capacidad de modificacin frente a SAX. Su especificacin ms reciente es la 2.0 SAX. Simple API for XML es otra forma de manipular un documento XML, pero esta vez slo parte del mismo. Trabaja en base a eventos, esto es segn es presentada. Permite trabajar fcilmente con rboles muy grandes, pero no todo l en memoria. Sin embargo, no permite la manipulacin de los nodos. Su versin actual es la 2.0 Una de las implementaciones ms populares para C++ o Java es Xerces que cumple tanto con las especificaciones para DOM como para SAX. JDOM. Surge como alternativa a DOM y SAX como un parser especfico para Java.

JAXP. Java API for XML Processing. No es un parser en si. Es el API oficial de Java para procesamiento de documentos XML. Establece las normas y operaciones comunes que debern cumplir los parser que quieran ser interoperables en el mundo Java. System.XML Biblioteca de la BCL de .NET para procesar documentos XML en el framework de Microsoft. XML. Principales tecnologas (XSL, XLL, XForms y XQuery) Las principales tecnologas referidas a XML son: XSL. eXtensible Style Language. Su objetivo es proporcionar un modo de formateo de documentos XML. Est formado por XSLT, XPath y XML-FO. - XSLT. Lenguaje extensible de estilos de transformacin. Su principal uso es transformar un documento XML en otro, por ejemplo XHTML. Usa XPath para trabajar sobre el XML. - XPath. Lenguaje de navegacin sobre documentos XML. Su sintaxis no es XML, permite posicionarse sobre cualquier objeto de XML e incluso devolver estructuras tipo array del rbol. - XML-FO. Lenguaje de formateo de XML. Describe el formato y los datos a aplicar. Su principal uso es transformar un XML en PDF. XLL. eXtensible Linking Language. Su objetivo es referenciar documentos desde XML. Est formado por XLink y XPath. - XLink. Lenguaje de creacin de hiperenlaces en un documento XML. Mediante la definicin de un namespace, xlink puede referenciar otros documentos a modo de anclaje (como el ancla de HTML) - XPointer. Su uso junto con XLink, permite referenciar elementos de la estructura interna de un documento XML. Hace, para ello uso de XLink y XPath. XForms. Pretende ser el estandar de creacin de formularios. Son los sucesores de los XHTML Forms. Separan la presentacin de los datos del formulario, pudiendo ste presentarse embebido en HTML, XML u otros medios que soporten XML. El no depender de la presentacin hace que estos formularios sean independientes del dispositivo. XQuery. Es un lenguaje de consulta de documentos XML. Son a los XML lo que SQL a las bases de datos relacionales. Permiten recuperar informacin estructurada de un XML con datos. XMLEncryption. Permite la encriptacin de documentos y datos sean XML o no. Admite algoritmos como TripleDES, AES, o RSA. La codificacin de datos se hace en Base64. XMLDSignature. Permite el firmado digital de documentos y datos sean XML o no. XKMS. XML Key Management System. Permite el registro y distribucin de claves pblicas en el uso de XMLDSig. SOAP. Simple Object Access Protocol, es un protocolo que permite el intercambio de mensajes XML entre sistemas distribuidos. Es unos de los protocolos ms utilizados en servicios web. XML es el lenguaje encargado tanto de su distribucin (mensajes SOAP) como de la descripcin de las interfaces de estos servicios (con WSDL). XML. XAdES XAdES (XML Advanced Electronic Signature) es un estndar de firmado electrnico basado en XMLDSig de W3C. Ha sido estandarizado por la ETSI (European Telecomunications Standard Institue) como especificacin tcnica europea en el mbito de la firma electrnica. En las Administraciones Pblicas europeas su uso extendido pretende sustituir al otro estndar de infraestructura de clave pblica PKCS#7. Ambos, XAdES y PKCS#7 se basan en criptografa de clave pblica para su firmado. Sin embargo, hay algunas caractersticas que incluye XAdES que lo hacen destacar: 1. XAdES est escrito en XML, mientras que PKCS#7 en notacin ASN1, lo que le confiere al primero alta interoperabilidad con los servicios actuales de comunicacin distribuida y permite utilizarse fcilmente con parsers XML actuales. 2. PKCS#7 no almacena el estado de la firma, ni cundo se realiz, mientras que XAdES incluye marcas y sellado de tiempo junto con la firma 3. XAdES permite realizar mltiples firmas de diferentes partes del documento (uso de Enveloped, Enveloping y Detached), as como firmar ficheros adjuntos. Por ltimo, XAdES permite realizar la firma con seis perfiles de proteccin diferentes: 1. XAdES-BES o firma electrnica avanzada, a. XAdES-EPES, es una especializacin de XAdES BES, aadiendo polticas de firma,

2. XAdES-T que aade sello de tiempo, 3. XAdES-C aadiendo referencias a los datos de verificacin de firma y a los certificados implicados, 4. XAdES-X que aade sello de tiempo tambin a las referencias de XAdES-C, 5. XAdES-XL que aade los certificados y las respuestas OCSP o CLR (a diferencia de XAdES-C que simplemente aada las referencias). Esto permite verificar en un futuro incluso si las fuentes no estn disponibles. 6. XAdES-A que aade la posibilidad de un timestamping peridico de documentos archivados

Sistemas eLearning Los sistemas eLearning combinan los sistemas tradicionales de aprendizaje con la tecnologa actual (internet, documentos electrnicos, plataformas web, xml...) En el mundo eLearning podemos hablar de LMS y LCMS. LMS (Learning Management System) son sistemas de gestin para el aprendizaje que consisten en agrupar en una plataforma informtica las labores de gestin de alumnos, profesorado, contenidos, acciones formativas, evaluaciones... Normalmente no contienen funciones de autora (no crean cursos). LCMS (Learning Content Management System) son sistemas de gestin de contenidos para el aprendizaje que combinan las posibilidades de sistemas LMS con la gestin de contenidos (almacenamiento y creacin). Los sistemas LMS generalmente se preocupan de cumplir con los estndares y normas aceptadas en el mbito de eLearning. Las ms destacadas son: - AICC (Aviation Industry CBT Comite): Primer estndar para formar aviadores - IMS (Instruction Management System). Consorcio creado para desarrollar y promover especificaciones abiertas en el mbito de eLearning. Entre otros trabajos se encuentra la empaquetacin de contenidos o LOM (Learning Object Metadata), que especifica la sintaxis y la semntica de los metadatos de un objeto educativo. - SCORM. El Modelo de referencia para la comparticin de objetos de contenido (Shared Content Object Reference Model) es creado por la organizacin ADL y proporciona especificaciones sobre los objetos de contenido a compartir (SCO), el entorno de ejecucin de estos SCO's y la descripcin de los metadatos necesarios para almacenar la estructura de los cursos, participacin de los alumnos, evolucin del aprendizaje... Tambin se ocupa de la metodologa para agregar contenido a las plataformas LMS. Gran parte del trabajo de SCORM hace referencia a los estndares de IMS. Algunos sistemas LMS son WebCT, Catedr@ o eCollege en el mbito propietario y Moodle, Sakai, Dokeos, Claroline o ATutor en el mbito del Open Source. Mantenimiento. Tipos de mantenimiento Solucin basada en Mtrica v3. El mantenimiento es cualquier tipo de modificacin de un programa que est en uso. Realiza una fase de desarrollo posterior al mismo. Hay 4 tipos de mantenimiento definidos en Mtrica v3: - Correctivo: Corrige errores, aproximadamente el 15% (Adems se usa en Mtrica v3) - Evolutivo: Cubrir las necesidades de los usuarios, aproximadamente el 60% (Adems se usa en Mtrica v3) (Perfectivo segn Bennett, Leintz y Swanson) - Perfectivo: Mejorar la calidad interna del software (Preventivo segn Bennett, Leintz y Swanson) - Adaptativo: Adaptarse al entorno Bennet, Lientz y Swanson definen correctivo, adaptativo, perfectivo (igual que evolutivo de Mtrica) y preventivo (para prevenir problemas futuros) Pressman define correctivo, adaptativo y perfectivo (debido a requisitos de usuarios y para crear una base para futuras mejoras) En Mtrica v3, el proceso encargado del mantenimiento es MSI y se compone de 4 actividades secuenciales: 1. Registro de la peticin 2. Anlisis de la peticin 3. Preparacin e implementacin de la modificacin 4. Seguimiento, evaluacin de los cambios hasta la aceptacin Las pruebas realizadas en este proceso son pruebas de regresin. Se usa la prctica del Anlisis de Impacto. El mantenimiento evolutivo se realiza en la medida que se cumplan los SLA definidos en IAS. El estndar de facto aplicable a las fases de mantenimiento es IEEE 1219-1992

Mantenimiento. Definiciones Ingeniera inversa: Proceso de analizar un sistema para identificar sus componentes y relaciones creando representaciones del sistema en otra forma distinta al original o a un nivel superior de abstraccin. Reingeniera: Examen y modificacin de un sistema para ser reconstruido de forma nueva e implantar esa nueva forma. Esto se suele hacer para recuperar un sistema heredado (legacy system), problemtico u obsoleto proporcionando una base para el mantenimiento y futuros desarrollos. Incluye Ingeniera inversa y va seguida de una ingeniera hacia delante o reestructuracin. A la hora de abordar un proceso de reingeniera, Harry Sneed propone un mtodo para justificar el gasto que supone una reingeniera, estudiando la calidad tcnica de las aplicaciones frente a su valor de negocio. Una vez que abordamos la tarea de la reingeniera el modelo sistemtico OAR (Anlisis de Opciones para la Reingeniera) puede ser til para estudiar los componentes reutilizables y los que no lo son. Se puede hablar del modelo IEEE, cclico y de herradura como modelos o metodologas de reingeniera (a pesar de que no hay metodologas oficiales para abordarla). Reestructuracin: Transformacin de una forma de representacin del sistema en otra distinta pero del mismo nivel de abstraccin, sin modificar el comportamiento externo del sistema. Aplicaciones Heredadas (Legacy Systems): Aplicaciones existentes que sirven para un propsito continuo y no merece la pena modificar. Mantenibilidad. Grado de posibilidad de comprender, corregir, adaptar o mejorar el software. Estudia la facilidad y el esfuerzo del mantenimiento. Mantenimiento. Reingeniera. Cmo abordar la reingeniera? Plantear una reingeniera sobre un sistema es costoso econmica y tecnolgicamente hablando. Antes de hacerlo, debemos estudiar el sistema. Nuestro sistema se puede encontrar en cuatro situaciones diferenciadas (realizar cuadrantes con el eje X mostrando el valor del negocio y el eje Y mostrando la calidad tecnolgica) 1. (Cuadrante superior derecho) Sistema con alta calidad tecnolgica y alto valor de negocio. En este caso, no ser necesario aplicar reingeniera ya que el sistema mantiene una alta calidad tecnolgica. 2. (Cuadrante superior izquierdo) Sistema con alta calidad tecnolgica y escaso valor para el negocio. Por sto ltimo no es necesario invertir tiempo y dinero en el sistema. 3. (Cuadrante inferior izquierdo) Sistema de baja calidad y escaso valor de negocio. En esta situacin se presentar el dilema de abordar la reingeniera. Ser una decisin empresarial. 4. (Cuadrante inferior derecho) Sistema de baja calidad y alto valor para el negocio. En este caso, la reingeniera es obligada para seguir manteniendo un alto valor tanto de negocio como de calidad. Una vez que se decide realizar la reingeniera podemos optar por el mtodo OAR (Opciones de Anlisis de Reingeniera) para decidir qu elementos recuperar del sistema actual y los componentes que se desarrollarn desde cero. Las fases del mtodo OAR son: Establecimiento del contexto de extraccin, Inventario de componentes, Anlisis de los componentes candidatos, Plan de extraccin y Seleccin de opciones de extraccin. Estn relacionadas con la extraccin y los componentes. No confundir con las fases del Modelo cclico de Pressman. Para la realizacin de la reingeniera podemos utilizar cualquiera de los modelos diponibles, entre ellos: 1. Modelo de Herradura, que representa tres niveles de abstraccin (Nivel de cdigo, Nivel funcional y Nivel conceptual) 2. Modelo IEEE, que define los conceptos de ingeniera inversa, reingeniera, reestructuracin y Ingeniera hacia delante 3. Modelo cclico de Pressman con las siguientes fases: Anlisis de inventario, Reestructuracin de documentos, Ingeniera inversa, Reestructuracin de cdigo, Reestructuracin de datos e Ingeniera directa. Cada uno de los modelos tiene en comn la aplicacin de algn tipo de ingeniera inversa, seguido de reestructuracin para despus finalizar con ingeniera hacia delante o ingeniera directa.

Auditoras. Qu es una auditora Puede servir como introduccin a otras preguntas. Es un proceso o actividad sistemtica (implica planificacin y metodologa) de obtencin y evaluacin de evidencias en una organizacin o sistema. Su objetivo es mejorar la eficiencia y eficacia (internas) o alcanzar una certificacin SGSI (las auditorias externas). El auditor es siempre externo a la organizacin. Est formada por tres fases: - Preparacin y estudio de la organizacin (toma de contacto) - Desarrollo. Obtener evidencias y evaluarlas. Implica interaccin con RRHH y sistemas - Informe. Diagnstico de puntos dbiles y fuertes. Son conclusiones. La diferencia con la Consultora es que no dice cmo solucionar las incidencias. Las auditorias se clasifican en: - Auditor de primera parte: Interna. Busca mejorar la eficiencia y la eficacia. - Auditor de segunda parte: Cliente - Auditor de tercera parte. Externo. Su objetivo es lograr la certificacin. Funciones de la auditora informtica: - Revisin de instalaciones informticas - Revisin de sistemas en desarrollo - Revisin de las aplicaciones - Apoyo a auditores no informticos Tambin se pueden comentar los requisitos COBIT (Eficiencia, Eficacia, Confidencialidad, Integridad, Disponibilidad, Fiabilidad y cumplimiento de las normas) Auditoras. COBIT COBIT (Control OBjectives for Information and related Tecnologies) es una metodologa desarrollada por la ISACA (Information System Audit & Control Association) independiente de la plataforma tecnolgica. La versin actual es la 4.1 COBIT consta de 3 elementos: 4 dominios, 34 procesos y 318 objetivos de control destinados a proporcionar una garanta de que los objetivos sern alcanzados (no es necesario cumplir los 318 para que la auditora se considere completa, pero si pasar por los 4 dominios y 34 procesos). PO-SS-AI-M o Planificacin y Organizacin o Soporte y Servicio o Adquisicin e Implementacin o Monitorizacin Requisitos de negocio o Eficiencia, o Eficacia, o Confidencialidad, o Integridad, o Disponibilidad, o Fiabilidad y o Cumplimiento de las normas Recursos TIC o Datos, o Aplicaciones, o Infraestructuras (Tecnologa, Instalaciones) y o Personas

Auditoras. Normas y estndares Por la ISACA (Information System Audit & Control Association), de uso obligatorio por sus auditores son las normas 500 En las AAPP: RD 1720/2007 en el Art.96. Los ficheros de datos a partir del nivel medio debern auditarse al menos cada 2 aos mediante auditoras internas o externas. Tambin, con caracter extraordinario, cuando se realicen modificaciones sustanciales, comenzando a contar los 2 aos desde el momento de la auditora extraordinaria. El resultado de la auditora se plasmar en un informe que reflejar los puntos dbiles y fuertes, las deficiencias, as como las recomendaciones para corregirlas. Este informe se elevar al responsable del fichero o al responsable del tratamiento del fichero. RD 3/2010, ENS en el captulo 5, Art.34. Los sistemas, servicios, datos de las AAPP debern auditarse al menos cada 2 aos mediante Autoevaluaciones o Auditoras. Tambin, con caracter extraordinario, cuando se realicen modificaciones sustanciales, comenzando a contar los 2 aos desde el momento de la auditora extraordinaria. Las Autoevalluaciones sern realizadas por el personal propio de la organizacin para sistemas de categora bsica y las Auditorias sern realizadas por un auditor externo para sistemas de categora media y alta. El resultado de la auditora se plasmar en un informe que reflejar los puntos dbiles y fuertes, las deficiencias, as como las recomendaciones para corregirlas. Este informe se elevar al responsable del sistema que, en los casos de sistemas con categora alta podr dar de baja el servicio, sistema o informacin vulnerable. ISO 27000. Para los Sistemas de Gestin de Seguridad Informacin (SGSI)

27000 - Trminos y definiciones 27001 - Requisitos de SGSI. Certifica auditores externos 27002 - Reemplaza ISO 17799. Gua de buenas prcticas que describe 11 dominios, 39 objetivos de control y 133 controles. No es certificable. 27003 - Gua de implementacin SGSI mediante PDCA 27006 - Requisitos para la acreditacin y certificacin de entidades auditora 27007 - Gua de auditora Se puede sealar que 27002 se usa en PILAR de MAGERIT v2 Pruebas. Definiciones Pruebas unitarias. Su objetivo es comprobar el correcto funcionamiento de los mdulos independientes una vez que han sido desarrollados. Comprueban su estructura interna (en el caso de las pruebas de caja blanca) y las entradas y salidas (en el caso de caja negra). Se realiza en el entorno de desarrollo por los tcnicos de sistemas y programadores. Pruebas de integracin. Su objetivo es realizar el correcto ensamblaje de los distintos componentes del sistema. Se combinan con las pruebas unitarias en la creacin de mdulos auxiliares y componentes conductores para llevar a cabo las distintas estrategias de integracin. Adems las pruebas de regresin tambin pueden servir de apoyo tras la integracin de un componente. Las pruebas de integracin pueden ser incrementales o no incrementales y se realizan en el entorno de desarrollo por los analistas, equipo de arquitectura, tcnico de comunicaciones y tcnicos de sistemas. Pruebas de sistema. Su objetivo es comprobar profundamente el sistema verificando los subsistemas que lo componen. Se realiza en el entorno de desarrollo por los mismos participantes que intervienen en las pruebas de integracin ms el Jefe de Proyecto. Pruebas de implantacin. Su objetivo es comprobar el correcto funcionamiento del sistema integrando SW y HW. Buscan la aceptacin del usuario desde el punto de vista operacional. Requisitos no funcionales. Se realizan en el entorno de operacin por el equipo de implantacin y el jefe de proyecto. Pruebas de aceptacin. Su objetivo es comprobar que el sistema cumple con los requisitos funcionales y de rendimiento segn las definiciones del usuario en las fases de anlisis. Se realizan en el entorno de operacin por los directores de usuarios, usuarios expertos y el jefe de proyecto. Pruebas de regresin. Su objetivo es comprobar que los cambios efectuados sobre un componente no producen un funcionamiento erroneo en los dems componentes o en el propio sistema. Se usan en las etapas de mantenimiento y tambin en las pruebas de integracin cuando aadimos nuevos

mdulos para comprobar que no se producen errores. Se realiza previamente un anlisis de impacto con el inventario de componentes afectados para evaluar la fiabilidad y el cumplimiento de la peticin. Seguridad. Poltica de Seguridad y Plan de Seguridad Plan de Seguridad. Definido segn Magerit, es un conjunto de programas de seguridad. Los programas de seguridad son tareas o proyectos orientados a afrontar el riesgo. El plan de seguridad es uno de los productos de Magerit v2 que se obtienen en el Proceso 3. 'Gestin de Riesgos'. Por lo tanto, el plan de Seguridad es la consecuencia y transcripcin de la aplicacin de un anlisis y gestin de riesgos en una organizacin. Se puede descomponer en tres niveles de detalle: Plan Director, con un alcance de 3 a 5 aos. Contiene las directrices de actuacin del plan de seguridad Plan Anual, con un alcance de 1 a 2 aos. Contiene la planificacin de los programas de seguridad Plan de Proyecto. Contiene los detalles de cada Programa de Seguridad

Poltica de Seguridad. Definido segn el RD 3/2010, ENS, como el documento que contiene las atribuciones de cada responsable y los mecanismos de coordinacin y resolucin de conflictos. La Poltica de Seguridad deber ser coherente con lo dispuesto por el Documento de Seguridad del RD 1720/2007. El documento deber contener, al menos, lo siguiente: 1. Los objetivos o misin de la organizacin. 2. El marco legal y regulatorio en el que se desarrollarn las actividades. 3. Los roles o funciones de seguridad, definiendo para cada uno, los deberes y responsabilidades del cargo, as como el procedimiento para su designacin y renovacin. 4. La estructura del comit o los comits para la gestin y coordinacin de la seguridad, detallando su mbito de responsabilidad, los miembros y la relacin con otros elementos de la organizacin. 5. Directrices de estructura, gestin y acceso de la documentacin de seguridad del sistema.

Seguridad. Anlisis de riesgos aplicando Magerit. MAgerit v2 propone un modelo de mejora continua basado en el crculo de Demming o PDCA para analizar los riesgos de una organizacin. Hay 5 fases con la siguiente secuencia: Fase 1. Identificar los activos y estudiar las dimensiones afectadas (Autenticacin, Confidencialidad, Integridad, Disponibilidad y Trazabilidad). Tambin se estudian las dependencias de los activos clasificndolos en la siguiente jerarqua (Capa1: Entorno, Capa2: Sistemas HW y SW, Capa3: Datos, Capa4: Funciones de la Organizacin y Capa5: otros elementos). Los activos se clasifican por su valor. Fase 2. Identificar las amenazas para cada activo. Las amenazas son los sucesos que pueden provocar la prdida de valor en un activo. La valoracin de las amenazas estudia la degradacin de un activo tras la materializacin de una amenaza y la frecuencia de ocurrencia de esa materialziacin. OJO. Saltamos el paso 3. En la primera iteracin no se contempla. El impacto y el riesgo es potencial, es decir, no se aplican salvaguardas. Fase 4. Estudio del impacto. El impacto es la consecuencia de la ocurrencia de una materializacin de una amenaza sobre un activo. Se estudiar el impacto acumulado, que es el valor del impacto sobre un activo ms el valor de los impactos sobre los activos que dependen de l. Tambin se estudiar el impacto repercutido, que es el valor del impacto sobre un activo ms el valor del impacto sobre los activos de que depende. Y se estudiar la agregacin de valores de impacto (ninguno de los anteriores) Fase 5. Estudio del riesgo. El riesgo es la probabilidad de la ocurrencia de materializacin de una amenaza sobre un activo. Se esudian el riesgo acumulado, repercutido y la agregacin de valores de riesgo que se definen de forma equivalente a los de la Fase 4. Fase 3. Desplegar salvaguardas que protegen los activos. Las salvaguardas se aplicarn sobre la degradacin y la frecuencia resultantes del impacto y el riesgo de cada amenaza sobre un activo. La

aplicacin de salvaguardas provocarn un impacto y riesgo residual. A partir de aqu se realizan iteraciones de las Fases 4, 5 y 3 hasta que el riesgo y el impacto residual sean despreciable. Al resultado de estas iteraciones se le conoce como la Gestin de Riesgos.

Seguridad. Documentos resultado de un anlisis y gestin de riesgos segn Magerit En el proceso P2. Anlisis de Riesgos: Actividad 1. Caracterizacin de los activos. Se obtiene el modelo de valor. El modelo de valor describe para cada activo, sus dimensiones afectadas, las dependencias sobre los dems activos y el valor en la organizacin. Actividad 2. Caracterizacin de las amenzazas. Se obtiene el mapa de riesgos. El mapa de riesgos describe las amenzadas que afectan a cada activo indicando la valoracin de la degradacin y la frecuencia que provocan sobre el activo Actividad 3. Caracterizacin de las salvaguardas. Se obtiene la evaluacin de salvaguardas. La evaluacin de salvaguardas es un listado con las salvaguardas actuales y su calificacin Actividad 4. Estimacin del estado de riesgo. Se obtienen dos documentos: el estado del riesgo y el informe de insuficiencias. El estado de riesgos propone, para cada activo el impacto y el riesgo residual que provocan sus amenazas. El informe de insuficiencias indica las salvaguardas innecesarias, ausentes o no eficaces.

En el Proceso P3. Gestin de Riesgos se obtiene el Plan de Seguridad como consecuencia de aplicar el proceso de anlisis de riesgos hasta conseguir un impacto y riesgo residual despreciable. Seguridad. Definiciones Certificacin, Acreditacin, Evaluacin Definiciones de la Orden Presidencial OM/PRE 2740/2007 Evaluacin: Es el anlisis, realizado por laboratorios mediante un proceso metodolgico, de la capacidad de un producto o sistema para proteger las condiciones de seguridad de acuerdo a unos criterios preestablecidos, con el objeto de determinar si puede ser certificado. Este concepto est muy ligado a las Auditoras. La evaluacin es el proceso. Certificacin: Es la resolucin, obtenida mediante un proceso metodolgico de evaluacin sobre la conformidad de un producto con unos criterios preestablecidos. En materia de seguridad, un sistema certificado es capaz de proteger unos datos frente a amenazas con una cierta calidad, en base a unas medidas de salvaguardas adoptadas. Las certificaciones son un valor aadido que se realizan a sistemas y productos y tiene caracter voluntario. Para mantener dicha certificacin es necesario la realizacin de auditorias de seguimiento anuales y una extra de renovacin a los tres aos. El organismo nacional reconocido de certificacin es AENOR. En el mbito de la seguridad de las TI, a partir de la OM/PRE 2740/2007, el CCN es Organismo de Certificacin del ENECSTI. La certificacin es el resultado del proceso. Declaracin de seguridad: Conjunto de requisitos y especificaciones de las propiedades de seguridad de un producto o sistema de las Tecnologas de la Informacin. Acreditacin: Declaracin de conformidad de los laboratorios solicitantes, emitida por el Organismo de Certificacin, en base al cumplimiento de los requisitos establecidos en el Reglamento. Una acreditacin permite legitimar a un sistema para formar parte de otros ms amplios. El objeto de la acreditacin es generar confianza sobre los Organismos de Evaluacin (laboratorios), garantizando la competencia tcnica de stos ltimos. La acreditacin consiste en un procedimiento de auditora y seguimiento. La OM/PRE 2740/2007 tambin define la acreditacin de competencia tcnica. Mientras que la acreditacin supervisa el cumplimiento de los requisitos establecidos en el reglamento, la Acreditacin de competencia tcnica supervisa los requisitos de la norma UNE 17025. El Organismo nacional reconocido de acreditacin y acreditacin de competencia tcnica es ENAC. ENAC acredita organismos como AENOR, ITV, Prestadores de Servicios de Certificacin, laboratorios... El CCN puede acreditar a los laboratorios la evaluacin de la seguridad, pero es requisito indispensable una acreditacin de competencia tcnica previa. La acreditacin es la confianza en el resultado del proceso. El esquema nacional de seguridad, en su artculo 18, especifica que se valorar positivamente los productos certificados para su adquisicin. La OM/PRE 2740/2007 aprueba el Reglamento de Evaluacin y Certificacin de las TIC que articula el Organismo de Certificacin del Esquema Nacional de Evaluacin y Certificacin de la Seguridad de

las Tecnologas de la Informacin (ENECSTI) en el mbito de actuacin del Centro Criptolgico Nacional. El Organismo de Cerificacin del CCN emite certificados "Common Criterias" reconocidos internacionalmente. Los Common Criterias, definidos en la norma ISO 15408, establecen 8 niveles aseguramiento de la evaluacin de seguridad que pretenden convalidar los niveles de otras normas internacionales como TCSEC e ITSEC. Seguridad. Criterios Comunes (CC) Los Criterios Comunes (Common Criteries) son un conjunto de normas y niveles cuyo objetivo es evaluar y, posteriormente, certificar la seguridad de productos o sistemas. Nacen como una iniacitiva para convalidar los criterios norteamericanos TCSEC y los criterios europeos ITSEC. En 1999 los criterios comunes son estandarizados como ISO/IEC 15408. Los CC permiten definir las funciones de seguridad de los productos o sistemas y evaluar dichas funciones. CC establece 8 niveles de aseguramiento que van de EAL0 a EAL7. Por ejemplo: EAL0 no ofrece garantas, EAL1 ha sido probado funcionalmente, EAL3 ha sido probado y chequeado metdicamente, EAL4 ha sido diseado, probado y revisado metodicamente y EAL7 ha sido diseado, probado y verificado formalmente. En el mbito de los sistemas de firma electrnica, los dispositivos seguros de creacin de firma suelen certificarse contra el nivel de aseguramiento EAL4+ (El + significa que est entre 2 niveles, EAL4 y EAL5). CC define TOE (Target of Evaluation) como el objeto a evaluar. CC define los PP (Protection Profile) como el conjunto de requisitos que se le exige a un sistema genrico. Tanto MAGERIT como el Esquema Nacional de Seguridad hacen referencia a los Criterios Comunes para certificar productos en materia de seguridad. Por ejemplo, en Espaa, INTECO, con el apoyo del CCN difunde la certificacin de seguridad sobre los perfiles de proteccin del DNI electrnico. Gracias a estos perfiles, el desarrollador de aplicaciones en materia de DNIe puede optar a una certificacin de nivel de aseguramiento EAL1 o EAL3. INTECO expone que el procedimiento operativo para alcanzar la certificacin a travs de los Criterios Comunes est descrito en la OM/PRE 2740/2007. Redes. Supernetting La tcnica de SUPERNETTING, tambin llamada de agregacin o reduccin de direcciones, basa el encaminamiento en mscaras de red ms cortas que la mscara de red natural de la direccin IP, en contraste con el subnetting, donde las mscaras de red son ms largas que la mscara natural. La sumarizacin permite reducir tamao de tablas de enrutamiento y por tanto, trfico de intercambio de informacin de enrutamiento porque posibilita que un router anuncie y tenga una nica entrada en la tabla para un conjunto de rutas. Para ello, los routers deben soportar CIDR (Classless Interdomain Routing - Enrutamiento Interdominio sin Clases), basado en el reparto de las redes clase C no asignadas an en bloques de tamao variable. De esta forma si una instalacin necesita 2000 direcciones se asignan 8 direcciones clase C contiguas en vez de una direccin clase B completa. En CIDR el encaminamiento no se realiza de acuerdo a la clase del nmero de red (de ah el trmino "classless": sin clase) sino slo segn los bits de orden superior de la direccin IP, que se denominan prefijo IP y viene dado por el nmero de bits a 1 de la mscara. Redes. Gestin SNMP SNMP (Simple Network Monitoring Protocol) es un protocolo utilizado para monitorizar el trfico de una conexin TCP-IP. Se ubica en el nivel de aplicacin de la torre de protocolos y funciona intercambiando informacin de administracin entre los nodos de red mediante mensajes UDP. Permite realizar anlisis de fallos, obtencin de estadsticas, supervisin y rendimiento de los elementos de la red... La versin actual de SNMP es la 3.0 SNMP trabaja como una arquitectura cliente/servidor donde destacan los siguientes componentes: Gestor SNMP, Agentes y Bases de Informacin Gestor SNMP. Es el nodo cliente. Inicia los comandos de interrogacin hacia el agente y recibe informacin del mismo. Escucha las traps en el puerto 162. Agente SNMP. Es el nodo servidor. Hay tantos agentes como dispositivos en la red a monitorizar. Controla el flujo de informacin entre el gestor y el dispositivo, enviando informacin peridica del estado del dispositivo al gestor SNMP. Las respuestas son llamadas traps y se envan por el puerto 162. El agente SNMP escucha en el puerto 161. Base de informacin de administracin (MIB). Un MIB es como una base de datos donde se almacen la informacin que recoge el gestor SNMP. Cada elemento tiene una estructura

definida y se describe mediante el lenguaje abstracto ASN1. Existe una variante evolucionada del IETF para sustituir a MIB llamada RMON (Remote Network MONitoring)

Redes. Secure Socket Layer (SSL) SSL (Secure Socket Layer) en su versin 3.0, es un protocolo de comunicacin seguro que sustituye al extinto S-HTTP y proporciona autenticacin, confidencialidad e integridad en las comunicaciones. Este protocolo, diseado por Netscape, se ubica entre las capas de transporte y aplicacin por lo que puede utilizarse junto con distintos protocolos como http o ftp. Por ejemplo, el puerto en que trabaja SSL con HTTP es el 443, con POP3 es el 995, con FTP es el 990. SSL proporciona sus servicios de criptosistemas combinando cifrado simtrico y cifrado asimtrico. Normalmente, se intercambia una clave de sesin mediante cifrado asimtrico al otro interlocutor y ste, al descifrar el mensaje obtiene la clave simtrica de sesin que utilizarn tanto emisor como receptor para intercambiar los datos del mensaje. Como medida adicional de seguridad, se usa una clave de sesin distinta para cada transaccin. SSL utiliza algoritmos de cifrado simtrico como DES de 56 bits, Triple-DES de 112 bits, RC2 y RC4 de 256 bits o IDEA. La autenticacin la realiza con cifrado asimtrico usando RSA de 1024 bits. Para la comprobacin de integridad, SSL trabaja con funciones Hash SHA. SSL versin 3 trabaja en 4 fases: 1. Client HELLO-Server HELLO. Saludo y negociacin de algoritmo simtrico a utilizar. Esto tambin es llamado Handshake o apretn de manos y se realiza con el subprotocolo que lleva su nombre. 2. Intercambio de certificados x.509v3 para comprobar al autenticidad del servidor. Slo se intercambian estos certificados si estn disponibles. Esta fase se puede ver como parte de la primera fase de Handshake. 3. Generacin de clave de sesin (a travs de una clave maestra que uno de los dos transmitir al otro para que ambos puedan generar la clave de sesin). El intercambio se realiza con criptografa asimtrica RSA y se comprobar su integridad mediante tablas Hash. En este momento se cede el control al subprotocolo Change Cipher Spec. 4. INTERCAMBIO DATOS. Verificacin de identidades e intercambio de datos mediante criptografa simtrica con la clave de sesin

Redes. IPSec IPSec (Internet Protocol Security). Es un estndar apoyado por el IETF que la aporta seguridad de que carece el protocolo IP. IPSec se ubica en el nivel de Red de la torre de protocolos y va incluido por defecto en IPv6. Entre sus mltiples usos se encuentra el de permitir la creacin de infraestructuras de redes privadas sobre redes pblicas (Por ejemplo en Redes Privadas Virtuales VPN). IPSec es un conjunto de protocolos agrupados en protocolos de seguridad, protocolos de gestin de claves y algortmos de cifrado: Protocolos de Seguridad en IPSec (spa, que no... ESP-AH) o AH: IP Authentication Header, proporciona integridad y autenticacin o ESP: IP Encapsulating Security Payload, proporciona adems confidencialidad Protocolos de Gestin de Claves en IPSec o IKE, Internet Key Exchange, permite a los nodos negociar protocolos e intercambiar claves Algoritmos de cifrado en IPSec o HASH: MD5 o SHA-1 o Criptografa simtrica: DES de 56 bits, Triple-DES de 112 bits, IDEA y Blowfish o Criptografa asimtrica: RSA o Certificados digitales: x509v3

IPSec puede trabajar en dos modos de operacin. Modo transporte y Modo tunel. Tanto AH como ESP proporcionan los dos modos de operacin. La diferencia estriba en que en el modo transporte slo se cifran y autentican los datos, incluyendo en el datagrama IP una cabecera ESP o AH.

Mientras, en el modo tunel, se genera un datagrama completo con cabecera ESP o AH en el que se incluye el datagrama IP original. El modo tunel es empleado por los gateways IPSec y por las redes privadas virtuales VPN (en muchas ocasiones empleado junto con los protocolos de nivel de enlace PPPT y L2TP) Redes. Opciones de seguridad en VPN Las diferentes opciones de seguridad en su implementacin son: PPTP, L2TP, IpSec en modo tunel y SSL: 1. PPTP (Point to Point Tunneling Protocol), de Microsoft es una extensin de PPP. Como ventajas tiene que trabaja a un nivel bajo de la capa OSI, concretamente a nivel de enlace. Como desventajas tiene que slo trabaja con redes IP y la seguridad se implementa con sistemas de autenticado PAP y CHAP 2. L2TP (Layer to Tunneling Protocol), de Cisco y Microsoft. Trabaja tambin sobre el nivel de enlace de OSI, pero como ventaja aporta que puede trabajar en redes distintas de IP como ATM y X.25. Adems de soportar las autenticaciones de PPP (CHAP y PAP), L2TP incorpora la opcin de los certificados digitales y criptografa asimtrica como ventaja sobre PPTP. Como desventajas tiene que sus caractersticas de seguridad lo hacen ms lento y la autenticacin slo se realiza en los puntos finales del tunel por lo que no podemos comprobar la integridad de la informacin. 3. IPSec (Internet Protocol Secure), trabajando en modo tunel trabaja en el nivel de red de OSI. En IPv6 va incorporado de serie. Slo permite trabajar con redes IP, como PPTP. Gracias al Internet Key Exchange, se le permite a los nodos negociar los protocolos y certificados de seguridad, haciendo a IPSec el medio ms seguro. Adems IPSec maneja mtodos de hashing, criptografa simtrica y asimtrica con multitud de algortmos. Como desventaja, se puede citar que no est implementado en sistemas de Microsoft anteriores a Windows 2000. 4. SSL (Secure Socket Layer). Este mtodo de VPN se realiza via web, por lo que ni el cliente ni el servidor requieren de ningn software vpn instalado en sus sistemas. Como desventaja tenemos que deberemos configurar adecuadamente el navegador para evitar la ejecucin de cdigo malicioso.

Redes. Diferencias entre IPv4 y IPv6 Ipv4 Espacio de direcciones lmitado a 32 bits (4 octetos) Ipv6 Espacio de direcciones ampliado a 128 bits (16 octetos repartidos en 8 bloques en hexadecimal)

Confidencialidad y Autenticado con IPSEC Confidencialidad y Autenticado aadiendo implementada de serie (de uso opcional IPSEC al nivel de red como en IPv4) Calidad de Servicio con el campo Type Of Service (TOS y tambin llamado Calidad de Servicio implementada de Servicios Diferenciados) para priorizar la serie en la cabecera con control de flujo entrega Cabecera compleja de 20 bytes Fragmentacin de paquetes en Host y Routers Realiza Checksum de la cabecera No escalable Organiza las direcciones en clases (A, B, Cabecera ms simple de 40 bytes La cabecera incluye una extensin para fragmentacin y reensamblado slo en Host No realiza Checksum (este se comprueba en otras capas) Escalable Permite arquitectura jerrquica de

C, ...)

direcciones Introduce direcciones anycast y mejora los mecanismos multicast, eliminando las direcciones broadcast (el multicast de IPv6, no enva paquetes a toda la red, slo a nodos predefinidos)

Usa direcciones multicast y broadcast

J2EE. Contenedores J2EE Los contenedores son mdulos software cuya funcin es prestar diferentes servicios a los componentes J2EE. Recordemos que los componentes J2EE segn la especificacin de Sun son: Componentes de aplicacin de cliente, Componentes applets de cliente, Componentes web de servidor como Servlets, JSP y JSF y Componentes EJB de negocio. Al igual que los componentes, los contenedores definidos por Sun son 4: Contenedor de aplicaciones, Contenedor de applets, Contenedor web y Contenedor de EJB. Los dos primeros estn relacionados con la parte cliente de la arquitectura multicapa, mientras que los dos ltimos se corresponden con la parte de servidor. Los servicios proporcionados por los contenedores pueden ser de seguridad, gestin de transacciones, servicios de directorios JNDI, invocacin remota de mtodos entre EJB, control de concurrencia, control de estados, gestin de persistencia, gestin de conexiones, cach, etc... Los servicios impiden que los componentes realicen llamadas directamente a las API, permitiendo la configuracin de estos servicios en la instalacin a travs de ficheros de configuracin. Los contenedores arrancan con el servidor. Algunos ejemplos de contenedores son el contenedor de servlets que permite, entre otras cosas, crear el objeto servlet con la llamada al mtodo init y, manejar distintos hilos de ejecucin para cada llamada al servlet. Tambin es claro el uso del contenedor de EJBs de Entidad cuando configuramos la persistencia manejada por el contenedor. De esta forma se instancia el descriptor definido en el constructor y libera al bean el control de la persistencia del objeto. Otro ejemplo de servicio en los contenedores EJBs es permitir la comunicacin de los mismos en entornos distribuidos mediante protocolos de comunicacin transparentes a los EJBs. J2EE. Componentes EJB Los EJB (Enterprise Java Bean) son componentes de servidor de J2EE que encapsulan la lgica de negocio y pueden ejecutarse en entornos distribuidos. Los EJB se ejecutan en un contenedor de EJB s que los abstrae de tareas de bajo nivel como comunicaciones, protocolos, persistencia, concurrencia de transacciones, seguridad... Este es el motivo por el cual es beneficioso para el programador usar EJB. Su uso es recomendado en los casos en que la aplicacin sea escalable, requiera gran seguridad y persistencia en las transacciones de los datos y en las aplicaciones con una gran concurrencia de clientes. Hay 3 tipos de EJB: a. Session Bean: Estos componentes llevan a cabo tareas especficas para un cliente. Opcionalmente pueden realizar servicios web. Los Session Bean no guardan persistencia. Dentro de los Session Bean podemos encontrar: o Stateless Session Bean: Son componentes sin estado que tienen la ventaja del ahorro de recursos de memoria, ya que para todos los clientes se comparte un objeto que no almacena informacin de la llamada del cliente. Son los ms indicados en funcionalidades ligeras. o Statefull Session Bean: Son componentes que almacenan el estado de la transaccin. De esta forma, son necesarios tantos objetos como transacciones se produzcan. En los casos de transacciones de larga duracin, la informacin se almacena temporalmente en disco. 1. Entity Bean: Son componentes que representan entidades de negocio que perduran en el tiempo (como entidades de bases de datos). Mantienen la persistencia que puede ser gestionada por el Bean (BMP o Bean Managed Persistance) o gestionada por el contenedor. Esta ltima opcin es la ms recomendable, liberando al programador de esa tarea. La

persistencia queda definida en un descriptor que se carga en el constructor del objeto y se destruye mediante el recolector de basura. 2. Message Driven Bean: Se utilizan para un tipo especial de mensajes en J2EE. Su funcionamiento es parecido al de los sessin bean, pero de manera asncrona. Se utilizan cunado las tareas son muy costosas en tiempo y no se sabe cuando se obtendr la respuesta. Su utilizacin ha facilitado el empleo de APIs como JMS ya que su funcionamiento es similar. La estructura interna de un EJB se compone de una interfaz llamada Business Interfaz, la implementacin de los mtodos de esta interfaz en una clase Enterprise Bean Class y las clases necesarias de apoyo al Bean. Adems es recomendable incluir el directorio META-INF con el fichero MANIFEST.MF y los XML descriptores de configuracin.

J2EE. JAR-EJB, WAR y EAR JAR-EJB: Empaqueta componentes EJB. Puede incluir clases de EJB, clases auxiliares. Incluye el descriptor de despliegue ejb-jar.xml WAR: Empaqueta aplicaciones Web. Puede incluir Servlets, JSP y JavaBeans, clases de negocio, paquetes JAR, Aplets y HTML. Incluye el descriptor de despliegue web.xml EAR: Empaqueta una o varias aplicaciones empresariales . Puede incluir paquetes WAR y JAR. Incluye el descriptor de despliegue application.xml Lenguajes de scripting. JSP Java Server Pages es una tecnologa para la creacin de contenido dinmico en la web. JSP forma parte de la arquitectura J2EE y es un lenguaje de programacin basado en etiquetas del lado de servidor que se ejecuta sobre un contenedor web. A nivel de arquitectura, JSP se encuentra en la capa Web de J2EE al mismo nivel que los Servlet, siendo considerado JSP una evolucin de estos ltimos ya que internamente, el cdigo JSP se traduce en un servlet que genera contenido dinmico. Los componentes de JSP son Scriptlets, variables JSP, directivas JSP y tags JSP: Scriptlets: Es cdigo JAVA embebido en las pginas JSP Variables implcitas JSP: No es necesario declararlas. Son page, pageContext, config, application, out, exception, session, request y response Directivas JSP: Se usan para configurar la pgina JSP. Las ms usadas son @page, @include y @taglib. @page especifica parmetros de la pgina a procesar como importacin de clases, control de sesin, pginas de errores, etc. @include permite incluir contenido de un fichero externo. @taglib permite usar etiquetas personalizadas que aportan funcionalidad extendida. Algunos ejemplos de taglib son JSTL de Sun o las taglib de apache incluidas en Struts. Tags JSP: Las etiquetas de jsp permiten, por ejemplo, redireccionar la pgina web con jsp:forward, incluir ficheros dinmicos con jsp:include. Adems los tags JSP pueden invocar mtodos de componentes reutilizables JavaBean con jsp:useBean, jsp:getProperty y jsp:setProperty

Las ventajas frente a ASP de Microsoft es que JSP el independiente de la plataforma en que se ejecuta, mientras que ASP depende de Internet Information Server y Sistemas Microsoft. ASP se escribe con lenguajes de programacin propietarios de Microsoft como JScript y Visual Basic Script. JSP puede extender las etiquetas y reutilizar tags de otros desarrolladores. Las ventajas de JSP sobre PHP son que est basado en Java que es un lenguaje orientado a objetos y PHP es un lenguaje rpido de Script con extensiones de programacin orientada a objetos. Adems JSP hace uso mediante los Beans de Java de toda la potencia de los componentes empresariales desarrollados en la arquitectura J2EE. Las ventajas frente a JavaScript son que ste ltimo es un lenguaje de scripting que se ejecuta del lado del cliente y, por lo tanto, no tiene acceso a los recursos del lado de servidor como el modelo de datos o componentes empresariales. Lenguajes de scripting. JavaScript JavaScript es un lenguaje interpretado del lado del cliente. Sus caractersticas ms importantes son: Fue creado por Netscape para su navegador y posteriormente, en la versin 1.2, estandarizado como ECMAScript-262

Hoy en da, la versin 1.5 de JavaScript se encuentra en la totalidad de los navegadores reconocidos Es un lenguaje basado en objetos y permite definir pseudoclases Es un lenguaje orientado a eventos (algunos de los ms conocidos onChange, onMouseOver, onLoad, onClick...) Es un lenguaje que podemos encontrar embebido en HTML a travs de las etiquetas <script> o importado de ficheros externos con la extensin .js Es dbilmente tipado, de forma que el tipo de datos de una variable depende del contexto y la asignacin de la misma Hace uso del estndar DOM (Document Object Model) para trabajar con XML y HTML Es case-sensitive para variables y funciones Su uso principal es el de proporcionar contenido dinmico a la web y validacin de formularios

Lenguajes de scripting. AJAX AJAX es el acrnimo de Asynchronous JavaScript And XML. AJAX no es un lenguaje de programacin, es una tecnologa para crear aplicaciones RIA (Rich Internet Applications) que aglutina una serie de tcnicas cuyo objetivo es devolver respuestas asncronas a peticiones http. AJAX trabaja con HTTP para el transporte de la informacin utilizando los mtodos GET y POST para las peticiones y el objeto creado por Microsoft XMLHTTPRequest. Normalmente AJAX hace uso de Javascript para escribir el control de peticiones y respuestas as como procesar estas respuestas a travs del uso de DOM (Document Object Model). AJAX puede funcionar en modo sncrono o asncrono, siendo este ltimo el ms atractivo ya que proporciona al usuario la experiencia de actualizar el contenido dinmico de la web sin necesidad de recargas en la pgina y re-orientando la interfaz en base a los eventos que provoca. Cuando se realiza una peticin con el objeto XMLHTTPRequest, el navegador sigue funcionando normalmente y, en segundo plano la peticin llega al servidor que la procesa y devuelve una respuesta. Esta respuesta puede ser en forma de texto plano haciendo uso de JSON o mediante XML. Al llegar la respuesta al navegador, ste reacciona de forma transparente al usuario y provoca que, normalmente una funcin programada en JavaScript, procese la respuesta y se vea reflejada en la pgina actual. Algunos problemas que presenta AJAX son los siguientes: El usuario no es consciente de que se est procesando su peticin El contenido cambia, pero la URL no. Esto puede llevar a confusin y a problemas de seguimiento y monitorizacin El botn 'Atrs' de los navegadores pueden provocar efectos inesperados en las webs con tecnologa AJAX Es necesario realizar una buena gestin de las excepciones y resultados de error para que el usuario conozca que ocurre con su peticin.

Lenguajes de programacin. Compiladores Un compilador es un software encargado de estudiar el cdigo fuente y transformarlo en cdigo objeto. Posteriormente, un linker o enlazador se encargar de recoger este cdigo objeto y combinarlo con las libreras necesarias y los recursos requeridos para conformar el programa ejecutable. El enlazador puede realizar sus tareas en tiempo de ejecucin dando como resultado el llamado enlazador dinamico o compilacin just in time. Por ejemplo el just in time de Java, llamado, HOTSPOT utiliza esta tcnica. La compilacin se realiza principalmente en dos fases, el anlisis y la sntesis: La fase de anlisis est formada por tres subfases de extraccin, construccin y verificacin del cdigo, mientras que la fase de sintesis conforma el cdigo objeto y lo optimiza. Veamos las fases detalladas: Anlisis o Front-End: 1. Anlisis lxico: Donde se realiza la extraccin de elementos del cdigo fuente y se separan las palabras reservadas de los operadores, variables y constantes. 2. Anlisis sintctico o parser: Donde se construye el rbol sintctico a partir de los elementos extraidos en el anlisis lxico y con ayuda de estructuras de datos reservadas y tokens.

3. Anlisis semntico: En esta fase se estudia el rbol semntico y se verifica su estructura para comprobar que est libre de errores y los tipos de datos se utilizan correctamente. Sintesis o Back-End: 1. Generacin de cdigo intermedio: Elabora el cdigo objeto del programa para una arquitectura determinada. 2. Optimizacin de cdigo: Optimiza el cdigo objeto para que se ejecute eficientemente en una arquitectura determinada.

Lenguajes de programacin. Lenguajes de cuarta generacin Mientras que en los lenguajes 3GL localizamos la programacin estructurada y orientada a objetos, los lenguajes 4GL se usan para automatizar el desarrollo. Inicialmente se usaban para describir los lenguajes no procedurales. Actualmente su uso abarca: Generador de Forms Generador de Reports o aplicaciones interfaz entre usuarios y BBDD Generador de cdigo desde herramientas CASE Administradores de datos como SAS, SPSS, SQL, QBE (Query by Example)

Algunos lenguajes y herramientas son Postgree 4GL OpenEdge, SQL for Business Intelligence, WinDev, PowerBuilder, Informix, Clipper, Rational, NATURAL, ... Gestin proyectos. Definicin y fases Un proyecto es un conjunto de recursos humanos y no humanos (tcnicos y financieros) organizados para realizar una serie de tareas dispuestas en una planificacin temporal para alcanzar un objetivo. Un proyecto est formado por 4 actividades: Gestin del proyecto, Desarrollo del proyecto, Operacin (explotacin y mantenimiento) y Control de proyecto (control de versiones y gestin de calidad). Las fases de la gestin del proyecto son (CERPS): 1. Comienzo del proyecto. En el cual se fijan los objetivos y aspectos crticos de un proyecto. Se usan tcnicas como Anlisis de factores crticos de xito y SADT (Structured Analysis and Design Technique). 2. Estimacin. Estimacin aproximada de recursos de personal, econmicos, fechas mediante tcnicas como los puntos funcin, staffing size, COCOMO 3. Anlisis y Gestin de Riesgos. Se analizan los riesgos del proyecto, riesgos de negocio, econmicos, tcnicos y de planificacin. 4. Planificacin. Se identifican y se dividen las tareas detectando sus dependencias, el esfuerzo de cada tarea, asignacin de recursos. Esto da como resultado una red de tareas que conforman la agenda del proyecto. Se utilizan tcnicas como WBS (Work Breakdown Structure), PERT (Program Evaluation and Review Technique), CPM y GANTT 5. Seguimiento y control. Seguimiento sobre los plazos, realizando anlisis de desviaciones en los plazos. Seguimiento de los resultados con tcnicas de gestin y garanta de calidad. Seguimiento sobre los costes econmicos.

Gestin de proyectos. Asignacin de recursos En la fase de planificacin de un proyecto, una de las tareas crticas es la asignacin de tareas a recursos. Se deber tener en cuenta: 1. Descomposicin total del proyecto en mdulos independientes y descomposicin de estos mdulos en tareas atmicas abordables por un recurso. Para ello nos podemos ayudar de la tcnica WBS (Estructura de descomposicin de trabajo) 2. Delimitar el proyecto en el tiempo. 3. Asignar una tarea a un recurso cada vez, buscando la plena ocupacin de los recursos. 4. Tener en cuenta la dificultad de las tareas y la experiencia y capacidad de los recursos. De esta forma asignaremos tareas sencillas a recursos con menos experiencia o capacidad y, a

su vez, asignaremos tareas ms complejas a los miembros del equipo ms experimentados. Esto previene la desmotivacin y el fracaso. 5. Hacer uso de tcnicas de planificacin como diagrama de Gantt para realizar la asignacin de tareas a recursos y tener la visin temporal del proyecto. A su vez, vigilar que no existen vacos en el diagrama. 6. Realizar un Histograma de recursos, que nos da el nmero de recursos que necesitamos en cada momento del proyecto. 7. Realizar un patrn de lmites de recursos que nos da el estado de cada recurso en funcin de las fases de arranque, pleno rendimiento y fin del proyecto. Esto nos permite reorganizar la asignacin de recursos o conocer el tiempo, en meses, que un recurso participar en el proyecto.

Gestin proyectos. Tcnicas de estimacin de proyectos: COCOMO La gestin de un proyecto supone una fase previa de estimacin de la duracin, coste y recursos necesarios y una fase de planificacin. En cuanto a la fase de estimacin podemos emplear diferentes tcnicas directas como las basadas en Lneas de Cdigo o indirectas como las basadas en Puntos de Funcin. Mtrica hace referencia COCOMO, Staffing Size y Puntos de Funcin. COCOMO: Es un mtodo de estimacin del esfuerzo de los proyectos software. COCOMO es una medida de comparacin entre proyectos que pueden clasificarse dependiendo del tamao y experiencia en: bsico, intermedio y avanzado o detallado. Cada uno de estos submodelos es aplicado a tres tipos de software: rgnico: Proyectos pequeos (hasta 50.000 lneas de cdigo) de los que se tiene bastante experiencia Semiacoplado: Proyectos intermedios con restricciones intermedias Empotrado: Proyectos grandes y complejos sin mucha experiencia para afrontarlos.

COCOMO emplea una serie de frmulas basada en las lneas de cdigo y coeficientes con valores estudiados para cada uno de los casos anteriores con la que se obtiene el esfuerzo medido en persona/mes y el tiempo de duracin del proyecto medido en meses. Las lneas de cdigo se miden por millares. La desventaja de este mtodo es su gran dependencia a cada lenguaje de programacin. Gestin proyectos. Tcnicas de estimacin de proyectos: STAFFING SIZE, PUNTOS FUNCIN STAFFING SIZE: Es una medida de estimacin de personas necesarias para afrontar un proyecto orientado a objetos. La medida fundamental de esta tcnica es el nmero de clases de la aplicacin. Esto hace que usar la tcnica de Staffing Size dependa en gran medida de la tecnologa y lenguaje de programacin empleado. Se consideran varios tipos de clases. Clases clave, son las clases que se detectan en fase de anlisis y tienen un alto valor en el modelo de negocio. Las clases clave suelen representar entre un 20 y un 40% del total de las clases. Las clases de soporte o secundarias, son clases prescindibles en el modelo. Se pueden incluir en las clases secundarias, las relativas a interfaces de usuario y habituales en lenguajes de programacin. El nmero de clases soporte suele ser de uno a tres veces el total de clases clave. Staffing Size considera que, un desarrollador puede tener una clase en produccin, en 10 o 15 das incluyendo documentacin y pruebas unitarias. Tambin considera que de 6 a 8 das se puede obtener un prototipo de clase. PUNTOS DE FUNCIN: Se centra en los valores de dominio de la informacin (entradas y salidas externas, archivos lgicos internos, archivos de interfaz externos). La ventaja de los puntos de funcin frente a otras tcnicas es que no dependen del entorno tecnolgico ni del lenguaje de programacin.