Enunciado 7: "Gestión de un hotel"

Enunciado 7: "Gestión de un hotel"

RESUMEN

En primer lugar se leyó con detenimiento el enunciado y los objetivos que pedía este sistema, en segundo lugar se repartió el trabajo entre los miembros de cada grupo, unos se encargaban de los requisitos y otros de realizar el modelo de Entidad-Relación. Por último se juntó todo y se realizo el informe.

INTRODUCCIÓN

Esta aplicación debe gestionar las actividades realizadas por hotel. Se tendrán unos departamentos que no ofrecen servicios al cliente pero que son importantes para la gestión del hotel y además se contará con una serie de proveedores a los que poder acudir para realizar pedidos de cualquier tipo para el hotel.

PROCESO DE DESARROLLO

Análisis de requisitos

• Requisitos del Cliente:

1. Realizar un presupuesto.

   1. Consultar disponibilidad de las habitaciones según las fechas.

   2. Consultar servicios adicionales.

   3. Ver precio final.

2. Registrarse en la aplicación.

   1. Añadir cliente en la BD.

      1. Introducir nombre único de usuario y contraseña.

      2. Introducir datos personales.

3. Modificar los datos personales.

   1. Modificar los datos introducidos cuando se registró.

4. Realizar reserva de habitación.

   1. Consultar disponibilidad de las habitaciones según las fechas.

   2. Elegir tipo de habitación y cantidad de las mismas.

   3. Ver precio final.

   4. Introducir número de tarjeta.

   5. Realizar reserva.

5. Modificar reserva.

   1. Mandar mensaje a recepción.

6. Cancelar reserva.

   1. Mandar mensaje a recepción.

7. Realizar reserva de servicio especial.

   1. Consultar disponibilidad de los servicios ofertados.

   2. Elegir el servicio.

   3. Realizar reserva.

8. Consultar Reservas.

9. Consultar factura.

• Requisitos de la Recepcionista:

1. Realizar reserva de habitación.

   1. Consultar disponibilidad de las habitaciones según las fechas.

   2. Elegir tipo de habitación y cantidad de las mismas.

   3. Introducir número de tarjeta dado por el cliente.

   4. Realizar reserva.

2. Modificar una reserva.

3. Cancelar una reserva.

4. Realizar reserva de servicio especial.

   1. Consultar disponibilidad de los servicios ofertados.

   2. Elegir el servicio.

   3. Realizar reserva.

5. Consultar reservas.

6. Consultar facturas.

• Requisitos del Camarero:

1. Reservar Mesa:

   1. Mirar disponibilidad de mesas.

   2. Realizar reserva.

2. Modificar reserva.

3. Cancelar reserva.

4. Gestión de factura.

   1. Añadir gastos a la factura.

   2. Modificar gastos.

   3. Eliminar gastos.

5. Imprimir factura.

6. Gestionar Platos.

   1. Añadir platos.

      1. Introducir datos de los platos.

   2. Modificar platos.

   3. Eliminar platos.

7. Consultar reservas.

• Requisitos del Entrenador:

1. Reservar Actividad:

   1. Mirar disponibilidad de actividades.

   2. Realizar reserva.

2. Modificar reserva.

3. Cancelar reserva.

4. Gestión de factura.

   1. Añadir gastos a la factura.

   2. Modificar gastos.

   3. Eliminar gastos.

5. Imprimir factura.

6. Gestionar Actividades.

   1. Añadir actividades.

      1. Introducir datos de las actividades.

   2. Modificar actividades.

   3. Eliminar actividades.

7. Consultar reservas.

• Requisitos de Personal de RR.HH.:

1. Gestión de empleados.

   1. Altas de empleados.

      1. Introducir datos de empleados.

   2. Modificación de empleados.

   3. Cancelación de empleados.

2. Gestión de departamentos.

   1. Altas de departamentos.

      1. Introducir datos de departamentos.

   2. Modificación de departamentos.

   3. Cancelación de departamentos.

• Requisitos de Personal de Dept. de Finanzas:

1. Gestión de facturas.

   1. Modificación de facturas.

   2. Eliminación de facturas (mantenimiento de BD).

2. Gestión de pedidos.

   1. Validación de pedidos.

   2. Modificación de pedidos.

   3. Eliminación de pedidos (mantenimiento de BD).

• Requisitos de Personal de Mantenimiento:

1. Revisar avisos.

2. Eliminar aviso (una vez resuelto el problema).

• Requisitos del Personal de Limpieza

1. Barrer y fregar el suelo

2. Limpieza del material

3. Administración del material de limpieza

• Requisitos del Personal de Atención al cliente (Botones)

1. Atender a las llamadas de los clientes

2. Responder a los avisos

3. Solucionar el problema

4. Apuntar el problema

Modelo Entidad-Relación

RECURSOS UTILIZADOS

Enunciados y documentación para completar la información: Ubu Virtual / Ingeniería del Software.

Los programas utilizados han sido: Microsoft Office Word 2007, para redactar los informes de las prácticas; y la versión portable de la herramienta case Pacestar EDGE Diagrammer (v6.20.2040): para la creación de los modelos Entidad-Relación.

CONCLUSIÓN

Con la realización de este enunciado nos hemos dado cuenta de todo el personal y todas las funciones y los servicios que implica regentar un gran hotel.

Enunciado 6: "Gestión de un taller"

Enunciado 6: "Gestión de un taller"

RESUMEN

En primer lugar se leyó con detenimiento el enunciado y los objetivos que pedía este sistema, en segundo lugar se repartió el trabajo entre los miembros de cada grupo, unos se encargaban de los requisitos y otros de realizar el modelo de Entidad-Relación. Por último se juntó todo y se realizo el informe.

INTRODUCCIÓN

Se desea modelar el sistema para la gestión de un taller de vehículos.

PROCESO DE DESARROLLO

Análisis de requisitos

• Usuarios

1. El Cliente:

   1. El usuario que acceda por primera vez a nuestro sistema deberá previamente registrarse introduciendo un login de cliente, y sus datos personales (nombre, apellido, dirección, teléfono ) que será almacenado en el sistema siempre y cuando el Id_cliente no exista ya en el sistema.

   2. Nuestro usuario se validará como cliente de la aplicación a través del login y tendrá acceso a los servicios de compra, alquiler y reparación de vehículos.

   3. Si accede al servicio de compra

      1. El cliente para registrar la compra, introducirá su clave de cliente (Id_cliente), las características del vehículo que desea adquirir (Modelo y marca) y el número de cuenta.

      2. De los vehículos con las características solicitadas se elegirá un vehículo con una clave única (Id_vehículo) en la aplicación al demandante, actualizándose los vehículos disponibles para la venta, de modo que un mismo vehículo no sea asignado a varios clientes.

      3. El cliente podrá recoger su vehículo en un plazo de 24 horas después de solicitar el servicio siempre y cuando el registro haya sido correcto.

   4. Si accede al servicio de alquiler

      1. El cliente para registrar el alquiler introducirá su clave de cliente (Id_cliente), las características del vehículo que desea adquirir (Modelo y marca), el número de cuenta en el cual se hará el cargo por el uso del servicio, la fecha a partir de la cual se va a iniciar el alquiler ( Fecha_Inicio) y la fecha de devolución del coche de alquiler (Fecha_Devolución).

      2. El usuario podrá recoger el vehículo alquilado en la oficina en la que se hizo el alquiler, en la fecha establecida, si el registro del mismo ha sido correcto.

      3. La devolución se hará en la misma oficina desde donde se hizo el alquiler.

      4. Una vez que el vehículo sea devuelto se comprueba que la fecha de entrega no supere la fecha de devolución fijada y el estado del vehículo en la devolución.

      5. Si se produce cualquier irregularidad se generará una sanción monetaria, en forma de cargo adicional a la cuenta del cliente.

   5. Si accede al servicio de reparación.

      1. El cliente para registrar una petición de reparación introducirá su clave de cliente (Id_cliente), matrícula del vehículo a reparar.

      2. Si el registro es correcto la petición será almacenada y el cliente será avisado cuando se complete la misma.

2. El Jefe de Taller:

   1. Un jefe de taller, en el trato con el cliente vende ó alquila coche.

   2. Cuando se produce una venta de un vehículo, recibe la descripción de la venta en cuanto a modelo, precio, cliente que ha adquirido el vehículo... para generar la factura y efectuar su cobro.

   3. Cuando se produce un alquiler recibe un informe del jefe de taller con el alquiler de un determinado vehículo, conteniendo el modelo de vehículo alquilado, el cliente, la duración del alquiler, el requerimiento de conductor... para generar la factura a pasar al cliente.

   4. Realiza el pedido de compra de vehículos nuevos destinados a la venta o al alquiler, generando el pago de la compra.

   5. Estudia las ventas y los alquileres para saber qué vehículos tienen más aceptación entre el público.

   6. Vigila el estado de los vehículos de alquiler, y los manda al taller de reparación si es necesario.

   7. Genera sanciones si se ha superado el plazo de alquiler o si se devuelve el vehículo en mal estado, informa al administrador.

3. El Mecánico:

   1. Para permitir el acceso del mecánico a la aplicación, debe haber sido registrado por el administrador en el sistema.

   2. En el registro recogeremos los siguientes datos (Id_mecánico, nombre, apellido, teléfono, edad)

   3. El mecánico para acceder al sistema debe validarse como usuario dentro del mismo, las claves de acceso serán (Id_mecánico, nombre), siendo Id_mecánico clave única en el sistema.

   4. El mecánico antes de atender a cualquier petición de reparación comprueba que hay stock suficiente de piezas en el almacén, sino realizará el pedido a los proveedores, actualizándose el almacén de piezas tras su recepción.

   5. Los pedidos van a ser atendidos por el mecánico en función del orden de llegada.

   6. Cuando el mecánico termine la reparación de un vehículo, mandará un informe al administrador para que comunique al cliente que puede recoger su vehículo. Además pasará el estado de la reparación de “en ejecución” a “fin”.

   7. Por último el mecánico comunica al administrador el número de piezas usadas para la reparación para que éste actualice las unidades en almacén.

4. El Administrador:

   1. El jefe de taller notificará al administrador las compras y las ventas que se realicen de los vehículos para que éste efectúa las correspondientes altas y bajas en los almacenes de vehículos.

   2. El mecánico notificará al administrador las compras de piezas que se realicen para poder reparar los vehículos, para que éste efectué las correspondientes altas y bajas en los almacenes de piezas.

   3. Realiza el mantenimiento de altas y bajas tanto de proveedores como de empleados así como las modificaciones en clientes.

   4. Es el encargado de la asignación de claves en el proceso de registro de usuarios.

5. Conductores:

   1. Los conductores deben tener una alta disponibilidad porque pueden ser requeridos en cualquier momento para realizar un servicio.

   2. El servicio de chofer conlleva un recargo adicional en la factura del cliente.

   3. El chofer es el responsable del vehículo con el que ofrece el servicio.

6. Tienda

   1. Los encargados de la tienda se encargan de vender piezas a clientes con la capacidad de arreglarse ellos mismos pequeños desbarajustes en sus coches.

   2. El encargado principal se encarga de gestionar el stock de piezas para ir haciendo reposiciones de las mismas en la tienda.

      1. Encargar piezas al Administrador del Taller.

      2. Ordenar y controlar las piezas recibidas.

   3. El encargado de las facturas se encarga de que los clientes abonen el pago de las piezas y de tener un control de los gastos de cada cliente.

7. Equipo de pintura

   1. Los pintores se encargan de pintar todos los coches que pidan los clientes.

   2. Hay distintos encargados dependiendo del modelo del coche, el tipo de pintura y el tipo de dibujo.

   3. Hay un encargado del material estrechamente relacionado con el Administrador del taller.

8. Equipo de limpieza

   1. Se encarga de dejar limpio todo el material para que pueda volver a ser utilizado el día siguiente.

   2. Encargado del material de limpieza.

• Los Proveedores:

1. El sistema gestionará de la misma forma los proveedores de piezas que los de coches.

2. Hay que registrar a los proveedores con los que trataremos en nuestra BD. Los elegirá el jefe de taller, y se lo comunicará al administrador para que los dé de alta en la tabla.

3. Los proveedores nos proporcionarán un e-mail al que mandarles los pedidos.

4. El proveedor/es recibe los avisos de pedidos solicitados al momento.

5. Si el proveedor no tiene stock se envía un aviso a nuestra empresa del tipo “pedido rechazado”.

6. Si el pedido puede satisfacerse con normalidad, el proveedor genera un presupuesto (presupuesto) y un posible descuento (dto) por número de artículos (piezas o coches) comprados.

7. Cuando nuestra empresa acepte el presupuesto se generará una factura por parte de los proveedores que será guardada y gestionada por nuestro jefe de taller.

Modelo Entidad-Relación

RECURSOS UTILIZADOS

Enunciados y documentación para completar la información: Ubu Virtual / Ingeniería del Software.

Los programas utilizados han sido: Microsoft Office Word 2007, para redactar los informes de las prácticas; y la versión portable de la herramienta case Pacestar EDGE Diagrammer (v6.20.2040): para la creación de los modelos Entidad-Relación.

CONCLUSIÓN

Con la realización de este enunciado nos hemos dado cuenta de todo el personal y todas las funciones y los servicios que implica regentar un taller mecánico, aún más, después de haber incluido la tienda.

Enunciado 2: "Hospital Privado"

Enunciado 2: "Hospital Privado"

RESUMEN

En primer lugar se leyó con detenimiento el enunciado y los objetivos que pedía este sistema, en segundo lugar se repartió el trabajo entre los miembros de cada grupo, unos se encargaban de los requisitos y otros de realizar el modelo de Entidad-Relación. Por último se juntó todo y se realizo el informe.

INTRODUCCIÓN

Se requiere desarrollar un sistema de software que apoye la gestión de unos multicines a fin de una inmediata implementación en sus instalaciones.

PROCESO DE DESARROLLO

Análisis de requisitos

1. Requisitos en cuanto a la gestión de pacientes:

   1. Se introducen los datos del paciente en la gestión y el mantenimiento de datos

      1. Si el paciente es nuevo se crea una tarjeta médica.

   2. Se valida y comprueba la tarjeta médica del paciente.

   3. Se gestiona una cita para el paciente, seleccionando especialidad.

      1. Se consulta la disponibilidad de consultas de la especialidad.

      2. Se asigna una consulta según su dolencia y horarios disponibles.

      3. Se registra la cita y se relaciona con el médico teniendo en cuenta la fecha, la hora y la ID del paciente.

   4. El médico gestiona el tratamiento del paciente.

      1. Se asignan medicamentos.

      2. Se asignan dietas.

      3. Se almacena en el historial del paciente.

   5. Si el paciente ha de ser ingresado:

      1. Se accede a la gestión de ingresos

   6. Se actualiza el historial

   7. Gestiona la factura.

2. Requisitos de la gestión de ingresos.

   1. Se consulta la especialidad necesaria.

   2. Se consulta el estado de las habitaciones de la planta.

   3. Se registra al paciente en una habitación vacía.

      1. Se registra la ID del paciente y se vincula a la ID de la habitación.

   4. Se actualiza el número de habitaciones vacías.

3. Requisitos de la gestión de bajas.

   1. Se registra la baja del paciente.

      1. Se elimina la ID asignada a la habitación.

      2. Se anulan las visitas médicas.

         1. Eliminan las restricciones médicas (dietas etc…).

      3. Se actualiza la gestión de cocina.

      4. Actualiza el número de habitaciones vacías.

4. Requisitos de la gestión de mantenimiento de datos.

   1. Se selecciona la tabla con el tipo de mantenimiento (Alta, Baja, Modificación).

   2. Se introducen, borran, modifican los datos y se guardan los cambios.

5. Requisitos de la gestión de proveedores.

   1. Alimentos.

      1. Almacén de registro de precios.

      2. Se generan pedidos de los alimentos.

   2. Medicamentos.

      1. Almacén de catálogo de medicamentos.

      2. Se generan pedidos de los medicamentos.

   3. Material Hospitalario.

      1. Almacén de catálogo de material de hospital.

      2. Listas para pedir presupuestos.

      3. Recibir ofertas y presupuestos de las listas.

      4. Confirmar pedido de material.

6. Requisitos de la gestión de dietas.

   1. Se recogen las restricciones de dietas de los pacientes.

   2. Elaboración de dietas conforme a los niveles nutricionales requeridos.

   3. Planing de menú semanal.

   4. Pedidos a los proveedores de alimentos.

7. Requisitos de la gestión de mantenimiento.

   1. Recogida de informes de desperfectos.

   2. Gestión de reparaciones.

      1. Evaluación de daños.

      2. Comprobación de materiales para reparación.

      3. Contacto con profesionales del sector si fuera necesario.

   3. Informe de reparaciones.

8. Requisitos de la gestión de personal.

   1. Opciones correspondientes a perfiles de usuarios.

   2. Acceso con Login y Password.

      1. Validación de acceso.

      2. Permiso o denegación de acceso.

9. Requisitos de la gestión de pagos.

   1. Gestión de nóminas.

      1. Salario mensual

      2. Horas Extras

      3. Cargos

      4. Incentivos

      5. Validación de datos.

      6. Registro de nóminas.

   2. Ordenar pagos.

   3. Gestión de pagos a los proveedores.

      1. Recogida de facturas.

      2. Validación de los datos de las facturas.

      3. Registro de Gastos.

   4. Ordenar pagos.

      
      

Modelo Entidad-Relación:

RECURSOS UTILIZADOS

Enunciados y documentación para completar la información: Ubu Virtual / Ingeniería del Software.

Los programas utilizados han sido: Microsoft Office Word 2007, para redactar los informes de las prácticas; la versión portable de la herramienta case Pacestar EDGE Diagrammer (v6.20.2040): para la creación de los modelos Entidad-Relación; otras herramientas CASE; y el Paint, para modificar ciertos retoques en los diagramas de Entidad-Relación.

CONCLUSIÓN

Con la realización de este enunciado nos hemos dado cuenta de todo el personal y todas las funciones y los servicios que implica regentar unos multicines.

Entregas de prácticas

Enunciado 1: "Centro de Animales"

RESUMEN

En primer lugar se leyó con detenimiento el enunciado y los objetivos que pedía este sistema, en segundo lugar se repartió el trabajo entre los miembros de cada grupo, unos se encargaban de los requisitos y otros de realizar el modelo de Entidad-Relación. Por último se juntó todo y se realizo el informe.

INTRODUCCIÓN

El proyecto abarca el proceso de gestión de un centro animal, que está constituido por una clínica veterinaria, un centro de belleza animal y una tienda de complementos.

PROCESO DE DESARROLLO

PSI

PSI 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN

PSI 1.1: Análisis de la Necesidad del PSI

El objetivo principal es desarrollar un sistema software para mejorar la gestión de un centro de animales.
Se debe crear una base de datos con sus campos correspondientes para cada una de las partes del centro.

PSI 1.2: Identificación del Alcance del PSI

Como objetivos principales, la base de datos que crearemos debe estar diferenciada en tres partes, porque el centro animal esta constituido por una clínica veterinaria, un centro de belleza animal y una tienda de complementos.
También se precisa una estructura clara para las facturas, pagos etc.

PSI 1.3: Determinación de Responsables

Los responsables de llevar a cabo este proyecto serán Fernando Somoza Alonso, Rodrigo García Diez y Daniel Hernando Blanco. Para este proyecto se va a intentar hacer un reparto equitativo, aunque trabajando de forma conjunta para la coherencia de éste y que no se vea disminuida la calidad por la incomunicación de los participantes.

PSI 2: DEFINICIÓN Y ORGANIZACIÓN DEL PSI

PSI 2.1: Especificación del Ámbito y Alcance

Se creara una base de datos, con tablas como cliente, animal, servicios (incluyendo en esta ramificaciones según se trate de la clínica veterinaria, el salón de belleza o la tienda de complementos), pedidos y facturas… Para cada campo, habrá un tipo de persona involucrada de una lista de participantes.

PSI 2.2: Organización del PSI

De los 3 responsables involucrados en el proyecto, Fernando Somoza se encargara de la planificación del sistema de información y del estudio de viabilidad. Rodrigo García, se encargara del análisis y el diseño del sistema de información. Daniel Hernando llevara a cabo las tareas de Construcción, Implantación y Aceptación y Mantenimiento del sistema de información.

PSI 2.3: Definición del Plan de Trabajo

Durante la primera semana se estudiara el sistema de información planificando y resolviendo problemas con la empresa contratante. Se debe tener un prototipo terminado para la segunda semana. En la tercera semana se deberán llevar a cabo tareas de desarrollo y se deberá ir terminando la base de datos. Para la cuarta semana el proyecto debe estar terminando y utilizar la semana para resolver errores y cambios de última hora.

PSI 2.4: Comunicación del Plan de Trabajo

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.

PSI 3: ESTUDIO DE LA INFORMACIÓN RELEVANTE

PSI 3.1: Selección y Análisis de Antecedentes

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. 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.

PSI 3.2: Valoración de Antecedentes

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.

PSI 4: IDENTIFICACIÓN DE REQUISITOS

PSI 4.1: Estudio de los Procesos del PSI

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. Se llevaran 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.

PSI 4.2: Análisis de las Necesidades de Información

Se identifican las necesidades de información de cada uno de los procesos analizados. También se realizara un modelo entidad-relación de los campos de la base de datos.

PSI 4.3: Catalogación de Requisitos

La catalogación de requisitos viene indicada mas adelante.

PSI 5: ESTUDIO DE LOS SISTEMAS DE INFORMACIÓN ACTUALES

PSI 5.1: Alcance y Objetivos del Estudio de los Sistemas de Información Actuales

Actualmente la empresa no dispone de ningún sistema de información por lo tanto se debe partir de cero. En caso de que los tuviera, se debe estudiar que características tienen y que objetivos cumplen.

PSI 5.2: Análisis de los Sistemas de Información Actuales

En caso de que tuviera un sistema de información se debe analizar que objetivos cumple y como se deben desarrollar para una mejor implementación. Se debe entrevistar a los usuarios para una mejor implementación y para que los requisitos se cumplan mejor.

PSI 5.3: Valoración de los Sistemas de Información Actuales

Se valoran de forma objetiva los sistemas de información actuales que tuviera la empresa ya que influirá en futuras decisiones de sustitución y/o mejora de los sistemas.

PSI 6: DISEÑO DEL MODELO DE SISTEMAS DE INFORMACIÓN

PSI 6.1: Diagnóstico de la Situación Actual

Se seleccionan los sistemas de información a conservar y se elabora, si procede, la relación de mejoras a realizar en cada uno de ellos para cubrir los requisitos que le afectan.

PSI 6.2: Definición del Modelo de Sistemas de Información

Esta tarea tiene como objetivo representar el conjunto de sistemas de información que da soporte a los procesos de la organización afectados, describiendo sus relaciones e interfaces, así como definir qué sistemas de información actuales se mantendrán con las mejoras propuestas, y qué sistemas de información nuevos cubrirán los requisitos no soportados por los sistemas de información actuales.
Para identificar cada sistema de información nuevo se analizan:

• Los sistemas de información actuales que se conservan

• Los requisitos no cubiertos por los sistemas de información actuales. Se realiza una identificación inicial de sistemas de información, agrupando actividades homogéneas de los procesos de la organización afectados que actúan sobre información común

• Diferentes tipos de sistemas de información (de gestión, de soporte a la toma de decisiones, especiales, etc.)

• Interfaces entre sistemas de información, con el objetivo de minimizarlas

• Tecnología especial requerida, si procede.

Las conclusiones obtenidas de dicho análisis sirven para identificar cada sistema de información nuevo y elaborar el modelo de sistemas de información.

PSI 7: DEFINICIÓN DE LA ARQUITECTURA TECNOLÓGICA

PSI 7.1: Identificación de las Necesidades de Infraestructura Tecnológica

Para poder implementar nuestro sistema de información, la empresa necesitará ordenadores con Windows 7 instalado y de unas características mínimas.
También será necesario el alquiler o compra de un servidor de pequeñas dimensiones para almacenar nuestra base de datos.

PSI 7.2: Selección de la Arquitectura Tecnológica

Nuestro proyecto, es de sencilla utilización por lo que sus usuarios necesitarán un cursillo de aprendizaje de una hora mas o menos.
En caso de que la empresa no realice cambio en sus computadoras se puede adaptar el proyecto a versiones anteriores pero perderá en prestaciones. El servidor para la base de datos seguirá siendo necesario, y en caso de alquiler vía Web se requerirá una conexión a Internet de velocidad medio-alto.

PSI 8: DEFINICIÓN DEL PLAN DE ACCIÓN

PSI 8.1: Definición de Proyectos a Realizar

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.

PSI 8.2: Elaboración del Plan de Mantenimiento del PSI

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 el se han definido.

PSI 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.

Estudio de Viabilidad del Sistema

EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA

EVS 1.1: Estudio de la Solicitud

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.

EVS 1.2: Identificación del Alcance del Sistema

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.

EVS 1.3: Especificación del Alcance del EVS

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.

EVS 2: ESTUDIO DE LA SITUACIÓN ACTUAL

EVS 2.1: Valoración del Estudio de la Situación Actual

En función de los objetivos establecidos para el estudio de la situación actual, y considerando el contexto del sistema especificado en la descripción general del mismo, se identifican los sistemas de información existentes que es necesario analizar con el fin de determinar el alcance del sistema actual.

EVS 2.2: Identificación de los Usuarios Participantes en el Estudio de la Situación Actual

En función del nivel de detalle establecido para el estudio de la situación actual, se identifican los usuarios participantes de cada una de las unidades organizativas afectadas por dicho estudio. Se informa a los usuarios identificados como implicados en el Estudio de la Situación Actual, se solicita su aceptación y se espera su confirmación.

EVS 2.3: Descripción de los Sistemas de Información Existentes

En esta tarea se describen los sistemas de información existentes afectados, según el alcance y nivel de detalle establecido en la tarea Valoración del Estudio de la Situación Actual (EVS 2.1), mediante sesiones de trabajo con los usuarios designados para este estudio. Si se ha decidido describir los sistemas a nivel lógico, y si existe un conocimiento suficiente de los sistemas de información a especificar, puede hacerse directamente, aplicando las técnicas de modelización y siguiendo un método descendente. Si no se dispone del conocimiento suficiente, se construyen los modelos a partir de la descripción del modelo físico, es decir, de forma ascendente.

EVS 2.4: Realización del Diagnóstico de la Situación Actual

Con el fin de elaborar el diagnóstico de la situación actual se analiza la información de los sistemas de información existentes, obtenida en la tarea anterior y se identifican problemas, deficiencias y mejoras. Estas últimas deben tenerse en cuenta en la definición de los requisitos.

EVS 3: DEFINICIÓN DE REQUISITOS DEL SISTEMA

EVS 3.1: Identificación de las Directrices Técnicas y de Gestión

La realización de esta tarea permite considerar los términos de referencia para el sistema en estudio desde el punto de vista de directrices tanto técnicas como de gestión. Si el sistema en estudio pertenece al ámbito de un Plan de Sistemas de Información vigente, éste proporciona un marco de referencia a considerar en esta tarea. Con este fin, se recoge información sobre los estándares y procedimientos que deben considerarse al proponer una solución.

EVS 3.2: Identificación de Requisitos

Para la obtención de las necesidades que ha de cubrir el sistema en estudio, se debe decidir qué tipo de sesiones de trabajo se realizarán y con qué frecuencia tendrán lugar, en función de la disponibilidad de los usuarios participantes.

EVS 3.3: Catalogación de Requisitos

Se analiza la información obtenida en las sesiones de trabajo para la Identificación de Requisitos, definiendo y catalogando los requisitos (funcionales y no funcionales) que debe satisfacer el sistema, indicando sus prioridades. Se incluirán también requisitos relativos a distribución geográfica y entorno tecnológico.

EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIÓN

EVS 4.1: Preselección de Alternativas de Solución

Una vez definidos los requisitos a cubrir por el sistema, se estudian las diferentes opciones que hay para configurar la solución. Entre ellas, hay que considerar la adquisición de productos software estándar del mercado, desarrollos a medida o soluciones mixtas. Dependiendo del alcance del sistema y las posibles opciones, puede ser conveniente realizar inicialmente una descomposición del sistema en subsistemas. Se establecen las posibles alternativas sobre las que se va a centrar el estudio de la solución, combinando las opciones que se consideren más adecuadas.

EVS 4.2: Descripción de las Alternativas de Solución

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.

EVS 5: VALORACIÓN DE LAS ALTERNATIVAS

EVS 5.1: Estudio de la Inversión

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.

EVS 5.2: Estudio de los Riesgos

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.

EVS 5.3: Planificación de Alternativas

En función del análisis de riesgos realizado en la tarea anterior, y para cada una de las alternativas existentes:

• Se determina el enfoque más adecuado para llevar a buen fin la solución propuesta en cada alternativa.

• Se realiza una planificación, teniendo en cuenta los puntos de sincronismo con otros proyectos en desarrollo o que esté previsto desarrollar, según se ha recogido en el catálogo de requisitos.

De esta manera se garantiza el cumplimiento del plan de trabajo en los restantes procesos del ciclo de vida.

EVS 6: SELECCIÓN DE LA SOLUCIÓN

EVS 6.1: Convocatoria de la Presentación

Se efectúa la convocatoria de la presentación de las distintas alternativas propuestas, adjuntando los productos de la actividad anterior con el fin de que el Comité de Dirección pueda estudiar previamente su contenido. Se espera confirmación por parte del Comité de Dirección de las alternativas a presentar.

EVS 6.2: Evaluación de las Alternativas y Selección

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.

EVS 6.3: Aprobación de la Solución

El Comité de Dirección da su aprobación formal o determina la inviabilidad del sistema, por motivos económicos, de funcionalidad como resultado del incumplimiento de los requisitos identificados en plazos razonables o de cobertura de los mismos, etc.

Análisis de requisitos

1. Requisitos en cuanto al mantenimiento de clientes.

   1. Si el cliente se quiere dar de alta, el sistema recoge los datos del cliente (DNI, nombre, apellidos, dirección, teléfono).

      1. El sistema comprueba que el cliente no esta dado de alta.

         1. Si es un nuevo cliente se generara un carné.

      2. El sistema actualiza el almacén de clientes.

   2. Si el cliente informa dar de baja debe presentar el DNI.

      1. El sistema comprueba que el cliente esta dado de alta.

      2. El sistema actualiza el almacén eliminando al cliente.

   3. Si el cliente quiere modificar sus datos, entrega el DNI junto con los datos a modificar.

      1. El sistema comprueba si el cliente existe.

      2. Si el cliente existe, se modifican los datos.

      3. Si no existen, se da de alta como nuevo cliente.

2. Requisitos en cuanto a la gestión de facturas.

   1. Cuando el cliente utiliza los servicios se le hace una factura.

   2. Se establece una relación ente factura-cliente.

   3. El cliente debe abonar la factura en el acto.

3. Requisitos en cuanto a la gestión del animal.

   1. Se realiza el alta del animal.

      1. Se adjuntan sus datos (nombre y edad).

      2. El sistema asigna un identificador para reconocerlo.

      3. Se establece una relación cliente-animal.

      4. El sistema actualiza el almacén animal.

   2. Para dar de baja un animal se facilita el identificador del animal.

      1. Se comprueba que el animal este dado de alta.

      2. Actualización del almacén animal eliminándolo.

   3. Modificación de datos del animal.

      1. Comprobación de la existencia del animal en el almacén.

      2. Se comprueban los diagnósticos en el historial.

      3. Se actualizan los diagnósticos en el historial del animal.

4. Requisitos en cuanto a la gestión de diagnostico:

   1. Con los datos del animal observado y sus síntomas se toma la decisión de que tratamiento utilizar.

   2. Se realiza el informe del tratamiento y se actualiza el almacén diagnostico.

5. Requisitos en cuanto a la gestión de pedidos:

   1. Si el stock de la clínica veterinaria está por debajo de un stock mínimo el sistema generará un pedido.

      1. El auxiliar de veterinario actualizara el stock de los productos de la clínica.

   2. Si el stock del salón de belleza está por debajo del stock mínimo el sistema generará un pedido.

      1. El peluquero actualizara el stock de los productos del salón de belleza.

   3. Si el stock de la tienda de complementos está por debajo de un stock mínimo el sistema generará un pedido.

      1. El dependiente actualizara el stock de los productos tienda de complementos.

6. Requisitos en cuanto a la gestión de reserva:

   1. La secretaria con los datos de la consulta le asigna una fecha para utilizar los servicios de la clínica veterinaria.

   2. Comprueba fecha y hora disponibles.

   3. Graba los datos de la consulta para una determinada fecha y hora en el almacén de consultas.

   4. Se saca un listado de las consultas previstas para el día todas las mañanas.

Modelo Entidad-Relación:

RECURSOS UTILIZADOS

Enunciados y documentación para completar la información: Ubu Virtual / Ingeniería del Software.

Los programas utilizados han sido: Microsoft Office Word 2007, para redactar los informes de las prácticas; la versión portable de la herramienta case Pacestar EDGE Diagrammer (v6.20.2040): para la creación de los modelos Entidad-Relación; otras herramientas CASE; y el Paint, para modificar ciertos retoques en los diagramas de Entidad-Relación.

CONCLUSIÓN

Con la realización de este enunciado nos hemos dado cuenta de todo el personal y todas las funciones y los servicios que implica regentar un centro de animales.