pis1.wikispaces.compis1.wikispaces.com/file/view/Informe+Final+de+Tesis.d… · Web viewTiene que...
111
UNIVERSIDAD TECNOLÓGICA DEL PERÚ FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS DISEÑO DE UN SISTEMA DE INFORMACIÓN PARA LA MEJORA DEL SERVICIO DE UNA EMPRESA DE TRANSPORTE PÚBLICO EN LIMA METROPOLITANA Presentado por: CIUDAD GAYOSO, Brayan Junior VERASTEGUI AVILA, David Orlando Asesor: Msc. KrugerSarapura Yupanqui. LIMA 2012
Transcript of pis1.wikispaces.compis1.wikispaces.com/file/view/Informe+Final+de+Tesis.d… · Web viewTiene que...
UNIVERSIDAD TECNOLÓGICA DEL PERÚ
FACULTAD DE INGENIERÍA INDUSTRIAL Y DE SISTEMAS
DISEÑO DE UN SISTEMA DE INFORMACIÓN PARA LA MEJORA DEL SERVICIO
DE UNA EMPRESA DE TRANSPORTE PÚBLICO EN LIMA METROPOLITANA
Presentado por:
CIUDAD GAYOSO, Brayan Junior
VERASTEGUI AVILA, David Orlando
Asesor:
Msc. KrugerSarapura Yupanqui.
LIMA
2012
INTRODUCCIÓN
En la actualidad, el servicio que ofrece las empresas de transporte público en la ciudad de Lima
Metropolitana, se ha vuelto deplorable debido a la mala gestión de la empresa para controlar este
servicio y el mal desempeño por parte de los conductores, donde los principales perjudicados son
los peatones por el uso de los vehículos de transporte de estas empresas, y por la dependencia
hacia estos como su principal medio de transporte. Por ende, la decisión de buscar otros medios
se ha vuelto común para la necesidad de movilización hacia un destino fijado por parte de los
usuarios.
Por ello esta investigación está dirigida a mejorar el servicio brindado a los peatones en la ciudad
de Lima Metropolitana, mediante el diseño 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, dándoles una mayor satisfacción al mejorar este servicio.
2 | P á g i n a
LISTA DE FIGURAS
Figura1: Linea de Autobuses de EMT.................................................................................10
Figura2: Interfaz del mapa interactivo "Navega por Madrid"............................................11
Figura3: Diseño del sistema automatizado de Transporte....................................................13
Figura 4: Comunicación entre el navegador y el servidor Web............................................16
Figura 5: Arquitectura del www...........................................................................................19
Ilustración 6: Arquitectura Multinivel.................................................................................20
Figura 7: Uso del Motor de PHP...........................................................................................22
Figura 8: En Julio ingresaron 56 buses nuevos a la ruta......................................................26
Figura 9: Tramo 1, red básica de tramo...............................................................................28
Figura 10: Interfaz del mapa interactivo "Navega por Madrid".........................................29
Figura 11: Interacciones entre etapas de la Metodología RUP.............................................50
Figura 12: Ejemplo de la aplicación del Método Estadístico................................................61
3 | P á g i n a
INDICE GENERAL
INTRODUCCIÓN..........................................................................................................................2LISTA DE FIGURAS......................................................................................................................31. FORMULACIÓN DEL PROBLEMA..................................................................................71.1. Planteamiento del Problema...........................................................................................71.2. Antecedentes de Solución................................................................................................81.2.1. Nacionales.....................................................................................................................81.2.2. Internacionales.............................................................................................................91.3. Propuesta de Solución...................................................................................................131.4. Alcance de la Propuesta................................................................................................141.5. Justificación....................................................................................................................141.6. Objetivos.........................................................................................................................151.6.1. Objetivos General.......................................................................................................151.6.2. Objetivos Específicos.................................................................................................152. MARCO TEÓRICO.............................................................................................................152.1. PROGRAMACIÓN WEB................................................................................................152.1.1. Protocolo HTTP (Protocolo de Transferencia de Hipertexto)................................152.1.2. Comunicación entre el navegador y el servidor web..................................................162.1.3. Arquitectura del WWW................................................................................................182.1.4. HTML.............................................................................................................................192.1.5. Desarrollo de aplicaciones web.....................................................................................202.1.5.1. Lenguajes de programación del lado del cliente.....................................................202.1.5.2. Lenguajes de programación del lado del servidor..................................................212.1.5.3. Metodologías para el desarrollo de aplicaciones web.............................................222.1.5.3.1. Aspectos de seguridad............................................................................................242.2. MARCO REFERENCIAL...............................................................................................242.2.1. Antecedentes:.................................................................................................................252.2.1.1. Nacionales...................................................................................................................252.2.1.2. Internacionales...........................................................................................................282.3. MARCO NORMATIVO...................................................................................................302.3.1. Políticas para la elaboración de sistemas.....................................................................302.3.2. Normas para la elaboración de Sistemas.....................................................................33
4 | P á g i n a
2.3.2.1. Objetivo:......................................................................................................................332.3.2.2. Normas Generales:.....................................................................................................332.3.2.3. Normas para el análisis de sistemas:.........................................................................352.3.2.4. Normas para el diseño de sistemas............................................................................352.3.2.5. Normas para la programación y documentación de sistemas.................................362.3.2.6. Normas para la implantación de sistemas y capacitación.......................................372.3.2.7. Normas para el mantenimiento de sistemas.............................................................382.3.3. Políticas Generales De Seguridad Informática...........................................................392.3.3.1. Del Departamento de Redes y Comunicaciones......................................................392.3.3.2. De los Administradores de red..................................................................................402.3.3.3. Del Departamento de Soporte Técnico.....................................................................412.3.3.4. Del Personal................................................................................................................412.3.4. Normas específicas para la seguridad de información...............................................422.3.4.1. Del Acceso a la Información......................................................................................422.3.4.2. De la Protección Especial de la Información...........................................................442.3.4.3. De la Integridad de la Información..........................................................................442.3.4.4. Seguridad de la Información.....................................................................................462.4. METODOLOGÍA RUP....................................................................................................462.4.1. UML................................................................................................................................472.4.2. Características del RUP................................................................................................472.4.3. Descripción de las Fases................................................................................................502.4.4. Beneficios de la Metodología Orientada a Objetos.....................................................552.4.5. Ventajas de la Metodología Orientada a Objetos.......................................................562.5. HIPOTESIS........................................................................................................................562.5.1. VARIABLES INDEPENDIENTES..............................................................................572.5.2. VARIABLES DEPENDIENTES..................................................................................573. MARCO METODOLÓGICO.............................................................................................573.1. Metodología para el análisis y diseño de la solución......................................................573.1.1. Fase de Inicio..................................................................................................................573.1.2. Fase de Elaboración.......................................................................................................583.2. Metodología para el estudio de factibilidad (viabilidad) de la solución.......................593.2.1. Investigación Cualitativa...............................................................................................593.2.1.1. Universo......................................................................................................................593.2.1.2. Muestra.......................................................................................................................59
5 | P á g i n a
3.2.1.3. Técnica........................................................................................................................603.2.1.4. Instrumento................................................................................................................603.2.1.5. Método de recolección de datos................................................................................603.2.2. Impacto Económico.......................................................................................................613.2.3. Viabilidad Legal.............................................................................................................614. ASPECTOS ADMINISTRATIVOS.......................................................................................614.1. Índice Preliminar de Tesis……...……………………………......…………......................61
4.2. Presupuesto y Cronograma de Actividades ……………………………………...………64
4.2.1. Presupuesto……..……………………………………………………...………………....64
4.2.2 Cronograma..……………………………………………………………………………...65
REFERENCIAS...........................................................................................................................67
6 | P á g i n a
1. FORMULACIÓN DEL PROBLEMA
1.1. Planteamiento del Problema
A lo largo de nuestra vida hemos estado en contacto con diversos problemas sociales,
políticos, económicos, laborales, etc.; entre los cuales uno de los principales es el tema
del transporte. Hoy en día el desplazamiento mediante el uso del transporte público
urbano en la ciudad de Lima Metropolitana ha afectado a la población limeña, debido a
que el tamaño del parque automotor de Lima Metropolitana es actualmente más de 1.5
millones de vehículos y está creciendo a una tasa de 15% anual1, el 45,9% de capitalinos
está fastidiado por el ineficiente servicio de transporte público limeño2, produciendo
incomodidad y malestar en los peatones que son los ciudadanos.
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 selección nos hacemos diversas preguntas: ¿A
qué hora pasará el bus?, ¿Cuánto más debo esperar?, ¿Pagaré más de lo que pago?,
¿Cuánto puedo gastar?, así como otras interrogantes; todo esto debido a la gran
incertidumbre del servicio que brinda el transporte público.
Dentro de esta problemática que se ha ido alimentando en el transcurso del tiempo, hay
factores que están directamente relacionados con el usuario (peatón), los cuales son el
tiempo pero en la encuesta realizada en el 2011 el 21,5% de limeños considera que se
demora menos tiempo3 para movilizarse por la ciudad que en el 2010 pero no todos los
limeños son acreedores de estos beneficios, otro de ellos es el sistema de tarifa y los
horarios de servicio. El factor tiempo es el más crítico 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 líneas de
transporte están 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.
1http://blog.pucp.edu.pe/item/159841/el-problema-del-transporte-urbano-en-lima-metropolitana2 Diario la República, http://www.larepublica.pe/17-01-2012/inseguridad-y-transporte-los-principales-problemas-de-nuestra-capital3 Diario la República, http://www.larepublica.pe/17-01-2012/inseguridad-y-transporte-los-principales-problemas-de-nuestra-capital
7 | P á g i n a
En las diferentes toma de decisiones de los usuarios, el tiempo de espera, que es el factor
más considerado, seguido del tiempo de viaje son los más contribuyentes para elegir la
opción correcta más factible en relación a las diferentes situaciones o realidades de los
ciudadanos ya que consideramos la posibilidad que en muchos de estas alternativas se
llegue a la utilización de más recursos, especialmente el económico, 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 reducción del tiempo de espera de los buses de los
cuales el 22%4 de limeños prefieren usar dicho medio de transporte, así como el de tener
un mejor sistema tarifario permitiendo una mejor relación usuario-transporte, y además
contribuya a una mejora en cuanto al servicio de transporte.
1.2. Antecedentes de Solución
1.2.1. Nacionales
Años atrás, el transporte urbano no era un problema crítico el cual hoy en día se enfoca
como uno de los principales problemas de Lima Metropolitana, el tráfico 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 década de los 90, el Perú se ha visto afectado por el incremento de la tasa
de desempleo que género que los desempleados encontraran en el transporte público una
manera de poder subsistir, generando actualmente una sobre oferta del 40%, ya sean
combis, ómnibus o custers. En consecuencia, el tráfico en Lima Metropolitana se ha
vuelto muy caótico y denso, y eso se observa principalmente en horas específicas, que es
4 Diario la República, http://www.larepublica.pe/17-01-2012/inseguridad-y-transporte-los-principales-problemas-de-nuestra-capital
8 | P á g i n a
cuando se generan las congestiones vehiculares, también 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 disminución del
tráfico vehicular en Lima y otros a la creación de nuevas vías alternas para el transporte
como Vía Expresa, “By Pass”; o creación de nuevas modalidades de transporte como el
Metropolitano o el Tren Eléctrico, pero la gran mayoría no han sido soluciones factibles
o deseables, ya que no se ha visto un cambio notorio; además de la falta de cultura y
atención de las ciudadanos, policías, 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 Eléctrico son dos proyectos que se implementaron como una
opción a los ciudadanos para movilizarse de una manera más rápida, 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), además estas no llegan a toda la
población a pesar que mucha gente los utiliza, aún hay una gran porcentaje de la
población que sigue utilizando el transporte público, lo que nos da a entender que estos
proyectos no fueron diseñados para mejorar el tema del tráfico vehicular, sino como
solución alternativa de trasladarse evitando el tráfico vehicular.
1.2.2. Internacionales
La Empresa Municipal de Transportes de Madrid es una sociedad anónima,
propiedad del Ayuntamiento de Madrid, encargada de la prestación del servicio de
transporte público urbano colectivo de superficie mediante autobús en la ciudad de
Madrid.
La EMT cuenta con una flota de 2.068 autobuses para explotar un total de 216
líneas. De las 216 líneas que opera la EMT, 171 líneas son convencionales
diurnas; 7 son líneas universitarias que sólo prestan servicio en periodo lectivo, 26
son líneas nocturnas convencionales y 12 son líneas nocturnas de ‘Metrobúhos’.
9 | P á g i n a
La EMT de Madrid pionera en la aplicación de nuevas tecnologías ha puesto en
marcha un mapa interactivo al que puedes acceder mediante internet, llamada
“Navega por Madrid”5, en donde usted mediante el uso de estas herramientas
podrá realizar lo siguiente:
Calcular itinerarios personalizados en autobús por la ciudad de Madrid
Consultar líneas que pasan por un punto concreto de la ciudad
Consultar tiempos de espera en paradas
Consultar itinerarios de las líneas de EMT
Consultar incidencias de servicio en tiempo real
5Navega por Madrid (EMT Madrid, España). Una de las interfaces de una aplicación móvil dirigida a los habitantes de Madrid
10 | P á g i n a
Figura2: Interfaz del mapa interactivo "Navega por Madrid"
También ha desarrollado un conjunto de aplicaciones y servicios disponibles
desde cualquier dispositivo móvil que podrás ingresar mediante tu Smartphone,
mediante dicho aplicativo se pueden realizar diferentes tipos de funcionalidades,
preguntándose ¿Dónde estoy? ¿Cómo 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, también brinda las mejores rutas de
trasladarse de un lugar a otro, también muestra en forma detallada la atención de
líneas de buses disponibles durante cada día.
En la aplicación EMTMADRID para IPhone podemos encontrar una utilidad
llamada Realidad Aumentada, a través de la cual tendrás acceso a la información
que se superpone en la imagen captada desde la cámara del dispositivo,
geolocalizando las paradas de autobús más cercanas así como diversos sitios de
interés, donde el usuario se orientara con una visión de 360º visualizando las
paradas, los tiempos de espera y a qué distancia están.
Gracias a esta aplicación las personas se podrán movilizar por Madrid sin
necesidad de tener un conocimiento detallado de la ciudad.
Por otra parte, la empresa Smartmatic es una compañía multinacional que diseña y
despliega soluciones que permite a los organismos gubernamentales y a grandes
empresas cumplir con sus ciudadanos de la manera más eficiente posible.
11 | P á g i n a
Uno de los proyectos realizados por Smartmatic es un Sistemas para la
Automatización del Recaudo de Pasajes, Gestión de Flotas e Información al
Usuario para TransCaribe, Cartagena de Indias, Colombia.
12 | P á g i n a
Tabla 1: Transporte Masivo Cartagena De Indias
POBLACIÓN
ATENDIDA:1.200.000
Vehículos de pasajeros por
año:220.000.000
VEHÍCULOS: 719 buses
Para el servicio troncal 111
Alimentadores 405
Auxiliares 204
PUNTOS DE VENTA 634
ESTACIONES
TRONCALES17
Este sistema comprende el servicio de la gestión de todos los aspectos relativos a
la recolección de pasajes, incluyendo la producción y distribución de tarjetas, los
equipos de a bordo de los nuevos autobuses, un centro de control de operaciones
para consolidar y gestionar toda la información, y comunicaciones GSM y vía
enlaces de radio troncalizados, utilizando redes privadas y públicas.
El sistema contara con boletería electrónica basado en tarjetas inteligentes con la
tecnología en software y hardware más avanzada en la industria. En Cartagena,
Smartmatic se encargara de suministrar, dar mantenimiento y de la operación de
los equipos, las flotas de autobuses y paneles de información para los pasajeros
tanto en los buses como estaciones.
1.3. Propuesta de Solución
La presente investigación que se plantea, está orientada al diseño de un sistema de
información para proporcionar información 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 línea de bus, y los paraderos en el recorrido
de esta línea, indicando donde debe de parar este y donde el usuario debe de bajar13 | P á g i n a
Figura3: Diseño del sistema automatizado de Transporte
Indicar los horarios que esta línea de bus pasa por cada uno de los paraderos y
puntos de control
Tener una aplicación que permita mostrar el tiempo que se demora la línea de bus
entre dos paraderos respectivos para el uso y conocimiento del usuario
Tener una aplicación que permite mostrar al usuario la cantidad que debe de
pagar por su viaje, indicando en donde abordará la línea 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 página, es decir poder gestionar los horarios, el tiempo de
un viaje y el tarifario de acuerdo a las políticas o acciones de la empresa
Con estas características, el usuario tendrá mayor facilidad al acceso de información de
este servicio y de una manera más rápida a través de la conexión a Internet, ya sea por un
computador o móvil.
1.4. Alcance de la Propuesta
El alcance de la presente investigación centra su atención en la ciudad de Lima
Metropolitana, lugar donde transitan más de 34 mil vehículos (buses, cústeres y combis)
según el diario la República, y donde se concentra la mayor cantidad de personas en el
país, siendo esta cifra más de 8, 432 mil habitantes lo que equivale al 28,14% de la
población nacional, esto según un informe de la INEI (Instituto Nacional de Estadísticas
e Informática) hecho a principios del año.
Por estas razones, el impacto de nuestra investigación tendrá un mayor efecto sinérgico y
beneficiara a muchos peatones que residen en la ciudad a tomarla como lugar de estudio;
por otra parte la aplicación del proyecto está dirigida a las empresas de transporte público
que cuenten como únicos vehículos los buses, ya que este tipo de vehículo es muy poco
informal a diferencia de los otros (custeres o combis).
1.5. Justificación
Actualmente en Lima Metropolitana, el ciudadano se ve inmerso en la misma situación
de todos los días y que nos afecta directa e indirectamente, que es lidiar con los servicios
que ofrece cada bus del transporte público, siendo las causas en muchos ocasiones el
14 | P á g i n a
tiempo de espera, las indeterminadas tarifas, los modos de manejo y conducción, y entre
otros que nos ocasionan insatisfacción y malestar.
Por tal motivo es que se realiza la siguiente investigación, para establecer una mejor
planificación sobre los horarios de los buses mediante un sistema en interacción con la
tecnología 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 diseño de un sistema de información que pretenda mejorar el servicio
que ofrecen las empresas de transporte público.
1.6.2. Objetivos Específicos
Simular el sistema de información en el establecimiento de los horarios por
parte de los buses
Incluir en el diseño del sistema de informaciónla aplicación costo de viaje del
usuario entre un paradero y otro, de acuerdo al tarifario de la línea de bus y de
la empresa de transporte público.
Incluir en el diseño del sistema de información una aplicación que permita
consultar el tiempo que le tomará a la línea de bus llegar a un punto específico
desde un punto fijado.
Incluir en el diseño del sistema, el manejo del mantenimiento de la
información, ya sea para el tarifario, el tiempo de viaje y los horarios de la
línea de bus.
2. MARCO TEÓRICO
A continuación se darán a conocer las diferentes teorías, conceptos, normas y referencias de los
diferentes temas abordados para el diseño de un sistema de Información del servicio orientado a
los usuarios de una empresa de transporte público, esta información fue recopilada de diferentes
15 | P á g i n a
bibliografías, artículos, documentos y linkografías para describir y explicar los temas
relacionados a la investigación.
1.
2.
2.1. PROGRAMACIÓN WEB
2.1.1. Protocolo HTTP (Protocolo de Transferencia de Hipertexto)
Desde 1990, el protocolo HTTP es el protocolo más utilizado en Internet. La
versión0.9 sólo tenía la finalidad de transferir los datos a través de Internet (en
particular páginas Web escritas en HTML). La versión 1.0 del protocolo permite la
transferencia de mensajes con encabezados que describen el contenido de los
mensajes mediante la codificación MIME (Extensiones de Correo de Internet
Multipropósito).
El propósito 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 cadena de caracteres denominada dirección URL.
2.1.2. Comunicación entre el navegador y el servidor web
La comunicación 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 después envía una respuesta HTTP
16 | P á g i n aFigura4: Comunicación entre el navegador y el servidor Web
I. Solicitud HTTP
Una solicitud HTTP es un conjunto de líneas que el navegador envía al servidor.
Incluye:
Una línea de solicitud: es una línea que especifica el tipo de documento
solicitado, el método que se aplicará y la versión del protocolo utilizada. La
línea está formada por tres elementos que deben estar separados por un
espacio:
o el método
o la dirección URL
o la versión del protocolo utilizada por el cliente (por lo general,
HTTP/1.0 )
Los campos del encabezado de solicitud: es un conjunto de líneas
opcionales que permiten aportar información adicional sobre la solicitud
y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas líneas
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 líneas opcionales que deben
estar separadas de las líneas precedentes por una línea en blanco y, por
ejemplo, permiten que se envíen datos por un comando POST durante la
transmisión de datos al servidor utilizando un formulario.
II. Respuesta HTTP
Una respuesta HTTP es un conjunto de líneas que el servidor envía al
navegador. Está constituida por:
Una línea de estado: es una línea que especifica la versión del protocolo
utilizada y el estado de la solicitud en proceso mediante un texto
explicativo y un código. La línea está formada por tres elementos que
deben estar separados por un espacio:
17 | P á g i n a
o la versión del protocolo utilizada
o el código de estado
o el significado del código
Los campos del encabezado de respuesta: es un conjunto de líneas
opcionales que permiten aportar información adicional sobre la respuesta
y/o el servidor. Cada una de estas líneas 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 aplicación Web dinámica, 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 aplicación Web estática se eliminaría 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 aplicación Web es
dinámico, el servidor Web no es capaz de responder por si solo las peticiones del
cliente Web, auxiliándose para ello del servidor de base de datos, a través un
motor de base de datos que sirve como interfaz entre ambos, el motor se encarga
de traducir el lenguaje utilizado durante la programación Web dinámica, 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 programación, mismo que deberá instalarse y
configurarse para operar de manera coordinada con el servidor Web y el servidor
de base de datos.
18 | P á g i n a
En el caso de una aplicación Web dinámica, el cliente realiza la petición 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
aplicación Web sea estática o dinámica el servidor Web siempre entregará al
cliente respuestas en formato HTML, de esta forma el cliente nunca recibirá
respuesta en el lenguaje de programación Web dinámica. Esto sirve como un
mecanismo de seguridad para evitar que el usuario del cliente Web pueda ver los
detalles de implementación ejecutados en el servidor Web utilizando el motor de
base de datos.
2.1.4. HTML
HTML es el lenguaje con el que se "escriben" la mayoría de páginas Web.
El lenguaje HTML es un estándar reconocido en todo el mundo y cuyas normas
define un organismo sin ánimo de lucro llamado World Wide Web Consortium
(http://www.w3.org/),más conocido como W3C. Como se trata de un estándar
reconocido por todas las empresas relacionadas con el mundo de Internet, una
19 | P á g i n a
Figura5: Arquitectura del www
misma página 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 información de forma global". Desde
su creación, el lenguaje HTML ha pasado de ser un lenguaje utilizado
exclusivamente para crear documentos electrónicos a ser un lenguaje que se
utiliza en muchas aplicaciones electrónicas como buscadores, tiendas en línea y
banca electrónica.
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 presentación que incluye no sólo el
navegador, sino también el servidor Web que es el responsable de dar a los datos
un formato adecuado. El segundo nivel está referido habitualmente a algún tipo de
programa o script. Finalmente, el tercer nivel proporciona al segundo los datos
necesarios para su ejecución.
Una aplicación Web típica 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).
20 | P á g i n a
Ilustración 6: Arquitectura Multinivel
2.1.5.1. Lenguajes de programación 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
interpretación del servidor
Visual Basic Script
Es un lenguaje de programación de scripts del lado del cliente, pero
sólo compatible con Internet Explorer. Es por ello que su utilización
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 están 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 versión reducida del primero.
2.1.5.2. Lenguajes de programación del lado del servidor
21 | P á g i n a
Son aquellos lenguajes que son reconocidos, ejecutados e interpretados por
el propio servidor y que se envían al cliente en un formato comprensible
para él.
Existe una multitud de lenguajes concebidos o no para Internet. Cada uno
de ellos explota más a fondo ciertas características que lo hacen más o
menos útiles para desarrollar distintas aplicaciones.
Los lenguajes del lado del servidor son invisibles para los clientes. Las
páginas que utilicen scripts de este tipo contienen el código entre etiquetas
parecidas a las de HTML, pero éstas desaparecen cuando el cliente recibe
la página. Los pasos que sigue el navegador son:
Solicita al servidor una página Web a través de Internet
El servidor comprueba si la página solicitada contiene script del
lado del servidor (PHP, ASP, JSP, etc.)
Ejecuta los posibles script y añade el resultado final a la página
Web resultante
El navegador recibe estos datos, interpreta la página Web enviada
y la muestra en la pantalla de acuerdo con la resolución del
monitor, las preferencias del usuario y algún otro factor.
Los lenguajes del lado del servidor necesitan un motor (un programa) que
interprete el código según el lenguaje de programación que se esté
utilizando.
22 | P á g i n a
2.1.5.3. Metodologías para el desarrollo de aplicaciones web
23 | P á g i n a
Figura7: Uso del Motor de PHP
Los sitios Web se presentan de todas formas y modelos, desde sencillas
páginas a megasitios que gestionan los negocios para empresas a nivel
mundial, el proceso de desarrollar un sitio implica los mismos pasos
básicos:
Conceptualizar e investigar
Esta primera fase es emocionante. Se empieza con una idea (“sitio de
venta en línea”, “ambiente virtual de aprendizaje”, “banca en línea”,
etc.) y luego realizar una lluvia de ideas sobre cómo se va a manifestar
como sitio Web. Este es el momento de las listas y bocetos, pizarras y
cuadernos. ¿Qué va hacer emociónate? ¿Qué va haber en la primera
página?
Crear y organizar contenido
La parte más importante de un sitio Web es su contenido. A pesar del
ruido sobre tecnologías 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 diseño grafico y
apariencia visual global incluida su esquema de color tipografía y estilo
de imagen.
Producir un prototipo
Una vez que el diseño esta aprobado y el documento están listos, el sitio
entra en la fase de producción se puede realizar por una persona. Es más
común en el diseño Web comercial contar con un equipo de personas
que trabajan en tareas especializadas.
Probarlo
24 | P á g i n a
Todos los sitios Web se tienen que probar antes de que estén listos para
el público. Los desarrolladores Web profesionales dedican tiempo y
recursos al calendario de producción para realizar pruebas. Tanto
formalmente como informalmente, los sitios se deberían probar para
funcionalidad básica, rendimiento en diferentes entornos de navegación
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 actualización y mantener el contenido actualizado es una de las
ventajas del medio Web. Es importante tener una estrategia para lo que
ocurriría con el sitio después 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
dinámicos. Se indicará quién puede estar interesado en la información y
como podrían obtenerla, los principios implicados en la creación de una
política para evitar este tipo de problemas y algunas tecnologías
disponibles para salvaguardad la seguridad de un sitio Web incluida la
criptografía, la autentificación y el rastreo.
Entre los aspectos de seguridad están:
Importancia de la información
Amenazas contra seguridad
Equilibrio entre usabilidad, rendimiento, costes y seguridad
Crear una política de seguridad
Principios de autentificación
Fundamentos de la criptografía
Criptografía de la clave publica25 | P á g i n a
Firmas digitales
Certificados digitales
Servidores Web seguros
Auditorias y registros
Cortafuegos
Copia de seguridad de datos
Seguridad física
2.2. MARCO REFERENCIAL
Las referencias para el desarrollo de la investigación 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. Según una encuesta realizada por Lima Como Vamos
(observatorio ciudadano que realiza seguimiento y evaluación a los cambios producidos
en la capital) a finales del año pasado, el 45,9% de los ciudadanos están fastidiados por el
ineficiente servicio de transporte público limeño, lo que nos conlleva a analizar algunas
de las causas que corresponde a este resultado. Además señala las preferencias de las
personas por el servicio del Metropolitano, estas preferencias están sustentadas en el
tiempo de viaje, es decir en su rapidez, siendo el más valorado según la encuesta con un
37,4 %, sin embargo este servicio solo beneficia a un 10% de limeños, lo que significa q
el resto de la población aun sigue utilizando el servicio clásico que aun sigue siendo
deficiente.
Así mismo, según un documento del Ministerio de Educación, 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 mayoría de empresas de transporte público,
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 gestión o del mal
sistema que tienen estas empresas.
26 | P á g i n a
2.2.1. Antecedentes:
2.2.1.1. Nacionales
Metropolitano
Como una solución para este problema, en el segundo semestre del 2010 se
empezó a utilizar el servicio Metropolitano, un nuevo sistema integrado de
transporte público para Lima, que cuenta con buses articulados de gran
capacidad que circulan por corredores exclusivos, bajo el esquema de
autobuses de tránsito rápido BRT (Bus Rapid Transit en inglés).
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 más humano, especialmente a gestantes, mujeres con niños
en brazo, niños, adultos mayores y personas con discapacidad.
Sin embargo, según Juan Tapia Grillo, presidente de Pro-transporte, el
Metropolitano todavía no es rentable: “Todos los sistemas de corredores
segregados de alta velocidad se basan en el rendimiento de pasajeros por
bus. El diseño original aquí fue hecho para atender a más de 600 mil
pasajeros por día. Todavía no hemos llegado a esa cifra”, explica Tapia.
Han pasado de 220 mil pasajeros en enero de 2011 –inicio de la gestión de
Susana Villarán– a 460 mil. Espera lograr la cifra necesaria a fines de este
año o comienzos del próximo “habilitando nuevas rutas y poniendo toda la
flota existente en la calle”.
27 | P á g i n a
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 población, siendo solo un poco más del 10% la cantidad de
personas beneficiarias de este servicio.
28 | P á g i n a
Figura8: En Julio ingresaron 56 buses nuevos a la ruta
Tren Eléctrico
Otra solución para este problema, es el servicio de tren eléctrico, este
servicio fue conformado por empresas líderes como Odebrecht (67%) y
Graña y Montero (33%), que así como el Metropolitano, este también se
desarrollo para mejorar la calidad en los servicios de transporte que se tiene
en nuestra ciudad, así como también los siguientes beneficios:
Transporte Masivo. El tren beneficiará a más de 3 millones de
personas.
Rapidez y puntualidad. Recorrerá 11 distritos en aproximadamente
45 minutos (en la actualidad son 4 horas en ómnibus)
Descongestión Vehicular. Permitirá una mejora y orden en el
tránsito de la ciudad.
Modernidad. Lima contará con un sistema de transporte moderno,
logrando ubicarse entre las ciudades más importantes en el mundo.
Cero contaminaciones. El moderno sistema de transporte no
contamina debido a su alimentación eléctrica.
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 todavía está en iniciación, es decir aun están en construcciones los
diferentes tramos o líneas del proyecto para que logre llegar a la mayor
parte de Lima Metropolitano ya que actualmente solo se tiene una línea en
operación 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 están distribuidas 16 estaciones de pasajeros.
29 | P á g i n a
2.2.1.2. Internacionales
Como una de las grandes soluciones referentes a enfrentar nuestra
problemática en particular desarrollada y aplicada fuera del país, la Empresa
Municipal de Transportes de Madrid, una sociedad anónima, propiedad del
Ayuntamiento de Madrid, encargada de la prestación del servicio de
transporte público urbano colectivo de superficie mediante autobús 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 autobús por la ciudad de
Madrid
Consultar líneas que pasan por un punto concreto de la ciudad
Consultar tiempos de espera en paradas
Consultar itinerarios de las líneas de EMT
Consultar incidencias de servicio en tiempo real
30 | P á g i n a
Figura9: Tramo 1, red básica de tramo
También ha desarrollado un conjunto de aplicaciones y servicios disponibles
desde cualquier dispositivo móvil que podrás ingresar mediante tu
Smartphone, mediante dicho aplicativo se pueden realizar diferentes tipos de
funcionalidades, preguntándose ¿Dónde estoy? ¿Cómo 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,
también brinda las mejores rutas de trasladarse de un lugar a otro, también
muestra en forma detallada la atención de líneas de buses disponibles durante
cada día.
En la aplicación EMTMADRID para IPhone podemos encontrar una utilidad
llamada Realidad Aumentada, a través de la cual tendrás acceso a la
información que se superpone en la imagen captada desde la cámara del
dispositivo, geolocalizando las paradas de autobús más cercanas así como
diversos sitios de interés, donde el usuario se orientara con una visión de 360º
visualizando las paradas, los tiempos de espera y a qué distancia están.
31 | P á g i n a
Figura10: Interfaz del mapa interactivo "Navega por Madrid"
Gracias a esta aplicación las personas se podrán movilizar por Madrid sin
necesidad de tener un conocimiento detallado de la ciudad.
2.3. MARCO NORMATIVO
2.3.1. Políticas para la elaboración de sistemas
Toda elaboración de sistemas deberá estar orientada a satisfacer las
necesidades de manejo de información para las funciones sustantivas de una
institución o empresa; es importante concebir el diseño de dichos sistemas
de manera que permitan su integración y consolidación en una base de datos
constitucional y un banco institucional de sistemas, en un futuro próximo
Toda elaboración de sistemas, tanto interna como externa, debe cumplir con
las normas establecidas por el comité de informática de una institución o
empresa. El cumplimiento de las normas es un requisito indispensable para
considerar un sistema apto para su liberación definitiva.
Toda elaboración de sistemas, tanto interna como externa de carácter
institucional, deberá estar avalada por un dictamen técnico de la dirección
de informática, órgano que en unión con el comité e informática de la
institución o empresa debe normar el uso y aprovechamiento de los recursos
informáticos de acuerdo al reglamento interno de ésta. El dictamen técnico
no será necesario para aquellos sistemas internos de carácter técnico
especializado o específico de las áreas de la institución o empresa, sólo
deberán apegarse a los estándares establecidos por el comité de informática.
La elaboración de sistemas institucionales debe apegarse a los estándares en
cuanto al uso de software. Cuando esto no sea posible, el área usuaria
deberá solicitar un dictamen técnico a la dirección de informática de la
institución o empresa, justificando plenamente el uso de las herramientas
propuestas para el desarrollo.
La contratación externa para la elaboración de sistemas deberá sujetarse a la 32 | P á g i n a
normatividad de adquisiciones vigente, los costos que se generen por dicha
contratación deberán ser cubiertos por el área solicitante.
Antes de la aprobación de cualquier contrato, la dirección de informática
deberá asegurarse que:
o Los requisitos definidos en el contrato se expresen siempre de manera
adecuada e invariablemente en forma textual
o En relación con las características del sistema, se hayan resuelto todas
aquellas diferencias de opinión entre las áreas usuarias y de informática y el
desarrollador, constando su firma de conformidad en el contrato
o 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
institución o empresa son propiedad de éste, por lo que la institución o
empresa tendrá los derechos de autor para la utilización de dichos
desarrollos en las diferentes áreas que así lo requieran. En el supuesto de
que el comité editorial apruebe su publicación, cada área de informática
deberá informar la terminación del sistema al área de la institución o
empresa que tramita los derechos de autor, con objeto de que se lleven a
cabo los trámites requeridos. Así también, él o los autores deberán firmar la
cesión de derechos a la institución o empresa, en el entendido de que la
institución o empresa otorgará los créditos respectivos en la publicación.
Durante el análisis, desarrollo e implantación de cualquier sistema, el área
solicitante deberá participar con su área de informática respectiva y con la
dirección de informática y la empresa externa.
Es responsabilidad del área de informática y de la empresa externa que
desarrolló un sistema, el proporcionar capacitación y asistencia técnica al
personal operativo del área usuaria para el uso y mantenimiento del sistema.
33 | P á g i n a
Será obligación del área solicitante asegurar que estos procesos cubran
todas sus necesidades y requerimientos sustantivos.
El comité de informática a través de la dirección de informática establecerá
de manera formal su política 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 informática, conjuntamente con la dirección de informática,
será el encargado de establecer la organización interna más adecuada para
las diferentes áreas de informática de la institución o empresa. Entre los
puntos por considerar destacan:
o Establecer un organigrama
o Delegar autoridad
o Compartir las responsabilidades
Conforme a las necesidades de las áreas de informática de la institución o
empresa distribuir adecuadamente los recursos materiales para las áreas
respectivas y establecer una política 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 serán proporcionados por las áreas
respectivas de la institución o empresa.
En la elaboración y diseño de sistemas informáticos internos la dirección de
informática será la encargada de establecer y mantener un sistema de
calidad documentado para asegurar productos conforme a los
requerimientos especificados por ella misma, además de alcanzar
consistentemente los objetivos de calidad de la institución o empresa. Entre
los documentos que se generarán por los desarrolladores, están los manuales
de procedimientos, técnicos, de instalación, operativos y de usuario.
34 | P á g i n a
El comité de informática será el encargado de establecer políticas de
administración, calidad y control de calidad; así como, la justificación y
consistencia de éstas. Periódicamente tiene la obligación de revisar las
políticas establecidas y evaluar los resultados logrados. También verificará
a través de la dirección de informática, la cooperación y comunicación entre
coordinaciones y evaluará a las empresas relacionadas (subcontratistas,
distribuidores, etc.).
El comité de informática, a través de la dirección de informática será el
encargado de establecer y describir las clases de trabajo para el desarrollo de
sistemas informáticos internos. Entre las clases de trabajo por considerar
están: división del trabajo, identificación 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 elaboración de Sistemas
2.3.2.1. Objetivo:
Definir la metodología a la que debe someterse todo el personal involucrado
en la elaboración de sistemas, con objeto de obtener productos de alta
calidad que resulten de fácil mantenimiento para cualquier miembro del
equipo de trabajo.
2.3.2.2. Normas Generales:
Los desarrollos de sistemas, tanto internos como externos deberán
respetar los lineamientos y estándares definidos en el Manual de
Procedimientos para el Desarrollo de Sistemas (MPDS).
El área de informática y la empresa externa deberán entregar al área
solicitante: los programas fuentes y ejecutables documentación técnica,
manual de instalación y manual del usuario de acuerdo al MPDS.
35 | P á g i n a
Para los desarrollos internos y externos, cualquier área de informática de
la institución o empresa deberá entregar a la dirección de informática el
original del sistema con su respectiva documentación y todos aquellos
elementos que hagan posible su incorporación al banco institucional de
sistemas, conservando una copia.
Para aquellos sistemas que se desarrollen con un software no estándar
para la institución, será requisito indispensable que cuenten con un
módulo de intercambio de información (importación/exportación) a
través de código ASCII de DOS.
Todas las fases del desarrollo de sistemas deberán esta documentadas de
acuerdo al MPDS.
Si la institución o empresa se encuentra en proceso de restructuración en
cuanto a su organización interna, por ninguna circunstancia se deberá
iniciar la elaboración de un sistema. Para este último caso, es
conveniente la implantación de los sistemas al menos dos (2) meses
después de que se comenzó a trabajar con el nuevo esquema de
organización. Cuando el nuevo esquema tenga contemplado el uso del
sistema, los líderes de proyecto, tanto de la restructuración
organizacional como del sistema de información, establecerán los
canales de comunicación adecuados para la coordinación respectiva de
sus proyectos.
Por ninguna causa se deberá comenzar la etapa de programación del
sistema en general, sin antes tener concluidas las etapas de análisis y
diseño. Para el caso en que el sistema por su magnitud se halla dividido
en módulos, será válido el comenzar la programación de cada uno de
ellos si se cuenta con sus etapas de análisis y diseño concluidas, además
de un análisis y diseño preliminar de carácter general del sistema.
36 | P á g i n a
2.3.2.3. Normas para el análisis de sistemas:
Los desarrollos de sistemas deberán contar con un estudio de factibilidad
tecnológica y económica que permita identificar y describir las
necesidades del usuario con objeto de justificar la elaboración del
sistema.
Apoyados en el estudio de factibilidad tecnológica y económica, las
áreas de informática y usuarias deberán solicitar un dictamen técnico a la
dirección de informática.
Se deberán establecer los grupos de trabajo encargados para las
actividades de diseño de encuestas, entrevistas, recopilación de datos,
etc.
La fase de análisis de sistemas deberá apegarse a las metodologías de
análisis estructurado, tales como Yourdon, De Marco o de Gane
&Sarson.
2.3.2.4. Normas para el diseño de sistemas
La fase de diseño de sistemas deberá apegarse a las metodologías de
análisis y diseño estructurado, tales como Yourdon, De Marco o de Gane
&Sarson.
Deben existir manuales de procedimientos vigentes en la institución o
empresa, todos los grupos de trabajo involucrados en el diseño de
sistemas deberán tener conocimiento del contenido de ellos, a fin de
reflejarlos en el sistema cuando éstos lo afecten.
Para los casos en los cuales se efectúe un cambio en el diseño de un
sistema, dicho cambio deberá ser documentado previa revisión y
justificación, así como aprobación de los responsables para posterior
37 | P á g i n a
notificación al encargado del control de la documentación, con el fin de
que todas las áreas se enteren del cambio efectuado.
2.3.2.5. Normas para la programación y documentación de sistemas
Todos los programas que integren cualquier sistema deberán 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 liberación
de un sistema. La Dirección de Informática deberá revisar que el manual
técnico se apegue a las especificaciones del MPDS; en los casos que así
se considere necesario la dirección de informática evaluará dichos
manuales.
El encargado del control de la documentación de un sistema, será
subordinado directo del líder de proyecto en que esté involucrado el
sistema. Este encargado dictaminará el control de la documentación con
base en claves de control (en la esquina inferior izquierda), las cuales
serán de conocimiento general para el equipo de desarrollo del sistema.
Los documentos serán inventariados en una lista maestra de control de
documentos, en la cual se tenga constancia del estado actual de cada
documento y de quién tiene posesión del mismo. Ejemplos:
CO=Confidencial, NF=No fotocopiable, CE____= Control específico del
___, UG= Uso general, CF __/__/__= Cambios frecuentes de fecha de
publicación, etc.
El encargado del control de la documentación tendrá especial cuidado en
la documentación que presente cambios frecuentes, ya que será su
obligación el velar que en todas las áreas se cambie la documentación
obsoleta del sistema por documentación actualizada.
38 | P á g i n a
Todos aquellos códigos que sean objeto de programación, ya sean
módulos, programas, pantallas, etc., deberán contener información de
quién efectuó la programación y en qué fecha; de ser posible en el mismo
software, mediante comentarios y adicionalmente en la documentación
por escrito.
Después de concluida la programación 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 programación en horas; esto con el fin de establecer un control
de calidad del trabajo de los programadores.
2.3.2.6. Normas para la implantación de sistemas y capacitación
Antes de liberar un nuevo sistema, éste deberá ser sometido a pruebas de
aceptación 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
versión anterior.
La capacitación al personal técnico-operativo formará parte fundamental
de la liberación de un sistema. Dicha capacitación deberá cubrir todas las
necesidades y requerimientos que el área usuaria especifique de común
acuerdo con el área de informática o empresa externa.
El proceso de capacitación deberá ser posterior a la aprobación de los
manuales:
técnico
de instalación
de operación
39 | P á g i n a
del usuario, que constituirán la guía con la que se lleve a cabo dicho
proceso
Los manuales de operación deberán especificar los métodos de manejo
que permitan cuidar la integridad, tanto física como lógica de los
elementos que conforman el sistema, ya sean datos información,
software, hardware y documentación.
Las pruebas de aceptación deberán ser clasificadas en: preliminares, para
los casos en que se pruebe el módulo 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, deberán 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 cómputo en el que se pretende operar
sistemáticamente. Para el caso de sistemas que operen en red, también se
deberán efectuar pruebas con usuarios concurrentes.
Los tipos de datos con los cuales se efectúen las pruebas deberán estar
apegados a la realidad, a fin de tomar en cuenta el rango de valores que
soportará el sistema y posteriormente realizar una gráfica de rendimiento
de cantidad de datos contra el tiempo de procesamiento. En el caso de
sistemas para trabajo en red, deberán establecerse elementos que
permitan observar objetivamente el desempeño del sistema. Si los
resultados de rendimiento del sistema no son aceptables para fines
prácticos, se consignará el módulo para su re-trabajo en programación.
2.3.2.7. Normas para el mantenimiento de sistemas
El área usuaria deberá solicitar el mantenimiento de un sistema a su área
40 | P á g i n a
de informática o empresa externa, siempre y cuando se identifiquen y
justifiquen plenamente los ajustes y cambios necesarios que permitan
mejorar el desempeño y cobertura del sistema en cuestión. Para los casos
que así se considere necesario, deberá solicitarse dictamen técnico a la
dirección de informática.
Aquellos códigos del sistema que no trabajen de manera óptima con
respecto a las necesidades o rendimiento que se pretenda satisfacer, serán
dispuestos a un proceso de re-trabajo; en primera instancia a quien
realizó la programación, y en último caso a un nuevo equipo de trabajo
para programación, esto considerando un estilo de programación
diferente que sea más adecuado a la necesidad a satisfacer. La situación
anteriormente descrita debe registrarse en la documentación
correspondiente.
2.3.3. Políticas Generales De Seguridad Informática
2.3.3.1. Del Departamento de Redes y Comunicaciones
Art. 1. Normar el correcto uso de los servicios de Internet y correo
electrónico en la empresa.
Art. 2. Establecer las medidas y mecanismos de control, monitoreo y
seguridad, tanto para los accesos a páginas o sitios de Internet, como para
los mensajes de correo con contenidos u orígenes sospechosos.
Art. 3. Que las conexiones a Internet cuenten con elementos de prevención,
detección de intrusos, filtros contra virus, manejo de contenidos, entre
otros, que afectan la integridad de los sistemas y la información
institucionales.
Art. 4. Reducir el tráfico de mensajes, paquetes o transacciones no
permitidos, que saturan la infraestructura de telecomunicaciones y generan
actividad innecesaria en los servidores.
41 | P á g i n a
Art. 5. De acuerdo a la demanda de servicios, establecer prioridades, dando
la más alta a las actividades consideradas esenciales para fomentar la
educación y las artes, objetivo primordial de la Institución.
Art. 6. Controlar, suspender o revocar los códigos de acceso a cualquier
usuario que haga mal uso de los recursos, viole las políticas de seguridad o
interfiera con los derechos de otros usuarios.
Art. 7. Asignar la capacidad de memoria de almacenamiento a cada
usuario, en función del perfil establecido y disponibilidad del recurso en los
servidores administra la Dirección de Servicios Informáticos (DSI).
Art. 8. Contratar enlaces o servicios de conectividad a Internet, ya sea
directamente o vía terceros, por lo que queda restringido a cualquier otra
área de la Institución obtener y utilizar enlaces y servicios que permitan la
interconexión 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 incorporación de las medidas de control
y seguridad en los enlaces.
Art. 9. Establecer las normas de construcción y arquitectura de los sitios de
Intranet, que optimicen el acceso a los servicios y la información
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 electrónico e Internet y de los
equipos de cómputo en general.
Art. 2. Instalar y actualizar los antivirus y sistemas operativos, así como
tener al día en los servidores asignados, las actualizaciones y parches de
programas institucionales licenciados y autorizados.
42 | P á g i n a
Art. 3. Llevar un registro y control de las direcciones IP de los equipos
conectados a la red con acceso a Internet y la información de los usuarios,
así como notificar al Departamento de Redes y Comunicaciones de las altas
y bajas de usuarios para los servicios de correo electrónico e Internet.
Art. 4. Proporcionar al Departamento de Redes y Comunicaciones la
documentación actualizada de la red local: planos de cableado, ubicación
del equipo y relación de las asignaciones de direcciones IP.
Art. 5. Administrar los servicios locales de red como son www, correo
electrónico, servidor de FTP y servidores de aplicaciones en red.
Art. 6. Solucionar fallas menores como son: cables desconectados, pérdida
de suministro de energía eléctrica en los equipos de datos,
desconfiguración de las computadoras de los usuarios o direcciones IP
repetidas.
Art. 7. Supervisar el cumplimiento de las políticas y lineamientos
institucionales.
2.3.3.3. Del Departamento de Soporte Técnico
Art. 1. Brindar mantenimiento preventivo y/o correctivo únicamente al
equipo que cuente con número 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 información contenida en los
servidores del Instituto.
2.3.3.4. Del Personal
Art. 1. El empleado no tiene ningún derecho sobre la información que
procese dentro de las instalaciones de la red institucional de la Empresa
43 | P á g i n a
Art. 2. La información 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 informática
de la Empresa
Art. 4. Conocer y obedecer las políticas de seguridad establecidas en el
presente documento, las cuales, una vez aprobadas se publicarán.
2.3.4. Normas específicas para la seguridad de información
2.3.4.1. Del Acceso a la Información
Todos los permisos de acceso a los sistemas deberán solicitarse con
documento formal al Departamento de Informática o haga sus veces.
El usuario deberá identificarse antes de ingresar a las áreas de cómputo,
verificando si cuenta con la autorización correspondiente del encargado
de Informática, registrándose el nombre de la persona, hora de ingreso y
hora de salida.
Toda persona sin excepción que use una computadora en las
instalaciones de la Empresa deberá ser usuario autorizado.
Las visitas deben portar la identificación proporcionada por el personal
de seguridad de la Empresa a la entrada de la institución, pudiendo
accesar a las computadoras siempre y cuando la visita se encuentre
acompañada mínimamente por el usuario de la Empresa, quien deberá
solicitar el permiso de acceso ante los encargados de los sistemas de
cómputo, debiendo existir una razón suficiente que amerite el acceso a
las mismas.
No está permitido que ninguna persona visitante instale, copie o elimine
información de las computadoras o servidores de la red interna. Para el
mantenimiento de los sistemas externos el visitante deberá estar
acompañada por personal especializado del Departamento de
Informática quien proporcionará el soporte técnico necesario.
En los Sistemas Informáticos los programas de cómputo, deberán contar
con rutinas de control para el acceso de los usuarios.
44 | P á g i n a
Las rutinas de control, permiten que los usuarios ingresen al Sistema,
previa identificación, 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 identificarán a los usuarios autorizados
a usar determinados sistemas con su correspondiente nivel de acceso, el
cual incluye la lectura o modificación en sus diferentes formas.
Existirán 4 niveles de acceso a la información:
a) Nivel de consulta de la información no es restringida o
reservada.
b) Nivel de mantenimiento de la información no restringida o
que no es reservada.
c) Nivel de consulta de la información, incluyendo la restringida
o reservada.
d) Nivel de mantenimiento de la información, incluyendo la
restringida o reservada
Para garantizar estos niveles cada palabra clave tendrá asignada uno de
estos niveles de acceso.
La información que se considere restringida o reservada deberá estar
debidamente identificada, así como los usuarios que tengan acceso a
ella.
Informática, maneja los 4 niveles de acceso a la información, contando
para ello con un Administrador de la seguridad del aplicativo, quien es
responsable de la asignación de las palabras claves, de los niveles de
acceso y las fechas de expiración.
La seguridad de la información debe configurarse también a nivel de
archivos físicos, el sistema de archivos deberá ser NTFS a fin de
garantizar su integridad. Los accesos a dichos archivos deberán
auditarse para monitoreo de la seguridad.
45 | P á g i n a
Los operadores de la información restringida o reservada realizarán
estrictamente lo indicado en cada procesamiento de la información,
debiendo contarse con el procedimiento claramente documentado.
2.3.4.2. De la Protección Especial de la Información
Para proteger una base de datos, se deberá prever que el número de
conexiones a la misma esté respaldada por su respectiva licencia de uso.
Para proteger la información 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
información, y que ese equivalente pueda codificar la información en
otro formato cuyo contenido es difícil acceso.
El software de encriptación deberá cumplir las siguientes condiciones:
a) Ser portable, es decir que funcione en diferentes sistemas
operativos con cambios mínimos.
b) Podrá utilizarse en cualquier lenguaje de programación.
c) Ser de fácil entendimiento por el usuario, de tal manera que
permita su uso sin necesidad que éste conozca las técnicas de
encriptación.
d) Estar debidamente documentado, para ser entendible por cualquier
usuario.
Para el control y distribución de la información impresa, así como para
la grabación de los medios magnéticos u ópticos y su respectivo
almacenamiento y/o distribución se deben registrar en la dependencia
que origina y/o envía la información.
Los reportes que contengan información de carácter reservado y que no
se usen deberán ser destruidos.
2.3.4.3. De la Integridad de la Información
Todo Sistema de Información, para que sea eficaz, deberá ser analizado
y diseñado con la participación conjunta del analista de sistemas y el
46 | P á g i n a
usuario. El analista de sistemas identificará y especificará todos los
requerimientos del usuario, para que éstos sean considerados en la etapa
de diseño del sistema.
Los programas deberán estar documentados y utilizarán nombres
estándares.
Todo cambio que se haga a los sistemas informáticos deberá ser
inmediatamente documentado en los manuales correspondientes y en las
ayudas en línea de los sistemas.
Para evitar el reinicio de los procedimientos que forman parte de los
procesos, deberán existir suficientes archivos de respaldo y suficientes
puntos de verificación /reinicio de operaciones.
Para que las acciones de auditoría, puedan rastrear las transacciones
necesarias para el control, se deberá prever la generación de toda la
información necesaria. Esta información deberá contener como mínimo:
nombre de usuario, fecha y hora, nombre de la tabla y acción realizada.
Para pruebas de los programas, es necesario preparar datos de
comprobación en donde se contemplen todas las entradas correctas y
erradas, verificándose las salidas generadas con los resultados previstos.
Los programas también serán probados con datos reales, haciéndose las
mismas verificaciones. Asimismo se confirmarán los límites extremos
más altos o más bajos de las cantidades utilizadas.
Para asegurar la calidad de los sistemas Informáticos es necesario
efectuar pruebas de verificación y validación.
Para la prueba de los Sistemas, es necesario la compatibilidad entre los
módulos individuales, integrantes de los sistemas.
Los Sistemas de Gestión de Base de Datos, deberán brindar facilidades
para su restauración con rapidez y con la mínima pérdida de
información. Las Bases de Datos se restaurarán en base a la técnica de la
redundancia.
47 | P á g i n a
Deberá llevarse un registro ordenado y clasificado de las versiones del
software, que permita un fácil mantenimiento del mismo, así como una
adecuada restauración de versiones anteriores en caso de falla.
Se proporcionará a los operadores de las computadoras con la debida
anticipación la documentación necesaria para la ejecución de trabajos de
procesamiento automático de datos, de acuerdo a las prioridades de los
mismos.
2.3.4.4. Seguridad de la Información
El usuario que utiliza sistemas mono usuario debe adoptar las medidas
de seguridad, que garanticen el cumplimiento de las normas y
procedimientos señalados en la presente directiva.
Las cuentas de los usuarios de los sistemas informáticos son
estrictamente personales e intransferibles. El usuario de sistemas
informáticos que disponga de una palabra clave de acceso será
responsable de su mal uso por otras personas no autorizadas.
El órgano de administración correspondiente deberá proveer el
mobiliario y/o el mantenimiento del mobiliario para almacenar bajo
llave toda la documentación de trabajo de carácter reservado.
2.4. METODOLOGÍA RUP
El Proceso Unificado Racional, Rational Unified Process en inglés, y sussiglas RUP,
es un proceso de desarrollo de software y junto con
el LenguajeUnificado de ModeladoUML, constituye la metodología estándar más
utilizada para el análisis, implementación y documentación de sistemas orientados a
objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un
conjunto de metodologías adaptables al contexto y necesidades de cada organización,
donde el software es organizado como una colección de unidades atómicas llamados
objetos, constituidos por datos y funciones, que interactúan entre sí.
48 | P á g i n a
También se conoce por este nombre al software desarrollado por Rational, hoy propiedad
de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones
de las diversas actividades. Está incluido en el RationalMethodComposer(RMC), que
permite la personalización de acuerdo a necesidades.
2.4.1. UML
UML es un lenguaje de propósito 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 ingeniería 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 diseñadores de coches preparan modelos en sistemas
existentes con todoslos detalles y los ingenieros de software deberían igualmente
construir modelos delos sistemas software.
2.4.2. Características del RUP
Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilización 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
implementación de las fases y disciplinas del RUP.
Un Caso de Uso es una secuencia de pasos a seguir para la realización de un fin o
propósito, y se relaciona directamente con los requerimientos, ya que un Caso
deUso es la secuencia de pasos que con lleva la realización e implementación 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 implementación del proyecto a
realizar en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada
iteración y así poder ir completando todo el proyecto iteración por iteración, con lo 49 | P á g i n a
cual se tienen varias ventajas, entre ellas se puede mencionar la de tener pequeños
avances del proyecto que son entregables al cliente el cual puede probar mientras
se está desarrollando otra iteración 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 organización o estructura de sus partes más
relevantes. Una arquitectura ejecutable es una implementación parcial del sistema,
refinamientos sucesivos de una arquitectura ejecutable, construida como un
prototipo evolutivo.
RUP se divide en 4 fases, dentro de las cuales se realizan varias iteraciones según
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 (Inspección y Concepción)
Se hace un plan de fases, donde se identifican los principales casos de uso y se
identifican los riesgos. Se concreta la idea, la visión del producto, como se
enmarca en el negocio, el alcance del proyecto.
b) Fase de Elaboración:
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 características y el diseño de la arquitectura.
c) Fase de Construcción:
Se basa en la elaboración de un producto totalmente operativo y en la elaboración
del manual de usuario. Construir el producto, la arquitectura y los planes, hasta
que el producto está listo para ser enviado a la comunidad de usuarios.
50 | P á g i n a
d) Fase de Transición:
Se realiza la instalación del producto en el cliente y se procede al entrenamiento de
los usuarios. Realizar la transición 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 prácticas, como lo son:
Desarrollar Software Iterativamente
Modelar el software visualmente
Gerenciar los Requerimientos
Usar arquitecturas basadas en componentes
Verificacióncontinúa de la calidad
Gerenciar los cambios
Ver Figura 11 donde se observan las interacciones entre las etapas de RUP.
51 | P á g i n a
2.4.3. Descripción de las Fases
Dependiendo de la iteración 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
mayor énfasis en actividades modelado del negocio y de requisitos.
En esta fase se realizan los siguientes pasos:
Un documento con la visión 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.52 | P á g i n a
Figura 11: Interacciones entre etapas de la Metodología RUP
Un Caso de Uso inicial de Negocio el cual incluye: contexto del
negocio,criterios de éxito y planificación 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 entender las
funciones de la organización del cliente, tanto en estructura como en susprocesos.
Su objetivo es modelar funciones y roles que realiza la organización para realizar
más fácilmente la reingeniería de procesos o la implantación del nuevo sistema.
También se describe lo que el sistema tendría que realizar y permitir que los
desarrolladores y el cliente estén de acuerdo con esta descripción.
Para ello se realizarán las siguientes sub-fases:
Describir los requerimientos funcionales y no funcionales (rendimiento
esperado, plataformas soportadas, integración con sistemas externos, etc.).
Capturar un glosario o vocabulario del sistema o proyecto (mediante
documento y clases conceptuales).
Encontrar actores y casos de uso.
Describir los casos de uso mediante su flujo principal, variaciones y
excepciones.
Asignar prioridades a los casos de uso encontrados para poder planificar la
iteración en forma de análisis, diseño e implementación.
Modelar la interfaz de usuario (diseño lógico).
Prototipo de la interfaz de usuario (diseño físico).
b) Fase de Elaboración: En esta fase las iteraciones se orientan al desarrollo de
la arquitectura, que incluye los flujos de trabajo de requerimientos, modelo de
negocios (refinamiento), análisis, diseño y una parte de implementación
orientado a la arquitectura.
En esta fase se realizan las siguientes sub-fases:
53 | P á g i n a
Un modelo de Casos de Uso con todos los actores identificados y la
mayor parte de las descripciones de Casos de Uso.
Requerimientos adicionales: no funcionales o pseudorequerimientos.
Descripción de la arquitectura del software.
Prototipo ejecutable de arquitectura.
Una lista revisada de riesgos.
Plan del proyecto, incluyendo iteraciones y criterios de evaluación para
cada iteración.
Manual preliminar de usuario.
En esta fase se especifican los requerimientos y se describen sobre cómo se van a
implementar en el sistema: transformar los requisitos al diseño del sistema,
desarrollar una arquitectura para el sistema, y adaptar el diseño para que sea
consistente con el entorno de implementación.
c) Fase de Construcción: Se implementan las clases y objetos en ficheros fuente,
binarios, ejecutables y demás. El resultado final es un sistemaejecutable.
Para ello se realizarán las siguientes sub-fases:
El producto de software integrado sobre la plataforma adecuada.
Los manuales de usuario.
Una descripción de la versión actual.
Planificar qué subsistemas deben ser implementados y en qué orden deben
ser integrados, formando el Plan de Integración.
Cada implementador decide en qué orden implementa los elementos del
subsistema.
Si encuentra errores de diseño, los notifica.
Se integra el sistema siguiendo el plan.
En la parte de Pruebas se evalúa la calidad del producto, pero no para aceptar o
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
54 | P á g i n a
del software. Generalmente asesora sobre la calidad del software percibida, provee
la validación de los supuestos realizados en el diseño y especificación de requisitos
por medio de demostraciones concretas, verificar las funciones del producto de
software según lo diseñado y que los requisitos tengan su apropiada
implementación.
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 ejecución final.
Empaquetar el software para su distribución.
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.
Durante todo el proyecto se ejecutan las fases de gestión del proyecto, donde se
vigila el cumplimiento de los objetivos, gestión 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:
Proveer un marco de trabajo para la gestión de proyectos de software
intensivos.
Proveer guías prácticas realizar planeación, contratar personal, ejecutar y
monitorear el proyecto.
Proveer un marco de trabajo para gestionar riesgos.
En la fase de configuración y control de cambios, permite mantener la integridad
de todos que se crean en el proceso, así como de mantener información del
proceso evolutivo que han seguido.
En la fase del Entorno, la finalidad es dar soporte al proyecto con las adecuadas
herramientas, procesos y métodos. Brinda una especificación de las herramientas
55 | P á g i n a
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:
Selección y adquisición de herramientas
Establecer y configurar las herramientas para que se ajusten a la
organización.
Configuración del proceso.
Mejora del proceso.
Servicios técnicos.
Los Roles que se cumplen en el RUP:
I. Analistas:
Analista de procesos de negocio
Diseñador del negocio
Analista de sistema
Especificador de requisitos
II. Desarrolladores:
Arquitecto de software
Diseñador
Diseñador de interfaz de usuario
Diseñador de cápsulas
Diseñador de base de datos
Implementador
Integrador
III. Gestores:
Jefe de proyecto
Jefe de control de cambios.
Jefe de configuración.
Jefe de pruebas
Jefe de despliegue
56 | P á g i n a
Ingeniero de procesos
Revisor de gestión del proyecto
Gestor de pruebas
IV. Apoyo:
Documentador técnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista gráfico
V. Especialista en pruebas:
Especialista en Pruebas (tester)
Analista de pruebas
Diseñador de pruebas
VI. Otros roles:
Stakeholders
Revisor
Coordinación de revisiones
Revisor técnico
Cualquier rol
Para grandes organizaciones con un números equipos de ingenieros y la
comunicación entre cada equipo es crítica por lo tanto es necesario que los
artefactos sean completos y bastante comprensivos
En tanto que para pequeños proyectos no es recomendable presentarse
tanto rigor en las preparaciones de los artefactos, la eficiencia del proceso
depende más de las habilidades de cada trabajador
2.4.4. Beneficios de la Metodología Orientada a Objetos
Promueve la reusabilidad.
Reduce la complejidad del mantenimiento (extensibilidad y facilidad de
cambios).
Riqueza semántica.
57 | P á g i n a
Disminuye la brecha semántica entre la visión interna y la visión externa del
sistema.
Facilita la construcción de prototipos.
2.4.5. Ventajas de la Metodología Orientada a Objetos
Reutilización
El diseñador piensa en términos del comportamiento de objetos y no en
detalles de bajo nivel
Confiabilidad, Integridad y Estabilidad
Mantenimiento más sencillo. Modificaciones locales
Modelado más realista.
Modelos empresariales inteligentes.
Independencia del diseño.
Mejores herramientas CASE.
Bibliotecas de clases para las empresas.
Se construyen clases cada vez más complejas.
Nuevos mercados para el software.
Diseño de mayor calidad.
Programación más sencilla.
Mejor comunicación entre los profesionales de los Sistemas de Información y
los empresarios.
Mayor nivel de automatización de las bases de datos.
La comprensión del sistema es más fácil porque la semántica entre el sistema y
la realidad son similares.
2.5. HIPOTESIS
Simulando el control de los buses mediante el uso de un sistema de información en
conexión con GPS, se espera mejorar el servicio de transporte público de una línea de
bus para los usuarios de Lima Metropolitana
2.5.1. VARIABLES INDEPENDIENTES
58 | P á g i n a
Uso de la aplicación costo de viaje
Uso de las consulta sobre el tiempo aproximado de un bus para llegar a un
paradero respectivo
Diseño del sistema
2.5.2. VARIABLES DEPENDIENTES
Efectividad de las consultas
Flexibilidad del sistema
3. MARCO METODOLÓGICO
3.1. Metodología para el análisis y diseño de la solución
Con esta metodología se pretende diseñar un sistema que pueda satisfacer los
requerimientos básicos y necesarios de los usuarios a quienes esta dirigido esta
investigación, además de hacer que este sea lo más flexible de manera que se pueda
adaptar a los distintos cambios que se pueda producir en cualquier situación o momento.
Para ellos se desarrollará las siguientes fases que involucran esta metodología.
3.1.1. Fase de Inicio
Para el desarrollo del presente trabajo solo se llegará hasta la fase de elaboración
ya que solo se está haciendo el diseño del sistema
Visión del proyecto
Con este documento se definirá cual es el propósito, el alcance y
limitaciones de la presente investigación para darnos la orientación
adecuada de lo que queremos lograr con este.
Para la realización 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
investigación así como las iteraciones de acuerdo a un cronograma
establecido para cada una de las fases.
59 | P á g i n a
Esto se llevara a cabo utilizando el Microsoft Project 2010.
3.1.2. Fase de Elaboración
En esta fase se desarrollaran los siguientes diagramas que se involucran y
relacionan hasta el diseño del proyecto:
Diagrama de Caso de Uso
Con este diagrama se podrá modelar las funcionalidades del sistema
agrupándola en descripciones de acciones ejecutadas por el sistema para
obtener un resultado.
Para su elaboración se podrá utilizar cualquiera de estas herramientas:
Microsoft Visual Studio 2010 o Rational Rose
Diagrama de Secuencia
Este diagrama permite describir la interacción entre obejtos de una
aplicación 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 Colaboración
Este diagrama es una forma alterna de representar la interacción entre
objetos al diagrama de secuencia, pero a diferencia de este puede mostrar
el contexto de la operación y ciclos de ejecución.
Este diagrama también 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 aplicación, junto con los cambios que permiten pasar de un
estado a otro.
También este diagrama se puede elaborar con el programa Microsoft
Visual Studio o Rational Rose
Diagrama Entidad-Relación
60 | P á g i n a
Este diagrama es para el modelado de datos que permite representar las
entidades relevantes de un sistema de información 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. Metodología para el estudio de factibilidad (viabilidad) de la solución
3.2.1. Investigación Cualitativa
Realizando este tipo de investigación 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 aplicación de la presente
investigación evaluando las mejoras q se haga para cada uno de los factores o
parámetros con que se estudia la productividad del servicio, para de esta manera
demostrar la viabilidad de esta investigación, para ello se llevará a cabo una
recolección de datos definiendo el universo, técnica, instrumento método de
recolección y donde además como se calculará la muestra con el que se realizara
este tipo de investigación
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 tamaño de la muestra que se va a tomar para este tipo de
investigación (Cualitativa) se empleará la siguiente fórmula:
61 | P á g i n a
Dónde:
n = Tamaño de la muestra.
N = Población
Z = Valor crítico correspondiente a un coeficiente de confianza del cual se
deseahacer la investigación.
P = Proporcional de ocurrencia de un evento.
Q = Proporción de no ocurrencia de un evento o fracaso.
E = grado de error.
3.2.1.3. Técnica
La técnica que se empleara para la recolección de datos será la encuesta
Encuesta
Técnica utilizada para obtener información de una muestra de
individuos. Esta
Muestra es usualmente sólo una fracción de la población bajo
estudio.
3.2.1.4. Instrumento
El instrumento que se empleará para la recolección de datos será el
cuestionario.
Cuestionario
Instrumento utilizado para la obtención de información constituida
por un conjunto de preguntas abiertas o cerradas orientadas a
obtener información específica de lo que se investiga.
3.2.1.5. Método de recolección de datos
62 | P á g i n a
Para la realización de este tipo de investigación se empleará el método
Estadístico, ya que esta ciencia matemática nos proporciona las
herramientas necesarias para la recolección, estudio e interpretación de los
datos obtenidos mediante gráficos, para luego analizar cada uno de los
resultados obtenidos.
3.2.2.
Impacto Económico
El siguiente estudio se empezará a realizar en cuando se lleve a cabo la
implementación de esta investigación, el cual el actual solo abarca hasta el diseño,
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 implementación podrá recuperar su inversión o de qué
manera esta empezara a obtener mayores ingresos, teniendo en cuenta los costos q
se reducirán 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 documentación de buenas prácticas
creadas por la W3C.63 | P á g i n a
Figura 12: Ejemplo de la aplicación del Método Estadístico
Y además de tener en cuenta las leyes que estén sobre la empresa a la cual se le
esté implementando el proyecto.
4. ASPECTOS ADMINISTRATIVOS
4.1. Índice Preliminar de la tesis
INDICE
Introducción
Lista de Tablas
Lista de Figuras
Resumen
Abstract
CAPITULO I
1. INTRODUCCIÓN
1.1. Motivación y Justificación
1.1.1. Planteamiento del Problema
1.1.1.1. Delimitación
1.1.2. Propuesta de Solución
1.1.3. Alcance de la Propuesta
1.1.4. Justificación
1.2. Antecedentes de Solución
1.2.1. Nacionales
1.2.2. Internacionales
1.3. Objetivos
1.3.1. Objetivo general
1.3.2. Objetivos Específicos
CAPITULO II
2. MARCO TEÓRICO
2.1. Programación Web
2.1.1. Protocolo http (Protocolo de Transferencia de Hipertexto)
2.1.2. Comunicación entre el navegador y el servidor web
2.1.3. Arquitectura del WWW
64 | P á g i n a
2.1.3.1. URL’s.
2.1.3.2. HTML
2.1.3.3. Desarrollo de aplicaciones web
2.1.3.4. Lenguajes de programación del lado del cliente
2.1.3.5. Lenguajes de programación del lado del servidor
2.1.3.6. Metodologías para el desarrollo de aplicaciones web
2.1.3.7. Aspectos de seguridad.
2.2. Marco Normativo
2.2.1. Sistemas y Programación
2.2.1.1. Políticas para la elaboración de sistemas
2.2.1.1.1. Políticas
2.2.1.2. Normas para la elaboración de Sistemas
2.2.1.2.1. Objetivo
2.2.1.2.2. Normas Generales
2.2.1.2.3. Normas para el análisis de sistemas:
2.2.1.2.4. Normas para el diseño de sistemas
2.2.1.2.5. Normas para la programación y documentación de sistemas
2.2.1.2.6. Normas para la implantación de sistemas y capacitación
2.2.1.2.7. Normas para el mantenimiento de sistemas
2.2.1.3. Políticas Generales De Seguridad Informática
2.2.1.4. Normas específicas para la seguridad de información
2.2.1.4.1. Del Acceso a la Información
2.2.1.4.2. De la Protección Especial de la Información
2.2.1.4.3. De la Integridad de la Información
2.2.1.4.4. Seguridad de la Información
2.3. Metodología RUP
2.3.1. Características del RUP
2.3.2. Descripción de las Fases
2.3.3. Beneficios
2.3.4. Ventajas
65 | P á g i n a
2.4. Marco Metodológico del Modelo de validación
CAPITULO III
3. DISEÑO DE LA SOLUCIÓN
3.1. Metodología RUP
3.1.1. Fase de Inicio
3.1.2. Fase De Elaboración
3.2. Analizar el Problema
3.3. Diseño de la propuesta
CAPITULO IV
4. VALIDACIÓN DEL MODELO
4.1. Instrumentos y Técnicas
4.1.1. Universo
4.1.2. Muestra
4.1.3. Técnica
4.1.4. Instrumento
4.1.5. Método Recolección de Datos
4.2. Análisis de Datos
CAPITULO V
5. CONCLUSIONES Y RECOMENDACIONES
4.2. Presupuesto y Cronograma de Actividades
4.2.1. Presupuesto
Recursos de Software
Licencias/Programas Cantidad Precio 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
TOTAL 1 S/. 15.00
66 | P á g i n a
Costos de Recolección de Información
Actividad Cantidad Costos Subtotal
Registros de tiempos 6 puntos de control S/. 30.00 S/. 180.00
Costos de viajes 12 viajes S/. 1.00 S/. 12.00
TOTAL 2 S/. 192.00
Recursos Humano
Estos costos están sujetos a labor que desempañara cada uno de los que realizan la
presente investigación
Personal Cantidad Precio Subtotal
Analista / Programador 2 S/. 1,900.00 S/. 3,800.00
Programador 1 S/. 1,500.00 S/. 1,500.00
Técnicos 1 S/. 1,200.00 S/. 1,200.00
Total S/. 6,500.00
Y como el proyecto se establece para su desarrollo en 3 meses, el costo total de
recurso humano sería:
TOTAL3=S/. 6,500.00 x 3 = S/. 19,500
Por tanto, el presupuesto total de toda la investigación (incluyendo el curso de
Proyectos de Ingeniería de Sistemas II) sería:
TOTAL1+ TOTAL 2 + TOTAL 3 = S/.19,707
4.2.2. Cronograma
67 | P á g i n a
68 | P á g i n a
REFERENCIAS
EMT Madrid.2012- ¿Quiénes Somos? Disponible en:
http://www.emtmadrid.es/Home/Corporativo/Presentacion.aspx. Accedida en: Septiembre 2012.
EMT Madrid.2012- Navega por Madrid. Disponible en:
http://www.emtmadrid.es/Home/Destacados/Navega-por-Madrid.aspx. Accedida en: Septiembre
2012.
EMT Madrid.2012- Realidad Aumentada. Disponible en:
http://www.emtmadrid.es/Home/Multimedia/Realidad-aumentada.aspx. Accedida en: Septiembre
2012
SmartMatic-Colombia: Automatización del Transporte Público Cartagena 2011. Disponible
en: http://www.smartmatic.com/espanol/casos-de-estudio/view/article/colombia-cartagena-
public-transit-automation-2011/#.UGkUqOF7tCh. Fecha de Consulta: Septiembre 2012
La República.18 de Enero del 2012- Lima tendría 8 millones 432 mil habitantes en la
actualidad, informa INEI. Disponible en: http://www.larepublica.pe/18-01-2012/lima-tendria-
8-millones-432-mil-habitantes-en-la-actualidad. Fecha de Consulta: Septiembre 2012
La República.18 de Enero del 2012- En pistas de Lima transitan más de 34 mil buses y
combis, por eso es urgente ejecutar reforma. Disponible en: http://www.larepublica.pe/27-04-
2012/en-pistas-de-lima-transitan-mas-de-34-mil-buses-y-combis-por-eso-urge-reforma. Fecha de
Consulta: Septiembre 2012
69 | P á g i n a
Lima Como Vamos-Inseguridad y transporte: los principales problemas de nuestra capital.
Disponible en: http://www.limacomovamos.org/movilidad-y-transporte/inseguridad-y-transporte-
los-principales-problemas-de-nuestra-capital/. Fecha de Consulta: 28 Octubre 2012
Ministerio de Educación - El Transporte Urbano en Lima Metropolitana: Un desafío en
defensa de la vida. Disponible en: http://ditoe.minedu.gob.pe/Materiales%20DITOE/B14.pdf.
Fecha de Consulta: 28 Octubre 2012
Metropolitano- ¿Qué es el Metropolitano?. Disponible en:
http://www.metropolitano.com.pe/index.php/metropolitano/ique-es-el-metropolitano. Fecha de
Consulta: 31 Octubre 2012
La República- El Metropolitano que se viene. Disponible en: http://www.larepublica.pe/22-07-
2012/el-metropolitano-que-se-viene.Fecha de Consulta: 31 Octubre 2012, párrafo 3.
Consorcio Tren Eléctrico – Beneficios. Disponible en:
http://www.consorciotrenelectrico.com.pe/index.php?
option=com_content&view=article&id=6&Itemid=133. Fecha de Consulta: 31 Octubre 2012
Consorcio Tren Eléctrico – Tramo 1. Disponible en:
http://www.consorciotrenelectrico.com.pe/index.php?
option=com_content&view=article&id=7&Itemid=134. Fecha de Consulta: 31 Octubre 2012
Wikipedia – Sistema de Información. Disponible en:
http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n. Fecha de Consulta: 2 Noviembre
2012
70 | P á g i n a
Gaston Dehesa Valencia - Programación web, capitulo 1.2 Protocolo http, páginas 9 a la 14.
Libro Online. Disponible en: http://es.scribd.com/doc/92941618/Libro-de-Programacion-Web.
Fecha de Consulta: Octubre 2012
Gaston Dehesa Valencia - Programación web, capitulo 1.2.1Arquitectura del WWW, página 15.
Libro Online .Disponible en: http://es.scribd.com/doc/92941618/Libro-de-Programacion-Web.
Fecha de Consulta: Octubre 2012
Gaston Dehesa Valencia - Programación web, capitulo 1.3 Introducción al HTML. Lenguaje de
despliegue del Web. Libro Online. Disponible en: http://es.scribd.com/doc/92941618/Libro-de-
Programacion-Web. Fecha de Consulta: Octubre 2012
Gaston Dehesa Valencia - Programación web, capitulo 2.1Arquitectura de las aplicaciones Web,
página 52. Libro Online. Disponible en: http://es.scribd.com/doc/92941618/Libro-de-
Programacion-Web. Fecha de Consulta: Octubre 2012
Gaston Dehesa Valencia - Programación web, capitulo 2.2 Lenguajes de programación del lado
del cliente página 53. Libro Online, Disponible en: http://es.scribd.com/doc/92941618/Libro-de-
Programacion-Web. Fecha de Consulta: Octubre 2012
Gaston Dehesa Valencia - Programación web, capitulo 2.3 Lenguajes de programación del lado
del servidor paginas del 55 al 58. Libro Online. Disponible en:
http://es.scribd.com/doc/92941618/Libro-de-Programacion-Web. Fecha de Consulta: Octubre
2012
71 | P á g i n a
Gaston Dehesa Valencia - Programación web, capitulo 2.5 Metodologías para el desarrollo de
aplicaciones Web. Libro Online. Disponible en: http://es.scribd.com/doc/92941618/Libro-de-
Programacion-Web. Fecha de Consulta: Octubre 2012
Gaston Dehesa Valencia - Programación web, capitulo 2.6 Aspectos de seguridad. Libro Onlin.
Disponible en: http://es.scribd.com/doc/92941618/Libro-de-Programacion-Web. Fecha de
Consulta: Octubre 2012
Políticas, Normas y Procedimientos para la elaboración de sistemas. Disponible en:
http://profesores.fi-b.unam.mx/heriolg/Ap_pnp_a.pdf. Fecha de Consulta: Octubre 2012
Manual de Políticas y Normas de Seguridad Informática, capitulo 1.1 Políticas Generales de
Seguridad. Disponible en:http://es.scribd.com/doc/49849751/Manual-de-politicas-y-normas-de-
seguridad-informatica. Fecha de Consulta: Noviembre 2012
SENCICO - Normas Técnicas Para la Seguridad e Integridad de la Información. Disponible
en: http://www.sencico.gob.pe/transparencia/directivas/2004/DirGGOAFDI020-2004.pdf. Fecha
de Consulta: Noviembre 2012
Universidad Politécnica del Oeste Mariscal Sucre – Metodología RUP. Disponible en:
http://es.scribd.com/doc/31440864/Metodologia-RUP. Fecha de Consulta: 27 Noviembre 2012
Universidad Tecnológica de Pereira – Fundamentos de la Metodología RUP. Disponible
en:http://es.scribd.com/doc/297224/RUP. Fecha de Consulta: 27 Noviembre 2012
Universidad Tecnológica de Pereira – Fundamentos de la Metodología RUP. Disponible
en:http://es.scribd.com/doc/297224/RUP. Fecha de Consulta: 27 Noviembre 2012
72 | P á g i n a
SlideShare - Modelo de Encuesta, Diseño de Cuestionario y tamaño de Muestra.Diapositiva
1-10. Disponible en: http://www.slideshare.net/AnaLucaCayaoFlores/modelo-de-encuestas-
cuestionario-tamao-de-muestra. Fecha de Consulta 25 Noviembre 2012
Universidad de Córdoba - Diseño de Encuesta.Disponible en:
http://www.uco.es/zootecniaygestion/img/pictorex/09_13_21_sesion_6.pdf. Fecha de Consulta
28 Noviembre 2012
Modelo de Encuesta de Satisfacción del servicio de transporte.Disponible en:
http://modelodeencuesta.wordpress.com/2010/11/05/modelo-de-encuesta-de-satisfaccion-del-
servicio-de-transporte. . Fecha de Consulta 25 Noviembre 2012
ProTransporte - Caracterización de las empresas de transporte Público urbano de pasajeros
que operan en los seis Corredores seleccionados para el estudio deconsolidación del sistema
integrado de Transporte público de Lima.Disponible en:
http://www.protransporte.gob.pe/COSAC_II/Anexos/Componente3/Capitulo3.2/SIT_LIMA_C3-
Anexo3.2.pdf. . Fecha de Consulta 2 Diciembre 2012
Municipalidad de Lima- Cifras. Disponible en: http://www.munlima.gob.pe/ciudad/cifras.html.
Fecha de Consulta: 3 Diciembre 2012
Monografías – Calculo del tamaño de una muestra. Disponible en:
http://www.monografias.com/trabajos87/calculo-del-tamano-muestra/calculo-del-tamano-
muestra.shtml. Fecha de Consulta: 3 Diciembre 2012
73 | P á g i n a
