jueves, 31 de mayo de 2018


Sistema de Avería para PARQUE DE ATRACCIONES


La empresa “DIVIERTIDO”, tiene varios parques de atracciones repartidos por el País. Lo que más preocupa a esta empresa es la seguridad en algunas de las atracciones, ya que un error mecánico podría producir daños materiales y humanos que plantearían serios problemas para la empresa. Hoy por hoy sólo es posible detectar fallos en las atracciones, cuando los operarios encargados realizan actividades de mantenimiento. La empresa quiere informatizar sus parques de atracciones y para ello ya ha decidido poner en marcha un proyecto piloto cuyo objetivo será el de dotar a uno de sus parques de atracciones de un sistema de detección automática de fallos en las atracciones. En un primer momento se va a preparar el sistema para gestionar la noria (rueda de chicago) y la montaña rusa. La noria tiene una serie de vehículos dotados cada uno de ellos de un detector gracias al cual se sabe en cada momento si el vehículo está suficientemente bien anclado a la estructura metálica de la noria. Si en un momento determinado se detectara pérdida de anclaje, el correspondiente vehículo se lo comunicaría a la Central Receptora de Averías (CRA) y también a la atracción de la que forma parte dicho vehículo, así en la próxima parada de dicha atracción se tendrá constancia de que uno de sus vehículos ha solicitado revisión. Por su parte, en la montaña rusa cada vagón está dotado de igual modo de un detector de anclaje con el vagón que lleva detrás (en el caso de llevarlo). Cada vagón detecta si existe suficiente anclaje con el vagón posterior y en caso de falta de anclaje avisa a la CRA y a la atracción, en este caso la montaña rusa. Cuando la CRA recibe un aviso, en el que se le indica el vehículo o vagón con posible avería y la atracción de que se trata, busca inmediatamente un operario de mantenimiento disponible. En caso de no haber ninguno libre, informa al componente en cuestión de que su petición no puede ser atendida, así dicho componente emitirá una señal de solicitud de revisión hasta que su petición le sea satisfecha. Como cada operario de mantenimiento cobra un extra en función del número de averías que atiende al mes, cada uno tiene asignado mensualmente un dispositivo gracias al cual recibe las posibles averías a atender, independientemente de en qué zona del parque se encuentre. Cuando la CRA demanda la revisión de una posible avería y encuentra un operario de mantenimiento libre le manda un mensaje indicándole la calle del parque en la que se encuentra la atracción y el número de vehículo o vagón con posible avería. Automáticamente, el dispositivo del operario pasa a indicar que ese operario se encuentra ocupado atendiendo una posible avería. Cuando el operario ha terminado de supervisarla, indica a su dispositivo que ha quedado libre para la siguiente petición de avería que reciba. A su vez dicho dispositivo informa a la CRA y al componente revisado. Dicho componente avisará a su atracción de que la operación de mantenimiento solicitada ha terminado para que ésta lo tenga en cuenta a la hora de poner la atracción en marcha de nuevo. Además, el sistema tendrá que ser capaz de contabilizar las personas que entran y salen de una atracción, con el fin de controlar dos cosas; en primer lugar, que no entren más personas de las que la atracción es capaz de sostener y, en segundo lugar, que todo el mundo abandone la atracción una vez finalizado cada viaje. El controlador de arranque y parada de la atracción puede recibir un mensaje indicando que la atracción está llena, para que inicie las labores de puesta en marcha de la atracción; dicho mensaje puede provenir del torniquete de entrada que detecta cuando se produce la ocupación máxima de la atracción, o bien del propio operario que vigila la atracción siempre que aún no estando llena no hay más personas esperando para subir y él considera que es tiempo suficiente como para que se ponga en marcha. Una vez que el dispositivo de parada y arranque de la atracción detecta que la atracción está detenida, le envía al torniquete de salida un mensaje para que se prepare para que la gente pase por él. El torniquete de salida sabe el número de personas que hay en la atracción gracias al torniquete de entrada, así sabe el número de personas que se tienen que bajar de la atracción. Cuando el torniquete de salida determina que el número de personas que han abandonado la atracción es igual al número de ellas que entró, envía al torniquete de entrada un mensaje para que ponga a cero el contador de personas en la atracción y además se libere y muestre un indicador verde para que la gente pueda tomar asiento en la atracción. Si pasados cinco minutos desde que la atracción se paró el torniquete de salida no ha liberado al torniquete de entrada, es indicativo de que alguien se ha quedado dentro y es necesario entrar a buscarlo. Cuando el torniquete de entrada recibe, del torniquete de salida, el mensaje de liberarse, primero consulta a la atracción si tiene alguna avería pendiente. Esto se reflejará en la atracción cuando uno o varios de los vehículos o vagones soliciten reparación. La atracción lleva un contador de averías pendientes de manera que sólo en el caso en que este contador esté a 0 el torniquete de entrada se pondrá verde para que entren los usuarios. En caso contrario permanecerá en amarillo, indicativo de estar esperando reparación.


Diagrama de Clases en Enterprise Architect








Diagramas de Estados en Enterprise Architect





martes, 15 de mayo de 2018


Sistema Gestión de Personal Bancario
Se trata de diseñar una base de datos para la gestión del personal de una entidad bancaria determinada que dispone de muchos empleados y de una amplia red de agencias. La siguiente descripción resume los requisitos de los usuarios de la futura base de datos:
           a)      Los empleados se identifican por un código de empleado, y también deseamos conocer su DNI, su NSS, su nombre y su apellido. Será importante registrar su ciudad de residencia, considerando que hay ciudades donde no reside ningún empleado. 
           b)      Interesa saber en qué ciudades están ubicadas las diversas agencias de la entidad bancaria. Estas agencias bancarias se identifican por la ciudad donde están y por un nombre que permite distinguir las agencias de una misma ciudad.
             c)       Se quiere tener constancia del número de habitantes de las ciudades, así como de la dirección y el número de teléfono de las agencias. Se debe considerar que la base de datos también incluye ciudades donde no hay ninguna agencia.
            d)      Un empleado, en un momento determinado, trabaja en una sola agencia, lo cual no impide que pueda ser trasladado a otra o, incluso, que vuelva a trabajar en una agencia donde ya había trabajado anteriormente. Se quiere tener constancia del historial del paso de los empleados por las agencias.
             e)      Los empleados pueden tener títulos académicos (aunque no todos los tienen). Se quiere saber qué títulos tienen los empleados.
            f)   Cada empleado tiene una categoría laboral determinada (auxiliar, oficial de segunda, oficial de primera, etc.). A cada categoría le corresponde un sueldo base determinado y un precio por hora extra también determinado. Se quiere tener constancia de la categoría actual de cada empleado, y del sueldo base y el precio de la hora extra de cada categoría.
           g)      Algunos empleados (no todos) están afiliados a alguna central sindical. Se ha llegado al pacto de descontar de la nómina mensual la cuota sindical a los afiliados a cada central. Esta cuota es única para todos los afiliados a una central determinada. Es necesario almacenar las afiliaciones a una central de los empleados y las cuotas correspondientes a las diferentes centrales sindicales.
            h)      Hay dos tipos de empleados diferentes:
• Los que tienen contrato fijo, cuya antigüedad queremos conocer.
• Los que tienen contrato temporal, de los cuales nos interesa saber las fechas de inicio y finalización de su último contrato.
i)  Si un empleado temporal pasa a ser fijo, se le asigna un nuevo código de empleado; consideraremos que un empleado fijo nunca pasa a ser temporal. Todo lo que se ha indicado hasta ahora (traslados, categorías, afiliación sindical, etc.) es aplicable tanto a empleados fijos como a temporales.
j)   Los empleados fijos tienen la posibilidad de pedir diferentes tipos preestablecidos de préstamos (por matrimonio, por adquisición de vivienda, por estudios, etc.), que pueden ser concedidos o no. En principio, no hay ninguna limitación a la hora de pedir varios préstamos a la vez, siempre que no se pida más de uno del mismo tipo al mismo tiempo. Se quiere registrar los préstamos pedidos por los empleados, y hacer constar si han sido concedidos o no. Cada tipo de préstamo tiene establecidas diferentes condiciones; de estas condiciones, en particular, nos interesará saber el tipo de interés y el periodo de vigencia del préstamo.

Diagrama de Clases:



martes, 10 de abril de 2018

Proyecto Agil


Taller Ejercicio Colaborativo – Proyecto Ágil
Nombre del Equipo: Pepe millonario

Roles:
– Cliente: Paredes, Saul.
– Dueño del Producto: Mancedo, Joaquin.
– Scrum Master: Aquino, Yamila.
– Geek/Equipo: Morales, Natalia.

Historias de Usuario:
ID 01 – Título: Enemigos en oleadas
Estimación: 4 horas
Valor: 70
Descripción: Como cliente deseo que los enemigos estén formados por oleadas.
Dependencia: -
Pruebas:
1. El número de aliens que conforma la oleada ira creciendo conforme se logre pasar cada oleada.
2. Luego de cada oleada la dificultad deberá aumentar.

ID 02 – Título: Comportamiento del Enemigo
Estimación: 2 horas
Valor:90
Descripción: Como desarrolador deseo que los aliens enemigos se muevan de manera aleatoria.
Dependencia: 01
Pruebas:-

ID 03 – Título: Jefe por cada oleada
Estimación: 3 horas
Valor: 70
Descripción: Como cliente deseo que luego de cada oleada de enemigos haya un jefe, el cual podrá atacar al jugador y tendrá más resistencia que los enemigos normales.
Dependencia: 01, 02
Pruebas:
1. El jefe deberá atacar al jugador.
2. El jefe tendrá más vida que los enemigos normales.





ID 04 – Título: Vida del jugador
Estimación: 3 horas
Valor: 40
Descripción: Como cliente deseo que el jugador tenga vidas.
Dependencia: -
Pruebas:
1. El jugador debe empezar con 1 vida.
2. El número de vida del jugador puede aumentar.
3. Luego de cada disparo que recibe el jugador pierde una vida.

ID 05 – Título: Drop
Estimación: 5 horas
Valor: 70
Descripción: Como cliente deseo que el jefe pueda soltar vida para el jugador.
Dependencia: 01, 03, 04
Pruebas:
1. Luego de cada 2 oleadas pasadas el próximo jefe de la siguiente oleada pueda soltar o no una o más vidas.

ID 06 –Titutlo: Movilidad del jugador
Estimación: 2 horas
Valor: 70
Como desarrollador deseo que la nave se mueva libremente manejando las teclas de dirección y poder disparar con la tecla espaciadora.
Dependencia: -
Pruebas:
1.    La nave no puede salir fuera del mapa.


Tareas a realizar por historia de usuarios más importantes
Id Historia Usuario

06
Titulo Historia Usuario

Movimiento del jugador
Tareas

Identificación
Descripción

01
Moviendo del jugador libre de izquierda a derecha.
02
El jugador podrá utilizar las teclas de dirección para moverse (izquierda – derecha) y la barra espaciadora para atacar y con el botón Esc poner pausa.


Id Historia Usuario

01
Titulo Historia Usuario

Enemigos en oleadas
Tareas

Identificación
Descripción

01
Configurar cantidad aliens por oleadas.
02
Configurar la cantidad de aliens que salgan en grupos de 4 a 8, ya que si saliera toda la oleada no seria justo.
03
Configurar la apriencia de los aliens comunes, estos deben ser diferentes a los jefes de cada oleada

Maqueta y/o modelo prototipo
El modelo lo hice con photoshop cc 2017, es un programa Edición y Retoque de imágenes y/o Fotografías.
La cual nos permite:
§  Crear gráficos de vanguardia.
§  Efectos especiales.
§  Gráficos para un sitio Web.
§  Anuncios impresos.
§  Etc









viernes, 6 de abril de 2018

NDT (Navigational Development Techniques)


NDT (Navigational Development Techniques), es una propuesta englobada en el paradigma de la ingeniería guiada por modelos que se mueve dentro del entorno de la Ingeniería Web. La Ingeniería Web es una rama de la Ingeniería del Software que define procesos técnicas y modelos específicos para el entorno de la web. Sin embargo, actualmente la metodología NDT puede ser aplicada para la especificación de cualquier tipo de sistema software,una técnica para especificar, analizar y diseñar el aspecto de la navegación en aplicaciones web. 

 El flujo de especificación de requisitos de NDT está fuertemente relacionado con la Ingeniería de Requerimientos, la cual comprende la definición del comportamiento del sistema, es decir, de lo que se desea desarrollar o producir. Su objetivo principal es la definición clara, consistente y compacta de las especificaciones correctas que definen el comportamiento del sistema con el fin de minimizar al máximo los problemas que se presentan en el desarrollo de software y que tanto afectan a la calidad del producto final.

Este proceso comienza con la fase de captura de requisitos y estudio del entorno. Para ello, plantea el uso de técnicas(IngReq)  como las entrevistas o el brainstorming (tormenta de ideas) y JAD(Joint Application Design). Tras esta fase, se propone la definición de los objetivos del sistema. En base a estos objetivos, el proceso continúa definiendo los requisitos que el sistema debe cumplir para cubrir los objetivos marcados. NDT clasifica los requisitos en:


  •    Requerimientos de almacenamiento de información, que definen qué información se va a manejar en el sistema y cómo se relacionan entre sí. NDT permite también definir nuevas naturalezas de datos que se vayan a utilizar en el sistema.


  •   Requerimientos de almacenamiento de información de actores, en los que se definen los roles que podrán interactuar en el sistema y las relaciones que se puede producir entre ellos.


  •    Requerimientos de almacenamiento de información funcionales, que permitirán definir la funcionalidad del sistema.


  •     Requerimientos de interacción, representados mediante:
- Frases, que recogen cómo se va a recuperar la información del sistema utilizando un lenguaje especial denominado BNL (Bounded Natural Language) (Brisaboa, Penabad, Places & Rodríguez, 2001).
- Prototipos de visualización, que representan la navegación del sistema, la visualización de los datos y la interacción con el usuario.

  • Requerimientos no funcionales, que recogerán otros requisitos del sistema.

Una vez validados estos requisitos, el proceso de NDT propone generar tres modelos:

  •  El modelo conceptual, que representa mediante un diagrama de clases la estructura estática del sistema.
  •  El modelo de navegación, que representa mediante un conjunto de diagramas de clases la forma en que se podrá navegar en el sistema.
  •  El modelo de interfaz abstracta, que mediante un conjunto de prototipos evaluables permitirá mostrar cómo se va a interactuar con el sistema.

 La propuesta ofrece una plantilla para cada tipo de requisito, lo que permite describir los requisitos y objetivos de una forma estructurada y detallada.
La característica más destacable del proceso propuesto por NDT es que el paso de especificación de requisitos a estos modelos se hace de una manera sistemática e independiente.
Es una manera sistemática porque NDT define algoritmos que indican cómo conseguir cada modelo a partir de la definición de requisitos.


Ventajas de NDT 

ü  NDT se puede utilizar en el entorno empresarial de forma satisfactoria. Hoy en día, un elevado número de empresas en España trabajan con NDT en el desarrollo de software. 

ü  NDT permite que los usuarios finales puedan validar los modelos generados.

Desventajas de NDT 

ü  Una de las desventajas de esta metodología está totalmente apoyada por un conjunto de herramientas propietario, agrupado en NDT Suite.

ü  Algunas de las subfases al poseer similitud entre ellas se puede tener información redundante.

Resultados de NDT

La aplicación de NDT genera tres resultados finales: 

ü  El documento de requisitos del sistema, donde se detallan los objetivos y requisitos que 
debe cumplir el sistema. 

ü  El documento de análisis del sistema, donde se recogen el modelo conceptual y el modelo de navegación del sistema. 

ü  Los prototipos del sistema, que muestran la estructura de la interfaz abstracta del sistema.



HERRAMIENTA:

NDT-SUITE
NDT-Tools, el soporte de herramientas de la metodología NDT, ha tenido que evolucionar para ser una propuesta útil en proyectos reales, dado que sólo cubría las fases de ingeniería de requisitos y análisis. Estas razones impulsaron al Grupo de Investigación Ingeniería Web y Testing Temprano a elaborar NDT-Suite. Esta nueva herramienta soporta las fases de requisitos, análisis, diseño, construcción e implantación, pruebas y mantenimiento. NDT-Suite está integrada por los diversos componentes, entre ellos, NDT-Profile, NDT-Quality y NDT-Driver.
NDT-Suite
Es un kit de herramientas NDT desarrollado utilizando software libre: tecnología Java. Está disponible para inglés y español.
Proporciona soporte para todo el ciclo de vida NDT.