ANALISIS DE SISTEMAS

FASE GRUPAL II

PRESENTADO A:
EDITH NANCY ESPINEL BERNAL

PRESENTADO POR:
OSCAR ANTONIO CASTILLO PEREZ COD 3167508
JUAN CARLOS CEDIEL RODRIGUEZ COD 1070978271
WILMER ROMINGUER CORTES GONZALEZ COD 107096240

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

OCTUBRE 16 DE 2015
OBJETIVOS
Objetivo General

- Conocer los diferentes sub-problemas que albergan un problema concreto ya que

este puede ser efectuado en diferentes áreas principales de la empresa.

Objetivos Específicos

- Verificar cada función que realiza los empleados, reconociendo así la raíz del
problema.
- Aplicar soluciones a problemas segundarios que afecten las diferentes áreas de
la aerolínea.
Parte 1: Listado de Falencias Citar al menos 10 Falencias

1. Falta de reconocimiento
- Equipaje mal marcado por afanes o falta de tiempo
- Poca información requerida a la hora de transbordar el equipaje

2. Personal no calificado
- Mala selección del personal a la hora de contratar
- Falta de una capacitación adecuada
- Falta de motivación

3. Perdida del equipaje

- Equipaje perdido o que no se tiene información de su paradero
- Mala manipulación del equipaje
- Robo

4. Falta de organización
- Personal adecuado en áreas que controlen el funcionamiento de la empresa
- Mecanismos de control de personal

5. Falta de comunicación
- El personal no solicita la información necesaria para así marcar el equipaje
- Falta de comunicación entre el personal

6. Falta de una Organización en la bodega

- Mala distribución y almacenamiento
- Mala manipulación a la hora de distribuir el equipaje a los diferentes destinos

7. Falta de organismos que ayuden al control

- Equipaje no verificado a la hora de ser abordado al aeropuerto
- Falta de verificación en el avión
8. Congestión
- Falta de la capacidad para el almacenamiento y el transporte de su equipaje
- Falta de personal para reducir gastos

9. Tiempos
- Desorden en los tiempos de trasporte y distribución
- Falta de mecanismos de transporte para hacer más eficaz el transporte

10. Falta de organismos de verificación

- Falta de un aplicativo donde se verifique en tiempo real la ubicación del
equipaje

Parte 2: Requerimientos funcionales y no funcionales

a. Realizar la fase de anticipación de requerimientos

“En los aeropuertos se presenta un problema con él envió del equipaje a los diferentes
destinos nacionales e internacionales, que conduce a que el equipaje se pierda, se
dirija a otro destino o no se envié. Esto genera mal ambiente al pasajero y un mal
nombre al aeropuerto y por supuesto a la aerolínea involucrada.”

El sistema Usado por el Aeropuerto es un sistema de toma de datos manual, el cual se

realiza llenando unos formatos.

Estos formatos son una buena base tangible al momento realizar algún tipo de auditoria,
pero no representan una facilidad al momento de realizar una consulta de un equipaje
porque se emplea demasiado tiempo en encontrar el documento para cotejar la
información.

Los equipajes son almacenados en el área de bodega por sectores sin ningún tipo de
control. Esto representa que se ubiquen erróneamente a un área de carga que no
corresponda, sin el suficiente personal que ayude a agilizar y a controlar el
almacenamiento
Al momento de cargue en el avión no realizan ningún tipo de control para garantizar él
envió correcto del equipaje.

 Con base a los análisis anteriores  hemos determinado como Analistas las falencias
del problema que el Aeropuerto presenta, hemos detectado 10 falencias, al estudiar
estas falencias determinamos una falencia  específica la cual encerraría solución a
varias de ellas.

 La falencia principal o falla que presenta el sistema en el aeropuerto se debe a la falta
de un software que permita tomar datos en tiempo real de los equipajes de los usuarios
que viajan o los equipajes que son enviados por encomienda, dichos datos serian:

Nombre usuario

Teléfono

Destino

Numero de vuelo

Fecha de vuelo

Hora de vuelo

Características del equipaje

Peso

Con el fin de generar un código de barras único a ese equipaje.

Dicho código de barras se colocaría en cada uno de los equipajes.

Se implementaría unas terminales en el área de carga con el fin de ESCANEAR  el

código de barras del equipaje para verificar de manera precisa, esto con el fin de
garantizar que el equipaje corresponda al vuelo, hora, fecha y destino correcto.
b. Realizar la fase de determinación de requerimientos

Al realizar el análisis de la infraestructura informática con que cuenta el aeropuerto en

el área de recepción y carga vemos que utilizan dispositivos obsoletos, razón por la cual
detallamos luego de haber realizado la Anticipación de Requerimientos los
requerimientos que se necesitarían para llevar a cabo dicha solución al problema
planteado.

Área de Recepción

6 Estaciones de cómputo las cuales estarán conformadas por:

 Pantallas de 22”
 CPU Alto Rendimiento
 Teclado
 Mouse
 Impresora códigos de barras ZEB-PL2824 Epson

El sistema a emplear de códigos de barras será SSCC (Código Seriado de Contenedor de

Embarque) es un número de 18 dígitos, asignado en forma secuencial. Identifica una
unidad logística de cualquier tipo. El creador de la unidad logística es quien asigna el
SSCC. Este sistema es con el fin de generar códigos de barras secuenciales y únicos, así
cada cliente tendrá un código único para su equipaje que contiene todos sus datos
personales. 

Área de Carga

Se dispondrán de una terminal por cada hangar de carga que constara de:

- Motorola Symbol MC3190-RL4S04E0A

Esta pistola tiene integrada varias funciones, además tiene una pantalla donde
directamente sin la ayuda de un computador podemos verificar si efectivamente ese
equipaje corresponde a ese avión.
 Todas las terminales estarán conectadas a un servidor Principal, esto con el fin de
disponer en cualquier momento de la información de cualquier equipaje, se recomienda
una buena conexión a internet para no formar lactancia en el sistema de verificación.

C. Realizar la fase de especificación de requerimientos clasificados en funcionales y

no funcionales.

Presentar al menos 10 requerimientos. 7 Funcionales y 3 no funcionales

Obtener requisitos: a través de entrevistas o comunicación con clientes o futuros

usuarios, para saber cuáles son sus expectativas.

Analizar requisitos: detectar y corregir las carencias o falencias comunicativas,

transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones
apropiadas para ser tratados en el diseño.

Documentar requisitos: igual que todas las etapas, los requisitos deben estar
debidamente documentados.
Verificar los requisitos: consiste en comprobar la implementación de los
requerimientos.

Validar los requisitos: comprobar que los requisitos implementados sean funcionales
para lo que inicialmente se construyó el producto.

Técnicas principales

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de
habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre
la gente, así que es importante identificar a todos los actores involucrados, considerar
sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los
analistas pueden emplear varias técnicas para obtener los requisitos del cliente.
Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con
grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y
utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de
estos métodos para establecer los requisitos exactos de las personas implicadas, para
producir un sistema que resuelva las necesidades del negocio.

Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que
se relacionará con el sistema, sino a una selección de personas que represente a todos
los sectores críticos de la organización, con el énfasis puesto en los sectores más
afectados o que harán un uso más frecuente del nuevo sistema.

Forma de contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los

requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo
plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del
sistema hasta determinar los objetivos críticos del funcionamiento interno que luego
darán forma a los comportamientos apreciables por el usuario. Luego, se establecen
formas de medir el progreso en la construcción, para evaluar en cualquier momento qué
tan avanzado se encuentra el proyecto
Prototipos y Casos de uso

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el

producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y
rectificar algunos aspectos antes de llegar al producto terminado.

Un caso de uso es una técnica para documentar posibles requisitos, graficando la

relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema
aparece como una caja negra, y sólo se representa su interacción con entidades externas,
permite omitir dichos aspectos y determinar los que realmente corresponden a las
entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los
usuarios y los desarrolladores, mediante la prueba temprana de prototipos para
minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica
se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho
trabajo por hacer para completar el diseño final.

Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el
tiempo” al comenzar otra vez.

Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de

usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la

interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del
negocio.

Identificación de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de un
tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los
implicados para que se obtengan y depuren sus requisitos de la forma más fidedigna
posible. Entre las personas implicadas hay que considerar:

Organizaciones que integran la organización del analista que está diseñando el sistema

Organizaciones o sistemas de respaldo

Dirección Usuarios.
CONCLUSION
Podemos concluir que hay varias falencias ligadas a un problema concreto, estas
falencias alteran el orden y el funcionamiento de otras áreas administrativas de la
empresa, lo cual genera más problemática desordenando así más la compañía y dando
un mal nombre a la empresa

Se busca reconocer todos esos factores para así plantear una solución general y así
corregir previamente todas las áreas afectadas y dar un mejor servicio y mejorar el
nombre y funcionamiento de la empresa
REFERENCIAS BIBLIOGRAFICAS

http://www.slideshare.net/sarahbf/presentacion-cap-3-21263708?
ref=http://campus03.unad.edu.co/ecbti02/mod/lesson/view.php?id=4821&pageid=409
http://www.slideshare.net/SergioRios/unidad-13-analisis-de-requerimientos?
ref=http://campus03.unad.edu.co/ecbti02/mod/lesson/view.php?id=4821&pageid=409

Ingeniería de Software Orientada a Objetos con UML, Java e Internet

Alfredo Weitzenfeld. México City: Cengage Learning, 2005. p197-199. COPYRIGHT
2005 Cengage Learning Editores, S.A. de C.V.