Santa 5.0

INSTITUTO TECNOLGICO
SUDAMERICANO
SISTEMAS DE AUTOMATIZACIN
PROYECTO INTEGRADOR
TEMA:
DESARROLLO E IMPLEMENTAIN DE UNA APLICACIN

WEB PARA LA COOPERATIVA DE TRANSPORTE SANTA DE
LA CUIDAD DE LOJA.
INTEGRANTES:
Jorge Andres Freire Ochoa

Richard Colon Jimnez lvarez
CICLO: ASIGNATURAS:
Quinto Diurno SOFTWARE: Ing. Lorena Pucha
PROG INTERNET: Ing. Alex Yunga
LOJA ECUADOR
2017
PROYECTO INTEGRADOR
1. TEMA:
DESARROLLO E IMPLEMENTAIN DE UNA APLICACIN WEB PARA LA

COOPERATIVA DE TRANSPORTE SANTA DE LA CUIDAD DE LOJA.
2. INTRODUCCIN
2
PROYECTO INTEGRADOR
La Cooperativa de Transportes Santa se viene detectando la falta de control de las
rutas, reservacin y venta de tickets. Las causas son: La tarea de rutas, reservacin y
venta de tickets se la realiza con mtodos manuales Las rutas se las asigna a los buses
al fin de la semana, para informar a los conductores las rutas que deben tomar, la fecha
y hora a la que deben partir se realiza llamadas telefnicas, muchas veces no se puede
contactar con los encargados del bus y por tano se generen problemas. No existan
reservaciones de asientos, lo cual cause incomodidad a los clientes por tanto los
clientes busquen mejoras en otras Cooperativas.
Razn por la cual se ve la necesidad de automatizar actividades manuales que se
llevan a cabo en el Transporte Santa. A continuacin se detallan las razones que
justifican el proyecto: Permitir facilitar las tareas de asignacin de rutas a los buses
que son realizadas en forma manual por el personal a cargo de las oficinas. Permitir
administrar la disponibilidad de asientos de los buses.
El presente plan de proyecto abarca el Anlisis, Diseo y Desarrollo de una
Aplicacin de Control de rutas, reservacin y venta de tickets para la Cooperativa de
Transportes Santa, utilizando la tecnologa ASP para la interfaz en la Web, el sistema
ser Cliente - Servidor, tambin se utilizar Bases de Datos SQL Server, y las
herramientas necesarias para desarrollar dicha aplicacin. Los mdulos que comprende
la aplicacin son: Administracin de Usuarios. Administracin de Perfiles.
3
PROYECTO INTEGRADOR
Administracin de Rutas Administracin de Reservaciones Administracin de Sucursal
Administracin de Venta de Tickets.
4
PROYECTO INTEGRADOR
3. NDICE DE CONTENIDOS
1. TEMA:.......................................................................................................................2
2. INTRODUCCIN.....................................................................................................3
3. NDICE DE CONTENIDOS.....................................................................................5
4. INDICE DE FIGURAS..............................................................................................7
5. INDICE DE TABLAS................................................................................................7
6. ANTECEDENTES.....................................................................................................8
7. PROBLEMATIZACIN............................................................................................9
8. JUSTIFICACIN....................................................................................................10
9. OBJETIVOS.............................................................................................................11
9.1. OBJETIVO GENEAL......................................................................................11
9.2. OBJETIVOS ESPECIFICOS............................................................................11
10. MARCO TERICO.............................................................................................12
10.1. INGENIERIA DEL SOFTWARE.................................................................12
10.1.1. Definicin Ingeniera del Software........................................................12
10.1.2. Estado del arte de la Ingeniera del Software........................................12
10.1.3. Trmino Ingeniera del Software...........................................................13
10.1.4. El producto y el proceso de la Ingeniera del Software.........................13
10.1.4.1. El producto.........................................................................................13
10.1.4.2. El proceso...........................................................................................15
10.1.5. Modelos de Desarrollo de Software.......................................................16
10.1.5.1. Modelo en Cascada............................................................................16
10.1.5.2. Modelos Prototipos............................................................................19
10.1.5.3. Modelo Espiral...................................................................................23
10.1.5.4. Modelo de Desarrollo por Etapas.......................................................27
10.1.5.5. Modelo de Desarrollo Iterativo y Creciente o Iterativo e Incremental
.30
10.1.5.6. Modelo de Desarrollo Rpido de Aplicaciones..................................34
10.1.6. Medidas Mtricas e Indicadores............................................................38
5
PROYECTO INTEGRADOR
10.2. PROGRAMACION EN INTERNET...........................................................39

10.2.1. Django....................................................................................................39
10.2.2. Python....................................................................................................41
10.2.3. Arquitectura de la aplicacin.................................................................42
10.2.4. Base de Datos.........................................................................................44
10.2.4.1. QU SON LAS BASES DE DATOS?.............................................44
10.2.4.2. QUE ES LA NORMALIZACIN?.................................................45
11. METODOLOGA.................................................................................................45
11.1. Modelo de Ingeniera de Software................................................................45
11.1.1. Fases del Modelo...................................................................................46
12. PROPUESTA DE ACCIN O DESARROLLO..................................................48
12.1. INGENIERA DE SOFTWARE...................................................................48
12.1.1. Descripcin de la Empresa....................................................................48
12.1.2. mbito...................................................................................................53
12.1.3. Fases de Desarrollo................................................................................59
12.1.4. Planificacin o Cronograma..................................................................64
12.1.5. Recursos.................................................................................................65
12.1.6. Identificacin de Riesgos.......................................................................66
12.2. PROGRAMACION EN INTERNET:..........................................................70
12.2.1. Capturas antes de la aplicacin:.............................................................70
12.2.2. Capturas despus de la aplicacin:........................................................70
12.2.3. rbol de archivos tipo manual de la aplicacin web.............................71
13. RESPONSABLES Y PARTICIPANTES..............................................................76
14. CRONOGRAMA.................................................................................................77
15. PRESUPUESTO...................................................................................................78
16. CONCLUSIONES................................................................................................79
17. RECOMENDACIONES......................................................................................80
18. BIBLIOGRAFA..................................................................................................81
19. AEXOS.................................................................................................................82
6
PROYECTO INTEGRADOR
4. INDICE DE FIGURAS
Figura 1: Fases del Modelo Lineal Secuencial................................................................17

Figura 2: Etapas para la elaboracin del Modelo de Prototipo.......................................21
Figura 3: Sistema basado en Prototipo............................................................................22
Figura 4: Modelo Espiral.................................................................................................24
Figura 5: Modelo de Desarrollo por Etapas....................................................................27
Figura 6: Modelo Incremental.........................................................................................31
Figura 7: Modelo de Desarrollo Rpido de Aplicaciones...............................................36
Figura 8: Medidas Mtricas e Indicadores......................................................................38
Figura 9: Logo de Python................................................................................................41
Figura 10: Arquitectura de la Aplicacin.........................................................................43
Figura 11: Modelo Lineal Secuencial aplicado al proyecto............................................46
Figura 12: Cronograma....................................................................................................64
5. INDICE DE TABLAS
Tabla 1: Requerimientos Funcionales.............................................................................53

Tabla 2: Recursos de Herramientas.................................................................................65
Tabla 3: Recursos Humanos............................................................................................65
Tabla 4: Riesgos..............................................................................................................66
Tabla 5: Gestin de Riesgos............................................................................................67
Tabla 6: Presupuesto........................................................................................................78
7
PROYECTO INTEGRADOR
6. ANTECEDENTES
Los proyectos integradores son requisito fundamental para la aprobar cada ciclo,
para lo cual se ha realizado el anlisis Actualmente en el Instituto Tecnolgico
Sudamericano como Institucin Educativa para la aprobacin de cada uno de los ciclos
tiene asignaturas tericas y prcticas, las cuales ayudan a formar el conocimiento del
profesional en las diferentes carrearas que ofrece. Una de las herramientas usada para
evaluar las materias tericas de Programacin en Internet, Ingeniera de Software es
mediante la elaboracin y presentacin de proyectos integradores. Los proyectos
integradores se diferencian por diferentes categoras: Sencillos (un proyecto por
materia), interdisciplinarias (Un proyecto por varias materias), multidisciplinario (un
proyecto que contiene varias carreras).
Actualmente los trabajos cientficos que elaboran los estudiantes deben estar sujetos a
un conjunto de normas aceptadas y consensuadas. El Instituto Tecnolgico
Sudamericano se ha basado en los estilos APA (2015) que se originaron en 1929, para
establecer una gua que permita elaborar de forma fcil y comprensible trabajos
integradores.
8
PROYECTO INTEGRADOR
7. PROBLEMATIZACIN
Tomando en cuenta la investigacin realizada en la primera fase del proyecto,
conclu que es viable elaboracin de esta aplicacin la cual generara una informacin
eficiente de la Cooperativa de Transporte. En el mbito empresarial enfocndose en las
pequeas y medianas cooperativas de transporte las aplicaciones Informticas para los
procesos de prestacin de informacin han ido evolucionando en base a los avances
tecnolgicos presentados en los ltimos aos, facilitando y prestando una informacin
mucho ms eficiente a todas las personas.
Pero es importante mencionar que este proceso evolutivo ha estado marcado por la
creciente demanda de las personas, lo cual nos ha obligado de una a otra manera la
adaptacin de aplicaciones informticas en nuestro vivir.
Esta aplicacin est enfocado en mejorar la informacin de servicios que presta la
Cooperativa de Trasporte Santa de la Ciudad de Loja Ubicada con su oficina en el
Terminal Terrestre Reina del Cisne de la Ciudad de Loja. Tomando
9
PROYECTO INTEGRADOR
Esto proyecto resulta beneficioso, pudiendo realizar una investigacin y anlisis para
dar solucin a los problemas encontrados en la Cooperativa de Trasporte. Todo el
trabajo realizado a seguido uno a uno los procesos tericos necesarios que se requieren
para poder as aplicarlo en un campo real recopilando toda clase de informacin que me
permitiera intervenir de una manera clara y precisa.
8. JUSTIFICACIN
El presente proyecto es importante en el mbito acadmico ya que es un requisito
fundamental para aprobar las asignaturas de Programacin en Internet, Ingeniera de
Software y a la vez ser promovido a sexto ciclo de la carrera de Sistemas de
Automatizacin; as tambin se cumplir con lo establecido en el Reglamento Interno
del Instituto Tecnolgico Superior Sudamericano el cual indica que para aprobar las
asignaturas prcticas es necesario elaborar un Proyecto Integrador con la finalidad de
vincular los conocimientos adquiridos en clase con la aplicacin prctica de los mismos.
En el mbito tecnolgico el presente proyecto beneficiara a la provincia de Loja
facilitndole nueva tecnologa a las empresas. Ya su vez ayudaremos a dar realce a la
zona 7 del pas.
10
PROYECTO INTEGRADOR
El desarrollo del presente proyecto ayudar a demostrar los conocimientos
adquiridos en las materias mencionadas anteriormente, y as tambin acceder y hacer
uso de diferentes lenguajes de programacin que actualmente se encuentran en auge y a
su vez utilizar metodologas ordenadas para el desarrollo de aplicaciones web.
9. OBJETIVOS
9.1. OBJETIVO GENEAL
Analizar, Disear y Desarrollar una aplicacin web de control de
Rutas, Reservacin y Venta de Tickets para los Cooperativa de
Transportes Santa.
9.2. OBJETIVOS ESPECIFICOS
Levantar los requisitos de la Cooperativa para desarrollar un
Sistema de acuerdo a sus necesidades.

Automatizar la reservacin de los asientos por parte de los
usuarios desde la WEB, para el personal a cargo de las oficinas de
la Cooperativa, manteniendo la informacin real y actualizada de
todos los procesos que realiza la Cooperativa.

Elaborar el manual de usuario para la correcta utilizacin del
11
PROYECTO INTEGRADOR
sistema.
10. MARCO TERICO
10.1. INGENIERIA DEL SOFTWARE
10.1.1. Definicin Ingeniera del Software.
La Ingeniera del Software es una disciplina o rea de la Informtica que ofrece
mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven
problemas de todo tipo. Existen varias definiciones sobre esta ciencia de la
computacin que permiten describir este proceso.
10.1.2. Estado del arte de la Ingeniera del Software
La Ingeniera del Software es una disciplina o rea de la Informtica o Ciencias
de la Computacin, que ofrece mtodos y tcnicas para desarrollar y mantener
software de calidad que resuelven problemas de todo tipo. Hoy da es cada vez ms
frecuente la consideracin de la Ingeniera del Software como una nueva rea de la
ingeniera, y el ingeniero del software comienza a ser una profesin implantada en
el mundo laboral internacional, con derechos, deberes y responsabilidades que
12
PROYECTO INTEGRADOR
cumplir, junto a una, ya, reconocida consideracin social en el mundo empresarial
y, por suerte, para esas personas con brillante futuro.
La Ingeniera del Software trata con reas muy diversas de la Informtica y de
las ciencias de la computacin, tales como construccin de compiladores, sistemas
operativos o desarrollos de Intranet/Internet, abordando todas las fases del ciclo de
vida del desarrollo de cualquier tipo de sistemas de informacin y aplicables a una
infinidad de reas tales como: negocios, investigacin cientfica, medicina,
produccin, logstica, banca, control de trfico, meteorologa, el mundo del
derecho, la red de redes Internet, redes Intranet y Extranet, etc.
10.1.3. Trmino Ingeniera del Software
Es el conjunto de conocimientos y tcnicas cuya aplicacin permite la
utilizacin racional de los materiales y de los recursos naturales, mediante
invenciones, construcciones u otras realizaciones provechosas para el hombre.
Evidentemente, si la Ingeniera del Software es una nueva ingeniera, parece
lgico que rena las propiedades citadas en las definiciones anteriores. Sin
embargo, ni el DRAE ni la Real Academia Espaola de Ciencias han incluido
todava el trmino es sus ltimas ediciones; en consecuencia vamos a recurrir para
su definicin ms precisa a algunos de los autores ms acreditados que comenzaron
en su momento a utilizar el trmino o bien en las definiciones dadas por organismos
internacionales profesionales de prestigio tales como IEEE o ACM.
10.1.4. El producto y el proceso de la Ingeniera del Software
13
PROYECTO INTEGRADOR
10.1.4.1. El producto
El software de computadora se ha convertido en el alma mter. Es la mquina
que conduce a la toma de decisiones comerciales. Sirve para la investigacin
cientfica moderna y de resolucin de problemas de ingeniera. Es el factor clave
que diferencia los productos y servicios modernos. Est inmerso en sistemas de
todo tipo: de transportes, mdicos, de telecomunicaciones, militares, procesos
industriales, entretenimientos, productos de oficina, la lista es casi interminable. El
software es casi ineludible en un mundo moderno. A medida que nos adentremos en
el siglo XXI, ser el que nos conduzca a nuevos avances en todo, desde la
educacin elemental a la ingeniera gentica.
El software de computadora es el producto que disean y construyen los
ingenieros del software. Esto abarca programas que se ejecutan dentro de una
computadora de cualquier tamao y arquitectura, documentos que comprenden
formularios virtuales e impresos y datos que combinan nmeros y texto y tambin
incluyen representaciones de informacin de audio, vdeo e imgenes.
Los ingenieros de software lo construyen, y virtualmente cualquier persona en
el mundo industrializado lo utiliza, bien directa o indirectamente. Es importante
porque afecta muy de cerca cualquier aspecto de la vida y est muy extendido en el
comercio y en las actividades cotidianas.
Los pasos son construir software de computadora como construimos cualquier
otro producto satisfactorio, aplicando un proceso que conduce a un resultado de alta
14
PROYECTO INTEGRADOR
calidad, que satisface las necesidades de las personas que usarn el producto. Debes
aplicar un enfoque de ingeniera de software.
Desde el punto de vista de un ingeniero de software, el producto obtenido son
los programas, documentos y los datos que configuran el software de computadora.
Pero desde el punto de vista de los usuarios el producto obtenido es la informacin
resultante que de algn modo mejora el mundo de los usuarios.
10.1.4.2. El proceso
Como el software, al igual que el capital, es el conocimiento incorporado, y
puesto que el conocimiento est inicialmente disperso, el desarrollo del software
implcito, latente e incompleto en gran medida, es un proceso social de aprendizaje.
El proceso es un dilogo en el que se rene el conocimiento y se incluye en el
software. El proceso proporciona una interaccin entre los usuarios y los
diseadores, entre los usuarios y las herramientas de desarrollo, y entre los
diseadores y las herramientas de desarrollo [tecnologa]. Es un proceso interactivo
donde la herramienta de desarrollo se usa como medio de comunicacin, con cada
iteracin del dilogo se obtiene mayor conocimiento de las personas involucradas.
Cuando se trabaja para construir un producto o un sistema, es importante seguir
una serie de pasos predecibles, un mapa de carreteras que le ayude a obtener el
resultado oportuno de calidad. El mapa de carreteras a seguir es llamado proceso
del software.
15
PROYECTO INTEGRADOR
Lo construyen los ingenieros del software y sus gestores adaptan el proceso a
sus necesidades y entonces lo siguen. Adems, las personas que han solicitado el
software tienen un papel a desempear en el proceso del software. Es importante
porque proporciona estabilidad, control y organizacin a una actividad que puede,
si no se controla, volverse catica.
Los pasos son a un nivel detallado, el proceso que adoptemos depende del
software que estamos construyendo. Un proceso puede ser apropiado para crear
software de un sistema de aviacin, mientras que un proceso diferente por completo
puede ser adecuado para la creacin de un sitio web.
Desde el punto de vista de un ingeniero de software, los productos obtenidos
son programas, documentos y datos que se producen como consecuencia de las
actividades ingenieriles definidas por el proceso.
Hay una cantidad de mecanismos de evaluacin del proceso de software que
permiten a las organizaciones determinar la madurez de su proceso. Sin embargo, la
calidad, oportunidad y viabilidad a largo plazo del producto que se est
construyendo, son los mejores indicadores de la eficiencia del proceso que estamos
utilizando.
10.1.5. Modelos de Desarrollo de Software
16
PROYECTO INTEGRADOR
Existen varios modelos, paradigmas y filosofas de desarrollo, en los cuales se
apoya la ingeniera de software para la construccin del software, entre ellos se
puede citar:
10.1.5.1. Modelo en Cascada
Tambin llamado Lineal secuencial, es el enfoque metodolgico que ordena
rigurosamente las etapas del proceso para el desarrollo de software, de tal forma
que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.
Fases del Modelo
Figura 1: Fases del Modelo Lineal Secuencial
17
PROYECTO INTEGRADOR
Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificacin de requisitos), que contiene la especificacin
completa de lo que debe hacer el sistema sin entrar en detalles internos. Es
importante sealar que en esta etapa se debe consensuar todo lo que se requiere del
sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose
requerir nuevos resultados a mitad del proceso de elaboracin del software.
Diseo del Sistema
18
PROYECTO INTEGRADOR
Se descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseo del Software), que contiene la descripcin de
la estructura relacional global del sistema y la especificacin de lo que debe hacer
cada una de sus partes, as como la manera en que se combinan unas con otras. Es
conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo
detallado. El primero de ellos tiene como objetivo definir la estructura de la
solucin (una vez que la fase de anlisis ha descrito el problema) identificando
grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus
relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo
define los algoritmos empleados y la organizacin del cdigo para comenzar la
implementacin.
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento
de los requerimientos del usuario, as como tambin los anlisis necesarios para
saber que herramientas usar en la etapa de Codificacin.
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos,
as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de
programacin y su versin se crean las bibliotecas y componentes reutilizables
19
PROYECTO INTEGRADOR
dentro del mismo proyecto para hacer que la programacin sea un proceso mucho
ms rpido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de
ser entregado al usuario final.
Existen varios tipos de Pruebas:
Pruebas de unidad
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
10.1.5.2. Modelos Prototipos
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se
construyan rpidamente para comprender con facilidad y aclarar ciertos aspectos en
los que se aseguren que el desarrollador, el usuario, el cliente estn de acuerdo en lo
que se necesita as como tambin la solucin que se propone para dicha necesidad y
de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo
se encarga del desarrollo de diseos para que estos sean analizados y prescindir de
20
PROYECTO INTEGRADOR
ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el
alcance del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto
de objetivos generales para el software a desarrollarse sin delimitar detalladamente
los requisitos de entrada procesamiento y salida, es decir cuando el responsable no
est seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la
forma en que interacta el hombre y la mquina. Este modelo se encarga
principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor
manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos.
El paradigma de construccin de prototipos tiene tres pasos:
1. Escuchar al cliente. Recoleccin de requisitos. Se encuentran y definen los
objetivos globales, se identifican los requisitos conocidos y las reas donde es
obligatorio ms definicin.
2. Construir y revisar la maqueta (prototipo).
3. El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del
software.
Este modelo es til cuando:
El cliente no identifica los requisitos detallados.

El responsable del desarrollo no est seguro de la eficiencia de un algoritmo,
sistema operativo o de la interface hombre-mquina.
21
PROYECTO INTEGRADOR
Etapas para la elaboracin del Modelo de Prototipo.
Figura 2: Etapas para la elaboracin del Modelo de Prototipo.
Ciclo de Vida de un Sistema basado en Prototipo.
Una maqueta o prototipo de pantallas muestra la interfaz de la aplicacin, su cara
externa, pero dicha interfaz est fija, esttica, no procesa datos. El prototipo no
tiene desarrollada una lgica interna, slo muestra las pantallas por las que ir
pasando la futura aplicacin.
22
PROYECTO INTEGRADOR
Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que
satisface los requisitos y necesidades que se han entendido claramente. Realiza, por
tanto, un un proceso real de datos, para contrastarlo con el usuario. Se va
modificando y desarrollando sobre la marcha, segn las apreciaciones del cliente.
Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el
software est constantemente variando, pero, a la larga, genera un producto ms
seguro, en cuanto a la satisfaccin de las necesidades del cliente.
Cuando un prototipo se desarrolla con el slo propsito de precisar mejor las
necesidades del cliente y despus no se va a aprovechar ni total ni parcialmente en
la implementacin del sistema final se habla de un prototipo desechable.
Para que la construccin de prototipos sea posible se debe contar con la
participacin activa del cliente.
Figura 3: Sistema basado en Prototipo
23
PROYECTO INTEGRADOR
Ventajas del Modelo de Prototipo.
Este modelo es til cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del
software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debera tomar la interaccin humano-mquina.
10.1.5.3. Modelo Espiral
El modelo en espiral, propuesto originalmente por Boehm, es un modelo de
proceso de software evolutivo que conjuga la naturaleza iterativa de construccin
24
PROYECTO INTEGRADOR
de prototipos con los aspectos controlados y sistemticos del modelo lineal
secuencial. Proporciona el potencial para el desarrollo rpido de versiones
incrementales del software. En el modelo espiral, el software se desarrolla en una
serie de versiones incrementales. Durante las primeras iteraciones, la versin
incremental podra ser un modelo en papel o un prototipo. Durante las ltimas
iteraciones, se producen versiones cada vez ms completas del sistema diseado.
El modelo en espiral se divide en un nmero de actividades de marco de
trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres y seis
regiones de tareas.
Figura 4: Modelo Espiral
25
PROYECTO INTEGRADOR
Comunicacin con el cliente: Las tareas requeridas para establecer
comunicacin entre el desarrollador y el cliente.
Planificacin: Las tareas requeridas para definir recursos, el tiempo y otra
informacin relacionadas con el proyecto.
Anlisis de riesgos: Las tareas requeridas para evaluar riesgos tcnicos y de
gestin.
Ingeniera: Las tareas requeridas para construir una o ms representaciones de
la aplicacin.
26
PROYECTO INTEGRADOR
Construccin y accin: Las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario (por ejemplo: documentacin y prctica).
Evaluacin del cliente: Las tareas requeridas para obtener la reaccin del
cliente segn la evaluacin de las representaciones del software creadas durante
la etapa de ingeniera e implementada durante la etapa de instalacin.
Cada una de las regiones est compuesta por un conjunto de tareas del trabajo,
llamado conjunto de tareas, que se adaptan a las caractersticas del proyecto que va
a emprenderse. Para proyectos pequeos, el nmero de tareas de trabajo y su
formalidad es bajo. Para proyectos mayores y ms crticos cada regin de tareas
contiene tareas de trabajo que se definen para lograr un nivel ms alto de
formalidad. En todos los casos, se aplican las actividades de proteccin (por
ejemplo: gestin de configuracin del software y garanta de calidad del software).
Cuando empieza este proceso evolutivo, el equipo de ingeniera del software
gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por
el centro. El primer circuito de la espiral puede producir el desarrollo de una
especificacin de productos; los pasos siguientes en la espiral se podran utilizar
para desarrollar un prototipo y progresivamente versiones ms sofisticadas del
software. Cada paso por la regin de planificacin produce ajustes en el plan del
proyecto.
27
PROYECTO INTEGRADOR
El coste y la planificacin se ajustan con la realimentacin ante la evaluacin
del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de
iteraciones requeridas para completar el software.
El modelo en espiral es un enfoque realista del desarrollo de sistemas y de
software a gran escala. Como el software evoluciona, a medida que progresa el
proceso el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en
cada uno de los niveles evolutivos.
El modelo en espiral demanda una consideracin directa de los riesgos tcnicos
en todas las etapas del proyecto, y, si se aplica adecuadamente, debe reducir los
riesgos antes de que se conviertan en problemticos. Pero al igual que otros
paradigmas, el modelo en espiral no es la panacea. Puede resultar difcil convencer
a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque
evolutivo es controlable.
Requiere una considerable habilidad para la evaluacin del riesgo, y cuenta con
esta habilidad para el xito. Si un riesgo importante no es descubierto y gestionado,
indudablemente surgirn problemas. Finalmente, el modelo no se ha utilizado tanto
como los paradigmas lineales secuenciales o de construccin de prototipos. Todava
28
PROYECTO INTEGRADOR
tendrn que pasar muchos aos antes de que se determine con absoluta certeza la
eficacia de este nuevo e importante paradigma.
10.1.5.4. Modelo de Desarrollo por Etapas
El modelo de desarrollo de software por etapas es similar al Modelo de
prototipos ya que se muestra al cliente el software en diferentes estados sucesivos
de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle
al inicio del proyecto y por tanto se van desarrollando simultneamente con las
diferentes versiones del cdigo.
Figura 5: Modelo de Desarrollo por Etapas
Pueden distinguirse las siguientes fases que se van repitiendo en cada etapa del diseo.
29
PROYECTO INTEGRADOR
Especificacin conceptual
Anlisis de requisitos
Diseo inicial
Diseo detallado, codificacin, depuracin y liberacin.
Este modelo estipula que el software ser desarrollado en sucesivas etapas:
1. Plan operativo: Etapa donde se define el problema a resolver, las metas del
proyecto, las metas de calidad y se identifica cualquier restriccin aplicable al
proyecto.
2. Especificacin de requisitos Permite entregar una visin de alto nivel sobre
el proyecto, poniendo nfasis en la descripcin del problema desde el punto de
vista de los clientes y desarrolladores. Tambin se considera la posibilidad de
una planificacin de los recursos sobre una escala de tiempos.
3. Especificacin funcional Especifica la informacin sobre la cual el software a
desarrollar trabajar.
4. Diseo Permite describir como el sistema va a satisfacer los requisitos. Esta
etapa a menudo tiene diferentes niveles de detalle. Los niveles ms altos de
detalle generalmente describen los componentes o mdulos que formarn el
software a ser producido. Los niveles ms bajos, describen, con mucho
detalle, cada mdulo que contendr el sistema.
5. Implementacin Aqu es donde el software a ser desarrollado se codifica.
Dependiendo del tamao del proyecto, la programacin puede ser distribuida
entre distintos programadores o grupos de programadores. Cada uno se
concentrar en la construccin y prueba de una parte del software, a menudo
30
PROYECTO INTEGRADOR
un subsistema. Las pruebas, en general, tiene por objetivo asegurar que todas
las funciones estn correctamente implementadas dentro del sistema.
6. Integracin Es la fase donde todos los subsistemas codificados
independientemente se juntan. Cada seccin es enlazada con otra y, entonces,
probada. Este proceso se repite hasta que se han agregado todos los mdulos y
el sistema se prueba como un todo.
7. Validacin y verificacin Una vez que el sistema ha sido integrado, comienza
esta etapa. Es donde es probado para verificar que el sistema es consistente
con la definicin de requisitos y la especificacin funcional. Por otro lado, la
verificacin consiste en una serie de actividades que aseguran que el software
implementa correctamente una funcin especfica. Al finalizar esta etapa, el
sistema ya puede ser instalado en ambiente de explotacin.
8. Mantenimiento El mantenimiento ocurre cuando existe algn problema
dentro de un sistema existente, e involucrara la correccin de errores que no
fueron descubiertos en las fases de prueba, mejoras en la implementacin de
las unidades del sistema y cambios para que responda a los nuevos requisitos.
La mantencin se puede clasificar en: correctiva, adaptativa, perfectiva y
preventiva.
10.1.5.5. Modelo de Desarrollo Iterativo y Creciente o Iterativo e Incremental
El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el
enfoque incremental de desarrollo como una forma de reducir la repeticin del
31
PROYECTO INTEGRADOR
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo
se conoce tambin bajo las siguientes denominaciones:
Mtodo de las comparaciones limitadas sucesivas.

Ciencia de salir del paso.
Mtodo de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con
la filosofa interactiva de Construccin de Prototipos. Como se muestra en la
Figura 6, el modelo incremental aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un
incremento del software. El primer incremento generalmente es un producto
esencial denominado ncleo.
Figura 6: Modelo Incremental
Sin embargo, para la produccin del Software, se usa el principio de trabajo en
32
PROYECTO INTEGRADOR
cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha
elementos al final de cada incremento a fin de que el software se adapte mejor a sus
necesidades reales. El proceso se repite hasta que se elabora el producto completo. De
esta forma el tiempo de entrega se reduce considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada
incremento la entrega de un producto completamente operacional. Este modelo es
particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los
primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se aadir personal, de ser necesario. Por otro lado, los incrementos se
pueden planear para gestionar riesgos tcnicos.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al
final terminar siendo la solucin completa requerida por el cliente, pero stas partes
no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este
necesitando con ms urgencia, de los puntos ms importantes del proyecto, los
requerimientos ms bsicos, difciles y con mayor grado de riesgo, ya que estos se
deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada
versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que
podr ser entregada al cliente para que ste pueda trabajar en ella y el programador
33
PROYECTO INTEGRADOR
pueda considerar las recomendaciones que el cliente efecte para hacer mejoras en el
producto. Estas nuevas mejoras debern esperar a ser integradas en la siguiente
versin junto con los dems requerimientos que no fueron tomados en cuenta en la
versin anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa
del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su
propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus
interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo,
sino nicamente correccin de errores. Dado que la arquitectura completa se
desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al
comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las
funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de
requisitos funcionales y ser el cliente quien se encarga de priorizar que
funcionalidades son ms importantes. Con las funcionalidades priorizadas, se puede
confeccionar un plan de incrementos, donde en cada incremento se indica un
subconjunto de funcionalidades que el sistema entregar. La asignacin de
funcionalidades a los incrementos depende de la prioridad dada a los requisitos.
Finalizado el plan de incrementos, se puede comenzar con el primer incremento.
Caractersticas:
34
PROYECTO INTEGRADOR
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
El usuario se involucra ms.
Difcil de evaluar el costo total.
Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a
operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.
Ventajas:
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que
se implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento.

35
PROYECTO INTEGRADOR
Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.
10.1.5.6. Modelo de Desarrollo Rpido de Aplicaciones
El RAD es un proceso de desarrollo de software, desarrollado inicialmente por
James Martin en 1980. El mtodo comprende el desarrollo iterativo, la construccin
de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rpido de
aplicaciones tiende a englobar tambin la usabilidad, utilidad y la rapidez de
ejecucin.
El Desarrollo Rpido de Aplicaciones (DRA) (Rapid Application Development
RAD) es un modelo de proceso del desarrollo del software lineal secuencial que
enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptacin a Alta
velocidad en el que se logra el desarrollo rpido utilizando un enfoque de
construccin basado en componentes. Si se comprenden bien los requisitos y se limita
el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un
sistema completamente funcional dentro de periodos cortos de tiempo. Cuando se
utiliza principalmente para aplicaciones de sistemas de informacin, el enfoque DRA
comprende las siguientes fases:
Modelado de gestin: el flujo de informacin entre las funciones de gestin se
modela de forma que responda a las siguientes preguntas: Qu informacin
conduce el proceso de gestin? Qu informacin se genera? Quin la genera?
A dnde va la informacin? Quin la proceso?.
36
PROYECTO INTEGRADOR
Modelado de datos: el flujo de informacin definido como parte de la fase de
modelado de gestin se refina como un conjunto de objetos de datos necesarios
para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
Modelado de proceso: los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de informacin necesario para
implementar una funcin de gestin. Las descripciones del proceso se crean para
aadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicacin
entre los objetos.
Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de cuarta
generacin. En lugar de crear software con lenguajes de programacin de tercera
generacin, el proceso DRA trabaja para volver a utilizar componentes de
programas ya existentes (cuando es posible) o a crear componentes reutilizables
(cuando sea necesario). En todos los casos se utilizan herramientas automticas
para facilitar la construccin del software.
Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo
de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
Figura 7: Modelo de Desarrollo Rpido de Aplicaciones
37
PROYECTO INTEGRADOR
Obviamente la limitacin de tiempo impuesto en un proyecto DRA demanda
mbito en escalas. Si una aplicacin de gestin puede modularse se forma que
permita completarse cada una de las funciones principales en menos de tres meses
(utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de
las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un
solo conjunto.
Algunos inconvenientes:
Para proyectos grandes, aunque por escalas, el DRA requiere recursos humanos
suficientes como para crear el numero correcto de equipos DRA.

DRA requiere clientes y desarrolladores comprometidos en las rpidas
actividades necesarias para completar un sistema en un marco de tiempo
abreviado. Si no hay compromiso, por ninguna de las partes constituyentes, los
proyectos DRA fracasaran.
38
PROYECTO INTEGRADOR
No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se
puede modelizar adecuadamente. La construccin de los componentes necesarios para
DRA ser problemtico. Si est en juego el alto rendimiento, y se va a conseguir el
rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA
puede que no funcione. DRA no es adecuado cuando los riesgos tcnicos son altos.
Esto ocurre cuando una nueva aplicacin hace uso de tecnologas nuevas, o cuando el
nuevo software requiere un alto grado de interoperabilidad con programas de
computadora ya existentes.
DRA enfatiza el desarrollo de componentes de programas reutilizables. La
reutilizacin es la piedra angular de las tecnologas de objetos, y se encuentra en el
modelo de proceso de ensamblaje.
Ventajas de RAD
1. Comprar puede ahorrar dinero en comparacin con construir.
2. Los entregables pueden ser fcilmente trasladados a otra plataforma.
3. El desarrollo se realiza a un nivel de abstraccin mayor.
4. Visibilidad temprana.
5. Mayor flexibilidad.
6. Menor codificacin manual.
7. Mayor involucramiento de los usuarios.
39
PROYECTO INTEGRADOR
8. Posiblemente menos fallas.
9. Posiblemente menor costo.
10. Ciclos de desarrollo ms pequeos.
11. Interfaz grfica estndar.
10.1.6. Medidas Mtricas e Indicadores
Figura 8: Medidas Mtricas e Indicadores
Las mtricas del software se refieren a un amplio elenco de mediciones para el
software de computadora. La medicin se puede aplicar al proceso del software con el
intento de mejorarlo sobre una base continua. Se puede utilizar en el proyecto del
software para ayudar en la estimacin, el control de calidad, la evaluacin de
productividad y el control de proyectos. Finalmente, el ingeniero de software puede
utilizar la medicin para ayudar a evaluar la calidad de los resultados de trabajos
40
PROYECTO INTEGRADOR
tcnicos y para ayudar en la toma de decisiones tctica a medida que el proyecto
evoluciona.
En el contexto de gestin de proyectos de software, existe una gran preocupacin
por las mtricas de productividad y de calidad -medidas de salida (finalizacin) del
desarrollo del software, basadas en el esfuerzo y tiempo empleados, y medidas de la
utilidad del producto obtenido.
Medimos para mejorar cuando recogemos la informacin cuantitativa que nos
ayuda a identificar obstculos, problemas de raz, ineficiencias y otras oportunidades
para mejorar la calidad del producto y el rendimiento del proceso.
Mediciones del Software
Mtricas Directas: Aquellas que no depende de ninguna mtrica de otro
atributo.
Ejemplo: costo, esfuerzo, lneas de cdigo, velocidad de ejecucin, nmero de
defectos
Mtricas Indirectas: Son aquellas que se obtienen a partir de mtricas
directas.
Ejemplo: productividad, calidad, complejidad, eficiencia, fiabilidad, etc.
10.2. PROGRAMACION EN INTERNET
41
PROYECTO INTEGRADOR
10.2.1. Django
Django es un framework para aplicaciones web gratuito y open source, escrito en
Python. Es un WEB framework - un conjunto de componentes que te ayudan a
desarrollar sitios web ms fcil y rpidamente.
Vers, cuando ests construyendo un sitio web, frecuentemente necesitas un
conjunto de componentes similares: una manera de manejar la autenticacin de
usuarios (registrarse, iniciar sesin, cerrar sesin), un panel de administracin para tu
sitio web, formularios, una forma de subir archivos, etc.
Por suerte para ti, hace tiempo varias personas notaron que los desarrolladores
web enfrentan problemas similares cuando construyen un sitio nuevo, por eso juntaron
cabezas y crearon frameworks (Django es uno de ellos) que te ofrecen componentes
listos para usarse.
Los frameworks existen para ahorrarte tener que reinventar la rueda y ayudarte a
aliviar la carga cuando construyes un sitio.
Por qu necesitas un framework?
Para entender para que es Django, necesitamos mirar mas de cerca a los
servidores. Lo primero es que el servidor necesita saber que quieres que te sirva una
pgina web.
42
PROYECTO INTEGRADOR
Imagina un buzn (puerto) el cual es monitoreado por cartas entrantes (peticiones).
Esto es realizado por un servidor web. El servidor web lee la carta, y enva una
respuesta con una pgina web. Pero cuando quieres enviar algo, tienes que tener algn
contenido. Y Django es algo que te ayuda a crear el contenido.
10.2.2. Python
Su nombre se debe a que su creador era fantico del grupo britnico de humoristas
Monty Python, muchas veces conocidos como LOS PYTHON. Es considerado
competencia directa con el Lenguaje de programacin PERL.
Figura 9: Logo de Python
Entre sus caractersticas principales tenemos:
43
PROYECTO INTEGRADOR
Lo primordial y bsico para poder desarrollar un programa, por ms pequeo
que este sea, es la limpieza y el orden del cdigo, lo que conlleva a una
mejor legibilidad del cdigo.
Es multiparadigma, esto implica que puede adoptar distintos paradigmas de
programacin (POO, Programacin imperativa y programacin funcional),
pero si algn programador usa algn otro paradigma puede hacer uso de l
mediante el uso de extensiones.
Tipado Dinmico, una misma variable puede tomar distintos valores en
distintos momentos.
Conteo de referencias.
Enlace dinmico de mtodos, esto implica el enlazamiento de un mtodo y
un nombre de variable durante la ejecucin de un programa.
Facilidad de extensin.
10.2.3. Arquitectura de la aplicacin
Una aplicacin web es proporcionada por un servidor web y utilizada por usuarios
que se conectan desde cualquier punto va clientes web (browsers o navegadores). La
arquitectura de un sitio web tiene tres componentes principales:
44
PROYECTO INTEGRADOR
Un servidor Web
Una conexin de red
Uno o ms clientes
El servidor Web distribuye pginas de informacin formateada a los clientes que
las solicitan. Los requerimientos son hechos a travs de una conexin de red, y para
ello se usa el protocolo HTTP. Una vez que se solicita esta peticin mediante el
protocolo HTTP y la recibe el servidor Web, ste localiza la pgina Web en su sistema
de archivos y la enva de vuelta al navegador que la solicit.
Figura 10: Arquitectura de la Aplicacin
Las aplicaciones Web estn basadas en el modelo Cliente/Servidor que gestionan
servidores web, y que utilizan como interfaz pginas web.
Una vez que se entrega una pgina, la conexin entre el browser y el servidor Web
se rompe, es decir que la lgica del negocio en el servidor solamente se activa por la
ejecucin de los scripts de las pginas solicitadas por el browser (en el servidor, no en
45
PROYECTO INTEGRADOR
el cliente). Cuando el browser ejecuta un script en el cliente, ste no tiene acceso
directo a los recursos del servidor. Hay otros componentes que no son scripts, como
los applets (una aplicacin especial que se ejecuta dentro de un navegador) o los
componentes ActiveX. Los scripts del cliente son por lo general cdigo JavaScript o
VBSscript, mezclados con cdigo HTML.
La coleccin de pginas son en una buena parte dinmicas (ASP, PHP, etc.), y
estn agrupadas lgicamente para dar un servicio al usuario. El acceso a las pginas
est agrupado tambin en el tiempo (sesin). Los componentes de una aplicacin Web
son:
1. Lgica de negocio.
Parte ms importante de la aplicacin.

Define los procesos que involucran a la aplicacin.
Conjunto de operaciones requeridas para proveer el servicio.
2. Administracin de los datos.
Manipulacin de BD y archivos.
3. Interfaz
Los usuarios acceden a travs de navegadores, mviles, PDAs, etc.

Funcionalidad accesible a travs del navegador.
Limitada y dirigida por la aplicacin.
46
PROYECTO INTEGRADOR
10.2.4. Base de Datos
10.2.4.1. QU SON LAS BASES DE DATOS?
Es el conjunto de informaciones almacenadas en un soporte legible por ordenador
y organizadas internamente por registros (formado por todos los campos referidos a
una entidad u objeto almacenado) y campos (cada uno de los elementos que
componen un registro). Permite recuperar cualquier clase de informacin: referencias,
documentos textuales, imgenes, datos estadsticos. Una base de datos proporciona a
los usuarios el acceso a datos, que pueden visualizar, ingresar o actualizar, en
concordancia con los derechos de acceso que se les hayan otorgado. Se convierte ms
til a medida que la cantidad de datos almacenados crece. 1
La principal ventaja de utilizar bases de datos es que mltiples usuarios pueden
acceder a ellas al mismo tiempo. Una base de datos o banco de datos es un conjunto
de datos pertenecientes a un mismo contexto y almacenados sistemticamente para su
posterior uso.
10.2.4.2. QUE ES LA NORMALIZACIN?
La normalizacin es el proceso de organizar los datos de una base de datos. Se
incluye la creacin de tablas y el establecimiento de relaciones entre ellas segn reglas
1 Molina, 2014
47
PROYECTO INTEGRADOR
diseadas tanto para proteger los datos como para hacer que la base de datos sea ms
flexible al eliminar la redundancia y las dependencias incoherentes. 2
11. METODOLOGA
11.1. Modelo de Ingeniera de Software
Modelo en Cascada tambin llamado Lineal secuencial, es el enfoque
metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo
de software, de tal forma que el inicio de cada etapa debe esperar a la
finalizacin de la etapa anterior.
11.1.1. Fases del Modelo
Figura 11: Modelo Lineal Secuencial aplicado al proyecto
2 E283878
48
PROYECTO INTEGRADOR
o Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificacin de requisitos), que contiene la especificacin completa
de lo que debe hacer el sistema sin entrar en detalles internos. Es importante sealar
que en esta etapa se debe consensuar todo lo que se requiere del sistema y ser aquello
lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a
mitad del proceso de elaboracin del software.
o Diseo del Sistema
Se descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el
49
PROYECTO INTEGRADOR
SDD (Documento de Diseo del Software), que contiene la descripcin de la
estructura relacional global del sistema y la especificacin de lo que debe hacer cada
una de sus partes, as como la manera en que se combinan unas con otras. Es
conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado.
El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez
que la fase de anlisis ha descrito el problema) identificando grandes mdulos
(conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define
la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la
organizacin del cdigo para comenzar la implementacin.
o Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de
los requerimientos del usuario, as como tambin los anlisis necesarios para saber
que herramientas usar en la etapa de Codificacin.
o Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos,
as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de
programacin y su versin se crean las bibliotecas y componentes reutilizables dentro
del mismo proyecto para hacer que la programacin sea un proceso mucho ms
rpido.
o Pruebas
50
PROYECTO INTEGRADOR
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de ser
entregado al usuario final.
Existen varios tipos de Pruebas:
Pruebas de unidad
Pruebas de integracin
Pruebas de sistema
Pruebas de aceptacin
12. PROPUESTA DE ACCIN O DESARROLLO
12.1. INGENIERA DE SOFTWARE
12.1.1. Descripcin de la Empresa
HISTORIA
Con singular denominacin, naci la Cooperativa de transportes ambatea el 21
de junio de 1945, como Servicio Auto motorizado Nacional de Transportes
Ambateos (SANTA), constituyndose en la primera institucin de transporte
interprovincial de pasajeros en el centro del pas.
Creada por un grupo de transportistas visionarios, con la idea de que mediante el
transporte se poda integrar al Ecuador, comenzaron a unir las provincias de la

51
PROYECTO INTEGRADOR
Sierra y de la Costa Ecuatoriana.
As empezaron recorriendo caminos de segundo y tercer orden, es as, que en la
dcada de los aos 60 y 70, comienza a cubrir rutas desde Ambato hacia las
provincias del Guayas, Esmeraldas, Manab, Guayaquil, El Oro, Loja, Bolvar,
Azuay y sus puntos intermedios. Brindando un servicio de transporte eficiente y
eficaz.
ACTUALIDAD
Hoy cuenta con un parque automotor de primera lnea, dando servicio a
importantes ciudades del pas, a travs de sus 23 oficinas a nivel nacional en las
ciudades de: Quito, Latacunga, Riobamba, Guayaquil, Azogues, Cuenca, Saraguro,
Loja, Bucay, La Troncal, Machala, Santa Rosa de Machala, Huaquillas, Catamayo,
Gonzanam, Nambacola, Cariamanga, Chaguarpamba y la matriz en Ambato.
Estamos conscientes de que si bien hemos obtenido logros y resultados
satisfactorios tambin han tenido lugar las deficiencias, insuficiencias y errores,
coment Miriam Rodrguez, presidenta de la Cooperativa.
Ante ello seal que la obra que se realice en el futuro deber tener nfasis en la
consolidacin en proseguir los aciertos y alcanzar los objetivos ms trascendentes,
manteniendo los principios bsicos de las organizaciones de economa popular y
solidaria.
52
PROYECTO INTEGRADOR
RUTAS
Salida desde la Terminal Terrestre Salida desde la Terminal Terrestre

Ambato Ambato
Hora de salida: 05:35am Hora de salida: 11:00am
Destino: Quito (Terminal Quitumbe) Destino: Quito (Terminal Quitumbe)
Salida desde la Terminal Terrestre
Salida desde la Terminal Terrestre Ambato
Ambato Hora de salida: 13:00pm
Hora de salida: 06:00am Destino: Guayaquil (Servicio Directo)
Destino: Quito Centro La unidad sale
del terminal terrestre Ambato Salida desde la Terminal Terrestre
Ambato
Salida desde la Terminal Terrestre Hora de salida: 13:10pm
Ambato Destino: Cuenca
Hora de salida: 06:00am
Destino: Cuenca Terminal Salida desde la Terminal Terrestre
Ambato
Ambato Destino: Machala-Huaquillas
Destino: Quito Centro (Terminal de Salida desde la Terminal Terrestre
SANTA) Ambato
Hora de salida: 13:30pm
Salida desde la Terminal Terrestre Destino: Quito Centro (Terminal de
Ambato SANTA)
Destino: Cuenca Salida desde la Terminal Terrestre
Ambato
Ambato Destino: Guayaquil (Servicio Directo)
Destino: Cuenca Salida desde la Terminal Terrestre
Ambato
Ambato Destino: Quito (Terminal Quitumbe)
Destino: Quito (Terminal Quitumbe) Salida desde la Terminal Terrestre
Ambato
Ambato Destino: Quito (Terminal Quitumbe)
Destino: Guayaquil (Servicio Directo) Salida desde la Terminal Terrestre
Ambato
53
PROYECTO INTEGRADOR
Destino: Loja (via cuenca)

Hora de salida: 16:30pm Destino: Machala - Huaquillas
Destino: Quito (Terminal Quitumbe)
Ambato Ambato
Hora de salida: 17:00pm Hora de salida: 21:45pm
Destino: Quito (Terminal Quitumbe) Destino: Loja (via Machala-La Toma)

Ambato Ambato
Destino: Cuenca Destino: Cuenca

Ambato Ambato
Destino: Machala - La Toma - Destino: Loja (via Cuenca)
Cariamanga
Hora de salida: 18:30pm Destino: Loja (via Cuenca)
Destino: Loja (via Cuenca)
Hora de salida: 19:30pm Destino: Machala - Huaquillas
Destino: Latacunga (Terminal de
SANTA) Salida desde la Terminal Terrestre
Ambato
Destino: Machala - Huaquillas Salida desde la Terminal Terrestre
Ambato
Destino: Cariamanga (via Cuenca-Loja) Salida desde la Terminal Terrestre
Ambato
Destino: Loja (via Cuenca)
54
PROYECTO INTEGRADOR
Salida desde la Terminal Terrestre Hora de salida: 01:00am

12.1.2. mbito
a. Funciones
Tabla 1: Requerimientos Funcionales
R# Funcin Categora
R1 Inicio de sesion
R.1.1 La aplicacin debe permitir ingresar al usuario y contrasea al Evidente
sistema.
R.1.2 El sistema deber permitir validar campos, como nombre de Evidente
usuario y contrasea.
R.1.3 El sistema deber permitir recuperar contrasea. Evidente
R2 Administrar datos de buses
R.2.1 El sistema deber permitir crear claves para buses, con un Evidente
idBuses secuencial que se incrementar automticamente al
momento de crear un bus.
R.2.2 El sistema deber permitir Registrar datos nicos del bus en el Evidente
sistema.
R.2.3 El sistema deber permitir Guardar bus en el sistema. Evidente
R.2.4 El sistema deber permitir Consultar todos los buses que estn Evidente
registrados en el sistema.
R.2.5 El sistema deber permitir buscar un bus y activar sus campos Evidente
para modificarlos en caso de que se requiera realizar algn
cambio en el registro.
R.2.6 El sistema deber permitir dar de baja registro de bus, en caso Evidente
de que se desee inactivarlo.
R.2.7 El sistema deber permitir Actualizar stock de buses en el Oculto
sistema.
R.2.8 El sistema deber permitir imprimir comprobante de bus. Superflua
R3 Administracin de usuario.
R.3.1 El sistema deber permitir crear claves para usuario, con un Evidente
idUsuario secuencial que se incrementar automticamente al
momento de crear un usuario.
R.3.2 El sistema deber permitir consultar todos los usuarios que Evidente
estn registrados en el sistema.
55
PROYECTO INTEGRADOR
R.3.3 El Sistema deber permitir Guardar usuarios en el sistema. Oculto

R.3.4 El sistema deber permitir consultar todos los usuarios que Evidente
R.3.5 El sistema deber permitir buscar un usuario y activar sus Evidente
campos para modificarlos en caso de que se requiera realizar
algn cambio en el registro.
R.3.6 El sistema deber permitir dar de baja registro de usuario, en Evidente
caso de que se desee inactivarlo.
R4 Administracin de clientes
R.4.1 El sistema deber permitir Crear nuevo cliente, con un Evidente
idCliente secuencial que se incrementar automticamente al
momento de crear cliente.
R.4.2 El sistema deber permitir Registrar datos personales del Evidente
Cliente en el sistema.
R.4.3 El sistema deber permitir Guardar Cliente en el sistema. Oculto
R.4.4 El sistema deber permitir Consultar todos los clientes que Evidente
R.4.5 El sistema deber permitir buscar un cliente y activar sus Evidente
campos para modificarlos en caso de que se requiera realizar
algn cambio en el registro.
R.4.6 El sistema deber permitir dar de baja registro de cliente, en Evidente
caso de que se desee inactivarlo.
R5 Administracin de reservaciones
R.5.1 El sistema deber permitir Crear nueva reservacin, con un Evidente
idReservacion secuencial que se incrementar automticamente
al momento de crear reservacin.
R.5.2 El sistema deber permitir consultar todas las reservaciones que Evidente
estn registradas en el sistema.
R.5.3 El sistema deber permitir Calcular subtotales y totales de Evidente
reservaciones.
R.5.4 El sistema deber permitir Consultar todas las reservaciones Evidente
que estn registradas en el sistema.
R.5.5 El sistema deber permitir Registrar datos de reservacin en el Oculto
sistema.
R.5.6 El sistema deber permitir Guardar registro de reservacin en el Evidente
sistema.
R.5.7 El sistema deber permitir Emitir comprobante de reservacin. Superflua
R.5.8 El sistema deber permitir Actualizar stock de reservaciones en Evidente
el sistema.
56
PROYECTO INTEGRADOR
b. Restricciones
Uso del Sitio
Este sitio web es propiedad de la Compaa en sus oficinas de la Cooperativa
Santa, y est disponible para informacin y uso personal, no para uso comercial.
Sintase en la libertad de explorar el Sitio; sin embargo, su uso y acceso al Sitio est
sujeto a Trminos y a todas las leyes que apliquen.
Contenido de Terceros
Cualquier opinin, declaracin, servicio, oferta u otra informacin o contenido
expresado o disponible en este Sitio por terceros pertenecen a sus respectivos autores
o distribuidores y no a la Compaa.
Limitacin de Responsabilidad
57
PROYECTO INTEGRADOR
Su uso y navegacin por el Sitio es a su propio riesgo. Si no est satisfecho con
alguno de los Materiales contenidos en este Sitio, o con cualquiera de sus Trminos,
su nico y exclusivo remedio es descontinuar el acceso y uso del Sitio.
Informacin del Usuario.
En el curso del uso que usted haga del Sitio Web o de los servicios puestos a su
disposicin en o a travs del Sitio Web, se le puede pedir que nos proporcione cierta
informacin personalizada (dicha informacin en lo sucesivo "Informacin del
Usuario"). Las polticas de uso y recopilacin de informacin de Time Inc. con
respecto a la privacidad de dicha Informacin del Usuario se establecen en la Poltica
de Privacidad del Sitio Web, la cual est incorporada al mismo como referencia para
todos los propsitos. Usted reconoce y acepta ser el nico responsable de la exactitud
del contenido de la Informacin del Usuario.
Informacin Privada o Delicada en Foros Pblicos.
Es importante recordar que los comentarios presentados en un foro pueden ser
registrados y almacenados en mltiples lugares, tanto en nuestro Sitio Web como en
otra parte en Internet, los cuales pueden ser accesibles durante mucho tiempo y no se
tiene control sobre quin los leer eventualmente. Es por lo tanto importante que tenga
usted cuidado y sea selectivo acerca de la informacin personal que divulgue acerca
de usted y de otros, y en especial, no debe divulgar informacin delicada, patrimonial
o confidencial en sus comentarios en nuestros foros pblicos.
58
PROYECTO INTEGRADOR
c. Interfaces
59
PROYECTO INTEGRADOR
60
PROYECTO INTEGRADOR
12.1.3. Fases de Desarrollo
61
PROYECTO INTEGRADOR
FASE: ANALISIS
a. Proceso: Recoleccin de datos

b. Recursos involucrados: Director de tesis, encargada de la unidad de
planificacin, tesistas.
c. Objetivo: recolectar datos que intervienen en el desarrollo del sistema de los
usuarios.
d. Actividades:
Reunin general con el personal de secretaria para determinar la
secuencia de trabajo
Investigacin sobre el modelo a emplear
Investigacin bibliogrfica(internet) sobre el lenguaje de programacin
Html
e. Resultados:
Obtencin de la informacin del proceso actual.
Obtencin de las dificultades que se presentan en el proceso de anlisis.
Obtencin de las restricciones establecidas
f. Entregables:
Diagrama del proceso actual del modelo que se usara.
Requerimientos funcionales y no funcionales.
Restricciones que se debe tomar en cuenta para cumplir con lo
establecido
62
PROYECTO INTEGRADOR
g. Duracin:
Recoleccin de informacin para desarrollar este proceso 2 semanas.
FASE: DISEO
a. Proceso: Diseo de base de datos

b. Recursos involucrados: Sistema de recursos humanos
c. Objetivo: Disear la base de datos
d. Actividades:
Programar bajo estndares.
Obtencin de todos los requerimientos.
Obtencin de las interfaces de la aplicacin web
Obtencin del diseo de las interfaces.
e. Resultados:
Diseo de las interfaces de la aplicacin web
Diseo de las funciones del sistema
f. Entregables:
Diseo de la base de datos
Diseo de los requerimientos del sistema
Diseo del modelo secuencial para el desarrollo de la aplicacin.
63
PROYECTO INTEGRADOR
g. Duracin:
Diseo de las interfaces de la aplicacin web 1 semanas.
Diseo y prueba del modelo secuencial 2 semanas
FASE: CODIFICACIN
a. Proceso: codificacin del proyecto

c. Objetivo: Implementacin de la aplicacin web para que interacte con las
interfaces el usuario.
d. Actividades:
Desarrollo de la aplicacin en la cooperativa SANTA
Diseo de las interfaces de la aplicacin web.
Diseo de Interfaces que interacten con el usuario
e. Resultados:
Obtencin de las etapas de la investigacin.
Obtencin para aportar instrumentos para manejar la informacin.
Obtencin de un control de la base de datos.
64
PROYECTO INTEGRADOR
f. Entregables:
rbol de directorio.
Conexin entre el servidor y la base de datos.
La aplicacin web debe presentar las interfaces.
g. Duracin:
Recoleccin de informacin para desarrollar este proceso 2 semanas.
Desarrollo de codificacin para la aplicacin web 2 semanas
FASE: PRUEBA
a. Proceso: implementacin de la aplicacin web

c. Objetivo: comprobar que aplicacin funciona y cumpla con las expectativas del
usuario
d. Actividades:
Realizar las pruebas necesarias de la aplicacin web
Obtencin de las interfaces de la aplicacin web.
e. Resultados:
Autentificacin del usuario
Diseo de la aplicacin web con sus respectivas interfaces
65
PROYECTO INTEGRADOR
f. Entregables:
Diseo de la aplicacin web
Diseo de los requerimientos del sistema
Diseo del modelo secuencial para el control de hospedaje
g. Duracin:
Diseo de las interfaces de la aplicacin web 1 semanas.
Diseo y prueba del modelo secuencial 2 semanas
12.1.4. Planificacin o Cronograma
Figura 12: Cronograma
66
PROYECTO INTEGRADOR
12.1.5. Recursos
Tabla 2: Recursos de Herramientas
RECURSOS DE HERRRAMIENTAS
Nombre. Descripcin. Informe de Fecha Tiempo de
disponibilidad. cronolgica. aplicacin de
recurso.
Django. Es un framework Tiempo Enero-Mayo. 5 meses.
de desarrollo completo.
web de cdigo
abierto.
SubLineText. Es un editor de Tiempo Enero-Mayo. 5 meses.
cdigo completo.
67
PROYECTO INTEGRADOR
multiplataforma.
Laptops. Es una Tiempo Enero-Mayo. 5 meses.
computadora completo.
porttil.
Tabla 3: Recursos Humanos
RECURSOS HUMANOS
Nombre. Descripcin. Informe de Fecha Tiempo de
disponibilidad. cronolgica. aplicacin del
recurso.
Jorge Freire. Desarrolladores Tiempo Enero-Mayo 5 meses
Richard de software. completo.
Jimenez.
Jorge Freire. Analistas de Tiempo Enero-Mayo 5 meses
Richard software. completo.
Jimenez.
Jorge Freire. Diseadores de Tiempo Enero-Mayo 5 meses
Richard software. completo.
Jimenez.
12.1.6. Identificacin de Riesgos
Tabla 4: Riesgos
PROBABILID
1. RIESGOS CATEGORIA AD IMPACTO RSGR
El cliente
Planificacin
cambiar los 80% Critica
temporal
requisitos
El SW no
Catastr
admite Soporte 70%
fica
cambios
68
PROYECTO INTEGRADOR
Los usuarios
finales insisten
Soporte 65% Critica
en nuevos
requisitos
El desarrollo de
funciones de
Software Planificacin Catastr
75%
innecesarias temporal fica
alarga la
planificacin
Un mal diseo
implica volver
Rendimiento 70% Critica
a disear e
implementar
El cliente
intenta
controlar el
proceso de
Planificacin Catastr
desarrollo, con 55%
temporal fica
lo que el
progreso es
ms lento de lo
esperado
Se aaden
requisitos Soporte 80% Critica
extra
El presupuesto
vara el plan Coste 75% Critica
del proyecto
El desarrollo de
un tipo de
componente
nuevo para la
Soporte 70% Critica
organizacin
consume ms
tiempo del
esperado
Tabla 5: Gestin de Riesgos
69
PROYECTO INTEGRADOR
RSGR
Riesgo ESTRATEGIAS DE ESTRATEGIAS ESTRATEGIAS RESPONSABLE
REDUCCION DE DE GESTION S
SUPERVISION
El cliente Tomar en cuenta Al iniciar En caso de
cambiara los todos los con el existir
requisitos. requisitos de la desarrollo de cambios o
aplicacin con el la aplicacin correctivos o
cliente para que a y el diseo cambios al
medio proyecto presentar al inicio del
no exista ningn cliente para proyecto de
cambio en los que tenga los requisitos
requisitos. claro cmo reprogramar la
va ser la planificacin
aplicacin y
escuchar
sugerencias
del mismo
para tomar
correctivos
en ese
instante
El SW no Tomar las Tomar muy Revisin de la
admite respectivas en cuenta documentaci
cambios precauciones con todos los n para poder
el cliente, y requisitos incluir todos
dejarle bien en inicialmente los requisitos
claro que una vez acordados del cliente.
terminado el con el
producto no cliente, para
podemos realizar la obtencin
cambios, en lo de un
posible realizar producto
un contrato final bien
firmado. elaborado y
con muy
buena
aceptacin.
Los Al tener un Se puede Tomar la
usuarios documento realizar planificacin
finales firmado donde se cambios a la del proyecto y
70
PROYECTO INTEGRADOR
insisten estableci que no aplicacin, aadirle los

en nuevos se pueden pero esto nuevos
requisitos realizar cambios sera con un requisitos que
al final de la valor y requiere el
aplicacin. tiempo extra cliente y poder
a la planificar el
planeacin costo y tiempo
del proyecto. que llevara.
El Tener bien claro Controlar el Realizar la
desarrollo todas las avance de la aplicacin lo
de funciones de la aplicacin mas sencilla y
funciones aplicacin para con lo funcional que
de no perder tiempo planificado requiera el
Software en funciones que ya que se cliente.
innecesari no requiere el tom todas
as alarga cliente. la funciones
la de la
planificaci aplicacin al
n. comienzo de
la misma.
Presentar avances Una vez Realizar los
Un mal del diseo de la presentado cambios y
diseo aplicacin al el diseo de sugerencias en
implica cliente para que la aplicacin la
volver a pueda dar su al cliente planificacin
disear e opinin y sus tomar del proyecto
implemen recomendaciones sugerencias para no tardar
tar . y correctivos ms de lo
a tiempo. establecido.
El cliente Al tener al cliente Llegar a un Al tener claro
intenta encima de acuerdo con las polticas de
controlar nosotros, en la el cliente en trabajo con el
el proceso elaboracin de la el que una cliente no
de aplicacin va a vez puede ocurrir
desarrollo, crear un mal presentado estas
con lo que ambiente en el los avances situaciones
el trabajo, por lo y diseo de donde
progreso tanto, nos la aplicacin tengamos
es ms conllevara al puede dar encima
lento de lo atraso de la sugerencias, nuestro en la
esperado aplicacin. luego no se elaboracin de
71
PROYECTO INTEGRADOR
aceptan la aplicacin al
cambios y cliente.
exigencias.
Debemos tener Presentar el Al estar de
en cuenta el presupuesto acuerdo con el
presupuesto con de la cliente con el
El
el que contamos aplicacin al presupuesto de
presupues
para la cliente para la aplicacin,
to vara el
elaboracin del realizar el tenemos
plan del
proyecto. plan de menos margen
proyecto
proyecto a de error en el
su plenitud. plan de
proyecto.
El Tener bien claro Controlar el Realizar la
desarrollo todos los avance de la aplicacin lo
de un tipo componentes de aplicacin ms sencilla y
de la aplicacin para con lo funcional que
componen no perder tiempo planificado requiera el
te nuevo en componentes ya que se cliente.
para la que no requiere tom todos
organizaci el cliente. los
n componente
consume s de la
ms aplicacin al
tiempo comienzo de
del la misma.
esperado
72
PROYECTO INTEGRADOR
12.2. PROGRAMACION EN INTERNET:
12.2.1. Capturas antes de la aplicacin:
12.2.2. Capturas despus de la aplicacin:
73
PROYECTO INTEGRADOR
12.2.3. rbol de archivos tipo manual de la aplicacin web.
Este equipo
Ingresamos a la unidad
C:\ donde encontraremos
nuestra aplicacin
C:\
Ingresamos a la carpeta
ProyectosPython donde
tenemos guardado nuestra
aplicacin
74
PROYECTO INTEGRADOR
C:\ProyectosPython
Ingresamos a la carpeta que

tiene el nombre de nuestra
aplicacin Cooperativa
Santa
C:\ProyectosPython\CooperativaSanta
Aqu tenemos el archivo

manage.py el cual nos
permite levantar nuestro
servidor
75
PROYECTO INTEGRADOR
C:\ProyectosPython\CooperativaSanta\Principal
Aqu encontramos archivo

los cuales son indispensables
para el funcionamiento de la
aplicacin
C:\ProyectosPython\CooperativaSanta\Principal\migrations
E la carpeta migrations se
encuentra la conexin de
Django con Python
76
PROYECTO INTEGRADOR
C:\ProyectosPython\CooperativaSanta\Principal\static
En la carpeta static
encontramos las distintas
carpetas como son: css,
imgenes, js
C:\ProyectosPython\CooperativaSanta\Principal\static\css
En la carpeta css
encontramos todos los estilos
que se implementara en la
aplicacin
77
PROYECTO INTEGRADOR
C:\ProyectosPython\CooperativaSanta\Principal\static\imagenes
En esta carpeta imgenes

tenemos todas las imgenes
que utilizaremos en la
aplicacin
C:\ProyectosPython\CooperativaSanta\Principal\static\js
En esta carpeta tenemos las

animaciones para darle a la
aplicacin
C:\ProyectosPython\CooperativaSanta\Principal\templates\Principal
78
PROYECTO INTEGRADOR
En la carpeta templates y
principal tenemos los
archivos html que es el
cdigo fuente de nuestra
aplicacin
13. RESPONSABLES Y PARTICIPANTES
Jorge Andres Freire Ochoa

Richard Colon Jimnez lvarez.
79
PROYECTO INTEGRADOR
14. CRONOGRAMA
15. PRESUPUESTO
RECURSOS HUMANOS
Cantida Nombre del Descripcin VALOR UNITARIO VALO
d Recurso R
TOTAL
3 Tutores Docentes que guiaron en --- ---
la ejecucin del Proyecto
4 Autores del Estudiantes que --- ---

proyecto desarrollan el proyecto
Integrador.
80
PROYECTO INTEGRADOR
RECURSOS TECNOLGICOS
d Recurso. R
TOTAL
4 Computador Necesario para la 10.00 10.00
porttil realizacin del proyecto
4 Necesario para realizar 15.00 15.00
Internet consultas
bibliogrficas
RECURSOS LOGSTICOS
d Recurso R
TOTAL
.... Impresiones Necesario para la 15.00 15.00
presentacin final del
proyecto
1 Necesario para el 2.00 2.50
Anillados mejoramiento esttico
del proyecto
1 Proyector Necesario para la .
defensa del proyecto
1 CD Necesario para 2.00 2.00
constancia del proyecto
en forma digital
TOTAL 44.50
Tabla 6: Presupuesto
16. CONCLUSIONES
El anlisis de requerimientos funcionales y no funcionales de un sistema es muy
importante ya que conforma la base para el desarrollo de una aplicacin.
81
PROYECTO INTEGRADOR
Se dise e implemento el sistema de servicios de la cooperativa Santa al sitio
web, en base a las necesidades indicadas en la especificacin de requerimientos.
Todos los diagramas obtenidos en el proceso de anlisis de requerimientos y de
diseo permitieron un desarrollo ptimo y claro del software.
Es indispensable hacer pruebas sobre el aplicativo ya que se conocen las
falencias y son corregidas a tiempo, evitando posibles errores al momento de
manejar informacin real.
La tcnica de respaldo de informacin en la base de datos, es la cual mantiene
una copia de la informacin ingresada en caso de prdida; as mismo los datos
estn altamente seguros y confiables.
17. RECOMENDACIONES
Difundir informacin de la cooperativa Santa a la ciudadana y dems
usuarios, con la finalidad de conseguir un mejor posicionamiento entre las

dems cooperativas de la provincia de Loja.
82
PROYECTO INTEGRADOR
Mantener actualizada la informacin publicada en el sitio web, a fin de dar a
conocer al pblico visitante las ltimas novedades de la cooperativa.
Difundir polticas de acceso y permisos de usuario al sistema, con la finalidad de
garantizar la integridad y confiabilidad de la informacin.
Realizar un estudio y anlisis antes de utilizar metodologas de software, para as
escoger la mejor y trabajar con la que mejor se adapte, y los beneficios que esta
ofrece, y con la finalidad que se requiere
18. BIBLIOGRAFA
http://informatica.ucm.es/data/cont/docs/titulaciones/46.pdf
http://uprotgs.blogspot.com/2008/02/anlisis-de-sistemas.html
http://causaencomun.org.mx/wp-content/uploads/2015/08/Unidad-1.-
Introduccion-al-analisis-orientado-a-objetos.pdf
83
PROYECTO INTEGRADOR
http://aprenderaprogramar.com/index.php?
option=com_content&view=article&id=688:ique-es-y-para-que-sirve-uml-
versiones-de-uml-lenguaje-unificado-de-modelado-tipos-de-diagramas-
uml&catid=46:lenguajes-y-entornos&Itemid=163
http://www.sparxsystems.com.ar/products/ea/index.html
http://www.logicstudio.net/spa/productos/enterprise-architect-uml
http://www.ecured.cu/Diagrama_Entidad_Relaci%C3%B3n
19. AEXOS
84
PROYECTO INTEGRADOR
85
PROYECTO INTEGRADOR
86

Santa 5.0

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Santa 5.0

Hochgeladen von

Copyright:

Verfügbare Formate

INSTITUTO TECNOLGICO

DESARROLLO E IMPLEMENTAIN DE UNA APLICACIN

Jorge Andres Freire Ochoa

DESARROLLO E IMPLEMENTAIN DE UNA APLICACIN WEB PARA LA

La Cooperativa de Transportes Santa se viene detectando la falta de control de las

clientes busquen mejoras en otras Cooperativas.

Razn por la cual se ve la necesidad de automatizar actividades manuales que se

llevan a cabo en el Transporte Santa. A continuacin se detallan las razones que

administrar la disponibilidad de asientos de los buses.

El presente plan de proyecto abarca el Anlisis, Diseo y Desarrollo de una

Aplicacin de Control de rutas, reservacin y venta de tickets para la Cooperativa de

Transportes Santa, utilizando la tecnologa ASP para la interfaz en la Web, el sistema

la aplicacin son: Administracin de Usuarios. Administracin de Perfiles.

Administracin de Rutas Administracin de Reservaciones Administracin de Sucursal

Administracin de Venta de Tickets.

10.2. PROGRAMACION EN INTERNET...........................................................39

Figura 1: Fases del Modelo Lineal Secuencial................................................................17

Tabla 1: Requerimientos Funcionales.............................................................................53

para lo cual se ha realizado el anlisis Actualmente en el Instituto Tecnolgico

evaluar las materias tericas de Programacin en Internet, Ingeniera de Software es

mediante la elaboracin y presentacin de proyectos integradores. Los proyectos

integradores se diferencian por diferentes categoras: Sencillos (un proyecto por

materia), interdisciplinarias (Un proyecto por varias materias), multidisciplinario (un

proyecto que contiene varias carreras).

un conjunto de normas aceptadas y consensuadas. El Instituto Tecnolgico

Tomando en cuenta la investigacin realizada en la primera fase del proyecto,

eficiente de la Cooperativa de Transporte. En el mbito empresarial enfocndose en las

pequeas y medianas cooperativas de transporte las aplicaciones Informticas para los

procesos de prestacin de informacin han ido evolucionando en base a los avances

tecnolgicos presentados en los ltimos aos, facilitando y prestando una informacin

mucho ms eficiente a todas las personas.

adaptacin de aplicaciones informticas en nuestro vivir.

Esta aplicacin est enfocado en mejorar la informacin de servicios que presta la

Cooperativa de Trasporte Santa de la Ciudad de Loja Ubicada con su oficina en el

Terminal Terrestre Reina del Cisne de la Ciudad de Loja. Tomando

dar solucin a los problemas encontrados en la Cooperativa de Trasporte. Todo el

permitiera intervenir de una manera clara y precisa.

El presente proyecto es importante en el mbito acadmico ya que es un requisito

fundamental para aprobar las asignaturas de Programacin en Internet, Ingeniera de

Software y a la vez ser promovido a sexto ciclo de la carrera de Sistemas de

Automatizacin; as tambin se cumplir con lo establecido en el Reglamento Interno

asignaturas prcticas es necesario elaborar un Proyecto Integrador con la finalidad de

En el mbito tecnolgico el presente proyecto beneficiara a la provincia de Loja

facilitndole nueva tecnologa a las empresas. Ya su vez ayudaremos a dar realce a la

zona 7 del pas.

El desarrollo del presente proyecto ayudar a demostrar los conocimientos

adquiridos en las materias mencionadas anteriormente, y as tambin acceder y hacer

uso de diferentes lenguajes de programacin que actualmente se encuentran en auge y a

su vez utilizar metodologas ordenadas para el desarrollo de aplicaciones web.

9.1. OBJETIVO GENEAL

Analizar, Disear y Desarrollar una aplicacin web de control de

Rutas, Reservacin y Venta de Tickets para los Cooperativa de

9.2. OBJETIVOS ESPECIFICOS

Levantar los requisitos de la Cooperativa para desarrollar un

Sistema de acuerdo a sus necesidades.

usuarios desde la WEB, para el personal a cargo de las oficinas de

la Cooperativa, manteniendo la informacin real y actualizada de

todos los procesos que realiza la Cooperativa.

10. MARCO TERICO

10.1. INGENIERIA DEL SOFTWARE

10.1.1. Definicin Ingeniera del Software.

La Ingeniera del Software es una disciplina o rea de la Informtica que ofrece

mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven