Sistema de información para la gestión de ligas de billar : Billargest

Sistema de Información para la Gestión de Ligas de Billar BILLARGEST PROYECTO FINAL DE CARRERA AUTOR: Carlos Soriano Lorente DIRECTOR: José María Torralba Martínez Valencia, Mayo 2010 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar 1 Contenido: 1. RESUMEN 2. DOCUMENTO I – MEMORIA Capítulo 1.- Introducción, objeto, antecedentes y bases. Capítulo 2.- Plan de Sistemas de información y selección de alternativas. Capítulo 3.- Análisis del sistema de información. Capítulo 4.- Evaluación de riesgos. Capítulo 5.- Medición, estimación, presupuesto, oferta y programación temporal. Capítulo 6.- Diseño de sistema de información. Capítulo 7.- Plan de construcción y pruebas. Capítulo 8.- Plan de puesta en servicio. Capítulo 9.- Conclusiones. Bibliografía. 3. ANEXOS A LA MEMORIA ANEXOS 1 – Estudio Preliminar del software de gestión actual. ANEXOS 2 - Planificación de Sistemas de Información (Proceso PSI). ANEXOS 3 - Estudio de Viabilidad del Sistema (Proceso EVS). ANEXOS 4 - Análisis del Sistema de Información (Proceso ASI). ANEXOS 5 - Diseño del Sistema de Información (Proceso DSI). ANEXOS 6 - Construcción del Sistema de Información (Proceso CSI). ANEXOS 7 - Implantación y Aceptación del Sistema (Proceso IAS). ANEXOS 8 - Mantenimiento del Sistema de Información (Proceso MSI). ANEXOS 9 - Manual de usuario. ANEXOS 10 – Presupuesto. ANEXOS 11 - Diseño de la Base de Datos. ANEXOS 12 - Ejemplo de Pruebas de Interfaz. ANEXOS 12 – Pliego de condiciones. ANEXOS 13 – Evaluación de Riesgos. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar 2 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Resumen 1 Resumen. Índice: 1. Necesidad, problema, promotor, usuarios ........................................................................... 2 2. Metodologías ........................................................................................................................ 3 3. Plazo de Realización .............................................................................................................. 4 4. Herramientas de Realización ................................................................................................. 4 5. Funcionalidades de la aplicación ........................................................................................... 4 6. Pantalla principal ................................................................................................................... 6 7. Precio final ............................................................................................................................. 6 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Resumen 2 1. Necesidad, problema, promotor, usuarios La Federación de Billar de la Comunidad Valenciana (en adelante FBCV) contaba con numerosos problemas debidos a la antigüedad del software con el que se gestionaban los torneos, clubes y socios de la comunidad. Estos problemas iban desde la imposibilidad de actualizar los componentes hardware en los que funcionaba la aplicación, hasta limitaciones en la mayor parte de datos de entrada, y no solo eso, la obligada adaptación a la LOPD1 al estar la federación en su ámbito de aplicación hacia que fuera necesario adoptar un paquete software que cumpliera las directrices de dicha ley. Para conseguir la financiación necesaria, que no solo se limitaba al software, sino también a la actualización de hardware, se utilizó una subvención del Consell Valencià de L’Esport. La primera estimación de presupuesto que hizo la FCBV fue de siete mil euros (7.000€) por la actualización integra. Una vez se aprobó el acta para la ampliación y actualización de los Sistemas de Información, el personal administrativo fue el encargado de contactar con empresas y particulares dispuestos a llevar a cabo el proyecto en cuestión. Se pensó en un primer momento en la empresa que había desarrollado la primera versión, pero tras quince años, la empresa había desaparecido. La siguiente opción fue la de intentar adquirir un paquete ya desarrollado, pero en el mercado no existía ninguna herramienta específica que cubriera todas las necesidades. Así pues, tras solicitar dos presupuestos, en los que la cuantía de una primera estimación superaba ampliamente los diez mil euros (10.000€) por el paquete completo, se plantea la compra por separado del material hardware y de la herramienta de gestión, que sería adaptada de otra federación de billar autonómica. Uno de los socios de la FBCV es copropietario de una tienda de informática en la cual se encargarían los dos equipos que formarán parte del nuevo sistema de información. Las características básicas serían:  Procesador Intel Dual Core E5200.  4GB Ram PC667.  1TB HD.  Impresora Laser HP© 1022 Compatible PS5 y PS6.  SO: Microsoft© Windows 7 Home, Compatible Framework 3.5. El mismo socio es el que ofrece, antes de que las gestiones con la federación de otra comunidad avancen, la posibilidad de hacer el trabajo al que finalmente será el futuro desarrollador del proyecto, D. Carlos Soriano Lorente, y tras una primera estimación de costes, la cuantía destinada al paquete informático es aceptada por las dos partes. De esta manera nace el proyecto BILLARGEST (Sistema de Información para la Gestión de Ligas de Billar) el cual permite llevar a cabo la gestión integral de los diferentes clubs, socios, torneos y ligas de Comunidad Valenciana. El principal cometido del nuevo programa es la actualización del antiguo paquete de software cubriendo los requisitos ya marcados anteriormente, y añadiendo nuevas funcionalidades y características acordes a los tiempos que corren. 1 Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Resumen 3 2. Metodologías El estudio de cada proceso de desarrollo del proyecto se ha llevado a cabo con Métrica2 v3. La decisión principal de usar esta metodología responde básicamente a que es la metodología estándar de planificación y desarrollo de sistemas de información de la administración central española, lo que asegura la calidad, la seguridad del paquete y sobre todo, la cantidad de recursos documentales que existen de esta metodología en español, al contrario que otras metodologías ágiles como Programación Extrema (XP) o Essential Unified Process (EssUP). También se ha tenido en cuenta la posibilidad futura de venta a alguna federación nacional que requiera obligatoriamente el uso de esta metodología, como así lo requieren todas las organizaciones de la administración central española. Debido a que el lenguaje usado para la programación del paquete será un lenguaje 100% orientado a objetos como es C# 3.5, se decide el uso del lenguaje de modelado UML3 2.0. Ello conlleva el uso de diferentes diagramas que serán para el caso: Diagramas de Estructura  Diagrama de clases  Diagrama de componentes  Diagrama de paquetes Diagramas de Comportamiento  Diagrama de casos de uso Las pruebas del ciclo de vida que se realizarán serán:  Pruebas Unitarias  Pruebas de Integración  Pruebas Funcionales  Pruebas de Rendimiento La planificación del proyecto se realiza con diagramas de Grantt, y la estimación del tiempo de desarrollo se basa en la estimación por puntos de función ajustados. 2 MÉTRICA V3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información (28/04/2010): http://www.csi.map.es/csi/metrica3/ 3 UML V2.0: Unified Modeling Language (28/04/2010): http://www.uml.org/ BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Resumen 4 3. Plazo de Realización El proyecto se lleva a cabo de Septiembre de 2009 a Abril de 2010. 4. Herramientas de Realización El paquete se ha realizado con el entorno de programación Microsoft© Visual Studio .NET 2008 usando el Framework 3.5 y el lenguaje de programación C#. La BB.DD. ha sido realizada con el entorno Visual Studio en formato Microsoft© Access 2007. También se ha usado la aplicación de generación de Reportes Crystal Reports© .NET y la herramienta de creación de paquetes autoinstalables InstallShield© 2010. 5. Funcionalidades de la aplicación La aplicación contiene las siguientes funcionalidades: Inicio de la aplicación: la aplicación contiene una pantalla de bienvenida que aparece durante el inicio y presenta datos acerca de la aplicación. Una vez mostrada la pantalla de inicio, se realizan las comprobaciones de licencias. En caso de que el usuario introduzca un código de licencia válido, este se almacena en los archivos de configuración de la aplicación y no se vuelve a solicitar la clave tras el primer arranque. En caso de no introducirlo, la pantalla no permite el acceso a la aplicación. Gestión de temporadas: Desde esta opción se gestiona la base de datos y las temporadas de BILLARGEST. En la gestión de temporadas se incluye: Nueva temporada: permite crear una nueva temporada para albergar nuevas competiciones. Crear una nueva temporada conlleva vaciar los listados de estadísticas del programa y las actas visibles, pero no los clubes y socios introducidos. Abrir temporada: permite abrir o eliminar una temporada ya creada seleccionando el año. Acta: Desde esta opción se gestionan solo las actas de la temporada abierta actualmente. En la gestión de actas se incluye: Añadir: permite añadir una nueva acta a la Base de Datos. Editar: permite editar un acta previamente introducida a la Base de Datos. Borrar: permite borrar un acta previamente introducida a la Base de Datos. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Resumen 5 Sancionar: permite sancionar algún club por cualquier tipo de irregularidad, como una alineación indebida. Club: Desde esta opción se gestionan los clubes adscritos a la Federación. En la gestión de clubes se incluye: Añadir: permite añadir un nuevo club a la Base de Datos. Editar: permite editar un club previamente introducido en la Base de Datos. Borrar: permite borrar un club previamente introducido en la Base de Datos. Socio: Desde esta opción se gestionan los socios adscritos a los clubes dados de alta. En la gestión de socios se incluye: Añadir: permite añadir un nuevo socio a la Base de Datos. Editar: permite editar un socio previamente introducido en la Base de Datos. Borrar: permite borrar un socio previamente introducido en la Base de Datos. Imprimir Etiqueta: permite imprimir un carnet de socio con un formato previamente establecido. Precio Licencia: permite establecer el precio de la licencia para socio Junior o socio Sénior. Listados: Desde esta opción se visualizan e imprimen los listados del programa. Dentro de listados se incluyen las opciones de: Clasificación: permite visualizar en pantalla un listado de la clasificación provisional por puntos de una liga. Promedios: permite visualizar en pantalla un listado de la clasificación provisional por mayor promedio de una liga. Opciones generales: Imprimir: si se tiene abierto un formulario de entrada de datos se puede seleccionar la opción de menú Imprimir, que presenta una selección de opciones de impresión para el origen de datos actual. Exportar: exportar cualquier formulario a un formato de archivo de hoja de cálculo de Microsoft© Excel (.xls). Otros: el marco de la aplicación también admite algunas características comunes de las aplicaciones para Windows. Entre ellas se incluyen: -Un menú Ventana que le permite distribuir en cascada o en la forma que elija todas las ventanas abiertas. -Un cuadro de diálogo Acerca de y elementos de menú del archivo de Ayuda. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 6 Administración recoge directamente las actas de las temporadas firmadas por los árbitros y son los encargados de publicar las estadísticas y clasificaciones semanalmente tanto en la Web como en el tablón de la federación. También es posible que si el jugador ha solicitado el envío por correo electrónico estas listas se le faciliten directamente en formato Excel. En caso de que algún club impugne el resultado del acta oficial, esta se introduce en el programa y se envía al Comité de apelación para su revisión. Según su resolución, se modificará o no el acta. Asimismo administración también es la encargada de dar de alta los clubes a principio de temporada, o los jugadores una vez recibido el formulario de inscripción y una vez pagada la cuota, con un importe variable según el tipo de club o el tipo de socio. El comité de competición marca al principio de temporada las diferentes divisiones y grupos que conformarán la competición, el calendario, las jornadas que se jugarán, etc. etc., toda esta información es recogida por administración e introducida en el sistema de información de la federación. El diagrama entidad relación básico1 del Sistema de información es el siguiente: Figura 1.2. Diagrama entidad relación Para automatizar y gestionar el sistema, se encuentra un único software de gestión llamado BILLGEST producido por la empresa Carbel Sistemas S.L. hace 16 años. El sistema de gestión esta centralizado en un único PC/IBM compatible 486 con MSDOS 6.22 y una impresora Epson EPL-6200N. Además se encuentra otro PC para las gestiones administrativas habituales (email, actualización de la Web, etc…) El programa a desarrollar no contempla en principio la integración de estas funcionalidades por lo que no serán objeto de estudio. Así, tras un análisis preliminar se establece que carencias tiene el actual software de gestión y cuáles serán las nuevas características que se requieren por parte de administración para que las gestiones se realicen de una manera más eficiente (ver ANEXOS 1 – Estudio Preliminar del software de gestión actual). 1 Modelo E-R Chen Original (1976): http://www.csc.lsu.edu/~chen/ CLUB ACTA FIRMA GESTIONA ADMINISTRACIÓN ÁRBITRO VALENCIA ALICANTE DELEGACIONES APELA COMITÉ APELACIÓN PRESIDENCIA FIRMA CASTELLÓN (0,n) ) (2,2) (0,n) (4,4) (0,n) (0,n) (2,n) (0,1) GESTIONA (0,n) (0,n) (0,n) (0,n) (0,n) BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 7 1.5. Bases del proyecto Como se ha comentado anteriormente el proyecto BILLARGEST consiste en llevar a cabo una aplicación para gestionar toda la información de la FBCV que se relacione con clubes, socios y temporadas, quedando fuera de ella todo lo que no sean estas tres entidades y sus relaciones. Factores críticos de éxito: -Es necesario disponer de una infraestructura básica para soportar la aplicación a desarrollar, esto es un equipo compatible con el Framework .NET 3.5 y un sistema operativo Microsoft© Windows en versión XP/2000 o Vista/W7. La aplicación se generará tanto para máquinas X86 como X64 habiendo una completa compatibilidad para los 2 tipos de tecnologías. -Se facilitará gratuitamente un servicio de conexión remota para realizar pruebas telemáticas desde internet con la máquina host que albergará el programa, no obstante en caso de hacer uso de esta herramienta es necesario que personal del departamento esté presente en la máquina física y supervise la conexión remota. -El departamento de administración debe jugar un papel clave a la hora de la toma de requisitos por parte del consultor, de manera que se facilite tanto información veraz relativa a la propia gestión actual, necesidades vigentes y carencias, e información del manejo actual del flujo de información. También se facilitará todo tipo de formularios e impresos relativos al sistema de información a desarrollar. - Es necesario que se establezca un medio de comunicación continuo entre el cliente y el responsable del proyecto para evitar retrasos en los avances de la aplicación. -Asimismo para poder resolver las incidencias de manera rápida y efectiva es necesario que el departamento de administración se implique en la parte de pruebas que corresponde exclusivamente al cliente. 1.6. Metodología general La metodología general del proyecto es MÉTRICA© en su versión 32. Esta metodología permite dar soporte al ciclo de vida del proyecto y 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.” 2 MÉTRICA V3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información (28/04/2010): http://www.csi.map.es/csi/metrica3/ BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 8 “- Facilitar la operación, mantenimiento y uso de los productos software obtenidos.” Empleando esta metodología se asegura la calidad, la seguridad del paquete y sobre todo gran cantidad de recursos documentales en lengua española. Los procesos que trata la metodología METRICA V3 y serán aplicados al proyecto son: 1) “Proceso de Planificación de Sistemas de Información, al no estar dentro del ámbito de la norma ISO 12.207 de Procesos del Ciclo de Vida de Software, se ha determinado a partir del estudio de los últimos avances en este campo, la alta competitividad y el cambio a que están sometidas las organizaciones. El entorno de alta competitividad y cambio en el que actualmente se encuentran las organizaciones, hace cada vez más crítico el requerimiento de disponer de los sistemas y las tecnologías de la información con flexibilidad para adaptarse a las nuevas exigencias, con la velocidad que demanda dicho entorno. La existencia de tecnología de reciente aparición, permite disponer de sistemas que apoyan la toma de decisiones a partir de grandes volúmenes de información procedentes de los sistemas de gestión e integrados en una plataforma corporativa. MÉTRICA Versión 3 ayuda en la planificación de sistemas de información facilitando una visión general necesaria para posibilitar dicha integración y un modelo de información global de la organización.” 2) “Proceso de Desarrollo de Sistemas de Información, para facilitar la comprensión y dada su amplitud y complejidad se ha subdividido en cinco procesos: -ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS). -ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI). -DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI). -CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI). -IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS).” 3) “Proceso de Mantenimiento de Sistemas de Información, cuyo objetivo es la obtención de una nueva versión de un sistema de información desarrollado con MÉTRICA, a partir de las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado en el sistema o por la necesidad de una mejora del mismo.” MÉTRICA Versión 3 facilita la toma de decisión y la realización de todas las tareas que comprende el desarrollo de un sistema de información. 1.7. Estructura documental La estructura básica documental del proyecto3 corresponde al siguiente índice: 1. RESUMEN 2. DOCUMENTO I – MEMORIA Capítulo 1.- Introducción, objeto, antecedentes y bases. Capítulo 2.- Plan de Sistemas de información y selección de alternativas. Capítulo 3.- Análisis del sistema de información. Capítulo 4.- Evaluación de riesgos. 3 Norma UNE 157801 (2007): Criterios Generales para la elaboración de proyectos de Sistemas Informáticos BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 9 Capítulo 5.- Medición, estimación, presupuesto, oferta y programación temporal. Capítulo 6.- Diseño de sistema de información. Capítulo 7.- Plan de construcción y pruebas. Capítulo 8.- Plan de puesta en servicio. Capítulo 9.- Conclusiones. Bibliografía. ANEXOS A LA MEMORIA ANEXOS 1 – Estudio Preliminar del software de gestión actual. ANEXOS 2 - Planificación de Sistemas de Información (Proceso PSI). ANEXOS 3 - Estudio de Viabilidad del Sistema (Proceso EVS). ANEXOS 4 - Análisis del Sistema de Información (Proceso ASI). ANEXOS 5 - Diseño del Sistema de Información (Proceso DSI). ANEXOS 6 - Construcción del Sistema de Información (Proceso CSI). ANEXOS 7 - Implantación y Aceptación del Sistema (Proceso IAS). ANEXOS 8 - Mantenimiento del Sistema de Información (Proceso MSI). ANEXOS 9 - Manual de usuario. ANEXOS 10 – Presupuesto. ANEXOS 11 - Diseño de la Base de Datos. ANEXOS 12 - Ejemplo de Pruebas de Interfaz. ANEXOS 12 – Pliego de condiciones. ANEXOS 13 – Evaluación de Riesgos. 1.8. Plan de ampliación Se considera la opción de ampliar la aplicación objeto de este PFC para dotar a la Web corporativa de toda la información manejada en el programa, para que los usuarios puedan acceder a ella directamente sin necesidad de ser reenviada por parte de administración. Esta posible ampliación se integraría como una nueva función de negocio en el programa, usando la misma tecnología C# .NET, por lo que no habría ningún tipo de problema para su implementación. La conexión con la BB.DD. se realizaría mediante las propias cadenas de conexión proporcionadas por el Framework sin necesidad de usar un conector ODBC externo. En caso de llevarla a cabo, habría que replantear el sistema físico y operativo ya que sería necesario incluir en el sistema de información de la FBCV algún tipo de servidor. Las peticiones adicionales se evaluarán y solo se implementarán si no requieren gran tiempo de realización, y siempre posteriormente a las incidencias, además serán gratuitas durante un mes, así pues no serán consideradas en ningún plan. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 10 2. Plan de Sistemas de Información y selección de alternativas 2.1. Situación actual Actualmente la Federación de Billar de la Comunidad Valenciana dispone de dos ordenadores personales los cuales son manejados por dos personas del departamento de administración. Estas personas son las encargadas de introducir y manejar los datos que circulan por el sistema de información de la Federación. Estos ordenadores están conectados entre sí mediante un cable de par trenzado ya que uno de ellos realiza funciones de conexión compartida a internet. Uno de ellos utiliza un sistema operativo Microsoft© Windows XP SP2, y el otro es manejado bajo un sistema Windows© 98 SE. Ambos tienen impresoras, una Epson matricial con drivers DOS específicos configurados en el programa de gestión actual y otra HP Laserjet© 1000 series PostScript 6 compatible. Los datos que son referentes a la gestión de liga, clubes o socios, son manejados mediante el software de gestión actual BILLGEST, asimismo los datos generados por este software son tratados por el personal del departamento en otros formatos de tecnología más actual, como son listados Excel© 2007, y reenviados mediante programas de correo electrónico a los socios y clubes para que informen a quienes consideren oportuno. Debido a las carencias del software actual, durante estos años se han ido creando nuevos formularios para dar servicios a sus clientes que no podían ofrecer con el programa de gestión. La mayoría han sido implementados con Macros Excel 2003. Estos formularios se utilizan como complemento al software BILLGEST. También se hace uso de la herramienta FrontPage para la modificación de la página web, de la cual se realizan actualizaciones periódicamente. 2.2. Plan de Sistemas de Información El departamento de administración requiere de mucho tiempo y esfuerzo en suplir las carencias que provoca el uso del programa actual de gestión BILLGEST. Las carencias principales son: - Nula capacidad de ampliación y actualización. - Falta de soporte. - Limitada capacidad de ampliación de hardware y mantenimiento que de soporte al software. - Formatos de ligas de hace 15 años. - Limitaciones en los datos de entrada de la aplicación. - Problemas de integridad en los datos. - Problemas con el sistema de backup. - Interfaz gráfica poco usable y manejable. - Nula portabilidad. - Alto coste en tiempo al tener que transformar los datos de salida de la aplicación en entregables a los asociados. El presente proyecto trata de suplir todas estas carencias e integrarlas en una nueva aplicación que de servicio a la FBCV. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 11 2.3. Estudio y selección de alternativas Una vez expuestos los problemas de la aplicación actual y los requerimientos básicos por parte de administración a presidencia, y una vez aprobado el seguimiento del plan, se hace necesario seleccionar el tipo de herramienta que pueda suplir el programa actual. Para ello se analizan diferentes alternativas: Alternativa 1: Adaptación integra de un programa de gestión en producción ya existente de otra Federación de Billar Esta alternativa fue una de las primeras consideraciones que se tuvo en cuenta a la hora de seleccionar un software adecuado que pudiera dar soporte al departamento. La Federación Catalana de Billar ya disponía de un software que podía suplir la mayor parte de las exigencias de administración de la FBCV. Este software era capaz de: - Gestionar Clubes y Socios - Gestionar Temporadas anuales - Gestionar Reservas en las mesas de juego de la Federación - Gestión de documentación y normativa asociada - Registro de árbitros - Registro contable La aplicación, desarrollada por una empresa Catalana en exclusiva para la Federación Catalana de Billar (FCB), superaba en cierta medida las necesidades actuales de la FBCV, no obstante se hacía necesaria una pequeña remodelación para adaptarlo al sistema de liga interprovincial que se lleva a cabo en esta comunidad. El factor limitante de esta alternativa es sin duda el precio, muy superior a las posibilidades con las que cuenta actualmente las arcas de la Federación Valenciana. Alternativa 2: Ampliación del programa actual La ampliación o actualización del programa actual BILLGEST fue la primera opción que se tuvo en cuenta para mejorar el sistema de información de la Federación. Desgraciadamente la compañía creadora ya no existe, y por tanto se parte de un programa totalmente cerrado y sin posibilidad de edición. No obstante se piensa en la posibilidad de realizar módulos independientes que editen las entradas y salidas del programa. 2.1. Ampliación en la gestión de listados La adaptación del módulo de exportación consiste en crear un convertidor de formatos de listados propietarios BILLGEST a formatos editables Microsoft© Office 2007. Para llevar a cabo esta tarea se piensa en la posibilidad de encargar la realización de Macros Visual Basic v6 a la empresa que desarrolló el software para la FCB. La ventaja clara de esta opción es el coste relativamente bajo. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 12 2.2. Creación de un módulo independiente para la gestión de carnets de socios De manera similar a la ampliación anterior, se piensa en crear otro pequeño módulo que integre la impresión de carnets de socios, mediante una BB.DD. que funcione de manera independiente de la BB.DD. principal, ya que después del pre análisis no se observa posibilidad de acceso a las BB.DD. de BILLGEST. El problema radica en la posible redundancia de datos. Alternativa 3: Programa sustitutorio íntegro 3.1. Aplicaciones comerciales Las herramientas de gestión de ligas son muy comunes, y es posible desde adquirir aplicaciones comerciales como es el paquete “Competiciones deportivas V.10” de la empresa Sagois S.L.U. a usar servicios Web de Gestión de Ligas como el que ofrece Esportalia S.L. Concretamente se estudia el programa de Competiciones deportivas V.10 de la empresa Sagois S.L.U. cuyas principales funciones de negocio son: CALENDARIO  Creación y gestión de campeonatos de liga (a 1 o 2 vueltas) y copa, así como fases previas y finales.  Realiza el sorteo del campeonato de manera automática a 1 o 2 vueltas con posibilidad de establecer la primera jornada de manera manual. Es posible establecer todas las jornadas de manera manual.  Genera los enfrentamientos de copa. Permite generar previas de liga y final de copa.  Creación de calendarios, pudiendo seleccionar entre calendarios completos, por jornadas, o de un rango de jornadas. Posibilidad de mostrar la clasificación actual en la parte inferior de la página.  Gestión profesional de horarios: Creación de calendarios con un número ilimitado de campos de juego. Además, ahora es posible reservar el campo de juego por parte de usuarios, y el programa tiene en cuenta estas reservas a la hora de generar el calendario para evitar coincidencias horarias. CLASIFICACIONES  Generación de clasificaciones de equipos y jugadores.  Equipos: clasificación general, deportividad, equipos menos goleados.  Jugadores: Goleadores, Deportividad y equipos menos goleados. SANCIONES  Imprime las actas de los partidos, informándonos de qué jugadores están sancionados.  Gestión profesional de árbitros y de sanciones.  Listas negras de DNI: permiten la detección automática, por medio del DNI, de un jugador al que no se le permita inscribirse en un campeonato. INTERNET  Exportación automática de equipos, calendarios y clasificaciones a HTML. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 13  Posibilidad de subir las páginas a un servidor privado.  Creación de copias de seguridad, con posibilidad de subirlas a internet. OTROS  Nueva base de datos de usuarios con la posibilidad de importarlos a los equipos a lo largo de los años.  Posibilidad de almacenar equipos y jugadores para poder utilizarlos en campeonatos posteriores.  Creación de hojas de inscripción.  Creación de carnets.  Gestión Económica (Sólo versión élite). El coste de la aplicación entra dentro de la partida destinada a la actualización del software de la FBCV, pero no así el coste de la ampliación para adaptarlo a las necesidades específicas de la FBCV, como es la adopción de listas de fuerza y generación de las diferentes divisiones. 3.2 Desarrollo desde cero de la aplicación Consiste en el desarrollo de una sola aplicación que disponga de información centralizada de todas las funciones requeridas para mantener el sistema de información de la FBCV. La aplicación correspondería por tanto a una actualización de la herramienta de gestión de la que se dispone actualmente. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 14 3. Análisis del Sistema de Información 3.1. Alcance del sistema El alcance del sistema debe cubrir toda la operatoria de gestión de clubes, de las tres provincias de la Comunidad Valenciana, la gestión de los Socios de los respectivos clubes, y el tratamiento de las ligas que se juegan anualmente. El límite del alcance radica por tanto, en las entidades externas de Club y Socio. Si bien la gestión estará centralizada por el departamento de administración, habrá que fijar en el catálogo de requisitos las exigencias particulares de cada una de estas dos entidades. Adicionalmente, el sistema de información contempla la actualización de equipos, una nueva gestión de BB.DD. y la inclusión de nuevos paquetes ofimáticos para dar soporte a las extensiones del sistema de gestión de ligas a implantar. También es importante destacar que el desarrollo no contempla el acceso al programa de gestión con distintos roles. Lo que si entra dentro del alcance es la posibilidad de exportación de datos en un formato propio, lo que permitirá la instalación en diferentes equipos de la FBCV, siempre trabajando sobre una única versión de BB.DD. El resto de entidades de la FBCV quedan fuera del ámbito del programa y no se desarrollarán. 3.2. Entorno tecnológico El entorno tecnológico que soportará la carga del sistema de información corresponde a las siguientes configuraciones: Equipos de administración (2): - Caja MicroATX - Microprocesador Intel Dual Core E5200 - Placa base Asus mod. P S775 - Disco duro 1TB - Memoria RAM 4GB 677 Mhz - Red Ethernet 10/100/1000 - Impresora HP 1022 - Monitor TFT HP 22” Mod. W2216v - S.O. Microsoft© Windows 7 Home Equipos de red: -Switch 4 puertos 10/100/1000 SMC Mod. 24C BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 15 3.3. Estándares y normas Metodología de desarrollo: El proyecto se realizará siguiendo las directrices de Métrica en su versión 3. Protección de datos: Se establecerán los ficheros conforme a la Ley Orgánica de Protección de Datos de 1999, de esta manera los ficheros con datos de carácter personal tendrán que inscribirse en la Agencia de Protección de datos, responsabilidad de la FBCV, y su finalidad será la gestión de los contenidos y comunicaciones comerciales relacionadas con la actividad de la Federación. La adopción de la LOPD será llevada a cabo por una empresa externa. Implementación: La implementación se realizará mediante el lenguaje C# .NET3.5 y el entorno de desarrollo de Microsoft© Visual Studio 2008. La BB.DD. será desarrollada en lenguaje Microsoft© Access 2007. Gracias al empleo de esta tecnología, se consigue un desarrollo ágil, potente y orientado 100% a objetos. Modelo de desarrollo: Prototipado evolutivo, se construye una serie de grandes versiones sucesivas de un producto. El modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. Una vez se crea el primer desarrollo, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente. Modelo de BB.DD.: Modelo entidad-relación de bases de datos. Análisis y diseño: Se usarán los modelos contenidos en Lenguaje de Modelado Unificado UML4 v2. La técnica para la captura de requisitos potenciales de la actualización de requisitos es el modelo de Casos de Uso y para la especificación se usa la Guía IEEE Std. 830-985. Plataforma y Arquitectura: La plataforma del sistema será Microsoft© Windows Framework 3.5, con arquitectura de tres capas y un nivel. 3.4. Requisitos funcionales La captura de requisitos tras el estudio de los formularios de la FBCV, las entrevistas con el personal de administración y el estudio preliminar de su anterior sistema de gestión BILLGEST se resumen en: Gestión de Temporadas: - Gestión de temporadas. Alta, baja y modificación. - Copias de seguridad. Apertura, Cierre, Salvado. - Especificación de número de grupos y divisiones por club. - Acceso directo a diferentes tipos de listado. - Exportación de listados a formato compatible Microsoft© Excel. - Impresión de listados por cualquier impresora compatible con Microsoft© Windows. - Información relativa a los clubes enfrentados y socios que las disputan. - Gestión de actas de temporadas. Alta, baja y modificación. - Sanciones por ruptura de listas de fuerza. - Gestión de árbitros. 4 UML V2.0: Unified Modeling Language (28/04/2010): http://www.uml.org/ 5 Estándar IEEE para la especificación de requisitos de software (28/04/2010): http://www.ctr.unican.es/asignaturas/is1/IEEE830_esp.pdf BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 22 3,2 Introducir división 1 1 B 3,3 Introducir jornada 1 1 B 3,4 Introducir grupo 1 1 B 3,5 Introducir club 1 1 B 3,6 Introducir jugador 1 1 B Figura 4.6. Consultas externas 2 Consultas Externas Evento Nombre del proceso Complejidad Entradas+Salidas. 3,1 Elegir categoría B 3,2 Introducir división B 3,3 Introducir jornada M 3,4 Introducir grupo B 3,5 Introducir club M 3,6 Introducir jugador M Total Consultas Externas 3 3 0 Figura 4.7. Consultas externas 3 # Factor de Complejidad Valor (0..5) 1 Comunicación de Datos. 3 2 Proceso Distribuido. 1 3 Objetivos de Rendimiento 0 4 Configuración de Explotación compartida 1 5 Tasa de Transacciones 0 6 Entrada de Datos EN-LÍNEA 2 7 Eficiencia con el Usuario Final 1 8 Actualizaciones EN-LÍNEA 1 9 Lógica del Proceso Interno Compleja 0 10 Reusabilidad del Código 1 11 Contempla la Conversión e Instalación 1 12 Facilidad de Operación 0 13 Instalaciones Múltiples 1 14 Facilidad de Cambios 0 Factor de Complejidad Total (FCT) 12 Figura 4.8. Factores de complejidad Tipo Elemento Dificultad Peso Cantidad Total Total Elemento Ficheros Internos Simple 7 8 56 Media 10 0 0 Compleja 15 0 0 Total Ficheros Internos 56 Ficheros de Simple 5 0 0 Interfaz Media 7 1 7 Compleja 10 1 10 Total Ficheros de Interfaz 17 Entradas Simple 3 0 0 Media 4 2 8 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 23 Compleja 6 6 36 Total Puntos de Función Entradas 44 Salidas Simple 4 4 16 Media 5 3 15 Compleja 7 1 7 Total Salidas 38 Consultas: Simple 3 3 9 Media 4 3 12 Compleja 6 0 0 Total Consultas 21 Total Puntos de Función Sin Ajustar (PFSA) 176 Figura 4.9. Puntos de función sin ajustar VFA Puntos de función Ajustados 0,77 135,52 Estimación 135,52 C# 474,32 horas A la vista de dichos puntos de función se puede estimar el esfuerzo de dicho proyecto en torno a 474,32 horas para desarrollarlo sobre un lenguaje de alto nivel y quinta generación como es C# 3.5 (aproximadamente 3,5 horas9 por punto de función ajustado). 5.2. Descomposición del esfuerzo por fases y presupuesto Una vez calculado el coste en horas para el desarrollo de la aplicación se establecen las tablas de coste unitario horario según actividad y presupuesto general. Actividad Coste € / hora Planificación del Sistema 20 € Estudio de Viabilidad 20 € Análisis del Sistema 20 € Diseño del Sistema 18 € Construcción del Sistema 18 € Implantación y pruebas 18 € Documentación 18 € Formación 15 € Figura 4.10. Coste/hora según actividad 9 Según los datos del estudio del Software Productivity Research (2009): http://www.gotdotnet.com/team/compare/petshop.aspx BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 24 Concepto Horas Porcentaje Final Precio unitario / hora (IVA excluido) Planificación del Sistema 48,85 10,30% 977 € Estudio de Viabilidad 27,79 5,86% 555,8 € Análisis del Sistema 64,55 13,61% 1.291 € Diseño del Sistema 55,68 11,74% 1.002,2 € Construcción del Sistema 124,74 26,30% 2.245,3 € Implantación y pruebas 74,27 15,66% 1.336,8 € Documentación 49,94 10,53% 898,92 € Formación 28,45 6,00% 426,75 € BASE IMPONIBLE TOTAL DE LA OFERTA 8.733,77 € IVA 1.397,40 € PRECIO TOTAL DE LA OFERTA 10.131,17 € PRECIO MÁXIMO ESCENARIO HIPOTÉTICO <= 10.500 € Correcto 4.11. Oferta económica 5.3. Oferta al cliente Tras el estudio en profundidad de los costes de la implantación del sistema y el margen de beneficio requerido, se asume por tanto un precio de venta de doce mil euros (12.000 €) IVA incluido. Debido a la posibilidad de comercializar la aplicación para otras Federaciones (en principio existen 17 clientes potenciales de los cuales uno parece estar interesado), se plantea la posibilidad de rebajar el precio final del paquete, que quedaría en tres mil novecientos noventa y cinco euros (3.995 €) IVA incluido. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 25 6. Diseño del sistema de información 6.1. Niveles de arquitectura La arquitectura lógica del sistema es una arquitectura multicapa, compuesta por 3 capas10 (presentación, lógica de negocio y acceso a datos): 6.1. Capas de una arquitectura multicapa. 1Capa de presentación: es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. 2Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al sistema de gestión de BB.DD. para almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación. 3Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por un gestor de base de datos relacionales (S.G.B.D.) Access 2007, que realiza todo el almacenamiento de datos, recibe solicitudes de almacenamiento o recuperación de información desde la capa de negocio. De esta manera, se consigue un programa con una mayor escalabilidad, que permitirá en un futuro la ampliación de funcionalidad sin perder la integridad principal lógica de la aplicación. La arquitectura física será una arquitectura de un nivel11, compuesta simplemente de una estación de trabajo que dará soporte a todas las capas lógicas. 10 Arquitectura multicapa Wikipedia (2010): http://es.wikipedia.org/wiki/Cliente-servidor 11 Programación por capas, Wikipedia (2010): http://es.wikipedia.org/wiki/Programación_por_capas BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 26 6.2. Requisitos de diseño El diseño orientado a objetos con el que se desarrollara el sistema requiere de una plataforma compatible. En este caso, la plataforma de desarrollo es .NET de Microsoft©, su entorno de desarrollo Visual Studio 2008, y el lenguaje de desarrollo, orientado 100% a objetos, será C#. El desarrollo será iterativo e incremental, de la siguiente manera: -Obtener los máximos requisitos posibles en el tiempo fijado. Ordenarlos y fijar los más importantes. -Obtener los máximos casos de uso y actores posibles. Ordenarlos por importancia (más importantes para el usuario, más difíciles de implementar o que ayuden a definir lo máximo posible la arquitectura) y detallar sólo los primeros en la lista. -Obtener la arquitectura para esos primeros casos de uso. -Diseño detallado para esos primeros casos de uso, siempre con un plazo. -Codificar y probar. Volver a iterar con nuevos requisitos y casos de uso surgidos, etc., etc.… La programación orientada a objetos permite concebir los programas de una manera bastante intuitiva y cercana a la realidad, aumentando la productividad, la reutilización de código y la mantenibilidad12. 6.3. Excepciones Las excepciones provocadas por el sistema serán todas debidamente tratadas por el programa. Es posible que en algún caso la excepción provoque que el sistema se vuelva inestable y no se pueda recuperar, por lo que todo error llevará un código marcado con el que se identificará claramente el problema y se podrá recurrir a una tabla para su posterior solución de incidencia. No obstante se intentará en la medida de lo posible realizar un buen filtrado de datos de entrada para evitar muchas de las excepciones de error. 6.4. Entorno tecnológico Como se ha explicado anteriormente, el sistema se prevé instalar sobre una arquitectura de un solo nivel físico, esto es todas las capas de la aplicación radican en una sola estación de trabajo. Para la correcta ejecución del software asociado al proyecto es necesario que el sistema posea las librerías del Framework 3.5 de Microsoft©. Estas librerías son totalmente gratuitas y de libre descarga. No obstante, se incluirán en el programa y se auto instalarán en caso de no estar previamente descargadas. 12 Miguel Angel Álvarez, Programación orientada a objetos en PHP (2009): http://www.desarrolloweb.com/articulos/1540.php BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 27 7. Plan de construcción y pruebas 7.1. Plan de Construcción El paquete se realiza con el entorno de programación Microsoft© Visual Studio .NET 2008 usando el Framework 3.5 y el lenguaje de programación C# 3.5. Las pruebas unitarias se realiza con la herramienta Open Source NUnit así como con las propias herramientas incluidas en el entorno de programación. La BB.DD. se realiza con el entorno Visual Studio en formato Access 2007. La aplicación para la generación de reportes (para los carnets de socio) es CrystalReports© .NET La herramienta de creación de paquetes autoinstalables corresponderá con el paquete InstallShield© 2010. 7.2. Alcance de las pruebas Las pruebas del ciclo de vida que se realizarán serán:  Pruebas Unitarias  Pruebas de Integración  Pruebas Funcionales  Pruebas de Rendimiento 7.3. Plan de pruebas del sistema Para el plan de pruebas se realizan pruebas de verificación de requerimientos y pruebas del sistema que incorpora el software. Los pasos para la realización de las pruebas son: - Revisar la verificabilidad del requerimiento. - Especificar el criterio de verificación. - Hacer visible las propiedades o elementos del software necesarios para verificar el cumplimiento del requerimiento. - Hacer controlable los elementos del software necesarios para llevar a cabo las pruebas. - Elaborar el plan de pruebas. - Ejecutar el plan de pruebas y reportar sus resultados. Cada caso de prueba se detallará en un documento que recogerá todas las pruebas de una determinada funcionalidad de la aplicación. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 28 8. Plan de puesta en servicio 8.1. Plan de formación El plan de formación se basará en sesiones dirigidas al personal del departamento donde se actualizará el sistema de información. El plan se dividirá en sesiones teórico/practicas, donde se expondrán casos reales de uso y se explicará el funcionamiento completo de la aplicación. Para el plan se hará uso de material de formación como son las diapositivas electrónicas. 8.2. Plan de manual de usuario El manual de usuario se compondrá básicamente de: - Introducción - Instalación y desinstalación del paquete - Descripción del entorno de trabajo - Funciones del programa - Solución de errores BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 29 9. Conclusiones Varios han sido los factores que han conseguido que el proyecto se implante con éxito y que sea una plataforma robusta y fiable de gestión para la FBCV. Los principales factores son los siguientes: 1. Negociación En este factor se determinan las dos variables principales del proyecto, el tiempo y el costo. Es clave ya que identifica si el proyecto tiene los argumentos para ser exitoso, o están en riesgo el alcance y las expectativas de ambas partes. Gracias a que el tiempo no era una prioridad para la FBCV y los requisitos eran muy concretos, no existieron grandes problemas en la negociación, y las exigencias fueron perfectamente aceptadas tanto por desarrollador como por cliente. 2. Tecnología En este factor se determina sobre qué plataforma tecnológica se desarrolla el proyecto. La selección de la tecnología puede darse por muchos factores, desde el factor económico, hasta el factor de imposición por el cliente o por la empresa desarrolladora. Se tuvo claro desde un primer momento que el desarrollo se haría con una plataforma 100% orientada a objetos y de última tecnología. También era necesario que el desarrollador tuviera experiencia con el lenguaje, y que fuera una solución de bajo coste de desarrollo. Así pues se optó por la versión académica gratuita de Microsoft© Visual Studio 2008 y por varias herramientas de libre distribución que acompañan al paquete. Al cumplir perfectamente para el cliente una implantación con esta tecnología, el proyecto no tuvo problemas al respecto. 3. Metodología La selección de la metodología de desarrollo adecuada depende del tiempo, costo y tecnología seleccionada. Hay que decidir que metodología de trabajo hay que usar según las características del proyecto para poder cumplir las expectativas funcionales y de negocio esperadas. En el proyecto se han usado metodologías altamente testadas y relacionadas con la plataforma de desarrollo elegida, que además han demostrado ser efectivas y cumplir con éxito en muchos proyectos de T.I.C. Estas metodologías eran conocidas de antemano por el desarrollador lo que agilizó en gran medida el tiempo de arranque de los procesos. Tampoco habían exigencias al respecto por parte del cliente. 4. Recursos El último factor del cual depende el éxito del proyecto son los recursos que estarán involucrados, es decir, las personas y sus respectivos perfiles de conocimientos y experiencia en el tipo de proyecto, metodología de trabajo y tecnología. Todo el peso del proyecto recayó sobre una persona, y si bien existía el riesgo de bloqueo, también agilizaba el desarrollo ya que no se producían problemas de comunicación y mala planificación entre los integrantes del equipo. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 30 Para la FBCV la puesta en marcha del software BILLARGEST ha permitido suplir todas las carencias que arrastraban por el uso de su antiguo programa de gestión: - Mejorada interfaz gráfica, más intuitivo y flexible. - Adecuación a las nuevas normativas de la FBCV. - Adecuación a las nuevas exigencias del personal de administración. - Independencia del hardware con respecto al software. - Posibilidad de actualización futura. - Soporte y asistencia. El presente proyecto además servirá de base para las futuras ampliaciones que pretende realizar la FBCV sobre el actual programa, y para conseguir que su herramienta en un futuro mantenga como mínimo los estándares actuales de calidad y fiabilidad. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Documento I 31 Bibliografía13  [AENOR] AENOR (2007): Norma UNE 157801 “Criterios generales para la elaboración de proyectos de Sistemas de Información”.  [CompeticionesV10] (2009) “Competiciones deportivas versión 10” http://www.sagois.com  [FBCV] [1998] Federación de Billar de la Comunidad Valenciana (1998): “Estatutos de la Federación”.  [Gutiérrez] Javier J. Gutiérrez, María J. Escalona, Manuel Mejías y Antonia M. Reina (2006) “Modelos de pruebas” http://www.lsi.us.es/~javierj/publications/MDA14.pdf.  [IBM] IBM (2010) “Best practices for programming in C” http://www.ibm.com/developerworks/aix/library/au-hook_duttaC.html  [ISO 9241-210:2010] (2009) “Ergonomics of human-system interaction” -- Part 210: http://www.usabilitynet.org/tools/r_international.htm#13407.  [Lacalle] Alberto Lacalle (2009) “Importancia de una buena interfaz” http://albertolacalle.com/hci/interfaz.htm  [Lorente] Diana Lorente Marí (2007) “Diseño de una aplicación informática para una empresa del sector de transporte marítimo de mercancías”.  [Marcelo] Marcelo, Julián (2004) Planificación de esfuerzos, costes y recursos. Apuntes de la asignatura. ETSII. UPV.  [Métrica] MÉTRICA. VERSIÓN 3 Consejo Superior de Administración Electrónica. Ministerio de Administraciones Públicas. (2010) “Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información”. www.csi.map.es/csi/metrica3/.  [Montesa] Montesa Andrés, Jose Onofre (2009): “Planificación de proyectos informáticos”. Apuntes.  [Prácticas .NET] Microsoft (2010) “Patterns & Practices” http://msdn.microsoft.com/eses/practices/default(en us).aspx.  [Pressman] Pressman, Roger S. (2006). “Ingeniería del software: un enfoque práctico” McGraw-Hill.  [Sánchez] Sánchez, Juan (2009): UML 2.0 Apuntes.  [SO/IEC DTR 9126-4] (2001) “Software Engineering - Product quality - Part 4: Quality in use metrics” http://www.usabilitynet.org/tools/r_international.htm#9126-4. 13 En base a la norma ISO 690-2 (11-15-1997): http://biblioteca.ucv.cl/herramientas/citaselectronicas/iso690-2/iso690-2.html BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 7 2.1.5. Impresión de Etiquetas. El programa permite la impresión de las Etiquetas introducidas en el apartado anterior. Además permite seleccionar cuales se quieren imprimir, seleccionarlas por diferentes clubes, y que cantidad hacer. Figura 6. Impresión de Etiquetas Modificaciones: La impresión se realizará directamente desde los reportes generados para los socios. El funcionamiento sera similar, pero se gestionará todo mediante el listado general de socios y la selección de las diferentes filas. El formato y las etiquetas físicas imprimibles se volverán a hacer con un nuevo diseño, por lo que no es necesario conservar el formato anterior. 2.2. LISTA DE FUERZA En esta sección se gestiona todo lo relacionado con las Listas de Fuerza: Figura 7. Menú de Lista de Fuerza BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 8 2.2.1. Introducción / Modificación de Listas de Fuerza. El programa permite la impresión de las etiquetas introducidas en el apartado anterior. Además permite seleccionar cuáles se quieren imprimir, seleccionarlas por diferentes clubes, y que cantidad hacer. Campos de entrada - Modificaciones - Figura 8. Modificación de Listas de Fuerza 2.2.2. Consulta. La consulta de la Lista de Fuerza permite entrar en el menu de Edición sin opcion a editar. De esta manera se puede ver directamente la lista de un club. Modificaciones: La opción quedará integrada en el futuro listado y no tiene sentido desarrollarla. 2.2.3. Listado. El listado de la Lista de Fuerza permite mostrar todas las listas introducidas. El criterio de pre-selección es el mismo que en el apartado 1.3, TODAS (lista todas las actas), UNA (Selección de una por club, = 2.2) o SELECCIÓN (Selección de varias de un listado de todas). Modificaciones: La opción quedará integrada en el listado BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 9 2.3. SOCIO En esta sección se gestiona todo lo relacionado con la gestión de socios y sus listados: Figura 9. Menú de socio 2.3.1. Edición de socio El programa permite la gestión (alta – modificación – consultabaja) de los socios de los diferentes clubes, así como de personal de la propia federación. Para introducir un socio, es necesario primero introducir un código. El programa revisa que los tres primeros caracteres del código correspondan a un club. En caso de no serlo, da un mensaje de error. Figura 8. Paso uno de edición de socio Si el número es válido, y la licencia ya existe, muestra la plantilla de la siguiente pantalla con los campos rellenados listos para edición. En caso de no existir, la plantilla aparece con los campos vacios lista para introducir un nuevo socio. El campo búsqueda permite buscar un socio por un nombre concreto. Si existe, la licencia se rellenará automáticamente. Figura 8. Edición de socio ventana principal BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 10 Los datos Nombre Batalla, Código de Club, Tipo de Licencia (JUNIOR/SENIOR) y Nombre de Club se completan automáticamente al introducir el número de licencia de 6 caracteres. Campos de entrada -Número de Licencia -Nombre -Apellidos -DNI -Fecha nacimiento -Dirección -Población -CP -Provincia -Teléfono -Fax Modificaciones -El código de Socio no tendrá correlación con el código de Club. La relación se hará por un campo en la tabla independiente - Se necesita incluir el campo Email y el campo Licencia en Vigor - Se elimina el campo Fax - Se intercambia la opcion independiente de listas de fuerza por el orden de socio. 2.3.2. Listado de socio Se selecciona el tipo de query para la extraccion del listado y posteriormente se permite la impresión de los mismos. Figura 9. Listado de socio Modificaciones: La opción quedará integrada en el listado general de socios, no habrá distinción para las búsquedas. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 11 2.3.3. Listado para Seguridad Social El programa permite mostrar un listado de licencias por rango para las gestiones administrativas en la seguridad social. Figura 10. Listado para la S.S. Modificaciones: La opción quedará integrada en el listado general de socios, no habrá distinción para las búsquedas. 2.3.4. Licencias Licencias permite imprimir los carnets de socios. Esta opción permite realizar una preselección antes de acceder al listado de impresión de etiquetas del apartado 1.4. Figura 11. Selección de Licencias Modificaciones: La opción quedará integrada en el detalle de Socios, se reconstruirá y la selección se realizará filtrando un listado general mediante lista desplegable. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 12 2.3.5. Clasificación Uno de los requisitos elementales del software es la generación de tablas de clasificación, tanto para jugadores como para clubs. En este apartado se pueden mostrar listados de clasificaciones en base a criterios seleccionados. La selección se realiza en base al siguiente diagrama de actividad1: 1 Diagrama de actividad: http://es.wikipedia.org/wiki/Diagrama_de_actividades Liga División Grupo Jornada 3.5 Clasificación Club Orden Todas 3 Bandas, Pool, Libre Una: Honor, 1ª, 2ª, 3ª, 4ª, 5ª, 6ª Uno: A,B,C,D,E,F,G Nº Jornada {1..20} Todos Todos Uno: {Nombre Club} Promedio Puntos Nombre BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 13 Figura 12. Clasificación de jugadores Figura 13. Selección de orden Modificaciones: La Clasificación por Jugadores se filtrará de dos maneras. La primera sera por menú, existirán diferentes opciones del menú general para acceder a las clasificaciones de jugadores por tipo de Liga. El segundo filtro, que corresponderá a los pasos 2 y 3, se realizará mediante lista desplegable, la cual solo mostrará las opciones realmente existentes (si no existen grupos G, no se mostrará esa opcion en la lista). El resto de las selecciones se incluyen implícitamente en los campos del listado a mostrar, los cuales servirán para restringir la impresión de los determinados socios. 2.3.6. Mejor Promedio El mejor promedio permite mostrar un listado de socios clasificados por promedios de mayor a menor. Mediante unos criterios se puede seleccionar que campos se quieren mostrar y el orden. Posteriormente estos promedios se imprimen y se distribuyen a los diferentes clubs. Figura 14. Mejor promedio BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 14 Modificaciones: La opción de mejor promedio queda implícita en el listado general de clasificación mediante una columna, la cual puede reordenar la lista al ser pulsada, por lo que se evita esta funcion de negocio. 2.3.7. Lista Subs Otra de las caracteristicas de los listados de socio es la posiblidad de seleccionar socios por categoria Sub15 (menor de 15 años antes de iniciar la temporada), Sub-17 y Sub-21. Figura 15. Listados Sub. Modificaciones: Esta opción en la practica no se utiliza, por lo que queda descartada su implimentación (no obstante es posible reordenar los listados por fecha de nacimiento). BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 15 2.4. CLUB En esta seccion se gestiona todo lo relacionado con la gestión de clubes y sus listados: Figura 16. Menú de club 2.4.1. Edición de Club Edición de Club permite las Altas, Modificaciones, Consultas y Bajas de los Clubes en la BB.DD. En primera instáncia se introduce un código de tres digitos, en caso de existir el club, la plantilla de la siguiente pantalla aparece con los campos rellenados y es editable. En caso de no exisitir, la pantalla aparece con campos vacios. El campo búsqueda permite introducir un nombre de club y comprobar si existe o no. Figura 17. Edición de club, primer paso Figura 18. Edición de club ventana principal Campos de -Código BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo I 16 entrada -Nombre -Nombre de Batalla -Nacional -Dirección -Dirección de Correo -Población -Provincia -CP -Teléfono -Fax Modificaciones -Se necesita incluir el campo CIF, Web, Email - Se necesita diferenciar entre dirección jurídica y dirección de correspondencia. - Se elimina la opción Internacional 2.4.2. Listado de Club EL Listado de clubes permite imprimir un listado con todos los clubes inscritos en la BB.DD. La opción imprime automáticamente el listado. Figura 19. Listado de club Modificaciones: Esta opción sera un clon de los listados de socios pero para clubes. El formato será completamente diferente. 2.4.3. Clasificación de club La Clasificación de club es una opción pareja a la clasificación de socios pero el filtrado solamente contiene los pasos LIGA -> DIVISION -> GRUPO -> JORNADA. El sistema calcula los puntos de los clubes en base a las BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 3 actualizado el Plan de Sistemas de Información para incluir en él todos los cambios necesarios, garantizando el cumplimiento adecuado del mismo. 1. Inicio del Plan de Sistemas de Información “El objetivo de esta actividad es determinar la necesidad del Plan de Sistemas de Información y llevar a cabo el arranque formal del mismo, con el apoyo del nivel más alto de la organización. Como resultado, se obtiene una descripción general del Plan de Sistemas de Información que proporciona una definición inicial del mismo, identificando los objetivos estratégicos a los que apoya, así como el ámbito general de la organización al que afecta, lo que permite implicar a las direcciones de las áreas afectadas por el Plan de Sistemas de Información.” Además, se identifican los factores críticos de éxito y los participantes en el Plan de Sistemas de Información, nombrando a los máximos responsables. Tareas propuestas para esta actividad: 1.1. Análisis de la necesidad del PSI 1.2. Identificación del alcance del PSI 1.3. Determinación de responsables 1.1. Análisis de la necesidad del PSI Objetivo: “Se analizan las expectativas de las áreas que han planteado la necesidad de llevar a cabo el Plan de Sistemas de Información, así como los productos finales esperados. Una vez verificado que las necesidades de la organización se deben cubrir con un Plan de Sistemas de Información, se toma la decisión de su inicio.” Aprobación del inicio del PSI: El departamento de administración y su responsable el secretario general de la organización ha decidido impulsar la puesta en marcha de un nuevo Plan de Sistemas de Información de actualización y apoyo a los procesos existentes en la organización. Esta decisión cuenta con el apoyo explícito del presidente de la Federación, y se basa en la necesidad de modernizar los procesos de la organización, dotándolos de la tecnología que permita un adecuado, coherente y preciso tratamiento de una información cada vez más voluminosa y crítica. Este apoyo de la Dirección se considera especialmente necesario, máxime teniendo en cuenta la novedad que un proyecto de este tipo representa para la empresa, al no existir precedentes en cuanto a Planes de Sistemas de Información o estudios similares. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 4 1.2. Identificación del alcance del PSI Objetivo: “Se define el ámbito del Plan de Sistemas de Información en términos de procesos de la organización afectados y, como consecuencia, las direcciones de las áreas implicadas. Se determinan los objetivos estratégicos de la organización que deben ser considerados en el Plan de Sistemas de Información, así como aquellos aspectos que la dirección considera factores críticos de éxito para el mismo.” Ámbito y Objetivos del PSI: El Comité de Dirección está formado por el Presidente, Vicepresidente 1º, Vicepresidente 2º y los Directores de todos los Departamentos. Tras una reunión se decide que el plan de Sistemas recaiga sobre los procesos manejados por el departamento de administración en exclusiva, por tanto el resto de departamentos no variarán la definición de su sistema de información, cierto es que en cierta medida el impacto en administración será patente en otros departamentos, indirectamente. Los objetivos estratégicos y sus factores críticos de éxito a conseguir con la elaboración del plan de sistemas de información son: Eliminar carga del departamento de Administración Rapidez y facilidad de uso de la actualización del paquete de gestión. Agilidad en la toma de decisiones Conexión directa del sistema de información con los respectivos responsables de los departamentos Aumento del número de clubes asociados Dotar de más servicios a la federación, publicitar mas la actividad y establecer una política de competencias Reducción del tiempo en la publicación de resultados Automatización del sistema para las actualizaciones de resultados y su difusión. Dotar de mayores facilidades al acceso de información para clubes y socios Publicar la información deseada con la mayor rapidez y que esta información pueda ser dispuesta por cualquiera de sus clubes y asociados. Remodelación de la web y conexión directa y automática con el software de gestión Auto actualización de la web corporativa en base a los datos introducidos en el sistema de información Facilitar el mantenimiento de los sistemas Facilidad para la compra y sustitución del material hardware y software. Gran capacidad de almacenamiento de información y seguridad a todos los niveles El volumen de información y su seguridad no debe ser un factor limitante para la consecución del plan de sistemas. Para ello se ha puesto en marcha un Plan Operativo cuyos primeros objetivos consisten en la compra de hardware informático que posibilite la adopción del nuevo paquete software. Asimismo es necesario el apoyo firme de Dirección en todo el proyecto, y es necesario que el volumen de trabajo crezca de forma controlada, a fin de evitar que un aumento de trabajo obligue a los responsables de los Departamentos a reducir la dedicación exigida por las tareas del Plan encomendadas. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 5 1.3. Determinación de responsables Objetivo: “Delimitado el ámbito del Plan de Sistemas de Información, se implica a las unidades organizativas afectadas, informándoles de la decisión y solicitando su participación en el estudio que se va a iniciar. En sesiones de trabajo con las distintas unidades se determinan los principales responsables del Plan de Sistemas de Información a los que seguidamente se les debe comunicar su nombramiento y solicitar su aceptación.” Las personas seleccionadas serán los participantes en la Dirección del Plan de Sistemas de Información. También se determina la necesidad de apoyo en la función de seguimiento que determine el Plan de Sistemas de Información. Dicha necesidad depende de la amplitud del Plan de Sistemas de Información y de la duración prevista para el mismo. Si se considera necesario, en esta actividad se proponen los responsables de dicho seguimiento. Responsables del PSI: La responsabilidad en primera instancia del Plan de Sistemas de Información recae sobre el departamento de administración, que es el principal objetivo en la reestructuración del plan. Asimismo se decide nombrar responsables en caso de que se necesite colaboración a los directores de cada departamento. - Director del Plan de Sistemas de Información: Sra. Dña. Cristina González (Secretario General). - Representantes de las áreas: PRESIDENCIA: D. Antonio Ortiz Martínez ADMINISTRACION: Dña. Cristina González TESORERIA/CONTABILIDAD Dña. Cristina González DIRECCION DEPORTIVA: D. Alejandro Gil Martínez COMITE JUECES-ARBITR: D. Angel Gutiérrez Alcaraz COMITE DE COMPETICION: D. Angel Gutiérrez Alcaraz COMITE DE APELACION: D. Julio Martínez Cusí DELEGADO ALICANTE: D. Luis M. González de la Vega DELEGADO CASTELLON: D. Jesús Gallen Naches DELEGADO DE POOL: D. Antonio Morales Fernández BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 6 2. Definición y Organización del PSI En esta actividad se detalla el alcance del plan, se organiza el equipo de personas que lo va a llevar a cabo y se elabora un calendario de ejecución. Todos los resultados o productos de esta actividad constituirán el marco de actuación del proyecto más detallado que en PSI 1 en cuanto a objetivos, procesos afectados, participantes, resultados y fechas de entrega. Tareas propuestas para esta actividad: 2.1. Especificación y ámbito de alcance 2.2. Organización del PSI 2.3. Definición del plan de trabajo 2.4. Comunicación del plan de trabajo 2.1. Especificación del ámbito y alcance Objetivo: “De manera más concreta que en la actividad Inicio del Plan de Sistemas de Información (PSI 1), en esta tarea se describe el ámbito de los procesos de la organización a considerar. Igualmente, se definirá el alcance, es decir, los objetivos específicos del Plan de Sistemas de Información. Puede ser necesario determinar distintos objetivos para cada proceso del proyecto. Los responsables de los distintos procesos de la organización afectados por el Plan de Sistemas de Información participarán de forma activa en la definición de los objetivos, sin perder de vista los resultados de la actividad anterior.” Descripción general de procesos afectados y catalogo de objetivos: Se especifican los objetivos a alcanzar por cada departamento: 1) Administración Proceso: La Sra. González, introduce los clubes y socios que formalizan su alta con el formulario pertinente a través de las delegaciones provinciales o directamente en un programa no estándar con base de datos propia y que corre bajo MS-DOS, llamado BILLGEST. Objetivos: Agilizar el trabajo, actualizar formatos y disponer de una BB.DD. de formato Microsoft© Office editable con posibilidades de exportación, además se debe mantener una BB.DD. común que permita mejorar la coherencia en la información. Proceso: El personal de administración imprime los listados semanalmente desde BILLGEST y los envía por correo ordinario a las direcciones físicas incluidas en la BB.DD. de BILLGEST. Objetivos: Simplificar el trabajo del personal automatizando el proceso de envío y cambiar a largo plazo el envío en papel por formato electrónico. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 7 Proceso: El personal de administración imprime los carnets de Socio anualmente una vez todos los socios están formalizados por sus respectivos clubes y son recibidos los impresos de inscripción. Objetivos: El diseño completo del carnet será impreso automáticamente al mismo tiempo que los datos para evitar tener que disponer de carnets vírgenes preestablecidos, asimismo se debe conseguir agilizar el envío de carnets a los clubes. Proceso: La Sra. González cierra la temporada una vez todas las ligas y partidos han finalizado y guarda una copia de seguridad en diskettes de 3 ½ de la misma. Objetivos: Poder realizar backups en cualquier medio físico y agilizar la conclusión de temporadas con guardados automáticos. Proceso: El personal de administración manda a los Socios información sobre nuevos eventos, torneos y descuentos ofrecidos por la FBCV. Objetivos: Aumentar la capacidad de envío de publicidad en formato electrónico de la FBCV con envíos masivos pero especializados con información que considere oportuna el secretario general. Proceso: Administración recibe las actas de las temporadas firmadas por los árbitros que la han disputado con un formulario estándar impreso. Objetivos: Conseguir a largo plazo el uso de firma electrónica digital para que los propios árbitros puedan firmar sus actas y enviarlas en formato electrónico al sistema de información de la FBCV. Proceso: Administración recibe una solicitud por parte de un socio adscrito a un club para recibir personalmente por email las tablas clasificatorias y promedios. Objetivos: El Socio debe poder tramitar electrónicamente sus solicitudes y en base a sus peticiones debe remitírsele toda la información requerida. Proceso: Administración recibe un formulario de impugnación por parte del comité de apelación. Objetivos: De la misma manera el Comité de Apelación debería, usando su intranet, introducir en el sistema las impugnaciones que lleven a cabo los clubes. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 8 Proceso: La Sra. González envía al comité de dirección deportiva la lista con los clubes y socios adscritos a principio de temporada, con su situación regularizada. Objetivos: El software de gestión debe filtrar las altas con fallos y defectos de forma, asimismo una vez comprobadas y validadas por el personal de administración, estas deben enviarse en formato electrónico a Dirección Deportiva para su alta final. Proceso: Administración recibe el acta de temporada con los cambios si los hubiere respecto a otros años, ligas a disputar, calendario de competición, etc. etc. Objetivos: La información debe introducirse en el sistema de una manera rápida y fácil, con formatos preestablecidos y con preferencias por usuario. Proceso: Los ordenadores de administración están interconectados mediante un cable de par trenzado, 2 tarjetas de red, y no comparten impresoras. Objetivos: La conexión de los ordenadores a internet debe ser totalmente independiente, además las impresoras deben estar compartidas. 2) Comité de Apelación Proceso: El Comité de Apelación recibe un recurso por parte de un Club mediante una carta dirigida al director del comité por asuntos relacionados con la competición. El comité aprueba o desestima el recurso e informa al remitente y en caso de modificar alguna acta también se lo comunica al personal de Administración. Objetivos: Las apelaciones deben tramitarse de manera electrónica, introduciendo los cambios si los hubiese directamente en el sistema evitando el trabajo de administración. 3) Delegaciones Proceso: La delegación provincial recibe una solicitud de diversa índole por parte de un club. Objetivos: Las delegaciones provinciales deben estar interconectadas con la Federación central por medio de una red privada virtual corporativa. Todos los procesos deben centralizarse en un mismo sistema de información. 4) Presidencia Proceso: El presidente o sus vicepresidentes aprueban o rechazan una propuesta. Objetivos Las propuestas, además de firmarse en un acuerdo escrito e introducidas en los estatutos, deben ser incluidas en el sistema de información de la FBCV. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 9 5) Tesorería Proceso: Operaciones con los flujos contables y libros de cuentas Objetivos: Se debe eliminar todas las operaciones en papel y habilitar un software de gestión que permita llevar una contabilidad electrónica de manera segura. Las aprobaciones y denegaciones por parte de Tesorería también deben ser comunicadas de manera electrónica a los departamentos afectados. 6) Dirección deportiva Proceso: Se decide la modificación de alguna norma establecida en los estatutos. Objetivos: Toda modificación debe introducirse en el sistema de información y por tanto modificar automáticamente las opciones de las actas clubes y ligas del software de gestión de ligas sin necesidad de personal externo de administración. 2.2. Organización del PSI Objetivo: “En esta tarea se tratan cuestiones relacionadas con la organización del trabajo para llevar a cabo el Plan de Sistemas de Información. Se seleccionan los participantes, valorando el número y perfil de profesionales de Sistemas y Tecnologías de la Información y Comunicaciones (STIC) necesarios en función de los objetivos perseguidos. Asimismo, se determinan las funciones de los responsables de la dirección y seguimiento del Plan de Sistemas de Información. Adicionalmente, se concretan aspectos logísticos relacionados con el material, salas de reuniones, estándares de documentación, etc.” Equipo de trabajo: El equipo de trabajo que realizara el Plan de Sistemas de Información corresponde a: 1) Jefe de Proyecto de PSI Nombre: Sra. Cristina González. Cargo: Secretario General Conocimientos Tecnologías de la Información: Medio Funciones: - Coordinar el Plan de Sistemas de Información. - Participar en las tareas que le sean encomendadas en el Plan. - Crear el calendario de seguimiento del PSI. - Asegurar la consecución de objetivos y tareas del Plan. - Participar en todas las reuniones relacionadas con el PSI. - Detectar necesidades de formación de los usuarios participantes. - Decidir sobre las posibles modificaciones técnicas del proyecto. - Aprobar los resultados de la realización del PSI. - Introducción de los datos correspondientes en el sistema. 2) Responsables Funcionales Son los respectivos Jefes de los departamentos. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 10 Conocimientos T.l.: Bajo Funciones: - Participar en las tareas que le sean encomendadas en el PSI. - Participar en todas las reuniones relacionadas con el PSI de su departamento. - Coordinar al personal de su departamento. 3) Consultores Externos Equipo técnico que elaborará los productos a entregar. Conocimientos T.l.: Alto Funciones: - Captación de información in situ o diferida mediante entrevistas, formularios e impresos con el personal requerido. - Evaluación de la información recogida. - Elaboración de informes y productos especificados en el PSI. 2.3. Definición del plan de trabajo Objetivo: “El objetivo de esta tarea es determinar todos los productos finales del Plan de Sistemas de Información, así como la fecha prevista de obtención y entrega de los mismos. Es necesario planificar las distintas actividades y estimar los tiempos requeridos para llevarlas a cabo, teniendo en cuenta la disponibilidad de los usuarios del Plan de Sistemas de Información. Se deben considerar también los factores críticos de éxito, identificados en la actividad anterior y recogidos en la descripción general de procesos de la organización afectados, ya que pueden condicionar la elaboración del plan de trabajo.” Se detallan las actividades, asignando participantes, tiempos y responsables de cada una de ellas, los resultados esperados y el plan de trabajo a seguir. Plan de trabajo: El plan de trabajo y el calendario detallado para la realización del PSI se especifica a continuación: Figura 2.1. Plan de trabajo BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 11 2.4. Comunicación del plan de trabajo Objetivo: “Una vez definido el plan de trabajo se comunica a los usuarios del Plan de Sistemas de Información con el fin de que sea aceptado. Esto permite que los usuarios conozcan el método de trabajo a seguir, los resultados a obtener y la dedicación necesaria por su parte.” Aceptación del plan de trabajo: El Plan de trabajo es comunicado a los usuarios del Plan de Sistemas de Información a fin de darlo a conocer y obtener su aceptación. 3. Estudio de la información relevante El objetivo de esta actividad es recopilar y analizar todos los antecedentes generales que puedan afectar a los procesos y a las unidades organizativas implicadas en el Plan de Sistemas de Información, así como a los resultados del mismo. Pueden ser de especial interés los estudios realizados con anterioridad al Plan de Sistemas de Información, relativos a los sistemas de información de su ámbito, o bien a su entorno tecnológico, cuyas conclusiones deben ser conocidas por el equipo de trabajo del Plan de Sistemas de Información. Tareas propuestas para esta actividad: 3.1. Selección y análisis de antecedentes 3.2. Valoración de antecedentes 3.1. Selección y análisis de antecedentes Objetivo: “Se seleccionan las fuentes de información y documentación a considerar en este estudio, teniendo en cuenta todos aquellos antecedentes de interés: plan estratégico de sistemas de información, estudios previos, plan general informático, etc. y se analiza el contenido de la información anterior. En el inicio y organización del Plan de Sistemas de Información se habrá orientado sobre la existencia de estos antecedentes, para facilitar al equipo de trabajo el desarrollo de esta actividad. Asimismo, se debe entrevistar a las personas de la organización que puedan aportar información adicional sobre antecedentes que deban ser considerados en el Plan de Sistemas de Información, al margen de la documentación disponible. La información recogida se tiene también en cuenta en la valoración de los mismos.” Análisis de antecedentes: Una vez analizadas las unidades organizativas se entrevista a la Sra. Cristina González, responsable de Administración y Secretario General de la FBCV, que es la persona responsable del sistema de información actual de la Federación. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 12 De la entrevista se concluye que no existe ningún tipo de estudio previo sobre Sistemas de Información, y que la informatización de la organización se produjo de forma no planificada e independiente para cada tarea, siempre con ayuda exterior. 3.2. Valoración de antecedentes Objetivo: “Se realiza la valoración de los antecedentes analizados en la tarea anterior y las conclusiones se recogerán en el catálogo de requisitos. La realización de esta valoración ayudará a establecer términos de referencia en cuanto a estándares, procedimientos, normativas, etc., si es que existen.” Antecedentes: Como se ha especificado anteriormente no existe ningún estudio previo, por lo que el Plan de Sistemas de Información ha de empezar desde cero. 4. Identificación de requisitos El objetivo final de esta actividad va a ser la especificación de los requisitos de información de la organización, así como obtener un modelo de información que los complemente. Para conseguir este objetivo, se estudia el proceso o procesos de la organización incluidos en el ámbito del Plan de Sistemas de Información. Para ello es necesario llevar a cabo sesiones de trabajo con los usuarios, analizando cada proceso tal y como debería ser, y no según su situación actual, ya que ésta puede estar condicionada por los sistemas de información existentes. Del mismo modo, se identifican los requisitos de información, y se elabora un modelo de información que represente las distintas entidades implicadas en el proceso, así como las relaciones entre ellas. Por último, se clasifican los requisitos identificados según su prioridad, con el objetivo de incorporarlos al catálogo de requisitos del Plan de Sistemas de Información. Tareas propuestas para esta actividad: 4.1. Estudio de los procesos del Plan de Sistemas de Información 4.2. Análisis de las necesidades de información 4.1. Estudio de los procesos del PSI Objetivo: “Se estudia cada proceso de la organización incluido en el ámbito del Plan de Sistemas de Información. Para cada uno de ellos, es necesario identificar las actividades o funciones, la información implicada en ellas y las unidades organizativas que participan en el desarrollo de cada actividad. Para obtener esta información es necesario llevar a cabo sesiones de trabajo con los usuarios implicados en cada uno de los procesos a analizar. Una vez contrastadas las conclusiones, se elabora el modelo correspondiente a cada proceso. Si existe relación entre los distintos modelos, se unifican en la medida de lo posible, con el fin de proporcionar una visión global en el contexto de la organización y facilitar una identificación de requisitos más objetiva.” BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 19 Internet Switch ones Se realiza un estudio de cada propuesta, indicando ventajas e inconvenientes, así como el nivel de respuesta a las necesidades identificadas en la tarea anterior. Por último, una estimación económica global puede ayudar a elegir la alternativa que va a ser propuesta, para la cual pueden incluirse opciones.” Arquitectura tecnológica: La infraestructura tecnológica con la que cuenta actualmente la FBCV corresponde a dos maquinas IBM PC X86 compatibles con sistema operativo Microsoft Windows XP y Microsoft Windows 98 SE respectivamente. Uno de ellos dispone de una impresora Epson de tipo matricial. Los ordenadores están conectados entre sí por una red de tipo TCP/IP mediante un cable de par trenzado, y uno de ellos realiza la función de conexión compartida a internet. Vistas las necesidades de infraestructuras tecnológicas basadas en la situación actual y los requisitos (no se establecerá un software de gestión para un entorno multicapa, multiusuario o multipuesto) se establece que: 1. Acceso a Internet: la única modificación corresponderá a la necesidad de independencia en las conexiones de internet, para ello se sustituirá el cable de par trenzado por un switch de 4 puertos 10/100mbps. La conexión de alta velocidad por cable de fibra óptica permanece inalterada. La estructura general queda de la siguiente manera: Figura 7.1. Estructura física 2. Sistemas Operativos: Debido principalmente a la existencia de licencias y al conocimiento de los usuarios, así como a la elección del sistema operativo de red, la decisión tomada en este aspecto es la de mantener los sistemas operativos en los equipos existentes, e introducir en los posibles nuevos equipos el sistema operativo de Microsoft más actual con el que cuenten, ya que los sistemas de gestión serán 100% compatibles con cualquier S.O. Microsoft. 3. Hardware: Se opta por hardware clónico analizando las prestaciones y los precios. Debido a que la experiencia de uso de este tipo de equipos en la empresa ha resultado exitosa no se observa la necesidad del cambio de equipos, Se reutilizarán los equipos existentes, adquiriendo los necesarios según Sistemas y aplicaciones. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 20 8. Definición del plan de acción En el Plan de Acción, que se elabora en esta actividad, se definen los proyectos y acciones a llevar a cabo para la implantación de los modelos de información y de sistemas de información, determinados en las actividades Identificación de Requisitos (PSI 4) y Diseño del Modelo de Sistemas de Información (PSI 6), con la arquitectura tecnológica propuesta en la actividad Definición de la Arquitectura Tecnológica (PSI 7). El conjunto de estos tres modelos constituye la arquitectura de información. Dentro del Plan de Acción se incluye un calendario de proyectos, con posibles alternativas, y una estimación de recursos, cuyo detalle será mayor para los más inmediatos. Para la elaboración del calendario se tienen que analizar las distintas variables que afecten a la prioridad de cada proyecto y sistema de información. El orden definitivo de los proyectos y acciones debe pactarse con los usuarios, para llegar a una solución de compromiso que resulte la mejor posible para la organización. Por último, se propone un plan de mantenimiento para el control y seguimiento de la ejecución de los proyectos, así como para la actualización de los productos finales del Plan de Sistemas de Información. Tareas propuestas para esta actividad: 8.1. Definición de proyectos a realizar 8.2. Elaboración del plan de mantenimiento 8.1. Definición de proyectos a realizar Objetivo: “Se determinan los proyectos y acciones necesarios para implantar la arquitectura de información propuesta, definiendo para cada proyecto los objetivos que cubre y cualquier observación que se considere relevante.” A continuación, se asignan prioridades tratando de combinar diferentes criterios como: - Relación con los objetivos considerados en el Plan de Sistemas de Información. - Condicionantes técnicos que impliquen dependencias entre proyectos. - Tiempo de implantación. - Beneficios para la organización (tangibles e intangibles). - Limitaciones y consideraciones relativas a la organización (impacto, necesidades de formación, etc.). - Recursos disponibles a corto y medio plazo, tanto de las áreas de Sistemas de Información y Tecnologías de la Información como de los usuarios. - Situación de riesgo de algunos de los sistemas actuales a sustituir o mejorar. - Otros. Después del estudio de todos los elementos anteriores, se propone el calendario de proyectos que mejor conjugue todas las restricciones analizadas previamente, estimando fechas de principio y fin de cada uno de ellos, así como los recursos necesarios para los más inmediatos. Se hará énfasis en los objetivos estratégicos soportados por el Plan de Sistemas de Información. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 21 Por último, se completa el plan de proyectos considerando los factores críticos de éxito para llevar a cabo la propuesta, así como el plan de acciones necesarias, deducidas del análisis de dichos factores (planes de formación, gestión del cambio, etc.). Las conclusiones obtenidas deben ser contrastadas y modificadas, si se estima conveniente, con las aportaciones de los usuarios. Plan de proyectos: Los criterios de decisión se establecerán en base a: 1) Prioridad 2) Dependencias 3) Coste Por tanto, se implantarán los sistemas de información de la siguiente manera: Figura 8.1. Plan de implantación En primera instancia se implantará la infraestructura tecnológica que dará soporte a los proyectos del Plan de Sistemas de información. Consistirá en la compra de los nuevos equipos que actualizaran los equipos existentes, el switch y las impresoras acordadas. Una vez instalada la base tecnológica se procederá a la implantación de los diferentes sistemas software estudiado. Al ser una única implantación de un programa cerrado no conllevara un calendario de implantación en fases en el cliente. El desarrollo contemplara en un primer momento la creación del modulo de clubes, posteriormente el de socios y en último lugar el modulo de ligas. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 22 8.2. Elaboración del plan de mantenimiento Objetivo: “Una vez establecido el plan de acción, se deben definir las acciones que permitan mantener actualizado el Plan de Sistemas de Información a su terminación, y conocer el grado de avance de los proyectos que en él se han definido.” Todo ello se denomina Plan de Mantenimiento del Plan de Sistemas de Información. En este plan de mantenimiento, entre otros aspectos que se puedan considerar relevantes para la organización, se deben establecer los productos finales del Plan de Sistemas de Información que se van a mantener actualizados, el soporte para los mismos, y cuándo y por quién van a ser modificados, así como la frecuencia y situaciones en los que se debe revisar el plan de proyectos y los responsables de hacerlo. También se determina a quiénes se informará, y con qué periodicidad, del grado de avance del plan establecido o de los cambios que en él se produzcan. Plan de mantenimiento: Se convocarán reuniones semanales para los grupos de trabajo correspondientes a cada tarea. Al final de estas reuniones se rellenará un acta donde se expondrán los avances conseguidos hasta el momento y las diferentes incidencias que hayan surgido. Una vez este desarrollada una beta preliminar instalable, se convocara al personal de administración para las primeras pruebas e instalaciones. Es el personal de administración el responsable de valorar la implantación. Las incidencias que vayan surgiendo serán informadas por los medios habituales, email o teléfono, al director del proyecto. Él es el encargado de solventarlas en el periodo más corto de tiempo posible. En caso de que aparezcan nuevas necesidades, se estudiará cada caso concreto, en caso de ser modificaciones de poca envergadura se incluirán directamente en el proyecto. En otro caso, tendrán que ser evaluadas y presupuestadas por parte del implantador. 9. Revisión y aprobación del PSI Esta actividad tiene como objetivo contrastar con los responsables de la dirección del Plan de Sistemas de Información la arquitectura de información y el plan de acción elaborados anteriormente, para mejorar la propuesta si se considera necesario y por último, obtener su aprobación final. Tareas propuestas para esta actividad: 9.1. Aprobación del Plan de Sistemas de Información BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-1 23 9.1. Aprobación del PSI Objetivo: “Se entrega la propuesta final, y se solicita formalmente al Comité de Dirección del Plan de Sistemas de Información la aprobación de la misma. Por último, se debe informar de los resultados a las unidades organizativas participantes y a todas aquellas afectadas por los resultados del Plan de Sistemas de Información.” Aprobación del PSI: Una vez reunidos presidente y vicepresidentes se acuerda por unanimidad la aprobación del Plan de Sistemas de Información propuesto. Se comunica al departamento de Administración y a su responsable, para comenzar la consecución de los proyectos propuestos. A su vez administración lo comunica al Jefe del Proyecto. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 1 Anexo II-2. Índice: 1. Establecimiento del alcance del sistema ............................................................................... 2 1.1. Estudio de la solicitud ................................................................................................... 3 1.2. Identificación del alcance del sistema ........................................................................... 4 1.3. Especificación del alcance del EVS ................................................................................ 4 2. Estudio de la situación actual ................................................................................................ 5 2.1. Valoración del estudio de la situación actual ................................................................ 6 2.2. Descripción de los sistemas de información actuales ................................................... 6 2.3. Realización del diagnóstico de la situación actual ........................................................ 8 3. Definición de requisitos del sistema ..................................................................................... 8 3.1. Catalogación de requisitos ............................................................................................ 8 4. Estudio de alternativas de solución .................................................................................... 11 4.1. Preselección de alternativas de solución .................................................................... 11 4.2. Descripción de las alternativas de solución ................................................................ 12 5. Valoración de las alternativas ............................................................................................. 15 5.1. Estudio de la inversión ................................................................................................ 15 5.2. Estudio de los riesgos .................................................................................................. 16 6. Selección de la solución ...................................................................................................... 17 6.1. Evaluación de las alternativas y selección ................................................................... 18 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 2  Estudio de Viabilidad 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.” 1. Establecimiento del alcance del sistema “En esta actividad se estudia el alcance de la necesidad planteada por el cliente o usuario, o como consecuencia de la realización de un PSI, realizando una descripción general de la misma. Se determinan los objetivos, se inicia el estudio de los requisitos y se identifican las unidades organizativas afectadas estableciendo su estructura. Se analizan las posibles restricciones, tanto generales como específicas, que puedan condicionar el estudio y la planificación de las alternativas de solución que se propongan. Si la justificación económica es obvia, el riesgo técnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoración y evaluación de las mismas, sino que éste se orientará a la especificación de requisitos, descripción del nuevo sistema y planificación. Se detalla la composición del equipo de trabajo necesario para este proceso y su planificación. Finalmente, con el fin de facilitar la implicación activa de los usuarios en la definición del sistema, se identifican sus perfiles, dejando claras sus tareas y responsabilidades.” BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 3 Tareas propuestas para esta actividad: 1.1. Estudio de la solicitud 1.2. Identificación del alcance del sistema 1.3. Especificación del alcance del EVS 1.1. Estudio de la solicitud Objetivo: “Se realiza una descripción general de la necesidad planteada por el usuario, y se estudian las posibles restricciones de carácter económico, técnico, operativo y legal que puedan afectar al sistema. Antes de iniciar el estudio de los requisitos del sistema se establecen los objetivos generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente. Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de Información vigente, se debe de tomar como referencia el catálogo de requisitos y la arquitectura de información resultante del mismo, como información adicional para la descripción general del sistema y determinación de los requisitos iniciales.” Estudio de la situación actual: La necesidad prioritaria para el cliente, que será el punto principal del objeto de estudio, es la actualización de su herramienta de gestión actual. Como se ha comentado anteriormente, la funcionalidad principal que debe aportar la actualización es la misma que la que aportaba la herramienta anterior, añadiendo algunas nuevas funciones y actualizando otras conforme a los nuevos estatutos, reglas y prioridades de la FBCV. La funcionalidad por tanto radica en la gestión de los datos de los clientes, los cuales son los socios y clubes adscritos a la federación, y la gestión de las temporadas de ligas anuales que se desarrollan en la comunidad. Los datos que genere el programa serán tratados con otras herramientas las cuales no serán desarrolladas. La restricción principal a la que la FBCV se enfrenta es la de carácter económico. La FBCV cuenta con unos ingresos muy limitados, dados en parte por la parte proporcional que cobra a los socios inscritos en clubes, como por los mismos clubes. Por otro lado, cuenta con una subvención anual del Consell Valencià de L’Esport. Con estos ingresos debe cubrir salarios de los componentes de la Federación, gastos derivados de los bienes muebles e inmuebles, etc. etc. La aplicación además tendrá que tener una muy buena interfaz de usuario. La formación del personal que trabajara con la herramienta es baja, por tanto se hace necesario un entorno de fácil trabajo. Los recursos físicos que soportaran la carga del programa de gestión superaran con creces los mínimos requisitos indispensables para el programa. Con respecto a las restricciones legales, la única norma que restringirá el uso de los ficheros con datos sensibles será la LOPD1. No habrá intercambio de ficheros con ninguna otra entidad, ni será necesario un control de acceso a la aplicación. 1 LOPD: Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 4 1.2. Identificación del alcance del sistema Objetivo: “Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronización con otros proyectos, que puedan interferir en la planificación y futura puesta a punto del sistema objeto del estudio. Esta información se recoge en el catálogo de requisitos. Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, se debe tener en cuenta la arquitectura de información propuesta para analizar el alcance del sistema e identificar los sistemas de información que quedan fuera del ámbito del estudio. Además, se estudia el plan de proyectos, para determinar las posibles dependencias con otros proyectos. Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, así como su estructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a quiénes afecta directamente y quiénes pueden influir en el éxito o fracaso del mismo.” Estudio: Para que el sistema de gestión se desarrolle correctamente es necesario que el soporte físico este instalado y funcionando en producción. La extensión del proyecto se reduce al departamento de administración y su software de gestión, por tanto quedan excluidos del ámbito de estudio los sistemas de información de: -Comité de Apelación -Delegaciones -Presidencia -Tesorería -Dirección deportiva 1.3. Especificación del alcance del EVS Objetivo: “En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan las actividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situación actual y, en el caso de considerarlo necesario, con qué objetivo. Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, los criterios que pueden orientar sobre la necesidad de llevar a cabo el estudio de la situación actual dependen de la arquitectura de información propuesta, en cuanto a la identificación de los sistemas de información actuales, implicados en el ámbito de este estudio, que se haya decidido conservar. Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la realización del Estudio de Viabilidad del Sistema, determinando previamente sus perfiles y responsabilidades. Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el Estudio de Viabilidad, solicitando su aceptación y esperado su confirmación.” BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 5 Objetivos del estudio de la situación actual: En vista a que el proyecto se basa en una actualización de un software de gestión creado con anterioridad, se hace indispensable el estudio de las herramientas anteriores a la nueva implantación. Una vez estudiado el antiguo sistema, se decide, conjuntamente con el departamento afectado, que nuevas opciones contemplara el sistema a desarrollar, y cuáles deben ser modificadas. También se identifica si el nuevo sistema abarcará más usuarios de los actuales, si modifica la gestión de otros departamentos, si contempla la eliminación de herramientas con las que se complementaba el actual sistema, si hay duplicidad de la información, etc. etc. Los usuarios responsables de las unidades organizativas por tanto serán: ADMINISTRACION/ TESORERIA/CONTABILIDAD Dña. Cristina González Su principal responsabilidad es la de facilitar la captura de requisitos al equipo del proyecto, seguimiento del proyecto, introducción de los datos en el sistema y testing. JEFE DE PROYECTO D. Carlos Soriano Lorente Es el principal responsable del proyecto, la persona a la que deben remitirse todas las incidencias y comunicaciones. Tras el estudio se determina que no afectara a nuevas áreas, ni modificara el uso de herramienta alguna excepto del sistema de gestión principal. Una vez asignados los roles, se comunica al departamento de administración cuál es el plan de trabajo propuesto. 2. Estudio de la situación actual “La situación actual es el estado en el que se encuentran los sistemas de información existentes en el momento en el que se inicia su estudio. Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de la información existente acerca de los sistemas de información afectados. En función de dicha valoración, se especifica el nivel de detalle con que se debe llevar a cabo el estudio. Si es necesario, se constituye un equipo de trabajo específico para su realización y se identifican los usuarios participantes en el mismo. Si se decide documentar la situación actual, normalmente es conveniente dividir el sistema actual en subsistemas. Si es posible se describirá cada uno de los subsistemas, valorando qué información puede ser relevante para la descripción. Como resultado de esta actividad se genera un diagnóstico, estimando la eficiencia de los sistemas de información existentes e identificando los posibles problemas y las mejoras.” BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 12 4.2. Descripción de las alternativas de solución Objetivo: “Para cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos a los que se da respuesta. Se deben considerar también aspectos relativos a la cobertura geográfica (ámbito y limitaciones) de procesos y datos, teniendo en cuenta a su vez la gestión de comunicaciones y control de red. En la definición de cada alternativa, se propone una estrategia de implantación teniendo en cuenta tanto la cobertura global del sistema como la cobertura geográfica. Si la alternativa incluye desarrollo se describe el modelo abstracto de datos y el modelo de procesos, y en el caso de Orientación a Objetos, el modelo de negocio y, opcionalmente, el modelo de dominio. Se propone el entorno tecnológico que se considera más apropiado para la parte del sistema basada en desarrollo y se describen los procesos manuales. Si la alternativa incluye una solución basada en producto se analiza su evolución prevista, adaptabilidad y portabilidad, así como los costes ocasionados por licencias, y los estándares del producto. Igualmente se valora y determina su entorno tecnológico.” Alternativas de solución: 1. Aplicación comercial existente El principal problema con el que cuenta la FBCV a la hora de disponer de una alternativa comercial existente es que no existen en el mercado actualmente sistemas de gestión de ligas exclusivos para ligas de billar, lo que provoca que nunca se cumplan los requisitos al 100%. Incluso seleccionando varias herramientas tampoco se podría llegar a cubrir todos los requisitos. No obstante se estudia alguna alternativa que pudiera dar soporte a la mayor parte de las funcionalidades requeridas, incluso ampliar otras. 1) Competiciones deportivas V.10 (Sagois S.L.U.) CALENDARIO  Creación y gestión de campeonatos de liga (a 1 o 2 vueltas) y copa, así como fases previas y finales.  Realiza el sorteo del campeonato de manera automática a 1 o 2 vueltas con posibilidad de establecer la primera jornada de manera manual. Es posible establecer todas las jornadas de manera manual.  Genera los enfrentamientos de copa. Permite generar previas de liga y final de copa.  Creación de calendarios, pudiendo seleccionar entre calendarios completos, por jornadas, o de un rango de jornadas. Posibilidad de mostrar la clasificación actual en la parte inferior de la página.  Gestión profesional de horarios: Creación de calendarios con un número ilimitado de campos de juego. Además, ahora es posible reservar el campo de juego por parte de usuarios, y el programa tiene en cuenta estas reservas a la hora de generar el calendario BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 13 para evitar coincidencias horarias, ... (esta opción no está disponible en la licencia educativa) CLASIFICACIONES  Generación de clasificaciones de equipos y jugadores.  Equipos: clasificación general, deportividad, equipos menos goleados.  Jugadores: Goleadores, Deportividad y equipos menos goleados. SANCIONES  Imprime las actas de los partidos, informándonos de qué jugadores están sancionados.  Gestión profesional de árbitros y de sanciones.  Listas negras de DNI: permiten la detección automática, por medio del DNI, de un jugador al que no se le permita inscribirse en un campeonato. INTERNET  Exportación automática de equipos, calendarios y clasificaciones a HTML.  Posibilidad de subir las páginas a un servidor privado.  Creación de copias de seguridad, con posibilidad de subirlas a Internet. OTROS  Nueva base de datos de usuarios con la posibilidad de importarlos a los equipos a lo largo de los años.  Posibilidad de almacenar equipos y jugadores para poder utilizarlos en campeonatos posteriores.  Creación de hojas de inscripción.  Creación de carnets.  Gestión Económica (Sólo versión élite). REQUISITOS DEL SISTEMA Windows XP (con Service Pack 2) • Pentium III 700MHz o más • 256MB de RAM Windows Vista • 800 MHz o más • 512 MB de RAM Mac OS X 10.5 • PowerPC G4 (867MHz+), G5, o Mac con procesador Intel • 512 MB de RAM Mac OS X 10.4.11 • PowerPC G4, G5 o Mac con procesador Intel • 256 MB de RAM BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 14 2) PCLIGA 2000 (Manuel Dan Pozo, Freeware) El programa permite introducir los enfrentamientos de cada jornada. Para cada partido:  Jugadores: Titulares y suplentes.  Goleadores y amonestaciones.  Árbitro, táctica de cada equipo.  Fecha del encuentro, asistencia de público y un bloc de notas. Para cada equipo:  Todos los datos referentes al club (presidente, entrenador, estadio, nº socios, etc.).  La plantilla de jugadores (pueden incluirse las fotos).  Reflejar si el equipo está sancionado con puntos. Para cada jugador:  Nombre y apodo futbolístico.  Fecha de nacimiento, foto, nacionalidad y altura.  Demarcación, dorsal, ficha, cláusula de rescisión y año de fin de contrato. Realizar una clasificación de la Liga, manejando diferentes posibilidades:  Clasificación por puntos.  Clasificación por puntos conseguidos en casa o fuera.  Clasificación por goles a favor y en contra.  Selección de un intervalo de jornadas o de fechas.  Zonas en la clasificación: Liga de Campeones, ascenso, descenso, etc.  Flechas indicativas de cambio de puesto de un equipo.  Evolución de un equipo en la liga en varios parámetros.  Evolución general de la liga en varios parámetros. Estadísticas generales de la liga y de jugadores. Tabla con todos los resultados Pueden contrastarse los datos de los jugadores, es decir, todos los datos de un jugador relativos a la competición (goles, partidos jugados, etc.) se obtienen de los datos que se hayan introducido en los partidos, o bien, pueden introducirse los datos manualmente independientemente de que no se hayan introducido directamente en los enfrentamientos. Extracción de todos los datos (Clasificaciones, Jornadas, Estadísticas) a formato HTML. REQUISITOS DEL SISTEMA Windows XP (con Service Pack 2) • Pentium III 700MHz o más • 256MB de RAM BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 15 Windows Vista • 800 MHz o más • 512 MB de RAM 2. Aplicación hecha a medida La aplicación hecha a medida, al contrario que las aplicaciones comerciales, sería capaz de cubrir totalmente los requisitos exigidos por la Federación, esto es la gestión de ligas, clubes y socios con las características descritas anteriormente. Para el caso de la aplicación hecha a medida los requisitos mínimos de sistema serían, teniendo en cuenta su plataforma con el Framework 3.5 de Microsoft©: Windows XP SP2 / Vista / W7 • Pentium IV 2.4 GHz • 512MB de RAM Otro punto a destacar es la flexibilidad que proporciona este tipo de desarrollo, que además de cubrir necesidades actuales podría cubrir también necesidades futuras que todavía no se necesiten. 5. Valoración de las alternativas “Una vez descritas las alternativas se realiza una valoración de las mismas, considerando el impacto en la organización, tanto desde el punto de vista tecnológico y organizativo como de operación, y los posibles beneficios que se esperan contrastados con los costes asociados. Se realiza también un análisis de los riesgos, decidiendo cómo enfocar el plan de acción para minimizar los mismos y cuantificando los recursos y plazos precisos para planificar cada alternativa.” Tareas propuestas para esta actividad: 5.1. Estudio de la inversión 5.2. Estudio de los riesgos 5.1. Estudio de la inversión Objetivo: “Para cada alternativa de solución propuesta, se valora el impacto en la organización y se establece su viabilidad económica. Para ello, se realiza un análisis coste/beneficio que determina los costes del sistema y los pondera con los beneficios tangibles, cuantificables directamente, y con los beneficios intangibles, buscando el modo de cuantificarlos.” BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 16 Impacto y viabilidad económica: 1 Aplicación comercial existente. Existiría un gran impacto en la organización al usar una nueva aplicación comercial: - Necesidad de nueva formación a usuarios. - Imposibilidad de abarcar los requisitos, deberían usarse varias aplicaciones simultáneamente. - El uso de varias aplicaciones provoca el aumento de recursos de los sistemas. - Trato menos personalizado y mayor lentitud en la resolución de incidencias. No obstante, las ventajas que aportaría esta opción, son varias, entre ellas el tiempo de implantación de las aplicaciones en el sistema, la fiabilidad, robustez, e inclusión de opciones no especificadas en los requisitos que pudieran ser interesantes al departamento. El coste económico de la adopción de estas herramientas es variable, y depende mucho de las características finales que incluya la aplicación. Se asume que para que el sistema mejorara algunos aspectos del programa, el coste medio de los programas de gestión rondaría los quinientos euros (500€). 2 Aplicación hecha a medida. El impacto en la organización de una aplicación desarrollada a medida básicamente otorgaría ventajas al sistema de información, a cambio de un desembolso económico a priori mayor. En todo caso, este desembolso entra dentro de la capacidad adquisitiva para una temporada de la FBCV. Sus características principales serian: - La Interfaz de la nueva aplicación se adaptaría a la manera antigua de interactuar con el sistema por lo que la formación necesaria seria escasa. - Requisitos funcionales y no funcionales 100% cubiertos. - Rápida resolución de incidencias y peticiones. - Posibilidad de preparar el sistema para cambios futuros. - Tecnología actual. - Cumplimiento de normas especificas. - Informes personalizados 5.2. Estudio de los riesgos Objetivo: “Para cada alternativa se seleccionan los factores de situación que habrá que considerar, relativos tanto a la incertidumbre como a la complejidad del sistema. Se identifican y valoran los riesgos asociados y se determinan las medidas a tomar para minimizarlos.” BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 17 Riesgos: 1 Aplicación comercial existente. Al utilizar una aplicación comercial se debe tener en cuenta que el riesgo asociado principal radica en que la funcionalidad propuesta no cubra la funcionalidad requerida por la FBCV. Se estudia para el caso de la aplicación comercial Competiciones deportivas V.10 (Sagois S.L.U.). - Al usar varias aplicaciones, se puede incurrir en duplicidad de datos. - Difícil mantenimiento de datos. - Problemas de incompatibilidad con normas preestablecidas. - Difícil integración en el sistema. - Interfaz de usuario en primera instancia poco amigable. 2 Aplicación hecha a medida. -En caso de carga excesiva del proyecto de sistemas de información al personal de la Federación, pudieran darse retrasos en la implantación y puesta en marcha por los propios responsables del departamento. -Es posible que la antigua interfaz del programa de gestión que va a ser adaptada no sea la interfaz más idónea a largo plazo. -Incumplimiento de plazos de entrega por parte de los desarrolladores. -Incumplimiento de presupuestos. 6. Selección de la solución “Antes de finalizar el Estudio de Viabilidad del Sistema, se convoca al Comité de Dirección para la presentación de las distintas alternativas de solución, resultantes de la actividad anterior. En dicha presentación, se debaten las ventajas de cada una de ellas, incorporando las modificaciones que se consideren oportunas, con el fin de seleccionar la más adecuada. Finalmente, se aprueba la solución o se determina su inviabilidad.” Tareas propuestas para esta actividad: 6.1. Evaluación de las alternativas y selección BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-2 18 6.1. Evaluación de las alternativas y selección Objetivo: “Una vez recibida la confirmación de qué alternativas van a ser presentadas para su valoración, se efectúa su presentación al Comité de Dirección, debatiendo sobre las ventajas e inconvenientes de cada una de ellas y realizando las modificaciones que sugiera dicho Comité, hasta la selección de la solución final.” Selección: Tras el estudio de las ventajas e inconvenientes de las opciones para sustituir la actual aplicación de gestión, se llega a la conclusión que la mejor propuesta es la creación de una herramienta partiendo de cero. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 1 Anexo II-3. Índice: 1. Definición del sistema ........................................................................................................... 3 1.1. Determinación del alcance del sistema......................................................................... 4 1.2. Especificación de estándares y normas......................................................................... 4 2. Establecimiento de requisitos ............................................................................................... 5 2.1. Obtención de requisitos ................................................................................................ 5 2.2. Especificación de casos de uso ...................................................................................... 9 2.3. Validación de requisitos .............................................................................................. 16 3. Identificación de subsistemas ............................................................................................. 16 3.1. Identificación de subsistemas de análisis .................................................................... 17 3.2. Integración de subsistemas de análisis ....................................................................... 18 4. Análisis de los casos de uso ................................................................................................. 18 4.1. Identificación de clases asociadas a los casos de uso ................................................. 18 5. Análisis de clases ................................................................................................................. 19 6. Definición de interfaces de usuario .................................................................................... 20 6.1. Identificación de principios generales de la interfaz ................................................... 21 6.2. Especificación del comportamiento dinámico de la interfaz ...................................... 23 6.3. Especificación de formatos de impresión ................................................................... 25 7. Especificación del plan de pruebas ..................................................................................... 26 8. Aprobación del análisis de sistemas de información .......................................................... 27 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 2  Análisis del sistema de información (ASI) “El objetivo de este proceso es la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema. Al ser MÉTRICA Versión 3 una metodología que cubre tanto desarrollos estructurados como orientados a objetos, las actividades de ambas aproximaciones están integradas en una estructura común. En la primera actividad, Definición del Sistema (ASI 1), se lleva a cabo la descripción inicial del sistema de información, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se delimita el alcance del sistema, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. También se identifican los usuarios que participan en el proceso de análisis, determinando sus perfiles, responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de trabajo a seguir. La definición de requisitos del nuevo sistema se realiza principalmente en la actividad Establecimiento de Requisitos (ASI 2). El objetivo de esta actividad es elaborar un catálogo de requisitos detallado, que permita describir con precisión el sistema de información, y que además sirva de base para comprobar que es completa la especificación de los modelos obtenidos en las actividades Identificación de Subsistemas de Análisis (ASI 3), Análisis de Casos de Uso (ASI 4), Análisis de Clases (ASI 5), Elaboración del Modelo de Datos (ASI 6), Elaboración del Modelo de Procesos (ASI 7) y Definición de Interfaces de Usuario (ASI 8). Hay que hacer constar que estas actividades pueden provocar la actualización del catálogo, aunque no se refleja como producto de salida en las tareas de dichas actividades, ya que el objetivo de las mismas no es crear el catálogo sino definir modelos que soporten los requisitos. Para la obtención de requisitos en la actividad Establecimiento de Requisitos (ASI 2) se toman como punto de partida el catálogo de requisitos y los modelos elaborados en la actividad Definición del Sistema (ASI 1), completándolos mediante sesiones de trabajo con los usuarios. Estas sesiones de trabajo tienen como objetivo reunir la información necesaria para obtener la especificación detallada del nuevo sistema. Las técnicas que ayudan a la recopilación de esta información pueden variar en función de las características del proyecto y los tipos de usuario a entrevistar. Entre ellas podemos citar las reuniones, entrevistas, Joint Application Design (JAD), etc. Durante estas sesiones de trabajo se propone utilizar la especificación de los casos de uso como ayuda y guía en el establecimiento de requisitos. Esta técnica facilita la comunicación con los usuarios y en el análisis orientado a objetos constituye la base de la especificación. A continuación se identifican las facilidades que ha de proporcionar el sistema, y las restricciones a que está sometido en cuanto a rendimiento, frecuencia de tratamiento, seguridad y control de accesos, etc. Toda esta información se incorpora al catálogo de requisitos. En la actividad Identificación de Subsistemas de Análisis (ASI 3), se estructura el sistema de información en subsistemas de análisis, para facilitar la especificación de los distintos modelos y la traza de requisitos. En paralelo, se generan los distintos modelos que sirven de base para el diseño. En el caso de análisis estructurado, se procede a la elaboración y descripción detallada del modelo de datos y de procesos, y en el caso de un análisis orientado a objetos, se BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 3 elaboran el modelo de clases y el de interacción de objetos, mediante el análisis de los casos de uso. Se especifican, asimismo, todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, diálogos, formatos de informes y formularios de entrada. En la actividad Análisis de Consistencia y Especificación de Requisitos (ASI 9), se realiza la verificación y validación de los modelos, con el fin de asegurar que son: - Completos, puesto que cada modelo obtenido contiene toda la información necesaria recogida en el catálogo de requisitos. - Consistentes, ya que cada modelo es coherente con el resto de los modelos. - Correctos, dado que cada modelo sigue unos criterios de calidad predeterminados en relación a la técnica utilizada, calidad de diagramas, elección de nombres, normas de calidad, etc.). En la actividad Especificación del Plan de Pruebas (ASI 10), se establece el marco general del plan de pruebas, iniciándose su especificación, que se completará en el proceso Diseño del Sistema de Información (DSI). La participación activa de los usuarios es una condición imprescindible para el análisis del sistema de información, ya que dicha participación constituye una garantía de que los requisitos identificados son comprendidos e incorporados al sistema y, por tanto, de que éste será aceptado. Para facilitar la colaboración de los usuarios, se pueden utilizar técnicas interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo. 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”. 1. Definición del sistema “Esta actividad tiene como objetivo efectuar una descripción del sistema, delimitando su alcance, estableciendo las interfaces con otros sistemas e identificando a los usuarios representativos. Las tareas de esta actividad se pueden haber desarrollado ya en parte en el proceso de Estudio de Viabilidad del Sistema (EVS), de modo que se parte de los productos obtenidos en dicho proceso para proceder a su adecuación como punto de partida para definir el sistema de información”. Tareas propuestas para esta actividad: 1.1. Determinación del alcance del sistema 1.2. Especificación de estándares y normas BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 10 Especificación de casos de uso: 1 – Gestión de temporadas Caso de Uso Crear nueva temporada. Descripción Se crea una nueva temporada que englobará un periodo de competición de septiembre del año seleccionado a junio del año siguiente. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún club introducido en la BB.DD. Post condiciones Se crean los registros en la BB.DD. con los datos de una nueva temporada, los datos de clasificaciones vacios, y se almacena esa temporada como actual. Flujo de Eventos 1 - El actor principal selecciona la opción nueva temporada del menú. 2 - Se selecciona el periodo en el que se desarrollará la temporada. 3 - Se selecciona para cada club, las divisiones y grupos donde jugará. 4 - Se crean los registros en la BB.DD. Restricción síncrona En 4) Si no hay clubes seleccionados, se avisa al usuario pidiendo que los seleccione. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Abrir temporada. Descripción Se abre una temporada ya creada y se establece como temporada actual. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir alguna temporada introducida en la BB.DD. Post condiciones Se guarda en la BB.DD. la temporada seleccionada como actual. Flujo de Eventos 1 - El actor principal selecciona la opción abrir temporada del menú. 2 - Se hace doble clic en la temporada que se desea abrir. 3 - Se actualiza en la BB.DD. la temporada seleccionada como la actual. Restricción síncrona - Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Añadir acta. Descripción Una vez recibida el acta en formato impreso, comprobada la firma, se introduce en el sistema. Actor principal Personal administración. Actor secundario - Precondiciones Existe una temporada abierta como actual. Post condiciones Se introduce el acta en las tablas de la BB.DD. Flujo de Eventos 1 - El actor principal selecciona la opción nueva acta del menú 2 - El personal de administración introduce los datos del acta en el dialogo 3 - Se introducen los datos del acta en la tabla de actas, y se modifican los datos de clasificación en las tablas de clasificación por club y jugadores. Restricción síncrona En 2) Si no se ha seleccionado la división y el grupo antes de escribir los clubes, el programa avisa que no puede continuar. En 2) Si el club local es igual que el club visitante, el sistema avisa del error. En 2) Si el jugador local es igual que el jugador visitante, el sistema avisa del error. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 11 Caso de Uso Modificar acta Descripción Se abre un acta en modo edición para su modificación. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún acta en la BB.DD. Post condiciones El acta modificada queda guardada en la BB.DD, así como las tablas de clasificación de jugadores y clubes. Flujo de Eventos 1 - El actor principal selecciona la opción modificar acta del menú. 2 - Se debe seleccionar un acta del desplegable. 3 - El personal de administración modifica los datos del acta en el dialogo 4 - Se modifican los datos del acta en la tabla de actas, y se modifican los datos de clasificación en las tablas de clasificación por club y jugadores. Restricción síncrona En 3) Si no se ha seleccionado la división y el grupo antes de escribir los clubes, el programa avisa que no puede continuar. En 3) Si el club local es igual que el club visitante, el sistema avisa del error. En 3) Si el jugador local es igual que el jugador visitante, el sistema avisa del error. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Borrar acta Descripción Se selecciona un acta a eliminar. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún acta en la BB.DD. Post condiciones El acta seleccionada queda eliminada de la BB.DD. Flujo de Eventos 1 - El actor principal selecciona la opción borrar acta del menú. 2 - Se debe seleccionar un acta del desplegable. 3 - El personal de administración elimina el acta seleccionada 4 - Se eliminan los datos del acta en la tabla de actas, y se modifican los datos de clasificación en las tablas de clasificación por club y jugadores. Restricción síncrona - Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Sancionar Descripción Se sanciona a un club por algún motivo reflejado en un acta de sanción Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún club en la BB.DD. Post condiciones Flujo de Eventos 1 - El actor principal selecciona la opción sancionar del menú. 2 - Se debe seleccionar un club del desplegable. 3 - El personal de administración introduce el club a sancionar y los puntos 4 - Se restan los datos introducidos en las tablas de clasificación por club y jugadores. Restricción síncrona - Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 12 Caso de Uso Visualización de jornadas. Descripción Se muestra un Datagridview con las jornadas de la temporada. Actor principal Personal administración. Actor secundario - Precondiciones Hay una temporada abierta. Post condiciones Se representa el Datagridview en pantalla con las jornadas. Flujo de Eventos 1 - El personal de administración selecciona la opción de visualizar jornadas. 2 - Se muestran en pantalla los datos de todas las jornadas. Restricción síncrona En 2) El usuario puede modificar los criterios de orden de la jornada pulsando en la cabecera del Datagridview. En 3) El usuario puede mandar a imprimir los datos del Datagridview. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Consultar clasificación. Descripción Se consulta la clasificación por clubes o jugadores. Actor principal Personal administración. Actor secundario - Precondiciones Hay una temporada abierta. Post condiciones Se representa el Datagridview en pantalla con la clasificación seleccionada Flujo de Eventos 1 - El personal de administración selecciona la opción de consultar clasificación. 2 - Se selecciona el tipo de consulta 2 - Se muestran en pantalla los datos de la clasificación filtrados por la selección. Restricción síncrona En 2) El usuario puede modificar los criterios de orden de la jornada pulsando en la cabecera del Datagridview. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. 2Gestión de clubes Caso de Uso Añadir club. Descripción Se introduce un nuevo club en la BB.DD. Actor principal Personal administración. Actor secundario - Precondiciones - Post condiciones Se crean los registros en la BB.DD. con los datos del nuevo club. Flujo de Eventos 1 - El personal de administración selecciona la opción de introducir nuevo club. 2 - Se introducen los datos del nuevo club. 3 - Se crean los registros en la BB.DD. Restricción síncrona En 2) Si los datos introducidos tienen formato incorrecto se avisa al usuario y se marca el Textbox para que sea modificado. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 13 Caso de Uso Modificar club. Descripción Se abre un club en modo edición para su modificación. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún club en la BB.DD. Post condiciones El club modificado queda guardado en la BB.DD. Flujo de Eventos 1 - El actor principal selecciona la opción modificar club del menú. 2 - Se debe seleccionar un club del desplegable. 3 - El personal de administración modifica los datos del club en el dialogo. 4 - Se modifican los datos del club en la tabla de clubes y clasificación. Restricción síncrona En 3) Si los datos introducidos tienen formato incorrecto se avisa al usuario y se marca el Textbox para que sea modificado. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Borrar club. Descripción Se selecciona un club a eliminar. Actor principal Personal administración. Actor secundario - Precondiciones Se debe seleccionar un club del desplegable. Post condiciones El club seleccionado queda eliminado de la BB.DD. de clubes. Flujo de Eventos 1 - El actor principal selecciona la opción borrar club del menú. 2 - Se debe seleccionar un club del desplegable. 3 - El personal de administración elimina el club seleccionado. 4 - Se eliminan los datos del club en la tabla de clubes, pero no se modifican los datos de clasificación en las tablas de clasificación por club y jugadores. Restricción síncrona - Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Imprimir club. Descripción Se envía a imprimir el club o clubes seleccionados. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún club en la BB.DD. Post condiciones Los datos seleccionados son enviados a la Impresora correctamente. Flujo de Eventos 1 - El actor principal selecciona la opción imprimir club del menú. 2 - Se debe seleccionar algún club del desplegable. 3 - Se configuran las opciones de impresión. 4Se lanza la impresión. Restricción síncrona En 2) Si no se selecciona ningún club, no se permite continuar. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 14 Caso de Uso Exportar club Descripción Se envía a Excel el club o clubes seleccionados. Actor principal Personal administración. Actor secundario - Precondiciones - Post condiciones Debe existir algún club en la BB.DD. Flujo de Eventos 1 - El actor principal selecciona la opción exportar club del menú. 2 - Se debe seleccionar algún club del desplegable. 3 - Se lanza el proceso Excel junto con los datos de los clubes seleccionados. Restricción síncrona En 2) Si no se selecciona ningún club, no se permite continuar. En 3) Si no se encuentra el software Ms.© Excel instalado, se mostrará un mensaje de error. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Listar clubes Descripción Se consulta el listado de clubes Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún club en la BB.DD. Post condiciones Se representa el Datagridview en pantalla con los clubes seleccionados Flujo de Eventos 1 - El personal de administración selecciona la opción de listar clubes. 2 - Se selecciona el tipo de consulta 2 - Se muestran en pantalla los datos de los clubes filtrados por la selección. Restricción síncrona En 2) El usuario puede modificar los criterios de orden de los clubes pulsando en la cabecera del Datagridview. En 3) El usuario puede mandar a imprimir los datos del Datagridview. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. 3 – Gestión de socios Caso de Uso Añadir socio. Descripción Se introduce un nuevo socio en la BB.DD. Actor principal Personal administración. Actor secundario - Precondiciones Existe algún club previamente introducido en la BB.DD. Post condiciones Se crean los registros en la BBDD con los datos del nuevo socio. Flujo de Eventos 1 - El personal de administración selecciona la opción de introducir nuevo socio. 2 - Se introducen los datos del nuevo socio. 3 - Se crean los registros en la BB.DD. Restricción síncrona En 2) Si los datos introducidos tienen formato incorrecto se avisa al usuario y se marca el textbox para que sea modificado. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo - En cualquier momento el usuario puede cerrar el programa BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 15 Caso de Uso Modificar socio. Descripción Se abre un socio en modo edición para su modificación. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún socio en la BB.DD. Post condiciones El socio modificado queda guardado en la BB.DD. Flujo de Eventos 1 - El actor principal selecciona la opción modificar socio del menú. 2 - Se debe seleccionar un socio del desplegable. 3 - El personal de administración modifica los datos del socio en el dialogo. 4 - Se modifican los datos del socio en la tabla de socios y clasificación Restricción síncrona En 3) Si los datos introducidos tienen formato incorrecto se avisa al usuario y se marca el textbox para que sea modificado. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo - En cualquier momento el usuario puede cerrar el programa Caso de Uso Borrar socio. Descripción Se selecciona un socio a eliminar. Actor principal Personal administración. Actor secundario - Precondiciones Se debe seleccionar un socio del desplegable. Post condiciones El socio seleccionado queda eliminado de la BB.DD de socios. Flujo de Eventos 1 - El actor principal selecciona la opción borrar socio del menú. 2 - Se debe seleccionar un socio del desplegable. 3 - El personal de administración elimina el socio seleccionado. 4 - Se eliminan los datos del socio en la tabla de socios, pero no se modifican los datos de clasificación en las tablas de clasificación por club y jugadores. Restricción síncrona - Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo - En cualquier momento el usuario puede cerrar el programa Caso de Uso Imprimir socio. Descripción Se envía a imprimir los carnets del socio o socios seleccionados. Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún socio en la BB.DD. Post condiciones Los datos seleccionados son enviados a la Impresora correctamente. Flujo de Eventos 1 - El actor principal selecciona la opción imprimir carnets de socio del menú. 2 - Se debe seleccionar algún socio del desplegable. 3 - Se configuran las opciones de impresión. 4 - Se lanza la utilidad de reportes. 5Se mandan imprimir los reportes. Restricción síncrona En 2) Si no se selecciona ningún socio, no se permite continuar. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 16 Caso de Uso Exportar socio. Descripción Se envía a Excel el socio o socios seleccionados. Actor principal Personal administración. Actor secundario - Precondiciones - Post condiciones Debe existir algún socio en la BB.DD. Flujo de Eventos 1 - El actor principal selecciona la opción exportar socio del menú. 2 - Se debe seleccionar algún socio del desplegable. 3 - Se lanza el proceso Excel junto con los datos de los socios seleccionados. Restricción síncrona En 2) Si no se selecciona ningún socio, no se permite continuar. En 3) Si no se encuentra el software Ms.© Excel instalado, se mostrará un mensaje de error. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. Caso de Uso Listado socios. Descripción Se consulta el listado de socios Actor principal Personal administración. Actor secundario - Precondiciones Debe existir algún socio en la BB.DD. Post condiciones Se representa el Datagridview en pantalla con los socios seleccionados Flujo de Eventos 1 - El personal de administración selecciona la opción de listar socios. 2 - Se selecciona el tipo de consulta 2 - Se muestran en pantalla los datos de los socios filtrados por la selección. Restricción síncrona En 2) El usuario puede modificar los criterios de orden de los socios pulsando en la cabecera del Datagridview. En 3) El usuario puede mandar a imprimir los datos del Datagridview. Restricción asíncrona - En cualquier momento el usuario puede cerrar la ventana de dialogo. - En cualquier momento el usuario puede cerrar el programa. 2.3. Validación de requisitos Objetivo: “Mediante esta tarea, los usuarios confirman que los requisitos especificados en el catálogo de requisitos, así como los casos de uso, son válidos, consistentes y completos”. Validación: Una vez presentados los requisitos del catalogo al responsable del proyecto del cliente, se confirman que son correctos y se validan para posterior ejecución. 3. Identificación de subsistemas “El objetivo de esta actividad, común tanto para análisis estructurado como para análisis orientado a objetos, es facilitar el análisis del sistema de información llevando a cabo la descomposición del sistema en subsistemas. Se realiza en paralelo con el resto de las actividades de generación de modelos del análisis. Por tanto, se asume la necesidad de una BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 17 realimentación y ajuste continuo con respecto a la definición de los subsistemas, sus dependencias y sus interfaces”. Tareas propuestas para esta actividad: 3.1. Determinación de subsistemas de análisis 3.2. Integración de subsistemas de análisis 3.1. Identificación de subsistemas de análisis Objetivo: “La descomposición del sistema en subsistemas debe estar, principalmente, orientada a los procesos de negocio, aunque también es posible adoptar otros criterios lógicos. Entre los criterios que pueden ayudar a su identificación, se encuentran los siguientes: - Homogeneidad de procesos. - Servicios comunes. - Prioridad. - Afinidad de requisitos. - Localización geográfica. En análisis estructurado, los subsistemas coinciden habitualmente con el primer nivel de descomposición del Diagrama de Flujo de Datos (diagrama 0), de modo que llevan implícita la definición de dependencia y de interfaz. En análisis orientado a objetos, se identifican y definen las dependencias entre subsistemas analizando los elementos compartidos entre ellos o las interfaces entre subsistemas. En el caso de que se decida abstraer un subsistema para su análisis como una unidad con una funcionalidad concreta, se puede, opcionalmente, definir la interfaz de dicho subsistema para poder delimitar su comportamiento y utilización en el modelo general del sistema. Por tanto, se establece como obligatoria la asociación entre subsistemas indicando sólo la dependencia. Además, opcionalmente, se propone la especificación de la interfaz de subsistemas de análisis, y la definición del comportamiento del sistema. En ambos casos, se asignan los requisitos y casos de uso a cada uno de los subsistemas identificados, actualizando el catálogo de requisitos”. Descripción de subsistemas de análisis: Como se ha comentado el proyecto se centra en único sistema de gestión con tres subsistemas. La dependencia entre ellos se muestra a continuación: Figura 3.1. Diagrama de dependencias Gestión CLUBES Gestión SOCIOS Gestión TEMPORADAS BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 18 3.2. Integración de subsistemas de análisis Objetivo: “El objetivo de esta tarea es la coordinación en la elaboración de los distintos modelos de análisis de cada subsistema, asegurando la ausencia de duplicidad de elementos y la precisión en la utilización de los términos del glosario. Esta tarea se realiza en paralelo con el resto de las actividades de elaboración de modelos del análisis, y permite tener una visión global y unificada de los distintos modelos. Como consecuencia de la coordinación de modelos, se pueden identificar elementos comunes con posible implicación en la propia definición de subsistemas y en sus dependencias o interfaces”. Integración: Los subsistemas descritos anteriormente están totalmente integrados en un único sistema software por lo que no existirán duplicidades de ningún tipo. 4. Análisis de los casos de uso “El objetivo de esta actividad, que sólo se realiza en el caso de Análisis Orientado a Objetos, es identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la interacción dichos objetos. Esta actividad se lleva a cabo para cada uno de los casos de uso contenidos en un subsistema de los definidos en la actividad Identificación de Subsistemas de Análisis (ASI 3). Las tareas de esta actividad no se realizan de forma secuencial sino en paralelo, con continuas realimentaciones entre ellas y con las realizadas en las actividades Establecimiento de Requisitos (ASI 2), Identificación de Subsistemas de Análisis (ASI 3), Análisis de Clases (ASI 5) y Definición de Interfaces de Usuario (ASI 8)”. Tareas propuestas para esta actividad: 4.1. Identificación de clases asociadas a los casos de uso 4.1. Identificación de clases asociadas a los casos de uso Objetivo: “En esta tarea se comienzan a identificar los objetos necesarios para realizar el caso de uso, basándose en la especificación que tenemos del mismo. A partir del estudio del caso de uso, se extrae una lista de objetos candidatos a ser clases. Es posible que, inicialmente, no se disponga de la información necesaria para identificar todas, por lo que se hace una primera aproximación que se va refinando posteriormente, durante esta actividad y en el proceso de diseño. Además, algunos de los objetos representan mejor la información del sistema si se les identifica como atributos en vez de como clases. Para poder diferenciarlas, es necesario estudiar el comportamiento de esos objetos en el diagrama de interacción y además se debe tener en cuenta una serie de reglas, como puede ser el suprimir palabras no pertinentes, con significados vagos o sinónimos. Una vez definidas cada una de las clases, se incorporan al modelo de clases de la actividad Análisis de Clases (ASI 5), donde se identifican sus atributos, responsabilidades y relaciones”. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 19 Identificación de clases asociadas: Tras un primer análisis, las clases identificadas asociadas a los casos de uso son: - Socio - Club - Temporada - Acta 5. Análisis de clases “El objetivo de esta actividad que sólo se realiza en el caso de Análisis Orientado a Objetos es describir cada una de las clases que ha surgido, identificando las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas. Para esto, se debe tener en cuenta la normativa establecida en la tarea Especificación de Estándares y Normas (ASI 1.3), de forma que el modelo de clases cumpla estos criterios, con el fin de evitar posibles inconsistencias en el diseño. Teniendo en cuenta las clases identificadas en la actividad Análisis de los Casos de Uso (ASI 4), se elabora el modelo de clases para cada subsistema. A medida que avanza el análisis, dicho modelo se va completando con las clases que vayan apareciendo, tanto del estudio de los casos de uso, como de la interfaz de usuario necesaria para el sistema de información”. Análisis de clases: - Socio: Contiene los datos de los socios introducidos en el sistema. - Club: Contiene los datos de los clubes introducidos en el sistema. - Temporada: Contiene los datos de las temporadas introducidas en el sistema. - Acta: Contiene las actas de las temporadas introducidas en el sistema. - Clasificación Jugador: Contiene los datos de la competición del socio para cada temporada. - Clasificación Club: Contiene los datos de la competición del club para cada temporada. - Temporada Club: Contiene los datos de la relación entre temporada y club. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 26 Formatos de impresión: Se ha creado un dialogo para las opciones específicas de impresión de todos los listados: Figura 6.7. Ventana de detalles de impresión El encargado de gestionar los formatos de impresión una vez establecidas las opciones es el propio sistema operativo. Es necesario que para su correcto funcionamiento la impresora sea compatible con PostScript v6. 7. Especificación del plan de pruebas “En esta actividad se inicia la definición del plan de pruebas, el cual sirve como guía para la realización de las pruebas, y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. El plan de pruebas es un producto formal que define los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a paso de las actividades de prueba. El plan se inicia en el proceso Análisis del Sistema de Información (ASI), definiendo el marco general, y estableciendo los requisitos de prueba de aceptación, relacionados directamente con la especificación de requisitos. Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida del software, Diseño del Sistema de Información (DSI), Construcción del Sistema de Información (CSI) e Implantación y Aceptación del Sistema (IAS). Se plantean los siguientes niveles de prueba: - Pruebas unitarias. - Pruebas de integración. - Pruebas del sistema. - Pruebas de implantación. - Pruebas de aceptación. En esta actividad también se avanza en la definición de las pruebas de aceptación del sistema. Con la información disponible, es posible establecer los criterios de aceptación de las pruebas incluidas en dicho nivel, al poseer la información sobre los requisitos que debe cumplir el sistema, recogidos en el catálogo de requisitos”. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-3 27 Plan de pruebas: Se establece un modelo de pruebas general que se describe con el siguiente diagrama3: Figura 7.1. Diagrama de pruebas Asimismo la documentación de las pruebas contendrá: - Fecha de la prueba - Persona responsable de la prueba - Función o Interfaz a probar - Nivel de ejecución (desarrollo – integración – producción) - Si se requieren módulos externos de adicionales para el correcto funcionamiento de la prueba - Tabla de casos de prueba, con un resumen de su resultado. - Descripción de los casos de prueba resueltos. Se ampliará la descripción de las pruebas en anexos sucesivos. 8. Aprobación del análisis de sistemas de información “En esta tarea se realiza la presentación del análisis del sistema de información al Comité de Dirección, para la aprobación final del mismo.” Aprobación del análisis del sistema de información: Una vez presentado el análisis al presidente y vicepresidentes de la FBCV se establece que el sistema cumplirá los requisitos exigidos y se acepta la siguiente fase del proyecto. 3 Modelos de pruebas para el sistema (2006): http://www.lsi.us.es/~javierj/publications/MDA14.pdf BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 1 Anexo II-4. Índice: 1. Definición de la arquitectura del sistema ............................................................................. 3 1.1. Definición de niveles de arquitectura ........................................................................... 4 1.2. Identificación de requisitos de diseño y construcción .................................................. 6 1.3. Especificación de excepciones ...................................................................................... 7 1.4. Especificación de estándares y normas de diseño y construcción ................................ 9 1.5. Especificación del entorno tecnológico ...................................................................... 18 1.6. Especificación de requisitos de operación y seguridad ............................................... 19 2. Diseño de clases .................................................................................................................. 21 3. Diseño físico de datos ......................................................................................................... 38 4. Diseño de la migración y carga inicial de datos .................................................................. 39 5. Especificación técnica del plan de pruebas ......................................................................... 40 6. Especificación de requisitos de documentación de usuario ............................................... 41 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 2  Diseño del sistema de información (DSI) “El objetivo del proceso de Diseño del Sistema de Información (DSI) es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda. Las actividades de este proceso se agrupan en dos grandes bloques. - En un primer bloque de actividades, que se llevan a cabo en paralelo, se obtiene el diseño de detalle del sistema de información. La realización de estas actividades exige una continua realimentación. El sistema de información se estructura en subsistemas de diseño. Éstos a su vez se clasifican como de soporte o específicos, al responder a propósitos diferentes. - Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la instalación, y generalmente están originados por la interacción con la infraestructura técnica o la reutilización de otros sistemas, con un nivel de complejidad técnica mayor. - Los subsistemas específicos contienen los elementos propios del sistema de información, generalmente con una continuidad de los subsistemas definidos en el proceso de Análisis del Sistema de Información (ASI). También se especifica en detalle el entorno tecnológico del sistema de información, junto con su planificación de capacidades (capacity planning), y sus requisitos de operación, administración, seguridad y control de acceso. El diseño detallado del sistema de información, siguiendo un enfoque estructurado, comprende un conjunto de actividades que se llevan a cabo en paralelo a la Definición de la Arquitectura del Sistema (DSI 1). El alcance de cada una de estas actividades se resume a continuación: - Diseño de la Arquitectura de Soporte (DSI 2), que incluye el diseño detallado de los subsistemas de soporte, el establecimiento de las normas y requisitos propios del diseño y construcción, así como la identificación y definición de los mecanismos genéricos de diseño y construcción. - Diseño de la Arquitectura de Módulos del Sistema (DSI 5), dónde se realiza el diseño de detalle de los subsistemas específicos del sistema de información y la revisión de la interfaz de usuario. - Diseño Físico de Datos (DSI 6), que incluye el diseño y optimización de las estructuras de datos del sistema, así como su localización en los nodos de la arquitectura propuesta. En el caso de Diseño Orientado a Objetos, conviene señalar que el diseño de la persistencia de los objetos se lleva a cabo sobre bases de datos relacionales, y que el diseño detallado del sistema de información se realiza en paralelo con la actividad de Diseño de la Arquitectura de Soporte (DSI 2), y se corresponde con las siguientes actividades: - Diseño de Casos de Uso Reales (DSI 3), con el diseño detallado del comportamiento del sistema de información para los casos de uso, el diseño de la interfaz de usuario y la validación de la división en subsistemas. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 3 - Diseño de Clases (DSI 4), con el diseño detallado de cada una de las clases que forman parte del sistema, sus atributos, operaciones, relaciones y métodos, y la estructura jerárquica del mismo. En el caso de que sea necesario, se realiza la definición de un plan de migración y carga inicial de datos. Una vez que se tiene el modelo de clases, se comienza el diseño físico en la actividad Diseño Físico de Datos (DSI 6), común con el enfoque estructurado. Una vez finalizado el diseño de detalle, se realiza su revisión y validación en la actividad Verificación y Aceptación de la Arquitectura del Sistema (DSI 7), con el objeto de analizar la consistencia entre los distintos modelos y conseguir la aceptación del diseño por parte de los responsables de las áreas de Explotación y Sistemas. - El segundo bloque de actividades complementa el diseño del sistema de información. En él se generan todas las especificaciones necesarias para la construcción del sistema de información: - Generación de Especificaciones de Construcción (DSI 8), fijando las directrices para la construcción de los componentes del sistema, así como de las estructuras de datos. - Diseño de la Migración y Carga Inicial de Datos (DSI 9), en el que se definen los procedimientos de migración y sus componentes asociados, con las especificaciones de construcción oportunas. - Especificación Técnica del Plan de Pruebas (DSI 10), que incluye la definición y revisión del plan de pruebas, y el diseño de las verificaciones de los niveles de prueba establecidos. El catálogo de excepciones permite, de una forma muy ágil, establecer un conjunto de verificaciones relacionadas con el propio diseño o con la arquitectura del sistema. - Establecimiento de Requisitos de Implantación (DSI 11), que hace posible concretar las exigencias relacionados con la propia implantación del sistema, tales como formación de usuarios finales, infraestructura, etc. Finalmente, en la actividad de Presentación y Aprobación del Diseño del Sistema de Información (DSI 12), se realiza una presentación formal y aprobación de los distintos productos del diseño”. 1. Definición de la arquitectura del sistema “En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la especificación detallada de la infraestructura tecnológica necesaria para dar soporte al sistema de información. El particionamiento físico del sistema de información se especifica identificando los nodos y las comunicaciones entre los mismos, con cierta independencia de la infraestructura tecnológica que da soporte a cada nodo. Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en subsistemas de diseño, como partes lógicas coherentes y con interfaces claramente definidas. Se establece una distinción entre subsistemas específicos del sistema de información (en adelante, subsistemas específicos) y subsistemas de soporte, con la finalidad de independizar, en la medida de lo posible, las funcionalidades a cubrir por el sistema de información de la BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 4 infraestructura que le da soporte. En la mayoría de los casos, los subsistemas específicos provienen directamente de las especificaciones de análisis y de los subsistemas de análisis, mientras que los subsistemas de soporte provienen de la necesidad de interacción del sistema de información con la infraestructura y con el resto de los sistemas, así como de la reutilización de módulos o subsistemas ya existentes en la instalación. Una vez identificados y definidos los distintos subsistemas de diseño, se determina su ubicación óptima de acuerdo a la arquitectura propuesta. La asignación de dichos subsistemas a cada nodo permite disponer, en función de la carga de proceso y comunicación existente entre los nodos, de la información necesaria para realizar una estimación de las necesidades de infraestructura tecnológica que da soporte al sistema de información. Este factor es especialmente crítico en arquitecturas multinivel o cliente/servidor, donde las comunicaciones son determinantes en el rendimiento final del sistema. Se propone crear un catálogo de excepciones en el que se especifiquen las situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información, y que se irá completando a medida que se avance en el diseño detallado de los subsistemas. En esta actividad también se establecen los requisitos, normas y estándares originados como consecuencia de la adopción de una determinada solución de arquitectura o infraestructura, que serán aplicables tanto en este proceso como en la Construcción del Sistema de Información (CSI)”. Tareas propuestas para esta actividad: 1.1. Definición de niveles de arquitectura 1.2. Identificación de requisitos de diseño y construcción 1.3. Especificación de excepciones 1.4. Especificación de estándares y normas de construcción 1.5. Especificación del entorno tecnológico 1.6. Especificación de requisitos de operación y seguridad 1.1. Definición de niveles de arquitectura Objetivo: “En esta tarea se describen los niveles de la arquitectura software, mediante la definición de las principales particiones físicas del sistema de información, representadas como nodos y comunicaciones entre nodos. Se entiende por nodo cada partición física o parte significativa del sistema de información, con características propias de ejecución o función, e incluso de diseño y construcción. Para facilitar la comprensión del sistema, se recomienda identificar como nodos los elementos de infraestructura más significativos de la arquitectura en la que se va a implementar el sistema de información. Los elementos que se aconseja especificar son los siguientes: - Gestores de datos. - Tipos de puesto cliente. - Tipos de dispositivos de impresión. - Monitores de teleproceso. - Servidores. - Comunicaciones. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 5 La comunicación se expresa por una conexión entre nodos, indicando su carácter bidireccional o unidireccional, con las principales características de los protocolos o tipo de mensajes utilizados. La especificación de los niveles de la arquitectura se realiza con el detalle suficiente como para permitir un diseño dirigido hacia una solución concreta. En general, no es preciso indicar en cada nodo detalles relativos al hardware, capacidad, rendimiento o configuraciones de tolerancia a fallos, entre otros. Esta información se concreta en la tarea Especificación del Entorno Tecnológico (DSI 1.6). Los criterios para diseñar la arquitectura se obtienen a partir de directrices tecnológicas o de integración, propias de la instalación, y del catálogo de requisitos del sistema de información. Es necesario tener en cuenta, especialmente, aspectos relacionados con: - Usuarios: ubicación, movilidad, concurrencia, número, etc. - Datos: variabilidad, volúmenes, necesidades de consolidación, seguridad, etc. - Procesos: distribución, reutilización, concurrencia, carácter crítico, etc.”. Niveles de arquitectura: Se analizan en un primer lugar las ventajas de una arquitectura multinivel y se observa cuales de ellas influirían en la solución actual. Recursos centralizados: debido a que el servidor es el centro de la red, puede administrar los recursos que son comunes a todos los usuarios, por ejemplo: una base de datos centralizada se utilizaría para evitar problemas provocados por datos contradictorios y redundantes. En el sistema actual solo habrá un usuario accediendo al sistema simultáneamente por lo que no es aplicable. Seguridad mejorada: no importa la cantidad de puntos de entrada que permiten el acceso a los datos, ya que la seguridad principal esta centralizada. Actualmente el trabajo se desarrolla en un solo lugar físico, por lo que esta mejora tampoco es aplicable. Administración al nivel del servidor: ya que los clientes no juegan un papel importante en este modelo, requieren por tanto menos administración. Siendo el administrador el mismo responsable que el usuario del software, no beneficiaría en la práctica. Red escalable: gracias a esta arquitectura, es posible quitar o agregar clientes sin afectar el funcionamiento de la red y sin la necesidad de realizar mayores modificaciones. Sería un punto importante en futuras ampliaciones, pero por el coste se deja el desarrollo para más adelante. Por tanto el sistema se basará en una arquitectura de un solo nivel, ya que se considera suficiente para el tipo de trabajo y la cantidad de transacciones diarias. Se analizan las ventajas de una arquitectura de un solo nivel: Menor coste: debido a la complejidad técnica del servidor, la solución de un nivel requiere menos tiempo de desarrollo y por tanto menor coste. Este punto es determinante en la configuración que se establecerá. Comunicaciones: Al no existir comunicaciones entre diferentes maquinas se evita cualquier fallo que pueda provocar la paralización del sistema. De esta manera, será una solución de tres capas (presentación, lógica del negocio, datos) que residirán en un solo ordenador (presentación + lógica + datos). BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 6 1.2. Identificación de requisitos de diseño y construcción Objetivo: “En esta tarea se realiza la especificación de los requisitos que están directamente relacionados con la adopción o diseño de una arquitectura o infraestructura concreta, y que pueden condicionar el diseño o la construcción del sistema de información. Entre estos requisitos pueden estar los relacionados con lenguajes, rendimiento de los distintos elementos de la arquitectura, así como criterios de ubicación de módulos y datos en los distintos nodos. Por tanto, como resultado de esta tarea se actualiza el catálogo de requisitos elaborado en el proceso Análisis de Sistemas de Información.” Requisitos de diseño y construcción: Como se ha especificado en el PSI, la arquitectura para el diseño y la construcción del sistema se basará en la plataforma .NET de Microsoft©. Sus ventajas a la hora de construir el sistema y diseñar prototipos son1: Código administrado: El motor en tiempo de ejecución de .NET realiza un control automático del código para que este sea seguro, es decir, controla los recursos del sistema para que la aplicación se ejecute correctamente. Interoperabilidad multilenguaje: El código puede ser escrito en cualquier lenguaje compatible con .Net ya que siempre se compila en código intermedio. Compilación just-in-time: El compilador JIT incluido en el Framework compila el código intermedio generando el código máquina propio de la plataforma. Se aumenta así el rendimiento de la aplicación al ser específico para cada plataforma. Garbage collector: El motor en tiempo de ejecución proporciona un sistema automático de administración de memoria denominado recolector de basura (garbage collector). El MTE detecta cuándo el programa deja de utilizar la memoria y la libera automáticamente. De esta forma el programador no tiene por que liberar la memoria de forma explícita aunque también sea posible hacerlo manualmente (mediante el método disponse() liberamos el objeto para que el recolector de basura lo elimine de memoria). Seguridad de acceso al código: Se puede especificar que una pieza de código tenga permisos de lectura de archivos pero no de escritura. Es posible aplicar distintos niveles de seguridad al código, de forma que se puede ejecutar código procedente del Web sin tener que preocuparse si esto va a estropear el sistema. Despliegue: Por medio de los ensamblados resulta mucho más fácil el desarrollo de aplicaciones distribuidas y el mantenimiento de las mismas. El Framework realiza esta tarea de forma automática mejorando el rendimiento y asegurando el funcionamiento correcto de todas las aplicaciones. Además, se decide la utilización de una BB.DD. Ms. © Access 2007. Esta decisión viene condicionada por el hecho que la arquitectura será de un solo nivel. En otro caso, hubiera sido indispensable el uso de otro SGBD. 1 Contadores de rendimiento .NET (2009): http://msdn.microsoft.com/es-es/library/ms172525(VS.90).aspx BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 7 1.3. Especificación de excepciones Objetivo: “El objetivo de esta tarea es la definición de los comportamientos no habituales en el sistema, que reflejan situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información. Para ello, se establece previamente el nivel de especificación de las mismas, así como los criterios de catalogación y clasificación. Se propone su catalogación como ayuda para el diseño del sistema de información y como guía en la especificación técnica de las pruebas, al permitir la generación de algunos casos de prueba de forma inmediata. Dicho catálogo se va completando a partir de las actividades correspondientes al diseño detallado de los subsistemas. Las excepciones se describen incluyendo, al menos, los siguientes conceptos: - Tipo y descripción de la excepción. - Condiciones previas del sistema de información. - Elemento afectado (nodo, módulo, caso de uso). - Respuesta del sistema de información. - Elemento asociado a la respuesta esperada del sistema (módulo, clase, procedimiento, etc.). Las excepciones que se proponen como obligatorias son las relacionadas con el funcionamiento general del sistema de información, habitualmente asociadas a: - Nodos y comunicaciones del particionamiento físico del sistema de información. Este tipo de excepciones tiene lugar cuando no están disponibles los gestores de bases de datos o los recursos compartidos del sistema (representados como nodos), cuando se producen fallos en las comunicaciones entre nodos, etc. - Rangos o valores no válidos en la entrada de datos, como pueden ser atributos obligatorios, con formatos específicos, etc. Se recomienda, según el nivel de especificación que se establezca en cada caso, catalogar también las excepciones particulares que se identifiquen en las actividades del diseño de detalle”. Catálogo de excepciones y errores: En el sistema que se está desarrollando se distinguen diferentes tipos de excepciones según su nivel de procedencia. Todas las excepciones se irán incorporando a un catálogo conforme la construcción de la aplicación avance. En caso de ya existir esa excepción, se asigna un nuevo código y se añade al catálogo. Excepciones de error: - Excepciones por datos de entrada incorrectos sin acceso a BB.DD. En este primer caso, para evitar este tipo de excepciones, al introducir un dato de entrada con un formato o valor incorrecto, el sistema localiza el cuadro de entrada y espera a que el usuario rectifique el texto. En caso de no hacerlo, el sistema no permite continuar (solo cancelar el diálogo). BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 8 Figura 1.1. Validación de datos de entrada - Excepciones por datos de entrada incorrectos con acceso a BB.DD. En este caso, al introducir un valor que requiere tener un campo dado previamente de alta en la BB.DD. el sistema responde con una ventana de mensaje advirtiendo de la necesidad de realizar una acción previa. Figura 1.2. Ventana de error por datos incorrectos - Excepciones por accesos incorrectos a BB.DD. En caso que la excepción no permita vuelta atrás, toda excepción irá asociada a un código, y estos códigos recogidos en una tabla Excel de códigos de excepción. El código contendrá un primer digito indicando el tipo de excepción, otro con la función de negocio del fallo, y otro conjunto de dígitos en numeración secuencial según la excepción. Figura 1.3. Ventana con código de error BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 15 - Incluir llaves en los bloques condicionales así sea de una sola sentencia. - Agregar los namespaces en orden descendente empezando por los del sistema y terminado por los personalizados o de usuario. - Una clase debe estar definida en orden descendente de la siguiente manera: Variables Miembro, Constructores, Enumeraciones, Estructuras o Clases anidadas, Propiedades y por último los Métodos. - La secuencia de declaración de acuerdo a los modificadores de acceso debe ser la siguiente: public > protected > internal > private - Aislar la interfaz de implementación utilizando bloques Region. - Alinear verticalmente las llaves de apertura y cierre de cualquier bloque: Public void Main() { ... } - Establecer una longitud de línea máxima para el código. - Utilizar espacios antes y después de los operadores siempre que eso no altere la sangría aplicada al código - Usar espacios en blanco para organizar a su antojo secciones de código. De tal manera que se comprenda la segmentación del código. - Cuando se tenga que dividir una línea en varias, aclarar que el código sigue en la línea de más abajo mediante un operador de concatenación colocado al final de cada línea, y no al principio. - Siempre que sea posible, no colocar más de una instrucción por línea, a excepción de los bucles. - Al escribir en HTML, establecer un formato estándar para las etiquetas y los atributos; como por ejemplo, las etiquetas siempre en mayúscula y los atributos en minúscula - Cuando se escriba instrucciones SQL utilizar mayúsculas para las palabras clave: SELECT, UPDATE, WHERE, FROM, etc. - Colocar las cláusulas SQL principales en líneas separadas, de modo que las instrucciones sean más fáciles de leer y editar: SELECT Nombre, Apellido FROM Clientes WHERE Fecha= ‘Now.Today’; - Cuando se aplique más de un atributo a una estructura colocarlos individualmente en una línea y no todos juntos y separados por comas. - Siempre que sea posible inicializar las variables en el momento de la declaración (no es necesario en VisualBasic). - Siempre utilizar los tipos nativos de cada lenguaje y no los del CTS. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 16 - Evitar hacer unboxing y boxing secuencialmente, es decir, en la misma rutina. - No comparar strings con “” o con string.empty, usar la propiedad length del string: If(String.length == 0) - Evitar las llamadas a métodos dentro de sentencias condicionales. - Evitar utilizar recursividad, usar mejor ciclos for anidados. - Usar el operador condicional ternario solo en casos triviales, cuando sean casos complejos evitarlo. - Evitar comparar variables booleanas contra false o true, en vez de eso utilizar el operador de negación: If(puedeEliminarse == true)if(puedeEliminarse=false) Mejor usar: If(puedeEliminarse)f(!puedeEliminarse) 2. Estándares de interfaz: 1. Consideraciones respecto al ratón: La funcionalidad del mouse se utilizará para seleccionar componentes en pantalla y comandos del menú por parte del usuario. El botón izquierdo del mouse será utilizado para seleccionar los componentes y los comandos del menú, siendo el único botón activado de este dispositivo. 2. Consideraciones respecto al teclado: El teclado tendrá la funcionalidad del ingreso de datos. Asimismo, mediante la tecla TAB o la tecla ENTER el usuario podrá desplazar el foco de selección del teclado de componente en componente de forma ordenada. 3. Con lo referente a la ventana principal: - Contendrá el menú principal. - Permitirá enlaces con otras ventanas, para realizar actividades específicas. - Contendrá un fondo de pantalla distintivo de las otras. - El tamaño será de 1024x768 píxeles. - La ventana iniciará maximizada por defecto y podrá ser minimizada. 4. Con referente a las ventanas se deben tener en cuenta las siguientes consideraciones acerca de sus propiedades: - Start Position: Center Screen - Form Border Style: Fixed Single - Maximize Box: False - Minimize Box: False BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 17 Todos los componentes serán tabulados a una misma distancia, a partir de margen izquierdo. Para el cálculo de la separación entre los diferentes elementos de la ventana, se configurarán las opciones del menú Herramientas con los valores que se detallan a continuación en el campo Diseñador de Windows Forms – General: - Layout Mod: Snap To Grid - Show Grid: True - Snap-To-Grid: False A continuación, en las propiedades de la ventana se colocan los siguientes valores: - Draw Grid: True - Grid Size: 15 píxeles. 5. Con referente a la separación entre las etiquetas, las cajas de texto, las listas de selección simple y múltiple, se deberá considerar: - La separación vertical entre cajas de texto, listas de selección simple y múltiple será de 12 píxeles. - La separación vertical entre etiquetas será de 20 píxeles. - La separación será horizontal entre etiquetas y demás controles (excepto control de marco): Se debe tomar en cuenta la alineación con las demás etiquetas del mismo grupo (alineación hacia la izquierda). Es decir, el espacio de separación será la mayor longitud de alguna de dichas etiquetas más 20 píxeles. 6. Con referente a la separación y alineación de un control de marco: - La separación horizontal entre control de marco y límite izquierdo de la ventana: 10 píxeles. - La separación horizontal entre etiquetas y control de marco: 20 píxeles. - Para la alineación de los elementos contenidos por un control de marco, se deberá seleccionar todos los elementos mencionados y dar clic en la opción Centrar Horizontalmente que aparece en la barra de herramientas. 7. Con referente a los botones de pulsación se deben tener en cuenta las siguientes consideraciones: - La separación horizontal entre botones será de 35 píxeles. - La separación vertical entre botón y límite inferior de la ventana o marco que lo contiene será de 20 píxeles. - El tamaño de los botones serán de 45x35 píxeles - Las imágenes que tendrán los botones estarán centradas. 8. Con referente al elemento grilla (DataGridView) se deben tener en cuenta las siguientes consideraciones: - Auto Size Columns Mode: All Cells - Auto Size Rows Mode: All Cells - Read Only: True (Todas las columnas) BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 18 1.5. Especificación del entorno tecnológico Objetivo: “En esta tarea se definen en detalle los distintos elementos de la infraestructura técnica que dan soporte al sistema de información, determinando la implementación concreta de los nodos y comunicaciones especificados en la tarea Definición de Niveles de Arquitectura (DSI 1.1). Se propone agrupar los elementos de la infraestructura en los siguientes conceptos: - Hardware: procesadores, unidades de almacenamiento, estaciones de trabajo, etc. - Software: sistemas operativos, subsistemas, middleware, gestores de bases de datos, sistemas de ficheros, software de base, herramientas y utilidades de gestión propias del sistema, etc. - Comunicaciones: diseño de la topología de la red, protocolos, nodos de red, etc. La definición de los distintos elementos puede generar restricciones técnicas que afecten al diseño o construcción del sistema de información. Asimismo, se realiza una estimación de la planificación de capacidades (capacity planning) o se especifican los parámetros que Explotación y Sistemas precisen para realizar dicha planificación. Se indican, al menos, las necesidades previstas de: - Almacenamiento: espacio en disco, espacio en memoria, pautas de crecimiento y evolución estimada del sistema de información, etc. - Procesamiento: número y tipo de procesadores, memoria, etc. - Comunicaciones: líneas, caudal, capacidades de elementos de red, etc. Para poder determinar la planificación de capacidades, es necesario conocer los diseños detallados de los módulos / clases y escenarios, incluida la información de control en las comunicaciones, así como el diseño físico de datos optimizado, productos que se están generando en paralelo a esta actividad. También se tienen en cuenta, cuando proceda, las estimaciones de volúmenes de datos propios de la migración y carga inicial de datos”. Entorno tecnológico: Como se ha comentado anteriormente, la plataforma se creará siguiendo un modelo de tres capas pero con un nivel de arquitectura. Por tanto, no se requieren diferentes maquinas según el modelo de capa, todas harán las funciones de estación de trabajo. Infraestructura entorno a: - Hardware: (2) Workstation hechas a medida, compuestas por: - Caja MicroATX - Microprocesador Intel Dual Core E5200 - Placa base Asus mod. P S775 - Disco duro 1TB - Memoria RAM 4 GB 677 MHz - Red Ethernet 10/100/1000 - Impresora HP 1022 - Monitor TFT HP 22” Mod. W2216v BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 19 - Software: - S.O. Windows 7 Home - Comunicaciones: - Switch 4 puertos 10/100/1000 SMC Mod. 24C. - Conexión ADSL. Con respecto a la plataforma se especifican a continuación los requisitos mínimos: - Requisitos de software: -Microsoft Windows XP Home o Microsoft Windows XP Professional, ambos con Service Pack 2 o posterior -Microsoft Windows Server 2003 con Service Pack 1 o posterior -Microsoft Vista -Microsoft Windows Server 2008 Nota: .NET Framework 3.5 solo admite IA64 en Microsoft Windows Server 2008. - Requisitos de hardware: -Mínimo: Pentium a 400 MHz, 96 MB -Se recomienda: Pentium a 1 GHz o más rápido, 256 MB o más 1.6. Especificación de requisitos de operación y seguridad Objetivo: “El objetivo de esta tarea es definir los procedimientos de seguridad y operación necesarios para no comprometer el correcto funcionamiento del sistema y garantizar el cumplimiento de los niveles de servicios que exigirá el sistema en cuanto a la gestión de operaciones (procesos por lotes, seguridad, comunicaciones, etc.). Los niveles de servicio se especifican formalmente en el proceso Implantación y Aceptación del Sistema (IAS). Tomando como referencia los requisitos establecidos para el sistema, y teniendo en cuenta la arquitectura propuesta y las características del entorno tecnológico definido en esta actividad, se lleva a cabo la definición de los requisitos de seguridad y control de acceso necesarios para garantizar la protección del sistema y minimizar el riesgo de pérdida, alteración o consulta indebida de la información. Para ello, se diseñan los procedimientos relacionados con: - Acceso al sistema y a sus recursos (datos, transacciones, librerías, etc.). - Mantenimiento de la integridad y confidencialidad de los datos. - Control y registro de accesos al sistema (logs, certificación, etc.). - Copias de seguridad y recuperación de datos y su periodicidad. - Recuperación ante catástrofes. Asimismo, se definen los requisitos de operación para los distintos elementos del sistema (módulos, clases, estructuras físicas de datos, sistemas de ficheros), que se están elaborando en paralelo a esta actividad, y se diseñan los procedimientos asociados relacionados con: BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 20 - Tratamiento en línea (franja horaria/periodos críticos, número máximo de usuarios, etc.). - Tratamiento por lotes (periodicidad y secuencia de ejecución, interdependencias, petición de ejecución, etc.). - Control y planificación de trabajos. - Recuperación y reanudación de trabajos. - Distribución de información generada por el sistema, tanto trabajos planificados o bajo petición. - Control y seguimiento del correcto funcionamiento de los procedimientos de backup y recuperación utilizados habitualmente. Requisitos de operación y seguridad: El control de acceso al programa vendrá establecido por el propio control de acceso que proporciona el sistema operativo instalado, en este caso Windows 7. Se crearán credenciales para los usuarios que trabajen con el software de la aplicación. Los logs de acceso al sistema serán habilitados y se mantendrá el registro de errores activo. Los usuarios, si bien podrán acceder con todos los derechos de administrador, tendrán instalado software de tipo antispyware y antivirus para evitar cualquier intrusión en el sistema, así como el control de aplicaciones proporcionado por defecto en Windows 7. Las actualizaciones del sistema operativo serán también automáticas por defecto. Para el mantenimiento y copia de los datos de la aplicación, se integra una opción que permite el guardado de todas las tablas que maneja el sistema en cualquier ubicación. Este fichero tendrá una extensión *.billar. La apertura y el salvado se realizarán con el habitual diálogo de Windows de la forma: Figura1.5. Diálogo de apertura de fichero No se establece por defecto el salvado de la BB.DD. cada periodo de tiempo, pero será posible habilitarlo si las exigencias del personal de administración lo requiere. Se establece como política interna del departamento el guardar un fichero de copia al finalizar cada día si se han introducido cambios en el sistema, este fichero será guardado en una unidad externa compatible. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 21 2. Diseño de clases “El propósito de esta actividad, que se realiza sólo en el caso de Diseño Orientado a Objetos, es transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de cada una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la implementación. Se identifican las clases de diseño, que denominamos clases adicionales, en función del estudio de los escenarios de los casos de uso, que se está realizando en paralelo en la actividad Diseño de Casos de Uso Reales (DSI 3), y aplicando los mecanismos genéricos de diseño que se consideren convenientes por el tipo de especificaciones tecnológicas y de desarrollo. Entre ellas se encuentran clases abstractas, que integran características comunes con el objetivo de especializarlas en clases derivadas. Se diseñan las clases de interfaz de usuario, que provienen del análisis. Como consecuencia del estudio de los escenarios secundarios que se está realizando, pueden aparecer nuevas clases de interfaz. También hay que considerar que, por el diseño de las asociaciones y agregaciones, pueden aparecer nuevas clases, o desaparecer incluyendo sus atributos y métodos en otras, si se considera conveniente por temas de optimización. La jerarquía entre las clases se va estableciendo a lo largo de esta actividad, a medida que se van identificando comportamientos comunes en las clases, aunque haya una tarea propia de diseño de la jerarquía. Otro de los objetivos del diseño de las clases es identificar para cada clase, los atributos, las operaciones que cubren las responsabilidades que se identificaron en el análisis, y la especificación de los métodos que implementan esas operaciones, analizando los escenarios del Diseño de Casos de Uso Reales (DSI 3). Se determina la visibilidad de los atributos y operaciones de cada clase, con respecto a las otras clases del modelo. Una vez que se ha elaborado el modelo de clases, se define la estructura física de los datos correspondiente a ese modelo, en la actividad Diseño Físico de Datos (DSI 6). Además, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial de información, se realizará su especificación a partir del modelo de clases y las estructuras de datos de los sistemas origen. Como resultado de todo lo anterior se actualiza el modelo de clases del análisis, una vez recogidas las decisiones de diseño.” BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 22 1) Gestión temporada: Se realiza la creación de una temporada y se pueden abrir temporadas existentes en la aplicación Secretaría Abrir temporada Nueva temporada Figura 2.1. Gestión de temporada 1.1 Crear nueva temporada El usuario puede crear una nueva temporada introduciendo cada uno de los clubes que participaran y en qué división van a competir. Figura 2.2. Crear nueva temporada Tipos elementales de datos: Fecha comienzo temporada: date Fecha fin temporada: date Nombre del club: varchar[50] Cod_club: integer[3] Disponible bit Tipos derivados de datos: Cod_temporada: integer[8] Formado por los 8 dígitos que corresponden a los dos años de las fechas introducidas: Vector de participación de temporadas: integer [6][4] BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 23 Ficheros accedidos: Temporada[lectura/escritura] Temporada_Club[lectura/escrituta] Clasificación club[lectura/escritura] Clasificación jugador[lectura/escritura] 1.2 Abrir temporada Se abre una temporada existente en el sistema. Se selecciona la temporada y se abre. Figura 2.3. Abrir temporada existente Ficheros accedidos: Temporada[lectura/escritura] Temporada_Club[lectura/escrituta] Clasificación club[lectura/escritura] Clasificación jugador[lectura/escritura] 2) Gestión socios: Se da de alta un nuevo socio, se pueden editar los valores de cada socio, se puede borrar un socio en caso de que este se dé de baja del club correspondiente y se imprimen las etiquetas a partir de las cuales se crean los carnets. Secretaría Nuevo socio Editar socio Borrar socio Imprimir etiqueta socio Figura 2.4. Gestión de socios BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo II-4 24 2.2 Nuevo socio El usuario introduce los datos de cada socio. Previamente, es necesaria la introducción del club al que va a pertenecer el socio. El número de licencia debe ser el código de un club existente (3 cifras) concatenado con su número de jugador. Figura 2.5. Nuevo socio Tipos elementales de datos: Nombre: varchar[50] Apellidos: varchar[100] Fecha nacimiento: date DNI: varchar[9] Dirección: varchar[100] Provincia: varchar[50] Población: varchar[50] CP: varchar[5] Teléfono: integer[10] Email: varchar[30] Código del Club: integer[3] Código clasificación: integer[10] Tipo derivado de datos: Numero Licencia: ‘cod_club’+’integer*3+’ Ficheros accedidos: Socio [lectura/escritura] Club[lectura] BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 32 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Clasificacion_jugador Página: 32 Propiedades DateCreated: 23/11/2008 2:55:44 DefaultView: 2 DisplayViewsOnSharePointSite 1 FilterOnLoad: Falso GUID: {guid {DBC3A27F-C192-4A27HideNewField: Falso 9551-BB8BCB3B2A34}} LastUpdated: 27/12/2008 2:57:00 NameMap: Datos binarios largos OrderBy: [Clasificacion_jugador].[CODLI OrderByOn: Verdadero GA] OrderByOnLoad: Verdadero Orientation: De izquieda a derecha RecordCount: 10503 TotalsRow: Falso Updatable: Verdadero Columnas Nombre Tipo Tamaño CODIGO Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo; Autoincremento CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: 1 ColumnWidth: Predeterminado DataUpdatable: Falso OrdinalPosition: 0 Required: Falso SourceField: CODIGO SourceTable: Clasificacion_jugador TextAlign: General NOMBRE Texto 255 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {20E06BEA-C9D8-41C9-96EF-086D61A8CEB3}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 1 Required: Verdadero SourceField: NOMBRE SourceTable: Clasificacion_jugador TextAlign: General UnicodeCompression: Falso TEMPORADA Texto 255 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 33 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Clasificacion_jugador Página: 33 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 2 Required: Falso SourceField: TEMPORADA SourceTable: Clasificacion_jugador TextAlign: General UnicodeCompression: Verdadero CODLIGA Texto 255 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {0A5B2A47-CA9D-4C5F-837D-FE9D7A13AEF4}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 3 Required: Falso SourceField: CODLIGA SourceTable: Clasificacion_jugador TextAlign: General UnicodeCompression: Verdadero PJ Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {570052FE-2178-4BED-B7BF-4FBF34B5A187}} OrdinalPosition: 4 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 34 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Clasificacion_jugador Página: 34 Required: Falso SourceField: PJ SourceTable: Clasificacion_jugador TextAlign: General PG Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {18CD582E-F679-4D8A-B580-07CC2AA70F2B}} OrdinalPosition: 5 Required: Falso SourceField: PG SourceTable: Clasificacion_jugador TextAlign: General PE Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {D97955A2-53A7-43A0-9007-10CB6425A876}} OrdinalPosition: 6 Required: Falso SourceField: PE SourceTable: Clasificacion_jugador TextAlign: General PP Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 35 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Clasificacion_jugador Página: 35 DisplayControl: Cuadro de texto GUID: {guid {A2228219-456C-40AE-827A-22CB2CB220DB}} OrdinalPosition: 7 Required: Falso SourceField: PP SourceTable: Clasificacion_jugador TextAlign: General P Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {B00AE271-11B9-485A-9D77-91A1255A4F04}} OrdinalPosition: 8 Required: Falso SourceField: P SourceTable: Clasificacion_jugador TextAlign: General SM Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {CA5D0CB6-D7B8-44ED-9236-493FCFAE38E1}} OrdinalPosition: 9 Required: Falso SourceField: SM SourceTable: Clasificacion_jugador TextAlign: General CAR Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 36 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Clasificacion_jugador Página: 36 ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {A27FF2F6-EF3E-42D1-B419-DA2D14BF1505}} OrdinalPosition: 10 Required: Falso SourceField: CAR SourceTable: Clasificacion_jugador TextAlign: General ENT Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {AE41FAD7-8B53-494E-B4C6-1C8BB5947DD8}} OrdinalPosition: 11 Required: Falso SourceField: ENT SourceTable: Clasificacion_jugador TextAlign: General PROM Doble 8 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto GUID: {guid {02ED3575-049C-4E31-9E6C-4940DAB1AAF8}} OrdinalPosition: 12 Required: Falso SourceField: PROM SourceTable: Clasificacion_jugador TextAlign: General Relaciones BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 37 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Clasificacion_jugador Página: 37 TemporadaClasificacion_jugador Temporada Clasificacion_jugador Temporada 1  TEMPORADA Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios Índices de tabla Nombre Número de campos PrimaryKey 3 Clustered: Falso DistinctCount: 65265 Foreign: Falso IgnoreNulls: Falso Name: PrimaryKey Primary: Verdadero Required: Verdadero Unique: Verdadero Campos: NOMBRE Ascendente TEMPORADA Ascendente CODLIGA Ascendente TemporadaClasificacion_jugador 1 Clustered: Falso DistinctCount: 22 Foreign: Verdadero IgnoreNulls: Falso Name: TemporadaClasificacion_jugador Primary: Falso Required: Falso Unique: Falso Campos: TEMPORADA Ascendente Permisos de usuario admin Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 38 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Clasificacion_jugador Página: 38 Permisos de grupo Admins Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos Users Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 39 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Club Página: 39 Propiedades DateCreated: 06/11/2008 2:05:58 DefaultView: 2 DisplayViewsOnSharePointSite 1 FilterOnLoad: Falso GUID: {guid {E9364693-B096-4E47HideNewField: Falso 8408-ED875E02F044}} LastUpdated: 24/08/2009 23:04:14 NameMap: Datos binarios largos OrderByOn: Falso OrderByOnLoad: Verdadero Orientation: De izquieda a derecha RecordCount: 38 TotalsRow: Falso Updatable: Verdadero Columnas Nombre Tipo Tamaño CODIGO Texto 3 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {56FC6A81-50CE-4013-AD07-D0BE304FC278}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 0 Required: Verdadero SourceField: CODIGO SourceTable: Club TextAlign: General UnicodeCompression: Falso NOMBRE Texto 38 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {96864BCF-AF60-4989-98BD-0BABFD50D025}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 1 Required: Verdadero SourceField: NOMBRE SourceTable: Club BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 40 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Club Página: 40 TextAlign: General UnicodeCompression: Falso DIRECCION Texto 100 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 2 Required: Falso SourceField: DIRECCION SourceTable: Club TextAlign: General UnicodeCompression: Falso COD_POST Texto 5 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {1E0FCB8B-C1FC-4298-AECD-04447718589A}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 3 Required: Falso SourceField: COD_POST SourceTable: Club TextAlign: General UnicodeCompression: Falso POBLACION Texto 30 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 41 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Club Página: 41 DisplayControl: Cuadro de texto GUID: {guid {8AA60F56-719F-44DD-A360-DEF2E6FD48DF}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 4 Required: Falso SourceField: POBLACION SourceTable: Club TextAlign: General UnicodeCompression: Falso TELEFONO Texto 10 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {565E39CF-05A9-469F-834A-2C32AC36495C}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 5 Required: Falso SourceField: TELEFONO SourceTable: Club TextAlign: General UnicodeCompression: Verdadero EMAIL Texto 40 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {90D52BEB-FD55-4FD9-86A5-9FA6BB34CE85}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 6 Required: Falso SourceField: EMAIL SourceTable: Club TextAlign: General UnicodeCompression: Verdadero PAGINA_WEB Texto 150 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 48 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Precio Página: 48 Propiedades DateCreated: 28/07/2009 23:24:39 DefaultView: 2 DisplayViewsOnSharePointSite 1 FilterOnLoad: Falso GUID: {guid {77498A9F-AB6B-45BCHideNewField: Falso 9633-9BE1536F04D8}} LastUpdated: 29/07/2009 0:41:50 NameMap: Datos binarios largos OrderByOn: Falso OrderByOnLoad: Verdadero Orientation: De izquieda a derecha RecordCount: 1 TotalsRow: Falso Updatable: Verdadero Columnas Nombre Tipo Tamaño Id Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo; Autoincremento CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso OrdinalPosition: 0 Required: Falso SourceField: Id SourceTable: Precio TextAlign: General Junior Simple 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: 2 DisplayControl: Cuadro de texto Format: General Number OrdinalPosition: 1 Required: Verdadero SourceField: Junior SourceTable: Precio TextAlign: General Senior Simple 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 49 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Precio Página: 49 Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: 2 DisplayControl: Cuadro de texto Format: General Number OrdinalPosition: 2 Required: Verdadero SourceField: Senior SourceTable: Precio TextAlign: General Índices de tabla Nombre Número de campos Id 1 Clustered: Falso DistinctCount: 1 Foreign: Falso IgnoreNulls: Falso Name: Id Primary: Falso Required: Falso Unique: Falso Campos: Id Ascendente PrimaryKey 1 Clustered: Falso DistinctCount: 1 Foreign: Falso IgnoreNulls: Falso Name: PrimaryKey Primary: Verdadero Required: Verdadero Unique: Verdadero Campos: Id Ascendente BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 50 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Precio Página: 50 Permisos de usuario admin Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos Permisos de grupo Admins Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos Users Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 51 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Socio Página: 51 Propiedades DateCreated: 06/11/2008 2:04:30 DefaultView: 2 DisplayViewsOnSharePointSite 1 FilterOnLoad: Falso GUID: {guid {030D1AB0-6401-45A9HideNewField: Falso A0EB-539465A708B9}} LastUpdated: 25/08/2009 23:43:07 NameMap: Datos binarios largos OrderByOn: Falso OrderByOnLoad: Verdadero Orientation: De izquieda a derecha RecordCount: 639 TotalsRow: Falso Updatable: Verdadero Columnas Nombre Tipo Tamaño LICENCIA Texto 6 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {1DA7564B-EB0B-4EF1-8BA7-6596F34940C4}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 0 Required: Verdadero SourceField: LICENCIA SourceTable: Socio TextAlign: General UnicodeCompression: Falso F_NACI Fecha/Hora 8 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso GUID: {guid {5E99362C-A532-4627-A68B-DEA67CE40057}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 1 Required: Falso ShowDatePicker: Para fechas SourceField: F_NACI SourceTable: Socio BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 52 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Socio Página: 52 TextAlign: General APELLIDOS Texto 35 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: 3528 DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {C294E867-39AB-48BC-BE10-3C2397233863}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 2 Required: Falso SourceField: APELLIDOS SourceTable: Socio TextAlign: General UnicodeCompression: Falso NOM_BATA Texto 55 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 3 Required: Falso SourceField: NOM_BATA SourceTable: Socio TextAlign: General UnicodeCompression: Falso NOMBRE Texto 20 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 53 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Socio Página: 53 GUID: {guid {0D31ADCC-DE05-45F0-858E-68668904469F}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 4 Required: Falso SourceField: NOMBRE SourceTable: Socio TextAlign: General UnicodeCompression: Falso COD_CLUB Texto 3 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {0CEAE19B-D378-4E67-B237-70F7CEBE6490}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 5 Required: Falso SourceField: COD_CLUB SourceTable: Socio TextAlign: General UnicodeCompression: Falso DNI Texto 10 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {D3033BA5-DDE7-4C6C-9E83-16C3CC7E1767}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 6 Required: Falso SourceField: DNI SourceTable: Socio TextAlign: General UnicodeCompression: Falso DIRECCION Texto 50 AggregateType: -1 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 54 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Socio Página: 54 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {C4182A47-78AE-4C5D-8C01-64945493F3DD}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 7 Required: Falso SourceField: DIRECCION SourceTable: Socio TextAlign: General UnicodeCompression: Falso POBLACION Texto 27 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {F389B3AE-6A8B-4CC9-AF38-16A501079E11}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 8 Required: Falso SourceField: POBLACION SourceTable: Socio TextAlign: General UnicodeCompression: Falso COD_POST Texto 5 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {18BE9148-1E39-4BAD-B6A0-4E3EDD20512D}} IMEMode: 0 IMESentenceMode: 3 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 55 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Socio Página: 55 OrdinalPosition: 9 Required: Falso SourceField: COD_POST SourceTable: Socio TextAlign: General UnicodeCompression: Falso PROVINCIA Texto 11 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {DDC751B7-D956-4D36-AE0B-1E2F094870D6}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 10 Required: Falso SourceField: PROVINCIA SourceTable: Socio TextAlign: General UnicodeCompression: Falso TELEFONO Texto 10 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {D744EF57-AE02-441A-BF5A-745E71672E94}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 11 Required: Falso SourceField: TELEFONO SourceTable: Socio TextAlign: General UnicodeCompression: Falso EMAIL Texto 40 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 56 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Socio Página: 56 CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: 1788 DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {8BD6385E-E88F-4786-A30F-88D32D20724D}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 12 Required: Falso SourceField: EMAIL SourceTable: Socio TextAlign: General UnicodeCompression: Falso NACIONAL Texto 1 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto GUID: {guid {6513893A-9BD2-4065-A1AC-FE1B6F888110}} IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 13 Required: Falso SourceField: NACIONAL SourceTable: Socio TextAlign: General UnicodeCompression: Falso ENVIGOR Sí/No 1 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: 106 Format: Yes/No OrdinalPosition: 14 Required: Falso SourceField: ENVIGOR SourceTable: Socio TextAlign: General BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 57 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Socio Página: 57 ORDEN Entero largo 4 AggregateType: -1 AllowZeroLength: Falso AppendOnly: Falso Attributes: Tamaño fijo CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DecimalPlaces: Automático DisplayControl: Cuadro de texto OrdinalPosition: 15 Required: Falso SourceField: ORDEN SourceTable: Socio TextAlign: General PRECIO Texto 20 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 16 Required: Falso SourceField: PRECIO SourceTable: Socio TextAlign: General UnicodeCompression: Verdadero CATEGORIA Texto 10 AggregateType: -1 AllowZeroLength: Verdadero AppendOnly: Falso Attributes: Longitud variable CollatingOrder: 3082 ColumnHidden: Falso ColumnOrder: Predeterminado ColumnWidth: Predeterminado DataUpdatable: Falso DisplayControl: Cuadro de texto IMEMode: 0 IMESentenceMode: 3 OrdinalPosition: 17 Required: Falso SourceField: CATEGORIA BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 64 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Temporada Página: 64 Relaciones TemporadaActa Temporada Acta Temporada TEMPORADA Attributes: No forzado RelationshipType: Uno a varios TemporadaClasificacion_club Temporada Clasificacion_club Temporada TEMPORADA Attributes: No forzado RelationshipType: Uno a varios TemporadaClasificacion_jugador Temporada Clasificacion_jugador Temporada 1  TEMPORADA Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios Índices de tabla Nombre Número de campos PrimaryKey 1 Clustered: Falso DistinctCount: 48 Foreign: Falso IgnoreNulls: Falso Name: PrimaryKey Primary: Verdadero Required: Verdadero Unique: Verdadero BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 65 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Tabla: Temporada Página: 65 Campos: Temporada Ascendente Permisos de usuario admin Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos Permisos de grupo Admins Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos Users Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Leer definición; Escribir definición; Leer datos; Insertar datos; Actualizar datos; Eliminar datos BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 66 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Base de datos: E:\Escritorio\Billgest 20100323\Billar66.accdb Página: 66 Propiedades AccessVersion: 09.50 AllowBuiltInToolbars: Verdadero AllowDatasheetSchema: Verdadero AllowFullMenus: Verdadero AllowShortcutMenus: Verdadero AllowSpecialKeys: Verdadero AllowToolbarChanges: Verdadero ANSI Query Mode: 0 Auto Compact: 0 Build: 423 CheckTruncatedNumFields: 1 CollatingOrder: 3082 HasOfflineLists: 70 NavPane Category: 1 NavPane Closed: 0 NavPane Sort By: 1 NavPane View By: 0 NavPane Width: 215 Picture Property Storage 0 ProjVer: 87 QueryTimeout: 60 RecordsAffected: 0 Show Values in Indexed: 1 Show Values in Non-Indexed: 1 Show Values in Remote: 0 Show Values Limit: 1000 ShowDocumentTabs: Verdadero StartUpShowDBWindow: Verdadero StartUpShowStatusBar: Verdadero Themed Form Controls: 1 Transactions: Verdadero Updatable: Verdadero UseAppIconForFrmRpt: Falso UseMDIMode: 0 Version: 12.0 Permisos de usuario admin Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Abrir o ejecutar; Abrir en modo exclusivo Permisos de grupo Admins Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Abrir o ejecutar; Abrir en modo exclusivo Users Eliminar; Leer permisos; Establecer permisos; Cambiar propietario, Abrir o ejecutar; Abrir en modo exclusivo BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 67 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Relaciones: Todas Página: 67 Relaciones ClubActa Club Acta NOMBRE 1  CLUB1 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios ClubActa Club Acta NOMBRE 1  CLUB2 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios ClubClasificacion_club Club Clasificacion_club NOMBRE 1  EQUIPO Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios SocioActa Socio Acta LICENCIA 1  LICENCIA12 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 68 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Relaciones: Todas Página: 68 SocioActa Socio Acta LICENCIA 1  LICENCIA21 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios SocioActa Socio Acta LICENCIA 1  LICENCIA22 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios SocioActa Socio Acta LICENCIA 1  LICENCIA31 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios SocioActa Socio Acta LICENCIA 1  LICENCIA32 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios SocioActa Socio Acta LICENCIA 1  LICENCIA41 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo V 69 E:\Escritorio\Billgest 20100323\Billar66.accdb domingo, 11 de abril de 2010 Relaciones: Todas Página: 69 SocioActa Socio Acta LICENCIA 1  LICENCIA42 Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios TemporadaActa Temporada Acta Temporada TEMPORADA Attributes: No forzado RelationshipType: Uno a varios TemporadaClasificacion_club Temporada Clasificacion_club Temporada TEMPORADA Attributes: No forzado RelationshipType: Uno a varios TemporadaClasificacion_jugador Temporada Clasificacion_jugador Temporada 1  TEMPORADA Attributes: Forzado; Actualizaciones en cascada; Eliminaciones en cascada RelationshipType: Uno a varios BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VI CICLO DE PRUEBAS Pruebas Unitarias Interfaz Socio Billargest 06/06/2010 06/06/10 Ciclo de Pruebas C:\Billargest\Pruebas\XXX Página 1 de 5 Socio RESUMEN DE LAS PRUEBAS Descripción Retorno Resultado Paso 1 DataGridView OK Funciona correctamente. Paso 2 Interfaz y estándares OK Funciona correctamente. Paso3 Ortografía Paso 4 E/S Paso 5 Rendimiento (Deben documentarse resultados correctos e incorrectos de todas las posibles opciones de lanzamiento de la rutina ó códigos de acción). CONFIGURACIÓN DEL PROBADOR  No se utiliza ningún probador específico. PRECONDICIONES  No existe ninguna precondición específica. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VI CICLO DE PRUEBAS Pruebas Unitarias Interfaz Socio Billargest 06/06/2010 06/06/10 Ciclo de Pruebas C:\Billargest\Pruebas\XXX Página 2 de 5 DETALLE DE LAS PRUEBAS 1. DATAGRIDVIEW Se comprueba que el formato del DataGridView que se representa en la pantalla sea el correcto acorde a los estándares establecidos. Su navegación debe ser completa. El enlace a datos debe funcionar correctamente. Entrada: Registros tabla Socio BB.DD. Salida: DataGridView correctamente representado y con su formato correcto. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VI CICLO DE PRUEBAS Pruebas Unitarias Interfaz Socio Billargest 06/06/2010 06/06/10 Ciclo de Pruebas C:\Billargest\Pruebas\XXX Página 3 de 5 2. Interfaz y estándares Se comprueba que la interfaz cumple con los estándares especificados en el conjunto de normas de la aplicación. Entrada: Salida: Diálogo socio correctamente representado. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VI CICLO DE PRUEBAS Pruebas Unitarias Interfaz Socio Billargest 06/06/2010 06/06/10 Ciclo de Pruebas C:\Billargest\Pruebas\XXX Página 4 de 5 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VII 6 2. Condiciones técnicas 2.1. Objetivo Constituye el objeto del presente pliego de condiciones técnicas para la contratación del proyecto de implantación del sistema de información para la gestión de ligas de billar BILLARGEST para la Federación de Billar de la Comunidad Valenciana (FBCV). Este documento abarcará los aspectos técnicos y organizativos necesarios para asegurar la máxima calidad del proyecto presentado. 2.2. Descripción funcional Las condiciones de los trabajos comprendidos en el presente pliego de condiciones técnicas, consiste en la realización del proyecto BILLARGEST que engloba las siguientes unidades de negocio: - Gestión de Temporadas. -Gestión de Actas. - Gestión de Clubes. - Gestión de Socios. Todos los módulos especificados además contendrán a su vez las funciones generales: - Listados. - Impresión. - Exportación a Excel (excepto actas). En el ANEXO II - 3.Análisis del sistema de información se encuentra una descripción detallada de los mismos. 2.3. Condiciones de realización El adjudicatario presentará un plan de actividades en el cual se especificarán los horarios de prestación de los servicios, calendarios de disponibilidad del técnico, periodos de desarrollo, implantación y pruebas y de resolución de incidencias, así como el resto de información de servicio necesaria para la correcta colaboración entre los dos titulares del contrato. El contratista se compromete a utilizar la metodología y pautas de trabajo especificadas en los anexos de requisitos entregados para garantizar la calidad de los servicios ofrecidos. Además, habrá de incluirse la correspondiente formación del personal seleccionado por la administración de la FBCV, que se encargará de la posterior administración del sistema. La aceptación del producto se realizará de manera formal a través de un documento que lo acredite una vez todas las pruebas de aceptación del producto queden concluidas y sean BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VII 7 satisfactorias para la FBCV. De la misma manera se realizará al finalizar el periodo de formación. Los detalles del proceso de formación se encuentran en el ANEXO II - 5. Construcción del Sistema de Información. 2.4. Equipo de trabajo El contratante designará a un solo director técnico de proyecto que considere oportuno, el cual con relación a la prestación de los servicios objeto del presente contrato tendrá las siguientes funciones: - Velar por el cumplimiento de las prestaciones exigidas y ofrecidas. - Realizar las certificaciones parciales de servicios prestados. - Otras actuaciones: - Informar al adjudicatario de cualquier deficiencia que observe en algún componente lógico, facilitando a la vez toda la información disponible sobre la incidencia. - Adoptar las medidas que fueren precisas, dentro de lo posible, con el fin de facilitar la determinación de los fallos y sus causas. - Adoptar las medidas que fuesen precisas para la utilización del sistema de acuerdo con las normas de empleo del adjudicatario. Respecto al técnico responsable del proyecto por parte del adjudicatario, se precisa que tenga experiencia los siguientes conocimientos: - Desarrollo de aplicaciones en entorno Microsoft© Visual Studio 2008 con Microsoft© Visual C# 3.5. - Elaboración de Bases de Datos relacionales con formato Microsoft© Access. - Construcción de diagramas y modelado. - Experiencia en informática ofimática para la redacción de la documentación asociada. - Capacidad de comunicación para la formación in situ a usuarios. 2.5. Requisitos Requisitos técnicos específicos: - Arquitectura La arquitectura donde se implantará el sistema será una arquitectura de un solo nivel de acuerdo a las exigencias de la FBCV. Esta arquitectura corresponde a los sistemas en los que tanto el remitente de una solicitud como el receptor de la solicitud enviada por BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VII 8 cliente se encuentran en una misma máquina física. Esta configuración no podrá ser alterada en ningún caso. - Herramienta de desarrollo y programación - Microsoft© Visual Studio 2008 Service Pack 1 (SP1) - Microsoft©.NET Framework 3.5 SP1 - Instalador: InstallShield© Premium 2010 -Generación de reportes: Crystal Report© .NET - Herramientas de gestión de Base de Datos: - Microsoft© Access 2007 - Herramientas de documentación: - Microsoft© Word 2007 - Herramientas de gestión: - Microsoft© Project 2003 Requisitos técnicos generales: Definición de los servicios que son necesarios para certificar la calidad de los productos: - Funcionalidad: deberá asegurar la adecuación y la exactitud de las aplicaciones, así como interoperabilidad y seguridad de acceso. - Mantenibilidad: se deberá asegurar que la aplicación es mantenible, es decir, con la documentación deberá poder ser analizada, cambiada y probada. Además se deberá asegurar que la aplicación sea estable. - Eficiencia: se deberá asegurar que la aplicación es eficiente. - Usabilidad: se validará que la aplicación se puede entender, aprender y operar. - Fiabilidad: se validará que la aplicación tiene una suficiente tolerancia a fallos y capacidad de recuperación ante errores. - Portabilidad: se validará que la aplicación ofrece unos niveles correctos de adaptabilidad, instalabilidad y coexistencia con otras aplicaciones. Se asumen además todos los requisitos no funcionales descritos en el ANEXO II - 2.Estudio de Viabilidad del Sistema. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VII 9 3. Seguridad y confidencialidad La empresa adjudicataria y el personal encargado de la realización de las tareas guardarán secreto profesional sobre todas las informaciones, documentos y asuntos a los que tengan acceso o conocimiento durante la vigencia del contrato, estando obligados a no hacerlos públicos o enajenar cuantos datos conozcan como consecuencia o con ocasión de su ejecución, incluso después de finalizar el plazo contractual. El adjudicatario se compromete a mantener estricta confidencialidad y a no revelar o ceder datos, ni aun para su conservación, o documentos proporcionados por la Administración o copia de los mismos, a terceros, para cualquier otro uso no previsto como necesario para el desempeño del proyecto, especialmente los datos de carácter personal. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VIII 1 Anexo VIII. Índice: 1. Evaluación de riesgos ................................................................................................................. 2 1.1. Riesgos identificados .......................................................................................................... 2 1.2. Exposición a riesgos ............................................................................................................ 8 1.3. Planes de acción ............................................................................................................... 12 1.4. Planes de contingencia ..................................................................................................... 13 BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VIII 2 1. Evaluación de riesgos 1.1. Riesgos identificados Riesgo es la Condición o evento incierto, que de darse, tiene efecto en al menos un objetivo del proyecto (ámbito, calendario, coste o productividad). Por tanto se hace necesario abordar, preparar y planificar las actividades de gestión de riesgos del proyecto para reducir los efectos adversos que puedan provocarse. Para la clasificación de riesgos se utilizarán las tablas propuestas por TeraQuest©1 que proporcionan una visión global de riesgos del proyecto. Factor ID Descripción Riesgo bajo Riesgo medio Riesgo alto Descripción Metas y objetivos 1 Ajusta el proyecto a la estructura del cliente. X No se esperan cambios en la estructura del cliente. 2 Ajusta el proyecto a la estructura del proveedor. X No se esperan cambios para adaptarse a los roles requeridos para la realización del proyecto. 3 Workflow. X El producto podría ocasionar cambios en los flujos de datos del cliente. Dirección del programa 4 Influencias políticas. X No hay ninguna decisión impulsada por las políticas. 6 Establecimiento de fechas. X Las fechas se han establecido mediante un compromiso razonable entre proyecto y proceso. 7 Atractivo tecnológico. X Se trata de una tecnología madura. 8 Solución a Corto Plazo. X Se trata de un proyecto que puede variar debió al cambio de normas en la reglamentación. Organización de Gestión 9 Estabilidad de la organización. X La organización no puede sufrir cambios. 10 Organización de roles y responsabilidades. X Todos los roles radican en la misma persona. 11 Políticas y estándares. X El proyecto se desarrollará de acuerdo a estándares y políticas ampliamente 1 TeraQuest, Riesgos genéricos del proyecto (Diciembre, 1999): http://ais.msu.edu/internal/projectmgt/documents/ProjectRiskFactors.pdf BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VIII 3 conocidas. 12 Apoyo a la Gestión. X El adjudicatario se encuentra comprometido con el éxito del proyecto. 13 Compromiso. X El compromiso es total. 14 Objetivos del proyecto. X Los objetivos están totalmente verificados por el cliente y son alcanzables por el adjudicatario. Cliente 15 Compromiso cliente. X El cliente de la aplicación ha descrito convenientemente todos los procesos y se encuentra comprometido. 16 Experiencia del cliente. X La experiencia del cliente es nula y eso provoca un alto nivel de incertidumbre. 17 Aceptación del cliente. X El cliente entiende el proyecto y los procesos pero puede pretender cambios. 18 Necesidades de formación del cliente. X El cliente precisa formación en la utilización del producto. 19 Justificación del cliente. X El cliente realizó una especificación completa pero existe la posibilidad de que la implantación del sistema produzca cambios en la especificación. Parámetros del proyecto 20 Tamaño del proyecto. X El tamaño del proyecto es pequeño. 21 Restricciones de hardware. X La aplicación puede ser soportada por un equipo comercial y no tiene problemas restricciones de tiempo. 22 Reutilización de componentes. X Ninguno de los componentes utilizados serán reutilizados. 23 Tamaño del presupuesto. X En caso de que el proyecto cambie de especificación, no está asegurado el presupuesto. 24 Restricciones de presupuesto. X El presupuesto debe adaptarse al tipo de organización que nos encontramos modelando. 25 Control de costos. X Los costos se encuentran controlados para los recursos establecidos. 26 Compromiso de entrega. X El compromiso por parte del adjudicatario es máximo, se cumplirán BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VIII 4 los plazos. 27 Compromiso de desarrollo. X Las fechas de cada fase han sido estudiadas y el compromiso es máximo. Contenido del producto 28 Estabilidad de los requisitos. X Los requisitos pueden cambiar. 29 Requisitos claros y completos. X Algunos requisitos podrían no encontrarse perfectamente especificados para su compresión o no estar completos. 30 Facilidad de prueba. X El tamaño del proyecto y su complejidad baja, junto con trabajar con una tecnología conocida hace que el proyecto sea fácil de probar. 31 Dificultad de diseño. X Al tratarse de un proyecto de gestión, en el que el proceso a seguir está bien definido, el diseño no se complica en este caso. 32 Dificultad de implementación. X La formación tecnológica del desarrollador es alta y por tanto la implementación no es un riesgo elevado. 33 Dependencias del sistema. X A pesar de tener algunas dependencias, el sistema puede funcionar al completo sin ellas. Despliegue 34 Recursos de hardware para entregables. X Los recursos de que se disponen hacen que no sea un riesgo importante. 35 Respuesta de otros factores de rendimiento. X El proyecto no requiere de grandes recursos, los planificados serán suficientes. 36 Servicio de Impacto de cambios al cliente. X Los cambios pueden producir un impacto muy bajo sobre la herramienta. 37 Migración de Datos. X El proyecto no tiene migración de datos. 38 Enfoque experimental. X Es un proyecto con antecesor. 39 Integración externa o interna de interfaces. X La base de datos que se usará tiene una interfaz totalmente integrada con el entorno de desarrollo. BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VIII 5 Proceso de desarrollo 40 Análisis de alternativas. X Se estableció una comparación de los ciclos de desarrollo y coste hasta encontrar el que mejor se adaptaba al proyecto. 41 Compromiso en el proceso. X Los cambios son únicamente comunicados a los implicados. 42 Enfoque de aseguramiento de la calidad. X La calidad del producto final está asegurada debido al cumplimiento de estándares. 43 Documentación de desarrollo. X La documentación del proyecto estará disponible y completa. 44 Uso de la ingeniería de procesos. X Al realizar el desarrollo del proyecto se tiene en cuenta la ingeniería de procesos. 45 Temprana identificación de defectos. X Se incorporan técnicas para detección de defectos, pero pueden no ser suficientemente eficientes. 46 Seguimiento de defectos. X Existirá un enfoque evolutivo para el seguimiento de defectos. 47 Control de cambios en los productos. X Se utilizarán herramientas para gestionar cambios. Entorno de desarrollo 48 Instalación física. X La instalación es sencilla, no supone riesgo. 49 Plataforma de hardware. X Estable, sin cambios previstos, la capacidad es suficiente. 50 Disponibilidad de las herramientas. X La disponibilidad de las herramientas que se utilizarán es total y su documentación esta completa. 51 Apoyo de proveedores. X El apoyo por parte de los proveedores del entorno de desarrollo es nulo de manera directa, pero existe gran cantidad de apoyo de terceras partes. 52 Contrato establecido. X El contrato especifica cláusulas como el número de equipos sobre el que se puede instalar el software. 53 Recuperación de desastres. X Existen medidas de seguridad pero no hay un procedimiento de seguridad establecido. Gestión del proyecto BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VIII 6 54 Enfoque PM (Project Management) X Los procesos de planificación y cumplimiento son llevados a cabo en el momento adecuado. 55 Comunicación PM. X La comunicación es clara en el equipo de desarrollo ya que está compuesto por un miembro. 56 Experiencia PM. X La experiencia es media sobre este tipo de proyectos. 57 Actitud PM. X La actitud es firme para conseguir el éxito del proyecto. 58 Autorización PM. X No es necesario implantar la gestión del liderazgo. 59 Apoyo de la PM. X El apoyo es máximo. Equipo de desarrollo 60 Disponibilidad de los miembros del equipo. X Es posible que el responsable del proyecto sea interrumpido en ocasiones de sus tareas. 61 Equipos con mezclas de habilidades. X El responsable del proyecto tiene solo unas ciertas habilidades sobre las que destaca. 62 Experiencia en aplicaciones. X La experiencia de desarrollo en proyectos de cualquier índole es media. 63 Experiencia con proyectos de hardware y software. X La experiencia sobre el hardware y el software del equipo es grande. 64 Experiencia con procesos. X El responsable tiene experiencia sobre procesos, pero quizás no la suficiente. 65 Formación del equipo. X La formación es continúa, aunque no demasiado necesaria para el tipo de desarrollo que se plantea. 66 Actitud y espíritu de equipo. X - 67 Productividad del equipo. X La productividad del responsable es alta. 68 Área de experiencia con la aplicación (de dominio). X La experiencia de desarrollo en este tipo de proyectos es media. Tecnología 69 Combinar la tecnología al proyecto. X La tecnología prevista para el proyecto es adecuada para los clientes y para BillarGEST: Sistema de Información para la Gestión de Ligas de Billar Anexo VIII 13 1.4. Planes de contingencia Para establecer el plan de contingencia se van a tener en cuenta los riesgos con mayores posibilidades de afectar a la evolución del proyecto.  Si por la implantación de la nueva herramienta se producen cambios en los flujos de datos del cliente, se le enseñara al cliente cual es este flujo de datos, como se origina y cuál es el nuevo comportamiento que tienen.  En caso de que durante la realización del proyecto, aparezcan problemas de implementación los cuáles el responsable del proyecto no sea capaz de resolver, se fomentará un contrato con una consultora experta en tecnología .NET que cubrirá las insuficiencias técnicas de la empresa mediante la impartición de algún curso.  En caso de que se produzca un defecto grave en el sistema, el responsable se compromete a hacerse cargo del coste de dicho problema sin coste para la FBCV. Esto supone que la calidad y los procesos que la controlan deben ser inspeccionados de forma cuidadosa.  Si no se cumpliesen las fechas marcadas como consecución de tareas, se respetarán los tiempos asignados a cada tarea y se retrasará la fecha de entrega final del proyecto tantos días como se haya retrasado la suma de todas las tareas.  En caso de que cambie la reglamentación de los campeonatos de billar, las modificaciones que requiera la aplicación por estas causas deberán ser tenidas en cuenta como ampliaciones o modificaciones del proyecto, y en ningún caso su coste será asumido por el proveedor.