“SISTEMA WEB PARA EL

CONTROL DE VENTAS” CASO:

PIZZA NINJA

CAPÍTULO II
Marco Teórico

2.1. Introducción
En el presente capitulo se da a conocer el marco teórico para absorber las dudas y como se
sustenta el proyecto de grado, donde los elementos teóricos están extraídos de varias fuentes
por lo tanto constituyen la explicación del problema planteado.
2.2. Ingeniera de Software
La ingeniería del software es una disciplina de la ingeniería que comprende todos los
aspectos de la producción de software desde las etapas iniciales de la especificación del
sistema, hasta el mantenimiento de este después de que se utiliza. En esta definición,
existen dos frases clave:
 Disciplina de la ingeniería. Los ingenieros hacen que las cosas funcionen. Aplican
teorías, métodos y herramientas donde sean convenientes, pero las utilizan de forma
selectiva y siempre tratando de descubrir soluciones a los problemas, aun cuando no
existan teorías y métodos aplicables para resolverlos. Los ingenieros también saben que
deben trabajar con restricciones financieras y organizacionales, por lo que buscan
soluciones tomando en cuenta estas restricciones.
 Todos los aspectos de producción de software. La ingeniería del software no solo
comprende los procesos técnicos del desarrollo de software, sino también con
actividades tales como la gestión de proyectos de software y el desarrollo de
herramientas, métodos y teorías de apoyo a la producción de software.

En general, los ingenieros de software adoptan un enfoque sistemático y organizado en su

trabajo, ya que es la forma más efectiva de producir software de alta calidad sin embargo,
aunque la ingeniería consiste en seleccionar el método más apropiado para un conjunto de
circunstancia, un enfoque más informal y creativo de desarrollo podría ser efectivo en
algunas circunstancias. El desarrollo informal es apropiado para el desarrollo de sistemas
basado en Web, los cuales requieren una mezcla de técnicas de software y de diseño
gráfico. (Sommerville, 2005, pág. 6)

2.2.1. Metodología de desarrollo Extreme Programming (XP)

Extreme Programming es una metodología ágil para el desarrollo de software y consiste

básicamente en ajustarse estrictamente a una serie de reglas que se centran en las
necesidades del cliente para lograr un producto de buena calidad en poco tiempo, centrada
en potenciar las relaciones interpersonales como clave para el éxito del desarrollo de
software. Está diseñada para el desarrollo de aplicaciones que requieran un grupo de
programadores pequeño, dónde la comunicación sea más factible que en grupos de
desarrollo grandes. La comunicación es un punto importante y debe realizarse entre los
programadores, los jefes de proyecto y los clientes. (Aduviri, 2016 en Rojas, 2014)

XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave
para el éxito en el desarrollo de software, promoviendo el trabajo en equipo, preocupándose
en todo momento del aprendizaje de los desarrolladores y propiciando un buen clima de
trabajo. XP se basa en la realimentación continua entre el cliente y el equipo de desarrollo,
comunicación fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como especialmente
adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un
alto riesgo técnico. (Beck, 1999)

2.2.1.1. Valores de la metodología XP

Los valores originales de la metodogia XP según Kent Beck son:
 Simplicidad XP propone el principio de hacer la cosa más simple que pueda funcionar,
en relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo
complicado y probablemente nunca usarlo mañana.
 Comunicación Algunos problemas en los proyectos tienen origen en que alguien no dijo
algo importante en algún momento. XP hace casi imposible la falta de comunicación.
 Realimentación Retralimentación concreta y frecuente del cliente, del equipo y de los
usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.
 Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si funciona…
mejóralo)
2.2.1.2. PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA
Para que todo esto funcione, la programación extrema se basa en doce "prácticas básicas"
que deben seguirse al pie de la letra. (Beck, 1999)
 Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver
con el proyecto, incluido el cliente y el responsable del proyecto
 Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a
hacer y las mini-versiones. La planificación se revisa continuamente.
 Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias
pruebas para validar las mini-versiones.
 Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como
para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al
usuario final y no trozos de código que no pueda ver funcionando.
 Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla
posible. Mantener siempre sencillo el código.
 Pareja de programadores: Los programadores trabajan por parejas (dos delante del
mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
 Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba
automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan,
mejor.
 Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y
en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es
un error mantener una versión congelada dos meses mientras se hacen mejoras y luego
integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo
que hemos metido.
 El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del
código. Para eso se hacen las pruebas automáticas.
 Normas de codificación: Debe haber un estilo común de codificación (no importa cual),
de forma que parezca que ha sido realizado por una única persona.
 Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las
distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer
una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el
 "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente)
sepan de qué estamos hablando y que no haya mal entendidos.
 Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente.
Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no
se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que
debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de
terminar una historia de usuario o mini-versión.
2.2.1.3. Fases de la Metodología XP
XP abarca 4 actividades que posteriormente serán descritas cada una, las fases se muestran
en la figura 2.
Figura 2 Metodología XP: Fases de la Metodología XP
Fuente: Bustamante y Rodríguez, 2015

2.2.1.3.1. Planificación del proyecto

La planificación del proyecto se plasma en la figura 2.1
Figura 2.1 Metodología XP: Fase Planificación del Proyecto XP
Fuente: Propia
 Historias de usuario: El primer paso de cualquier proyecto que siga la metodología XP
es definir las historias de usuario con el cliente. Las historias de usuario tienen la misma
finalidad que los casos de uso, pero con algunas diferencias: Constan de 3 ó 4 líneas
escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los
detalles; no se debe hablar ni de posibles algoritmos para su implementación ni de
diseños de base de datos adecuados, entre otros. Son usadas para estimar tiempos de
desarrollo de la parte de la aplicación que describen. También se utilizan en la fase de
pruebas, para verificar si el programa cumple con lo que especifica la historia de
usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los
desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha historia.
El tiempo de desarrollo ideal para una historia de usuario es 22 entre 1 y 3 semanas.
Las historias de usuario tienen tres aspectos:
o Tarjeta: en ella se almacena suficiente información para identificar y detallar la
historia.
o Conversación: cliente y programadores número discuten la historia para ampliar
los detalles (verbalmente cuando sea posible, pero documentada cuando se
requiera).
o Pruebas de aceptación: permite confirmar que la historia ha sido implementada
 Release Planning: Después de tener ya definidas las historias de usuario es necesario
crear un plan de publicaciones, donde se indiquen las historias de usuario que se crearán
para cada versión del programa y las fechas en las que se publicarán estas versiones. Un
Release planes una planificación donde los desarrolladores y clientes establecen los
tiempos de implementación ideales de las historias de usuario, la prioridad con la que
serán implementadas y las historias que serán implementadas en cada versión del
programa. Después de un Release plan tienen que estar claros estos cuatro factores: los
objetivos que se deben cumplir (que son principalmente las historias que se deben
desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las
versiones del programa, el número de personas que trabajarán en el desarrollo y cómo
se evaluará la calidad del trabajo realizado.
 Iteraciones: Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones
de aproximadamente 1 a 3 semanas de duración. Al comienzo de cada iteración los
 clientes deben seleccionar las historias de usuario definidas en el "Release planning"
que serán implementadas. También se seleccionan las historias de usuario que no
pasaron el test de aceptación que se realizó al terminar la iteración anterior. Estas
historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se
asignarán a los programadores. Para cada iteración se define un módulo al conjunto de
historia de usuario que se van a implementar, al final de cada iteración se tiene la
entrega de un producto, el cual debe superar las pruebas de aceptación que establece el
cliente para dar 24 cumplimiento a los requisitos las tareas que no se vean cubiertas por
el producto deberán ser tomadas en cuenta para la siguiente iteración
 La Velocidad del Proyecto: Es una medida que representa la rapidez con la que se
desarrolla el proyecto; estimarla es muy sencillo, basta con contar el número de
historias de usuario que se pueden implementar en una iteración; de esta forma, se sabrá
el cupo de historias que se pueden desarrollar en las distintas iteraciones. Usando la
velocidad del proyecto controlaremos que todas las tareas se puedan desarrollar en el
tiempo del que dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4
iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo
Release Plan. La velocidad de proyecto se usa para determinar cuántas historias de
usuario puede ser implementada antes de una fecha dada (tiempo), o cuento tiempo es
necesario para llevar a cabo un conjunto de historias (alcance). Cuanto se realiza una
planificación por alcance se divide el número total de semanas entre la velocidad del
proyecto para determinar cuántas iteraciones estarán disponibles.
N úmero de Historias de usuario
Velocidad del Proyecto=
N úmero de Semanas
 Programación en Parejas: La metodología X.P. aconseja la programación en parejas
pues incrementa la productividad y la calidad del software desarrollado. El trabajo en
pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno
codifica haciendo hincapié en la calidad de la función o método que está
implementando, el otro analiza si ese método o función es adecuado y está bien
diseñado. De esta forma se consigue un código y diseño con gran calidad.
 Reuniones Diarias: Es necesario que los desarrolladores se reúnan diariamente y
expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen
que ser fluidas y todo el mundo tiene que tener voz y voto
2.2.1.3.2. Diseño
El diseño del proyecto se plasma en la figura 2.2
Figura 2.2 Metodología XP: Fase Diseño del Proyecto XP
Fuente: Propia

 Diseños Simples: La metodología XP sugiere que hay que conseguir diseños simples y
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir
un diseño fácilmente entendible.
 Glosarios de Términos: Usar glosarios de términos y una correcta especificación de
los nombres de métodos y clases ayudará a comprender el diseño y facilitará sus
posteriores ampliaciones y la reutilización del código.
 Riesgos: Si surgen problemas potenciales durante el diseño, XP sugiere utilizar una
pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que
supone ese problema.
 Funcionabilidad extra: Nunca se debe añadir funcionalidad extra al programa, aunque
se piense que en un futuro será utilizada.
 Refactorizar: Refactorizar es mejorar y modificar la estructura y codificación de
códigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo
estos códigos para procurar optimizar su funcionamiento.
2.2.1.3.3. Codificación
El cliente es una parte más del equipo de desarrollo, su presencia es indispensable en las
distintas fases de XP. A la hora de codificar una historia de usuario su presencia es aún más
necesaria. No olvidemos que los clientes son los que crean las historias de usuarios y
negocian los tiempos en los que serán implementados. Antes del desarrollo de cada historia
de usuario el cliente debe especificar detalladamente lo que esta hará y también tendrá que
estar presente cuando se realicen los test que verifiquen que la historia implementada
cumple la funcionalidad especificada. La codificación debe hacerse ateniendo a estándares
de codificación ya creados. Programar bajo estándares mantiene el código constante y
facilita su comprensión y escalabilidad. (Beck, 1999)
2.2.1.3.4. Pruebas
Uno de los planes de la metodología XP es el uso de test para comprobar el funcionamiento
de los códigos que vayamos implementando.
El uso de los test en XP es el siguiente:
 Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo
específico para test.
 Hay que someter al test las distintas clases del sistema omitiendo los métodos más
triviales.
 Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado
anterior se explicó la importancia de crear antes los test que el código.
 Un punto importante es crear test que no tengan ninguna dependencia del código que en
un futuro evaluará.
 Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas
tareas en las que ha sido dividida una historia de usuario.
 Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se
harán test que analicen partes de las mismas, sino que las pruebas se realizarán para las
funcionalidades generales que debe cumplir el programa especificado en la descripción
de requisitos.
2.2.1.4. Roles de la metodología XP
Los roles que posee la metodología XP permite a los desarrolladores organizar y distribuir
el trabajo de manera más equilibrada y eficiente. Estos roles se pueden resumir de la
siguiente manera:
 Programador
Responsable de construir, analizar, programar, tomar decisiones y realizar pruebas del
sistema.
 Jefe de proyecto
Responsable de coordinar, gestionar y administrar las reuniones para considerar las
condiciones de cómo avanza el proyecto.
 Cliente
Persona que debe especificar qué construir, cuándo y dónde realizar las pruebas.
 Encargado de pruebas
Delegado de ayudar al cliente para que las pruebas sean realizadas y superadas.
 Rastreador
Responsable de obtener datos históricos; encargados de observar sin molestar durante el
desarrollo del sistema.
 Entrenador
Facultado de visualizar el proceso y desarrollo del sistema, desde un segundo plano.
Cuando se utilizan los roles de la metodología xp se trata al cliente como parte del equipo
de desarrolladores, lo que evita la redundancia de información, y permite que se realicen
pruebas constantes de la aplicación. Otro beneficio de esta inclusión es que se efectúan
cambios mientras avanza el desarrollo según los requerimientos solicitados evitando
pérdidas de tiempo.
(Rodriguez, 2014)
2.3. Diagramas UML(LENGUAJE UNIFICADO DE MODELADO)
UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y una reglas para permitir
una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un
sistema. Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto
último es el objetivo de las metodologías de desarrollo. Las objetivos de UML son muchos, pero se
pueden sintetizar sus funciones:
 Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede
entender.
 Especificar: UML permite especificar cuáles son las características de un sistema antes de su
construcción
 Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.
 Documentar: Los propios elementos gráficos sirven como documentación del sistema
desarrollado que pueden servir para su futura revisión
Aunque UML está pensado para modelar sistemas complejos con gran cantidad de software, el
lenguaje es los suficientemente expresivo como para modelar sistemas que no son informáticos,
como flujos de trabajo (workflow ) en una empresa, diseño de la estructura de una organización y
por supuesto, en el diseño de hardware.
Un modelo UML está compuesto por tres clases de bloques de construcción:
 Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones,
etc.).
 Relaciones: relacionan los elementos entre sí.
 Diagramas: Son colecciones de elementos con sus relaciones.
(G. Booch, J. Rumbaugh y I. Jacobson, “El Lenguaje Unificado de Modelado”, Addison Wesley,
1999.)
2.3.1. DIAGRAMAS
2.3.1.1. DIAGRAMA DE CASOS DE USO
Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del
usuario
Figura 3.1.1.1. Diagramas de casos de uso
Fuente: Propia
2.3.1.2. DIAGRAMA DE SECUENCIA
El diagrama de secuencia UML, muestra la mecánica de la interacción con base en
tiempos. El diagrama de secuencia es un tipo de diagrama de interacción cuyo objetivo es
describir el comportamiento dinámico del sistema de información haciendo énfasis en la
secuencia de los mensajes intercambiados por los objetos.
Figura 3.1.1.2.Diagramas de Secuencia
Fuente: (“Diagrama de Secuencia”, Manuel Cillero, (2004))

2.3.1.3. DIAGRAMAS DE ACTIVIDADES

Las actividades que ocurren dentro de un caso de uso o dentro del comportamiento de un objeto
se dan, normalmente, en secuencia, como en los once pasos de la sección anterior.
Figura 3.1.1.2.Diagramas de Actividades
Fuente: ("Aprendiendo UML en 24 Horas". Schmuller, J. (2004). p. 31)

2.3.1.4. DIAGRAMA DE CLASES

Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares, como por
ejemplo la clase lavadora, cuenta con los atributos marca, modelo, número de serie, capacidad.
También posee ciertos comportamientos o métodos tal como: agregar ropa, agregar detergente y
sacar ropa.
 Figura 3.1.1.2.Diagramas de Clases
Fuente: ("Aprendiendo UML en 24 Horas". Schmuller, J. (2004). p. 28)

2.3.1.5. CONTROL DE CALIDAD Y PRUEBAS

Las razones por las que ocurren los errores en el software:
 Especificaciones: Al momento de redactar las especificaciones estas están incompletas,
ambiguas, variables o simplemente no están realizadas.
 Diseño: El diseño de la solución esta incompleto o inadecuado o bien las especificaciones no se
comprendieron correctamente.
 Codificación: el código es incorrecto porque se hizo rápidamente, el programador no conoce
bien el lenguaje o no comprendió bien el diseño.
La calidad es un concepto difícil de definir ya que contiene múltiples facetas, en primer lugar según
Pressman (2010), es una característica que se reconoce de inmediato aunque no pueda ser
definida explícitamente, desde el punto de vista del usuario es un producto o servicio que satisface
sus necesidades, para el fabricante es el cumplimiento de las especificaciones del producto
fabricado o servicio prestado, la calidad también se encuentra relacionada con el precio que está
dispuesto a pagar el comprador a cambio de un producto con tales características.
En el desarrollo de software, la calidad del diseño es el grado en el que éste cumple con las
funciones y características especificadas en el modelo de requerimiento. La calidad de la
conformidad se centra en el grado en el que la implementación se apega al diseño y en el que el
sistema resultante cumple sus metas de requerimientos y desempeño.
La calidad del software, continua Pressman (2010), se presenta de la siguiente manera:
 Un proceso eficaz de software envuelve la calidad del proceso con el cual es llevado a cabo,
envolviendo los aspectos de gestión y de buenas prácticas de ingeniería.
 En segundo lugar se relaciona con la producción de un producto útil que cumpla con las
expectativas del usuario de forma confiable y libre de errores.
 Añade valor agregado al productor y el usuario del producto, beneficiando a la organización
que lo utiliza, lo produce y a la comunidad de usuarios finales.
 Así el producto final redunda en una serie de beneficios, menor esfuerzo en mantenimiento,
menores errores, menos costo de producción, mayor rentabilidad y disponibilidad de
información. Señala Pressman (2010) los factores de calidad dictada por la norma ISO 9126,
que sirven de guía de acción a la calidad:
 Funcionalidad: Es el grado en el que el software satisface las necesidades planteadas según su:
adaptabilidad, exactitud, interoperatividad, cumplimiento y seguridad.
 Confiabilidad: Cantidad de tiempo que el software se encuentra disponible para su uso, según
lo indican los atributos tales como: madurez, tolerancia a fallos y recuperación.
 Usabilidad: Grado en el que el software es fácil de usar, que sea entendible, aprendible y
operable. Eficiencia: Grado en el que el software emplea óptimamente los recursos del
sistema.
 Facilidad de recibir mantenimiento: Facilidad con la que pueden efectuarse reparaciones al
software, que sea analizable, cambiable, estable y susceptible de someterse a pruebas.
Portabilidad: Facilidad con la que el software puede llevarse de un ambiente a otro,
cumpliendo con atributos de adaptabilidad, instalable, conformidad y sustituible
2.4. TECNOLOGIAS DE SOFTWARE
2.4.1. LENGUAJES DE PROGRAMACION
Un lenguaje de programación" es un lenguaje diseñado para describir el conjunto de acciones
consecutivas que un equipo debe ejecutar. Por lo tanto, un lenguaje de programación es un modo
práctico para que los seres humanos puedan dar instrucciones a un equipo.
Por otro lado, el término "lenguaje natural" define un medio de comunicación compartido por un
grupo de personas (por ejemplo: inglés o francés).
Los lenguajes que los equipos usan para comunicarse entre ellos no tienen nada que ver con los
lenguajes de programación; se los conoce como protocolos de comunicación. Se trata de dos
conceptos totalmente diferentes. Un lenguaje de programación es muy estricto:
A CADA instrucción le corresponde UNA acción de procesador.
El lenguaje utilizado por el procesador se denomina lenguaje máquina. Se trata de datos tal como
llegan al procesador, que consisten en una serie de 0 y 1 ( datos binarios).
El lenguaje máquina, por lo tanto, no es comprensible para los seres humanos, razón por la cual se
han desarrollado lenguajes intermediarios comprensibles para el hombre. El código escrito en este
tipo de lenguaje se transforma en código máquina para que el procesador pueda procesarlo.
El ensamblador fue el primer lenguaje de programación utilizado. Es muy similar al lenguaje
máquina, pero los desarrolladores pueden comprenderlo. No obstante, este lenguaje se parece
tanto al lenguaje máquina que depende estrictamente del tipo de procesador utilizado (cada tipo
de procesador puede tener su propio lenguaje máquina). Así, un programa desarrollado para un
equipo no puede ser portado a otro tipo de equipo. El término "portabilidad" describe la
capacidad de usar un programa de software en diferentes tipos de equipos. Para poder utilizar un
programa de software escrito en un código ensamblador en otro tipo de equipo, ¡a veces será
necesario volver a escribir todo el programa!
Por lo tanto, un lenguaje de programación tiene varias ventajas:
 es mucho más fácil de comprender que un lenguaje máquina:
 permite mayor portabilidad, es decir que puede adaptarse fácilmente para ejecutarse
2.4.2. JAVA
El lenguaje de programación Java fue originalmente desarrollado por James Gosling de Sun
Microsystems (la cual fue adquirida por la compañía Oracle) y publicado en 1995 como un
componente fundamental de la plataforma Java de Sun Microsystems. Su sintaxis deriva mucho de
C y C++, pero tiene menos facilidades de bajo nivel que cualquiera de ellos. Las aplicaciones de
Java son generalmente compiladas a bytecode (clase Java) que puede ejecutarse en cualquier
máquina virtual Java (JVM) sin importar la arquitectura de la computadora subyacente. Es un
lenguaje de programación de propósito general, concurrente, orientado a objetos y basado en
clases que fue diseñado específicamente para tener tan pocas dependencias de implementación
como fuera posible. Su intención es permitir que los desarrolladores de aplicaciones escriban el
programa una vez y lo ejecuten en cualquier dispositivo (conocido en inglés como WORA, o "write
once, run anywhere"), lo que quiere decir que el código que es ejecutado en una plataforma no
tiene que ser recompilado para correr en otra. Java es, a partir de 2012, uno de los lenguajes de
programación más populares en uso, particularmente para aplicaciones de clienteservidor de web,
con unos 10 millones de usuarios reportados.
La compañía Sun desarrolló la implementación de referencia original para los compiladores de
Java, máquinas virtuales, y librerías de clases en 1991 y las publicó por primera vez en 1995. A
partir de mayo de 2007, en cumplimiento con las especificaciones del Proceso de la Comunidad
Java, Sun volvió a licenciar la mayoría de sus tecnologías de Java bajo la Licencia Pública General
de GNU. Otros también han desarrollado implementaciones alternas a estas tecnologías de Sun,
tales como el Compilador de Java de GNU y el GNU Classpath.
El lenguaje para la programación en Java, es un lenguaje orientado a objeto, de una plataforma
independiente. El lenguaje para la programación en Java, fue desarrollado por la compañia Sun
Microsystems, con la idea original de usarlo para la creacion de paginas WEB. Esta programación
Java tiene muchas similitudes con el lenguaje C y C++, asi que si se tiene conocimiento de este
lenguaje, el aprendizaje de la programación Java sera de facil comprension por un programador
que haya realizado programas en estos lenguajes. Con la programación en Java, se pueden realizar
distintos aplicativos, como son applets, que son aplicaciones especiales, que se ejecutan dentro de
un navegador al ser cargada una pagina HTML en un servidor WEB, Por lo general los applets son
programas pequeños y de propositos especificos. Otra de las utilidades de la programación en Java
es el desarrollo de aplicaciones, que son programas que se ejecutan en forma independiente, es
decir con la programación
Java, se pueden realizar aplicaciones como un procesador de palabras, una hoja que sirva para
calculos, una aplicacion grafica, etc. en resumen cualquier tipo de aplicacion se puede realizar con
ella. Java permite la modularidad por lo que se pueden hacer rutinas individuales que sean usadas
por más de una aplicacion, por ejemplo tenemos una rutina de impresion que puede servir para el
procesador de palabras, como para la hoja de calculo.
La programación en Java, permite el desarrollo de aplicaciones bajo el esquema de Cliente
Servidor, como de aplicaciones distribuidas, lo que lo hace capaz de conectar dos o más
computadoras u ordenadores, ejecutando tareas simultaneamente, y de esta forma logra
distribuir el trabajo a realizar.
2.4.3. PHP
PHP es un lenguaje de programación de uso general de código del lado del servidor originalmente
diseñado para el desarrollo web de contenido dinámico. Fue uno de los primeros lenguajes de
programación del lado del servidor que se podían incorporar directamente en el documento HTML
en lugar de llamar a un archivo externo que procese los datos. El código es interpretado por un
servidor web con un módulo de procesador de PHP que genera la página Web resultante. PHP ha
evolucionado por lo que ahora incluye también una interfaz de línea de comandos que puede ser
usada en aplicaciones gráficas independientes. Puede ser usado en la mayoría de los servidores
web al igual que en casi todos los sistemas operativos y plataformas sin ningún costo. Fue creado
originalmente por Rasmus Lerdorf en 1995. Actualmente el lenguaje sigue siendo desarrollado con
nuevas funciones por el grupo PHP.2 Este lenguaje forma parte del software libre publicado bajo la
licencia PHP, que es incompatible con la Licencia Pública General de GNU debido a las restricciones
del uso del término PHP
2.4.3.1. VISION GENERAL
PHP puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas
operativos y plataformas sin costo alguno. El lenguaje PHP se encuentra instalado en más de 20
millones de sitios web y en un millón de servidores. El enorme número de sitios en PHP ha visto
reducida su cantidad a favor de otros nuevos lenguajes no tan poderosos desde agosto de 2005. El
sitio web de Wikipedia está desarrollado en PHP. Es también el módulo Apache más popular entre
las computadoras que utilizan Apache como servidor web.
El gran parecido que posee PHP con los lenguajes más comunes de programación estructurada,
como C y Perl, permiten a la mayoría de los programadores crear aplicaciones complejas con una
curva de aprendizaje muy corta. También les permite involucrarse con aplicaciones de contenido
dinámico sin tener que aprender todo un nuevo grupo de funciones.
Aunque todo en su diseño está orientado a facilitar la creación de sitios webs, es posible crear
aplicaciones con una interfaz gráfica para el usuario, utilizando alguna extensión como puede ser
PHP-Qt, PHP-GTK, WxPHP, WinBinder, Roadsend PHP, Phalanger, Phc o HiP Hop VM. También
puede ser usado desde la línea de comandos, de la misma manera como Perl o Python pueden
hacerlo; a esta versión de PHP se la llama PHP-CLI (Command Line Interface).
Cuando el cliente hace una petición al servidor para que le envíe una página web, el servidor
ejecuta el intérprete de PHP. Éste procesa el script solicitado que generará el contenido de manera
dinámica (por ejemplo obteniendo información de una base de datos). El resultado es enviado por
el intérprete al servidor, quien a su vez se lo envía al cliente.
Mediante extensiones es también posible la generación de archivos PDF,Flash, así como imágenes
en diferentes formatos.
Permite la conexión a diferentes tipos de servidores de bases de datos tanto SQL como NoSQL
tales como MySQL, PostgreSQL, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird, SQLite o
MongoDB.
PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas operativos, tales
como Unix (y de ese tipo, como Linux o Mac OS X) y Microsoft Windows, y puede interactuar con
los servidores de web más populares ya que existe en versión CGI, módulo para Apache, e ISAPI.
PHP es una alternativa a las tecnologías de Microsoft ASP y ASP.NET (que utiliza C# y Visual
Basic .NET como lenguajes), a ColdFusion de la empresa Adobe, a JSP/Java, CGI/Perl y a
Node.js/Javascript. Aunque su creación y desarrollo se da en el ámbito de los sistemas libres, bajo
la licencia GNU, existe además un entorno de desarrollo integrado comercial llamado Zend Studio.
CodeGear (la división de lenguajes de programación de Borland) ha sacado al mercado un entorno
de desarrollo integrado para PHP, denominado 'Delphi for PHP. También existen al menos un par
de módulos para Eclipse, uno de los entornos más populares.
2.5. SISTEMA DE GESTION DE BASE DE DATOS
2.5.1. INTRODUCCION
El propósito general de los sistemas de gestión de base de datos es el de manejar de manera clara,
sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información
relevante, para un buen manejo de datos.
2.5.2. BASE DE DATOS
En el entorno informático, la gestión de bases de datos ha evolucionado desde ser una aplicación
más disponible para los computadores, a ocupar un lugar fundamental en los sistemas de
información. En la actualidad, un sistema de información será más valioso cuanto de mayor
calidad sea la base de datos que lo soporta, la cual resulta a su vez un componente fundamental
del mismo, de tal forma que puede llegarse a afirmar que es imposible la existencia de un sistema
de información sin una base de datos, que cumple la función de "memoria", en todas sus
acepciones posibles, del sistema.
Las bases de datos almacenan, como su nombre dice, datos. Estos datos son representaciones de
sucesos y objetos, a diferente nivel, existentes en el mundo real: en su conjunto, representan
algún tipo de entidad existente. En el mundo real se tiene percepción sobre las entidades u
objetos y sobre los atributos de esos objetos; en el mundo de los datos, hay registros de eventos y
datos de eventos. Además, en ambos escenarios se puede incluso distinguir una tercera faceta:
aquella que comprende las definiciones de las entidades externas, o bien las definiciones de los
registros y de los datos.
La transferencia entre las entidades del mundo real, y sus características, y los registros contenidos
en una base de datos, correspondientes a esas entidades, se alcanza tras un proceso lógico de
abstracción, conjunto de tareas que suelen englobarse bajo el título de diseño de bases de datos.
Sin embargo, es necesario definir, en primer lugar, qué es una base de datos, independientemente
de su diseño y/o su orientación. Entre las numerosas definiciones que pueden encontrarse en la
bibliografía, pueden escogerse, por su exhaustividad, las siguientes:
"Colección de datos correspondientes a las diferentes perspectivas de un sistema de información
(de una empresa o institución), existentes en algún soporte de tipo físico (normalmente de acceso
directo), agrupados en una organización integrada y centralizada en la que figuran no sólo los
datos en sí, sino también las relaciones existentes entre ellos, y de forma que se minimiza la
redundancia y se maximiza la independencia de los datos de las aplicaciones que los requieren."
(GUILERA, 1993: 377)
"Una base de datos es una colección de datos estructurados según un modelo que refleje las
relaciones y restricciones existentes en el mundo real. Los datos, que han de ser compartidos por
diferentes usuarios y aplicaciones, deben mantenerse independientes de éstas, y su definición y
descripción han de ser únicas estando almacenadas junto a los mismos. Por último, los
tratamientos que sufran estos datos tendrán que conservar la integridad y seguridad de éstos."
(MOTA, CELMA y CASAMAYOR, 1994: 9)
La segunda definición añade los objetivos que debe cumplir un sistema de gestión de bases de
datos, sobre los cuales se tratará más adelante. Por ahora, basta considerar que deben cumplir los
objetivos de independencia de los datos (las aplicaciones no deben verse afectadas por cambios
en la estructura de los datos), integridad de los datos (los datos deben cumplir ciertas restricciones
que aseguren la correcta introducción, modificación y borrado de los mismos) y seguridad
(establecer diferentes niveles de acceso a los datos a diferentes tipos de usuarios).
La entidad existente en el mundo real es objeto de un doble tratamiento, desde el momento en
que convierte en objeto de la base de datos. El tratamiento de sus datos se va a realizar en un
nivel lógico, por una parte, y en un nivel físico, por otra. En el primero de ellos, el lógico, se va a
trabajar en los aspectos referidos a la identificación de las características de la entidad, su
descripción y organización, mientras que en el segundo todo lo anterior se va a plasmar en la
organización, acceso y almacenamiento de los datos en un soporte físico. Esta división entre un
nivel lógico y otro físico se va reflejar en todos los métodos y conceptos subsiguientes.
2.5.3. MODELO DE ARQUITECTURA DE BASE DE DATOS
Hasta fecha relativamente cercana, las bases de datos eran el resultado de una compleja
programación y de complicados mecanismos de almacenamiento. Con la popularización de la
microinformática, la aparición de aplicaciones específicas también trajo con ella la disponibilidad
de herramientas de gestión de datos, que acabaron desembocando en los denominados sistemas
de gestión de bases de datos, identificados por sus siglas SGBD (DBMS en inglés, siglas de
DataBase Management Systems). De esta manera, la gestión de base de datos pudo liberarse de
los grandes ordenadores centrales, pudiendo distribuirse según los intereses de los usuarios, y
dotando de autonomía en la gestión de información a muchas entidades. Los SGBD permitieron a
todo tipo de usuarios crear y mantener sus bases de datos, dotándolos de una herramienta que
era capaz de transformar el nivel lógico que éstos diseñaban en un conjunto de datos,
representaciones y relaciones, traduciéndolo al nivel físico correspondiente. Para que fuese
posible, y para asegurar a los usuarios cierta seguridad en el intercambio de datos entre diferentes
sistemas, y en el diseño de ficheros y bases de datos, fue necesario normalizar los esquemas que
guiaban la creación de las bases de datos.
2.6. METODOS DE ANALISIS DE COSTOS Y BENEFICIOS
2.6.1. COCOMO
El Modelo Constructivo de Costos (o COCOMO, por su acrónimo del inglés COnstructive COst
MOdel) es un modelo matemático de base empírica utilizado para estimación de costos1 de
software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez
mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80,
exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981)
2.6.2. CARACTERISTICAS
Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas.
Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de
código principalmente.
2.6.3. INCONVENIENTES
 Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los
recursos necesarios para realizarlas.
 Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el
código fuente.
 Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser
"vistos" de distinta manera por distintos analistas que usen el método.
 Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la
productividad.
 La medición por líneas de código no es válida para orientación a objetos.
 Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos
(que también sólo estiman).
2.6.4. MODELOS DE ESTIMACION
La ecuaciones que se utilizan en los tres modelos son:

 E=a( Kl )b∗m(X ), en persona - mes

d
 Tdev=c(E) , en meses
 P=E / Tdev , en personas
Donde::
 E es el esfuerzo requerido por el proyecto, en persona-mes
 Tdev es el tiempo requerido por el proyecto, en meses
 P es el número de personas requerido por el proyecto
 a, b, c y d son constantes con valores definidos en una tabla, según cada submodelo
 Kl es la cantidad de líneas de código, en miles.
 m(X) Es un multiplicador que depende de 15 atributos.
A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y
puede ser:
 Modo orgánico: un pequeño grupo de programadores experimentados desarrollan software
en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas
(tamaño pequeño) a unas decenas de miles (medio).
 Modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el
rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no
experimentadas.
 Modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar
relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es
difícil basarse en la experiencia, puesto que puede no haberla.
2.6.5. VAN(VALOR ACTUAL NETO)
El valor actual neto, también conocido como valor actualizado neto o valor presente neto (en
inglés net present value), cuyo acrónimo es VAN (en inglés, NPV), es un procedimiento que
permite calcular el valor presente de un determinado número de flujos de caja futuros, originados
por una inversión. La metodología consiste en descontar al momento actual (es decir, actualizar
mediante una tasa) todos los flujos de caja (en inglés cash-flow) futuros den determinar la
equivalencia en el tiempo 0 de los flujos de efectivo futuros que genera un proyecto y comparar
esta equivalencia con el desembolso inicial. Dicha tasa de actualización (k) o de descuento (d) es el
resultado del producto entre el coste medio ponderado de capital (CMPC) y la tasa de inflación del
periodo. Cuando dicha equivalencia es mayor que el desembolso inicial, entonces, es
recomendable que el proyecto sea aceptado
En las transacciones internacionales es necesario aplicar una tasa de inflación particular, tanto,
para las entradas (cobros), como, para las de salidas de flujos (pagos). La condición que maximiza
el margen de los flujos es que la economía exportadora posea un IPC inferior a la importadora, y
viceversa.
La fórmula que nos permite calcular el Valor Actual Neto es:
n
Vt
VAN =∑ t
−I o
t=1 (1+k )
Vt: representa los flujos de caja en cada periodo t.
Io: es el valor del desembolso inicial de la inversión
n: es el número de períodos considerado.
k,d o TIR: es el tipo de interés.
Si el proyecto no tiene riesgo, se tomará como referencia el tipo de la renta fija, de tal manera que
con el VAN se estimará si la inversión es mejor que invertir en algo seguro, sin riesgo específico. En
otros casos, se utilizará el coste de oportunidad.
Cuando el VAN toma un valor igual a 0, k pasa a llamarse TIR (tasa interna de retorno). La TIR es la
rentabilidad que nos está proporcionando el proyecto.
2.6.5.1. INTERPRETACION
El valor actual neto es muy importante para la valoración de inversiones en activos fijos, a pesar de
sus limitaciones en considerar circunstancias imprevistas o excepcionales de mercado. Si su valor
es mayor a cero, el proyecto es rentable, considerándose el valor mínimo de rendimiento para la
inversión.
Una empresa suele comparar diferentes alternativas para comprobar si un proyecto le conviene o
no. Normalmente la alternativa con el VAN más alto suele ser la mejor para la entidad; pero no
siempre tiene que ser así. Hay ocasiones en las que una empresa elige un proyecto con un VAN
más bajo debido a diversas razones como podrían ser la imagen que le aportará a la empresa, por
motivos estratégicos u otros motivos que en ese momento interesen a dicha entidad.
Puede considerarse también la interpretación del VAN, en función de la creación de valor para la
empresa:
 Si el VAN de un proyecto es positivo, el proyecto crea valor.
 Si el VAN de un proyecto es negativo, el proyecto destruye valor.
 Si el VAN de un proyecto es cero, el proyecto no crea ni destruye valor.
2.6.5.2. PROCEDIMIENTOS DEL VALOR ACTUAL NETO
Como menciona el autor Coss Bu, existen dos tipos de valor actual neto:
 Valor presente de inversión total. Puesto que el objetivo en la selección de estas alternativas
es escoger aquella que maximice valor presente, las normas de utilización en este criterio son
muy simples. Todo lo que se requiere hacer es determinar el valor presente de los flujos de
efectivo que genera cada alternativa y entonces seleccionar aquella que tenga el valor
presente máximo. El valor presente de la alternativa seleccionada deberá ser mayor que cero
ya que de este manera el rendimiento que se obtiene es mayor que el interés mínimo
atractivo. Sin embargo es posible que en ciertos casos cuando se analizan alternativas
mutuamente exclusivas, todas tengan valores presentes negativos. En tales casos, la decisión a
tomar es “no hacer nada”, es decir, se deberán rechazar a todas las alternativas disponibles.
Por otra parte, si de las alternativas que se tienen solamente se conocen sus costos, entonces
la regla de decisión será minimizar el valor presente de los costos.
 Valor presente del incremento en la inversión. Cuando se analizan alternativas mutuamente
exclusivas, son las diferencias entre ellas lo que sería más relevante al tomador de decisiones.
El valor presente del incremento en la inversión precisamente determina si se justifican esos
incrementos de inversión que demandan las alternativas de mayor inversión.
Cuando se comparan dos alternativas mutuamente exclusivas mediante este enfoque, se
determinan los flujos de efectivo netos de la diferencia de los flujos de efectivo de las dos
alternativas analizadas. Enseguida se determina si el incremento en la inversión se justifica. Dicho
incremento se considera aceptable si su rendimiento excede la tasa de recuperación mínima.
2.6.5.3. VENTAJAS
 Es muy sencillo de aplicar, ya que para calcularlo se realizan operaciones simples.
 Tiene en cuenta el valor de dinero en el tiempo.
2.6.5.4. INCONVENIENTES
 Dificultad para establecer el valor de K. A veces se usan los siguientes criterios
o Coste del dinero a largo plazo
 o Tasa de rentabilidad a largo plazo de la empresa
o Coste de capital de la empresa.
o Como un valor subjetivo
o Como un coste de oportunidad.
 El VAN supone que los flujos que salen del proyecto se reinvierten en el proyecto al mismo
valor K que el exigido al proyecto, lo cual puede no ser cierto.
 EL VAN es el valor presente de los flujos futuros de efectivo menos el valor presente del costo
de la inversión.
2.6.6. TIR
La tasa interna de retorno o tasa interna de rentabilidad (TIR) de una inversión es el promedio
geométrico de los rendimientos futuros esperados de dicha inversión, y que implica por cierto el
supuesto de una oportunidad para "reinvertir". En términos simples, diversos autores la
conceptualizan como la tasa de descuento con la que el valor actual neto o valor presente neto
(VAN o VPN) es igual a cero.
La TIR puede utilizarse como indicador de la rentabilidad de un proyecto: a mayor TIR, mayor
rentabilidad, así, se utiliza como uno de los criterios para decidir sobre la aceptación o rechazo de
un proyecto de inversión. Para ello, la TIR se compara con una tasa mínima o tasa de corte, el
coste de oportunidad de la inversión (si la inversión no tiene riesgo, el coste de oportunidad
utilizado para comparar la TIR será la tasa de rentabilidad libre de riesgo). Si la tasa de rendimiento
del proyecto - expresada por la TIR- supera la tasa de corte, se acepta la inversión; en caso
contrario, se rechaza.
Otras Definiciones
 Es la tasa que iguala la suma del valor actual de los gastos con la suma del valor actual de
los ingresos previstos:
N N

∑ VPIi=∑ VPCi
i=1 i =1

 Es la tasa de interés para la cual los ingresos totales actualizados es igual a los costos
totales actualizados:
ITAc=CTAc
 Es la tasa de interés por medio de la cual se recupera la inversión
  Es la tasa de interés máxima a la que se pueden endeudar para no perder dinero con la
inversión.
 Es la tasa real que proporciona un proyecto de inversión y es aquella que al ser utilizada
como tasa de descuento en el cálculo de un VAN dará como resultado 0.
Cálculo de la Tasa Interna de Retorno La Tasa Interna de Retorno TIR es el tipo de descuento que
hace igual a cero el VAN:

Sin embargo, el cálculo obtenido puede estar bastante alejado de la TIR real.
Uso general de la TIR
Como ya se ha comentado anteriormente, la TIR o tasa de rendimiento interno, es una
herramienta de toma de decisiones de inversión utilizada para conocer la factibilidad de diferentes
opciones de inversión.
El criterio general para saber si es conveniente realizar un proyecto es el siguiente:
 Si TIR >=r Se aceptará el proyecto. La razón es que el proyecto da una rentabilidad mayor
que la rentabilidad mínima requerida (el coste de oportunidad).
 Si TIR <=r Se rechazará el proyecto. La razón es que el proyecto da una rentabilidad menor
que la rentabilidad mínima requerida
Representa el costo de oportunidad.
2.6.6.1. DIFICULTADES EN EL USO DE LA TIR
 Criterio de aceptación o rechazo. El criterio general sólo es cierto si el proyecto es del tipo
"prestar", es decir, si los primeros flujos de caja son negativos y los siguientes positivos. Si el
proyecto es del tipo "pedir prestado" (con flujos de caja positivos al principio y negativos
después), la decisión de aceptar o rechazar un proyecto se toma justo al revés:
o Si TIR >r Se rechazará el proyecto. La rentabilidad que nos está requiriendo este préstamo
es mayor que nuestro costo de oportunidad.
o Si TIR <= r Se aceptará el proyecto
 Comparación de proyectos excluyentes. Dos proyectos son excluyentes si solamente se puede
llevar a cabo uno de ellos. Generalmente, la opción de inversión con la TIR más alta es la
preferida, siempre que los proyectos tengan el mismo riesgo, la misma duración y la misma
inversión inicial. Si no, será necesario aplicar el criterio de la TIR de los flujos incrementales.
 Proyectos especiales, también llamado el problema de la inconsistencia de la TIR. Son
proyectos especiales aquellos que en su serie de flujos de caja hay más de un cambio de signo.
Estos pueden tener más de una TIR, tantas como cambios de signo. Esto complica el uso del
criterio de la TIR para saber si aceptar o rechazar la inversión. Para solucionar este problema,
se suele utilizar la TIR Corregida.
2.7. |||||||||||||||||||||||||||||||||||||||||
2.8. Ingeniería Web.
La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y
cuantificables de desarrollo eficiente, operación y evolución de aplicaciones de alta calidad
en la World Wide Web. La Ingeniería Web es una versión adaptada del enfoque de la
Ingeniería de Software que propone una estructura ágil, pero disciplinada, para construir
sistemas y aplicaciones basados en la web con calidad industrial (Pressman, 2008)
2.8.1. Definición de Ingeniería Web
Una Aplicación Web (en lo sucesivo también denominada WebApp) es la forma en que se
denomina a una categoría de software centrada en redes y que agrupa una amplia gama de
aplicaciones diferentes a las conocidas como nativas. Son poco más que un conjunto de
archivos de hipertexto vinculados que presentan información con uso de texto y gráficas
limitadas. Están integradas con bases de datos corporativas y aplicaciones de negocios,
desde cierto punto de vista se considera como un esfuerzo multidisciplinario debido al 32
manejo de múltiples formatos, siendo susceptible de efectos éticos y legales. (Pressman,
2010)
2.8.2. Características de aplicaciones Web
 Pueden ser ejecutadas en múltiples plataformas ya que no hacen uso del sistema
operat1ivo del terminal o equipo, sino del navegador implementado para su ejecución.
 No se instalan en el dispositivo y consiguen una experiencia de operación muy similar a
una aplicación nativa, pero requieren conexión constante a Internet.
 La inversión de recursos para su desarrollo se realizará una sola vez para múltiples
plataformas, pero se deberá optimizar en cada una de ellas para obtener el mejor
rendimiento de cada ambiente.
 El diseño de interfaz está condicionado por necesidades de claridad y simplicidad sobre
la de impacto.
 Su funcionalidad puede variar desde navegación/consulta de ABMs hasta complejos
servicios transaccionales de comercio electrónico. (Olsina, 1999)

2.8.3. WebML (Web Modeling Languaje)

WebML es un lenguaje de modelado gráfico utilizado para apoyar las actividades del diseño de
sitios Web. Provee gráficos, formalismos, especificaciones y diseño de procesos apoyados por
herramientas gráficas. Define varios tipos de diagramas: de estructura, composición y navegación.
(Carmona, 2008)

2.8.4. Diseño en WebML

El diseño de aplicaciones en WebML consiste en especificar sus características en términos de
varios tipos de abstracciones ortogonales, los cuáles son:
 El modelo estructural
 El modelo de hipertexto
 El modelo de presentación
2.8.4.1. Modelo Estructural
El modelo de datos representa las diferentes tablas de datos y sus relaciones que son
necesarias para una aplicación Web concreta. Se pueden utilizar:
Diagramas de Entidad-Relación (E-R) que muestran todas las tablas, los diferentes campos
de cada tabla, y las relaciones entre ellas
Diagramas UML de clases que pueden representar la misma información que un diagrama
de Entidad - Relación por lo que puede usarse de manera equivalente e incluso información
adicional sobre el modelo de datos (Carmona, 2008).
Figura 2.3 Modelo Estructural
Fuente: Pedro Muñoz Merino

2.8.4.2. Modelo Hipertexto

 Un modelo por cada hipertexto
 Cada hipertexto describe una vista del sitio
o Modelo de composición. Representa las páginas de un hipertexto y cada página que
elementos de contenido tiene
o Modelo de navegación. Representa los enlaces entre las diferentes páginas y sus
elementos de contenido (Carmona, 2008).
Figura 2.4 Modelo Hipertextol
Fuente: Pedro Muñoz Merino

 Elementos del modelo de hipertexto

Tabla 2.1 Elementos del modelo de hipertexto
Fuente: Elaboración propia
Elemento Descripción Propiedades
Unidad de Datos Atributos de la instancia de  Nombre
alguna entidad.  Entidad fuente
 Selector
 Atributos
Unidad de Datos Múltiples Atributos de las instancias de  Nombre
algunas entidades.  Entidad fuente
 Selector
 Atributos incluidos
 Cláusula de orden
Unidad índice Listado de instancias de  Nombre
entidades a través de algún  Entidad fuente
atributo descriptivo, además  Selector
permite su selección  Atributos incluidos
  Cláusula de orden
Unidad de desplazamiento o Navegación en un conjunto de  Nombre
navegación objetos ordenados  Entidad fuente
 Selector
 Bloque de factores
 Cláusula de orden
Unidad de ingreso Formulario para recolectar  Nombre
datos del usuario  Para campo
 Entidad fuente
 Selector
 Atributos incluidos
 Cláusula de orden

2.8.4.3. Modelo de Presentacion

Define como lucirá la vista del sitio WebML incluye un modelo simple de presentación
que permite colocar contenidos dinámicos en la página además de aplicar estilos distintos
para cada uno. (Carmona, 2008).
2.8.5. Características WebMl
 Pueden ser ejecutadas en múltiples plataformas ya que no hacen uso del sistema
operativo del terminal o equipo, sino del navegador implementado para su ejecución.
 No se instalan en el dispositivo y consiguen una experiencia de operación muy similar a
una aplicación nativa, pero requieren conexión constante a Internet.
 La inversión de recursos para su desarrollo se realizará una sola vez para múltiples
plataformas, pero se deberá optimizar en cada una de ellas para obtener el mejor
rendimiento de cada ambiente.
 El diseño de interfaz está condicionado por necesidades de claridad y simplicidad sobre
la de impacto.
 Su funcionalidad puede variar desde navegación/consulta de ABMs hasta complejos
servicios transaccionales de comercio electrónico.
 Al igual que en la Ingeniería de Software, en la Ingeniería Web también se realizan las
denominadas Actividades CGC (de Control y Garantía de la Calidad) como el
establecimiento y supervisión de estándares, revisiones técnicas formales, análisis y
seguimiento/registro de informes, entre otros; sin embargo otros aspectos valorativos
que le son exclusivos están relacionados a criterios de usabilidad, funcionabilidad,
fiabilidad, seguridad, eficiencia y mantenibilidad, en el marco de la escalabilidad
(Olsina, 1999)
2.8.6. Objetivos Principales de WebMl
Al proporcionar especificaciones gráficas mediante un proceso de diseño integral
desarrollado con herramientas de diseño visual, sus principales objetivos consisten en:
 Expresar la estructura de una aplicación: Soportar una colección de conceptos que
posibiliten un diseño de alto nivel, proveyendo especificaciones gráficas para producir
una descripción abstracta de la WebApp.
 Prestar múltiples vistas de un mismo contenido.
 Separar el contenido de la información de su composición en las páginas, la navegación
y la presentación, que puede ser definido y desarrollado de forma independiente.
 Almacenar meta-información: Registrar información recopilada durante el proceso de
diseño de un repositorio que pueda utilizarse durante el tiempo de vida útil de la
solicitud de generación dinámica de la página web.
 Permitir la especificación de las operaciones de manejo de datos para actualizar el
contenido del sitio o la interacción con servicios externos.
 Modelar usuarios y comunidades. (Ceri, 2012)
2.9. Ventas
Tiene múltiples definiciones dependiendo del contexto en el que se maneje. La venta es el
intercambio de servicios y productos. Es a su vez entendida como un contrato donde el sujeto que
actúa como vendedor transmite un derecho, bienes o servicios al comprador a cambio de una
determinada suma de dinero. La venta puede ser tanto un proceso personal como impersonal
donde el comprador puede ser influido por el vendedor. Desde el punto de vista contable y
financiero, la venta es el montón total cobrado por productos o servicios prestados. En cualquier
situación, las ventas son el corazón de cualquier negocio y actividad fundamental.
La definición que se tomara es que las ventas es un cambio de productos y servicios por dinero.
Desde el punto de vista legal, se trata de la transferencia del derecho de posesión de un bien a
cambio de dinero. (Arana, 2014)

2.9.1. Control de Ventas

En este módulo permitirá realizar la gestión correspondiente a cotizaciones, pedidos, remisiones y
facturación de mercancía, venta de productos y servicios en diferentes unidades de medida

2.10. Bibliografía
 https://www.sage.com/es-es/blog/tasa-interna-de-retorno-tir-que-es-y-como-se-
calcula/
 http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm
 https://carespe2.blogs.uv.es/
 https://www.ecured.cu/SGBD
 https://www.google.com/search?q=modelo+de+dise
%C3%B1o+de+base+de+datos&ei=NusCY7TKJPj25OUPxPeZyAg&oq=MO
DELO+DE+DISE
%C3%91O+DE+BASE+DE&gs_lcp=Cgdnd3Mtd2l6EAMYADIFCAAQgAQy
BggAEB4QFjoECAAQQzoHCC4Q1AIQQzoHCAAQsQMQQzoQCC4QsQM
QgwEQxwEQ0QMQQzoUCC4QgAQQsQMQgwEQxwEQ0QMQ1AI6CwguE
IAEELEDEIMBOgsIABCABBCxAxCDAToICAAQgAQQsQM6CAguEIAEE
LEDOggILhCABBDUAjoICAAQsQMQgwE6CggAELEDEIMBEEM6CAgAE
B4QDxAWSgQIQRgASgQIRhgAUABYui5g3DRoAHABeACAAdABiAGDFp
IBBjE5LjcuMZgBAKABAcABAQ&sclient=gws-wiz
 https://www.idqweb.com/que-es-php/
 https://www.ictea.com/cs/index.php?rp=/knowledgebase/8663/iQue-es-el-
lenguaje-de-programacion-PHP.html#:~:text=Fue%20uno%20de%20los
%20primeros,genera%20la%20p%C3%A1gina%20Web%20resultante.
 https://www.ictea.com/cs/index.php?rp=/knowledgebase/8790/iQue-es-el-
lenguaje-de-programacion-JAVA.html
 http://www.disca.upv.es/Enheror/Pdf/Actauml.Pdf
 https://www.academia.edu/17124068/
Aprendiendo_UML_en_24_Horas_Joseph_Schmuller