pis1.wikispaces.compis1.wikispaces.com/file/view/pis1_capitulo_1,2,3.docx · web viewen la...
TRANSCRIPT
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 la implementación 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 TABLAS
Tabla 1: Transporte Masivo Cartagena De Indias...............................................................12
Tabla 2: Tabla de Operacionalización de Variables.............................................................82
Tabla 3: Edad de los encuestados.........................................................................................85
Tabla 4: Sexo de los Encuestados..........................................................................................85
Tabla 5: Tabla de Resultado sobre la calificación del servicio de bus que más un usuario
utiliza.....................................................................................................................................86
Tabla 6: Tabla del Resultado sobre las razones de acuerdo a la calificación de que el
servicio es pésimo o regular..................................................................................................86
Tabla 7: Tabla del Resultado sobre las razones de acuerdo a la calificación de que el
servicio es bueno o excelente.................................................................................................87
Tabla 8: Tabla del Resultado sobre la frecuencia con que se utiliza un bus.........................88
Tabla 9: Tabla del Resultado sobre tiempo aproximado para abordar un bus....................89
Tabla 10: Tabla del Resultado sobre gasto de utilización de un bus.....................................89
Tabla 11: Tabla del Resultado sobre número de personas que cuentan con servicio a
Internet.................................................................................................................................90
Tabla 12: Tabla del Resultado sobre frecuencia de problemas relacionados al tarifario.....91
3 | P á g i n a
INDICE GENERAL
INTRODUCCIÓN..........................................................................................................................2Lista de Tablas................................................................................................................................31. FORMULACIÓN DEL PROBLEMA..................................................................................7
1.1. Planteamiento del Problema...........................................................................................71.1.1.Delimitación................................................................................................................81.1.2.Viabilidad...................................................................................................................8
1.1.2.1.Recursos Económicos...................................................................................81.1.2.2.Recursos de Información.............................................................................81.1.2.3.Recursos de Tiempo.....................................................................................8
1.2. Antecedentes de Solución................................................................................................91.2.1.Nacionales...................................................................................................................91.2.2.Internacionales.........................................................................................................10
1.3. Propuesta de Solución...................................................................................................131.4. Alcance de la Propuesta................................................................................................141.5. Justificación....................................................................................................................141.6. Objetivos.........................................................................................................................15
1.6.1.Objetivos General....................................................................................................152. MARCO TEÓRICO.............................................................................................................15
2.1.Marco Conceptual.............................................................................................................162.1.1.Conceptos básicos....................................................................................................16
2.1.1.1.Sistema............................................................................................................162.1.1.2.Base de datos...................................................................................................172.1.1.3.Lenguaje de programación............................................................................17
2.1.2.Sistema de información...........................................................................................192.1.2.1.Sistemas transaccionales................................................................................202.1.2.2.Sistemas de apoyo a la toma de decisiones...................................................222.1.2.3.Sistemas de soporte para la toma de decisiones de grupo (GDSS)............242.1.2.4.Sistemas de información estratégicos (SIE).................................................27
2.1.3.Programación web...................................................................................................282.1.3.1.Protocolo http (Protocolo de Transferencia de Hipertexto)....................282.1.3.2.Comunicación entre el navegador y el servidor web..................................29
4 | P á g i n a
2.1.4.Arquitectura del WWW..........................................................................................312.1.4.1.URL’s..............................................................................................................322.1.4.2.HTML..............................................................................................................332.1.4.3.Desarrollo de aplicaciones web.....................................................................34
2.1.4.3.1.Lenguajes de programación del lado del cliente...................................352.1.4.3.2.Lenguajes de programación del lado del servidor................................362.1.4.3.3.Metodologías para el desarrollo de aplicaciones web..........................372.1.4.3.4.Aspectos de seguridad.............................................................................39
2.2.Marco Referencial.............................................................................................................402.2.1.Antecedentes:...........................................................................................................40
2.2.1.1.Nacionales.......................................................................................................402.2.1.2.Internacionales...............................................................................................43
2.3.Marco Normativo..............................................................................................................452.3.1.Sistemas y Programación........................................................................................45
2.3.1.1.Políticas para la elaboración de sistemas.........................................................452.3.1.1.1.Políticas.....................................................................................................45
2.3.1.2. Normas para la elaboración de Sistemas.........................................................492.3.1.2.1.Objetivo.....................................................................................................492.3.1.2.2.Normas Generales:...................................................................................492.3.1.2.3.Normas para el análisis de sistemas:.......................................................512.3.1.2.4.Normas para el diseño de sistemas..........................................................512.3.1.2.5.Normas para la programación y documentación de sistemas...............522.3.1.2.6.Normas para la implantación de sistemas y capacitación.....................532.3.1.2.7.Normas para el mantenimiento de sistemas...........................................55
2.3.1.2.Políticas Generales De Seguridad Informática................................................552.3.1.3.Normas específicas para la seguridad de información...................................58
2.3.1.3.1.Del Acceso a la Información...................................................................582.3.1.3.2.De la Protección Especial de la Información........................................602.3.1.3.3.De la Integridad de la Información........................................................612.3.1.3.4.Seguridad de la Información..................................................................62
2.4.Hipótesis.............................................................................................................................632.4.1.Variables Independientes........................................................................................632.4.2.Variables Dependientes...........................................................................................63
3. MARCO METODOLÓGICO.............................................................................................63
5 | P á g i n a
3.1.Metodología para el análisis y diseño de la solución......................................................633.1.1.Metodología RUP.....................................................................................................63
3.1.1.1.Características del RUP.....................................................................................643.1.1.2.Descripción de las Fases:...................................................................................673.1.1.3.Beneficios de la Metodología Orientada a Objetos.........................................733.1.1.4.Ventajas de la Metodología Orientada a Objetos...........................................733.1.1.5.Determinación de las causas..............................................................................743.1.1.6.Desarrollo de la Metodología RUP...................................................................75
3.1.2.Operacionalización de variables.............................................................................813.1.3.Técnicas e Instrumento de Recolección de Datos.................................................82
3.1.3.1.Universo...............................................................................................................823.1.3.2.Muestra...............................................................................................................823.1.3.3.Técnica.................................................................................................................843.1.3.4.Instrumento.........................................................................................................84
3.1.3.5.Método Recolección de Datos..............................................................................843.1.4.Análisis de Datos......................................................................................................84
3.2.Metodología para el estudio de factibilidad (viabilidad) de la solución.......................913.2.1.Impacto Social..........................................................................................................913.2.2.Impacto Económico.................................................................................................923.2.3.Viabilidad Legal.......................................................................................................95
REFERENCIAS...........................................................................................................................96ANEXO........................................................................................................................................102
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 se ha vuelto cada vez más caótico,
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, el sistema de tarifa, 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.
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,
7 | P á g i n a
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, 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.1.1. Delimitación
La ciudad de Lima Metropolitana es el lugar donde se concentra el mayor parque
automotor del país, por ende hemos seleccionado como caso de estudio y donde
se realizara nuestra presente investigación.
1.1.2. Viabilidad
1.1.2.1. Recursos Económicos
Para la realización de esta investigación, se cuenta con recursos
económicos suficientes para el desarrollo del sistema, así como los gastos
para la obtención de información.
1.1.2.2. Recursos de Información
Al hacerse uso del lenguaje de programación .NET para la realización del
sistema, se cuenta con el IDE de desarrollo Visual Studio 2010 Ultimate,
así como el uso de la base de datos SQLServer 2008 para el
almacenamiento de información y conexión con el sistema. Además del
uso del manejo de componentes electrónicos, en este caso el lector de
código de barras, para la comunicación con el sistema.
1.1.2.3. Recursos de Tiempo
Se cuenta con un tiempo establecido para la realización de este proyecto de
investigación fijado en los cursos de Proyectos de Ingeniería de Sistemas I
y II
8 | P á g i n a
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
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.
9 | P á g i n a
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’.
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”1, 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 EMT1Navega 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
Figura1: Linea de Autobuses de EMT
Consultar incidencias de servicio en tiempo real
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
11 | P á g i n a
Figura2: Interfaz del mapa interactivo "Navega por Madrid"
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.
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
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.
13 | P á g i n a
Tabla 1: Transporte Masivo Cartagena De Indias
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 bajar
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
14 | P á g i n a
Figura3: Diseño del sistema automatizado de Transporte
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
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.
Objetivos Específicos
Simular el sistema de información en el establecimiento de los horarios por
parte de los buses15 | P á g i n a
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
bibliografías, artículos, documentos y linkografías para describir y explicar los temas
relacionados a la investigación.
1.
2.
2.1. MARCO CONCEPTUAL
Desde nuestro punto de vista, la informalidad de los controladores de una determinada
empresa de transporte público para cumplir su función, ha generado una mala costumbre
como efectos de sus acciones inmorales en los choferes de los respectivos buses de estas
empresas, debido a que aceptan una “coima” por parte de los choferes o cobradores a
cambio de adulterar su tiempo real de llegada a los respectivos lugares de control.
En consecuencia de lo mencionado, los choferes al no estar debidamente controlados, se
sienten con la libertad de hacer lo que mejor les parezca y actuar de acuerdo a su
conveniencia, provocando los problemas actuales que vemos día a día como los famosos
“correteos” por consecuencia de disminuir o aumentar su velocidad, peligrosas
16 | P á g i n a
maniobras que pueden acabar incumpliendo las normas de transito, no cumplir con toda
la ruta respectiva o no cobrar correctamente el tarifario de viaje; y muy aparte de estos
problemas que afectan a la sociedad, ellos también son sancionados por parte de las
empresas al no llegar al paradero final a su respectivo tiempo; por lo que todo esto ha
provocado una mala cultura entres ellos y haciendo decadente el servicio de transporte
público, donde los principales perjudicados son los usuarios dependientes de este
servicio.
Bajo este criterio, es que se está desarrollando el presente trabajo de investigación, ya
que hoy en día, con el avance de la tecnología, la mayoría de los ciudadanos tienen
mayor acceso a Internet ya sé por medio de un computador, PDA o Smartphones; para lo
cual se empezara a dar conceptos claves que permitan entender el desarrollo de nuestro
trabajo:
2.1.1. CONCEPTOS BÁSICOS
2.1.1.1. Sistema
Un sistema es un conjunto de partes o elementos organizados y relacionados
que interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada)
datos, energía o materia del ambiente y proveen (salida) información, energía o
materia.
Un sistema puede ser físico o concreto (una computadora, un televisor, un
humano) o puede ser abstracto o conceptual (un software).
2.1.1.2. Base de Datos
Se define una base de datos como una serie de datos organizados y
relacionados entre sí, los cuales son recolectados y explotados por los sistemas
de información de una empresa o negocio en particular.
Características
Entre las principales características de los sistemas de base de datos
podemos mencionar:
17 | P á g i n a
Independencia lógica y física de los datos.
Redundancia mínima.
Acceso concurrente por parte de múltiples usuarios.
Integridad de los datos.
Consultas complejas optimizadas.
Seguridad de acceso y auditoría.
Respaldo y recuperación.
Acceso a través de lenguajes de programación estándar.
2.1.1.3. Lenguaje de Programación
Un lenguaje de programación es un lenguaje artificial que puede ser usado
para controlar el comportamiento de una máquina, especialmente una
computadora. Estos se componen de un conjunto de reglas sintácticas y
semánticas que permiten expresar instrucciones que luego serán interpretadas.
En su uso, un lenguaje de programación puede acercarse a la forma humana
de expresarse y, por eso, este tipo de lenguajes es llamado de alto nivel. Esto
significa que utilizan palabras y formas en sus estructuras que se asemejan al
lenguaje natural (especialmente al inglés). En cambio, aquellos lenguajes que
se aproximan más a la forma en la cual la computadora se maneja, son
llamados lenguajes de bajo nivel. Esto significa que lo que el programador
deba escribir se acercará al lenguaje máquina, que es, en definitiva, lo que las
computadoras pueden interpretar.
Existen lenguajes del tipo script que son directamente ejecutados por un
intérprete y no necesitan compilación.
Los lenguajes de programación pueden clasificarse según el paradigma que
usan en: procedimentales, orientados a objetos, funcionales, lógicos, híbridos,
etc., clasificación que depende de motivos que escapan al alcance de este
artículo.
18 | P á g i n a
Son ejemplos de lenguajes de programación: php, prolog, asp, actionscript,
ada, python, pascal, c, basic, java, etc.
Para nuestra Investigación se utilizara el lenguaje de Programación ASP.NET
ASP/ASP.Net
ASP (Active Server Pages) es un lenguaje de programación de Microsoft “del
lado del servidor”, con el cual se realizan sitios Web dinámicos. Generalmente
se comercializa junto con el servidor ISS (Internet Information Server). Se
llama ASP clásico a las versiones 1.0, 2.0 y 3.0, es decir a las previas al
ASP.NET. Al crear sitios con este lenguaje se combina HTML con las
instrucciones ASP. También se pueden emplear tecnologías como Flash y
JavaScript junto con ASP y HTML.
A partir del año 2002 Microsoft lanzó al mercado el lenguaje ASP.NET. Este
lenguaje es más ordenado que el ASP, dado que se separa el contenido de un
sitio de su comportamiento dinámico. Por otra parte, una restricción del ASP y
del ASP.NET es que este lenguaje sólo puede ser ejecutado en el sistema
operativo Windows.
2.1.2. SISTEMA DE INFORMACIÓN
Un sistema de información (SI) es un conjunto de elementos orientados al
tratamiento y administración de datos e información, organizados y listos para su
uso posterior, generados para cubrir una necesidad u objetivo.
Los elementos que se requieren para el funcionamiento del sistema de información
son: el componente físico (computadoras y sus complementos), programas
(manejo de datos), el recurso humano .
Un sistema de información desarrolla cuatro actividades básicas: entrada,
almacenamiento, procesamiento de datos y salida de información.
Entrada de información:
19 | P á g i n a
Proceso en el cual se toman los datos requeridos para procesar la información,
las entradas se pueden hacer manual o automáticamente. En la primera el
usuario aporta la información directamente y en la segunda, los datos
provienen de otros sistemas.
Almacenamiento de la información:
Es un proceso en el cual se guarda la información en archivos que pueden ser
recuperados en cualquier momento.
Procesamiento de la información:
Permite la transformación de los datos fuentes en resultados por la aplicación
de mecanismos o indicadores que soporten la toma decisiones.
Salida de información:
Es la capacidad de un sistema para sacar la información procesada hacia otro
sistema o usuario.
La principal función de los SI es proporcionar la información que necesitan los
distintos grupos dentro de ella, para esto deben alinearse con las
organizaciones y al mismo tiempo, estas deben tener conciencia y abrirse a las
influencias de los SI para beneficiarse de las nuevas tecnologías. Como existen
muchas clases de organizaciones, resulta que la tecnología de los SI tendrá un
impacto diferente en cada tipo, por lo tanto, diferentes instituciones en distintas
circunstancias experimentan efectos diferentes de la misma tecnología.
Tipos de sistemas de información
Sistemas transaccionales
Sistemas de apoyo a las decisiones
Sistemas estratégicos
2.1.2.1. Sistemas transaccionales
Es un tipo de sistema de información diseñado para recolectar, almacenar,
modificar y recuperar todo tipo de información que es generada por las
20 | P á g i n a
transacciones en una organización. Una transacción es un evento o proceso
que genera o modifica la información que se encuentran eventualmente
almacenados en un sistema de información.
Estos sistemas se dirigen principalmente a las áreas de ventas y
mercadotecnia, administración y finanzas y al área de recursos humanos.
Propiedades de los Sistemas Transaccionales:
a) Automatizan tareas operativas en una organización,
permitiendo ahorrar en personal.
b) Suelen dirigirse especialmente al área de ventas, finanzas,
marketing, administración y recursos humanos.
c) Suelen ser los primeros sistemas de información que se
implementan en una organización.
d) Sus cálculos y procesos suelen ser simples.
e) Se suelen utilizar para cargar grandes bases de datos.
f) Los beneficios de este tipo de sistemas en una organización
son rápidamente visibles.
g) Estos sistemas son optimizados para almacenar grandes
volúmenes de datos, pero no para analizar los mismos.
Características esperables de un sistema transaccional
Para que un sistema informático pueda ser considerado como un
sistema transaccional, debe superar el Tes. ACID.
Rapidez: Deben ser capaces de responder rápidamente, en
general la respuesta no debe ser mayor a un par de segundos.
Fiabilidad: Deben ser altamente fiables, de lo contrario podría
afectar a clientes, al negocio, a la reputación de la
organización, etc. En caso de fallas, debe tener mecanismos de
recuperación y de respaldo de datos.
Inflexibilidad: No pueden aceptar información distinta a la
establecida. Por ejemplo, el sistema transaccional de una
aerolínea debe aceptar reservas de múltiples agencias de
21 | P á g i n a
viajes. Cada reserva debe contener los mismos datos
obligatorios, con determinadas características
Beneficios de los Sistemas transaccionales
a) Rapidez para procesar información
b) Exactitud de los cálculos
c) Facilidad para manejar grandes vol. De información.
d) Capacidad de almacenamiento de información
e) Calidad de presentación de los resultados
f) Reducción de costos a largo plazo
g) Información rápida para tomar decisiones
h) Permite compartir información entre usuarios
Desventajas de los Sistemas transaccionales
a) Altos costos iníciales
b) Dependencia del funcionamiento del sistema
c) Rápida obsolescencia del hardware y software
d) Automatización del personal
e) Requiere capacitación y personal especializado
f) Vulnerabilidad ante “virus”
g) Resistencia del personal al cambio
h) Desaprovechamiento de equipo
2.1.2.2. Sistemas de apoyo a la toma de decisiones
Se define a los sistemas de soporte para la toma de decisiones como un
conjunto de programas y herramientas que permiten obtener de manera
oportuna la información que se requiere durante el proceso de la toma de
decisiones que se desarrolla en un ambiente de incertidumbre.
El verdadero objetivo de un sistema de apoyo a las decisiones es
proporcionar la mayor cantidad de información relevante en el menor
tiempo posible, con el fin de decidir lo más adecuado.
Tipos de Sistema de apoyo a las decisiones
22 | P á g i n a
Sistemas de soporte para la toma de decisiones (DSS: Decision Support
Systems) que tienen como finalidad apoyar la toma de decisiones
mediante la generación y evaluación sistemática de diferentes
alternativas o escenarios de decisión mediante el empleo de modelos y
herramientas computacionales.
Un DSS no soluciona problemas, ya que sólo apoya el proceso de toma de
decisiones. La responsabilidad de tomar una decisión, de adoptarla y de
ponerla en práctica es de los administradores, no del DSS.
Sistemas de información para ejecutivos (EIS: Executive Information
Systems), dirigidos a apoyar el proceso de toma de decisiones de los
altos ejecutivos de una organización, presentan información relevante y
usan recursos visuales y de fácil interpretación, con el objetivo de
mantenerlos informados.
Sistemas para la toma de decisiones de grupo (GDSS: Group
Decisiotfupport Systems), los cuales cubren el objetivo de lograr la
participación de un grupo de personas durante la toma de decisiones en
ambientes de anonimato y consenso, apoyando decisiones simultáneas.
Sistemas expertos de soporte para la toma de decisiones (EDSS: Expert
Decision Support Systems), los que permiten cargar bases de
conocimiento integrados por una serie de reglas de sentido común para
que diferentes usuarios las consulten, apoyen la toma de decisiones, la
capacitación, etcétera
Características de los Sistemas de Soporte para la toma de
Decisiones (DSS)
Existen varias características que deben estar presentes en un sistema para
poder considerarlo un DSS.
Interactividad: Sistema computacional que puede interactuar en forma
amigable y con respuestas a tiempo real con el encargado de tomar
decisiones.
23 | P á g i n a
Tipo de decisiones: Apoya el proceso de toma de decisiones
estructuradas y no estructuradas
Frecuencia de uso: Tiene una utilización frecuente por parte de la
administración media y alta para el desempeño de su función.
Variedad de usuarios: Puede ser empleado por usuarios de diferentes
áreas funcionales como ventas, producción, administración, finanzas y
recursos humanos.
Flexibilidad: Permite acoplarse a una variedad determinada de estilos
administrativos: autocráticos, participativos, etcétera.
Desarrollo: Permite que el usuario desarrolle de manera directa modelos
de decisión sin la participación operativa de profesionales en
informática.
Interacción ambiental: Permite interactuar con información externa
como parte de los modelos de decisión.
Comunicación interorganizacional: Facilita la comunicación de
información relevante de los niveles altos hacia los niveles operativos y
viceversa, a través de gráficas.
Acceso a bases de datos: Tiene capacidad de accesar información de las
bases de datos corporativas.
Simplicidad: Simple y fácil de aprender y utilizar por el usuario final.
2.1.2.3. Sistemas de soporte para la toma de decisiones de grupo (GDSS)
Según De Sanctis y Gallupe, un sistema de soporte para la toma de decisiones de
grupo (GDSS) es un sistema interactivo basado en una computadora, el cual facilita la
solución de problemas no estructurados por un conjunto de tomadores de decisiones
que trabajan juntos como grupo. Los componentes de que consta son hardware,
software, recursos humanos y procedimientos.
Requerimientos mínimos de Hardware
Dispositivo de entrada y salida (entrada = teclado y/mouse, salida = monitor).
Procesador (Por lo general es una computadora).
24 | P á g i n a
Una línea de comunicación entre el dispositivo de entrada/salida y el procesador.
Una pantalla o monitores individuales.
Componentes del Software
Una base de datos que cuente con la información relacionada con la decisión que
debe tomarse y la consulta y búsqueda de temas específicos.
Una base de modelos, de la cual se puedan elegir diferentes alternativas para tomar
una decisión.
Programas como procesadores de palabras, graficadores, hojas de cálculo, o
paquetes estadísticos.
Una interfaz flexible y fácil de usar, que permita al ejecutivo interactuar de manera
adecuada sin la necesidad de mucha capacitación en la misma.
Recursos humanos
Este componente incluye a las personas que participan en el proceso de tomas de
decisiones, aun operador del GDSS y a un facilitador. Roles de las distintas
personas que participan en el grupo-Líder o facilitador.
El líder es el facilitador del proceso, es quien da instrucciones y dirige el
funcionamiento del grupo.
También puede ser el responsable de lograr ciertos objetivos durante las sesiones
de trabajo, como planear y preparar las reuniones con anticipación, clarificar las
ideas, etc.
Solicitante (jefe o encargado del grupo). Su rol es esencial para definir los
objetivos de las reuniones y seleccionar las actividades que se ejecutan durante la
sesión de toma de decisiones.
Cabe mencionar que en ocasiones el líder y el solicitante son la misma persona.
Participantes. El resto de las personas que toman parte en las reuniones y cuya
función principal es recolectar y/o proveer información a la junta apoyando se en
la experiencia y conocimiento que tienen del problema planteado.
25 | P á g i n a
Procedimientos
Los procedimientos con que cuenta un GDSS son los que facilitan el uso eficaz y
la operación de la tecnología de los sistemas por parte de los miembros del grupo.
Estos pueden referirse al uso del hardware o el software e incluir reglas para el
manejo de la discusión verbal entre los miembros del grupo o para el flujo de los
eventos durante la junta.
Características de los GDDS
Son sistemas diseñados para apoyar las decisiones en grupo, lo que implica que no
están formados por elementos de sistemas ya existentes.
La meta es apoyar el trabajo de los tomadores de decisiones, por lo que mejora el
proceso de la toma de decisiones así como las decisiones resultantes.
Debe ser fácil de entender y de usar, es decir, partiendo que será utilizados por
usuarios con diferentes niveles de conocimientos computacionales (generalmente
son administradores de cualquier área funcional de la empresa como ventas,
producción, recursos humanos administración, finanzas, etc.).
Puede ser específico o general. Es específico si se diseña para un tipo o clase de
problema, y es general si se diseña para diversas decisiones organizacionales.
Contiene mecanismo para evitar el desarrollo de conductas negativas en el grupo,
como son los problemas de comunicación, estar de acuerdo con lo que dice la
mayoría sólo por estar con el grupo o proponer ideas con la intención de molestar
a algún miembro del grupo.
Debe motivar a todos los elementos del grupo a participar de manera activa. Es
importante cuidar el anonimato de la participación.
Ventajas del Uso de GDSS
a) Motiva a los elementos del grupo a trabajar juntos
b) Mejora la etapa de preparación de la reunión
c) Da la misma oportunidad de participación a todos los miembros de la
reunión
26 | P á g i n a
d) Se optimiza el uso de la información que aporta cada persona cuando el
grupo es numeroso
e) Proporciona un mecanismo para enfocar la atención del grupo en el tema
principal y evitar distracciones con temas irrelevantes o no agendados en
la junta
f) Apoya el desarrollo de una memoria organizacional de una junta a otra
g) Mejora la calidad en la toma de decisiones debido al anonimato de las
contribuciones y permite una mayor participación
h) Incrementa la creatividad en la toma de decisiones, ya que permite que
todos los miembros participen
Desventajas del Uso de GDSS
a) Falta de costumbre al utilizar un sistema para soportar el proceso de toma
de decisiones diferente al de la forma tradicional de realizarlo
b) Resistencia al cambio por parte de los administradores, por pensar que el
sistema puede desplazarlos
c) La responsabilidad al tomar una decisión pudiera diluirse ya que las
aportaciones son anónimas y la decisión representa al consenso del grupo
d) Que en el grupo no exista una cultura desarrollada de trabajo de grupo
2.1.2.4. Sistemas de Información Estratégicos (SIE)
Un Sistema de Información estratégico puede ser considerado como el uso de
la tecnología de la información para soportar o dar forma a la estrategia
competitiva de la organización, a su plan para incrementar o mantener la
ventaja competitiva o bien reducir la ventaja de sus rivales.
Los SIE cambian las metas, operaciones, productos o relaciones con el
entorno de las instituciones para ayudarlas a ganar una ventaja sobre la
competencia. A menudo cambian a la institución así como a los productos,
servicios y procedimientos internos, llevándola a nuevos patrones de
comportamiento. Tales cambios con frecuencia requieren de nuevos
27 | P á g i n a
administradores, una nueva mano de obra y una relación más estrecha con los
clientes y proveedores.
En general, los SIE proporcionan ventajas de mercado
significativas principalmente incrementando los costos de entrada de los
competidores. Sise repiten las ventajas a corto plazo, de cualquier manera la
empresa gana una ventaja para 5 años y puede utilizar el tiempo y los recursos
adicionales que trae el liderazgo para asegurar mantener la ventaja
tecnológica.
Características
Cambian significativamente el desempeño de un negocio al medirse por uno o
más indicadores clave, entre ellos, la magnitud del impacto. Contribuyen al
logro de una meta estratégica.
Generan cambios fundamentales en la forma de dirigir una compañía, la forma
en que compite o en la que interactúa con clientes y proveedores.
Clasificación:
Sistemas que modifican el estilo de operación del negocio
Sistemas de soporte para la toma de decisiones
Sistema de soporte para las decisiones en grupo
Sistemas de información ejecutiva
Pasos a seguir en el proceso de planeación de sistemas estratégicos
Los pasos para una adecuada planeación de sistemas estratégicos son:
Fase A: Introducir a los administradores de la informática de la
organización en la perspectiva estratégica de los sistemas dar un
panorama del proceso y describir varios casos.
Fase B: Conducir una sesión de “lluvia de ideas” con los
administradores de la función de la información. Identificar áreas de
oportunidad para el desarrollo de sistemas de información estratégicos.
Fase C: Conducir una sesión de “lluvia de ideas” con el responsable de
la función de informática. Identificar ideas para desarrollar sistemas de
28 | P á g i n a
información estratégicos y hacer una evaluación conjunta, considerando
las ideas que surgieron en las juntas anteriores.
Fase D: Introducir al equipo de directores del primer nivel al concepto
de sistemas de información estratégicos. Analizar ideas que se han
considerado positivas para el negocio, obtener autorización para
continuar con las sesiones de “lluvia de ideas “, involucrando al área de
planeación de la empresa.
Fase E: Conducir una sesión de “lluvia de ideas” con los responsables
del proceso de planeación del negocio. Identificar algunas ideas de
las juntas previas y hacer una evaluación final del proceso.
2.1.3. PROGRAMACIÓN WEB
2.1.3.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.3.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
29 | P á g i n a
Figura 4: 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
30 | P á g i n a
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:
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.4. 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 31 | P á g i n a
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.
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.
32 | P á g i n a
Figura5: Arquitectura del www
2.1.4.1. URL’s.
URL significa Uniform Resource Locator, es decir, localizador uniforme de
recurso. Es una secuencia de caracteres, de acuerdo a un formato estándar, que
se usa para nombrar recursos, como documentos e imágenes en Internet, para
su localización.
El URL es la cadena de caracteres con la cual se asigna una dirección única a
cada uno de los recursos de información disponibles en la Internet. Existe un
URL único para cada página de cada uno de los documentos de la World
Wide Web.
Una URL indica tanto una dirección de Internet como el servicio que se
espera ofrezca el servidor al que corresponde la dirección. Tiene el siguiente
formato:
servicio://máquina:puerto/ruta/archivo@usuario
Donde el servicio podrá ser uno de los siguientes:
a) http:Es el servicio invocado para transmitir páginas Web y el que se usará
normalmente en los enlaces.
b) https:Es una innovación sobre el anterior, que permite acceder a
servidores (generalmente comerciales) que ofrecen el uso de técnicas de
encriptación para proteger los datos que se intercambien con él de terceras
personas.
c) ftp: Permite trasmitir archivos desde servidores de ftp anónimo. Si no se le
pide un archivo sino un directorio, en general el navegador se encargará de
33 | P á g i n a
mostrar el contenido del mismo para que se pueda escoger el archivo
cómodamente. Utilizando la @ se puede acceder a servidores privados.
d) mailto:Para poder mandar un mensaje. Por ejemplo, la
URLmailto:[email protected] me enviaría un mensaje.
e) News: Para poder acceder a foros de discusión (mal traducidos a veces
como grupos de noticias). Se indica el servidor y el grupo. Por
ejemplonews://news.ibernet.es/es.comp.demos se conectaría con el
foroes.comp.demos en el servidor nacional de Telefónica.
f) telnet:No es implementado generalmente por los navegadores, que suelen
invocar un programa externo. Permite conectarse con otras computadoras
externas y entrar a ellos como si la computadora local fuese una terminal
del mismo.
La dirección de la máquina puede ser, o bien la dirección IP compuesto por
una serie de cuatro números entre 0 y 255 (148.208.237.1) o bien algo más
fácil de recordar cómo es una serie de palabras separadas por puntos
(www.itistmo.edu.mx).
2.1.4.2. 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 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
34 | P á g i n a
utiliza en muchas aplicaciones electrónicas como buscadores, tiendas en línea
y banca electrónica.
2.1.4.3. Desarrollo de aplicaciones web
Arquitectura de las 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).
35 | P á g i n a
2.1.4.3.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
Javascript
Javascript es un lenguaje de programación utilizado para crear
pequeños programitas encargados de realizar acciones dentro
del ámbito de una página Web. Se trata de un lenguaje de
programación del lado del cliente, porque es el navegador el
que soporta la carga de procesamiento. Su uso se basa
fundamentalmente en la creación de efectos especiales en las
páginas y la definición de interactividades con el usuario.
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
36 | P á g i n a
Figura 6: Arquitectura Multinivel
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.
El modo de funcionamiento de Visual Basic Script para
construir efectos especiales en páginas Web es muy similar al
utilizado en Javascript y los recursos a los que se puede acceder
también son los mismos: el navegador.
2.1.4.3.2. Lenguajes de programación del lado del servidor
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.
37 | P á g i n a
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.
38 | P á g i n a
Figura 7: Uso del Motor de PHP
2.1.4.3.3. Metodologías para el desarrollo de aplicaciones web
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
39 | 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.4.3.4. 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 publica40 | 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.
41 | 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”.
42 | 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.
Tren Eléctrico
43 | P á g i n a
Figura 8: En Julio ingresaron 56 buses nuevos a la ruta
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.
44 | 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
45 | P á g i n a
Figura 9: Tramo 1, red básica de tramo
Consultar incidencias de servicio en tiempo real
Figura 10: 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
46 | P á g i n a
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.
2.3. MARCO NORMATIVO
2.3.1. SISTEMAS Y PROGRAMACIÓN
1.
2.
2.1
2.2
2.3
2.3.1
2.3.1.1 Políticas para la elaboración de sistemas
La política de calidad se define como las directrices u objetivos generales que
tienen una institución o empresa concernientes a la calidad, las cuales son
emitidas por la dirección. De hecho, a través de la administración de la
calidad. La dirección es la encargada de difundirla y principalmente de
asegurar de que sea entendida, implantada y revisada periódicamente en su
organización.
2.3.1.1.1. Políticas
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
47 | P á g i n a
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 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
48 | P á g i n a
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. 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
49 | P á g i n a
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.
50 | 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.1.2 Normas para la elaboración de Sistemas
2.3.1.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.1.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
51 | P á g i n a
técnica, manual de instalación y manual del usuario de acuerdo al
MPDS.
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
52 | P á g i n a
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.
2.3.1.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.1.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
53 | P á g i n a
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
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.1.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.
54 | P á g i n a
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.
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.1.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.
55 | P á g i n a
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
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.
56 | P á g i n a
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.1.2.7 Normas para el mantenimiento de sistemas
El área usuaria deberá solicitar el mantenimiento de un sistema a su
área 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.1.2. Políticas Generales De Seguridad Informática
Del Departamento de Redes y Comunicaciones
Art. 1. Normar el correcto uso de los servicios de Internet y correo electrónico
en la empresa.
57 | P á g i n a
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.
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.
58 | P á g i n a
Art. 10. Administrar y asignar todas las direcciones IP de la Empresa, así
como los dominios y subdominios asignados a la Empresa.
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.
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.
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.
59 | P á g i n a
Art. 2. Realizar respaldos diarios de la información contenida en los
servidores del Instituto.
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
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.1.3. NORMAS ESPECÍFICAS PARA LA SEGURIDAD DE
INFORMACION
2.3.1.3.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
60 | P á g i n a
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.
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.
61 | P á g i n a
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.
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.1.3.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.
62 | P á g i n a
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.1.3.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 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.
63 | P á g i n a
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.
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.1.3.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
64 | P á g i n a
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. 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.4.1. VARIABLES INDEPENDIENTES
Simulación de tiempos de salida de los buses
Simulación de la accesibilidad al sistema
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.4.2. VARIABLES DEPENDIENTES
Control de tiempos de llegada a un paradero respectivo
Margen de separación entre los buses
Control de acceso al sistema
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
65 | P á g i n a
3.1.1. 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 Lenguaje
Unificado de Modelado UML, 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í.
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 Rational Method
Composer(RMC), que permite la personalización de acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso
Unificado, y una especificación más detallada, el Rational Unified Process, que se
vendiera como producto independiente.
1.
2.
3.
3.1.
3.1.1.
3.1.1.1. 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.
66 | P á g i n a
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 de Uso 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 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:67 | P á g i n a
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.
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ón continúa de la calidad
Gerenciar los cambios
Ver Figura 11 donde se observan las interacciones entre las etapas de RUP.
68 | P á g i n a
3.1.1.2. Descripción de las Fases:
69 | P á g i n a
Figura 11: Interacciones entre etapas de la Metodología RUP
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.
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 sus
procesos. 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 (rendimien
to 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.
70 | P á g i n a
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:
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 pseudo requerimientos.
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 paracad
a 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.
71 | P á g i n a
c) Fase de Construcción: Se implementan las clases y objetos en ficheros
fuente, binarios, ejecutables y demás. El resultado final es un sistema
ejecutable.
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 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.
72 | P á g i n a
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 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 negocio73 | P á g i n a
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
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:
74 | P á g i n a
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
3.1.1.3. Beneficios de la Metodología Orientada a Objetos
Promueve la reusabilidad.
Reduce la complejidad del mantenimiento (extensibilidad y facilidad de
cambios).
Riqueza semántica.
Disminuye la brecha semántica entre la visión interna y la visión
externa del sistema.
Facilita la construcción de prototipos.
3.1.1.4. 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.
75 | P á g i n a
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.
3.1.1.5. Determinación de las causas
Educación Principal causa que enfoca la falta de concientización
cultural y conductual por la mayoría del personal de a empresa,
choferes, cobradores, controladores, entre otros
Control Principal causa que se enfoca en la falta de o bajo
mecanismos, acciones o herramientas para detectar la presencia de
errores o inspección sobre el personal que labora para la empresa
Tarifario Principal causa que hace referencia al costo que un usuario
debe de pagar por la movilización de un trayecto determinado, variando
según el tamaño del trayecto
Conductores Principal causa que habla sobre los problemas que pueden
causar estos agentes por sus malas conductas o hábitos, perjudicándose
así mismos y a los usuarios.
76 | P á g i n a
3.1.1.6. Desarrollo de la Metodología RUP
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
a) Fase de inicio
77 | P á g i n a
Figura 12: Diagrama de Ishikawa
FUENTE: Elaboración Propia
Vista General del Proyecto
Propósito
El propósito de éste documento es recoger, analizar y definir las
necesidades de alto nivel y las características de la simulación
del sistema de información para la mejora del servicio de
transporte público. El documento se centra en la funcionalidad
requerida por los participantes en el proyecto y los usuarios
finales.
Esta funcionalidad se basa principalmente en la gestión de los
buses que tiene la empresa, de forma que dichos buses lleguen a
los paraderos a sus respectivos tiempos.
Los detalles de cómo el sistema cubre los requerimientos se
pueden observar en la especificación de los casos de uso y otros
documentos adicionales.
Alcance
El documento Visión se ocupa, como ya se ha apuntado, de la
simulación del sistema de información para la mejora del
servicio de transporte público.
Mediante la simulación del sistema se podrá controlar a la flota
de buses de la empresa. Además permitirá a los clientes realizar
consultas vía web, saber los paraderos y conocer el tarifario de
pasaje.
Definiciones, Acrónimos, y Abreviaciones
RUP: Son las siglas de Rational Unified Process. Se trata de una
metodología para describir el proceso de desarrollo de software.
Especificación de los requerimientos:
Establecer los horarios de tiempos de salida y llegada de
los buses
Consultar los paraderos
Brindar tarifario de los pasajes
78 | P á g i n a
Consultar el tiempo de viaje de los buses entre dos
paraderos y de acuerdo a la hora del día
b) Fase de elaboración
En esta fase se desarrollará los diagramas de casos de uso, de
secuencia y de colaboración
i. Diagrama de Casos de Uso
Proceso General del Uso del Sistema
Caso de Uso: Consultar tiempo de viajeRequisitos Asociados Sistema de información webActor Iniciador PeatónDescripción Se consulta el tiempo de viaje de un lugar a otro Precondición El paradero existePostcondición Se muestra el tiempo aprox. que durara el viajeCurso normal
1. El peatón quiere consultar el tiempo viaje2. El sistema muestra las zonas a la cual se va desplazar3. El peatón elije las zonas4. El sistema muestra el tiempo aproximado que durara su viaje
Caso de Uso: Consultar Costo de ViajeRequisitos Asociados Sistema de información webActor Iniciador PeatónDescripción Se consulta el costo de viaje por zonas
79 | P á g i n a
Consultar tiempo de viaje
Consultor costo de viaje Visualizar los horarios del bus
Peaton
Informacion del paradero
Figura 13: Diagrama de caso de Uso del Usuario
Precondición La zona existePostcondición Se muestra el costo de viaje de la zona
seleccionadaCurso normal
1. El peatón quiere consultar el costo de viaje entre dos zonas2. El sistema muestra todos las zonas3. El peatón elije la zona a la que se desplazara4. El sistema muestra el costo que debe pagar para viajar a la zona seleccionada
Caso de Uso: Visualizar los horarios del busRequisitos Asociados Sistema de información webActor Iniciador PeatónDescripción Se visualiza los horarios del bus PrecondiciónPostcondición Se muestra los horarios del busCurso normal
1. El peatón quiere visualizar los horarios de salida de los buses2. El peatón ingresa a visualizar horarios3. El sistema muestra los horarios de salida
Caso de Uso: Información de paraderosRequisitos Asociados Sistema de información webActor Iniciador PeatónDescripción Se consulta el paraderoPrecondición El paradero existaPostcondición Se muestra el paradero seleccionadoCurso normal
1. El peatón quiere consultar los paraderos2. El sistema muestra todos los paraderos3. El peatón elije el paradero deseado4. El sistema muestra el paradero
ii. Diagrama de Secuencia
80 | P á g i n a
81 | P á g i n a
:peaton:peaton :sistema:sistema :base de datos:base de datos
1: Ingresa al sistema
2: Ingesa a consultar tiempo de viaje
3: Selecciona los lugares a desplazarse
6: Muesta el tiempo aprox. en que llegara el bus
4: Envia los datos de los lugares
5: Calcula el tiempo aproximado
Figura 14: Diagrama de Secuencia del Caso de Uso Consulta tiempo de viaje
peaton:peaton: :sistema:sistema
1: Ingresa al sistema
2: Ingresa a visualizar horarios del bus
3: Sistema muestra lo horarios de salida
Figura 15: Diagrama de Secuencia del Caso de Uso Visualizar horarios del bus
:peaton:peaton :sistema:sistema :base de datos:base de datos
1: Ingresa al sistema
2: Ingresa a consultar costo de viaje
3: Selecciona la zona a la que se dirige
6: Le muestra el costo que debe pagar
4: Envia el dato
5: Le envia la informacion
Figura 16: Diagrama de Secuencia del Caso de Uso Consultar Costo de Viaje
iii. Diagrama de Colaboración
82 | P á g i n a
:peaton:peaton :sistema:sistema
1: Ingresa al sistema
2: Ingresa a informacion de paraderos
3: Muestra ubicacion de los paraderos
Peaton
Sistema
Base de datos
1: selecciona consultar tiempo de viaje
2: Envia los datos de los lugares
3: Envia el tiempo calculado4: Muestra el tiempo aprox. de su viaje
Figura 18: Diagrama de Colaboración del Caso de Uso Consulta tiempo de viaje
Peaton Sistema1: Selecciona visualizar horario del bus
2: Le muestra los horarios de salida de los buses
Figura 19: Diagrama de Colaboración del Caso de Uso Visualizar horarios del busPeaton Sistema
Base de datos
1: Selecciona a la zona a la que se dirige
2: Envia las zonas seleccionadas3: Calcula el tiempo
4: Muestra el tiempo aprox. que durara su viaje
3.1.2. Operacionalización de variables
VARIABLE
INDEPENDIENTEDEFINICIÓN OPERACIONAL INDICADORES
1. Simulación de tiempos
de salida de los buses
Se hará una simulación de las horas
en que los buses salen de su
paradero inicial, para de esta
manera establecer horarios fijos de
salida y no hacerlo de una manera
desordenada
1.1. Número de buses que salen por día
1.2. Tiempo promedio de salida entre
cada bus
1.3. Tiempo de llegada de los buses al
paradero final
1.4. Tiempo de espera entre paraderos
intermedios
1.5. Tiempo promedio del recorrido de
la trayectoria de los buses
83 | P á g i n a
Figura 20: Diagrama de Colaboración del Caso de Uso Consultar Costo de Viaje
Peaton Sistema
1: Selecciona informacion de paraderos
2: Muestra los paraderos del bus
Figura 21: Diagrama de Colaboración del Caso de Uso Consultar Información de los paraderos
2. Simulación de la
accesibilidad al sistema
Se simulará el acceso al sistema por
parte de los usuarios, ya sea por un
medio móvil o un computador
2.1. Número de visitas al sistema por
parte del usuario
2.2. Número de entradas a la intranet por
parte de la administración de la
empresa
2.3. Porcentaje de visitas desde un
computador o móvil
2.4. Cantidad de personas con permiso
para acceso a la intranet
3. Uso de la aplicación
costo de viaje
Revisar si la aplicación es muy
usada o útil para los usuarios que
acceden al sistema, permitiendo
evaluar su rendimiento
3.1. Número de veces que se utiliza la
aplicación por día
3.2. Porcentaje de consultas entre zonas
4. Uso de las consulta
sobre el tiempo
aproximado de un bus
para llegar a un
paradero respectivo
Revisar si las consultas son usadas
por los usuarios y que tan
beneficiosas son para ellos
4.1. Cantidad de consultas realizadas por
día
4.2. Porcentaje de consultas realizadas
por paradero inicial
5. Diseño del sistema
Cualquier pasos, secuencias,
actividades u operaciones que se
deben de tener en cuenta y realizar
cuando se va a desarrollar un
sistema
5.1. Elaboración de Interfaces bajo
estándares
5.2. Normalización de la base de datos
5.3. Construcción del sistema bajo
estándares de programación
Tabla 2: Tabla de Operacionalización de Variables
3.1.3. Técnicas e Instrumento de Recolección de Datos
3.1.3.1. Universo
84 | P á g i n a
Está constituido por un total de 8 445,211 sujetos de estudio, compuesto
por todos los habitantes en el departamento de Lima.
3.1.3.2. Muestra
Para saber el tamaño de la muestra que se va a tomar se empleará la
siguiente fórmula:
Donde:
n = Tamaño de la muestra.
N = Población
Z = Valor crítico correspondiente a un coeficiente de confianza del cual se
desea hacer 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.
Para este estudio se utilizó un nivel de confianza del 95% y además se
decidió utilizar una P(probabilidad de éxito) del 50% y una q(probabilidad
de fracaso) del 50%, ya que así se representa el peor escenario o bien se
tiene la misma posibilidad de éxito o fracaso. Además para un nivel de
confianza del 95% el Z= 1.96
Así mismo se acordó un error del 8%. Aunque por motivos de tiempo, ya
que se acercaba la sustentación de este capítulo se tomo un grado de error
del 8%, para llegar a tener un número posible como muestra para esta
fecha.
Por tanto aplicando la fórmula:
85 | P á g i n a
n= 1.962 x 8445211x 0.5 x0.50.082 x (8445211−1 )+1.962 x 0.5 x 0.5
n=8110780.64454050.3044
n=150.0599
Por tanto se tomará como muestra para el día de sustentación 151
habitantes en el Departamento de Lima
3.1.3.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.1.3.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.1.3.5. Método de recolección de datos
86 | P á g i n a
Para la realización de este proyecto 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.
3.1.4. Análisis de Datos
Al recopilar los datos mediante el instrumento, el grupo procederá a la tabulación
y representación gráfica de cada una de las preguntas, concluyendo con el
respectivo análisis para cada resultado de la encuesta.
La edad que predomina en esta muestra es de 20 – 24 años con un 45 % seguido con la edad de 40 a más con 19 %. Además nos indica que una parte de los encuestado fueron personas que ya tiene buen tiempo utilizando este servicio, y por tanto sus respuestas son muy valoradas
87 | P á g i n a
Tabla 3: Edad de los encuestados
FUENTE: Elaboración Propia
Figura 22: Gráfico Estadístico sobre la edad de los encuestados
Tabla 4: Sexo de los Encuestados
FUENTE: Elaboración Propia
FUENTE: Elaboración Propia
Esta encuesta fue realizada por el género masculino con 53% y por el femenino con un 47%.
Los resultados de la 1era pregunta indican que el servicio de bus es calificado como regular con un 51 % y pésimo con un 36 %, en conclusión el servicio actualmente es considero malo para la población.
88 | P á g i n a
FUENTE: Elaboración Propia
Figura 23: Gráfico Estadístico sobre el sexo de los encuestados
Tabla 5: Tabla de Resultado sobre la calificación del servicio de bus que más un usuario utiliza
Figura 24: Gráfico Estadístico sobre Pregunta 1 del Cuestionario
FUENTE: Elaboración Propia
FUENTE: Elaboración Propia
Las respuestas que indican que el servicio de bus es pésimo y regular explican que es porque va muy lleno con un 58 % y que el bus demora mucho en pasar con un 38 % seguido también por realizar maniobras riesgosas con 32 %.
89 | P á g i n a
Tabla 6: Tabla del Resultado sobre las razones de acuerdo a la calificación de que el servicio es pésimo o regular
Figura 25: Grafico estadístico sobre la pregunta 1.1 del cuestionario
FUENTE: Elaboración Propia
FUENTE: Elaboración Propia
Tabla 7: Tabla del Resultado sobre las razones de acuerdo a la calificación de que el servicio es bueno o excelente
FUENTE: Elaboración Propia
Las respuestas que indican el gráfico y tabla que el servicio de bus es excelente y bueno explican que es por la seguridad con un 64 % y que el bus es muy cómodo con un 36 %. Aunque las respuesta que indicaron que el servicio era bueno, fueron muy pocas comparadas a las otras
90 | P á g i n a
FUENTE: Elaboración Propia
Tabla 8: Tabla del Resultado sobre la frecuencia con que se utiliza un bus
FUENTE: Elaboración Propia
FUENTE: Elaboración Propia
La muestra indica que la frecuencia que se utiliza el bus es diariamente con un 62 %, también se puede destacar que es usado 2 – 3 veces a la semana por un 21 % de la muestra.
En esta pregunta se concluye que el tiempo de espera para el bus es de 10 minutos con un 50 % y de 5 minutos con 23 %, aunque hay un valor de 21% que dice que se demora 20 minutos, lo cual nos indica una de las principales razones porque en conclusión se llego a que el servicio era regular o pésimo.
91 | P á g i n a
Figura 28: Grafico estadístico sobre la pregunta 3 del cuestionario
Tabla 9: Tabla del Resultado sobre tiempo aproximado para abordar un bus
FUENTE: Elaboración Propia
FUENTE: Elaboración Propia
Tanto la gráfica como la tabla nos indican que el dinero que se gasta en el servicio de bus va de 3 nuevos soles con un 32% y de 2 nuevos soles con un 25 %, también se considera el gasto de 4 nuevos soles con un 19 %.
92 | P á g i n a
Tabla 10: Tabla del Resultado sobre gasto de utilización de un bus
Figura 29: Grafico estadístico sobre la pregunta 4 del cuestionario
FUENTE: Elaboración Propia
Tabla 11: Tabla del Resultado sobre número de personas que cuentan con servicio a Internet
FUENTE: Elaboración Propia
Este resultado da por resultado que las personas de esta muestra si cuentan con servicio de internet con un 87%, lo cual nos favorece bastante, ya que el proyecto iba a estar en la web, lo que indica que muchas personas podrán tener acceso a esta.
93 | P á g i n a
FUENTE: Elaboración Propia
Tabla 12: Tabla del Resultado sobre frecuencia de problemas relacionados al tarifario
FUENTE: Elaboración Propia
Grafico estadístico sobre la pregunta 6 del cuestionario
FUENTE: Elaboración Propia
Los resultados de la 6ta pregunta indican que la frecuencia de problemas con respecto a la tarifa es de 2-3 veces a la semana con un 40 % y de diario con un 32 %, en otras palabras, el problema con el tarifario es una de las principales causas de que el servicio sea considerado malo actualmente.
3.2. Metodología para el estudio de factibilidad (viabilidad) de la solución
3.2.1. Impacto Social
Según los resultados de la encuesta, para la pregunta 2, notamos que un 62% de la
muestra utiliza diariamente un bus y seguida de esta el 21% lo utiliza de 2-3 veces
por semana y el 14% lo utiliza de 4-5 veces a la semana, lo que sumando y
generalizando, tenemos que aproximadamente casi el 80% de habitantes en Lima
utilizan un bus en la mayor parte de la semana, lo que nos indica también que este
podría ser el posible valor porcentual de población beneficiaria cuando se llegue a
mejorar el servicio, en caso de que se implemente el presente trabajo.
Por otra parte, teniendo como base el resultado de la pregunta 5, el cual muestra
que mas del 85% de encuestados tiene acceso a Internet ya se por un móvil o
doméstico, podemos concluir que mas de los 4/5 de personas que utilizan un bus la
mayor parte de la semana podrá beneficiarse en tener el acceso a los horarios de
una línea de bus respectiva y más el beneficio porque el servicio se mejorará,
entonces esta sería parte de la población mas beneficiaria si hablamos en términos
globales para el departamento de Lima.
Por tanto el sector y tamaño de la población que se va a favorecer si se llega a
implementar el trabajo, dependería de a que empresa de transporte se implemente
este y la ruta que tenga sus respectivas línea de buses, ya que los resultados
anteriores fueron de una manera generalizada, pero tomando en cuenta que los
usuarios de una respectiva línea de bus en el mayor de los casos son demasiados,
entonces si se tomaría como población esa cantidad de usuarios, el resultado sería
similar al obtenido de manera general, obteniendo un buen porcentaje de personas
que se podrían beneficiar.
3.2.2. Impacto Económico
94 | P á g i n a
Se tomará en cuanto primero los recursos de hardware a adquirir (Costos dados en
soles):
Dispositivos Cantidad Precio(1) SubtotalSitio Web (anual) 1 S/. 600.00 S/. 600.00Router 1 S/. 200.00 S/. 200.00Cableado (por metro) 50 S/. 10.00 S/. 500.00PC’s 3 S/. 2,000.00 S/. 6,000.00Conexión a Internet y Modem 12 S/. 150.00 S/. 1,800.00Total S/. 9,100.00
Ahora en cuanto a recursos de software:
Software/ Licencia Cantidad Precio SubtotalSistema Operativo para PC’s (Windows 7)
3 S/. 110.00 S/. 330.00
Visual Studio 2008 3 S/. 1,200.00 S/.3,600.00SQL Server 2008 1 S/. 250.00 S/. 250.00Total S/. 4,150.00
Por tanto:
TOTAL1= TOTAL HARDWARE + TOTAL SOFTWARE
TOTAL1= S/. 9,100.00 +S/. 4,150.00
TOTAL1= S/. 13,250.00
Seguimos con los costos del recurso humano mensual:
Personal Cantidad Precio SubtotalJefe de Proyecto 1 S/. 3,500.00 S/. 3,500.00Analista / Programador 2 S/. 2,500.00 S/. 5,000.00Programador 2 S/. 1,800.00 S/. 3,600.00Técnicos 1 S/. 1,800.00 S/. 1,800.00Total S/. 13,900.00
95 | P á g i n a
Y como el proyecto se establece para su desarrollo en 3 meses, el costo total de
recurso humano sería:
TOTAL2=S/. 13,900.00 x 3 = S/. 41,700
Por consiguiente, de manera global el costo sería de:
TOTAL = TOTAL1+ TOTAL2
TOTAL= S/. 13,250.00+ S/. 41,700.00
TOTAL= S/. 54,950.00
Y según ProTransporte, los ingresos de estas empresas se basan en el cobro de
alquiler de la ruta que hacen los concesionarios de ruta, el cual en promedio es
S/12.35 diario a cada unidad de concesionario que opera y por cada ruta que
tienen en concesión. Y por otra parte quitando los controladores que son de la
empresa, por el hecho de que ya no deberían registrar su tiempo ya que este será
establecido entre un rango, y tomando como promedio que la cantidad de estos son
6 y se estimando un costo de S/. 500 mensuales, entonces la empresa tendría un
ingreso de :
S/. 500 x 6= S/. 3000 mensuales
Agregando que se puede incrementar en S/. 2.5 el alquiler de la ruta a un
concesionario, por le hecho de que ya no debería dar alguna “propina” a los
controladores para que le reduzcan el tiempo, y estimando que una empresa que
cuente con solo buses tiene en promedio 40 buses, se tendría un ingreso diario de:
S/. 2.5 x 40 = S/. 100
Entonces el ingreso mensual sería de:
S/. 100 x 30 días = S/. 3000
Juntando ambos ingresos, se tendrá un ingreso extra mensual de:
S/. 3000 + S/. 3000= S/. 600096 | P á g i n a
Considerando el costo del proyecto, el tiempo de pagarlo sería de:
S / .54,950S / .6,000
=9.16 meses
Concluyendo que a partir del Décimo mes de haberse implementado el
proyecto, la empresa comenzaría a sentir un ingreso extra de
aproximadamente S/. 6,000 mensuales, y en caso que tenga otra ruta a
alquilar, el ingreso extra se incrementaría en un 50% más.
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.
Y además de tener en cuenta las leyes que estén sobre la empresa a la cuál se le
este implementando el proyecto.
97 | 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-
98 | P á g i n a
2012/en-pistas-de-lima-transitan-mas-de-34-mil-buses-y-combis-por-eso-urge-reforma. Fecha de
Consulta: Septiembre 2012
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
99 | P á g i n a
Wikipedia – Sistema de Información. Disponible en:
http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n. Fecha de Consulta: 2 Noviembre
2012
Scribd - Sistemas de Información Estratégicos y Tecnologías de Información, desde la pagina
30-32. Disponible en: http://es.scribd.com/doc/94850450/Sistemas-de-ion-Estrategicos-y-TI.
Fecha de Consulta: Octubre 2012
Scribd - Sistemas Transaccionales. Disponible en: http://es.scribd.com/doc/17188468/Sistemas-
Transaccionales. Pag. 1-12. Fecha de Consulta: Octubre 2012
Scribd - Sistemas de Información, la penúltima y última diapositiva. Disponible en:
http://es.scribd.com/doc/27742693/sistemas-de-informacion. Pag. 1-10. Fecha de Consulta:
Octubre 2012
Scribd - Definición y tipos de sistemas de apoyo a decisiones. Disponible en:
http://es.scribd.com/doc/80195980/DEFINICION-Y-TIPOS-DE-SISTEMAS-DE-APOYO-A-
LAS-DECISIONES. Fecha de Consulta: Octubre 2012
Scribd - Sistema de Información Estratégico diapositiva Nº2. Disponible en:
http://es.scribd.com/doc/17181507/Sistemas-Estrategicos. Fecha de Consulta: Octubre 2012
Scribd - Sistemas de Información Estratégicos y Tecnologías de Información, las páginas 44
y 45. Disponible en: http://es.scribd.com/doc/94850450/Sistemas-de-ion-Estrategicos-y-TI. Fecha
de Consulta: Octubre 2012
100 | P á g i n a
Scribd - Sistemas de Información Estratégicos y Tecnologías de Información, las páginas 53
y 54. Disponible en: http://es.scribd.com/doc/94850450/Sistemas-de-ion-Estrategicos-y-TI. Fecha
de Consulta: Octubre 2012
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:
101 | P á g i n a
http://es.scribd.com/doc/92941618/Libro-de-Programacion-Web. Fecha de Consulta: Octubre
2012
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
102 | 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 de consolidació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
103 | P á g i n a
ANEXO
CUESTIONARIO SOBRE EL SERVICIO DE TRANSPORTE PÚBLICO
EDAD: _______________SEXO: _______________
Somos estudiantes universitarios y actualmente nos encontramos realizando un trabajo de investigación con el fin de conocer las opiniones de los usuarios sobre el servicio de transporte público, para ello le agradecemos su colaboración y veracidad al momento de responder las preguntas. Marque solo una alternativa en cada pregunta, a excepción las que diga que puede marcar más de una.
OBSERVACIÓN: En la siguiente parte del documento la siguiente palabra utilizada: Buses, hace referencia a vehículos de transporte grande o masivo
1. Según su opinión personal, califique el servicio de la línea de bus de transporte público que usted más utiliza.
a) Servicio Pésimo b) Servicio Regularc) Servicio Bueno d) Servicio Excelente
1.1. Por favor explicar su respuesta, del porque el servicio del servicio de transporte público (es pésimo/regular) para usted, en caso que los considere pésimo, malo o regular (puede marcar más de una respuesta).
a) El servicio se demora mucho b) Poca frecuencia de Vehículosc) Va muy lleno d) Realizan maniobras riesgosase) Otra, ____________________________________________
1.2. Por favor explicar su respuesta, del porque el servicio del servicio de transporte público (es bueno/excelente) para usted, en caso que lo considere bueno o excelente (puede marcar más de una respuesta)
a) Es muy cómodo b) Por la seguridadc) Por la calidad del servicio d) Por la frecuencia de los busese) Otra, _________________________________________
2. ¿Con qué frecuencia utiliza el un bus?104 | P á g i n a
a) Diariamente b) 2-3 veces a la semanac) 4-5 veces a la semana d) De vez en cuando
3. ¿Cuánto tiempo le toma aproximadamente esperar para abordar el bus que utiliza o desea utilizar?
a) 5 minutos b) 10 minutos c) 20 minutos
d) Más de 20 minutos
4. ¿Cuánto gasta normalmente cuando utiliza un bus, tanto en ida como en venida?
b) S/. 2 b) S/. 3 c) S/. 4c) S/. 5 e) Más de S/.5
5. ¿Cuenta usted con servicio de Internet por: Celular y/o Doméstico?
a) Si b) No
6.- Con referencia a la tarifa de transporte del bus que utiliza, ¿Con qué frecuencia se presentan problemas?
a) Diario b) 2-3 veces a la semana
e) 4-5 veces a la semana d) Nunca
105 | P á g i n a