UNIVERSIDAD TECNOLGICA DEL PER
FACULTAD DE INGENIERA INDUSTRIAL Y DE SISTEMAS
DISEO DE UN SISTEMA DE INFORMACIN PARA LA MEJORA DEL SERVICIO DE
UNA EMPRESA DE TRANSPORTE PBLICO EN LIMA METROPOLITANA
Presentado por:
CIUDAD GAYOSO, Brayan Junior
VERASTEGUI AVILA, David Orlando
Asesor:
Msc. KrugerSarapura Yupanqui.
LIMA
2012
INTRODUCCIN
En la actualidad, el servicio que ofrece las empresas de
transporte pblico en la ciudad de Lima Metropolitana, se ha vuelto
deplorable debido a la mala gestin de la empresa para controlar
este servicio y el mal desempeo por parte de los conductores, donde
los principales perjudicados son los peatones por el uso de los
vehculos de transporte de estas empresas, y por la dependencia
hacia estos como su principal medio de transporte. Por ende, la
decisin de buscar otros medios se ha vuelto comn para la necesidad
de movilizacin hacia un destino fijado por parte de los
usuarios.
Por ello esta investigacin est dirigida a mejorar el servicio
brindado a los peatones en la ciudad de Lima Metropolitana,
mediante el diseo de un sistema que ayude a estas empresas a
controlar la calidad de su servicio, as como a los conductores, a
evitar las sanciones que reciben por el incumplimiento de las
normas laborales regidas por estas empresa; y principalmente a los
peatones, dndoles una mayor satisfaccin al mejorar este
servicio.
LISTA DE FIGURAS
Figura1: Linea de Autobuses de EMT10
Figura2: Interfaz del mapa interactivo "Navega por Madrid"11
Figura3: Diseo del sistema automatizado de Transporte13
Figura 4: Comunicacin entre el navegador y el servidor Web16
Figura 5: Arquitectura del www19
Ilustracin 6: Arquitectura Multinivel20
Figura 7: Uso del Motor de PHP22
Figura 8: En Julio ingresaron 56 buses nuevos a la ruta26
Figura 9: Tramo 1, red bsica de tramo28
Figura 10: Interfaz del mapa interactivo "Navega por
Madrid"29
Figura 11: Interacciones entre etapas de la Metodologa RUP50
Figura 12: Ejemplo de la aplicacin del Mtodo Estadstico61
INDICE GENERAL
INTRODUCCIN2LISTA DE FIGURAS31.FORMULACIN DEL
PROBLEMA71.1.Planteamiento del Problema71.2.Antecedentes de
Solucin81.2.1.Nacionales81.2.2.Internacionales91.3.Propuesta de
Solucin131.4.Alcance de la
Propuesta141.5.Justificacin141.6.Objetivos151.6.1.Objetivos
General151.6.2.Objetivos Especficos152.MARCO
TERICO152.1.PROGRAMACIN WEB152.1.1.Protocolo HTTP (Protocolo de
Transferencia de Hipertexto)152.1.2.Comunicacin entre el navegador
y el servidor web162.1.3.Arquitectura del
WWW182.1.4.HTML192.1.5.Desarrollo de aplicaciones
web202.1.5.1.Lenguajes de programacin del lado del
cliente202.1.5.2.Lenguajes de programacin del lado del
servidor212.1.5.3.Metodologas para el desarrollo de aplicaciones
web222.1.5.3.1.Aspectos de seguridad.242.2.MARCO
REFERENCIAL242.2.1.Antecedentes:252.2.1.1.Nacionales252.2.1.2.Internacionales282.3.MARCO
NORMATIVO302.3.1.Polticas para la elaboracin de
sistemas302.3.2.Normas para la elaboracin de
Sistemas332.3.2.1.Objetivo:332.3.2.2.Normas
Generales:332.3.2.3.Normas para el anlisis de
sistemas:352.3.2.4.Normas para el diseo de sistemas352.3.2.5.Normas
para la programacin y documentacin de sistemas362.3.2.6.Normas para
la implantacin de sistemas y capacitacin372.3.2.7.Normas para el
mantenimiento de sistemas382.3.3.Polticas Generales De Seguridad
Informtica392.3.3.1.Del Departamento de Redes y
Comunicaciones392.3.3.2.De los Administradores de red402.3.3.3.Del
Departamento de Soporte Tcnico412.3.3.4.Del Personal412.3.4.Normas
especficas para la seguridad de informacin422.3.4.1.Del Acceso a la
Informacin422.3.4.2.De la Proteccin Especial de la
Informacin442.3.4.3.De la Integridad de la
Informacin442.3.4.4.Seguridad de la Informacin462.4.METODOLOGA
RUP462.4.1.UML472.4.2.Caractersticas del RUP472.4.3.Descripcin de
las Fases502.4.4.Beneficios de la Metodologa Orientada a
Objetos552.4.5.Ventajas de la Metodologa Orientada a
Objetos562.5.HIPOTESIS562.5.1.VARIABLES
INDEPENDIENTES572.5.2.VARIABLES DEPENDIENTES573.MARCO
METODOLGICO573.1.Metodologa para el anlisis y diseo de la
solucin573.1.1.Fase de Inicio573.1.2.Fase de
Elaboracin583.2.Metodologa para el estudio de factibilidad
(viabilidad) de la solucin593.2.1.Investigacin
Cualitativa593.2.1.1.Universo593.2.1.2.Muestra593.2.1.3.Tcnica603.2.1.4.Instrumento603.2.1.5.Mtodo
de recoleccin de datos603.2.2.Impacto Econmico613.2.3.Viabilidad
Legal614. ASPECTOS ADMINISTRATIVOS614.1. ndice Preliminar de
Tesis...............................614.2. Presupuesto y Cronograma
de Actividades ...644.2.1. Presupuesto.........644.2.2
Cronograma.....65REFERENCIAS67
1. FORMULACIN DEL PROBLEMA
1.1. Planteamiento del Problema
A lo largo de nuestra vida hemos estado en contacto con diversos
problemas sociales, polticos, econmicos, laborales, etc.; entre los
cuales uno de los principales es el tema del transporte. Hoy en da
el desplazamiento mediante el uso del transporte pblico urbano en
la ciudad de Lima Metropolitana ha afectado a la poblacin limea,
debido a que el tamao del parque automotor de Lima Metropolitana es
actualmente ms de 1.5 millones de vehculos y est creciendo a una
tasa de 15% anual[footnoteRef:1], el 45,9% de capitalinos est
fastidiado por el ineficiente servicio de transporte pblico
limeo[footnoteRef:2], produciendo incomodidad y malestar en los
peatones que son los ciudadanos. [1:
http://blog.pucp.edu.pe/item/159841/el-problema-del-transporte-urbano-en-lima-metropolitana]
[2: Diario la Repblica,
http://www.larepublica.pe/17-01-2012/inseguridad-y-transporte-los-principales-problemas-de-nuestra-capital]
Cuando se espera un bus para desplazarnos de un punto a otro,
muchas veces decidimos el camino o ruta para lograr esto, y tras su
seleccin nos hacemos diversas preguntas: A qu hora pasar el bus?,
Cunto ms debo esperar?, Pagar ms de lo que pago?, Cunto puedo
gastar?, as como otras interrogantes; todo esto debido a la gran
incertidumbre del servicio que brinda el transporte pblico.
Dentro de esta problemtica que se ha ido alimentando en el
transcurso del tiempo, hay factores que estn directamente
relacionados con el usuario (peatn), los cuales son el tiempo pero
en la encuesta realizada en el 2011 el 21,5% de limeos considera
que se demora menos tiempo[footnoteRef:3] para movilizarse por la
ciudad que en el 2010 pero no todos los limeos son acreedores de
estos beneficios, otro de ellos es el sistema de tarifa y los
horarios de servicio. El factor tiempo es el ms crtico debido a que
muchos de los usuarios (peatones) pierden demasiado tiempo ya sea
esperando el bus o estando en ellos; y esto ha venido siendo una
variable aleatoria por el hecho de que estas lneas de transporte
estn sometidos a diferentes agentes externos lo cual como
consecuencia originan la importante necesidad de que los usuarios
opten por tomar otras alternativas que puedan confrontar este
factor la cual permita que el tiempo que se invierta sea el menor
posible. [3: Diario la Repblica,
http://www.larepublica.pe/17-01-2012/inseguridad-y-transporte-los-principales-problemas-de-nuestra-capital]
En las diferentes toma de decisiones de los usuarios, el tiempo
de espera, que es el factor ms considerado, seguido del tiempo de
viaje son los ms contribuyentes para elegir la opcin correcta ms
factible en relacin a las diferentes situaciones o realidades de
los ciudadanos ya que consideramos la posibilidad que en muchos de
estas alternativas se llegue a la utilizacin de ms recursos,
especialmente el econmico, lo cual no est en la contingencia de
todos.
Otro de los factores es el ya mencionado sistema tarifario, por
lo que en muchas situaciones los usuarios creen que el valor de su
respectivo viaje ya est determinado, pero varias veces se dan con
la sorpresa de que este valor ha aumentado ya sea por la viveza de
muchos cobradores o conductores o por factores relacionados al alza
del combustible.
El presente trabajo est orientado a la reduccin del tiempo de
espera de los buses de los cuales el 22%[footnoteRef:4] de limeos
prefieren usar dicho medio de transporte, as como el de tener un
mejor sistema tarifario permitiendo una mejor relacin
usuario-transporte, y adems contribuya a una mejora en cuanto al
servicio de transporte. [4: Diario la Repblica,
http://www.larepublica.pe/17-01-2012/inseguridad-y-transporte-los-principales-problemas-de-nuestra-capital]
1.2. Antecedentes de Solucin
1.2.1. Nacionales
Aos atrs, el transporte urbano no era un problema crtico el cual
hoy en da se enfoca como uno de los principales problemas de Lima
Metropolitana, el trfico vehicular era liviano, el tiempo de espera
y viaje era mucho menor al de ahora, debido a que Lima era un lugar
poco centralizado.
A partir de la dcada de los 90, el Per se ha visto afectado por
el incremento de la tasa de desempleo que gnero que los
desempleados encontraran en el transporte pblico una manera de
poder subsistir, generando actualmente una sobre oferta del 40%, ya
sean combis, mnibus o custers. En consecuencia, el trfico en Lima
Metropolitana se ha vuelto muy catico y denso, y eso se observa
principalmente en horas especficas, que es cuando se generan las
congestiones vehiculares, tambin cabe mencionar que entre Lima y
Callao se concentra el 69% del parque automotor del Per.
Actualmente, se han desarrollado diversos proyectos orientados a
la disminucin del trfico vehicular en Lima y otros a la creacin de
nuevas vas alternas para el transporte como Va Expresa, By Pass; o
creacin de nuevas modalidades de transporte como el Metropolitano o
el Tren Elctrico, pero la gran mayora no han sido soluciones
factibles o deseables, ya que no se ha visto un cambio notorio;
adems de la falta de cultura y atencin de las ciudadanos, policas,
municipalidades; los cuales no respetan las normas vehiculares y
los principales lugares para abordar un bus, el cual son los
paraderos.
El Metropolitano y el Tren Elctrico son dos proyectos que se
implementaron como una opcin a los ciudadanos para movilizarse de
una manera ms rpida, estos cuentan con un mejor nivel de servicio
para los usuarios aunque vienen teniendo problema con la frecuencia
de los buses( en el caso del Metropolitano), adems estas no llegan
a toda la poblacin a pesar que mucha gente los utiliza, an hay una
gran porcentaje de la poblacin que sigue utilizando el transporte
pblico, lo que nos da a entender que estos proyectos no fueron
diseados para mejorar el tema del trfico vehicular, sino como
solucin alternativa de trasladarse evitando el trfico
vehicular.
1.2.2. Internacionales
La Empresa Municipal de Transportes de Madrid es una sociedad
annima, propiedaddel Ayuntamiento de Madrid, encargada de la
prestacin del servicio de transporte pblico urbano colectivo de
superficie mediante autobs en la ciudad de Madrid.
La EMT cuenta con una flota de 2.068 autobuses para explotar un
total de 216 lneas. De las 216 lneas que opera la EMT, 171 lneas
son convencionales diurnas; 7 son lneas universitarias que slo
prestan servicio en periodo lectivo, 26 son lneas nocturnas
convencionales y 12 son lneas nocturnas de Metrobhos.
(Figura1: Linea de Autobuses de EMT)
La EMT de Madrid pionera en la aplicacin de nuevas tecnologas ha
puesto en marcha un mapa interactivo al que puedes acceder mediante
internet, llamada Navega por Madrid[footnoteRef:5], en donde usted
mediante el uso de estas herramientas podr realizar lo siguiente:
[5: Navega por Madrid (EMT Madrid, Espaa). Una de las interfaces de
una aplicacin mvil dirigida a los habitantes de Madrid]
Calcular itinerarios personalizados en autobs por la ciudad de
Madrid
Consultar lneas que pasan por un punto concreto de la ciudad
Consultar tiempos de espera en paradas
Consultar itinerarios de las lneas de EMT
Consultar incidencias de servicio en tiempo real
(Figura2: Interfaz del mapa interactivo "Navega por Madrid")
Tambin ha desarrollado un conjunto de aplicaciones y servicios
disponibles desde cualquier dispositivo mvil que podrs ingresar
mediante tu Smartphone, mediante dicho aplicativo se pueden
realizar diferentes tipos de funcionalidades, preguntndose Dnde
estoy? Cmo ir hacia?, donde te muestra el nombre de las calles del
lugar donde te encuentras, las paradas que tienes alrededor y el
tiempo de llegada de los autobuses en tiempo real, tambin brinda
las mejores rutas de trasladarse de un lugar a otro, tambin muestra
en forma detallada la atencin de lneas de buses disponibles durante
cada da.
En la aplicacin EMTMADRID para IPhone podemos encontrar una
utilidad llamada Realidad Aumentada, a travs de la cual tendrs
acceso a la informacin que se superpone en la imagen captada desde
la cmara del dispositivo, geolocalizando las paradas de autobs ms
cercanas as como diversos sitios de inters, donde el usuario se
orientara con una visin de 360 visualizando las paradas, los
tiempos de espera y a qu distancia estn.
Gracias a esta aplicacin las personas se podrn movilizar por
Madrid sin necesidad de tener un conocimiento detallado de la
ciudad.
Por otra parte, la empresa Smartmatic es una compaa
multinacional que disea y despliega soluciones que permite a los
organismos gubernamentales y a grandes empresas cumplir con sus
ciudadanos de la manera ms eficiente posible.
Uno de los proyectos realizados por Smartmatic es un Sistemas
para la Automatizacin del Recaudo de Pasajes, Gestin de Flotas e
Informacin al Usuario para TransCaribe, Cartagena de Indias,
Colombia.
POBLACIN ATENDIDA:
1.200.000
Vehculos de pasajeros por ao:
220.000.000
VEHCULOS:
719 buses
Para el servicio troncal
111
Alimentadores
405
Auxiliares
204
PUNTOS DE VENTA
634
ESTACIONES TRONCALES
17
Tabla 1: Transporte Masivo Cartagena De Indias
Este sistema comprende el servicio de la gestin de todos los
aspectos relativos a la recoleccin de pasajes, incluyendo la
produccin y distribucin de tarjetas, los equipos de a bordo de los
nuevos autobuses, un centro de control de operaciones para
consolidar y gestionar toda la informacin, y comunicaciones GSM y
va enlaces de radio troncalizados, utilizando redes privadas y
pblicas.
El sistema contara con boletera electrnica basado en tarjetas
inteligentes con la tecnologa en software y hardware ms avanzada en
la industria. En Cartagena, Smartmatic se encargara de suministrar,
dar mantenimiento y de la operacin de los equipos, las flotas de
autobuses y paneles de informacin para los pasajeros tanto en los
buses como estaciones.
(Figura3: Diseo del sistema automatizado de Transporte)
1.3. Propuesta de Solucin
La presente investigacin que se plantea, est orientada al diseo
de un sistema de informacin para proporcionar informacin a los
usuarios (peatones) sobre el servicio de transporte que ellos
utilizan, y a la vez ayude a la empresa en la toma de
decisiones.
Este sistema se caracterizada por realizar lo siguiente:
Mostrar los horarios de salida de una lnea de bus, y los
paraderos en el recorrido de esta lnea, indicando donde debe de
parar este y donde el usuario debe de bajar
Indicar los horarios que esta lnea de bus pasa por cada uno de
los paraderos y puntos de control
Tener una aplicacin que permita mostrar el tiempo que se demora
la lnea de bus entre dos paraderos respectivos para el uso y
conocimiento del usuario
Tener una aplicacin que permite mostrar al usuario la cantidad
que debe de pagar por su viaje, indicando en donde abordar la lnea
de bus y donde desea este bajar, para evitar la sorpresa de este al
pagar la tarifa de acuerdo a su tramo de viaje
Dar mantenimiento a la pgina, es decir poder gestionar los
horarios, el tiempo de un viaje y el tarifario de acuerdo a las
polticas o acciones de la empresa
Con estas caractersticas, el usuario tendr mayor facilidad al
acceso de informacin de este servicio y de una manera ms rpida a
travs de la conexin a Internet, ya sea por un computador o
mvil.
1.4. Alcance de la Propuesta
El alcance de la presente investigacin centra su atencin en la
ciudad de Lima Metropolitana, lugar donde transitan ms de 34 mil
vehculos (buses, csteres y combis) segn el diario la Repblica, y
donde se concentra la mayor cantidad de personas en el pas, siendo
esta cifra ms de 8, 432 mil habitantes lo que equivale al 28,14% de
la poblacin nacional, esto segn un informe de la INEI (Instituto
Nacional de Estadsticas e Informtica) hecho a principios del
ao.
Por estas razones, el impacto de nuestra investigacin tendr un
mayor efecto sinrgico y beneficiara a muchos peatones que residen
en la ciudad a tomarla como lugar de estudio; por otra parte la
aplicacin del proyecto est dirigida a las empresas de transporte
pblico que cuenten como nicos vehculos los buses, ya que este tipo
de vehculo es muy poco informal a diferencia de los otros (custeres
o combis).
1.5. Justificacin
Actualmente en Lima Metropolitana, el ciudadano se ve inmerso en
la misma situacin de todos los das y que nos afecta directa e
indirectamente, que es lidiar con los servicios que ofrece cada bus
del transporte pblico, siendo las causas en muchos ocasiones el
tiempo de espera, las indeterminadas tarifas, los modos de manejo y
conduccin, y entre otros que nos ocasionan insatisfaccin y
malestar.
Por tal motivo es que se realiza la siguiente investigacin, para
establecer una mejor planificacin sobre los horarios de los buses
mediante un sistema en interaccin con la tecnologa actual y
moderna, obteniendo un mejor estilo de vida logrando para ello en
el servicio una mejora de su calidad, un servicio del cual por
mucho tiempo hemos sido afectados por sus acciones y del que somos
dependientes.
1.6. Objetivos
1.6.1. Objetivos General
Elaborar el diseo de un sistema de informacin que pretenda
mejorar el servicio que ofrecen las empresas de transporte
pblico.
1.6.2. Objetivos Especficos
Simular el sistema de informacin en el establecimiento de los
horarios por parte de los buses
Incluir en el diseo del sistema de informacinla aplicacin costo
de viaje del usuario entre un paradero y otro, de acuerdo al
tarifario de la lnea de bus y de la empresa de transporte
pblico.
Incluir en el diseo del sistema de informacin una aplicacin que
permita consultar el tiempo que le tomar a la lnea de bus llegar a
un punto especfico desde un punto fijado.
Incluir en el diseo del sistema, el manejo del mantenimiento de
la informacin, ya sea para el tarifario, el tiempo de viaje y los
horarios de la lnea de bus.
2. MARCO TERICO
A continuacin se darn a conocer las diferentes teoras,
conceptos, normas y referencias de los diferentes temas abordados
para el diseo de un sistema de Informacin del servicio orientado a
los usuarios de una empresa de transporte pblico, esta informacin
fue recopilada de diferentes bibliografas, artculos, documentos y
linkografas para describir y explicar los temas relacionados a la
investigacin.
1.
2.
2.1. PROGRAMACIN WEB
2.1.1. Protocolo HTTP (Protocolo de Transferencia de
Hipertexto)
Desde 1990, el protocolo HTTP es el protocolo ms utilizado en
Internet. La versin0.9 slo tena la finalidad de transferir los
datos a travs de Internet (en particular pginas Web escritas en
HTML). La versin 1.0 del protocolo permite la transferencia de
mensajes con encabezados que describen el contenido de los mensajes
mediante la codificacin MIME (Extensiones de Correo de Internet
Multipropsito).
El propsito del protocolo HTTP es permitir la transferencia de
archivos (principalmente, en formato HTML), entre un navegador (el
cliente) y un servidor Web localizado mediante una cadenade
caracteres denominada direccin URL.
2.1.2. Comunicacin entre el navegador y el servidor web
La comunicacin entre el navegador y el servidor se lleva a cabo
en dos etapas:
El navegador realiza una solicitud HTTP
El servidor procesa la solicitud y despus enva una respuesta
HTTP
(Figura4: Comunicacin entre el navegador y el servidor Web)
I. Solicitud HTTP
Una solicitud HTTP es un conjunto de lneas que el navegador enva
al servidor. Incluye:
Una lnea de solicitud: es una lnea que especifica el tipo de
documento solicitado, el mtodo que se aplicar y la versin del
protocolo utilizada. La lnea est formada por tres elementos que
deben estar separados por un espacio:
el mtodo
la direccin URL
la versin del protocolo utilizada por el cliente (por lo
general, HTTP/1.0 )
Los campos del encabezado de solicitud: es un conjunto de lneas
opcionales que permiten aportar informacin adicional sobre la
solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada
una de estas lneas est formada por un nombre que describe el tipo
de encabezado, seguido de dos puntos (:) y el valor del
encabezado.
El cuerpo de la solicitud: es un conjunto de lneas opcionales
que deben estar separadas de las lneas precedentes por una lnea en
blanco y, por ejemplo, permiten que se enven datos por un comando
POST durante la transmisin de datos al servidor utilizando un
formulario.
II. Respuesta HTTP
Una respuesta HTTP es un conjunto de lneas que el servidor enva
al navegador. Est constituida por:
Una lnea de estado: es una lnea que especifica la versin del
protocolo utilizada y el estado de la solicitud en proceso mediante
un texto explicativo y un cdigo. La lnea est formada por tres
elementos que deben estar separados por un espacio:
la versin del protocolo utilizada
el cdigo de estado
el significado del cdigo
Los campos del encabezado de respuesta: es un conjunto de lneas
opcionales que permiten aportar informacin adicional sobre la
respuesta y/o el servidor. Cada una de estas lneas est formada por
un nombre que describe el tipo de encabezado, seguido de dos puntos
(:) y el valor del encabezado.
El cuerpo de la respuesta: contiene el documento solicitado.
2.1.3. Arquitectura del WWW
La arquitectura de una aplicacin Web dinmica, consta de tres
elementos principales que son: un cliente Web, un Servidor Web y un
servidor de base de datos, si se tratar de una aplicacin Web
esttica se eliminara el servidor de base de datos, de tal manera
que el cliente Web realiza las peticiones al servidor y este
responde el mensaje en formato HTML solamente. Cuando una aplicacin
Web es dinmico, el servidor Web no es capaz de responder por si
solo las peticiones del cliente Web, auxilindose para ello del
servidor de base de datos, a travs un motor de base de datos que
sirve como interfaz entre ambos, el motor se encarga de traducir el
lenguaje utilizado durante la programacin Web dinmica, como pueden
ser PHP, JSP, ASP al lenguaje del servidor de base de datos que se
est utilizando, as se puede utilizar PHP o cualquiera de los otros
lenguajes para acceder y manipular una base de datos de MySQL,
Microsoft SQL server, Microsoft Acces, o cualquier otra. Por
supuesto dependiendo del lenguaje utilizado para el acceso a la
base de datos ser el motor que se debe usar, existiendo un motor
por cada lenguaje de programacin, mismo que deber instalarse y
configurarse para operar de manera coordinada con el servidor Web y
el servidor de base de datos.
En el caso de una aplicacin Web dinmica, el cliente realiza la
peticin al servidor, el servidor utilizando el motor de base de
datos acceso a la base de datos, quien responde y entrega los
resultados al servidor Web, finalmente el servidor Web responde al
cliente Web en formato HTML. Se puede notar que ya sea que la
aplicacin Web sea esttica o dinmica el servidor Web siempre
entregar al cliente respuestas en formato HTML, de esta forma el
cliente nunca recibir respuesta en el lenguaje de programacin Web
dinmica. Esto sirve como un mecanismo de seguridad para evitar que
el usuario del cliente Web pueda ver los detalles de implementacin
ejecutados en el servidor Web utilizando el motor de base de
datos.
(Figura5: Arquitectura del www)
2.1.4. HTML
HTML es el lenguaje con el que se "escriben" la mayora de pginas
Web.
El lenguaje HTML es un estndar reconocido en todo el mundo y
cuyas normas define un organismo sin nimo de lucro llamado World
Wide Web Consortium (http://www.w3.org/),ms conocido como W3C. Como
se trata de un estndar reconocido por todas las empresas
relacionadas con el mundo de Internet, una misma pgina HTML se
visualiza de forma muy similar en cualquier navegador de cualquier
sistema operativo.
El propio W3C define el lenguaje HTML como "un lenguaje
reconocido universalmente y que permite publicar informacin de
forma global". Desde su creacin, el lenguaje HTML ha pasado de ser
un lenguaje utilizado exclusivamente para crear documentos
electrnicos a ser un lenguaje que se utiliza en muchas aplicaciones
electrnicas como buscadores, tiendas en lnea y banca
electrnica.
2.1.5. Desarrollo de aplicaciones web
La arquitectura de las aplicaciones Web suelen presentar un
esquema de tres niveles. El primer nivel consiste en la capa de
presentacin que incluye no slo el navegador, sino tambin el
servidor Web que es el responsable de dar a los datos un formato
adecuado. El segundo nivel est referido habitualmente a algn tipo
de programa o script. Finalmente, el tercer nivel proporciona al
segundo los datos necesarios para su ejecucin.
Una aplicacin Web tpica recoger datos del usuario (primer
nivel), los enviar al servidor, que ejecutar un programa (segundo y
tercer nivel) y cuyo resultado ser formateado y presentado al
usuario en el navegador (primer nivel otra vez).
(Ilustracin 6: Arquitectura Multinivel)
2.1.5.1. Lenguajes de programacin del lado del cliente
Los lenguajes del lado del cliente son aquellos que pueden ser
directamente interpretados por el navegador cliente Web y no
necesitan la interpretacin del servidor
Visual Basic Script
Es un lenguaje de programacin de scripts del lado del cliente,
pero slo compatible con Internet Explorer. Es por ello que su
utilizacin est desaconsejada a favor de Javascript.
Est basado en Visual Basic, un popular lenguaje para crear
aplicaciones Windows. Tanto su sintaxis como la manera de trabajar
estn muy inspiradas en l. Sin embargo, no todo lo que se puede
hacer en Visual Basic se puede hacer en Visual Basic Script, pues
este ltimo es una versin reducida del primero.
2.1.5.2. Lenguajes de programacin del lado del servidor
Son aquellos lenguajes que son reconocidos, ejecutados e
interpretados por el propio servidor y que se envan al cliente en
un formato comprensible para l.
Existe una multitud de lenguajes concebidos o no para Internet.
Cada uno de ellos explota ms a fondo ciertas caractersticas que lo
hacen ms o menos tiles para desarrollar distintas aplicaciones.
Los lenguajes del lado del servidor son invisibles para los
clientes. Las pginas que utilicen scripts de este tipo contienen el
cdigo entre etiquetas parecidas a las de HTML, pero stas
desaparecen cuando el cliente recibe la pgina. Los pasos que sigue
el navegador son:
Solicita al servidor una pgina Web a travs de Internet
El servidor comprueba si la pgina solicitada contiene script del
lado del servidor (PHP, ASP, JSP, etc.)
Ejecuta los posibles script y aade el resultado final a la pgina
Web resultante
El navegador recibe estos datos, interpreta la pgina Web enviada
y la muestra en la pantalla de acuerdo con la resolucin del
monitor, las preferencias del usuario y algn otro factor.
Los lenguajes del lado del servidor necesitan un motor (un
programa) que interprete el cdigo segn el lenguaje de programacin
que se est utilizando.
(Figura7: Uso del Motor de PHP)
2.1.5.3. Metodologas para el desarrollo de aplicaciones web
Los sitios Web se presentan de todas formas y modelos, desde
sencillas pginas a megasitios que gestionan los negocios para
empresas a nivel mundial, el proceso de desarrollar un sitio
implica los mismos pasos bsicos:
Conceptualizar e investigar
Esta primera fase es emocionante. Se empieza con una idea (sitio
de venta en lnea, ambiente virtual de aprendizaje, banca en lnea,
etc.) y luego realizar una lluvia de ideas sobre cmo se va a
manifestar como sitio Web. Este es el momento de las listas y
bocetos, pizarras y cuadernos. Qu va hacer emocinate? Qu va haber
en la primera pgina?
Crear y organizar contenido
La parte ms importante de un sitio Web es su contenido. A pesar
del ruido sobre tecnologas y herramientas, el contenido sigue
siendo el rey de internet. Tiene que haber algo de valor, tanto sea
algo de leer, algo que hacer o algo que comprar que atraiga a los
visitantes y haga que regresen. Es acertado ser sensible a la
necesidad de un buen contenido.
Desarrollar el aspecto visual y comportamiento
El aspecto visual de un sitio hace referencia a su diseo grafico
y apariencia visual global incluida su esquema de color tipografa y
estilo de imagen.
Producir un prototipo
Una vez que el diseo esta aprobado y el documento estn listos,
el sitio entra en la fase de produccin se puede realizar por una
persona. Es ms comn en el diseo Web comercial contar con un equipo
de personas que trabajan en tareas especializadas.
Probarlo
Todos los sitios Web se tienen que probar antes de que estn
listos para el pblico. Los desarrolladores Web profesionales
dedican tiempo y recursos al calendario de produccin para realizar
pruebas. Tanto formalmente como informalmente, los sitios se
deberan probar para funcionalidad bsica, rendimiento en diferentes
entornos de navegacin y facilidad de uso.
Lanzar el sitio
Una vez que se tiene todos los detalles resueltos para el sitio,
es el momento de enviarlo al servidor final, y ponerlo disponible
al mundo.
Mantener el sitio
Un sitio Web nunca est del todo terminado. De hecho la
posibilidad de realizar actualizacin y mantener el contenido
actualizado es una de las ventajas del medio Web. Es importante
tener una estrategia para lo que ocurrira con el sitio despus de su
lanzamiento inicial.
2.1.5.3.1. Aspectos de seguridad.
En este tema se analiza el papel de la seguridad en los sitios
Web dinmicos. Se indicar quin puede estar interesado en la
informacin y como podran obtenerla, los principios implicados en la
creacin de una poltica para evitar este tipo de problemas y algunas
tecnologas disponibles para salvaguardad la seguridad de un sitio
Web incluida la criptografa, la autentificacin y el rastreo.
Entre los aspectos de seguridad estn:
Importancia de la informacin
Amenazas contra seguridad
Equilibrio entre usabilidad, rendimiento, costes y seguridad
Crear una poltica de seguridad
Principios de autentificacin
Fundamentos de la criptografa
Criptografa de la clave publica
Firmas digitales
Certificados digitales
Servidores Web seguros
Auditorias y registros
Cortafuegos
Copia de seguridad de datos
Seguridad fsica
2.2. MARCO REFERENCIAL
Las referencias para el desarrollo de la investigacin presente
ha sido las diferentes vivencias por parte de nosotros, los cuales
experimentamos el problema en particular bajo diferentes
situaciones, aparte por el hecho de que el problema que intentamos
solucionar pertenece a uno de los principales problemas que
actualmente la sociedad de Lima Metropolitana enfrenta. Segn una
encuesta realizada por Lima Como Vamos (observatorio ciudadano que
realiza seguimiento y evaluacin a los cambios producidos en la
capital) a finales del ao pasado, el 45,9% de los ciudadanos estn
fastidiados por el ineficiente servicio de transporte pblico limeo,
lo que nos conlleva a analizar algunas de las causas que
corresponde a este resultado. Adems seala las preferencias de las
personas por el servicio del Metropolitano, estas preferencias estn
sustentadas en el tiempo de viaje, es decir en su rapidez, siendo
el ms valorado segn la encuesta con un 37,4 %, sin embargo este
servicio solo beneficia a un 10% de limeos, lo que significa q el
resto de la poblacin aun sigue utilizando el servicio clsico que
aun sigue siendo deficiente.
As mismo, segn un documento del Ministerio de Educacin, que
corresponde al informe defensorial N 137, cita varios argumentos
que se entiende, que debido a un mal sistema regulador o de control
por parte de la mayora de empresas de transporte pblico, provoca
diferentes problemas as como accidentes, dentro de los cuales la
principal causa es la forma de actuar de los choferes como
consecuencia de la mala gestin o del mal sistema que tienen estas
empresas.
2.2.1. Antecedentes:
2.2.1.1. Nacionales
Metropolitano
Como una solucin para este problema, en el segundo semestre del
2010 se empez a utilizar el servicio Metropolitano, un nuevo
sistema integrado de transporte pblico para Lima, que cuenta con
buses articulados de gran capacidad que circulan por corredores
exclusivos, bajo el esquema de autobuses de trnsito rpido BRT (Bus
Rapid Transit en ingls).
El desarrollo de este proyecto se hizo con el objetivo de elevar
la calidad de vida de los ciudadanos, al ahorrarles tiempo en el
traslado diario, proteger el medio ambiente, brindarles mayor
seguridad, una mejor calidad de servicio y trato ms humano,
especialmente a gestantes,mujeres con nios en brazo,
nios,adultosmayores ypersonascon discapacidad.
Sin embargo, segn Juan Tapia Grillo, presidente de
Pro-transporte, el Metropolitano todava no es rentable: Todos los
sistemas de corredores segregados de alta velocidad se basan en el
rendimiento de pasajeros por bus. El diseo original aqu fue hecho
para atender a ms de 600 mil pasajeros por da. Todava no hemos
llegado a esa cifra, explica Tapia. Han pasado de 220 mil pasajeros
en enero de 2011 inicio de la gestin de Susana Villarn a 460 mil.
Espera lograr la cifra necesaria a fines de este ao o comienzos del
prximo habilitando nuevas rutas y poniendo toda la flota existente
en la calle.
(Figura8: En Julio ingresaron 56 buses nuevos a la ruta)
Aparte este servicio conecta Lima Sur con Lima Norte,
recorriendo 16 distritos de la ciudad desde Chorrillos hasta Comas.
Por lo que se concluye que no ayuda a toda la poblacin, siendo solo
un poco ms del 10% la cantidad de personas beneficiarias de este
servicio.
Tren Elctrico
Otra solucin para este problema, es el servicio de tren
elctrico, este servicio fue conformado por empresas lderes como
Odebrecht (67%) y Graa y Montero (33%), que as como el
Metropolitano, este tambin se desarrollo para mejorar la calidad en
los servicios de transporte que se tiene en nuestra ciudad, as como
tambin los siguientes beneficios:
Transporte Masivo. El tren beneficiar a ms de 3 millones de
personas.
Rapidez y puntualidad. Recorrer 11 distritos en aproximadamente
45 minutos (en la actualidad son 4 horas en mnibus)
Descongestin Vehicular. Permitir una mejora y orden en el
trnsito de la ciudad.
Modernidad. Lima contar con un sistema de transporte moderno,
logrando ubicarse entre las ciudades ms importantes en el
mundo.
Cero contaminaciones. El moderno sistema de transporte no
contamina debido a su alimentacin elctrica.
Seguridad. El recorrido de los vagones est cronometrado y
monitoreado.
Tranquilidad. El metro es un sistema de transporte que no emite
ruidos inoportunos.
Aunque los beneficios que se pretende lograr con este servicio
son grandes, aun todava est en iniciacin, es decir aun estn en
construcciones los diferentes tramos o lneas del proyecto para que
logre llegar a la mayor parte de Lima Metropolitano ya que
actualmente solo se tiene una lnea en operacin que es el Tramo 1,
la cual comprende desde Villa El Salvador hasta la Av. Grau en el
Cercado de Lima, atraviesa 9 distritos y a lo largo de sus 22 km de
longitud estn distribuidas 16 estaciones de pasajeros.
(Figura9: Tramo 1, red bsica de tramo)
2.2.1.2. Internacionales
Como una de las grandes soluciones referentes a enfrentar
nuestra problemtica en particular desarrollada y aplicada fuera del
pas, la Empresa Municipal de Transportes de Madrid, una sociedad
annima, propiedaddel Ayuntamiento de Madrid, encargada de la
prestacin del servicio de transporte pblico urbano colectivo de
superficie mediante autobs en la ciudad de Madrid, ha puesto en
marcha un mapa interactivo al que puedes acceder mediante internet,
llamada Navega por Madrid, en donde usted mediante el uso de estas
herramientas podr realizar lo siguiente:
Calcular itinerarios personalizados en autobs por la ciudad de
Madrid
Consultar lneas que pasan por un punto concreto de la ciudad
Consultar tiempos de espera en paradas
Consultar itinerarios de las lneas de EMT
Consultar incidencias de servicio en tiempo real
(Figura10: Interfaz del mapa interactivo "Navega por
Madrid")
Tambin ha desarrollado un conjunto de aplicaciones y servicios
disponibles desde cualquier dispositivo mvil que podrs ingresar
mediante tu Smartphone, mediante dicho aplicativo se pueden
realizar diferentes tipos de funcionalidades, preguntndose Dnde
estoy? Cmo ir hacia?, donde te muestra el nombre de las calles del
lugar donde te encuentras, las paradas que tienes alrededor y el
tiempo de llegada de los autobuses en tiempo real, tambin brinda
las mejores rutas de trasladarse de un lugar a otro, tambin muestra
en forma detallada la atencin de lneas de buses disponibles durante
cada da.
En la aplicacin EMTMADRID para IPhone podemos encontrar una
utilidad llamada Realidad Aumentada, a travs de la cual tendrs
acceso a la informacin que se superpone en la imagen captada desde
la cmara del dispositivo, geolocalizando las paradas de autobs ms
cercanas as como diversos sitios de inters, donde el usuario se
orientara con una visin de 360 visualizando las paradas, los
tiempos de espera y a qu distancia estn.
Gracias a esta aplicacin las personas se podrn movilizar por
Madrid sin necesidad de tener un conocimiento detallado de la
ciudad.
2.3. MARCO NORMATIVO
2.3.1. Polticas para la elaboracin de sistemas
Toda elaboracin de sistemas deber estar orientada a satisfacer
las necesidades de manejo de informacin para las funciones
sustantivas de una institucin o empresa; es importante concebir el
diseo de dichos sistemas de manera que permitan su integracin y
consolidacin en una base de datos constitucional y un banco
institucional de sistemas, en un futuro prximo
Toda elaboracin de sistemas, tanto interna como externa, debe
cumplir con las normas establecidas por el comit de informtica de
una institucin o empresa. El cumplimiento de las normas es un
requisito indispensable para considerar un sistema apto para su
liberacin definitiva.
Toda elaboracin de sistemas, tanto interna como externa de
carcter institucional, deber estar avalada por un dictamen tcnico
de la direccin de informtica, rgano que en unin con el comit e
informtica de la institucin o empresa debe normar el uso y
aprovechamiento de los recursos informticos de acuerdo al
reglamento interno de sta. El dictamen tcnico no ser necesario para
aquellos sistemas internos de carcter tcnico especializado o
especfico de las reas de la institucin o empresa, slo debern
apegarse a los estndares establecidos por el comit de
informtica.
La elaboracin de sistemas institucionales debe apegarse a los
estndares en cuanto al uso de software. Cuando esto no sea posible,
el rea usuaria deber solicitar un dictamen tcnico a la direccin de
informtica de la institucin o empresa, justificando plenamente el
uso de las herramientas propuestas para el desarrollo.
La contratacin externa para la elaboracin de sistemas deber
sujetarse a la normatividad de adquisiciones vigente, los costos
que se generen por dicha contratacin debern ser cubiertos por el
rea solicitante.
Antes de la aprobacin de cualquier contrato, la direccin de
informtica deber asegurarse que:
Los requisitos definidos en el contrato se expresen siempre de
manera adecuada e invariablemente en forma textual
En relacin con las caractersticas del sistema, se hayan resuelto
todas aquellas diferencias de opinin entre las reas usuarias y de
informtica y el desarrollador, constando su firma de conformidad en
el contrato
El proveedor sea capaz de cumplir los requisitos del contrato,
tomando como referencia su curriculum vitae presentado.
Todos los sistemas y sus componentes desarrollados por personal
de la institucin o empresa son propiedad de ste, por lo que la
institucin o empresa tendr los derechos de autor para la utilizacin
de dichos desarrollos en las diferentes reas que as lo requieran.
En el supuesto de que el comit editorial apruebe su publicacin,
cada rea de informtica deber informar la terminacin del sistema al
rea de la institucin o empresa que tramita los derechos de autor,
con objeto de que se lleven a cabo los trmites requeridos. As
tambin, l o los autores debern firmar la cesin de derechos a la
institucin o empresa, en el entendido de que la institucin o
empresa otorgar los crditos respectivos en la publicacin.
Durante el anlisis, desarrollo e implantacin de cualquier
sistema, el rea solicitante deber participar con su rea de
informtica respectiva y con la direccin de informtica y la empresa
externa.
Es responsabilidad del rea de informtica y de la empresa externa
que desarroll un sistema, el proporcionar capacitacin y asistencia
tcnica al personal operativo del rea usuaria para el uso y
mantenimiento del sistema. Ser obligacin del rea solicitante
asegurar que estos procesos cubran todas sus necesidades y
requerimientos sustantivos.
El comit de informtica a travs de la direccin de informtica
establecer de manera formal su poltica de calidad en cuanto a las
normas y procedimientos por utilizar, con objeto de que funcione
eficazmente el sistema de aseguramiento de calidad.
El comit de informtica, conjuntamente con la direccin de
informtica, ser el encargado de establecer la organizacin interna
ms adecuada para las diferentes reas de informtica de la institucin
o empresa. Entre los puntos por considerar destacan:
Establecer un organigrama
Delegar autoridad
Compartir las responsabilidades
Conforme a las necesidades de las reas de informtica de la
institucin o empresa distribuir adecuadamente los recursos
materiales para las reas respectivas y establecer una poltica de
calidad que se base en principios, con el fin de crear relaciones
para que las personas trabajen en conjunto de manera efectiva. Los
recursos humanos sern proporcionados por las reas respectivas de la
institucin o empresa.
En la elaboracin y diseo de sistemas informticos internos la
direccin de informtica ser la encargada de establecer y mantener un
sistema de calidad documentado para asegurar productos conforme a
los requerimientos especificados por ella misma, adems de alcanzar
consistentemente los objetivos de calidad de la institucin o
empresa. Entre los documentos que se generarn por los
desarrolladores, estn los manuales de procedimientos, tcnicos, de
instalacin, operativos y de usuario.
El comit de informtica ser el encargado de establecer polticas
de administracin, calidad y control de calidad; as como, la
justificacin y consistencia de stas. Peridicamente tiene la
obligacin de revisar las polticas establecidas y evaluar los
resultados logrados. Tambin verificar a travs de la direccin de
informtica, la cooperacin y comunicacin entre coordinaciones y
evaluar a las empresas relacionadas (subcontratistas,
distribuidores, etc.).
El comit de informtica, a travs de la direccin de informtica ser
el encargado de establecer y describir las clases de trabajo para
el desarrollo de sistemas informticos internos. Entre las clases de
trabajo por considerar estn: divisin del trabajo, identificacin de
fuentes de autoridad y establecimiento de relaciones. En lo que
concierne a las formas de trabajo, se encuentran la funcional, por
proyectos y la matricial.
2.3.2. Normas para la elaboracin de Sistemas
2.3.2.1. Objetivo:
Definir la metodologa a la que debe someterse todo el personal
involucrado en la elaboracin de sistemas, con objeto de obtener
productos de alta calidad que resulten de fcil mantenimiento para
cualquier miembro del equipo de trabajo.
2.3.2.2. Normas Generales:
Los desarrollos de sistemas, tanto internos como externos debern
respetar los lineamientos y estndares definidos en el Manual de
Procedimientos para el Desarrollo de Sistemas (MPDS).
El rea de informtica y la empresa externa debern entregar al rea
solicitante: los programas fuentes y ejecutables documentacin
tcnica, manual de instalacin y manual del usuario de acuerdo al
MPDS.
Para los desarrollos internos y externos, cualquier rea de
informtica de la institucin o empresa deber entregar a la direccin
de informtica el original del sistema con su respectiva
documentacin y todos aquellos elementos que hagan posible su
incorporacin al banco institucional de sistemas, conservando una
copia.
Para aquellos sistemas que se desarrollen con un software no
estndar para la institucin, ser requisito indispensable que cuenten
con un mdulo de intercambio de informacin (importacin/exportacin) a
travs de cdigo ASCII de DOS.
Todas las fases del desarrollo de sistemas debern esta
documentadas de acuerdo al MPDS.
Si la institucin o empresa se encuentra en proceso de
restructuracin en cuanto a su organizacin interna, por ninguna
circunstancia se deber iniciar la elaboracin de un sistema. Para
este ltimo caso, es conveniente la implantacin de los sistemas al
menos dos (2) meses despus de que se comenz a trabajar con el nuevo
esquema de organizacin. Cuando el nuevo esquema tenga contemplado
el uso del sistema, los lderes de proyecto, tanto de la
restructuracin organizacional como del sistema de informacin,
establecern los canales de comunicacin adecuados para la
coordinacin respectiva de sus proyectos.
Por ninguna causa se deber comenzar la etapa de programacin del
sistema en general, sin antes tener concluidas las etapas de
anlisis y diseo. Para el caso en que el sistema por su magnitud se
halla dividido en mdulos, ser vlido el comenzar la programacin de
cada uno de ellos si se cuenta con sus etapas de anlisis y diseo
concluidas, adems de un anlisis y diseo preliminar de carcter
general del sistema.
2.3.2.3. Normas para el anlisis de sistemas:
Los desarrollos de sistemas debern contar con un estudio de
factibilidad tecnolgica y econmica que permita identificar y
describir las necesidades del usuario con objeto de justificar la
elaboracin del sistema.
Apoyados en el estudio de factibilidad tecnolgica y econmica,
las reas de informtica y usuarias debern solicitar un dictamen
tcnico a la direccin de informtica.
Se debern establecer los grupos de trabajo encargados para las
actividades de diseo de encuestas, entrevistas, recopilacin de
datos, etc.
La fase de anlisis de sistemas deber apegarse a las metodologas
de anlisis estructurado, tales como Yourdon, De Marco o de Gane
&Sarson.
2.3.2.4. Normas para el diseo de sistemas
La fase de diseo de sistemas deber apegarse a las metodologas de
anlisis y diseo estructurado, tales como Yourdon, De Marco o de
Gane &Sarson.
Deben existir manuales de procedimientos vigentes en la
institucin o empresa, todos los grupos de trabajo involucrados en
el diseo de sistemas debern tener conocimiento del contenido de
ellos, a fin de reflejarlos en el sistema cuando stos lo
afecten.
Para los casos en los cuales se efecte un cambio en el diseo de
un sistema, dicho cambio deber ser documentado previa revisin y
justificacin, as como aprobacin de los responsables para posterior
notificacin al encargado del control de la documentacin, con el fin
de que todas las reas se enteren del cambio efectuado.
2.3.2.5. Normas para la programacin y documentacin de
sistemas
Todos los programas que integren cualquier sistema debern estar
documentados conforme al Manual de Procedimientos para el
Desarrollo de Sistemas (MPDS).
El rea usuaria deber aprobar el manual de usuario previo a la
liberacin de un sistema. La Direccin de Informtica deber revisar
que el manual tcnico se apegue a las especificaciones del MPDS; en
los casos que as se considere necesario la direccin de informtica
evaluar dichos manuales.
El encargado del control de la documentacin de un sistema, ser
subordinado directo del lder de proyecto en que est involucrado el
sistema. Este encargado dictaminar el control de la documentacin
con base en claves de control (en la esquina inferior izquierda),
las cuales sern de conocimiento general para el equipo de
desarrollo del sistema. Los documentos sern inventariados en una
lista maestra de control de documentos, en la cual se tenga
constancia del estado actual de cada documento y de quin tiene
posesin del mismo. Ejemplos: CO=Confidencial, NF=No fotocopiable,
CE____= Control especfico del ___, UG= Uso general, CF __/__/__=
Cambios frecuentes de fecha de publicacin, etc.
El encargado del control de la documentacin tendr especial
cuidado en la documentacin que presente cambios frecuentes, ya que
ser su obligacin el velar que en todas las reas se cambie la
documentacin obsoleta del sistema por documentacin actualizada.
Todos aquellos cdigos que sean objeto de programacin, ya sean
mdulos, programas, pantallas, etc., debern contener informacin de
quin efectu la programacin y en qu fecha; de ser posible en el
mismo software, mediante comentarios y adicionalmente en la
documentacin por escrito.
Despus de concluida la programacin de una parte del sistema se
deber registrar en un documento que dicha parte del sistema ha sido
concluida, especificar el o los nombre(s) del o los
programador(es), as como el tiempo de programacin en horas; esto
con el fin de establecer un control de calidad del trabajo de los
programadores.
2.3.2.6. Normas para la implantacin de sistemas y
capacitacin
Antes de liberar un nuevo sistema, ste deber ser sometido a
pruebas de aceptacin definidas por el rea usuaria, utilizando para
ello datos reales. En el caso de nuevas versiones, ser necesario
realizar corridas en paralelo para verificar su correcto
funcionamiento con respecto a la versin anterior.
La capacitacin al personal tcnico-operativo formar parte
fundamental de la liberacin de un sistema. Dicha capacitacin deber
cubrir todas las necesidades y requerimientos que el rea usuaria
especifique de comn acuerdo con el rea de informtica o empresa
externa.
El proceso de capacitacin deber ser posterior a la aprobacin de
los manuales:
tcnico
de instalacin
de operacin
del usuario, que constituirn la gua con la que se lleve a cabo
dicho proceso
Los manuales de operacin debern especificar los mtodos de manejo
que permitan cuidar la integridad, tanto fsica como lgica de los
elementos que conforman el sistema, ya sean datos informacin,
software, hardware y documentacin.
Las pruebas de aceptacin debern ser clasificadas en:
preliminares, para los casos en que se pruebe el mdulo o el
programa de manera individual, y totales, cuando se encuentren
ensamblados todos los componentes del sistema. Para cada una de
estas pruebas, se llevar un control de los resultados
obtenidos.
Las corridas de prueba que se realicen con el fin de acreditar
un sistema como aceptado, debern efectuarse con una cantidad de
datos superior al 50% de la cantidad de datos que el sistema correr
de manera cotidiana, y con el equipo de cmputo en el que se
pretende operar sistemticamente. Para el caso de sistemas que
operen en red, tambin se debern efectuar pruebas con usuarios
concurrentes.
Los tipos de datos con los cuales se efecten las pruebas debern
estar apegados a la realidad, a fin de tomar en cuenta el rango de
valores que soportar el sistema y posteriormente realizar una
grfica de rendimiento de cantidad de datos contra el tiempo de
procesamiento. En el caso de sistemas para trabajo en red, debern
establecerse elementos que permitan observar objetivamente el
desempeo del sistema. Si los resultados de rendimiento del sistema
no son aceptables para fines prcticos, se consignar el mdulo para
su re-trabajo en programacin.
2.3.2.7. Normas para el mantenimiento de sistemas
El rea usuaria deber solicitar el mantenimiento de un sistema a
su rea de informtica o empresa externa, siempre y cuando se
identifiquen y justifiquen plenamente los ajustes y cambios
necesarios que permitan mejorar el desempeo y cobertura del sistema
en cuestin. Para los casos que as se considere necesario, deber
solicitarse dictamen tcnico a la direccin de informtica.
Aquellos cdigos del sistema que no trabajen de manera ptima con
respecto a las necesidades o rendimiento que se pretenda
satisfacer, sern dispuestos a un proceso de re-trabajo; en primera
instancia a quien realiz la programacin, y en ltimo caso a un nuevo
equipo de trabajo para programacin, esto considerando un estilo de
programacin diferente que sea ms adecuado a la necesidad a
satisfacer. La situacin anteriormente descrita debe registrarse en
la documentacin correspondiente.
2.3.3. Polticas Generales De Seguridad Informtica
2.3.3.1. Del Departamento de Redes y Comunicaciones
Art. 1. Normar el correcto uso de los servicios de Internet y
correo electrnico en la empresa.
Art. 2. Establecer las medidas y mecanismos de control,
monitoreo y seguridad, tanto para los accesos a pginas o sitios de
Internet, como para los mensajes de correo con contenidos u orgenes
sospechosos.
Art. 3. Que las conexiones a Internet cuenten con elementos de
prevencin, deteccin de intrusos, filtros contra virus, manejo de
contenidos, entre otros, que afectan la integridad de los sistemas
y la informacin institucionales.
Art. 4. Reducir el trfico de mensajes, paquetes o transacciones
no permitidos, que saturan la infraestructura de telecomunicaciones
y generan actividad innecesaria en los servidores.
Art. 5. De acuerdo a la demanda de servicios, establecer
prioridades, dando la ms alta a las actividades consideradas
esenciales para fomentar la educacin y las artes, objetivo
primordial de la Institucin.
Art. 6. Controlar, suspender o revocar los cdigos de acceso a
cualquier usuario que haga mal uso de los recursos, viole las
polticas de seguridad o interfiera con los derechos de otros
usuarios.
Art. 7. Asignar la capacidad de memoria de almacenamiento a cada
usuario, en funcin del perfil establecido y disponibilidad del
recurso en los servidores administra la Direccin de Servicios
Informticos (DSI).
Art. 8. Contratar enlaces o servicios de conectividad a
Internet, ya sea directamente o va terceros, por lo que queda
restringido a cualquier otra rea de la Institucin obtener y
utilizar enlaces y servicios que permitan la interconexin de las
redes de la Empresa hacia el exterior. La DSI es la nica autorizada
dentro del Instituto para realizar o autorizar ese tipo de
contrataciones, esto podr hacerlo atendiendo a necesidades
especiales por cuenta de las reas, certificando la incorporacin de
las medidas de control y seguridad en los enlaces.
Art. 9. Establecer las normas de construccin y arquitectura de
los sitios de Intranet, que optimicen el acceso a los servicios y
la informacin disponible para los usuarios.
Art. 10. Administrar y asignar todas las direcciones IP de la
Empresa, as como los dominios y subdominios asignados a la
Empresa.
2.3.3.2. De los Administradores de red
Art. 1. Configurar los servidores de correo electrnico e
Internet y de los equipos de cmputo en general.
Art. 2. Instalar y actualizar los antivirus y sistemas
operativos, as como tener al da en los servidores asignados, las
actualizaciones y parches de programas institucionales licenciados
y autorizados.
Art. 3. Llevar un registro y control de las direcciones IP de
los equipos conectados a la red con acceso a Internet y la
informacin de los usuarios, as como notificar al Departamento de
Redes y Comunicaciones de las altas y bajas de usuarios para los
servicios de correo electrnico e Internet.
Art. 4. Proporcionar al Departamento de Redes y Comunicaciones
la documentacin actualizada de la red local: planos de cableado,
ubicacin del equipo y relacin de las asignaciones de direcciones
IP.
Art. 5. Administrar los servicios locales de red como son www,
correo electrnico, servidor de FTP y servidores de aplicaciones en
red.
Art. 6. Solucionar fallas menores como son: cables
desconectados, prdida de suministro de energa elctrica en los
equipos de datos, desconfiguracin de las computadoras de los
usuarios o direcciones IP repetidas.
Art. 7. Supervisar el cumplimiento de las polticas y
lineamientos institucionales.
2.3.3.3. Del Departamento de Soporte Tcnico
Art. 1. Brindar mantenimiento preventivo y/o correctivo
nicamente al equipo que cuente con nmero de inventario, o se
encuentre como dato, debiendo en este ltimo caso enviar a la DSI
copia del contrato correspondiente.
Art. 2. Realizar respaldos diarios de la informacin contenida en
los servidores del Instituto.
2.3.3.4. Del Personal
Art. 1. El empleado no tiene ningn derecho sobre la informacin
que procese dentro de las instalaciones de la red institucional de
la Empresa
Art. 2. La informacin que maneja o manipula el empleado, no
puede ser divulgada a terceros o fuera del mbito laboral.
Art. 3. El usuario se norma por las disposiciones de seguridad
informtica de la Empresa
Art. 4. Conocer y obedecer las polticas de seguridad
establecidas en el presente documento, las cuales, una vez
aprobadas se publicarn.
2.3.4. Normas especficas para la seguridad de informacin
2.3.4.1. Del Acceso a la Informacin
Todos los permisos de acceso a los sistemas debern solicitarse
con documento formal al Departamento de Informtica o haga sus
veces.
El usuario deber identificarse antes de ingresar a las reas de
cmputo, verificando si cuenta con la autorizacin correspondiente
del encargado de Informtica, registrndose el nombre de la persona,
hora de ingreso y hora de salida.
Toda persona sin excepcin que use una computadora en las
instalaciones de la Empresa deber ser usuario autorizado.
Las visitas deben portar la identificacin proporcionada por el
personal de seguridad de la Empresa a la entrada de la institucin,
pudiendo accesar a las computadoras siempre y cuando la visita se
encuentre acompaada mnimamente por el usuario de la Empresa, quien
deber solicitar el permiso de acceso ante los encargados de los
sistemas de cmputo, debiendo existir una razn suficiente que
amerite el acceso a las mismas.
No est permitido que ninguna persona visitante instale, copie o
elimine informacin de las computadoras o servidores de la red
interna. Para el mantenimiento de los sistemas externos el
visitante deber estar acompaada por personal especializado del
Departamento de Informtica quien proporcionar el soporte tcnico
necesario.
En los Sistemas Informticos los programas de cmputo, debern
contar con rutinas de control para el acceso de los usuarios.
Las rutinas de control, permiten que los usuarios ingresen al
Sistema, previa identificacin, mediante una palabra clave, la cual
ser nica para cada uno de ellos; negando el acceso a las personas
que no han sido definidas como usuarios del Sistema.
Las rutinas de control de acceso identificarn a los usuarios
autorizados a usar determinados sistemas con su correspondiente
nivel de acceso, el cual incluye la lectura o modificacin en sus
diferentes formas.
Existirn 4 niveles de acceso a la informacin:
a) Nivel de consulta de la informacin no es restringida o
reservada.
b) Nivel de mantenimiento de la informacin no restringida o que
no es reservada.
c) Nivel de consulta de la informacin, incluyendo la restringida
o reservada.
d) Nivel de mantenimiento de la informacin, incluyendo la
restringida o reservada
Para garantizar estos niveles cada palabra clave tendr asignada
uno de estos niveles de acceso.
La informacin que se considere restringida o reservada deber
estar debidamente identificada, as como los usuarios que tengan
acceso a ella.
Informtica, maneja los 4 niveles de acceso a la informacin,
contando para ello con un Administrador de la seguridad del
aplicativo, quien es responsable de la asignacin de las palabras
claves, de los niveles de acceso y las fechas de expiracin.
La seguridad de la informacin debe configurarse tambin a nivel
de archivos fsicos, el sistema de archivos deber ser NTFS a fin de
garantizar su integridad. Los accesos a dichos archivos debern
auditarse para monitoreo de la seguridad.
Los operadores de la informacin restringida o reservada
realizarn estrictamente lo indicado en cada procesamiento de la
informacin, debiendo contarse con el procedimiento claramente
documentado.
2.3.4.2. De la Proteccin Especial de la Informacin
Para proteger una base de datos, se deber prever que el nmero de
conexiones a la misma est respaldada por su respectiva licencia de
uso.
Para proteger la informacin clasificada como restringida o
reservada, es necesario encriptarla, utilizando un software que
elabore un algoritmo que permita encontrar un equivalente por cada
letra o bloque de informacin, y que ese equivalente pueda codificar
la informacin en otro formato cuyo contenido es difcil acceso.
El software de encriptacin deber cumplir las siguientes
condiciones:
a) Ser portable, es decir que funcione en diferentes sistemas
operativos con cambios mnimos.
b) Podr utilizarse en cualquier lenguaje de programacin.
c) Ser de fcil entendimiento por el usuario, de tal manera que
permita su uso sin necesidad que ste conozca las tcnicas de
encriptacin.
d) Estar debidamente documentado, para ser entendible por
cualquier usuario.
Para el control y distribucin de la informacin impresa, as como
para la grabacin de los medios magnticos u pticos y su respectivo
almacenamiento y/o distribucin se deben registrar en la dependencia
que origina y/o enva la informacin.
Los reportes que contengan informacin de carcter reservado y que
no se usen debern ser destruidos.
2.3.4.3. De la Integridad de la Informacin
Todo Sistema de Informacin, para que sea eficaz, deber ser
analizado y diseado con la participacin conjunta del analista de
sistemas y el usuario. El analista de sistemas identificar y
especificar todos los requerimientos del usuario, para que stos
sean considerados en la etapa de diseo del sistema.
Los programas debern estar documentados y utilizarn nombres
estndares.
Todo cambio que se haga a los sistemas informticos deber ser
inmediatamente documentado en los manuales correspondientes y en
las ayudas en lnea de los sistemas.
Para evitar el reinicio de los procedimientos que forman parte
de los procesos, debern existir suficientes archivos de respaldo y
suficientes puntos de verificacin /reinicio de operaciones.
Para que las acciones de auditora, puedan rastrear las
transacciones necesarias para el control, se deber prever la
generacin de toda la informacin necesaria. Esta informacin deber
contener como mnimo: nombre de usuario, fecha y hora, nombre de la
tabla y accin realizada.
Para pruebas de los programas, es necesario preparar datos de
comprobacin en donde se contemplen todas las entradas correctas y
erradas, verificndose las salidas generadas con los resultados
previstos. Los programas tambin sern probados con datos reales,
hacindose las mismas verificaciones. Asimismo se confirmarn los
lmites extremos ms altos o ms bajos de las cantidades
utilizadas.
Para asegurar la calidad de los sistemas Informticos es
necesario efectuar pruebas de verificacin y validacin.
Para la prueba de los Sistemas, es necesario la compatibilidad
entre los mdulos individuales, integrantes de los sistemas.
Los Sistemas de Gestin de Base de Datos, debern brindar
facilidades para su restauracin con rapidez y con la mnima prdida
de informacin. Las Bases de Datos se restaurarn en base a la tcnica
de la redundancia.
Deber llevarse un registro ordenado y clasificado de las
versiones del software, que permita un fcil mantenimiento del
mismo, as como una adecuada restauracin de versiones anteriores en
caso de falla.
Se proporcionar a los operadores de las computadoras con la
debida anticipacin la documentacin necesaria para la ejecucin de
trabajos de procesamiento automtico de datos, de acuerdo a las
prioridades de los mismos.
2.3.4.4. Seguridad de la Informacin
El usuario que utiliza sistemas mono usuario debe adoptar las
medidas de seguridad, que garanticen el cumplimiento de las normas
y procedimientos sealados en la presente directiva.
Las cuentas de los usuarios de los sistemas informticos son
estrictamente personales e intransferibles. El usuario de sistemas
informticos que disponga de una palabra clave de acceso ser
responsable de su mal uso por otras personas no autorizadas.
El rgano de administracin correspondiente deber proveer el
mobiliario y/o el mantenimiento del mobiliario para almacenar bajo
llave toda la documentacin de trabajo de carcter reservado.
2.4. METODOLOGA RUP
ElProcesoUnificadoRacional,RationalUnifiedProcesseningls,ysussiglas
RUP, esun proceso dedesarrollo desoftware yjuntocon
elLenguajeUnificadodeModeladoUML, constituye la metodologa estndar
ms utilizada para el anlisis, implementacin y documentacin
desistemasorientadosa objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino
que trata de un conjunto de metodologas adaptables al contexto y
necesidades de cada organizacin, donde el software es organizado
como una coleccin de unidades atmicas llamados objetos,
constituidos por datos y funciones, que interactan entre s.
Tambin se conoce por este nombre al software desarrollado por
Rational, hoy propiedad de IBM,elcualincluyeinformacinentrelazadade
diversos artefactos y descripciones de las diversas actividades.
Est incluido en el RationalMethodComposer(RMC), que permite la
personalizacin de acuerdo a necesidades.
2.4.1. UML
UML es un lenguaje de propsito general para el modelado
orientado a objetos, quecombina notaciones provenientes desde:
Modelado Orientado a Objetos, Modeladode Datos, Modelado de
Componentes, Modelado de Flujos de Trabajo (Workflows).
En todos los mbitos de la ingeniera se construyen modelos, en
realidad,simplificaciones de la realidad, para comprender mejor el
sistema que vamos adesarrollar: los arquitectos utilizan y
construyen planos (modelos) de los edificios, los grandes
diseadores de coches preparan modelos en sistemas existentes con
todoslos detalles y los ingenieros de software deberan igualmente
construir modelos delos sistemas software.
2.4.2. Caractersticas del RUP
Proceso Dirigido por los Casos de Uso: Con esto se refiere a la
utilizacin de los Casos de Uso para el desenvolvimiento y
desarrollo de las disciplinas con los artefactos, roles y
actividades necesarias. Los Casos de Uso son la base para la
implementacin de las fases y disciplinas del RUP.
Un Caso de Uso es una secuencia de pasos a seguir para la
realizacin de un fin o propsito, y se relaciona directamente con
los requerimientos, ya que un Caso deUso es la secuencia de pasos
que con lleva la realizacin e implementacin de un Requerimiento
planteado por el Cliente.
Proceso Iterativo e Incremental: Es el modelo utilizado por RUP
para el desarrollo de un proyecto de software. Este modelo plantea
la implementacin del proyecto a realizar en Iteraciones, con lo
cual se pueden definir objetivos por cumplir en cada iteracin y as
poder ir completando todo el proyecto iteracin por iteracin, con lo
cual se tienen varias ventajas, entre ellas se puede mencionar la
de tener pequeos avances del proyecto que son entregables al
cliente el cual puede probar mientras se est desarrollando otra
iteracin del proyecto, con lo cual el proyecto va creciendo hasta
completarlo en su totalidad.
Proceso Centrado en la Arquitectura: Define la Arquitectura de
un sistema, y una arquitectura ejecutable construida como un
prototipo evolutivo.
Arquitectura de un sistema es la organizacin o estructura de sus
partes ms relevantes. Una arquitectura ejecutable es una
implementacin parcial del sistema, refinamientos sucesivos de una
arquitectura ejecutable, construida como un prototipo
evolutivo.
RUP se divide en 4 fases,dentrodelascualesserealizanvarias
iteraciones segn el proyecto y en las que se hace mayor o menor
esfuerzo en las distintas actividades. En las iteraciones de cada
fase se hacen diferentes esfuerzos en diferentes actividades:
a) Fase de Inicio (Inspeccin y Concepcin)
Se hace un plan de fases, donde se identifican los principales
casos de uso y se identifican los riesgos. Se concreta la idea, la
visin del producto, como se enmarca en el negocio, el alcance del
proyecto.
b) FasedeElaboracin:
Se realiza el plan de proyecto, donde se completan los casos de
uso y se mitigan los riesgos. Planificar las actividades necesarias
y los recursos requeridos, especificando las caractersticas y el
diseo de la arquitectura.
c) FasedeConstruccin:
Sebasaenlaelaboracindeunproducto totalmente operativo y en la
elaboracin del manual deusuario. Construir el producto, la
arquitectura y los planes, hasta que el producto est listo para ser
enviado a la comunidad de usuarios.
d) Fase de Transicin:
Se realiza la instalacin del producto en el cliente y se procede
al entrenamiento de los usuarios. Realizar la transicin del
producto a los usuarios, lo cual incluye: manufactura, envi,
entrenamiento, soporte y mantenimiento del producto, hasta que el
cliente quede satisfecho, por tanto en esta fase suelen ocurrir
cambios. Con estas fases se logra ejecutar un conjunto de mejores
prcticas, como lo son:
Desarrollar Software Iterativamente
Modelar el software visualmente
Gerenciar los Requerimientos
Usar arquitecturas basadas en componentes
Verificacincontina de la calidad
Gerenciar los cambios
Ver Figura 11 donde se observan las interacciones entre las
etapas de RUP.
(Figura 11: Interacciones entre etapas de la Metodologa RUP)
2.4.3. Descripcin de las Fases
Dependiendo de la iteracin del proceso el equipo de desarrollo
puede realizar diferentes tipos de actividades. Veamos de qu trata
cada fase.
a) Fase de Inicio: Durante la fase de inicio las iteraciones
hacen poner mayornfasis en actividades modelado del negocio y de
requisitos.
En esta fase se realizan los siguientes pasos:
Un documento con la visin del proyecto.
El modelo de Casos de Uso con una lista de todos los Casos de
Uso y los actores que puedan ser identificados.
Un glosario inicial del proyecto.
Un Caso de Uso inicial de Negocio el cual incluye: contexto del
negocio,criterios de xito y planificacin financiera.
Un estudio inicial de riesgos.
Un plan del proyecto que muestre las fases y las
iteraciones.
El objetivo de esta fase, y el establecer el modelo de negocio
es entenderlas funciones de la organizacin del cliente, tanto en
estructura como en susprocesos. Su objetivo es modelar funciones y
roles que realiza la organizacin para realizar ms fcilmente la
reingeniera de procesos o la implantacin del nuevo sistema. Tambin
se describe lo que el sistema tendra que realizar y permitir que
los desarrolladores y el cliente estn de acuerdo con esta
descripcin.
Para ello se realizarn las siguientes sub-fases:
Describirlosrequerimientosfuncionalesynofuncionales(rendimiento
esperado, plataformas soportadas, integracin con sistemas externos,
etc.).
Capturarunglosarioovocabulariodelsistemaoproyecto(mediante
documento y clases conceptuales).
Encontrar actores y casos de uso.
Describirloscasosdeusomediantesuflujoprincipal,variacionesy
excepciones.
Asignar prioridades a loscasos de uso encontrados para poder
planificar la iteracin en forma de anlisis, diseo e
implementacin.
Modelar la interfaz de usuario (diseo lgico).
Prototipo de la interfaz de usuario (diseo fsico).
b) Fase de Elaboracin: En esta fase las iteraciones se orientan
al desarrollo de la arquitectura, que incluye los flujos de trabajo
de requerimientos, modelo de negocios (refinamiento), anlisis,
diseo y una parte de implementacin orientado a la arquitectura.
En esta fase se realizan las siguientes sub-fases:
Un modelo de Casos de Uso con todos los actores identificados y
la mayorparte de las descripciones de Casos de Uso.
Requerimientos adicionales: no funcionales o
pseudorequerimientos.
Descripcin de la arquitectura del software.
Prototipo ejecutable de arquitectura.
Una lista revisada de riesgos.
Plan del proyecto, incluyendo iteraciones y criterios de
evaluacin para cada iteracin.
Manual preliminar de usuario.
En esta fase se especifican los requerimientos y se describen
sobre cmo se van a implementar en el sistema: transformar los
requisitos al diseo del sistema, desarrollar una arquitectura para
el sistema, y adaptar el diseo para que sea consistente con el
entorno de implementacin.
c) Fase de Construccin: Se implementan las clases y objetos en
ficheros fuente, binarios, ejecutablesydems.
Elresultadofinalesunsistemaejecutable.
Para ello se realizarn las siguientes sub-fases:
El producto de software integrado sobre la plataforma
adecuada.
Los manuales de usuario.
Una descripcin de la versin actual.
Planificar qu subsistemas deben ser implementados y en qu orden
deben ser integrados, formando el Plan de Integracin.
Cada implementador decide en qu orden implementa los elementos
del subsistema.
Si encuentra errores de diseo, los notifica.
Se integra el sistema siguiendo el plan.
En la parte de Pruebas se evala la calidad del producto, pero no
para aceptaro rechazar el producto al final del proceso de
desarrollo, sino que debe ir integrado en todo el ciclo de vida. Se
deben encontrar y documentar defectos en la calidad delsoftware.
Generalmente asesora sobrelacalidaddelsoftwarepercibida, provee la
validacin de los supuestos realizados en el diseo y especificacin
de requisitos por medio de demostraciones concretas, verificar las
funciones del producto de software segn lo diseado y que los
requisitos tengan su apropiada implementacin.
En la parte de despliegue se produce con xito distribuciones del
producto y distribuirlo a los usuarios. Las actividades implicadas
incluyen:
Probar el producto en su entorno de ejecucin final.
Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.
Durantetodo el proyecto se ejecutan las fases de gestin del
proyecto, donde se vigila el cumplimiento de los objetivos, gestin
de riesgos y restricciones para desarrollar un producto que sea
acorde a los requisitos de los clientes y los usuarios. En la cual
se realizan las tareas:
Proveerunmarcodetrabajoparalagestindeproyectosdesoftware
intensivos.
Proveer guas prcticas realizar planeacin, contratar personal,
ejecutar y monitorear el proyecto.
Proveer un marco de trabajo para gestionar riesgos.
En la fase de configuracin y control de cambios, permite
mantener la integridad de todos que se crean en el proceso, as como
de mantener informacin del proceso evolutivo que han seguido.
En la fase del Entorno, la finalidad es dar soporte al proyecto
con las adecuadas herramientas, procesos y mtodos. Brinda una
especificacin de las herramientas que se van a necesitar en cada
momento, as como definir la instancia concreta del proceso que se
va a seguir. En concreto las responsabilidades de este flujo de
trabajo incluyen:
Seleccin y adquisicin de herramientas
Establecer y configurar las herramientas para que se ajusten a
la organizacin.
Configuracin del proceso.
Mejora del proceso.
Servicios tcnicos.
Los Roles que se cumplen en el RUP:
I. Analistas:
Analista de procesos de negocio
Diseador del negocio
Analista de sistema
Especificador de requisitos
II. Desarrolladores:
Arquitecto de software
Diseador
Diseador de interfaz de usuario
Diseador de cpsulas
Diseador de base de datos
Implementador
Integrador
III. Gestores:
Jefe de proyecto
Jefe de control de cambios.
Jefe de configuracin.
Jefe de pruebas
Jefe de despliegue
Ingeniero de procesos
Revisor de gestin del proyecto
Gestor de pruebas
IV. Apoyo:
Documentador tcnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista grfico
V. Especialista en pruebas:
Especialista en Pruebas (tester)
Analista de pruebas
Diseador de pruebas
VI. Otros roles:
Stakeholders
Revisor
Coordinacin de revisiones
Revisor tcnico
Cualquier rol
Para grandes organizaciones con un nmeros equipos de ingenieros
y la comunicacin entre cada equipo es crtica por lo tanto es
necesario que los artefactos sean completos y bastante
comprensivos
En tanto que para pequeos proyectos no es recomendable
presentarse tanto rigor en las preparaciones de los artefactos, la
eficiencia del proceso depende ms de las habilidades de cada
trabajador
2.4.4. Beneficios de la Metodologa Orientada a Objetos
Promueve la reusabilidad.
Reduce la complejidad del mantenimiento (extensibilidad y
facilidad de cambios).
Riqueza semntica.
Disminuye la brecha semntica entre la visin interna y la visin
externa del sistema.
Facilita la construccin de prototipos.
2.4.5. Ventajas de la Metodologa Orientada a Objetos
Reutilizacin
El diseador piensa en trminos del comportamiento de objetos y no
en detalles de bajo nivel
Confiabilidad, Integridad y Estabilidad
Mantenimiento ms sencillo. Modificaciones locales
Modelado ms realista.
Modelos empresariales inteligentes.
Independencia del diseo.
Mejores herramientas CASE.
Bibliotecas de clases para las empresas.
Se construyen clases cada vez ms complejas.
Nuevos mercados para el software.
Diseo de mayor calidad.
Programacin ms sencilla.
Mejor comunicacin entre los profesionales de los Sistemas de
Informacin y los empresarios.
Mayor nivel de automatizacin de las bases de datos.
La comprensin del sistema es ms fcil porque la semntica entre el
sistema y la realidad son similares.
2.5. HIPOTESIS
Simulando el control de los buses mediante el uso de un sistema
de informacin en conexin con GPS, se espera mejorar el servicio de
transporte pblico de una lnea de bus para los usuarios de Lima
Metropolitana
2.5.1. VARIABLES INDEPENDIENTES
Uso de la aplicacin costo de viaje
Uso de las consulta sobre el tiempo aproximado de un bus para
llegar a un paradero respectivo
Diseo del sistema
2.5.2. VARIABLES DEPENDIENTES
Efectividad de las consultas
Flexibilidad del sistema
3. MARCO METODOLGICO
3.1. Metodologa para el anlisis y diseo de la solucin
Con esta metodologa se pretende disear un sistema que pueda
satisfacer los requerimientos bsicos y necesarios de los usuarios a
quienes esta dirigido esta investigacin, adems de hacer que este
sea lo ms flexible de manera que se pueda adaptar a los distintos
cambios que se pueda producir en cualquier situacin o momento. Para
ellos se desarrollar las siguientes fases que involucran esta
metodologa.
3.1.1. Fase de Inicio
Para el desarrollo del presente trabajo solo se llegar hasta la
fase de elaboracin ya que solo se est haciendo el diseo del
sistema
Visin del proyecto
Con este documento se definir cual es el propsito, el alcance y
limitaciones de la presente investigacin para darnos la orientacin
adecuada de lo que queremos lograr con este.
Para la realizacin de este documento se utilizara el programa
Microsoft Word 2010.
Plan de Proyecto
Con este plan se mostraran las fases que se realizaran para esa
investigacin as como las iteraciones de acuerdo a un cronograma
establecido para cada una de las fases.
Esto se llevara a cabo utilizando el Microsoft Project 2010.
3.1.2. Fase de Elaboracin
En esta fase se desarrollaran los siguientes diagramas que se
involucran y relacionan hasta el diseo del proyecto:
Diagrama de Caso de Uso
Con este diagrama se podr modelar las funcionalidades del
sistema agrupndola en descripciones de acciones ejecutadas por el
sistema para obtener un resultado.
Para su elaboracin se podr utilizar cualquiera de estas
herramientas: Microsoft Visual Studio 2010 o Rational Rose
Diagrama de Secuencia
Este diagrama permite describir la interaccin entre obejtos de
una aplicacin y los mensajes recibidos y enviados por los objetos,
es decir permite describir los pasos que se realizan en cada uno de
los casos de uso
Se utilizar cualquiera de las siguientes herramientas Microsoft
Visual Studio 2010 o Rational Rose.
Diagrama de Colaboracin
Este diagrama es una forma alterna de representar la interaccin
entre objetos al diagrama de secuencia, pero a diferencia de este
puede mostrar el contexto de la operacin y ciclos de ejecucin.
Este diagrama tambin se podr elaborar utilizando cualquiera de
las siguientes herramientas: Microsoft Visual Studio o Rational
Rose
Diagrama de Estado
Muestra el conjunto de estados por los cuales pasa un objeto
durante su vida en una aplicacin, junto con los cambios que
permiten pasar de un estado a otro.
Tambin este diagrama se puede elaborar con el programa Microsoft
Visual Studio o Rational Rose
Diagrama Entidad-Relacin
Este diagrama es para el modelado de datos que permite
representar las entidades relevantes de un sistema de informacin as
como sus interrelaciones y propiedades.
Este diagrama se puede modelar con el Microsoft Visual Studio o
Rational Rose.
1.
2.
3.
3.1.
3.1.1.
3.2. Metodologa para el estudio de factibilidad (viabilidad) de
la solucin
3.2.1. Investigacin Cualitativa
Realizando este tipo de investigacin se podr estudiar la
productividad del servicio que ofrecen estas empresas actualmente,
para luego compararlas con el estudio que se haga a este servicio
pero con la aplicacin de la presente investigacin evaluando las
mejoras q se haga para cada uno de los factores o parmetros con que
se estudia la productividad del servicio, para de esta manera
demostrar la viabilidad de esta investigacin, para ello se llevar a
cabo una recoleccin de datos definiendo el universo, tcnica,
instrumento mtodo de recoleccin y donde adems como se calcular la
muestra con el que se realizara este tipo de investigacin
3.2.1.1. Universo
Est constituido por un total de 8 445,211 sujetos de estudio,
compuesto por todos los habitantes en el departamento de Lima.
3.2.1.2. Muestra
Para saber el tamao de la muestra que se va a tomar para este
tipo de investigacin (Cualitativa) se emplear la siguiente
frmula:
Dnde:
n = Tamao de la muestra.
N = Poblacin
Z = Valor crtico correspondiente a un coeficiente de confianza
del cual se deseahacer la investigacin.
P = Proporcional de ocurrencia de un evento.
Q = Proporcin de no ocurrencia de un evento o fracaso.
E = grado de error.
3.2.1.3. Tcnica
La tcnica que se empleara para la recoleccin de datos ser la
encuesta
Encuesta
Tcnica utilizada para obtener informacin de una muestra de
individuos. Esta
Muestra es usualmente slo una fraccin de la poblacin bajo
estudio.
3.2.1.4. Instrumento
El instrumento que se emplear para la recoleccin de datos ser el
cuestionario.
Cuestionario
Instrumento utilizado para la obtencin de informacin constituida
por un conjunto de preguntas abiertas o cerradas orientadas a
obtener informacin especfica de lo que se investiga.
3.2.1.5. Mtodo de recoleccin de datos
Para la realizacin de este tipo de investigacin se emplear el
mtodo Estadstico, ya que esta ciencia matemtica nos proporciona las
herramientas necesarias para la recoleccin, estudio e interpretacin
de los datos obtenidos mediante grficos, para luego analizar cada
uno de los resultados obtenidos.
(Figura 12: Ejemplo de la aplicacin del Mtodo Estadstico)
3.2.2. Impacto Econmico
El siguiente estudio se empezar a realizar en cuando se lleve a
cabo la implementacin de esta investigacin, el cual el actual solo
abarca hasta el diseo, en donde se ver los recursos que se utilizar
como recursos de software, recursos de hardware, recurso humano,
entre otros, para luego calcular en cuanto tiempo la entidad que
realice la implementacin podr recuperar su inversin o de qu manera
esta empezara a obtener mayores ingresos, teniendo en cuenta los
costos q se reducirn o que ya no se usaran para obtener este.
3.2.3. Viabilidad Legal
Dentro del marco legal no se encuentra impedimentos en el
desarrollo de un sistema siempre y cuando se cumpla con la
documentacin de buenas prcticas creadas por la W3C.
Y adems de tener en cuenta las leyes que estn sobre la empresa a
la cual se le est implementando el proyecto.
4. ASPECTOS ADMINISTRATIVOS
4.1. ndice Preliminar de la tesis
INDICE
Introduccin
Lista de Tablas
Lista de Figuras
Resumen
Abstract
CAPITULO I
1. INTRODUCCIN
0. Motivacin y Justificacin
0. Planteamiento del Problema
0. Propuesta de Solucin
0. Alcance de la Propuesta
0. Justificacin
0. Antecedentes de Solucin
1. Nacionales
1. Internacionales
0. Objetivos
2. Objetivo general
2. Objetivos Especficos
CAPITULO II
1. MARCO TERICO
1. Programacin Web
0. Protocolo http (Protocolo de Transferencia de Hipertexto)
0. Comunicacin entre el navegador y el servidor web
0. Arquitectura del WWW
2. URLs.
2. HTML
2. Desarrollo de aplicaciones web
2. Lenguajes de programacin del lado del cliente
2. Lenguajes de programacin del lado del servidor
2. Metodologas para el desarrollo de aplicaciones web
2. Aspectos de seguridad.
1. Marco Normativo
1. Sistemas y Programacin
0. Polticas para la elaboracin de sistemas
0. Polticas
0. Normas para la elaboracin de Sistemas
1. Objetivo
1. Normas Generales
1. Normas para el anlisis de sistemas:
1. Normas para el diseo de sistemas
1. Normas para la programacin y documentacin de sistemas
1. Normas para la implantacin de sistemas y capacitacin
1. Normas para el mantenimiento de sistemas
0. Polticas Generales De Seguridad Informtica
0. Normas especficas para la seguridad de informacin
3. Del Acceso a la Informacin
3. De la Proteccin Especial de la Informacin
3. De la Integridad de la Informacin
3. Seguridad de la Informacin
1. Metodologa RUP
2. Caractersticas del RUP
2. Descripcin de las Fases
2. Beneficios
2. Ventajas
1. Marco Metodolgico del Modelo de validacin
CAPITULO III
1. DISEO DE LA SOLUCIN
2. Metodologa RUP
0. Fase de Inicio
0. Fase De Elaboracin
2. Analizar el Problema
2. Diseo de la propuesta
CAPITULO IV
1. VALIDACIN DEL MODELO
3. Instrumentos y Tcnicas
0. Universo
0. Muestra
0. Tcnica
0. Instrumento
0. Mtodo Recoleccin de Datos
3. Anlisis de Datos
CAPITULO V
1. CONCLUSIONES Y RECOMENDACIONES
4.2. Presupuesto y Cronograma de Actividades
4.2.1. Presupuesto
RECURSOS PARA EL DESARROLLO DE LA INVESTIGACIN
Recurso de Software
Cantidad
Costo Unitario
Subtotal
CD Windows 7 Ultimate
1 unid.
S/.5.00
S/.5.00
CD Visual Studio 2010 Ultimate
1 unid.
S/. 5.00
S/. 5.00
CD SQLServer 2008
1 unid.
S/. 5.00
S/. 5.00
Recurso de Material
Cantidad/Tiempo
Costo Unitario
Subtotal
Impresiones
Avance 1- PIS I
2 unid.
S/. 6.00
S/. 12.00
Avance 3 - PIS I
2 unid.
S/.5.00
S/. 10.00
Informe Tesis Final - PIS I
