Ingeniero en Informtica e I. T. Gestin. Tercer curso. Facultad de Informtica. Universidad de Murcia. Prcticas de Fundamentos de Ingeniera del Software. 2004/2005.

Prctica 1: Anlisis con Mtrica 3

Objetivos
Utilizar la metodologa Mtrica 3 (en su vertiente estructurada) en la especificacin de los requisitos de una aplicacin. Dominar los conceptos fundamentales del Anlisis Estructurado. Crear un prototipo de interfaz de la aplicacin.

Caso de estudio - Docentes@murcia.net

El analista de sistemas de la Fundacin X adscrita a la CARM (Comunidad Autnoma de la Regin de Murcia) ha recibido el encargo de desarrollar un portal de contenidos educativos para los docentes de la Regin. Tras diversas entrevistas con el Director General de Formacin Profesional e Innovacin Educativa y con tcnicos adscritos a dicha Direccin General, con el director del CPR (Centro de Profesores y Recursos) de Molina de Segura y con diversos representantes del mbito docente (directores, profesores, maestros y padres de alumnos), el analista se encuentra imbuido en el proceso de ordenar las notas que ha ido tomando sobre los objetivos del proyecto y estructurar la informacin que ha asimilado con el fin de plantear un primer informe de necesidades. A da de hoy, el estado de sus notas es el siguiente: Introduccin La Consejera de Educacin y Ciencia pretende desarrollar un portal cuyo principal objetivo sea ofrecer servicios y contenidos que contribuyan a la mejora del sector educativo. DOCENTES@MURCIA.NET ser el nombre del portal educativo, cuyas pginas estn abiertas a la participacin de la comunidad educativa, instituciones, centros, profesorado y asociaciones de padres, madres y alumnos/as de Murcia. Adems de la informacin institucional y de Murcia como espacio educativo, DOCENTES@MURCIA.NET har un recorrido por los centros, las nuevas tecnologas, los programas de formacin del profesorado y las ayudas e iniciativas comunitarias. Este proyecto forma parte de un proyecto de mbito superior denominado PLUMIER (http://www.f-integra.org/plumier/plumier.swf), que pretende la integracin de las Tecnologas de la Informacin y de las Comunicaciones (TICs) en el proceso educativo en la Regin, de forma que toda la comunidad educativa posea los conocimientos necesarios para vivir y trabajar en la sociedad de la informacin, erradicando el analfabetismo tecnolgico, eliminando la distancia como barrera en el sistema educativo y prestando especial atencin a las personas discapacitadas.

La Consejera de Educacin y Cultura ha desarrollado una primera versin de este portal educativo (www.educarm.es), que ya est en servicio. La ventana principal se puede observar en la Figura 1.

Figura 1. El portal educativo educarm.es El entorno web que se muestra en la Figura 1 proporciona un conjunto de recursos relativos al mbito docente de la Regin, como por ejemplo listas de distribucin, foros, legislacin, concursos, etc. En el sistema existen bsicamente usuarios de dos tipos, a saber: administradores y usuarios docentes. En la Figura 2 se muestra una ventana con el rea restringida de la aplicacin, que es accesible tanto para usuarios docentes como para administradores, despus de introducir su login y password. Evidentemente, los administradores dispondrn en la pgina de administracin de su rea restringida de ms recursos a administrar que los usuarios docentes, que slo pueden acceder a foros y tablones de anuncios (ver Figura 3). Las opciones comunes para usuarios docentes y administradores son las siguientes: correo electrnico, listas de correo, pgina web, cambiar clave y administracin.

Figura 2. rea restringida de educarm.es. Cada centro docente y por tanto cada profesor de secundaria o maestro de primaria est adscrito a lo que se denomina un Centro de Profesores y Recursos (CPR), que gestiona los recursos formativos, pedaggicos y didcticos de una zona geogrfica determinada. En la CARM existen 7 CPRs, como se muestra en la Figura 1. Cada CPR tiene una pgina web que sirve para informar sobre los distintos cursos, seminarios, proyectos, etc. aprobados para el curso acadmico actual. Actualmente estas pginas web son independientes del entorno educarm, si bien estn homogeneizadas sus interfaces, cosa que no ocurra antes.

Figura 3. Opcin de Administracin en el rea restringida de un usuario docente.

Objetivos del proyecto Se pretende desarrollar un nuevo proyecto que tome como base el desarrollo actual ya en explotacin (www.educarm.es), al cual se le quiere dotar de nueva funcionalidad manteniendo los servicios ya existentes. El proyecto consta, por tanto, de una parte de ingeniera inversa, para obtener los modelos de anlisis a partir de la aplicacin actual. En primer lugar, se podra considerar que todos recursos gestionados en la primera versin del portal comparten un patrn comn de manejo o gestin, que denominaremos gestin de recursos documentales, y que describimos con ms detalle en un apartado posterior. En segundo lugar, consideramos que las aportaciones adicionales de esta segunda versin, que no se han incorporado en la primera, son las siguientes: El concepto de CAP, Centro de Apoyo al Plumier, que permitira liberar a los docentes de los centros de la gestin de las incidencias informticas no triviales. El concepto de aula virtual, que en resumen gestionara de forma individualizada cursos de formacin para docentes destinados a la mejora de su formacin y por ende de la calidad de la enseanza en la Regin.

En los siguientes apartados se describen en detalle cada una de estas funciones. Gestin de Recursos Documentales Como se muestra en el men de la pgina web (Figura 1), el portal proporciona acceso a diversos recursos educativos, que se organizan en grupos temticos. Grupos temticos son, por ejemplo, los siguientes: enlaces de inters, unidades didcticas, presentaciones multimedia, opiniones, software de libre distribucin, tabln de anuncios, etc. (ver Figura 4). En general, podemos decir que la gestin de todo recurso documental involucra las siguientes operaciones (no necesariamente en este orden): alta, baja (no fsica, es preciso llevar un historial que se pueda consultar), modificacin, publicacin, consultas. Por ejemplo, en el rea de Noticias, nos encontramos con un administrador de noticias, que puede solicitar la publicacin de noticias de inters para el mundo educativo. Otro administrador por encima de ste, el administrador regional de noticias, se encarga de dar el visto bueno a la publicacin de aquellas noticias que considere de mayor inters entre todas las solicitudes, as como dar de baja noticias. Toda noticia publicada o dada de baja se puede encontrar en un Historial de noticias, en el cual se pueden efectuar bsquedas. Toda noticia tiene una fecha de publicacin, que determina su vida mxima (actualmente, un mes). La pgina de noticias tiene un nmero limitado de noticias que pueden ser publicadas, con lo cual la publicacin de una nueva noticia implica la baja de la ms antigua si no queda espacio. Este ejemplo de la gestin de noticias particulariza el marco general de gestin de los recursos que se ha mencionado anteriormente. Los analistas del proyecto tendrn que plantearse la gestin de cada uno de los recursos, dado que en las reuniones con los promotores de la aplicacin stos no han mostrado inters en llegar hasta un alto nivel de detalle en la descripcin de cmo se ha de producir la gestin de cada recurso.

Figura 4. Recursos educativos organizados por reas temticas. El hecho de que los clientes no tengan claros los requisitos de gestin de los recursos, hace candidato al sistema al uso de prototipos para intentar llegar a un acuerdo sobre el portal que se quiere desarrollar antes de dedicar muchos recursos a la construccin del mismo. En principio, en el presente proyecto se pretende centrar los esfuerzos en la gestin de los siguientes recursos: noticias, foros de discusin, recursos didcticos (unidades didcticas y presentaciones multimedia), actividades de formacin del profesorado (ver apartado Aula Virtual) y lgicamente usuarios. La gestin de estos recursos es obligatoria. La gestin de ms recursos a los sealados ser opcional y har que el resultado del proyecto tenga un valor mayor. El entorno educativo proporciona una vista pblica de los recursos mencionados en el apartado anterior y un rea restringida que solo podr ser accedida previa validacin. En el sistema nos encontramos definidos diversos administradores, cada uno de los cuales tiene asociado un perfil que determina qu recursos administra y a qu nivel los administra. En el sistema existe tambin la figura del usuario docente, al cual la Consejera, a travs de este entorno, le proporciona un rea web, con una cuota (espacio de almacenamiento) fijada, que podr gestionar libremente (podr pedir una ampliacin de la misma); un buzn de correo, que el usuario podr utilizar a travs de algn lector de correo externo, que todava no se ha determinado; unas listas de distribucin y un rea de administracin reducida a tabln de anuncios y foros. Un administrador tendr los mismos recursos que un usuario docente, pero en funcin de su perfil tendr la capacidad de administrar determinados recursos a determinados niveles. Por ejemplo, el administrador de noticias, en la parte de administracin, tendr un enlace al proceso de gestin de noticias, cuya funcionalidad se ver condicionada segn sea un administrador de noticias regional o local.
5

En resumen, podemos encontrarnos en el sistema con usuarios de dos tipos: 1.- Usuarios Docentes: Qu hacen? Acceso a determinadas listas de distribucin. Si quieren participar en alguna de ellas debern solicitar su admisin al administrador de esa lista. Subir pginas a su sitio web y pedir a su administrador (el que cre al usuario docente) un aumento de cuota. Acceso al sistema de gestin de correo POP3 de educarm.es. Administrar: o Foros: Acceder a determinados foros y poder responder, considerando que la respuesta deber ser validada por el administrador o propietario de dicho foro. o Tablones de anuncios: Aadir un nuevo anuncio a un determinado tabln. Dicho anuncio deber ser validado por el administrador del tabln. 2.- Administradores: Qu hacen? Lo mismo que los usuarios docentes, y adems... En la zona de administracin se aadirn enlaces asociados a los recursos que gestiona el administrador, accediendo a cada uno de ellos con un cierto nivel de gestin (por ejemplo, un enlace de "Noticias" a nivel Administrador no regional).

En ambos casos, usuario docente y administrador, existir un enlace a la zona de Aula Virtual (ver seccin correspondiente de este enunciado). Sistema de Gestin de Incidencias (Centro de Apoyo al Plumier, CAP) Este subsistema pretende posibilitar la asistencia tcnica descentralizada por comarcas, liberando al docente, y ms concretamente a los profesores responsables de medios informticos (RMIs), de las tareas de mantenimiento ms complicadas. Las posibles averas o problemas de configuracin en los equipos y redes sern atendidas por personal del Centro de Apoyo al Plumier (CAP) externo al centro. Deber existir un tcnico por cada uno de los CPRs de la Regin, y dos ms de apoyo a las zonas de mayor necesidad en cada momento (9 tcnicos en total). El procedimiento establecido para la notificacin de incidencias al CAP se realizar a travs de educarm.es, rellenando una ficha de notificacin. En un breve plazo de tiempo, el CAP, apoyado por la empresa adjudicataria del contrato de renting, debe resolver la mayora de los problemas. La automatizacin de incidencias a travs del portal permite controlar las causas de averas ms frecuentes, su localizacin geogrfica y el tiempo de respuesta. Ms concretamente, tenemos que: Cada centro tiene asociado un docente denominado RMI (Responsable de medios informticos). Cuando dentro del centro se produce algn tipo de incidencia informtica, sta se comunica al RMI. Si la avera es tan simple que el RMI puede solucionar directa y rpidamente la incidencia, lo hace, y si no, crea una incidencia para el CAP. El RMI constituye un tipo o perfil de administracin que, por tanto, puede dar de alta una incidencia para el CAP. El centro estar asociado a un CPR.
6

En el CPR existe un responsable del CAP, el cual se encarga de gestionar las incidencias que cualquier RMI le formule y que pertenezca al rea geogrfica del CPR en el que se encuentre. Una incidencia tiene asociado un RMI, una descripcin, una fecha de alta, un estado (pendiente, en trmite, resuelta, cancelada), un centro y un CPR. Despus de su resolucin, la incidencia debe tener asociada una causa y un tiempo de respuesta. El RMI del centro docente podr ver las incidencias actuales y el estado en el que se encuentran, con la posibilidad de consultar un histrico correspondiente a las incidencias del centro al que pertenece. Existe un responsable de los CPRs que se encuentra en la Consejera y que se encarga de generar diversas estadsticas.

Aula virtual Se pretende mejorar la formacin de los docentes de la Regin a travs de la oferta de un conjunto de cursos que puedan ser de inters para ellos: se ofertarn tanto cursos pedaggicos como tcnicos. Se busca que cada CPR tenga un administrador de cursos, que ser el responsable de gestionar todos los cursos que ofrezca el CPR. Los cursos se pueden dividir en tres categoras: presenciales, no presenciales y virtuales. Estos ltimos son aquellos cuyo desarrollo es monitorizado por el sistema. El portal debe posibilitar a los docentes realizar la preinscripcin en un curso, y al administrador seleccionar los alumnos admitidos al curso, que luego debern realizar la matrcula definitiva. El administrador realizar la seleccin en virtud de una serie de criterios de admisin, que se debern aplicar ordenadamente a los aspirantes. En principio, todos los cursos son gratuitos por lo que no se considera necesario introducir el concepto de beca. La matrcula se puede considerar, por tanto, ms que nada como una confirmacin del deseo de asistir al curso. Los docentes que habiendo sido admitidos a un curso no lo realizaran, sern penalizados al ao siguiente, en el que no podrn optar a ningn curso. Un docente podr matricularse en hasta cinco cursos en un mismo ao. Cuando un docente realiza una matriculacin en un curso virtual, acto seguido recibe un correo electrnico con un login y una clave. Del apartado anterior se deduce que los cursos pasan por los siguientes estados: preinscripcin, matriculacin, en desarrollo, finalizado. Adems, un curso puede pasar al estado cancelado si no obtiene el nmero mnimo de alumnos, o por alguna razn de fuerza mayor durante su desarrollo. Slo el administrador puede cancelar cursos. El portal se encargar de la gestin de los cursos virtuales, que podrn ser representados mediante el siguiente conjunto de atributos: nombre descripcin mbito [CPR | regional] * el curso puede ser ofertado slo dentro del mbito comarcal del CPR o para toda la regin * fecha de inicio duracin programa de teora: tema 1...tema N, con hipervnculos entre los apartados de los temas programa de prcticas: prctica 1...prctica N (una prctica por tema)
7

tutor (que propone el curso al administrador y se encarga de su evaluacin) una lista de criterios estndar con su prioridad: (Criterio_admisin_1, Prioridad1), ..., (Criterio_admisin_n, Prioridad_n), donde cada criterio pertenece al conjunto de los criterios vlidos en el sistema. Cuando el usuario se preinscriba ver una lista con todos los criterios, y tendr que indicar cules posee. Un mensaje le indicar al usuario que la matriculacin podr implicar una posible justificacin de dichos criterios, incluso de manera presencial.

El docente que se haya matriculado en un curso virtual podr entrar al rea restringida del sistema con su login y su password generales. En esta rea aparecer un icono con el nombre de aula virtual, y al pinchar en l le aparecer una lista con todos los cursos en los que se ha matriculado y que estn en desarrollo. El usuario podr pinchar en uno de sus cursos virtuales, y tras autenticarse con el login y password del curso, entrar en un escritorio virtual en el que se mostrar el desarrollo del curso para este usuario, que podr as retomar el trabajo donde lo haba dejado. Cada curso tiene un foro de discusin asociado, moderado por el tutor, en el que los alumnos pueden preguntar dudas, exponer comentarios, conclusiones, etc. Tras cada tema, se activar la prctica correspondiente y se abrir un periodo para que el alumno pueda completarla. Una prctica podr constar de varios ejercicios. Los ejercicios completados podrn ser evaluados automticamente si son tipo test, o sern reenviados al tutor del curso para su correccin. Cada ejercicio tendr un peso determinado en la evaluacin de la prctica, y cada prctica un peso determinado en la evaluacin del curso. Cuando un ejercicio se corrige, se remite al estudiante junto con su calificacin y los resultados correctos (si era tipo test) o los comentarios del tutor (si fue ste el encargado de corregir el ejercicio). Si el ejercicio no est aprobado se conceder al estudiante un intento ms para realizarlo correctamente. Una vez que termine el curso, cuando el tutor del mismo lo crea conveniente (usualmente unos pocos das despus de su finalizacin) se enviar a todos los matriculados un correo electrnico informando de la finalizacin del curso y de su calificacin final. Si un matriculado ha aprobado el curso, el administrador de cursos del CPR se encargar de enviarle un correo postal con el certificado de aprovechamiento correspondiente, firmado por el tutor del curso.

Descripcin del trabajo prctico

Consideremos viable el proyecto descrito en el apartado anterior. En esta prctica se debe seguir el proceso de Anlisis de Sistemas de Informacin (ASI) de Mtrica 3 (desarrollo estructurado) para especificar los requisitos del caso prctico Docentes@Murcia.net. El director del proyecto ha decidido que la estructura de la documentacin resultante de aplicar el proceso ASI deber incluir los siguientes apartados: ERS (Especificacin de Requisitos del Software) mbito y alcance Catlogo de requisitos Glosario de trminos Catlogo de normas Descripcin general del entorno tecnolgico Contexto del sistema Descripcin de subsistemas Modelo de procesos Modelo de datos Especificacin de interfaz de usuario Durante la elaboracin del ERS se deben seguir las siguientes pautas: Por favor, leed cuidadosamente este apartado antes de comenzar a trabajar en la prctica y antes de entregar la documentacin final. El alumno puede enriquecer o cambiar la especificacin del problema a partir de su conocimiento del problema planteado, pero debe discutirlo con el profesor. En los casos, si los hubiera, de que el enunciado del problema sea ambiguo o no sea lo suficientemente completo, el grupo deber recoger por escrito las suposiciones que se adopten, indicando las razones de la eleccin, si fuera necesario. El alumno tambin puede enriquecer el formato de ERS que debe entregarse como resultado de la prctica. La documentacin de la prctica se debe elaborar usando System Architect 2001, entregando los resultados en papel y en un disquete que contenga la enciclopedia y el informe correspondiente. Toda la documentacin necesaria para la comprensin de la prctica se debe incluir en papel. La portada de la documentacin debe incluir: cdigo de grupo (disponible en el web y en los tablones de clase), los nombres de los integrantes del grupo, una direccin de e-mail de contacto, la titulacin, el nombre de la asignatura y el nombre del profesor de prcticas. Para no dar lugar a listados en papel muy extensos, en el informe en papel de la enciclopedia recomendamos obviar todos aquellos campos que no sean relevantes o que estn en blanco. En el apartado de mbito y alcance del ERS que se propone, se deberan tratar los siguientes aspectos:

o Identificacin. Este apartado debera contener una identificacin completa del sistema y del software que se va a producir, incluyendo su nombre y nmero de versin. o Breve descripcin del sistema. Este apartado debera establecer brevemente el propsito del sistema y del software sobre el cual se aplica el documento ERS, incluyendo beneficios y objetivos del desarrollo. Se debe indicar expresamente qu har el producto software y, en su caso, qu no har. En este apartado se debera describir la naturaleza general del sistema y del software; resumir la historia de desarrollo, operacin y mantenimiento del sistema; identificar el promotor del proyecto, comprador, usuario, desarrollador; identificar los lugares de explotacin del producto actuales y planeados; y listar cualquier otro documento relevante para el conocimiento del sistema. o Breve descripcin del documento. Este apartado debera resumir el propsito y contenidos del documento ERS y debera describir las consideraciones de seguridad y de privacidad asociadas con su uso, si las hubiera. Recuerda que en el Catlogo de requisitos los requisitos deben estar identificados de forma nica (por ejemplo, con un nmero) y deben ser priorizados (por ejemplo, prioridad alta requisito obligatorio, media requisito recomendable, o baja requisito opcional). Recuerda que los requisitos en el Catlogo de requisitos deben estar agrupados a partir de algn criterio. Por ejemplo, se puede organizar los requisitos por funciones, de manera que exista una correspondencia entre los procesos de los DFDs y los apartados del catlogo de requisitos. Lo que no debe ocurrir es que se presente el Catlogo de requisitos como una lista nica (y probablemente muy extensa) de requisitos, sin estructura, dado que ese tipo de largas listas de la compra son muy difciles de usar. El Glosario de trminos deber definir los trminos necesarios para comprender adecuadamente el Catlogo de requisitos. Aunque se puede generar con System Arhitect 2001, recomendamos su realizacin mediante un procesador de textos. Como sabemos, la Descripcin de subsistemas de anlisis se corresponde con una descripcin del DFD 0. Presta una especial atencin a realizar una descomposicin en subsistemas coherente. En el Modelo de procesos del sistema, se debe entregar un modelo lgico de los procesos del nuevo sistema de informacin. Se deben usar pre y post-condiciones en las miniespecificaciones de los procesos primitivos, pero en un par de procesos no triviales tambin se debe ilustrar el uso de lenguaje estructurado. Obviamente, es requisito indispensable respetar las reglas sintcticas del anlisis estructurado. Recuerda que el modelo de procesos y el modelo E/R deben estar balanceados. En el Modelo de datos, slo se deber realizar un modelo conceptual utilizando el modelo entidad/relacin extendido (no se debe realizar el modelo lgico ni el modelo lgico normalizado). Dado que la herramienta CASE que usamos, System Architect 2001, utiliza una notacin para el modelado de datos que est ms cerca del nivel lgico que del nivel conceptual, recomendamos realizar el modelo de datos con lpiz y papel. La Especificacin de interfaz de usuario contendr un prototipo de interfaz de la aplicacin, que debe incluir (al menos) los cuadros de dilogo y los informes ms importantes. Para ello se pueden utilizar los diagramas de System Architect Menu y
10

Graphic Screen, pero recomendamos el uso de una herramienta que permita la edicin de documentos HTML. Si los alumnos prefieren usar cualquier otra herramienta para generar el prototipo de interfaz, pueden hacerlo.

Contenidos de entrega opcional. Cada grupo puede ampliar la prctica de acuerdo con sus intereses, abordando alguno de los puntos que listamos a continuacin: Siguiendo la aproximacin de (Yourdon 93)1, se pide el modelo ambiental y el modelo de comportamiento del modelo esencial del sistema (usando el mtodo de particin de eventos). Modelo de casos de uso. Consiste en estructurar los requisitos funcionales del catlogo de requisitos de Mtrica 3 mediante casos de uso, e investigar las implicaciones en el desarrollo posterior (estructurado). Se puede utilizar cualquier plantilla publicada para especificar los casos de uso, por ejemplo, la de Coleman. Los diagramas HVE de las principales entidades del sistema. Para asegurar la coherencia entre HVEs y DFDs, indica cmo se reflejan los eventos del diagrama HVE en los DFDs del sistema. Siguiendo el proceso DSI de Mtrica 3, disear la estructura modular del sistema, usando diagramas de estructura. Cada grupo puede realizar otras aportaciones a la prctica que sean de su inters, aportaciones que deber discutir primero con el profesor.

Yourdon, E., Anlisis estructurado moderno. 1993: Prentice-Hall Hispanoamericana. El proceso de anlisis. Captulos 17-20. 11