Practica Con Metrica V3

Ingeniero en Informática e I. T. Gestión. Tercer curso. Facultad de Informática. Universidad de Murcia. Prácticas de Fundamentos de Ingeniería del Software. 2006/2007. Profesor: Juan Antonio López Quesada.

Caso Práctico: Análisis con Métrica 3 Objetivos • Utilizar la metodología Métrica 3 (en su vertiente estructurada) en la especificación de los requisitos de una aplicación. • Dominar los conceptos fundamentales del Análisis Estructurado. • Crear un prototipo de interfaz de la aplicación.

1

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

Esquema.Objetivos ............................................................................................................ 1 Esquema.- .......................................................................................................... 2 1.- Metodología del Desarrollo del Software Métrica 3....................................... 3 1.1.- Introducción. ........................................................................................... 3 1.2.- Planificación del Sistema de Información. PSI. ...................................... 5 1.3.- Estudio y Evaluación del Sistema. EVS.................................................. 7 2.- Caso de Estudio: Ordenadores para todos. .................................................. 9 Descripción General ....................................................................................... 9 Beneficiarios, requisitos y obligaciones. ....................................................... 10 Conceptos susceptibles de ayuda y cuantía de la subvención. .................... 10 Oficina municipal. ......................................................................................... 11 Solicitud y validación..................................................................................... 11 Instrucción del procedimiento. ...................................................................... 13 Resolución del procedimiento....................................................................... 16 Otras consideraciones. ................................................................................. 16 3.- Descripción del trabajo práctico. ................................................................. 17 4.- Durante la elaboración del ERS se deben seguir las siguientes pautas. .... 18 5.- Trabajos Opcionales de estudio/investigación. ........................................... 20 6.- Esquema de las actividades ASI y DSI. ...................................................... 21 6.1.- Esquema de ASI: Análisis del Sistema de Información. ....................... 21 6.2.- Esquema de DSI: Diseño del Sistema de Información. ........................ 22 7.- Entregables en la etapa ASI-DIS. ............................................................... 23

2

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

1.- Metodología del Desarrollo del Software Métrica 3. 1.1.- Introducción.

La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos: ¾ Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos. ¾ Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos. ¾ Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible. ¾ Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos. ¾ Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

3

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

La nueva versión de MÉTRICA contempla el desarrollo de Sistemas de Información para las distintas tecnologías que actualmente están conviviendo y los aspectos de gestión que aseguran que un Proyecto cumple sus objetivos en términos de calidad, coste y plazos. Su punto de partida es la versión anterior de MÉTRICA de la cual se han conservado la adaptabilidad, flexibilidad y sencillez, así como la estructura de actividades y tareas, si bien las fases y módulos de MÉTRICA versión 2.1 han dado paso a la división en Procesos, más adecuada a la entradatransformación-salida que se produce en cada una de las divisiones del ciclo de vida de un proyecto. Para cada tarea se detallan los participantes que intervienen, los productos de entrada y de salida así como las técnicas y prácticas a emplear para su obtención. En la elaboración de MÉTRICA Versión 3 se han tenido en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares de ingeniería del software y calidad, además de referencias específicas en cuanto a seguridad y gestión de proyectos. También se ha tenido en cuenta la experiencia de los usuarios de las versiones anteriores para solventar los problemas o deficiencias detectados. En una única estructura la metodología MÉTRICA Versión 3 cubre distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a través de interfaces la realización de los procesos de apoyo u organizativos: Gestión de Proyectos, Gestión de Configuración, Aseguramiento de Calidad y Seguridad. La automatización de las actividades propuestas en la estructura de MÉTRICA Versión 3 es posible ya que sus técnicas están soportadas por una amplia variedad de herramientas de ayuda al desarrollo. Además, para facilitar la utilización de MÉTRICA Versión 3 se ha desarrollado una herramienta software, Gestor Metodológico, de ayuda a la aplicación de la metodología en cada proyecto concreto y que permite adaptar la estructura de MÉTRICA Versión 3 de acuerdo a las características del mismo, permitiendo el seguimiento y control de sus actividades y tareas realizadas por distintos perfiles de usuario asignados a los participantes por el jefe de proyecto. Se ha desarrollado también un software, Selector de Herramientas, que ayuda a seleccionar entre las CASE del mercado la que mejor se adapta a las necesidades de cada proyecto teniendo en cuenta las características de cada organización. Tanto la metodología como todas estas herramientas estarán disponibles en la web del Consejo Superior de Informática: http://www.map.es/csi

4

1.2.- Planificación del Sistema de Información. PSI. El Plan de Sistemas de Información tiene como objetivo la obtención de un marco de referencia para el desarrollo de sistemas de información que responda a los objetivos estratégicos de la organización. Este marco de referencia consta de: ¾ Una descripción de la situación actual, que constituirá el punto de partida del Plan de Sistemas e Información. Dicha descripción incluirá un análisis técnico de puntos fuertes y riesgos, así como el análisis de servicio a los objetivos de la organización. ¾ Un conjunto de modelos que constituya la arquitectura de información. ¾ Una propuesta de proyectos a desarrollar en los próximos años, así como la prioridad de realización de cada proyecto. ¾ Una propuesta de calendario para la ejecución de dichos proyectos. ¾ La evaluación de los recursos necesarios para los proyectos a desarrollar en el próximo año, con el objetivo de tenerlos en cuenta en los presupuestos. Para el resto de proyectos, bastará con una estimación de alto nivel. ¾ Un plan de seguimiento y cumplimiento de todo lo propuesto mediante unos mecanismos de evaluación adecuados. La perspectiva del plan debe ser estratégica y operativa, no tecnológica. Para la elaboración del Plan de Sistemas de Información se estudian las necesidades de información de los procesos de la organización afectados por el Plan, con el fin de definir los requisitos generales y obtener modelos conceptuales de información. Por otra parte se evalúan las opciones tecnológicas y se propone un entorno. Tras analizar las prioridades relacionadas con las distintas variables que afectan a los sistemas de información, se elabora un calendario de proyectos con una planificación lo más detallada posible de los más inmediatos. Además, se propone una sistemática para mantener actualizado el Plan de Sistemas de Información para incluir en él todos los cambios necesarios, garantizando el cumplimiento adecuado del mismo. A continuación se incluye un gráfico que representa la secuencia de actividades del proceso PSI.

5

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

6

1.3.- Estudio y Evaluación del Sistema. EVS Mientras que el Plan de Sistemas de Información tiene como objetivo proporcionar un marco estratégico que sirva de referencia para los Sistemas de Información de un ámbito concreto de una organización, el objetivo del Estudio de Viabilidad del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas. La solución obtenida como resultado del estudio puede ser la definición de uno o varios proyectos que afecten a uno o varios sistemas de información ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situación actual. A partir del estado inicial, la situación actual y los requisitos planteados, se estudian las alternativas de solución. Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas. Se describe cada una de las alternativas, indicando los requisitos que cubre. Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organización, la inversión a realizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación. Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso. Las actividades que engloba este proceso se recogen en la siguiente figura, en la que se indican las actividades que pueden ejecutarse en paralelo y las que precisan para su realización resultados originados en actividades anteriores.

7

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

La decisión de desarrollar un SI por parte de los componentes del Departamento de Informática de la organización tras realizar el correspondiente estudio de las alternativas y elección de la solución más adecuada.

8

2.- Caso de Estudio: Ordenadores para todos. Descripción General

El Ministerio de Industria, Turismo y Comercio ha puesto en marcha el Programa de Ciudades Digitales como un programa de telecomunicaciones cuyo objetivo es la promoción e implantación de la sociedad de la información. El Gobierno de la Comunidad Autónoma de la Región de Murcia ha impulsado la ejecución del Plan para el Desarrollo de la Sociedad de la Información en la Región de Murcia 2002-2004 “RegióndeMurciaSI” (http://www.regiondemurciasi.com), iniciativa estratégica cuyo objetivo es acelerar la incorporación, en igualdad de condiciones, de los ciudadanos y las empresas de la Región de Murcia a la Sociedad de la Información y del Conocimiento de forma plena. El Plan incluye la realización de una nueva experiencia de ciudad digital: Proyecto “Molina Digital”. Para la realización de dicho proyecto, la CARM firma un convenio de colaboración con el Ayuntamiento de Molina de Segura y la Fundación X, donde se detallan las actuaciones a seguir. Una de las mismas es “Internet en casa: equipamiento doméstico”. Esta actuación tiene como objetivo conseguir que las familias del municipio incorporen un equipamiento básico y moderno con el que puedan acceder desde casa a los servicios del Proyecto. De acuerdo con esto, se realiza una convocatoria de la concesión de ayudas dirigidas a ciudadanos residentes en el municipio de Molina de Segura para la adquisición de ordenadores con capacidad de conexión a Internet. Para abordar la tramitación y gestión de las solicitudes, la Consejería de Industria y Medio Ambiente encarga a la Fundación X el análisis y desarrollo de una aplicación web que solvente tal problema. El director de proyectos de la Fundación X, responsable del departamento de desarrollo, ante la posible extensión de estas subvenciones a otros municipios de la región en un futuro cercano, pone de nombre al proyecto “Ordenadores para todos” y encarga al analista que comience el trabajo. El analista de sistemas, tras estudiar el modelo de la solicitud y el borrador de la Orden de la Consejería que regulará las bases y convocatoria de las ayudas, y entrevistarse con los funcionarios técnicos que actuarán como usuarios de la aplicación web, se dispone a ordenar las notas que ha ido tomando sobre los objetivos del proyecto y estructurar la información que ha asimilado con el fin de plantear un primer enfoque de necesidades.

9

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

Beneficiarios, requisitos y obligaciones.

Podrán ser beneficiarios de estas ayudas las personas físicas residentes en el municipio durante al menos los 6 meses anteriores a la presentación de su solicitud y adquieran un ordenador con capacidad de conexión a Internet. La residencia se acreditará mediante volante o certificado de empadronamiento en el que figure la fecha de alta en el padrón de habitantes, y en el que figure su DNI. En el caso de extranjeros no comunitarios deberán aportar documento que refleje el NIE, si no se indica en el volante o certificado de empadronamiento. No serán válidos los certificados con fecha de expedición de una antigüedad superior a 6 meses desde el momento de la presentación del mismo. Sólo se podrá optar a una subvención por unidad familiar. Una vez concedida la ayuda, ningún miembro de la unidad familiar podrá solicitar otra adicional durante la vigencia de la convocatoria de ayudas y de sus eventuales prórrogas. No podrán ser beneficiarios de las ayudas los solicitantes que no se encuentren al corriente en sus obligaciones fiscales con la CARM. Conceptos susceptibles de ayuda y cuantía de la subvención.

Las ayudas previstas se destinarán a subvencionar la adquisición de ordenadores nuevos con las prestaciones necesarias para su conexión a Internet, y que reúnan, como mínimo, las siguientes características: ¾ Placa base con cualquier procesador para plataforma PC o MAC, con velocidad igual o superior a 2,4GHz (PC sobremesa) o a 1,2GHz (PC portátil, MAC sobremesa o MAC portátil). ¾ Memoria RAM: 256Mb. ¾ Disco duro: 30Gb. ¾ Lector de DVD o lector/grabador de DVD. ¾ MODEM o tarjeta de red. ¾ Monitor color 15’’. ¾ Teclado y ratón (para equipos sobremesa). ¾ Tarjeta gráfica (en tarjeta o integrada en placa). ¾ Tarjeta de sonido (en tarjeta o integrada en placa). ¾ Sistema operativo (opcional). El importe genérico de la subvención será del 33% del coste de adquisición, con un máximo de 300€. Tanto el porcentaje de subvención como el importe máximo de la misma podrán verse modificado en función de sus datos fiscales. No se subvencionará la adquisición de periféricos externos (impresoras, 10

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

escáneres, etc.). En el caso de incluirlo en la misma factura que el equipo subvencionado, los precios de cada uno de ellos deberán constar por separado. El módem o tarjeta de red se subvencionarán al 100% con un máximo de 60 euros. El sistema operativo no se subvenciona (se pretende promover el uso de Linux). El valor de los conceptos subvencionables será IVA incluido. El beneficiario tendrá completa libertad para elegir el comercio donde adquirir el equipo, pero éste ha de ser adquirido íntegramente en el mismo comercio. Un comercio, para poder participar en este programa, necesita disponer de conexión a Internet y estar registrado en la aplicación. Oficina municipal.

Se habilitará una oficina por municipio que atenderá las solicitudes de información por parte de los ciudadanos y validará las solicitudes presentadas. Habrá un único responsable por oficina y un número variable de empleados o gestores. Habrá un plazo de presentación de solicitudes para cada municipio, de acuerdo con las correspondientes convocatorias. Solicitud y validación.

Como vamos a ver, el proceso de alta de una petición de subvención se realiza en dos pasos. Primero, la solicitud de subvención se rellena por parte del comercio vendedor del equipo, que tiene acceso a la aplicación a través del web. Segundo, un empleado de la oficina municipal (gestor) valida la solicitud al realizar diversas comprobaciones. Durante el proceso de alta de la solicitud, la aplicación requiere el registro electrónico de todos los campos de la factura. Al ocuparse el vendedor de dar de alta la factura, se libera al personal de los ayuntamientos de esta tediosa tarea. Los campos de la factura no son simplemente texto plano, sino que en la aplicación existe un “catálogo de componentes de ordenadores” en el que cada posible componente del ordenador tiene un código. Cada línea de la factura, entonces, estaría formada por el código del componente; descripción (tal y como viene en el catálogo anterior); cantidad; precio sin iva; precio con iva; porcentaje de subvención aplicable (según el tipo de componente); y precio final con subvención (estos tres últimos campos son calculados automáticamente por la aplicación).

11

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

Al finalizar el alta de la solicitud de subvención, el vendedor debe imprimir la solicitud y la factura, firmarlas y entregarlas al cliente, que a partir de entonces ha de acudir a la oficina municipal correspondiente, antes de que finalice el plazo de fin de la convocatoria, para aportar la documentación que permita validar la petición. En la oficina municipal, un gestor del ayuntamiento deberá validar la solicitud de subvención, para lo cual, el impreso de solicitud debidamente cumplimentado (realizado por el comercio vendedor) deberá ir acompañado de la siguiente documentación: ¾ Original o copia compulsada del volante o certificado de empadronamiento, donde constarán los datos de los integrantes de la unidad familiar (nombre, apellidos y DNI), la fecha de expedición, la fecha de alta y dirección postal. ¾ Original o copia compulsada de la factura del equipo informático adquirido en la que constarán, además de las características técnicas detalladas, los datos del comprador (nombre, apellidos y DNI), y los datos del comercio (nombre jurídico y/o comercial, dirección y CIF). La fecha de la factura no podrá ser anterior a la entrada en vigor de la convocatoria correspondiente. ¾ Original o copia compulsada del certificado de código de cuenta cliente expedido por la entidad bancaria donde el solicitante desee que se le ingrese la subvención, donde constarán, además de nombre, apellidos y DNI del solicitante, el nombre de la entidad y la dirección postal de la oficina correspondiente. ¾ Original o copia compulsada del certificado de renta correspondientes al ejercicio 2005, donde constarán, además del nombre, apellidos… etc., además de el nº de remesa, nº de comunicación, resultado de la cuota ingresar/devolver, importe de su contribución a hacienda pública..etc. El gestor del ayuntamiento comprueba la documentación anterior, introduce los datos relativos al empadronamiento y a la entidad bancaria, y marca la solicitud de subvención como validada. Para el tratamiento de los errores asociados a una solicitud se define la siguiente tipología: solicitud (1), solicitante (2), equipo (3), certificado de empadronamiento (4), factura (5), certificado bancario (6). Estos errores se asignan a la petición de subvención cuando proceda (en ocasiones varios errores para una misma petición), y van explicados por un campo de texto. Por ejemplo, posibles errores pueden ser:

¾ (2) Persona física ya subvencionada. ¾ (2) Persona residente en domicilio ya subvencionado. ¾ (2) Persona morosa con Hacienda. 12

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

Aunque en principio no se espera que sea un procedimiento habitual, el gestor de la oficina tiene habilitada una operación para modificar la solicitud al margen del procedimiento de validación, que incluye la anulación parcial de una subvención: esta opción permitiría anular alguno/s de los campos de la factura. Los gestores de la oficina municipal disponen de opciones para dar de alta y de baja comercios en el programa. Evidentemente, también disponen de operaciones de consulta de los comercios adheridos al programa, y de las subvenciones en trámite y que han sido tramitadas, junto con sus errores asociados y eventuales subsanaciones. Instrucción del procedimiento.

El personal de la oficina municipal valida por un lado los datos de la solicitud en la aplicación tal cual estén presentados por el interesado y por otro lado registra la documentación aportada. Al interesado le proporcionan un número de solicitud validada a efectos de la aplicación, y número y fecha de registro a efectos administrativos (que se incluyen como referencias en la solicitud). Se ha de prever un procedimiento de registro abreviado para evitar colas de personas. Durante la validación se ha de comprobar los datos grabados conforme a las especificaciones requeridas, y se han de grabar todos los errores calculados. Hay una serie de contingencias que sólo podrán ser detectadas por el personal de la oficina, y éstos deberán grabar manualmente los errores detectados. Para tal menester, la solicitud irá pasando por sucesivos estados, que se relacionan: pendiente de validación (1), pendiente de subsanación (2), aprobada (3) y presentada (4). Estos estados son los que se manejarán en las oficinas municipales.

A) campo "ESTADO": estados de la solicitud que maneja el personal de las oficinas municipales 1) lista de valores ¾ Pendiente de validación (1). ¾ Pendiente de subsanación (2). ¾ Aprobada (3).

13

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

¾ Presentada (4).

2) valores iniciales

¾ 1 -> estado por defecto cuando se graba la solicitud completa

3) tránsito entre valores

¾ 1 -> 2 ¾ 1 -> 3 ¾ 2 -> 3 ¾ 3 -> 2 ¾ 3 -> 4 En cada oficina municipal hay un responsable. Una vez que las solicitudes lleguen al estado “aprobada”, el responsable de la oficina podrá dar el visto bueno y pondrá los estados a “presentada”, lo que implicará que presente físicamente las solicitudes en papel y sus documentos ante un administrador de la Consejería de Hacienda, junto con un listado de cada remesa de transferencias pendientes de realización si las subvenciones son finalmente resueltas favorablemente por la administración. Indicar que el administrador de la Conserjería de Hacienda será el encargado de definir las reglas que permiten en función de los datos fiscales de un individuo, establecer el porcentaje de subvención como el importe máximo de la misma. A partir de ahí y hecha la recepción por parte del personal de la administración, se realizará el procedimiento que finalizará en la propuesta de resolución correspondiente. Si una vez realizado el proceso de validación de datos se detecta en la oficina municipal que la información es incompleta o que ésta no reúne los requisitos exigidos, se notificará al interesado para que subsane las deficiencias detectadas o acompañe la documentación requerida, en el plazo de diez días hábiles contados a partir del siguiente al de la recepción de la notificación, con apercibimiento de que si así no lo hiciera se le tendrá por desistida su petición.

14

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

El personal de la Consejería (administrador) manejará un estado sobre la concesión de la subvención, según se relaciona: pendiente (0), recibida (1), publicada en BORM (2), en administración (3), rechazada (4), pagada (5), denegada (6) y desistida (7). B) campo "CONCESION": estados de la solicitud que maneja el personal de la administración 1) lista de valores ¾ Pendiente (0). ¾ Recibida (1). ¾ Publicada en BORM (2). ¾ En administración (3). ¾ Rechazada (4). ¾ Pagada (5). ¾ Denegada (6). ¾ Desistida (7). 2) valores iniciales ¾ 0 -> estado por defecto cuando se graba la solicitud 3) tránsito entre valores ¾ 0 -> 1

¾ 3 -> 5

¾ 1 -> 2

¾ 3 -> 6

¾ 1 -> 3

¾ 3 -> 7

¾ 1 -> 4

¾ 4 -> 1

¾ 1 -> 6

¾ 4 -> 2

¾ 1 -> 7

¾ 4 -> 3

¾ 2 -> 1

¾ 4 -> 6

¾ 2 -> 3

¾ 4 –> 7

¾ 2 -> 6 ¾ 2 -> 7 ¾ 3 -> 4

15

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

En cualquier momento, el estado de una solicitud (y por supuesto, los estados por los que ha pasado) se han de poder consultar con facilidad, tanto por el interesado como por parte de los administradores. Resolución del procedimiento.

El procedimiento finalizará mediante Orden del Consejero correspondiente dictada a la vista de la propuesta elevada por el administrador de la Consejería. Dicha Orden será notificada al interesado por correo ordinario y por mail y registrada en la aplicación. Finalmente, el administrador de la Consejería se encargará de dar la orden de pago de las remesas aprobadas. (Las solicitudes de subvención se agrupan en remesas, que son básicamente colecciones de transferencias bancarias a realizar). Al igual que el responsable de la oficina, el administrador dispondrá de una opción para generar diversas estadísticas sobre las concesiones, y de otras opciones para revisar solicitudes, modificar remesas, consultar remesas, y realizar y consultar subsanaciones. Otras consideraciones.

Es evidente que este desarrollo como se observa en la documentación, procedimiento..etc. está en principio dirigido a personas físicas con la nacionalidad española, la cuestión que surge y que puede considerarse como una posible extensión el incluir los elementos necesarios para permitir que estas ayudas puedan aprobarse cuando el destinatario sea una persona jurídica, es decir una empresa, o una persona física pero de nacionalidad comunitaria o extracomunitario con permiso de residencia.

16

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

3.- Descripción del trabajo práctico. Consideremos viable el proyecto descrito en el apartado anterior. En esta práctica se debe seguir el proceso de Análisis de Sistemas de Información (ASI) de Métrica 3 (desarrollo estructurado) para especificar los requisitos del caso práctico. El director del proyecto ha decidido que la estructura de la documentación resultante de aplicar el proceso ASI deberá incluir los siguientes apartados:

 Catálogo General de Requisitos: o Véase documento explicativo….  Elaboración y descripción del modelo de procesos: o Contexto del sistema. o Diagrama de subsistemas o Jerarquía de procesos. o Diccionario de datos.  Elaboración y descripción del modelo de datos: o Modelo entidad/relación (E/R). o Modelo extendido de datos.  Especificación y prototipado de la Interfaz de Usuario.  Anexos. Contenidos Opcionales: o Modelo/Diagrama de casos de uso. o Los diagramas HVE de las principales entidades del sistema. o Siguiendo el proceso DSI de Métrica 3, diseñar la estructura modular de una parte del sistema. o Cada grupo puede realizar otras aportaciones a la práctica que sean de su interés, aportaciones que deberá discutir primero con el profesor.  Anexos. Trabajos : o Trabajos Opcionales de estudio/investigación.

17

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

4.- Durante la elaboración del ERS se deben seguir las siguientes pautas. Por favor, leed cuidadosamente este apartado antes de comenzar a trabajar en la práctica y antes de entregar la documentación final.

¾ El grupo de prácticas puede enriquecer o cambiar la especificación 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 elección, si fuera necesario. ¾ El alumno también puede enriquecer el formato de ERS que debe entregarse como resultado de la práctica. ¾ La documentación de la práctica se debe elaborar usando System Architect 2001, entregando los resultados en papel y en un soporte que contenga la enciclopedia y el informe correspondiente. Toda la documentación necesaria para la comprensión de la práctica se debe incluir en papel. ¾ La portada de la documentación debe incluir: código de grupo (disponible en el web y en los tablones de clase), los nombres y dni de los integrantes del grupo, una dirección de e-mail de contacto, la titulación, el nombre de la asignatura y el nombre del profesor de prácticas. ¾ 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 estén en blanco. ¾ El Glosario de términos deberá definir los términos necesarios para comprender adecuadamente el Catálogo de requisitos. Aunque se puede generar con System Arhitect 2001, recomendamos su realización mediante un procesador de textos. ¾ Como sabemos, la Descripción de subsistemas de análisis se corresponde con una descripción del DFD 0. Presta una especial atención a realizar una descomposición en subsistemas coherente. ¾ En el Modelo de procesos del sistema, se debe entregar un modelo lógico de los procesos del nuevo sistema de información. ¾ Se deben usar pre y post-condiciones en las miniespecificaciones de los procesos primitivos, pero en un par de procesos no triviales también se debe ilustrar el uso de lenguaje estructurado. 18

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

¾ Obviamente, es requisito indispensable respetar las reglas sintácticas del análisis estructurado. Recuerda que el modelo de procesos y el modelo E/R deben estar balanceados. ¾ En el Modelo de datos, sólo se deberá realizar un modelo conceptual utilizando el modelo entidad/relación extendido (no se debe realizar el modelo lógico ni el modelo lógico normalizado). ¾ La Especificación de interfaz de usuario contendrá un prototipo de interfaz de la aplicación, que debe incluir (al menos) los cuadros de diálogo y los informes más importantes. Para ello se pueden utilizar los diagramas de System Architect “Menu” y “Graphic Screen”, pero recomendamos el uso de una herramienta que permita la edición de documentos HTML. Si los alumnos prefieren usar cualquier otra herramienta para generar el prototipo de interfaz, pueden hacerlo.

19

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

5.- Trabajos Opcionales de estudio/investigación. Š Diseño del Sistema de Información (Proceso DSI). Š Construcción del Sistema de Información (Proceso CSI). Š Implantación y Aceptación del Sistema (Proceso IAS). Š Mantenimiento del Sistema de Información (Proceso MSI). Š REAL DECRETO LEGISLATIVO 1/1996, de 12 de abril, (BOE de 22 de abril) por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual regularizando, aclarando y armonizando las disposiciones legales vigentes sobre la materia. Š Interface de seguridad: MAGERIT - Versión 2 (julio de 2005). Š Interface de calidad: PGGC. Š Introducción al UML. Š Diagramas de Clases y otros tipos de diagramas UML: actividades, secuencia, despliegue, paquetes, etc. Š Standard de ERS 830 XXXX. Š The World Wide Web Consortium (W3C). Š Capability Maturity Model® for Software (SW-CMM®). Š La familia de estándares ISO (Organización Internacional de Estandarización). Š Gestión Temporal de Proyectos Software: Método Pert-Gantt. Š Gestión Temporal de Proyectos Software: Método ROY. Š Gestión de Costes: COCOMO2000. Š Otros métodos de gestión de costes: Puntos de Función, Técnica Delphi... Š Software:

20

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

6.Esquema de actividades ASI y DSI. 6.1.- Esquema de ASI: Sistema de Información.

Análisis

las

del

En el siguiente gráfico se muestra la relación de actividades del proceso Análisis del Sistema de Información, tanto para desarrollos estructurados como para desarrollos orientados a objetos, distinguiendo las que se pueden realizar en paralelo de aquellas que han de realizarse secuencialmente.

21

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

6.2.- Esquema de DSI: Diseño del Sistema de Información. En el siguiente gráfico se muestra la relación de actividades del proceso Diseño del Sistema de Información (DSI), tanto para Desarrollos Estructurados como para Desarrollos Orientados a Objetos.

22

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

7.- Entregables en la etapa ASI-DIS. A continuación se muestra el índice documental de entregables considerando la información anteriormente mencionada referente a la organización en tareas y documental de las actividades en las que se estructura ASI y DSI en el marco de la Metodología de Desarrollo de Sw Métrica 3.

ASI 1. Definición del sistema. ¾ Catálogo de requisitos generales. ¾ Glosario de términos. ¾ En AE: o Contexto del sistema. DFD de Contexto. o Modelo conceptual de datos. Modelo Entidad Relación no Extendido. ¾ Catálogo de estándares y de normas. ¾ Catálogo de usuarios (participantes y finales). ¾ Entorno tecnológico del sistema. ¾ Plan de trabajo. ASI 2. Establecimiento de requisitos. ASI 2.1: Obtención de requisitos. Sesiones de trabajo con los usuarios para extraer los requisitos (con prioridades): ¾ Catálogo de requisitos detallado. ¾ Modelo de casos de uso. ASI 2.2: Especificación de Casos de Uso. ¾ Especificar cada caso de uso: (Escenarios) o Descripción del escenario principal o Pre y post-condiciones o Interfaces de usuario o Escenarios secundarios ¾ Es posible que se dividan casos de uso complejos en otros más simples. (Relaciones de Uso y Herencia).

23

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

ASI 3. Identificación de subsistemas de análisis. ¾ En AE, se corresponde con el DFD 0. ASI 6. Elaboración del modelo de datos. Técnica: Modelo E-R extendido. ¾ Se completa el modelo conceptual de datos (versión inicial en ASI 1). ¾ Se elabora el modelo lógico. ¾ Se normaliza el modelo lógico (al menos hasta 3FN) ¾ Si es necesaria una migración de datos de otros sistemas o una carga inicial de información, determinar las necesidades de migración o carga inicial de datos ⇒ plan de migración y carga inicial de datos. ASI 7. Elaboración del modelo de procesos. ¾ Descomposición del DFD 0 en la jerarquía de procesos. ¾ Diccionario de Datos. Entidades Externas-AlmacenasFlujos-Procesos… ect. ASI 8. Definición de interfaces de usuario. ¾ Se especifican los estándares y directrices a tener en cuenta: o Normas de interfaz (gráfica o de caracteres), para mensajes de error, de ayuda, etc. ¾ Se definen: o Formatos de pantallas y de impresión. o Diálogos, informes y formularios. o (En AOO, las interfaces ya se han especificado en los casos de uso.) ¾ Opcionalmente, usar prototipos en la interfaz interactiva y de impresión. ASI 10. Especificación del plan de pruebas. (Opcional). ¾ Se inicia la definición del plan de pruebas. o Se definen las pruebas de aceptación.

24

Prácticas de Fundamentos de Ingeniería del Software 3º IT de Gestión. 2006/2007.

DSI 5. Diseño de la arquitectura de módulos del sistema. ¾ Objetivo: para cada uno de los subsistemas se diseña la estructura modular de los procesos que lo integran. ¾ Pto. de partida: modelo de procesos obtenido en ASI y catálogo de requisitos. ¾ Técnica: Diagrama de Estructura de Cuadros de Constantine (DEC) ¾ Se realiza el diseño detallado de la interfaz de usuario, de pantalla e impresa. ¾ El interfaz de usuario debe corresponderse con la estructura modular.

25